Software Certification: Is There a Case against Safety Cases?

  • Alan Wassyng
  • Tom Maibaum
  • Mark Lawford
  • Hans Bherer
Part of the Lecture Notes in Computer Science book series (LNCS, volume 6662)

Abstract

Safety cases have become popular, even mandated, in a number of jurisdictions that develop products that have to be safe. Prior to their use in software certification, safety cases were already in use in domains like aviation, military applications, and the nuclear industry. Argument based methodologies/approaches have recently become the cornerstone for structuring justification and evidence to support safety claims. We believe that the safety case methodology is useful for the software certification domain, but needs to be tailored, more clearly defined, and more appropriately structured in analogy with regulatory regimes in classical engineering disciplines. This paper presents a number of reasons as to why current approaches to safety cases do not satisfy essential attributes for an effective software certification process and proposes improvements based on lessons learned from other engineering disciplines. In particular, the safety case approach lacks the highly prescriptive and domain specific nature that can be seen in other engineering specialities, in terms of engineering and analysis methods to be applied in generating the relevant evidence. Safety case approaches and corresponding methods should aim to achieve the levels of precision and effectiveness of engineering methods underpinning regulatory regimes in other engineering disciplines.

Preview

Unable to display preview. Download preview PDF.

Unable to display preview. Download preview PDF.

References

  1. 1.
    Kornecki, A., Zalewski, J.: Certification of software for real-time safety-critical systems: state of the art. Innovations in Systems and Software Engineering 5, 149–161 (2009), http://dx.doi.org/10.1007/s11334-009-0088-1, doi:10.1007/s11334-009-0088-1CrossRefGoogle Scholar
  2. 2.
    CBC Staff: Infusion pumps recalled in U.S. but not Canada. CBC News Online (May 2010), http://www.cbc.ca/news/health/story/2010/05/04/con-baxter-pump.html
  3. 3.
    Poulson, K.: Known software bug disrupts brain-tumor zapping. Wired (October 2009), http://www.wired.com/threatlevel/2009/10/gamma
  4. 4.
    Bogdanich, W.: Radiation offers new cures, and ways to do harm. The New York Times Online (January 2010), http://www.nytimes.com/2010/01/24/health/24radiation.html
  5. 5.
    Bogdanich, W., Rebelo, K.: A pinpoint beam strays invisibly, harming instead of healing. The New York Times Online (December 2010), http://www.nytimes.com/2010/12/29/health/29radiation.html
  6. 6.
    Software Certification Consortium: Software Certification Consortium Charter (Draft) (2010)Google Scholar
  7. 7.
    Jackson, D., Bloch, J., Dewalt, M., Gardner, R., Lee, P., Lipner, S.B., Perrow, C., Pincus, J., Rushby, J., Sha, L., Thomas, M., Wallsten, S., Woods, D.: Software for Dependable Systems: Sufficient Evidence? National Academies Press, Washington (2007)Google Scholar
  8. 8.
    Bishop, P., Bloomfield, R.: A methodology for safety case development. In: Redmill, F., Anderson, T. (eds.) Industrial Perspectives of Safety-critical Systems: Proceedings of the Sixth Safety-critical Systems Symposium, Birmingham, UK, pp. 194–203. Springer, Heidelberg (1998)CrossRefGoogle Scholar
  9. 9.
    Rushby, J.: A safety-case approach for certifying adaptive systems. In: Proceedings of AIAA Infotech@Aerospace, Seattle, WA, American Institute of Aeronautics and Astronautics (April 2009)Google Scholar
  10. 10.
    Panesar-Walawege, R., Sabetzadeh, M., Briand, L., Coq, T.: Characterizing the chain of evidence for software safety cases: A conceptual model based on the IEC 61508 standard. In: 2010 Third International Conference on Software Testing, Verification and Validation, pp. 335–344. IEEE, Los Alamitos (2010)CrossRefGoogle Scholar
  11. 11.
    Fong, E., Kass, M., Rhodes, T., Boland, F.: Structured assurance case methodology for assessing software trustworthiness. In: 2010 Fourth International Conference on Secure Software Integration and Reliability Improvement Companion (SSIRI-C), pp. 32–33. IEEE, Los Alamitos (2010)CrossRefGoogle Scholar
  12. 12.
    Graydon, P.J., Knight, J.C., Strunk, E.A.: Assurance based development of critical systems. In: DSN 2007: Proceedings of the 37th Annual IEEE/IFIP International Conference on Dependable Systems and Networks, pp. 347–357. IEEE Computer Society, Washington, DC, USA (2007)Google Scholar
  13. 13.
    Bloomfield, R., Bishop, P.: Safety and assurance cases: Past, present and possible future - an adelard perspective. In: Dale, C., Anderson, T. (eds.) Making Systems Safer, Proceedings of the Eighteenth Safety-Critical Systems Symposium, Bristol, UK, pp. 51–67 (February 2010)Google Scholar
  14. 14.
    FDA Staff: Guidance for Industry and FDA Staff Total Product Life Cycle: Infusion Pump - Premarket Notification [510(k)] Submissions DRAFT GUIDANCE. U.S. Department Of Health and Human Services: Food and Drug Administration, Center for Devices and Radiological Health (April 2010)Google Scholar
  15. 15.
    Parnas, D.L.: Software engineering programs are not computer science programs. IEEE Software 16(6), 19–30 (1999)CrossRefGoogle Scholar
  16. 16.
    Canadian Portland Cement Association Ottawa, Ontario, Canada: CSA CAN3 A23.3 M94 Concrete Design Handbook (1994)Google Scholar
  17. 17.
    IEC 61508: Functional safety of electrical/electronic/programmable electronic (E/E/EP) safety-related systems: Parts 3 and 7, International Electrotechnical Commission (IEC) (2010)Google Scholar
  18. 18.
    Vincenti, W.G.: What Engineers Know and How They Know It: Analytical Studies from Aeronautical History. The Johns Hopkins University Press, Baltimore (1993)Google Scholar
  19. 19.
    High, K.M., Kelly, T.P., Mcdermid, J.A.: Safety case construction and reuse using patterns. In: 16th International Conference on Computer Safety and Reliability (SAFECOMP 1997), pp. 55–69. Springer, Heidelberg (1997)Google Scholar
  20. 20.
    Parsons, T.: What is an argument? The Journal of Philosophy 93(4), 164–185 (1996)CrossRefGoogle Scholar
  21. 21.
    Common Criteria for Information Technology Security Evaluation: Part 1: Introduction and general model. CSE, SCSSI, BSI, NLNCSA, CESG, NIST, NSA, Version 3.1 Revision 3 (July 2009)Google Scholar
  22. 22.
    Common Criteria for Information Technology Security Evaluation: Evaluation methodology, Version 3.1, Revision 3 (July 2009)Google Scholar
  23. 23.
    Parnas, D.L., Asmis, G.J.K., Madey, J.: Assessment of safety-critical software in nuclear power plants. Nuclear Safety 32(2), 189–198 (1991)Google Scholar
  24. 24.
    Archinoff, G.H., Hohendorf, R.J., Wassyng, A., Quigley, B., Borsch, M.R.: Verification of the shutdown system software at the Darlington nuclear generating station. In: International Conference on Control and Instrumentation in Nuclear Installations, Glasgow, UK, The Institution of Nuclear Engineers (May 1990)Google Scholar
  25. 25.
    Wassyng, A., Lawford, M.: Lessons learned from a successful implementation of formal methods in an industrial project. In: Araki, K., Gnesi, S., Mandrioli, D. (eds.) FME 2003. LNCS, vol. 2805, pp. 133–153. Springer, Heidelberg (2003)CrossRefGoogle Scholar
  26. 26.
    Joannou, P., et al.: Standard for Software Engineering of Safety Critical Software. CANDU Computer Systems Engineering Centre of Excellence Standard CE-1001-STD Rev. 1 (January 1995)Google Scholar

Copyright information

© Springer-Verlag Berlin Heidelberg 2011

Authors and Affiliations

  • Alan Wassyng
    • 1
  • Tom Maibaum
    • 1
  • Mark Lawford
    • 1
  • Hans Bherer
    • 1
  1. 1.McMaster Centre for Software Certification Faculty of EngineeringMcMaster UniversityHamiltonCanada

Personalised recommendations