INCOSE IW MBSE Workshop January 2013 1

INCOSE (MBSE)Model Based System Engineering

System of Systems and Enterprise Architecture Activity

Ron Williamson, PhD Raytheon

ron.williamson@incose.org

January 26/27, 2013INCOSE IW MBSE Workshop Breakout Session

INCOSE MBSE Wiki page: http://www.omgwiki.org/mbse

INCOSE MBSE SoS/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 2

Session… in a Nutshell• INCOSE MBSE SoS/EA Background

– http://www.omgwiki.org/MBSE/doku.php?id=mbse:enterprise– Focus on Architecture Framework Standards, SoS 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?– SoS 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 SoS’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

INCOSE MBSE Definition

3

“Model-based systems engineering (MBSE) is the formalized application of modelingformalized 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-004-02), Sept 2007

INCOSE IW MBSE Workshop January 2013

INCOSE MBSE Roadmap

2010 2020 2025

Mat

urity

MBSE Capability

Ad Hoc MBSEDocument Centric

2010

Well Defined MBSE

InstitutionalizedMBSE across Academia/Industry

Reduced cycle times Design optimization across broad trade spaceCross domain effects based analysis

System of systemsinteroperability

Extending Maturity and Capability

Distributed & secure model repositoriescrossing multiple domains

Defined MBSE theory, ontology, and formalisms

Emerging MBSE standards

Matured MBSE methods and metrics,Integrated System/HW/SW models

Architecture model integrated with Simulation, Analysis, and Visualization

•Planning & Support•Research•Standards Development•Processes, Practices, & Methods•Tools & Technology Enhancements•Outreach, Training & Education

Refer to activities inthe following areas:

Current SoS/EA Activity Focus: Mature Methods, Architecture, M&S, Formalisms

INCOSE IW MBSE Workshop January 2013

Activity TeamSystem of Systems/Enterprise Modeling

• Team Lead: Ron Williamson, Raytheon

• Team Focus Areas– OMG Unified Profile for DoDAF/MODAF (UPDM) standards

UPDM Group– OMG Architecture Ecosystem Special Interest Group AE SIG– Business Process Modeling BPMN– Service Oriented Architecture modeling SOAML– IDEAS Group IDEAS Group Website– DoD DODAF 2.0 Meta Model DM2 Website– UK MOD MODAF 1.2 Meta Model M3 Website– MODEM Dropbox– NCOIC Netcentric Patterns Netcentric Patterns Website

5

INCOSE IW MBSE Workshop January 2013 6

Mark Maier’s Architecting Principles for SoS: 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 7

Enterprise Architecture PerspectiveIDEAS Group Vocabulary

Defining a language for SoSE

INCOSE IW MBSE Workshop January 2013 8

SoS Engineering PerspectiveSoS MBSE Implications

Legacy Systems Models for behavior, interfaces, requirements, performance, e.g. SysML, Modelica, MARTE

Dynamic Reconfiguration of Architecture

Dynamic Reconfigurable models of architecture, e.g. UPDM with UML/SysML model version management

Service Oriented Architecture Enabler

SOA modeling language, e.g. SoaML, SOA Patterns

Protocols and Standards to Enable Interoperable Systems

Models for protocols, standards, interoperability, e.g. UPDM, DoDAF 2 MetaModel

Added “ilities” or Quality Attributes

Specialty Engineering models, e.g Assurance, RMAS

Federated Acquisition Models for acquisition project synergy, e.g. UPDM, MODAF, DoDAF 2 MetaModel

Independent Systems Models for independence in system functionality, e.g. Agent Based, federated models

Concept of Operations Critical Models for CONOPs including Mission, Objectives, Courses of Action, etc. e.g. UPDM Operational Viewpoint, BPMN Business Processes

Ongoing Experimentation Analysis of Alternatives models for all viewpoints and model versioning

INCOSE IW MBSE Workshop January 2013

MBSE & SoS Pain Points

• SoS Management– Lack of SoS Authorities and Funding– Constituent Systems– Leadership

• SoS Technical Issues– Autonomy and Emergence– Capabilities and Requirements– Testing, Validation and Learning– SoS Principles

9

INCOSE IW MBSE Workshop January 2013

MBSE & SoS Pain PointsSoS Management

• Lack of SoS Authorities and Funding– Business Models

• Top Down Command and Bottom Up Initiative Behavior models

– Funding Models• Service Model, CrowdSourcing, 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

10

INCOSE IW MBSE Workshop January 2013

MBSE & SoS Pain PointsSoS 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– SoS Level and Traceability

Capability, Function, Performance Models SoS Requirements Analysis Models

• Testing, Validation and Learning– Incremental, evolving

Model based testing and validation

• SoS Principles– Processes, Examples, Workflow

Process models, Model libraries, Behavior Models Visualization of SoS to detect anomalies

11

INCOSE IW MBSE Workshop January 2013

Generalized SoSE Approach….

• Start with an architecture addressing all the stakeholder viewpoints and concerns

• 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

12

PlannerOwnerDeveloperBuilderImplementerUser

Wha

tH

owW

here

Who

Whe

nW

hy

Source: NDIA Test and Evaluation Conference Tutorial March 2012

vs.

INCOSE IW MBSE Workshop January 2013 13

Please capture and hold questions until the Panel Discussions Sunday Afternoon