Automated integration of real-time and non-real-time defense systems

Journal Pre-proof Automated integration of real-time and non-real-time defense systems Emre Dalkiran, Tolga Önel, Okan Topçu, Kadir Alpaslan Demir PII:

S2214-9147(19)30941-9

DOI:

https://doi.org/10.1016/j.dt.2020.01.005

Reference:

DT 589

To appear in:

Defence Technology

Received Date: 5 September 2019 Revised Date:

30 December 2019

Accepted Date: 8 January 2020

Please cite this article as: Dalkiran E, Önel T, Topçu O, Demir KA, Automated integration of realtime and non-real-time defense systems, Defence Technology (2020), doi: https://doi.org/10.1016/ j.dt.2020.01.005. This is a PDF file of an article that has undergone enhancements after acceptance, such as the addition of a cover page and metadata, and formatting for readability, but it is not yet the definitive version of record. This version will undergo additional copyediting, typesetting and review before it is published in its final form, but we are providing this version to give early visibility of the article. Please note that, during the production process, errors may be discovered which could affect the content, and all legal disclaimers that apply to the journal pertain. © 2020 Production and hosting by Elsevier B.V. on behalf of China Ordnance Society.

Defence Technology Journal Automated Integration of Real-Time And Non-Real-Time Defense Systems Title Page and Author Biographies

TITLE PAGE Automated Integration of Real-Time and Non-Real-Time Defense Systems Emre DALKIRAN Barbaros Naval Science and Engineering Institute, Turkish Naval Academy, National Defense University, Tuzla, Istanbul, 34942, Turkey. [email protected] Tolga ÖNEL Department of Computer Engineering, Turkish Naval Academy, National Defense University, Tuzla, Istanbul, 34942, Turkey. [email protected] Okan TOPÇU Department of Computer Engineering, Middle East Technical University Northern Cyprus Campus, Kalkanli, Guzelyurt, Mersin 10, 99738, Turkey. [email protected]

Kadir Alpaslan Demir* Department of Software Development, Turkish Naval Research Center Command, Pendik, Istanbul, 34890, Turkey. [email protected]

* Corresponding Author Tel. +90 532 3333988 E-mail: [email protected]

Defence Technology Journal Automated Integration of Real-Time And Non-Real-Time Defense Systems Title Page and Author Biographies ABSTRACT Various application domains require the integration of distributed real-time or near-real-time systems with non-real-time systems. Smart cities, smart homes, ambient intelligent systems, or network-centric defense systems are among these application domains. Data Distribution Service (DDS) is a communication mechanism based on Data-Centric Publish-Subscribe (DCPS) model. It is used for distributed systems with real-time operational constraints. Java Message Service (JMS) is a messaging standard for enterprise systems using Service Oriented Architecture (SOA) for non-real-time operations. JMS allows Java programs to exchange messages in a loosely coupled fashion. JMS also supports sending and receiving messages using a messaging queue and a publish-subscribe interface. In this article, we propose an architecture enabling the automated integration of distributed real-time and non-real-time systems. We test our proposed architecture using a distributed Command, Control, Communications, Computers, and Intelligence (C4I) system. The system has DDS-based real-time Combat Management System components deployed to naval warships, and SOA-based non-real-time Command and Control components used at headquarters. The proposed solution enables the exchange of data between these two systems efficiently. We compare the proposed solution with a similar study. Our solution is superior in terms of automation support, ease of implementation, scalability, and performance. Keywords: Systems Integration, System of Systems, Systems Engineering, Software Engineering, C4I Systems, Defense Systems, Data Distribution Service, DDS Integration, Java Message Service, JMS.

Short Biographies of Authors Emre Dalkıran, M.S. Emre Dalkıran is a graduate student at Georgia Institute of Technology, USA. He has a B.S. in Computer Engineering and an M.S. in Command, Control, Communications, Computers, and Intelligence (C4I) Systems from Turkish Naval Academy. His research interests include C4I Systems, defense systems development, systems integration, and middleware software. Tolga Önel, Ph.D., Assistant Professor Tolga Önel is an assistant professor of computer engineering in National Defense University, Turkey. He has a B.S. in Computer Engineering, an MS in Computer Science, and a Ph.D. in Computer Science. He worked as a research engineer in Turkish Naval Research Center Command for more than 10 years. He took a post as a software project officer in Turkish Naval Forces Headquarters. Dr. Onel has extensive experience in development and management of C4I systems and distributed defense information systems. His research interests include C4I systems, distributed systems, wireless sensor networks, and defense systems development.

Defence Technology Journal Automated Integration of Real-Time And Non-Real-Time Defense Systems Title Page and Author Biographies Okan Topçu, Ph.D., Associate Professor Okan Topçu is a faculty member in the department of Computer Engineering at METU NCC. Professor Topçu received his Ph.D. and M.S. degrees from the Middle East Technical University, Ankara, Turkey in 2007 and 1999 respectively. Prior to joining METU NCC, he worked as a faculty member in the department of Computer Engineering at Turkish Naval Academy. His current research interests include distributed simulation, agent-based simulation, intelligent agents, autonomous systems, model driven engineering, and creative evolutionary systems. Kadir Alpaslan Demir, Ph.D, Associate Professor Kadir Alpaslan Demir is a program manager of a large-scale defense system and an associate professor of management of information systems. Dr. Demir has an M.S. in Computer Science and another M.S. in Software Engineering, and a Ph.D. in Software Engineering from Naval Postgraduate School, USA. He also has an MBA from Gebze Technical University, Turkey. Dr. Demir served as a faculty member of department of computer engineering in Turkish Naval Academy. Dr. Demir has significant experience in development and management of large-scale defense and C4I systems. His research interests include C4I systems, defense systems development, distributed systems development, software engineering, unmanned aerial vehicles, and IT and software project management.

Automated integration of real-time and non-realtime defense systems Abstracts: Various application domains require the integration of distributed real-time or near-real-time systems with non-real-time systems. Smart cities, smart homes, ambient intelligent systems, or network-centric defense systems are among these application domains. Data Distribution Service (DDS) is a communication mechanism based on Data-Centric Publish-Subscribe (DCPS) model. It is used for distributed systems with real-time operational constraints. Java Message Service (JMS) is a messaging standard for enterprise systems using Service Oriented Architecture (SOA) for non-real-time operations. JMS allows Java programs to exchange messages in a loosely coupled fashion. JMS also supports sending and receiving messages using a messaging queue and a publish-subscribe interface. In this article, we propose an architecture enabling the automated integration of distributed real-time and non-real-time systems. We test our proposed architecture using a distributed Command, Control, Communications, Computers, and Intelligence (C4I) system. The system has DDS-based real-time Combat Management System components deployed to naval warships, and SOA-based non-real-time Command and Control components used at headquarters. The proposed solution enables the exchange of data between these two systems efficiently. We compare the proposed solution with a similar study. Our solution is superior in terms of automation support, ease of implementation, scalability, and performance. Keywords: Systems Integration, System of Systems, Systems Engineering, Software Engineering, System Implementation, C4I Systems, Defense Systems, Data Distribution Service, DDS Integration, Java Message Service, JMS.

I.

Introduction There are many application domains that can benefit from solutions enabling the integration of real-time or near-real-time and non-real-time systems. Smart cities, smart homes, ambient intelligent systems, and defense systems are among these application domains. Especially, in the defense domain, the cost of defense software systems increases exponentially. Therefore, cost-effective solutions enabling system of systems developments are highly valuable. The integration of existing real-time and non-real-time systems to achieve new or increased capabilities is a cost-effective solution in the defense domain. In this article, we propose a communication mechanism for the integration of real-time Data Distribution Service (DDS) systems, i.e., Combat Management Systems (CMSs) on naval warships and the non-real-time Command and Control (C2) systems at headquarters. On the battlefield, situational awareness is one of the critical factors for mission success. Situational awareness refers to the perception of elements on the battlefield in the current situation, comprehension of the current situation, and projection of the future status of the battlefield [31, 32]. Good situational awareness helps to achieve effective decision making. In the past two decades, a new concept namely Network Centric Warfare (NCW), which is also called Network-Enabled Capability, has emerged to replace platform-centric warfare [19]. In platform-centric warfare, each warfighting unit maintains an individual situational awareness that is bound by a geographical area due to limited sensor range. In the NCW paradigm, a shared battlespace awareness is created by networking geographically dispersed forces [1, 2]. For example, we achieve a shared battlespace awareness by networking CMSs on warships with C2 systems at headquarters. Warship combat management systems are real-time systems. C2 systems at headquarters are non-real-time systems. Therefore, in many cases, we need to integrate real-time and non-real-time defense systems. A CMS supports the military personnel on a warship and it has two primary functions. The first is to create a battlespace awareness in real-time. The second is to eliminate enemy forces using onboard weapon systems. The CMS generates a tactical picture with the track data from various sensors and using the data fusion algorithms. Afterward, the track information is sent to weapon systems at high frequencies to engage at enemy forces. This process needs to occur in real-time. The sensors on a warship include radars, sonars, identification of friend and foe (IFF) systems, optical, and infrared sensors. The sensory data is obtained in real-time at high frequencies. This sensory data is used to create a real-time tactical picture showing the locations of friendly and enemy forces. Therefore, CMSs are commonly real-time or near-real-time systems. DDS is an Object Management Group (OMG) specification that can be used for the creation of real-time middleware software. Today, various real-time defense systems use DDS middleware [3][4]. A DDS middleware handles data distribution in a predictable, deterministic, and efficient way for distributed systems with real-time constraints [5]. DDS is an important technology for mission-critical net-centric systems with its decoupling of space, time, and flow via anonymous publish/subscribe protocols, scalability, platform flexibility, and interoperability [6]. On the other hand, C2 systems used at military headquarters or commanding posts are enterprise systems. These enterprise systems are generally at an operational or strategic level. Various real-time and non-real-time defense systems provide information to these enterprise systems. C2 systems at headquarters help commanders to orchestrate the military entities to achieve a mission objective. Service-Oriented Architecture (SOA) has become a favored approach for designing enterprise systems not only in the civilian domain but also in the military domain. For example, NATO recommends SOA in the NATO Architecture Framework (NAF) [7, 26]. SOA was chosen by NATO C3 Board as the recommended method for information interoperability in NATO [38]. SOA is composed of standardized services such as web services. In this study, we provide interoperability between a real-time CMS system and a non-real-time C2 enterprise system, using Java Message Service (JMS) functioning as a bridge between two domains. We establish bi-directional communication between the CMS and the web service on the C2 enterprise system. In general, the CMS is called the real-time domain, and the C2 enterprise system is called the non-real-time domain. They are called domains because the data objects used in one system are only defined within that domain. Without transformations, the data objects used in one domain cannot be used in the other

domain. To make data exchange between these two types of systems and to integrate them, it is possible to write a custom integration software serving as a bridge. To develop this custom integration software, first, developers need to identify the related data objects used in both domains and the mappings between these data objects. Then, the developers need to manually write code that transforms a data object used in one domain to another data object used in the other domain. However, there are significant problems with this solution. First, this solution is error-prone due to manual coding. Second, the development effort is costly, again, due to manual coding. Third, its maintenance will be costly as the systems evolve. The contribution of this article is a solution enabling an automatic bridging of a real-time and a non-real-time system. Our solution overcomes the problems associated with manual implementations. We compare our solution with a previous study aiming at a similar integration. Note that the previous solution does not provide a sufficiently automated solution. Besides, our solution scales better. As a result, the solution offered in this study is a viable option for the integration of real-time (utilizing a DDS middleware) and non-real-time (utilizing SOA-based solutions) systems. There is not a single architecture that can support all types of systems. The architecture of a system determines the capabilities and limitations of a system. A system architect has to analyze the requirements of a system and choose the best architecture that optimally satisfies all requirements, minimizes life cycle cost, and ensures high quality. As a result, various different software architectures are developed to satisfy different needs. Our study basically proposes a solution to integrate two different specific types of systems. The proposed solution is applicable to cases in which there is a need to integrate a system based on a DDS architecture with another system based on architecture (such as Service Oriented Architecture) utilizing web services. The comparison of DDS versus Web services for C4I systems is discussed in [19]. According to this study, DDS performs much better in terms of satisfying real-time requirements for a C4I system. However, web services based on service-oriented architectures are highly popular for enterprise systems [19]. There are many technologies and tools supporting web services. There are many companies offering applications based on web service technology. There is a huge developer base for web application development. Web services based on service-oriented architectures are scalable. Therefore, many command and control (C2) systems without hard real-time constraints are developed based on service-oriented architectures utilizing web services. DDS has gained attention for a number of challenging application areas with real-time requirements such as air traffic management, industrial automation, smart grids, and financial applications [27, 28, 29]. In [30], the researchers utilize a DDS-based architecture to plan and coordinate multi-robot missions for lunar sample collection in unknown environments. In the DDS domain, a shared world model is created to ensure that each robot has the same knowledge of each other’s internal status [30]. DDS architecture enables the timely exchange of data to ensure high coordination among robots. For example, using our solution this application may be extended to provide data to another system using web services that can monitor the status of robots and track their movements on a map. The remainder of this paper is organized as follows. Section II provides information about DDS and JMS technologies. Section III summarizes the related work on DDS and SOA interoperability. Section IV describes the proposed system architecture with an example implementation. Section V provides a performance analysis of our solution. In Section VI, we provide a brief discussion on how to achieve integration security. In Section VII, we provide a discussion of our study. Finally, we conclude the research study in Section VIII. II.

Overview of data distribution service (DDS) and java message service (JMS) technologies

Object Management Group (OMG) defines the Data Distribution Service (DDS) as “a middleware protocol and Application Programming Interface (API) standard for data-centric connectivity." [3]. DDS is maintained by OMG. Version 1.4 used in this study, was released in March 2015. The first edition was released in December 2004. According to the formal OMG specification documentation, “the DDS specification describes a Data-Centric Publish-Subscribe (DCPS) model for distributed application communication and integration. This specification defines both the Application Programming Interfaces (APIs) and the Communication Semantics (behavior and quality of service)" [3]. The specification aims at enabling the efficient delivery of data from producers to subscribed consumers using these mechanisms. The specification document states its purpose as the “Efficient and robust delivery of the right information to the right place at the right time” [3]. This promise is attractive for many defense system developers. Note that DDS is not a middleware software, it is an open middleware specification supported by the OMG. Therefore, different vendors develop middleware software supporting DDS specification. Developers may choose DDS middleware software from a vendor they trust. The basic principles of a DCPS model should be followed by all vendors. The Common Object Request Broker Architecture (CORBA) [60] is another standard defined by the OMG. CORBA is designed to facilitate the communication of systems deployed on diverse platforms. Note that CORBA is used as an underlying technology supporting the implementation of various middlewares such as DDS middlewares. In the next paragraphs, we explain the details of the DCPS model and mechanisms. A DCPS model utilizes a global data space. This data space is accessible to all interested applications. Some of these applications provide data to the global data space. They are called publishers. The applications requiring data from the global data space are called subscribers. Publishers provide data for interested subscribers. The middleware provides a mechanism for the exchange of data between these applications. Whenever a publisher puts new data into the global data space, the middleware broadcasts this data to the interested subscribers. Sometimes publishers are called data writers or producers and subscribers are called data readers or consumers. A publisher may also be a subscriber requesting data from various other publishers. A DCPS model requires a data model. This data model consists of data structures. Within DDS specification, each data structure is called a topic or a type. In other implementations of DCPS, the data structures have different names but the same purpose. A topic is defined in the data model and it has a unique identifier within the global data space. One of the main tasks

of the middleware is to manage this global data space. In many cases, a distributed database management mechanism is used for this purpose. Publisher applications inform the middleware about the topics they will provide to the global data space. This is called publishing. Subscribers interested in various topics inform the middleware about the request. Naturally, this mechanism is called subscribing. As a result, we have various publisher applications producing various topics and subscriber applications consuming various related topics. A publisher may produce many topics distributed to a number of subscribers. A subscriber may consume data produced by a number of publishers. This is an “m-to-n” relation. One of the powerful aspects of the DCPS model is that publishers do not need to know about the subscribers and vice versa. The middleware keeps track of which applications are the publishers and the subscribers and which topics the applications publish or subscribe to. The management of publisher and subscriber lists and the data exchange are handled by the middleware. This decoupling helps to achieve scalability in large-scale system developments. The DCPS model is supported by a mechanism enabling a certain level of Quality of Service (QoS). DDS specification offers a rich set of QoS parameters. A full set of QoS parameters can be found at [3]. The required quality of service may be defined for each publisher, subscriber, and type of data object. The defined QoS serves as a contract within the data domain. As emphasized earlier, the DDS specification defines both the APIs and the Communication Semantics (behavior and quality of service). The communication semantics enables us to build robust and scalable distributed systems composed of many publisher and subscriber applications. DDS entities and relationships between publishers and subscribers on the data domain are as shown in Fig. 1. A Data Domain is a virtual network providing a communication infrastructure for the publisher and subscriber applications. The publish/subscribe mechanism and the data model composed of topics (the data objects in DDS) are only meaningful within a particular data domain. Communication between publisher and subscriber applications can only occur within the same domain. A Domain Participant enables an application to join the data domain. It serves as an entry point to the domain. Publisher, Data Writer, Subscriber and Data Reader objects are all attached to a domain participant. A Publisher is an application providing a data object to the domain. Publishers may publish different data objects. A Data Writer provides applications to access publishers. Applications providing data objects to the domain use the data writer to inform subscribers about the data object instances. When the new instances of a data object arrive, data writers send out the instance of the data object to the data domain according to its own QoS settings and the data object’s QoS settings. Subscribers receive data objects published in the domain. Subscriber applications access the data object instance from the Data Reader object associated to the subscriber object with the related QoS settings. Within this context, a publication is identified by linking a data writer object to a publisher object and a subscription is identified by linking a data reader object to a subscriber object. The association between a publication and a subscription is completed using the object called Topic. A topic has a unique name in the data domain, a data object type, and QoS settings related to the data object.

Fig. 1. DDS entities and relationships between publishers and subscribers on the data domain [5]. Java Message Service (JMS) is an API used for communication between computers in a network. It enables Java programs in enterprise systems to send and receive messages. JMS allows separate business processes to be associated in a loosely coupled, reliable, and asynchronous manner. Therefore, JMS is widely used in SOA-based systems. Java 2 Enterprise Edition (J2EE) is the standard for the message exchange. Interfaces provided by the JMS API is implemented by different vendors. Products developed by these vendors serve as a JMS provider. A JMS provider manages sessions between communicating with clients and responsible for message deliveries. JMS supports messaging for both point-to-point (P2P) and publish-subscribe (PS) systems. P2P systems require sending and receiving applications to be running at the time of message exchange, whereas

PS systems do not have this strict requirement. P2P model works with messaging queues. Each sent message goes to a specific queue from where receiving clients get their messages. PS model works with topics. A message sent as a topic is delivered to all subscribed clients. With the aim of decoupling vendor-specific messaging technologies, JMS has two types of administrated objects: the connection factory and the destination. These objects enable portable usage of JMS by its clients. To start a JMS connection, a client checks the registered connection factory object using Java Naming Directory Interface (JNDI). Then, the client creates a connection object using the connection factory object. A session is created using this connection. Afterward, the clients conduct a look-up for destinations (queues or topics) in JNDI. The client creates message consumers and producers depending on its needs and starts a connection. JMS supports different types of messages such as byte messages, text messages, and object messages [8]. JMS provides limited QoS when compared to the DDS specification. JMS is mostly concerned with the reliable delivery of messages [9]. As pointed in JMS specification, JMS is for enterprise message exchanges. For enabling JMS communication with the DDS system, a real-time message engine is required. For this purpose, in our study, we use the LightStreamer JMS Extender (LJE) [10]. LJE leverages the LightStreamer server, which is for real-time messaging and data push over HTTP and Web Sockets. LJE allows JMS API for the web using JavaScript to connect any JMS provider. LJE has a file-based configuration system based on Extensible Markup Language (XML). It can be configured for JMS implementations. LJE requires class definitions of the Java objects for creating or decoding JMS messages. LJE performs serialization/deserialization between Java and JavaScript Object Notation (JSON) objects [10]. Fig. 2 shows the main components of the LJE.

Fig. 2. Main components of the JMS Extender and its relation to a client, a JMS Provider and a LightStreamer Server [10]. JMS Connectors enable sending and receiving data from JMS queues and deliver them to the LightStreamer server. JMS Extender is an extension to LightStreamer real-time message engine. JMS Extender controls and accommodates working with JMS Connectors. JMS Extender JavaScript Client provides JMS-like API on JavaScript by using LightStreamer Javascript Client libraries. III.

Current state of data exchange mechanisms between DDS and SOA systems

With the emerging need for interoperability between the real-time and the non-real time systems, a limited number of studies were conducted on the subject. Park et al. [11] describe the middleware integration of DDS and Enterprise Service Bus (ESB) based systems/domains. The authors develop a custom binding component namely DDS Binding Component (BC) in the ESB domain. This component works in a similar way to other binding components of the ESB domain. DDS BC waits for the messages from outside of the domain. When such a message arrives, it performs required transformations on the received message and sends it to the Service Engine (SE) of the ESB. Similarly, when a service wants to send a message to the DDS, BC again performs the necessary transformations and sends the message to the outside of the ESB system. To satisfy the realtime requirements of the DDS, the researchers add a special routing mechanism called delegation. Delegation message routing sends messages, whose both the source and the destination applications are in a DDS system, directly to the destination without using the Normalized Message Router. The goal of our study and the study conducted by Park et al. [11] is similar. The weakness of their approach is the necessity for the development of a custom software module, whereas development and maintenance costs are involved inherently. The maintenance effort is more essential. As new requirements emerge, developers

have to update the message transformation components of the custom software module (DDS BC). In large-scale systems such as defense systems, maintenance costs are significant. In Caban et al. [12], the authors designed a Web Service-DDS interface serving as a gateway and bridge between the DDS and the web service domain. The developed interface provides DDS applications to publish data to the defined web services and vice versa. However, their implementation does not include a publish-subscribe communication mechanism for web services. They focus on a request-response model. Also, for each web service communicating with DDS, a specific translator gateway between the web service interface and DDS interface is required. Moreland et al. investigate an SOA instantiation within a real-time combat management system (CMS) [13]. They use two different data objects; track data and readiness level. In the C2 domain (the non-real time system), two JMS publishers, each for a different type of a data object, publish data they receive from CMS domain using Real-Time Innovations (RTI) Routers to the corresponding C2 applications. One JMS subscriber delivers track data produced in the C2 system to the CMS. Routing between two domains is provided by RTI Routers. Data produced in the CMS domain is mediated to XML format using binary Interface Definition Language (IDL) format, and then at JMS publishers, only metadata of the message is exchanged (while the payload remains the same) and get delivered to corresponding applications. Data produced in the C2 domain using XML format is wrapped around a JMS message without changing the payload at the JMS subscriber and get delivered to the CMS where mediation from XML to binary IDL is carried out. OMG has a specification called Web-Enabled DDS [14]. It defines a Web-Enabled DDS operating as a gateway to the DDS domain, where the mapping from the Web-Enabled DDS Object Model to the DDS Object model is provided. Web-enabled service uses Real-Time Publish-Subscribe (RTPS) interoperability for connecting to native DDS applications. RTI has a product called Connext DDS for integrating the DDS domain with the web [15]. Advanced Message Queuing Protocol (AMQP) is an open standard that aims to be “become the standard protocol for interoperability between all messaging middleware” [16]. It is an initiative to overcome some of the issues arising from proprietary messaging protocols. The initiative was supported by many institutions. Some of these issues are difficulty faced during integrating various business partners, restricted platform support, and vendor lock-in [16]. The latest version of the OASIS Advanced Message Queuing Protocol (AMQP) was released in 2012. That version was 1.0 and it was not updated since then. AMQP is a wire-level protocol specification and does not provide an API as JMS does. AMQP, providing a wirelevel protocol, and JMS, providing an API, complements each other [25]. AMQP performs better at high bandwidths, but the success rate is low at low bandwidths [20]. Low bandwidths and even communication interruptions are common in the defense system domain. As such the applicability of AMQP should be investigated for the defense system domain. Kulkarni et. al. conducted a comparative study of Middlewares for C4I systems [19]. They compared two middleware solutions. The first solution is web services based on service-oriented architecture (SOA). The second solution utilizes DDS based on DCPS. They found out that the DDS based solution is quite superior in terms of performance [19]. In our study, we integrate these two solutions. Since both solutions are viable candidates for C4I systems with different needs and characteristics. IV.

A system model for exchanging data between the naval CMS and Headquarter

We conceptualize a system, in which, the combat management system of naval warships processes the sensory information using DDS infrastructure in real-time. When the geographically dispersed units in a wide area are considered, a geostationary satellite is the communication medium between the navy vessels and the C2 system at the headquarters. Applications running at the headquarters, like friend or foe force monitoring, use the same satellite link to communicate with the battlefield units in different areas. The general view of the system is shown in Fig. 3. In our use case scenario, two different CMSs representing two naval vessels on the field are deployed. A web application is connected to the C2 system at the headquarters with the service-oriented architecture standards. The web application interoperates with the CMS of the naval vessel using an object called C4I operations manager. We developed the C4I operations manager as a generic maintenance-free object, which is a DDS domain participant. This framework enables a simple web client located at the headquarters to become a publisher or subscriber at the CMS data domain at the naval warship. The web client can create a topic and set QoS parameters based on the requirements. Moreover, due to its inherent deployed location at the headquarters, the web client can also benefit from the services offered by the non-real-time C2 system applications at the headquarters. These services may include data from different domains like maritime administration agencies, track data of merchant navy vessels, or the meteorology report from other domains. As the CMS middleware, we deploy OpenDDS version 3.7 running on the naval vessel with real-time constraints. It is an open-source C++ implementation of the DDS specification. OpenDDS also supports Java API using JNI. As the serviceoriented system at the headquarters, which is running with non-real-time constraints, we deploy RedHat JBOSS WildFly application server 8.1. Wildfly uses an open-source messaging system called HornetQ developed by JBOSS which also implements complete JMS API. JBOSS also has a product called SwitchYard, which is a lightweight service delivery framework for service-oriented applications. JMS can be used for communicating with DDS applications. However, a mechanism to forward JMS messages to web clients is required. We use LJE product that enables web clients to make use of JMS directly from their web browsers.

An architectural overview of the system is shown in Fig. 4. When a web client from the enterprise system (i.e., the C2 system at the headquarters) wants to connect to the DDS domain (i.e., CMS of the warship), it opens a JMS connection to the LJE using JavaScript client libraries provided by LJE. The web application provides the address of the LJE and the name of the JMS provider as a configuration parameter. Using this configuration, LJE opens a JMS connection to the related messaging queues or topics. These messaging queue or topic information is determined according to the web application request. For the same data object required by multiple web applications, LJE supports both the publish-subscribe model and the pooled connections for topics. In the pooled connections for topics, LJE opens one connection to the same topic subscription request on JMS provider and handles delivery to multiple clients using its data push mechanism. In our implementation, we choose the publish-subscribe model. This choice is an important factor considering performance issues. Because the workload of the application server is reduced, better network utilization in the non-real-time C2 domain is achieved by reducing the traffic intensity caused by the high data production rates of real-time DDS applications. We use JMS object messages for the communication between CMSs and C2 systems at the headquarters. There are two reasons for this choice. First, it provides byte-stream data transfer over the network. Second, in the DDS domain we use the Java object definitions constructed by IDL to JNI (idl2jni) generator component of OpenDDS.

Fig. 3. Overview of the system model.

Fig. 4. Architectural overview of the system.

In our use case, warships send track data as Java objects in their DDS domain. Just after a subscription from a web client, the same data object can be published immediately without any transformation in the real-time system as shown in Fig. 5a. This transformation-free system saves the precious processing power of the real-time system and achieves reduced message delivery delays when compared with the transformation-based systems. Also, note that the processing power at the real-time CMS is more valuable than the processing power of the non-real-time C2 system. Transforming a massive amount of data produced in CMS will increase the workload of the real-time system.

Fig. 5 （a）Communication steps between DDS Domain, C4I Operations Manager, and the application server including data formats, (b)Communication steps between web client, LJE, and the application server including data formats for each phase.

While communicating with the DDS domain, the web clients send and receive their messages in JSON format. Therefore, a data transformation between the Java object message of the JMS and the JSON object is required. Fig. 5b. depicts this flow of data between the web client and the application server. JMS object messages are Java objects. Hence, LJE requires Java class definitions to construct and send JMS object messages. We made LJE use the class definitions as generated by the idl2jni component of OpenDDS. This allows a transparent transfer of data objects from the CMS to the C2 system at the headquarters. Furthermore, an automated transformation between Java and JSON objects eases the development process. For each different data type defined in the DDS domain, LJE performs the necessary steps for the transformation of DDS generated class definition files. Previous studies on data interchange formats show that JSON has advantages over XML. JSON performs better in terms of performance and resource utilization in data encoding/decoding and serialization [17, 21]. Hence, compared to other data formats (i.e. XML), JSON promises better performance for communication with real-time systems. C4I Operations Manager in the CMS acts as a domain participant in the DDS domain (see Fig. 6). After the CMS starts, the C4I operations manager establishes a JMS connection to the application server and waits for messages from web clients. When a web client needs data from the CMS, the C4I operations manager creates the subscribers to related topics based on the requests of the web clients and publishes the data objects received from JMS adhering to the QoS set by the web client. In the other case, when a web client needs to send data to the CMS, it creates publishers to deliver data to the DDS domain with QoS parameters provided by the clients. Clients can also create a topic in the DDS domain. Figure 6 shows the sequence diagram of the interaction between the C4I operation manager and the web client. One C4I operations manager is running on each DDS domain. In our use case scenario, the C4I operations managers running on two CMSs provide communication between the web clients and the CMSs. With the proposed system architecture, maintenance costs go down since the system integration is automated. In addition, in our case, high portability is achieved since we use COTS web browsers.

Fig. 6. Sequence diagram of the interaction between C4I Operations Manager and Web Client (ignoring JMS provider and LJE).

As its specification points out, JMS is developed for enterprise systems and their integration. Therefore, JMS does not aim to support real-time properties required by CMSs. When communicating with CMSs, the QoS parameters should be set carefully. The requirements of C2 systems at headquarters are mostly at the human perception level in real-time. Providing a better performance for real-time communication can be achieved using a messaging middleware such as the one proposed by Garcés-Erice [18]. The researcher implements a reduced version of the JMS specification and develops a JMS-like API for real-time ESB’s communication subsystem. An event scheduler is also implemented for the prioritization of real-time messaging requirements. Main features that are not provided by this JMS-like API are; transaction, which may interfere with real-time requirements due to a set of messages needed to be processed to complete an atomic work of a unit, and persistent message storage that stores messages for complete system failure, which is also incompatible with real-time requirements. The middleware used for real-time messaging has promising results. 116423 messages per second can be transferred over messaging middleware when message size is 13 bytes, 101879 can be transferred if the message size is 130 bytes and 40088 messages can be transferred if the message size is 1300 bytes.

V.

Performance analysis and evaluation of the proposed system architecture

Systems such as a combat management system of a warship have strict real-time requirements. Command and control systems used at the headquarters are generally near-real-time or non-real-time systems. In this study, our goal was to achieve interoperability rather than satisfying real-time requirements. We aimed at accessing CMSs of naval vessels on the battlefield from a web browser located anywhere without a prior set up or configuration (i.e., real-time operating system, custom applications). The information acquired from the warship CMS is used to support C2 systems for decision making at the headquarters. We use currently available SOA and DDS systems. However, performance tests focused on latency are carried on putting forth the current situation of the system in a standard environment similar to which it can most likely be used. The tests also enable us to compare results with a similar study [12]. We deploy the CMS and the applications on a virtual machine and the Wildfly AS and LJE on the host machine. The client interactions from the web browser are handled by two other machines. Table 1, 2, and 3 show the host machine’s, the virtual machine’s, and the test machine’s specifications. With this configuration, we perform the tests for two scenarios. Scenario 1 focuses on the time required for data transformations between two systems, since they use different data types. Data transformations are handled in LJE. They are performed for createTopic, createSubscriber, createPublisher and publish operations. Scenario 2 focuses on the response times of requests coming from the clients. We perform the same operations as in scenario 1 for 1 and 10 clients. For 50 and 100 clients, we perform only publish operation. In scenario 1, each client request is tested for 100 times to compensate for other system processes. Measured time in scenario 1 is the time between a client's request sent from the web browser and LJE to transform it into an appropriate JMS message format. Table 4 shows the data transformation duration of messages from one client. The reason to choose to measure from the client to LJE is that the data transformation is only performed in the LJE. Client requests are sent in the JSON format. At LJE, for the publish operation, the class definition generated from “idl2jni generator” of OpenDDS is used, and the JSON objects are transformed and sent as a JMS Object Message. Other requests are transformed into JMS Text Message as the payload of the message. These results show that for mentioned JMS message types and data types used in DDS, transforming into text messages or object messages slightly differ in processing time. Sending all data types in the text message format may reduce dependency on class definition files generated in DDS and provides more flexibility. However, a mapping from the text message to data types in DDS must be performed for each message. While using object messages, no such transformation is needed. The choice between the two message types depends on the requirements of the designed system. Table 1. Host Machine. Item Processor Memory Operating system Application Server JMS Provider JMS Connector for Web

Property Intel Core i7-4510 2.00 GHz 8 GB RAM Windows 10 64 bit WildFly AS 8.1.0 Final HornetQ Version 2.4.1 Final LightStreamer JMS Extender 1.6 Table 2. Virtual Machine.

Item Processor Memory Operating system DDS Implementation

Property 1 processor core from the host machine 2 GB RAM from the host machine Ubuntu 14.04 64 bit OpenDDS-3.7 Table 3. Test Machines.

Item Processor Memory Operating system Browser

Property Intel Core i7-4702 MQ 2.20 GHz 8 GB RAM Windows 10 64 bit Google Chrome

Table 4. Data transformation duration of messages from one client (Scenario 1). Client Request createTopic

Processing Time/ms 3

createSubscriber

3.2

createPublisher

3.2

publish

3.25

We compare our results with another solution for interoperability with DDS using web services (WS) provided by Caban et al. [12]. Their solution is referred to as WS-DDS and we call our solution as JMS-DDS. Fig. 7 shows the comparison of proposed JMS-DDS with WS-DDS according to scenario 1. Fig. 7 provides a comparison of JMS-DDS and WS-DDS on data transformation. These results also seem consistent with the performance comparison of XML and JSON as in [17] and [21].

Fig. 7. Comparison of JMS-DDS and WS-DDS on data transformation.

Data transformation delay measurement for the receive data operation for the non-real-time side is not included in this comparison, because at the system proposed in [12], data from DDS to WS clients are only sent when a request comes from WS client. In our proposed system, sending a subscription request from a web client for one time to a topic is enough to receive data published for that topic continuously. Since the mechanisms for receive operations in the web service side are different in these solutions, a comparison may lead to invalid conclusions, especially considering the request overhead in the WS-DDS solution compared to the subscription-based mechanism provided in the JMS-DDS solution. For the tests of scenario 2, each client request is tested for 100 times. While interoperating with DDS, createTopic, createSubscriber, and createPublisher operations are mostly one-time-only operations. The main workload of the system would be caused by publish and receive operations on the actual data. Because of that, only publish operation is tested with 50 and 100 clients. Measured response time in scenario 2 begins with the client’s request and includes processing in LJE, sending JMS topic over JMS provider, C4I operations manager's action in the DDS domain and receiving time of acknowledgment message following the same path reversely on a web client. In a real situation, there may not be a need for the C4I operations manager to send acknowledgment messages after performing the requested operation. However, to make the same comparison with the system in [12], the C4I operations manager sends an acknowledgment message for each client request after performing the request successfully. Table 5 shows response times for the operations except publish performed in scenario 2. Table 6 shows response times for the publish operation in scenario 2.

In the tests of scenario 2, the publishing frequency of web clients changed between 100 ms and 1 second and response times remained the same. Web clients are simulated with the combination of Selenium [23] test framework for web applications and TestNG [24] framework for Java applications where both are open source frameworks. Table 5. Response times for the operations except publish in scenario 2. Number of Clients

create Topic

create Publisher

create Subscriber

1

6 ms

6 ms

6 ms

10

8.3 ms

8.3 ms

8.3 ms

Table 6. Response times for the publish operation in scenario 2. Number of Clients

publish

1

10 ms

10

14 ms

50

19.6 ms

100

25.8 ms

Fig. 8. Comparison of JMS-DDS and WS-DDS on response times for 1 and 10 clients.

Fig. 9. Comparison of JMS-DDS and WS-DDS on response times of publish operation for 50 and 100 clients.

These results can be improved by deploying CMS and DDS middleware on different computers and also distributing web clients to different computers. That would be closer to a real deployment environment. Figure 8 shows the comparison of JMSDDS and WS-DDS on response times for 1 and 10 clients in scenario 2. Fig. 9 shows the comparison of JMS-DDS and WSDDS on response times of publish operation for 50 and 100 clients in scenario 2. Similar to transformation time comparison as in Fig. 7, it is observed in Fig. 8 and Fig. 9 that the JMS-DDS system offers better performance for response times than WS-DDS. Moreover, it is clear from Fig. 8 and Fig.9 that, for publishing data from the web client to the DDS domain, response time in WS-DDS grows dramatically while it remains more stable in JMS-DDS. It is important to note that JMS-DDS and WS-DDS tests are in different environments. WS-DDS has a custom solution namely WS-DDS Interface. Because of that, it was not possible to test two different solutions in the same test environment. These comparisons aim to show the results of the two different architectures on the same problem and regardless of test environments, the trend in response times of JMS-DDS shows a more stable attitude and provides better scalability (see Fig. 10). Both tests show that the JMS-DDS connection promises better latency values than the WS-DDS interface. The main reason for this performance difference comes from the heavy load of XML transformation when compared to JSON. Another reason is the use of web socket protocol between browsers and LJE which enables bi-directional communication over a single Transmission Control Protocol (TCP) connection and reduces overhead in request handshake, error checking thus provides better scalability. One advantage that WS-DDS has over JMS-DDS is the flexibility of web services which eliminates programming language dependency. JMS-DDS is dependent on the Java environment. Nevertheless, both commercial and open-source implementations support Java language for DDS specification. We perform the tests for the proposed in an isolated environment where there is approximately no network delay. For testing purposes, we provide time synchronization between the two systems. In a real application domain, naval vessels would communicate with the non-real-time system using geostationary satellites, and there would be no time synchronization between real-time and non-real-time systems. Besides that, communication over geostationary satellites would bring propagation delay. Therefore, including other parameters in end-to-end delay, a mechanism to compensate delay and alter either data inside messages or timestamping messages should be implemented to get more accurate data representing the situation about the environment.

Fig. 10. Comparison of WS-DDS and JMS-DDS on Publish Response Times.

VI.

Integration security

In this section, due to its importance, we provide a brief discussion on how to achieve a necessary level of security in our integration solution in this section. Security is a crucial aspect of any system and it is a multifaceted issue. System security, at minimum, involves personnel security, physical security, database security, network security, application security, operational security, and system development security. Ensuring complete security in a system is extremely hard if not impossible. It is also costly. Therefore, project technical managers or relevant project members conduct a security risk analysis. Based on the analysis, they conduct various activities to increase the security of the system and mitigate risks. Due to their nature, defense systems must be of high quality and highly secure systems. In many countries, defense system developments are heavily regulated compared to most civilian system developments. There are government agencies that regulate and inspect defense system developments. While some defense systems are developed by defense companies, some others are developed by government agencies. Personnel working on defense projects both on the government and commercial side are required to have adequate security clearances that are issued after detailed background checks. In some countries, people working on defense projects are also required to be citizens. Not just developers but also the users of defense systems are also required to have security clearances. Defense systems are mainly used by military personnel that is trained on information security issues. Military personnel is subject to certification processes on the use of classified information and systems. These certifications and training are repeated periodically. Defense system developments are conducted on designated restricted sites. The development compounds of the government agencies and defense companies are required to have certain information security certifications. They are also subject to regular or irregular inspections to ensure information and development security at all times. As part of the information security, these development sites also have high physical security. The defense system developments are required to comply with many national and international system development standards and regulations. Common Criteria is one of the well-recognized international computer security certifications that defense systems are subject to. Compliance with all these regulations and standards increases system quality. System quality also helps to achieve a more secure system. These standards and regulations dictate how a defense system should be developed. For example, the databases used in defense systems are generally encrypted to increase data security. The data transfers are also encrypted depending on the requirement of the defense system. Network security is ensured via the use of secure protocols and other relevant measures. The defense system developers are not free to use any software tools or compiler. They are required to use certified software

tools and compilers. In most cases, the defense system development is carried out in closed local area networks and software development environments are hardened by various security measures. Defense systems are subject to heavy testing including security and penetration testing. Heavy testing helps to achieve a high level of quality and security for the defense system. The hardware and equipment used in defense systems are military-grade certified equipment. The information technology equipment used in these systems is required to have a certain level of Evaluation Assurance Level (EAL). Operational security is an important aspect of information security. Operational security is commonly high in a military setting. Again, military personnel is trained for operational security. As a result, compared to many civilian systems, defense systems are developed with high security as a priority. Well-known secure design principles such as defense in depth are used in the design of defense systems. Ideally, in defense systems, security is not a feature but it is an essential quality that is designed into the system from the start. In Fig. 11, we present an overview of secure communications architecture between the combat management system (CMS) of a warship and the command and control (C2) system at the headquarters. We assume that these CMS and C2 systems are developed based on the security principles outlined in the previous paragraphs. These principles and others not mentioned here ensure the development of a secure defense system. In addition, we assume that these systems work on closed secure local area networks. The next step is securing the communication between these two systems. A number of devices are required to secure communication. These are, at a minimum depending on a secure communication channel configuration, an encryption/decryption unit, a modem unit, a tactical radio unit, a satellite communication unit, and a tactical radio antenna. The encryption/decryption unit is used to encrypt or decrypt the packets exchanged between the CMS and C2 systems. A cryptographic key is used for this purpose. The management of this key is according to the secure military communication policies set by the Navy. This encryption/decryption unit is connected to the CMS or C2 gateways. Another connection of this unit is to a modulation/demodulation unit. This modem has two output channels. One channel is to a satellite communication unit. The other channel connects the modem to a tactical radio unit with a radio antenna. This provides redundancy for communication. Depending on the capabilities of the Navy and the geographical constraints, the appropriate communication channel is used. On the receiving end, the packets are processed in the reverse order and finally received by the C2 system. Note that these devices are military-grade equipment. They are hardened in many aspects compared to civilian applications. Some of these devices such as the encryption/decryption units are produced by government agencies. Furthermore, they are certified with Common Criteria security evaluations and they are ensured to have the required Evaluation Assurance Level (EAL). In addition, these systems are operated by authorized personnel having security clearances with necessary access levels. Security of the communication architecture between the CMS and C2 systems consists of confidentiality in which only the approved participants can access the information, authenticity in which the participants are authenticated in different authentication levels ranging from e-mail accounts to fingerprints, integrity which provides data to be not altered or modified on the way from its source to its destination, non-repudiation in which participants cannot deny any message that they have sent and availability in which the system and the resources are available when required and security measures taken are not making the system unusable. In the secure communication architecture between the warship and headquarters, the confidentiality relies on the secrecy of the symmetric key between the sender and the receiver. The algorithm used may not necessarily be secret and it may be an open symmetric key encryption-decryption algorithm like Data Encryption Standard (DES) [45], Triple DES [46], Blowfish [47], Twofish [48], Advanced Encryption Standard (AES) [49], International Data Encryption Algorithm (IDEA) [50]. Asymmetric key encryption algorithm which requires two keys, one for the encryption and one for the decryption like as in Rivest Shamir Adleman (RSA) [51] or Elliptic Curve Cryptography (ECC) [52] would require more processing power [53], hence, may be inefficient when compared to the symmetric encryption-decryption algorithms. There are various approaches to the distribution of the secret keys ranging from controlled hand to hand daily to monthly delivery to online session key establishment algorithms like RSA [51] or Diffie Hellman Key Exchange [54]. When the integrity is concerned, Message Authentication Code (MAC) [55], Hash-based MAC (HMAC) [56], Secure Hash Algorithm (SHA) [57], Message Digest algorithms like MD5 [58] are used for appending a message digest or message hash to the original message. When the authenticity and non-repudiation are concerned as well as online symmetric key (i.e. session key) establishment, the public key cryptography is required. Hence, participants of the system authenticate themselves to a certification authority and get their certificates which include their public and private key pairs. These key pairs are used for the asymmetric key encryption and decryption. Messages encrypted with one participant’s private key can only be opened with the corresponding public key and vice versa. Private keys are only kept secret at the participants and public keys are made available to the other participants in the system. Participants authenticate themselves by using their own private keys and non-repudiation is satisfied by the other participant’s private keys since they are the only legitimate owner of that private key.

Fig. 11. Secure Communications Architecture between the Warship and the Headquarters.

VII. Discussions The benefits of SOA have been recognized by the defense community. Thus, there were various attempts to combine the strengths of SOA and DCPS architectures in addition to overcoming the shortcomings of SOA in applying it to the tactical domain. The European Defense Agency supported a project called Tactical Service Oriented Architecture (TACTICS). The project started in 2014 and completed in 2017. The goal of the project was “to define a Tactical Service Infrastructure (TSI) enabling military tactical radio networks to participate in SOA”. The Tactical Service Infrastructure was discussed in [33]. Various studies were conducted based on the TACTICS project to overcome the connectivity, limited bandwidth, security, quality of service (QoS) issues [34-37]. Science and Technology Organization (STO) within NATO supported two research task groups: IST-090 titled “SOA challenges over real-time and disadvantaged grids” [22] and IST-118 titled “SOA recommendations for disadvantaged grids in the tactical domain” [38-41]. IST-118 is a follow-on research task group of IST090 [41]. IST-090 investigated the challenges of implementing SOA on disadvantaged grids. SOA works well on wellconnected networks. The disadvantaged grids, such as tactical networks formed by moving military units connected with tactical radios, bring many challenges to effectively implementing SOA. IST-118 provided a set of recommendations such as compression of messages to overcome the challenges identified by IST-090. While the TACTICS project has a holistic view, IST-090 and IST-118 projects have partial solutions to the concept of bringing SOA advantages to the tactical domain. US Air Force Research Laboratory sponsored the development of a middleware called Mission and Network Adaptive Tactical Information Management (MaNATIM) that “addresses many of the concerns of interconnecting enterprise and tactical networks and effectively managing the information flow across those networks” [42]. This middleware is composed of four core elements: (i) extensions to a mission modeling framework (Mission Instantiation Service for Tactical Systems – MISTS), (ii) a federation capability (iii) a gateway capability (iv) a prioritization, filtering, and dissemination capability. In the study, the research group shows the application of MaNATIM with a set of experiments [42]. Agile Computing Middleware is “a software framework that enables the realization of applications and services for tactical edge networks.” [43]. Again, this framework aims at overcoming the problems of connectivity and limited bandwidth for tactical networks. These projects mainly aim at developing the necessary infrastructure to bring the benefits of SOA into Tactical Systems and Networks. These projects and studies show promising results. However, they have to be supported with government or commercial of the shelf tools (GOTS / COTS) and development environments, well-recognized and well-supported standards, adequate development documentation, necessary training and courses, a certain level of developer base, and field deployments showing the actual applicability. These projects have a higher-level goal, unlike our study that aims at solving a specific problem within this domain. This specific problem is finding an integration solution between a DDS-based system and a system composed of SOA-based web services. The integration approach proposed in this study is an automated solution composed of readily available COTS tools based on well-recognized standards. Therefore, our solution is readily available to all. NATO’s Allied Command Transformation (ACT) conducts Coalition Warrior Interoperability Exercise (CWIX) [44] with the aim of achieving federated interoperability between the C4I systems of NATO countries. In these annual exercises countries test their systems in a multi-national environment. CWIX is a suitable environment to test such integrations. Note that many C2 and C4I systems are large-scale systems. These large-scale systems have both real-time and non-realtime components. Depending on the specific task being conducted, the necessary components exhibit the necessary time-

critical (or non-time-critical) behavior. As a result, classifying a large-scale system as a real-time or a non-real-time system is not an easy task anymore. In this study, our goal was to provide a solution to a specific problem that is to integrate a system based on a DDS architecture with another system based on architecture (such as Service Oriented Architecture) utilizing web services. This problem was not discussed in detail in the literature and there are only a handful of reported studies. However, considering the implications of the study, it is quite relevant and important to the defense community, especially to C2 defense system developers. We try to compare our study with the most similar study in the literature. Note that these are experimental setups and actual defense systems are much larger. Therefore, these studies only provide an indication for performance predictions of actual systems. In addition, it is not always possible to provide an experimental setup that is completely identical to an earlier study. Depending on the types of software running on the experimental setups (for example debugging or runtime monitoring software) the performances measured in milliseconds (depending on how they are measured) may vary slightly. However, when we investigate Figure 10, we will notice that as the number of clients increases, JMS-DDS solution scales better in terms of performance. When the number of clients increases from 10 clients and 100 clients, the publish response time increases by 3.9 times for the WS-DDS solution. However, in the JMS-DDS solution, the publish response time increases by only 1.8 times. Note that as long as the response times are within the limits set by the specific defense system requirements, they are acceptable for system implementation. Without a specific system performance requirement, it is hard to determine whether the performance is acceptable or not. Furthermore, the performance expectancy of the different systems is naturally different. While we provide the response times for both studies, what we find more value in these studies is the scalability indication of these solutions considering the scale of defense systems. VIII. Conclusions In this study, a communication mechanism for extending DDS to web services using JMS as a bridge is proposed. Using this mechanism, we develop an architecture for the interoperability of two different domains such as real-time combat management systems (CMSs) used in Naval warships and non-real-time command and control (C2) systems used at Naval command headquarters. We utilize a web client, i.e., a web browser, to communicate with the DDS domain. The proposed solution provides ubiquitous access to the CMS of the naval vessels on the battlefield with the use of a web browser. One of the advantages of the proposed solution is that the necessary data transformations are performed on the non-real-time system domain to reduce the workload on the real-time system domain. We compare our solution with a previous similar study [12]. Note that there are only a limited number of studies on the subject. We chose the study [12] because their goal is similar to ours. As the number of clients increases, the proposed solution, JMS-DDS, performs better than the solution proposed in [12]. In addition, their solution requires custom implementation, whereas we benefit from automation. The uniqueness and strength of our solution compared to earlier reported studies is its automation support. Minimal implementation, only specifying DDS topics to be exchanged, is required. Previously reported solutions require custom implementations with some level of coding that increases the development costs. With small-scale systems, development and maintenance costs may not be an important issue. However, when systems are large-scale, development and maintenance costs are among the most important criteria for choosing an architectural solution. In addition, custom implementations are error-prone, whereas automation reduces errors in implementations. In large-scale systems, the cost of eliminating errors increases as the system scale increases. The reason for the selection of Naval C4I and C2 systems as the application domain is two-fold. First, the authors are developers and researchers of large-scale C4I defense systems, and they have a deep understanding of the requirements and development dynamics of these systems. Second, C4I and C2 systems are generally large-scale systems in which automated integration of real-time and non-real-time systems has significant benefits. The integration approach proposed in this study is an automated solution composed of readily available COTS tools based on well-recognized standards. Therefore, our solution is readily available. The main drawback of our solution is the Java dependency. While DDS supports a handful of programming languages, the use of JMS limits the solution to Java. On the other hand, the use of Java is also a strength. Java is one of the most common programming languages with significant support in terms of libraries. Many undergraduate and graduate computer science and software engineering programs include a programming course on Java. Therefore, Java has a huge developer base. Java is also gaining attention as a programming language for defense systems. Our study may be improved in various ways. Communication between the CMS of the naval vessel and the C2 system of the command headquarters mostly requires satellite communication. Developing a mechanism to compensate for geostationary satellite communication end-to-end delay to maintain the real-time requirements of the naval vessel may be future work. When the communication between the CMS of the naval vessel and the C2 system of the headquarters is considered, most of the network traffic load is about track data. Within the real-time context, most of the track data message content such as identity, status, course, and speed remain the same. Instead of using directly JSON, a more efficient protocol to decrease redundant data may be developed by using a position-based protocol with a delta compression method so that most of the payload a message carries would be track kinematic data. Such a protocol may reduce processing time for messages and provide more efficient use of network resources. IX. Acknowledgment and dısclaımers The views and conclusions contained herein are those of the authors and should not be interpreted as necessarily representing the official policies or endorsements, either expressed or implied, of any affiliated organization or government.

X. REFERENCES [1] Alberts DS, Garstka JJ, Stein FP. Network Centric Warfare: Developing and Leveraging Information Superiority. 2nd ed. Washington DC: C3I/Command Control Research Program; 2000. [2] Cebrowski AK, Garstka JJ. Network-centric warfare: Its origin and future. US Naval Institute Proc. vol. 124. no. 1. 1998. [3] OMG Data-Distribution Service (DDS) Version 1.4, http://www.omg.org/spec/DDS/1.4/; [accessed 4 February 2018]. [4] Pardo-Castellote G. Omg data-distribution service: Architectural overview. In: 23rd International Conference on distributed computing systems workshops; May 2003. p. 200–206. [5] Pardo-Castellote G, Farabaugh B, Warren R. Introduction to DDS and Data-Centric Communications. RTI, http://bpmn.omg.org/news/whitepapers/Intro_To_DDS.pdf; [accessed 4 February 2018]. [6] Ahmad MI, Kanoi V, Nema MK, Kumar R. Performance analysis of data distribution service on error prone channels. In: 2017 International conference on recent innovations in signal processing and embedded systems (RISE). 27-29 October 2017. Bhopal, India. p. 33-37. https://doi.org/10.1109/RISE.2017.8378120. [7] Alghamdi AS, Ahmad I. Comparative Analysis of Defense Industry Frameworks for C4I System. In: IEEE 2nd international conference on computer engineering and applications ICCEA 2010, 19 – 21 March 2010. Bali Island, Indonesia. p. 443-447. https://doi.org/10.1109/ICCEA.2010.92. [8] Oracle Java Message Service 2.0. http://download.oracle.com/otn-pub/jcp/jms-2_0-fr-eval-spec/JMS20.pdf; [accessed 4 February 2018]. [9] Corsaro A, Querzoni L, Scipioni S, Piergiovanni ST, Virgillito A. Quality of Service in Publish/Subscribe Middleware. R. Baldoni and G. Cortese Eds. IOS Press, 2006. [10] LightStreamer JMS Extender. http://www.lightstreamer.com/doc; [accessed 4 February 2018]. [11] Park Y, Chung D, Min D, Chobi E. Middleware integration of DDS and ESB for interconnection between real-time embedded and enterprise systems. In: Lee G., Howard D., Ślęzak D. (eds) Convergence and Hybrid Information Technology. ICHIT 2011. Communications in Computer and Information Science, vol 206. Springer, Berlin, Heidelberg. 337-344. https://doi.org/10.1007/978-3-642-24106-2_44. [12] Caban P, Sliwa J. Dedicated WS-DDS Interface for Sharing Information Between Civil and Military Domains. In: Proceedings of Military Communications and Information Systems Conference 2011 (MCC 2011), Amsterdam, Netherlands, October 2011. [13] Moreland JD, Sarkani S, Mazzuchi T, Service-Oriented Architecture (SOA) Instantiation within a Hard Real-Time, Deterministic Combat System Environment. Syst Eng 2014; 17(3): 264-277. https://doi.org/10.1002/sys.21268. [14] OMG Web-Enabled DDS Version 1.0. http://www.omg.org/spec/DDS-WEB/1.0/Beta2/PDF/; 2015 [accessed 4 February 2018]. [15] RTI Connext DDS. https://www.rti.com/products/ ; [accessed 4 February 2018]. [16] AMQP. http://www.amqp.org/ ; [accessed 4 February 2018]. [17] Nurseitov N, Paulson M, Reynolds R, Izurieta C. Comparison of JSON and XML Data Interchange Formats: A Case Study. Caine 2009 Nov 4;9:157-162. [18] Luis GE. Building an Enterprise Service Bus for real-time SOA: a messaging middleware stack. In: Proceedings of 33rd Annual IEEE International Computer Software and Applications Conference, vol. 2, 20-24 July 2009. Seattle, WA, USA. p. 79–84. https://doi.org/10.1109/COMPSAC.2009.119. [19] Kulkarni AM, Nayak VS, Rao PB. Comparative study of middleware for C4I systems Web Services vis-à-vis Data Distribution Service. In: 2012 International Conference on Recent Advances in Computing and Software Systems (RACSS). 25-27 April 2012. Chennai, India. p. 305-310. https://doi.org/10.1109/RACSS.2012.6212685. [20] Fernandes JL, Lopes IC, Rodrigues JJ, Ullah S. Performance Evaluation of RESTful Web Services and AMQP Protocol. In: Fifth International Conference on Ubiquitous and Future Networks (ICUFN), Da Nang, Vietnam, 2-5 July 2013. p. 810-815. https://doi.org/10.1109/ICUFN.2013.6614932. [21] Sumaray A, Makki SK. A comparison of data serialization formats for optimal efficiency on a mobile platform. In: 6th International conference on ubiquitous information management and communication (ICUIMC). Kuala Lumpur, Malaysia. 20-22 February 2012. ACM. https://doi.org/10.1145/2184751.2184810. [22] Johnsen FT, Bloebaum TH, Schenkels L, Fiske R, van Selm M, de Sortis V, Zanden A, Sliwa J, Caban P. SOA over disadvantaged grids experiment and demonstrator. In: 2012 Military Communications and Information Systems Conference (MCC). Gdansk, Poland. 8-9 October 2012. p. 1-8. [23] Selenium. http://www.seleniumhq.org/; [accessed 4 February 2018]. [24] TestNG. http://testng.org/doc/index.html; [accessed 4 February 2018]. [25] Stefan A, Sachs K, Buchmann A. Towards benchmarking of AMQP. In: Fourth ACM International Conference on Distributed Event-Based Systems (DEBS). Cambridge, United Kingdom. 12‐15 July 2010. p. 99-100. https://doi.org/10.1145/1827418.1827438.

[26] NATO Architecture Framework (NAF) Version 4.0. https://www.nato.int/cps/en/natohq/topics_157575.htm; 2018 [accessed 30 December 2019]. [27] Bellavista P, Corradi A, Foschini L, Pernafini A. Data Distribution Service (DDS): A performance comparison of OpenSplice and RTI implementations. In: 2013 IEEE symposium on computers and communications (ISCC). IEEE, Split, Croatia. 7-10 July 2013. p. 377-383. https://doi.org/10.1109/ISCC.2013.6754976. [28] Lopez-Vega JM, Povedano-Molina J, Pardo-Castellote G, Lopez-Soler JM. A content-aware bridging service for publish/subscribe environments. J Syst and Softw., 2013, 86.1: 108-124. https://doi.org/10.1016/j.jss.2012.07.033. [29] Yang J, Sandström K, Nolte T, Behnam M. Data distribution service for industrial automation. In: 17th IEEE International conference on emerging technologies & factory automation (ETFA). Krakow, Poland. 17-21 September 2012. p. 1-8. https://doi.org/10.1109/ETFA.2012.6489544. [30] Eich M, Hartanto R, Kasperski S, Natarajan S, Wollenberg J. Towards coordinated multirobot missions for lunar sample collection in an unknown environment. J Field Robotics, 2014; 31(1): 35-74. https://doi.org/10.1002/rob.21491. [31] Endsley MR. Situation awareness global assessment technique (SAGAT). In: IEEE National Aerospace and Electronics Conference. Dayton, OH, USA. 23-27 May 1988. p. 789-795. https://doi.org/10.1109/NAECON.1988.195097. [32] Endsley MR. Toward a Theory of Situation Awareness in Dynamic Systems. Human Factors. 1995; 37(1): 32-64. https://doi.org/10.1518/001872095779049543. [33] Diefenbach A, Ginzler T, McLaughlin S, Śliwa J, Lampe TA, Prasse C. TACTICS TSI architecture: A European reference architecture for tactical SOA. In: 2016 International Conference on Military Communications and Information Systems (ICMCIS). Brussels, Belgium. 23-24 May 2016. p. 1-8. https://doi.org/10.1109/ICMCIS.2016.7496584. [34] Lopes RRF, Nieminen M, Viidanoja A, Wolthusen SD. Reactive/proactive connectivity management in a tactical serviceoriented infrastructure. In: 2017 International Conference on Military Communications and Information Systems (ICMCIS). Oulu, Finland. 15-16 May 2017. p. 1-8. https://doi.org/10.1109/ICMCIS.2017.7956505. [35] Diefenbach A, Lopes RRF, Lampe TA, Prasse C, Śliwa J, Goniacz R, Viidanoja A. Realizing overlay Xcast in a tactical service infrastructure: An approach based on a service-oriented architecture. In: 2018 International Conference on Military Communications and Information Systems (ICMCIS). Warsaw, Poland. 22-23 May 2018. p. 1-8. https://doi.org/10.1109/ICMCIS.2018.8398724. [36] Gkioulos V, Wolthusen SD. Securing tactical service oriented architectures. In: 2016 International Conference on Security of Smart Cities, Industrial Control System and Communications (SSIC). Paris, France. 18-19 July 2016. p. 1-6. https://doi.org/10.1109/SSIC.2016.7571813. [37] Lopes RRF, Balaraju PH, Sevenich P. Creating Ever-changing QoS-constrained Dataflows in Tactical Networks: An Exploratory Study. In: 2019 International Conference on Military Communications and Information Systems (ICMCIS). p. 1-8. Budva, Montenegro. 14-15 May 2019. https://doi.org/10.1109/ICMCIS.2019.8842732. [38] Johnsen FT, Bloebaum TH, Meiler P, Owens I, Barz C, Jansen N. IST-118 – SOA recommendations for Disadvantaged Grids in the Tactical Domain. In: 18th International Command and Control Research and Technology Symposium (ICCRTS), Alexandria, VA, USA, June 2013. [39] Johnsen FT, Bloebaum TH, Karud KR. Recommendations for increased efficiency of Web services in the tactical domain. In: 2015 International Conference on Military Communications and Information Systems (ICMCIS). Cracow, Poland. 18-19 May 2015. p. 1-11. https://doi.org/10.1109/ICMCIS.2015.7158709. [40] Manso M, Calero JMA, Barz C, Bloebaum TH, Chan K, Jansen N, Johnsen FT, Markarian G, Meiler P, Owens I, Sliwa J, Wang Q. SOA and wireless mobile networks in the tactical domain: Results from experiments. In: 2015 IEEE Military Communications Conference (MILCOM 2015). Tampa, FL, USA. 26-28 October 2015 p. 593-598. https://doi.org/10.1109/MILCOM.2015.7357508. [41] Bloebaum TH, Johnsen FT, Brannsten MR, Alcaraz-Calero J, Wang Q, Nightingale J. Recommendations for realizing SOAP publish/subscribe in tactical networks. In: 2016 International Conference on Military Communications and Information Systems (ICMCIS). Brussels, Belgium. 23-24 May 2016. p. 1-8. https://doi.org/10.1109/ICMCIS.2016.7496588. [42] Benincasa, G., Bunch, L., Casini, E., Lenzi, R., Morelli, A., Paulini, M. S., Suri, N. & Uszok, A. Bridging the gap between enterprise and tactical networks via mission-and network-sensitive adaptation. In: 2018 International Conference on Military Communications and Information Systems (ICMCIS). Warsaw, Poland. 22-23 May 2018. p. 1-8. https://doi.org/10.1109/ICMCIS.2018.8398699. [43] Suri, N., Benincasa, G., Tortonesi, M., Stefanelli, C., Kovach, J., Winkler, R., Kohler, R., Hanka, J., Pochet, & Watson, S. Peer-to-peer communications for tactical environments: Observations, requirements, and experiences. IEEE Communications Magazine 2010:48(10): 60-69. https://doi.org/10.1109/MCOM.2010.5594678. [44] Coalition Warrior Interoperability Exercise (CWIX). https://www.act.nato.int/cwix; [accessed 16 November 2019]. [45] Smid ME, Branstad DK. Data Encryption Standard: past and future. Proc IEEE. May 1998; 76(5): 550-559. https://doi.org/10.1109/5.4441.

[46] Coppersmith D, Johnson DB, Matyas SM. A proposed mode for triple-DES encryption. IBM J Research and Development. March 1996; 40(2): 253-262. https://doi.org/10.1147/rd.402.0253. [47] Mahajan T, Masih S. Enhancing Blowfish file encryption algorithm through parallel computing on GPU. In: 2015 international conference on computer, communication and control (IC4). Indore, India. 10-12 September 2015. https://doi.org/10.1109/IC4.2015.7375604. [48] Gulsezim D, Zhansaya S, Razaque S, Ramina Y, Amsaad F, Almiani M, Ganda R, Oun A. Two factor authentication using twofish encryption and visual cryptography algorithmsfor secure data communication. In: 2019 Sixth international conference on internet of things: systems, management and security (IOTSMS), Granada, Spain. 22-25 October 2019. [49] D’souza FJ, Panchal D. Advanced encryption standard (AES) security enhancement using hybrid approach. In: 2017 International conference on computing, communication and automation (ICCCA), Greater Noida, India. 5-6 May 2017. https://doi.org/10.1109/CCAA.2017.8229881. [50] Qin Y, Oh JC, Kim B. CMOS implementation of the IDEA encryption algorithm. In: 43rd IEEE Midwest symposium on circuits and systems. Lansing, MI, USA. 8-11 August 2000. https://doi.org/10.1109/MWSCAS.2000.951641. [51] Rivest RL, Shamir A, Adleman L. A method for obtaining digital signatures and public-key cryptosystems. Comm. ACM. February 1978; 21 (2): 120-126. https://doi.org/10.1145/359340.359342. [52] Nimbhorkar SU, Malik LG. A survey on elliptic curve cryptography (ECC). Int J Adv Studies Comp, Sci and Eng. 2012; 1(1): p. 1-5. [53] Chandra S, Paira S, Alam SS, Sanyal G. A comparative survey of symmetric and asymmetric key cryptography. In: IEEE International conference on electronics, communications, and computational engineering (ICECCE). Hosur, India. 17-18 November 2014. https://doi.org/10.1109/ICECCE.2014.7086640. [54] Li N. Research on Diffie-Hellman key Exchange protocol. In: 2010 2nd International Conference on Computer Engineering and Technology, Chengdu, China. 16-18 April 2010. https://doi.org/10.1109/ICCET.2010.5485276. [55] Van DH, Thuc ND. A Privacy Preserving Message Authentication Code. In: 2015 5th International Conference on IT Convergence and Security (ICITCS). Kuala Lumpur, Malaysia. 24-27 August 2015. https://doi.org/10.1109/ICITCS.2015.7292927. [56] Li J, Wu L, Zhang X. High-performance implementation of an HMAC processor based on SHA-3 hash function. In: 2017 International Conference on Electron Devices and Solid-State Circuits (EDSSC). Hsinchu, Taiwan. 18-20 October 2017. https://doi.org/10.1109/EDSSC.2017.8126543. [57] Gueron S, Johnson S, Walker J. SHA-512/256. In: 2011 Eighth International Conference on Information Technology: New Generations. Las Vegas, NV, USA. 11-13 April 2011. https://doi.org/10.1109/ITNG.2011.69. [58] Kim K, Kyong US. Efficient implementation of MD5 algorithm in password recovery of a PDF file. In: 2012 7th International Conference on Computing and Convergence Technology (ICCCT). Seoul, South Korea. 3-5 December 2012. [59] Common Criteria, https://www.commoncriteriaportal.org; [accessed 10 December 2019]. [60] Common Object Request Broker Architecture (CORBA) Version 3.3. October 2012. https://www.omg.org/spec/CORBA/About-CORBA/; [accessed 10 December 2019].

Declaration of interests ☒ The authors declare that they have no known competing financial interests or personal relationships that could have appeared to influence the work reported in this paper. ☐The authors declare the following financial interests/personal relationships which may be considered as potential competing interests: