Multilink Processors (Link 11/16/22) and Integration Architectures

Transcription

1 Multilink Processors (Link 11/16/22) and Integration Architectures Authors: Serdar ÖZTÜRK, Emine ESEN TAŞDEMİR, Murat ŞAHİN MilSOFT Yazılım Teknolojileri A.Ş. Teknokent, ODTU Ankara / TURKEY Mailto:sozturk@milsoft.com.tr, eesen@milsoft.com.tr, msahin@milsoft.com.tr Abstract Data Link systems can be deployed to various platforms (ship, air, and land) in four different architectures: 1. Multilink Processor is embedded into Combat Management System (CMS)/ Avionic Mission Computer over native interface for full functionality 2. Multilink Processor integrated to legacy CMS with an adaptation module and adding Link Console for enhanced modernization in case CMS has limited functionality 3. Multilink Processor connected to legacy CMS with an adaptation module for modernization with limited functionality 4. Multilink Processor with Link Consoles for standalone capability for gaining data link capability in a simple and cheap way. Different architectures are suitable for different type of projects/systems. Option 1 is suitable for providing tactical data link capability to new systems. Option 2, 3, and 4 provide cost effective tactical data link capability to legacy systems (modernization projects) with minimum or no modification depending on the data link capability to be gained. MilSOFT has developed a Multilink Processor (Mil-DLP) which provides full compatibility to STANAG 5516 (Edition 5/6), STANAG 5511 (Edition 8), STANAG 5522 (Edition 4) and STANAG 5616 (Edition 5), including related Data Link Change Proposals (DLCPs -Foxtrot versions) and which can be fitted to target platform in all of the above integration architectures. MilSOFT has also its own fully Link16 compliant CMS. In this article utilization of tactical data link processors in various integration approaches and challenges faced during integration are detailed and MilSOFT s solution for these integration architectures and challenges are discussed. 1. Introduction The success of a military operation highly depends on the level of the coordination among armed forces. Historically, command and control communications have been carried on voice communication. Voice communication was inadequate to interchange large amount of data in a fast and secure way. To solve the problem, digital communication methods like Tactical Data Links (TDLs) have been developed. The throughput, granularity and variety of data produced and to be shared between platforms increase continuously which forces improvements in existing tactical data links and introduction of new ones. Since upgrading legacy Combat Management Systems (CMS) to support new or improved data link systems is costly, a new and complex issue arises; integration of TDL systems with CMS. 2. Tactical Data Links Tactical Data Links provide transmission of bit-oriented tactical digital information over

2 a common network which is continuously and automatically updated. The main goal of tactical data links is to establish an unambiguous communication backbone to support various tactical operations. In order to achieve this goal each tactical data link is based on a standard to ensure interoperability among different units. Throughout the history many tactical data link systems and command and control systems, whose data structure and capabilities are based on these data links, has been developed. Today some of these data links have become obsolete, Link 16 and Link 22 arose as the modern tactical data links. There is also a continuing demand for Link 11 to networking with existing naval platforms. These links cover largest set of functional areas, provide secure & jamresistant communication, increased throughput and high data granularity. These links also constitute the backbone of the network centric warfare and many systems that are being equipped with these data links. Following table shows the functional areas covered by different TDLs: Functional Area Link 11 Link 16 Link 22 Platform Situational Awareness Air Surveillance Land Surveillance N/A Surface Surveillance Sub-surface Surveillance Space Surveillance N/A Electronic Warfare Weapon Coordination Command Aircraft Control N/A Network Management N/A Imagery N/A N/A Table 1: TDL Functional Areas Many platforms with CMS based on old link systems are being equipped with modern links like Link 16 and Link 22. Above table also shows that if the onboard CMS on a platform is not based on a modern link, equipping the platform with a modern TDL system does not offer the intended gain. For example, if the onboard CMS is based on Link 11, when the platform is equipped with Link 16, the platform cannot exchange space tracks over Link 16. But with a complementary CMS adaptation module and additional link consoles capable of handling and displaying space tracks, the platform can gain space surveillance capability even when the existing CMS is not capable of space surveillance. Missing functional areas and messages are implemented by the complementary CMS adaptation module. 3. MilSOFT s Multilink Processor (Mil- DLP) MilSOFT has developed Multilink Processor which provides the data link capability to share tactical information with other Link 22, Link 16, and/or Link 11 capable platforms. Mil-DLP communicates with the CMS using a normalized message structure which is based on Link 11, Link 16, and Link 22 messages. This normalized interface, which includes all the data elements of all the links, is independent from a specific link and isolates the CMS from data link specific data structures and protocols. Figure 1 Normalized Message Structure The system design of MilSOFT Multilink Processor provides a cost effective solution for advanced tactical data link capability for legacy systems (modernization projects) as well as new Combat Management Systems and Avionic Mission Computers. The

3 solution provides an advanced tactical data link processing capability for the legacy systems with minimum modification, while providing the CMS and mission computers seamless advanced tactical data link communication without link specific implementation effort. 3.1 Mil-DLP Functionalities Mil-DLP provides the following data link functionalities: Link 11/16/22 Multilink processing Air, surface, subsurface, land and space surveillance Terminal initialization, Network management, control and monitoring PPLI, Platform and system status Correlation of local and remote tracks Correlation of remote tracks from different links Weapon management and coordination Command messages Aircraft control Track number management Information management Electronic warfare control and coordination Data link filters Data forwarding between links Digital image transfer Terminal free text individual Link messages in order to meet different platform requirements. Mil-DLP is a distributed system over DDS (Data Distribution Services) middleware. Depending upon the platforms size, the system can be deployed on a single computer or on multiple servers. Portable: Data link processing logic is isolated from external dependencies and Mil-DLP is developed independent from platform, Operating System and hardware. Open to Modifications/Improvements: Mil- DLP is developed by following Open Architecture Computing Environment (OACE) standard and it can be modified or improved by spending little effort to adapt changes in Link standards like addition of a new Link, addition/deletion of messages or changes in message fields. Suitable for Different Integration Models: Mil-DLP can be deployed standalone, or it can be a part of Mission Computer, or it can be integrated with Legacy CMS systems through an adapter unit or it can be deployed together with MilSOFT CMS without using an adapter. 3.2 Mil-DLP Architecture Mil-DLP architecture is developed using the Architectural Trade-Off Analysis Methodology (ATAM) process defined by Software Engineering Institute (SEI). During Mil-DLP design process, different platform requirements and continuous changes in Link standards were main considerations for the architecture. Hence the following four quality attributes are considered to be the most important features of Mil-DLP: Scalable: Mil-DLP can easily be scaled by enabling/disabling Links (11/16/22) or

4 Link operations. Link HMI supports multiple symbology standards like APP-6B, Mil-Std- 2525, and NTDS which can be changed at runtime by the operator. Link HMI is capable of displaying maps in different formats like S-57, S63, and ARCS using MilSOFT PiriMap GIS library. JREAP Extension: JREAP is a military standard which defines a protocol and message structures to enable TDL messages to be transmitted over digital media to non-tdl units. Besides providing TDL picture to remote systems which have no TDL connection capability JREAP extension can also be used to extend the range of a TDL network, to connect distant systems or to join disparate TDL networks. JREAP extension provides a cost-effective TDL connection capability to platforms or systems which are not equipped with the link communication equipment. Figure 2 Mil-DLP Architecture 3.3 Mil-DLP Extensions Mil-DLP also contains some additional products which can be delivered together with the data link processor. These are Link HMI (Human Machine Interface), JREAP (Joint Range Extension Application Protocol), and SIMPLE (Standard Interface for Military Platform Link Evaluation) extensions. Link HMI Extension: Link HMI is a java based, user friendly application. It enables the operator to fully utilize all Link 11, Link 16, and Link 22 functionalities within the same application. Link HMI contains two main windows; Tactical Picture Windows containing map, symbologies, and other information overlayed on the map window, and Information Window, that provides tabular display dialogs to the operator to perform all SIMPLE Extension: SIMPLE is a NATO standard which defines a protocol to provide a solution to geographically separated TDL units to exchange environment data and TDL messages to conduct detailed TDL interoperability testing. Using the SIMPLE extension, Mil-DLP can be connected to other TDL units or TDL simulators in a standard way without using any Link terminal device. 4. Integration of TDL and CMS Systems Integration of TDL with CMS are necessary to perform effective operations in the net centric warfare environment. Level of the integration between TDLs and CMS directly affect benefit of TDL during operations. All integration methods aim to benefit from tactical data link functional areas, data dictionary and granularities to the maximum extent, and try to prevent data losses. However, due to limited or different

5 capabilities of CMS, cost and schedule issues, various integration methods are used to support TDLs functionalities and hence different scale of integrations can be achieved. In this article, three important concerns of TDL integration to CMS are focused. Issues related with these concerns should be taken into account carefully. 1. Data Link Processor Interfaces Data dictionary and granularities of interface data Reception and storage of TDL data Correlation and conflict resolution with TDL data 2. Sensor Data Processing CMS may have a legacy multi sensor tracking system which presents [correlated/fused] data to the Multilink processors. TDL standards require track data to be registered, so that the alignment of local and remote data can be optimized and dual designations are minimized. Data registration errors can occur through: Geodetic Position Errors where your platform is and where it is reported Sensor Registration Errors how good your sensors are Data Processing Errors data conversion errors TDL units should report their real time data with trusted positional accuracy based on track quality values. This is essential for removing dual designations and assessing reporting responsibility for a clear and reliable tactical picture. This can be often difficult depending on sensor quality and track management capabilities of CMS. 3. HMI Functionality and Display Modern TDLs require automated operational functions and HMI should be developed to support operator level interoperability. HMI should cover all the tactical picture established using TDL and should conform to a common symbology standard to minimize operator level interoperability issues. APP-6B or Mil-std-2525 may be used as a common guide for symbology and PPLI symbology should also be considered. 5. Data Link Deployment Architectures and MilSOFT s Solutions 5.1 Multilink Processor embedded into CMS In order to utilize all of the functionalities and the achievements that are defined with modern TDLs by the CMS, the best integration model is the Multilink Processor natively and fully integrated to CMS. In this integration model, CMS software has to be developed or upgraded according to the tactical data link elements and all necessary CMS functions for link operations have to be implemented. Data Link Processor Interfaces: Data Dictionary and granularities of interface data are fully compatible with TDLs. Data or precision losses are not observed. Automated or operator interactive CMS functions for link operations are implemented by CMS. Data received from TDLs are stored on CMS, processed and displayed to the operator if necessary. Sensor Data Processing: CMS performs sensor registration correction in order to minimize sensor errors. Since CMS s data structure and granularities are compatible with TDLs, data conversion errors are minimized. Sensitive own unit positional data can be held and transferred to

6 Multilink processors. Track quality and positional error mapping on STANAGs is used by CMS, so positional error information on all link participants is aligned and correlation/decorrelation results on all parties are consistent. HMI Functionality and Display: HMI is designed and implemented to provide all required operator interactions for data links. Tactical picture reflects all TDL parameters. APP-6B or Mil-std-2525 can be used as a guide for symbology. CMS console dedicated to any functionality also implements the operator interactions of the corresponding TDL functional areas. A separate link console may be included for handling of data link specific processes, initializing, control and monitoring of data links and link communication equipment. Figure 3 Multilink Processor embedded into CMS MilSOFT s Solution: MilSOFT has also its own CMS Software which is able to fully support Link11/16/22 operations. This CMS is developed according to the Link 11/16/22 data dictionary and processing rules to perform the functionalities addressed by the data links without performing any information transformations to minimize data loss and interoperability problems. Multilink Processor and CMS are fully integrated and all functionalities are available without any degradation. MilSOFT uses same computing environment for its CMS and Multilink Processor products. This enables seamless integration of CMS with Multilink Processor. 5.2 Multilink Processor connected to legacy CMS with an adaptation module with Link Console Although fully integrated TDL-CMS systems seems an ideal solution, in reality it is not cost and effort effective to develop a new CMS or modify an existing CMS. Some of legacy CMSs do not have any previous link capability and mostly only have Link 11 based CMS. In order to decrease the cost and effort of the modernization, upgrading the legacy CMS software capabilities is avoided and an adaptation module is developed to integrate TDLs with CMSs and to fill the gap between CMS capabilities and the data link functions. In this type of modernization, operator interactions related to the functionalities that CMS cannot provide are performed on the dedicated link consoles instead of the CMS software and related data processing and CMS actions are performed by adaptation module. Therefore the existing CMS is complemented by the new Link Consoles and the adaptation unit. Data Link Processor Interfaces: Adaptation unit provides an interface between CMS and TDL, also it complements the legacy CMS by implementing the missing functional areas and messages. Necessary data structure conversions are done by the adaptation unit. Automated or operator interactive CMS functions for link operations which are missing within the legacy CMS are performed by the adaptation unit. Legacy CMS software only receives and processes the information which can be performed by the existing CMS capabilities. Adaptation unit may provide filtering capability if CMS data load capacity is less than the data link s capacity. Full

7 functionality cannot be achieved. Data loss cannot be prevented but minimized, data granularity loss can be observed. Sensor Data Processing: If legacy CMS cannot perform sensor registration corrections, this functionality is performed by the adaptation unit. According to the data structure of the legacy CMS, data conversion errors may be observed. Track quality and positional error mappings defined in STANAGs may not be used by the CMS. The adaptation unit maps CMS track qualities to STANAG track qualities. If CMS cannot support STANAG track quality range, incorrect correlations and reporting responsibility assessments may occur. HMI Functionality and Display: Since a new Link HMI is developed, required operator interactions are implemented. Tactical picture reflects all TDL parameters. Operator actions for new capabilities may not be integrated with related CMS functions. In this case, verbal interaction between link operator and CMS operator is required. For example, when a hold fire command is received from link and accepted by link operator, all the engagements of own unit shall be broken. Since this cannot be an automated action link operator shall ask the weapons operator to break the engagement. APP-6B or Milstd-2525 can be used as a guidance for symbology. Figure 4 Multilink Processor-CMS with Adaptation Unit and Link Console MilSOFT s Solution: MilSOFT has developed adaptation units for various legacy CMSs. This adaptation unit provides a gateway to transfer Link 16/22 information to legacy CMS on Link 11 data structures or any other, in order to provide integration with minimum change to the existing systems. Another adaptation requirement is related with additional data exchange and process capabilities which CMS system shall be gained for Link 16 utilization. Even though all the information received from the TDL systems are transformed to the CMS data structure and presented to the operators, some of the information could not be used as an input to legacy CMS functions because simply the CMS does not understand it or cannot perform as expected. Mission assignment, Flight Path, Imagery, Target Sorting, Correlation capabilities are example capabilities which cannot be performed by a Link 11 based legacy CMS. Adaptation unit includes implementation of these functionalities and can perform necessary actions and therefore overall system is fully complemented for the Link16 operations. MilSOFT has also developed Link HMI console application for this type of integration. Link console provides the operator with the capability to initiate, display and interact with all the data exchanged over tactical data links. Link console displays tabular and graphical alerts to the operator, allows initiating manual information transmission on tactical data links, provides manual response capability to received commands and requests, displays all the received and calculated data. Information is presented to the operator on a tactical picture window and on information windows. All surveillance entities is presented to the operator on tactical picture window with unique symbols.

8 5.3 Multilink Processor connected to legacy CMS with an adaptation module This model is very similar to Multilink Processor connected to legacy CMS with an adaptation module with Link Console except Link Console. Instead of integration of the Link Console, the existing CMS console software is modernized to cover all Link related functional areas. HMI functionality is limited to scale of CMS console update. Figure 5 Multilink Processor-CMS with Adaptation Unit MilSOFT s Solution: MilSOFT provide this integration models for the projects which do not require a separate link console. Similar concerns and problems are faced with integration models with consoles. 5.4 Multilink Processor with Link Consoles for standalone Link capability In this model, there is no integration between TDL and CMS. Data received from tactical data link is processed by Multilink processor and displayed to operator via Link Console. This model is cheap and simple way of providing tactical data link utilization. However, since CMS functionalities cannot be used, operational benefits are limited. Figure 6 Standalone with Link Console MilSOFT s Solution: MilSOFT has deployed a limited capability CMS system to be used in this model which is called LinkC2. This CMS manages and processes all the data exchanged over data links in accordance with the rules defined in STANAGs. By this CMS module and link consoles it is possible to initiate and receive all messages and provide the operator with a clear tactical picture. 6. Other Integration Issues 6.1 Communication Protocols If CMS and TDL systems are using different communication or middleware architectures, then a common communication protocol may be constructed between two different systems or an adapter unit is developed to work as a gateway between two different communication mechanisms. Figure 7 Integration using Common Communication Protocol Figure 7 shows the integration architecture using a common communication protocol between TDL and CMS systems. For

9 example TCP/IP protocol can be used as a common communication protocol. In this case, a connection needs to be established between TDL and CMS adapter units. One of them should act as a client and the other one as a server side. Systems may not be up and running at the same time. For a smooth integration, client side should periodically try to connect to the server side. Then, whenever the server side is up, the connection is established immediately. When TCP/IP is used as the common communication protocol, at the sending side, message data structures are serialized to bit stream, then transferred to receiver side, at the receiver side bit stream data are deserialized back to message data structures again. In this architecture, for correct decoding, each message needs to be uniquely identified. 6.2 Different CPU Architectures If there are CPU architecture differences between TDL and CMS systems, endianness problem occurs. For example Sparc based computers store data in big-endian order whereas Intel based computers store in littleendian order. To solve this problem, one side may convert all data to the correct byte ordering, but this choice is very open to errors and requires extra effort for integration. Another solution can be using Common Data Representation (CDR) during data serialization and de-serialization. CDR is a transfer syntax, mapping from data types defined in OMG IDL (Interface Definition Language) to a bi-canonical, low-level representation for transfer between agents. Since CDR provides a common representation of the data, it is useful to use it for data encoding/decoding in order to ensure compatibility between computer architectures having different endianness. CORBA specification defines the CDR standard. MilSOFT s DDS middleware uses CDR standard to serialize and de-serialize the message data structures, therefore it can be used between different CPU architectures easily. Figure 8 Integration using Adapter Unit as Gateway Figure 8 shows the integration architecture using an adapter unit as a gateway. In this architecture the adapter unit can communicate through both Middleware A and Middleware B. It receives data from one middleware, converts or prepares data for the other middleware and publishes the data. If TDL and CMS systems are developed by different companies, and middleware libraries are not publicly available COTS products, then these libraries need to be provided to the adapter developing company. For security or Intellectual Property Rights concerns, this methodology may not be preferred. Because of using the middleware library, non-related messages can also be sniffed from systems. 6.3 Time Synchronization Synchronization of time between TDL and CMS systems are very important. Each positional data is time stamped using the observation time of the position. When an entity is to be displayed on operator consoles or to be sent to the Link, the position of the entity is extrapolated using the time difference between the observation time and the current time, and the course, speed values of the entity. The most common method for synchronizing time between different systems is using Network Time Protocol (NTP). NTP applications are available on most of the operating systems and it is very easy to configure it. Generally CMS is selected as the reference time system, and configured as the NTP server,

10 and TDL system is configured as NTP client. The NTP client application periodically checks time difference and updates the system time if necessary. 6.4 Initialization and Synchronization of TDL and CMS Systems During initialization, before sharing important tactical information, two systems should technically be synchronized by establishing connections, time synchronization and receiving appropriate system state/mode or heartbeat data from the count part system. Otherwise important tactical data might be lost or misinterpreted by the receiving system. After technical level synchronization, all tactical information is shared between TDL and CMS systems so that two systems have the same tactical picture at the end of the initialization period. During operation, technical level synchronization is continuously monitored, and whenever the synchronization is lost, exchange of tactical information is suspended. Since sometimes systems are loaded with high amount of track data, in order not to have problem in reception of technical messages in time, two separate channels can be established. One channel can be dedicated to technical messages like periodic heartbeat and state/mode messages, and another channel can be dedicated to tactical Link related messages. 6.5 Definition of Interfaces between TDL and CMS Systems For a smooth integration, a technical agreement document which clearly defines the interface between TDL and CMS systems should be prepared. This document usually contains message and field definitions, communication mechanisms, system state/modes, interaction diagrams, responsibilities of each system etc. If messages are defined in a machine readable format like XML or IDL, the integration process can be less error-prone and easier, since these formats enable auto-code generation for message encode/decode purposes. Mil-DLP provides a normalized message interface for CMS integration. This interface can be provided in machine readable XML and IDL formats. In addition the interface is also provided in human readable HTML format. 6.6 Coordinate System Conversions If the legacy system is based on Link 11 data structure and design, the first major adaptation requirement can be related with positional data. The legacy CMS may use Cartesian coordinate system. In this case all positional data are stored in the Cartesian X/Y (data miles) coordinate system whose origin is located at a position reference. However in Link 16, entities are reported as latitude and longitude in WGS-84 format. Adaptation unit converts the reported position information between WGS-84 format and Cartesian coordinates. STANAG 5516 offers a lat/long to Cartesian coordinate conversion algorithm, this algorithm may be implemented in the adaptation unit. However if CMS uses Cartesian coordinates with slant ranges, this algorithm gives incorrect results when the track has altitude. So, the algorithm that should be implemented has to be determined depending on the coordinate system used by CMS. 7. Conclusion There is no perfect solution for Multilink Processor and legacy CMS integration. Integration model shall be selected according to the operation needs, required capability, cost, time, and maintainability issues. Fully integrated models provides full functionality. In this aspect, operational

11 benefits high but on the other hand, fully integrated systems are usually complex, are not cost effective and their maintainability is relatively difficult. Time needs for development of such systems is longer them modernization of current systems. Partial integration models (with or without a link console) are relatively simple and cheaper. Due to modular structures, maintainability is easier. However, functionality degradation is usually unavoidable. Standalone models provide cheaper solutions. These models provide reception of data from links and display to user. However, transmission capabilities are limited, operational functions are inadequate and most of the time, used as a backup system. 8. References [1] STANAG 5516 TACTICAL DATA EXCHANGE - LINK16 [2] STANAG 5511 TACTICAL DATA EXCHANGE - LINK11/LINK11B [3] STANAG 5522 TACTICAL DATA EXCHANGE LINK22