Joint Common Architecture Demonstration
Lessons Learned –
Honeywell Perspective
Presented by:
Alex Boydston, US Army Aviation Development Directorate
Matt Warpinski, Honeywell Aerospace
.
DISTRIBUTION
STATEMENT
A. Approved
for
release;
distribution
is unlimited.
DISTRIBUTION
STATEMENT
A. Approved
forpublic
public release;
distribution
is unlimited
Joint Common Architecture (JCA)
Demo Overview
Modular Integrated Survivability (MIS) System
Approach:
• Model based acquisition of a software
component (i.e., Data Correlation & Fusion
Manager) conforming to FACETM Std & JCA v0.X
• Reusable Verification Component (RVC) made to
test DCFM in target Operating Environment (OE)
Data Correlation &
Fusion
Manager &
Data Correlation
(DCFM)
Fusion
Manager
(Vendor
1)
(DCFM)
(Vendor 2)
TASKS
JCA Demo Schedule
FY13
FY14
Solicitation Preparation
Request for Information (RFI)
to Industry
Issue BAA
Award Component Dev. Efforts
Component Development
Lab Integration
Conformance & Integration
Testing
Write Report / Update JCA
• FACE Ecosystem tools used for development
• Exercised FACE Conformance Test Suite,
Verification Authority & FACE registry process
FY15
• Controlled experiment reserving info on OEs
from DCFM developers until after delivery
• System Integration into multiple OEs on MIS
system to prove portability
Goals:
• Validate the JCA & FACE approaches
• Mature JCA, FACE Standard & Ecosystem tools,
and business practices to reduce future risks
• Gain experience implementing a model based
approach (learn by doing)
DISTRIBUTION STATEMENT A. Approved for public release; distribution is unlimited
.
2
Model Based Solicitation:
Data Model & Supplemental Requirements
•
BAA Solicitation contained DCFM UML Data
Model (DM) & Supplemental requirements
•
Proposal response and post award
meetings revealed necessary changes in
DCFM DM & requirements
•
Lessons learned captured with respect to:
– FACE standard
– Ecosystem tools
– Model & requirements
– Integration and verification
– Government’s ability to procure a software
UoP via a FACE data model is achievable!
•
•
•
•
•
•
•
PART OF DCFM
UML DATA MODEL
(Sequence Diagram)
SUPPLEMENTAL REQUIREMENTS
The DCFM shall analyze uncorrelated source tracks in order to identify a single correlated track believed to represent the
same uncorrelated source tracks, combining the data from the duplicate uncorrelated source tracks.
The DCFM shall analyze correlated source tracks in order to identify separate tracks, breaking the linkage of the
correlated track with the uncorrelated source tracks.
The DCFM shall analyze tracks within 25km of own-ship position
The DCFM shall correlate or de-correlate 50 source tracks within 1 second.
The DCFM Data Model shall be used during the development of the software component
The DCFM shall be built as a FACETM Unit of Portability (UoP) as specified in the Data Model
The DCFM shall have a verification statement provided by the candidate FACE CTS for the FACE Standard ed. 2.0
DISTRIBUTION STATEMENT A. Approved for public release; distribution is unlimited
.
3
DCFM Requirements Derivation
• Goal was to identify minimum set of requirements needed to give UoP
software component provider
• Majority of issues identified during requirement stage
‒ Missing message ports sampling rate
‒ Timing requirements without hardware specified (e.g., 50 tracks within 1 sec)
‒ Uniqueness of source identification not defined
‒ UTC time service not provided
4
© 2015 Honeywell International All Rights Reserved
4
DCFM Architecture Description
• Design consists of four components:
‒ Data Correlation and Fusion Manager (DCFM)
 FACE-conformant component that performs
correlation, fusion, & de-correlation of tracks.
‒ Reusable Verification Component (RVC):
 Simulates MIS Situational Awareness Data
Manager (SADM) and Health
Monitor Manager (HMM)
 Intended for verifying the DCFM
functionality on target OE
‒ RVC Controller
 User interface to control the RVC operation
‒ Transport Services
 Provides FACE conformant message transport
 Created by FACE Ecosystem SDK / IDK tool
5
© 2015 Honeywell International All Rights Reserved
5
Partitioning & Timing Aspects
• Original BAA had sequence diagram depicting serial data flow
partition
time window
DCFM
SADM
DCFM
SADM
Request
source
tracks
Send source
tracks
Get source tracks
Request
correlated
tracks
partition
time window
DCFM
SADM
DCFM
Get correlated
tracks
Request
platform position
Send platform
position
TSS (message ports)
partition
time window
TSS (message ports)
partition
time window
TSS (message ports)
partition
time window
TSS (message ports)
partition
time window
TSS (message ports)
partition
time window
Send correlated
tracks
Get platform position
Process data
Send updated
Correlated Track
data
DCFM – Data Correlation and Fusion Manager
SADM –Situational Awareness Data Manager
6
© 2015 Honeywell International All Rights Reserved
6
Partitioning & Timing Aspects
• Updated sequence diagram to request all DCFM data in one frame
• SADM would send data in its partition time window
• Upon calling the DCFM it will have data ready, process the data, and request next
data set
partition
time window
Get track
& position
data
Get track &
position data
process data
Send updated
Correlated
Track data
Request tracks
and position
SADM
Get correlated
tracks
Send requested
data
TSS (message ports)
DCFM
TSS (message ports)
DCFM
process data
Send updated
Correlated
Track data
Request tracks
and position
TSS (message ports)
partition
time window
partition
time window
time
7
© 2015 Honeywell International All Rights Reserved
7
DCFM Specifications & Implementation
• DCFM UoP interfaces need to be defined to a higher level of detail and clarity
‒ Frame Rate
‒ Latencies
‒ Priorities
‒ Time allocation
• DCFM UoP timing and latency concerns need to be addressed and understood
‒ Hardware Dependent
• Early collaboration between system and software providers will enhance overall
system architecture and requirements benefits
• Goal is not to develop software for specific platform
‒ Understanding the range of platforms allows you to optimize software
performance
8
© 2015 Honeywell International All Rights Reserved
8
Utilization of the FACE Ecosystem Tools
• FACE Conformance Test Suite (CTS)
‒ Used prior to delivery to government
Portable Component Segment (PCS)
UoP
‒ Conducted by FACE VA after delivery
‒ Autogenerated code
‒ Created all the software pieces for
execution, ARINC 653 handling, message
routing
• Lessons Learned
‒ SDK / IDK tool created software that
included ACM emulator function calls that
were not FACE compliant
‒ FACE SDK/IDK provided efficiencies in
software development
Test Harness
• Software Development Kit / Integration
Development Kit (SDK/IDK)
‒ Modeled data flow
Reusable
Verification
Component
(SA DM Sim)
DCFM
* Apply Correlation Algorithm
* Call DCFM
* Generate Track Data
* Store Correlated Tracks
* Display Tracks
* Notification of Track
Correlation/Decorrelation
Correlation Fusion
Algorithm
Transforms
SADM Stub (API)
DCFM (API)
SADM Stub FACE
DCFM FACE
Routing
ARINC 653
Transport Services Segment (TSS)
Auto Generated Code
‒ Shortcomings to Ecosystem tools to be
corrected in future revision of tools
9
© 2015 Honeywell International All Rights Reserved
9
DCFM & RVC Development
• Traditional Development
Copy 1
‒ Optimized storage
‒ Additional copies of data needed
‒ Internal and external data sets
• Data Correlation and Fusion Manager
(DCFM)
‒ Auto generated code contained ACM wrapper
functions and stdint.h
DCFM
Shared Memory
Data
Generator
• FACE Development
Correlation Fusion
Algorithm
Transforms
Portable Component Segment (PCS)
‒ Additional Health Monitor Manager interface
needed to start and stop
UoP
DCFM
RVC
Correlation Fusion
Algorithm
Copy 1
• Reusable Verification Component (RVC)
‒ RVC needed to act as a UoP but not required
to be conformant
‒ Allows for an external non conformant
interface
10
Copy 6
Transforms
‒ Created vehicle emulators to simulate track
data generation
‒ Simulated data makes instantaneous heading
and speed changes
Copy 2
Copy 2
SADM Stub (API)
DCFM (API)
Copy 5
SADM Stub FACE
DCFM Stub FACE
Copy 4
Copy 3
Routing
ARINC 653
Transport Services Segment
© 2015 Honeywell International All Rights Reserved
10
FACE Conformance &
Verification Authority Experience
•
Honeywell performed the FACE Conformance Test Suite (CTS) before delivery.
•
DCFM Software with associated technical artifacts were supplied to FACE VA.
•
DCFM passed the majority of the CTS but still failed due to lack of FACE 2.1 Shared
Data Model when BAA was published
•
FACE Conformance Statement completed jointly by Honeywell and Army.
•
FACE online registry process was exercised and minor problems elicited.
•
Improvements to the FACE Registry site and FACE VA process were identified.
Conduct
Preparation
Initiate
Verification
FACE
Verification
Initiate
Certification
Initiate
Registration
FACE
Registration
FACE
Certification
DISTRIBUTION STATEMENT A. Approved for public release; distribution is unlimited
.
11
•
JCA Demo
Integration Experience
MIS Operating Environment
Integration successes
– FACE tools eased integration as
compared to traditional process
– Tested DCFM with RVC in Linux
environment prior to integration
– Integrated DCFM into VxWorks and
LynxOS proving FACE portability
– Passed integration tests
– Executed demo scenario flights
•
Integration challenges
– Ecosystem generated Transport
Service code required some manual
modifications
– Data input/output required manual
modifications
– Lack of FACE conforming RTOS
•
Platform
AH64DSystem
MIS
MIS
Host 1OE
(WVHTC)
APR39C
MFD
WeaponWatch
MFD
Controller
MIS
Moving Map
Flight Sim
Tactical
Network
EGI
Controller
DCFM
JCA DEMO SCENARIO FLIGHT
Objective
Radar
guided
AAA
Hostile
Fire Small
Arms
Obstacle
Threats
Challenge areas reported to FACE
IR
Manpads
DISTRIBUTION STATEMENT A. Approved for public release; distribution is unlimited
Takeoff
.
12
Honeywell Lessons Learned/
Conclusions/Recommendations
• Lessons Learned
‒ FACE modeling tools enabled easy insertion & connection of the UoP into system
‒ Auto generation of TS layer interface saved time and scope
‒ Use of the FACE Standard and data model added minimal integration and test time
‒ Experience and knowledge in the FACE eco-system was gained and issues identified
‒ FACE Edition 3.0 and data model changes were suggested and made
‒ FACE tools (CTS, and SDK/IDK tools) issues were indentified for the tool provider
• Conclusions
‒ System integration performance considerations still must be addressed
‒ Information in a model can clarify expectations, but does not fix requirements issues
‒ Majority of the information needed for system design & integration was sufficient
• Recommendations
‒ Conduct requirements analyses prior to solicitation and during proposal.
‒ Improve FACE standard to incorporate system integration aspects.
‒ Additional exercises of the FACE standard would allow further insight
13
© 2015 Honeywell International All Rights Reserved
13
ACRONYMS
ACRONYM
AAA
ACM
ACVIP
ADD
API
ATW
BAA
BFT
CA
CTS
DCFM
DoD
EGI
FACE
FVL
GPS
HMM
IDK
INS
ACRONYM
DEFINITION
Agile, Adaptive, Ad hoc
ARINC 653 Component Module
Architecture Centric Virtual
Integration Process
Aviation Development Directorate
Application Programming Interface
Advanced Threat Warning
Broad Agency Announcement
Blue Force Tracker
Certificate Authority
Conformance Test Suite
Data Correlation and Fusion
Manager
Department of Defense
Embedded GPS / INS
Future Airborne Capability
Environment
Future Vertical Lift
Global Positioning System
Health Monitor Manager
Integrators Development Kit
Inertial Navigation System
ISIS
DEFINITION
MIS
NDA
NRE
OE
PSSS
RTOS
RVC
SA
SADM
SDK
TS
Vanderbilt University Institute for
Software Integrated Systems
Input / Output
Infra Red
Joint Common Architecture
Manned Portable Air Defense
System
Modular Integrated Survivability
Non-Disclosure Agreement
Non Recurring Engineering
Operating Environment
Platform Specific Services Segment
Real Time Operating System
Reusable Verification Component
Situational Awareness
SA Data Manager
Software Development Kit
Transport Services
TSS
UoP
UTC
VA
Transport Services Segment
Unit of Portability
Universal Time Coordinate
Verification Authority
IO
IR
JCA
MANPADS
DISTRIBUTION STATEMENT A. Approved for public release; distribution is unlimited
.
14