VICTORY-Training-20220617-Dist-A-A1027.pdf

APPROVED FOR PUBLIC RELEASE

VEHICULAR INTEGRATION FOR

C4ISR/EW INTEROPERABILITY (VICTORY)

TRAINING COURSE

Updated 17 June 2022

MOSA Management Office

DEVCOM C5ISR Center

INITIATIVE BACKGROUND & OVERVIEW

Motivation: problems driving VICTORY

Approach: how we are moving toward a solution

VICTORY Framework Products: what we are producing

VICTORY process and organizational overview

An Army SoS Problem: C4ISR/EW Integration in Ground Platforms

“Bolt On” Mission Equipment Integration VICTORY Data Bus enables interoperability across

C4ISR/EW and platform systems

MTS

FBCB2/JBC-P

GPS

GPS

MTS

FBCB2/JBC-P

GPS

Shared PNT

Threat Reports

Video Display

EW Interface

Audio Alarms

Platform to host

SW Products

VICTORY ApproachTraditional Approach

1) Reduces SWaP-C impact of GFE/TPE over time

2) Enables new capabilities through interoperability:

systems share data and are managed via a vehicle network – the VICTORY Data Bus (VDB)

3) Enables commonality: common specifications, software and hardware

VICTORY Benefits

• Support overall DoD Modular Open System Approach (MOSA) philosophy

• Enable interoperability between systems on the vehicle

– Eliminate, where possible, the practice of “Bolt On” systems

– Support new capabilities

• Support current & future IA/Cyber requirements

– Enable “defense in depth” security designs

– Support many IA/Cyber requirements and levels

• Significantly reduce SWaP-C required for GFE and TPE

• Integrate with current-force systems

– Define a path toward network-centricity

• Reduce overall life cycle costs of the integrated system (by enabling competition for sub-systems and for integration)

• Maximize C4ISR/EW portability

VICTORY Goals

• VICTORY provides enablers to enhance integration and interoperability between electronics systems on Army ground vehicle platforms

– Enables integration of C4ISR/EW systems

• Interface to the sensors, many components and systems

– Enables interfaces (bridges) to platform systems

• Interface to platform systems

• Scope / boundaries of the current VICTORY initiative

– Stops at the edge of the platform in-vehicle network

• Interface to satellite, terrestrial, dismounts, mobile sensors

• Interface to data/voice radio

– Stops at the edge of platform systems

• Interface to automotive, weapons, power distribution, logistics, protection

– Does not integrate safety critical systems

– Does not define common physical components or software applications

VICTORY Scope

• Add a data bus (network) to vehicles

– Integrate C4ISR/EW systems, interface with other electronic systems

– Provide the plumbing for systems and components to interoperate

• Provide shared hardware and services as part of the data bus

– Shared processing and user interface hardware

– Shared services

• Management: configuration, control, health reporting

• Position, orientation, direction of travel

• Define components with standard, open network-based messaging interfaces

– IA/Cyber components: protect data & control access

– C4ISR/EW components: interoperate via network messages

– Platform systems: interface with VDB via network messages

Technical Approach

These ideas have been emerging organically. However, a COMMON, OPEN approach is crucial to long-term success for the Army.

• Specify “on-the-wire” network-based interfaces

• Mature specifications into standards

– Validate the architecture & standards through experiments

– Prove that architecture and standards are reasonable and effective

• Keep specifications open to the ground vehicle community

• Treat Information Assurance (IA) and Cybersecurity as part of core design

• Keep time critical processing integrated with sensors

– Publication on data bus can be secondary (e.g., high-rate video)

• Enable open competition

• Identify roadmap from current to future architectures

– Include current-force systems in the architecture

– Evolve toward network-centric C4ISR/EW

Architectural Tenets

VICTORY is not about new technology. It is about adding in-vehicle networks to vehicles, and agreeing upon open specifications for interfaces.

1) Not controlled by a single vendor

2) Not tied to a specific vendor’s platform (platform independent)

3) Available for implementation by multiple sources

4) Usable without royalties or non-disclosure agreements (NDAs)

5) Published and managed by a standards body

VICTORY Definition of Open

“Open” places power in the procurement process with the Army

Standardized

Published Freely By Vendor

Published by Vendor w/ NDA

Not Published

Physical (phy/mac)

Transport (datalink/network/transport)

Application (data format/protocol)

Open

NOT

Open Minimum entry to be

OPEN

VICTORY

End State

• Interoperability: the ability for entities developed by different organizations, and perhaps in different contexts, to be composed into systems in which the overall requirements are met through the exchange of data and coordination between the components

– Is this achievable? How close can we get?

• Open interfaces alone do not achieve interoperability

• Interface control documents (interface specifications), even if clear and non-ambiguous, do not guarantee interoperability

• Standards (formally accepted interface specifications) are an enabler

• The weak link is the human interpretation of documents

• Pathway to achieving interoperability, and less integration effort

– Open standard specifications + formalized, machine readable acceptance criteria (test procedures), supported by tools available across the community to evaluate and document compliance early in the process

Achieving Interoperability

• Architecture

– Version A (April 2019)

• Standard Specifications

– V1.9 (April 2021)

• Initial Validation Artifacts

– Published as completed

• Compliance Test Suite

– Test Plans & Test Report Templates published as completed

– Compliance Test Tool (CTT) V3.4.2 (June 2022)

• Reference Designs

– Provided as needed

• Reusable Software

– VSSO: Reference Software Library (Implements CT specs & tested for compliance)

– DEVCOM GVSC: libVICTORY

• Public Releasable Version:

– Architecture (Version A)

– Standard Specification (V1.9)

– Compliance Test Suite (pending)

VICTORY Framework Products

Terminology

• “Architecture”: a conceptual framework defining overall concepts and terms, identifying elements to be standardized, including component types, their interfaces, design patterns, and common structures

• “Specifications”: a document containing specifications of varying maturity levels, which identify the technical details of system (application) and component interfaces

• “Reference Designs”: documents describing how the specifications could be deployed

• “Standard”: a specification at the “proposed standard” or higher level of maturity

• “Maturity level”: a label that identifies the level of maturity of a specification, which varies over time. Maturity levels include:

– Preliminary

– Informational

– Experimental

– Proposed Standard

– Draft Standard

– VICTORY Standard

VICTORY specifications document:

• Versioned [major].[minor] (e.g., 1.0)

• Aggregates many specifications

• Each specification has an independent maturity level

Specification Types include:

• Component Type Specifications

• Interface Specifications

• Application Profile Specifications

• VICTORY standard specifications are organized into a hierarchical structure

• A “Component Type” is a collection of interfaces

Structure of VICTORY Standard Specifications

VICTORY implementation and compliance verification are based on Component Types, not on document version

• VICTORY has a formalized government structure that has

– Defined open standard interface specifications for data exchanges and management operations

– Defined an open network-based architecture that includes an in-vehicle networking (VDB) on vehicles to act as plumbing (with required HW and shared data and services) for systems to interoperate

– Used a bottoms-up approach for specification development with a Gov’t and industry Standards Body

– Matured standard specifications through a validation process

– Developed useful artifacts that supports implementation by programs and industry vendors

• By implementing VICTORY, ground platforms will now be able to

– Reduce size, weight, and power claims of future C4ISR/EW systems

– Enhance interoperability with shared services and data between systems

– Deploy new technologies more rapidly

– Reduce time and cost to integrate electronics systems

– Automate many processes that are currently manual (logistics)

– Support current and future information assurance requirements

Review – Big Picture

• MMO is actively working with acquisition programs on implementing VICTORY standard specifications into ground vehicle platforms and mission equipment components

• Please join the VICTORY Subcommittee (VSC) in the SOSATM

Consortium if you’d like to contribute to the VICTORY standards

– SOSA: https://www.opengroup.org/sosa

• For more information:

– VICTORY Publicly Release Documentation

• SAM.gov: https://sam.gov/opp/889a0f920a5f4e8db99b9ee5d35d329c/view

• JCM: https://jtnc.experience.crmforce.mil/JTNC/s/cmoss

– VICTORY Restricted Documentation

• SOSA Program on VDL (coming soon)

Conclusions https://www.opengroup.org/sosa https://sam.gov/opp/889a0f920a5f4e8db99b9ee5d35d329c/view https://jtnc.experience.crmforce.mil/JTNC/s/cmoss

ARCHITECTURE CONTENTS

• Network infrastructure: Ethernet-based vehicle network with specific routing and QoS choices

• Shared PNT: PNT data from common devices shared on VDB

• Recording & Logging: capability to store network data for post-mission use

• System Management: configuration, control, health management of VDB, systems, and applications

• Information Assurance: built-in access control, data protection

Core Concept: VICTORY Data Bus (VDB)

• VDB is an “in-vehicle network” with built-in features to advanced interoperability in ground vehicles

• VDB connections: vehicle network is to be connected to electronic systems

• C4ISR/EW systems: VDB integrates these, interfaces at component level

• Platform systems: VDB “bridges” to these, interfaces at system-level

• Systems without Ethernet are adapted (native port to SPU plus conversion SW)

Core Concept: VICTORY Data Bus (VDB)

• Transport: communication functions from the transport layer and lower, including the data formats, protocols, signaling, and perhaps physical media specifications (routing data w/QoS)

• Data: data definitions, message formats, encapsulation methods, and transport choices for publishing data on the VDB (publish-subscribe)

• Management: data definitions, message formats, and behaviors for configuration, control, and health functions (command-response)

• Health Reporting: data definitions, message formats, encapsulation methods, and transport choices for health publishing (publish-subscribe)

• Access Control: protocols used for protecting access to data and other interfaces (Attribute Based Access Control model)

• Auto-discovery: protocols for automatically identifying components at runtime on the VDB

• Application Program Interface (API): properties and resources of the runtime system that will host software (minimal approach; libraries, runtime elements)

Kinds of VICTORY Interfaces

• Transport:

– Ethernet and TCP/IP

• Data – VICTORY Data Message (VDM):

– XML application layer payload encapsulated in a VDM-specific binary header

– Multicast UDP provides a simple publish/subscribe paradigm

• Management:

– Simple Network Management Protocol (SNMP) for network infrastructure

– SOAP-based web services for everything else

• Health Reporting:

– SNMP for network infrastructure

– Syslog over Multicast UDP for everything else

• Access Control:

– Confidentiality & Integrity: TLS for management, IPsec for data

– Authentication: Password, SAML, PKI, or biometrics

– Access Control: ABAC based on SOAP, SAML, and XACML

• Auto-discovery:

– Zero Configuration Networking (Zeroconf) including mDNS and DNS-SD

• Application Program Interface (API):

– Low-Level: Qt, libBoost, POSIX

– Mid-Level: Java VM

Summary of VICTORY Technologies

• Architecture consists of a set of component types

– Organized into hierarchical “capability groups” for convenience

– Grouping does not imply “class hierarchy” or “inheritance”

• Top-level grouping

– VDB component types

– Information Assurance component types

– C4ISR/EW systems and component types

– Platform system types

• Following slides walk through these groups, and provide examples

VICTORY Architecture Composition

VDB Component Types

VICTORY Data Bus Architecture

Infrastructure Switch

Low Latency Switch

Generic End Node

Shared Processing Unit

Network Attached Storage

Direct Attached Storage Encryption Management Interface

Shared PNT Time Synchronization Service

Position Service

Orientation Service

Direction of Travel Service

GPS Receiver

Assured PNT

System Management VDB Management Service

VICTORY Configuration Language Instance Document

Recording & Logging Mission Recorder

Data Logger

Infrastructure Component Types

Switch

Low Latency Switch

Generic End Node

Shared Processing Unit

Network Attached Storage

Direct Attached Storage Encryption Management Interface

Shared PNT Component Types

Time Synchronization Service

Position Service

Orientation Service

Direction of Travel Service

GPS Receiver

Assured PNT

• Infrastructure types generally imply hardware to support their functions

• The functions can be grouped into combinations in a single “box”

– Example 1: Time, Position, Orientation, Direction of Travel, GPS Receiver, Assured PNT

– Example 2: SPU, GEN, access control services, VDB System Management component types (see later slides)

Infrastructure and Shared PNT Component Types

System Management VDB Management

Service

VICTORY Configuration Language Instance Document

Recording & Logging Component Types

Mission Recorder

Data Logger

• VDB Management Service

– Configure, control, and manage health (status and faults) of VDB as an aggregate

• VICTORY Configuration Language Instance Document (VCLID) describes the configuration of the system

– Sections describe the VDB, IA, C4ISR/EW systems, and platform systems configuration

• Facilitates automated management of the vehicle network and integrated electronics

• Recording & Logging component types responsible for storage of network data for playback or bulk retrieval at a later time

– Defines interface for configuring and controlling network recording

– Defines a playback interface

– Includes common interfaces

System Management and Recording & Logging Component Types

• Position service has four interfaces

– Position data interface: Publishing position messages

– Position management interface:

• Configuring and controlling the service and its interfaces

• Requesting current data

– Health publishing interface: Publishing status and faults of the service

– Auto-discovery interface: Finding the service on the VDB

• This service publishes position, and is not specific to GPS

– See “GPS Receiver” component type

• For reference, the “spec table” for Position Service CT is:

Example Component Type: Position Service

Position Service <VT50100-V1.9> Spec Title Spec Tag Applicability Position Data Interface VT50101-V1.6 Required Position Management Interface VT50102-V1.9 Required Syslog-Based Health Publishing Interface VT50103-V1.9 Required Auto-Discovery Interface VT59930-V1.6 Optional

Information Assurance Component Types

Information Assurance Component Types are described separately in the next section

Information Assurance Architecture

Access Control Authentication Service

Attribute Store Service

Policy Decision Service

Policy Enforcement Service

Policy Store Service

Data Integrity and Confidentiality

Data Signing Service

Signed Data Verification Service

Data at Rest Encryptor

Inline Network Encryptor

Host and Network Protection Host-Based Antivirus

Host-Based Firewall

Intrusion Detection and Prevention System

Network Firewall

C4ISR/EW Component Types

C4ISR/EW

Systems Architecture

Audio Communications Intercom

Legacy Radio

Streaming Audio Data Source

Single-Instance Audio Data Source

Video and Imagery Situational Awareness

Video or Image Sensor

Video or Image Encoder

Camera Gimbal

Extra-Vehicle Network Interfacing Router

Data Radio

Modular RF Signal Resources MORA Device

MORA Signal Resource Manager

MORA Signal Port Manager

RF Processing RF Direction Finding Engine

RF Geolocation Engine

RF Spectrum Sensor

RF Signal Detector

RF Signal Generator

Electronic Warfare System

Audio Communications CTs

• Streaming Audio Data Source

– Defines streaming digital audio I/F

– Based on existing standards

• Intercom and Legacy Radio

– Defines SOAP-based I/F to configure and control audio systems

– Defines generic interfaces

• Single-Instance Audio Data Source

– Defines sending and playing sound files when an event occurs

Video and Imagery SA CTs

• Video or Image Sensor

– Defines SOAP-based I/F to focus and zoom cameras

• Video or Image Encoder

– Defines streaming digital video I/F

– Defines SOAP-based I/F to configure and control encoders

• Camera Gimbal

– Defines SOAP-based I/F to pan and tilt camera

– Defines interface to publish status

C4ISR/EW System and Component Types (1)

Interfaces Common to most CTs

• Health publishing: Syslog / UDP-based interface for publishing status & faults

• Auto-discovery: Zeroconf-based interface for identifying CTs on a VDB

• Data management: SOAP-based interfaces for managing data & health publishing

• Extra-Vehicle Network Interfacing

– Interface between an in-vehicle network (VDB) and an off-vehicle network

– Routing between two networks on different logical subnets

• Electronic Warfare Device

– Defines I/F for reporting object detections

– Defines SOAP-based interface for receiving list of reported objects

– Will be replaced by MORA component types in the future

• Modular RF Signal Resources

– Extend scope of VICTORY to enable modularity within systems that support complex RF missions

– Contain Modular Open RF Architecture (MORA) component types

– Enable resource sharing and management

– Dependable, low latency, high-speed access and transport of RF data

– Formatting, encoding, encapsulation, transport, and routing of messages between MORA and VICTORY components

C4ISR/EW System and Component Types (2)

Platform Systems Component Types

Platform Systems Architecture

Vehicle Systems Interfacing Automotive System

Power Distribution System

Lethality Systems Interfacing Remote Weapon Station

Protection Systems Interfacing Threat Detection and Reporting Service

Active Protection System

Logistics Systems Interfacing Vehicle Configuration Service

Training Systems Interfacing Live Training Transformation Adapter

Vehicle Systems Interfacing

• Automotive System

– Defines interface for publishing automotive-related messages

– Defines SOAP-based interface for managing the publication of each message type

• Power Distribution System

– Defines interface for publishing PDU status messages

– Defines SOAP-based interface to read PDU status

– Control functions being added

Logistics Systems Interfacing

• Vehicle Configuration Service

Platform System Types

Lethality Systems Interfacing

• Remote Weapon Station

– Defines interface for publishing weapon pointing direction

– Defines SOAP-based interface to read weapon status and to add targets

– No control interface

Protection Systems Interfacing

• Threat Detection Service

– Defines I/F for reporting threats

– Defines SOAP-based interface for receiving list of reported threats

• Active Protection System

Training Systems Interfacing

• Live Training Transformation Adapter

• VICTORY architecture defines sets of Component Types

• Component Types are collections of interfaces

• Most of the VICTORY interfaces are network interfaces

• Specifications are intended to create “on-the-wire” interoperability between components

Conclusions

INFORMATION ASSURANCE (IA)

ASPECTS OF VICTORY

• Version A architecture identifies 3 capability groups of IA standard specifications

– Access Control

– Data Integrity and Confidentiality

– Host and Network Protection

Grouping of VICTORY IA Standard Specifications

IA ≠ Cross Domain Solution (CDS)

Information Assurance Component Types

• Authentication Service utilizes the following methods:

– User Name and Password – SAML Token

– Certificate-Based – Biometric

• Four other services support Attribute Based Access Control (ABAC) to provide Authorization

• ABAC is:

– IA policy-based authorization with fine granularity

– Able to encompass other authorization models

• Why do we need Access Control?

– We need to ensure that only legitimate users have access to resources to which they are authorized

Access Control

• Protection of Data at Rest (DAR)

– Direct Attached Storage

– Network Attached Storage

• Why do we need to protect data at rest?

– Required by federal/DoD policy for personally identifiable information (PII)

– Required by Army policy for all data

– In certain applications, used to protect classified data when system is not in use

– Data purge specification

• Protection of Data in Transit

– Inline Network Encryptor (INE) – Transport Layer Security (TLS)

– Internet Protocol Security (IPsec) – Web Services Policy

– Web Services Security

• Why do we need to protect data in transit?

– Required by DoD/Army policy for wireless transmissions

– Ensure data confidentiality

– Assists in data integrity and protects against certain malicious attacks

Data Integrity and Confidentiality

• Protection of Network Boundary

– Network Firewall

– Intrusion Detection and Prevention System

• Why do we need to protect the network boundary?

– Prevention and detection against malicious attacks

– Part of overall defense in depth approach

• Protection of End Nodes

– Host-Based Firewall – Host-Based Antivirus

– Data Signing Service – Signed Data Verification Service

• Why do we need to protect end nodes?

– Typically the last line of defense

– Prevents/detects malicious attacks

Host and Network Protection

CAPABILITIES ENABLED BY VICTORY

Explanation of the benefits of implementing VICTORY

VICTORY capability themes

Example implementations for each capability theme

VICTORY Capability Themes for Architecture A

• Improve SWaP-C in the vehicle (clean up the cab)

– Reduce the SWAP-C burden and improve ingress and egress

• Enhance local situational awareness

– Integrate video & other data in vehicles and across units

• Realize cost conscious integration

– Integrate C4ISR, EW, and platform systems affordably with core IVN

• Reduce the Logistics footprint

– Significantly reduce costs of logistics operations by implementing condition-based maintenance (CBM), and automating configuration management and health management tasks

• Reduce test and training costs

– Significantly reduce costs and time necessary to integrate test and training systems with vehicles, while improving the availability of information to support test and training operations

• Reduce users’ operational burden

– Automate manual and duplicative tasks

• PNT Capabilities

– Time synchronization

– Position

– Orientation

– Direction of travel

– GPS Receiver

– Assured PNT

• Audio/Video Capabilities

– Streaming Audio Data Source

– Intercom

– Legacy Radio

– Video or Image Sensor

– Video or Image Encoder

– Camera Gimbal

– Single Instance Audio Data Source

• C4ISR/EW/Intelligence Capabilities

– Data Radio

– EW System

– MORA Device

– MORA Signal Resource Manager

– MORA Signal Port Manager

• Sensor, Targeting & Weapon System Capabilities

– Remote Weapon Station

– Video or Image Sensor

– Video or Image Encoder

– Camera Gimbal

– Threat Detection and Reporting Service

– Active Protection System

Capabilities Enabled by Implementation Tactical System Capabilities

• Access Control Capabilities

– Authentication Service

– Attribute Store Service

– Policy Decision Service

– Policy Enforcement Service

– Policy Store Service

• Network Capabilities

– Switch

– Router

• Data Management Capabilities

– Data Signing Service

– Signed Data Verification Service

– Data at Rest Encryptor

– Inline Network Encryptor

• Host Security Capabilities

– Host-Based Antivirus

– Host-Based Firewall

– Intrusion Detection and Prevention System

– Network Firewall

• Shared Resource Capabilities

– Shared Processing Unit

– Network Attached Storage

– Generic End Node

– Direct Attached Storage Encryption Management Interface

• Data Bus Capabilities

– VDB Management Service

– VICTORY Configuration Language Instance Document

Host and Network System Capabilities

Host and Network System Capabilities (Cont’d)

• Configuration Description Capabilities

– Infrastructure Component Types

– Shared Data Service Component Types

– System Management Component Types

– Record and Logging Component Types

– Access Control Component Types

– Data Confidentiality and Integrity for Management Interfaces

– Audio Communications Component Type

– Video and Imagery Situational Awareness Component Type

– Extra-Vehicle Network Interface

– Vehicle Configuration Service

– Lethality Systems Interfaces

– Logistics Systems Interfacing Configuration

– Training Systems Interfacing Configuration

• Training Capabilities

– Live Training Transformation Adapter

Vehicle System and Logistics Capabilities

• Vehicle System Capabilities

– Automotive System

– Power Distribution System

– Lethality System

• Vehicle Reporting and Logistics Capabilities

– Health Publishing Interfaces

– Vehicle Configuration Service

• Historical Recording Capabilities

– Mission Recorder

– Data Logger

OVERVIEW OF SPECIFICATION

DEVELOPMENT, MATURATION &

COMPLIANCE VERIFICATION PROCESSES

Top-level process: architecture and specification management structure

Maturation process: specifications initial validation experiments

Compliance verification: verifying at the component type level

Initial Government Management Structure

• Have moved beyond a “coalition of the willing.”

• Have a dedicated core team – the VICTORY

Standards Support Office (VSSO)

• Configuration Management Plan in force

Resulting VICTORY Governance Structure

Current Government Management Structure

Manage

•Manage and mature standards

•Educate community

•Application to relevant S&T

•Lab and development architecture

•Transition deliverables

•Compliance/performance tools and testsSIL

•Baseline platform architecture

•Compliance/performance tests

•Tech demonstrationsField Experiment

ORGANIZE

SYNCHRONIZE

EXECUTE

• C5ISR Center S&T and CMOSS prototyping efforts

• PEO IEW&S

• PEO C3T

• PEO GCS

• PEO Aviation

• N-CFT and APNT/Space CFT

• AFLCMC Open Architecture Management Office

• NAVAIR PMA-209

• Industry Partners

• International Partners

MOSA Management Office SOSA Consortium

VICTORY management transitioned to the MMO in 2021. Leverages the SOSATM

Consortium as the Industry-Government consensus-based standards body.

CMOSS

WIPT

NetModX

• VICTORY adheres to the following approach:

– Adopt existing standards as-is (e.g., Ethernet, PTP)

– Adapt existing standards with minor modifications fitting the VICTORY operational environment

– Author when no existing standards are available

• Specifications are maintained by the VICTORY Subcommittee (VSC) within the SOSATM Consortium

– Leverages existing consensus-based standards body

– Facilitates alignment between VICTORY and SOSA

– Maximizes efficiency of individuals developing and using the specifications

• Core technical team is funded by Government and managed by the MOSA Management Office (MMO)

• Government controls/maintains the Compliance Test Suite and reference software

VICTORY Standardization Approach

• Validation: The execution of experiments to determine whether a specification is mature enough for use in varying contexts

– Initial Validation: Experiments to mature to proposed standard level

– Additional Validation: Experiments to mature to draft standard level

• Verification: The determination of whether a particular hardware or software component complies with a set of VICTORY component type specifications. Verification is accomplished through compliance testing.

Validation vs. Verification

• “Maturity Level”: label identifying how “well proven” a specification is

• Specifications are matured over time through “validation” – the execution of experiments to determine whether a specification is mature enough for use in varying contexts

• Maturity levels include:

– Preliminary Specification

– Informational Specification

– Experimental Specification

– Proposed Standard Specification

– Draft Standard Specification

– VICTORY Standard Specification

• “Standard”: a specification at a “Standards Track” level of maturity

• Individual specifications have independent maturity levels

– {Preliminary | Informational | Experimental} Specification

– {Proposed | Draft | Final} Standard Specification

Specification Maturity Levels

Non-Standards Track Maturity Levels

Standards Track Maturity Levels

• Maturity levels include:

– Preliminary Specification

– Informational Specification

– Experimental Specification

– Proposed Standard Specification

– Draft Standard Specification

– Standard Specification

Maturing Specifications Through Implementation

Initial

Validation

Additional

Validation*

Broad

Deployment

* Deployment by a program or another reference implementation by a gov’t lab constitutes additional validation

• Develop lab “experiment”

– Experiment plan and draft test plan

– Reference SW implementation

– Capture and document results: functionality, performance, resource requirements, development effort, caveats

• Recommend changes to mature specifications

– Reduce ambiguity

– Ensure functionally correct, usable, implementable

Initial Validation Experiments

• Objectives:

– Provide a robust verification means to support PMs and vendors

– Provide guidelines for establishing and accrediting facilities to perform independent compliance verification tests for VICTORY component types

• The CTS is being developed; provides artifacts for each VICTORY component type, including:

– A “golden standard” Compliance Test Plan (CTP), which provides detailed test configuration and methodologies for conducting compliance verification test

– A Compliance Test Report (CTR) template, for documenting compliance test results

– A Compliance Test Tool (CTT), which provides a mix of capabilities, including automating some compliance tests, providing guidance for non-automated tests, allowing user input for verification results based on inspection and demonstration, and generating/viewing CTRs

VICTORY Compliance Concept: Compliance Test Suite (CTS)

• Inspection: visual verification of equipment or documentation

• Demonstration: non-instrumented tests, success determined by observation

• Test: instrumented and automated

• Analysis: verification through the technical evaluation of equations, charts, reduced data, etc. that the test evaluation criteria have been met

Types of Compliance Verification Tests

• An accurate compliance claim statement for Widget X (a mythical component product) must address the specific VICTORY client and service side capabilities being implemented

• Compliance Claim Statement Example:

– Widget X provides (implements the service side of) interfaces that are compliant with the the following VICTORY specifications:

• Shared processing unit, Switch, Position, and time synchronization services

• Threat detection and reporting service, VDB management service

• Policy decision, policy enforcement, policy store, attribute store services

– Compliance of Widget X is documented by the attached CTR

– Widget X uses (implements the client side of) interfaces that are compliant with the following VICTORY specifications:

• Video or image sensor, video or image encoder, camera gimbal

• Automotive bus system interface, electronic warfare device

Accurate Claim for Compliance

An undocumented claim of “VICTORY Compliance” is not sufficient!