ibm innovate 2011 system engineering in railways safety ... · pdf filesystem engineering in...

IBM Innovate 2011 System Engineering in Railways Safety Critical Systems Francisco Lozano ERTMS CoE Programme Manager Invensys Rail Dimetronic

2 © 2011 IBM Corporation

El principal evento sobre innovación en software

1 Preface



Preface – Who am I?

Francisco Lozano Ovejero

IRG ERTMS Centre of Excellence –

Programme Manager

14 years of experience in Signalling

8 years of experience in ERTMS



Preface – What is Invensys?



Preface –

What is Invensys Rail Dimetronic? Invensys Rail Dimetronic

• The leading Railway Signalling company in Spain and Portugal.

• Headquarters in Madrid.

• References in Romania, China, Philippines, Algeria, Australia,

Argentina, Turkey, Brazil, Venezuela, Taiwan, Singapore and Chile.

• 700 employees.

• Turnover €250m.

Our job

The design, manufacture, supply, installation, testing, commissioning and

maintenance of Signalling and Automatic Train Control Systems that will

allow our customers to manage railway traffic SAFELY and efficiently.

Most of our equipments are embedded real time safety critical



2 Basic Definitions



What is System Engineering? (I)

According to INCOSE (International Council on System Engineering,

www.incose.org):

Systems Engineering is an interdisciplinary approach and means to

enable the realization of successful systems. It focuses on defining

customer needs and required functionality early in the development

cycle, documenting requirements, then proceeding with design synthesis

and system validation while considering the complete problem:

– Operations

– Cost & Schedule

– Performance

– Training & Support

– Test

– Disposal

– Manufacturing

http://www.incose.org/



What is System Engineering? (II)

Systems Engineering integrates all the disciplines and specialty groups into a team effort forming a structured development process that proceeds from concept to production to operation. Systems Engineering considers both the business and the technical needs of all customers with the goal of providing a quality product that meets the user needs.



Railways Market (IR perspective)

Two main markets in Safety Critical Systems for Railways:

– Mass Transit (metropolitan applications)

– Main Line (Commuter Lines, Intercity, High Speed Lines)

Two similar systems but different technologies:

– CBTC for Mass Transit: Different providers use similar

concepts of operation but incompatible technologies

– ERTMS for Main Line: Different providers must comply

with a common specification (TSI) ensuring different

equipments are able to operate together (a certification of

interoperability generated by an independent body has to

be obtained)



The acronym of ERTMS corresponds to “European Railway Traffic

Management System”, i.e. an standard for handling trains across Europe.

Before ERTMS, each Railways Administration had one or more ATP systems

available in its network.

The rationale behind ERTMS is to handle in a unique and uniform way all

Railways Traffic through Europe. ERTMS emerged under the idea of allowing

trains transit throughout Europe in an easy and safe way by using a common

ATP system.

Usually the ATP systems were different from one country to another that

made difficult a safe train transit throughout different countries and involved

high equipment costs.

The ERTMS System is definitively supported by the European Union on

1993 when the TSI (Technical Specification for Interoperability) is generated

and approved.

What is ERTMS? (I)



Automatic Train Protection system (ATP) specified by all railways

company (UNISIG)

Consisting of : - Onboard System

- Trackside System

It uses the existing trackside infrastructure

(interlocking and associated elements)

The major goals to achieve are:

- Interoperability

- Scalability

- Safety

Extremely concise description of

ERTMS System Characteristics

What is ERTMS? (II)



The acronym of CBTC corresponds to “Communications Based Train

Control”

What is CBTC? (I)

Is a continuous system for automatic train control

Continuous, bidirectional and of high capacity data communication Track-

Train

Each train knows its position within the line using high resolution

processes to determine its position independently of the track circuit

occupancy.



Extremely concise description of

CBTC System Characteristics

What is CBTC? (II)

Uses a digital radio subsystem based on “Spread Spectrum”

transmission techniques

Uses standard protocols Ethernet, Profibus, TCN and IP

Continuous and bidirectional transmission Track to Train and

vice versa through the radio link of:

• Movement authorities from track to train

•Train position from train to track

•Track profile characteristics from track to train



Generic: This term is used for those systems/product designed to be used in

several installations. Those are developed by R&D and can be considered as

for general purpose for a specific type of applications.

Examples of Generic equipments are EVC (European Vital Computer – On

board equipment) for ERTMS or BP (Block Proccessor) for CBTC

Specific: This term is used for those generic systems/products configured

and/or customised for a specific contract application

Generic vs Specific

Examples of Specific equipments are EVC (European Vital Computer – On

board equipment) used in 446 locomotives or or BP (Block Proccessor) for

CBTC in Madrid Metro



3 System Engineering applied to Railways Environment



System Engineering applied to Railways

Like in many other industries, System Engineering is applied

to Railways

• Major driver for any Railways development is Safety

How railways industry ensures Safety in any development or

application?

• Following CENELEC (European Committee for

Electrotechnical Standardization) standards see

(www.cenelec.eu )

• One of the key factors to ensure the Safety of each

component and the overall system is by dedicating a

completely independent group specifically for Safety

Assessment

http://www.cenelec.eu/



System Engineering and CENELEC standards

Main used CENELEC standards:

• EN50126: Railway applications - The specification and

demonstration of Reliability, Availability, Maintainability and Safety

(RAMS)

• EN50128: Railway applications - Communication, signalling and

processing systems - Software for railway control and protection

systems

• EN50129: Railway applications - Communication, signalling and

processing systems - Safety related electronic systems for

signalling

Three different types of Safety developments / Five different Safety

Integrity Levels:

• Safety Critical SIL 4

• Safety Related SIL2

• Non – safety SIL0

Higher SIL3

SIL1 (SIL: Safety Integrity Level)

Lower



All projects follow the “V” project lifecycle as

required by CENELEC 50126 standard

(V for Verification and Validation):

The «V» cycle in CENELEC EN50126

Verification: The process of evaluating to determine whether

the products of a given development phase satisfy the conditions imposed

at the start of that phase.

In other words, verification is ensuring that the product has been built

according to the requirements and design specifications.

Validation: The process of evaluating during or at the end of the development

process to determine whether the equipment/system satisfies specified

requirements.

In other words, validation ensures that the product actually meets

the user's needs, and that the specifications were correct in the first place.



System Engineering and «V» cycle

Such rigor ensures:

- nothing is done unnecessarily

- everything that is necessary is accomplished.

- Traceability must be ensured from requirements to validation: - All design elements and acceptance tests are traced to one or

more system requirements - every requirement must be addressed by at least one design

element and acceptance test.

The process emphasizes requirements-driven design and testing

Disposal

Decommissioning

Eventually disposal (including procedures)

Maintenance

Operation

Eventually system upgrades if required

Guarantee of providing long term operation and maintenance (preventive and corrective) including appropriate tools/processes

System Acceptance

Support to System Acceptance: Customer Notified Bodies

System Validation

Validation

Measuring of system effectiveness

Check of System Behavior against System Requirements

Installation

Generation of rigorous acceptance testing of the implemented system to ensure it meets the stated requirements (system verification)

Manufacturing

Generation of manufacturing documentation Manufacturing

Design & Implementation

Generation of the detailed system design Perform implementation

Apportionment of System

Requirements

Apportionment of System Requirement defining System Architecture

System Requirements

Identification of testable system requirements

Risk Analysis

Detailed Risk Analysis including: Preliminary Hazard Analysis PHA Hazard Log through the whole project lifecycle

System Definition &

Application Conditions

Concept of operation

Definition of a concept of operation describing user needs and the operating environment Early, effective and comprehensive identification of customer requirements

The Systems Engineering Process requires: • The Systems Engineering Process improves the cost effectiveness of

complex systems over the entire life of the system, from concept of operation

to disposal.



System Engineering process within a company - Invensys Rail Dimetronic example (I)

Involves several departments

Generic Developments are performed by R&D Department

Once a line of products or a product exists, the process is started by Tendering

Department (Solution Architects):

– They study customer requirements and produce concept of operation

and system requirements

Continued by Engineering Department (Application System-Design Engineers):

– They produce a detailed system design

– Consider all functional details and phases

– Based on clear definition of roles but enough flexibility to cover overlaps

It requires strong communication between different departments

Expertise of required stakeholders to find out if modifications are needed to

existing products/systems that may involve R&D modifications



System Engineering process within a company - Invensys Rail Dimetronic example (II) Involved Departments

The Process

(Market requirements capture for new Generic Systems not included) Departments, People involved

R&D

Department Tendering

Department Application Engineering

Department

Type A: New customer requirements (completely new or variations to existing ones)

Type B: Application of existing products / systems / subsystems

Always

Support,

only if required

Process

Generic System

Engineering (*)

Tender A (**)

Tender System

Engineering

Tender B (*)

Tender System

Engineering

Support,

only if required

Contract A (**)

Tender System

Engineering

Contract B (*)

Tender System

Engineering

Always Always

Type A: Always (**)

Type B: Support,

if required

Always

Type A: Always (**)

Type B: Support,

if required



Products requirements capture within Railways Market

In CBTC • In ERTMS Customer Requirements

Operational Rules 2Operational Rules 1

Maintenance

Performances

Hazards Mitigations & Safety constraints

Disposal

Storage

Power supply &consumption

Security

Environmental & Operating Conditions

(inc. Seal)

CommunicationsEMC & Vibration

BP Requirements

Interfaces

Data Preparation

SW Plataform

Maintenance System

Control System

Juridical Storage

Interlocking

Key Management Centre

Train Comms

FunctionalApplication

Operational Scenarios

HardwareExperience

Safety Hazard Analysis &

Hazard Log

System Requirements Specification

Current Platform Architecture

Experience

International Standandards

State of the Art

Customer Requirements

Operational Rules 2Operational Rules 1

Maintenance

Performances

Hazards Mitigations & Safety constraints

Disposal

Storage

Power supply &consumption

Security

Environmental & Operating Conditions

(inc. Seal)

CommunicationsEMC & Vibration

RBC Requirements

TSI

Interfaces

SW Plataform

Maintenance System

Control System

Juridical Storage

Interlocking

Key Management Centre

Train Comms

FunctionalApplication

Operational Scenarios

HardwareExperience

Safety Hazard Analysis &

Hazard Log

Data Preparation

Current Platform Architecture

Experience

International Standandards

State of the Art



System Engineering cycle for a generic product (R&D) and used tools

Module tests

System Acceptance /

Certification (Notified Body)

System Validation

Validation

Implementation

SW/SW integration tests Analysis & Design

Apportionment of System

Requirements

System Requirements

Risk Analysis

System Definition &

Application Conditions

Concept of operation

DOORS

RPE

Hazard Log

Rhapsody Synergy

CHANGE

HW/SW integration tests

System integration tests



Keys for an effective System Engineering in Railways Market (I)

Correct understanding of customer requirements at early stages of the

process avoid problems at latest stages. Generation of Operational

Scenarios is extremely useful

Definition of clear, complete and accurate interfaces requires the inputs

of all involved stakeholders. Two different levels :

FIS: Functional Interface Specification

FFFIS: Form Fit Functional Specification

Successful integration of all involved subsystems depends mostly on

the appropriate interfaces definition and in the generation of a complete

set of integration tests



Keys for an effective System Engineering in Railways Market (II)

Traceability from requirements to validation is crucial to

ensure that the solution is complete. A tool like DOORS is

essential

The early involvement of Independent Safety Assessors

avoid difficulties at latest stages.

If necessary to demonstrate the interoperability of

components (like in ERTMS) the use of DOORS simplify this

demonstration to Notified Body

A coherent set of integrated tools simplify the process



www.ibm.com/software/rational

www.dimetronic.com

http://www.ibm.com/software/rational

http://www.invensys.com/



© Copyright IBM Corporation 2011. All rights reserved. The information contained in these materials is provided for informational purposes only, and is provided AS IS without warranty of any kind, express or implied. IBM shall not be responsible for any damages arising out of the use of, or otherwise related to, these materials. Nothing contained in these materials is intended to, nor shall have the effect of, creating any warranties or representations from IBM or its suppliers or licensors, or altering the terms and conditions of the applicable license agreement governing the use of IBM software. References in these materials to IBM products, programs, or services do not imply that they will be available in all countries in which IBM operates. Product release dates and/or capabilities referenced in these materials may change at any time at IBM’s sole discretion based on market opportunities or other factors, and are not intended to be a commitment to future product or feature availability in any way. IBM, the IBM logo, Rational, the Rational logo, Telelogic, the Telelogic logo, and other IBM products and services are trademarks of the International Business Machines Corporation, in the United States, other countries or both. Other company, product, or service names may be trademarks or service marks of others.

www.ibm.com/software/rational

ibm innovate 2011 system engineering in railways safety ... · pdf filesystem engineering in...

Documents