This text was presented at
the TÜVIT seminar Application of the international standard IEC 61508,
held in January 2003 in Augsburg, Germany.
Odd Nordland
SINTEF Telecom and Informatics
Trondheim, Norway
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 the E/E/PE system that is supposed to conform to the standard, but it could equally well be applied to the derived application specific standards. In most cases, such standards simply claim compliance with IEC 61508, usually by making it a normative reference, but there is no well defined process for actually demonstrating 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 in case of conflict. This is not usually stated explicitly, but general practice is to give the application specific standard 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 they generate), it would also contribute to the "high level of consistency ... both within application sectors and across application sectors" that IEC 61508 aims at.
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 a RAMS 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 be demonstrated.
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 requirements for assurance of correct functional operation, effects of faults, operation with external influences, safety related 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.
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, design and 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.
The standard is broken up into seven parts, viz.:
Now the last four parts are evidently supplementary information that is intended to facilitate interpretation and 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 railway application 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 mutual definitions (in Part 4), each of the CENELEC standards has its own set of definitions. And they are not consistent 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. Both standards require a systematic and detailed process that starts with a concept and leads to a well defined set of requirements, including clearly defined safety requirements. From there, a process for realisation is described, followed by requirements for operation, maintenance, possible modification or retrofit, and finally safe 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 is substantially compliant with IEC 61508 Part 1.
For prEN 50129 the comparison with IEC 61508 is slightly more complicated. IEC 61508 Part 2 makes extensive 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 same development model that was defined in EN 50126, there are of course similar differences with respect to IEC 61508. It should be noted that the approach in prEN 50129, Annex A, where safety integrity levels are associated 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 it is not surprising that there is a large degree of similarity between EN 50128 and IEC 61508, Part 3. As with Part 2, Part 3 also makes extensive reference to the general requirements in Part 1, so here too, Part 1 must also be considered. One immediately visible difference is that EN 50128 explicitly describes software safety integrity 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 IEC 61508.
It should be noted that the foregoing paragraphs describe a fairly superficial comparison of the main CENELEC railway application standards with IEC 61508, and a more rigorous examination could well reveal considerable differences. Nevertheless, the superficial scrutiny does reveal a degree of compliance that goes well beyond simply making IEC 61508 a normative reference, so there is good reason to believe that the CENELEC railway application standards are substantially compliant with IEC 61508.
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 requirements assumes 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 cycle model 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 a more detailed design is a form of implementation, but actually producing (manufacturing) the bits and pieces that 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 these three phases are often treated in one big lump! This makes demonstrating compliance of a real life project with the standards at least complicated. Not impossible, but expensive.
The next two phases are "System validation (including safety acceptance and commissioning)" and "System acceptance", 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 the way things often are done, but once again, this makes documenting compliance with the standards more difficult.
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 a rather theoretical exercise, because the time scale for the three parallel phases operation, performance monitoring 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 the system 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.
Unfortunately, the requirements in the standard for modification and retrofit are not particularly detailed. In fact, 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 no longer 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 those to 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 what the 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 upgraded legacy systems.
EN 50126 has the following definitions:
Now a definition is really just a special case of a specification, and like any good specification it should only say "what", but not "how" nor "when", "why" etc. So in order to extract the actual contents of the above definitions, we remove the superfluous frills, which makes the same definitions become:
EN 50126:
Now here we see that the EN 50126 definitions of verification and validation are effectively the same. It should 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:
Only prEN 50129 defines the term design:
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 is not always compliant with the definitions that are given in the standards. So there is certainly a need for the quality assurance exercise of checking that terms are used as defined, and - more importantly - that the definitions are sensible.
In the field of software development, new techniques and languages are coming. Extreme programming is an example of such a new technique that can probably be adapted to safety related applications (ref. [9]), but this 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 were written and consequently could never be addressed by the standards. EN 50128 identifies certain programming languages as either "Recommended", "Highly Recommended" or "Not Recommended" in the normative annex A, but the list was far from complete, even when EN 50128 was written, and today there are several 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 and more 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 the operations, based on more complex data than just parameters for those operations, is not covered by the standard.
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 where manufacturers have developed such procedures and tools, it is natural to use them again and again, possibly refining 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.
The CENELEC standards (and IEC 61508 too) have their faults and weaknesses. There are inconsistencies and contradictions that must be rectified, and development methods and tools are changing, and with them the development life cycle, which so strongly influences the structure and demands of the standards, will also change.
Some of the more evident weaknesses of the CENELEC railway application standards have been described here. 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 room for improvement. This must be reflected in future modifications of the standards. Until then, it will be up to the railway community to find solutions and interpretations that are practicable without compromising safety.