YOU ARE DOWNLOADING DOCUMENT

Please tick the box to continue:

Transcript
Page 1: 1October 29, 2007 © 2007 BAE Systems Land & Armaments L.P. 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

October 29, 2007

Tom Schroeder

FCS MGV Software Engineering Manager

BAE Systems, Ground Systems

Integrating Systems and Software Engineering:Observations in Practice

Page 2: 1October 29, 2007 © 2007 BAE Systems Land & Armaments L.P. October 29, 2007 Tom Schroeder FCS MGV Software Engineering Manager BAE Systems, Ground Systems.

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?

Page 3: 1October 29, 2007 © 2007 BAE Systems Land & Armaments L.P. October 29, 2007 Tom Schroeder FCS MGV Software Engineering Manager BAE Systems, Ground Systems.

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

Page 4: 1October 29, 2007 © 2007 BAE Systems Land & Armaments L.P. October 29, 2007 Tom Schroeder FCS MGV Software Engineering Manager BAE Systems, Ground Systems.

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.

Page 5: 1October 29, 2007 © 2007 BAE Systems Land & Armaments L.P. October 29, 2007 Tom Schroeder FCS MGV Software Engineering Manager BAE Systems, Ground Systems.

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

Page 6: 1October 29, 2007 © 2007 BAE Systems Land & Armaments L.P. October 29, 2007 Tom Schroeder FCS MGV Software Engineering Manager BAE Systems, Ground Systems.

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

Page 7: 1October 29, 2007 © 2007 BAE Systems Land & Armaments L.P. October 29, 2007 Tom Schroeder FCS MGV Software Engineering Manager BAE Systems, Ground Systems.

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

Page 8: 1October 29, 2007 © 2007 BAE Systems Land & Armaments L.P. October 29, 2007 Tom Schroeder FCS MGV Software Engineering Manager BAE Systems, Ground Systems.

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

Page 9: 1October 29, 2007 © 2007 BAE Systems Land & Armaments L.P. October 29, 2007 Tom Schroeder FCS MGV Software Engineering Manager BAE Systems, Ground Systems.

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

Page 10: 1October 29, 2007 © 2007 BAE Systems Land & Armaments L.P. October 29, 2007 Tom Schroeder FCS MGV Software Engineering Manager BAE Systems, Ground Systems.

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?

Page 11: 1October 29, 2007 © 2007 BAE Systems Land & Armaments L.P. October 29, 2007 Tom Schroeder FCS MGV Software Engineering Manager BAE Systems, Ground Systems.

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)

Page 12: 1October 29, 2007 © 2007 BAE Systems Land & Armaments L.P. October 29, 2007 Tom Schroeder FCS MGV Software Engineering Manager BAE Systems, Ground Systems.

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

Page 13: 1October 29, 2007 © 2007 BAE Systems Land & Armaments L.P. October 29, 2007 Tom Schroeder FCS MGV Software Engineering Manager BAE Systems, Ground Systems.

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.

Page 14: 1October 29, 2007 © 2007 BAE Systems Land & Armaments L.P. October 29, 2007 Tom Schroeder FCS MGV Software Engineering Manager BAE Systems, Ground Systems.

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+

Page 15: 1October 29, 2007 © 2007 BAE Systems Land & Armaments L.P. October 29, 2007 Tom Schroeder FCS MGV Software Engineering Manager BAE Systems, Ground Systems.

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.


Related Documents