overview of the application notes the railway-level issues and the software and en 50128 application notes

1. Overview of the Application Notes YBUG5, 26th February 2003Bruce Elliott, Chief Engineer

3. What is an application note? Supplementary advice to YB3 But later integration is not precluded Not a standard Advice from the industry to the industry All sectors of the industry Currently published on www.yellowbook-rail.org.uk But could be published on paper later Part of a continuing initiative

4. How are they produced? Yellow Book Steering Group (YBSG) agrees remit YBSG invites members to join editorial committee (YBEC) Praxis Critical Systems drafts note under YBEC supervision When YBEC are satisfied, note goes to YBSG for endorsement YBSG may take advice from an independent reviewer Note is published Note is revised in response to industry feedback The same process as the Yellow Book

5. Editorial Committees YBEC-SW Paul Cheeseman, Lloyds Register-MHA Trevor Cockram, Praxis Critical Systems John Corrie, Mott MacDonald Peter Duggan, Invensys Bruce Elliott, Atkins Rail Simon Errington, Lloyd's Register MHA Richard Imhoff, Alstom Iain Johnston, CSE International Ian Shannon, Atkins Rail Chris Shepperd, Siemens Jeremy Whitley, Bombardier Transportation Author Paul Leader, Praxis Critical Systems Independent Reviewer Jeff Allan, Railway Safety YBEC-RL Richard Allan, Network Rail Andy Bourne, London Underground Limited Bob Brewer, Praxis Critical Systems Limited John Corrie, Mott MacDonald Paul Cheeseman, Lloyds Register MHA Limited Stephen Denniss, Bechtel Bruce Elliott, Praxis Critical Systems Limited Ali Hessami, WS Atkins Rail Limited Author Paul Leader, Praxis Critical Systems Independent Reviewer David Waboso, Nichols

6. Status Railway-Level Issues � ISSUED Kick off meeting Mar 02 Published Jan 02 Software & EN50128 � ISSUED Kick off meeting Apr 02 Published Feb 03 Human Error - UNDERWAY See later Independent Safety Assessment � UNDERWAY See later

7. Railway-Level Issues - Motivation Rail shares the following curse with many other industries: �When you connect together several systems to accomplish one objective it is unfortunately the case that the ensemble does not always do what you want, even though each system was built correctly, as far you could tell. As systems become more and more complicated, the likelihood of nasty surprises increases, unless you do something about it.� But in rail this problem is flavoured by: Some difficulties in specifying what is wanted A tendency to rely on unwritten �custom and practice� The fact that the railway is designed so that systems mitigate each other�s hazards

8. Railway-Level Issues � Assumptions, Dependencies and Caveats Assumptions made about the rest of the world, including people and organisations as well as the physical railway. for instance tolerances on the supply voltage someone will have to check that they hold when the system goes into service and continue to hold for the rest of its life (or deal with the situation if they do not). Dependencies agreements that people will act before a system can safely be put into service for example, upgrades to air conditioning before a computerised signalling system is installed Caveats agreements that people must respect after a system is put into operation for it to remain safe for instance, a certain inspection regime

9. Railway-Level Issues - Content Guidance on some aspects of ensuring that railway systems work together to control risk or on avoiding some common problems in this area Primarily for people introducing new systems or co-ordinating ESM activities at the railway level but also for independent safety assessors and safety authorities Contents Specification Issues The Problem Guidance Assumptions, Dependencies and Caveats Introduction Identifying ADCs that you will place on others Identifying ADCs that others will place on you Documenting ADCs Resolving ADCs Failure Detection and Modelling Introduction Failure detection Modelling failure and its detection Estimation of time at risk Appendix: Example Specification Topics 13 pages (excluding wrapping)

10. Software and EN50128 - Motivation YB3 provides little guidance on software; Section 9.8 of volume 2 refers to EN 50128, but EN 50128 is being revised EN 50128 does not always provide enough guidance to deal with the problems that practitioners face: It assumes a procedural programming language, for example There is more that can usefully be said about configuring software, specifying software and using COTS There are some inconsistencies between YB3 and the CENELEC standards Although EN 50128:2003 is expected to remove some of these There are some technical problems with software SILs EN 50128 promotes a qualitative approach to software integrity but the issue of whether software failure can be modelled probabilistically is an issue of contention.

11. Software and EN50128 - Content Guidance on some aspects of managing the development and use of software and avoiding some common problems Written for those involved in planning a safety argument for software; specifying, delivering or configuring software but also for independent safety assessors and safety authorities Written to complement, not compete with EN 50128