Bild 1 - Industrial information and control systems

Large scale MBSE – Lessons from SAAB
Erik Herzog, Ph.D., SAAB Fellow - Systems Engineering
2011-04-04
INCOSE Large Scale MBSE Seminar
The domain
What I do for a living
@ SAAB
•
SE Process and methodology development/harmonisation – towards
’one SAAB’
@ SAAB Aeronautics
•
•
•
•
•
SE Process and method development and management
Process adaptation for large projects
Introducing a System architecture and design methodology using
SysML
Methodology development in research projects
Ph.D. student supervisor
@ INCOSE
•
Ordförande INCOSE Sverige
@ Home
•
•
•
Family management
Golf
Innebandy
The world we live in
Complex technologies
Integrated into complex products
Life cycle issues
Change is constant
Developed in complex organisations
The challenge
We need to do more with less resources
while improving product quality
How to optimise the SE capability?
The paradox
Whenever we add a new mathod/tool - the stengths of the
tool will be used out of proportion
When DOORS was introduced at SAAB traceability links
was created in abundance
Over use of tool capabilities may actually decrease the
overall performance of an organisation
Adding tool support must reduce overall workload!
If we add something new then we have to stop doing
something else
•
We can’t just stack up new methodologies, the old ones have to be
adapted or retired
Where we were
Our ’old’ development process
Stakeholder
Requirements
Definition
System
Requirements
Analysis
Define
Functional
Architecture
Typ
JAS
System
Documentation
Define
Physical
Architecture
PS
PS HU
HU
PS
PS CZ
CZ
PDD
PDD
PDD
PDD
PDD
PDD
Trace links
SSS
SSS
PDD
PDD
PDD
PDD
SSDD
SSDD
PDD
PDD
PDD
PDD
DOORS
SRS
SRS
PDD
PDD
PDD
PDD
Kod
Kod
PDD
PDD
PDD
PDD
EqSp
EqSp
PDD
PDD
PDD
PDD
Integrate
Sequential process
Document driven approach
•
PS
PS SE
SE
Implement
SDD
SDD
PDD
PDD
PDD
PDD
PS
PS J2
J2
PS
PS SA
SA
Complete one document prior to initiating
work on the next one
Fixed document structure
Much focus on requirements
(requirements in design documentation)
Traceability is costly to implement and
maintain
Insufficient attention on describing what
the system looks like (in a reader
friendly format)
Where we want to go 1 (2)
Development process that emphasise parallel aspect of work
Where we want to go 2 (2)
Clear definition of system design
System components
Interfaces
MBSE
Concept of execution
Specification
Specification
PDD
PDD
PDD
PDD
Design
Design
PDD
PDD
PDD
PDD
Trace links
Documentation structure basedon
system complexity
WS
•
Specification
Specification
PDD
PDD
PDD
PDD
A/C
Design
Design
PDD
PDD
PDD
PDD
Specification
Specification
PDD
PDD
PDD
PDD
Design
Design
PDD
PDD
PDD
PDD
MSS
…
Test
Test
PDD
PDD
PDD
PDD
NAV
EWS
Modell
Modell
…
Dynamic depth
Early focus on integration, verification,
transit to use and validation
System – Subsystem – Capabilitiy lifecycles
WS level
WS/AC concept design
Equipment A
Equipment and
subsystems
Equipment
concept
Equipment B
Capability A
Capability level
Product design, realisation & integration
Equipment
verification
Equipment
Integration
Equipment
Acquisition
Equipment
concept
Equipment
Acquisition
Equipment
verification
Equipment
Integration
Capability realisation
Capability
Capability
concept design detailed design
& integration
Capability B
Capability
verification
Capability realisation
Capability
Capability
concept design detailed design
& integration
Capability C
Overall capability
definition set
(first baseline)
Capability
verification
Capability realisation
Capability
Capability
concept design detailed design
& integration
Capability D
Constraints
implied by
equipment A
fixed
Verification
Capability
verification
Capability realisation
Capability
Capability
concept design detailed design
integration
Constraints
implied by
equipment B
fixed
Capability
verification
SAAB MBSE vision
MBSE
validation
validation in traditional
approach
Scoping the presentation
Models (examples)
Requirements
Prototypemodel
Black
Box
Designmodel
Y=x+1
Realisationmodel
X-2
Y+2
2x+5
transform
Testmodel
Realisation
10010100101001
00101010101001
0101010
Requirements containing model
fragments expressing required system
properties.
Prototype model potentially
executable, meeting high level
functional requirements. May be used
for code generation.
Design model: Architectural and
functional design at a suitable level of
abstraction.
Realisation model potentially
executable, meeting requirements,
structure corresponds to the
realisation.
Realisation executable object code
(for verification in target system)
Test model realises requirements
based testing. May be used to verify
the prototype and realisation models
as well as the realisation.
Model development intensity vs lifecycle
Realisation models
Design models
Prototype models
Capability realisation
Capability
Capability
concept design detailed design
& integration
Capability
verification
Domain models vs system models
Domain models typically provide the following benefits
•
•
•
•
Rapid prototyping
Early validation
Code generation
• Production code
• Simulation
Communication
System models
•
•
•
•
Communication
Early validation
Integration
Verification
Some experience from SAAB
Where are we MBSE-wise?
Skeldar
System architecture in
UML/SysML.
Software generated
from Systembuild and
Rhapsody models
Gripen NG (C/D)
System architecture in SysML.
Software generated from Simulink
and Rhapsody/Bridgepoint models.
User interface models generated
using VAPS
Physical models in Dymola
MBSE challenges
Integration across tool boundaries
Training of third parties
PDM system integration
Variant management
The legacy of the document paradigm
Obsolescence
Training of third parties
The readers of our models/deliverables must
understand what we are trying to convey
•
•
We must limit our usage of the modelling language
And present it in a reader friendly way
Information must be in a format that is natural to
interpret for the receiver
•
Once basic model semantics is understood
Training must be adapted to each stakeholder
Minimised SysML set
Accept that some information will not be SysML formatted
Integration across tool
boundaries
It migh be possible to integrate all tools in the development
tool chain
•
•
•
Links
Data exchange
…
Tight integration limits flexibility
And is risky/costly over time
The challenge is to find the right balance
Information management
Face it, our support systems are made for managing
documents
•
•
CM
PDM
The document paradigm is excellent for providing a
coherent view on a design
Sign-off routines work for documents
•
How to do it on models?
Not all design information is suitable for SysML-ification
•
Keep traditional document format where appropriate
Not all information in the model is intended for publication
A good document generator (and model package structure)
is a prerequisite for MBSE acceptance
Model structure for documentation
SSDD outline (MIL-STD-498)
Document template
1.
1.1
1.2
1.3
SCOPE
Identification
System overview
Document overview
Package ”Scope”
• Controlled files
1
1..*
Package ”System-wide design decisions”
• Controlled files
1
1..*
2
REFERENCED DOCUMENTS
3
SYSTEM-WIDE DESIGN DECISIONS
4
4.1
4.2
4.3
SYSTEM ARCHITECTURAL DESIGN
System components
Concept of execution
Interface design
Package ”System components”
• Controlled files
• Block Definition Diagrams
• Picture + Description
• Controlled files
• Blocks
• Name + Description
• Tags
1
0..*
1..*
1..*
0..*
1..*
1..*
0..*
5
REQUIREMENTS TRACEABILITY
6
6.1
NOTES
Terms and abbreviations
Package ”Concept of Execution”
• Controlled files
• Use Case Diagrams
• Use cases
• Name + Description
• Controlled files
• Statechart Diagrams
• Name + Picture + Description
• Controlled files
• Activity Diagrams
• Name + Picture + Description
• Controlled files
1
0..*
1..*
1..*
1..*
0..*
0..*
0..*
0..*
0..*
0..*
0..*
Package ”Interface Design”
• Internal Block Diagrams
• Picture + Description
• Controlled files
• Parts
• Picture + Description
• Controlled files
1
1..*
1..*
0..*
1..*
1..*
0..*
Package ”Notes”
• Controlled files
1
Variant management and incremental
development
It is not one product, one release any more
The system model need to support a baseline for
subsystem development
While the system model itself is evolving
And doing so for multiple variants/configuration of
the system
Obsolescence
Tool landscape is changing very fast
No matter which tool you select there will soon be others
that appear more competitive
Tool providers are small and notorious for not meeting
promises in their development plans
What to do?
•
•
Make an educated guess
Consider the exit strategy up-front
Steps towards MBSE
One process that clearly communicates a common way of
working
•
If different parts of the organisation have conflicting views on how work shall be
performed then we will be forced to introduce MBSE many times.
Clearly communicate what the processes shall deliver and in
which format
•
Same approach for all projects applying MBSERestriktioner
Don’t use all possibilities in the language!
Training
•
Capture how you want the engineers to work, not multiple alternatives ways
describing how they could potentially work
Pilots and Mentors
•
Engage the engaged first and ensure that there is adequate support available
for the engineers that apply the new methodology
Think about documentation up front
•
•
•
All elements in the database need not end up in all formal documentation
Elements that will not be used in any formal documentation should not be
entered in the database
Use MBSE where its strengths add value, not for everything just because it is
possible
What is next?
Usage of architecture models for integration domain
design and simulation models
Real parametrics
Capture of requirements, and requirement integration with
models
•
Focus on the essential requirements
Introduction of industrial strength formal methods