Integrating Systems and Software Engineering:
Observations in Practice
October 29, 2007
Tom Schroeder
FCS MGV Software Engineering Manager
BAE Systems, Ground Systems
October 29, 2007
© 2007 BAE Systems Land & Armaments L.P.
1
Purpose
Provide a perspective on:
 Integrating Systems and Software Engineering for Complex Systems.
• From the perspective of a major supplier and integrator
• Starting Build 2
 What are the significant issues and concerns expressed by project
suppliers?
 What works in practice? What doesn’t?
 How can the Incremental Commitment Model be improved?
October 29, 2007
© 2007 BAE Systems Land & Armaments L.P.
2
Ground Systems – A Summary

Protected Fighting Platforms for Today’s Warfighter as well as
the Battlefield of Tomorrow
• Predominant Supplier to the U.S. Army Heavy Brigades with
•
•

Bradley, HERCULES, Paladin, M113
Mine-Protected Wheeled Vehicles
FCS Manned Ground Vehicles and Armed Robotic Vehicle
Key Technologies
• Advanced Protection and Mobility Solutions for Soldiers, Manned
•
•

Vehicles and Robots
Outstanding Program Management and Experienced Workforce
3,250 employees, including more than 600 technologists
World-Class Development Processes
• CMMI Level 5 Software and Systems Engineering Process
• Physics-Based Models & Real-Time Simulation Capabilities
• Rapid Prototyping of Complex Systems
 Lean, Cost-effective Production Facilities
GS is a modern, efficient, full-spectrum developer, integrator and supplier
of survivable, lethal ground combat platforms and advanced technologies
October 29, 2007
© 2007 BAE Systems Land & Armaments L.P.
3
FCS Brigade Combat Team (BCT)
18 Integrated Systems + 1 Network + 1 Soldier
Infantry Carrier
Vehicle (ICV)
Manned Systems
Unmanned Aerial Vehicles
Class IV
Command and
Control Vehicle (C2V)
Class II
Class I
Class III
Mounted Combat
System (MCS)
Unattended Munitions
Unattended
Ground
Sensors
NLOS LS
Intelligent
Munitions
Systems
Reconnaissance and
Surveillance Vehicle (RSV)
Unmanned Ground Vehicles
Non-Line of Sight
Cannon (NLOS-C)
Non-Line of Sight Mortar (NLOS-M)
Small
(Manpackable) UGV
ARV Aslt
ARV RSTA
FCS Recovery and
Maintenance Vehicle
(FRMV)
Armed Robotic
Vehicle (ARV)
Medical Vehicle
Treatment (MV-T)
Medical Vehicle
Evacuation (MV-E)
ARV-A (L)
MULE
(Countermine)
MULE
(Transport)
FCS is about the 21st Century Soldier
October 29, 2007
© 2007 BAE Systems Land & Armaments L.P.
Approved for Public Release, Distribution Unlimited, TACOM 20 SEP 2006, case 06-208.
4
MGV Base Platform Software Context
Real–Time, Deterministic Software - Isolated from the C2 Network
An MGV Vehicle Platform
Base
Vehicle
ISR
Inter-Platform Behaviors:
“Brigade Combat Team SOS”
C2
Logistics /
Sustainment
Training
Integrated Platform:
“MGV Platform”
Vehicle Platforms Must be Designed for Integration and Evolution
October 29, 2007
© 2007 BAE Systems Land & Armaments L.P.
5
Characteristics of Project from a Software Perspective


Extremely large System of Systems project
Target computing hardware developed concurrently with software
• Includes vehicle computers, remote interface units, servo control units
• Includes many additional subsystems internally produced/procured and externally provided
• Most final hardware not available during early build iterations
 Must substitute “host” and “surrogate” development environments
 Evolve Simulators to Emulators and Stimulators


Many decisions not under platform supplier’s control
Interface contracts extremely important due to size of SOS
• Successive refinement and elaboration through multiple levels of Systems Engineering to
•
•
•
October 29, 2007
Software Engineering
At Software level, utilize IDL and interface code generators to minimize architecture dependencies
Utilize common design patterns for communications across deployable software entities
 Pub-sub, proxy, etc.
Ideally generate IDL directly from tagged attributes in shared design model
 Requires all groups to use same interface modeling approach
 Allows for one data dictionary
© 2007 BAE Systems Land & Armaments L.P.
6
Software Build 1 Objectives
 Build initial prototype vehicles for one vehicle type (“variant”), the NonLine of Sight Cannon (NLOS-C), to be assembled in 2008
 Develop “threshold path” common components and software for a
common chassis.
• Hybrid Electric Drive Powertrain, Driving functions, Vehicle Management
• Power Distribution, Remote Interface Units, Servo Control Units
• Embedded Training
 Develop “threshold path” mission equipment and software for the
weapon and mission control functions
 Develop low-cost software and hardware “surrogates” to stand-in for
functionality that is not yet available, such as the sustainment system,
the displays and user interface system, etc.
 Develop and improve processes for software development and
integration
 Reduce risk for objective vehicles and software development
October 29, 2007
© 2007 BAE Systems Land & Armaments L.P.
7
Software Build 2 Objectives
 Build out software infrastructure for all MGV variants
 Ensure that MGV common components and common software can be
configured for every MGV variant
 Develop vehicle and mission module control functions for all MGV
variants
 Utilize and integrate externally provided software and subsystems
• Prove viability of layered software infrastructure
• Define peer interfaces at application level across SOS
 Continue to develop and improve processes for systems and software
development and integration
• Better integrate MGV Systems and Software Engineering Workflows
• Improve Coordination with SOS Development
 Continue to reduce risk for objective vehicles and software development
October 29, 2007
© 2007 BAE Systems Land & Armaments L.P.
8
Integration of Systems and Software Engineering:
MGV Sys/Sw WorkflowWorkflow
Design
Stages
Engineering
Cycle 2.n+1
@ Points
in Time
Engineering Cycle 2.n
Sys PIDS/AL1 Rq
Engineering Cycle 2.n+2
Sys PIDS/AL1 Rq
Sys Design
Sys PIDS/AL1 Rq
Sys Design
Sys Spec/Alloc
Sys Spec/Alloc
Systems
EC 2.n+1
SSys AL2 Rq
Sys Design
Sys Spec/Alloc
SSys AL2 Rq
SSys Design
pec/Alloc
SSys Design
SSys Spec/Alloc
SW Mgmt & Env
SSys AL2 Rq
SSys Spec/Alloc
SW Mgmt & Env
SW Rqmts
SSys Des
SW Mgmt & Env
SW Rqmts
Software
EC 2.n
SW Design
SW C&UT
SW Rqmts
SW Design
SW C&UT
SW I&T
CMN SW I&T Env
MN SW Int
SW Design
SW C&UT
SW I&T
T Env
VNT SW Int
VNT SW Test
CMN SW
CMN SW Int
CMN SW Test
VNT SW I&T Env
SW I&T
CMN SW I&T Env
CMN SW Int
CMN SW Test
SSy
Software
IntegrationVNT SW I&T Env
EC 2.n-1
VNT SW Int
VNT SW Test
CMN SW Test
VNT SW I&T Env
VNT SW Int
VNT SW Test
4 months
October 29, 2007
© 2007 BAE Systems Land & Armaments L.P.
9
Idealized Systems and Software Integrated Build Life Cycle
Start
DI 2.1
S/SS
Year 1
SW
By adding Systems & Subsystems
requirements and design engineering
stages synchronized with Software
development increments, upstream
work products can be worked
iteratively to support Software.
SIT
SyLCO
DI 2.2 S/SS
Consider introduction
of Systems LCO and
DI 2.3
LCA events.
SwLCO (ACR)
SW
SIT
S/SS
SW
DI b.c
IOC
LCA
LCO
S/SS
SI
SIT
SW
SwLCA
SwLCO
SyLCA
SyLCO
TRR
DI 2.4
Acronyms and Abbreviations
Development Increment, Build b, Increment c
Initial Operational Capability
Life Cycle Architecture Milestone
Life Cycle Objectives Milestone
Systems/Subsystems (IPT) Engineering
Software Item
Software Subsys/Sys Integration & Test
Software Engineering (incl. SI-Level Int & Test)
Software LCA
Software LCO
Systems/Subsystems LCA
Systems/Subsystems LCO
Test Readiness Review (SI Level)
October 29, 2007
S/SS
DI 2.5
Inception
Phase
SIT
SyLCA
Need to keep as
separate Sys/SW
events to coordinate
workflows?
Year 2
SwLCA (DCR)
SW
SIT
Software can provide valuable
implementation feedback to Systems
& Subsystems teams, with preplanned learning adjustments.
S/SS
SW
SIT
S/SS
SW
DI 2.6
Construction
Phase
SIT
TRRs
DI 2.7
S/SS
DI 2.8
© 2007 BAE Systems Land & Armaments L.P.
Elaboration
Phase
SW
SIT
S/SS
SW
IOC
SIT
Transition
Phase
10
Systems Engineering Support to LCO (ACR)



LCO viewed by MGV Systems Engineering as a “Software Event,” but SE provided required support.
Created internal RBR (Requirements Baseline Review) milestone to have the LCO equivalent for
Systems within MGV.
Created mappings from MGV System Use Cases to MGV Software Capabilities, and scheduled
Systems, Software, and Integration Thread capabilities across all Development Iterations.
What level of completion of Systems Engineering work products is needed for Software to have a
successful LCO?



Recent RBR Experience: All requirements allocated to software were specified at a broad level, with
traceability to upper-level models.
• Challenge was leveling MGV IPTs to consistent levels of detail, and gaining consistent support across every team
• Factored out common use cases to ensure consistent requirements
Some systems requirements were developed in greater depth
• Vehicle start-up, shut-down, mode changes
Other documents were made available as reference (works in progress) which will be matured leading
up to System PDR:
• System Architecture which may include applicable DDM's, such as Vehicle Electronics Architecture,
•
•
•
•
•
October 29, 2007
System/Subsystem Schematics, Specialty Engineering Reports (Security, HFE/MANPRINT, Safety,
Maintainability), Sustainment and Training Design Concepts
Thread based performance analyses
Current Version of Common Subsystem and Variant Level S/SDD's
Vehicle External ICD’s - Interfaces to all C4ISR, Sustainment, and Training supplied subsystems.
Vehicle Internal ICD’s – Interfaces to MGV Subsystems
HW Configuration Item Specifications (HW CIDS - as available)
© 2007 BAE Systems Land & Armaments L.P.
11
Feasibility Rationale - Key Point: Need to Show Evidence
B. Boehm, “A Case for Anchor Point Milestones and Feasibility Rationales,” April 2005


Not just traceability matrices and PowerPoint charts
Evidence can include results of
•
•
•
•
•
•
•

Prototypes: networks, robots, user interfaces, COTS interoperability
Benchmarks: performance, scalability, accuracy
Exercises: mission performance, interoperability, security
Models: cost, schedule, performance, reliability; tradeoffs
Simulations: mission scalability, performance, reliability
Early working versions: infrastructure, data fusion, legacy compatibility
Combinations of the above
Validated by independent experts
•
•
•
•
October 29, 2007
Realism of assumptions
Representativeness of scenarios
Thoroughness of analysis
Coverage of key off-nominal conditions
© 2007 BAE Systems Land & Armaments L.P.
12
Feasibility Analysis Planning Workshop




Review Build Objectives, incl. Risks, Concerns, Issues
Develop candidate software prototypes and integration threads by IPT Software
Team using provided template
Integrate results
Template with example provided to teams:
Concern (significant LCO or LCA
Risk, Rqmt, Arch)
Handling Approach, Value (Prototype,
Thread, Analysis)
Plan (EC, Description, ROM Cost, Product)
Sensor/Weapon I/F Integration
Prototype Interface with SDM,
Exercise Preliminary Thread, High
Value prior to LCA
EC 2.3, Prototype sensor/weapon slew I/F, 80
hrs, SADD & FR input. Integrate with SDM
LoFi in lab.
…

Result Summary:
• 10 Subsystem and Vehicle Software Teams developed a total of 36 candidate
feasibility analyses

Next steps are to expand participants, prioritize, isolate common concerns, plan
and schedule analyses
Need to find ways to increase involvement of Systems Engineering and
External SOS groups in Feasibility Analysis
October 29, 2007
© 2007 BAE Systems Land & Armaments L.P.
13
Span of Feasibility Concerns
Notional SOS Project
Summary of Initial Results
Org, 3,
8%
MGV
MGV,
12, 33%
SOS,
21, 59%
SOS
Organization
Contract/Agreement Relationship
Example: 2 Organizations
SOS Span Distance = 5
SOS Organizations = 6
• Most concerns are about the feasibility of interfacing to and
using products produced across SOS organizations.
• Communications burden and contractual boundaries rapidly
expand as the number of SOS organizations increases.
October 29, 2007
© 2007 BAE Systems Land & Armaments L.P.
Span Distance
Within Org = 0
MGV = 1 or 2
SOS = 2 to 5+
14
SOS Challenges

Synchronizing development to similar iterations across many organizations,
each with its own development processes, is extremely difficult.
• Unsynchronized workflows increase the number “surprise” requirements changes

Greater numbers of participants tend to stretch out the iterations to make the
same amount of progress.
• Takes time to discover who to coordinate with, and if they have tasking to do so
• Organizations change, people move around, responsibilities shift, POC’s change
• Potential O(2) effect with more interactions and interfaces

Interface and scope negotiation across many associate teams adds activities
and stretches iterations.
• To make progress, teams are forced to make unilateral decisions
• From SOS perspective, may be sub-optimal or not even viable system-wide



Coordinating compatible requirements to achieve viable functioning threads
across associate contractors for small increments is difficult.
Incremental SOS use of tactical software can be prohibitively expensive in
terms of numbers of computers, simulators, emulators, and plant models
needed prior to long-lead time dedicated hardware being available.
Intellectual property protection, licensing, and legal involvement increases.
October 29, 2007
© 2007 BAE Systems Land & Armaments L.P.
15