H-P Hoffmann, Ph.D. Model-based Systems Engineering Page 1
Overview of Systems Engineering Fundamentals- Model-based Systems Engineering -
Minneapolis 11-08-01
I-Logix Inc.3 Riverside Drive
Andover MA 01810USA
tel: 978-645-3022 . fax: 978-682-5995e-mail: [email protected]
Hans-Peter Hoffmann, Ph.D.Director and Chief Methodologist for Systems Design
Systems & MicroController Division
http://www.ilogix.com
H-P Hoffmann, Ph.D. Model-based Systems Engineering Page 2
1. Process Overview:
Model-based System Development
• The “V” Development Process • Requirements Capture (“Use Cases”)• Systems Analysis and Architectural Design• Transition to SW Design
2. Modeling Languages
3. Model-based Verification/Validation
4. Documentation in a Model-based Development
Model-based Systems Engineering
H-P Hoffmann, Ph.D. Model-based Systems Engineering Page 3
Test Engineers
SystemIntegration &
Test
System Acceptance
Shortcomings in System DevelopmentsThe “Throw-it-over-the-Fence” Process
Software Engineers
Electrical Engineers
Mechanical Engineers
HW/SWDesign
HW/SWImplementation
ModuleIntegration &
Test
System Engineers
SystemsAnalysis &
Design
Requirements-Analysis
Costs ofDesign Changes
Time
Cop
yrig
ht I
-Log
ix
H-P Hoffmann, Ph.D. Model-based Systems Engineering Page 4
Improving the Development Process: “Concurrent Engineering”
System Engineers Test Engineers
Mechanical Engineers
Software Engineers
Electrical Engineers
System Engineers
Test Engineers
Electrical Engineers
Software Engineers
Mechanical Engineers
SystemIntegration &
Test
System Acceptance
HW/SWDesign
HW/SWImplementation
ModuleIntegration &
Test
SystemsAnalysis &
Design
Requirements-Analysis
Cop
yrig
ht I
-Log
ix
H-P Hoffmann, Ph.D. Model-based Systems Engineering Page 5
Use Case Models
SystemAcceptance
System Integration & Test
Module Integration & Test
System Modification
Model/Scenario-based System Development
Test Scenarios Test Scenarios
Kn
owle
dge
Bas
e *
* Configuration controlled Knowledge that is increasing in Understanding until Completion of the System:
• Requirements Documentation• Requirements Traceability• Model Data/Parameters• Test Definition/Vectors
Cop
yrig
ht I
-Log
ix
Requirements Analysis
HW / SWImplementation
& Unit Test
HW / SW Design
Systems Analysis &
Design
System- / Performance- Model
Implementation Model
The iterative Process (“Micro-Cycles”)
Iterative Prototype
Implementation
Design
Analysis V&V
H-P Hoffmann, Ph.D. Model-based Systems Engineering Page 6
Requirements Capture
Basic tools for requirements capture are Use Cases and Scenarios
A Use Case describes a specific usage (“operational thread”) of a system.
• It specifies the behavior as perceived by the user(s) and the message flow between the user(s) and the use case.• It does not reveal the system’s internal structure (“black-box view”)
A Scenario is a specific path through a Use Case .
SystemAcceptance
SystemIntegration & Test
ModuleIntegration & Test
TEST/PARAMETER-DATABASE
HW / SWImplementation
& Unit Test
HW / SWDesign
Systems Analysis &
Design
Requirements Analysis
Cop
yrig
ht I
-Log
ix
H-P Hoffmann, Ph.D. Model-based Systems Engineering Page 7
Languages for Requirements Capture System
Acceptance
SystemIntegration & Test
ModuleIntegration & Test
TEST/PARAMETER-DATABASE
HW / SWImplementation
& Unit Test
HW / SWDesign
Systems Analysis &
Design
Requirements Analysis
Cop
yrig
ht I
-Log
ix
Actor 2
System Boundary Box
Use Case B
Use Case A
Use Case C
Actor 1
System Boundary Box
<<extend>> <<include>>
Use Case Diagrams
Sequence Diagramscapturing a specific use case scenario
Statechartscapturing all possible use case scenarios
Functional / Non-functionalRequirements
H-P Hoffmann, Ph.D. Model-based Systems Engineering Page 8
Input_Tray_Sensor
Tray_Detect_Sensor
Puller_Jaws_Solenoid
Puller_X_Stepper
I_Gripper_Jaws_Solenoid
Rail_Assembly_Stepper
PRS
Input_Mag_Y_Stepper
Input_Mag_Z_Stepper
Top_Jaw_Stepper
DC_Motor
LF_Present_Sensor
Jam_Detect_Sensor
Tucker_Assembly
I_Gripper_X_Stepper
Clamp
Output_Mag_Z_Stepper
Materials Handling System
Load Magazine
Eject Magazine
Inject Leadframe
Indexing Leadframe
Eject Leadframe
Materials Handling System
Requirements Capture (Use Case Diagram)Example: Materials Handling System
H-P Hoffmann, Ph.D. Model-based Systems Engineering Page 9
Requirements Capture (Sequence Diagram)Example: Materials Handling System
H-P Hoffmann, Ph.D. Model-based Systems Engineering Page 10
Cop
yrig
ht I
-Log
ix
Requirements Analysis
Requirements captured in use cases and respective scenarios may be incomplete, ambiguous or even wrong.
Use cases may be translated into executable functional models (Executable Use Cases) which then are validated through
• Simulation with stimuli derived from respective use case scenarios (Sequence Diagrams / Statechart) and
• Formal Verification Analysis
SystemAcceptance
SystemIntegration & Test
ModuleIntegration & Test
TEST/PARAMETER-DATABASE
HW / SWImplementation
& Unit Test
HW / SWDesign
Systems Analysis &
Design
Requirements Analysis
H-P Hoffmann, Ph.D. Model-based Systems Engineering Page 11
Use Case 1:“Fuel XFR and CG-Control”
Use Case Scenarios:• Normal Operation: - Center to Feed Tank Transfer - Forward Transfers from Trim Tanks - Aft Transfers to Trim Tank
• Operations with Failures: - Valves failed shut - Valves failed open - Pump Failures
X
L
LOT LIT
Center Tank
Trim Tank
RIT ROT
E1
BA BBF HWV
T
X
E2 E3 E4
Use Case 3: “Defueling”
Use Case 2: “Fueling”
Requirements Analysis
Capturing Requirements via Use CasesExample: Aircraft Fuel-/Defuel System
SystemAcceptance
SystemIntegration & Test
ModuleIntegration & Test
TEST/PARAMETER-DATABASE
HW / SWImplementation
& Unit Test
HW / SWDesign
Systems Analysis &
Design
Requirements Analysis
Cop
yrig
ht I
-Log
ix
H-P Hoffmann, Ph.D. Model-based Systems Engineering Page 12
Generic Activity
When the Trim Tank contains fuel and the aircraft is not in refuel or defuel mode then both Trim Tank Transfer Pumps shall be commanded ON otherwise they shall be commanded OFF.
Cop
yrig
ht I
-Log
ixValidation of Requirements through
Executable Use Case Model USE Case: XFR_AND_CG_CONTROL (Statemate)
Fuel_Control_System
Fuel_XFR_and_CG_Control
Switches Plant
Fuel_Control_System
H-P Hoffmann, Ph.D. Model-based Systems Engineering Page 13
Validation of Requirements through Executable Use Case Model
USE Case: XFR_AND_CG_CONTROL – Graphical User Interface (Statemate)
H-P Hoffmann, Ph.D. Model-based Systems Engineering Page 14
Benefits from Requirements Modeling
Manage complexity by focusing on specific intended operations
Understand requirements relationship
Generate “Derived Requirements”
Perform preliminary validation of requirements, e.g. Eliminate ambiguities through model execution
SystemAcceptance
SystemIntegration & Test
ModuleIntegration & Test
TEST/PARAMETER-DATABASE
HW / SWImplementation
& Unit Test
HW / SWDesign
Systems Analysis &
Design
Requirements Analysis
Cop
yrig
ht I
-Log
ix
H-P Hoffmann, Ph.D. Model-based Systems Engineering Page 15
SystemAcceptance
System Integration & Test
Module Integration & Test
Requirements Analysis
Use Case Models
System Modification
System- / Performance- Model
Test Scenarios
Model/Scenario-based System Development
HW / SWImplementation
& Unit Test
HW / SW Design
Systems Analysis &
Design
Implementation Model
Kn
owle
dge
Bas
e
Test Scenarios
Validated Requirements
incl. executable Use Case Prototypes
From Requirements Analysis to Systems Analysis & Design
Cop
yrig
ht I
-Log
ix
H-P Hoffmann, Ph.D. Model-based Systems Engineering Page 16
V&V Cycle
V&V Cycle
• “Conceptual Model”: Functional Decomposition down to the Hierarchy Level where related System States are captured ( Level 3)
SystemFunctional
Design
if System Architecture tbd
HW Design & Build SW Design & Implementation
Requirements
V&V Cycle incl.RAPID PROTOTYPING
V&V Cycle
Subsystem Design *
• HW/SW Partitioning• Subsystem Analysis of HW/SW Collaboration• Definition of Subsystem Interfaces
V&V Cycle
Use Case Scenarios • Requirements Capture and V&V through executable Use Case Models
RequirementsAnalysis
• Use Cases Assignment to Subsystems
SubsystemFunctionalDesign *Subsystem
RequirementsDocument
HW/SW Requirements Specification
Document
The Top-Down System Design Processin Aerospace/Defense
* Concurrent Engineering Task
• Grouping of Functionality• System-Level COTS Analysis• Partitioning into Subsystems
SystemDesign *
Cop
yrig
ht I
-Log
ix
System Requirements
Document
Links providingTraceability of Specs
to original Requirements Test Scenarios /Test Vectors
H-P Hoffmann, Ph.D. Model-based Systems Engineering Page 17
Functional Decomposition The „Top-Down“ Approach
Hierarchy Level 0(“ Context-Diagram“ )
ExternalData Sink
External Data Source
Hierarchy Level 1Top-Down
Hierarchy Level 2
Cop
yrig
ht I
-Log
ix
H-P Hoffmann, Ph.D. Model-based Systems Engineering Page 18
Subsystem Functional Design
The Subsystem Design ProcessHW/SW Partitioning (Statemate) V&V Cycle incl.
Rapid Prototyping
SubsystemFunctional
Design
SubsystemDesign
V&V Cycle
Subsystem Design:Definition of Subsystem Interfaces
Interface to other Subsystems
*
Subsystem Design:HW/SW Partitioning
Analysis of HW/SW Collaboration
*
* may have to be partitioned
Cop
yrig
ht I
-Log
ix
H-P Hoffmann, Ph.D. Model-based Systems Engineering Page 19
• Power Mirror• Power Window• Seat Heating• Memory Store/Recall. . . . . . . . . .
Platform independent Feature Library
FeatureModels
FA
F
F
FeatureModels
FA
F
F
FeatureModels
F
FeatureModels
F
Process Buffer
Vehicle System
. . .
Test Scenariosderived fromRequirements
Recorded System Behavior
“Feature-based” System Design Approach (Automotive)
Capturing Vehicle-specific Features in a Conceptual System ModelFunctional Requirements
H
AF
FP
AF
FM
F
S
F
K
AF
FB
F
X
F
L
F
. . .
FeatureModels
FA
F
F
FeatureModels
FA
F
F
FeatureModels
FA
F
F
FeatureInteraction
Models• Exterior Light ( Front, Back, Fog, Wiper/Washer )• Seat Control ( Positioning, Heating, Venting ). . . . . . . . . . . . . . . . . . . . .
Cop
yrig
ht I
-Log
ix
H-P Hoffmann, Ph.D. Model-based Systems Engineering Page 20
started/SH_S1_CMD:=SH_LVL1_CMD;SH_S2_CMD:=SH_LVL2_CMD;SH_LOW_VOLTG:=KL30_LOW_VOLTG;;--ch(SH_LVL1_CMD) or ch(SH_LVL2_CMD) orfs(KL15C or KL15X orKL30_HIGH_VOLTG or KL30_LOW_VOLTG)/if not KL15C and not KL15X and not KL30_HIGH_VOLTG and not KL30_LOW_VOLTG then SH_S1_CMD:=SH_LVL1_CMD; SH_S2_CMD:=SH_LVL2_CMD; SH_LOW_VOLTG:=KL30_LOW_VOLTGend if;;--tr(KL15C or KL15X or KL30_HIGH_VOLTG or KL30_LOW_VOLTG)/fs!(SH_S1_CMD);fs!(SH_S2_CMD);SH_LOW_VOLTG:=KL30_LOW_VOLTG;;
Feature Model (Statemate):Seat Heating
Cop
yrig
ht I
-Log
ix
H-P Hoffmann, Ph.D. Model-based Systems Engineering Page 21
Feature Interaction Model (Statemate):Seat Controller
Cop
yrig
ht I
-Log
ix
H-P Hoffmann, Ph.D. Model-based Systems Engineering Page 22
. . .
Process Buffer
Vehicle System
H
AF
FP
AF
FM
F
S
F
. . .
K
AF
FB
F
X
F
L
F
Test Scenariosderived fromRequirements
Process Buffer
ECU_1 Functions ECU_N Functions
Vehicle System
ECU Test Vector Recording
“Feature-based” System Design ApproachSystem Partitioning, Parsing of Features/Feature Sub-Functions, and
Validation of logical Interfaces
B
FK
AF
FH
AF
F
X
FH
AF
FM
F
. . .
Cop
yrig
ht I
-Log
ix
H-P Hoffmann, Ph.D. Model-based Systems Engineering Page 23
. . .
Process Buffer
Vehicle System
InputFilter
OutputFilter
Process Buffer
Bus Interface
ECU_N
Test Scenariosderived fromRequirements
Definition of HW Interfaces and Validation through Rapid Prototyping
ECU_1 Functions
B
FK
AF
FH
AF
F
ECU_N Functions
X
FH
AF
FM
F
ECU_N Functions
X
FH
AF
FM
F
H/W Test Vectorsderived from recordedlogical ECU Test Vectors
Cop
yrig
ht I
-Log
ix
H-P Hoffmann, Ph.D. Model-based Systems Engineering Page 24
SystemAcceptance
SystemIntegration & Test
Test Scenarios
System Modification
HW/SW RequirementsSpecification
Test ScenariosRequirementsAnalysis T
EST
DBSystems
Analysis & Design
function/data-orientedSystems Engineering
RequirementsSpecification
A-D-I-T Cycles
A-D-I-T Cycles
From Function/Data-oriented Systems Engineeringto Object-oriented SW Design
A-D-I-T : Analysis-Design-Implementation-Testing
Design
Implementation
Testing
MechanisticDesign
DetailedDesign
Coding
UnitTesting
IntegrationTesting
ValidationTesting
IterativePrototypes
object-oriented SW Design
H-P Hoffmann, Ph.D. Model-based Systems Engineering Page 25
1. Process Overview:
Model-based System Development
• The “V” Development Process • Requirements Capture (“Use Cases”)• Systems Analysis and Architectural Design• Transition to SW Design
2. Modeling Languages
3. Model-based Verification/Validation
4. Documentation in a Model-based Development
Model-based Systems Engineering
H-P Hoffmann, Ph.D. Model-based Systems Engineering Page 26
User Interface View
Panel
TargetPilot
Use Case 1
UC_1_1_3 Select Weapon
UC_1_1_4 Perform prerelease calcsUC1_1_1 Process
and store TGT position data
UC1_1 TGT Acquisition
UC1_1_12 Groundstab LDP
to TGT
Use Case 1
<<include>>
<<include>>
Use Case View
Use
Cas
e D
iagr
am
Use Case Scenario View
Sequ
ence
Dia
gram
Time-continuous Behavioral View
Time-
cont
inuo
us D
iagr
am
State-based Behavioral View
Statechart
Cop
yrig
ht I
-Log
ix
Statemate
Functional / Architectural View
Activity Chart
Modeling Languages (Statemate)The different “Views” to a System
H-P Hoffmann, Ph.D. Model-based Systems Engineering Page 27
+ Hierarchy:Structure:A state may consist of states which consist of states …Priority rule for transitions:Priority is given to the transition whose source and target states have a higher common ancestor state.
Modeling Languages Definition of Statecharts
Finite State Machine (FSM):A virtual machine that can be in any one of a set of finite states and whose next states and outputs are functions of input and current states.
+ Concurrency:Description of independent - or almost independent – parts of system behavior (e.g. subsystems) in a single Statechart.
Synchronization through Broadcasting.
Cop
yrig
ht I
-Log
ix
H-P Hoffmann, Ph.D. Model-based Systems Engineering Page 28
The Statechart LanguageDescribing Interrupt Priorities through Hierarchies
H-P Hoffmann, Ph.D. Model-based Systems Engineering Page 29
Modeling Languages Functional Description through Activity Charts
Activity Chart
Statechart
Cop
yrig
ht I
-Log
ix
H-P Hoffmann, Ph.D. Model-based Systems Engineering Page 30
Activity ChartsEncapsulation of Activities
Statechart
Activity Chart
Cop
yrig
ht I
-Log
ix
H-P Hoffmann, Ph.D. Model-based Systems Engineering Page 31
Activity ChartsDescribing Basic Function-Blocks (“Basic Activities”)
Mini-Spec Continuous Diagrams
Truthtables
(Legacy) C-Code
Statemachines(Statechart)
Cop
yrig
ht I
-Log
ix
H-P Hoffmann, Ph.D. Model-based Systems Engineering Page 32
started/ACCEL_CMD:=GAIN_ACC*ACCEL_DEFLECTION;;tm(wr(ACCEL_CMD),0.1)/ACCEL_CMD:=GAIN_ACC*ACCEL_DEFLECTION;;
PI_Controller
Modeling Languages (Statemate)“Hybrid” ( = state-based & time-continuous/time-discrete) Modeling
(Example: Simplified Model of a Cruise Control )
Vehicle_Dynamics_Kinematics
Cop
yrig
ht I
-Log
ix
H-P Hoffmann, Ph.D. Model-based Systems Engineering Page 33
1. Process Overview:
Model-based System Development
• The “V” Development Process • Requirements Capture (“Use Cases”)• Systems Analysis and Architectural Design• Transition to SW Design
2. Modeling Languages
3. Model-based Verification/Validation
4. Documentation in a Model-based Development
Model-based Systems Engineering
H-P Hoffmann, Ph.D. Model-based Systems Engineering Page 34
Executable Specification (Statemate)
Example: Mission Computer Symbol Generator (UFCP)
Cop
yrig
ht I
-Log
ix
H-P Hoffmann, Ph.D. Model-based Systems Engineering Page 35
Seat-Heating Module (Functional Model)
Test-Data Generation
via GUI
Model Verification / Validation through Simulation (Statemate)
Simulation Output: Waveform Diagram
Requirements Scenario SH-005
Cop
yrig
ht I
-Log
ix
H-P Hoffmann, Ph.D. Model-based Systems Engineering Page 36
Model Verification / Validation
Test-Script Generation and Re-Use of Tests
S/W Requirements Specification
Test Patterns
1. FUNCTIONAL DESCRIPTION
2. BEHAVIORAL DESCRIPTION
Requirements related Test-Vectors ( Playback File)
Actual Output
OutputAnalysis
ECU
RQOutput
TestInput
Testbench for Unit-Test i.e. HP ECUTESTC
opyr
igh
t I-L
ogix
H-P Hoffmann, Ph.D. Model-based Systems Engineering Page 37
Model Verification / Validation
Extended System Analysis
A system specified by means of a Formal Specification Language, may be amenable to Formal Verification.
Formal Verification increases the safety of a design by mathematically
• Proving that disastrous situations never happen Based on the description of an unwanted situation the algorithm will check for the respective safety bug
• Ensuring expected situations are reachable “Drive to State / Drive to Configuration”
Formal Verification may also be used to automatically generate test cases for unit, module, and integration testing
H-P Hoffmann, Ph.D. Model-based Systems Engineering Page 38
Model Verification / Validation
Code Generation
A system specified by means of a Formal Specification Language may be amenable to Code Synthesis , e.g. C-Code or VHDL-Code
During the Requirements Analysis Phase a “Soft Prototype” together with a graphical User Interface may be used as a first “Proof of Concept” or for marketing purposes
During the System Design Phase, code generation may help to
• Validate Hardware/Software partitioning (“Hardware/Software Co-Design”)
• Validate the design in its real environment by porting it to some prototyping hardware (“Rapid Prototyping”)
Cop
yrig
ht I
-Log
ix
H-P Hoffmann, Ph.D. Model-based Systems Engineering Page 39
MIL 1553B
parallel/ serial
TCP/IP
Model (Back-) Animation
UNIX / NT
Prototype Target Unit
Statemate MAGNUM generated code running on RTOS (e.g. VxWorks)
Functional Model Verification / Validation
Rapid Prototyping
Cop
yrig
ht I
-Log
ix
H-P Hoffmann, Ph.D. Model-based Systems Engineering Page 40
1. Process Overview:
Model-based System Development
• The “V” Development Process • Requirements Capture (“Use Cases”)• Systems Analysis and Architectural Design• Transition to SW Design
2. Modeling Languages
3. Model-based Verification/Validation
4. Documentation in a Model-based Development
Model-based Systems Engineering
H-P Hoffmann, Ph.D. Model-based Systems Engineering Page 41
Documentation in a Model-based Development
A system specified by means of a Formal Specification Language implies a paradigm shift in documentation.
Since by definition the system under design is described unambiguously, no additional “descriptive” text is needed.
The additional information should be restricted to remarks like
• Quality of Service Requirements or
• Requirements Traceability information.
H-P Hoffmann, Ph.D. Model-based Systems Engineering Page 42
1 APPLICABLE DOCUMENTS
2 SYSTEM OVERVIEW
3 SMS NEW
3.1 OUTPUT PROC3.2 NORMAL OPERATIONS
3.2.1 CALCULATE BALANCE3.2.2 DEFINE SEQUENCE3.2.3 SELECT PACKAGES3.2.4 PERFORM RELEASE GEN
3.3 INVENTORY MANAGEMENT3.3.1 DISPLAY IN AIR3.3.2 DISPLAY LOP3.3.3 DISPLAY ON GROUND3.3.4 DISPLAY RELEASE INFORMATION
3.4 INITIALISATION3.4.1 INIT ON POWER UP3.4.2 RESET INVENTORY
3.5 EMERGENCY OPERATIONS
4 GENERIC ACTIVITY CHARTS
4.1 STATION CONTROL
5 STATECHARTS
5.1 GENERATE RELEASES FUNCTION5.2 INITIALISATION CTRL5.3 NORMAL OPERATIONS CTRL5.4 PERFORM EMERGENCY JETTISON5.5 SMS NEW CTRL5.6 STORE DISPLAY CTRL
6 DATA DICTIONARY
6.1 Actions6.2 Conditions6.3 Simple Data-items6.4 Events6.5 Information Flows6.6 Simple User Defined Types6.7 Enumerated User Defined Types6.8 Structured User Defined Types6.9 Subroutines
7 TREE REPORT
8 APPENDIX
8.1 Truth Tables8.1.1 Truth-Table of Action DETERMINE_RELEASE_TT
9 CHANGE LOG
Model Documentation (Statemate) Example: STORES MANAGEMENT SYSTEM
hierarchical order of Activity Charts
3 . 2 N O R M A L O P E R A T I O N S
O v e r v i e w :T h e n o r m a l o p e r a t i o n s a l l o w t h e o p e r a t o r t o s e l e c t r e l e a s e p a c k a g e s a n d t o p e r f o r m t h e r e l e a s e .
T h e o p e r a t o r i s a l l o w e d t o d e f i n e u p t o t h r e e r e l e a s e p a c k a g e s , e a c h p a c k a g e c o n s i s t i n g o f a s t o r e t y p e ,q u a n t i t y t o r e l e a s e a n d t h e r e l e a s e s e q u e n c e . T h e o p e r a t o r s e l e c t s t h e s t o r e t y p e a n d t h e q u a n t i t y b u t i t i st h e S M S w h i c h d e c i d e s t h e r e l e a s e s e q u e n c e . T h e r e l e a s e s e q u e n c e i s c a l c u l a t e d s u c h t h a t t h e a i r c r a f tb a l a n c e i s m a i n t a i n e d ; i n t h i s c a s e t h e a i r c r a f t w i l l b e b a l a n c e d p r o v i d e d t h a t n e i t h e r w i n g c a r r i e s m o r e t h a to n e s t o r e m o r e t h a n t h e o t h e r .
I n p u t / O u t p u t R e q u i r e m e n t s :
3 . 2 . 1 C A L C U L A T E B A L A N C E
D e s c r i p t i o n :I t i s u n s a f e f o r t h e a i r c r a f t t o b e s i g n i f i c a n t l y o u t o f b a l a n c e . B a l a n c e i s c a l c u l a t e d b y t a k i n g t h e d i f f e r e n c eb e t w e e n t h e n u m b e r o f s t o r e s o n t h e l e f t w i n g a n d t h e n u m b e r o f s t o r e s o n t h e r i g h t w i n g . I n g e n e r a l , t h eb a l a n c e i s g i v e n a p o s i t i v e n u m b e r w h e n t h e r i g h t w i n g c o n t a i n s m o r e s t o r e s .
N O R M A L _ O P E R A T I O N S
@ P E R F O R M _R E L E A S E _G E N
D E F I N E _S E Q U E N C E >
C A L C U L A T E _B A L A N C E >
S E L E C T _P A C K A G E S >
@ N O R M A L _ O P E R A T I O N S _ C T R L
P R O C E S S _ B U F F E RP R O C E S S _ B U F F E R
S E L E C T E D _ P A C K A G E
T E R M I N A T E _R E L E A S E
E N D _P E R F O R M _R E L E A S E
P A C K A G E S _S E Q U E N C E
C U R R E N T _B A L A N C E
P A C K A G E S _ S T O R E _ T Y P E
P A C K A G E S _ Q U A N T I T Y
R E L E A S E _ T Y P E _ A C T
S E L E C T E D _ S T _ N O P
R E L E A S E _ Q U A N T I T Y _A C T _ D S
S T _ S T O R E _ F U Z E _N O R M A L _ O P
S T _ S T O R E _ R E L E A S E _N O R M A L _ O P
R E L E A S E _Q U A N T I T Y _ A C T _ S P
S E L E C T E D _ S T A T I O N S
S T O R E _ D A T A
R E L E A S E _ Q T Y _ A C TS T A T I O N S _ S T O R E _ F U Z E
S T O R E _ R E L E A S E _ F R E ER E L E A S E _ D E M A N D
I N V E N T O R Y
L A T E _ A R M
R E L E A S E _ C O N S E N T
R E L E A S E _ Q T Y _ D M DR E L E A S E _ T Y P E _ D M D
S T E P _ P A C K A G E
S T A T I O N S _ S T O R E _ P R E SCop
yrig
ht I
-Log
ix
H-P Hoffmann, Ph.D. Model-based Systems Engineering Page 43
1 APPLICABLE DOCUMENTS
2 SYSTEM OVERVIEW
3 SMS NEW
3.1 OUTPUT PROC3.2 NORMAL OPERATIONS
3.2.1 CALCULATE BALANCE3.2.2 DEFINE SEQUENCE3.2.3 SELECT PACKAGES3.2.4 PERFORM RELEASE GEN
3.3 INVENTORY MANAGEMENT3.3.1 DISPLAY IN AIR3.3.2 DISPLAY LOP3.3.3 DISPLAY ON GROUND3.3.4 DISPLAY RELEASE INFORMATION
3.4 INITIALISATION3.4.1 INIT ON POWER UP3.4.2 RESET INVENTORY
3.5 EMERGENCY OPERATIONS
4 GENERIC ACTIVITY CHARTS
4.1 STATION CONTROL
5 STATECHARTS
5.1 GENERATE RELEASES FUNCTION5.2 INITIALISATION CTRL5.3 NORMAL OPERATIONS CTRL5.4 PERFORM EMERGENCY JETTISON5.5 SMS NEW CTRL5.6 STORE DISPLAY CTRL
6 DATA DICTIONARY
6.1 Actions6.2 Conditions6.3 Simple Data-items6.4 Events6.5 Information Flows6.6 Simple User Defined Types6.7 Enumerated User Defined Types6.8 Structured User Defined Types6.9 Subroutines
7 TREE REPORT
8 APPENDIX
8.1 Truth Tables8.1.1 Truth-Table of Action DETERMINE_RELEASE_TT
9 CHANGE LOG
Model Documentation (Statemate) Example: STORES MANAGEMENT SYSTEM
5 .5 S M S N E W C T R L
D e scr ip tio n :
T h e o v e ra ll c o n tro ls fo r th e S to re s M an a g em e n t S ys te m a re th e M a s te r A rm S a fe tyS w itch (M A S S ) an d th e E m e rg en c y J e ttiso n b u tto n . T h e s ys te m p o w e r is co n tro lled b yth e M as te r A rm S a fe ty S w itc h (M A S S ) w h ic h h as th re e p o s itio n s : O F F , S T A N D B Y a n dL IV E .
W h en th e M A S S is O F F th e S M S is u n -p o w e re d an d h en c e n o o p e ra tio n is p o ss ib le .
W h en th e M A S S is in S T A N D B Y th e S M S is p o w e re d b u t n o re le a se s a re a llo w ed .T h u s in th is m o d e th e S M S co m p le te s a n y s ta rt-u p b u ilt in te s t, re se ts an y v a ria b le s a n dse ts a ll o u tp u ts to a n o n -a c tiv e s ta te .
W h en th e M A S S is L IV E th e S M S rem a in s p o w e re d an d a ll fu n c tio n s in c lu d in g re le a se sa re a l lo w e d . W h e n in th is s ta te , th e S M S h as tw o o p e ra tin g m o d es : L IV E an dE M E R G E N C Y J E T T IS O N . L IV E is th e n o rm a l ca s e . O p e ra tin g th e e m e rg en c y je ttiso nb u tto n w ill c a u se th e S M S to e n te r th e E M E R G E N C Y JE T T IS O N s ta te w h ich w ill c au s en o rm a l o p e ra tio n s to b e ce a s ed an d s ta r t th e em e rg e n c y o p e ra tio n s seq u en ce .
T h e em erg e n c y o p e ra tio n s se q u e n ce sh a ll co n tin u e u n til th e em e rg en c y je tt iso n b u tto n isre lea s ed .
F u n c tio n :
SMS_NEW_CT RL
SM S_OFF
SMS_ON>
SMS_STANDBY
SMS_EMERGENC Y_JETTISON>
SMS_LIVE>
[not EM ERGENCY_JETTISON][EMERGENCY_J ETTISON]/DESELECT_STA TIONS
[MASS=MASS_ST ANDBY]/DESELECT_STAT IONS
[MASS=MASS_L IVE]
[MASS=MASS_S TANDBY]/ALL_FUZING_S IGNALS_OFF;ALL_RELEASE_ SIGNALS_OFF
[MASS=MASS _OFF]
alphabetical order of Statecharts
Cop
yrig
ht I
-Log
ix
H-P Hoffmann, Ph.D. Model-based Systems Engineering Page 44
1 APPLICABLE DOCUMENTS
2 SYSTEM OVERVIEW
3 SMS NEW
3.1 OUTPUT PROC3.2 NORMAL OPERATIONS
3.2.1 CALCULATE BALANCE3.2.2 DEFINE SEQUENCE3.2.3 SELECT PACKAGES3.2.4 PERFORM RELEASE GEN
3.3 INVENTORY MANAGEMENT3.3.1 DISPLAY IN AIR3.3.2 DISPLAY LOP3.3.3 DISPLAY ON GROUND3.3.4 DISPLAY RELEASE INFORMATION
3.4 INITIALISATION3.4.1 INIT ON POWER UP3.4.2 RESET INVENTORY
3.5 EMERGENCY OPERATIONS
4 GENERIC ACTIVITY CHARTS
4.1 STATION CONTROL
5 STATECHARTS
5.1 GENERATE RELEASES FUNCTION5.2 INITIALISATION CTRL5.3 NORMAL OPERATIONS CTRL5.4 PERFORM EMERGENCY JETTISON5.5 SMS NEW CTRL5.6 STORE DISPLAY CTRL
6 DATA DICTIONARY
6.1 Actions6.2 Conditions6.3 Simple Data-items6.4 Events6.5 Information Flows6.6 Simple User Defined Types6.7 Enumerated User Defined Types6.8 Structured User Defined Types6.9 Subroutines
7 TREE REPORT
8 APPENDIX
8.1 Truth Tables8.1.1 Truth-Table of Action DETERMINE_RELEASE_TT
9 CHANGE LOG
Model Documentation (Statemate) Example: STORES MANAGEMENT SYSTEM
Optional: alphabetical order
Cop
yrig
ht I
-Log
ix