Safety-Related Application Conditions – A Balance between Safety Relevance and Handicaps for Applications

  • Friedemann Bitsch
  • Ulrich Feucht
  • Huw Gough
Part of the Lecture Notes in Computer Science book series (LNCS, volume 5775)


Railway standards prescribe the use of Safety-related Application Conditions (SACs). SACs are demands to be observed when using a safety related system or a sub-system. The use of SACs can, however, easily be associated with difficulties. SACs of sub-systems can imply high efforts regarding their fulfillment at system level. Furthermore, SACs at sub-system level may become very obstructive for the user of the sub-system, if the safe application on system level has strong restrictions. Additionally, a large number of SACs may be very difficult to manage. In this way, SACs may obstruct the introduction of a system or a sub-system into the field. Particular hazards could arise from SACs, if they are formulated ambiguously, so that the originally intended safety-related measures are not taken at all. This paper presents the objectives and benefits of SACs and depicts difficulties and challenges associated with the use of SACs. The paper not only explains what should be the SAC content but also the quality criteria, the conditions for SAC creation and SAC fulfillment are described. The SAC management process introduced at Thales Rail Signalling Solutions GmbH is outlined. On the one hand, this process shall support the quality of SACs and on the other hand reduce the effort for SAC creation, fulfillment and evidence.


Safety-related Application Conditions SAC quality conditions for defining SACs process for defining and complying with SACs 


Unable to display preview. Download preview PDF.

Unable to display preview. Download preview PDF.


  1. 1.
    CENELEC: Railway applications – Communication, signalling and processing systems – Safety related electronic systems for signalling, EN50129:2003-05-07 (2003) Google Scholar
  2. 2.
    Reuters: Geldstrafen im Transrapid-Prozess verhängt, 2008-05-23 (2008) Google Scholar
  3. 3.
    Dörner, D.: The Logic of Failure: Why Things Go Wrong and What We Can Do To Make Them Right. Metropolitan Books. Henry Holt and Co., New York (1996)Google Scholar
  4. 4.
    Hewison, N.S.: Book Review: The Logic of Failure: Why Things Go Wrong and What We Can Do To Make Them Right. Group Facilitation: A Research and Applications Journal 3, 86–89 (spring 2001)Google Scholar
  5. 5.
    International Electrotechnical Commission: Functional Safety of Electrical/Electronic/ Programmable Electronic Safety Related Systems, IEC 61508. Geneva, Switzerland (2000) Google Scholar
  6. 6.
    Bate, I., Bates, S., Hawkins, R., Kelly, T., McDermid, J.: Safety case architectures to complement a contract-based approach to designing safe systems. In: 21st International System Safety Conference, System Safety Society (2003)Google Scholar
  7. 7.
    Abran, A., Moore, J.W. (eds.): SWEBOK: Guide to the Software Engineering Body of Knowledge. IEEE Computer Society, Los Alamitos (2004)Google Scholar
  8. 8.
    Lauber, R., Göhner, P.: Prozessautomatisierung II. Springer, Heidelberg (1999)CrossRefGoogle Scholar
  9. 9.
    CENELEC: Railway applications – Communications, signalling and processing systems – Software for railway control and protection systems, EN50128:2001-05-15 (2001) Google Scholar

Copyright information

© Springer-Verlag Berlin Heidelberg 2009

Authors and Affiliations

  • Friedemann Bitsch
    • 1
  • Ulrich Feucht
    • 2
  • Huw Gough
    • 2
  1. 1.Informatik Consulting Systems AGStuttgartGermany
  2. 2.Thales Rail Signalling Solutions GmbHStuttgartGermany

Personalised recommendations