Download - INCOSE International Workshop 25-28 Jan 2014
© 2014
How MBSE is used in Rail INCOSE International Workshop
25-28 Jan 2014
Dr. Mike Brownsword Atkins
© 2014
Overview
2
•Introduction
• Company overview
•Using MBSE
• Process definition
• Requirements
• Architecture
• V&V/assurance
•Delivering MBSE
© 2014
Introduction
3
Model-based Systems Engineer - Rail
•London Underground,
•Network Rail,
•HSL Zuid,
•MARTA.
Atkins Consultant
•Requirements, Architecture, Information, Architecture Frameworks, Process definition.
© 2014
At a glance
Atkins is one of the world’s leading design, engineering and project management consultancies.
We have the depth and breadth of expertise to respond to the most technically challenging and time-critical infrastructure projects and the urgent transition to a low carbon economy.
In 2013 Atkins is celebrated 75 years in business.
5
© 2014
Our clients
6
Revenue by client type
Public sector: local government 28%
Public sector: national government 21%
Regulated 16%
Private sector 35%
Key Transport clients include:
Network Rail
Texas Dept of Transportation
UK Highways Agency
Florida Department of
Transportation
Transport for London
Trafikverket
BAM Group (UK)
Banedanmark (RailDenmark)
New York City Transit
MTR Corporation Ltd
Etihad Rail Company PJSC
Jernbaneverket (Rail Norway)
Ministry of Municipality & Urban
Planning (MMUP) Qatar
Crossrail
MARTA
Crossrail United Kingdom
Detailed design of twin bored tunnels,
and design and specification Tottenham Court Road and
Custom House stations and Plumstead depot
Image courtesy of Crossrail
Birmingham New Street Station United Kingdom
Image courtesy of Network Rail
Lead consultant,
design management and
urban planning
European Rail Traffic Management System Denmark
Client advisor for the design,
implementation and testing of
ERTMS on the entire Danish rail
network (3200km)
© 2014
Process definition
11
Aim
● Identify the right process
● Understand the information and activities to be delivered
● Ensure consistency between activities and information
● Focus on Activities not documents
Approach
● Take multiple views of a process
● Combine/contrast views to provide consistency.
● Be pragmatic regarding rigour and maturity of information.
● Expect repetition of processes, not one shot.
© 2014
Process definition
12
act Requirements Dev elopment
Perform analysis
(Requirements Development::)
ActivityInitial
ActivityFinal
Analysis completed
to defined purpose?
Approval gained
from all reviewers?
Requirements
reports
Requirements
specifications
Requirements Engineer
Ensure traceability
relationships are established
and v erifiable(Requirements Development::)
Formalise requirements,
ADCs, relationships and SAs
(Requirements Development::)
Prepare for the rev iew of
requirements, ADCs,
relationships and SAs(Requirements Development::)
Define purpose of this
dev elopment
(Requirements Development::)
Requirements Approv er
Rev iew the requirements,
ADCs, relationships and SAs
(Requirements Development::)
Approv e requirements, ADCs,
relationships and SAs
(Requirements Development::)
Requirements Manager
[Yes]
[No]
[No]
[Yes]
class Process Content View
Process
Requirements Planning Requirements Elicitation Requirements Dev elopment
class Information View - Requirements Elicitation
Requirements
Management Plan
Standards Project
Documentation
Checklists and aides
for elicitation
Source
Documentation
Requirements
Elicitation
Stakeholders
Requirements
Scenario
Context
Assumptions,
Dependencies and
Cav eats
Requirements Management
Processes, Guidance and
Examples Document
Requirements
Elicitation Output
Elicitation Record
Trace
Prev ious project
documentation
Repository
are a source of
Stores and enables management of
documents
guides elicitation of
defines methodology for eliciting
aids
is source of
constrains
aids elicitation of
Process List
Process Flow Process Information
© 2014
Process definition
13
Benefits
•Cross domain application
•Enables balance between generic process and specific technique.
•Relevant to people with differing levels of expertise.
•Consistent activities and information
© 2014
Requirements Analysis
15
Aim
● Ensure requirements have a home
● Understand the essence of the requirements
● To support the development of the whole set of requirements – not just individual statements.
● Understand the problem and whether it is being solved.
● Differentiate between different types of requirement (Stakeholder vs System)
Approach
● Provide relationships between requirements within a set
● Clearly separate requirements into contexts
© 2014
Where to start?
16
Administer the
Serv ice Plan
Receiv e
Modify
RetainMigrate between
Ability for RCO
to Interv ene
Continue serv ice
plan deliv ery
Amend
Long term
Passenger
Demand
Deliv er Serv ice
Plan
CurrentDeploy
Planned
Maintenance
P4
Deliv er the
Serv ice
Identify
cause/nature
Determine
duration
Determine
impact
Identify best
possible serv ice
P1+P2
Auto
Recov ery and
maintain Serv ice
Plan
P2
Auto/manual
Recov er Current
Serv ice Plan
Ability for RCO
to Interv ene
Modes of
operation
Direct RemoteUnattended
Passenger
Allow
communication
Prov ide info on
Serv ice Deliv ery
Prov ision of
routine
information
Changes in
serv ice
Automated
action
Understand
asset condition
External
Internal
Transport Planning
Schedule
Simulate
Railway States
P1
P2
P3
P4
Understand State
of Line
uc 5.1 Functionality
Administer the
Serv ice Plan
Operate 24/7
Receiv e
Modify
Retain
Migrate between
P3
Continue serv ice
plan deliv ery
Amend
Passenger
Demand
Deliv er Serv ice
Plan
Current
Deploy
Routine
Maintenance
P4
Operate the
Railway Serv ice
Identify
cause/nature
Determine
duration
Determine
impact
Identify best
possible serv ice
P1+P2
Recov ery and
maintain Serv ice
Plan
P2
Recov er Activ e
Serv ice Plan
RCO Interv ene
Modes of
operation
ManuallyRemotely
Automatically
Operate the
Station
Passenger (Happy
on the inside)
Regulate flow of
Passengers
Manage
Security
Collect fares
Physical trav el
pass
Automated
Allow
communication
Activ ely prov ide
information
Routine
Changes in
serv ice
Operate
maintenance
Minimum
track-side
assets
Plan
maintenance
Up to date
Accurate
Control
maintenance
Recov er after
fault (Fault
correction)
Av ailability
Status
Condition
Usage
Run-time
between giv en
points
Location
Monitor asset
characteristics
Continuously
reflect
av ailability
Continuously
reflect capacityChange in
planned
av ailability
Continuously
Monitor
Monitor loading
Monitor
behav iour
Monitor
env ironmental
conditions
Monitor security
Alarm and ev ent
logging??
Process data
Create
Trend
Absolute
Make
information
av ailable
Automated
action
Inform
DTR
Loading exceeds
pre-defined limits
Train
Station
Env ironmental
conditions exceed
pre-defined limits
Unusual/suspicious
behav iour identified
Alarm
Alert
Understand
asset condition
External
Internal
Transport Planning
Schedule
Simulate
Prov ide
Maintenance
Locations
Access to
mantainable
Asset
Capability
Capacity
Public Highway
Railway States
P1
P2
P3
P4
Understand State
of Railway
Asset
Characteristics
Ops Serv ice
Deliv ery
«constrain»
«include»
«constrain»
«constrain»
«include»
«include»
«include»
«include»
«constrain»
«constrain»
«include»
«include»
«constrain»
«include»
«include»
«constrain»
«constrain»
«constrain»
«constrain»
«constrain»
«include»
«constrain»
«include»
«include»
«include»
«include»«constrain»
«Constrain»
«constrain»
«include»
«include»
«constrain»
«include»
«include»
«include»
«include»
«include»
«constrain»
«include»
«include»
«Constrain»
«include»
«include»
«include»
«include»
«include»
«include»
«include»
«include»
«include»
«include»
«include»
«constrain»
«constrain»
«include»
«include»
«include»
«include»
«include»
«include»
«include»«include»
«Constrains»
«include»
«include»
«include»
«include»
«include»
«include»
«include»
«include»
«include»
«include»
«include»
«include»
«constrain»
«include»
«include»«include»«include»
«constrain»
«include»
Old Reqs - Pre SDR 1.3
Link to 5.11
Maintenance
Link to 5.11
Maintenance>
Minimum Ops
disruption
P3
Need to clarify
diff between
current and active
with RH
Emergency
comms
Staff outside of
DTP, Alien Railway
Statically
prov ide
Location of People
Links to schedules
and planing
service
Emergency
Serv ices
Informs future service
plan and scheduling of
future service plans
Service plans have an
element of recovery
built into them links to
performance
Predict Serv ice
leav ing P1 (and
inform)
Prev ent/Mitigate the
effects of anything
other than P1
Link to amend
service plan in
short term
Both condition
based
maintenance and
re-active
maintenance
Duty staff
Link to
org
Link to
reactive
maintenance
Dynamically
prov ide
Effect states
differently
change in planned
availabil ity may
not constrain
mode of operation Link to 5.11 Maintenance>
asset availabil ity
Note CGL is this the
"current" service plan?
If so, remove "Current"
use case.
Receiv e
feedback
«constrain»
«include»
«constrain»
«include»
«Constrain»
«include»
«include»
«include»
«include»«include»
«include»
«include»
«constrain»
«constrain»
«constrain»
«include»
«Constrain»
«include»
«include»
«include»
«Constrain»
«include»
«constrain»
«Constrain»
«include»
«include»
«constrain»
«include»
«include»
«include»
«include»
«include»
«include»
«include»
«include»
«include»
«include»
«include»
«constrain»
«include»
«include»
«constrain»
«constrain»
«include»
«include»
«constrain»
«Constrain»
«constrain»
«Constrain»
«include»
«include»
«include»
«include»
«constrain»
Identifying Complexity
© 2014
Comparing contexts
18
SystemsEngineer
«Stakeholder»
Audience
«Stakeholder»
Film-maker
«Stakeholder»
Safety Officer
«Stakeholder»Marketing
«Stakeholder»
Escapologist
«Stakeholder»
Assistant
«Stakeholder»
AnalyseContext
AnalyseSystem
Ensure Safetyof Equipment
Ensure Safety
PromoteSysML
PromoteServices
Create leads
Promote tools
Be interesting
Set-up
Get-out
Don't Die
Make PeopleSweat
Look Great
Escape
DemonstrateUsefulness of
Modelling
Show SystemsApproach
DemonstrateUsefulness of
Modelling
EngineerSystem
Ensure Safetyof People«include»«include»
«include»
«include»
«include»
«include»
«include»«include»
«include»«include»
«extend»«extend»
«extend»
«extend»
«constrain»
«constrain»...
«constrain»«constrain»
Safety Officer's Requirements Context
Marketing Requirements Context Escaplologist's Requirements Context
Systems Engineer's Requirements Context
© 2014
The Tail of the Brontosaurus
19
operate the railway
serv ice
comply with
standards
Standards
Regulation
LegislationManadatory
standards
Deliv er the serv ice
Admin Serv ice
Plan
Deliv er Current
Serv ice Plan
Recov er
Serv ice Plan
State of
Serv ice
ability for 24/7
Maintain Asset
Manage
Information Monitor Data
Process Data
Feedback
Information
Understnad
State of the
Line
Allow
Communication
Plan
Maintenance
Manage
Maintenance
Locations Control Assets
Asset
Maintenance
Regime
Minimum
Operations
Disruption
AAccess Assets
Policy
«include»
«include»
«include»
«include»
«constrain»
«constrain»
«include»
«constrain»
«include»«include»«include»
«include»
«include»
«include»
«include»
«include»
«include»
«include»
«include»
«include»
«include»«include»
«include»
«include»
«include»
Non- Functional
Requirement
Functional
Requirement
Constraint
relationship
© 2014
Requirements Analysis
20
Benefits
● Enables well structured requirement sets to be developed
● Enables visualisation of requirements including relationships between functional and non-functional.
● Model-based view validates text
● Improves communication and engagement with stakeholders
● Enables conflict resolution
● Enables levelling of requirements
© 2014
Architecture
22
Aim
● Facilitate development of and capture design information
● To answer specific stakeholder questions/issues/concerns, i.e. How do we migrate?
● Deliver facts aligned with fuzzy pictures
● Ensure it isn’t ‘just‘ another railway
● Understand boundaries and interfaces
● Ensure structure and function are consistent
Approach
● Deliver information in the best way for the stakeholder to understand.
● Provide multiple representations of information where appropriate.
● Ensure consistency between information.
© 2014
Many Views make lite work
23
Alien Railway
Group Serv ices
Comms Network
Utility
External
Gov ernance
Station
Infrastructure
(Fabric)
TenantsEmergency
Serv ices
Passenger
General public
(non passenger)
Local Conditions
Neighbour
Alien Ops
Alien Maintenance
Alien Asset
Org Internal
Gov ernanceRailway Line
Infrastructure
Command and control
Rolling Stock
Platform Edge
equipment
Station Equipment
Train
Depot
Civ il Infrastructure
Comms Infrastructure
Control System
Infrastructure
Cooling
Power Distribution
Track
«Interface»
Control - Train
resides in
communicates via
communicates via
heats
communicates viadefines kinematic envelope of
maybe in
controls
maybe in
communicates via
powers
monitors, runs on
operate the railway
serv ice
prov ide performanceOrganisation
Performance
Asset
Maintenance
Asset
Reliability
Function
Av ailabilityAsset
Av ailability Serv ice Target
comply with
standards
Standards
RegulationLegislation
Manadatory
standards
Deliv er the serv ice
Admin Serv ice
Plan
Deliv er Current
Serv ice Plan
Recov er
Serv ice Plan
operate/access
station
Operate Asset
State of
Serv ice
ability for 24/7
Maintain Asset
Manage
Information
Monitor Data
Process Data
Feedback
Information
Understnad
State of the
Line
Allow
Communication
Plan
Reactiv e
Planned Maintenance
LocationsControl of
Assets
Understand
Asset
Asset
Maintenance
Regime
Minimum
Operations
Disruption
AAccess Assets
Env ironmental
Performance
Serv ice
Targets
Capacity
Targets
Policy
«include»
«include»
«constrain»
«include»
«include» «include»«include»
«include»
«include»
«include»
«include»
«include»
«constrain»
«constrain»
«constrain»
«include»
«include»
«include»
«include»
«include»
«include»
«include»
«include»
«include»
«include»«include»«include»
«include»
«include»
«include»
«include»
«include»
«include»
«include»
«constrain»
«include»
«include»
«include»
«include»
«include»
par
[Instruct]
[Maintain Safety]
[Adhesion]
Control SystemTrainLocal Conditions Track
alt
Determine Train Movement Required()
move(effort, direction)
move(traction)
Brake(Brake)
Determines Instruction has been executed()
Determine Movement is safe()
calculate slip/slide()
calculate Adhesion(WSP)
Adhesion()
Adhesion()
System Context
Requirements
Interaction
Interfaces
Traceability
© 2014
Architecture
24
Benefits
● Enables confidence in design
● Facilitates focused technical discussion.
● Enables re-use of information
● Provides consistency
● Supports demonstration of performance
© 2014
V&V/Assurance
26
Aims
•Ensure all requirements are met
•Reduce manual application of traceability
•Increase consistency
Approach
•Provide rich traceability
•Integrate Requirements and Architecture
© 2014
Tracing distributed systems
27
Requirement
Minimise environmental
impacttype a)
Requirement
W10 structure gaugetype b)
Requirement
No impact piling near
Mr X’s housetype c)
Physical
OLE Production Unit GW/00Physical
OLE Production Unit GW/01
Physical
OLE Structure
GW/00/01
Physical
OLE Structure
GW/00/02
Physical
OLE Structure
GW/01/01
Each of these
links must be
independently
verified for full
technical
assurance
traces to
traces to
traces to
© 2014
Multi-level applicability of requirements
28
Requirement
Type a) requirement
All elementstraces to
Physical
T00 Generic design
element
Physical
T03 OLE Structure
Physical
GW/00/01 structure
is a
is a
Requirement
Type b) requirement
All elements of type
Requirement
Type c) requirement
location specific
traces to
traces to
© 2014
Inferred applicability
29
Physical
T03 OLE Structure
Physical
GW/00/01 structure
is a
Requirement
Type b) requirement
All elements of typetraces to
Inferred trace
Inference:
If ‘Signal Head’ traces to ‘Requirement 1’
and ‘colour light signal’ is a type of ‘Signal Head’
then a ‘colour light signal traces’ to ‘Requirement 1’
© 2014
V&V/Assurance
30
Benefit
•Integrates Architecture and Requirements
•Enables re-use and normalisation information
•Provides consistency of traceability and approach
•Delivery of information to conform with stakeholder need
© 2014
Information Modelling
32
Aim
● Understand the information required
● Understand the relationship between the information
● Understand how it all fits together
● Enable successful delivery to stakeholders.
Approach
● Organise information for the business
● Use the businesses terminology
© 2014
© Atkins 2014
Discipline View Set
Technical View
Asset Breakdown
View
Agent
Asset
Functional View
Functional Needs View
Functional View
Asset functionality
View
Technical View
Asset Migration
View
Technical View
Physical ViewInterface View
Shows relationships
betweenshows layout of
defines need for
defines functions of
considers transition to
considers transition to
What are the Views
The Context of a set of information
Defines the
hierarchy of
the elements.
Defines the relationships
between the elements as
pictures, tables and
matrices
Defines the requirements
of the element.
Shows what the element
does and the information
flow between elements.
33
© 2014
© Atkins 2014
What is the Information
Asset Functiontechnical
requirement
Interface
is performed by
relates to
defines need for
communicates
information to
The problem
the asset has
to solve
The element
in the system
The things the
element does
The way the
information is passed
34
Requirement
traceability
Requirement
Satisfaction
Functional
decomposition
Functional
allocation
Asset
decomposition Asset
Interaction
© 2014
Information Modelling
35
Benefit
● Enables consistent information definition
● Enables Impact analysis
● Assessment of information maturity
● Enables consistency of approach
● Brings together process, Architecture, Requirements and Assurance