Signals and Systems Powerpoint

7/29/2019 Signals and Systems Powerpoint

1/54

SYS 5390 Lecture #2, Slide 1

Model BasedCollaborative Systems Engineering

Stphane Bucaille, PhDElectrical and Computer Engineering Department


2/54


GeneralInformation

Product/Teamarchitectureprinciple

SysML

Overview

Example


3/54



4/54


General Information

JPL project

Objective: Design a model for the electrical systems of a

generic spacecraft

Software: Magic Draw

JPL visit

Career fair

Additional recommended book

The Engineering Design of Systems: Models and Methods

(Wiley Series in Systems Engineering and Management),Dennis M. Buede, 2nd edition, 2009


5/54



6/54


Model

Toothbrush

head

Toothbrush

base

Toothbrush

body

Viewpoints

Perceptions

System

Toothbrush

head

Toothbrush

body

Toothbrush

base

Interface(external, i.e. with environment)

Interface

(internal)

System: a collection of (hardware, software & humanware) systems organized in order that

theirintegration allows to accomplish within a specificenvironment the missions it was

designed for

Systems overview


7/54SYS 5390 Lecture #2, Slide 7

Electronic

toothbrush

Users

Maintenance

Power

Internet

External

system

Externalsystems

External system

Internal

integration

External

integration

Basis

Internal sub-systems

Embedded

system

Corpse Head

Sales

Hardware systems

Software systems

Human systems

Introduction to MBSE



ViewpointAnswers to

the question

Some associated

keywords

Examples

(e-toothbrush)

Operational Why ?

Operational

context, mission,

use case

Clean & healthy

teeth, gain of time,

fashion bathroom

Functional What ?

Service, function,

task, operation &

mode of operation

Brushing, speed

regulating,

brushing strength

programming

Constructional How ?

Component,

technical

architecture &

configuration

Head, base,

corpse, speed

regulator

Introduction to MBSE



ConstructionalTo be

What the system shall be?

OperationalTo expect

What could be the problem?

FunctionalTo do

What the system shall do?

DynamicsStaticsControl

Lifecycle

(behavior)

Operational

contexts

(mission)

Operational

scenarios

(scenario)

Operation

mode

(behavior)

Function

(operation)

Functional

dynamic

(scenario)

Configuration

(behavior)

Ressource

(organization)

Constructional

dynamic

(scenario)



States Static structure Dynamic behavior

Operationalvision

Functionalvision

Constructionalvision

Electronic

toothbrush



The key system problem in practice: how to make the systems

stakeholders converge on a same vision of the same system?

Stakeholder 1

Stakeholder 2Stakeholder 3 Stakeholder 4

Human

system

Key human

problem:

CONVERGENCE

System 1System 3

System 2 System 4

Technical

system

Key technical

problem:

INTEGRATION 1

(to be prepared

as early as

possible)

1 I.e. defining the interfaces

Towards the Product / Team

Architecture Principle



Chief

Architect

External

support

ProjectManager

Security

Verification

Engineer

Technical

Managers

Customer

Validation

Engineer

A system architect must interact

and take into account multiplecultures and stakeholders

System

Architect

User

Platform

director

Subsystems

directors

Industrial

Managers

Modules

managers





Chief

Architect

Security / Quality

Engineer

Project

Manager

Industrial

Managers

Customer

UserNeeds

QualityDesign

Technical

Managers

Each stakeholderhas his own territoty and his skills.

He also interacts with the other stakeholders.

Planning

SystemD

esign

System

Architect

Validation

Validation

Engineer

DesignExpertise

Security/Quality

Expertise

Industrialization

Platform / Sub-

systems / ModulesDirectors

Management

Key difficulty: Identify and

manage organization interfaces





Project

ManagerPlanning

Designer

(fashion)Design

MarketerNeeds

Engineer

TechnicalDesign

OrthodontistHealth

Beta-tester

REX

Industrial

EngineerIndustrialisation

Electric toothbrush stakeholders





15

System

?

?

?? ?

?

? ?

?

?

?

What are the stakeholders of yoursystem of interest? Once you abstracted them,

identify theirrole and skills, and the way they interact.





NEED

REQUIREMENT

TECHNOLOGICAL OPPORTUNITY

DEMONSTRATION

Whole consistency: animate & organize a

common system properties referential

A stakeholder shall

The system shall

A shall prove

that the system satisfies

A technology can

Needs referential

Technologicalopportunities

referential

Requirements referential

Demonstrationsreferential





Caption

Is responsible of

Non

technological

environment

Sub-

systems &

modules

Product system

Project system

Use

cases

De-

mons-

tra-

tions

Needs Product requirements

Functional analysisInputs Outputs

REFERENTS

PM

Technologies

System

referentialsan

imation

(arc

hitecture,methods,tools,etc.)

QUALITY

Needs referential

T2M T3MT1M

Technologicalopportunities

referential

Requirements referential

Demonstrations

SS1 SS2 SS3 SS4

SS5 SS6

Involvement

Technological

needs Technological solutions

& proposals

Laboratory

(demonstrator)

LABO

Demosreferential

CT

Prod. M

TM

LM

QM

The Product / Team Architecture

Principle



The RACI tool(s) R Responsible:

Those who do the work to achieve the task.There is typically one role with a participationtype of Responsible, although others can bedelegated to assist in the work required.

A Accountable The one ultimately accountable for the correct

and thorough completion of the deliverable or

task, and the one to whom Responsible isaccountable. In other words, an Accountablemust sign off (Approve) on work thatResponsible provides. There must be only one

Accountable specified for each task ordeliverable.

C Consulted Those whose opinions are sought; and with

whom there is two-way communication.

I Informed Those who are kept up-to-date on progress,often only on completion of the task ordeliverable; and with whom there is just one-way communication.

Variations RASCI, RACI-VS, RACIO, DACI, RSI, PARIS,

PACE, OARP



Paradigm Analytical Architectural

Key principle Exhaustive understanding Global understanding

Perimeter Homogeneous systemHeterogeneous integrated

system

Building blocks Disciplinary knowledge Systems & interfaces

Mindset Uniqueness & certainty Diversity & relativity

Description mode Detailed representation Perceptions & viewpoints

Working mode Assembling Integration

Interaction mode Expertise & local Collaborative & global

Industrial specialist Engineer Systems architect

Paradigm opposition leads to acceptation and implementation difficulties!

Be didactic


21/54


SysML purpose and Key Features

SysML is a general-purpose graphical modeling languagethat supports the analysis, specification, design,verification and validation of complex systems Systems might include hardware, software, data, personnel,

procedures, facilities, organizations

Links established with UML and VHDL for components designs

SysML can represents the following aspects: Structural composition, interconnection and classification

Function-based, message-based, and state-based behavior

Constraints on the physical and performance properties

Allocations between behaviors, structures and constraints(= functions allocated to components)

Requirements and their relationship to other requirements,design elements and test cases


22/54


SysML Diagram overview

9 diagrams enable the complete engineeringprocess

Constraints apply to each diagram type Ex: an activity diagram

Can contain elements that represent actions, control flow andinput/output flow

But cannot contain elements for connectors and ports

SysMLDiagram

BehaviorDiagrams

ActivityDiagram

SequenceDiagram

StateMachineDiagram

Use CaseDiagram

RequirementDiagram

StructureDiagrams

BlockDefinitionDiagram

Internal BlockDiagram

ParametricDiagram

PackageDiagram

Same as UML

Modified from UML

Not in UML


23/54


SysML Diagram details

Activity diagram represents behavior in terms of the ordering ofactions based on the availability of inputs, outputs, controls,

and how the actions transform the inputs to outputs

Sequence diagram represents behavior in terms of a sequence ofmessages exchanged between parts

State machine diagram represents behavior of an entity in terms ofits transitions between states triggered by events

Use case diagram represents functionality in terms of how asystem or entity is used by external entities (actors) to accomplish aset of goals

BehaviorDiagrams

ActivityDiagram

SequenceDiagram

StateMachineDiagram

Use CaseDiagram


24/54



Requirement diagram represents text-based requirements and

their relationship with other requirements, design elements,

and test cases to support requirements traceability

Requirement Diagram


25/54



Block definition diagram represents structural elements called

blocks, and their composition and classification

Internal block diagram represents interconnection and interfaces

between the parts of a block

Parametric diagram represents constraints on property values,such as F=m*a, used to support engineering analysis

Package diagram represents the organization of a model in

terms of packages that contain model elements

StructureDiagrams

BlockDefinitionDiagram

InternalBlock

Diagram

ParametricDiagram

PackageDiagram


26/54


SysML and comparison with TTDSE(Traditional Top-Down Systems Engineering)


27/54


Using SysML in support of MBSE

SysML enables the capture of the modeling information as part

of an MBSE approach without imposing a specific method on

how it is performed.

The selected method determines

Which activities are performed

The ordering of the activities

And which modeling artifacts are created to represent the system

Examples:

Traditional structured analysis

Use case driven approach

Different methods might produce different combinations of

diagrams


28/54


Typical use

Capture and analyzeblack box system

requirements

Develop one or morecandidate systemarchitectures to

satisfy therequirements

Perform engineeringand trade-off analysisto evaluate and select

the preferredarchitecture

Specify componentsrequirements andtheir traceability to

system requirements

Verify that the systemdesign satisfies the

requirements byexecuting system-

level cases


29/54


Typical use

Capture and analyzeblack box system

requirements

Capture text-based requirements in a requirementmanagement tool

Import requirements into the SysML modeling tool

Identify top-level functionality in terms of use cases

Capture the traceability between the use cases and

requirements Model the use case scenarios as activity diagrams, sequence

diagrams, and/or state machine diagrams

Create the system context diagram

Identify test cases to support system verification


30/54


Typical use

Develop one or morecandidate system

architectures to satisfythe requirements

Decompose the system using theblock definition diagram

Define the interaction among the partsusing activity or sequence diagram

Define the interconnection among theparts using the internal block diagram


31/54


Typical use

Perform engineering andtrade-off analysis to

evaluate and select thepreferred architecture

Capture the constraints on system properties usingthe parametric diagram to support analysis of

performance,

reliability,

cost, or other critical properties

Perform the engineering analysis to determine thebudgeted values of the system properties (typicallydone with a separate tool)


32/54


Typical use

Verify that the systemdesign satisfies the

requirements by executingsystem-level cases

Capture the functional, interface, andperformance requirements for eachcomponent (block) in the architecture

Verify that the system design satisfiesthe requirements by executingsystem-level test cases


33/54



34/54


Problem summary

Marketing analysis shows needs to: increase automobile acceleration

fuel efficiency

MBSE selected aspects here to support initial trade-off analysis

Engine 4-cylinder engine

6-cylinder engine

vehicle controller and associated software to control air-mixture

maximize fuel efficiency and engine performance


35/54


SysML Diagram

Header Frame

Content

A t bil ifi ti t


36/54


Automobile specification capture:

Requirement Diagram

Depicts requirements usuallycaptured in a text specification

Shown in a containmenthierarchy

Relations types derive

satisfy verify

refine

trace

copy

with other requirements,

design elements

test cases

Top-level

requirement

Lower-level

requirement

Crosshair symbol:

Containment relationship

Each requirement includes:

Unique identification

Text Other properties

Verification status

Rationale

Risks


37/54


Define the Vehicle and its external environment:

Block Definition Diagram

Block: general modeling concept used to model entities (SYS, HW, SE, physical objects,

abstract entities The Block Definition Diagram captures the relation between blocks such as block hierarchy

Top-level

Block

Driver, Passenger

subclasses of

vehicle occupant

Diamond symbol:

Contains relationship

Sys of Interest:

Car

External blocks

External

entities: # from

0 to unlimited

Ex: Traffic light

Blocks also include:

Properties

Behaviors, in

terms of activities

allocated to the

block

Operations of the

block

Ports (Interfaces)

U C Di


38/54


Use Case Diagram

forOperate Vehic le

Use case diagram forOperate Vehicle depicts the major functionality for operating the vehicle

Use Case define how the system is used to achieve a user goal. The goals are accomplished by interactions between the actors and the subject. (Sequence Diagram)

Other Use Case Diagrams can represent how the system is used across its life cycle

Relate Use Cases to Requirements using refine relationship

Actor

(external)

Subject of the Use Case

(Used by the actors)

Represent ing Drive Vehic le Behavior


39/54


Represent ing Drive Vehicle Behavior

Sequence Diagram

Sequence diagram specifies the interaction

between the Driverand the Vehicle as indicated by the names at the top of the lifelines

Time proceeds vertically down the diagram

The interaction occurrences each reference a more

detailed interaction (ref). The reference interaction is

another sequence diagram

These three interactions Control Power, Brake and

Direction occur in parallel (par)

These three interactions Control Neutral, Forwardand

Reverse occur in alternative (alt)

Reverse Powerinteraction occurs as a condition of the

vehicle state is reverse. (State Machine Diagram)

St t V hi l


40/54


Start Vehic le

Referenced Sequence Diagram

Sequence diagram depicts an interaction that is referenced in the previous sequence diagram.

Sequence diagrams can include multiple message exchanges between multiple lifelines thatrepresent interacting entities.

Sequence diagrams provides considerable additional capability to express behavior that includes other message types,

Timing constraints

Additional control logic

the ability to decompose the behavior of a life line into the interaction of its parts

Driver sends a message to the

vehicle to start.

Message is synchronous

(filled arrowhead): operationcall that specify a request for

service)

Arguments of the operation call

represent the input data andreturn

The Vehicle responds with

the Vehicle on replymessage (dashed line).

The message is

asynchronous (open

arrowhead): the sender

does not wait for a reply

Once the reply has been

received, the driver and vehicle

can proceed to the next

interaction

C t l P


41/54


Contro l Power

Activity Diagram

Activity Diagram is a more efficient representation of continuous types of behaviors

such as Control Power, Control Brakes, orControl Direction Activity Diagram shows the actions required of the Driverand the Vehicle to Control Power

Contains semantics for precisely specifying terms of the flow of control, inputs and outputs

Action output:Accelerator Cmd,

continuous= Input to the Provide Power

action

Initial node: Execution start.

Transition to the Control

Accelerator Position is performedby the Driver

Activity Partitions (Swimlanes): Actions in the

partitions specify functional requirements that

the Driverand the Vehicle must perform

Action output: TorqueContinuous torque generated

by the wheels to the road to

produce the force thataccelerates the Vehicle

Drive Vehic le States


42/54


Drive Vehic le States

State Machine Diagram State Machine diagram shows the states of the

Vehicle and the events that can triggera transition

between the states. It can specify the life-cycle of blocks in terms of its

states and transitions

When the Vehicle is ready to be driven, it starts in the vehicle offstate

An ignition offevent triggers the transition back to the vehicle offstate

The text indicates the turn off vehicle behavior is executed prior to

entering the vehicle offstate

//

An ignition on event triggers the transition back to the vehicle on state

The text indicates the start vehicle behavior is executed prior to

entering the vehicle on state

After entry to the vehicle on state,

Vehicle immediately transitions to

the neutralstate.

A forward selectevent triggers a transition to the forwardstate if the

guard condition[speed>=0]is true.

In this state, the Vehicle performs the Provide Powerbehavior in the

previous activity diagram.

The neutral selectevent triggers a transition back to the neutralstate.

A reverse selectevent triggers a transition to the reverse state if the

guard condition [speed


43/54


Vehicle Con text

Internal Block Diagram

Internal Block Diagram describes Vehicle context.

It shows the interfaces between the Vehicle, the Driver, and the Physical Environment(i.e. Road,Atmosphere, External Entity), cf. Block Definition Diagram

It represents the internal structure of a higher level block (bddAutomobile Domain block).

Item Flow: represents the

item flowing between parts

May include mass, energy,

informationInputs and Outputs from the

activity diagram are allocated

to the item flows on the

connectors.

Ports (Flow port, Standard

port)specify interactions points with

other parts

Connectors (shown if of interest) show

how parts are connected.

Ex: rear/front wheels (Power/Direction)

V hi l hi h


44/54


Vehicle hierarchy

Block Definition Diagram

This diagram focuses on showing the decomposition of the Vehicle into its components

Indicates different usages of a

Wheelin the context of thePower train

Only one engine is part of a particularVehicle. They

represent a complete set of sub-classes and are

mutually exclusive or disjoint ({complete, disjoint}

constraint)

The Vehicle controller

software is allocated to theVehicle Processor.

The Vehicle Processoris the

execution platform for the

Vehicle Controllersoftware.

Components specification

(Interaction and interaction

analysis)

P id P


45/54


Provide Power

Activity Diagram

The activity diagram Control Powershowed that the Vehicle must Provide Powerin

response to the Driver Accelerator Cmdand generate Wheel-Torque at the road surface.

The Provide Power activity diagram shows how the Vehicle components generate this

torque.

The actions in the activity partitions that are allocated to the Vehicle components realize the

provide poweraction that the Vehicle perform, as shown in the activity diagram Control Power.

This approach is used to decompose the system behavior.

External inputs

External

outputs

Nonstreaming input: only available prior the start of the action execution

Nonstreaming output: produced only at the completion of the action execution

Power subsys tem


46/54


Power subsys tem

Internal Block Diagram

This diagram shows how the parts are interconnected to achieve the functionality previously described.

It is a structural view vs. the behavioral view expressed in the activity diagram.The diagram includes only

parts that collaborate withProvide Power

Frame is the Vehicle

Fuel stored

(store) Same approach for

provide breaking

provide steering

Left and right rear

are different usages

of the Wheelblock.

: is used todistinguish the part

(usage) from the

block (definition)

The expression to

the right is the

generic definition

The expression to

the left is the

particular usage

Other example : Fuel

Defining the Equations to Analyze


47/54



Vehicle Performance (1/2)

Critical requirements are for the design of this automobile To accelerate from 0 to 60 mph in less than 8 seconds

To achieve a fuel efficiency greater than 25 mpg

Two alternative solutions: 4 and 6-cylinder engines Alternatives shown in the Vehicle Hierarchybdd

Other impacts with different engines:

Vehicle weight Body shape

Electrical power

The Vehicle controller controls Fuel and air mixture

When the gear changes in the automatic transmission

to optimize engine and overall performance



48/54



Vehicle Performance (2/2)

Block Definition Diagram forAnalysis Contextdefines the equations for analyzing the vehicle

acceleration requirement.

The equations and their parameters are specified using constraint blocks.

Constraint block defines:Parameters (with units)

Generic equations (if

definition not deferred to

detailed analysis)

Diagram also

referencesAutomobile

Domain:

Identify both the

equations for the

analysis and the subjectof the analysis

Equations can

constraint the

properties of the

Vehicle, its components

and the physical

environment.

Vehicle Ac celerat ion analysis


49/54


Vehicle Ac celerat ionanalysis

Parametric Diagram

The Parametric Diagram shows how the equations are used to analyze the time for the

Vehicle to accelerate from 0 to 60 mph.

It shows a network of constraints (equations). Each constraint is a usage of a constraint blockdefined in the previous bdd

The diagram can then be exported to the appropriate simulation tools for property values

evaluation.Binding connector: Output

total force ft is equal to input f

in theAcceleration equation

Parameters can be bound toproperties of blocks:

it makes the parameter equal

to the property.

a.v.b = Bodyof the Vehicle of

the Autmobile Domain

Analysis Results from


50/54


Analysis Results from

Vehicle Ac celerat ion

Results from Engineering analysis can then be incorporated into the SysML model, or using other

incorporated models.

Ex: UML timing diagram

Using the Vehicle Control ler


51/54


Using the Vehicle Control ler

to Optimize Engine Performance

This activity diagram is a refinement of a portion of the Provide Poweractivity diagram

Vehicle Controller software has been added as an activity partition to support the analysis needed to

optimize fuel efficiency and engine performance

The specification of the algorithms require further analysis

A parametric diagram can specify the required fuel and air mixture in terms of RPM and engine

temperature to achieve optimum fuel efficiency, and they can be used to constrain the inputs and outputs

of the actions

The algorithms can be captured either in an activity diagram or directly in code

The Vehicle Controllerincludes

an action to Control Fuel Air

Mixture that produces the Engine

Acceleration Command.

The Vehicle Controllerincludes

an action to Control Gearto

determine when to change gear

based on engine speed (i.e.

RPM)

Specifying the Vehicle


52/54


Specifying the Vehicle

and its components

The Block definition diagram Vehicle Structure defined the blocks for the Vehicle and its

components.

The preceding analysis was used to specify the features of the blocks in terms of

Functions they perform,

Interfaces

Performances

And physical properties.

Component example: 6-Cylinder Engine block

Selected properties are indicated along

with their units

The 6-Cylinder Engine performs a

function called generate torque, with

specified inputs and outputs


53/54


Requirement traceability

Capturing theAutomobile System Requirements in the SysML model provides the means

to establish traceability between the requirements and other parts of the model

Example: Requirement for the Maximum Acceleration

Requirement is satisfied by the

Power Subsystem shown in its

own bdd

Rationale refers the

engineering analysisbased on the Vehicle

Acceleration Analysis

parametric diagram

Test case is shown as the

method to verify the requirement

is satisfied

Engine Powerrequirement

is derived from the

Maximum Acceleration req.

and contained in the

Engine Specification.

The 6-cylinder Engine block

refines the Engine Specification

by restating the requirements in

the model

Package Diagram


54/54

Package Diagram

for Organizing the Model

Integrated system model is the fundamental concept of MBSE

The Model contains all of the model elements

The model elements and their relationships

are captured in a Model Repositery

And can be displayed on diagrams

Model elements on one diagram may have relationships to

model elements on other diagrams.

Thus, a model organization is essential to manage the model.

The Package diagram shows how the model elements are

organized into packages.

Each package contains a set of model elements.

Model elements in one package can be related to model

elements in another package

BUT, model organization enable each model element tobe uniquely identified by the package that contains it

View is generally similar to a tool browser.

Documents

Signals and Systems Powerpoint