wma incose - rick steiner111/9/99 model driven system design (mdsd) workshop rick steiner raytheon...

WMA INCOSE - Rick Steiner 111/9/99

Model Driven System Design (MDSD) Workshop

Rick SteinerRaytheon Systems Company, San Diego CA

[email protected]


Objectives of this Discussion

• Introduce Model Driven System Design concepts

• Interactively discuss how MDSD might apply in your workplace

• Identify potential ways INCOSE MDSDWG can help

– discuss ongoing MDSDWG activities

– forum for feedback


Model Driven - A Distinct Approach

• Distinction between approaches– Document Driven

– traditional approach, SE focus on “specifications” – Requirement Driven

– database approach - manage design by declarative statements– Model Driven

– manage design using highly interconnected descriptive objects

• Process implications of MDSD– products shift from being documents to being models– customer view into design shifts from being specifications to being report

routines/viewers into design database, or scenarios in which models execute

• It’s clear we want model based approach (or is it?)– System Model should include entire “body of knowledge” developed as part

program - this can be a BIG DEAL, and CM nightmare!– is not stand-alone set of simulations– is not independent from PDM


Technical Management Approach Options

Management By: Manual

Tra

ceT

rigger

from

Lin

ksM

ulti

ple

Conte

xt

1) Document (Traditional - monolithic specs) L H X2) Text Objects (Modern - flexible linkages) M M X X3) Models (Visionary - objects participate in multiple models) H L X X

Sem

antic

know

ledge

captu

red in

DB

Desi

gn I

tera

tion T

ime

Change

Impact

Ass

ess

-

ment:


Interconnected System of Models

ObjClass

Obj 1 Obj 2Rel 1-2

Synthesis/Physical Model

Fcn 1

Fcn 2 Fcn 4

Fcn 3

Fcn 5

Task 1 Task 2.1 Task 31 2

start

end

&

&

Item 1

Task 2.2

Item 2

Attr 1.1Attr 1.2

Attr 2.1Attr 2.2Attr 2.3

Function/LogicalModel

Time-phased Deployent Model

Product @State 1

Product @State 2

Requirements

(includes cost)


Architectural and Analytical Models

• “Architectural Model” is different than “Analytical Model”– Architectural models emphasize how pieces fit together into cohesive

whole– functions, info flow, interfaces, components/objects– need for rigor to ensure “cohesion”– is a vehicle to “hang” & integrate analysis products

– Analytical models emphasize specific aspect of performance– MOE, MOP, KPP– timing, Phit, MTBF, Cost

• What is “Cohesion”? Why important?– how well the individual pieces hang together, how tightly related they are, how

well balanced the design is– this is obvious in mechanical design/CAD, less obvious in complex system design

– the most important aspect of design is ensuring that the parts work together to meet ALL overall objectives


Representation of Architectures

• Architectural Model needs to incorporate Behavior, Strucuture/Objects, and Allocation

– Behavior has to do with action– functions (verbs)– inputs & outputs (messages, material)

– Structure has to do with “pieces” or components– objects (nouns)

– Allocation describes what piece/component exercises which function

• Segregating behavior from structure is essential to keeping options open, making room for innovation!

– Reallocation of functions to different objects– Aggregating functions a different way for efficiency– Reuse of functions or objects in different places


Segregation of form & function is key SE principle

– OOA/D folks will disagree… they are wrong!!– Functional analysis is an essential aspect of system level

definition. Functional design is the integration of threads, or use cases, into a cohesive behavior.

– Function = measure. – “If you don’t measure your product, how do you know

when you are finished?” - P. W. Klipsch

– Use cases are, by definition, incomplete– they are threads, not integrated behavior


Behavioral Model

f1 f2

&

d1

f3

&

d2

d3

• f1, f2, f3 are functions (verbs)– perform surveillance of battle

space

• d1, d2, d3 are items (nouns) that pass between functions

– inputs, outputs, controls, and mechanisms

• a rigorous description can be used, which is “executable”

• no nouns are used to describe what components or objects accomplish the function!

– “aircraft” or “RC135” doesn’t appear in behavior model


“Structural” or Object Model

• boxes represent objects (structural elements)– these are nouns

• diamonds show aggregation– e.g. vehicle

propulsion– engine

• red lines/dots show interconnects & interfaces

• class structure not shown– e.g. surveillance asset

surveillance aircraft (abstract)– RC135 (specific)

SystemAlternative

B

2.0 3.01.0

1.1 1.2 41 4.2 4.3

4.0


Allocation of Behavior to Structure is key to avoiding point solution

f1 f2

&

d1

f3

&

d2

d3

SystemAlternative

B

2.0 3.01.0

1.1 1.2 41 4.2 4.3

4.0

• functions allocated to objects/components• items (I/O) allocated to interfaces• a given behavioral model may have allocation to more than

one structural (object) model alternative


Levels of Abstraction - Recursive Referencing

Supersystem

System under consideration

Subsystem Subsystem

• One engineer’s design decision is another engineer’s requirement

• Boundaries of the boxes establish the context


Architectural Model is Hierarchical

f1 f2

&

d1

f3

&

d2

d3

systemalternative

2.0 3.01.0

1.1 1.2 41 4.2 4.3

4.0

f1 f2

&

d1

f3

&

d2

d3

systemalternative

2.0 3.01.0

1.1 1.2 41 4.2 4.3

4.0

f1 f2

&

d1

f3

&

d2

d3

systemalternative

2.0 3.01.0

1.1 1.2 41 4.2 4.3

4.0

Architecture A

• Each level of decomposition forms the context for the next level down

– Architectural models at each level rely on inputs & outputs from higher level

• Integration of models occurs periodically

– some design may occur at lower levels without needing to “roll it all up”

– integration is critical part of change management process

• Will want to “execute” at different levels - not always at top level!


Tiers of Architectural ModelsScenario #1

f1 f2

&

d1

f3

&

d2

d3

system/subsystemalternative

2.0 3.01.0

1.1 1.2 41 4.2 4.3

4.0

MissionAnalysis - threads ofbehavior

System Contexts(integrated missions,different weightings

or emphasis)

Scenario #2

f1 f2

&

d1

f3

&

d2

d3


2.0 3.01.0

1.1 1.2 41 4.2 4.3

4.0

Scenario #3

f1 f2

&

d1

f3

&

d2

d3


2.0 3.01.0

1.1 1.2 41 4.2 4.3

4.0

Integrated Context #1

f1 f2

&

d1

f3

&

d2

d3


2.0 3.01.0

1.1 1.2 41 4.2 4.3

4.0

Integrated Context #2

f1 f2

&

d1

f3

&

d2

d3


2.0 3.01.0

1.1 1.2 41 4.2 4.3

4.0

System Arch #A

f1 f2

&

d1

f3

&

d2

d3


2.0 3.01.0

1.1 1.2 41 4.2 4.3

4.0

System Arch #B

f1 f2

&

d1

f3

&

d2

d3


2.0 3.01.0

1.1 1.2 41 4.2 4.3

4.0

SystemAlternatives

Sensor Alt #1

f1 f2

&

d1

f3

&

d2

d3


2.0 3.01.0

1.1 1.2 41 4.2 4.3

4.0

Sensor Alt #2

f1 f2

&

d1

f3

&

d2

d3


2.0 3.01.0

1.1 1.2 41 4.2 4.3

4.0

Processor Alt #1

f1 f2

&

d1

f3

&

d2

d3


2.0 3.01.0

1.1 1.2 41 4.2 4.3

4.0

SubsystemAlternatives


Sys Arch Model B

f1 f2

&

d1

f3

&

d2

d3


2.0 3.01.0

1.1 1.2 41 4.2 4.3

4.0

Relationships Between System Models & Scenarios

Sys Design Context

f1 f2

&

d1

f3

&

d2

d3


2.0 3.01.0

1.1 1.2 41 4.2 4.3

4.0

Sys Design Context #1

f1 f2

&

d1

f3

&

d2

d3


2.0 3.01.0

1.1 1.2 41 4.2 4.3

4.0

Sys Arch Alt (A)

f1 f2

&

d1

f3

&

d2

d3


2.0 3.01.0

1.1 1.2 41 4.2 4.3

4.0

Integrated Scn #2

f1 f2

&

d1

f3

&

d2

d3


2.0 3.01.0

1.1 1.2 41 4.2 4.3

4.0

Integrated Scn #1

f1 f2

&

d1

f3

&

d2

d3


2.0 3.01.0

1.1 1.2 41 4.2 4.3

4.0

Sensor Alt #1

f1 f2

&

d1

f3

&

d2

d3


2.0 3.01.0

1.1 1.2 41 4.2 4.3

4.0

Sensor Alt #2

f1 f2

&

d1

f3

&

d2

d3


2.0 3.01.0

1.1 1.2 41 4.2 4.3

4.0

Processor Alt #1

f1 f2

&

d1

f3

&

d2

d3


2.0 3.01.0

1.1 1.2 41 4.2 4.3

4.0

Mission ScenarioModels

Architecture Development Models

Scenario #3

f1 f2

&

d1

f3

&

d2

d3


2.0 3.01.0

1.1 1.2 41 4.2 4.3

4.0

Scenario #2

f1 f2

&

d1

f3

&

d2

d3


2.0 3.01.0

1.1 1.2 41 4.2 4.3

4.0

Scenario #1

f1 f2

&

d1

f3

&

d2

d3


2.0 3.01.0

1.1 1.2 41 4.2 4.3

4.0

Source Mission Requirements

missionintegrationconcepts

Alternatives for minimum essential system interfaces

Architecture model validation


Discussion Points

• What are the technical benefits of Model Driven System Design?

• What are the technical risks and/or downsides to the MDSD approach?

• What criteria could be used to determine if an MDSD approach is technically appropriate to your project?


Models and the Joint Technical Architecture

OperationalModels(holisticfunction)

TechnicalModels

(specificfunction)

SystemModels

(archetypeform)

Mission Models

Synthesis Models

Engagement Models

Radar Models

Sensor Models

Network Models

Human Performance Models

HSI Models

3D CAD models Structure Models

PWBS

Manning Models

Information Models Interface Models


Model Interfaces

OperationalModels

TechnicalModels

SystemModels

MOEs,

Technology MOPs

TechnologyWatch-list

System MOPsand Key Technologies


Requirements & Model Interrelationships

OperationalModels

TechnicalModels

SystemModels

OperationalRequirements

TechnicalRequirements

SystemRequirements


Transition to Model Based

Implementation success depends on• Producing organization maturity (CM of model)• Customer maturity (acceptance of model as control of design)

Tightly Integrated

time

Requirement Database

Isolated Models

Constraint Database

Integrated Models

Loosely coupled

Document Based

Text Object Based(e.g. Requirements Database)

Model Based

Specifications


environmentmission &

models

RequirementsAnalysis

FunctionalAnalysis &

RequirementsAllocation

Synthesis &Verification

SystemAnalysis &

Control

CustomerDialog,Specs

SimulationMission

Change Control

FunctionalModeling

ModelIntegration

SystemSimulation

r,c,&b

r,c,&b

requirements, constraints & budgets

risks & opporunities

r&o

r&o

r&o

SynthesisModeling

(System, CAD,cost, etc.)

TestFacilities

functionalmodels

functionalimplications

formimplications

formmodels& costimpacts

formimplications

EIA 632 SE Process IDEFØ w/ Models

• All four activities happen in parallel• Risk Management & CAIV are integral to process• Process is applied iteratively at each level of design


Technical Management: the focus of the SEMP

• Manage system definition activity– across multiple levels of detail (levels of abstraction)

– theater level– system level– subsystem level

– across multiple alternatives– early alternatives will be addressed at ALL levels of abstraction

– theater/mission– system context– subsystem

– across “operational, system, & technical” views (JTA)– across IPTs, horizontal & vertical

• Includes coordination of– models– requirements– other design products


SEMP sets approach and criteria for collaborative design

• System level approach to:– aggregation of design products– evaluation of aggregated designs

• Set criteria for assessing:– aggregate design completeness– detail design completeness– design consistency

• SEMP may be updated from one design cycle to the next

• SEMP defines which IPTs contribute, which evaluate


Core SE process vs. Process Framework (meta process)

• Definitions– Core SE Process is that generic process used by each IPT during

each PDC for each level of design– Process framework is used to coordinate design activities between

IPTs and between PDCs


• This is a generic framework

• Needs tailoring• SEMP is the vehicle for

making this happen!

Example: SE Process Framework (Oliver)


• Again, this needs tailoring

Example: SE Core Process model


Process Framework for technical management

• Incorporates & relates– SE core process– trade study process– risk management process– CAIV process– technical decision making process– modeling & simulation process

• Must simultaneously manage– multiple views of product (operational (behavioral), system

(structural), technical (standards, evolution))– multiple levels of detail (or “levels of abstraction”)– multiple alternatives system implementation (broad trade space)


Process Framework & Development Cycles

• periodic assessment across system design “body of knowledge” (design products, a.k.a. deliverable models)

• evaluate to pre-determined assessment criteria for each design cycle– Completeness of design products– Consistency of design products

• “rule based” approach - – don’t try to define every minute process step in advance– concentrate on rules for how steps are conducted– leave responsibility for defining low level process and execution with

IPTs


Alternatives & Concurrency

• Management of alternatives– each alternative developed must fit into

– Operational, system, technical view– each alternative must fit within appropriate level of abstraction (level

of detail)– Requirements allocation is vehicle for ensuring consistency

– consistent with design decisions at higher level– sets derived requirements for lower level

• Process Framework and concurrent design– multiple levels of abstraction simultaneously

– not top-down or bottom-up - “All at once”!– completeness and consistency demand linkage to other levels


• 3 views are:– operational– system– technical

• discussed on next chart

Design Cycle Iteration


Develop 3 Views

• views are artifacts of the core process

• relationship between core SE process and process framework may be unique to each team


Example - Criteria for a Design Cycle

• Completeness criteria: – source requirements parsed– approach to theater and system level modeling defined

– system baseline 0 structure– initial theater level modeling approach identified– scope of alternatives identified

– all major IMP plans released– SEMP, M&S plan, ...

– initial design infrastructure functionality deployed

• Consistency criteria:– all functional elements linked to source requirements– unallocated source requirements identified– any identified alternatives are linked to baseline product structures


Discussion Points

• How are process metrics different in MDSD?

• What would an MDSD SEMP include? How would it be different?

• What criteria should be used to evaluate the organizational readiness for MDSD?

• How can the benefits of MDSD be quantified, and/or the cost justified?


An Integrated Architecture “Model”

EnduringTransitoryA

bstr

act

Con

cret

e

Behavioral

Structu

ral

Ideally, this entire space should be filled by the system architecture concept:

A Solid Cube!

View

Ab

stra

ctio

nPermanence

We need a way to identify things that are inconsistent or missing!


Abstraction Axis

• Continuum from Abstract to Concrete– Abstract - design guidelines, integration principles, “vision”

of product– concept level, understandable by user or customer

– Concrete - implementable design– buildable by domain specialist

• Abstraction across views– layers of consistent form & function

• Abstraction across permanence– discrete points for identifying reuse

Abs

trac

tC

oncr

ete

Ab

stra

ctio

n


View Axis

• Two relevant aspects: Structure (form) and Behavior (function).

– Many other views, most are sub-setsof these two (Wright ADL, Oliver)

– Behavior: states, modes, functions, information models, input/output relationships, transfer functions, software performance models

– use cases and interaction diagrams are only partial descriptions of behavior– integration of these threads yields system behavior, and engineering is required to do that

– Structure: components, interfaces, pinouts, voltages, software modules, hardware & software configuration items

– software is buildable, hence it is “structure”. It must be tested to behavioral requirements.

• Consistency of form & function architectures at a given level of abstraction and/or detail

ViewBehavio

ral

Structu

ral


Abstraction - View Plane• “Traditional” SE approach starts

“abstract” and ends “concrete”, BUT: – Need to deal with multiple levels of abstraction

simultaneously– Need to control “rigidity” of design, which

changes over time within each abstraction level

• B & S balance at each progressive level of abstraction

– Completion and Consistency criteria at each technical milestone

– Clear statement of design objectives to engineering team leaders during each phase of development

Expression

Abs

trac

tC

oncr

ete

“Boehm Spiral”

Behavioral

Structu

ral

Ab

stra

ctio

n


Permanence Axis

• Continuum from Enduring to Transitory• Used to explore: lifecycle design, potential changes in

stakeholder roles, technology insertion, COTS dependencies• Used to establish “Anchor points” of system architecture:

– human system interface, logistics, support chain, safety, reliability– conscious identification of enduring aspects of architecture

– consistent with business strategy, core competence– establish tech insertion, reuse goals– minimize COTS risk on long-life programs

– proprietary data and interfaces– unplanned upgrades

– identify aspects of architecture that are “throw away”

• Enduring aspects at multiple levels– reuse of top level concepts (manage demands on subsystems)– reuse of subsystems (design for flexibility)– reuse of standards, protocols

EnduringTransitory

Permanence


Abstraction - Permanence Examples

EnduringTransitory

Abs

trac

tC

oncr

ete

Ab

stra

ctio

n

Permanence

Protocols, data

exchange standards

Interface management

principles

Strategy for legacy system

integration

Pragmatic design/

integration details


View - Permanence Examples

EnduringTransitory

Behavioral

Structu

ral

legacycomponents

legacyprotocols

key interfaces

partitioning of core processing


Management of Enduring Architectures:

Some Thoughts• Enduring architectures have strategic significance• Focus core business competence on enduring architectures

– minimize internal on transitory aspects… do just enough to meet immediate needs, or subcontract to someone else

– don’t allow transient aspects to subsume your entire business!– factor in how transitory aspects change

– set rollout dates, focus on transition plans– be flexible when considering enduring aspects, but don’t be driven by short term concerns

• Standards aren’t always enduring, but they have their place– see beyond the immediate standard to the long term need– don’t rely solely on a standard to solve an evolvability or technology insertion problem!

– identify evolutionary technology needs, then look at standards

• COTS systems are transitory– enduring COTS architectures belong to the vendor, not the integrator


Enduring Architecture Hierarchies

• conscious identification of enduring aspects of architecture

– consistent with business strategy, core competence– establish tech insertion, reuse goals– minimize COTS risk on long-life programs

– proprietary data and interfaces– unplanned upgrades

– identify aspects of architecture that are “throw away”

• enduring aspects at multiple levels– reuse of top level concepts (manage demands on subsystems)– reuse of subsystems (design for flexibility)– reuse of standards, protocols


Examples of Level-by-level management

• spiral model… form/function balance at each “turn”• multi-level simultaneous development

– managing “rigidity” of models from top down

• balance and focus of effort on missing pieces at higher abstraction


Discussion Points

• When is Model Based System Architecting appropriate? When is it not appropriate?

• In what ways are models important to system architecting? How “Model Based” to system architectures really need to be?

• What is the potential impact of MDSD on identification of Enduring Architectures?


ModelINCOSE

Tech. Ops.[S ]

AP-233 [SL]

T ie to O therProcess

Im provem ent[SL]

MDSD "Light"[SL]

Inform alBenefits

(SuccessStories) [SL]

Form alBenefits

(Metrics) [L]

Modeling theS/E Process

[L]

Process forMDSD [L]

Form alMethods [L]

ModelInteroperability

[L]

InterrogationMechanism s

[L]

Taxonom y ofModeling

Techniques[S ]

UML for S /E[SL]

Inform ationModel of

Models [SL]

ReviewAutom obileUML [SL]

Review JPLModel

IntegrationW ork [SL]

S im ulationBased

Acquisition[L]

Forward Dependency

Feedback

[S ] Short Term[L] Long Term[SL] Short/Long Term

Case S tudies[SL]

Integration &Oversight

[SL]

Initiated Prior to January International Business Meeting

Initiated Prior to M inneapolis Sym posium

MDSDWG Task Dependencies


Information Model of Models

• Characterize basic (common) modeling abstractions.• Define “Model” and relate it to other concerns• Use this information as a basis for:

– Model evaluation (e.g., adequacies & inadequacies of UML)– Model interoperabilitry– Defining interrogation mechanisms– Defining completeness/consistency rules– Defining process for model-based systems engineering


Process for MDSD

• Propose process(es) tailored for a model-driven system design.

• Begin with recognizable, standard process– IEEE 1220– Integrated Systems & Software Engineering Process (ISSEP)– British Defence Evaluation and Research Agency (DERA) process

• Tailor for model-driven environment• “MDSD Lite” is a “lightweight” version of the complete

process– Motivation: Transition to MDSD Lite should be relatively inexpensive.


Process Tailoring for MDSD

• Associate modeling techniques with work products.• Identify differences in:

– Flow of information– Engineering activities– Sequencing of activities


Process Improvement Tie-In

• Improving use of models is a process improvement (PI) activity.

• As such, it can compete or cooperate with other PI activities.

– Cooperation is better in this case.

• How do we...– Coordinate modeling PI with more traditional PI?– Demonstrate how modeling PI will help you “move up the maturity

ladder”?


Unified Modeling Language Version 2

• The Object Modeling Group (OMG) will produce version 2 of the Unified Modeling Language (UML).

• For version 2, they are particularly interested in concerns of systems engineers!!

– They have issued a Request for Information (RFI) for suggestions about what the new version should do.

– They will later ask for proposals on how the new version should be structured to achieve its objectives.

• INCOSE must respond (RFI deadline: 17 Dec. 1999)• For more information:

– http://www.omg.org– ftp://ftp.omg.org/pub/docs/ad/99-08-08.{doc,rtf,pdf,txt,ps}


Conclusions

• There is strong interest in modeling, inside and outside the INCOSE technical community.

• Effective use of modeling at the systems level is a difficult challenge.

– Engineering organizations must meet this challenge in order to remain competitive.

• The INCOSE Model Driven System Design Group is working to meet the modeling needs of INCOSE members.

• We invite your participation.


Contact Points

Bob Cohen, Co-ChairUnited Technologies Research Center411 Silver Lane, Mail Stop 129–85East Hartford, Connecticut 06108860–610–[email protected]

Howard Lykins, Co-ChairSoftware Productivity Consortium2214 Rock Hill RoadHerndon, Virginia [email protected]

wma incose - rick steiner111/9/99 model driven system design (mdsd) workshop rick steiner raytheon...

Documents

system model

functional design

design shifts

design isthis

design database

important aspect of

model based approach

complex system designthe