odd nordland_ a critical look at the cenelec railway application standards

8/12/2019 Odd Nordland_ a Critical Look at the CENELEC Railway Application Standards

http://slidepdf.com/reader/full/odd-nordland-a-critical-look-at-the-cenelec-railway-application-standards 1/7

d Nordland: A critical look at the CENELEC Railway Application Standards

p://home.broadpark.no/~onordla/~SINTEF/tekster/A_critical_look_at_rail_standards.htm[2014-03-13 09:15:08]

This text was presented atthe TÜVIT seminar Application of the international standard IEC 61508,

held in January 2003 in Augsburg, Germany.

A critical look at the CENELEC Railway Application

Standards

Odd Nordland SINTEF Telecom and InformaticsTrondheim, Norway

1. Introduction

IEC 61508 (ref. [1]) is a generic standard for the functional safety of electrical/electronic/programmableelectronic safety-related systems. Right at the start, in Part 1, §1.1, it states that "a major objective of this

standard is to facilitate the development of application sector international standards by the technicalcommittees responsible for the application sector ". In §1.2(j) it claims that it " provides general requirements

for E/E/PE safety-related systems where no application sector standards exist ". For railway applications, theEuropean Committee for Electrotechnical Standardization, CENELEC, has produced a number of standards(resp. pre-standards) that address the functional safety of railway applications. To the extent that electrical,electronic or programmable electronic systems are involved, the CENELEC standards can be regarded as the"application sector standards" referred to in IEC 61508. This is the case for the family of standards EN50126 "The specification and demonstration of Reliability, Availability, Maintainability and Safety (RAMS)",

prEN 50129 "Safety related electronic systems for signalling" and EN 50128 "Software for railway controland protection systems" (ref. [2] to [4]). For completeness, EN 50159 parts 1 and 2 "Communication,

signalling and processing systems" (ref. [5] and [6]) should be mentioned, but since they relate very closely

to the three previously mentioned standards, they will not be discussed in further detail here.

IEC 61508 Part 1, §4.1, stipulates that "to conform to this standard it shall be demonstrated that the

requirements have been satisfied to the required criteria...". Now the foregoing statement applies to theE/E/PE system that is supposed to conform to the standard, but it could equally well be applied to thederived application specific standards. In most cases, such standards simply claim compliance with IEC61508, usually by making it a normative reference, but there is no well defined process for actuallydemonstrating compliance of a derived standard with IEC 61508. So what do we do if inconsistencies or contradictions are discovered? The simplest solution is to decide which standard shall have preference incase of conflict. This is not usually stated explicitly, but general practice is to give the application specificstandard priority because it is better focused to the needs and problems of that particular application.

However, it would be better to actually demonstrate consistency between IEC 61508 and application specific"derivatives". Not only would this facilitate removing inconsistencies (and the expensive discussions theygenerate), it would also contribute to the "high level of consistency ... both within application sectors and across application sectors" that IEC 61508 aims at.

2. The CENELEC railway application standards.

The relationship between the main CENELEC railway application standards is indicated in prEN 50129,which explicitly claims to be "the sector specific interpretation of IEC 61508 ". Whilst EN 50126 (RAMS)applies to the total railway system, the remaining standards, prEN 50129 (safety), EN 50128 (software) and

EN 50159 (communication) are applicable to a "complete railway signalling system" including its individualsub-systems and items of equipment.

2.1 EN 50126

http://www.tuvit.de/

http://www.tuvit.de/XS/T1.Home/T2.Suchen/c.020301/sprache.EN/SX/

http://www.tuvit.de/XS/T1.Home/T2.Suchen/c.020301/sprache.EN/SX/

http://www.tuvit.de/





EN 50126 is the top-level document that covers the overall process for the total railway system. It provides baseline information on the subject of RAMS and RAMS engineering, linking RAMS to Quality of Service.It identifies the elements of railway RAMS and "defines a process to support the identification of factorswhich influence the RAMS of railway systems". It then describes "the means to achieve RAMS requirements"and the concepts of risk, safety integrity and the fail-safe concept.

It then goes on to define a management process based on a system life cycle that has a total of 14 phases,from Concept to De-commissioning and Disposal, with detailed descriptions of the objectives, inputs,

requirements, deliverables and verification of each phase. Finally, it has annexes giving an outline of aRAMS specification, an example of a RAMS programme, examples of railway parameters, examples of risk acceptance principles and a guideline for responsibilities within the RAMS process. All of the annexes are"informative", i.e. they are not of a normative character, so compliance with them does not have to bedemonstrated.

2.2 prEN 50129

As previously mentioned, prEN 50129 is the standard that explicitly claims to be " the sector specificinterpretation of IEC 61508 ", which is possibly a reason why it, at the time of writing, has not yet been

finally adopted! It defines "conditions that shall be satisfied in order that a safety-related electronic railwaysystem/subsystem/equipment can be accepted...", requiring a "structured safety justification document, knownas the Safety Case". In the safety case, evidence of quality management, evidence of safety management andevidence of functional and technical safety shall be documented.

In Annex A, which is normative, it "defines the interpretation and use of Safety Integrity Levels" in terms of Tolerable Hazard Rates (THR). Annex B, which is also normative, contains detailed technical requirementsfor assurance of correct functional operation, effects of faults, operation with external influences, safetyrelated application conditions and safety qualification tests.

Annexes C, D and E are each informative and contain procedures for identifying failure modes of hardware,supplementary technical information and techniques, and measures for avoiding or controlling faults.

2.3 EN 50128

This is the standard that handles the software specific aspects that are relevant for the two previouslymentioned standards. It states that it "concentrates on the methods which need to be used in order to provide

software which meets the demands for safety integrity which are placed upon it by these wider considerations".

The standard describes software safety integrity levels and identifies requirements for personnel and their responsibilities, lifecycle issues and documentation. It gives detailed descriptions of objectives, input

documents, output documents and requirements for software requirements specification, architecture, designand implementation, verification and testing as well as software/hardware integration, software validation,quality assurance and maintenance. It also addresses the concept of software configured by application data(e.g. "table driven software"). In annex A, which is normative, it provides criteria for the selection of techniques and measures, depending on the software safety integrity level. In Annex B, which is informative,it gives descriptions and bibliography of most of the techniques identified in annex A.

3. Compliance with IEC 61508

The three principal railway application standards are themselves not entirely consistent, as will be discussedin more detail in the next section. This makes comparing the CENELEC standards with IEC 61508 somewhatdifficult, because for example correct activities are sometimes given wrong names. Nevertheless, it can beshown that much of IEC 61508 is reflected in the CENELEC railway application standards. To this end wemust first take a (very) brief look at the contents of IEC 61508.





The standard is broken up into seven parts, viz.:

1. General requirements2. Requirements for electrical/electronic/programmable electronic safety-related systems3. Software requirements4. Definitions and abbreviations5. Examples of methods for the determination of safety integrity levels6. Guideline on the application of parts 2 and 37. Overview of techniques and measures

Now the last four parts are evidently supplementary information that is intended to facilitate interpretationand application of the first three parts, so for our purposes we can concentrate on those first three parts. A

brief look at the descriptions given in section 2 of this text reveals that the main CENELEC railwayapplication standards follow a similar approach to IEC 61508, with EN 50126 "corresponding" to Part 1,

prEN 50129 "corresponding" to Part 2 and EN 50128 "corresponding" to Part 3.

The first difference is also immediately visible: whereas the various parts of IEC 61508 have mutualdefinitions (in Part 4), each of the CENELEC standards has its own set of definitions. And they are notconsistent with each other (see next section)!

A comparison of EN 50126 with IEC 61508 Part 1 reveals that EN 50126 uses a different life cycle model,which of course results in somewhat differing activities. The basic structure is, however, quite similar. Bothstandards require a systematic and detailed process that starts with a concept and leads to a well defined setof requirements, including clearly defined safety requirements. From there, a process for realisation isdescribed, followed by requirements for operation, maintenance, possible modification or retrofit, and finallysafe decommissioning and disposal. The main differences between the two standards lie in the description of the realisation process, but they are not of such a grave nature that one cannot claim that EN 50126 issubstantially compliant with IEC 61508 Part 1.

For prEN 50129 the comparison with IEC 61508 is slightly more complicated. IEC 61508 Part 2 makesextensive reference to the general requirements in Part 1, so both parts must be taken into account when

examining compliance between prEN 50129 and IEC 61508. Since prEN 50129 is based on the samedevelopment model that was defined in EN 50126, there are of course similar differences with respect to IEC61508. It should be noted that the approach in prEN 50129, Annex A, where safety integrity levels areassociated with Tolerable Hazard Rates, is compliant with IEC 61508 Part 5.

EN 50128 states that it "owes much of its direction to earlier work ... which is now part of IEC 61508 ", so itis not surprising that there is a large degree of similarity between EN 50128 and IEC 61508, Part 3. As withPart 2, Part 3 also makes extensive reference to the general requirements in Part 1, so here too, Part 1 mustalso be considered. One immediately visible difference is that EN 50128 explicitly describes software safetyintegrity levels, whereas IEC 61508 addresses safety integrity levels for the Equipment Under Control("EUC"). The EUC safety integrity levels will be determined by both soft- and hardware, so EN 50128 is

more specific here. But then, that's what one would expect from a sector specific interpretation of IEC61508.

It should be noted that the foregoing paragraphs describe a fairly superficial comparison of the mainCENELEC railway application standards with IEC 61508, and a more rigorous examination could wellreveal considerable differences. Nevertheless, the superficial scrutiny does reveal a degree of compliance thatgoes well beyond simply making IEC 61508 a normative reference, so there is good reason to believe that theCENELEC railway application standards are substantially compliant with IEC 61508.

4. A critical view

Like all standards, the CENELEC railway application standards are a compromise between rivallinginterests. This leaves them open for interpretation and improvement. In addition, they were developed bydifferent working groups in different periods of time, so certain discrepancies and inconsistencies are almostunavoidable. In the following paragraphs, some of the more evident shortcomings will be discussed.





4.1 The life cycle model

The system life cycle as defined in EN 50126 is difficult to map to real life practice and consequentlyseldom, if ever, fully applied. It starts with four phases, namely "Concept ", "System definition and

application conditions", " Risk analysis" and, finally, "System requirements". Now this is certainly a sensibleapproach that will result in a reasonably complete and well defined set of requirements. However, in real life,the starting point is more often than not often a market analysis! What does the market need, and can we

deliver it? From that, something resembling a combination of Concept and System definition is derived, andfrom there the Risk analysis and System requirements can be performed.

However, that is not the only problem with the life cycle model. The next two phases are " Apportionment of

system requirements" followed by " Design and implementation". Now apportionment of requirementsassumes that there is something to apportion them to, so some kind of structure is necessary. This can either

be a modular structure of the system, or simply the decision to use a combination of software, hardware and possibly administrative procedures. That, however, is a design decision, and according to the life cyclemodel design should begin afterwards! So clearly, practitioners are forced to be "creative" and assume that"Design and implementation" means "More detailed design...".

The phase following Design and implementation is " Manufacturing". Where the difference between"Implementation" and "Manufacturing" lies is unclear. Certainly, breaking down a preliminary design into amore detailed design is a form of implementation, but actually producing (manufacturing) the bits and piecesthat are supposed to perform the actual tasks is also part of implementation. Even the next phase," Installation" can be regarded as part of the implementation process, and indeed, in real life projects thesethree phases are often treated in one big lump! This makes demonstrating compliance of a real life projectwith the standards at least complicated. Not impossible, but expensive.

The next two phases are "System validation (including safety acceptance and commissioning)" and "Systemacceptance", followed by "Operation and maintenance". This sequence, too, is almost wishful thinking.Certainly for large railway applications, it is virtually impossible to perform any kind of system validation

without first commissioning the system and performing some kind of "restricted operation". This is also theway things often are done, but once again, this makes documenting compliance with the standards moredifficult.

The remaining phases of the life cycle model are "Operation and maintenance", "Performance monitoring"and " Modification and retrofit ", which are to be regarded as parallel processes, and the last phase of them all," Decommissioning and disposal". For these phases, documenting compliance with the standards must be arather theoretical exercise, because the time scale for the three parallel phases operation, performancemonitoring and modifications can easily be thirty or more years. And nobody knows what environmental or safety requirements will be applicable a generation later, so whatever was planned and documented when thesystem was commissioned may be thoroughly out of date when the system is going to be decommissioned.

This is not reflected in the requirements that the standards pose for these phases.

4.2 Legacy systems

The CENELEC standards have a very clear focus on the development of new systems. For already existingsystems, the standards presume that documentation according to the standards, i.e. a full safety case, isavailable. Then, any upgrade of an existing system is simply a case of " Modification and retrofit " andcovered by the corresponding requirements in the standard.

Unfortunately, the requirements in the standard for modification and retrofit are not particularly detailed. Infact, their quintessence is "update the safety case appropriately". If there never was a safety case (because the

system was developed and commissioned long before the standards were adopted), there's nothing to update,so we have to create an appropriate safety case. But following the life cycle model of the standard is nolonger feasible.

The initial phases of the development model as defined in the standards are not relevant: the requirements are





dictated by the already existing parts of the system, both those parts to be replaced (or upgraded) and thoseto be left unchanged. The realisation phases can probably be conducted along the lines of the standard,although this might well mean that the manufacturer must adapt well proven procedures and routines to whatthe standards demand. This is admittedly a one-time exercise, but it can be expensive, and the reluctance of large, successful organisations to modify their well proven procedures is perfectly understandable.

And finally, the approval process will certainly need to be adapted in order to be practicable for upgradedlegacy systems.

4.3 Terminology

It was pointed out earlier that the three CENELEC standards each have their own set of definitions, and thesedefinitions are not always consistent. Take for example the terms verification and validation.

EN 50126 has the following definitions:

Validation = "Confirmation by examination and provision of objective evidence that the particular requirements for a specific intended use have been fulfilled "Verification = "Confirmation by examination and provision of objective evidence that the specified

requirements have been fulfilled "whilst EN 50128 uses:Validation = "activity of demonstration, by test and analysis, that the product meets in all respects itsspecified requirements"Verification = "activity of determination, by analysis or test, that the output of each phase of the life-

cycle fulfils the requirements of the previous phase"

Now a definition is really just a special case of a specification, and like any good specification it should onlysay "what", but not "how" nor "when", "why" etc. So in order to extract the actual contents of the abovedefinitions, we remove the superfluous frills, which makes the same definitions become:EN 50126:

Validation = "Confirmation... that the... requirements for a specific... use have been fulfilled "Verification = "Confirmation... that the specified requirements have been fulfilled "

EN 50128:Validation = "...demonstration... that the product meets... its specified requirements"Verification = "...determination... that the output of each phase... fulfils the requirements ..."

Now here we see that the EN 50126 definitions of verification and validation are effectively the same. Itshould be noted that the definitions in EN 50126 are identical to the definitions in IEC 61508.

More interestingly, the definition of verification in EN 50126 is essentially the same as the definition of validation in EN 50128 and vice versa! These two standards have both been adopted and are applicable, so

the confusion is "official". (A more detailed discussion of this subject can be found in ref. [7]).

The term "error" is another example. Whilst EN 50126 doesn't define the word at all, both EN 50128 and prEN 50129 use the following definition:

Error = "a deviation from the intended design which could result in unintended system behaviour or failure"

Based on that definition, there can be no such thing as "human error" or "operational error", not to mentionthe "design errors" that annex A of the standard mentions! It should be noted here that IEC 61508 uses adifferent definition.

Only prEN 50129 defines the term design:

Design = "the activity applied in order to analyse and transform specified requirements intoacceptable design solutions which have the required safety integrity"

Now applying the same method we just used for the terms validation and verification, we remove the





superfluous frills from this definition and getDesign = "the activity... to... transform... requirements into... design..."

So design is a design activity!

The preceding examples show that the definitions in the standards (including IEC 61508!) are inconsistent,incomplete and sometimes even downright wrong. In addition, the way the terms are used within the texts isnot always compliant with the definitions that are given in the standards. So there is certainly a need for thequality assurance exercise of checking that terms are used as defined, and - more importantly - that thedefinitions are sensible.

4.4 New technologies

Certain aspects of modern systems are not addressed by the standards at all. With increasing cost pressure,there is a growing desire to use mass produced, general purpose components, so called Commercial Off TheShelf products (COTS). These products are typically not originally designed with a safety related applicationin mind, so their documentation will seldom be anywhere near the demands that the CENELEC railwayapplication standards stipulate. Incorporating such systems into a safety related application then becomes adifficult exercise of demonstrating that they will be safe enough in a particular environment and application.It won't always succeed (ref. [8]). The standards do not address this matter at all, so the criteria that were

used to determine if a COTS product was suitable can vary considerably from system to system.

In the field of software development, new techniques and languages are coming. Extreme programming is anexample of such a new technique that can probably be adapted to safety related applications (ref. [9]), butthis will require at least a "flexible" interpretation of the standards' demands on documentation.

There are also new programming languages and tools emerging that didn't exist when the standards werewritten and consequently could never be addressed by the standards. EN 50128 identifies certain

programming languages as either " Recommended ", " Highly Recommended " or " Not Recommended " in thenormative annex A, but the list was far from complete, even when EN 50128 was written, and today there areseveral application specific languages that are not mentioned in the list, but they are proven in use. And as

experience grows, and more and better tools are developed, the demands of EN 50128 will become more andmore obsolete.

EN 50128 addresses "Systems configured by application data", and requires that tools and procedures for data preparation are developed "in accordance with (the) standard in parallel with the generic software and hardware for the system". Now this is based on the assumption that the system uses application data as

parameters for performing statically defined operations. The idea of embedded processes that generate theoperations, based on more complex data than just parameters for those operations, is not covered by thestandard.

It should also be noted that the requirement that tools and procedures shall be developed "in parallel with...

the system" does not take into consideration the possibility of re-using generic processes and tools for data preparation that have been developed completely independently of the system. In those cases wheremanufacturers have developed such procedures and tools, it is natural to use them again and again, possiblyrefining and perfecting them in the process. For such generic tools and procedures, even identifying a(software) safety integrity level will be a problem, because the classification will depend on the data that is

being produced and the way it is going to be used. This may vary from application to application, particularly if a sufficiently high degree of flexibility is maintained.

5. Conclusion

The CENELEC railway application standards EN 50126, prEN 50129 and EN 50128 together can beregarded as an "application specific" interpretation of IEC 61508. A rather superficial comparison shows thatthe CENELEC railway application standards appear to satisfy the demands that IEC 61508 makes, althoughthis paper does not claim to present or report a rigorous confirmation of such compliance.




The CENELEC standards (and IEC 61508 too) have their faults and weaknesses. There are inconsistenciesand contradictions that must be rectified, and development methods and tools are changing, and with themthe development life cycle, which so strongly influences the structure and demands of the standards, will alsochange.

Some of the more evident weaknesses of the CENELEC railway application standards have been describedhere. Now this should not give the impression that the standards are "bad" or unusable. Describing their

positive sides would have far exceeded the scope of this paper, but there is nevertheless considerable roomfor improvement. This must be reflected in future modifications of the standards. Until then, it will be up tothe railway community to find solutions and interpretations that are practicable without compromising safety.

6. References

1. IEC 61508; Functional safety of electrical/electronic/programmable electronic safety-related systems;IEC; 1998

2. EN 50126:1999; Railway Applications - The specification and demonstration of Reliability,Availability, Maintainability and Safety (RAMS); CENELEC; 1999

3. prEN 50129:2000; Railway applications - Safety related electronic systems for signalling; CENELEC;

20004. EN 50128:2001; Railway Applications - Software for railway control and protection systems;CENELEC; 2001

5. EN 50159-1:2001; Railway Applications - Communication, signalling and processing systems - Part 1:Safety-related communication in closed transmission systems; CENELEC; 2001

6. EN 50159-2:2001; Railway Applications - Communication, signalling and processing systems - Part 2:Safety-related communication in open transmission systems; CENELEC; 2001

7. O.Nordland: "V&V - Veridation or Valification?"in Nagib Callaos, John Porter, Naphtali Rishe (editors):The 6th World Multiconference on Systemics, Cybernetics and InformaticsProceedings, Volume VII, pp. 261-266

(c) International Institute of Informatics and Systemics,Orlando, FL 32837, USA; 2002ISBN 980-07-8150-1

8. Linda Kristiansen: "COTS components in safety critical systems"; Diploma thesis, NTNU, Trondheim,2002

9. Liv Ryssdal Thorsen: "Extreme programming in safety related systems"; Diploma thesis, NTNU,Trondheim, 2002

odd nordland_ a critical look at the cenelec railway application standards

Documents