Standards Conformance Testing and MS Web Services Bernard

Standards Conformance Testing and M&S Web Services Bernard P. Zeigler, Ph. D. , Arizona Center for Integrative Modeling and Simulation and Joint Interoperability Test Command Fort Huachuca, AZ 85613 -7051

Outline • Role of Standards Conformance Testing in Net-Centric T&E – – JITC responsibility for Link-16 standards conformance testing Link-16: Challenges to implementation and testing M&S–based Automated Test Case Generation Application to Link-16 in the IABM SIAP Context • Service Oriented Architecture: M&S-based Testing Services – Link-16 standards conformance testing – certification for GIG deployable services – exposing M&S-based T&E assets as services

Net-Centric Test and Evaluation: Some Assertions Net-Centric T&E • places an increased emphasis on standards conformance testing (SCT) – – • performed on distributed net-centric test-bed infrastructure – – • SCT will be the first gate before more extensive T&E necessary, but not sufficient, for interoperability and mission effectiveness Global Information Grid (GIG) provide on-site or downloadable SCT packages emphasizes services rather than systems – testing of Service Oriented Architecture (SOA) – GIG enterprise services

JITC is the Responsible Test Organization for Tactical Data Link Standards • Joint Interoperability Test Command (JITC) is responsible for ensuring systems that implement Tactical Data Link* (TDL) – 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 11/11 B/16 and Variable Message Format (VMF)

Link-16: Challenges to Implementation and Testing Joint Single Link Implementation Requirements Specification JSLIRS is an evolving standard (MIL-STD-6016 c) 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

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

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. source: 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 • First major test of IABM – Config 05 – ATC-Gen is the basis for testing link-16 and extended IABM requirements

Discrete Event Nature of Link-16 Specification Transaction Level - example P. 1. 2 = Drop Track Transmit 1 Preparation Constraints (Exception) Rules 2 Processing Rule Processing Modify C 2 Record for TN 3 Transmit Msg Validity checking Track Display Time outs Operator decisions Periodic Msg Other Consequent. Processing Stop, Do Nothing, Alerts, Or jump to other Transaction Jumps (stimuli) to other Transactions of specification Output from Input to system DEVS t 1 t 2 t 3 t 4

ATC Gen Goals & Approach Goals: • To increase the productivity and effectiveness of standards conformance testing (SCT) at Joint Interoperability Test Command (JITC) • To apply systems theory, modeling and simulation concepts, and current software technology to (semi-)automate portions of conformance testing Objective: Automate Testing Capture Specification as If-Then Rules in XML Analyze Rules to Extract I/O Behavior Synthesize DEVS Test Models Test Driver Executes Models to Induce Testable Behavior in System Under Test (SUT) Interact With SUT Over Middleware Test Driver DEVS Simulator SUT HLA Network

ATC Gen Tool • Standard to XML Translation – Analyst interprets the requirements text to extract state variables and rules, where rules are written in the form: If P is true now Condition Then do action A later Consequence Unless Q occurs in the interim Exception • Dependency Analysis & Test Generation – Dependency Analyzer (DA) determines the relationship between rules by identifying shared state variables – Test Model Generator converts Analyst defined test sequences to executable simulation models • Test Driver – Test Driver interacts with and connects to SUT via HLA or Simple J interfaces to perform conformance testing – Validated against legacy test tools

Capturing the Link-16 Standard in XML Repository Appendix P Appendix U Section 4. 11. 13 Appendix D MIL-STD-6061 C XML FILES

Rule Analysis Extract I/O Behaviors Appendix P Appendix U Section 4. 11. 13 Appendix D MIL-STD-6061 C RULE ANALYSIS RESULTS

Test Sequence Manually Derive & Create Paths Automatic Generation of Path File (Text) Responder. Nnot specified> D. 1. 3. 1. 9 ND. 1. 3. 1> D. 1. 3. 3. 10. 1 a, D. 1. 3. 3. 1 ND. 1. 3. 1> D. 1. 3. 12. 1 ND. 1. 3. 1>

Test Sequence Validation & Generation Completed Path File Repository Appendix P Appendix U Section 4. 11. 13 Appendix D XML FILES DEPENDENCY ANALYZER Validates Test Sequence GENERATED TEST SEQUENCE (XML)

Test Case Generation Test Sequence with Assigned Values TEST CASE GENERATOR GENERATED TEST CASE (XML)

Test Model Validation & Generation Test Case TEST MODEL GENERATOR GENERATED TEST CASE MIRROR (XML) Test Model #include "hier. Sequence. h" #include "PPLI. h" #include "Remote. TNdrop. h" const port_t hier. Seq. Digraph: : start=0; hier. Seq. Digraph: : in. Jmsg=1; hier. Seq. Digraph: : pass=2; hier. Seq. Digraph: : out. Jmsg=3; hier. Seq. Digraph: : hier. Seq. Digraph(): static. Digraph() { PPLI *pp = new PPLI(); add(pp); couple(this, this->start, pp->start); couple(pp, pp->out. Jmsg, this->out. Jmsg); Remote. TNdrop *p 1 = new Remote. TNdrop(); add(p 1); couple(this, this->start, p 1 ->start); couple(this, this->in. Jmsg, p 1 ->in. Jmsg); couple(p 1, p 1 ->out. Jmsg, this->out. Jmsg); }

Test Model Execution Test Model (C++) #include "hier. Sequence. h" #include "PPLI. h" #include "Remote. TNdrop. h" const port_t hier. Seq. Digraph: : start=0; hier. Seq. Digraph: : in. Jmsg=1; hier. Seq. Digraph: : pass=2; hier. Seq. Digraph: : out. Jmsg=3; hier. Seq. Digraph: : hier. Seq. Digraph(): static. Digraph() { PPLI *pp = new PPLI(); add(pp); couple(this, this->start, pp->start); couple(pp, pp->out. Jmsg, this->out. Jmsg); Remote. TNdrop *p 1 = new Remote. TNdrop(); add(p 1); couple(this, this->start, p 1 ->start); couple(this, this->in. Jmsg, p 1 ->in. Jmsg); couple(p 1, p 1 ->out. Jmsg, this->out. Jmsg); } TEST DRIVER SYSTEM UNDER TEST

Extending M&S-Based T&E to the GIG • Migrate ATC-Gen capability to the GIG-SOA – accessible to all developers requiring Link-16 conformance testing and certification – enable self-tests for Link-16 standards conformance – expose Link-16 XML-rule repository as authorized reference model – register ATC-Gen test capabilities as web services • Extend M&S-Based automated testing – provide mission thread testing for GIG deployable services – certify transitions through the stages of DISA’s Federated Distributed Certification Environment • Expose M&S-based T&E assets as services – experimental frame components: generators, acceptors, transducers – exploit DEVS reusability support – characterize services for discovery and reuse

Link-16 XML Repository Web-Service Asset • Organized according to MIL-STD-6016 C macro-structure hierarchy • Folders store aggregations/abstractions of lower level rules • MIL-STD-6016 C Reference Model – 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

Transferring DEVS-based Testing Methodology to SOA • • • DEVS-based Testing Methodology readily migrates to SOA environment as shown below In particular, the ATC-Gen Test Driver can be offered as a service for Link-16 conformance self-test Further, the methodology can be applied to other test and evaluation contexts DEVS Model DEVS Simulator HLA Packaging: FOM Messaging: Interactions, Updates Communication: RTI SOA Service Discovery: UDDI Sevice Description: WSDL Packaging: XML Messaging: SOAP Communication: HTTP

Automating Mission Thread/Vignettes for GES Testing • Objective – automate to the maximum extent the definition of mission threads/vignettes and the generation of test services based on them • Enable COI and community wide service users and developers to easily write threads/scenarios in (restricted) Natural Language form • Interacting with such users/developers, implement these scenarios with DEVS test federation models that can execute over Core ES • Mission thread/Vignette scenario testing applies objectives-driven testing to all service levels and throughout service offering life cycle • Repository can support re-use and re-application for regression testing to preserve service behavior under continual change in SOA environment

Mission Thread Testing Applies to all Service Levels and Throughout Service Offering Life Cycle Mission Threads enable objectives driven testing at every development level Community-wide Enterprise Services COI Enterprise Services CORE Enterprise Services Mission Threads enable objectives driven testing throughout service offering life-cycle

NLP Mission Thread Scenario Generation JTAC working with Fourth. Inf. Div …. … USNAircraft gets deconfliction from USMCAircraft Natural Language Parser Restricted Natural Language form of Mission Thread Scenario Specification Transform to System Entity Structure Scenario in XML (actor = JTAC, action = work, actee = Fourth. Inf. Div) …. (actor = JTAC, action = requests, message = Immediat. CAS, actee = Direct. Air. Supp. Airborne) …. Transform to DEVS Parser outputs tagged equivalent of input DEVS Test Driver for NCES Mission Threads

Example: Joint Close Air Support Scenario JCAS JMT Operational Scenario #1 A. Special Operations Force (SOF) (AFSOC and NSW) JTAC working with Operational Detachment-Alpha (ODA) is tasked to request Immediate CAS on a stationary mechanized target in mountainous terrain. A Predator unmanned aerial vehicle (UAV) is on station for support. B. SOF JTAC contacts AWACS with request. AWACS passes the request to Special Operations Liaison Element (SOLE) in the Combine Air Operations Center (CAOC). C. Joint Special Operations Task Force (JSOFT) approves the request and CAOC assigns a section of USMC F/A-18 Ds, F-15 Es, and a single B-1 B. Ordnance consists of 20 mm, Joint Direct Attack Munitions (JDAMs), and Laser Guided Bombs (LGBs). D. Aircraft get situational brief from AWACS aircraft while in route, then switch to SOF JTAC for Terminal Attack Control and deconfliction from orbiting UAV. A 9 -Line brief will be given to each section/single aircraft. JTAC will continue to execute CAS missions until all weapons are expended.

NLP Test Generation Example: Joint Close Air Support Scenario JTAC works with ODA! JTAC is supported by a Predator! JTAC requests Immediate. CAS to AWACS ! AWACS passes request. Immediate. CAS to CAOC! CAOC assigns USMCAircraft to JTAC! CAOC sends ready. Order to USMCAircraft ! USMCAircraft sends sit. Brief. Request to AWACS ! AWACS sends sit. Brief to USMCAircraft ! USMCAircraft sends request. For. TAC to JTAC ! JTAC sends TACCommand to USMCAircraft ! USMCAircraft sends deconflict. Request to UAV! USMCAircraft gets target. Location from UAV!! NCES

DEVS-based Web-Services Testing DEVS Test Player Service Under Test NCES/GIG Live Test Player SOAPXML DEVS Test Federation DEVS Simulator Node

Demo: http: //acims 9. acims. arizona. edu JCAS JMT Operational Scenario #1 A. Special Operations Force (SOF) (AFSOC and NSW) JTAC working with Operational Detachment-Alpha (ODA) is tasked to request Immediate CAS on a stationary mechanized target in mountainous terrain. A Predator unmanned aerial vehicle (UAV) is on station for support. B. SOF JTAC contacts AWACS with request. AWACS passes the request to Special Operations Liaison Element (SOLE) in the Combine Air Operations Center (CAOC). C. Joint Special Operations Task Force (JSOFT) approves the request and CAOC assigns a section of USMC F/A-18 Ds, F-15 Es, and a single B-1 B. Ordnance consists of 20 mm, Joint Direct Attack Munitions (JDAMs), and Laser Guided Bombs (LGBs). D. Aircraft get situational brief from AWACS aircraft while in route, then switch to SOF JTAC for Terminal Attack Control and deconfliction from orbiting UAV. A 9 -Line brief will be given to each section/single aircraft. JTAC will continue to execute CAS missions until all weapons are expended. Web Service: Find aircraft available for CAS given coordinates and time frame.

M&S-Based T&E Services on the SOA: Experimental Frame Repository • Compose EF from generator, acceptor, and transducer components in repository • Characterize functionalities using M&S Theory and WSDL • Support composability based on migration of DEVS technology to SOA SUT Generator Acceptor Transducer Experimental Frame Request Generator Repository Acceptor Repository Transducer Repository

Example: Synthetic Environment Repository Experimental Frames needed for Testing Objectives Experimental Frame Partial Order Experimental Frame- Model Applicability Relations Environmental and Standards Reference Models available for use in Testing

Summary and Conclusions There is an acute need for a new Net-centric testing paradigm at the enterprise level where joint and coalition operations are conducted (Editorial, ITEA Jnl, Sept, 2005) • Net-Centric T&E places an increased emphasis on standards conformance self-testing over the GIG-SOA and emphasizes services rather than systems • Due to its formal and abstract basis, the DEVS functionality migrates quite directly to execute over the web-services middleware based on XML and SOAP • This extension enables semi-automated construction of DEVS test federations for verification testing of a wide variety of proposed web services: – ATC-Gen Link-16 and other TDL standards conformance self testing – Mission thread or vignette scenario specification using natural language input can replace Link-16 style standards formalization as the source input for test case generation • M&S-based T&E services can exploit experimental frame methodology

Contact: Bernard P. Zeigler zeigler@ece. arizona. edu More information: ACIMS www. acims. arizona. edu JITC jitc. fhu. disa. mil

Joint Interoperability, Assured Security, Best Value, Customer Success Global Net-Centric Solutions -- The Warfighter's Edge