EN 50126 / IEC 62278

Blog pause

2011-08-22T10:47:00.000-07:00

Dear blog reader

I am taking a pause from this blog in the near future. It is after all quite complete.

The background for the first blog posts was a course, "Introduction to EN 50126", I held for a broad group of employees in railway companies.

Immediately, after the first blog posts, I had positive expressions from colleagues in- an outside Europe. It whetted my appetite to continue - so thank you for your comments and mails!

At the present moment, I think the blog contains most significant subjects. All is collected in the "Quick Guide to EN50126".
Maybe, I will start again.

In the meantime, please take a 'Tour de safety management'.

Best regards

Troels Winther

Putting it all together

2011-01-02T08:30:00.000-08:00

How do we grab the airy key concepts of EN 50126 / IEC 62278 and convert them into a well working Safety Management System?

Case 1: Small Supplier Company

A minor Developing house with twenty employees is producing a control circuit for industrial applications.
They realize that the control circuit is suited to control points in railway tracks, but the circuit has to be Safety Approved.
Firstly, a plan for converting the control circuit into a safety approved circuit is written in a living document, named the Safety plan.
A further investigation of the company shows that they already have an ISO certificate. This means most quality and configuration management are in place.
However, the audit also discloses that the company has one key software developer who keeps all source files on his own computer and most software decision are taken at informal meetings.
Nobody in the company, except the programmer, can tell how the software code works in details.
In order to fulfil EN 50216 / IEC 62278, the programmer is asked to make a System definition of the software, hardware and developing environment, read EN 50128 and make a flowchart of the code.
All interfaces to the system definition have to be described and the developing engineers are asked to write a document describing the Safety principles in the design (TR 50129).
A Hazard workshop is performed, describing all hazards that can arise, if the control circuit does not work as expected. Mitigating actions for the hazards is listed in a Hazard log and derivate Safety requirements are found.
The proof for fulfilling the Safety requirements and closing the hazards are written in a Safety Case.
The quality system is updated with change management procedures for changing functionality on the control circuit. The process includes Minutes of meetings, Responsibilities and Mandatory actions in each Phase.
The company already has parted developing and validating testing into to independent departments.
There is no need to change this organization; however a new procedure regarding mandatory education ensures that all current and future employees will have to participate in this course.
Finally, an external Assessor is hired to supervise the fulfilling of the Safety plan.
Basic concepts of EN 50126 are now implemented and the company is ready to meet the local Safety Authority.

Case 2: Major Operator

See "Quick Guide to Safety Management based on EN50126"

Case 3: The Cut-off Safety Authority

See "Quick Guide to Safety Management based on EN50126"

Next chapter >> 7.1 How are the standards produced?

Quantitative Risk Analysis

2010-02-12T09:49:00.000-08:00

In some situations the qualitative risk analysis or the ALARP principle is insufficient: The safety people are torn and disagrees internally. Consequently, it is time to use the heavier "quantitative risk analysis"-tool.
The fault tree is integrated into Excel and models a scenario, where a passenger is trapped between closing doors. (All numbers and technical barriers are hypothetical).

Interpretation

The quantitative risk analysis is the right way to estimate the frequency of a hazard.
It removes personal obsessions from a safety problem and ensures that the discussions are conducted on an objective basis.
The fault tree above concerns a commuter fleet operating 365 days pr. year with 80 trains with 100 departures pr train pr. day. This result in c = 2.9E-06 departures every year pr. fleet.
In order to have an accident, there have to be squeezed a passenger arm, leg or items like e.g. a baby carriage, umbrella etc. between the closing doors. This is judged to happen continuously when passengers passes the doors, meaning d = 1.
There are three barriers that prevent the hazard:
A human based departure procedure, where the train driver looks out of the window and checks the doors before departure (e). It is estimated that the driver miss a check every 4'Th day due to distraction or lacking of concentration, meaning e = 1/(4*b).
There are also two technical functions:
- A traction blocking that prevents the train from driving if the door controllers indicate the doors are open (f). This function is part of the train computer and is expected to be reliable with a failure rate of 1 failure pr. 1,000,000 departures.
- A trap detection system in the door controller that prevents the passengers from being squeezed in a closing door (g). This function is sensitive to door mechanics; the FRACAS system indicates a failure rate of 1 failure pr. 10,000 departures.
As it can be seen we will end up having an accident where the train departs with a passenger trapped between doors every year. The Safety department has recorded an incident the recent year, indicating the fault tree is trustable.
Can we accept this? What are our quantitative acceptance criterion? It should be written and stated in the safety management system of the Operator.
The safety management now decides that the above result is unacceptable. We can only allow the hazard to occur every 10,000'End year.
A deeper analysis shows that the failures on the detection function only occurs for thin objects like a small child's arm.
It is judged that the detection system in the daily life is activated by large objects like a person; thin objects only occurs 3 times pr. day, meaning d = 3/b.
The sensors are adjusted and a maintenance program introduced; the following test result shows an improved reliability in the area of 1 failure pr. 100,000 departures (g).
An additional departure procedure is introduced stating the train conductor has to supervise the train doors before departure in front of a dedicated door. A new technical feature makes it possible to firstly close the other doors and finally, the train conductor enters the last door before departure. The improved procedure is expected to be more reliable with an estimated human failure rate of 1 failure pr. 10,000 departures (e).
These mitigating actions result in a dramatically lowering of the frequency of the hazard to app. 10,000 years between accidents, hereby fulfilling the acceptance criterion.

As a side effect, the analysis proves the importance of the departure procedure and the detection function.

The old rule, KISS, (Keep It Simple Stupid) is recommended for quantitative analysis. The fault trees easily swell up into large trees with several undocumented values based on engineering judgement. This only starts new discussions instead.

Next chapter >> 4.5 Common Cause Failures (CCF)

Focus on the Source

The "Guide to the application of EN 50126-1 for safety", TR 50126-2: Feb. 2007, concerns risk modelling and quantitative risk models.

Chapter 5.2, "Generic Risk Model" says:

Modelling predominantly represents a simplification and generalisation of reality but, enhances our understanding of causal relationships, highlights important factors and provides a useful tool for anticipation and potentially prediction of future.
A risk model may be created for a specific task (e.g., occurrence of a hazard, a combination of hazards, an operation, a sub-system, etc.) for a particular application or for a whole railway system by applying the risk assessment process to the relevant task or to the railway system.
[.....]
Developing a risk model for a whole railway system is a demanding task [....] the report does not recommend a single generic risk model for a whole railway system. [....]
Annex D lists essential steps for building such a model [....]

Configuration Management

2010-02-12T09:36:00.000-08:00

Configuration management concerns the task to be in control of documents and product configurations.
When a major project is running with full steam ahead, configuration management is a challenge.
However, if safety was a house then configuration management was the foundation.

Interpretation

The quality of the configuration management is an easy parameter to sense for an auditor.
In organizations with strong safety management (high SIL), the configuration management is pedantic and without a hitch: Documents, Minutes of meetings and Changes on the product are controlled in configuration management systems with fields for unique identity, date, responsible, revision, documents to be updated and tests performed etc.

In organizations with a lower safety culture the configuration management is random and uneven: Not all meetings have a minute of meeting or maybe you hear a busy employee stating: "I do not have time for making registrations!"
Such a statement indicates low awareness of the traceability requirements of safety decisions.
It takes commitment from the executives to change a low safety culture into a high concerning the configuration management issue.

Next chapter >> 4.2 Failure Reporting and Corrective Actions (FRACAS)

Focus on the Source

From chapter 3, "Definitions", in EN 50126

Configuration management: A discipline applying technical and administrative direction and surveillance to identify and document the functional and physical characteristics of a configuration item, control change to those characteristics, record and report change processing and implementation status and verify compliance with specified requirements.

From chapter 5.3.5, "Within all applications of this standard, the following requirements are mandatory":
...
e) an adequate and effective configuration management system shall be established and implemented...

From TR50126 Feb 2007, chapter 7.1.2
Change Management is seen as a crucial part of the LC Phases 11-13 [Operation], as emphasized in Table 7, column D: "…strict Configuration Control is THE most important issue…"

The subject is addressed to the maintenance of the QM and SM Systems of all involved perties.

Common Cause Failures (CCF)

2009-11-29T14:08:00.000-08:00

Special precautions have to be taken against common cause failures.

It is a single failure that causes a safety function to collaps e.g. a mechanical or logic error in a product as shown below in Figure A.7 from EN 50129.

It can be handled by using redundant systems, inherited charactheristics of components, safety analysis, independent reviews, FRACAS system, etc.

Interpretation

Common causes failures can e.g. be a sleeping tricky error in Function A that cause a dramatic failure in Function B.
If we have installed hundreds of systems we have a possibly accident.

Train fleet example:

Let’s say the developer of a diesel traction system in a train uses the exhaust gas to power a turbo. The turbo powers an air inlet compressor. The compressed air enters the combustion chamber.
A hose clamp on the air tubes are under dimensioned, nevertheless the design passes design reviews and burn-in tests.
The hose clamp is slowly loosened during operation and this causes a decrease of air in the combustion chamber that again causes an overheated exhaust gas that again causes the turbo to overheat and crack and finally cause an oil leakage in the turbo driven power transmission to the compressor located near the exhaust pipe.
The operational staff reports of occasional small fires in the turbo driven power transmission, the maintenance staff discovers the cracked turbo, and it is concluded that cracked turbo's must be changed.
In this case we have an undisclosed common cause failure in the train fleet (the loose hose clamp).
One day, under the right circumstances, the oil leakage will cause a larger fire. If the daily train route furthermore passes a tunnel we might end up with a "fire in train in tunnel" scenario.

Interlocking logic example:

See "Quick guide to safety management based on EN50126"

Next chapter >> 4.6 Safety Integrity Levels (SIL)

Focus on the Source

See "Quick guide to safety management based on EN50126"

Failure Reporting And Corrective Action System (FRACAS)

2009-11-06T15:34:00.000-08:00

Once the operation starts, the product enters phase 12, “Performance monitoring” in the V-model. In this phase it is time to implement a monitoring system.
If e.g. the maintenance staff discovers that a certain type of points tend to have loose bolts then there have to be an office, guard, database or other report system where the incident can be reported.
There also have to be somebody in the organization that reads this report and takes appropriate corrective action.

Potters Bar accident in UK, 2002, due to loose bolts in a point

Interpretation

It sounds easy; but investigation reports from accidents and “near miss” incidents often shows that the implemented FRACAS did not work properly: The points were poorly maintained, the failure report was shelved, the engineers misjudged data, the supplier never fixed it, the appropriate procedure was not updated or the purchasers lacked time to buy new bolts.

Regularly audits are a suitable tool for examining the implemented FRACAS system.

Statistics is a helpful tool, because it removes emotions from a problem and forces the safety management to take action.

Next chapter >> 4.3 Using the ALARP principle

Focus on the Source

Chapter 6.12 , “Phase 12: Performance monitoring” in EN 50126:1999 describes the objectives and requirements to this phase:

6.12.3 Requirements
6.12.3.1 Requirement 1 of this phase shall be to establish, implement and regularly review a process for:
- the collection of operational performance and RAMS statistics;
-the acquisition, analysis and evaluation of performance and RAMS data; checking that the assumptions made in the safety case remain valid.
6.12.3.2 Requirement 2 of this phase shall be to analyse performance and RAMS data and statistics to influence:
- new operating and maintenance procedures;
- changes in logistic support for the system.

Safety Integrity Levels (SIL)

2009-10-16T15:56:00.000-07:00

The SIL concept is a way of categorizing safety functions into five discrete levels: SIL0 - SIL4. The SIL determination follows a complex, although systematic, process as shown below (Figure A.5 from EN 50129).

However, for many purposes the quantitative SIL value can be substituted with a more straightforward qualitative approach when categorizing safety functions. For example:
Safety critical functions kind of compare to SIL3/4 (as e.g. the emergency brake in a train or the logic in an interlocking system.)
Safety related functions kind of compare to SIL 1/2 (as e.g. emergency announcement speakers in a train or warning lamps for track crossing)

Interpretation

At high SIL, the heaviest measures to avoid random, systematic errors and common cause failures have to be used at all phases in the V-model.

The SIL determination often ends up in complicated mathematical discussions among risk analytics (e.g. is the human failure rate 1e-3 or 2e-4 [pr. action]).

These types of discussions narrow the number of persons, who participates in the safety discussions; which again might decreases the safety awareness among the other staff groups: Implementation engineers, maintenance staff, train drivers and sub suppliers as an unfortunate side effect.

In an operating organization, with many small projects and a few major projects, it can therefore be advantageously to simplify the categorization of the safety functions into the above described categories e.g. "Safety related" and "Safety critical".

Such a concept is easier to communicate to the staff groups and integrate into the used procedures and documents.

Note 1; the used categorization method should be described in the Safety plan and agreed upon by the Safety Authority.

Note 2; for product developers and suppliers it will most likely be necessary to make quantitative risk calculations and common cause analysis, see examples in e.g. TR 50451:2007.

Next chapter >> 5.1 What is the task of the Assessor?

Focus on the Source

The SIL levels are explained in EN 50129 in the normative Annex A, "Safety Integrity Level".
Related concepts like Systematic and random failures, Tolerable Hazard rates (THR), Common cause Failures (CCF), process independence and safety targets are also explained.

Annex B of EN 50129 explains about Detailed technical requirements to e.g. redundancy and CCF.

Annex C of EN 50129 explains about Identification of hardware component failure modes.

TR 50451:2007, "Railway applications. Systematic allocation of safety integrity requirements" explains how to calculate the needed SIL of a new product.

Supervising of hazard indicators

2009-10-11T14:28:00.000-07:00

Dr. L. Neumann, Berlin, has given the following comment:

"I have 'spot-visited' your Blog and regard it as a time saving and
understandable introduction to the CENELEC ideas.

Regarding the ALARP principle, I would like to highlight, that a hazard which has been classified as "tolerable" (apart from "negligible" ) and for which a further risk reduction seems to be not adequate at least an "observation" should be foreseen in the sense, that indicators of this special kind of risk should be more frequently and detailed supervised than others."

I appreciate the above advice as I know Mr. Neumann as an experienced Assessor and EN 50126 interpreter. It has been added in the ALARP post.

Revision of the EN5012X suite

2009-03-19T14:08:00.000-07:00

Mr. Mairhofer Stefan, Fachhochschule OÖ Campus Wels, has kindly send the interesting information below.

The slides were presented at a workshop regarding upcoming European standards in Brunswick in week 49/2008.

The revision of the EN 50126-suite will be updated by 80 people in Cenelec working group TC9X/WG14 from May 2008 to app. 2011.

Interpretation

As discussed in blogpost Welcome and How are the standards being produced; EN 50126, 128 and 129 have to be interpreted.

The coming revision will try to make the EN 5012X suite more coherent. For the pedantically person, the current versions of EN 50126:1999, EN 50128:2001 and EN 50129:2003 are inconsistent when they are read closely. Some of the issues will be handled in the next revision:

Example 1: EN 50129 states in its scope that it does not cover SIL0 systems while EN 50128 says it covers SIL0 systems.
Example 2: EN 50129 only covers the safety case of signalling systems, but it is used for all types of railway systems (e.g. trains, level crossings, etc.)
Example 3: The determination of a SIL level of a safety function requires long-haired mathematical exercises, which can cause misunderstanding.
Example 4: There are some inconsistency regarding the definitions (e.g. safety critical functions vs. safety functions).
Example 5: The European EN 50126 suite has to be coherent with the worldwide IEC 61508 because of the “Dresden agreement“.

The standards will be compiled into one standard as shown above.

Next chapter >> 8.1 Is the Quick guide on book-form different from this blog?

Focus on the source

Special thanks to Mr. Stephan Griebel, Siemens AG for his informative slides.

The System Definition

2009-02-07T13:53:00.000-08:00

The system definition is basically a drawing defining the system at block diagram level. It shows the internal sub systems and important interfaces to neighbouring systems.
At a first glance it seems like a simple document to produce, but once released and posted to interested parties, it can easily cause important discussions.

Interpretation

Let’s take a look at the rough system definition above. The blue line marks the system.

Furthermore, the blue line immediately shows the interfaces. The interfaces are marked with green circles. An interface occurs whenever the system interacts with other systems e.g. the wheels interact with the tracks and the train doors interact with the passengers.

Although the system definition is clear, there are still many issues it would be advantageous and time-saving to discuss as early as possible in the trains life cycle:

- Is the maintenance manual a part of the system?
- Should the system involve coupled trains?
- Should the mission definition be a part of the system?
- Is intentional misuse part of the system?

The system definition can be organized into Generic Product, Generic Application and Specific Application as described in the Safety Approval Process.

The system definition defines the hazards in the hazard log, because hazards occur at the system borders.

Finally, it might end up with a system definition at block diagram level as shown below. The example below shows the sub systems that were considered inside and outside of the electronic brake system of a Copenhagen commuter train type during a safety approval process.
The rectangle boxes are sub systems and the hexagons boxes are measuring sensors.

Please note the system definition is the basis for the hazard log, the safety requirements, the safety approval and other safety activities. Any ambiguity in the system definition will surely cause problems and delays later on in the Safety approval process.

Next chapter >> 3.3 The Safety Plan

Focus on the sources (EN 50129:2003)

See "Quick Guide to Safety Management"

Results from former poll's

2009-01-19T03:46:00.000-08:00

Poll 6

Are bonus arrangements suitable for Operational staff as regularity increasing measure?

Result: 'Yes' (43%), 'No' (56%)

The question was raised by the Chinese delegation at an international railway safety conference. They concluded that when the staff was paid with bonus arrangements if regularity increased, then they had a tendency to jeopardize the safety. As an example, incidents had occurred where the train driver started the train when an umbrella was stuck in the door, forcing the passengers on platform to jump.
Therefore, the answer must be 'No'.

Poll 5

Is Independency intact, if the Project Manager and the Validator report to separate Managers, but have office jobs side by side?

Result: 'Yes' (65%), 'No' (35%)

There has to an adequate level of independency between the Project Manager and the Validator. This independency is intact because they report to different managers. From this point of view, I agree with the 'Yes' voters.
However, during a project lifetime a number of disagreements must be expected between the Project Manager and Validator e.g. whether a change-request should be validated by a time-costly retesting.
It is more comfortable for both parts to be located in different offices during such conflicts.
Therefore, I lean towards the 'No'.

Poll 4

Do simple and low-level safety-related projects have a bagatelle border for approvals?

Result: 'Yes' (38%), 'No' (62%)

It is a question often raised by e.g. operational staff: "We need to change this rubber pipe to another type, urgently - can we do it? It is such a small item without any safety relevance!"
If there was a bagatelle border, who should decide whether the change was below or above the border and on which basis? In order to take such a decision, it is necessary to make a fast risk analysis, define the safety function affected by the change etc. in the head - so why not write it down on some very simple key documents?
Therefore, I agree with the 62%.

Poll 3

Is an ISO 9001 certificate a basic EN 50126 requirement?

Result: 'Yes' (40%), 'No' (60%)

The voting result reflects the ambiguity in the EN 5012x suite; EN 50128 (about software) states that ISO 9003 is a basic requirement. But EN 50126, chapter 5.3.5.d) states there “shall be a quality management system compliant with the requirements of ISO 9001”, meaning ISO 9001 is not a formal requirement.

Poll 2

In which phase should the first revision of the 'Safety plan' be released?

Result: 'Concept' (46%), 'System Definition' (46%), 'Risk analysis' (7%), 'System requirements' (0%)

The voting result shows an agreement among the voters that it has to be in either the 'Concept' phase or in the 'System Definition' phase. According to Figure 9 in EN 50126, it has to be in the System Definition phase. See the Figure in chapter "Focus on the Source" in The Key Documents.

Poll 1:

Would you name the task "to inspect a train and report it ready for test runs" as:

Result: Verification (70%), Validation (10%), Assessment (20%)

I agree with the 70 % majority. I consider it as a verifying task, stating that we are ready to move on to the next phase in the V-model. See further explanation in chapter "Interpretation", question 1 in the quiz in verification, validation and assessment.

Does the Guide add information cp. to the blog?

2009-01-17T15:22:00.001-08:00

The "Quick guide to safety management based on EN50126 / IEC 62278" is almost identical to this blog. In this way, you could print out the blog and have the same information.

If you are e.g. a Project manager, a Research and developing engineer or maybe a Purchaser and are just about to start a railway project, you might find it helpful to read the guide on book-form.

1) Brush up your safety management knowledge each time a new project starts

2) You can use it as a reference work, years after forgetting the blog link.

3) You will not be disturbed by the internet commercials.

4) The book can be read in the train on the way home.

5) You will read the content in the right sequence as suggested by the author with better pictures.

6) Bring it to your boss' office, when explaining the importance of EN 50126.

7) You save the time it takes to print out the entire blog.

8) Get a reference work of the buzz words used by the European Safety Authorities.

9) A few Examples and "Focus on the Source" chapters are removed from the blog.

10) An extra chapter about "Putting it all together".

Safety approval process

2009-01-16T15:03:00.000-08:00

The approval process can be parted into three different types of approvals.

1) A "Generic Product (GP)" approval (the platform).

2) A "Generic Application (GA)" approval (the type).

3) A "Specific Application (SA)" approval (the installed product).

This is shown at Figure 9 in EN50129:2003, see below:

Interpretation

If e.g. Windows for PC was used as a railway product in e.g. a supervisory system, then the approval process could be parted into e.g.:

GP; the platform: This could e.g. be an American version of Windows, running on a PC.

GA; the type: This could e.g. be a Spanish version of Windows version, running on the platform PC.

SA; the installed product: This could e.g. be the Spanish Windows version physically installed at a supervisory centre at a site.

It works well in the theory, but it is difficult to part a complex system like Windows, a train or an interlocking system sharply into the three different systems definitions, GP, GA and SA.

Most often an approval process is connected to a contract concerning a specific application (SA). Everybody works hard to make the system ready and in this process the different System Definition's GP, GA and SA gets mixed with ambiguous interfaces.

But the basic idea is well-thought in order to approve a basic system in different country specific variants in the European countries and the parting should be strived towards.

Next chapter >> 3.1 EN 50126 key documents

Focus on the sources (EN 50129:2003)

Chapter 5.5.2, "Safety approval Process" describes the approval process. The approval concepts of GP, GA and SA are shown in EN50129:2003 at Figure 8 (see below and please excuse the quality).

How to choose an Assessor

2009-01-09T05:10:00.000-08:00

The 1'st and 2'nd part in a railway contract can hire an assessor:

- The 1'st part will typically be a supplier, who wants to develop a railway system (a train, a level crossing, an LED lamp etc.) and
- The 2'nd part will typically be an Operator or Infrastructure owner, who wants to buy a railway system.

It is recommendable to choose an assessor in corporation with the Safety authority.

Interpretation

The assessor should have the capacity to perform the required assessor tasks.

The assessor should have the needed independency.

The assessor should have the needed competence.

There can be many candidates.

Please note an approval of a product can be parted into Generic Product (GP), Generic Application (GA) and Specific Application (SA).

Each approval step can have different assessors.

Add 1) For the GP it might be beneficial to use internal assessors as far as possible. If this is not accepted by the relevant safety authority, an external assessor can be hired to ensure the independency.

Add 2) For the GA and SA it might be beneficial to choose a local assessor or someone who is accepted by the local Safety Authority.

Add 3) For the SA it might only be necessary with an assessor for the first installed site.

Focus on the sources (EN 50129:2003)

See "Focus on the sources" in the referenced links.

How does the Notified Body fit in?

2008-12-27T07:10:00.000-08:00

The Notified Body (NB) is an independent role which is similar to the independent assessor role, but the NB role belongs to the European Interoperability Directives for the TEN network and not to EN 50126. The vision of the interoperability directives is to achieve a free european market and achieve that a train, with the same train driver, can drive from Finland to Italy.

Interoperability

The concept of interoperability is defined in European Directives.
A underlaying documentation layer of Technical Specification for Interoperability, also named "TSI"'s, are affiliated to the directives.

The interoperability concept concerns all the technical functions, which must be implemented in the infrastructure and in the train fleets in order to achieve interoperability.
An example of TSI functionality is the ERTMS/ETCS system. It transmits the signal aspect of the signals into a speed mark at the speedometer of the train. Hereby, it is superfluous for the train drivers to know the signalling aspects in the country the train passes, because the train driver can rely on the mark at the speedometer.
Another example of TSI functionality is the diameter of the toilet flushing pipe. This diameter must have a certain value in order to ensure that the toilet can be emptied in any country.

A Notifed Body is an organization, which makes a Certificate of conformaty of a train or an infrastructure system against the TSI's.

The NB's are appointed by the national safety authority. There are a number of requirements to an organization before it can be appointed as a NB, e.g. it must prove it's independency, it must have the needed technical knowledge and capacity within the scope of the TSI's and it should participate in the standardization work of the Cenelec standards.

Therefore,
- the NB performs an independent assessment of the interoperability functionality against the TSI's and
- the assessor performs an independent assessment of the RAMS management against EN 50126.

It is often seen that a NB works as an independent assessor on railway projects, because they have the independency, capacity and knowledge to be an assessor.

Focus on the sources (Interoperability directives)

The European directives of Interoperability (96/48/EF, 2001/16/EF and 2004/50/EF) are parted into a directive for high-speed trains and for conventionel trains.

Hazard log, risk analysis and safety requirements

2008-12-18T14:56:00.000-08:00

The hazard log, risk analysis and the safety requirements are all key documents. They are all rooted in the hazard log.

Interpretation

The hazard log can be written in many different ways. Typically the hazard log contains a number of hazard sheets, where each sheet can have many forms and looks e.g. like the hazard sheet shown above of the size of an A4 page.

The hazard sheet above concerns a hazard, where the passengers can not communicate with the train driver in case of an emergency situation. This might lead to an accident.

According to the risk analysis theory, the frequency (column 'F') and the consequence (column 'C') of this type of accidents should be stated, before and after the mitigation actions.
The associated risk value can then be found with a look-up in the risk table.

Please note that the "before" column is left empty. It is difficult to enter a trustworthy value in the before column, because what is actually "before"; is it an old train without passenger emergency brakes?

The mitigation actions are per definition the safety requirements to the system. They state the safety functions, which must be implemented in the train in order to control the risk level.
In the above example the safety functions should be categorized as "safety related", which can be compared to SIL1/2, because a failing function can not alone cause an accident; if e.g. the 'passenger emergency brake'-function fails then the passenger can use the 'Emergency speech unit'-function instead and ask the driver to stop the train.

Another important spin-out from this is that it is not possible to have a safety requirement, if it can not be associated with a hazard. Any accident is caused by a hazard and only mitigation actions are safety functions, because they reduce the risk of the hazards.
In old Railway organizations you might find some requirements to inherited safety functions, but no one remembers the associating hazard.

Next chapter >> 3.6 The Safety Case

Focus on the sources (EN 50126:1999 and TR 50126-2:Feb. 2007)

Chapter 4.6 in EN 50126 talks about "risk" and "risk analysis"

The risk concept is explained in details and with examples in "guide to EN 50126", TR50126-2:Feb 2007. As an example, Figure 4 in the guide shows the relation between the hazards and the safety functions:

The Safety Case

2008-12-17T14:21:00.000-08:00

The Safety Case is a key document.

The chapters are fixed and has to be organized as showed above.

Interpretation

The Safety Case should be written as a logic proof - like a mathematical proof from math courses at the high-school.
When the experienced colleague reads the Safety Case he or she should be nodding and saying: "Of course".

Part 2, 3 and 4 shows that a railway product can be considered as safe, if the technical safety is adequate AND the quality and safety management is adequate too.

It can be compared with two eggs from the super market. One egg is from an organic hen and one egg is from a battery hen. When you look at the two eggs they look the same. The egg shell can be compared with the Technical safety - the egg shell protects the egg. But nobody can tell how the eggs were brought into existence: Did the hen eat organic corns or spouted corns etc. - the feeding and living of the hens can be compared to the quality and safety management.

The technical safety is demonstrated by referring to the validation test reports and e.g. a requirement matrix, showing that each safety requirement has been tested.

The quality management can often be proved by referring to the general quality system of the company. It concerns subjects like e.g. document configuration systems, internal audits etc.

The safety management can be proved by e.g.
- Referring to minutes of meeting from safety management meetings listed in the safety plan.
- Reference to the minutes of meeting from a hazard workshop stating dates, participants etc.
- Referring to important decision e.g. the day the top manager declared that a safety issue could be postponed.

The conclusion in part 6 should be a short statement: Hereby, it is proved that the product is safe.

Next chapter >> 4.1 Configuration Management

Focus on the source (EN 50129:2003)

See "Quick Guide to Safety Management"

The Safety Plan

2008-12-06T15:44:00.001-08:00

The Safety Plan is a key document and describes "Who does what and when". A Safety Plan of the size of an A4 paper could look like below for an Operator or Infrastructure owner who wants to buy a product from a Supplier.

Interpretation

The Safety Plan, above, describes, in a simple way, the most important headlines of "who does what and when".

The fourteen phases from the V-model has been simplified into three vertical phases.

The risk analyses and requirements specification phases are handled at the workshop(s), arranged by the Project manager in phase 1.

The needed independency is cleared and discussed by the Project Manager and the Safety Authority, when he or she must enter personal names and company names for the roles in each column.

The main safety activities are described in the table. As it can be seen, the supplier is responsible of designing, implementing, verifying and validating the product, mainly in phase 2.

The customer (the Operator or Infrastructure owner) must participate in phase 1, when the product is specified, and in phase 3, when the product must be approved and set into service.

The Safety Plan can be seen as an overview of the main safety management phases, roles and activities. More detailed information can be added if needed with references to Minutes of Meetings, appendices, sub chapters etc.

Next chapter >> 3.4 Hazard log and risk analysis

Focus on the source (EN 50126:1999)

EN50126; chapter 3.39 Safety plan: A documented set of time scheduled activities, resources and events serving to implement the organisational structure, responsibilities, procedures, activities, capabilities and resources that together ensure that an item will satisfy given safety requirements relevant to a given contract or project.

A recommendation to a complete Safety Plan, suited for a complex project, is given in chapter 6.2.3.4.

Requirement 4 of phase “System definition” shall be to establish the Safety Plan for the system. The Safety Plan shall be agreed by the Railway Authority and the railway support industry for the system under consideration and shall be implemented, reviewed and maintained throughout the lifecycle of the system. The Safety Plan should include:

a) the policy and strategy for achieving safety.
b) the scope of the plan.
c) a description of the system.
d) details of roles, responsibilities, competencies and relationships of bodies undertaking tasks within the lifecycle.
e) description of the system lifecycle and safety tasks to be undertaken within the lifecycle along with any dependencies.
f) the safety analysis, engineering and assessment processes to be applied during the lifecycle, including processes for:
- ensuring an appropriate degree of personnel independence in tasks, commensurate with the risk of the system;
- hazard identification and analysis;
- risk assessment and on-going risk management;
- risk tolerability criteria;
- the establishment and on-going review of the adequacy of the safety requirements;
- system design;
- verification and validation;
- safety assessment, to achieve compliance between system requirements and realisation;
- safety audit, to achieve compliance of the management process with the safety plan;
- safety assessment to achieve compliance between sub-system and system safety analysis.
g) details of all safety related deliverables from the lifecycle, including:
- documentation;
- hardware;
- software.
h) a process to prepare system Safety Cases.
i) a process for the safety approval of the system.
j) a process for safety approval of system modifications.
k) a process for analysing operation and maintenance performance to ensure realised safety is compliant with requirements.
l) a process for the maintenance of safety-related documentation, including a Hazard Log.
m) interfaces with other related programmes and plans.
n) constraints and assumptions made in the plan.
o) subcontractor management arrangements.
p) requirements for periodic safety audit, safety assessment and safety review, throughout the lifecycle and appropriate to the safety relevance of the system under consideration, including any personnel independence requirements.

The key documents

2008-11-05T13:39:00.001-08:00

A number of documents can be considered as "key" documents in a Safety Management system based on EN 50126.

The System definition: Defines the system on block diagram level.

The Safety Plan: Describes "Who does what and when".

The Hazard log: Contains all known hazards and their history.

The Risk analysis: Contains the risk analysis performed for each hazard.

The Safety Requirements: The safety requirements to the system

The Safety Case: The document that proves the system is safe.

Interpretation

An Operator, Infrastructure owner or Supplier organization might have thousands of small projects every year and maybe a few large projects.

It is some times asked: "Do who need all these documents for each single small project?".

The answer is "Yes" - however, it is allowed to simplify the documents to one A4 page.

Of course you need the documents! Imagine it was a small company saying: "We are so small that we do not need a yearly accounting report for the taxes authority".

If you do not have the key documents, everybody around you gets confused: The Safety authority, the safety department and the Assessor.

Next chapter >> 3.2 The System Definition

Focus on the source (EN 50126:1999)

In Figure 9 in EN50126, it is recommended to update the safety documents during the life cycle as shown below:

Information about the Safety organization and the FRACAS system can be included in the Safety Plan.

Infomation about relevant standards can be included in the Hazard log.

Information about the Risk acceptance criterion can be included in the Risk analysis.

Verification, Validation and Assessment

2008-11-04T13:07:00.000-08:00

There is defined three different types of tasks and roles in EN 50126:

"Verification": The "Verificator" checks, if we are ready to move on to the next phase in the V-model.

"Validation": The "Validator" checks whether the physical systems behaves as it was supposed to do, i.e. horizontal tests and checks in the V-model.

"Assessment": The "Assessor" checks, if the processes in the Safety Management System are working as they should, i.e. the Safety Management Circle is turning. The assessor is not performing project tasks, the project would be made without the Assessor.

Figure 11, "Verification and Validation"

Interpretation

The difference between the different types of tasks and roles are not very clear between Verification and Validation.

But if Figure 11 is interpreted very strict, it is possible to identify the different types of tasks you meet in the daily Safety Management Life.

The table below shows some tasks that occur when a train is being prepared for take-over from a Supplier to an Operator:

The explanation to the table above is showed graphically below:

Verification example (no. 1): The task "Inspection check, to see if the train is ready for test driving" is a check, which verifies, that we are ready to move on from phase "Installation" in the V-model to the next phase "System Validation".

Validation example (no. 4): The task "Compile documentation showing fulfilment of safety requirements." is a task, which collects different types of proofs like test protocols and hereby validates that the installed system fulfils the requirements from the specifications.

Assessment example (no. 3): The task "Judgement, whether roles and responsibilities are defined in a safety plan, is a task which controls that a proper Safety plan actually exists for the project. It is not the task to actually write the Safety Plan.

Next chapter >> 2.4 Safety Approval process

Focus on the source (/EN 50126/)

The tasks are shown at Figure 11 (see above) and roles a described in the "Definitions" chapter of EN 50126:

Assessment: The undertaking of an investigation in order to arrive at a judgement, based on evidence, of the suitability of a product.

Validation: Confirmation by examination and provision of objective evidence that the particular requirements for a specific intended use have been fulfilled.
The objective of validation is to demonstrate that the system under consideration, at any step of its development and after its installation, meets its requirements in all respects.

Verification: Confirmation by examination and provision of objective evidence that the specified requirements have been fulfilled.
The objective of verification is to demonstrate that, for the specific inputs, the deliverables of each phase meet in all respects the requirements of that phase.

The Safety Management Circle

2008-10-31T15:22:00.000-07:00

Safety Management can be shown as a circle that enters different seasons like the Year.

"Planning" is to: Prepare service, make risk analysis and set goals.
"Execute" is to: Implement the plans and organize the work.
"Control" is to: Check performing through statistics and audits.
"Adjust" is to: Evaluate the checking and adjust the plans.

Interpretation

It can be a challenge for a Railway organization to keep the Circle above intact.

If, for example, a Supplier Company starts a large developing project of a new system (e.g. a new train or interlocking system, etc.) in the "Planning" season, then the Suppliers Project organization moves on and enters the "Execute" season.

Once the Project organization has finished the system and the system has been set into service, is the Project organization dissolved. The Project Manager and the Project Engineers moves on to new projects and forgets everything about this newly installed system.
A Customer takes over the service of the system.

From this point the system enters season "Control", but the Customer Organization consists of completely other persons, who are not aware about the hazards, risks, procedures, configuration management, education, documentation, emergency, etc., which where discussed in the former "Planning" and "Execute" season.

In this case the Circle is broken! - See the figure below.

The conclusion is that the take-over phase, where a Supplier delivers a system to a Customer, is a critical phase from a Safety Management point of view.

Next chapter >> 2.1 RAMS and how to control it

Focus on the source (/ISO 9001/)

The Circle is identical for all types of Management systems. It can be seen in one of first pages of the Quality Standard, ISO 9001. A quality standard should be followed according to EN 50126:

“5.3.5.d) The requirements of this standard shall be implemented within the business processes, supported by a Quality Management System (QMS) compliant with the requirements of EN ISO 9001, EN ISO 9002 or EN ISO 9003 appropriate for the system under consideration.”

The needed awareness when a system is passed on from a Developing Project Organization to a Service Organization is described in EN 50126, e.g. chapter 6.11:

"6.11 Phase 11: Operation and maintenance

6.11.1 Objectives

The objective of this phase shall be to operate (within specified limits), maintain and support the total combination of sub-systems, components and external risk reduction measures such that compliance with system RAMS requirements is maintained.

6.11.2 Inputs

The input to this phase shall include all relevant information, and where appropriate, data, necessary to meet the requirement, and in particular the operation and maintenance procedures prepared in phase 6 (Design and Implementation)."

How to measure "Risk"

2008-10-30T13:35:00.000-07:00

"Risk" is the measurable unit in a Safety Management System. - The unit we have to measure and control!

Although it is not as easy to measure! - We do not have any handy measuring instruments to measure "risk" - like e.g. a Geiger counter, which can measure radioactivity.

We only have the Statistics to measure back in time and the Risk analysis to measure ahead, see the Figure below.

Interpretation

The figure above shows the close relationship between statistics and risk analysis.

This relationship is often forgotten: In many projects, a "Risk department" from e.g. the Supplier creates a large hazard log for a complex interlocking system, filled up with complex fault trees with many hard-to-understand branches.

Afterwards, an independent Assessor is asked to assess the Risk analysis, and the Assessor creates a huge hard-to-understand assessment report.

However, it should not be that complicated; when the close relationship between statistic and the risk analysis is kept in mind, the statistics can be a helpful tool to get a feeling of the quality of a hazard log.

Let's say we have the statistics from

- "Passengers traps in doors for a train fleet",
- "Trains parsing a red signal on a certain line" or
- "Accidents in level crossings pr. year"
etc.

Once we have such statistical numbers, it is often possible to find the corresponding branch in the hazard log.

If the numbers are close, it indicates that the hazard log somehow reflects and models the "real life". - Or maybe it needs adjustment.

It is also worth an effort to screen the hazards and pick out the "Top 5" hazards, which has the highest risk level.
In order to reduce the complexity, all branches in the hazards fault trees, which gives a low risk contribution, can be removed or compiled together.
Finally, the fault trees are simplified, easy to understand, can be controlled through statistics and evidently models the "real life".

Next chapter >> 1.4 The Safety Management Circle

Focus on the source (/EN 50126:1999/)

See "Quick Guide to Safety Management"

Control the Risk level

2008-10-25T16:18:00.000-07:00

The Basic idea behind a Risk based Safety Management System is to control the risk level.

In the "Old-Days"-graph, shown below, the Safety Department in an organization implements a procedure or technical solution every time an accidents occur: "Oops, we did it again". Time goes on and evidently, a major accident occurs one day.

In the "Now-a-days"-graph, all accidents have been foreseen in the hazard-log and mitigation actions have therefore been implemented by the Safety Department before the accidents occur.

Interpretation

What happens if the risk management level (on the graph) is set too low?

Then - of course - we will experience more small event and accidents.

What happens if the risk level is set too high?

Then we will will not experience any events and accidents. But safety is expensive, this means an organization with a too high risk management level will have higher operational costs.

Lets say we have two Railway Operators, called A and B, and lets say that they are competing of operating a train fleet somewhere in Europe. Operator A has implemented a too high risk management level compared to Operator B and compared to the guidelines set out by the local Safety Authority. In this case Operator B has lower expenses on Safety and will therefore be able to make a better offer.

Next chapter >> 1.3 How to measure "Risk"

Focus on the Source (/EN 50126/)

2.2.2 Focus on the source (EN 50126:1999)

The concept of risk based safety management is explained in chapter 4, “Railway RAMS”.

In chapter 4 is stated that the risk evaluation shall be performed:

”4.6.1 Risk concept:

The concept of risk is the combination of two elements:
the probability of occurrence of an event or combination of events leading to a hazard, or
- the frequency of such occurrences;
- the consequence of the hazard.

4.6.3.2 Risk evaluation shall be performed by combining the frequency of occurrence of a hazardous event with the severity of its consequence to establish the level of risk generated by the hazardous event.

4.6.3.3 Risk acceptance should be based on a generally accepted principle.” (e.g. the ALARP principle).

The main hazards and the acceptable risk level shall be defined in phase 1, ”Concept”.

“6.1.3.4 Requirement 4 of this phase shall be to obtain information about:
- previous RAMS requirements and past RAMS performance of similar and/or related systems.
- identified sources of hazards to RAMS performance.
- current Railway Authority Safety Policy and Targets.
- safety legislation.”

Definition of Safety Management

2008-10-18T14:52:00.000-07:00

Safety Management is the implementation of a "Safety Management System" into an organization.

A "Safety Management system based on EN 50126" uses a "Hazard log" to manage the safety. The controlled unit, - which can be counted and calculated -, is "Risk".

A "Safety Management System" is similar to other types of "Management Systems"; - For example, an "Economy Management System" uses a "Budget" to manage the economy; the used controlled unit, - which can be counted and piled up -, is "Money".

Interpretation

There exist other types of "Management Systems":

- A "Capacity Management System", which controls the Capacity of a system.
- A "Quality Management System", which controls the Quality of a system

In order to implement a Management System into an organization, there have to be some procedures, processes and key documents that must be used and updated by the organization.

EN 50126 describes all the necessary key elements for a Safety Management System; there must be a company policy, a safety plan, a hazard log, internal audits and a failure reporting and corrective actions system, a risk estimation process etc.

It is then up to the Railway organization to adjust size, amount and complexity of these key elements into a suitable and operative Safety Management System for the product and organization in question (see examples of adjustment in post 'The V-model').

Next chapter >> 1.2 Control the Risk Level

Focus on the source (/EN 50126:1999/ and /Railway Safety Directive/)

In chapter 5 of /EN 50126:1999/, "Management of railway RAMS", it is stated:

5.1.1 Clause 5 of this European Standard defines a management process, based on the system lifecycle, which will enable the control of RAMS factors specific to railway applications. The process supports the:
- definition of RAMS requirements;
- assessment and control of threats to RAMS;
- planning and implementation of RAMS tasks;
- achievement of compliance with RAMS requirements;
- on-going monitoring, during the lifecycle, of compliance.

In the European Union Directive 2004/49/EC, also named the "Railway Safety Directive" it is stated in article 3, "Definitions", chapter (i):

"Safety management system’ means the organisation and arrangements established by an infrastructure manager or a railway undertaking to ensure the safe management of its operations;"

Further on is stated in article 9, "Safety Management", chapter 2:

"The safety management system shall meet the requirements and contain the elements laid down in Annex III, adapted to the character, extent and other conditions of the activity pursued."

Which is interpreted by the author of this blog as: A Safety Management System must contain the required elements (from annex III; page 24 of the Railway Safety Directive), but the elements can be bended, adjusted and simplified to a suitable and operational level for the product and organization in question.

The V-model

2008-09-27T05:11:00.000-07:00

The EN50126 process is based on a general lifecycle view; the lifecycle starts when the product (e.g. an interlocking system, a train, an LED-lamp etc.) is in a concept phase. Then the product is developed, approved and put into operation and finally it is disposed. This lifecycle is expressed in the V-model, see Figure 10 from EN 50126 below.

Interpretation

Please note the V-model can be viewed as a time-line, which is bended down to form a "V". The product moves sequentially from phase 1, "Concept", to phase 2, "System definition and application conditions", etc.

The V-model is created (by the working group) in order to handle all Railway systems - simple as well as complex.

In the daily life, the fourteen phases of the V-model can be compiled and simplified into a model that smoothly fits into the product in question.
However, the main idea of viewing a product as going through life-cycle phases, on a V-shaped time-line, should be intact.

Example 1:

We would like to install entertainment video screens in a train fleet. For this product, it should be sufficient with three phases: "Design", "Installation" and "Operation". The V-model can then be compiled and simplified into the Figure below:

Example 2:

A more complex system, like e.g. a new supervisory system in a major city, controlling many sub stations, is planned to be set into service in steps: Mission 1 includes the first 10 sub station on a single line, Mission 2 includes all stations on the line etc.; until the Final mission, where all sub stations in the city are supervised.
For such a system, the V-model can be viewed as a life-cycle line, where you step back to a former appropriate phase each time a mission has reached phase "Operation" and the preparation for the next mission starts. For example, the project might step back to phase "Design and Implementation of mission 2" once the phase "Operation of mission 1" has been reached, See the Figure below:

Next chapter >> 2.3 Verification, Validation and Assessment

Focus on the Source (EN50126:1999)

The life-cycle concept is explained already in the scope of EN 50126, chapter 1.1:

"This European Standard: - defines a process, based on the system lifecycle and tasks within it, for managing RAMS;"

In chapter 5 is Figure 10 (from above) explained:

5.2.6
This standard represents the system lifecycle sequentially. This representation shows individual phases and the links between phases. Other lifecycle representations are widespread within industry and include the ”V” model.

5.2.7
A ”V” representation of the lifecycle contained within this standard is shown in figure 10. The top-down branch (left side) is generally called development and is a refining process ending with the manufacturing of system components. The bottom-up branch (right side) is related to the assembly, the installation, the receipt and then the operation of the whole system.

And finally is chapter 6, describing each phase in the V-model.

Using the ALARP principle

2008-09-12T10:00:00.000-07:00

The ALARP-principle stands for "As Low As Reasonable Practible".

It means, that if it is practible, with reasonable effort, to reduce the risk from the "Tolerable" (Yellow) hazards in the risk table below, it should be done.
In all cases an "observation" should be foreseen in the sense that indicators of this special kind of risk should be more frequently and detailed supervised than others.

This goes particularly for the yellow hazards in the right-bottom corner.

Interpretation

In risk analysis you might end up with a risk matrix looking like above.

In a major project some years ago, it was necessary to decide, at a meeting, what to do with the "yellow" hazards in the ALARP region. The Project Manager looked at the table and said: "It is easy, - we have no money, and the customer has no time".

The Project Manager was interpreting "Reasonable Practible" in the ALARP-definition and came to the logic conclusion, that we didn't have to do anything.

The definition needs to be coupled with the general dislike of large accidents in society, also named: ("Differential Risk Aversion" (DRA)).
This principle concerns the "yellow" hazards in the bottom-right corner in the risk table above. This field contains all the controversial and unpleasant hazards; they are almost improbable, but the outcome is catastrophic.

For these hazards, the ALARP-principle should be implemented.

Driving through the tunnel

For example, let's say that hazard 1, in the risk table above, concerns the catastrophic scenario where a train is caught with fire while driving in a tunnel.
The risk analysis has revealed, that it is possible to reduce the frequency from 10 occasions pr. 1 Million year to 2 occasions pr. Million year by implementing an "Escape-button" on the Train driver panel.
The Escape-button allows the driver to speed up, even if the traction power has failures, in order to the help the driver escaping the tunnel.
The button is expected to cost 100,000 Euro's and taking 12 weeks to install.

The Project Manager, from above, might say: "It is not practible because of the budget and the time schedule. Furthermore, the reduction from 10 to 2 occasions pr. 1 Million years is so small that it's not worth the effort."

Acoording to the ALARP-principle, the button shall be implemented because the budget and time schedule is inside reasonable practible and because of the dislike of large accidents.

In order help the Project Manager, it would be reasonable to give the train a running permit for service for a limited time period of 12 weeks, until the button has been implemented; because the risk reduction, after all, constitutes a minor risk reducing contribution.

In any case the risk management should also ensure that indicators of hazards in the yellow area are supervised more frequently and detailed than others in the FRACAS system.
For the tunnel hazard, it would therefore be necessary to supervise activated smoke and fire alarms on the train fleet.

Next chapter >> 4.4 Quantitative Risk analysis

Focus on the Source (/EN 50126/)

See the quick guide.

How can I get a copy of the standards?

2008-09-10T07:42:00.001-07:00

Check e.g. Standards at the Knowledge database at the Cenelec homepage.

How are the standards being produced?

2008-09-10T01:48:00.000-07:00

The standards are produced in "Working Groups" (WG) arranged by Cenelec. To become a member of a WG you must be a member of the National standardization Committee (NC). A company can register to become a member of the NC by paying a fee.

Once your company has paid the fee for the NC, you can enrol into a WG of your interest.
Each standard is - in principal - updated every 5'Th year. This means every standard has almost all the time an affiliated active WG, working on the next update.

It can be risky for the major players on the market to ignore the work in the WGs. - Imagine, a major supplier is developing a new Railway safety product (e.g. an interlocking system, a train,..). It takes 5 years and cost 15 millions Euro. Once the Company has finished the product, it realizes, a WG in the meantime has released an updated standard, which the product does not satisfy.

Every WG has an appointed chairman who organizes the work. Typically the group meets every 3'rd month in a major city in Europe. Everyone is seated around a table; the text is projected on a large screen. The chairman controls the keyboard; the standard is written as a "One-text negotiation". For example the chairman asks: "Which key documents are necessary in order to implement an adequate Safety Management System?"

Typically participants could be: Siemens, Bombardier, Alstom, Westinghouse etc. Other participants could be the Infrastructure owners, the Safety Authorities: French EPSF, German EBA; independent Assessors like DNV and Tüv; and the Advisors like Atkins.

Once the WG releases a version it must be formally be approved by the national committes.

If the WG agrees about a subject, it is formulated clearly in the standard; if they disagree, the standard will only contain some vague superior sentences like: "An adequate mitigation activity should be established...".

In the daily work you can then try to interpret and discuss, what is actually "adequate"?

Hopefully, this blog can inspire the interpretations.

Next chapter >> 7.2 Revision of the EN 5012X suite

Competence of the Assessor?

2008-09-02T14:34:00.001-07:00

Basically, the Assessor should have general knowledge of:

- Railway technology and
- Auditing techniques.

Interpretation

The task of the Assessor is to supervise - through audits and technical spot checks - that all involved parties are working jointly with the safety of the product.

The Assessor role only makes sense, if the other parties implement the recommendations of the Assessor. This will happen, if the Assessor is believed to have the needed capacity and independency.

There is also a "3'rd part" dimension in the work of the Assessor:

If the Supplier ("1'st part") is pressed by the Operator ("2'nd part") on e.g. time of delivery, the Supplier might attempt to play down a safety failure and argue that this failure can easily be handled by e.g. the train driver, or
Maybe the Operator overacts and claims a minor RAM failure as a major safety issue, but actually it covers an attempt from the Operator to get a better product than ordered, or
Another situation can occur if both the "1'st part" and "2'nd part" reluctantly have been forced to use an Assessor by the Safety Authority. In this case, both 1'st and 2'nd part might play down any deviations and failures and produce airy documents to please the assessor

The Assessor must be able to see through these hidden agendas and rely on "judgement based on evidence" (from the definition of "assessment" in EN 50126). The "evidence" could be e.g. the gab between "the process experienced through audits" and "the process according to the Safety Plan of the Project".

Next chapter >> 6. Putting it all together

Focus on the Source (/TR 50129/)

In TR 50129, Draft 2006, chapter 7.1.2, is written the competence for an ISA:

"The assessor must prove as a minimum competence in the following fields:

- specific or relevant expertise in Railway Operation
- the technology of the system
- local requirements/rules for application
- the legal requirements and the recognised rules of the technology
- the necessary practical experience and the ability to provide an assessment report
- guarantee for independence and impartiality
- quality processes in development phase and safety management requirements
- knowledge of all related CENELEC standards"

Notes

1) TR 50129 is a "Guide". It states only recommendations and not mandatory requirements.

2) The Safety Authority in each country decides, who is allowed to call him- or her-self an ISA.

RAMS and how to control it

2008-08-16T06:37:00.000-07:00

EN 50126 is all about controlling the RAMS parameters of a Railway system (e.g. a complete train, an LED lamp etc.).

It appears directly from the title: “Railway applications - The specification and demonstration of Reliability, Availability, Maintainability and Safety (RAMS)”.
The RAMS parameters are linked as shown at Figure 2:

Interpretation
The RAMS parameters are useful when categorizing different items e.g.:

the requirements to and specifications of the system
faults and findings during design and service.

This way, all parties (Operator, Supplier, Safety Authority, Assessor) know what we are talking about if e.g. an error is disclosed during testing: Is the fault a Reliability issue, an Availability issue, a Maintainability problem or a Safety problem.

Lets say we have a new train ready and approved for operation, but some errors exists. The errors have been categorized as Reliability issues, which are not directly safety-related. In this case Figure 2 above would look as shown on the left:

The yellow "Reliability" in the bottom will cause a Yellow "Availability" in the middle, which again will cause a yellow top level "Railway RAMS".

Since we have a green "Maintainability" in the bottom, it might be possible to increase the "Maintenance" work and hereby compensate for the yellow "Reliability", so we obtain a green "Availability", which again will cause a green top level "Railway RAMS". See the Figure below.

This is controlling RAMS!

Next chapter >> 2.2 The V-model

From the Source (EN 50126)

The links are described more detailed in chapter 4.3.2 and 4.3.3 in EN 50126:1999:

"Safety and availability are inter-linked in the sense that a weakness in either or mismanagement of conflicts between safety and availability requirements may prevent achievement of a dependable system. The inter-linking of railway RAMS elements, reliability, availability, maintainability and safety is shown in figure 2."
"Attainment of in-service safety and availability targets can only be achieved by meeting all reliability and maintainability requirements and controlling the ongoing, long-term, maintenance and operational activities and the system environment."

A more elaborated version of Figure 2 is given in Figure 5 (not shown here).

When is the Assessor independent?

2008-08-15T14:00:00.000-07:00

The Assessor should be independent from the Supplier and Customer of the product. The needed "Degree of economical and organizational Independency" is decided by the Safety Authority.

As it can be seen above, from Figure 6 in EN50129:2003, the Assessor can not be a part of the same organisation, in which the Project Manager, Designer, Implementer, Verifier or Validator belongs.

Interpretation

The idea of complete "independence" should be substituted with the more flexible concept: "The degree of economical and organizational independence". This concept can furthermore be simplified in to whether it should be in-house or external assessment.

The in-house assessment-divisions are - due to historical reasons - organizations placed inside the large suppliers e.g. Siemens, Bombardier, Alstohm, Alcatel. Because they are organizations inside the suppliers, they have a low "degree of economical and organizational independence". Nevertheless, the Safety Authorities often allows these divisions as Assessors, because they trust the in-house assessment:

The in-house assessment-divisions have a high technical knowledge of the products,
the entire reputation of the companies depend on their integrity and
the alternative external Assessor-companies are just the same paid by the suppliers, which undermines their independence.

External assessment can be performed by inspection companies like DNV, Lloyds and Tüv, which have a high degree of economical and organizational independency, because they do not have any shareholders, but are owned by a foundation.
Another alternative could be the Advisors like Atkins, which have shareholders, but still have a high degree of economical and organizational independence from the traditionally railway Suppliers, Infrastructure owners and Operators.

As a guideline to the minimum needed degree of independence the following criteria can be used: What is the SIL-level of the products safety functions? And how complex is the Project? This interpretation is shown in the table below.

For SIL1/2 or simple projects, the degree of independence it not so important for the safety. In these cases it is often more convenient (faster, less paperwork) with in-house assessment.
For SIL 3/4 and complex projects, it is necessary with a high degree of independence for safety reasons and external Assessors from Assessor-companies should be involved.

Next chapter >> 5.3 Competence of the Assessor?

Focus on the source (/TR 50126/, "Guide to EN 50126")

In TR 50129 ("guide to EN50129") Draft 2006, chapter 7.1.2, is the word "Organization" interpreted to either an external organization or an autonomous in-house organization:

"In general the Safety Assessor or the Safety Assessment Organisation must be accepted by the safety authority. The safety Assessor could be either a member of the in-house organisation (e.g. Assessment Centre) or an independent external organisation. The degree of the independence of the Assessor from the development and RAMS Process must be proven and accepted by the safety authority in charge of the approval. The Assessment organisation should have an accreditation in accordance with EN 45004.

(The mentioned standard EN 45004 contains some requirements to an in-house department regarding economical and organizational independence from the other departments and some professional skills to the Head of the department.)

Mandatory EN standards for ERTMS

2008-08-10T03:43:00.000-07:00

At ERA is shown a List of Mandatory EN Standards.

Please note

The listed standards are only Mandatory for ERTMS/ETCS lines - not for the national lines.

What is the task of the Assessor?

2008-07-31T13:38:00.000-07:00

The Assessor performs independent checks of: The development process (audits) and the products safety functions (spot checks).

It takes some time to really understand the role of the Assessor.

Interpretation

The tasks of the assessor can be divided into two branches. - A judgement - based on evidence - of:

The safety functions implemented in the physical product
The developing process of the product.

Not only one of the branches!

The Assessor should perform audits, based on the Safety plan, of the Quality and Safety management systems of the Supplier, the Infrastructure owner and the Operator and be convinced that these systems works.

To be further convinced, the Assessor can also perform spot checks on detailed technical issues to see that safety functions are correctly implemented. The safety functions key documentation (Hazard Log, Safety Requirements and Safety Case) should be examined too.

As an example of the Assessor work, the Assessor could examine the implemented FRACAS system: What happens if an Operator discloses a failure during testing of a new train? Who decides whether the failure is safety related? Is the role of this person described in the Safety Plan? Is the sub supplier being noticed? Etc.

Next chapter >> 5.2 When is the Assessor independent?

Focus on the Source (EN 50126 and "Guide to EN 50126")

See the quick guide.

Welcome

2008-07-22T06:37:00.000-07:00

Welcome to this blog about the Cenelec standard EN 50126 / IEC 62278.

EN 50126 and IEC 62278 are identical and published by Cenelec and IEC respectively.

EN 50126 is about Safety Management Systems in Railway Projects.

There exists two closely related standards:

EN 50128 / IEC 62279 are about Safety Software Management.
EN 50129 / IEC 62425 are about proving the safety of a product in a Safety Case.

They are originally Cenelec standards, mentioned in most European railway contracts.
They are not particularly readable. You can get a little wiser by reading e.g. the "Guide to EN 50126" (TR 50126-2).

A selected number of the posts on this blog have been compiled and linked into a "Quick guide to EN 50126". These blogs summarizes experiences achieved from:

- Cross-european railway projects,
- teaching in Safety Management and
- being a Cenelec Working Group member.

Other posts are inspired by readers who wrote a mail or just a subject that was discussed that day.

Feel free to use the blog!

Click here for jumping to the first chapter >> 1.1 Definition of Safety Management

Troels Winther