Modeling Systems-of-Systems and Management of Design Variations

Modeling Systems-of-Systems and Management of Design Variations
Matthew Hause – 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

Starting With What’s Possible …
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)

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 Growing Complexity & Functionality of Systems & Software Larger Share of a Products Cost & Capability is Software System & Sub-system Integration Certification, Regulation & Standards Compliance The Move to ‘Systems Thinking’ – Requirements, Design, Integration, Testing Larger & More Distributed Teams Communication & Collaboration Implementing Common, Architected Goals Increasing Time Pressures Shorter Development Cycles Delivering on Schedule Quality Assurance Risk of Building the Wrong System Increased Costs of Later Stage Errors Cost Reduction Demands Total Development Cost Risks & Costs of Delays or Cancellation

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 Growing Complexity & Functionality of Systems & Software Larger Share of a Products Cost & Capability is Software System & Sub-system Integration Certification, Regulation & Standards Compliance The Move to ‘Systems Thinking’ – Requirements, Design, Integration, Testing Larger & More Distributed Teams Communication & Collaboration Implementing Common, Architected Goals Increasing Time Pressures Shorter Development Cycles Delivering on Schedule Quality Assurance Risk of Building the Wrong System Increased Costs of Later Stage Errors Cost Reduction Demands Total Development Cost Risks & Costs of Delays or Cancellation

Model-Based Engineering
course title 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. Presentation Title

Changes in Systems Engineering Practice
Systems Engineering using SysML 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. There is a significant shift taking place in how systems engineers capture and hold information, with the use of integrated computer models replacing documents. Old Approach New Approach Course Introduction

The Four Pillars of SysML
2. Behavior The Four Pillars of SysML Behavior Interaction Structure Use State Machine Definition Activity/Function Parametrics Requirements Structure e.g., system hierarchies, interconnections Behavior e.g., function-based behaviors, state-based behaviors Properties e.g., parametric models, time variable attributes Requirements e.g., requirements hierarchies, traceability

Cross Connecting Model Elements
Structure Behavior satisfy allocate value binding Requirements 4 types of cross-connecting principles: Allocation Requirement satisfaction/derivation Value Binding/Parametrics Requirement Verification verify Parametrics

Systems of Systems (SoS)
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

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.

DoD Architecture Framework 2.0 Views
Overarching aspects of architecture context that relate to all models All Viewpoint Articulate the data relationships and alignment structures in the architecture content Data and Information Viewpoint Articulate applicable Operational, Business, Technical, and Industry policy, standards, guidance, constraints, and forecasts Standards Viewpoint 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 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. Project/Acquisition Viewpoint New Renamed In DODAF 2.0 we have described an expanded number of viewpoints (categories of models and views expressing differing aspects of a common architecture need) to include those shown on the slide. Some of the viewpoints were introduced in earlier versions of DoDAF, others, such as Project and Capability are new to DoDAF 2.0. An architecture viewpoint can be displayed in a number of formats, such as dashboards, fusion, textual, composite, or graphs, which represents data and the architecture description which represents an architecture. In DoDAF 2.0, the ability is provided to create an architectural description which can be expressed in many of the same formats normally used for briefing, analysis, and decision-making. The next few slides present a view of data from an architecture developed for the US Air Force at Arnold Engineering Development Center in Tennessee. This is the Air Force Center for R&D, testing and Analysis of aircraft, engines, and other components. Both Charles and I are using these views today with the permission of the Air Force. Architecture viewpoints are composed of data that has been organized to facilitate understanding. 15

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.

SoS Pain Point Survey Purpose Survey Logistics Respondents
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 ( 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

SoS Pain Points Pain Points Question
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

How NOT to Model Systems of Systems
This high level abstract diagram is used to define the context for the disaster relief. This is used to define the main elements and relationships between them. In this case, the disaster management concept and supporting elements such as the Government, Victim, Health Care Organization, etc. However, blue boxes with lines are not a good way to communicate with non-technical stakeholders.

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.

Operational Concept for Disaster Relief
This high level abstract diagram is used to define the context for the disaster relief. This is used to define the main elements and relationships between them. In this case, the disaster management concept and supporting elements such as the Government, Victim, Health Care Organization, etc. However, blue boxes with lines are not a good way to communicate with non-technical stakeholders.

Operational Concept for Disaster Relief Internals
In this case, the blue boxes have been replaced with graphics to help communicate with non-technical stakeholders. This shows the supporting elements for disaster relief such as Food Storage and Distribution, Emergency Communications, Disaster Management, and most importantly Ice Provision.

Dictionary of Project Capabilities
Rather than specify a set of systems to be delivered, system engineers specify the required capabilities and their desired outcomes. Providing ice is just part of managing a disaster. In this case, the disaster is an environmental incident. Additional capabilities will be needed such as Logistics, Communications, Cold Storage., etc. These capabilities will depend on one another and it is necessary to document the way in which this happens.

Capability Dependencies for Manage Environmental Incidents
In the context for managing environmental incidents, we have documented all the required capabilities and their dependencies. In this case, Cold Storage depends on Logistics, which depends on Temporary Storage and Security, etc. This will help to define interfaces and system dependencies.

System Structure for Disaster Response
In the systems model, the physical systems are identified that support the various capabilities. This helps to define the context for Victim Support including information and logistics.

System Structure for Victim Support
The required systems for victim support are further identified. The interfaces between these systems are identified including data, power, fuel, and water. Summary documents of these interfaces can also be generated.

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 2005+ Software Product Lines 2000s Services 1990s Components 1980s Objects 1970s Modules 1960s Subroutines

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)

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

Models + Asset Library = Configuration Models
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 1 Asset 2 Asset 3 Asset 4 V2.0 V3.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 V2.0 V3.0 V4.0

View of Asset Library connectivity (OSLC)
If I launch into the web interface of Asset Library I can see additional information such as version of the asset, and it even shows it’s structure here so I know if I want to reuse this interface before using this asset.

System Overview of an Ice Plant
Now we are going to show the system breakdown solution. Here we can see we have an IcePlant which represents all the necessary components to create ice. Including a power supply that uses fuel, water supply that uses distilled water and the central part the ice machine itself that will use all these other items and generate ice into an ice container.

Atego Asset Library View in other model
I wanted to also show how in a system we can pull from other design models to pull off interface information to be reused. I have the ability to double click on the asset and it will show in the web portal Atego Asset Library, I can also browse from one model to the other directly.

Block Definition Diagram of Distiller

Block Definition Diagram of Types

Distiller model complete system
When I look at the other model you can see it has all it’s internal structure and connections to the interface. Where I am just using the outer most interface in my final Ice calculations.

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.

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.

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.

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.

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.

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) 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 among design and implementation assets Optimize reuse of effort across similar products within each of its product lines 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

Model Based Systems Engineering
Package Diagram

Modeling Based Systems Engineering
Block Definition Diagram

Model Based Systems Engineering
Internal Block Diagram

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

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)

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

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 Product Line Model Product Model Decision Set

3 - Product Model Creation
Auto-Create Product Models (IBD) Product Line Model Product Model No Gasoline Engine Decision Set

Model-Based Product Line Engineering
Publish from Sub-system model into Atego Asset Library With Variation

Use Sub-system from Atego Asset Library in Super-system Model (BDD) With Variation

Include Asset Variation in Super-system Model Variation Design & Make Decisions Super-model Variation Asset Variation

Create Product Model – Including Super-model and Asset Variation Both Manual and 5 Gears selected

Model- Based Product Line Engineering
Integrated MBSE, Modular Design & Variability Modeling = 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 2 Asset 3 Asset 4 (Sub-System NO Model) Product Line Models Links via Assets Sub-system Product Line etc. V VP Decision Set

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 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 MBPLE MBSE 75% SE 62% 59%

Systems of Systems have long been in existence
Conclusion 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

Questions and Answers

Modeling Systems-of-Systems and Management of Design Variations

Similar presentations

Presentation on theme: "Modeling Systems-of-Systems and Management of Design Variations"— Presentation transcript:

Similar presentations

About project

Feedback

Log in

Auth with social network:

Modeling Systems-of-Systems and Management of Design Variations

Similar presentations

Presentation on theme: "Modeling Systems-of-Systems and Management of Design Variations"— Presentation transcript:

Similar presentations

About project

Feedback