Hardware Software Integration in System-of-Systems Architecting The Role of

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

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 3/15/2006 SOS HW-SW Integration. ppt 3

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

System-of-Systems Modeling DESIGN FLEXIBILITY X 1000 X 10 COST IMPACT OF DESIGN CHANGES DURING A SYSTEM’S LIFE CYCLE CONCEPT DESIGN PROTOTYPEDEPLOY SOURCE: Design For Competitiveness Concurrent Engineering Handbo © 1992 by Bart Huthwaite, Institute For Competitive Design 3/15/2006 SOS HW-SW Integration. ppt 5

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 3/15/2006 SOS HW-SW Integration. ppt 6

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 3/15/2006 SOS HW-SW Integration. ppt 7

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

System-of-Systems Modeling • “Executable” Sys. ML 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) 3/15/2006 SOS HW-SW Integration. ppt 9

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 3/15/2006 SOS HW-SW Integration. ppt 10

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

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

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 3/15/2006 SOS HW-SW Integration. ppt 13