WIXLIB

Interoperability vs InterconnectivityØ Data Distribution Service (DDS)n API standardn Available through the Object Management Group (OMG) www.omg.orgn For real-time interconnectivity of systems exchanging data via DDSn Common application is for “Internet of Things” (IoT), to enable interconnected systems to exchange dataover a networkn DDS uses some similar concepts as TENA and High Level Architecture (HLA)n Publish-Subscribe architecturen Data model HLA has a “Federation Object Model” DDS has a “Data Space”n Targeted use interconnectivity, e.g. Internet of Things (IoT) applicationsn Does not provide runtime interoperability services (e.g. time management) like HLAn Cannot be used in place of HLA but could be used in conjunction with HLAn Often confused item:n HLA has a “Run Time Infrastructure” (RTI) DDS has no equivalentn The best known company providing DDS software is “Real-Time Innovations” (RTI)@IITSECNTSATodayIITSECIITSECIITSEC23

Timeline Of Interoperability StandardsDISv82020TENA ardNETN TSECIITSEC24

Distributed Interactive Simulation (DIS) OverviewDISApplicationsNetworkØDIS IEEE 1278 is an “Over the Wire” specificationnnnnnnØ@IITSECDefines the structure of data sent over the networkusing a Protocol Data Unit (PDU)Is a binary protocol where individual bits are defined and bit order and byte order is mandatedDefines behavior of message handling. Receiving participants must review each packet forapplicabilityDoes not include an “API” or implementation details or solutionsFollows the COTS and Open Source business modelsPrimarily focuses on military systems/requirementsDIS participants must Broadcast or Multicast data on a local network using UDPnetwork transfer protocolNTSATodayIITSECIITSECIITSEC25

Distributed Interactive Simulation (DIS) Example PDUDISApplicationsNetworkØExamples: DIS “Entity Type” PDUnUSAF F-16C Falconnnnnnnn@IITSECNTSATodaynEntity Kind 1Domain 2Country 225Category 1Sub Category 3Specific 3Extra 0IITSECIITSECUSAF F-22B RaptornnnnnnnIITSECEntity Kind 1Domain 2Country 225Category 1Sub Category 6Specific 2Extra 026

High Level Architecture (HLA) OverviewØØØØDefines services for simulation data exchange and coordination provided by aRun-Time Infrastructure (RTI)Services are accessed through a standardized interface.A data model (Federation Object Model FOM) expressed in a standardized textfile, using the xml standard, defines how objects interact with each otherInformation exchange governed by Federation Agreements and supportingfederation Information Data Exchange Models (IDEM)oØe.g. when, where and how to utilize the service to distribute data in order to exchange informationUses COTS and Open Source business modelsFederatesFederation Object Model FOM Shared object classes Shared interaction classes More /FOM HLA APIRTI Services@IITSECNTSATodayIITSECFederation ManagementDeclaration ManagementObject ManagementIITSECIITSECOwnership ManagementTime ManagementData Distribution Management27

DIS and HLA Data Model & ication”HLA Real-time Platform ReferenceFOM (RPR-FOM) SISO-STD-001DIS IEEE 1278 Data ModelDIS and HLAare maintainedthrough ndustryAcademiaEtc-COTS, GOTSIn-houseOpen sourceOther- Research- Student projects- CoursesIEEE is the externalstandards body for SISO28

TENA OverviewTENA is the DoD GOTS live range integration architectureØWhat does TENA enable?nnnnnØWhat is included in the TENA architecture?nnnnØ@IITSECInteroperability between inter- and intra-range assetsElimination of proprietary interfaces to range instrumentationEfficient incremental upgrades to test and training capabilitiesIntegration of Live, Virtual, and Constructive assets (locally or distributed)Sharing and reuse of common capabilities across existing and new investmentsCustomizable “data contracts” that standardize repeatable information exchangeInteroperability-enabling, auto-code generated software librariesA core set of tools that address common test and training requirementsCollaboration mechanisms that facilitate sharing and reuseTENA is continuing to be evolved and has institutional fundingNTSATodayIITSECIITSECIITSEC

TENA-Enabled Interoperabilitylllllllllll@IITSECCommon specifications for test and training dataData Dissemination across variable applications, platforms,programming languages, networks, and classification levelsData Collection and PlaybackDataManagementLocal and Remote Command and ControlHealth & Status MonitoringEventManagementReal-Time simulationsStimulation of live sensors and instrumentationConnecting non-interoperable inter- and intra-range systemsLVCIntegrationEliminating proprietary interfaces to range instrumentationSharing and reuse of common range tools and capabilitiesOnline Collaboration and File SharingSharing &ReuseNTSATodayIITSECIITSECIITSEC

Test and Training Enabling Architecture (TENA) OverviewTENA ApplicationsTENA ToolsHWILRange ResourceApplicationTENATENAObject TENA pplicationReusableApplicationsTENA MiddlewareTENA MiddlewareTENARepositoryLogicalRange DataArchiveTENA Common InfrastructureObject agement andPlanning NA CommunicationsNon-TENASystemTENA Utilities@IITSECReusableApplicationsIITSECØ100% Government off the Shelf (GOTS) Initially developed to support the demandsof live system testing Provides tools for common Event Planning,Execution, and Analysis functions Provides Subject Matter Experts to supportdistributed exercise and system integration Community-managed Open Architectureand Standards Constantly improved to meet new userrequirements Download TENA Middleware and tool set http://www.tena-sda.orgNon-TENASystemNon-TENA ApplicationsIITSECIITSEC31

TENA Data Model & StandardizationØØØThe DoD maintains the extensive and extendable TENA Standard Object ModelObject Models were initially based on Live Test and Training Range requirementsVirtual and constructive simulation requirements are now includedØPlatform n-v3nTENA-SyncController-v1nTENA-UniqueID-v3JNTC OMs (for reat-v2NTSATodayIITSECTime-Space Position Information(TSPI) -v2Other v4TENA-Exercise-v1TENA-GPS-v3TENA-Radar-v3.1TENA OM for RPR FOMTENA OM for HLATENA om for DISEtc, etc., etc.IITSEC TENA is funded, maintained, enhanced andprovided via US Department of Defense(DoD) Test Resources Management Center(TRMC) Also sponsors JMETC for DoD-widepersistent network connectivityTest LessonsLearnedLearnedLearnedTRMC’s TENA Architecture ManagementTeam (AMT) comprised of Govt, industryand academia32

Recommended Integration ApproachØIdentify a Common ArchitecturenØESB Provides Ability to Meaningfully Communicate for Reuse and ComposabilitynnØUtilize horizontal Integration using Enterprise Service Bus (ESB) concept (HLA, TENA, etc.) when possibleStandard Data Model to describe the data communicatedStandard Services Interfaces (API) Software provides the Standard Services using Standard APIs e.g. Services to distribute the data modelSubsystems are called Federates. The Integrated System is called a Federation.FederatesAPI andData ModelsSoftware infrastructure@IITSECNTSATodayIITSECIITSECIITSEC33

Identify Integration ProcessØSuggested standards and guidelines includennnØIEEE Std 1730-2010 - IEEE Recommended Practice for Distributed Simulation Engineering and Execution Process(DSEEP)IEEE Std 1730.1-2013 - IEEE Recommended Practice for Distributed Simulation Engineering and Execution ProcessMulti-Architecture Overlay (DMAO)TENA Concepts of Operations (CONOPS)HLA Distributed Simulation Engineering and Execution Process (DSEEP) OverviewnnnnIEEE 1730-2010 was developed based on authoritative systems engineering processes that were adopted and extendedto address distributed simulation requirementsIdentifies and describes the sequence of activities necessary to construct and run distributed simulationsA high-level process that is relevant to and can facilitate the development of solutionsIs independent of interoperability ent234IITSECIITSECIntegrateand ment6Analyze Dataand EvaluateResults7

Focus on CommunicationØTools like Interface Matrices and Connectivity Diagrams are effective at communicatingevent design across the teamnnThese diagrams ensure clear communication and that implementation mirrors designKey data includes: Location, IP, Port, Protocol, messages, and system namesSee vI/ITSEC 2020 Tutorial20017 : by Mr. MichaelO’Connor, TrideumCorporation for more details@IITSECNTSATodayIITSECIITSECIITSEC

4. Interoperability Using GatewaysØØComplex LVC environments may require interoperability between simulationfederations using different architecturesGateways are bridges between different simulation architecturesnExamples:nnTENA used at a test range interoperating with other facilities using DIS, HLA, or bothLegacy DIS-based system interoperating with newer HLA-based systemExample gatewayHLAHLA GatewayDISDIS v736

Interoperability Using GatewaysØGatewaysnnnØØCaution: Placing a gateway may create a single point of failure for the system.Careful system design can minimize this potential problem.A top level “system design” trade-off analysis that considers schedules, costs,technical factors, etc., should determine the best of two implementation methods1.2.@IITSECTranslate data and services between different middleware, object models, and servicesCan filter data, transferring some data while blocking other dataCan provide logging, monitoring, and detection and notification of errors or issuesSelecting a common architecture for the entire LVC environment, orImplementing, integrating, testing, operating and maintaining gateways.NTSATodayIITSECIITSECIITSEC37

Interoperability Using GatewaysØCommonly used gateways are available as Commercial Off-The-Shelf (COTS)products from numerous vendors.n@IITSECCheck carefully the product’s list of translated data types, models, and services!!ØTENA-related gateways can be downloaded from the TENA website.ØSometimes unique modifications are needed, especially when a gateway isinterfaced to a “stove-piped” (non-standards-based) system.NTSATodayIITSECIITSECIITSEC38

Multiple Levels of SecurityDefinitions:ØØSecurity DomainØØCross Domain Solution (CDS) aka Multi Domain Operations (MDO)ØØØSystem or group of systems operating under a common security policyAn information assurance solution that provides the ability to access or transfer informationbetween two or more security domainsEnables data transfers between Unclassified, Secret, Top Secret, Top Secret/SCIWhen establishing a complex distributed environment, information transferbetween two or more security domains may be neededØMost organizations do not have any effective means to address this issueØ@IITSECAs a result, too often the “solution” is a brute-force denial of access to information, thusseverely limiting system effectivenessNTSATodayIITSECIITSECIITSEC

Purpose of Cross Domain SolutionsLevel of Trust(totally open)(totally protected)Rule SetLogic, Math, &Comparative OperationsLow SecurityDomainNetwork 1Filter Decisions Block Sanitize PassHigh SecurityDomainNetwork 2 Enforces Relevant Security Classification Guidance The CDS default state is to block all traffic. Data owner guidance is implemented through user-definable, event-specific, Rule Sets. Rule Sets define if and how designated traffic can pass through. Rules must support event objectives and classification guidance. Logical operations (e.g. AND, OR, NOT) Mathematical operations involving object attributes (e.g. addition, subtraction,multiplication, division, exponents, logs, trig) Comparative operations ( , , , , ): how object attributes relate to fixed values40@IITSECNTSATodayIITSECIITSECIITSEC

CDS: Multiple Protocol ExampleØ Gateways enable broader use of existing CDSsHLASourceHLA/TENAGatewayCDSUnclassified NetworkHLA/TENAGatewayHLADestinationClassified NetworkØ There are two federations running in different Security domains, each usingHLAHLA to interoperateØ The example CDS meets requirements yet has a native TENA interfaceØ Gateways are used to translate between HLA-based simulations and TENAØ Approach enables HLA-based environments to use existing TENA-based CDS41@IITSECNTSATodayIITSECIITSECIITSEC

5. LVC Interoperability Use CaseØThe Task: A ground-based Commandand Control (C2) system is beingenhanced and must be tested.nnn@IITSECThe present test method stimulates the C2system under test with real data sent from alive aircraft via a Tactical Data Link (radio).This is a *very* expensive way to test aground-based C2 system.Great savings would be achieved if thetests used a flight simulator instead of areal aircraft.NTSATodayIITSECIITSECIITSECC2 system under testTactical Data Link(TDL), e.g. Link16

LVC Interoperability Use CaseØAn available flightsimulator has a Link 16“Data Link Processor”(interface), so the flightsimulator can be usedto stimulate the C2system under test.C2 system under testTactical Data Link(TDL), e.g. Link16Data LinkProcessorEverything’s good right?@IITSECNTSATodayIITSECIITSECIITSEC

LVC Interoperability Use CaseØAnalysis of the “real world”reveals:nnnn@IITSECThe flight simulator has an olderHLA 1.3 interface and uses avendor-modified version of the RPRFOM (“Didn’t anyone tell them toavoid building stove-pipes?!!”)A scenario generator, with DIS &SIMPLE interfaces, is available toinsert simulated tracks of otheraircraft into the Link 16 network.The data link processor has aSIMPLE interface.Link 16 is represented in two ways,standards-based and non-standardsbased.NTSATodayIITSECIITSECC2 system under testTactical Data Link(TDL), e.g. Link16HLA 1.3 withproprietaryadditions to FOMData LinkProcessorSIMPLEDISIITSECScenarioGenerator

LVC Interoperability Use CaseØDSEEP-driven feasibility studysuggested:nnnØUse HLA as the commoninteroperability solutionInsert an HLA to HLA bridge tofilter/modify vendor-specific (nonstandard) RPR-FOM extensionsUse a gateway from HLA/RPRFOM to DIS, to connect with theScenario GeneratorSome Limitations Accepted:nnn@IITSECSimulator data is accepted as the“ground truth”“J messages” from flight simulatorare not bridgedNo voice communicationsNTSATodayIITSECIITSECC2 system under testTactical Data Link(TDL), e.g. Link16HLA 1.3 withproprietaryadditions to FOMData LinkProcessorstandardHLA 1516SIMPLEBridgeHLA 1.3 toHLA 1516IITSECGatewayHLA-DISDISScenarioGenerator

LVC Interoperability Use CaseØIntegration spiral demonstrated:nnnnnØØSuccess! Initial tests produced good results with previously known limitationsAdditional actions required:nnn@IITSECSelecting HLA as a standard was appropriate due to HLA technology and performance plus existing HLAbased solutions and experienceRPR-FOM extensions, HLA to DIS gateway, and HLA to HLA bridge concepts were acceptableThe DIS network did not work due to computer clocks not being in sync (or set correctly)The scenario generator’s DIS interface only worked in one directionSecurity aspects needed further analysisUpdating the Scenario Generator’s DIS interfaceGetting approval from responsible authorities to synchronize the computer clocksGetting approval to run tests with a dedicated Link16 network and the participating real aircraft on the ground(when the flight simulator was not being used as a substitute for the real aircraft, and to validate data)NTSATodayIITSECIITSECIITSEC46

6. Summary: StandardsØThere are several standards available for Live-Virtual-Constructive interoperabilitynnØStandards needs to be maintained and updatednØNew requirements emerge over timeStandards need to be balanced between stability and flexibilitynn@IITSECSome are especially made to support simulationSome are focused on use with live systemsStable enough to allow systems to be developed that support the same version of thestandardFlexible enough to be useful and support current requirements plus new and evolvingrequirementsNTSATodayIITSECIITSECIITSEC

Summary: Standards (2)ØStandards should not be selected only on technical meritsnA “Community of Users” helps tremendouslyvvvnIndustry Support (the marketplace) is very importantvvvvØGovernment and Commercial Off-The-Shelf (GOTS/COTS) products, generally costing less than customdeveloped solutionsOn-demand training coursesOn-demand technical assistancePromotes adoption and evolution of standards (e.g. trade show demos)Organizations should try to use a limited number of interoperability LVC standardsnnn@IITSECEnsures long-term use of a standard avoids obsolescencePromotes evolution of a standardCommunication forum about common LVC applications, problems, and solutionsDeviations must be expected to fit unusual situationsDevelops “in-house” skills and experience that will be needed on future programsAdopt Gateways as initial approach to integrate disparate architecturesNTSATodayIITSECIITSECIITSEC

Summary: Standards (3)ØIntegrating LVC-based systems via distributed simulation is a powerful capabilitynLVC interoperability across domains, e.g. involving multiple military groups, createsoperationally realistic environmentsnnnnnn@IITSECSupplementing a single system with other LVC systems greatly enhances realism of trainingnThe whole is greater

Distributed LVC Event ØDistributed LVC Event nAn activity to integrate and execute LVC simulations in a virtual environment so that "real-world" processes and "things" can be exercised to investigate and solve complex issues v Real-time for live systems, Can be faster than real-time for virtual and constructive systems