Bill Schindel Troy Peterson

[email protected] [email protected]

Introduction to Pattern-Based Systems Engineering

(PBSE): Leveraging MBSE Techniques

INCOSE Great Lakes Regional Conference 2016

Copyright © 2016 by Bill Schindel and Troy Peterson
1.5.3 Published and used by INCOSE with permission 1.7.4
 Abstract
• This tutorial is a (half day) practitioner’s introduction to Pattern-Based Systems
Engineering (PBSE), including a specific system domain illustration. (For those
seeking a shorter awareness briefing on PBSE, a single-session overview is also
provided during the conference technical sessions.)
• INCOSE thought leaders have discussed the need to address 10:1 more complex
systems with 10:1 reduction in effort, using people from a 10:1 larger community
than the “systems expert” group INCOSE currently reaches. The INCOSE Patterns
Working Group describes PBSE to enable INCOSE membership, and the larger
systems community beyond INCOSE, to achieve such order-of-magnitude
improvements.
• PBSE leverages the power of Model-Based Systems Engineering (MBSE) to rapidly
deliver benefits to a larger community. Projects using PBSE get a “learning curve
jumpstart” from an existing Pattern, gaining the advantages of its content, and
improve that pattern with what they learn, for future users.
• The major aspects of PBSE have been defined and practiced some years across a
number of enterprises and domains, but with limited INCOSE community
awareness. Addressing this, the INCOSE PBSE Challenge Team was started in
2013 as a part of the INCOSE/OMG MBSE Initiative, and it later became the
INCOSE Patterns Working Group.
• This tutorial is for SE practitioners.
page 2
 Contents—Summary
• The need, call-to-arms, and vision
• Conceptual summary of PBSE
• PBSE applications to date
• Representing system patterns: An example
• Applying system patterns: Example uses and benefits
• Challenges and opportunities
• Conclusions

• References

page 3
 Contents—Detail & Timeline
• The need, call-to-arms, and vision
• Conceptual summary of PBSE
• PBSE applications to date
• Representing system patterns: An example 1:00 – 2:30
– S*Metamodel framework
– A Vehicle Pattern in SysML
– A practice exercise

Coffee Break

• Applying system patterns: Examples of uses and benefits

1. Stakeholder Features and Scenarios: Better stakeholders alignment sooner
2. Pattern Configuration: Generating better requirements faster
3. Selecting Solutions: More informed trades
4. Design for Change: Analyzing and improving platform resiliency
5. Risk Analysis: Pattern-enabled FMEAs 3:00 – 4:30
6. Verification: Generating better tests and reviews faster
• Challenges and opportunities:
– Human nature & organizations
– Approaches to my situation
– Exercise and discussion
• Conclusions

• References page 4
 PBSE Addresses Speed, Leverage, Knowledge

– INCOSE thought leaders have discussed

the growing need to address 10:1 more
complex systems with 1:10 reduction in
time and effort, using people from a 10:1
larger community than the “systems
expert” group
Source:
– Many other SE efforts (other than Microsoft,
published in the
leveraging system patterns) are in some INCOSE SE
Handbook
way concerned with growing in complexity,
but don’t offer evidence of the sweeping 1905 ~83 yrs.
order-of-magnitude improvements 1952 ~44 yrs.
1986 ~14 yrs.
demanded by this call-to-arms.
Rates of system proliferation
– PBSE is a methodical way to achieve this decreased by 4:1 over 50 years
order-of-magnitude improvement

page 5
 Pattern-Based Systems Engineering (PBSE)

• What are System Patterns?

• What are System Patterns for?

page 6
 Pattern-Based Systems Engineering (PBSE)

• Standard Parts have been a great aid to progress:

• The same part type can be used to make many things!

page 7
Quick Exercise: Can you recognize this system?

page 8
Using different views helps improve recognition:
Does rotating the parts improve recognition?

page 9
Showing parts in relationship helps recognition

page 10
 Can we identify a system from its parts alone?

Obviously not in many cases—and in all cases, the

parts list alone lacks critical information . . .

page 11
 Any systems engineer will tell you . . .

• We need to know the relationships between the parts to

understand what the “system” they create.

Physical Architecture
page 12
 But . . .

we are interested in much more than Physical Architecture:

• Stakeholders • Alternatives
• Requirements • Configurability
• Design • Manufacturability
• Interfaces • Maintainability
• Modes • Operability
• Performance • Reliability
• Failure Modes & Effects • Risks
• Verification Plans • etc., etc., etc.

page 13
 And, in an “information sense”, . . .

we can still think of all these as kinds of “parts”—not just

physical parts of a system, but parts of a system model:
• Stakeholders • Alternatives
• Requirements • Configurability
• Design • Manufacturability
• Interfaces • Maintainability
• Modes • Operability
• Performance • Reliability
• Failure Modes & Effects • Risks
• Verification Plans • etc., etc., etc.

page 14
 And, once again, it turns out that . . .

the relationships between these information components is

just as important as the lists of them, taken alone:
• Stakeholders • Alternatives
• Requirements • Configurability
• Design • Manufacturability
• Interfaces • Maintainability
• Modes • Operability
• Performance • Reliability
• Failure Modes & Effects • Risks
• Verification Plans • etc., etc., etc.

Physical Architecture Information Architecture

??
page 15
 And, once again, it turns out that . . .

the relationships between these information components is

just as important as the lists of them, taken alone:
• Stakeholders • Alternatives
• Requirements • Configurability
• Design • Manufacturability
• Interfaces • Maintainability
• Modes • Operability
• Performance • Reliability
• Failure Modes & Effects • Risks
• Verification Plans • etc., etc., etc.

Physical Architecture Information Architecture

??

page 16
Taking advantage of Model-Based Systems Engineering (MBSE)
– An S* Model is a description of all those important things, and the relationships
between them.
– Typically expressed in the “views” of some modeling language (e.g., SysML™).
– The S* Metamodel: The smallest set of information sufficient to describe a system
for systems engineering purposes.
– Includes not only the physical Platform information, but all the extended system
information (e.g., requirements, risk analysis, design trade-offs & alternatives,
decision processes, etc.):

page 17
 Extending the Concept to Patterns, and
Pattern-Based Systems Engineering (PBSE)
– An S* Pattern is a configurable, re-usable S* Model. It is an extension of the idea
of a Platform (which is a configurable, re-usable design) or Enterprise / Industry
Framework.
– The Pattern includes not only the physical Platform information, but all the
extended system information (e.g., pattern configuration rules, requirements, risk
analysis, design trade-offs & alternatives, decision processes, etc.):

General Vehicle Pattern

Vehicle Product Lines

Specific Vehicle Configurations

Same S*Metamodel at each level

page 18
 Concept Summary:
Pattern-Based Systems Engineering (PBSE)
– By including the appropriate S* Metamodel concepts, these can readily be managed in
(SysML or other) preferred modeling languages and MBSE tools—the ideas involved here
are not specific to a modeling language or specific tool.
– The order-of-magnitude changes have been realized because projects that use PBSE rapidly
start from an existing Pattern, gaining the advantages of its content, and feed the pattern
with what they learn, for future users.
– The “game changer” here is the shift from “learning to model” to “learning the model”, freeing
many people to rapidly configure, specialize, and apply patterns to deliver value in their
model-based projects.

General Vehicle Pattern

Vehicle Product Lines

Specific Vehicle Configurations

Same S*Metamodel at each level

page 19
 Concept Summary:
Pattern-Based Systems Engineering (PBSE)
• PBSE provides a specific technical method for implementing:
– Platform Management and Product Line Engineering (PLE)
– Enterprise or Industry Frameworks
– System Standards
– Experience Accumulation for Systems of Innovation
– Lean Product Development & IP Asset Re-use

page 20
 Comparative Benefits and Costs Summary
“Learn to Model” “Learn the Model”
COMPARATIVE ROI
Model-Based SE Pattern-Based SE
Traditional SE
(MBSE) (PBSE/MBSE)

ROI: Ratio of
Benefits (below) to
Investment (below)
(Recurring ROI
Per Project)

Ratio

Ratio

Ratio
QUALITATIVE ANALYSIS
ding and
Benefits to Users of ve Understan
nuously Impro
Patterns Conti s Proje cts an d En terprise
System Descriptions erstanding Content Acros
prove Und
(Recurring Benefit Models Im ects
Within Proj
Per Project)
(1X Scale)

d Only
Investment rs Nee attern
Creato
(10X Scale) Model Creators Mu Model Model from P
Per Project st ure
Create and Validate Config
Model
(Recurring Cost (possibly also learning
to model)
Per Project)

Cost to Support
Methodology Methodology Go
vernance Must
Accommodate
Modeling Rules Pattern Creators
(Small group per Enterprise, Must
Manage IP Portfo
lio Asset
not Project Recurring)

page 21
 Status of PBSE
– The major aspects of PBSE have been defined and practiced for years across a number of
enterprises and domains, but with limited integration or awareness within INCOSE community:
Medical Device Patterns Construction Equipment Patterns Commercial Vehicle Space Tourism Pattern
Patterns
Manufacturing Process Vision System Patterns Packaging System Patterns Lawnmower Pattern
Patterns
Embedded Intelligence Systems of Innovation (SOI) Baby Product Pattern Orbital Satellite Pattern
Patterns Pattern
Development Process Production Material Handling Engine Controls Patterns Military Radio Systems
Patterns Patterns Pattern

– What makes these “PBSE” applications?

• Each is based on an MBSE model of requirements, and often designs, failure modes,
other aspects;
• Each is a generalized model (pattern) that is configurable to different specific applications,
market segments, customers, or situations;
• Each is based on the underlying S*Metamodel.

– The PBSE Tutorial is more about integration of proven methods and INCOSE community
awareness and capability than about technically establishing a new method—although it may
look new to INCOSE practitioners.

– We recognize that the human change aspect can be the most challenging – but are not
suggesting that we also have to create new technical methods. We are introducing PBSE to a
larger community.
Representing system patterns: An example

• S*Metamodel framework
• A Vehicle Pattern in SysML
• An Exercise

page 23
 Representing System Patterns:
The S* Metamodel Framework

• What is the smallest amount of information we need to

represent pattern regularities?
– Some people have used prose to describe system regularities.
– This is better than nothing, but usually not enough to deal with the
spectrum of issues in complex systems.
• We use S* Models, which are the minimum model-based
information necessary:
– This is not a matter of modeling language—your current favorite
language and tools can readily be used for S* Models.
– The minimum underlying information classes are summarized in the
S* Metamodel, for use in any modeling language.
• The resulting system model is made configurable and
reusable, thereby becoming an S* Pattern.
page 24
 Representing System Patterns:
The S* Metamodel Framework

• A metamodel is a model of other models;

– Sets forth how we will represent Requirements, Designs, Verification,
Failure Analysis, Trade-offs, etc.;
– We utilize the (language independent) S* Metamodel from
Systematica™ Methodology:
Simple summary of detailed S* Metamodel.

• The resulting system models may

be expressed in SysML™, other
languages, DB tables, etc.

• Has been applied to systems

engineering in aerospace,
transportation, medical, advanced
manufacturing, communication,
construction, other domains.
page 25
 Definitions of some S* Metamodel Classes
• System: A collection of interacting components. Example: Vehicle; Vehicle Domain
System.
• Stakeholder: A person or other entity with something at stake in the life cycle of a
system. Example: Vehicle Operator; Vehicle Owner; Pedestrian
• Feature: A behavior of a system that carries stakeholder value. Example: Automatic
Braking System Feature; Passenger Comfort Feature Group
• Functional Interaction (Interaction): An exchange of energy, force, mass, or
information by two entities, in which one changes the state of the other. Example:
Refuel Vehicle; Travel Over Terrain
• Functional Role (Role): The behavior performed by one of the interacting entities
during an Interaction. Example: Vehicle Operator; Vehicle Passenger Environment
Subsystem
• Input-Output: That which is exchanged during an interaction (generally associated
with energy, force, mass, or information). Example: Fuel, Propulsion Force, Exhaust
Gas
General
Vehicle

Ambulance

page 26
 Definitions of some S* Metamodel Classes
• System of Access: A system which provides the means for physical interaction
between two interacting entities. Examples: Fueling Nozzle-Receptacle; Grease Gun
Fitting; Steering Wheel; Dashboard; Brake Peddle
• Interface: The association of a System (which “has” the interface), one or more
Interactions (which describe behavior at the interface), the Input-Outputs (which pass
through the interface), and a System of Access (which provides the means of the
interaction). Examples: Operator Interface; GPS Interface
• State: A mode, situation, or condition that describes a System’s condition at some
moment or period of time. Example: Starting; Cruising; Performing Maneuvers
• Design Component: A physical entity that has identity, whose behavior is described
by Functional Role(s) allocated to it. Examples: Garmin Model 332 GPS Receiver;
Michelin Model 155 Tire
• Requirement Statement: A (usually prose) description of the behavior expected of (at
least part of) a Functional Role. Example: “The System will accept inflow of fuel at up to
10 gallons per minute without overflow or spillage.”

page 27
 Physical Interactions: At the heart of S* models

• S* models represent Interactions as explicit objects:

– Goes to the heart of 300 years of natural science of systems as a
foundation for engineering, including emergence.
– All physical laws of science are about interactions in some way.
– All functional requirements are revealed as external interactions (!)

• Other Metamodel parts: See the Vehicle Pattern example.

page 28
 Physical Interactions: At the heart of S* models

• S* models represent Physical Interactions as explicit objects:

Vehicle Pattern Interactions

Metamodel

Aspirate: The interaction of the vehicle

with the Local Atmosphere, through which
air is taken into the vehicle for operational
purposes, and gaseous emissions are Interaction Diagram
expelled into the atmosphere.

page 29
 Pattern-based systems engineering (PBSE)

• Model-based Patterns:
– In this approach, Patterns are reusable, configurable S* models of
families (product lines, sets, ensembles) of systems.
– A Pattern is not just the physical product family—it includes its behavior,
decomposition structure, failure modes, and other aspects of its model.
• These Patterns are ready to be configured to serve as Models
of individual systems in projects.
• Configured here is specifically limited to mean that:
– Pattern model components are populated / de-populated, and
– Pattern model attribute (parameter) values are set
– both based on Configuration Rules that are part of the Pattern.

• Patterns based on the same Metamodel as “ordinary” Models

page 30
 Pattern-based systems engineering (PBSE)
• Pattern-Based Systems Engineering (PBSE) has two overall processes:
– Pattern Management Process: Creates the general pattern, and
periodically updates it based on application project discovery and learning;
– Pattern Configuration Process: Configures the pattern into a specific
model configuration (e.g., a new product) for application in a project.

We’ll discuss examples from both processes in this tutorial. page 31

 Pattern configurations

• A table of configurations illustrates how patterns facilitate compression;

• Each column in the table is a compressed system representation with respect to
(“modulo”) the pattern;
• The compression is typically very large;
• The compression ratio tells us how much of the pattern is variable and how
much fixed, across the family of potential configurations.

page 32
 Checking holistic alignment to a pattern

• Gestalt Rules express what is meant by holistic

conformance to a pattern:
– Expressing regularities of whole things, versus same “parts”

Governing pattern

Candidate model
configuration—does it
conform to pattern?

page 33
 The Gestalt Rules
1. Every component class in the candidate model must be a subclass of a
parent superclass in the pattern—no “orphan classes”.
2. Every relationship between component classes must be a subclass of a
parent relationship in the pattern, and which must relate parent superclasses
of those same component classes—no “orphan relationships”.
3. Refining the pattern superclasses and their relationships is a permissible
way to achieve conformance to (1) and (2).

Governing pattern

Candidate model
configuration—does it
conform to pattern?
Example: State Model Pattern—illustrates how visual is the “class
splitting” and “relationship rubber banding” of the Gestalt Rules

page 35
A vehicle pattern in SysML

page 36
Vehicle Pattern:
Model Organization (Packages)

page 37
Vehicle Features
Model

page 38
 Vehicle Features
Model

The feature of targeted configurations of

the vehicle being developed at an
acceptable cost in an acceptable time,
with acceptable risk.
The feature of being capable of being
efficiently arranged or rearranged,
adjusted or altered for a different use
within the limitations of the current design.
This includes support for maintaining
awareness of the current or other
configurations of the system.
page 39
Vehicle Domain Model

page 40
Vehicle State Model

page 41
 Vehicle Interaction Model

pkg Interactions

«Interaction» «Interaction» «Interaction» «Interaction»

«Interaction»
Travel Over Interact with Manage Vehicle Attack Hostile
Refuel Vehicle
Terrain Operator Performance System

«Interaction» «Interaction» «Interaction» «Interaction» «Interaction»

Avoid Obstacle Aspirate Navigate Configure Vehicle Survive Attack

«Interaction» «Interaction»
«Interaction» «Interaction»
Interact with Perform
Ride in Vehicle Maintain System
Higher Control Application

«Interaction» «Interaction»
«Interaction»
Interact with Account for
Deliver Vehicle
Nearby Vehicle System

«Interaction»
Perform Dock «Interaction» «Interaction» «Interaction»
Approach & Transport Vehicle View Vehicle Secure Vehicle
Departure

page 42
 Vehicle Interactions:
Which Actors Participate in Interaction?

page 43
Vehicle Feature-Interaction Associations

page 44
Logical Architecture Model

page 45
 Logical Architecture Model
The vehicle logical subsystem responsible for
managing vehicle-level performance,
configuration, faults, security, or accounting.
This includes interaction with external
management systems, including the vehicle
operator.

The vehicle logical subsystem responsible for

transmitting forces and maintaining structural
integrity of the overall vehicle. This includes
smoothing of dynamical forces during travel
across uneven terrain.

The vehicle logical subsystem responsible for

storing chemical, electrical, or mechanical
energy until needed, and converting that energy
into forms useful for propulsion or internal
page 46 consumption.
Physical Architecture Model

page 47
Allocation of Logical Roles to Physical Architecture

page 48
 Allocation of Logical Roles to Physical Architecture

• Same Logical Architecture covers many Physical Architectures:

page 49
Attribute Coupling Model

page 50
 Logical Architecture Views
Block Diagram and Design Structure Matrix (DSM)

• The structure shown in these architectural diagrams can

also be expressed in matrix form
– These matrices are known as: N2 matrices, Adjacency Matrices
and Design or Dependency Structure Matrices (DSMs)
– N2 because their column and row headings are identical, with the
matrix cells showing “marks” indicating relationships between
components.

Logical Arch. DSM

Diagram .
page 51
 Logical Architecture Views
Block Diagram and Design Structure Matrix (DSM)

• In the case of Logical Architecture:

– The blocks in the LA diagram become rows and columns of the DSM
– The connection lines in the LA diagram become marks in the DSM
• Both views are visualizations of the same information:
– However the functionality has been partitioned into interacting
subsets – Vehicle Functional Roles and Interfaces in this case.

Logical Arch. DSM

Diagram .
page 52
 Physical Architecture Views
Block Diagram and Design Structure Matrix (DSM)

• In the case of Physical Architecture:

– The blocks in the LA diagram become rows and columns of the DSM
– The connection lines in the LA diagram become subsystems or components in
the DSM shown in rows and columns
• Both views provide visualizations of hierarchy
– How the physical system has been partitioned into physical sub-systems that are
physically related (connected, contained, adjacent, etc.)
– The DSM additionally shows the interactions of subsystems

Physical Arch. DSM

Diagram .
page 53
 Domain Structure Matrix (DSM) View of Same

• In the case of Coupled Parameters (attributes):

– Attributes become row and column headings in the DSM
– This includes adding rows and columns to the Logical Architecture
DSM, showing attributes of the Logical Subsystems
– Connection lines in the drawing become marked cells in the DSM
• Both views convey the same information:
– Which attributes are coupled (impact each others’ values)
•
•
•
•

Parametric DSM
Diagram .
page 54
 Domain Structure Matrix (DSM) View of Same
• Instead of just showing which attributes are coupled, the DSM (like the
Parametric Diagram) can also symbolize the named Coupling that connects
them:
– This provides a reference to a (separately documented) quantitative coupling
description.
• The names of the couplings can be introduced as row and column
headings, separate from the rows and columns that list the attribute names:
– This becomes a Multi-Domain Matrix (MDM):

Parametric DSM
Diagram .
page 55
Requirement Statements

page 56
 Failure Modes Model
Physical Entity Failure Mode
Vehicle ECM Dead ECM
Vehicle ECM Network Connector Open
Vehicle ECM Network Connector Short
Vehicle ECM Erratic ECM
<Insert Failure Modes Model from Vehicle
Battery Discharged Battery
SysML Pattern before 9/20>
Battery Battery Cell Short
Battery Battery Cell Open
Battery Battery Leak
Panel Display Fractured Display
Panel Display Illuminator Fail
Bluetooth Module Module Hard Fail
Bluetooth Module Transmitter Fail
Bluetooth Module Receiver Fail
page 57
Filling in the Feature Population Form—
with Stakeholder Needs

page 58
Resulting Auto-Populated Requirements

page 59
 Break out: Practice exercise
• For the Vehicle Pattern:
– Think of some Vehicle Application
– Fill in the Feature Configuration Form for your application
– Did you need any new Features not in the Vehicle Pattern?

• For your own Pattern: Interactions

– Think of a new Interaction between the Vehicle and some Actor
(you can add a new Actor)
– Create an Interaction Diagram
– Write requirements on the Vehicle for this Interaction

• Group Discussion of Exercise

page 60
 Applying system patterns
• Example Uses and Benefits:
1. Stakeholder Features and Scenarios: Better stakeholder alignment
sooner
2. Pattern Configuration: Generating better requirements faster
3. Selecting Solutions: More informed trade-offs
4. Design for Change: Analyzing and improving platform resiliency
5. Risk Analysis: Pattern-enabled FMEAs
6. Verification: Generating better tests faster

• At the end: What seems most important?

page 61
 1. Stakeholder Features and Scenarios:
Better stakeholders alignment sooner

• Alignment with stakeholders is critical to program success.

• That alignment can be achieved earlier and maintained
stronger using:
– Stakeholder Feature Pattern: Aligns understanding of system
capabilities (base as well as options) and the nature of their value to
stakeholders
– Scenario Pattern: Aligns understanding of the concepts of operations,
support, manufacture, distribution, other life cycle situations; accelerates
alignment of system documentation, training, and communication.
• Both of these are “pattern configurations” directly generated
from the System Pattern—not separate and unsynchronized
information.

page 62
 1. Using the Feature Pattern to Rapidly Capture &
Validate Stakeholder Requirements: An Example
• Concept: The Feature Pattern is a powerful tool for establishing Stakeholder
Requirements—as a “configuration” of Feature Pattern.
• By “configuration”, we mean that individual Features from the Pattern are
(1) either populated or de-populated, and (2) their Feature Attributes
(parameters) are given values:

• These can be expressed (1) as configured Feature objects and their attribute
values or (2) as sentence-type statements if desired, but in any case the
degrees of freedom (stakeholder choices) are brought into clear focus.
page 63
 Using the Feature Pattern to Rapidly Capture &
Validate Stakeholder Requirements: An Example

Feature Pattern Stakeholder

Requirements
Document

Stakeholder
Interview
Template
Stakeholder
Interview
Process
Populates the Generates
questions & issues

page 64
1. Using the Feature Pattern to Rapidly Capture &
Validate Stakeholder Requirements: An Example

page 65
1. Using the Feature Pattern to Rapidly Capture &
Validate Stakeholder Requirements: An Example

page 66
 1. Using the Feature Pattern to Rapidly Capture
& Validate Stakeholder Requirements
• Benefits:
– A more complete set of stakeholder requirements—reduce omissions;
– Stronger alignment with stakeholders, sooner—surface issues earlier;
– Pattern identifies classes of stakeholders that might have been missed;
– Pattern makes very clear the difference between Stakeholder
Requirements versus Design Constraints or Technical Requirements;
– The Pattern provides a clear place to accumulate new learning (e.g.,
additional Features);
– Sets up subsequent uses of Feature Pattern in support of Trade Space,
Risk Management, FMEA “effects”, and other applications.
• No free lunch:
– Interviewer needs to be knowledgeable about the Features;
– Stakeholders won’t have all the answers—find the right representative;
– Stakeholder representatives need know they are formal representatives;
– The Feature Pattern needs to be relatively complete.
page 67
 How do I know whether I have all the Features?

• This is why we use a Pattern!

– Moves problem to the builder of the original pattern, plus maintainer.
• Related key points for the builder of the Feature Pattern:
– First, identify all the Stakeholder classes
– Then, all the Features for each Stakeholder class
– Validate the Features with their Stakeholder Representatives
– Then, make sure all the Interactions are reviewed for associated Feature value
– There are well-known abstract Feature classes (e.g., Maintainability)
• Every time we discover another Feature, we add it to the
Pattern; for example:
– Every argument / decision should invoke trade space Features as its ultimate
rationale – a new one might appear during an argument.
– Every impactful Failure Mode should cause Feature impacting Effects – a new
one might appear while discussing a Failure Mode.

page 68
 1. Using the Interactions & States Pattern to Rapidly
Generate & Validate Scenarios: An Example

• Concept: Scenarios can be efficiently generated, as single

thread tracings through the configured pattern State Model;
• Each scenario “tells a story” within the system’s life cycle—
operations, maintenance, or other CONOPS type view;
• Early in life cycle: Stakeholders validate (or give feedback)
scenario;
• Later in life cycle: Generates base data for training and
documentation, as well as test plans;
• Akin to typical Use Case process, but easier maintained
ongoing as a part of the configured pattern;
• Reference: Operational Views (OV)

page 69
 1. Using the Interactions & States Pattern to Rapidly
Generate & Validate Scenarios: An Example
Concept of
Interactions & Operations
Concept of
States Pattern Document
Operations

Traffic Control System

Remote Management
Maintenance System

Curb & Dock System

Concept of

External Attachment

Application System
Nearby Pedestrian

Local Atmosphere

Vehicle Transport
External Observer
Vehicle Occupant

Nearby Vehicle
Hostile System
Refuel System

Global Region
Local Terrain
Passenger

Maintainer
Operator
Vehicle

System

System
Load
Interaction Name Definition

Travel Over Terrain The interaction of the vehicle with the terrain over which it travels, by means
of which the vehicle moves over the terrain.

Document
X X
Perform Application The interaction of the vehicle with an external Application System, through
which the vehicle performs a specialized application.

Avoid Obstacle

Ride In Vehicle
The interaction of the vehicle with an external object, during which the vehicle
minimizes contact with or proximity to the object.

The interaction of the vehicle with its occupant(s) during, before, or after travel
by the vehicle.
X

X X
X

Operations
Document
X X X X
View Vehicle The interaction of the vehicle with an external viewer, during which the viewer
observes the vehicle.

X X
Maintain System The interaction of the vehicle with a maintainer and/or maintenance system,
through which faults in the vehicle are prevented or corrected, so that the
intended qualified operating state of the vehicle is maintained.

X X X
Aspirate The interaction of the vehicle with the Local Atmosphere, through which air is
taken into the vehicle for operational purposes, and gaseous emissions are
expelled into the atmosphere.

X X
Refuel Vehicle The interaction of the vehicle with a fueling system and its operator, through
which fuel is added to the vehicle.

X X
Survive Attack The interaction of the vehicle with an external hostile system, during which the
vehicle protects its occupants and minimizes damage to itself.

X X
Attack Hostile System The interaction of the vehicle with an external hostile system, during which the
vehicle projects an attack onto the hostile system's condition.

X X
Interact with Traffic Control The interaction of the vehicle with an external traffic control system, through
which fhe vehicle is fit into larger scale traffic objectives.

X X
Transport Vehicle The interaction of the vehicle with a Vehicle Transport System, through which
the Vehicle is transported to an intended destination.

X X
Perform Dock Approach & Departure The interaction of the vehicle with an external docking system, through which
the vehicle arrives at, aligns with, or departs from a loading / unloading dock.

X X
Secure Vehicle The interaction of the vehicle with external actors that may or may not have
privileges to access or make use of the resources of the vehicle, or with
actors managing that vehicle security.

X X
Configure Vehicle The interaction of the vehicle with people or systems that manage its
arrangement or configuration for intended use.

X X X
Manage Vehicle Performance The interaction of the vehicle with its operator and/or external management
system, through which the performance of the vehicle is managed to achieve
its operational purpose and objectives.

X X

Operational
(or other)
Scenario Model Scenario
Validation
Process
Populates States, Generates
Interactions

page 70
1. Using the Interactions & States Pattern to Rapidly
Generate & Validate Scenarios: An Example
Scenario plan as state model tracing:

page 71
1. Using the Interactions & States Pattern to Rapidly
Generate & Validate Scenarios: An Example
Scenario plan as sequence diagram and requirements:

State Interaction Capability Actor Req ID Requirement

Operating Navigate Central Mission Vehicle VEH-1031 The system shall allow the operator to select a pre-stored route for travel on a mission.
Route Download

Operating Navigate Trip and Mission Vehicle VEH-1032 The system shall calculate and display a recommended route to an operator-specified destination from
Route Display and the current location, providing turn-by-turn en route directions and progress tracking.
Directions
Operating Navigate GPS-based Vehicle VEH-1029 The system shall sense the location of the vehicle by accessing the Global Positioning System (GPS)
Location Sensing satellite constellation and computing location on the surface of the earth, accurate to 10 feet.

Operating Navigate Map Location Vehicle VEH-1030 The system shall display position of the vehicle on a pre-stored graphic map presentation, including major
Display road and geographic features, updating while enroute to reflect travel of the vehicle.

Operating Navigate GPS-based Vehicle VEH-1033 The system shall display to the vehicle operator a location confidence indicator, signaling whether
Location Sensing accurate GPS location sensing is currently available.

page 72
 1. Using the Interactions & States Pattern to
Rapidly Generate & Validate Scenarios

• Benefits:
– A more complete set of scenarios—reduces omissions;
– Easier to generate from pattern;
– Easier to keep consistent with configured system model as it evolves
over the delivery and life cycle;
– Valuable not only for initial validation, but also as seed information for
generation of system training, documentation, SOPs;
– As system requirements are configured, becomes progressively more
detailed;
– The Pattern provides a clear place to accumulate new learning (e.g.,
additional Scenarios);
• No free lunch:
– The State and Interaction Pattern needs to be relatively complete.

page 73
 2. Using Pattern Configuration to generate
better System Requirements faster: Example

• Concept: Configured System Requirements can be semi-

automatically generated from Configured Features, using
the System Pattern;
• Low dimensionality / degrees of freedom choices in Feature
stakeholder space imply higher dimensionality / degrees of
freedom choices in Requirements space:
– The difference is made up by relationships encoded in the Pattern.

page 74
 2. Using Pattern Configuration to generate better
System Requirements faster: Example

Configured System
System Requirements
Features Requirements Document
Configuration
Process

Populates Requirements System

and Requirements Attributes System Pattern Requirements

page 75
 • The S*Pattern links Features to Requirements:
– This means that populating a configuration of Features can
automatically populate a configuration of Requirements--
Feature FPK Interaction IPK Rule Role-Phys Compon Table
Role Phys Comp IPPK Rule

Feature-Interaction Table
Functional Functional
Feature Interaction Role
FPK IPK RPK
Attribute Attribute
Pattern

Attribute Interaction-Role-Requirement Table Attribute

Attribute Interaction Role Requirement RSPK Rule
Design
Populated by Requirement
Pattern (Auto) Interaction – Role Table
Component
Statement Interaction Role RPK Rule
IPPK
Populated by RSPK Attribute
Populated by Pattern Attribute
Attribute
User, from Populated by (Auto)
Stakeholder Attribute
Pattern (Auto) Attribute
Needs Coupling
ACPK

Populated by
Pattern (Auto) Populated by
User or
Pattern (Auto)
Configured Pattern (Model)

Populated by Populated by
Pattern (Auto) Pattern (Auto)
Configured Configured Configured User Visible
Functional Functional
Feature Interaction Role
FPK IPK User Visible RPK Configured
Attribute Attribute Attribute
Values Attribute
Design
Populated by Attribute Attribute
Attribute Pattern (Auto)
Configured Req’d Vals Capability Vals
Component
PCPK
User Visible PK Value Set Requirement
Values Attribute
by Pattern Statement PK Value Set by Attribute
(Auto) RSPK Pattern (Auto)
Attribute
User Visible— Values
Attribute
other items Systematica™
Attribute Configuration Workbook
typically not
Coupling Pattern Configuration
user visible
ACPK
page 76 V1.4.1 03-15-16
 2. Using the Feature Pattern to Rapidly Capture &
Validate Stakeholder Requirements: An Example

Populating / depopulating Features:

page 77
 2. Using the Feature Pattern to Rapidly Capture &
Validate Stakeholder Requirements: An Example

Configuring Features: Setting Feature Attribute Values

page 78
• Resulting Requirements:
Attribute values can also be set, in line or in tables . . . .

page 79
 2. Using Pattern Configuration to generate
better System Requirements faster: Example
• Requirements Attribute Value Setting:
– A part of the configuration process
– Example: Cruise Control Speed Stability
– In PBSE, requirements attribute value setting can be manual, semi-
automatic, or automatic—in all cases, driven by Feature Attribute
Values and Attribute Couplings:

page 80
 2. Using Pattern Configuration to generate
better System Requirements faster: Example
In general, Configuration Rules are found in the Relationships that associate
the model Classes, and also those that associate the model Attributes:

page 81
 2. Using Pattern Configuration to generate
better System Requirements faster

• The scope of a System Pattern can include more

than Requirements:
– Design Patterns include Physical Architecture,
Requirements Decomposition, Requirements Allocations:

page 82
 2. Using Pattern Configuration to generate better
System Requirements faster

• PBSE processes continuously improve the content of the

pattern, accumulating lessons for use in future projects:

page 83
 3. Selecting Solutions
More Informed Trade-offs
Introduction:
Understanding trade-offs are an essential and critical
part of engineering systems

Trades include many formalized methodologies to

1
make informed decisions

Trade-offs seek to:

– Identify practical alternatives / optimal solutions
– Resolve conflicting objectives
– Account for the full spectrum of stakeholder needs 2
to ensure a balanced system solution
– Methods incorporate identifying/defining
stakeholders, requirements, values, attributes,
metrics, costs, governing equations, interactions
etc.
3
1. Bullets from MIT, ESD.77 MDO Course, Oli deWeck
2. SEARI Ref: http://seari.mit.edu/short_courses.php#value
3. Defense Acquisition University SE Handbook Trades Studies process page 84
 3. Selecting Solutions:
More Informed Trade-offs

Concept:
Patterns provide a very quick and explicit way
to perform trades

– Patterns contain the essential information to

identify and assess systems solutions
– Enable the rapid creation and comparison of
multiple system configurations
– Patterns save time in collection, integration and
structuring of the required information to perform
trade-offs
– Patterns provide leverage across programs and
promote consistency
– PBSE enables feature space optimization through
the turning of knobs in the logical and design
component space Functional Design
Roles Components

page 85
 3. Selecting Solutions
More Informed Trade-offs
PBSE and Trades
Feature Space
• Makes explicit all stakeholder needs
• Quantifies value impact through attributes
• Contains the entire trade space
Functional Role / Logical Architecture
• Logical, independent of design
• Describes the system’s behavioral structure
• Formally models subsystems/design components
• Houses performance data (range, cost, weight etc.)
• Supports modeling of multiple physical architectures
Design Components
• Contains subsystem and technology options
• Design component options populate the logical
architecture to create system configurations
• Contains part numbers, option names etc.
• Models the physical architecture
page 86
 3. Selecting Solutions:
More Informed Trade-offs

Vehicle Trades Example

• Buyer Sample Features:

– Sufficient range to make it to work and back -
without going into Flintstone mode
– Low operating costs i.e. fuel economy
– Reasonable acceleration – 0-60 mph in 2.8 sec.
– Affordability / purchase price / cost

• Producer Sample Features:

– To develop product lines which meet a broad
portfolio of user requirements
– To meet ambitious fuel economy standards -
CAFÉ 54.5 mpg by 2025
– Provide a return on investment
– Leverage existing assets and capital structure

page 87
 3. Selecting Solutions
More Informed Trade-offs
Vehicle Trades Example
Vehicle Configurations

Systems of
Access (SOAs)

Range

Current

Charging Interface Infrastructure

page 88
 3. Selecting Solutions
More Informed Trade-offs

Vehicle Trades Example

– Using patterns a table of multiple configurations is easily created
– The table enables many different configurations to be easily compared
– Provides the ability to generate many repeatable views and models of value,
gaps, utility, sensitivity etc.

page 89
 3. Selecting Solutions
More Informed Trade-offs
Vehicle Trades Example
– Selecting design components populates performance
criteria within the logical space and value impact within
feature space providing a basis to measure the value of
any potential system configuration

Vehicle 1
Vehicle 2
Vehicle 3
Vehicle 4
stV ehicle 5
Vehicle 6
Vehicle 7
Range (miles) Cost ($)
Purchase Price ($) Cost of Operation (mpg) Acceleration 0-60 mph (sec)
Vehicle 7 73 Vehicle 7 $28,800 Vehicle 7 116 Vehicle 7 7.9

Vehicle 6 446 Vehicle 6 $16,200 Vehicle 6 36 Vehicle 6 7.2

Vehicle 5 496 Vehicle 5 $20,780 Vehicle 5 40 Vehicle 5 11.1

Vehicle 4 540 Vehicle 4 $33,000 Vehicle 4 95 Vehicle 4 10.2

Vehicle 3 570 Vehicle 3 $25,200 Vehicle 3 47 Vehicle 3 9.4

Vehicle 2 620 Vehicle 2 $32,950 Vehicle 2 108 Vehicle 2 8.9

Vehicle 1 640 Vehicle 1 $38,712 Vehicle 1 62 Vehicle 1 8.9

100
200
300
400
500
600
700
800
900
1000
0

$- $10,000$20,000$30,000$40,000$50,000 0 50 100 150 0 5 10 15

page 90
 For Fun…

Highlighted in the table

Configuration Ford C-Max Energi

Variant Hybrid Plug In
Range (miles) 620
Operating Costs (mpg) 108
Acceleration 0-60 mph (sec) 8.9
Cost (dollars) $32,950
Top speed (mph) 102
Not in the table
A whole different kind of
Woo-hoo. As wildly different
Configuration Porsche 918 as these two are
Variant Hybrid Plug In can you think of
Range (miles) 952
pattern aspects
Operating Costs (mpg) 78
Acceleration 0-60 mph (sec) 2.8 they share?
Cost (dollars) $845,000
Top speed (mph) page 91 202
 3. Selecting Solutions
More Informed Trade-offs
Summary / Benefits
– Patterns provide a rapid way to investigate configuration options and the
impact of subsystem selections on stakeholder value impact
– Patterns provide an established and well documented knowledge base for
making decisions
– Patterns translate discrete design component selections into system level
value impact through attribute couplings
– Provides a way to develop heuristics, design rules and platform strategies

If you drive 20 miles or less a day, the Energi plug-in

version is for you. It costs more, but you’d probably go to
the dentist more often than the gas station.

If your daily driving much exceeds 30 miles, the regular

hybrid is the better choice. You’ll save about two grand and
you’ll still get 40-plus mpg, which is stellar.

Dan Neil, The Wall Street Journal

May 31, 2013

page 92
 4. Design for Change
Improving System Resiliency

Concept: System Resiliency/ Platform Evolution

Challenge:
To design and build systems which overcome constraints and
The new ilities
vulnerabilities of the global supply chain, rapidly changing
user needs, and an uncertain operational future1. 2

Goal:
Significantly transform traditional engineering practices to
develop and adapt systems to address dynamic needs and
risks1.

Assertions:
– Clean sheet design is extremely rare
– Rapid change is normative, keeping pace is required
– Systems often require lifecycle extension i.e. upgrades
– System resilience provides significant competitive advantage

1. DoD Engineering Resilient Systems http://www.acq.osd.mil/chieftechnologist/areas/ers.html

2. Engineering Systems: de Weck, Ross and Magee, 2011 - http://mitpress.mit.edu/books/engineering-systems 2

page 93
 4. Design for Change
Improving System Resiliency

Uncertainty Management:

– Understanding how requirements might change

– Eliminating the physical cause of the uncertainty

– Delaying design decisions until uncertain variables

are known
 Range
Architecture Management:

– Reducing the system sensitivity to uncertainties

– Purposefully isolating anticipated change

– Planning for subsystem and technology insertion

– Leveraging platform engineering methodologies

We can't solve problems by using the same kind of thinking we used when we created them. -- Albert Einstein --

page 94
 4. Design for Change
Improving System Resiliency

Uncertainty Management:

– Should be viewed across all Stakeholders

– Is performed in Feature space

– Assigns value and measures to new ilities

– Must go beyond best guess or average estimates

Architecture Management:

– Extends beyond the end product alone – flexible

manufacturing etc.

– Is performed in functional and physical space

– Accommodates new ilities within product

lines/families to improve leverage. Move up
resilient design principles where appropriate

page 95
 4. Design for Change Feature
Uncertainty Management
Uncertainty Management Includes:
• Clarifying Issues
– Envisioning alternate futures for operational context, mission, technologies etc.
– Identifying key issues and categorizing them as Criteria, Chances, Choices & Constituencies
– Clarifying Issues Tools: War gaming, Brainstorming, Delphi, Affinity Diagrams…

• Describing the potential uncertainties, decisions and criteria

– Assessing probability of occurrence and how that probability changes over time
– Understanding how uncertainties may be driven by more fundamental ones
– For each criteria perform Five Whys to infer the primary criteria/needs
– Identifying Uncertainties Tools: SME and Stakeholder Interviews, Five Whys, Root Cause Analysis…

• Identifying the contextual drivers of potential change

– Define a deterministic multi-objective measure of performance
– Relate multi-objective measure to the uncertainties and decisions (Influence Diagrams)
– Analyze the end-point uncertainties of the influence diagram to determine which uncertainties, when
varied over their range, cause the greatest change in value
– Identifying Drivers Tools: Influence Diagrams, Sensitivity Analysis, DOEs, Pareto Charting…

For all of its uncertainty, we cannot flee the future. - Barbara Jordan

page 96
 4. Design for Change Feature
Uncertainty Management
Influence Diagrams
Cost

• The adjacent example models cost as the

Manhours RDTE Human
Required per
Casualties
Innovation

relevant criteria Degree of

Innovation Procurement
Operations and
Maintenance Repair Loss of Life
Costs per Incident

• Great tool for identifying potential drivers Supplier

Variable
Fuel Costs

of change in complex systems Costs

Amortized
Fixed Costs
Maintenance
Costs
Cost per Salvage
Combat
Damage
Costs
Labor liter Costs

• Sensitivity - With this model we can

#Maintenance Fuel
Cycles Quality
Consumption
Materials Costs
#Damage
$/Worker Cost per
conduct a sensitivity analysis, via a DOE, #Workers
Supplier
Fixed Costs
Cost per
Failure #Quality
Incidents
Damage

to identify the impact and interaction Second-

Units
Purchased
Cost per
Cycle
Failures
Successful
Tier Supplier #km Incidents per
effects Costs Logistics

Spec.
Traveled #Combat
Influence
Engagements
Engagement

Tooling Plant
Diagram
• This DOE also allows for the estimation of Second-
Tier
Variable
Amortized
Fixed
Overhead Lethality Attacks per
Engagement
Mass
Criticality - Use a tornado chart (two-sided %Attacks
Deterred
%Adversary
Fixed Costs Speed
vertical Pareto chart) to identify the most Traveled
Ability

critical uncertainties Symbol Element Description

A variable that can be

Decision
modified directly

A value which cannot

Chance
be controlled directly,
Variable
is uncertain
A deterministic fuction
General
Design Of Tornado Variable
of the quantities is
depends on
Experiments Chart A measure of
Objective satisfaction with an
outcome, utility
Arrow An influence

page 97
 4. Design for Change
Architecture Management
Architecture Management Includes
• Informing system designers through analysis
– Provide rigor around how system elements
interact – pattern contains this key information

Functional Role.Vehicle Functional Roles.Vehicle Propulsion Subsystem.Flow Energy [Control Energy Flow]
– Understanding how system elements and
interactions are affected by change
– Modifying architectures to decrease sensitivity

Powertrain Power Management/Distribution System

Convert Mechanical Energy to Electrical Energy

Convert Electrical Energy to Mechanical Energy

Vehicle Passenger Environment Subsystem

Rolling Resistance [Slow or Stop Vehicle]

Vehicle External Appearance Subsystem
to change

Vehicle Exterior Structural Subsystem

Engine System [Internal Combustion]

Vehicle Interior Structural Subsystem

Vehicle Chassis Structure Subsystem

Vehicle Power & Data Mgmt & Dist

Convert Fuel to Mechanical Energy

Start and Stop Energy Conversion

Fuel Tank Capacity [Store Fuel]
Vehicle Management Feature
Vehicle Management System

Translate Torque to Wheels

Electric Motor / Generator

Infrastructure Availability
$root

Release Energy as Heat

Store Electric Energy

Fuel Supply System

Starter Generator
Consumalble Typ

Vehicle Driveline
Cooling System

Vehicle Interior

Body Structure
Operating Cost
Comfort Issue

Enable Rolling

Body Exterior
Suspension
Refuel Cost
Fuel Type

Steering
Wheels
Battery

Brakes
Range

10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
1
2
3
4
5
6
7
8
9
Feature
Vehicle Features
Vehicle
Range 1 2% 1 1 1 4 1 1 1 2 1 1 3

Comsumables
Consumalble Typ 2 2%
Fuel Type 3 1 2%

Performance
•

Passenger
Comfort Issue 4 2%

Architectural analysis of:

Cost Compatibility
Operating Cost 5 2%
Refuel Cost 6 1 2%

ofReliability
Infrastructure Availability 7 1 2%

Comfort
Operation
Feature Feature
Vehicle Management Feature 8 1 2%

Functional Role
Vehicle Functional Roles
Vehicle Management System 9 2% 1 4

&Feature
Vehicle External Appearance Subsystem 10 2% 1

Availability
Passenger
Vehicle Interior Structural Subsystem 11 2% 1 1 1
Vehicle Passenger Environment Subsystem 12 1 2% 1 1

GroupFeature
– Modularity & System Partitioning
Vehicle Exterior Structural Subsystem 13 2 5% 1
Vehicle Chassis Structure Subsystem 14 1 1 4 2% 1

Carrying
Vehicle Propelling Systems
Fuel Tank Capacity [Store Fuel] 15 1 2% 1 1 1
Convert Fuel to Mechanical Energy 16 2% 1 1 1 1
Rolling Resistance [Slow or Stop Vehicle] 17 1 2% 1 1 1 1 1 1 1
Convert Mechanical Energy to Electrical Energy
18 1 2% 1 1 1 1 1 1 1 1
Functional Role.Vehicle Functional Roles.Vehicle
19 Propulsion Subsystem.Flow Energy [Control Energy Flow]
1 1 2% 1 1 1 1
Store Electric Energy 20 1 1 2% 1 1 1

– Accommodating New Technology

Convert Electrical Energy to Mechanical Energy
21 1 2% 1 1
Start and Stop Energy Conversion 22 2% 1
Translate Torque to Wheels 23 1 1 2% 1 1
Enable Rolling 24 1 2%
Release Energy as Heat 25 2% 1

Design Component
Vehicle Design Components
Powertrain
Fuel Supply System 26 1 2% 1 1 3
Engine System [Internal Combustion] 27 1 1 1 1 12% 1 1 1 1 1 4
Starter Generator 28 1 1 1 2% 1 1 1 5

– Change Propagation and Impact

Cooling System 29 1 1 1 2% 1 1 1 1 5
Powertrain Power Management/Distribution 30System 1 1 1 1 2% 1 1 1 1 1 5
Battery 31 1 1 1 1 2% 1 1 5
Electric Motor / Generator 32 1 1 1 1 1 1 1 2% 1 1 5
Vehicle Driveline 33 1 1 1 1 1 3% 1 1 5

Chassis
Wheels 34 1 1 1 2% 1 1 1 4
Brakes 35 1 1 1 2% 1 1 5
Steering 36 1 1 1 2% 1 3
Suspension 37 1 1 1 2% 1

Vehicle Body
Vehicle Interior 38 1 1 2% 1 1 6
Body Exterior 39 1 1 1 2% 1 5
Body Structure 40 1 1 1 1 1 1 1 1 1 1 1 1 1 1 2% 6

Vehicle Electrical System

Vehicle Power & Data Mgmt & Dist 41 3 3 7 6 5 5 5 5 5 17 4 8 5 1 11 12 6 12%

Curiosity begins as an act of tearing to pieces or analysis. - Samuel Alexander

page 98
 Graph Theory & Design Structure Matrix
Systems Analysis
Powerful methods to analyze architectures
• The diagrams below provide two different views of a generic system with interrelationships as shown
• These interrelationships could be physical, informational, energy transfer or material/mass exchange
• Such diagrams are necessary to gain a better understanding of how systems elements interact

A B C D E F G H
A X
C B X X X
A G C X X X X X
D F D X X X
B H E X X
F X X X X X
E
G X X X
H X
Network Graph Matrix View
Lines indicate connectivity between elements X’s indicate connectivity between elements

The benefit of the matrix is that it provides a compact visual of the system and it enables
holistic systems modeling, analysis and optimization

page 99
 Design Structure Matrix Overview

$root
Design Structure Matrix (DSM)
A N
B C

1 Level 3 Names
• Square matrix- N x N or N2
DSM
NxN
• Analyze dependencies within a domain

10
11
12
13
14
15
16
17
18
20
21
22
23
24
25
26
27
28
29
30
31
32
34
35
36
37
38
39
40
41
42
43
44
45
2
3
4
5
6
8
9
Level 1
Level 2
Level 3 Names 1

•
2
Used for products, process and Organizations 3
4
• Binary marks “(1” or “X”) show existence of a 5

DSM MDM
A
6

Domain A
relation 8

Level 2.
9
10
Domain A Domains A, B & C
• Numerical entries are weights of relation 11
12
NxN
strength 13
14

• Can be directed or undirected (symmetrical)

15

Level 1
Level 2
16
17
18
20

Multi Domain Matrix (MDM) 21

DMM DSM
B
N
22
Domain B

23

• Square matrix - N x N or N2
Level 2

24
25
Domains A & B Domain B
26 AxB MxM
• Analyze dependencies across domain 27
28

• Combination of DSMs and DMMs 29

30
Level1
Level 2

31
• Especially helpful for DSMs > 1000 elements 32
34
35
36

DSM
C
37
Domain C

Domain Mapping Matrix (DMM)

38
DMM DMM
Level 2

39
40
Domain C
41 PxP
• Normally rectangular matrix – N x M 42
43

• Mapping between two domains 44

45

page 100
 Example Network Graphs and DSM Patterns
Understanding Architecture, Dependency and Related Patterns

Layout: Concentric • Symmetrical Layout: Circular • Non symmetrical

• Layered System – every systems uses • Layered System – every systems uses
every system below it every system below it

Layout: ForceAtlas2 • Symmetrical Layout: Yifan Hu • Symmetrical

• Non-Overlapping clusters • Overlapping clusters

page 101
 Example Network and DSM Patterns
Understanding Architecture, Dependency and Related Patterns

Unorganized
Network Graph
• Randomly generated

DSM
• Randomly ordered

Organized
Network Graph
• Nodes sized by degree
• Arranged by cluster

DSM
• Layered
• Change propagator, Element 10,
clearly shown at the bottom
• Clustered, showing both overlapping
non-overlapping and clusters

page 102
 4. Design for Change
Architecture Management
Modularization & System Partitioning
• Modularization is the grouping of system elements
that are mutually exclusive or minimally interacting
subsets (absorb interactions internally).
• It eliminates redundancy, minimizes external
connections
• It minimizes change propagation, enables technology
insertion and platform based engineering methods
making systems less sensitive to the uncertainties

26
27
28
29
33
34
35
36
37
38
39
40
41
Design Component
Vehicle Design Components
Powertrain

Vehicle Body Fuel Tank 26 2% 1

Power- 1 3
IC Engine System 27 1 12% 1 1 1 train 1 4

Chassis Starter Generator 28 1 2% 1 1 5

Power/
Electric Drive 29 1 1 % 1 1
Electrical
Vehicle Driveline 33 1 1 3% 1 1 5
Chassis

Wheels 34 1 2% 1 1 1 4
Brakes 35 1 1 2% 1 1 5
Steering 36 1 1 2% 1 3
Chassis
Suspension 37 1 1 1 2% 1
Vehicle Body

Vehicle Interior 38 Vehicle 2% 1 1 6

Ele. & Pwr.
Body Exterior 39 Body 1 2% 1 5
Powertrain Body Structure 40 1 1 1 1 1 1 1 2% 6
Vehicle Electric

Vehicle Power & Data Mgmt & Dist 41 7 6 5 17 4 8 5 1 11 12 6 12%

page 103
 4. Design for Change
Architecture Management
Accommodating New Technologies / Subsystems
• Patterns enable in depth analysis of design component selection
• Combining system and subsystem matrixes permits:
– Analysis of subsystem and technology integration complexity and risk
– Identification of potential cost drivers
– Further pattern recognition, development and refinement
Element Number 1 3 2 5 4 6 8 7 9 10 12 13 11 14 15 16 17 18 19 20 21 22 23 24 25
Body - Exterior 1 1 1 3 3
Body - Structure 3 1 1 1 1 1 1 1 1 1 1 1
Body - Interior 2 1 1 1 3 1
Powertrain - Powertrain Control Module 5 5 5 5 1 5 5
Powertrain - Transmission 4 5 3 1 1 5 3
Powertrain - Engine 6 5 3 1 1 1 5 3
Identify high impact
Chassis - Driveline 8 1 1 1 1 1 3 1 1 1 areas to a particular
Chassis - Frame 7 1 1 1 1 1 1 1 1 1
Chassis - Suspension 9 1 1
system element
Chassis - Steering 10 1 1 1 3 1 1
Identify which Chassis - Fuel Supply System 12 1 1 3 1
technology elements Chassis - Exhaust System 13 1 1 3 1
Chassis - Brakes 11 1 1 3 1 3 1 1 1 1
affect multiple system Electrical - Data System 14 3 3 5 5 5 3 3 3 1 3 3 3 5 5 5 5
level elements Electrical - Power Distribution 15 3 1 1 3 3 1 Element
1 1 1Number1 3 16 17
1 18
1 19
1 1 21
20 1 22
1 23
1 24
1 25
1
Chassis - Brakes - Exciter 16 1 Chassis - Brakes - Exciter 16 11
Chassis - Brakes - Speed Sensors 17 Chassis
1 - Brakes - Speed Sensors3 17
1 11 11 33
Assess multiple
Chassis - Brakes - ABS Control Module 18 1 5Chassis - Brakes - ABS Control Module
3 5 18
1 11 33 33 33 33 55 technologies to
Chassis - Brakes - ABS Pump 19 1 Chassis - Brakes - ABS Pump
1 19
1 33 1 1 1 33
Chassis - Brakes - ABS Modulator Valves 20 1 Chassis - Brakes - ABS Modulator Valves
1 20
1 33 1 11 11 33
determine Technology
Traction Control Solenoid Valve 21 1 Traction Control Valves/Solenoids
1 21
1 33 1 11 11 33 Invasiveness (Technology
Modulator Valves 22 33 1 11 11 33
Modulator Valves 22 1 1 1
Infusion – Oli de Weck)
Acceleration Sensor (Yaw,R,L) 23 1 Acceleration Sensor (Yaw,R,L)
5 23
1 55
Steering Angle/Position Sensor 24 1 Steering Angle/Position
1 Sensor
5 24
1 55
Electronic Controller Module & Data Bus 25 1 Electronic
5 Controller Module & Data Bus5 25
1 33 55 33 33 33 33 55 55

page 104
 4. Design for Change
Architecture Management
Change Propagation
• Realized uncertainties often drive engineering changes Generate more changes
Multipliers
which can easily balloon in an uncontrolled fashion than they absorb
Absorb a similar number of
• Knowing how changes propagate so 2nd, 3rd, and 4th Carriers
changes to those they cause
order impacts are known is very powerful Absorb more change they
Absorbers
themselves cause
• Early discovery of ”propagation paths” can have a
significant impact on total life cycle cost.1 Constants Unaffected by change 1
• Architectural analysis and understanding of system 1. Eckert C, (2004) Change and Customization in
Complex Engineering Domains, Research in Eng. Design
patterns helps control change propagation

26
27
28
29
33
34
35
36
37
38
39
40
41
# of Elements # Dependencies
Design Component
Vehicle Design Components
Powertrain

Fuel Tank 26 1 1 3 3 5
IC Engine System 27 1 1 1 1 1 4 6 11
Starter Generator 28 1 1 1 5 4 10
Electric Drive 29 1 1 1 1 4 8
Vehicle Driveline 33 1 1 1 1 5 5 11
Chassis

Wheels 34 1 1 1 1 4 5 8
Brakes 35 1 1 1 1 5 5 10
Steering 36 1 1 1 3 4 6
Suspension 37 1 1 1 1 4 4
Vehicle Body

Vehicle Interior 38 1 1 6 3 8
Body Exterior 39 1 1 5 3 7
Body Structure 40 1 1 1 1 1 1 1 6 8 17
Vehicle Electrical System

Vehicle Power & Data Mgmt & Dist 41 7 6 5 17 4 8 5 1 11 12 6 11 102

All change is not growth, as all movement is not forward. - Ellen Glasgow

page 105
 4. Design for Change
Architecture Management
Impact Analysis
• Product Line/System Families/Platforms: The common system pattern which enable
rapid specialization or configuration of individual products / systems configurations i.e.
product variants. Change impact analysis can aid in determining which elements
remain a part of the family pattern, which are unique and which should become flexible.
Prioritize
Feature
Vehicle Features
Vehicle

Range 1 2% 1 1 1 4 1 1 1 2 1 1 3
Comsumables

Consumalble Typ 2 2%
Fuel Type 3 1 2%
impacted
Performance
Passenger

Comfort Issue 4 2%
Generate impact element
CostCompatibility

Operating Cost 5 2%
Refuel Cost 6 1 2%
report of realized /
ofReliability

Infrastructure Availability 7 1
analysis by
Comfort
Feature

2%
Operation

 Range
Vehicle Management Feature 8 1 2%
modeled secondary
Functional Role
Vehicle Functional Roles

Vehicle Management System 9 2% 1 4

Feature
&Feature

Vehicle External Appearance Subsystem 10 2% 1

uncertainties
Availability

criteria such as
Passenger

Vehicle Interior Structural Subsystem 11 2% 1 1 1

GroupFeature

Vehicle Passenger Environment Subsystem 12 1 2% 1 1

Vehicle Exterior Structural Subsystem
Vehicle Chassis Structure Subsystem
13 2
14
5%
1 1 4 2%
1
1
change
Carrying

propagation,
Vehicle Propelling Systems

Fuel Tank Capacity [Store Fuel] 15 1 2% 1 1 1

Convert Fuel to Mechanical Energy 16 2% 1 1 1 1
Rolling Resistance [Slow or Stop Vehicle] 17 1
Convert Mechanical Energy to Electrical Energy
18
2%
1
1
2% 1
1
1 1 1
1
1
1 1
1 1
1
1
1 cost, integration
Functional Role.Vehicle Functional Roles.Vehicle
19 Propulsion Subsystem.Flow Energy [Control Energy Flow]
1 1 2% 1 1 1 1 1 risk, coupling…
Store Electric Energy 20 1 1 2% 1 1 1
Convert Electrical Energy to Mechanical Energy
21 1 2% 1 1
Start and Stop Energy Conversion 22 1 2% 1
Translate Torque to Wheels 23 1 1 2% 1 1
Enable Rolling 24 1 2%
Release Energy as Heat 25 2% 1
Design Component
Vehicle Design Components
Powertrain

Fuel Tank 26 1 2% 1 1 3
IC Engine System 27 1 1 1 1 12% 1 1 1 1 1 1 4
Starter Generator 28 1 1 1 2% 1 1 1 1 5
Electric Drive 29 1 1 % 1 1 1 1 1 1
Cooling System 29 1 1 1 1 2% 1 1 1 1 5
Powertrain Power Management/Distribution 30System 1 1 1 1 1 2% 1 1 1 1 1 5
Battery
Electric Motor
31 1
32 1 1 1
1
1
1
1
1
1
1 2% 1
1 1 2% 1
1
1
5
5
Address
Vehicle Driveline 33 1 1 1 1 1 1 3% 1 1 5
uncertainty as
Chassis

Wheels 34 1 1 1 2% 1 1 1 4
Brakes
Steering
35
36 1
1 1 1 1 2% 1
1 1 2% 1
1 5
3
high up in the
Suspension 37 1 1 1 2% 1
pattern as
Vehicle Body

Vehicle Interior 38 1 1 2% 1 1 6
Body Exterior
Body Structure
39 1
40 1
1
1 1 1 1 1 1 1 1 1 1 1
1 2% 1
1 1 2% 6
5
possible to
leverage across
Vehicle Electrical System

Vehicle Power & Data Mgmt & Dist 41 3 3 7 6 5 5 5 5 5 17 4 8 5 1 11 12 6 12%

1. deWeck, Oli, Strategic Engineering: Designing Systems for an Uncertain Future, Flexible Product Platforms: Framework and Case Study the portfolio
2. Kalligeros K., de Weck O., de Neufville R., Luckins A., "Platform Identification using Design Structure Matrices", Sixteenth Annual International
Symposium of the International Council On Systems Engineering (INCOSE), Orlando, Florida, 8 - 14 July 2006

page 106
 Functional Role.Vehicle Functional Roles.Vehicle Propulsion

Powertrain Power Management/Distribution System

4. Design for Change

Convert Mechanical Energy to Electrical Energy

Convert Electrical Energy to Mechanical Energy

Vehicle Passenger Environment Subsystem
Architecture Management

Rolling Resistance [Slow or Stop Vehicle]

Vehicle External Appearance Subsystem

Vehicle Exterior Structural Subsystem

Engine System [Internal Combustion]

Vehicle Interior Structural Subsystem

Vehicle Chassis Structure Subsystem

Vehicle Power & Data Mgmt & Dist

Convert Fuel to Mechanical Energy

Start and Stop Energy Conversion

Fuel Tank Capacity [Store Fuel]
Vehicle Management Feature
Vehicle Management System

Translate Torque to Wheels

Electric Motor / Generator

Vehicle Example

Infrastructure Availability
$root

Release Energy as Heat

Store Electric Energy

Fuel Supply System

Starter Generator
Consumalble Typ
MDM

Vehicle Driveline
Cooling System

Vehicle Interior

Body Structure
Operating Cost
Comfort Issue

Enable Rolling

Body Exterior
Suspension
Refuel Cost
Fuel Type

Steering
Wheels
Battery

Brakes
Range
Features

10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
1
2
3
4
5
6
7
8
9
Feature
Vehicle Features
Vehicle
Range 1 2% 1 1 1 4 1 1 1 2 1 1 3

Comsumables
Consumalble Typ 2 2%
Fuel Type 3 1 2%

Performance
Passenger
Comfort Issue 4 2%

Cost Compatibility
Operating Cost 5 2%
Refuel Cost 6 1 2%

ofReliability
Infrastructure Availability 7 1 2%
Comfort
Operation
Feature Feature
Vehicle Management Feature 8 1 2%
Functional Role
Vehicle Functional Roles

Requirement X Vehicle Management System 9 2% Chunks of 1 4

&Feature

Vehicle External Appearance Subsystem 10 2% Behavior 1

Regenerative
Availability
Passenger

Vehicle Interior Structural Subsystem 11 2% 1 1 1

Vehicle Passenger Environment Subsystem 12 1 2% 1 Braking 1
GroupFeature

Vehicle Exterior Structural Subsystem 13 2 5% 1

Functional Roles Vehicle Chassis Structure Subsystem 14 1 1 4 2% 1

Carrying
Vehicle Propelling Systems

Fuel Tank Capacity [Store Fuel] 15 1 2% 1 1 1

Convert Fuel to Mechanical Energy 16 2% 1 1 1 1
Rolling Resistance [Slow or Stop Vehicle] 17 1 2% 1 1 1 1 1 1 1
Convert Mechanical Energy to Electrical Energy
18 1 2% 1 1 1 1 1 1 1 1
Functional Role.Vehicle Functional Roles.Vehicle
19 Propulsion Subsystem.Flow Energy [Control Energy Flow]
1 1 2% 1 1 1 1
Store Electric Energy 20 1 1 2% 1 1 IC Engine1
Convert Electrical Energy to Mechanical Energy
21 Drive Electric 1 2% 1 1
Related Design
Start and Stop Energy Conversion 22 2% 1 Components
Translate Torque to Wheels 23 1 1 2% 1 1
Enable Rolling 24 1 2%
Range
Release Energy as Heat 25
Feature 2% 1 Extender

Traceability
Design Component
Vehicle Design Components
Powertrain

Fuel Supply System 26 1 2% 1

Electric 1 3

Design Components Engine System [Internal Combustion]

Starter Generator
27 1
28
1
1
1
1
1 12% 1
1 2%
1
1
1
1
1
Drive
1
1
4
5
Cooling System 29 1 1 1 2% 1 1 1 1 5
Powertrain Power Management/Distribution 30System 1 1 1 1 2% 1 1 1 Chassis
1 1 5
Battery 31 1 1 1 1 2% 1 1 5
Electric Motor / Generator 32 1 Functional
1 1 1 1 1 1 2% 1
Body1
1 5
Vehicle Driveline 33 1 1 1 1 1 3% 1 5
Allocations/
Chassis

Wheels 34 1 1 1 2% 1 1 1 4
Brakes 35 Traceability1 1 1 2% 1 1 5
Steering 36 1 1 1 2% 1 3
Suspension 37 Power/Data 1 1 1 2% 1
Bus
Vehicle Body

Vehicle Interior 38 1 1 2% 1 1 6
Body Exterior 39 1 1 1 2% 1 5
Body Structure 40 1 1 1 1 1 1 1 1 1 1 1 1 1 1 2% 6
1
Vehicle Electrical Sy

Vehicle Power & Data Mgmt & Dist 41 3 3 7 6 5 5 5 5 5 17 4 8 5 1 11 12 6 12%

page 107
 4. Design for Change
Improving System Resiliency

Designing for Change Benefits:

Feature
Vehicle Features
Vehicle
Range 1 2% 1 1 1 4 1 1 1 2 1 1 3

Comsumables
Consumalble Typ 2 2%
Fuel Type 3 1 2%

Performance
Passenger
Comfort Issue 4 2%

– Provide a means to accommodate rapidly

CostCompatibility
Operating Cost 5 2%
Refuel Cost 6 1 2%

ofReliability
Infrastructure Availability 7 1

Comfort
Feature
2%

Operation
Vehicle Management Feature 8 1 2%

Functional Role
Vehicle Functional Roles
Vehicle Management System 9 2% 1 4

Feature
&Feature
Vehicle External Appearance Subsystem 10 2% 1

Availability
Passenger
Vehicle Interior Structural Subsystem 11 2% 1 1 1

GroupFeature
Vehicle Passenger Environment Subsystem 12 1 2% 1 1

changing needs
Vehicle Exterior Structural Subsystem 13 2 5% 1
Vehicle Chassis Structure Subsystem 14 1 1 4 2% 1

Carrying
Vehicle Propelling Systems
Fuel Tank Capacity [Store Fuel] 15 1 2% 1 1 1
Convert Fuel to Mechanical Energy 16 2% 1 1 1 1
Rolling Resistance [Slow or Stop Vehicle] 17 1 2% 1 1 1 1 1 1 1
Convert Mechanical Energy to Electrical Energy
18 1 2% 1 1 1 1 1 1 1 1
Functional Role.Vehicle Functional Roles.Vehicle
19 Propulsion Subsystem.Flow Energy [Control Energy Flow]
1 1 2% 1 1 1 1 1
Store Electric Energy 20 1 1 2% 1 1 1
Convert Electrical Energy to Mechanical Energy
21 1 2% 1 1
Start and Stop Energy Conversion 22 1 2% 1
Translate Torque to Wheels 23 1 1 2% 1 1
Enable Rolling 24 1 2%

– Measure change impact and improve

Release Energy as Heat 25 2% 1

Design Component
Vehicle Design Components
Powertrain
Fuel Tank 26 1 2% 1 1 3
IC Engine System 27 1 1 1 1 12% 1 1 1 1 1 1 4
Starter Generator 28 1 1 1 2% 1 1 1 1 5
Electric Drive 29 1 1 % 1 1 1 1 1 1
Cooling System 29 1 1 1 1 2% 1 1 1 1 5
Powertrain Power Management/Distribution 30System 1 1 1 1 1 2% 1 1 1 1 1 5
Battery 31 1 1 1 1 1 2% 1 1 5

pattern management evolution and

Electric Motor 32 1 1 1 1 1 1 1 1 2% 1 1 5
Vehicle Driveline 33 1 1 1 1 1 1 3% 1 1 5

Chassis
Wheels 34 1 1 1 2% 1 1 1 4
Brakes 35 1 1 1 1 2% 1 1 5
Steering 36 1 1 1 2% 1 3
Suspension 37 1 1 1 2% 1

Vehicle Body
Vehicle Interior 38 1 1 2% 1 1 6

26
27
28
29
33
34
35
36
37
38
39
40
41
Body Exterior 39 1

leverage Body Structure 40 1

# of Elements
1
1 1
# Dependencies 1 1 1 1 1 1 1 1 1
1 2% 1
1 1 2% 6
5

Design Component
Vehicle Design Components
Powertrain
Fuel Tank 26 3 5

Vehicle Electrical System

1 Vehicle Power & Data Mgmt & Dist 41 3 1 3 3 7 6 5 5 5 5 5 17 4 8 5 1 11 12 6 12%

IC Engine System 27 1 1 1 1 1 4 6 11
Starter Generator 28 1 1 1 5 4 10
Electric Drive 29 1 1 1 1 4 8
Vehicle Driveline 33 1 1 1 1 5 5 11

Chassis
– Improve new ility system characteristics
Wheels 34 1 1 1 1 4 5 8
Brakes 35 1 1 1 1 5 5 10
Steering 36 1 1 1 3 4 6
Suspension 37 1 1 1 1 4 4

Vehicle Body
Vehicle Interior 38 1 1 6 3 8
Body Exterior 39 1 1 5 3 7
Body Structure 40 1 1 1 1 1 1 1 6 8 17

– Supports platform methods reducing total

Vehicle Electrical System

Vehicle Power & Data Mgmt & Dist 41 7 6 5 17 4 8 5 1 11 12 6 11 102

life cycle cost

– Avoids the Flaw of Averages

• Assuming that evaluation of accommodating
an uncertainty based upon average
conditions gives a correct result1.

1. Flexibility in Engineering Design: de Neufville and Scholtes, 2011 - http://mitpress.mit.edu/books/flexibility-engineering-design

page 108
 5. Using Patterns to Improve Risk
Analysis: Example
• Concept: A System Pattern can be used to generate more complete risk analyses,
and with less effort;
• Because the Feature Pattern by intention represents the stakeholder level
concerns of all classes of stakeholders:
– Features are the only things that can possibly be at risk!
• For example, in an FMEA, the only possible “Effects” at risk are the system
Features:
– The System Pattern can provide a pre-stored library of Impacts of non-delivery / non-
performance of each Feature, even before a design exists.
• Similarly, analysis and management of Project Risks, Technology Risks, doing a
Preliminary Hazard Analysis (PHA), Fault Tree Analysis, integrating Technology
Readiness Levels (TRLs), or other forms of risk analysis can all be viewed
through the integrated lens of Stakeholder Features
• This has a nice integration effect—for example, project “top level” risk reports or
views can be expressed in the form of master risk views . . . .

page 109
 5. Using Patterns to Improve Risk
Analysis: Example
Vehicle System Configurations: Summary Scoring
Vehicle Config A

Vehicle Config A

Vehicle Config A

Vehicle Config A

Vehicle Config A
Vehicle Config B

Vehicle Config B

Vehicle Config B

Vehicle Config B

Vehicle Config B
Vehicle Config C

Vehicle Config C

Vehicle Config C

Vehicle Config C

Vehicle Config C
V V V V V V V V V V V V V V V
Personal Vehicle Environmental Consumable Vehicle
Safety Feature
Application Compatibility Compatibility Performance
Group
Feature Group Feature Feature Feature

Reliability &
Vehicle Delivery Vehicle Aesthetics Vehicle Comfort Cost of Operations
Availability
Feature Feature Group Feature Group Feature
Feature

Operability Maintainability Configurability Accountability

Security Feature
Feature Feature Feature Feature

Remote
Communications
Management
Feature Group
Access Feature

STATUS LEGEND: COLUMN LEGEND:

Unsatisfied or unknown Vehicle Config A
Satisfied, low margin Vehicle Config B
Satisfied, in margin Vehicle Config C
Satisfied, high margin
Not applicable to this config

page 110
5. Using Patterns to Improve Risk Analysis: Example
Physical Entity Failure Mode
Vehicle ECM Dead ECM
Vehicle ECM Network Connector Open
Vehicle ECM Network Connector Short
Vehicle ECM Erratic ECM
Battery Discharged Battery
Battery Battery Cell Short
Battery Battery Cell Open
Battery Battery Leak
Panel Display Fractured Display
Panel Display Illuminator Fail
Bluetooth Module Module Hard Fail
Bluetooth Module Transmitter Fail
Bluetooth Module Receiver Fail
page 111
 Using Patterns to Improve Risk Analysis: Failure Modes
• The pattern is used to accumulate experience in the following Risk Model
areas:
– Feature Impacts: The stakeholder impact of non-delivery of a Feature
– Counter-Requirements: An (abnormal) behavior violating a System
Requirement
– Failure Mode: A state of an entity in which its behavior includes at least one
Counter Requirement

page 112
 Using Patterns to Improve Risk Analysis:
Example

Feature Effect Severit Functional Component Failure Probability Mitigation

(Failure y Failure (Counter Mode (Control)
Impact) Requirement)
Navigation No Serious The system displays Vehicle ECM Erratic 0.0015 Nav Backup
Feature [GPS- Confidence in (4) a location that is not ECM Mode:
based Location Displayed accurate to 10 feet. External Nav
Sensing] Position Module
Navigation False Critical The system displays Vehicle ECM Erratic 0.0015 None
Feature [GPS- Confidence in (5) a location confidence ECM
based Location High Error indicator that is not
Sensing] Displayed correct.
Position
Navigation No Displayed Serious The system does Panel Fractured 0.0003 Nav Backup
Feature [GPS- Location (4) not display the Display Display Mode:
based Location graphic map External Nav
Sensing] presentation. Module

page 113
 Design
Failure Mode Functional Role
Component
Probability

Logical Counter- Physical Failure Mode

Requirements Space Space

Stakeholder Functional Technical

Feature Requirement
Language Interaction Language

Failure Counter FMEA Functional

FMEA Failure
Effects
Impact Requirement Failures
Severity

Stakeholder

page 114
 Combinatorial “matching up” of
requirements-design pairs
Logical Counter- Physical Failure Mode
Requirements Space Space

• The Functional Failures (counter requirements) and Failure Effects (feature failure impact) data can be pre-
populated independent of the system’s internal design, and the Failure Mode data for standard component
roles can be pre-populated independent of the system’s external requirements.
– So, when both the requirements and a candidate design have become known, how do these two halves of the failure analysis model get
connected to each other?
– This turns out to be a combinatorial algorithm.
• First, it turns out that the counter-requirements (functional failures) obtained by reversing the requirements
statements may describe some hypothetical external behaviors that are never (or with probability too small to
matter) caused by component failure modes.
– This will cause some pre-populated functional failures to be dropped.
– For example, a requirement that a product weigh less than one pound has a counter-requirement that it weighs more than one pound.
– It may be determined that there is no component failure mode that impacts weight, so that this functional failure is dropped from the list.
– Notice that even this failure mode could happen for some products—for example, a hazard protection suit that becomes wet weighs more.
• Second, it turns out that some failure modes of a physical component have no consequence on the product’s
required behavior, because the failure mode goes with a role not allocated to the part in this particular product
design.
– For example, an integrated circuit may have built-in circuitry for performing certain functions which are not used by a certain product’s
design, even though other portions of that chip are used.
• The connection of the requirements half of the failure analysis to the design half of the failure analysis is
made by matching up “mating” pairs, and discarding what is left as not applicable (after checking for missed
cases this approach also helps us find—another benefit) . . .

115
 Combinatorial “matching up” of
requirements-design pairs
Logical Counter- Physical Failure Mode
Requirements Space Space

• The “matching up” is accomplished through the matching of counter-requirements with failure modes.
– Each failure mode causes some abnormal behavior.
– All abnormal behavior is described by counter requirements. When we find a counter-requirement belonging to a failure impact is equal
to a counter-requirement for a failure mode, that pair is associated together, completing two major sections of a row in a failure analysis
table.
– Some failure modes may connect to multiple counter requirements and some counter requirements may connect to multiple failure
modes.
• This process may use two levels of requirements, in the form of system black box requirements and their
decomposed white box requirements (allocated to physical parts), in which case counter-requirements may
be developed at both levels.
– A simpler alternate method is to use only one level of counter-requirements, with the component failure modes associated directly with
the resulting abnormal behavior at the black box level—in which case the association of failure modes with abnormal behavior is
dependent upon knowing the system level design.
– Likewise, the states discussed above may be at two levels, representing states (and failure modes) of system components and the
whole system, or simplified to states of the whole system, in which case the failure modes are modes of the whole system and again
dependent upon its design.
• The discussion above assumes failure modes originate in internal system components, typical of analyses
such as a Design FMEA (D-FMEA).
– Also discussed later below are failure modes of external people or processes (actors) that impact upon the subject system, as seen in
an Application FMEA (A-FMEA) or a Process FMEA (P-FMEA).
– The counter-requirements and physical mode matching-up approach is substantially the same in these cases.
 5. Using Patterns to Improve Risk Analysis:
Example

• Benefits:
– Generate initial FMEA or other risk analyses with less initial effort;
– More complete—reduces omissions;
– Feels more systematic than the usual FMEA process;
– Generates the “normal” FMEA view
– Easier to generate from pattern;
– Stages—without failure modes versus with failure modes
– The Pattern provides a clear place to accumulate new learning (e.g.,
additional Requirements);
• No free lunch:
– Analysis should still pass through normal SME review—this is just a
way to generate the first draft faster and in more complete form;
– Incomplete models of features, requirements, or failure modes means
incomplete failure risk analysis.
page 117
 6. Using Patterns to Improve
Verification

• Concept: Patterns help generate better Verification Plans

faster—including plans for Design Review, Simulation,
System Test, etc.
• Verification is concerned with confirming that a candidate
design will meet requirements;
• In some domains (medicine, flight, etc.), verification
represents a high fraction of large costs and time
investment—patterns can help reduce this;
• Patterns represent: Requirements, Design, and connecting
relationships—including the degree of their consistency with
each other, as well as the means of verifying it.

page 118
 There are a limited number of types of
potential misalignments to check and close

Scope of Requirements Review Scope of Design Verification

Shortfall? Shortfall? Shortfall? Shortfall?

Overshoot? Overshoot? Overshoot? Overshoot?

Stakeholder Stakeholder Black Box White Box Design Component

or Subsystem
Needs Features Requirements Requirements Capabilities

“Keep the product “Product “Maintain storage space “Measure air “Thermodyne Model TC-58
o
cool.” Protection” air temperature at 45 temperature accurate measures air temperature
o o o
F, +/- 2 .” to 0.3 F.” accurate to 0.25 F.”

(All these misalignments are ultimately measured in terms of their impact on Features.)

page 119
Six questions for Design Review:

5. Do the Components fulfill the

requirements allocated to them?

page 120
 6. Using Patterns to Improve
Verification: An Example
• Using the System Pattern, configuring its Features not only configures
the Requirements, it also populates the Verification Approach (plan):

page 121
 6. Using Patterns to Improve
Verification: An Example
• Configuring both the Requirements, as well as the High Level Design,
also configures the Decomposition and related Verification:

“Maintain storage space “Measure air “Thermodyne Model TC-58

o
air temperature at 45 temperature accurate measures air temperature
o o o
F, +/- 2 .” to 0.3 F.” accurate to 0.25 F.”

Black Box White Box Design Component or

Requirements Requirements Subsystem
Temperature Range (Required) Accuracy (Required) Manufacturer
Temperature Range (Capability) Accuracy (Capability) Model No.

page 122
 6. Using Patterns to Improve
Verification

• “Test” includes not just functional testing, but also characterization

testing, such as planned in the methods of DOE and Taguchi:

“Keep the product “Product Protection “Maintain storage space “Measure air “Thermodyne Model TC-58
o
cool.” for Xiamine” air temperature at 45 temperature accurate measures air temperature
o o o
F, +/- 2 .” to 0.3 F.” accurate to 0.25 F.”

Stakeholder Stakeholder Black Box White Box Design Component or

Needs Features Requirements Requirements Subsystem
Product Potency (Required) Temperature Range (Required) Accuracy (Required) Manufacturer
Product Potency (Capability) Temperature Range (Capability) Accuracy (Capability) Model No.

Characterization of these parametric couplings

Characterization of these parametric
is the realm of market research, human factors
couplings is the realm of DOE and
analysis, consumer research.
Taguchi methods

page 123
 6. Using Patterns to Improve Verification

• Benefits:
– Accumulation of good test methods reduces re-invention of the
testing “wheel”.
– Accumulation of known design review trace information reduces
effort to generate paper design review analysis.
– The Pattern provides a place to accumulate this learning.
• No Free Lunch:
– Just because we are re-using these assets does not mean we
don’t have to think.
– For example, we need to assure ourselves that previous test
methods and design review decompositions really do apply in the
next case at hand.

page 124
 Challenges and Opportunities

1. Human hurdles: Inventing from scratch,

expertise

2. Organizational hurdles: Better business models

are nevertheless unfamiliar

Exercise / group discussion: Approaches to my situation

page 125
 Human hurdles
• Engineers and other designers enjoy creating things—sometimes
even if the thing has been created before:
– This may lead to re-traveling paths, sometimes re-discovering
things the hard way (e.g., overlooking requirements, using over-
simplifications, etc.)
– In any case, it can expend time and effort in re-generating, re-
validating, and re-verifying what others had already done.
• In other cases, human subject matter experts provide great expertise:
– but it is accessible only in the form of the presence of the SME,
and after accumulating years of experience.
– Seemingly more a craft of journeymen experts than a discipline
based upon teachable principles.
• All these challenges can be viewed as resistance to expressing and
applying explicit patterns.

page 126
 Human hurdles

• A broad issue across human life:

– The science of irrationality
– Daniel Kahneman, Nobel Laureate, “Thinking, Fast
and Slow”)
– “Moneyball”, Oakland A’s, Billy Beane.

• Engineering teams more rational than others?

– Ever encounter a bad decision?
– A significant fraction of requirements are left unstated

• Patterns existing in Nature do not mean the

patterns are recognized by humans

page 127
Organizational hurdles: Better business
processes are nevertheless unfamiliar

page 128
 Challenges and Opportunities: Organizational hurdles

• Better business processes may nevertheless be unfamiliar;

• Some familiar organizational paradigms can be leveraged
in explaining to others: e.g.:
– Standards groups, change control boards
– Platform management processes
– Standard parts processes

page 129
 Exercise: What seems most important?
What seems most actionable?
Pattern Applications & Benefits Importance Actionable
1. Stakeholder Features and Scenarios: Better stakeholder
alignment sooner
2. Pattern Configuration: Generating better requirements faster
3. Selecting Solutions: More informed trade-offs and design
reviews
4. Design for Change: Analyzing and improving platform resiliency
5. Risk Analysis: Pattern-enabled FMEAs
6. Verification: Generating better verifications, tests faster

• Rank importance (1-6 ; 1 = most important)

• Rank actionable (1-6 ; 1 = most actionable)

page 130
 Exercise / Group Discussion:
Approaches to my situation
• Write your ideas about what you could do next, in these areas:
– Learn more:
– Try an experiment:
– Build a pattern:
– Apply PBSE to:
– Take a class:
– Other:

• The INCOSE Patterns Working Group will meet at IW2017 in LA

(January 28-31, 2017):
– Contact [email protected] or [email protected]
if you are interested in this INCOSE working group.

page 131
 Conclusions
1. Patterns abound in the world of systems engineering.
2. These patterns extensively impact our projects, whether we take
advantage of them as Explicit Patterns, or we are negatively impacted
by Dark Patterns.
3. Pattern-Based Systems Engineering (PBSE) offers specific ways to
extend MBSE to exploit Patterns.
4. Patterns provide benefits across many SE areas, through better models
available at lower costs per project.
5. MBSE comes first—Patterns without Models is like orbital mechanics
before Newton: useful but not as powerful as it could be.
6. We’ve had good success applying pattern-based methods in
mil/aerospace, automotive, medical/health care, advanced
manufacturing, and consumer product domains.
7. In site of the net benefits, change is difficult, so both MBSE and PBSE
are not without challenges.

page 132
Representing Systems: References
1.W. Schindel, “Requirements statements are transfer functions: An insight from model-based systems engineering”,
Proceedings of INCOSE 2005 International Symposium, (2005).
2.W. Schindel, “What Is the Smallest Model of a System?”, Proc. of the INCOSE 2011 International Symposium,
International Council on Systems Engineering (2011).
3.Schindel, W., “System Interactions: Making The Heart of Systems More Visible”, Proc. of INCOSE Great Lakes Regional
Conference, 2013.
4.W. Schindel, “Got Phenomena? Science-Based Disciplines for Emerging Systems Challenges”, Proc. Of the INCOSE
2016 International Symposium, Edinburgh, UK, 2016.
Patterns; Pattern-Based Systems Engineering:
5.INCOSE Patterns Working Group, “MBSE Methodology Summary: Pattern-Based Systems Engineering (PBSE), Based
On S*MBSE Models”, V1.5.5A, retrieved from: http://www.omgwiki.org/MBSE/doku.php?id=mbse:pbse
6.INCOSE MBSE Initiative Patterns Working Group web site, at
http://www.omgwiki.org/MBSE/doku.php?id=mbse:patterns:patterns
7.W. Schindel, “Pattern-Based Systems Engineering: An Extension of Model-Based SE”, INCOSE IS2005 Tutorial TIES 4,
(2005).
8.J. Bradley, M. Hughes, and W. Schindel, “Optimizing Delivery of Global Pharmaceutical Packaging Solutions, Using
Systems Engineering Patterns” Proceedings of the INCOSE 2010 International Symposium (2010).
9.W. Schindel, and V. Smith, “Results of applying a families-of-systems approach to systems engineering of product line
families”, SAE International, Technical Report 2002-01-3086 (2002).
10.W. Schindel, “The Impact of ‘Dark Patterns’ On Uncertainty: Enhancing Adaptability In The Systems World”, INCOSE
Great Lakes 2011 Conference, Dearborn, MI, 2011.
11.W. Schindel and T Peterson, “Introduction to Pattern-Based Systems Engineering (PBSE): Leveraging MBSE
Techniques”, Tutorial at INCOSE Great Lakes Regional Conference, September, 2016.
Systems Engineering in Innovation:
12.Schindel, W., “Introduction to the Agile Systems Engineering Life Cycle MBSE Pattern ”, Proc. Of the INCOSE 2016
International Symposium, Edinburgh, UK, 2016.
13.W. Schindel, S. Peffers, J. Hanson, J. Ahmed, W. Kline, “All Innovation is Innovation of Systems : An Integrated 3-D
Model of Innovation Competencies ”, Proc. of ASEE 2011 Conference (2011).
page 133
 References
Analysis of Architecture, Changeability, Modularity:
14.Carlos A. Osorio, Dov Dori, Joseph Sussman, “COIM: An Object-Process Based Method for Analyzing Architectures
of Complex, Interconnected, Large-Scale Socio-Technical Systems”, Systems Engineering Vol. 14, No. 4, pp. 364-
382, 2011.
15.Jason E. Bartolomei, Daniel E. Hastings, Richard de Neufville, and Donna H. Rhodes, “Engineering Systems
Multiple-Domain Matrix: An Organizing Framework for Modeling Large-Scale Complex Systems”, Systems
Engineering, Vol. 15, No. 1, pp. 41- 61, 2012.
16.Azad M. Madni, “Adaptable Platform-Based Engineering: Key Enablers and Outlook for the Future”, Systems
Engineering, Vol. 15, No. 1, pp. 95-107, 2012.
17.Tobias K.P. Holmqvist and Magnus L. Persson, “Analysis and Improvement of Product Modularization Methods:
Their Ability to Deal with Complex Products”, Systems Engineering, Vol. 6, No. 3, pp. 195-209, 2003.
18.Ernst Fricke, and Armin P. Schulz, “Design for Changeability (DfC): Principles To Enable Changes in Systems
Throughout Their Entire Lifecycle”, Systems Engineering, Vol. 8, No. 4, pp. 342-359, 2005
19.Avner Engel, * and Tyson R. Browning, “Designing Systems for Adaptability by Means of Architecture Options”,
Systems Engineering, Vol. 11: pp. 125–146, 2008.
20. David M. Sharman and Ali A. Yassine, “Characterizing Complex Product Architectures”, Systems Engineering, Vol.
7, No. 1, pp. 35-60, 2004.
21.Adam M. Ross, Donna H. Rhodes, and Daniel E. Hastings, “Defining Changeability: Reconciling Flexibility,
Adaptability, Scalability, Modifiability, and Robustness for Maintaining System Lifecycle Value”, Systems
Engineering, Vol. 11, No. 3, pp. 246-262, 2008.
Other Systems Engineering References:
22.ISO/IEC 15288: Systems Engineering—System Life Cycle Processes. International Standards Organization (2008).
23.INCOSE Systems Engineering Handbook: A Guide for System Life Cycle Processes and Activities, Version 3.2,
International Council on Systems Engineering (2010).
24.NASA Systems Engineering Handbook, NASA/SP-2007-6105, Rev 1, U.S. National Aeronautics and Space
Administration (2007).
25.W. Schindel, “Failure Analysis: Insights from Model-Based Systems Engineering”, Proceedings of INCOSE 2010
Symposium, July 2010.
page 134
About the presenters
Troy Peterson, the Vice President of Systems Strategy, Inc., is a
Systems Engineering thought leader helping clients confront
critical systems challenges. He's led several teams in the delivery
of complex systems and has instituted numerous methodologies
to speed development times. His experience spans academic,
commercial and government environments across all product life
cycle phases. Troy is INCOSE Assistant Director for
Transformation of Systems Engineering to a Model Based
Discipline, and co-chair of the INCOSE Patterns Working Group.

William D. (Bill) Schindel, president of ICTT System Sciences,

practices advance of Pattern-Based Systems Engineering across
multiple industry domains and applications. His engineering
career began in mil/aero systems with IBM Federal Systems,
included faculty service at Rose-Hulman Institute of Technology,
and founding of three systems enterprises. Bill co-led a project on
Systems of Innovation in the INCOSE System Science Working
Group. He co-leads the INCOSE Patterns Working Group and is a
member of lead teams of the INCOSE Agile SE Life Cycle
Discovery Project and the INCOSE Transformation.
page 135