1october 29, 2007 © 2007 bae systems land & armaments l.p. october 29, 2007 tom schroeder fcs...
Post on 19-Dec-2015
213 views
TRANSCRIPT
October 29, 2007 © 2007 BAE Systems Land & Armaments L.P. 1
October 29, 2007
Tom Schroeder
FCS MGV Software Engineering Manager
BAE Systems, Ground Systems
Integrating Systems and Software Engineering:Observations in Practice
October 29, 2007 © 2007 BAE Systems Land & Armaments L.P. 2
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. 3
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
Ground Systems – A Summary
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. 4
FCS Brigade Combat Team (BCT)18 Integrated Systems + 1 Network + 1 Soldier
FCS is about the 21FCS is about the 21stst Century Soldier Century SoldierFCS is about the 21FCS is about the 21stst Century Soldier Century Soldier
Unmanned Aerial Vehicles
Class II Class III Class IV
Class I
ARV-A (L)
Small (Manpackable) UGV
MULE(Countermine)
MULE(Transport)
Unmanned Ground Vehicles
Unattended Ground Sensors
Armed Robotic Vehicle (ARV)
Unattended Munitions
ARV RSTAARV Aslt
Intelligent MunitionsSystems
NLOS LS
Infantry CarrierVehicle (ICV)
Manned Systems
Command andControl Vehicle (C2V)
Reconnaissance andSurveillance Vehicle (RSV)
Mounted Combat System (MCS)
Non-Line of SightCannon (NLOS-C)
Non-Line of Sight Mortar (NLOS-M)
Medical VehicleTreatment (MV-T)
FCS Recovery and Maintenance Vehicle (FRMV)
Medical VehicleEvacuation (MV-E)
Approved for Public Release, Distribution Unlimited, TACOM 20 SEP 2006, case 06-208.
October 29, 2007 © 2007 BAE Systems Land & Armaments L.P. 5
An MGV Vehicle PlatformAn MGV Vehicle Platform
MGV Base Platform Software ContextMGV Base Platform Software Context
Base VehicleBase
VehicleLogistics /
SustainmentLogistics /
Sustainment
ISRISR TrainingTraining
Integrated Platform: “MGV Platform”
Integrated Platform: “MGV Platform”
Real–Time, Deterministic Software - Isolated from the C2 NetworkReal–Time, Deterministic Software - Isolated from the C2 Network
C2C2
Inter-Platform Behaviors: “Brigade Combat Team SOS”
Inter-Platform Behaviors: “Brigade Combat Team SOS”
Vehicle Platforms Must be Designed for Integration and Evolution
October 29, 2007 © 2007 BAE Systems Land & Armaments L.P. 6
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 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
October 29, 2007 © 2007 BAE Systems Land & Armaments L.P. 7
Software Build 1 Objectives
Build initial prototype vehicles for one vehicle type (“variant”), the Non-Line 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. 8
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. 9
VNT SW TestVNT SW Test
VNT SW IntVNT SW Int
VNT SW I&T EnvVNT SW I&T Env
CMN SW TestCMN SW Test
CMN SW IntCMN SW Int
CMN SW I&T EnvCMN SW I&T Env
VNT SW TestVNT SW Test
VNT SW IntVNT SW Int
VNT SW I&T EnvVNT SW I&T Env
CMN SW TestCMN SW Test
CMN SW IntCMN SW Int
CMN SW I&T EnvCMN SW I&T Env
SW I&TSW I&T
SW C&UTSW C&UT
SW DesignSW Design
SW RqmtsSW Rqmts
SW Mgmt & EnvSW Mgmt & Env
SSys Spec/AllocSSys Spec/Alloc
SSys DesignSSys Design
VNT SW TestVNT SW Test
VNT SW IntVNT SW Int
VNT SW I&T EnvVNT SW I&T Env
CMN SW TestCMN SW Test
CMN SW IntCMN SW Int
CMN SW I&T EnvCMN SW I&T Env
SW I&TSW I&T
SW C&UTSW C&UT
SW DesignSW Design
SW RqmtsSW Rqmts
SW Mgmt & EnvSW Mgmt & Env
SSys Spec/AllocSSys Spec/Alloc
SSys DesignSSys Design
SSys AL2 RqSSys AL2 Rq
Sys Spec/AllocSys Spec/Alloc
Sys DesignSys Design
Sys PIDS/AL1 RqSys PIDS/AL1 Rq
CMN SW IntCMN SW Int
CMN SW I&T EnvCMN SW I&T Env
SW I&TSW I&T
SW C&UTSW C&UT
SW DesignSW Design
SW RqmtsSW Rqmts
SW Mgmt & EnvSW Mgmt & Env
SSys Spec/AllocSSys Spec/Alloc
SSys DesignSSys Design
SSys AL2 RqSSys AL2 Rq
Sys Spec/AllocSys Spec/Alloc
Sys DesignSys Design
Sys PIDS/AL1 RqSys PIDS/AL1 Rq
SSys Spec/AllocSSys Spec/Alloc
SSys DesignSSys Design
SSys AL2 RqSSys AL2 Rq
Sys Spec/AllocSys Spec/Alloc
Sys DesignSys Design
Sys PIDS/AL1 RqSys PIDS/AL1 Rq
Engineering Cycle 2.n+2Engineering Cycle 2.n+1Engineering Cycle 2.n
Integration of Systems and Software Engineering:MGV Sys/Sw Workflow Design
4 months
SoftwareIntegration
EC 2.n-1
SoftwareEC 2.n
SystemsEC 2.n+1
WorkflowStages
@ Pointsin Time
October 29, 2007 © 2007 BAE Systems Land & Armaments L.P. 10
Idealized Systems and Software Integrated Build Life CycleYear 2Year 1
S/SS SW SITDI 2.1
Start
S/SS SW SITDI 2.2
S/SS SW SITDI 2.3
S/SS SW SITDI 2.4
S/SS SW SIT
S/SS SW SITDI 2.6
S/SS SW SITDI 2.7
S/SS SWDI 2.8
SwLCO (ACR)
SwLCA (DCR)
SyLCO
SyLCA
InceptionPhase
ElaborationPhase
ConstructionPhase
TransitionPhase
TRRs
Acronyms and AbbreviationsDI b.c Development Increment, Build b, Increment cIOC Initial Operational CapabilityLCA Life Cycle Architecture MilestoneLCO Life Cycle Objectives MilestoneS/SS Systems/Subsystems (IPT) EngineeringSI Software ItemSIT Software Subsys/Sys Integration & TestSW Software Engineering (incl. SI-Level Int & Test)SwLCA Software LCASwLCO Software LCOSyLCA Systems/Subsystems LCASyLCO Systems/Subsystems LCOTRR Test Readiness Review (SI Level)
IOC
SIT
DI 2.5
By adding Systems & Subsystems requirements and design engineering stages synchronized with Software development increments, upstream work products can be worked iteratively to support Software.
Software can provide valuable implementation feedback to Systems & Subsystems teams, with pre-planned learning adjustments.
Consider introduction of Systems LCO and LCA events.
Need to keep as separate Sys/SW events to coordinate workflows?
October 29, 2007 © 2007 BAE Systems Land & Armaments L.P. 11
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, 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)
October 29, 2007 © 2007 BAE Systems Land & Armaments L.P. 12
Feasibility Rationale - Key Point: Need to Show Evidence
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• Realism of assumptions
• Representativeness of scenarios
• Thoroughness of analysis
• Coverage of key off-nominal conditions
B. Boehm, “A Case for Anchor Point Milestones and Feasibility Rationales,” April 2005
October 29, 2007 © 2007 BAE Systems Land & Armaments L.P. 13
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:
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 analysesNeed to find ways to increase involvement of Systems Engineering and
External SOS groups in Feasibility Analysis
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.
…
October 29, 2007 © 2007 BAE Systems Land & Armaments L.P. 14
Span of Feasibility Concerns
MGV, 12, 33%
Org, 3, 8%
SOS, 21, 59%
• 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.
Notional SOS Project
SOS
MGV
Organization
Contract/Agreement Relationship
Summary of Initial Results
Example: 2 OrganizationsSOS Span Distance = 5SOS Organizations = 6
Span DistanceWithin Org = 0MGV = 1 or 2SOS = 2 to 5+
October 29, 2007 © 2007 BAE Systems Land & Armaments L.P. 15
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.