INCOSE MBSE Model Based System Engineering System of

INCOSE (MBSE) Model Based System Engineering System of Systems and Enterprise Architecture Activity Ron Williamson, Ph. D Raytheon ron. williamson@incose. org January 26/27, 2013 INCOSE IW MBSE Workshop Breakout Session INCOSE MBSE Wiki page: http: //www. omgwiki. org/mbse INCOSE MBSE So. S/Enterprise Modeling Wiki page: http: //www. omgwiki. org/MBSE/doku. php? id=mbse: enterprise Credits: Mark Sampson, Sanford Friedenthal, the INCOSE MBSE Team INCOSE IW MBSE Workshop January 2013 1

Session… in a Nutshell • INCOSE MBSE So. S/EA Background – http: //www. omgwiki. org/MBSE/doku. php? id=mbse: enterprise – Focus on Architecture Framework Standards, So. S Engineering Best Practices – Modeling & Simulation role aligned with MBSE static and dynamic models • How do we describe Systems of Systems & Enterprise Architectures and what’s the role of MBSE? – Beyond annotated nodes and links drawings – Beyond cartoons and lightning bolts – Beyond textual Specifications of Functionality and Performance/Quality Factors • What’s missing and how does MBSE help fill the gaps? – So. S Engineering Pain Points – As EE and Mechanical components became more complex, CAD/CAM became fundamental to conceiving, designing and manufacturing the components – As Systems become more complex…. what is the CAD/CAM equivalent? • Is the CAD/CAM analogy accurate? • How do we Engineer So. S’s and what is the role of MBSE – – Start with an architecture addressing all the stakeholder viewpoints and concerns Identify existing systems as nodes and assess quality attributes across nodes Design the “interoperability layer” or glue to enable inter node communications Integrate, Verify and Validate expected behaviors and quality attributes INCOSE IW MBSE Workshop January 2013 2

INCOSE MBSE Definition “Model-based systems engineering (MBSE) is the formalized application of modeling to support system requirements, design, analysis, verification and validation activities beginning in the conceptual design phase and continuing throughout development and later life cycle phases. ” INCOSE SE Vision 2020 (INCOSE-TP-2004 -02), Sept 2007 INCOSE IW MBSE Workshop January 2013 3

INCOSE MBSE Roadmap MBSE Capability Reduced cycle times System of systems interoperability Design optimization across broad trade space Cross domain effects based analysis Extending Maturity and Capability Institutionalized MBSE across Academia/Industry Distributed & secure model repositories crossing multiple domains Well Defined MBSE Maturity Defined MBSE theory, ontology, and formalisms Architecture model integrated with Simulation, Analysis, and Visualization Matured MBSE methods and metrics, Integrated System/HW/SW models Ad Hoc MBSE Document Centric Emerging MBSE standards 2010 Refer to activities in the following areas: • Planning & Support • Research • Standards Development • Processes, Practices, & Methods • Tools & Technology Enhancements • Outreach, Training & Education 2020 2025 Current So. S/EA Activity Focus: Mature Methods, Architecture, M&S, Formalisms INCOSE IW MBSE Workshop January 2013

Activity Team System of Systems/Enterprise Modeling • Team Lead: Ron Williamson, Raytheon • Team Focus Areas – OMG Unified Profile for Do. DAF/MODAF (UPDM) standards UPDM Group – OMG Architecture Ecosystem Special Interest Group AE SIG – Business Process Modeling BPMN – Service Oriented Architecture modeling SOAML – IDEAS Group Website – Do. D DODAF 2. 0 Meta Model DM 2 Website – UK MODAF 1. 2 Meta Model M 3 Website – MODEM Dropbox – NCOIC Netcentric Patterns Website INCOSE IW MBSE Workshop January 2013 5

Mark Maier’s Architecting Principles for So. S: Characteristics • Five principal characteristics are useful in distinguishing very large and complex but monolithic systems from true systems-of-systems. – Operational Independence of the Elements: • • If the system-of-systems is disassembled into its component systems the component systems must be able to usefully operate independently. The system-of-systems is composed of systems which are independent and useful in their own right. – Managerial Independence of the Elements: • • The component systems not only can operate independently, they do operate independently. The component systems are separately acquired and integrated but maintain a continuing operational existence independent of the system-of- systems. – Evolutionary Development: • The system-of-systems does not appear fully formed. Its development and existence is evolutionary with functions and purposes added, removed, and modified with experience. – Emergent Behavior: • • The system performs functions and carries out purposes that do not reside in any component system. These behaviors are emergent properties of the entire system-of-systems and cannot be localized to any component system. The principal purposes of the systems-of-systems are fulfilled by these behaviors. – Geographic Distribution: • • The geographic extent of the component systems is large. Large is a nebulous and relative concept as communication capabilities increase, but at a minimum it means that the components can readily exchange only information and not substantial quantities of mass or energy. INCOSE IW MBSE Workshop January 2013 6

Enterprise Architecture Perspective IDEAS Group Vocabulary Defining a language for So. SE INCOSE IW MBSE Workshop January 2013 7

So. S Engineering Perspective So. S MBSE Implications Legacy Systems Dynamic Reconfiguration of Architecture Service Oriented Architecture Enabler SOA modeling language, e. g. Soa. ML, SOA Patterns Protocols and Standards to Enable Interoperable Systems Models for protocols, standards, interoperability, e. g. UPDM, Do. DAF 2 Meta. Model Added “ilities” or Quality Attributes Federated Acquisition Specialty Engineering models, e. g Assurance, RMAS Independent Systems Models for acquisition project synergy, e. g. UPDM, MODAF, Do. DAF 2 Meta. Models for independence in system functionality, e. g. Agent Based, federated models Models for CONOPs including Mission, Objectives, Courses of Action, etc. e. g. UPDM Operational Viewpoint, BPMN Business Processes Analysis of Alternatives models for all viewpoints and model versioning Concept of Operations Critical Ongoing Experimentation INCOSE IW MBSE Workshop January 2013 Models for behavior, interfaces, requirements, performance, e. g. Sys. ML, Modelica, MARTE Dynamic Reconfigurable models of architecture, e. g. UPDM with UML/Sys. ML model version management 8

MBSE & So. S Pain Points • So. S Management – Lack of So. S Authorities and Funding – Constituent Systems – Leadership • So. S Technical Issues – – Autonomy and Emergence Capabilities and Requirements Testing, Validation and Learning So. S Principles INCOSE IW MBSE Workshop January 2013 9

MBSE & So. S Pain Points So. S Management • Lack of So. S Authorities and Funding – Business Models • Top Down Command Bottom Up Initiative – Behavior models – Funding Models • Service Model, Crowd. Sourcing, Traditional – Economic Models • Constituent Systems Perspectives – Coordination and Management of Independent Systems • Collaboration Models, Change Sensitivity Analysis Models • Monte Carlo Based Emergence Models • Leadership – Multiple Organizations • Organizational Collaboration Models INCOSE IW MBSE Workshop January 2013 10

MBSE & So. S Pain Points So. S Technical Issues • Autonomy and Emergence – Expected behaviors based on combination of systems • Monte Carlo Based Emergence Models, Constraint Models • Interdependency Models (node-link analysis), Vulnerability/Fault Analysis Models • Capabilities and Requirements – So. S Level and Traceability • Capability, Function, Performance Models • So. S Requirements Analysis Models • Testing, Validation and Learning – Incremental, evolving • Model based testing and validation • So. S Principles – Processes, Examples, Workflow • Process models, Model libraries, Behavior Models • Visualization of So. S to detect anomalies INCOSE IW MBSE Workshop January 2013 11

Generalized So. SE Approach…. Start with an architecture addressing all the stakeholder viewpoints and concerns What How Where Who When Why • Planner Owner Developer Builder Implementer User • Identify existing systems as nodes and assess interoperability and other quality attributes across nodes • Design the “interoperability layer” or glue to enable inter node communications • Integrate, Verify and Validate expected behaviors and quality & mitigate unexpected behaviors vs. INCOSE IW MBSE Workshop January 2013 Source: NDIA Test and Evaluation Conference Tutorial March 2012 12

Please capture and hold questions until the Panel Discussions Sunday Afternoon INCOSE IW MBSE Workshop January 2013 13