Ron Williamson Raytheon ron.williamson@incose January 26/27, 2013

1. INCOSE (MBSE)Model Based System EngineeringSystem of Systems and Enterprise Architecture Activity Ron Williamson Raytheon ron.williamson@incose.org January 26/27, 2013 INCOSE IW MBSE Workshop Breakout Session Outbrief INCOSE MBSE Wiki page: http://www.omgwiki.org/mbse Google: incose omg wiki mbse INCOSE MBSE SoS/Enterprise Modeling Wiki page: http://www.omgwiki.org/MBSE/doku.php?id=mbse:enterprise LinkedIn Group: INCOSE MBSE SoS / EA Modeling Credits: Mark Sampson, Sanford Friedenthal, the INCOSE MBSE Team

2. Session… in a Nutshell • INCOSE MBSE SoS/EA Background • http://www.omgwiki.org/MBSE/doku.php?id=mbse:enterprise • LinkedIn Group: INCOSE MBSE SoS / EA Modeling • Focus on Architecture Framework Standards, SoS Engineering & EA Best Practices • What’s missing and how does MBSE help fill the gaps? Judith Dahmann • SoS Engineering Pain Points • How do we describe Systems of Systems & Enterprise Architectures and what’s the role of MBSE….focus on Architecture Framework Standards Matthew Hause • Beyond annotated nodes and links drawings • Beyond cartoons and lightning bolts • Beyond textual Specifications of Functionality and Performance/Quality Factors • How do we Engineer SoS’s and what is the role of MBSE (Auto/Aero Case Study) Charles Dickerson • Panel Discussion

3. SoS Defined • An SoS is defined as • “a set or arrangement of systems that results when independent and useful systems are combined into a larger system that delivers unique capabilities”. • There are four types of SoS: • Virtual • Virtual SoS lack a central management authority and a centrally agreed upon purpose for the system-of-systems. • Large-scale behavior emerges—and may be desirable—but this type of SoS must rely upon relatively invisible mechanisms to maintain it. • Collaborative • In collaborative SoS the component systems interact more or less voluntarily to fulfill agreed upon central purposes. • Acknowledged (Primary form of DoD SoS • Acknowledged SoS have recognized objectives, a designated manager, and resources for the SoS; however, the constituent systems retain their independent ownership, objectives, funding, and development and sustainment approaches. • Changes in the systems are based on collaboration between the SoS and the system. • Directed • Directed SoS’s are those in which the integrated system-of-systems is built and managed to fulfill specific purposes. • It is centrally managed during long-term operation to continue to fulfill those purposes as well as any new ones the system owners might wish to address. • The component systems maintain an ability to operate independently, but their normal operational mode is subordinated to the central managed purpose.

4. Dr. Judith DahmannSoS Pain Points Survey identified seven ‘pain points’ raising a set of SoS SE questions

5. Matthew HauseArchitecture Framework Future Problems • Systems of systems will grow in complexity and scale • Architectures will be necessary for understanding and governance • Essential for proper management and control • Tools will need to evolve to support this • Individual national support of proprietary architecture frameworks will become unsupportable • Unaffordable • Not interoperable • A barrier to communications • The ROI case for MBSE has not yet been made • Some evidence exists, but it is not yet overwhelming • PowerPoint Engineering is still the status quo

6. Matthew HauseArchitecture Framework Action List • Development of the UAF will solve many problems (but not all) • Requires immediate support and funding from national governments • A change from “individual cars” to shared transport • Local variants will be necessary • An interchange standard will be essential • Problems with PES or its replacement must be overcome • Work on interchange using RDF is looking promising • Reference Architectures need to be created and shared • At both the capability and component level • A fundamental change in process needs to happen • MBSE needs to change from “extra work” to “how things are done” • Tools need to evolve to better enable this change in process • The case for MBSE Must be made • Industry partners Must publish more success stories • Governments Must require MBSE starting with the concept phase, the bid process and throughout the acquisition lifecycle

7. Prof. Charles DickersonSummary International Workshop 26 – 29 Jan 2013 Jacksonville, FL USA • Achieve an integrated approach to ESoS engineering • ESoSE methods independent of tools and modeling languages • Use of modeling languages (e.g. SysML) • Integration with modeling and simulation tools • Case studies • The SysML HSUV as a starting point for a conceptual vehicle • Possibly evolve to a common auto-aero ESoS architecture? • Test methods, tools & approaches in case studies: prove the integrated approach is executable and repeatable ESoSE Electronic System of Systems Engineering IV&V Integration, Verification and Validation SysML Systems Modeling Language HSUV Hybrid Sport Utility Vehicle

8. Outbrief Approach • The Good • The Bad • The Ugly • Recommendations !!!

9. The Good, The Bad , The Ugly Recommendations • Good • Huge potential for MBSE to address issues • Bad • Independent and demanding to get the constituent models • Ugly • Claim can “do” it but haven’t taken time to address fundamental issues • Recommendations/Next Steps: • Outbrief topics (top 5) study/initiatives to look at the issues • Challenge study

10. The Good, The Bad , The Ugly Recommendations • Good • Have modeling language (e.g. SysML) • Bad • Not an executable language? (subset of primary model but too simple) • Ugly • Repeatable process not defined • Architecture design -> Build -> IV&V • OOSEM not well known • Not full process, method, people, solution • Need a persuasive argument • Traditional hierarchy approach doesn’t work • Need abstraction but not levels • Recommendations: • Develop reference case studies (include change over time) • Demonstrate the value proposition • Develop SoS/Enterprise trade plan • Technical, organization, etc

11. The Good, The Bad , The Ugly Recommendations • Good: • Standards for AF’s combining for interchange to support analysis, etc. (4+ ISO related standards) • Bad: • So much entrenched positions • Ugly • So many standards to choose from • Standards-based AF’s need to evolve to support Enterprise Architecture • Recommendations: • Reconcile ISO, etc. Architecture and modeling standards • Case study for value proposition for following standards • Push government and industry to use standards and save money

12. The Good, The Bad , The Ugly Recommendations • Good • Make applicable ISO standards as a starting point for progressing standards • ISO 11354 Enterprise Interoperability • Bad • Don’t have a well defined process of SoSE/EA • Ugly • Ad hoc everyone has their own approach • How to start with constituent systems • Recommend • Push standards to add process sections • Include system evolution impact on SoS evolution