Research ArticleAn Open Architecture Framework for Electronic Warfare BasedApproach to HLA Federate Development

HyunSeo Kang ,1 YoonJe Sung,1 HyoungJun Kwon ,1

SugJoon Yoon ,1 and SangYeong Choi2

1Department of Aerospace Engineering, Sejong University, Seoul, Republic of Korea2School of Defense Science, Hansung University and Myongji University, Seoul, Republic of Korea

Correspondence should be addressed to SugJoon Yoon; sjyoon@sejong.ac.kr

Received 17 November 2017; Accepted 14 February 2018; Published 21 March 2018

Academic Editor: Prem Mahalik

Copyright © 2018 HyunSeo Kang et al.This is an open access article distributed under the Creative Commons Attribution License,which permits unrestricted use, distribution, and reproduction in any medium, provided the original work is properly cited.

A variety of electronic warfare models are developed in the ElectronicWarfare Research Center. An Open Architecture Frameworkfor ElectronicWarfare (OAFEw) has been developed for reusability of various object models participating in the electronic warfaresimulation and for extensibility of the electronic warfare simulator. OAFEw is a kind of component-based software (SW) lifecyclemanagement support framework.This OAFEw is defined by six components and ten rules.The purpose of this study is to constructa Distributed Simulation Interface Model, according to the rules of OAFEw, and create Use Case Model of OAFEw ReferenceConceptual Model version 1.0.This is embodied in the OAFEw-FOM (Federate Object Model) for High-Level Architecture (HLA)based distributed simulation. Therefore, we design and implement EW real-time distributed simulation that can work with amodel in C++ andMATLAB API (Application Programming Interface). In addition, OAFEw-FOM, electronic component model,and scenario of the electronic warfare domain were designed through simple scenarios for verification, and real-time distributedsimulation between C++ and MATLAB was performed through OAFEw-Distributed Simulation Interface.

1. Introduction

With the advance of science and technology, the aspectof the warfare has changed the electronic warfare. Elec-tronic warfare technology is validated through modeling andsimulation (M&S) to save cost and time. M&S has beenacknowledged as one of the most important systems in thedefense field [1].

Electronic warfare is defined as themilitary action involv-ing the use of electromagnetic energy to determine, exploit,reduce, or prevent hostile use of electromagnetic spectrumwhile simultaneously safeguarding one’s own [2]. The threemajor subdivisions within electronic warfare are electronicwarfare support (ES), electronic attack (EA), and electronicprotection (EP) [3].

Electronic warfare modeling & simulation (EW M&S)is performed by gathering various EW equipment (object)modeling. At this time, the lack of EW M&S reusability,scalability, and interoperability has been degrading its use-fulness [4]. Several studies have produced framework for

M&S-based system, but they have not been dealing withEW M&S problem domain [5]. In order to solve these prob-lems, “Open Architecture Framework for Electronic Warfare(called OAFEw)” was developed that can achieve the reuseand interoperability of EWM&S lifecycle [4]. The basic con-cept of OAFEw is that EWM&S software components are tobe reassembled to suit the user’s needswith its building blocksdefined in the common Reference Conceptual Model andrules governing all stages through an EWM&S lifecycle [4].

Now, High-Level Architecture/Run-Time Infrastructure(HLA/RTI) is already widely used in the field of defenseM&S. Also, related research is actively proceeding [5, 6].In addition, the US DMSO (Defense Modeling SimulationOffice) mandates that all defense M&S developed after 2000are executive on RTI basis. However, there is no study onarchitecture framework and HLA/RTI distributed interfacein EWM&S domain.

This paper focuses on simulation method, specially EWcomponents interoperability and resusability technology forHLA. HLA is a high-level concept to support interoperability

HindawiSecurity and Communication NetworksVolume 2018, Article ID 5150730, 12 pageshttps://doi.org/10.1155/2018/5150730

2 Security and Communication Networks

Interplay UseCase Model

Simulationmodel

InterplayComponent Library

Problemdomain

SimulationUtilities

ReferenceConceptual Model

DistributedInterface Model

Ew simulationexecution

provides

derives

is implemented byprovide for

providesa resolution of

the composition of

common semantics

Figure 1: Constituents of OAFEw.

for distributed simulation of heterogeneous simulator asproposed by US DoD (Department of Defense) [7–9].

We present an HLA federate development method that ishighly reusable and interoperable based onOAFEwRules andOAFEw Reference Conceptual Model.

In the next section, we will review the relevant researchworks. And Sections 3 and 4 describe how to developOAFEw-based HLA federate. In Section 5, we will show itsimplementation and show demonstration. Finally, we willhave conclusions in Section 6.

2. Related Literature Review

2.1. OAFEw Basic Concept Review. An Open ArchitectureFramework of Electronic Warfare modeling & simulation(called OAFEw) is intended to foster easy composition ofthe EW simulation model and to be used for the lifecyclemanagement of EW simulation components on the basisof the common Reference Conceptual Model so that it canachieve the reuse and interoperability of EWM&S.The basicconcept of OAFEw is as follows.

Firstly, we assemble M&S components according to anEW scenario on the basis of the EW Reference ConceptualModel. Secondly, we use common templates for the compo-nent specifications that are the embodiment of elements inthe EW Reference Conceptual Model. Thirdly, we keep thecommon rules for component assembling, its implementa-tion, reuse, and governing all stages through an EW M&Slifecycle [4].

OAFEw comprises a Reference Conceptual Model, anInterplay Use Case Model, an Interplay Component Library,and a simulation model, which are shown in Figure 1.

The Reference Conceptual Model is a conceptual modelof an EW real world in the problem domain. It is noted thata conceptual model represents the real world to be imple-mented in the simulation model. The Reference ConceptualModel provides common semantics to be referenced by otherOAFEw constituents [4].

The InterplayUseCaseModel is tomodel use caseswithinthe context of EW simulation domain.The InterplayUseCaseModel is associated with an EW scenario with which a certain

problem should be resolved.The scenario thus can be formu-lated using each of the interplay use cases.The InterplayCom-ponent Library is a collection of EW simulation componentsimplemented according to the specifications of the interplayuse cases. The components in the Interplay ComponentLibrary must have both internal interfaces to the simulationutilities such as a simulation engine and external interfacesto the HLA/RTI to be compliant with the HLA of distributedsimulation. Thus, there are two types of components in theInterplay Component Library. These are simulation utilitycomponents and distributed interface components. Simula-tion utility components are simulation execution and collec-tion of simulation data. Distributed interface components arefor the interoperability of the components residing on theother federates in the EW federation [4].

The simulation model is to mimic an EW real worldrelated to a problem domain. The simulation model is com-posed of components in the Interplay Component Library.The components are reused for the simulation compositionassociated with an experiment scenario of the problemdomain [4].

2.2. OAFEw Specification Rules Review. Specification rulesconstrain the specification method of the OAFEw con-stituents such as the Reference Conceptual Model, the Inter-play Use Case Model, and the Distributed Interface Model.Figure 2 shows the graphical depiction of their relationshipsconstraining each other.

Firstly, theReferenceConceptualModel providesOAFEwconstituents of a common dictionary which explains whatis going on in an EW real world. The Reference ConceptualModel should be described using CML (Conceptual Model-ing Language). The CML elements are shown schematicallyin Figure 3. The CML describes both static and dynamicproperties of EW entities in a way that an EW elementgenerates an event, then the event again activates the elementbehavior and alters the state of the element. Every elementbelongs to a category and has characteristics. Piece and gamespace inherit from the element, and they belong to a battlespace. For the sake of the fuller modeling power of theOAFEw constituents, we extend the notion of the events

Security and Communication Networks 3

ReferenceConceptual Model

Interplay UseCase Model

DistributedInterface Model

InterplayComponent Library

CML

BOM FOM

Class entitiesPattern actionsState machine

CommonElements

BehaviorsTransition events

Common

Trigger eventsMessage events

Runtimeinterconnections

Figure 2: Specification methods.

ElementEvent

Behavior

generates

activates

altersstate of

Category Characteristic

Modifier Time

exists at or for

belongs to has

Battlespace

GameSpace

Piece

locatedin or on

External Element

1

modifies

createsanddeletes

1

sends andreceives

generates

0..∗

0..∗

0..∗ 0..∗

1..∗

1..∗

0..∗

1..∗

1..∗

1..∗

1..∗

Figure 3: Conceptual Modeling Language.

to three types which are partly adapted from BOM (BaseObject Model): transition event, message event, and triggerevent. Transition event is an event that changes the innerstate of an element. Either the message event or the triggerevent is an event sending an external element. The messageevent designates the receiver, but the trigger event does notdesignate the receiver.

Secondly, the OAFEw use cases in the Interplay Use CaseModel have to be captured so that the series of use casesmay compose an experimental scenario for the resolution ofproblems. The interplay is the same notion as in the BOMstandard which is a sequence of pattern-actions involvingone or more conceptual entities which appeared in the EWReference Conceptual Model. The pattern-action is a singlestep in a pattern of interplay that may result in a state changeof a conceptual entity. Thus, each Interplay Use Case shouldbe specified using BOM standard. Further, the specification

of interplay use cases has to use the same dictionary of con-ceptual entities, behaviors, and events in the EW ReferenceConceptual Model, because they should share the commonsemantics with each other. The use case specifications arethen to be implemented as reusable components in theInterplay Component Library. The components provide thesimulation model with reusable building blocks.

Finally, the Distributed Interface Model should be speci-fied with the HLAObject Model Template (OMT) in order tobe compliant with HLA. HLA Object and Interaction in theOMThave to be defined using either themessage event or thetrigger event in the conceptual model in order to share com-mon semantics throughout all of the OAFEw constituents.

2.3. HLA/RTI Review. HLA (High-Level Architecture) isone of the first priority efforts of the US Department ofDefense (DoD) as a common technical standard to promote

4 Security and Communication Networks

Liveparticipants

Interfaces tolive players

Supportutilities

Simulations

C++Java

Runtime Infrastructure (RTI)Federation Management Declaration Management

Ownership ManagementData Distribution Management

Object ManagementTime Management

HLA Interface Specification

Figure 4: RTI introduction.

interoperability between all kinds of simulations in a networkor distributed environment or between C4I (Command,Control, Communication, and Intelligence) systems andweapon systems and reusability of each component.

HLA consist of HLA Rule [7], Federate Interface Specifi-cation [8], and Object Model Template [9].

The reuse unit of the simulation software that provides themodel implemented for the simulation is called the federate.The multiple federates in a federation communicate witheach other via the RTI using a common OMT. Federationaggregates and simulates the entire environment; also eachfederate’s information and state variable can be exchanged.

RTI is a middleware that implements the interfacespecification of the HLA. It provides a common service ofthe simulation system as shown in Figure 4 and providesdeclaration and management of federates.

Within the HLA, federations are comprised of federatesthat exchange information in the form of objects and inter-actions–concepts that will be explained further in this guide.The HLA is defined by three components: (1) FederationRules, (2) the HLA Interface Specification, and (3) the ObjectModel Template.

The interface specification describes the six service man-agement functions as protocols regarding the functionalinterface between each federate and the RTI. Each serviceprovides the following functions.

(1) Federation management: it is a service that managesFederation Execution. It provides services such ascreation, removal, subscription, withdrawal, synchro-nization, storage, and recovery of federations.

(2) Declaration management: it manages the subscribe-publish mechanism of shared objects between fed-erates as a service that manages the declaration ofstate and information exchange between federatesbelonging to a federation.

(3) Object management: interaction with mock objectsin federation creates and discovers messages, updatesand reflects objects, deletes, andmanages the functionof sending and receiving interactive messages.

(4) Ownership management: it is a service related toacquiring or transferring the right to update and

delete shared objects to be simulated within a federa-tion.

(5) Time management: it is a simulation time manage-ment service that runs in the federation.

(6) Data distribution management: it is a routing serviceto control the amount of messages exchanged withina federation.

3. OAFEw-Based HLA Federate Development

3.1. EW Reference Conceptual Model. The first implemen-tation of OAFEw is its Reference Conceptual Model [4].EW Simulation Reference Conceptual Model is a referencemodel for the conceptual model of the reality that the elec-tronicwarfare simulationmodelwants to simulate.TheRefer-ence Conceptual Model also serves as a common semanticdictionary of EWcomponents for constructing a specific con-ceptualmodel.TheReferenceConceptualModel ofOAFEw isdefined as a model that describes the EW real world throughCML.

This conceptual model includes the entire domain EWM&S.This study was based on the OAFEw conceptual modelversion 1.0.

Reference Conceptual Model version 1.0 (Figure 5) con-sists of 4 components: ECMsystem,WeaponSystem, Platform,and Operator. Each of the components has events and theirbehaviors. This shows and explains the process of electronicwarfare simulation.

It should be defined for reusablemodeling and simulationbased on HLA-based federate. This can be defined through amutual progressive use model.

The most important role of the interoperable usabilitymodel is to express the use of the EW domain. Interactiveuse identifies and standardizes a modeling unit called CMLinterplay. In addition, this interactive and progressive UseCase Model becomes a building block of the simulation sce-nario.

3.2. Interplay Use Case Model. OAFEw Rules 3 and 4 definethat the use of the Interplay Use Case Model should be iden-tified to be a component of the EW Simulation SpecificationModel. Use Case Model should be specified in accordancewith the template form of the mutual progression of the BaseObject Model (BOM) standard [2, 4].

InterplayUseCaseModel is composed of a group of inter-related element specifying metadata information, ReferenceConceptual Model information, and class information. Thisinformation is defined using HLA OMT [2] and mappingbetween Reference Conceptual Model element and objectmodel elements that identify the class structure.

Use Case Model is intended to reduce the degree of cou-pling between HLA/RTI and federated layers of HLA/RTI-based distributed simulation. It is the process required toreuse the Federated Object Model (FOM) by providing a wayfor the user to combine components easily. This allows manydistributed interfaces in the domain.

The completed unit BOMs are the unit elements of theFOM for HLA-based distributed simulation. Use CaseModel

Security and Communication Networks 5

E-Element e-Transition Event B-BehaviorLegend of stereotype:

⟨E::Player⟩Transmitter(Jammer)

⟨B::Immediate⟩generateCarrier

m-Message Event t-Trigger Event

⟨B::Immediate⟩modulate(J)OntoCarrier

⟨B::Immediate⟩amplifyTo(J)Signal

⟨e::Decision⟩eModulate(J)OntoCarrier

⟨e::Decision⟩eAmplifyTo(J)Signal

⟨m::InfoExchange⟩m(J)SignalTransmitted

⟨B::Immediate⟩compute(J)ERP

⟨E::Player⟩EmitterAntena

⟨B::Immediate⟩compute(J)PropagationLoss

⟨t::InfoExchange⟩t(J)SignalRadiated

⟨E::Player⟩AirLinker

⟨E::Player⟩Receiver

⟨B::Immediate⟩analyseSignalDetected

⟨E::Player⟩Processor

⟨B::Immediate⟩compute(J)PowerReceived

⟨t::InfoExchange⟩t(J)SignalDegraded

⟨m::InfoExchange⟩m(J)SignalDetected

⟨B::Immediate⟩identifyThreat

⟨e::Decision⟩eIdentifyThreat

⟨B::Immediate⟩computeJSRatio

⟨e::Decision⟩eComputeJSRatio

⟨B::Immediate⟩computeEmitterLocation

⟨e::Decision⟩eComputeEmitterLocation

⟨E::Player⟩Displayer

⟨E::Player⟩Operator

⟨B::Immediate⟩prioritizeThreat

⟨e::Decision⟩ePrioritizeThreat

⟨m::InfoExchange⟩mThreatPrioritized⟨B::Immediate⟩

displayThreat

⟨E::Player⟩Platform

⟨m::InfoExchange⟩mThreatInformation

⟨B::Immediate⟩awareSituation

⟨m::InfoExchange⟩mCOASelected

⟨B::Immediate⟩selectCOA

⟨m::InfoExchange⟩mCOA

⟨B::Immediate⟩implementCOA

⟨e::Decision⟩eEvade

⟨B::Immediate⟩evade

⟨B::Immediate⟩takeOff

⟨e::Decision⟩eCheckLeathalArea

⟨B::Immediate⟩detonate

⟨m::InfoExchange⟩mDetonation

⟨E::Player⟩Weapon

⟨e::Decision⟩eManeuver

⟨B::Immediate⟩maneuver

⟨m::InfoExchange⟩mJamming

⟨B::Immediate⟩generateJCarrier

⟨m::InfoExchange⟩mFire

⟨e::Decision⟩eTransmit(J)

⟨B::Immediate⟩transmit(J)Signal

⟨m::InfoExchange⟩mIlluminate(Search)

⟨B::Immediate⟩moveTo

⟨E::Player⟩ReceiverAntena

⟨t::InfoExchange⟩t(J)SignalReceived

⟨B::Immediate⟩determineDetection

⟨B::Immediate⟩assessDemise

⟨B::Immediate⟩selectECM

⟨m::InfoExchange⟩mThreatIdentified

⟨m::InfoExchange⟩mTargetInfo⟨B::Immediate⟩

performTEWA

⟨m::InfoExchange⟩mTargetInfo

⟨B::Immediate⟩generateCarrier

⟨m::InfoExchange⟩mIlluminate(Track)

ECMSystem

WeaponSystem

Platform

Operator

Figure 5: EW Reference Conceptual Model v1.0.

is pattern of interplay: state machine, entity type, and eventtype definition.

Firstly, Interface Use CaseModel of class entity is the classentity component providing a mechanism for describing thetypes of conceptual entities used to represent “senders” and“receivers” identifiedwithin a “pattern of interplay” and carryout the role of conceptual entities identified within a statemachine [2].

Secondly, pattern-action template components providea mechanism for identifying sequences of pattern-actionnecessary for fulfilling a pattern of interplay, which may berepresented by a BOM [11].

Finally, the state machine template component provides amechanism for identifying the behavior states expected to beexhibited by one or more conceptual entities.

As shown in Figure 6, the OAFEw Use Case Model is themain purpose of defining the action for simulating the systemand subsystem for the EW simulation.

The unit of the electronic warfare simulation scenario iscalled interplay. The Key Interplay required for the OAFEw-based electronic warfare simulation is defined by Jamming,ReceiveSignalWithJaming, Receive SignalWoutJam, and Illu-mination. Pattern-action, state machine, entity type, andevent type can be defined according to SISO BOM standardfor each action [11].

This Use Case Model is the basic manual for the simula-tion of EW domain as mentioned above, which becomes thebasic unit BOM for reusable FOM for HLA federate.

3.3. Model Mapping (OAFEw-FOM). If the Use Case Modeland unit BOMs are created through the OAFEw ReferenceConceptual Model, after that, we can obtain FOM for HLAsimulation through the developed Use Case Model of theOAFEw.

This FOM is called OAFEw-FOM.OAFEw-FOM consists of HLA Object class and HLA

Interaction. Parameter is data field of an interaction thatevent sent between simulation entities. Attribute is data fieldof an object that a collection of related data sent betweensimulations. HLA Object/Interaction classes are made upthrough interplay entity type and event type mapping of UseCase Model.

This section introduces how to develop OAFEw-FOMthrough Use Case Model mapping. The Use Case Modelallows us to create HLA SimulationObjectModel (SOM) andOAFEw-FOM using two types of entity and event mapping.Each type can be defined in the Reference ConceptualModel.

We define the event type BOM of the Use Case Model bydistinguishing the “message event” and “trigger event.” Thereference concept model of OAFEw defines a trigger event ifthere is no receiver (or target) and a message event if there isa receiver (or target).

Then, event typemapping can be used to define attributesand parameters of Object or Interaction class according towhether there are messages or triggers.

The BOMs generated for each Key Interplay are usedto construct a repository for HLA federate Object/Interplay

6 Security and Communication Networks

Aircraft

Linker

Missile

Antena ProcessorTransmitter

Weapon Platform

SAMLauncher

Illuminate

Jamming ReceivSignalWoJam

Jammer

EW SimulationEW M&S System

Engi

neer

ing

Leve

lO

pera

tiona

l Lev

elSo

S

Receiver

Search Track ReceivSignalWJam

ECM Simulation

EW Threat Simulation

EvadeGuidance

ReceiveSignal

SubS

yste

mSy

stem

Key InterplayLegend:

Chaff

(ＣＨ＝ＦＯ＞？)

(ＯＭＣＨＡ)

Figure 6: Interplay Use Case Model.

class and attributes/parameters through the model mappingprocess. This can be referred to as the OAFEw-FOM for elec-tronic warfare simulation HLA federation. It can be used as adictionary terminology for electronic warfare simulation fed-erate throughOAFEw-FOM.Table 1 shows theOAFEw-FOMof IlluminateKey Interplay, an example generated through theReference Conceptual Model and Use Case Model.

The Use Case Model of OAFEw and the OAFEw-FOM oftheDistributed InterfaceModel are specified according to theHLA/OMT format.

In addition, the interactionwith objects ofHLA is definedusing message event or trigger event. Distributed simulationis performed through HLA/RTI based on the OAFEw-FOMdefined above.

3.4. FED Generation. OAFEw uses Distributed SimulationInterface based on Interplay Use Case Model. HLA interfacedisorder occurs when federates with different FOMs wantto distribute simulation in a federation. Interplay Use CaseModel uses the same HLA/OMT representation format asDistributed Interface Model. The attribute and parameter,which is the data transmission method of distributed simu-lation through RTI, are classified into Object or Interactionclass. AlsoHLAObject/Interaction class can be reused duringthe simulation lifecycle without revising.

If the HLA Object/Interaction class definition and attri-butes/parameters selection for EW simulation are completedthrough OAFEw-FOM, then FED (Federation ExecutionData) file for HLA Federation Execution can be created.

Now we will show how to create a FED file based onUse Case Model. We will describe the HLA OMT to generate

the FED file. An OMT is a form for describing a simulationobject. All federates of the simulation belonging to the federa-tion are represented according to this template and exchangeinformation and state variable. OMT has to be defined usingeither themessage event or the trigger event in the conceptualmodel in order to share common semantics throughout all ofthe OAFEw constituents.

HLA OMT are classified into three types.First, there is only one SOM per federation, and it

describes simulation information. It defines an interpersis-tent message of the federate and an interaction message.This is achieved through the OMT Model Mapping processusing the Use Case Model. For example, characteristics ofthe fighter, radar, and missile platform corresponding to thesystem level platform on the electronic warfare simulationcan be HLA attributed to an object class. Also event triggerssuch as fire and explosion are designed as HLA parameters ofInteraction class.

Next, OAFEw-FOM is implemented by describing theexchange attribute/parameter information of federates in-volved in federation, where there is one OAFEw-FOM perfederation. The RTI federate exchanges the state and theinformation of each federate through the publish-subscribemethod, and it describes the declaration about the attribute/parameter sending, receiving, and saving.

Finally, theManagement ObjectModel (MOM) identifiesall the attributes and interactionmessage information presentin the federation, it describes the information, and it alsoshows the state of the federation itself.

The HLA 1.3 version and the 1516 version OMT haveessentially the same functionality, but the OMT format is

Security and Communication Networks 7

Table 1: Illumination interplay OAFEw-FOM.

Entity typeName HLA Object/Interaction class Characteristics HLA attribute/parameters

TransmitterEntity

HLAobjectClass.ECMSystem.Transmiter

ID Transmitter.IDType Transmitter.RDType

Location Transmitter.LocationFrequency Transmitter.Frequency

EmitterPattern Transmitter.EmitterPatternTransmiterPower Transmitter.TransmiterPowerTargetDistance Transmitter.TargetDistance

EmitterAntennaEntity

HLAobjectClass.ECMSystem.Tr Antenna

ID EmitterAntenna.IDType EmitterAntenna.RDType

Location EmitterAntenna.LocationFrequency EmitterAntenna.Frequency

EmitterPattern EmitterAntenna.EmitterPatternTransmiterPower EmitterAntenna.TransmiterPowerTargetDistance EmitterAntenna.TargetDistance

AirLinkerEntity

HLAobjectClass. ECMSystem.AirLinker AirLinker AirLinker

Federate 1JAM BOM

Receive SignalWJam

BOM

Assembly

Illuminate BOM

Federate 2

SOM

SOM

OAFEw-FOM

FED(Federation Execution

Data)

MOMOMT Template

Receive SignalWoJam

BOM

Figure 7: FED generation process.

slightly different. In HLA 1.3, Federation Execution Data(FED) files are used in the standard format and can beextended to fed, .mtl extensions. The 1516 OMT standardformat is an FDD (FOM Document Data) file that can beextended with the .xml, .fdd extension. In this study, OMTis designed by defining the class and the attribute values ofobject based on OAFEw-FOM as FED file format of HLA1.3version as shown in Figure 7. The information and attributesof federates are described in SOM, and the OAFEw-FOM isconfigured by combining these SOMs.

After that, OMT was designed and implemented byintegrating FOM and MOM and implementing FED filewhich is the Federation Execution Data.

In this way, it is possible to create a federation with theFederation Execution File based on the OAFEw ReferenceConceptual Model terminology dictionary and the FED filegenerated through the OAFEw-FOM.

4. OAFEw-Based Distributed Interface Model

4.1. Federate Ambassador Design. After designing the FED todefine the simulation, we design and implement the simu-lation management service function for the electronic war-fare simulator. The detailed design items of the managementservice for implementing the component-based interoper-ability device of the electronic warfare environment are asfollows. Figure 8 shows the OAFEw-based HLA/RTI dis-tributed interface flow cycle.

First, we create a Federate Ambassador through the RTIlibrary and get the managed service to be called through theRTI.Then we implement the RTIAmbassador requesting thatthe service was enabled through the Federate Ambassadorimplemented.Themain routine ofHLADistributed Interfacefor the electronic warfare simulation was designed by theRTIAmbassador.

8 Security and Communication Networks

Start

Create Federation Execution

Join Federation Execution

Model initialization

End condition

Reflect attribute,receive parameters

Resign Federation Execution

Delete Federation Execution

Sim end

Attribute & parametermapping

Update attribute,send parameters

Apply time policy

Synchronization

Declaration (P&S) register object

Delete all management

Yes

No

Synchronization

Time advance

Simulation(Ti∼Ti+1)

Figure 8: HLA/RTI interface flow chart.

// Create the federationcreateFedEx(rtiAmb,federationName, federationFile);

// Create the federationcreateFedEx(rtiAmb,federationName,federationFile);

// Main Iterationwhile (1){

// Attribute Handle Map InitializetheAttrHandleMap.clear();theClassHandle =

rtiAmb.getObjectClassHandle(“EW Dat”);// Attribute Mapping

theAttrNameHandleMap.insert//Attribute Update

rtiAmb->updateAttributeValues(theObjectHandle,∗(theAmbData.attrValues),(∗currentTime),tag.c str());

Algorithm 1: OAFEw-FOM based interface module pseudocode.

Subsequently, federates join the federation using the join-FederateExecution of the implemented FederateAmbassador.

Afterward, if the computation of the models is done upto the end condition, the computing result of the models istransmitted at the different federates. At this time, the result

value is exchanged through the RTIAmbassador’s Handle inthe publish-subscribe manner.

Handle values consist of a key and values are mapped toeach instance, so that the key and value can be transmittedtogether. At this time, if we use the normal Map containerprovided in Visual Studio, there is a problem that the dupli-cate key value is not recognized as object handles. In order tosolve this problem, we implemented Multimap container asshown in Algorithm 1 so that even if multiple attributes haveoverlapping values, we can construct an ordered pair to formhandles.

When the message handle to be published is configured,the request for message transmission and time progression ismade. At the same time the RTI is called back through theRTIAmbassador in accordance with the time progress of thefederate managing the simulation time.

One cycle of the computation model is done by updatingthe attributes with time advance permission. The modelcalculation is repeated until the simulation end condition.

In order to simulate electronic warfare through Dis-tributed Interface Model, the component and model of theelectronic warfare platform are made in dll format, and thevariable region values to be used corresponding to OAFEw-FOM are generated.

After that, we compiled the dll file in the DistributedInterface Model and created a real-time distributed simula-tion.

4.2. Time Management for Real-Time Simulation. In a dis-tributed simulation, each federate has different operating

Security and Communication Networks 9

Table 2: HLA federate time management policy [10].

Time Regulating Time Constrained

TimeRegulating

(i) It affects other federates’ time(ii) It synchronizes the full time progress of thefederation with this federation

(i) Other federates affect and are affected by timeprogress

TimeConstrained

(i) Other federates affect and are affected by timeprogress

(i) This federate is under the influence ofregulating federate(ii) This federate can be observer (management)

systems and protocols. If the logical time synchronization ofeach federate in the real-time and scenario-based simulationis not performed, the causal relation of the logical time iserroneous and the simulation result having the reliabilitycannot be derived [9].

The federate can request time progress via the RTI. In thispaper, we implement the time management service providedby the RTI in the user API (Application ProgrammingInterface) to construct the electronic warfare simulationenvironment, thereby preventing the error of the logical timeof the federates participating in the federation.

TheRTI provides two federate timemanagement policies:Time Constrained and Time Regulating. Time Constrainedand Time Regulating policy is affected by the time of itssimulation time advance from the time of the other federates(Table 2).

In case of Time-Constrained Federate, RTI provides sup-port for receiving different federate Time StampOrder (TSO)messages. So, in order to prevent causality errors, the simula-tion time is advanced to the LBTS (Low Boundary TimeStamp) [12].

On the other hand, when Time Regulating policy isapplied, RTI reports its TSOmessage to other federates. Eachfederate can use all two policies, only one, and none at all. Asshown in Table 2, federate can use time management policiesto manage the time of federation and total federation.

The designed OAFEw-based Distributed Interface Modelimplements these two policies as individual functions so thatthe user can selectively apply the functions through the userinterface module. When the user sets the usage policy for thetime management of the federate, the federate time policy isapplied via the RTI at the start of the simulation. Algorithm 2shows the pseudocode for the time-step progress request andapproval of the federate using time management policy.

When the visual system of the EW simulation is added,it is appropriate to simulate the logical time progressing in atime-step manner at regular time intervals.

Thus, using the time synchronization management of thesimulation, all events sent to the other federates at the currenttime step are calculated and advanced the next time step.

5. OAFEw-Based Distributed InterfaceCase Study

In order to verify the usefulness of the OAFEw-based Dis-tributed InterfaceModel proposed in this study, a simple real-time simulated heterogeneous electronic domain as shown inFigure 9 was performed.

//become time constrained, regulatingrtiAmb->enableTimeRegulation((∗currentTime), (∗lookAhead));rtiAmb->enableTimeConstrained();

//Time Advanceif ( theAmbData.isRegulating )(∗currentRTITime)+=(∗oneTimeStep);(∗currentTime)+=(∗oneTimeStep);rtiAmb->timeAdvanceRequest(∗currentRTITime);theAmbData.timeAdvanced = false;

Algorithm 2: Time management pseudocode.

The engineering level EW model of OAFEw Use CaseModel is implemented by C++ language. In addition, visualsystem federate and simulation control station federate areimplemented usingMATLAB/Simulink. Each of theC++ andMATLAB/Simulink federates contains HLA/RTI service andconstitutes one federation with the same FED file.

An engagement scenario for an electronic warfare sim-ulation is that friendly fighters penetrate the enemy radarbase and explode and return. If a fighter is detected on anenemy search radar, a guidedmissile is fired and the fighter istracked. At this time, the fighter emits a jamming signal. Thesimulation is terminated when the fighter is blown away orescapes formore than a certain amount of time. And the jam-ming effectiveness depends on the survival rate of the fighter.

The EW Simulation Specification Model is constructedby Key Interplay BOMs as shown in Figure 10. The modelsdesigned and implemented are stored and managed by theOAFEwModel Component Library.

As shown in Figure 11, the electronic warfare simulationcan be constructed by applying the interoperability device,and the field environment can be simulated and visualized bythe interoperability with the HLA/RTI.

This result verified that real-time simulations could beeasily performed without expensive and time-consumingreassembly, as is the design purpose of the OAFEw.

6. Conclusions

The various research models developed in the Defense Elec-tronics Specialization Research Center project are modeledaccording to the environment of development programs ofdifferent developers. Projects developers require simulation

10 Security and Communication Networks

RTI

MATLAB - HLA Interface Model

C++ - HLA InterfaceModel

MATLAB - HLA Interface Model

CS & Analysis

C++ - HLA Interface Model

Visual ModelEW PlatformEW Platform

Friend

Object

EW_hardware

Foe

Object

EW_hardware

Figure 9: HLA-based C++-MATLAB EW distributed simulation.

Platform::Fighter

mJammingJamming

IlluminateSearchmSearch

ReceiveSignalWJam

tSignalRadiated

mDetonation

tJSignalDegraded

Platform::SAMLauncher

tSignalDegradedReceiveSignalWoJam

mThreatIdentified

assessDemise

MissilemFire

takeOffIlluminateTrack

mTrack

selectECM

maneuver

mTargetInfo

performTEWA

mTargetInfo

moveTo

maneuver

implimentCOA

tSignalDegradedReceiveSignalmThreatIdentified

selectECMimplimentCOA

maneuvermJamming

JammingtJSignalDegraded

ReceiveSignalWJamperformTEWA

implimentCOAmTargetInfo

IlluminateTrack mTracktSignalDegradedmThreatIdentifiedReceiveSignal

identifyThreat

Evade or assessDemise mDetonation

Figure 10: Simulation Specification Model.

models to run in real-time use development tools suchas MATLAB or Visual Studio to model and test dynamicsystems.

However, in order to simulate a model developed ina different program, the developer needs to modify it. To

solve this problem, this study introduces HLA/RTI federatedevelopment method based on the OAFEw.

The OAFEw is a simulation lifecycle management toolthat guarantees the reusability and interoperability of modelsdeveloped for electronic warfare simulation. If an OAFEw

Security and Communication Networks 11

YES

C++ Federate EW_Federation

join

publish object attributes/interactions

create and register objects

delete/remove object

resign

begin shutdown

remove federate

MATLABFederate

create federation

join

subscribe object attributes/interactions

update attribute & send interaction reflect attribute/receive interaction

begin shutdown

Destroy federation

resign

remove federate

synchronization synchronization

synchronization synchronization

enable time regulation enable time constrained

disable time regulation disable time constrained

Figure 11: Simulation HLA service diagram.

method is adapted at EW M&S development, real-timedistributed simulation of an EW model is facilitated. EWscenarios can be created by reassembling the Key Interplayof the Use Case Model of the OAFEw. Also, if the modelis constructed through the OAFEw-Distributed SimulationInterface, there is an advantage that the EW simulation canperform without being restricted to languages such as C/C++ and MATLAB/Simulink.

We propose theOFEW-FOMbased onOAFEwReferenceConceptual Model v1.0 for many developers who want to usethe OAFEw’s Distributed Interface simulation. The OAFEw-FOM is useful for mapping EW model state machine andinput/output variables to HLA attribute/parameter. Federateexchange information OAFEw-FOM also allows developersto set HLA attributes/parameters via a EW common term.

The developed OAFEw-based Distributed InterfaceModel introduced the application of time managementservice for reliable simulation between federates. Throughthis, various models of electronic equipment developedin the future can be simulated in real-time regardless ofthe model development environment. In addition, for thereusability of the Distributed Interface Model itself, theInterface Model was designed and proposed by structuring itas a user interface module, a HLA service interface module,and an OAFEw-FOMmodule.

The proposed frameworks and interfaces model weretested for the feasibility and validity through the EW partici-pation scenarios and the EWmodels.

In the future, it is also necessary to address the problemof constantly requiring code modifications in response toFED changes resulting fromupdates to theOAFEwReferenceConceptual Model. To do this, we need a code generator thatcan automatically implement the OAFEw-FOM endecodingmodule of the proposed framework.

Conflicts of Interest

The authors declare that they have no conflicts of interest.

Acknowledgments

This research was supported by Agency for Defense Devel-opment (ADD) and Defense Acquisition Program Admin-istration (DAPA) through the Gwangju Institute of ScienceTechnology (GIST) of The Electronic Warfare ResearchCenter.

References

[1] J. S. Dahmann, R. M. Fujimoto, and R. M. Weatherly, “DoDhigh level architecture: An update,” in Proceedings of the 1998Winter Simulation Conference, WSC. Part 1 (of 2), pp. 797–804,December 1998.

[2] S. K. Gupta, G. Siva Prasad, and J. Nanda Kishore, “Electronicwarfare simulation-based on service oriented architecture,”Defence Science Journal, vol. 62, no. 4, pp. 219–222, 2012.

[3] Electronic warfare in the information age, Artech House, 1999.

12 Security and Communication Networks

[4] S. Y. Choi, H. S. Kang, H. J. Kyeon, and S. J. Yoon, “An OpenArchitecture Framework for the Electronic Warfare ModelingSimulation,” in Proceedings of the European Simulation andModeling Conference (ESM 2017), pp. 278–282, October 2017.

[5] M. Ficco, G. Avolio, F. Palmieri, and A. Castiglione, “An HLA-based framework for simulation of large-scale critical systems,”Concurrency and Computation Practice and Experience, vol. 28,no. 2, pp. 400–419, 2016.

[6] B. Moller, A. Garro, A. Falcone, E. Z. Crues, and D. E. Dexter,“On the execution control of HLA federations using the SISOspace reference FOM,” in Proceedings of the 2017 IEEE/ACM21stInternational Symposium on Distributed Simulation and Real-Time Applications (DS-RT), pp. 1–8, Rome, October 2017.

[7] IEEE, IEEE Standard for Modeling and Simulation(MS) HighLevel Architecture(HLA)-Framework and Rules , IEEE Std.1516,2000.

[8] IEEE, IEEE Standard for Modeling and Simulation(MS) HighLevel Architecture(HLA)-Federate Interface Specification , IEEEStd.1516.1, 2000.

[9] IEEE., “Standard for Modeling and Simulation (M&S) HighLevel Architecture (HLA)-Object Model Template (OMT),” 2,2000, IEEE Std.1516.

[10] R. M. Fujimoto, “Time Management in The High Level Archi-tecture,” Simulation, vol. 71, no. 6, pp. 388–400, 1998.

[11] SISO(Simulation Interoperability Standard Organization, BaseObject Model(BOM) Template Specification , SIOS-STD-003,March 2006.

[12] R. Fujimoto, A. Malik, and A. Park, “Parallel and distributedsimulation in the cloud,” SCS MS Magazine, vol. 3, p. 10, 2010.

International Journal of

AerospaceEngineeringHindawiwww.hindawi.com Volume 2018

RoboticsJournal of

Hindawiwww.hindawi.com Volume 2018

Hindawiwww.hindawi.com Volume 2018

Active and Passive Electronic Components

VLSI Design

Hindawiwww.hindawi.com Volume 2018

Hindawiwww.hindawi.com Volume 2018

Shock and Vibration

Hindawiwww.hindawi.com Volume 2018

Civil EngineeringAdvances in

Acoustics and VibrationAdvances in

Hindawiwww.hindawi.com Volume 2018

Hindawiwww.hindawi.com Volume 2018

Electrical and Computer Engineering

Journal of

Advances inOptoElectronics

Hindawiwww.hindawi.com

Volume 2018

Hindawi Publishing Corporation http://www.hindawi.com Volume 2013Hindawiwww.hindawi.com

The Scientific World Journal

Volume 2018

Control Scienceand Engineering

Journal of

Hindawiwww.hindawi.com Volume 2018

Hindawiwww.hindawi.com

Journal ofEngineeringVolume 2018

SensorsJournal of

Hindawiwww.hindawi.com Volume 2018

International Journal of

RotatingMachinery

Hindawiwww.hindawi.com Volume 2018

Modelling &Simulationin EngineeringHindawiwww.hindawi.com Volume 2018

Hindawiwww.hindawi.com Volume 2018

Chemical EngineeringInternational Journal of Antennas and

Propagation

International Journal of

Hindawiwww.hindawi.com Volume 2018

Hindawiwww.hindawi.com Volume 2018

Navigation and Observation

International Journal of

Hindawi

www.hindawi.com Volume 2018

Advances in

Multimedia

Submit your manuscripts atwww.hindawi.com