3 Agenda Introduction Model Based Systems & Software Engineering (MBSE) Systems of SystemsAsset-Based Modular DesignModel-based Product LinesVariant ModelingVariant SelectionProduct Model CreationModel-based Product Line Engineering (MB-PLE)Summary
4 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)
5 Issues/Challenges Facing Systems Engineering Organizations Business BasedIncreasing Time PressuresShorter Development CyclesDelivering on ScheduleCost Reduction DemandsTotal Development CostRisks/Costs associated with delays and cancellationsLarger & More Distributed TeamsCommunication & CollaborationImplementing Common, Architected GoalsQuality AssuranceRisk of Building the Wrong SystemIncreased Costs of Later Stage ErrorsGrowing Complexity & Functionality of Systems & SoftwareLarger Share of a Products Cost & Capability is SoftwareSystem & Sub-system IntegrationCertification, Regulation & Standards ComplianceThe Move to ‘Systems Thinking’ – Requirements, Design, Integration, TestingLarger & More Distributed TeamsCommunication & CollaborationImplementing Common, Architected GoalsIncreasing Time PressuresShorter Development CyclesDelivering on ScheduleQuality AssuranceRisk of Building the Wrong SystemIncreased Costs of Later Stage ErrorsCost Reduction DemandsTotal Development CostRisks & Costs of Delays or Cancellation
6 Issues/Challenges Facing Systems Engineering Organizations Technical/Technology BasedGrowing Complexity & Functionality of Systems & SoftwareSoftware comprises growing share of total systems Cost & CapabilitySystem & Sub-system IntegrationCertification, Regulation & Standards ComplianceThe Move to ‘Systems Thinking’ – Requirements, Design, Integration, TestingGrowing Complexity & Functionality of Systems & SoftwareLarger Share of a Products Cost & Capability is SoftwareSystem & Sub-system IntegrationCertification, Regulation & Standards ComplianceThe Move to ‘Systems Thinking’ – Requirements, Design, Integration, TestingLarger & More Distributed TeamsCommunication & CollaborationImplementing Common, Architected GoalsIncreasing Time PressuresShorter Development CyclesDelivering on ScheduleQuality AssuranceRisk of Building the Wrong SystemIncreased Costs of Later Stage ErrorsCost Reduction DemandsTotal Development CostRisks & Costs of Delays or Cancellation
7 Agenda Introduction Model Based Systems & Software Engineering (MBSE) Systems of SystemsAsset-Based Modular DesignModel-based Product LinesVariant ModelingVariant SelectionProduct Model CreationModel-based Product Line Engineering (MB-PLE)Summary
8 Model-Based Engineering course titleModel-Based EngineeringModel-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 effortCovers the complete product and project lifecycleHas a direct effect on any generated artifacts.MBE encompasses architecture, systems and software development.Presentation Title
9 Changes in Systems Engineering Practice Systems Engineering using SysMLChanges in Systems Engineering PracticeChange from Document centric to Model centricRequirement SpecificationsInterface DefinitionsSystem ArchitectureSystem FunctionalityTrade-off AnalysisTest SpecificationsEtc.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 ApproachNew ApproachCourse Introduction
10 The Four Pillars of SysML 2. BehaviorThe Four Pillars of SysMLBehaviorInteractionStructureUseState MachineDefinitionActivity/FunctionParametricsRequirementsStructuree.g., system hierarchies, interconnectionsBehaviore.g., function-based behaviors, state-based behaviorsPropertiese.g., parametric models, time variable attributesRequirementse.g., requirements hierarchies, traceability
11 Cross Connecting Model Elements StructureBehaviorsatisfyallocatevalue bindingRequirements4 types of cross-connecting principles:AllocationRequirement satisfaction/derivationValue Binding/ParametricsRequirement VerificationverifyParametrics
12 Agenda Introduction Model Based Systems & Software Engineering (MBSE) Systems of SystemsAsset-Based Modular DesignModel-based Product LinesVariant ModelingVariant SelectionProduct Model CreationModel-based Product Line Engineering (MB-PLE)Summary
13 Systems of Systems (SoS) Increasingly important in civilian and military systemsAn 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
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 Overarching aspects of architecture context that relate to all modelsAll ViewpointArticulate the data relationships and alignment structures in the architecture contentData and Information ViewpointArticulate applicable Operational, Business, Technical, and Industry policy, standards, guidance, constraints, and forecastsStandards ViewpointSystems ViewpointArticulate the legacy systems or independent systems, their composition, interconnectivity, and context providing for, or supporting, DoD functionsServices ViewpointArticulate the performers, activities, services, and their exchanges providing for, or supporting, DoD functionsOperational ViewpointArticulate operational scenarios, processes, activities & requirementsCapability/Strategic ViewpointArticulate the capability requirement, delivery timing, and deployed capabilityDescribes 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 ViewpointNewRenamedIn 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
16 The Unified Profile for DoDAF and MODAF (UPDM) UPDM is a standardized way of expressing DoDAF and MODAF artefacts using UML and SysMLUPDM is NOT a new Architectural FrameworkUPDM is not a methodology or a processUPDM 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 standardUPDM has been implemented by multiple tool vendors.Tools supporting UPDM are available now, including of course by Atego.
17 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 engineeringTo support planning for activities of the WGSurvey LogisticsDeveloped during February and March 2012, with several drafts and pretestsReleased to the community in April with a cutoff of respondents in Mid-May.Administered over the internet using KWIK Surveys (www.kwiksurverys.com)Respondents38 survey respondents65 SoS ‘pain points’ reportedRespondent locationUS (86%).UK (8%)Australia (6%)Respondent SoS experienceExtensive (60%)Some (37%)Almost all (94%) are from defense sectorQuestions & AnalysisAsked 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 exampleResults were analyzed, a paper on the results was drafted and circulated for comment
18 SoS Pain Points Pain Points Question Lack of SoS Authorities & FundingWhat are effective collaboration patterns in systems of systems?LeadershipWhat are the roles and characteristics of effective SoS leadership?Constituent SystemsWhat are effective approaches to integrating constituent systems into a SoS?Capabilities & RequirementsHow can SE address SoS capabilities and requirements?Autonomy, Interdependencies & EmergenceHow can SE provide methods and tools for addressing the complexities of SoS interdependencies and emergent behaviors?Testing, Validation & LearningHow can SE approach the challenges of SoS testing, including incremental validation and continuous learning in SoS?SoS PrinciplesWhat are the key SoS thinking principles, skills and supporting examples?Survey identified seven ‘pain points’ raising a set of SoS SE questions
19 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.
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 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.
22 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.
23 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.
24 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.
25 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.
26 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.
27 Agenda Introduction Model Based Systems & Software Engineering (MBSE) Systems of SystemsAsset-Based Modular DesignModel-based Product LinesVariant ModelingVariant SelectionProduct Model CreationModel-based Product Line Engineering (MB-PLE)Summary
28 Methods for Re-Use are Not New… A standards-based Integrated, Practical & Pragmatic SolutionCombining 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 Lines2005+ SoftwareProduct Lines2000sServices1990sComponents1980sObjects1970sModules1960sSubroutines
29 Asset-based Modular Design Design the same way you BuildConstruct Systems of Sub-Systems (SoS)Use Services to build your Application (SOA)Plug Components together (CBD)Modular DesignTop-Down, ArchitectedSpecification (& Requirements) DrivenParallel WorkingSeparation of ConcernsBottom-Up, Asset MiningUn-modeled AssetsOther Modeling ToolsLegacy IntegrationPublished 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
32 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.
33 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.
34 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.
37 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.
38 Addressing Pain Points Lack of SoS Authorities and FundingModeling cannot provide authority or funding.MBSE has begun to demonstrate true ROIThese 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 SystemsIntegrating constituent systems is difficultClearly 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 RequirementsDefining 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 EmergenceEmergent 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 LearningPaper 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 modificationProvides 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 SystemsAsset-Based Modular DesignModel-based Product LinesVariant ModelingVariant SelectionProduct Model CreationModel-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 toCreate, Deploy and Maintain Similar ProductsBy Leveraging Product & System CommonalityAnd Designed-in Variation (More than just Asset Reuse)To achieve this goal, the solution mustMinimize duplicate effortMaximize commonalityOptimize reuse across similar productsManage product line variations and complexityModel 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 toCreate, Deploy and Maintain Similar ProductsBy Leveraging Product & System CommonalityAnd Designed-in Variation (More than just Asset Reuse)To achieve this goal, the solution mustMinimize duplicate effortMaximize commonality among design and implementation assetsOptimize reuse of effort across similar products within each of its product linesManage product line variations and complexityModel 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
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 StudioProduct Line ModelVariability ModelBase ModelDecisionSetProduct ModelRemaining(Unresolved)ProductCreate Product ModelEditorVariantSelector123MBSE
49 1 - Variant Modeling Variant Diagram Variation on all Diagrams Simple NotationVariation PointVariantVariability DependencyMandatory/OptionalRequires DependencyExcludes DependencyArtifact DependencyAlternate ChoiceOVMPALUNO, The Ruhr Institute of Software TechnologySoftware Product Line Engineering (Pohl et al - Springer 2005)
50 2 - Variant Selection Variant Selector Decision Set Editor Browser User InterfaceExternal Variation Points OnlyJump to Next Decision/ProblemProgress BarDecision Set EditorVariant DebugExternal & Internal Variation PointsBoth Edit the Same Decision Sets
51 3 - Product Model Creation Auto-Create Product ModelsApplies Variability DecisionsUnnecessary Variation Points, Variants & Base Model Artefacts RemovedCreates New Product Model Branch, Original Product Line Model RetainedProduct Model suitable for Trade Studies, Simulation, Documentation & GenerationProduct Line ModelProduct ModelDecision Set
52 3 - Product Model Creation Auto-Create Product Models (IBD)Product Line ModelProduct ModelNo Gasoline EngineDecision Set
53 Agenda Introduction Model Based Systems & Software Engineering (MBSE) Systems of SystemsAsset-Based Modular DesignModel-based Product LinesVariant ModelingVariant SelectionProduct Model CreationModel-based Product Line Engineering (MB-PLE)Summary
54 Model-Based Product Line Engineering Publish from Sub-system model into Atego Asset LibraryWith Variation
55 Model-Based Product Line Engineering Use Sub-system from Atego Asset Library in Super-system Model (BDD)With Variation
56 Model-Based Product Line Engineering Include Asset Variation in Super-system Model Variation Design & Make DecisionsSuper-model VariationAsset Variation
57 Model-Based Product Line Engineering Create Product Model – Including Super-model and Asset VariationBoth Manual and 5 Gears selected
58 Model- Based Product Line Engineering Integrated MBSE, Modular Design & Variability Modeling = Model-based Product Line EngineeringProduct ModelProduct Line Super-system ModelSub-System 2Sub-System 1Asset LibraryAsset 1(Sub-System Model)Asset 2Asset 3Asset 4(Sub-System NO Model)Product LineModelsLinks via AssetsSub-system Product Lineetc.VVPDecision Set
59 Agenda Introduction Model Based Systems & Software Engineering (MBSE) Systems of SystemsAsset-Based Modular DesignModel-based Product LinesVariant ModelingVariant SelectionProduct Model CreationModel-based Product Line Engineering (MB-PLE)Summary
60 Development Cost Reduction & Delivery Time Improvements SE (Non-Modeled Systems Engineering)59% of Projects Delivered on TimeMBSE (Model Based Systems Engineering)62% of Projects Delivered on TimeCompared to SE55% Reduction in Total Development Cost per Project16% More Project Delivered on TimeMB-PLE (Model Based Product Line Engineering)75% of Projects Delivered on TimeCompared to MBSE17% Reduction in Total Development Cost per Project6% More Projects Delivered on Time62% Reduction in Total Development Cost per Project23% More Projects Delivered on Time(EMF 2013 Independent Survey Results from 667 Systems engineering respondents)SEMBSEMBPLEMBPLEMBSE75%SE62%59%
61 Systems of Systems have long been in existence ConclusionSystems of Systems have long been in existenceTheir inherent complexity complicates thingsModeling has both helped and hinderedSysML, UPDM, & RAS provide a standard way to model and reuse SoSMBSE provides proven ROIThis combination helps address the SoS Pain PointsProduct Line Engineering provides a means of managing product variantsModel-Based Product Line Engineering provides proven ROI