final_HLAPlusPrime_SOWRevised20180725.docx

Statement of Work Migration of Universal Cyber Physical System Environment Federation (UCEF) Platform to use Portico 2.2.0

I. Background The National Institute of Standards and Technology (NIST) has created a software platform that enables the co-simulation of Cyber-Physical Systems (CPS). This software platform features a simple graphical environment where a user can model interfaces between a set of interacting agents called federates, and a suite of code generation plugins that transform the models into executable code and simulations.

In the current version, there is support for code generation of Java, C++, and GridLAB-D federates with additional development efforts working towards the integration of LabVIEW and OMNeT++ federates. This platform, called the Universal CPS Environment for Federation (UCEF), will serve as an open-source environment that expedites development of complex experiments without the need for expertise in domain-specific simulators. Documentation on UCEF is available at https://pages.nist.gov/ucef, and the source code and build process is available at https://github.com/usnistgov/ucef.

The core of the UCEF workflow is a graphic design environment called the Web-based Generic Modeling Environment (WebGME). WebGME is an HTML5 development environment written in JavaScript used to design federates, federations, and experiments. A set of JavaScript code generation plugins, that rely on Embedded JavaScript (EJS) template files, transform the designs into Java and C++ source code. While a developer must still extend the source code with custom business logical to implement the functionality associated with a federate, the code generated stubs greatly reduce implementation time. For non-Java or C++ simulators, the code generation produces the required artifacts to bind the external simulation to the UCEF platform.

The code generated by UCEF relies on an open-source Java implementation of IEEE Standard 1516 High Level Architecture called Portico (https://github.com/openlvc/portico). However, UCEF currently implements an older version of the standard called HLA 1.3 1998, and the Portico team is preparing a summer release of a complete overhaul of their software called Portico 2.2.0. This solicitation seeks to upgrade the Java and C++ foundational code of UCEF to be compatible with both a subset of the services described in the latest version of HLA, and the Portico 2.2.0 libraries.

NIST has released a software library called UCEF Gateway (https://github.com/usnistgov/ucef-gateway) that provides a foundation that should be adapted to the revised Portico 2.2.0. This library simplifies the integration between HLA and simulators such as LabVIEW through implementation of boilerplate code necessary by all federates, and automatic construction of the object model by parsing an XML file called the Simulation Object Model (SOM). This architecture is shown in Figure 1.

Figure 1: Gateway Federate Architecture This development effort is expected to extend the gateway federate implementation to support additional HLA services, implement an equivalent gateway implementation for C++ federates, and port several existing federates from the old version of UCEF into the new code base. The implementation will resemble that shown in Figure 2.

Figure 2: Refactored Federate and Federation Manager In order to support network co-simulation, UCEF utilizes Omnet++, https://www.omnetpp.org/. The current implementation uses an adaptor federate, “mapper-federate” to convert standard HLA Interactions and Objects into “network packets” that can be injected or emitted from the Omnet++ simulator. It is desired to replace this mechanism with a run-time configuration option that allows a federate design to have it data exchange messages (not the HLA control messages) serialized and routed through Omnet++ rather than HLA. The goal is to allow federations to be composed entirely with HLA to be further studied with the addition of network co-simulation. A key requirement is that a tested federate does not need to be modified or recompiled to support this mode of exchange. The current Omnet++ federate implementation can be found in https://github.com/usnistgov/ucef-cpp/tree/develop/foundation/OmnetFederate.

II. Scope of Work The principle goal of this firm fixed price solicitation is to advance the UCEF tool suite by refactoring the underlying implementation of the HLA interface to:

1) Revise the UCEF Gateway to bind efficiently to the new version of the HLA Suite Portico 2.2.0; the federate ambassador end of this gateway should expose the services identified in the HLA standard under the sections for federation management, declaration management, object management, and time management. Callbacks should be easily configured for exposure at user application.

2) Make direct use of the simulation object model (SOM), an XML file defined in the HLA standard, to allow federates to be reconfigured without recompilation for minor changes in their interface (currently, all interfaces must be represented as Java/C++ classes and compiled into a runtime instance of a federate or federation manager).

3) Replicate the UCEF Gateway implementation in a C++ project to use in environments where C++ is the optimal development language.

4) Refactor the existing Federation Manager federate to use the Java version of the library (see https://github.com/usnistgov/ucef-core). This includes the COA component shown in the figure 2. This task will prune much of the existing code replacing it with the gateway component.

5) Optionally, refactor the existing OMNeT++ federate to support either HLA or the network simulator for data exchange, configured at runtime.

Some additional context for the scope of work:

How does the application interface work?

WebGME allows you to design the interfaces between federates – Interactions and Objects. Federates can publish and/or subscribe to these. For a Java Federate type, WebGME provides a code generation that produces a valid Java application project with these interfaces and all code necessary to run federates individually or in a federation. Technical Option 2 would extend the code generation to inherit from the classes in the ucef-gateway which a developer could then add behavior where appropriate. For C++ federates, a mirror of the java ucef-gateway will be constructed as task 3 with approximately the same interfaces, inheritance, and code template. For those federates for external solvers such as MATLAB, LabView, etc… the code generator produces artifacts needed by the wrapper and the solver model application. The wrapper code for the federate inherits from the ucef-gateway and adds a customized interface for the specific solver involved. This project only includes the creation of the gateway code that is the basis of the wrappers.

How does the COA interface work?

The COA is an experiment scripting language implemented as part of the Federation Manager code. It has the ability to add to the basic experiment orchestration performed by the Federation Manager federate – that of initiating the federation, waiting for required federates to join, marching logical time, …. COA adds the ability to monitor the federation’s messages and react and otherwise inject interactions according to the script. For example – start the experiment; wait 12 logical time steps; inject a setting change via an interaction injection.

How is Federation Manager different then federates code?

The federation manager is a federate that has been implemented to manage federation creation, synchronization, and experiment orchestration. It is desired to make the Federation Manager code as similar as possible to the federate code by refining as needed the ucef-gateway resulting from task 2. It can remove much of the existing code underlying the basic operation of the federation and binding to the RTI.

What is the intent of making federates use the SOM.xml as opposed to native classes based on the interactions and objects of the federate?

Particularly for solver wrappers based on ucef-gateway, it is desirable to use the same code for different federate models without recompilation of the wrapper. For example, for a MATLAB model, a SOM is required to design the interfaces to other federates and a wrapper code would provide a gateway between the MATLAB runtime and model and the federation. The wrapper would be designed once and used with SOM files matching the models being run on the solver.

What is required for the Omnet++ and Mapper Federate?

The Mapper Federate is a kind of federate that allows parameters to be reformatted from one interaction or object instance to another. For example, if one federate publishes a temperature in degrees F and another subscribes to it but needs degrees C, the mapper federate allows for this conversion. Omnet++ is a network simulator that allows the dimension of communications behavior to be imposed on a simulation. The current design which is to be preserved uses a version of the mapper federate to convert an interaction into a “network packet” form for use with Omnet++. The revised Omnet++ federate would use the new version of the ucef-gateway as its underlying binding to the RTI and be otherwise customized to the current wrapper federate code base behavior. Technical Option 1 revises the ucef-gateway so that at runtime via configuration change, specific interactions and objects can be routed through the Omnet++ network co-simulator instead of through the HLA RTI binding.

What are the requirements for the code releases?

We would require that the developer fork the ucef code bases and produce each release in a corresponding set of branches in the forked projects. The release should include unit and integration tests and instructions on how to run them. NIST would pull these branches into a corresponding set of branches in the ucef code base for eventual migration into the develop and release branches at the end of the project.

In Task 9, where do the code generation updates get modified?

The code generation templates for Java and C++ are part of the https://github.com/usnistgov/ucef-meta project. They make use of a templating language and are driven by JavaScript loaded by WebGME during the code generation procedure. Specifically, the files in https://github.com/usnistgov/ucef-meta/tree/develop/src/plugins/C2Federates/Templates/cpp , https://github.com/usnistgov/ucef-meta/tree/develop/src/plugins/C2Federates/Templates/java, and https://github.com/usnistgov/ucef-meta/tree/develop/src/plugins/DeploymentExporter/Templates need to be refined accordingly.

III. Specific Tasks and Performance Requirements The Contractor shall complete the following tasks:

Base Period Task 1: Attend a start-of-work meeting Requirement 1: The Contractor attend a Start of Work Meeting within one week of the start of the task order. This shall be done through a web-based meeting. At this meeting, the Contractor shall meet with the COR and NIST project leads to discuss the task order requirements, proposed project plan, including the Work Breakout Structure (WBS).

Deliverable 1a: The Contractor shall provide a preliminary project plan to the COR that addresses the requirements of the task order three (3) business day prior to the Start of Work meeting start of the task order.

Deliverable 1b: The Contractor shall provide a revised project plan one week after the Start of Work Meeting based on input from that meeting.

Task 2: Implement a Java library for Portico 2.2.0 that can be used to expedite the development of Java federates in UCEF Requirement 2a: The contractor shall implement a federate ambassador in the Java language for IEEE 1516-2010 High Level Architecture Evolved using the Portico 2.2.0 RTI based on the current implementation implemented by the UCEF Gateway. The produced federate ambassador must implement the services identified in the HLA standard under the sections for federation management, declaration management, object management, and time management.

Deliverable 2a: The Contractor shall provide a presentation (webinar) to the COR within the time period agreed in the revised project plan that demonstrates the fulfillment of Requirement 2a.

Requirement 2b: The contractor shall, in collaboration with the NIST technical lead and based on the current UCEF Gateway design, implement a Java base class that executes the complete life cycle of an HLA federate. This base class should use a configuration file and the federate ambassador from Task 2a to automate the process of joining a federation, synchronizing with the federation when necessary, making publications and subscriptions, and advancing logical time. It should have clear extension points for where a Java developer using the library would insert custom business logic to define federate behavior.

Deliverable 2b: The Contractor shall provide a presentation (webinar) to the COR within the time period agreed in the revised project plan that demonstrates the fulfillment of Requirement 2b.

Requirement 2c: The contractor shall implement a design for a Java class representation of HLA interaction classes and object classes. The design should define a one-to-one mapping from an interaction or object class to an equivalent Java class. The proposed design must be compatible with the deliverable from Task 2b, such that calling the public members of the Java class representation is sufficient to publish information to the HLA federation. The deliverable from Task 2b must not depend on these Java classes. The current gateway code supports a direct interface based on the SOM file, an XML file that follows the IEEE Standard schema. These new Java classes shall be designed so that they can directly utilize the Task 2b mechanisms. Additionally, the current gateway code utilizes a library with a dependency on lightly maintained org.eclipse.emf. Consider replacing this library code based on the https://github.com/FasterXML/jackson libraries already being used in much of the UCEF code.

Deliverable 2c: The Contractor shall provide a presentation (webinar) to the COR within the time period agreed in the revised project plan that demonstrates the fulfillment of Requirement 2c.

Requirement 2d: The resulting library should be sufficient to fully implement a compliant federate by adding business logic to a single file that inherits from the library and a SOM file that describes the interactions and objects exposed and consumed by the federate. A sample federate shall be constructed with appropriate “ToDo” comments to illustrate where a developer might add business logic.

Deliverable 2d: The Contractor shall provide a presentation (webinar) to the COR within the time period agreed in the revised project plan that demonstrates the fulfillment of Requirement 2d.

Task 3: Implement a C++ library for Portico 2.2.0 that can be used to expediate the development of C++ federates in UCEF

Requirement 3a: The contractor shall implement a C++ federate ambassador as defined in Requirement 2a.

Deliverable 3a: The Contractor shall provide a presentation (webinar) to the COR within the time period agreed in the revised project plan that demonstrates the fulfillment of Requirement 3a.

Requirement 3b: The contractor shall design and implement a C++ base class that executes the complete life cycle of an HLA federate as defined in Requirement 2b.

Deliverable 3b: The Contractor shall provide a presentation (webinar) to the COR within the time period agreed in the revised project plan that demonstrates the fulfillment of Requirement 3b.

Requirement 3c: The contractor shall implement a design for a C++ class representation of HLA interaction classes and object classes as defined in Requirement 2c.

Deliverable 3c: The Contractor shall provide a presentation (webinar) to the COR within the time period agreed in the revised project plan that demonstrates the fulfillment of Requirement 3c.

Task 4: Port existing Federation Manager code designed for HLA 1.3 using Portico 2.1.0 to use the Java libraries produced from Task 2

Requirement 4a: Implement a java Federation Manager based on the Task 2 library. It should include the use of the FOM.xml (This is a merge of SOM files for the individual federates). It shall implement the interface to COA library and refactor that as needed (this library currently requires the compiled in java classes that represent the interactions and objects published and subscribed by the federates). The library constructed in Task 2 may need to be enhanced for this purpose but it desirable to have the single version if practical.

Deliverable 4a: The Contractor shall provide a presentation (webinar) to the COR within the time period agreed in the revised project plan that demonstrates the fulfillment of Requirement 4a.

Requirement 4b: Implement a test federation that demonstrates the function of a Federation Manager that can be used in any federation and with any COA experiment configuration without the need to recompile the federation manager code itself.

Deliverable 4b: The Contractor shall provide a presentation (webinar) to the COR within the time period agreed in the revised project plan that demonstrates the fulfillment of Requirement 4b.

Task 5: Port existing Omnet++ federate using the library constructed in Task 3.

Requirement 5: Implement a C++ Omnet++ federate based on the Task 3 library and the existing C++ federate design Deliverable 5: The Contractor shall provide a presentation (webinar) to the COR within the time period agreed in the revised project plan that demonstrates the fulfillment of Requirement 5.

Task 6: Requirement 6: Provide documented source code developed to meet Requirements 1-5.

Deliverable 6: The Contractor provide the COR a compilation of documented source code developed to meet Requirements 1-5 within one week of the end of the period of performance of the task order.

Technical Option 1 Task 7: Extend the libraries produced from Task 2 and Task 3 to support an alternative configuration that sends all message traffic to the OMNeT++ network simulator.

Requirement 7a: The contractor shall design and implement a method that converts all message traffic produced by a federate into the interface expected by the OMNeT++ federate. This method should handle both conversion into an OMNeT++ style message, and the reverse process to convert from an OMNeT++ message into the format described in the federate’s interface.

Deliverable 7a: The Contractor shall provide a presentation (webinar) to the COR within the time period agreed in the revised project plan that demonstrates the fulfillment of Requirement 7a.

Requirement 7b: The contractor shall integrate the method produced from Task 5a into the classes produced from Task 2 and Task 3b as an option that can be configured at runtime. A federate should be able to switch between using a network simulator – or not – through a configuration change that does not require recompilation of the source code. And this configuration shall allow routing selection on a per-interaction/object instance basis.

Deliverable 7b: The Contractor shall provide a presentation (webinar) to the COR within the time period agreed in the revised project plan that demonstrates the fulfillment of Requirement 7b.

Task 8: Requirement 8: Provide documented source code developed to meet Requirement 7.

Deliverable 8: The Contractor provide the COR a compilation of documented source code developed to meet Requirements 7-8within one week of the end of the period of performance of the task order Technical Option 2 Task 9: Integrate the Java and C++ libraries produced from Task 2 and Task 3 into the UCEF code generation plugins

Requirement 9a: The contractor shall write Embedded JavaScript (EJS) templates for the Java and C++ code produced from Task 2 and Task 3 that is compatible with the UCEF code generation plugins.

Deliverable 9a: The Contractor shall provide a presentation (webinar) to the COR within the time period agreed in the revised project plan that demonstrates the fulfillment of Requirement 8a.

Requirement 9b: The contractor shall extend the JavaScript code generation plugins to integrate the new EJS templates into the UCEF workflow.

Deliverable 9b: The Contractor shall provide a presentation (webinar) to the COR within the time period agreed in the revised project plan that demonstrates the fulfillment of Requirement 8b.

Task 10: Requirement 10: Provide documented source code developed to meet Requirement 9.

Deliverable 10: The Contractor provide the COR a compilation of documented source code developed to meet Requirements 7-8within one week of the end of the period of performance of the task order IV. Deliverables and Deliverable Due Dates

Final project plan to the COR that addresses the requirements of the task order MS Word via email

MS Word via email

No later than 3 days before the Start of Work meeting

1 week after the Start of Work meeting

Within the time frame developed in the revised project plan

Within the time frame developed in the revised project plan

Within the time frame developed in the revised project plan

Within the time frame developed in the revised project plan

Within the time frame developed in the revised project plan

Within the time frame developed in the revised project plan

V. Performance Requirement Summary

for timeliness, completeness, accuracy, clarity, conciseness, relevance, and provide comments.

for timeliness, completeness, accuracy, clarity, conciseness, relevance, and provide comments.

Standards for Acceptance of Deliverables:

Standards for Acceptance of Deliverables: The Contracting Officer's Representative (COR) will provide comments on each deliverable within 5 business days from receipt of a given deliverable. The Contractor shall make any needed changes to the deliverables within 5 business days from receipt of electronic or written comments from the COR.

VI. Period of Performance The period of performance will be nine (9) months ARO.

VII. Place of Performance and Government Furnished Equipment (GFE) Performance will be at the Contractors facilities. No GFE will be provided.

VIII. Travel

No travel is anticipated.

IX. Contractor’s Minimum Qualifications

· An intimate knowledge of IEEE 1516 HLA Evolved and the architecture and design of Portico.

· Experience in Java and C++ development

· Experience in development and source control on GitHub image1.png image2.png