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

The System Definition

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"



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