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

Emre Dlk?rn ,Tolg¨Onel ,Okn Top?u ,Kdir Alpsln Demir

a Barbaros Naval Science and Engineering Institute,Turkish Naval Academy,National Defense University,Tuzla,Istanbul,34942,Turkey

b Department of Computer Engineering,Turkish Naval Academy,National Defense University,Tuzla,Istanbul,34942,Turkey

c Department of Computer Engineering,Middle East Technical University Northern Cyprus Campus,Kalkanli,Guzelyurt,Mersin 10,99738,Turkey

d Institute of Social Sciences,Gebze Technical University,Gebze,Kocaeli,41400,Turkey

Keywords:Systems integration System of systems Systems engineering Software engineering C4I systems Defense systems Data distribution service DDS integration Java message service JMS

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.?2020 The Authors.Production and hosting by Elsevier B.V.on behalf of China Ordnance Society.This is an open access article under the CC BY-NC-ND license(http://creativecommons.org/licenses/by-nc-nd/4.0/).

1.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,lately,the development cost of defense software systems is increasing exponentially.Therefore,cost-effective solutions enabling system of systems developments are highly valuable.The integration of existing realtime 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 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 track data from various sensors and using 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 realtime constraints[5].DDS is an important technology for missioncritical 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 realtime 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 enable 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 realtime 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-realtime(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 Ref.[19].According to this study,DDS performs much better in terms of satisfying realtime 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 serviceoriented 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-29].In Ref.[30],the researchers utilize a DDSbased 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.

2.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 mechanisms 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 models,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 or 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 Subscriber is an application receiving data objects from the domain.Applications providing data objects to the domain use the data writer to inform subscribers about the data object instances.When a new instance of a data object is created,a data writer sends 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.

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 SOAbased 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 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 vendorspecific messaging technologies,JMS has two types of administered 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 out 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 works with aLightStreamer server,which is for real-time messaging and data push over HTTP and Web Sockets.LJE enables us to use the 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.

3.Current state of data exchange mechanisms between DDS and SOA systems

With the emerging need for interoperability between the realtime 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 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 real-time 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 Ref.[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 realtime 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 wire-level 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 a result,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.

4.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,such as 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.

Fig.3.Overview of the system model.

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 serviceoriented 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 service-oriented 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 that implements the 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 the LJE product that enables web clients to make use of JMS directly from their web browsers.

Fig.4.Architectural overview of the system.

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.This messaging queue or topic information is determined based on 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 realtime 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.

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.

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 startup,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.Fig.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.

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′es-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.

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

5.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-realtime 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.Tables 1-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.

We compare our results with another solution for interoperability with DDS using web services(WS)provided by Caban and Sliwa[12].Their solution is referred to as WS-DDS and we call our solution as JMS-DDS.Fig.7 shows the comparison of proposed JMSDDS 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 Refs.[17,21].

Table 1Host machine.

Table 2Virtual machine.

Table 3Test machines.

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

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 Ref.[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.

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

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.Therefore,only publish operation is tested with 50 and 100 clients.Measured response time in scenario 2 begins with the client’s request and includes durations due to processing at LJE,sending JMS topic over JMS provider,C4I operations manager’s action in the DDS domain,and receiving acknowledgment message following the same path reversely on a web client.In a real system,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 Ref.[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 s 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 5Response times for the operations except publish in scenario 2.

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

Fig.8.Comparison of JMS-DDS and WS-DDS on response times for 1 and 10 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.Fig.8 shows the comparison of JMS-DDS and WS-DDS on response times for 1 and 10 clients in scenario 2.Fig.9 shows the comparison of JMS-DDS and WS-DDS 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 Figs.8 and 9 that the JMS-DDS system offers better performance for response times than WS-DDS.Moreover,it is clear from Figs.8 and 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.WSDDS has a custom solution namely WS-DDS Interface.Thus,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.Regardless of test environments,the trend in response times of JMS-DDS is more stable.JMS-DDS solution provides better scalability(see Fig.10).

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

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 bidirectional communication over a single Transmission Control Protocol(TCP)connection and reduces overhead in request handshake and error checking.Thus,LJE provides better scalability.

Fig.10.Comparison of WS-DDS and JMS-DDS on Publish response times.

One advantage that WS-DDS has over JMS-DDS is the flexibility of web services that 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 system 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 may be no time synchronization between realtime 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.

6.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.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 are trained on information security issues.Military personnel are 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[59]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 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.

Fig.11.Secure communications architecture between the warship and the headquarters.

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 at different authentication levels,integrity that ensures unaltered data 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 such as 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 that requires two keys,one for the encryption and one for the decryption such as 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 that 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 by the participants and public keys are made available to other participants in the system.Participants authenticate themselves 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.

7.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 Ref.[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 realtime 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 IST-090[41].IST-090 investigated the challenges of implementing SOA on disadvantaged grids.SOA works well on well-connected 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-real-time components.Depending on the specific task being conducted,the necessary components exhibit the necessary time-critical(or nontime-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 Fig.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 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.

8.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-realtime 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 Ref.[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 largescale 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 with this study,namely JMS-DDS,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 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.

Acknowledgment and disclaimers

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.