“Great spirits have always encountered violent opposition from mediocre minds”
Albert Einstein Requirements Capture, Analysis & Specification experiences using SysML / UML
8th April 2009
Michelle Ellis MSc, BEng (Hons), MIET Aims
To share my experience of using UML / SysML in a Systems Engineering environment. Contents
• SysML / UML Definitions • A picture paints a thousand words • Modelling Abstractions • Reasons for Modelling • Overlap between UML/SysML • UML / SysML Diagrams and Categories • How we have used this so far • Building SE processes around the use of the language • Advantages & Disadvantages What is UML / SysML?
The UML is a general purpose modelling language that is intended for software intensive systems, however it has more recently been used to communicate any form of information not limited to software.
The SysML is actually based on the original UML but contains a set of additions.
SysML started in 2003 as a proposal from INCOSE to OMG – UML for Systems Engineering and then in April 2007 the OMG finalization task force recommended a final version having gone through several iterations over those 4 years.
Official Definitions, various introductions and tutorials are available on the OMG (Object Management Group) website:
www.omg.org Descriptions & Analogies that work for me
•A graphical language for modelling more or less what you like
•A bag of notation with a set of rules
•Not a methodology or process but a language!
•Groups of graphical notation which can be used to create views or abstractions of the real world.
•Just a means of communication. A picture paints a thousand words
Pissarro Prints - The Boulevard Montmartre at Night It is important to Model
Why Model? It allows us to identify complexity, aid understanding and improve communication
A Model is only a representation of reality and should not be confused with the real thing
A Model always includes: Abstraction Claudia Schiffer Simplification Assumptions
In order to model successfully a common language is required; i.e. the Unified Modelling Language Modelling Abstractions
Text Models such as written specifications and functional Any System can be considered at many different levels of decompositions abstraction
Level of WHAT WHOM WHERE WHEN HOW Abstraction
Logical
Operational
Physical
Mission Models Physical Structure Scenario Models Models Modes / States Physical Layout Models Models Thermal Models Etc Electrical / Electronic Models Etc SysML / UML – there is a relationship SysML & UML Diagrams
UML SysML Structural Diagrams: Structural Diagrams •Class Diagram •Package Diagram •Block Definition Diagram •Composite Structure Diagram •Package Diagram •Object Diagram •Internal Block Diagram •Component Diagram •Parametric Diagram •Deployment Diagram •Requirement Diagram
Behavioural Diagrams Behavioural Diagrams •State Machine Diagram •State Machine Diagram •Activity Diagram •Activity Diagram •Use Case Diagram •Use Case Diagram •Sequence Diagram •Sequence Diagram •Communication Diagram •Timing Diagram •Interaction Overview Diagram
Typical Customer Requirements Capture Activities SysML Requirements Diagram – illustrating sources of requirements for ERTMS
req Pre-Bid Phase - NR Mainline ERTMS Requirements Diagram
«requirement» European Directives
«requirement» Technical Specs for Interoperability
txt
«requirement» Annex A
«requirement» «requirement» «requirement» Mandatory Specifications Informative Specifications ENs/CENELEC Standards
«trace» «requirement» UK Rail IndustryYellow Book «requirement» «requirement» «requirement» «requirement» «requirement» Unisig SRS 2.3.0 Unisig FRSs Unisig FIS Unisig FFFIS Dimensioning & Engineering Rules «requirement» «requirement» Network Rail Strategic Business Plan 108 Changes
«deriveReqt»
«requirement» ERTMS EU Operational Rules
«trace»
«requirement» «requirement» Route Utilisation Strategies UK Customer Requirements «trace» «trace»
«requirement» Route Plans «trace»
«requirement» «requirement» «requirement» «requirement» «deriveReqt» UK Operational Rules RSSB Group Standards Cambrian Pilot Line National Functions
txt «refine» National Functions affecting UK: «trace» 1) Tilt Control of Train «requirement» (WestCoast Mainline) Network Rail Rule Book «trace» 2) Level Crossing Control
«requirement» DOORS Database - Customer Formal Requirements Statements «refine»
«requirement» «requirement» Operational Concepts / Changes from ORG Annex A (New Modules) Standards within Scope of Impact Assessment (ERTMS)
«requirement» ERTMS Users Handbook SysML Requirements Diagram used for communicating UK ERTMS Stakeholders
req Pre-Bid Phase - NR Mainline ERTMS Stakeholder Diagram refines «requirement» «requirement» «requirement» «Activity Diagram» Requirements Capture Activities Transport Scotland «trace»Scotish Executive Welsh Assembly
UK Stakeholders - Potential Sources of Requirements «requirement» «requirement» «requirement» «requirement» ERA UNISIG «trace» «trace» DFT «trace» EU Passenger & Freight Users «trace» «requirement» represented by: «requirement» ORR ERTMS Users Group «trace» «trace» «trace» «requirement» «trace» EWS
«requirement» «requirement» «trace» «requirement» «trace» HMRI «requirement» FOC «trace» Direct Rail Services «trace» TOC «trace» «requirement» «requirement» «trace» Fastline Passenger Focus «trace» «trace» «requirement» «trace» «trace» «requirement» «trace» «trace» Freightliner London Travel Watch? «trace» «requirement» «trace» «requirement» Network Rail First GBRf «requirement» «trace» Rail Freight Group (RFG) «requirement» Mendip Rail
«requirement» «trace» «requirement» «requirement» Railways Approvals Freight Transport Association (FTA) «trace» HSBC Rail UK Ltd
«trace»
«requirement» NEP
«trace» «requirement» «requirement» «requirement» «trace» ROSCOs CB Rail «trace» Royal Bank of Scotland (RBS)
«requirement» «trace» «trace» Route Planning Team «requirement» «trace» «trace» Angel Trains Ltd «requirement» «requirement» RIASIG ATOC «requirement» «requirement» «requirement» PorterBrook Leasing Abbey National ANSALDO
«requirement» «requirement» «requirement» CCS TOM RST «trace» «trace» «trace» «requirement» «requirement» «requirement» ETCS European Change Review Group RSSB «trace»Eng & Operational Standards Review Group «requirement» Eurotunnel Railways Network
«requirement» «requirement» «requirement» Operational Review Group Infrastructure Review Group Train Specification Review Group
«requirement» Reliability Steering Group
Back SysML Block Diagram used for communicating system boundaries
bdd [Package] Scope Diagram
Controller ETCS Onboard 1..* * * 1 1 1 «block» Track Worker * ERTMS Northern European Trackside Signalling 1 System
Technician 1 1
1..*
1
Signalling Engineer / Data Prep State of Railway SysML Block Diagram used for communicating ERTMS Candidate Architectures
bdd [Package] Candidate Physical System Architecture Simplified for External Viewing
* * Track Worker 1 ETCS Onboard 1 1 1 «block» 11«block» GSM-R State of Handheld Possession Terminal Railway 1 1
1 1 1..* «block» «block» «block» EuroBalise (Switchable) EuroBalise (Non-switchable) Interlocking 1..* 1..* «block» RBC (EURORADIO) «block» 1 1 1..* 1..* 1 Key Management Centre «block» *1 Lineside Electronic Unit 1 * *
1 1 1 1 1 «block» «block» Local Control Workstation CTC 1 Maintainer
1
1
Technician
1..*
Controller SysML or UML Activity Diagram used for communicating a operational procedure
Control System Controller / Signaller RBC ETCS Onboard Driver DMI
Switches on Cab
Enter Driver ID
Enter / Confirm Level
Cold movement detection to confirm valid position when cab has been powered down. Enter / Confirm Level 2 RBC ID and SOM Confirmation Message can be Initiation of a communication Initiation Of Comms Phone Number sent to the train in the case where the session position is valid. Currently specified in the SRS as message 43 SOM position Version of ETCS Language Level 0 report confirmed by the RBC. Config Data Rx & Compatible Configuration sent to Train
Session Established Session Established* Assuming Valid Ack receipt of Position Report Position or Train Process Start of Mission Position Report Accepted Provide SOM Position Report
Select Mode / Data Entry Receipt of Train Data Communicate Position Report Confirmation of invalid location rx from signaller
Shunting Non Leading Invalid Signaller tries to confirm location Shunting Mode Non Leading Mode Unknown from train describer or verbal Train Data Data Entry comms with the driver Process Train Data Send Train Data to RBC Location? Signaller Contacted by Driver Enter / Confirm Train Running Valid Number becomes unknown N Send Ack Train has Unknown location Y
N Issue OS MA from current location Enter/Confirm Adhesion Factor Requests OS MA to end of route
Train at Route Entry Point? Request MA Y N Select Train Data Set Train known to signaller? Signaller requests train deletion Terminate comms with train and delete associated data
Y Display on Control Centre OS MA Received Schematic Set a Route Is sue FS M A Y - New Data Req Change / Enter New Data
Signaller Confirms Location with Observe any Lineside N Driver Set a Route Indication
Signaller associates train with Y Confirm Train Data route? N Available on schematic when selected, drop Signaller Requests SR Authority Issue SR Authority without a down list:Train Running No., Train Reporting balise list No., Driver ID, Mode of Operation, Selection of FS MA Received having observed train emergency stop. any lineside indication
Select Start
Perhaps displayed through a general Issue SR Authority with Balise list purpose screen as without a route set the train location cannot be displayed on the schematic view. Perhaps with an option of changing the default distance to travel.
Requirement - reduce the potential for human error and workload during data entry. Fixed Data Sets for a number of train categories. Up to 10 possible sets for a particular cab. Adjustable parameters such as maximum speed and brake rate. For freight trains and loco hauled passenger trains - 18 sets of train data as the number of configurations is potentially much greater. Data Set will include: Train category (type of rolling stock), Train length, Deceleration data (braking parameters), Loading...
SR Authority Received without SR Authorisation Received with Balise List Balise List
Complete Written Order and Confirm: Position of train and distance can travel Complete Written Order and Confirm: Position of train and distance can travel
Process Request to Proceed from Driver
Complete Written Order and Confirm: Position of train and distance can travel Train passes over next balise group
Y Signaller will dictate so that the driver Send Train Location Report can complete an identical copy to ensure they reach a common Control System could: provide electronic versions of the Balise in list provided? understanding. written orders completed 'on-line'. Capability to associate written orders with routes (reminder of N authority given). Warnings so that signaller cannot set a route which conflicts with an existing written order.
Issue FS MA (assuming train at Trip Train route entry point)
FS MA RBC ETCS Onboard Driver
RBC Train awakens with a valid position in a level 2 area Send OS MA
Rx OS MA Route Entry Point
Ack OS Mode Change
OS FS
Process OS MA providing speed Observe OS distance and speed and distance data to driver
N Y Send FS MA Train at detection boundary?
Process and automatically Observe FS Mode Change change to FS Mode
Back Extract of Process & Language usage
Class Diagram showing Customer / User Requirements the structural relationships between Use Case Diagrams to give a Activity sources of requirements. behavioural view of the Diagram used Useful for understanding requirements, showing actors, to explore baselines system boundary, key functions, behavioural constraints and specialisations abstraction
Detailed Analysis Analyse the Use Case Diagram Eliciting of existing contents of each Requirements Requirements with stakeholder standard / Synthesis Customer requirements Specification
System Requirements Detailed Scenario Relate scenarios Analysis together
Sequence Diagrams – show Interaction Overview detailed behaviour wrt time using Diagram lifelines. Also used to customer requirements and moving into System Requirements to an extent Extract of Process & Language usage
1. Capture into DOORS / Analyse
2. Capture 3. Capture 4. Capture 5. Performance Scope Function Constraints Requirements
Use Case External ‘Actors’ Use Case Constraint Object Class Diagram OSD disagram Sequence Diagrams
6. State Analysis
State Transition Diagrams Not OK
OK Not OK
7. Review OK Requirements HL1a System Process Stage - Capture Scope Output Graphic - Class/Scope Diagram
Train Controller
Process Stage – Decompose System Implementation/ RBC CS IL PC Bridge Data Prep (Functional and Physical) Design HL1b Output Graphic – Class Diagram
Requirements HL2a Process Stage - RBC CS Capture Scope Output Graphic - Data Prep Class/Scope Diagram Data Prep
CS IL RBC PC Bridge IL PC Bridge
Product Design Specification
Implementation / Process Stage – Decompose System Design HL2b (Functional and Physical) Output Graphic – Class Diagram
MPM DPM SIOM TBS
Requirements Process Stage - Capture Scope RBC Most useful diagrams for me – User/Customer Requirements
• Activity Diagram • Use Case Diagram • Block Definition Diagram • Requirements Diagram
Whereas my colleagues who are defining System and Subsystem Requirements and Design prefer:
• Class • Sequence Diagram (for specifying requirements) • Activity Diagram (for design analysis) Experience of Activity Diagrams
• Communicates an overview of activities, the order in which they happen with responsibilities assigned to someone or something • Easy to Use • Look Familiar • Overview of Activities • Areas for discussions can be seen in context • Show a medium level of behavioural abstraction based on information flow rather than states
Example - for SOM we were able to much more easily identify areas for discussion: – Train Data Entry – Use of OS Mode when not at REP – Uncertainties surrounding the use of Lineside indications – Use of SR Mode for trains with an unknown location Experience of Activity Diagrams
Pitfalls:
• The rules associated with the language state that activity diagrams should represent a mission which covers all possible scenarios at a high level. If this is not possible then ideally individual sequence diagrams should be used to show each scenario and an (interaction overview diagram or packages) should be provided to show grouping and interaction. • Rules relating to some notation can be a bit of a minefield; i.e. use of control forks (only 1 path in and 1 path out) and merge notation. Different specifications concerning notation and semantics are available on the OMG website. However some of the tools will run consistency checks • Found that when creating activity diagrams in particular it’s best to use simple drawing packages like Visio for 1st couple of iterations – not particularly easy in some of the supporting tools to rearrange the swim lanes Experience of Use Cases
• Allowed me to communicate the relationships between actions and the functional requirements of the system at the highest level of abstract behaviour • Useful for both context and requirements modelling • Useful for bringing together disparate sources of requirements
Pitfalls • Actually quite time consuming to get right even though they appear very simple • Need to ensure that the version of the tool your using supports the version of the language you are using; i.e. the constrains relationship • Use Cases should be verbs SRS 2.3.0d SoM
Degraded Situation Enter Data
«include» Driver
«<
«include» RBC ID/phone «include» number «include» «include» «<
ETCS Communicate ERTMS/ETCS Onboard Valid Data Level Communicate Movement Authority Communicate Radio Session Status
RBC Understand validity status of data
Signaller Experience of Block Definition Diagrams
• To a Systems Engineer this looks and feels more familiar than class diagrams but once you become more used to using the language you realise that this diagram is just a specialised Class Diagram • Useful for communicating physical candidate architectures • Found beneficial for analysing boundaries at subsystem level too and communicating uncertainties with customers • Advantage over class diagrams is that actors can be used to indicate someone or something interacting with the system. Strictly speaking Class Diagrams do not include actors although some of the tools allow this
Pitfalls
• Have not found any real disadvantages. Experience of Requirements Diagrams
• Easy to construct and obtain a structural view of requirements • Can map them on to logical and physical abstractions (other diagrams) then produce traceability reports (more related to tool functionality though)
Pitfalls
• If there are hundreds of requirements then diagrams end up being huge. General Advantages and Disadvantages
Advantages • Graphical Representations of requirements are less ambiguous • Synthesize disparate requirements into a coherent picture • Easier to communicate context • Relative ease when writing test specifications • Traceability between systems and software requirements become easier • Rather than having a disparate set of diagrams representing your requirements and design you are able to build up a model of many abstractions General Advantages and Disadvantages
Disadvantages
• Tools don’t always seem to support all aspects of the language. Therefore need to keep the tool versions aligned with the language version which is difficult when you are supporting use across business units, departments and with suppliers. • Not everyone is literate in the languages so businesses need to develop a migration strategy for dealing with the language and associated tools across the process. Which in itself can cause its own problems. • Configuration Management & Control have been challenging • Document Generation from the tools have been problematic • Requires a lot of investment in terms of the language and associated tools • Need to ensure that individual models within the tools don’t become too large