25
System of Systems Capability-to-Requirements Engineering Jo Ann Lane University of Southern California [email protected]
System of Systems
Capability-to-Requirements
Engineering
Jo Ann Lane
University of Southern California
System of Systems Definitions
What is a “system of systems” • Very large system using a
framework or architecture to integrate constituent systems (CSs)
• Exhibits emergent behavior not otherwise achievable by CSs
• SoS 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
Types of SoS • Virtual
• Lacks a central management authority and a clear SoS purpose
• Collaborative • CS engineering teams work
together, but no overarching SoSE team to guide
• Acknowledged • Has recognized objectives, a
designated manager, and resources at the SoS level (SoSE team)
• Directed • Centrally managed by a
government, corporate, or Lead System Integrator organization
2 Based on Mark Maier’s SoS definition [Maier, 1998]
SoSE Activities and Challenges for
“Acknowledged” SoS
Key challenges • Focusing constituent systems on SoS needs and capabilities
• Coordinating development of new capabilities across constituent systems
• Creating SoS roadmap to guide constituent system activities
• Testing SoS capabilities in an asynchronous development environment
3
Translating capability objectives
Translating capability objectives
Translating capability objectives
Addressing new requirements
& options
Addressing new requirements
& options
Addressing requirements
& solution options
Understanding systems &
relationships (includes plans)
Understanding systems &
relationships (includes plans)
Understanding systems &
relationships
External Environment
Developing, evolving and maintaining
SoS design/arch
Developing, evolving and maintaining
SoS design/arch
Developing & evolving
SoS architecture
Assessing (actual)
performance to capability objectives
Assessing (actual)
performance to capability objectives
Assessing performance to capability objectives
Orchestrating upgrades
to SoS
Orchestrating upgrades
to SoS
Orchestrating upgrades
to SoS
Monitoring & assessing
changes
Monitoring & assessing
changes
Monitoring & assessing
changes
SoSE Guidebook* [1] view based on
interviews and analysis of 18 DoD
SoSs in various stages:
• Communications systems
• Command and control systems
• Integrated combat systems
• Ballistic missile defense systems
• Intelligence information systems
• Space-related systems
* http://www.acq.osd.mil/sse/docs/SE-Guide-for-SoS.pdf
SoSE Core Element Description
Translating Capability Objectives • Starts with an SoS need or new
capability
• Works to understand new
capability and alternatives for
providing it
Understanding Systems and Their
Relationships • Collects and maintains information
about current state of the SoS and
its constituent systems
Assessing Performance to Capability
Objectives • Evaluation of current performance
and how performance meets
current and future needs
Developing/Evolving SoS Architecture • Evaluation of existing SoS architecture
and identification of alternatives to
mitigate limitations and improve
performance
Monitoring and Assessing Changes • Monitoring of constituent system non-
SoS changes
Addressing Requirements and Solution
Options • Evaluation/prioritization of SoS reqs
• Evaluation of solution options and
selection of option
Orchestrating Upgrades • Oversight activity to monitor progress
of the constituent system SoS capability
upgrades and mitigate obstacles 4
Capability-to-Requirements
Engineering
Capability: High level description of a need that
is relatively independent of the constituent
systems
Goal: Starting with the identification of a needed
capability, how to identify and assess options
for decomposing capability into a set of
requirements that will eventually result in a
testable capability
5
Capabilities to Requirements
Net - Centric SoS
Net-Centric
Connectivity
Select desired capability(s)
Identify resources and viable options
Assess options
Develop and allocate requirements to
constituents
Select option
Illustrated using Regional Area Crisis Response SoS (RACRS)
6
Capabilities Engineering
Identify resources: SysML Objects
Determine options: Responsibility/ dependability modeling
Assess options: • Net-centricity/ interoperability matrices • Use cases to evaluate how •Trades with respect to data fusion needs/formats
Develop and allocate requirements to constituents
Select option
7
Methods, Processes, and Tools (MPTs)
to
Support Capability Engineering
8
MPTs to Support Capability Engineering
1. Identify general needs/capabilities
9
RACRS Needs • Primary needs
• Improve number of fire-fighting resources available to fight major
fires in the region
• Further reduce the time and number of official crisis management
personnel resources required to evacuate a specified area
• Protect evacuated areas from looters
• Related goals
• Minimize local government expense (city, county)
• Minimize risk to human life (crisis responders and local
population)
• Minimize workload on skilled personnel responsible for
responding to crisis
MPTs to Support Capability Engineering (continued )
1. Identify general need/capability 2. Use (develop) SysML object models to
identify/understand single system functions that can be used to develop new capabilities [2] • Each constituent system is modeled as an object • Functions performed by each system are object
attributes • Relationships between constituent systems are
interfaces • Interface objects describe protocols • Data objects describe data elements going across
interfaces and can be used to identify data inconsistencies in format, precision, resolution
10
Potential RACRS Resources/ Systems
Available to Support Need
Personnel • Local: fire fighters, police, and
sheriff personnel • Volunteer civilians • Military personnel at local bases • National Guard personnel • Low-risk inmates incarcerated in
local jails • TV/radio station announcers
Local government systems • Fire systems • Sheriffs systems
• 911 system • Command and Control Center • Cars • SWAT robots
• Police systems • Paramedic systems
Military systems • Unmanned aerial vehicles • Unmanned ground vehicles
Other systems • Private airplanes that can
drop fire retardant • Private helicopters that can
drop water • Canadian aerial water
tanker for major water drops (potential lease)
• Satellite and local road camera images showing crisis areas and traffic status
• Local news cast systems • Buses for evacuating people • Reverse-911 system
(potential new local government system)
• Homeowner alarm/security systems
11
SysML Modeling for SoS [2]: Identify Objects Regional Area Crisis Response SoS (RACRS)
12
Intent is to only model the SoS “objects” or aspects of interest and abstract the rest away….
MPTs to Support Capability Engineering (Continued)
3. Use “responsibility/dependability modeling” to determine possible options [3] • Shows organizations that “own” systems that one
must depend upon for cross-cutting capability options
• Shows organizations that one must share information with in order to provide desired capability
• Used to identify political/organizational dependencies and to characterize the strength/reliability/desirability of those dependencies
13
RACRS Responsibility/Dependability
Model [3]
Responsibility
Resources
Fire trucks
Sheriff cars
Water tankers
UAV Reverse 911
system Ambulances Buses Manual
Fight fire Local Regional Military
Local Canadian company
Military Local Regional Military Volunteer Low-risk inmates
Evacuate homes and businesses
Local Volunteer
Local CCC personnel
Evacuate assisted living homes
Local
Local Local CCC personnel
Local transit Charter
Assisted living staff Volunteers
Evacuate hospitals
Public Private
Hospital staff Volunteers
Prevent looters Local Military
14
Risk Target Hazard Condition Consequence Severity
1 Regional fire
trucks/fighters
Late or never
due to fires in
own region
Reduced fire-
fighting capability
More extensive fire
damage
Medium to high,
depending on other
available resources
2 Canadian
water tanker
Late or never
due to other
commitments
Reduced fire-
fighting capability
More extensive fire
damage, longer to
put fires out
Medium to high,
depending on other
available resources
3 Local fire
trucks
Unavailable due
to reallocation to
other fire
Reduced fire-
fighting capability
More extensive fire
damage, longer to
put fires out
Medium to high,
depending on other
available resources
4 Reverse 911
System
Insufficient Not all residents
notified to
evacuate
Residents at risk for
being trapped/
affected by crisis
(fire, hazardous
material, etc.)
Low to high, depending
on type of crisis requiring
evacuation
5 Low-risk
inmates
Various – may
be unskilled,
may escape
custody
Fire-fighting
capability is less
than that of
experts
Additional resources
required to train and
monitor inmates
Low severity with respect
to crisis, but medium
severity with respect to
costs associated with
training and monitoring
RACRS Responsibility/Dependability
Model [3] (continued)
15
Hazard levels: Early, Late, Never/unavailable, Incapable, Insufficient, Impaired, Changes
MPTs to Support Capability Engineering (Continued)
4. Use net-centricity/interoperability matrices to evaluate “available options” [4] • Determines the level of interoperability of
the constituent systems identified from object models and “responsibility/dependability” models
• Provides information about the level of work required to get selected constituent systems to interoperate to perform the new capability: openness, adaptability, and cost
16
Net-centricity/Interoperability
Matrices Based on LISI Model[4]
Fire-fighting Constituents
Local Regional Military Canadian Volunteer Low-risk Inmates
Local
Regional Functional
Military Isolated
Canadian Connected Connected Isolated
Volunteer Connected via handheld devices
Isolated Isolated Isolated
Low-risk Inmates
Connected via handheld devices
Isolated Isolated Isolated Connected via handheld devices
17
LISI PAID Views:
Procedures
Applications
Infrastructure
Data
LISI Levels of Interoperability:
Isolated
Connected
Functional
Domain
Enterprise
MPTs to Support Capability Engineering (Continued)
5. Develop SoS use cases and sequence
diagrams [2] to illustrate how “available
options” would work • Provides usability information of new
capability from user’s perspective
• Can be used to solicit further user input on
capability options
18
SysML Modeling for SoS [2] Regional Area Crisis Response SoS (RACRS)
19
MPTs to Support Capability Engineering (Continued)
6. For capabilities requiring data fusion, use
trades described in “SoSE Architecture
Principles for Net-Centric Multi-Int Fusion
Systems” [5] • Techniques used to guide assessment and design of
desired data fusion capabilities
• Aspects included are level of fusion, level of
centralization, and vertical/horizontal scaling
20
MPTs to Support Capability Engineering (Continued)
7. For selected options, use modeling results to
develop next level requirements and
allocation to SoS constituent systems
8. Use SoS cost modeling techniques [6] to
develop estimated engineering effort
associated with each option
21
Estimating Cost of SoS Capability
Options
22
System
Capability
CS 1 SoSE
contribution
effort
SoSE effort
Equivalent
set of
“sea-level”
requirements
Conversion to
COSYSMO size units
Calculations based on SoS
characteristics/size and capability
implementation approach using
COSYSMO [7,8] algorithm
CS n SoSE
contribution
effort
• • •
SoSE
Effort
Applies reuse factors [9], different cost factors for each engineering
organization at each system level, and diseconomy of scale for SoS
and constituent system-level requirements implemented in the same
upgrade cycle….
Summary
Existing MPTs can be re-purposed to support SoS
capability to requirements engineering
Results in a fairly rigorous technical analysis of
capability options and costs required to
implement each option
Next steps are to continue to • Refine MPTs through additional case studies
• Further investigate and refine the data fusion MPT
23
Acknowledgement
This material is based upon work supported in part by the U.S.
Department of Defense through the Systems Engineering
Research Center (SERC) under Contract H98230-08-D-0171.
SERC is a federally funded University Affiliated Research Center
managed by Stevens Institute of Technology.
24
25
References
1. Department of Defense. 2008. Systems engineering guide for system of systems, version 1.0.
2. Lane, J. and T. Bohn. 2010. Using SySML to evolve systems of systems. USC CSSE Technical Report USC-CSSE-
2010-506.
3. Greenwood, D. and I. Sommerville. 2011. Responsibility modeling for identifying sociotechnical threats to the
dependability of coalitions of systems. Proc. of the 2011 6th International Conference on Systems of Systems
Engineering, Albuquerque, New Mexico.
4. Fry, D. and D. DeLaurentis. 2011. Measuring net-centricity. Proc. of the 2011 6th International Conference on
Systems of Systems Engineering, Albuquerque, New Mexico.
5. Solano, M. 2011. SoSE architecture principles for net-centric multi-int fusion systems. Proc. of the 2011 6th
International Conference on Systems of Systems Engineering, Albuquerque, New Mexico.
6. Lane, J. 2009. Cost model extensions to support systems engineering cost estimation for complex systems and
systems of systems. 7th Annual Conference on Systems Engineering Research, Loughborough University, UK.
7. Valerdi, R. 2005. Constructive systems engineering cost model. PhD. Dissertation, University of Southern
California.
8. 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.
9. 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.
