PERFORMANCE_WORK_STATEMENT.pdf

Performance Work Statement (PWS) HLAPlus

I. Background:

NIST is assembling a test bed for the purpose of doing research on Smart Grid and Cyber- Physical systems (SG/CPS Testbed). A key component of this testbed is a platform that enables federated experiments.

A federated experiment consists of reusable software and hardware components called federates that are combined into a larger federation to perform some useful experiment. A federate could be a piece of equipment or a simulation model, and can be located anywhere such as on a local machine, in the cloud, or at geographically dispersed test facilities.

The NIST Smart Grid/CPS Office is working with an open source tool suite that can graphically model federate I/O and generate source code and build files for a federate based on its graphical representation. The generated source code may be standalone or it may have additional hardware or software dependencies that must be resolved prior to deployment. In addition to federate source code, our tool suite can also generate experimental configurations which script the runtime behavior of federates and include deployment information such as where the built executable for each federate should be run. The following illustration shows the tool suite and its generated products:

NIST calls this federated testbed architecture “UCEF” for Universal CPS Environment for Federation. UCEF, at its heart, utilizes an open-source implementation of IEEE 1516-2010 HLA for communications. This implementation is called Portico (https://github.com/openlvc/portico).

While Portico provides the basic services of Federate coordination and messaging, we have found that there are several scalability, security, and performance issues with the current

Virtual Machine

Experiment Configurations

HLA Application Implementations

HLA BUS

Deployed Federate

Deployed Federate

Federation Manager…

D ep lo ym en t E nv iro nm en t

Application Data FileKey:

code stub

Federate Types (HLA Wrappers)

Existing Applications

Implementation Environment

Federate Descriptor

WebGME

Federate Interfaces https://github.com/openlvc/portico) implementation for our intended use that we would like to enhance. NIST refers to the outcome as HLAPLus.

The requirements seek to enhance or replace the current Portico version (2.1.0) with extensions as means of realizing HLAPlus. The resulting extensions/replacement shall be provided as open source per an Apache 2.0 license or equivalent. Ideally these would be implemented as extensions that are part of the existing portico project or a fork of that project.

Scope of Work

The contractor shall broadly add the following features (with typical examples in the sub-bullets):

Required Behavior:

1) Compliance with the HLA Evolved version of the standard IEEE 1516 2010.

2) Support for the subset of HLA services currently available in version 2.1.0 of Portico.

Enhancements:

1) Communication between federates using a secure Point to Point connected protocol

a. Binary transport protocol

b. Federates only receive messages to which they subscribe. Federates only propagate messages to their subscriber federates.

c. Data in transit is encrypted using PKI and authorized via an access token included in the message to facilitate Role Based Access Control.

2) Situational awareness of federates

a. Federates can retrieve data type information for objects and interactions at runtime.

b. Federates can query themselves and each other about their active publications, subscriptions, and relationships with other federates at runtime.

3) Improved conformance to the HLA standard

a. Support the standard XML format for the federation object model (FOM) -https://www.sisostds.org/schemas/IEEE1516-OMT-2010.xsd.

b. Support for the request and report interaction classes defined in the management object model (MOM).

Specific Tasks and Performance Requirements

The contractor shall perform the following tasks:

1. Meet with NIST and other implementers at a series of one or two meetings to participate in discussions to solidify design requirements needed to resolve software dependencies.

Meetings can be web-based, or if contractor is local, at the NIST Gaithersburg campus.

2. Develop enhancements 1), 2), and 3) above.

https://www.sisostds.org/schemas/IEEE1516-OMT-2010.xsd

II. Deliverables and Deliverable Due Dates:

Standards for Acceptance of Deliverables: The Contracting Officer's Representative (COR) or Technical Point of Contact (TPOC) will provide comments on each deliverable within five (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.

Task Requirement Deliverable Due Date 1 Determine software requirements to resolve dependencies

Description of requirements, solutions and a Project Plan with proposed Work Break Down Structure

(WBS)

Within one week after the requirements determination meeting, the Contractor shall provide a Draft Project Plan.

2 Develop and demonstrate solutions that meet requirements

(a) Develop and demonstrate a specific solution that meets the identified requirements. (b) Document the solution in a 5-page paper.

Due by the agreed-upon WBS, but no later than two weeks before the end of the contract. The COR will review the solution and document and provide feedback within five (5) business days; the Contractor shall have five business days to address any comments.

3 Final Documentation

Provide a compilation of all documents related to the Contract including source code, test code, description paper (from 2b)

Due within three (3) weeks of the last day of the period of performance.

4 Source code Develop and demonstrate source codes that meet the identified requirements.

Due by the agreed-upon WBS, but no later than two weeks before the end of the contract.

III. Period of Performance:

The period of performance shall be one year from the date of award.

IV. Place of Performance and Government Furnished Equipment (GFE):

The Contractor’s Performance shall be at the Contractor’s facilities. No GFE will be provided.

V. Travel:

No travel is anticipated. Meetings shall be web-based unless the contractor is local, in which case, they can chose to come to the NIST Gaithersburg campus.

VI. Key Personnel:

Contractor’s Key Personnel shall meet the following minimum qualifications:

• Senior software developer with the following qualifications:

o Familiarity with the IEEE HLA-evolved standard o Familiarity with the Portico Project and source code o MS in Computer Science, Computer Engineering, or equivalent experience.

VII. Quality Assurance Plan:

I. Objective: The purpose of this plan is to provide a quality surveillance plan for the tasks performed in this PWS. This plan provides a basis for the COR to evaluate the quality of the Contractor's performance. The oversight provided for in this contract and in this plan will help to ensure that service levels reach and maintain the required levels throughout the contract term.

Further, this plan provides the COR with a proactive way to avoid unacceptable or deficient performance, and provides verifiable input for the required annual past performance evaluations.

II. Performance Standards:

A. Quality Level: By monitoring the Contractor, the COR will determine whether the performance levels set forth in the PWS have been attained. Quality standards (i.e., performance standards) for all tasks are specified in the Performance Requirements Summary.

B. Frequency: During performance of this PWS, the COR will take periodic measurements (i.e., conduct surveillance), as specified, and will analyze whether the frequency of measurement is appropriate for the work being performed.

C. Management Responsiveness: The COR will determine whether the Contractor has managed the contract effectively and efficiently, as specified in the performance standards set forth in this PWS. The COR will confirm whether the Contractor has satisfactorily met all reporting requirements, including subcontracting reports when applicable.

III. Evaluation Methods:

The COR will conduct performance evaluations based upon Section II above and the required performance levels set forth in the Performance Requirements Summary found in the following section. The following techniques will be used to perform surveillance:

A. Analysis/Visual Review of Completed Deliverables. The COR will perform a visual review of Contractor work for accuracy and completeness.

C. Review of the timeliness of completion of tasks

VIII. Performance Requirements Summary:

Desired Output Required Service Performance Standard Monitoring Method Determine software requirements to resolve dependencies.

Description of requirements, solutions and a Project Plan with proposed the WBS.

Project Plan and Work Breakout Structure addresses the PWS requirements in a timely and effective manner; requirements are meaningful, achievable, and reflect the scope of work

Documentation will be reviewed by the COR for completeness, timeliness, and effectiveness.

Develop and demonstrate solutions that meet requirements.

(a) Develop and demonstrate a specific solution that meets the identified requirements.

(b) Document the solution in a 5-page paper.

(a) The demonstration accurately shows the operation of the development project.

(b) Contents of the document are complete, accurate, and directly related to the identified requirement.

Documentation and software will be reviewed by the COR for pertinence to the requirements, and to support that they are delivered completely, accurately, and on time.

Final Documentation.

Provide a compilation of all documents related to the Contract.

Contents of the summary are complete, accurate, and relevant

Documentation will be reviewed by the COR for relevancy and to support that they are delivered completely, accurately, and on time.