1. 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 Cureton March 15, 2006 cureton@usc.edu kenneth.l.cureton@boeing.com

2. 3/15/2006SOS HW-SW Integration.ppt Page 2 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 generating any code Before designing any hardware THE GLOBAL INFORMATION GRID (GIG)

3. 3/15/2006SOS HW-SW Integration.ppt Page 3 System-of-Systems Modeling 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

4. 3/15/2006SOS HW-SW Integration.ppt Page 4 System-of-Systems Modeling 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?

5. 3/15/2006SOS HW-SW Integration.ppt Page 5 System-of-Systems Modeling COST IMPACT DESIGNPROTOTYPEDEPLOYCONCEPT DESIGN FLEXIBILITY X10 X100 X1000 IMPACT OF DESIGN CHANGES DURING A SYSTEM’S LIFE CYCLE SOURCE: Design For Competitiveness Concurrent Engineering Handbook © 1992 by Bart Huthwaite, Institute For Competitive Design

6. 3/15/2006SOS HW-SW Integration.ppt Page 6 System-of-Systems Modeling 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

7. 3/15/2006SOS HW-SW Integration.ppt Page 7 System-of-Systems Modeling 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

8. 3/15/2006SOS HW-SW Integration.ppt Page 8 System-of-Systems Modeling SysML v1.0a: One Candidate Tool to Accomplish Modeling Goals SOURCE: http://www.sysml.org/ Copyright © 2003-2006 SysML Partners

9. 3/15/2006SOS HW-SW Integration.ppt Page 9 System-of-Systems Modeling “Executable” SysML Models –Modeled System-of-Systems can be run, tested, debugged, and measured for performance –Allows “execution” to validate the system design over its life cycle Initially at a top level Increasing levels of fidelity as the design matures or is updated THE GIG ENTERPRISE SERVICES (GES)

10. 3/15/2006SOS HW-SW Integration.ppt Page 10 System-of-Systems Modeling 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

11. 3/15/2006SOS HW-SW Integration.ppt Page 11 System-of-Systems Modeling 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):

12. 3/15/2006SOS HW-SW Integration.ppt Page 12 System-of-Systems Modeling The Federal Enterprise Architecture (FEA):

13. 3/15/2006SOS HW-SW Integration.ppt Page 13 System-of-Systems Modeling 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 Be a Useful Tool in Achieving These Goals