Presentation is loading. Please wait.

Presentation is loading. Please wait.

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

Similar presentations


Presentation on theme: "© 2014 Atego Modeling Systems-of-Systems and Management of Design Variations Matthew Hause – Atego."— Presentation transcript:

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

2 © 2014 Atego 2

3 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 © 2014 Atego 4 Applying Model-Based Product Line Engineering can Reduce Total Development Costs by 62% and Deliver 23% More Projects on Time* * (EMF 2013 Independent Survey Results from 667 Systems Engineering respondents) Starting With What’s Possible …

5 © 2014 Atego 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 © 2014 Atego 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 © 2014 Atego 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 © 2014 Atego 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 © 2014 Atego 9 Changes in Systems Engineering Practice Requirement Specifications Interface Definitions System Architecture System Functionality Trade-off Analysis Test Specifications Etc. Change from Document centric to Model centric Old Approach New Approach

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

11 © 2014 Atego 11 Cross Connecting Model Elements Structure Behavior Parametrics satisfy verify value binding allocate Requirements

12 © 2014 Atego 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 © 2014 Atego 13 Increasingly important in civilian and military systems – An SoS is 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 Systems of Systems (SoS)

14 © 2014 Atego 14 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. System of Systems Engineering

15 © 2014 Atego 15 DoD Architecture Framework 2.0 Views All Viewpoint Overarching aspects of architecture context that relate to all models Data and Information Viewpoint Articulate the data relationships and alignment structures in the architecture content Standards Viewpoint Articulate applicable Operational, Business, Technical, and Industry policy, standards, guidance, constraints, and forecasts Systems Viewpoint Articulate the legacy systems or independent systems, their composition, interconnectivity, and context providing for, or supporting, DoD functions Services Viewpoint Articulate the performers, activities, services, and their exchanges providing for, or supporting, DoD functions Operational Viewpoint Articulate operational scenarios, processes, activities & requirements Capability/Strategic Viewpoint Articulate the capability requirement, delivery timing, and deployed capability 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. Architecture viewpoints are composed of data that has been organized to facilitate understanding.

16 © 2014 Atego 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 International Workshop 26 Jan – 29 Jan 2013 Jacksonville, FL, USA MBSE Workshop 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 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 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)www.kwiksurverys.com 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 17

18 International Workshop 26 Jan – 29 Jan 2013 Jacksonville, FL, USA MBSE Workshop SoS Pain Points Pain PointsQuestion Lack 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 18

19 © 2014 Atego 19 How NOT to Model Systems of Systems

20 © 2014 Atego 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.TVC page 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 © 2014 Atego 21 Operational Concept for Disaster Relief

22 © 2014 Atego 22 Operational Concept for Disaster Relief Internals

23 © 2014 Atego 23 Dictionary of Project Capabilities

24 © 2014 Atego 24 Capability Dependencies for Manage Environmental Incidents

25 © 2014 Atego 25 System Structure for Disaster Response

26 © 2014 Atego 26 System Structure for Victim Support

27 © 2014 Atego 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 © 2014 Atego 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 (Linda Northrop, SEI SSPL ) System & Software Product Lines Software Product Lines 2000s Services 1990s Components 1980s Objects 1970s Modules 1960s Subroutines

29 29 © 2013 Atego 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 © 2014 Atego 30 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 The Reusable Asset Specification (RAS)

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

32 © 2014 Atego 32 View of Asset Library connectivity (OSLC)

33 © 2014 Atego 33 System Overview of an Ice Plant

34 © 2014 Atego 34 Atego Asset Library View in other model

35 © 2014 Atego 35 Block Definition Diagram of Distiller

36 © 2014 Atego 36 Block Definition Diagram of Types

37 © 2014 Atego 37 Distiller model complete system

38 © 2014 Atego 38 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. Addressing Pain Points

39 © 2014 Atego 39 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. Addressing Pain Points

40 © 2014 Atego 40 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. Addressing Pain Points

41 © 2014 Atego 41 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. Addressing Pain Points

42 © 2014 Atego 42 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. Addressing Pain Points

43 43 Copyright © 2013 Atego. 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 © 2014 Atego 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 45 Copyright © 2013 Atego. Model Based Systems Engineering  Package Diagram

46 46 Copyright © 2013 Atego. Modeling Based Systems Engineering  Block Definition Diagram

47 47 Copyright © 2013 Atego. Model Based Systems Engineering  Internal Block Diagram

48 48 Copyright © 2013 Atego. Product Line Engineering Artisan Studio Product Line Model Artisan Studio Product Line Model Variability Model Base Model Decision Set Decision Set Artisan Studio Product Model Artisan Studio Product Model Remaining (Unresolved) Variability Model Remaining (Unresolved) Variability Model Product Base Model Product Base Model Create Product Model Decision Set Editor Decision Set Editor Variant Selector Variant Selector MBSE

49 49 Copyright © 2013 Atego. 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 50 Copyright © 2013 Atego. 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

51 51 Copyright © 2013 Atego. 3 - Product Model Creation  Auto-Create Product Models -Applies Variability Decisions -Unnecessary Variation Points, Variants & Base Model Artefacts Removed  Creates New Product Model Branch, Original Product Line Model Retained  Product Model suitable for Trade Studies, Simulation, Documentation & Generation Decision Set Product Line Model Product Model

52 52 Copyright © 2013 Atego. 3 - Product Model Creation  Auto-Create Product Models (IBD) Product Line Model Decision Set No Gasoline Engine Product Model

53 53 Copyright © 2013 Atego. 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

54 54 Copyright © 2013 Atego. Model-Based Product Line Engineering  Publish from Sub-system model into Atego Asset Library − With Variation

55 55 Copyright © 2013 Atego. Model-Based Product Line Engineering  Use Sub-system from Atego Asset Library in Super-system Model (BDD) − With Variation

56 56 Copyright © 2013 Atego. Model-Based Product Line Engineering  Include Asset Variation in Super-system Model Variation Design & Make Decisions Super-model Variation Asset Variation

57 57 Copyright © 2013 Atego. Model-Based Product Line Engineering  Create Product Model – Including Super-model and Asset Variation Both Manual and 5 Gears selected

58 © 2014 Atego 58 Model- Based Product Line Engineering Product Model Product Line Super-system Model Sub-System 2 Sub-System 1 Asset Library Asset 1 (Sub-System Model) Asset 1 (Sub-System Model) Asset 2 (Sub-System Model) Asset 2 (Sub-System Model) Asset 3 (Sub-System Model) Asset 3 (Sub-System Model) Asset 4 (Sub-System NO Model) Asset 4 (Sub-System NO Model) Sub-System 2 Asset 1 Asset 2 Asset 3 Asset 4 Product Line Models Links via Assets Sub-system Product Line Models etc. V V V V V V V V V V V V V V V V VP V V Decision Set V V VP V V Decision Set V V VP V V Decision Set Integrated MBSE, Modular Design & Variability Modeling = Model-based Product Line Engineering

59 © 2014 Atego 59 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

60 60 Copyright © 2013 Atego. Development Cost Reduction & Delivery Time Improvements  SE (Non-Modeled Systems Engineering) -59% of Projects Delivered on Time  MBSE (Model Based Systems Engineering) -62% of Projects Delivered on Time Compared to SE -55% Reduction in Total Development Cost per Project -16% More Project Delivered on Time  MB-PLE (Model Based Product Line Engineering) -75% of Projects Delivered on Time Compared to MBSE -17% Reduction in Total Development Cost per Project - 6% More Projects Delivered on Time Compared to SE -62% Reduction in Total Development Cost per Project -23% More Projects Delivered on Time (EMF 2013 Independent Survey Results from 667 Systems engineering respondents) SE MBSE MBPLE SE MBSE MBPLE 59% 75% 62%

61 © 2014 Atego 61 Systems of Systems have long been in existence – Their inherent complexity complicates things Modeling has both helped and hindered SysML, UPDM, & RAS provide a standard way to model and reuse SoS – MBSE provides proven ROI This combination helps address the SoS Pain Points Product Line Engineering provides a means of managing product variants Model-Based Product Line Engineering provides proven ROI Conclusion

62 © 2014 Atego 62 Questions and Answers


Download ppt "© 2014 Atego Modeling Systems-of-Systems and Management of Design Variations Matthew Hause – Atego."

Similar presentations


Ads by Google