System of Systems Engineering

and
Process Synchronization

Jo Ann Lane jolane@usc.edu

University of Southern California
Center for Software Engineering

© USC CSE 2008

 Overview

• System of Systems (SoS) and SoS Engineering

(SoSE) Environment
• Life Cycle Implications
• ICM SoS Special Case
• Process Synchronization in an SoSE Environment
• Conclusions

Lane: SoSE and Process © USC CSSE 2008 2

Synchronization
 Key Definitions

• System of Systems (SoS)

– Very large systems developed by creating a framework or architecture
to integrate constituent systems
– Typically software-intensive and net-centric
– SoS constituent systems independently developed and managed
– SoS constituent systems have their own purpose
– Constituent systems can dynamically come and go from SoS
• System of Systems Engineering (SoSE)
– “The process of planning, analyzing, organizing, and integrating the
capabilities of a mix of existing and new systems into a system-of-
systems capability that is greater than the sum of the capabilities of the
constituent parts. This processes emphasizes the process of
discovering, developing, and implementing standards that promote
interoperability among systems developed via different sponsorship,
management, and primary acquisition processes.” [USAF 2005]

Lane: SoSE and Process © USC CSSE 2008 3

Synchronization
 Recent Research Findings*
• Many types of SoS and associated modes of SoSE
– Directed (example: Future Combat Systems)
– Acknowledged (most SoSs with a defined SoSE team to guide, but not manage
constituent systems)
– Collaborative (example: Internet)
– Virtual (examples: Web/social systems)
• SoSE Teams: Varying degrees of responsibility and authority
• Incorporating many agile-like approaches to handle
– Multiple constituent systems
– Asynchronous activities and events
– Quickly take advantage of opportunities as they appear
• SoSE
– Must support multiple purposes and visions
– Requires significantly more negotiation
– Is content to satisfice rather than optimize
• SoSE activities map to traditional SE activities (e.g., DAG and EIA 632), but
take on a different focus and scope
* Based on USC CSSE SoSE cost model research and OSD SoS SE pilot studies
Lane: SoSE and Process © USC CSSE 2008 4
Synchronization
 SoSE Compared to Traditional SE Activities:
Reported Differences

• Architecting
– Architecting composability vs. decomposition (Meilich 2006)
– Net-friendly vs. hierarchical (Meilich 2006)
• Prototypes/experimentation/tradeoffs
– Early tradeoffs/evaluations of alternatives (Finley 2006)
– Intense concept phase analysis followed by continuous anticipation;
aided by ongoing experimentation (USAF 2005)
– Modeling and simulation, in particular to better understand
“emergent behaviors” (Finley 2006)
– First order tradeoffs above the component systems level (e.g.,
more optimal at the SoS level, instead of at the component system
level) (Garber 2006)
– Discovery and application of convergence protocols (USAF 2005)

Lane: SoSE and Process © USC CSSE 2008 5

Synchronization
 SoSE Compared to Traditional SE Activities:
Reported Differences (continued)

• Scope and performance

– Added “ilities” such as flexibility, adaptability, composability (USAF
2005)
– Human as part of the SoS (Siel 2006, Meilich 2006, USAF 2005)
– Organizational scope defined at runtime instead of at system
development time (Meilich 2006)
– Dynamic reconfiguration of architecture as needs change (Meilich
2006)
• Maintenance and evolution
– Component systems separately acquired and continue to be
managed as independent systems (USAF 2005)

Lane: SoSE and Process © USC CSSE 2008 6

Synchronization
 SoSE Core Elements*

Typically not the

Translating Assessing role of the SE but
Translating
Translating Assessing key to SoS
capability
capability Assessing
(actual)
(actual)
capability
objectives
objectives performance
performance
performance [assumes these
objectives to
tocapability are fixed]
to capability
capability
objectives
Orchestrating objectives
objectives
Orchestrating
Orchestrating
upgrades
upgrades
upgrades
to
toSoS Block upgrade
Understanding to SoS
SoS Developing,
Understanding
systems Developing, process for SoS
systems&&
Understanding evolving
evolvingand
Developing
and
relationships
systems &
relationships maintaining
(includes
(includes plans)
plans)
and
SoS evolving
maintaining
design/arch
relationships SoS design/arch
SoS design
Addressing
Addressing
Addressingnew
new Persistent
new
requirements
requirements framework overlay
requirements
&&options
options on systems in SoS
& solution options [architecture]

Monitoring
Monitoring
Monitoring
&&assessing Large role of
assessing
&changes
assessing
changes external influences
changes

External Environment

* [OUSD AT&L, 2008]

Lane: SoSE and Process © USC CSSE 2008 7

Synchronization
 SoSE Compared to Traditional SE Activities:
Key Challenges for DoD SoSE

• Business model and incentives to encourage working together at

the SoS level (Garber 2006)
• Doing the necessary tradeoffs at the SoS level (Garber 2006)
• Human-system integration (Siel 2006, Meilich 2006)
• Commonality of data, architecture, and business strategies at the
SoS level (Pair 2006)
• Removing multiple decision making layers (Pair 2006)
• Requiring accountability at the enterprise level (Pair 2006)
• Evolution management (Meilich 2006)
• Maturity of technology (Finley 2006)

For the most part, SoSE appears to be SE+

organized in new ways and with new challenges
Lane: SoSE and Process © USC CSSE 2008 8
Synchronization
 Life Cycle Implications

• For the SoS, the life cycle model and associated processes need to
– Identify and respond to change quickly
– Combine both rigor and agility to provide needed SoS capabilities in
the needed timeframe
– Provide for extensive modeling and simulation early on to
• Investigate alternatives and potential new technologies
• Understand potential SoS emergent behaviors
– Provide flexibility to handle the asynchronous nature of constituent
system upgrades and evolution
• For the constituent systems, the life cycle model and associate
processes need to
– Accommodate the expanding number of stakeholders as the system
becomes part of one or more SoSs
– Attempt to synchronize (to the extent possible) the implementation of
their part of SoS capabilities with other constituent systems

Lane: SoSE and Process © USC CSSE 2008 9

Synchronization
 What is the ICM?

• Risk-driven framework for tailoring system life-cycle

processes
• Integrates the strengths of phased and risk-driven spiral
process models
• Synthesizes together principles critical to successful
system development
– Commitment and accountability of system sponsors
– Success-critical stakeholder satisficing
– Incremental growth of system definition and stakeholder Principles
commitment trump
– Concurrent engineering diagrams…
– Iterative development cycles
– Risk-based activity levels and anchor point milestones

Used by 60-80% of CrossTalk Top-5 projects, 2002-2005

Lane: SoSE and Process © USC CSSE 2008 10
Synchronization
 Common Risk-Driven
Special Cases of the ICM
Special Case Example Size, Change Criticality NDI Support Org, Personnel Key Stage I Activities : Incremental Key Stage II Activities: Incremental Time per Build;
Complexity Rate % Capability Definition Development, Operations per Increment
/Month

1. Use NDI Small Accounting Complete Acquire NDI Use NDI

2. Agile E-services Low 1 – 30 Low-Med Good; Agile-ready Skip Valuation , Architecting phases Scrum plus agile methods of choice <= 1 day;
in place Med-high 2-6 weeks

3. Architected Business data Med 1 – 10 Med-High Good; Agile-ready Combine Valuation, Architecting phases. Architecture-based Scrum of Scrums 2-4 weeks;
Agile processing most in place Med-high Complete NDI preparation 2-6 months

4. Formal Security kernel; Low 0.3 Extra High None Strong formal Precise formal specification Formally-based programming language; 1-5 days;
Methods Safety-critical LSI methods formal verification 1-4 weeks
chip experience

5. HW component Multi-sensor Low 0.3 – 1 Med-Very Good; Experienced; Concurrent HW/SW engineering. CDR- IOC Development, LRIP, FRP. SW: 1-5 days;
with embedded control device High In place med-high level ICM DCR Concurrent Version N+1 engineering Market-driven
SW

6. Indivisible IOC Complete vehicle Med – High 0.3 – 1 High-Very Some in place Experienced; Determine minimum-IOC likely, Drop deferrable features to meet SW: 2-6 weeks;
platform High med-high conservative cost. Add deferrable SW conservative cost. Strong award fee for Platform: 6-18
features as risk reserve features not dropped months

7. NDI- Intensive Supply Chain Med – High 0.3 – 3 Med- Very NDI-driven NDI-experienced; Thorough NDI-suite life cycle cost-benefit Pro-active NDI evolution influencing, NDI SW: 1-4 weeks;
Management High architecture Med-high analysis, selection, concurrent upgrade synchronization System: 6-18
requirements/ architecture definition months

8. Hybrid agile / C4ISR Med – Very Mixed Mixed parts; Mixed parts Mixed parts Full ICM; encapsulated agile in high Full ICM ,three-team incremental 1-2 months;
plan-driven system High parts: Med-Very change, low-medium criticality parts (Often development, concurrent V&V, next- 9-18 months
1 – 10 High HMI, external interfaces) increment rebaselining

9. Multi-owner Net-centric military Very High Mixed Very High Many NDIs; some Related Full ICM; extensive multi-owner team Full ICM; large ongoing system/software 2-4 months; 18-
system of systems operations; Global parts: in place experience, med- building, negotiation engineering effort 24 months
Supply Chains 1 – 10 high

10. Family of Medical Device Med – Very 1–3 Med – Very Some in place Related Full ICM; Full stakeholder participation in Full ICM. Extra resources for first system, 1-2 months; 9-18
systems Product Line High High experience, med product line scoping. Strong business case version control, multi-stakeholder support months
– high

C4ISR: Command, Control, Computing, Communications, Intelligence, Surveillance, Reconnaissance. CDR: Critical Design Review.
DCR: Development Commitment Review. FRP: Full-Rate Production. HMI: Human-Machine Interface. HW: Hard ware.
IOC: Initial Operational Capability. LRIP: Low-Rate Initial Production. NDI: Non-Development Item. SW: Software
Lane: SoSE and Process © USC CSSE 2008 11
Synchronization
 Case 9: Multi-Owner SoS
• Biggest risks: all those of Case 8 plus
– Large scale, high complexity, rapid change, mixed high/low criticality, partial NDI
support, mixed personnel capability (same as Case 8-Hybrid Agile/Plan-Driven)
– Need to synchronize/integrate separately-managed, independently-evolving systems
– Extremely large-scale; deep supplier hierarchies
– Rapid adaptation to change extremely difficult
• Examples: Net-centric military operations and global supply chains
• Size/complexity: Very high
• Anticipated change rate (% per month): Mixed parts; 1-10%
• Criticality: Very high
• NDI support: Many NDIs; some in place
• Organization and personnel capability: Related experience, medium to high
• Key Stage I activities: Full ICM; extensive multi-owner teambuilding,
negotiation
• Key Stage II activities: Full ICM; large ongoing system/software engineering
effort
• Time/build: 2-4 months Time/increment:18-24 months
Lane: SoSE and Process © USC CSSE 2008 12
Synchronization
 SoSE Synchronization Points
Rebaseline/
ACR1 Adjustment ACR1 DCR1 OCR1 OCR2

SoS-Level Exploration Valuation Architecting Develop Operation 

Candidate Supplier/ LCO-type

Strategic
●
Partner n Proposal &
● Feasibility
Source ●
Info
Selection Candidate Supplier/
Strategic Partner 1

OCRx1 OCRx2 OCRx3 OCRx4 OCRx5

System x  Develop Operation Operation Operation Operation 

●
●
● ACRC DCRC OCRC1 OCRC2

System C    Exploration Valuation Architecting Develop Operation 

ACRB DCRB OCRB1 OCRB2

System B    Exploration Valuation Architecting Develop Operation 

ACRA DCRA OCRA1

System A    Exploration Valuation Architecting Develop Operation 

Lane: SoSE and Process © USC CSSE 2008 13

Synchronization
 Conclusions
• SoSE teams are evolving traditional methods to support the development and
on-going evolution of SoSs
– Early feasibility assessments and tradeoff analyses
– Knowing when to engineer and when not to engineer
• In general, leave the constituent systems engineering to the constituent
system engineers
• Constituent system monitoring to ensure that constituent system changes are
not adversely impacting the SoS
– Combining agile with traditional approaches
• Increases concurrency
• Reduces risk
• Compresses schedules
• The ICM special case for SoSs can provide both the rigor and the flexibility
needed to achieve SoS goals
• A key to success is the ability to maintain an SoS integration lab to
– Support modeling and simulation activities
– Provide for SoS incremental integrations and test
– Synchronize the roll-out of SoS capabilities
Lane: SoSE and Process © USC CSSE 2008 14
Synchronization
 Workshop Issues, Goals, and Approach

• ICM provides a tailorable framework for SoSE, but

there are many devils in the details
• Key SoSE core elements are identified in the OUSD
AT&L SoS SE Guidebook [OUSD AT&L, 2008]
– Summarized on next charts
• Proposed workshop goals and approach
– Discuss SoSE core elements in context of chart #13
– Identify, prioritize key SoSE issues
– Discuss solution approaches for top-priority issues
– Evaluate degree of payoff, difficulty of solution approaches
on 0-10 scale
– Prepare summary briefing

Lane: SoSE and Process © USC CSSE 2008 15

Synchronization
 SoSE Core Element Descriptions*
• Translating capability objectives
– Developing a basic understanding of the expectations of the SoS
and the core requirements for meeting these expectations,
independent of the systems that comprise the SoS
• Understanding systems and relationships
– In a SoS, the focus is on the systems which contribute to SoS SE
capabilities and their interrelationships (as opposed to in a system,
the focus is on boundaries and interfaces)
• Assessing actual performance to capability objectives
– Establishing SoS metrics and methods for assessing performance
and conducting evaluations of actual performance using metrics
and methods
• Developing, evolving, and maintaining an SoS architecture/design
– Establishing and maintaining a persistent framework for addressing
the evolution of the SoS to meet user needs, including possible
changes in systems functionality, performance or interfaces
* [OUSD AT&L, 2008]
Lane: SoSE and Process © USC CSSE 2008 16
Synchronization
 SoSE Core Element Descriptions*
(continued)

• Monitoring and assessing changes

– Monitoring proposed or potential changes and assessing their
impacts to:
• Identify opportunities for enhanced functionality & performance,
and
• Preclude or mitigate problems for the SoS and constituent
systems (this may include negotiating with the constituent
system over how the change is made, in order to preclude SoS
impacts)
• Addressing new requirements and options
– Reviewing, prioritizing, and determining which SoS requirements to
implement next
• Orchestrating upgrades to SoS
– Planning, facilitating, integrating, testing changes in systems to
meet SoS needs

* [OUSD AT&L, 2008]

Lane: SoSE and Process © USC CSSE 2008 17

Synchronization
 Candidate Agile Change Processing and Rebaselining
to Support Monitoring and Assessing Changes
Stabilized Agile Future-
Increment-N Increment Future Increment Change
Development Team Rebaselining Team Managers Proposers
Defer some Increment-N capabilities Propose
Proposed changes
Changes
Recommend handling
in current increment Assess Changes,
Propose Handling Recommend no action, Discuss, revise,
provide rationale
defer, or drop
Negotiate change Handle in current
disposition rebaseline

Accept changes
Formulate, analyze options
Handle in context of other changes
Accepted Recommend deferrals to future increments
Increment-N
changes Discuss, resolve deferrals to
future increments

Rebaseline Prepare for rebaselined

future-increment future-increment
LCA packages development

Lane: SoSE and Process © USC CSSE 2008 18

Synchronization
 References
Dahmann, J. (2007); “Systems of Systems Challenges for Systems Engineering”, Systems and Software Technology
Conference, June 2007.
DiMario, Mike (2006); “System of Systems Characteristics and Interoperability in Joint Command Control”,
Proceedings of the 2nd Annual System of Systems Engineering Conference
Electronic Industries Alliance (1999); EIA Standard 632: Processes for Engineering a System
Finley, James (2006); “Keynote Address”, Proceedings of the 2nd Annual System of Systems Engineering
Conference
Garber, Vitalij (2006); “Keynote Presentation”, Proceedings of the 2nd Annual System of Systems
Engineering Conference
INCOSE (2006); Systems Engineering Handbook, Version 3, INCOSE-TP-2003-002-03
Krygiel, A. (1999); Behind the Wizard’s Curtain; CCRP Publication Series, July, 1999, p. 33
Lane, J., Boehm, B., Modern Tools to Support DoD Software Intensive System of Systems Cost Estimation,
Data and Analysis Center for Software, August 2007.
Lane, J., Valerdi, R., “Synthesizing System-of-Systems Concepts for Use in Cost Modeling,” Systems
Engineering, Vol. 10, No. 4, December 2007.
Maier, M. (1998); “Architecting Principles for Systems-of-Systems”; Systems Engineering, Vol. 1, No. 4 (pp
267-284)
Meilich, Abe (2006); “System of Systems Engineering (SoSE) and Architecture Challenges in a Net Centric
Environment”, Proceedings of the 2nd Annual System of Systems Engineering Conference
Office of the Under Secretary of Defense for Acquisition, Technology and Logistics (OUSD AT&L), Systems
of Systems Systems Engineering Guide: Considerations for Systems Engineering in a System of
Systems Environment, Washington, DC: Pentagon, 2008 (forthcoming).
Pair, Major General Carlos (2006); “Keynote Presentation”, Proceedings of the 2nd Annual System of
Systems Engineering Conference
Proceedings of AFOSR SoSE Workshop, Sponsored by Purdue University, 17-18 May 2006
Proceedings of Society for Design and Process Science 9th World Conference on Integrated Design and
Process Technology, San Diego, CA, 25-30 June 2006
Siel, Carl (2006); “Keynote Presentation”, Proceedings of the 2nd Annual System of Systems Engineering
Conference
United States Air Force Scientific Advisory Board (2005); Report on System-of-Systems Engineering for Air
Force Capability Development; Public Release SAB-TR-05-04

Lane: SoSE and Process © USC CSSE 2008 19

Synchronization