Making Systems Safer

Suitable formalisms could allow the arguments of a safety case to be checked mechanically. We examine some of the issues in doing so.

This position paper identifies a potential problem with the evolution of software controlled safety critical systems. It observes that the rapid growth of bureaucracy in society quickly spills over into rules for behaviour. Whether the need for the rules comes first or there is simple anticipation of the need for a rule by a bureaucrat is unclear in many cases. Many such rules lead to draconian restrictions and often make the existing situation worse due to the presence of unintended consequences as will be shown with a number of examples.

In science and engineering, the effects of such bureaucracy are generally mitigated because the rules naturally devolve from the exercise of the scientific method whereby evidence leads to policy and lasting benefit. In the absence of the scientific method (which is usually the case in software systems development), policy flourishes like weeds without the constraints of reality. In software con-trolled systems, any consequent unintended side-effects could be lethal.

For developing embedded safety critical systems, industrial companies have to face increasing complexity and variety coupled with increasing regulatory constraints, while costs, performances and time to market are constantly challenged. This has led to a profusion of enablers (new processes, methods and tools), which are neither integrated nor interoperable because they have been developed more or less independently (addressing only a part of the complexity: e.g. Safety) in the absence of internationally recognized open standards. CESAR has been established under ARTEMIS, the European Union’s Joint Technology Initiative for research in embedded systems, with the aim to improve this situation and this pa-per will explain what CESAR’s objectives are, how they are expected to be achieved and, in particular, how current best practice can ensure that safety engineering requirements can be met.

This paper focuses on the approaches used in safety cases for software based systems. We outline the history of approaches for assuring the safety of software-based systems, the current uptake of safety and assurance cases and the current practice on structured safety cases. Directions for further development are discussed.

System failures in safety-critical domains can lead to harmful consequences for humans, the environment and for the system itself. The field of ‘system safety’ provides relief and aims at identifying possible risks already during the project planning phase of the system development. This requires modern project management support. The realisation of innovative ideas in software often in-creases the complexity and increasingly leads to dangerous system states or even system failures that put the safety of the system at risk.

This paper addresses the development of an integrated project management approach for software development projects in safety-related domains. The core elements are project management, the process maturity model SPICE and system safety in general based on IEC 61508. The project management process sets the framework. The development life cycle and the safety life cycle are integrated into this process model. The result is an integrated project management life cycle for safety-related software development projects.

This integrated project management life cycle offers a generic approach on a high level of abstraction in order to cover a broad range of applications. It gives project managers and furthermore the whole project team the opportunity to influence quality and system safety in a preventative manner.

Within Logica UK, safety-related projects are run in a variety of ways depending on the constraints imposed and how the risks and mitigations are owned and handled. A total of eight different types of project development patterns have been identified and this paper discusses each type. A simple decision tool has been developed based on the patterns which is used as an aid in deciding how to bid a safety project, allowing tradeoffs between risk ownership, development methods and cost to be assessed.

IEC 61508 is often but erroneously thought of as applying only to the process industries. This paper considers how the standard can be applied to the safety management of air traffic management and control systems, examining areas where the standard is helpful and other areas where it is less useful and requires some augmentation. By considering the set of aircraft involved in controlled movements at any one time as the Equipment Under Control, a framework is provided, using the principles in IEC 61508, for deriving functional, performance and integrity requirements for the components of the overall control system.

Phileas, developed by Advanced Public Transportation Systems (APTS) is a new concept for comfortable high frequency passenger mass transport. Its unique safety requirements impose a serious challenge for the development of a safe electronic guidance system. In particular, the standard systems engineering methodologies applied need to be tailored in order to comply with the CENELEC railway standards EN50126, EN50128 and EN50129. From formal and traceable requirements capture to the rigorous verification and validation processes, the integrated development approach must provide not only a functional system in compliance with all stakeholder needs, but also evidence of quality and safety management in all phases of the life cycle. Once certification for Phileas is achieved, the chances for APTS to become an important player in the development of safe next generation vehicle intelligence are significantly increased.

Defence Standard 00-56 Issue 4 is the current contractual safety standard for UK MOD projects. It requires the production of a structured argument, supported by diverse evidence, to show that a system is safe for a defined purpose within a defined environment. This paper introduces a Standard of Best Practice which has been produced by the Software Systems Engineering Initiative to provide guidance for software compliance with Defence Standard 00-56 Issue 4.

Traditionally a medical device is viewed as a standalone hospital system with a carefully segregated private network running on specialist bespoke equipment, managed by highly skilled medical technicians. The regulations in force implementing the Medical Devices Directive support this view. The emerging reality in the modern health organisation is a patient-centric shared electronic record, networked over the organisation’s local area network, with medical devices hanging as endpoints off that shared network and contributing to the central pool of patient data – all the time reliant on the shared network services. The IEC80001 standard has been developed to provide guidance on the measures that the medical devices community considers are required best practice in order to ensure that the integrity and safety of the interconnected medical device is not compromised. This in itself is both a laudable and pragmatic action. The question that it immediately prompts for those left with the new and very real task of ‘compliance’ with the new standards – primarily the over worked health organisation’s IT department, is ‘what impact does this have on me?’. A number of papers exist prepared from a health-system-supplier standpoint. This paper is principally focused on examining the ramifications of IEC80001 from a health organisation stand point. This paper seeks to identify the areas where a health organisation may expect to have their business-as-usual IT processes impacted, and offers a simple framework to address these challenges.

Competence plays an important role in ensuring functional safety. Safety-related systems rely on a complex mix of hardware, software, human fac-tors and safety management systems. This paper takes a look at the requirements for such a Competence Management System, and gives information on a practical approach to competence implemented by Invensys Rail (UK).

The continuing increases in electronic complexity, and the continuing shrinking of the feature sizes in silicon integrated circuits, has made the normal testing-based approach to EMC inadequate where safety is concerned.

So the new discipline of ‘EMC for Functional Safety’ has had to be developed to help maintain tolerable levels of safety risks.

The IET’s new Guide comprehensively describes practical and cost-effective procedures for both management and engineering, which can be used right away to help to save lives and reduce injuries, wherever electronic technologies are used in safety-implicated products, systems or installations of any type.

It includes useful checklists to aid project management, design and compliance assessment.

For a number of reasons, real financial savings can generally be expected when the Guide is correctly applied, as well as a significant reduction in financial risks.

Independent safety assessment is widely used as a means of obtaining assurance of safety for safety related systems. Experience of both Independent Safety Assessors (ISAs) and users of ISAs, together with growing appreciation of the responsibilities and potential liabilities of ISAs, suggested that there would be safety assurance and other benefits from identifying good practice for ISAs. A voluntary Code of Practice for Independent Safety Assessors (ISAs), together with a supporting Competency Framework for ISAs, has therefore been developed by the ISA Working Group of the Institution of Engineering and Technology (IET) and the British Computer Society (BCS).

The Code of Practice consists of ten requirements and associated amplification and guidance. They address both technical and non-technical aspects of ISA work. The competence requirement is developed in the Competency Framework for ISAs. Both the Code of Practice and the Competency Framework are intended to be practical tools appropriate for wide adoption across the many technical disci-plines and domains in which ISAs work. The ISA Working Group encourages their pragmatic use to help establish good practice in ISA work and discourages their use as checklists for formal compliance.

This paper describes the scope and content of the Code of Practice and Compe-tency Framework together with examples of how they can be used by users and employers of ISAs as well as by ISAs themselves.

COTS have increasingly been used by industrial practice as a means of maintaining low development costs of a product, whilst offering significant capability upgrades. COTS are multipurpose products driven by commonly used functionality. However, being general purpose products raises certain challenges regarding their ability to be certified. Previously used (process-based) standards stipulated a process that the product needed to adhere to. This involved production of a generic set of evidence known as the certification pack (CertPack). Being the product of a generic test process, the available (CertPack) COTS evidence may not be sufficient or suitable to support the developers’ safety claims. The challenges raised by use of COTS in such assurance frameworks can have ramifications on a project both from a managerial and safety assurance perspective. The paper presents an analysis of the challenges from the use of CertPack and their impact on assurance and project management. Moreover a process is presented that assists de-risking the integration of evidence, as early as possible during system development or upgrade.

The key point of every safety process is hazard identification and management. This is required by many related standards and shall be performed for every project. It’s often a challenge to find all possible hazards in advance but it’s possibly an even bigger challenge to manage all hazards over a wide range of products and projects.

This paper describes in brief the development and the current state of an organization wide hazard management and tracking system which allows for efficient hazard handling. The goal is to act well in advance instead of reacting to problems.

The hazard process defines the ‘lifecycle’ of a hazard: the phases, tasks and responsibilities from its detection to its closing. The state of each hazard is published in the organization’s intranet and can be viewed by every employee, which makes the processing of hazards a transparent activity, where everyone has to participate actively or passively.

The gained knowledge about hazards is that way directly transferred to new projects where they might apply and possibly contribute to accidents. Additionally, findings about potential failure mechanisms are used for the derivation of checklists, to get another step ahead and prevent hazards from the very beginning of the development of a product.