International Workshop Jan 21– 24, 2012 Jacksonville, Fl USA INCOSE IW 2012 MBSE Requirement Flowdown Workshop - Outbrief - John C. Watson Principal Member of Engineering Staff Lockheed Martin, MS2 Moorestown

International Workshop Jan 21– 24, 2012 Jacksonville, Fl USA Workshop Goal To identify the key multi-disciplinary information exchanges during a requirement flowdown process At each point of exchange identify: –What is the content of these exchanges between domains? –What are today’s challenges to do these exchanges? –How would we like to exchange data?

International Workshop Jan 21– 24, 2012 Jacksonville, Fl USA Software Models Mechanical & Electrical Models Q Q SET CLR S R Verification Models Performance, RMA, SWaP, Cost, etc.  G(s)U(s) Analytical Models The MBSE Integration Across Domains MBSE Manufacturing Program Management Product Support System Architectural Model (SAM) Test Plan Analysi s Spec Copyright © 2012 by Lockheed Martin Corporation

International Workshop Jan 21– 24, 2012 Jacksonville, Fl USA A Model Tree SoS Level - System Specification System Level - Subsystem Specification Subsystem Level - Component Specification S/W … Component Domain Model 1 H/W S/W … Component Domain Model 2 Spec 1 Spec n Spec 1 Spec 3 Spec n Spec 2Spec 1 Spec 6Spec 5Spec 4 …. Subsystem C Model Subsystem A Model Subsystem B Model Spec 2Spec 1Spec n System Model Spec S1 System of Systems Model... Component Level - Design - Implementation Copyright © 2012 by Lockheed Martin Corporation

International Workshop Jan 21– 24, 2012 Jacksonville, Fl USA Use Case Preconditions and Assumptions This use case focuses on flowing down requirements for a large complex System from the customer to a set of derived system components. It does not use a specific flowdown methodology. Customer Capabilities have been provided ConOps are available Slide 3 provides a view of a logical development environment. –The intent of this diagram is to show an abstracted logical view of the key multi-disciplinary interfaces internal and external –The MBSE red box defines our use case context. –The SAM model environment is used to flowdown requirements to the SE and design teams, mechanical, electrical and software. –Since this this use case focuses on a requirement flowdown process the interfaces to PM, Support and Manufacturing will not be included in this use case

International Workshop Jan 21– 24, 2012 Jacksonville, Fl USA Use Case Preconditions and Assumptions Slide 4 shows a model tree for an example system. –This model tree defines a project with multiple models hierarchically organized. –This model tree above the red line is contained within the SAM bubble shown in slide 3. Below the red line are the software, mechanical and electrical design teams and the implementations teams. –The Use Case context contains all models above the red dashed line. –Subsystem C (blue background) is implemented by an external contractor – The down arrows indicate a formal point of specification exchange. –Other points of exchange can be seen in slide 3, to the analysis and V&V teams –Actual systems may have more or less levels and have more or less models below it.

International Workshop Jan 21– 24, 2012 Jacksonville, Fl USA Use Case Stakeholders Define Stakeholders – –Listed below are the key stakeholders for this use case. On an actual program there can be many additional stakeholders. Actors –Customer –Software design teams –Electrical design Teams –Mechanical design Teams Internal Stakeholders –SoS SE Team - –System Level SE Team –Multiple Subsystem Design Teams –External Contractor –Test teams at each model level –Analysis Teams at each model level

International Workshop Jan 21– 24, 2012 Jacksonville, Fl USA Flowdown Requirements Use Case In this example each model is managed by a different organization and requires a formal delivery of a specification. The need for a formal specification is based on pre-arranged agreements between the two organizations. The delivery is made from the higher level model to the lower level model. Higher level models deliver specifications to one or more lower level models. Therefore at each of these specification points on the diagram a specification is delivered. The lowest level models(below the red dashed line) represent the physical components a design/implementation teams will realize.

International Workshop Jan 21– 24, 2012 Jacksonville, Fl USA Exchange Points Identified SoS to System System to Subsystem Model Subsystem to Component Model Component Model to Mechanical Design Component Model to Electrical Design Component Model to Software Design

International Workshop Jan 21– 24, 2012 Jacksonville, Fl USA Types of Exchanges that can be used at each exchange point SysML Model to a Specification Document SysML Model to SysML Model SysML Model to UML Model XMI Transfer from one model to another Compatible Tool to Tool Transfer Model API to another model API –Point to point solution transfer software

International Workshop Jan 21– 24, 2012 Jacksonville, Fl USA Non-uniform exchange environment Issues – –This is an issue common across all domain exchange points that makes many exchanges complex and unique –It is a combination of various tools and specialized programs to make point- to-point transfers. –See two previous slides identifying types of exchange points and types of exchanges possible –Many are not standards based –Many are tool specific or a customized program that needs to be maintained –Tool specific transfers require compatible versions. Upgrades to tools may cause the transfer to break –Need pre-agreed guidelines to ensure traceability across transfer point –Document exchanges Solutions: –Get stakeholder environment/management buy-in –Define a set of standard transformations between the various transfer points and types –Keep all requirements in a uniform environment. E.g. SysML

International Workshop Jan 21– 24, 2012 Jacksonville, Fl USA Time to transfer Issues – –Often the quantity of data exchanged is unnecessarily large. –Bulk transfers are done periodically on off hours if they take hours to transfer Solutions: –More efficient tool integration –Don’t do bulk transfers Transfer only what has change Transfer data changes as they are made –Derive a minimal set of standard transformations that all tool vendors conform to

International Workshop Jan 21– 24, 2012 Jacksonville, Fl USA Feedback on Delivered Spec Issues – Providing Feedback on delivered Specification (All interfaces) –The formality often prevents an easy means of providing feedback, especially with external entities such as customers and outside contractors are involved Solutions: –In an effort to minimize the first pass concerns, the receivers of the specification can work with the producing organization. –Consider this issue when deriving the delivery process.

International Workshop Jan 21– 24, 2012 Jacksonville, Fl USA Mechanical Design Exchange Issues – Are there any? Can they be identified? –There wasn’t time to get to this topic, but we can continue this dialog via the Google Docs if people are interested. Solutions:

International Workshop Jan 21– 24, 2012 Jacksonville, Fl USA Electrical Design Exchange Issues – Are there any? Can they be identified? –There wasn’t time to get to this topic, but we can continue this dialog via the Google Docs if people are interested. Solutions:

International Workshop Jan 21– 24, 2012 Jacksonville, Fl USA Specification/Requirement Terminology Issue - Definition of a specification vs. requirements –It was felt a that not all participants had a common understanding of these terms so a brief discussion tried to clarify the issue A requirement specification contains requirements and other supporting material to provide context and clarity for the contained requirements A requirement specification defines the constraints the design must satisfy A design specification describes the solution

International Workshop Jan 21– 24, 2012 Jacksonville, Fl USA Issues/Solutions Issues – Solutions:

International Workshop Jan 21– 24, 2012 Jacksonville, Fl USA Issues – Solutions:

International Workshop Jan 21– 24, 2012 Jacksonville, Fl USA Thank You