ron williamson raytheon ron.williamson@incose january 26/27, 2013

INCOSE IW MBSE Workshop January 2013 1

INCOSE (MBSE)Model Based System Engineering

System of Systems and Enterprise Architecture Activity

Ron Williamson Raytheon

[email protected]

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

INCOSE MBSE Wiki page: http://www.omgwiki.org/mbseGoogle: 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 ModelingCredits: Mark Sampson, Sanford Friedenthal, the INCOSE MBSE Team

mailto:[email protected]

http://www.omgwiki.org/mbse

http://www.omgwiki.org/MBSE/doku.php?id=mbse:enterprise

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– 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

http://www.omgwiki.org/MBSE/doku.php?id=mbse:enterprise

INCOSE IW MBSE Workshop January 2013

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.

3


Dr. Judith DahmannSoS Pain Points

Pain Points QuestionLack of SoS Authorities & Funding

What are effective collaboration patterns in systems of systems?

Leadership What are the roles and characteristics of effective SoS leadership?

Constituent Systems What are effective approaches to integrating constituent systems into a SoS?

Capabilities & Requirements How can SE address SoS capabilities and requirements?

Autonomy, Interdependencies & Emergence

How can SE provide methods and tools for addressing the complexities of SoS interdependencies and emergent behaviors?

Testing, Validation & Learning How can SE approach the challenges of SoS testing, including incremental validation and continuous learning in SoS?

SoS Principles What are the key SoS thinking principles, skills and supporting examples?

Survey identified seven ‘pain points’ raising a set of SoS SE questions

4


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


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


Prof. Charles DickersonProf. Charles DickersonSummarySummary

•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

7

International Workshop26 – 29 Jan 2013Jacksonville, FL USA

ESoSE Electronic System of Systems EngineeringIV&V Integration, Verification and Validation SysML Systems Modeling LanguageHSUV Hybrid Sport Utility Vehicle


Outbrief Approach

• The Good

• The Bad

• The Ugly

• Recommendations !!!

8


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

9



• 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

10



• 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

11



• 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

12

ron williamson raytheon ron.williamson@incose january 26/27, 2013

Documents