04 workshop presentation merge

8/13/2019 04 Workshop Presentation Merge

http://slidepdf.com/reader/full/04-workshop-presentation-merge 1/44

Dependable Technologies For Critical Systems© 2011 Critical Software

Railway Certification and RAM Calculations

CSW Workshop on Dependability and Certification,

Coimbra, Portugal, September 28th-29th, 2011



2

© 2 0 1 1 C r i t i c a

l S o

f t w a r e

S . A .

Contents

Railway CertificationART

SafetyPART 2

RAMART 3



DependableTechnologies

For CriticalSystems

PART 1– Railway Certification



4

© 2 0 1 1 C r i t i c a

l S o

f t w a r e

S . A .

Railway Certification Topics

IEC 61508 - Functional Safety

Safety Integrity Levels

CENELEC Standards – EN50126/8/9

EN50126 Lifecycle

Safety Cases Organisation

Organisation Independency



5

© 2 0 1 1 C r i t i c a

l S o

f t w a r e

S . A .

IEC 61508Functional Safety



6

© 2 0 1 1 C r i t i c a

l S o

f t w a r e

S . A .

IEC 61508Safety Integrity Level– Tolerable Hazard Rate

SIL Tolerable Hazard Rate4 10 -9 <= THR < 10 -8

3 10 -8 <= THR < 10 -7

2 10 -7 <= THR < 10 -6

1 10-6

<= THR < 10-5



7

© 2 0 1 1 C r i t i c a

l S o

f t w a r e

S . A .

CENELEC StandardsEN50126/8/9

EN 50126Railway applications - Specification

and demonstration of reliability,availability, maintainability and

safety (RAMS)

EN 50128Railway applications -

Communications, signalling andprocessing systems -

Software for railway control andprotection systems

EN 50129Railway applications -

Communication, signalling andprocessing

systems - Safety related electronicsystems for signalling



8

© 2 0 1 1 C r i t i c a

l S o

f t w a r e

S . A .

EN50126 Lifecycle

Phase 1: Concept

Phase 2: System Definition

Phase 3: Risk Analysis

Phase 4: System Requirements

Phase 5: Apportionment ofSystem Requirements

Phase 6: Design andImplementation

Phase 8: Installation

Phase 9: System Validation

Phase 10: System acceptance

Phase 11:

Operation andMaintenance

Phase 7: Manufacture

Phase 12:

PerformanceMonitoring

Phase 13:

Modificationand Retrofit

Phase 14:De-commissioning

and Disposal

NewLifecycle



9

© 2 0 1 1 C r i t i c a

l S o

f t w a r e

S . A .

EN50126 LifecycleGPSC and GASC

Phase 1: Concept

Phase 2: System Definition

Phase 3: Risk Analysis

Phase 4: System Requirements

Phase 5: Apportionment ofSystem Requirements

Phase 6: Design andImplementation

Phase 7: Manufacture

Generic ProductSafety Case

Generic ApplicationSafety Case



1 0

© 2 0 1 1 C r i t i c a

l S o

f t w a r e

S . A .

EN50126 LifecycleSASC

Phase 8: Installation

Phase 9: System Validation

Phase 10: System acceptance

Phase 11:Operation andMaintenance

Phase 12:PerformanceMonitoring

Phase 13:Modificationand Retrofit

Phase 14:De-commissioning

and Disposal

NewLifecycle

Specific Application

Safety Case



1 1

© 2 0 1 1 C r i t i c a

l S o

f t w a r e

S . A .

Safety Cases OrganisationGPSC, GASC and SASC

GenericProduct

Generic Application



GenericApplicationSafety Case

SystemRequirementsSpecification



SafetyRequirementsSpecification




Safety CaseApplication

Design

PhysicalImplementati

on

Safety Assessment

Report

Safety Assessment

Report

Safety

AssessmentReport



1 2

© 2 0 1 1 C r i t i c a

l S o

f t w a r e

S . A .

Safety Cases

The HW boards composing a module and the “base SW”that runs on the boards of the module represent ageneric product.

The “base SW” is intended as the part of the SW thatdoesn’t change from customer to customer and thereforenormally includes the OS, the drivers, and the base SWfunctionalities.

GENERIC PRODUCT




1 3

© 2 0 1 1 C r i t i c a

l S o

f t w a r e

S . A .

Safety Cases

The generic application changes, typically, from customer tocustomer. It is defined by a set of HW modules combination(minimum and maximum number of a module, types ofmodules interconnection etc.) and by an application SW that

specialize each module behaviour for a customer.The generic application is normally implemented byapplication data.

GENERIC APPLICATION

GenericApplicationSafety Case



1 4

© 2 0 1 1 C r i t i c a

l S o

f t w a r e

S . A .

Safety Cases

The specific application specializes a generic applicationfor a specific usage (typically a single train between allthe trains of a customer fleet). This means that the

generic application is configurable and that the specificapplication represents a specific configuration of it.

An object of the specific application configuration levelcan be a voltage level of an input, a specific behavior of

the logic for a particular train, etc…

SPECIFIC APPLICATION

Specific ApplicationSafety Case

ApplicationDesign

PhysicalImplementati

on



1 5

© 2 0 1 1 C r i t i c a

l S o

f t w a r e

S . A .

Organisation Independency

ProjectManager

Dev.Team

Ver.Team

Val.Team

ProjectManager

Dev.Team

Val.Team

Ver.Team

Assr

Assr

SIL 3 &SIL 4




For CriticalSystems

PART 2– Safety



1 7

© 2 0 1 1 C r i t i c a

l S o

f t w a r e

S . A .

Safety Topics

Preliminary Hazard Analysis / Risk Analysis

Hazard Analysis

Hazard Log

Safety Case

Relation with other Safety Cases



1 8

© 2 0 1 1 C r i t i c a

l S o

f t w a r e

S . A .

Preliminary Hazard Analysis

Hazard Identification

Hazard Causes Identification

Hazard Consequences

Hazard Initial Risk Evaluation

Hazard Mitigation Recommendations

Hazard Final Risk Evaluation



1 9

© 2 0 1 1 C r i t i c a

l S o

f t w a r e

S . A .


SystemContext

ApplicationDomain

PastExperience

SystemHazards



2 0

© 2 0 1 1 C r i t i c a

l S o

f t w a r e

S . A .


Example of hazard consequences in the railway domain:

Collision

Derailment

Casualties

Injuries



2 1

© 2 0 1 1 C r i t i c a

l S o

f t w a r e

S . A .

Risk Analysis

System Analysis Hazard IdentificationHazard

ConsequenceInitial RiskEvaluation Mitigation Actions

Final RiskEvaluation

Risk Analysis Process

Check HazardFrequency

Make QualitativeRisk Evaluation

Verify HazardSeverity Risk Value

Risk Quantification Process



2 2

© 2 0 1 1 C r i t i c a

l S o

f t w a r e

S . A .

Risk Analysis

Risk Evaluation Matrix

Frequency Risk Level

Frequent Undesirable Intolerable Intolerable Intolerable

Probable Tolerable Undesirable Intolerable Intolerable

Occasional Tolerable Undesirable Undesirable Intolerable

Remote Negligible Tolerable Undesirable Undesirable

Improbable Negligible Negligible Tolerable Tolerable

Incredible Negligible Negligible Negligible Negligible

Insignificant Marginal Critical Catastrophic

Severity



2 3

© 2 0 1 1 C r i t i c a

l S o

f t w a r e

S . A .

Hazard Analysis

Hazard Analysis Process

Preparation

· Analyse all Inputs;· Define Risk Analysis Methodoly;· Define Safety Criteria· Define Hazard Analysis

Properties.

Input

· System and InterfaceRequirements;

· Architecture Specification;· Preliminary Hazards Analysis;· Top level system activities.

Output

· Hazard Log;· System Safety Requirements;· Safety Exported Constraints;· Functional and Physical SIL

Allocation.

Execution

· Identify all foreseen hazards;· Identify causes and consequences

of each hazard;· Evaluate initial risk (frequency and

severity) of each hazard;· Define mitigations (both preventive

and protective) for each hazard;· Define external costumer

recomendations;· Evaluate final risk when mitigations

are applied

ArchitectureSpecification

System andInterface

Requirements

Preliminary Analysis

IdentifiedHazards

Hazard Analysis

Top LevelSystem

Activities



2 4

© 2 0 1 1 C r i t i c a

l S o

f t w a r e

S . A .

Hazard LogProperty Description

ID-xxx A running number starting from 1

System Activity Activity to support the analysis of this hazard.

Architecture Item Sub-system where the hazard was identified

Function Name Function where the hazard was identified

Component Name Component where the hazard was identified

System State System state where the hazard was identified

Hazard Description Hazard Description

Hazard Cause Cause of Hazard

Hazard Effect Effects of the hazard in the system

Direct Consequence Description of the direct consequence of this hazard in the environment.

Frequency Frequency of the hazard occurrence

Severity Severity of the hazard

Risk Evaluation level Risk evaluation Level

Preventive Countermeasure Preventive Countermeasure

Protective Countermeasure Protective CountermeasureMitigated Consequence Description of the consequence of this hazard in the environment after applying the mitigation action.

Customer Recommendations Recommendations for the customer. Need to be transmitted to customer

Final Frequency Final Frequency of the hazard occurrence

Final Severity Final Severity of the hazard

Final Risk Evaluation Level Final Risk Evaluation Level

Application Conditions Application conditions code for the correct usage of the system in terms of safety.

Safety Requirement related Code FDT3_RS_SR_xxx : Code of Safety Requirement related to Hazard.Hazard Status Status of the hazard.



2 5

© 2 0 1 1 C r i t i c a

l S o

f t w a r e

S . A .

Safety Case

Generic Product Safety Case

Part 6:Conclusions

Part 5:Related Safety

Cases

Part 4:Technical Safety

Report

Part 3:Safety

ManagementReport

Part 2:Quality

ManagementReport

Part 1:Definition of the

System

Part 4:Technical Safety Report

Section 6:Safety

QualificationTests

Section 5:Safety-related ApplicationConditions

Section 4:Operation with

ExternalInfluences

Section 3:Effects of Faults

Section 1:Introduction

Section 2: Assurance of

CorrectOperation



2 6

© 2 0 1 1 C r i t i c a

l S o

f t w a r e

S . A .

Relation with other Safety Cases

Component 1GPSC

Product 1GPSC

Component 2GPSC

Component 3GPSC




For CriticalSystems

PART 3– RAM



2 8

© 2 0 1 1 C r i t i c a

l S o

f t w a r e

S . A .

RAM Topics

Dependability Concepts

RAM Process

RAM Activities

Qualitative Analysis

FMEA, FTA

Quantitative Analysis

Software Reliability



2 9

© 2 0 1 1 C r i t i c a

l S o

f t w a r e

S . A .


ReliabilityProbability that an item can perform a required function undergiven conditions for a given time interval (t 1 , t 2 ).

AvailabilityAbility of a product to be in a state to perform a required functionunder given conditions at a given instant of time or over a giventime interval, assuming that the required external resources areprovided.

MaintainabilityProbability that a given active maintenance action, for an itemunder given conditions of use can be carried out within a statedtime interval when the maintenance is performed under statedconditions and using stated procedures and resources.

EN50126



3 0

© 2 0 1 1 C r i t i c a

l S o

f t w a r e

S . A .


System A System B

MTTF: Mean Time To Failure

MTBF: Mean Time Between Failures

MDT: Mean Down Time

MTW: Mean Time Waiting

MTTR: Mean Time To Repair

MDT = MTW + MTTR

MTBF = MTTF + MDT



3 2

© 2 0 1 1 C r i t i c a

l S o

f t w a r e

S . A .

RAM Activities

Preliminary RAM Analysis

Reliability Apportionement & Prediction

Detailed RAM Analysis


Quantitative Analysis

FMEA/FMECA

FTA

RBD

FA

CCA

HSIA, …



3 3

© 2 0 1 1 C r i t i c a

l S o

f t w a r e

S . A .

Back to Basics

Failure Mode:

Cause (Fault)

Local Effect (Error)

End Effect (Failure)

Fault -> Error -> Failure

Fault -> Detection -> Negation -> Restore

All errors must be properly handled (detected and mitigated)

FMEA/FMECA, FTA, CCA, HSIA are all different techniques for assisting theidentification of all system failures, effects and combinations/propagations.




3 4

© 2 0 1 1 C r i t i c a

l S o

f t w a r e

S . A .

FMECA TableFailure Modes, Effects, and Criticality Analysis

Field Name

FMEA ID

Trace from

Function

Generic failure modeFailure Mode

Failure Cause

Local Effects

Propagates to

End Effects

Impact Type

Severity

Probability of Ocurrence

Method of Detection

Compensating Provisions

Mitigated Severity

Mitigated Probability

Notes



3 9

© 2 0 1 1 C r i t i c a

l S o

f t w a r e

S . A .


RAM calculations tipically consider only HW failure rates;

In SW failures are systematic;

Software does not wear out or break;

Software failures result of errors in the software;

This does not necessarily imply that a software functioncontaining implementation errors will fail every time it is called!

The error may not reveal every time the function is called.

There are no absolute answers for the classification ofsoftware reliability



4 0

© 2 0 1 1 C r i t i c a

l S o

f t w a r e

S . A .


To prove the absence of faults in reasonably complexsoftware is a tremendous task, if not impossible.

To avoid software errors, EN 50128 provides a set ofdevelopment guidelines and V&V procedures that, for thehighest integrity levels, are very demanding.

Accordance with these procedures allows an extremelevel of confidence in the SW implementationcorrectness.



4 1

© 2 0 1 1 C r i t i c a

l S o

f t w a r e

S . A .

SW Failure Probability

Classification alternatives:

0 / 1

No value. Only Qualitative Analysis.

Evaluate the probability of failure excluding software causes from thecalculation and present this value together with a detailed analysis of SWfailures impact

Mapped to SIL Level

Value evaluation supported by:

Sound engineering and statistical judgment, analyses, and evidences.

Service records



4 3

© 2 0 1 1 C r i t i c a

l S o

f t w a r e

S . A .

Example

r 2 20

T 50000 500000

m 25000 25000

90% ~9400 ~19300

95% ~7950 ~17900

99% ~6920 ~15700



Coimbra, Lisboa, Portowww.criticalsoftware.com

San Josewww.criticalsoftware.com

Southampton

www.critical-software.co.uk

São José dos Campos

www.criticalsoftware.com.br

Maputohttp://www.criticalsoftware.co.mz

Jorge Almeida [email protected]

José Faria [email protected]

Contacts

http://www.criticalsoftware.com/


http://www.critical-software.co.uk/

http://www.criticalsoftware.com.br/

http://www.criticalsoftware.co.mz/



http://www.criticalsoftware.com.br/






04 workshop presentation merge

Documents