Putting it all together

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?



Read more...

Configuration Management

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.

Read more...

Failure Reporting And Corrective Action System (FRACAS)

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.



Read more...

Supervising of hazard indicators

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.



Read more...

Results from former poll's

Poll 7

Can the Safety Management system be merged into the Quality Management system?

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

The Safety Management System "produces" the Safety plan that defines task, roles and procedures. Such input is well-placed in the Quality Management system in an Organization. From this point of view, the answer is a plain 'Yes'. However, it has some drawbacks concerning the Safety Approval work if the two systems are merged into one system without a possibility to distingiush between Safety and Quality tasks: Any change in any procedure in the Quality System must subsequently be presented to the Safety Authority because it potentially have an impact on Safety.
But the answer is 'Yes'.

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.


Read more...

Does the Guide add information cp. to the blog?

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".



Read more...

Safety approval process

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).





Read more...

How does the Notified Body fit in?

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.



Read more...

Hazard log, risk analysis and safety requirements

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:





Read more...

The Safety Case

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"

Read more...

The Safety Plan

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.



Read more...

The key documents

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.



Read more...

Verification, Validation and Assessment

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.



Read more...

The Safety Management Circle

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)."



Read more...

How to measure "Risk"

"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"



Read more...

Control the Risk level

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.”

Read more...

Definition of Safety Management

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.



Read more...

The V-model

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.



Read more...

RAMS and how to control it

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).

Read more...