hardware/software integration in system-of-systems architecting: the role of systems modeling...

Hardware/Software Integration

in System-of-Systems

Architecting:

The Role of Systems Modeling

University of Southern California

Viterbi School of Engineering

Systems Architecture & Engineering (SAE)

Ken CuretonMarch 15, 2006

[email protected]@boeing.com

3/15/2006 SOS HW-SW Integration.ppt

System-of-Systems Modeling

• A Key Challenge in Systems-of-Systems Architecting:– To describe a complex system rigorously and

unambiguously– Such that the integrated system design can be

tested and verified to meet requirements• Before

generatingany code

• Beforedesigninganyhardware

THE GLOBALINFORMATIONGRID (GIG)



• Other Goals in Describing a Complex System Rigorously and Unambiguously:– Serve as a means of describing the system design

to customers– Serve as a guiding path for completing the

hardware and software design according to plan– Serve as a constant reference for measuring

progress during the design process– Detect/correct any divergence from the approved

system design– Such that the impact of inevitable design

problems are minimized



• The Reality of Systems Architecting:– There WILL be design problems!– And WHEN they occur… be detected and resolved as

early as possible in the detailed design process:• Design holes or “OSIF’s”

(Oh Shucks, I Forgot)• Unexpected interfaces, dependencies, and

couplings• “Unk-Unk’s” (unknown-unknowns)

– Unrealistic goal:• Minimize number of design changes

– More practical goal:• Accomplish a large portion of necessary design

changes in the Conceptual Design Phase• More/better “experimentation” may be

beneficial?



CO

ST

IM

PA

CT

DESIGN PROTOTYPE DEPLOYCONCEPT

DE

SIG

N F

LE

XIB

ILIT

Y

X10

X10

0

X10

00

IMPACT OF DESIGN CHANGESDURING A SYSTEM’S LIFE CYCLE

SOURCE: Design For Competitiveness Concurrent Engineering Handbook© 1992 by Bart Huthwaite, Institute For Competitive Design



• What is the Root Cause of Most Design Changes?– A study by the US General Accounting Office

showed a 4% probability of success in delivering software

• At cost and on schedule

• That actually met customer needs

– “Well, that’s what I TOLD you to do,but that’s not what I NEED you to do…”

– A 1975 study showed that a majority of software errors in delivered systems are not coding related

• Instead, they are a direct result of missing, conflicting, mis-understood, or mis-interpreted requirements



• A Few Personal Observations Regarding Design Changes:– People tend to work on the EXCITING things first

• Necessity of tangible evidence to support proposals?– “Hard” problems are too often left until the end

• More useful focus would be to tackle design challenges in priority by RISK

– Hardware choices are often “assumed” based on prior system experience, results of Research & Development, and presumed customer preferences

– All too often, the “hard” problems are left to the software developers• Who are further constrained by hardware choices

– Another key goal of the System Architect:• Accomplish the “correct” HW/SW partitioning early in

the design process, with buy-in from all stakeholders and consideration of all life cycle phases



• SysML v1.0a: One Candidate Tool to Accomplish Modeling Goals

SOURCE: http://www.sysml.org/Copyright © 2003-2006 SysML Partners



• “Executable” SysML Models– Modeled System-of-Systems can be run, tested,

debugged, and measured for performance

– Allows “execution” tovalidate the systemdesign over its life cycle

• Initially at a top level

• Increasing levels offidelity as the designmatures or is updated

THE GIG ENTERPRISESERVICES (GES)



• Is Model-Driven Architecture (MDA)“The Answer?”– Separates specification of system functionality from

specification of implementation on a specific technology platform

– Structured around some set of specific concepts

• Or is Domain-Driven Architecture (DDA)More Useful? Domain-Driven Design Premise:– Key to development is knowledge of subject matter

and finding useful ways of understanding that subject matter

– Focus on complexity of the domain itself• Not the technical architecture• Not the user interface• Not even specific features



• A Few Predictions For The Future:– The “Methods Wars” aren’t really over yet…

– The US Government will likely require detailed architecture models with all proposals

• With the goal of using them to contrast/compare proposed system performance, interoperability in a System-of-Systems, and assess Life-Cycle Risk(Cost, Schedule, and Performance)

• Witness the potential impact of the Federal Enterprise Architecture (FEA):



• The Federal Enterprise Architecture (FEA):



• For Any Complex, Comprehensive System,the System Architect Needs:– Ability to validate requirements

(i.e. ensure having the “right” requirements)– Ability to communicate a common vision

to many different people and organizations– Ability to iterate the conceptual design process to

reduce risk in subsequent states of the system’s life cycle

– Ability to contrast, compare and integrate system elements from multiple sources• Large & small, internal and external

– Ability to verify that delivered elements will smoothly integrate into the system

System-of-Systems Modeling May Bea Useful Tool in Achieving These Goals

System-of-Systems Modeling May Bea Useful Tool in Achieving These Goals

hardware/software integration in system-of-systems architecting: the role of systems modeling...

Documents

software design

approved system design

integrated system design

design challenges

design holes

competitive design slide

number of design changes

complex system