Modeling Methodology For Systems v4.0

Modeling Methodology for Systems ©
3DS.COM © Dassault Systèmes | Confidential Information | 3/7/2016 | ref.: 3DS_Document_2014
Example of the elevator

[x] Glossary Reference
By Gauthier Fanmuy, Arnaud Durantin,

Bertrand Faure and Hugo Messicat
© Dassault Systèmes
Modifications and versions
Date of modification Authors Version Nature of modifications
08/07/2015 Gauthier Fanmuy, Arnaud Durantin, V0 First full version

Bertrand Faure, Hugo Messicat
04/11/2015 Gauthier Fanmuy, Pierre-Yves Boyer V1 Transitions between system
layers
13/11/2015 Gauthier Fanmuy, Arnaud Durantin, V2 Additional concept: Operational
Pierre-Yves Boyer Activities
Additional views: stakeholder
map, service chain, component
specification
11/12/2015 Gauthier Fanmuy V3 New MMS display
04/03/2016 Gauthier Fanmuy, Arnaud Durantin, V4 MMS activities

Frédéric Chauvin Precision on use case services
2
Presentation
 19 steps Methodology to apply a System Engineering [1] approach

 Can be a used by everyone, whatever the domain is
 Example to illustrate each step: conception of an elevator, safer and most
commonly used mean of transport, in the world
3
Context: Collaboration between disciplines & sub-
systems Operational Needs
Life duration Performances Consumption
Drivability Cost Comfort

Architecture :
Disciplines inter-disciplines trade-offs:
Motor Science X X
Electric / X X X
Electronics Science X X
X X
Acoustics Science
Interdependence Needs to
Thermal Science
between suppliers
Services/Disciplines/ Sub-Systems
Sub-Systems Thermal engine Battery Electrical engine
4
Need for a Systems Engineering Methodology
Define activities to implement
What to do? Processes and expected results
supported by support
Defines technics & methodology to

How to do? Methods implement the activities
supported by support
Improve the efficiency of tasks

With what? Tools implementation, use of methods
5
Presentation From silos disciplines Engineering
Stakeholders [2] Needs to integrated Systems Engineering
 Silos Engineering
System
System
System
System
D
B
A
 Organized by disciplines
Sub-System
Sub-System
Sub-System
Sub-System
 Lack of mastering interactions
Navigation
Electrical
Fluidics
between sub-systems [3]
Power
 Lack of mission analysis

 Multiple design iteration loops
Equipments &
Parts
6
Presentation From silos disciplines Engineering
to integrated Systems Engineering
 Systems Engineering
 System as black box [4] with
multidisciplinary services
 System as white box [5] with technical
functions & components
 Disciplines contribute to System artifacts
 Mastering of internal & external interfaces
and flows
Equipments
& Parts
7
8
Presentation
9
Presentation
Design
Operational
CAR Example Mission: Commute People from one
Why
destination to other Safely
Service: Ensure Secured Access,

Ensure Passengers Safety, etc
What
Technical Functions: Receive Signal,

Actuate Unlock, Push Brake Caliper
Components: Sensor, BCM ECU,

How
Software, Actuator, Door Locks,
Brakes, etc
10
Modeling Methodology for Systems ©: Goals
Goal: Understand operational context to define missions & stakeholders’ requirements and identify
candidate systems that realize operational activities to fulfill the missions
Scope: System of Systems
Goal: Define the engagement of the system to provide by defining system services and
requirements that satisfy operational activities and stakeholders’ requirements
Scope: System in black box
Goal: Define the functional solution by defining the functional architecture and functional design
requirements that satisfy the system services and system requirements
Scope: System in white box
Goal: Define the logical solution by defining the components architecture with allocated technical
functions & flows and non-functional design requirements that satisfy the service performances and
system requirements
Scope: System in white box
11
Modeling Methodology for Systems ©: Viewpoints
Actors
Stakeholders map
Stakeholders
Lifecycle phases Missions & Use Cases Missions Scenarios Environment
Requirements
Op. Activities &
Allocation
Service Chain
Service Use cases Physical Syst. Requirements
Modes Service Scenarios
System Context System External interfaces
Services States System Scenarios
Services Architecture Installation (physical & flows)
System Behavior
Functional chain
Syst. Design Req.
Technical Functional Technical Functions
Internal Interfaces
Functions States Architecture Scenarios
(flows)
Functional Behavior
Allocated Functional Syst. Design Req.
Physical
Components Architecture Components Internal Interfaces
Geometry &
Modes Comp. Architecture Scenarios & behavior (physical & flow
Materials
Comp. Specification allocations)
12
Operational definition example
Life situations Operational context System Services Requirements
Lifecycle phases
Stakeholders Use Cases Scenarios Experience
13
Operational definition example
States Static Dynamic Physical/Topology Requirements
Operational
System Requirement
14
Design definition example
States Static Dynamic Physical/Topology Requirements
Functional
Decomposed Requirement
Component
15
16
Modeling Methodology for Systems ©
PHYSICAL /
STATES STATIC DYNAMIC REQUIREMENTS
TOPOLOGY
Initial
Stakeholders
Requirements
MISSION
Define Define
Identify Define
Operational Operational
stakeholders Missions
Identify Scenarios Environment Agreed
Elicit /Refine
lifecycle Stakeholders
stakeholders
phase & Requirements
Requirements
situations Define & Allocate
of life Concept of
Operational Activities
Operations
Define
Service use
cases
Define
System
Context
Define
External
Interfaces
(flows &
interfaces)
Define System
installation
Define System
Requirements &
System
Requirements
traced to
MMS
Activities
traceability to Stakeholders
Make stakeholders
SERVICE
Requirements
Safety requirements
Define Services Reuse / Define / Analysis
States & System Refine System
modes Services
Define service scenarios Allocate System
(per service or set of Requirements to
services) Components
Define Define Define Define functional

Reuse /Define / Refine
Functional Internal functional scenarios (cross
Technical Functions
States flows chains functional chains)
FUNCTIONAL
Make
Safety Define System Design
Analysis Requirements related to
techical functions, flows &
Functional traceability to sytem
Architecture requirements
Make safety
Legacy Define System
analysis System Design
Components spatial zones
Allocate Requirements
Allocated traced to System
Technical
Functional Place Requirements
Functions to
Architecture Component in
Reuse / Define / Components
Refine System System spatial
Components & zone
COMPONENT
interfaces Define System Design

Define/
consolidate flows Define /Refine Requirements related
mapping to Allocated Functional to Components &
Components Component Scenarios interfaces & traceability
Architecture Interfaces to sytem requirements
Produce Component
Stakeholders Requirements
Define
Requirements Document
Components
for Component
Configuration
17
18
System Architecture big picture
MMS : a systematic & collaborative methodology
System
System Decomposition
Model refinement
Sub-
systems
Equipment
Black box model While box model
Allocate / Decompose / Implement links
20
21
System to Sub-System transition
Sub-System Architecture big picture
Needs
System Design Technical Functions
Requirements & interfaces
Sub System 2 “Specification”

Sub-System
Operational
Sub-System
Requirements
& Interfaces
Services
Contract
Implemented by
 Compliance
L
Sub System 2 “Solution”
Design Technical Functions

Sub-System Requirements
Design & Interfaces
Implemented by
Solution
Components
23
Overall System data
System Aircraft01
organization example
Missions Needs
Missions
Stakeholders Requirements
Capabilities
Logical (Systems/Actors/Organizations)
System Design (White Box)

System Definition (Black Box)
Functional Design: Technical Functions
Functional Definition : Services
Non Functional Design
Non Functional Definition
System Definition Viewpoints
System Definition Viewpoints
System Context System Decomposition
System Requirements System Design Requirements
Services
Allocated Technical Functions
Logical (System of interest / Actors)
Logical (Sub-System/Equipment)
24
Presentation
 Different views to represent a system
 Each view represents the system from one point of view

 Views are independent
 Reduce complexity
25
Actors
Stakeholders map
Stakeholders
Requirements
Op. Activities &
Allocation
Service Chain
System Behavior
Functional chain
Syst. Design Req.
Internal Interfaces
(flows)
Functional Behavior
Physical
Geometry &
Materials
26
Operational - Presentation
WHY the need for a system?
 Study type: Black Box

 Description: Understand problem to solve and the system
role in this context
 Main objective: Define missions and operational activities.
Understand usage during the complete System lifecycle
 Secondary objective: Define System answer - Services &
interactions,
 Deliverable: Missions, Stakeholders requirements and
operational scenarii; System services and system
requirements
27
Actors
Stakeholders map
Stakeholders
Requirements
Op. Activities &
Allocation
Service Chain
System Behavior
Functional chain
Syst. Design Req.
Internal Interfaces
(flows)
Functional Behavior
Physical
Geometry &
Materials
28
Missions - Static
 Missions [6] :
 What is the intended goal against problem
to solve or innovation to bring
 Can involve one or several systems
 Formalized as Mission Requirements or
goals in Use Cases representation
29
Actors
Stakeholders map
Stakeholders
Requirements
Op. Activities &
Allocation
Service Chain
System Behavior
Functional chain
Syst. Design Req.
Internal Interfaces
(flows)
Functional Behavior
Physical
Geometry &
Materials
30
Missions - Static
Identify stakeholders that are source of needs and constraints
 Relevant stakeholders (Positive and

Negative [7] ) for studied lifecycle phases
 Stakeholders can be either human
beings or systems
31
Missions – Static Users
Building
Packages
Building
Stakeholders’ map representation example

Unauthorized
person
Maintenance Maintenance
Operator Operator
Help Center
Security Security
Housekeeping Housekeeping
SUD
Elevator stakholders
32
Actors
Stakeholders map
Stakeholders
Requirements
Op. Activities &
Allocation
Service Chain
System Behavior
Functional chain
Syst. Design Req.
Internal Interfaces
(flows)
Functional Behavior
Physical
Geometry &
Materials
33
Mission - Static
Define Operational Activities that realize missions
 Formalizes the business processes through Operational Activities
34
Mission - Static
Allocate Operational Activities to stakeholders
 Allocation to systems and actors

 Allocated Operational Activities to a System are inputs to define Services of a
system
SUD: System Under Development
35
Stakeholders
Lifecycle phases Missions Scenarios Environment
Requirements
Service Chain
System Behavior
Functional chain
Syst. Design Req.
Internal Interfaces
(flows)
Functional Behavior
Physical
Geometry &
Materials
36
Missions - States
 Lifecycle:
 Define phases where system is

implicated, for each step of its life
 Helps to identify stakeholders that
express needs
 Each stakeholder is related to at least
one lifecycle phase
37
Stakeholders
Missions Scenarios Environment
Requirements
Service Chain
System Behavior
Functional chain
Syst. Design Req.
Internal Interfaces
(flows)
Functional Behavior
Physical
Geometry &
Materials
38
Missions - Dynamic
 Contextualization of the mission, in a business process with operational activities [21]
 Operational activities are tasks ensured by stakeholders in a functional description
Check authorization
Enter the building
Operational
Check
authorization Activities
Enter the building
Go to desired floor
Go to desired floor
Walk to desired room
Walk to
desired room
Ride up two persons on several floors

[8]
High level Sequence diagram
39
Missions - Dynamic
 Contextualization of the mission, in a business process with operational activities
[8]
 We can go further, in the services study
40
Stakeholders
Environment
Requirements
Service Chain
System Behavior
Functional chain
Syst. Design Req.
Internal Interfaces
(flows)
Functional Behavior
Physical
Geometry &
Materials
41
Services - States
 Modes [9] :
 System states giving a level of

availability of its services
 Modes are applicable to all system
services
42
43
 A stable
 State [22] :
Services - States
state of a service for a given system mode

Stakeholders
Environment
Requirements
Service Chain
Service Scenarios
System Scenarios
System Behavior
Functional chain
Syst. Design Req.
Internal Interfaces
(flows)
Functional Behavior
Physical
Geometry &
Materials
44
Services - Static
Define system context and perimeter of the system
 Identify relevant
stakeholders and effective
interactions
 Identify interfaces with the
system
SUD = System Under Development
45
Services - Static
 Services [10] : Activities, performances provided by the system to
stakeholders, in response to the missions (Black Box view)

 Identification: from Operational Activities (static or dynamic viewpoints),
events connecting SUD [11] to stakeholders
Go to the right floor Ride up/down
to desired floor
Go to desired floor Services can be
architectured if
Services
Allow
Events
Enter the elevator Allow packages

passengers
entrance/exit
not independent
Exit the elevator entrance/exit
Indicate floor Indicate cabin

state
Indicate state
46
Services - Static
 Services use case : a particular usage of the service by the stakeholders
System
Ride up/down
to desired floor Evacuate floor
Building
Services
Allow
Allow packages
passengers Transport
entrance/exit packages
entrance/exit Packages
Users
Call for
Indicate cabin emergency
state
Use case Service level
47
Stakeholders
Environment
Requirements
Service Chain
Physical Syst. Requirements
Service Scenarios
System External interfaces
System Scenarios
Installation (physical & flows)
System Behavior
Functional chain
Syst. Design Req.
Internal Interfaces
(flows)
Functional Behavior
Physical
Geometry &
Materials
48
Services - Static
 Each Operational Activity can be ensured by several system services
 For a given operational activity, these services are represented in a Service

Chain
49
Services - Dynamic
 From missions dynamic, define services provided by the SUD
 System centered view: System scenarios

SUD
Check authorization
Enter the building
Check authorization
Enter the building
Call
Call
Enter
Enter
Move to floor
Exit the SUD

Move to floor
Exit the SUD
Ride up two persons on several floors

Detailed level Sequence diagram
50
Services - Dynamic
 From missions dynamic, define services provided by the SUD
 System centered view
Click here to go
back to missions
51
Services - Dynamic
 Alternative representation – Service scenarios: sequences of services
Stakeholders or Services
Flows
52
Stakeholders
Environment
Requirements

Functional chain
Syst. Design Req.
Internal Interfaces
(flows)
Functional Behavior
Physical
Geometry &
Materials
53
Missions - Physical/Topology
 Sizing elements
 Define a reference environment [12]

 Stakeholders constraints related to system physical aspect
 Max height, max space, temperature conditions,

materials, sound isolation, structure vibrations
54
Stakeholders
Requirements

Functional chain
Syst. Design Req.
Internal Interfaces
(flows)
Functional Behavior
Physical
Geometry &
Materials
55
Services - Physical/Topology
Physical
 To identify the best possible concept of solution [13] for the services.
 Sizing elements, installation in context of mission considering each discipline

(mechanical, electronics, electrical, fluidics…).
 Mechanical example
 Cabin size Mechanism Machinery position Opening type Mirror
1m x 1m Top of the Hostway In front of the doors

Double Sliding Doors
56
Services - Physical/Topology
System installation
 To identify the best possible concept of solution [13] for the services.
 Sizing elements, installation in context of mission considering each discipline

(mechanical, electronics, electrical, fluidics…).
 Electronic example
 Controllers? One, on the elevator
 Lights? 3 light bulbs, no safety lights
 Lights power supply? Independent
57
Stakeholders
Requirements
Syst. Requirements
External interfaces
(physical & flows)
Functional chain
Syst. Design Req.
Internal Interfaces
(flows)
Functional Behavior
Physical
Geometry &
Materials
58
Requirements [14]
 Express in natural language the result of the system analysis.
 To each layer of a system (missions / services / functional and components)

corresponds different requirement nature: stakeholder / system / system design.
59
Missions - Requirements
 Express stakeholders requirements in terms of usages, missions and regulation Stakeholders
requirements
 « The user shall… »
 Express system requirements in terms of services, external flows/physical interfaces System

 « The system shall… » requirements
 Express functional design requirements for internal technical functions and flows System Design
 « The technical function shall… » requirements
 Express non-functional requirements for internal components and physical interfaces System Design
 « The component shall… » requirements
60
Syst. Requirements
External interfaces
(physical & flows)
Functional chain
Syst. Design Req.
Internal Interfaces
(flows)
Functional Behavior
Physical
Geometry &
Materials
61
Services - Requirements
requirements

Answers
62
Functional chain
Syst. Design Req.
Internal Interfaces
(flows)
Functional Behavior
Physical
Geometry &
Materials
63
Functional - Presentation
WHAT the system does to achieve services?
 Study type: White Box

 Description: Inner functions (technical functions [15]) working together to fulfill the
expected services
 Main objective: Design functional architecture [16]
 Secondary objective: Detail of the technical functions & flow interfaces, their states
and behaviors
 Deliverable: System design requirements, functional architecture
64
65
Functional architecture
Functional chain
Syst. Design Req.
Internal Interfaces
(flows)
Functional Behavior
Physical
Geometry &
Materials
66
Functional - Static
 Main Inputs: Services, Stakeholders, Dynamic functional
 Activities:
 Define technical functions related to services
 Allocate elementary technical functions to component architecture
 Output: Functional architecture with technical functions and flows
67
Functional chain [17] Door presence measure
for Allow passengers entrance Display floor Display state

Unlock Measure door
presence (Cabin)
Measure
Send presence
measure (Cabin)
Unlock cmd doors
(Cabin) (Cabin) (Cabin)
Floor State Déverrouillage ok
Receive door
Receive floor Receive state Command Lock doors Light power on Light power off
Turn light on Turn light off command Lock cmt
data (Cabin) data (Cabin) Motor Cmd Doors motors (Cabin) (Cabin) (cabin)
(Weight (Weight Alarm (Cabin)
(Cabin)
Alarm Light) Light)
Power
Power light OFF Data current floor Ack Power
Door cmd
Power light ON
Weight measure
Identify light need
Measure Weight Send weight Analyze weight (Controller)
(Sensor Measure measure (Sensor for alert Data current state
Send doors Send mission Command button
Network) Network) (Controller)
command Mission command
Ack (Mission Power Button lights on (Mission
(Controller) Command) Command)
Get floor data
(Controller)
Floor measure Send floor Send state Get Command
Floor Call command
data data (Controller)
Get weight (Controller) (Controller)
Weight measure data
(Controller) Floor User Command Users
State
Weight Door command
Process
Analyzed Send call
command Analyze Command button
User command (Call
Door presence (Controller) command Power Button lights on bouton
Get door (Controller) Command) (Call Command)
Measure floor Send floor presence data State
Measure
(Sensor Network) (Sensor Network) (Controller)
Commande
Traction
Send motor and
system state
breaks command
(Controller)
(Controller)
Inform
Traction system command Number help
building for a
Center
problem
(Emergency
(Emergency
Button)
button)
Traction system state
Receive Motor
and Breaks Transfer torque
Motor Cmd Motor state Numerotation Help Center
command (Treuil)
(Treuil)
Torque
Establish
Ensure
Breaks command communicatio
Telephone Communication
Transfer Give motor and Communication
n Help Center
to cabin breaks state (Treuil) (Telephone)
(Telephone)
Transform kinetic
energy into heat
Breaks
(Treuil)
69 Breaks state
Door presence measure
Functional chain for Indicate Unlock Measure door

Measure
Send presence
cabin state
Display floor Display state Unlock cmd doors presence (Cabin) measure (Cabin)
Receive door
(Cabin)
Alarm Light) Light)
Ack
Power
Door cmd
Power light ON
Weight measure
Identify light need
command Mission command (Mission Power Button lights on (Mission
Get floor data
(Controller)
Floor Call command
Weight measure data
State
Weight Door command
Process
Analyzed Send call
User command (Call
Measure
Commande
Traction
Send motor and
system state
breaks command
(Controller)
(Controller)
Inform
Traction system command Number help
building for a
Center
problem
(Emergency
(Emergency
Button)
button)
Traction system state
Receive Motor
and Breaks Transfer torque
command (Treuil)
(Treuil)
Torque
Establish
Ensure
Breaks command communicatio
Transfer Give motor and Communicatio
n Help Center
to cabin breaks state (Treuil) n (Telephone)
(Telephone)
Transform kinetic
energy into heat
Breaks
(Treuil)
70 Breaks state
Door presence measure
Unlock Measure door Send presence

Measure
Display floor Display state Unlock cmd doors presence (Cabin) measure (Cabin)
Receive door
(Cabin)
Alarm Light) Light)
Power
Door cmd
Power light ON
Weight measure
Identify light need
command Mission command
Ack (Mission Power Button lights on (Mission
Get floor data
(Controller)
Floor Call command
Weight measure data
State
Weight Door command
Process
Analyzed Send call
User command (Call
Measure
Commande
Traction
Send motor and
system state
breaks command
(Controller)
(Controller)
Inform
Allow passengers Traction system command Number help

building for a
Center
problem
(Emergency
(Emergency
entrance Traction system state
Button)
button)
Receive Motor
and Breaks
Indicate cabin state
Transfer torque
command (Treuil)
(Treuil)
Torque
Establish
Ensure
Common technical Breaks command
Transfer
to cabin
Give motor and
breaks state (Treuil)
Communicatio
n (Telephone)
communicatio
n Help Center
(Telephone)
functions Transform kinetic
energy into heat
Breaks
(Treuil)
71 Breaks state
Functional chain
Syst. Design Req.
Technical Technical Functions
Internal Interfaces
Functions States Scenarios
(flows)
Functional Behavior
Physical
Geometry &
Materials
72
Functional - Dynamic
 Main Input: Services sequences (from dynamic analysis at service level)
 Output:
 Functional behavior for each service: sequence of technical functions
 Complete the list of technical functions required if necessary
73
74
Functional - Dynamic
 Establish the sequences of technical functions for a service
Syst. Design Req.

Technical
Internal Interfaces
Functions States
(flows)

Physical
Geometry &
Materials
75
76
 States of
Functional - States
technical functions
Syst. Design Req.

Internal Interfaces
(flows)

Physical
Geometry &
Materials
77
Functional - Requirements
requirements

Answers
Answers
78

Physical
Geometry &
Materials
79
Component - Presentation
 HOW is the system composed ?
 Study type: White Box
 Description: Inner components working together to support technical functions
 Main objective: Define components and interfaces : components architecture [18]
 Secondary objective: Define components states, scenarios, behaviors and

technical functions allocation
 Deliverables: System design requirements, Component architecture with
allocated technical functions
80
81
Component architecture

Physical
Geometry &
Materials
82
Component - Static
 Define components
 Define the physical interfaces [19] between components

 Allocate elementary technical functions to components
83
84
Component - Static
 Define components
 Define the physical interfaces [19] between components

 Allocate elementary technical functions to components
 Map technical functions flows to components physical interfaces
Flow Physical interface
Traction system command Electric cable
Floor measure Electric cable
Mission command Bus
Call command Bus
85
Component - Static
 Establish the specification (i.e. Needs) for each component the Components
architecture:
 System Design Requirements
 Allocated technical functions & flows
 Logical interfaces
86
Syst. Design Req.

Physical
Components Components Internal Interfaces
Geometry &
Modes Scenarios & behavior (physical & flow
Materials
allocations)
87
Component - Dynamic
 Main Inputs:
 Services use cases,

 Allocated functional architecture,
 Technical functions sequence diagrams
 Outputs:
 Components [20] scenario as sequence diagram. Exchanged messages correspond to
technical functions,
 Multi-physics components behavior.
 Note: scenario in example shows « User calls, then asks for a destination
floor »
88
89
Syst. Design Req.

Physical
Components Internal Interfaces
Geometry &
Modes (physical & flow
Materials
allocations)
90
91
 Modes of components
Component - States
Syst. Design Req.

Physical
Internal Interfaces
Geometry &
(physical & flow
Materials
allocations)
92
Component - Physical/Topology
 Installation constraints
 System to components: available space and interfaces,
 Components to system: required space and interfaces.
 Physical characteristics
 Materials,
 Weight,
 Performances,
 …
 Example:
 Choose to tract from above or below
 Choose motor type
 Chose cabin materials: iron, aluminum…
93
Syst. Design Req.

Internal Interfaces
(physical & flow
allocations)
94
Component - Requirements
requirements

Answers
Answers
Answers
95
96
Glossary
 [1] Systems Engineering:
 IEEE Std 1220-2005: The interdisciplinary tasks, which are required throughout a system's life cycle to
transform customer needs, requirements, and constraints into a system solution.

 INOCSE: Systems Engineering is an engineering discipline whose responsibility is creating and executing
an interdisciplinary process to ensure that the customer and stakeholder's needs are satisfied in a high
quality, trustworthy, cost efficient and schedule compliant manner throughout a system's entire life cycle.
 [2] Stakeholder, ISO 15288-2015: individual or organization having a right, share, claim, or
interest in a system or in its possession of characteristics that meet their needs and
expectations.
 Note: Stakeholder can be extended with Actor: in UML, someone or something outside the system that
interacts with the system (ISO/IEC/IEEE 24765-2010 Systems and software engineering-Vocabulary).
 Note: [7] Positive (resp. negative) stakeholder: stakeholder that will have a positive (resp. negative)
effects on the system during the different lifecycle phases.
 [3] Subsystem, ISO/IEC/IEEE 24765-2010: a secondary or subordinate system within a

larger system.
97
Glossary (2)
 [4] Black-box, ISO/IEC/IEEE 24765-2010: a system or component whose inputs, outputs,
and general function are known but whose contents or implementation are unknown or
irrelevant.
 [5] White-Box (glass box definition), ISO/IEC/IEEE 24765-2010: a system or component

whose internal contents or implementation are known.
 [6] Mission: Objective toward which work is to be directed, […] a purpose to be achieved, a result
to be obtained, a product to be produced, or a service to be performed (PMBOK(R) Guide -- Fifth
Edition).
 [8] Sequence diagram:
 A Unified Modeling Language (UML) diagram that depicts time-sequential ordering of interactions, as in a
use case scenario of interactions between an actor and some system elements. (Software Extension to the
PMBOK(R) Guide Fifth Edition) .
 A sequence diagram represents the items involved in a scenario or interaction, and the messages that are
exchanged in a chronological order (SysML definition).
 [9] Mode, IEEE 1362-1998 (R2007): a set of related features or functional capabilities of a product.
98
Glossary (3)
 [10] Service, ISO/IEC/IEEE 24765c-2014: means of delivering value for the customer by
facilitating results the customer wants to achieve.
 [11] SUD: System Under Development, the system of interest to develop, modify, acquire or
reuse.
 Note: system whose life cycle is under consideration (ISO/IEC 15288-2008)
 [12] Environment, IEEE 1175.1-2002:R2007: anything affecting a subject system or affected
by a subject system through interactions with it, or anything sharing an interpretation of
interactions with a subject system.
 [13] Concept of solution: Chosen concept(s) of the available alternatives that will guide the
system white box analysis. It is not a detailed solution but a high level principles description.
99
Glossary (4)
 [14] Requirement:
IEEE 29148-2011: statement that translates or expresses a need and its associated constraints and

conditions.
 PMBOK(R) Guide - Fifth Edition: a condition or capability that must be present in a product, service,
or result to satisfy a contract or other formally imposed specification
 [15] Functional architecture, IEEE 1220-2005 : an arrangement of functions and their
sub-functions and interfaces (internal and external) that defines the execution
sequencing, conditions for control or data flow, and the performance requirements to
satisfy the requirements baseline.
 [16] Technical function (allocated), IEEE 24765-2010: defined objective or
characteristic action of a system or component (white box context).
 [17] Functional chain: set of technical functions working together to provide a given
service.
100
Glossary (5)
 [18] Component architecture (design architecture definition), IEEE 1220-2005: an
arrangement of design elements that provides the design solution for a product or life cycle
process intended to satisfy the functional architecture and the requirements baseline.
 [19] Interface, IEEE 24765-2010: hardware or software component that connects two or more
other components for the purpose of passing information from one to the other.
 [20] Component (System element definition): member of a set of elements that constitutes a
system (ISO/IEC 15288-2015).
 Note: A component may be hardware or software and may be subdivided into other components
 [21] Operational Activity, ISO/IEC 15288:2008: set of cohesive tasks of a process

 [22] State, IEEE 1220-2005: a condition that characterizes the behavior of a
function/sub-function or element at a point in time
101
Bibliography
 [1] Eléments de systémique – Architecture des systèmes, Daniel Krob
 [2] Integrated Modeling, Dr. Aurelijus Morkevičius
 [3] A pragmatic approach to SE practices at Schindler Elevators, Ph.

Henneau
 [4] Model Based Systems Engineering Management Plan, Audun Resser
 [5] Systems Thinking. Applied. A Primer. , Robert Edson
 [6] AFIS - System Engineering Methodology, Gauthier Fanmuy (Dassault

Systèmes), François Colet (Renault) and Jean-René Ruault (DGA)
 [7] Systems Engineering Introduction, Fabrice Pinot (Dassault Systèmes)
102
Bibliography (2)
 [8] V-Model Views, INCOSE
 [9] Introduction à l’ingénierie des systèmes complexes, Arnaud Durantin

(Dassault Systèmes)
 [10] Advanced System Engineering training – ENSTA : OMS Case Study -
Multi-Sensor System for fire prevention, Gauthier Fanmuy (Dassault Systèmes)
 [11] Architecture des systèmes complexes, Daniel Krob
 [12] Eléments d’architecture des systèmes complexes, Daniel Krob
 [13] Systems Praxis Framework, International Council on Systems Engineering
(INCOSE) and International Society for the Systems Sciences (ISSS).
103
104

Modeling Methodology For Systems v4.0

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Modeling Methodology For Systems v4.0

Uploaded by

Copyright:

Available Formats

Modeling Methodology for Systems ©

3DS.COM © Dassault Systèmes | Confidential Information | 3/7/2016 | ref.: 3DS_Document_2014

Example of the elevator

By Gauthier Fanmuy, Arnaud Durantin,

08/07/2015 Gauthier Fanmuy, Arnaud Durantin, V0 First full version

04/03/2016 Gauthier Fanmuy, Arnaud Durantin, V4 MMS activities

 19 steps Methodology to apply a System Engineering [1] approach

Drivability Cost Comfort

Defines technics & methodology to

Improve the efficiency of tasks

 Lack of mission analysis

Service: Ensure Secured Access,

Technical Functions: Receive Signal,

Components: Sensor, BCM ECU,

Stakeholders Use Cases Scenarios Experience

Define Define Define Define functional

interfaces Define System Design

Black box model While box model

Sub System 2 “Specification”

Sub System 2 “Solution”

Design Technical Functions

System Design (White Box)

 Each view represents the system from one point of view

 Study type: Black Box

 Relevant stakeholders (Positive and

Stakeholders’ map representation example

 Formalizes the business processes through Operational Activities

 Allocation to systems and actors

SUD: System Under Development

 Define phases where system is

Ride up two persons on several floors

 System states giving a level of

state of a service for a given system mode

SUD = System Under Development

stakeholders, in response to the missions (Black Box view)

Enter the elevator Allow packages

Indicate floor Indicate cabin

Use case Service level

 For a given operational activity, these services are represented in a Service

 System centered view: System scenarios

Exit the SUD

Exit the SUD

Walk to desired room

Ride up two persons on several floors

 System centered view

Physical Syst. Requirements

 Define a reference environment [12]

 Max height, max space, temperature conditions,

Physical Syst. Requirements

 Sizing elements, installation in context of mission considering each discipline

1m x 1m Top of the Hostway In front of the doors

 Sizing elements, installation in context of mission considering each discipline

 Express in natural language the result of the system analysis.

 To each layer of a system (missions / services / functional and components)

 « The user shall… »

 Express system requirements in terms of services, external flows/physical interfaces System

 « The user shall… »

 Study type: White Box

 Output: Functional architecture with technical functions and flows

for Allow passengers entrance Display floor Display state

Functional chain for Indicate Unlock Measure door

Unlock Measure door Send presence

Allow passengers Traction system command Number help