Software safety-critical

EUR 19265 EN Common position of European nuclear regulators for the licensing of safety critical software for nuclear reactors. May 2000... 

Vilkomir S.A., Kharchenko V.S. An "Asymmetric" Approach to the Assessment of Safety -Critical Software During Sertification and Licensing// Proceeding of the ESCOM - SCOPE 2000 Conference "PROJECT CONTROL THE HUMAN FACTOR", Munich, Germany, 18-20 April, 2000, pp. 467-475. 

CHEYNET, R NICOLESCU, B. VELAZCO, R. REBAUDENGO, M. REORDA, S. VIOLANTE, M. Experimentally evaluating an automatic approach for generating safety-critical software with respect to transient errors. IEEE Transactions On Nuclear Science, [S.l.] IEEE Nuclear and Plasma Sciences Society, 2000, v. 47, n. 6 (part 3X pp. 2231-2236. 

McDermid, J., 2012. Safety Critical Software, Article Published in the Encyclopaedia of Aerospace Engineering. John Wiley Sons, Ltd. http //www-module.cs.york.ac.uk/casa/R eae506.pdf. 

Gowen, L. D., Specifying and Verifying Safety-Critical Software Systems, Proceedings of the IEEE 7th Symposium on Computer-Based Medical Systems, 1994, pp. 235-240. 

The major disadvantage is that, at the preliminary level, the analysis is not a structured technique it is somewhat limited to only high-level functions, and thus additional analyses of complex systems are often required, especially where safety-critical software functions have been identified. 

For the development of safety-critical software, the choice of programming language makes a significant difference in meeting the requirements of exacting safety standards and, ultimately, high-reliability applications. 

Safety Critical software development processes are based on software safety standards such as IEC61605-3, DEF-0055 or DO-178. [IEC61508, 1998-2000] is a well established standard [Brown, 2000] in the civil industry. The standard is... 

We have heard it claimed that object technology (and dynamic binding in particular) is not useful in most safety-critical software. While there may be some systems for which object technology has little to offer, there are many others that clearly could benefit from object technology provided that safety concerns can be addressed. 

Dynamic memory allocation is generally avoided in safety-critical software. This policy is typically justified on the grounds that memory allocation operations may fail due to insufficient memory or excessive fragmentation, and that the time taken to perform them will vary depending on the history of calls to allocate and release memory. 

The solution we adopted is not to perform implicit type conversions (these are, in any case, undesirable in languages used for safety-critical software development). We make one exception to this rule to allow the type of a value to be automatically converted to a supertype (otherwise the notation becomes very clumsy to use). This exception raises the possibility of ambiguity, so we explicitly forbid any instance of overloading for which it is possible to construct an ambiguous call. We have not found this restriction to be onerous in practice indeed, we find that the corresponding error message is only triggered where a mistake has been made, or the same name has been used for two unrelated operations. 

Concerns about UML among safety-critical software developers centre on the lack of a precise semantic definition for the language. 

The Primary Protection System (PPS) for the Sizewell B Nuclear Power Plant (NPP) was the first safety-critical software based system to be used in a UK NPP. The software was developed by Westinghouse Electric and consisted of approximately 100,000 lines of software written in PL/M-86 and ASM-86 (a structured version of 8086 assembler). (There were additionally a further 100,000 lines of configuration data.) The software, not including the configuration data. 

SHOLIS (Chapman, 2000) is a software-based system that advises ship s crew on the safety of helicopter operations under various scenarios. The software was developed in accordance with DEF STAN 00-55 (Issue 2). A software hazard analysis was performed and on this basis certain parts of the software were designated as safety-critical. Safety critical software was formally specified using Z, developed in Spark Ada, and a partial correctness performed of the code against the specification. Information Flow analysis was used to demonstrate functional separation of critical and non-critical software. Freedom from run-time exceptions was demonstrated for all code. Static analysis of I/O usage, memory and timing was used to show separation of non-functional properties. Finally, proof that the system s top-level safety properties were maintained by the software was carried out. 

Harrison (1999). Static Code Analysis on the C-130J Hercules Safety Critical Software. Aerosystems International, UK. Int. Systems Safety Conf. 1999... 

Pamas D L, Asmis G J K, Kendall J D (May 1990). Re viewable development of Safety Critical Software. International Conference on Control and Instrumentation in Nuclear Installations. 

Testing of Safety-Critical Software Embedded in an Artificial Heart... 

One must develop systematic approaches to safety-critical software validation while minimizing casualties, including animals used in clinical testing. Real world validation through deployment, like command and control systems in military war game systems, is often impossible. Yet, one must develop approaches to develop credible safety assurance. 

Our experience proves once again how difficult it is to make a credible claim on software quality especially in a safety-critical setting. Although highly useful and essential, testing of safety-critical software embedded in medical devices in an in-vitro setting has limitations. 

Software requirements in non-critical software are usually tested wifli a coverage that depends on factors such as ftie quality system, criticahty to the project, resources and schedule. Execution priority and regression execution will also depend on these factors. In the case of safety critical software it cannot be accepted to work in the same way. Risk mitigations shall be completely and reliably tested before releasing to the public. In oftier words, test coverage for risk related requirements shall be 100% in all cases. This is a very important check that ensures that risk mitigations are put into place and effectively work. 

An important problem in safety-critical software development results from its ever increasing complexity and from the fact that software functions often interact strongly with different contexts in event-based systems. This can be a physical context (e.g. a monitored and controlled device), human users in an organizational context, or other software and hardware (e.g. a device driver). Other factors increasing the complexity of this problem are asynchronous communication with and within the system, event-driven behaviour, complex data types, timing constraints, parallel execution and non-deterministic behaviour of the system under test. Testing event-driven software thus faces special challenges. In summary, the characteristics of event-driven, safety-critical software are ... 

Safety-critical software usually has a large or infinite space of possible behaviours. 

Due to the numerous dependencies, safety-critical software may deviate from its anticipated (normal) behaviour (e.g. presence of hardware faults). 

Safety-critical software is often distributed over several (logical or physical) processing units (e.g. several electronic control units in the sector of embedded automotive software systems). 

Peischl B (2007) Standards for safety critical software validation, verification, and testing requirements. SNA-TR-2007-1, Softnet-Report... 

RTCA DO-178B/EUROCAE ED-12B (RTCA 1992, referred to as DO-178B in the remainder of this paper) is one of the most influential doemnents in safety critical software development. Most of the software flying on eommercial aircraft has to satisfy the objectives of DO-178B. ... 

Model-based development and verification promises many advantages for safety-critical software development ... 

EUROPEAN COMMISSION, European Nuclear Regulators Current Requirements and Practices for the Licensing of Safety Critical Software for Nuclear Regulators, Rep. EUR 18158 EN, Office for Official Pubhcatiorrs of the European Commimities, Luxembourg (1998). 

---