System of Systems Engineering: RACRS Case Study

System of Systems Engineering: RACRS Case Study

Jo Ann Lanejolane at usc.edu

14 April 2010

2

Overview

SoS context and key challengesSoSE strategies• Incremental commitment and evolution• Lean principles• Engineering cost estimation• Engineering and management artifacts• Test and evaluation

SoS example •Regional Area Crisis Management System (RACRS)

Future plansAcknowledgements

Questions

1. List a static model that can support the SoSE core element “Develop and Evolve and SoS Architecture”.

2. List a dynamic model type that can be used to support the SoSE core element “Understanding Constituent Systems and Their Relationships”.

3. List a model that is key to evaluating SoS constituent system interoperability.

3

4

Net-Centric SoS Net-CentricConnectivit

y

What is a “System of Systems”?Very large systems using a framework or architecture to integrate constituent systems (CSs)Exhibits emergent behavior not otherwise achievable by CSsSoS CSs

• Independently developed and managed• New or existing systems in various stages of

development/evolution• May include a significant number of COTS

products• Have their own purpose• Can dynamically come and go from SoS

Typical domains• Military/Crisis Response: Dynamic

communications infrastructure• Business: Enterprise-wide and cross-enterprise

integrations

Based on Mark Maier’s SoS definition [Maier, 1998]

Laboratory System

Imaging Management

SystemPharmacy

System

PatientManagement

System

TelemetrySystem

Health Care

Network

5

SoS Taxonomy

Virtual [Maier, 1998]• Lacks a central management authority and a clear SoS purpose

Collaborative [Maier, 1998]• CS engineering teams work together, but no overarching SoSE

team to guideAcknowledged [Dahmann, 2008]• Have recognized objectives, a designated manager, and

resources at the SoS level (SoSE team)Directed [Maier, 2008]• SoS centrally managed by a government, corporate, or Lead

System Integrator (LSI) and built to fulfill specific purposes

Case Study: Regional Area Crisis Response SoS (RACRS) for Ensayo County

6

Constituent Systems

Satellite Imaging System: Provides images of interest to requestorFire Department: Manages the fire response unitsPolice Department/Sheriff’s Dept: Provides safety and crime-

fighting support/includes evacuation support and protection from looters

Handheld devices: Provides connectivity to people on the ground (fire fighters, police, sheriff deputies) via voice and video

Unmanned ground vehicle (UGV): Provides • On the ground video feeds in situations where it is too dangerous for

personnel• Clearing of brush/small trees to create fire breaks

Hazmat system: Instrumented gear to help quickly evaluate potentially hazardous situations and well as communications and video capability

7

Constituent Systems (continued)

Regional area Planning and Land Use Data: Includes building plans and maps for utilities (electricity, water, sewer) and other regional areas of interest

Command and Control Center: Central site to monitor and help coordinate activities/site to support decision makers

Aerial water tanker: State/national asset shared among multiple regional areas

News helicopter: Used to capture video feeds for news programs—includes news events as well as traffic flows, may also be used to monitor for signs of looting

Unmanned aerial vehicles (UAVs): Used for surveillance, lightweight fire retardant drops, and can also be armed to start needed backfires or fire upon looters/rioters

8

RACRS Key FeaturesGoals:

• Minimize impacts of area crises• Contain potential losses

Ability to coordinate responses to regional area crises• Classify type of crisis• Alert appropriate organizations• Alert/evacuate public• Identify and manage needed resources• Fire trucks• Airplanes• Helicopters• Robots/remotely controlled vehicles• Medical supplies/special treatment or isolation facilities

Request and coordinate support from other agencies: state, Federal, or other regional areas

Strategic partnership with local news stations for live video feedsSupport crisis management activities in other regions 9

Desired SoS capabilities…Starting point for SoS requirements identification…

RACRS Issues and Risks

Incompatible interfaces between existing systemsCOTS products available to support interconnectivity, but have not been

used at this level (potential scalability issues)Police and fire departments currently have on-going projects to

integrate the police, fire department, and 911 systemsLimited local budgets to modify other existing systemsLittle or no modifications expected for related State and Federal systems

but expectations that these will evolve• Potential impacts with interfaces to other regional area systems

Federal funds available if system implemented within the next 5 yearsBoth County Board of Supervisors and City Council need to approve

plans and budgetsCitizen privacy and security issuesPotential overlapping authorities during crises: local, state, and Federal

10

RACRS Desired Characteristics

Integrate existing legacy systems together using a net-centric architecture that includes wireless, mobile networks for mobile units and existing networks for fixed Control Center connectivity

Must work across coastal plain, intermediate mountain range, and low-lying desert area on far side of mountain range

As part of this effort, the city and county planning and land use organizations would like to replace their location tracking systems with a new system that is based on city/county records and not the more general purpose map programs/ databases typically provide by Geographic Information System (GIS) vendors

No other new system components planned for the early versions of this SoS

Build on existing connectivity• Some sort of connectivity exists between• City police, sheriff’s, 911, and ambulance systems• Jail information system and state and Federal agencies

• Most other system components are relatively closed, independent systems11

Elements to Think About

Key mission scenarios• Fires• Earthquake in Southern California• Hazardous material spill on freeway during rush hour

Feature, service, or crisis priorities—how to define early incrementsCandidate architecture(s) and increment definitions: What can be

defined as “independent projects”? How does this impact cost and schedule?

What elements require early simulation/prototyping/evaluation?Risk management: What key risks should be addressed first?Where to be agile? Where to be plan-driven?Types of oversight for various types of component system providers

• Strategic partners Suppliers• Vendors Developers

What additional assumptions/constraints are there?

12

Desired SoS Engineering Modeling Support

Understand CSs and their relationships• SoS architecture and capabilities• CS functional capabilities• Interfaces and protocols• Data elements, precision, and rates

Develop and evolve an SoS architecture• Understand current architecture• Develop target architecture to guide SoS evolution

13

Desired SoS Engineering Modeling Support (continued)

Assess CS changes• Impact to SoS architecture and capabilities

Address new requirements and options• Implementation and transition strategies for desired

capability• Impact to constituent systems

14

SysML Models that Support SoS Engineering Needs

Object classes• Characterize each SoS CS

and its capabilities• Logical data models for

each CSInterface classes• Describe each CS

interfaceInput/output entity classes• Express the associated

data attributes of each data item transferred over that interface

Use cases• Characterize both CS and

SoS capabilities from the different user perspectives

Sequence diagrams• Characterize and analyze

the operational flow for an SoS capability

15

Overview of SysML Model Capabilities with respect to SoSE

16

Understanding the user perspective

Understanding how the single system fits in the SoS environment

Understanding the key constituent systems in the SoS environment and what their single system capabilities are

Understanding the interactions between the various constituent systems within the SoS

Dynamic Modeling and Simulation (M&S) Support for SoS—Recent Survey Findings

M&S can support SoS engineering in a number of areas• Understand complex & emergent behavior of systems that interact with

each other• Provides an environment to help SoS engineering teams explore options

for creating new capability from existing systems• Analysis of architecture approaches and alternatives• Analysis of requirements and solution options

• Illuminates integration issues that can have a direct effect on the operational user

• Supports T&E when difficult or infeasible to do in other ways, particularly end-end performance

Challenges• Ensuring M&S validity• Include M&S considerations early in SE planning, including resources to

identify, develop, evolve & validate M&S to support SE and T&EBig picture from surveys (19 respondents from 14 organizations)

• Lots of potential and associated enablers/inhibitors for M&S in the SoS SE environment

• Much less experience (8 specific project experiences) with M&S in the SoS SE environment—Consistent with SoS program interviews 17

18

Example SoS: Regional Area Crisis Response SoS (RACRS)

Command Control Center (CCC) Context Diagram:Depicts scope of SoS and key relationships from CCC perspective

19

Scenarios: CCC Use Cases (by Mission Scenario)

Fire Fighting Scenario

20

Evacuate Area Sequence Diagram(SoS White Box/System Black Box)

Focus: Communications between constituents

21

Evacuate Area Alternate Sequence for Intruder “Management”

≈ ≈

22

CCC Interface Class

Focus: What data goes over each interface

23

Evacuate Area I/O Entities

Focus: For shared data/information, what are the data characteristics

24

Evacuate Area I/O Entities by Actor

Focus: How consistent is the data (data formats, precision, aging, etc.) across the constituents that must share the data

Another View for Interoperability: Logical Data Models*

DoDAF OV-7 (Logical Data Model): describes the structure of an architecture domain's system data types and the structural business process rules that govern the system data. It provides a definition of architecture domain data types, their attributes or characteristics, and their interrelationships. Important to understand data units, coordinate systems, precision, etc.

Diagramming techniques that may be used include:• Tables• IDEF• Entity-relationship diagrams• UML/SysML object diagrams

Example Logical Data Model Using UML-like Constructs

System B

System A

* From DoDAF standard

Last WordsFor large complex systems or SoS, need to focus on:• Needed capability(s) and associated prioritized requirements• What exists• Options for providing new capabilities• Associated risks and issues• Incremental “battle rhythm” for developing capabilities across set of

constituent systemsModeling tools and simulators are only a few of the tools in the engineering tool box• Learn your tools and how to best apply them• Not a “one-size-fits-all” situation• They all take time and resources to build and validate before they can

be used26

Questions

1. List a static model that can support the SoSE core element “Develop and Evolve and SoS Architecture”.

2. List a dynamic model type that can be used to support the SoSE core element “Understanding Constituent Systems and Their Relationships”.

3. List a model that is key to evaluating SoS constituent system interoperability.

27

28

References

1. Dahmann, J. and K. Baldwin. 2008. Understanding the current state of US defense systems of systems and the implications for systems engineering. Proceedings of the IEEE Systems Conference, April 7-10, in Montreal, Canada.

2. Department of Defense. 2008. Systems engineering guide for system of systems, version 1.0.

3. Maier, M. 1998. Architecting principles for systems-of-systems. Systems Engineering 1, no. 4: 267-284.

4. Valerdi, R. 2005. Constructive systems engineering cost model. PhD. Dissertation, University of Southern California.

5. Valerdi, R. and M. Wheaton. 2005. ANSI/EIA 632 as a standardized WBS for COSYSMO, AIAA-2005-7373, Proceedings of the AIAA 5th Aviation, Technology, Integration, and Operations Conference, Arlington, Virginia.

6. Wang, G., R. Valerdi, A. Ankrum, C. Millar, and G. Roedler. 2008. COSYSMO reuse extension, Proceedings of the 18th Annual International Symposium of INCOSE, The Netherlands.