Modeling Systems-of-Systems and Management of Design Variations

1. Modeling Systems-of-Systems and Management of Design Variations Matthew Hause – Atego

3. Agenda • Introduction • Model Based Systems & Software Engineering (MBSE) • Systems of Systems • Asset-Based Modular Design • Model-based Product Lines • Variant Modeling • Variant Selection • Product Model Creation • Model-based Product Line Engineering (MB-PLE) • Summary

4. Starting With What’s Possible … • Applying Model-Based Product Line Engineering canReduce Total Development Costs by 62% and Deliver 23% More Projects on Time* • * (EMF 2013 Independent Survey Results from 667 Systems Engineering respondents)

5. Issues/Challenges Facing Systems Engineering Organizations • Business Based • Increasing Time Pressures • Shorter Development Cycles • Delivering on Schedule • Cost Reduction Demands • Total Development Cost • Risks/Costs associated with delays and cancellations • Larger & More Distributed Teams • Communication & Collaboration • Implementing Common, Architected Goals • Quality Assurance • Risk of Building the Wrong System • Increased Costs of Later Stage Errors

6. Issues/Challenges Facing Systems Engineering Organizations • Technical/Technology Based • Growing Complexity & Functionality of Systems & Software • Software comprises growing share of total systems Cost & Capability • System & Sub-system Integration • Certification, Regulation & Standards Compliance • The Move to ‘Systems Thinking’ – Requirements, Design, Integration, Testing

7. Agenda • Introduction • Model Based Systems & Software Engineering (MBSE) • Systems of Systems • Asset-Based Modular Design • Model-based Product Lines • Variant Modeling • Variant Selection • Product Model Creation • Model-based Product Line Engineering (MB-PLE) • Summary

8. Model-Based Engineering • 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 through-out development and later lifecycle phases.” (INCOSE, 2007). • Modeling is at the heart of all aspects of the development effort • Covers the complete product and project lifecycle • Has a direct effect on any generated artifacts. • MBE encompasses architecture, systems and software development.

9. Changes in Systems Engineering Practice Change from Document centric to Model centric Requirement Specifications Interface Definitions System Architecture System Functionality Trade-off Analysis Test Specifications Etc. Old Approach New Approach

10. 2. Behavior Interaction Definition State Machine Activity/Function Use The Four Pillars of SysML Behavior Structure Parametrics Requirements

11. allocate value binding satisfy verify Cross Connecting Model Elements Structure Behavior Requirements Parametrics

12. Agenda • Introduction • Model Based Systems & Software Engineering (MBSE) • Systems of Systems • Asset-Based Modular Design • Model-based Product Lines • Variant Modeling • Variant Selection • Product Model Creation • Model-based Product Line Engineering (MB-PLE) • Summary

13. Systems of Systems (SoS) • Increasingly important in civilian and military systems • An SoSis a “set or arrangement of systems that results when independent and useful systems are integrated into a larger system that delivers unique capabilities.” • DoD Defense Acquisition Guidebook • “Key to addressing the evolution of complex systems of systems. SE principles and tools can be used to apply systems thinking and engineering to the enterprise levels.” • FEAF, 1999

14. System of Systems Engineering • SoS systems engineering (SE) deals with planning, analyzing, organizing, and integrating the capabilities of new and existing systems into a SoS capability greater than the sum of the capabilities of its constituent parts. • SoS delivers capabilities by combining multiple collaborative and independent-yet-interacting systems. • Capabilities provide the criteria to systems engineers to determine how the different systems fit together and whether or not the SoS as a whole will meet stakeholder requirements. • Evaluation at the level of individual requirements is too low level. • Due to the complexity of these systems, an essential aspect of SoS SE is MBSE.

15. DoD Architecture Framework 2.0 Views Capability/Strategic Viewpoint Articulate the capability requirement, delivery timing, and deployed capability Operational Viewpoint Articulate operational scenarios, processes, activities & requirements Project/Acquisition Viewpoint Describes the relationships between operational and capability requirements and the various projects being implemented; Details dependencies between capability management and the Defense Acquisition System process. Standards Viewpoint Articulate applicable Operational, Business, Technical, and Industry policy, standards, guidance, constraints, and forecasts Data and Information Viewpoint Articulate the data relationships and alignment structures in the architecture content All Viewpoint Overarching aspects of architecture context that relate to all models Services Viewpoint Articulate the performers, activities, services, and their exchanges providing for, or supporting, DoD functions Systems Viewpoint Articulate the legacy systems or independent systems, their composition, interconnectivity, and context providing for, or supporting, DoD functions Renamed New New New New Architecture viewpoints are composed of data that has been organized to facilitate understanding.

16. The Unified Profile for DoDAF and MODAF (UPDM) • UPDM is a standardized way of expressing DoDAF and MODAF artefacts using UML and SysML • UPDM is NOT a new Architectural Framework • UPDM is not a methodology or a process • UPDM 2.0 supports DoDAF 2.0, MODAF 1.2, NAF 3.x, • UPDM was developed by members of the OMG with help from industry and government domain experts. • UPDM is now a DoD mandated standard • UPDM has been implemented by multiple tool vendors. • Tools supporting UPDM are available now, including of course by Atego.

17. SoS Pain Point Survey Purpose To collect information on major issues or 'pain points' in the area of Systems of Systems operation, management and systems engineering To support planning for activities of the WG • Survey Logistics • Developed during February and March 2012, with several drafts and pretests • Released to the community in April with a cutoff of respondents in Mid-May. • Administered over the internet using KWIK Surveys (www.kwiksurverys.com) • Respondents • 38 survey respondents • 65 SoS ‘pain points’ reported • Respondent location • US (86%). • UK (8%) • Australia (6%) • Respondent SoS experience • Extensive (60%) • Some (37%) • Almost all (94%) are from defense sector • Questions & Analysis • Asked respondents to identify and describe their priority SoS areas of concern: describe up to three 'pain points' including a short name, a description and an example • Results were analyzed, a paper on the results was drafted and circulated for comment

18. SoS Pain Points Survey identified seven ‘pain points’ raising a set of SoS SE questions

19. How NOT to Model Systems of Systems

20. Disaster Relief Challenge….Provide Ice: • Goals and Objectives: For the challenge, show how today’s tools can be used and integrated together to support planning, analysis, decision making, communications, and documentation and reporting while minimizing duplication of effort, or data entry. Refer to the listing of Goals and Objectives posted on the TVC page for a full listing of all Goals and Objectives to consider including as part of your demonstration. • Challenge: It is summer time in Pleasantville, a rural US town located in a temperate climate zone currently experiencing temperatures ranging between 70 – 100 degrees Fahrenheit (20-35 C). A recent natural disaster has devastated the area within a 100 mile radius. An estimated 3000 people lost their homes due to the destruction, and need to find shelter. Most roads are impassible by public so there is limited vehicle transportation and the electricity is out in most of the disaster area. As part of emergency response requirements, shelters must be set up within 24 hours from when the evacuations begin to help sustain those who need to relocate. As part of the initial emergency response, ice must be provided to sustain perishables such as medicine and foods, and to support first aid needs. Power and potable water are to be provided with the shelter solution.

21. Operational Concept for Disaster Relief

22. Operational Concept for Disaster Relief Internals

23. Dictionary of Project Capabilities

24. Capability Dependencies for Manage Environmental Incidents

25. System Structure for Disaster Response

26. System Structure for Victim Support

27. Agenda • Introduction • Model Based Systems & Software Engineering (MBSE) • Systems of Systems • Asset-Based Modular Design • Model-based Product Lines • Variant Modeling • Variant Selection • Product Model Creation • Model-based Product Line Engineering (MB-PLE) • Summary

28. Methods for Re-Use are Not New… • A standards-based Integrated, Practical & Pragmatic Solution • Combining 2 Powerful Paradigms for ‘Model-Based Product Line Engineering’ • Model-base Systems & Software Engineering (MBSE) • Extending into Variable Product Families (PLE) • with a Well Documented Value Proposition System & Software Product Lines 1960s Subroutines 1970s Modules 1980s Objects 1990s Components 2000s Services 2005+ Software Product Lines (Linda Northrop, SEI SSPL 2008-2012)

29. Asset-based Modular Design • Design the same way you Build • Construct Systems of Sub-Systems (SoS) • Use Services to build your Application (SOA) • Plug Components together (CBD) • Modular Design • Top-Down, Architected • Specification (& Requirements) Driven • Parallel Working • Separation of Concerns • Bottom-Up, Asset Mining • Un-modeled Assets • Other Modeling Tools • Legacy Integration • Published Interfaces (e.g. IDL)

30. The Reusable Asset Specification (RAS) • Defines reusable assets, their interfaces, characteristics and supporting elements. • Three dimensions describe reusable assets: • Granularity describes problems or solution alternatives a packaged asset addresses. • Variability and visibility vary from black-box assets, to white box assets, clear-box and gray-box assets. • Articulation describes the degree of completeness of the artifacts in providing the solution. • Asset specifications includes supporting documentation, requirements addressed, interfaces, etc. • A modular, multi-level approach avoids the spaghetti diagrams

31. Asset-Based Modular Design Models + Asset Library = Configuration Models System Model 1 System Model 2 Sub-System 1 Sub-System 2 Sub-System 2 Higher Level Models etc. V2.0 V3.0 V3.0 V1.0 V1.1 Asset Library Links via Assets Asset 4 Asset 1 Asset 2 Asset 3 V3.0 V2.0 Asset 1 (Sub-System Model) Asset 2 (Sub-System Model) Asset 3 (Sub-System Model) Asset 4 (Sub-System NO Model) Lower Level Models V3.0 V4.0 V2.0

32. View of Asset Library connectivity (OSLC)

33. System Overview of an Ice Plant

34. Atego Asset Library View in other model

35. Block Definition Diagram of Distiller

36. Block Definition Diagram of Types

37. Distiller model complete system

38. Addressing Pain Points • Lack of SoS Authorities and Funding • Modeling cannot provide authority or funding. • MBSE has begun to demonstrate true ROI • These techniques will provide ROI to decrease the cost of developing SoS. • The Asset library provides metrics to demonstrate cost savings for reuse. • Includes the development effort required to create the original asset, and the estimated effort to reuse the asset. • The reuse effort subtracted from the development effort provides an estimated time saving. • The overall total savings for each asset library is also summarized.

39. Addressing Pain Points • Constituent Systems • Integrating constituent systems is difficult • Clearly defined system interfaces, capabilities, requirements, behavior, characteristics, etc. is essential for any meaningful integration. • Integrating system models as black box systems, means engineers can concentrate on the individual system definitions. • With clearly defined system interfaces, development of these systems can take place in parallel without affecting the other models. • The SoS model can then examine the interaction of the individual systems as a whole.

40. Addressing Pain Points • Capabilities and Requirements • Defining systems with capabilities specifies the purpose and benefits of a system at a high level. • Capabilities describe desired outcomes as well as specifying stakeholders and realizing resources. • Architects and engineers can determine capability overlaps as well as capability gaps. • Shows how systems work together at a capability level. • Useful when no model exists of the existing system. • When models do exist, system functions and requirements they satisfy provide more detailed analysis examination.

41. Addressing Pain Points • Autonomy, Interdependencies and Emergence • Emergent behavior is often unpredictable. • The real problems of systems integration only come to light when they are integrated together in the field under real conditions. • Modeling and simulation of SoS can help, but no test or set of tests can predict all possible outcomes. • As modeling simulation techniques improve and a critical mass of system models is built up, problems involving emergent behavior can be found, diagnosed and mitigated before the systems are fielded.

42. Addressing Pain Points • Testing Validation and Learning • Paper on model-based generation of system tests. • The rail system models were developed for almost 10 years. • Complex safety critical systems involving the interaction of multiple complex systems. • Lead to ROI of 70% savings on system test. • A direct benefit to testing and validation is the black-box reuse of components. • Reused assets are not modified but simply referenced. • Reduces the chance of unintentional or even intentional modification • Provides a modular structure for testing the individual systems. • Provides supporting evidence, highlights potential problems, and increases confidence in the proposed solution.

43. Agenda • Introduction • Model Based Systems & Software Engineering (MBSE) • Systems of Systems • Asset-Based Modular Design • Model-based Product Lines • Variant Modeling • Variant Selection • Product Model Creation • Model-based Product Line Engineering (MB-PLE) • Summary

44. Enhancing MBSE with Product Line Engineering (PLE) • The Goal of PLE is to Reduce the Time, Cost and Effort required to Create, Deploy and Maintain Similar Products • By Leveraging Product & System Commonality • And Designed-in Variation (More than just Asset Reuse) • To achieve this goal, the solution must • Minimize duplicate effort • Maximize commonality • Optimize reuse across similar products • Manage product line variations and complexity • Model Based PLE offers a fundamental shift in approach • “A broader perspective that views product line engineering as designing a single system rather than as creating a multitude of products” • Designing your products as a single system can deliver considerable development cost savings (Dr Jerry Krasner, EMF 2013)

45. Model Based Systems Engineering • Package Diagram

46. Modeling Based Systems Engineering • Block Definition Diagram

47. Model Based Systems Engineering • Internal Block Diagram

48. Product Line Engineering Artisan Studio Product Line Model Artisan Studio Product Model Create Product Model Variability Model Decision Set Remaining (Unresolved) Variability Model 1 2 Variant Selector Base Model Product Base Model 3 MBSE Decision Set Editor MBSE

49. 1 - Variant Modeling • Variant Diagram • Variation on all Diagrams • Simple Notation Variation Point Variant Variability Dependency Mandatory/Optional Requires Dependency Excludes Dependency Artifact Dependency Alternate Choice • OVM • PALUNO, The Ruhr Institute of Software Technology • Software Product Line Engineering (Pohl et al - Springer 2005)

50. 2 - Variant Selection • Variant Selector • Browser User Interface • External Variation Points Only • Jump to Next Decision/Problem • Progress Bar • Decision Set Editor • Variant Debug • External & Internal Variation Points • Jump to Next Decision/Problem • Both Edit the Same Decision Sets