m&s–based system development and testing in a net-centric environment
DESCRIPTION
M&S–Based System Development and Testing In a Net-Centric Environment. Bernard P. Zeigler, Ph.D., Arizona Center for Integrative Modeling and Simulation and Joint Interoperability Test Command Fort Huachuca, AZ 85613-7051 [email protected]. Motivation from a Testing Perspective. - PowerPoint PPT PresentationTRANSCRIPT
M&S–Based System Development and
Testing In a Net-Centric EnvironmentBernard P. Zeigler, Ph.D.,
Arizona Center for Integrative Modeling and Simulation and
Joint Interoperability Test CommandFort Huachuca, AZ [email protected]
Motivation from a Testing Perspective
• Traditional interoperability concepts and test practices are facing severe challenges from several sources:
– a) complexity within each new system, as well as composition into families of
systems and systems of systems, – b) extensive use of modeling and simulation in simulation-based acquisition, and– c) the move to service oriented architecture (SOA) to support composable
services over the Global Information Grid (GIG).
• Need a methodology and process to integrate development and testing in a net-centric environment
– combines with and goes beyond current software development paradigms – rests upon and exploits dynamic systems theory, a modeling and simulation
(M&S) framework, and model-continuity development concepts
• Relationship to other software development processes will be open for discussion at the end
Part 1 Modeling and Simulation Background
Briefly review the M&S framework and theory
• provide background for integrated system development and testing process
• overview the Discrete Event Systems Specification (DEVS) formalism which provides the computational support for the M&S framework and theory
• DEVS can serve as the basic medium for formalization of standards, analysis of the resulting models, automation of the test cases, and execution of the test drivers
Part 2. M&S-Based Development and Testing: DEVS Methodology
• Illustrate M&S-Based testing methodology with an application drawn from a current effort to provide automated test generation for an important tactical command and control standard, MIL-STD 6016c
• Goal: develop a “formalized” version of the MIL-STD 6016C rule sets with the objective– to complete an unambiguous description of the specification,– enable more automated test development
• Result: Automated Test Case Generator (ATC-Gen) is a methodology and tool-set based on the DEVS formalism.
• Success: ATC-Gen will be one of the primary test vehicles for the first assessment of an integrated air picture system based on MIL-STD 6016c to occur this fall
Framework for M&S
Systems theory-based framework
• provides an ontology for M&S that recognizes the essential dynamic character of simulation models
• distinguishes the elements in the M&S enterprise (such as models, simulators, and experimental frames) and the relationships (such as validity and correctness) that connect such elements in meaningful ways related to the objectives of simulation exercises,
• provides a rigorous mathematical theory that supports manipulations of the elements in their real-world incarnations in order to achieve the desired relationships
M&S Entities and Relations
Real WorldReal World SimulatorSimulatorSimulatorSimulator
modelingrelation
simulationrelation
Each entity is represented as a dynamic system
Each relation is represented by a homomorphism or other equivalence
Data: Input/output relation pairs
structure for generating behaviorclaimed to represent real world
Device forexecuting model
Model
M&S Framework: Continuous case
Real WorldReal World SimulatorSimulatorSimulatorSimulator
modelingrelation
simulationrelation
Model
d q(t) / dt = x(t)
Numerical Integration:•Accuracy•Error effects
Validity:•Accuracy of -retro-diction-prediction
M&S Framework: Discrete Event case
Real WorldReal World SimulatorSimulatorSimulatorSimulator
simulationrelation
Model
x0 x1X
t0 t1 t2
first second third passiveFirstDuration
secondDuration
thirdDuration
active
0
modelingrelation
Concurrent Processing•Correctness• Randomness
Validity:•Accuracy of -retro-diction-prediction
sMake a transition
s’
Time advance
output
DEVS within the Framework for M&S
• DEVS (Discrete Event Systems Specification) formalism
– is a constructive framework for M&S– based on mathematical systems theory
• DEVS enables applications resting on rigorous theory
– modeling discrete/continuous heterogeneously composed networked systems – universality of representation
– hierarchical, modular model construction –closure under coupling
– verifiably correct parallel and distributed simulation of ultra-large scale networks
– model-continuity from simulation to execution – based on abstract simulator
– automated test generation for net-centric services – based on behavior representation from systems theory
DEVS Hierarchical Modular Composition – Key to Constructing/Orchestrating Complex Systems
Atomic: lowest level model, contains structural dynamics -- model level modularity
Atomic
Atomic Atomic
Atomic
+ coupling
Atomic
Atomic
Atomic
Coupled: composed of one or more atomic and/or coupled models hierarchical
construction
Atomic Models
OrdinaryDifferentialEquations
Pulse BasedModels
(varGen, Sum)
Quantum Based Models
(DEVS Integrator,instantaneous
Functions
Coupled Models
Phase BasedModels
Cellular Automata
1,2 Dim Cell Space
PartialDifferentialEquations
Self Organized Criticality
Models
Processing/Queuing/
Coordinating
DigraphModels
NetworksCollaborations Physical
Space
1 Dim State Space
2 Dim State Space
Types of Models and their DEVS Representations
can becomponents in a coupled model
MultiAgent
Systems
Discrete Time/
Automata
DEVS Theory: Nutaro's optimistic simulation algorithm and its correctness proof
• Nutaro developed a time warp variant that correctly simulates all discrete event models
– Previous variants of the time warp algorithm have been based on the logical process world view.
– These time warp derivatives have been widely used for simulating discrete event models on parallel computers,
– But, they can not correctly simulate DEVS coupled models with zero-time interactions
– employs a 2-D distributed clock
• A correctness proof for the algorithm was constructed– The correctness proof demonstrates that the parallel algorithm simulates exactly
the same system as the canonical DEVS abstract simulator. – Consequently, parallel and sequential simulation of the same DEVS model will
always produce the same results.
• This is a strong proof of correctness that no logical-processor-based proof has been able to rival – depends strongly on model/simulator separation
DEVS-Based Model Continuity
•Model continuity is retained between models of different design stages
•reduces the occurrence of design discrepancies along the development process
•increases the confidence that the final system realizes the specification
•Allows component models of a distributed real-time system to be tested incrementally then deployed to a distributed environment for execution
•Based on replacing DEVS simulator with DEVS Real Time executor
RobotModel
RobotModel
Virtual Environment
Virtual Sensor
VirtualActuator
RobotModel
RealRobot
Mixed Environment
Virtual Sensor
VirtualActuator
Virtual Sensor
HIL Actuator
RealRobot
RealRobot
Real Environment
Real Sensor
RealActuator
DEVS Distributed Simulator
DEVS Distributed RT Executor
Model Continuity Mixed Virtual/Real Environment – Any number of virtual
robots can interact with a few real robots
Summary
DEVS is an overarching approach
– supports all levels of system interoperability
– using a Systems Theoretic worldview
– component-based characterization of dynamical systems in discrete and continuous forms
– methods for modular, hierarchical model composition targeting reusability and composability
Part 2. M&S-Based Development and Testing: DEVS Methodology
• DoD acquisition policy requires testing throughout the systems development process to ensure interoperability and conformance to standards.
• The Joint Interoperability Test Command (JITC) is striving to improve traditional standards conformance and interoperability testing methodologies to
– keep pace with the behavioral complexity of new systems that are increasingly reliant on advanced information technology
– DoD mandated use of M&S throughout the development life cycle, requires testing methods that are themselves M&S-based
• In 2003, the JITC started development of a “formalized” version of the MIL-STD 6016C rule sets with the objective
– to complete an unambiguous description of the specification, and – enable more automated test development.
• illustrate the methodology with an application drawn from a current effort to provide automated test generation for an important tactical command and control standard, MIL-STD 6016c
– Automated Test Case Generator (ATCGen), which is a methodology and tool-set based on the DEVS formalism.
– ATC-Gen will be one of the primary test vehicles for the first assessment of an integrated air picture system based on MIL-STD 6016c to occur this fall.
• working towards a proposal for how the DEVS-based approach enables– 1) simulation-based model continuity in developing and testing specifications that stem from
the DoD Architectural Framework (DoDAF), and– 2) a standard and an infrastructure for developing and testing web-based services for
DoD’s emerging Net-Centric Enterprise Services on the Global Information Grid.
Outline
• JITC responsibility for Link-16 and successors
• Link-16: Challenges to Implementation and Testing
• M&S–based Approach to Automated Test Case Generation
• Application to Link-16 in the IABM SIAP Context
JITC is the Responsible Test Organization for TDL Standards
• JITC is responsible for ensuring systems that implement Tactical Data Link (TDL) (Link 11/11B/16 and Variable Message Format (VMF)) are interoperable and in compliance with the applicable joint standards.
• This is accomplished by conducting the following types of tests: – Joint / NATO /Combined Interoperability – Performance Assessment in Operational Environments – Standards Validation – Standards Conformance
• JITC employs a variety of tools that provide its analysts the ability to evaluate TDL system performance in both the lab and live environments.
source: http://jitc.fhu.disa.mil
Link-16: Challenges to Implementation and Testing
Joint Single Link Implementation Requirements Specification JSLIRS is an evolving standard (MIL-STD-6016c) for tactical data link
information exchange and networked command/control of radar systems
• Presents significant challenges to automated conformance testing:– The specification document states requirements in natural language– open to ambiguous interpretations– The document is voluminous – many interdependent chapters and appendixes– labor intensive and prone to error– potentially incomplete and inconsistent.
• Problem: how to ensure that a certification test procedure – is traceable back to specification– completely covers the requirements– can be consistently replicated across the numerous contexts– military service, inter-national, and commercial companies
SIAP/IABM —Successor to Link-16
• SIAP (Single Integrated Air Picture) Goal: Improve the adequacy and fidelity of information to form a shared understanding of tactical situation
• Integrated Architecture Behavior Model (IABM) requires that all sensors utilize a standard reference frame for conveying information about the location of targets.
• Developed by the Joint SIAP System Engineering Organization (JSSEO), Arlington, Va., a sub-office of the Assistant Secretary of the Army for Acquisition, Logistics and Technology.
• Development costs $160 million over five years; the individual services will spend an estimated $600 million
• First major test – Config05 – next week -- ATC-Gen will be the basis for testing link-16 and extended IABM requirements
http://www.navyleague.org/sea_power/mar_04_18.php
Automated Test Case Generator (ATC-Gen)
• IABM is an extension of Link-16 developed in HLA environment and requires HLA simulation-based testing
• JITC has taken the initiative to integrate modeling and simulation into the automation of the testing process
• Funded the development of Automated Test Case Generator (ATC-Gen) led by ACIMS using DEVS (Discrete Event System Specification) technology.
• In R&D of two years, proved the feasibility and the general direction
• The requirements have evolved to a practical implementation level, with help from conventional testing personnel.
Discrete Event Nature of Link-16 Specification
Constraints(Exception)Rules
Stop
Modify C2Record for TN
1 2 3
RuleProcessing
Stop, Do Nothing,Alerts, Or jump to other
Transaction
TrackDisplay
Operatordecisions
Validity checking
TransmitMsg
Other ConsequentProcessing
Jumps (stimuli) to other
Transactions of specification
Transaction Level - example P.1.2 = Drop Track Transmit
Preparation Processing
Timeouts
PeriodicMsg
Input to
systemDEVS
Output from
system
t1
t2 t
3t4
Automated Test Case Generation: Goals and Approach
Objective:Automate Testing
Capture Specification as DEVS
Analyze DEVSI/O Behavior
Synthesize Test Models
Test Driver executesmodels to induce testable behavior in SUT
Interactwith SUT over Middleware
Goals:
• Increase the productivity and effectiveness of the conformance testing• Apply DEVS systems theory, modeling and simulation concepts, and current software technology to (semi-)automate portions of conformance testing
Formalized approach for converting standards documents into test models to run directly against a system, automating the process to the extent possible
Network
DEVS Simulator
Test Driver
HLA
SystemUnder
Test (SUT)
HLA
Benefits of Formalization and Automation
• Provides traceability to original specification
• Reduces ambiguity from textual specification
• Facilitates integrating Modeling & Simulation into the testing process
• Enables testing of complex:– Standards– Systems– Functions– Families of systems
ATC Gen Overall Process
• MIL-STD-6016C is a description of a DEVS that mandates the outcome of tests and sequences of tests
• ATC Gen analysts convert if-then rules from the MIL-STD into XML, defining state variables and vectors
• XML if-then rules are used to generate test sequences
• Test models are derived from test sequences
• Test Driver runs test models against SUT in distributed simulation
XMLRule Set
Rule capture
6016C
XMLRules
XMLRule Set
Analyze Rules Define State Variables
Reference Model
Compile executableReference model
Rule Compiler Executable
paths
Test case models
Simulations of test cases
Verification of Test Sequences
Test sequences
ExecutableTests
Test StimulatorReference modelLogging
Test Execution
Test Driver
Test ProceduresTest Results
Rule capture andDependencyAnalysis
Rule Formalization
Test Generation
ATC-Gen Process Lines
Analyst:Interpret the text to extract state variables and rules, where rules are written in the form:
If P is true nowthen do action A
laterunless Q occurs in the interim
The Dependency Analyzer (DA):determines the relationship between rules by identifying shared state variablesGenerates test sequences and test modelsTest Engineer:Develop sets of test sequencesConvert test sequences to executable simulation modelsConvert test sequences to executable simulation models
Test Driver:Interacts with and connects to SUT via HLA or Simple J interfacesPerforms conformance testing of SUTs
MIL-STD-6016C Micro-Structure
Stimuli ConstraintsProcessing
MessagePreparation
Message Transmission
Message Reception
InitiatorInitiator ResponderResponderRoles
AppendixStructure
MessagePhase
Interpretation and Translation
Appendix E.1.1
Identify RolePreparation of message set as
Initiator Role
Identify Type of Stimulus Operator action
Translation to XML – Variable Standards
Role E1.Init=True
Type of Stimulus VOI
Interpretation and Translation
Constraints in Appendix E.1.1.2.1
If Reference TN equals 0, 77, 176, 177, 777 or 77777
ThenHost System:
– Performs no further processing– Alerts operator (CAT 4)
Translation to XML – Variables Standards
ConditionE1.Init == True and
VOI.TNref == 0 or 63 or 126 or 127 or 4095 or 118783
Action E1.Init = False
Output CAT 4 Alert
Detailed XML Example: Traceability, Quality Assurance
4.11.13.12 Execution of the Correlation. The following rules apply to the disposition of the Dropped TN and the retention of data from the Dropped TN upon origination or receipt of a J7.0 Track Management message, ACT = 0 (Drop Track Report), for the Dropped TN. The correlation shall be deemed to have failed if no J7.0 Track Management message, ACT = 0 (Drop Track Report), is received for the dropped TN after a period of 60 seconds from the transmission of the correlation request and all associated processing for the correlation shall be cancelled.
a. Disposition of the Dropped Track Number: (2) If own unit has R2 for the Dropped TN, a J7.0 Track Management message, ACT = 0 (Drop Track Report), shall
be transmitted for the Dropped TN. If the Dropped TN is reported by another IU after transmission of the J7.0 Track Management message, own unit shall retain the dropped TN as a remote track and shall not reattempt to correlate the Retained TN and the Dropped TN for a period of 60 seconds after transmission of the J7.0 Track Management message.
• XML Translation:<rule trans="4.11.13" stimulus="4.11.13.12" reference="4.11.13.12.a.2" ruleName="R2 Unit transmits J7.0">
<condition txt="Check for R2 own unit" expression="AutoCor==True and (CRair.TNcor.CORtest==3 and J32.TNref.CORtest==3) and CRair.R2held==1 AND J72.MsgTx==True">
</condition><action txt="Prepare J7.0 Drop Air Track message" expression="J70.TNsrc=TNown; J70.TNref=TNdrop;
J70.INDex=0; J70.INDcu=0; J70.ACTVair=0; J70.SZ=0; J70.PLAT=0; J70.ASchg=0; J70.ACTtrk=0; J70.ENV=0; MsgTx(J70)">
</action><output txt="Transmit J7.0" outType="Message" outVal="J70"></output>
</rule><QA>
<revisit name="DHF" date="10/16/04" status="Open">need to add timer for a period of 60 seconds in which correlation is not reattempted</revisit>
</QA>
Quality Assurance (QA)
• Provides a history of rule changes• Identifies possible Change Requests and
other problematic portions of the standard• QA tags:
– Info: Explanation / reasoning for rule interpretation– Revisit: Rule needs further analysis; set to Open
or Closed– Resolution: Solution to question / issue
Appendix N Functional Area, e.g. Track Management
Function P.N e.g. C2 Drop Track
Transaction P.1.N C2 Drop Track Transmit
Step 1 – Stimuli, Preparation, Constraints
Step 2 – Processing, Operator Decisions
Step 3 – Update Database, Output
AtomicLevelUnit
• Transactions are atomic units
• Functions are collections of Transactions
• Appendices group related Functions
• Java processing restructures rules into a Transaction Module Hierarchy
MIL-STD-6016C Macro-Structure
• Organized according to MIL-STD-6016C macro-structure hierarchy
• RuleCombo folders store aggregations/abstractions of lower level rules
• Value added:– Provides a basis for further analysis– Removes ambiguity – Annotates problems areas, improving the
ability to find and fix issues– Provides organization for indexing states,
rules, and variables– Supports test generation and executable rule
construction
XML Repository – GIG/SOA Asset
Dependency Analysis:Visualization of Rule Dependencies
Clicking will reveal rule text
Dependencies revealed by hovering
DependencyBetween Modules
Desired SequenceC.1 Receive PPLID.1 Receive TrackU.1 Correlate
Test Sequence Generation Transaction Level Paths
C.1ModuleN
active
= infinity
D.1ModuleN
active
= infinity
U.1ModuleN
passive[out1]
= infinity
Potential Test
Sequence
Determining initial state and message field values required to drive SUT through sequence
Analyst:• Determine the data
needed to execute a test sequence
• Set state variables and field values accordingly
Test Simulatlon Architecture
J-SeriesMessage
Generator
J-SeriesMessageAcceptor
Test Model
System Under Test
Produces Stimulus
Checks for Proper Response
holdSend(Jx1,data1,t1) holdSend (Jx2,data2,t2)
holdSend (Jx3,data3,t3) waitReceive(Jx4,data4)
receiveAndProcess(Jx1,data1) receiveAndProcess(Jx2,data2)
receiveAndProcess(Jx3,data3) transmit(Jx4,data4)
Jx1,data1Jx2,data2Jx3,data3
Jx4,data4
t1 t2 t3 t4time
Test ModelTest Model
SUT
Test Model Construction:
Translate test sequences from the DA to derive a composed model for the Test Driver
Test Driver Composition and Deployment
Middleware
Test ModelTest Model
Jx1,data1Jx2,data2Jx3,data3
Jx4,data4 Jx1,data1Jx2,data2Jx3,data3
Jx4,data4 Jx1,data1Jx2,data2Jx3,data3
Jx4,data4
Sequence 1
Sequence 2
Sequence 3
SUT
IABM/Link 16 Correlation Testing
• ATC Gen automated correlation/decorrelation tool provides in-depth compliance testing
• Mathematical algorithm of the proximity of the tracks
• Logic for prohibitions and constraints
• Test for post-correlation (dropped and retained tracks)
• Discriminates between types of failures encountered during correlation testing
ATC Gen Summary: What Can (not) be Automated?
Original Standard(MIL-STD-6016C)
Repository (XML)
XML Translation
Natural Language
XML (Computer Language)
XML Validation &Verification (DTD)
Validated XML
Dependency Web(Java GUI)
DependencyAnalyzer
Test Sequence Step& Test ModelGeneration
XML
Class Files
XML
Test ModelsTest Driver
(Event Coordinator)
DEVS Model
Manually Derived Paths
Simple JInterface
HLAInterface
DEVS Messages
SUT
XML Capture of Standard
Dependency Analysis & Test Generation
Process Legend:
Manual
Semi-Automated
Automated
Executable TestSequences
C Files
Java Files
Simple J
DEVS Messages
HLA Updates& Interactions
Testing of Systems
Discussion
Can the DEVS-based M&S approach enable
• simulation-based model continuity in developing and testing specifications that stem from the DoD Architectural Framework (DoDAF), and
• a standard and an infrastructure for developing and testing web-based services for DoD’s emerging Net-Centric Enterprise Services on the Global Information Grid.
Systems Engineering Perspectives for M&S Applications (Robert Marcus)
DoD System Life-Cycle
ConceptRefinement
TechnologyDevelopment
SystemDevelopment & Demonstration Production &
DeploymentOperations &
Support
Concept Analysis Design Develop Test Deploy Maintain
Proofof
ConceptSystem
SimulationSystems
EmulationModelBased
LVCSimulation
DemosLVC
TrainingDiagnosticEmulation
ConceptsTesting
PrototypeTesting
SystemValidation
DesignTesting
SystemVerification
UseabilityTesting
DiagnosticTesting
IndustrySystemLife-Cycle
DODAF
Operational View
Systems View
Technical View
Packaging
Messaging
Communication
Service D
iscovery
Service D
escription
Service C
omposition
Service T
estingLevel
Name What we specify at this level
4 Coupled Systems
System built up by several component systems which are coupled together
3 I/O System System with state and state transitions to generate the behavior
2 I/O Function
Collection of input/output pairs constituting the allowed behavior partitioned according to the initial state the system is in when the input is applied
1 I/O Behavior
Collection of input/output pairs constituting the allowed behavior of the system from an external Black Box view
0 I/O Frame Input and output variables and ports together with allowed values
Simulator
Model
Experimental Frame
Hierarchy of System Specifications
ArchitectureFrameworkStandards
DevelopmentProcessStandards Service
OrientedArchitectureStandards
MiddlewareStandardsM&S
Standards
ConceptRefineme
nt
Technology
Development
SystemDevelopme
nt & Demonstrat
ion
Production &
Deployment
Operations &
Support
Concept
Analysis
Design
Develop Test Depl
oyMaintain
Proofof
Concept
System
Simulation
Systems
Emulation
ModelBase
d
LVCSimulationDemo
s
LVCTraini
ng
DiagnosticEmulation
ConceptsTesting
PrototypeTesting
SystemValidation
DesignTesting
SystemVerification
UseabilityTesting
DiagnosticTesting
IndustrySystemLife-Cycle
Interlocking Standards – How Do These Play Together?
Models and Methodologies –How Do These Play Together?
IDEFIntegrated Definition
for Function Modeling
PetriNets
UMLUnified Modeling
Language
MDAModel Driven Architecture
MDDModel Driven Development
IDEFØ is a method designed to model the decisions, actions, and activities of an organization or system. IDEFØ was derived from a well-established graphical language, the Structured Analysis and Design Technique (SADT). The United States Air Force commissioned the developers of SADT to develop a function modeling method for analyzing and communicating the functional perspective of a system. Effective IDEFØ models help to organize the analysis of a system and to promote good communication between the analyst and the customer. IDEFØ is useful in establishing the scope of an analysis, especially for a functional analysis. As a communication tool, IDEFØ enhances domain expert involvement and consensus decision-making through simplified graphical devices. As an analysis tool, IDEFØ assists the modeler in identifying what functions are performed, what is needed to perform those functions, what the current system does right, and what the current system does wrong. Thus, IDEFØ models are often created as one of the first tasks of a system development effort.
This is a 4GL notation tailored to OO software development. It is primarily a graphical notation. The standard is managed by the OMG.integrates the concepts of Booch, OMT and OOSE by fusing them into a single, common and widely usable modelling language. UML aims to be a standard modelling language which can model concurrent and distributed system
"model-driven" development methods, based on greater use of automation compared to traditional methods, have already demonstrated their potential for radical improvements in the quality of software
The MDA defines an approach whereby you can separate the system functionality specification from its implementation on any specific technology platform. That way you can have an architecture that will be language, vendor and middleware neutral.
Petri nets were invented by Carl Adam Petri to model concurrent systems and the network protocols used with these systems.
Semi-automated test suite design based on Experimental Frames
BehaviorRequirements at one or morelevels of SystemSpecification
Reference Master Model
Formalization by mapping into DEVS representationsCorresponding levels ofSystem Specification
Real-timeimplement-ation and execution
Simulation based testing in net-centric environment
Ideal Bifurcated Development Process
AV-1,2OV 1,5,6,2
Bifurcated Development Process in the DODAF/GIG Context
OV Activities classified into Activity Components
OV-3,8,9DEVS
Formalization
Activity characterizationand System scope refinement
Integrated Functionalities transported to System viewsusing:1. Model Continuity2. Web services3. COTS components
OV-7,4
Semi-automated test suite design based on NLspecified vignette scenarios
Simulation based testing using DEVSTest Federations
OV-8 information mapped to WSDL and vice versa. Any Web Service can become a component Activity of OV-8 and be constituted as a ‘functionality’ in DoDAF
WEB SERVICES
Model Design &Repository
Transfering DEVS-based Testing Methodology to SOA
DEVS Simulator
DEVS Model
Packaging:FOM
Messaging:Interactions,Updates
Communication: RTI
HLA
Service Discovery: UDDI
DEVS Simulator
DEVS Model
Sevice Description: WSDL
Packaging:XML
Messaging:SOAP
Communication: HTTP
SOA
Refining OV-6a (IDEF) to OV-8 (DEVS)
LOGIC CODE IN OV-6a (Rules of Engagement/Activation of further Activities done with boolean decision making)
IF Significant Movement of target Then Monitor Target/Target Status
Project Target Movement Target Vector = . . . .. ?
Else Monitor for Movement
•Inherent problems with IDEF process (&,||,!),•Timing, a critical factor in real-time decision making• unaddressed by CPNs, IDEF processes,
Automated Code generation of DEVS model thru OV-8
IDEF
DEVS
DEVS-based Web-Services Testing
GES DEVS Test Federation
LiveTest
Player
ServiceUnderTest
DEVS Simulator
Node
SOAP-XML
DEVS Test
Player