There are many facets to consider in the safety of embedded systems. An holistic approach to safe system development will give due consideration to cybersecurity, ergonomics, system integrity, environmental factors and many other elements to ensure that the risk associated with resulting product is acceptable.
Safety by Design, Functional Safety (FuSa) and SOTIF (Safety Of The Intended Function) represent the primary contributions of the software developer to system safety.
Safety by design is an approach where safety considerations are integrated into the initial stages of system, product, and/or process design, ensuring that safety becomes an intrinsic part of the design philosophy. This approach encompasses embedding safety requirements into design specifications, conducting thorough risk assessments, implementing redundancy and fail-safe mechanisms, and adhering to relevant safety standards.
By addressing safety concerns from the outset, safety by design aims to enhance reliability, reduce operational risks, and optimize safety performance throughout the lifecycle of the system or product.
The DO-178C standard for avionics describes a safety by design approach which distinguishes it from the functional safety standards that followed in its wake (that is, IEC 61508 and its derivatives).
The International Electrotechnical Commission (IEC) addresses this question with the following definition:
“Functional safety seeks to reduce the level of risk in a device or system. [It] identifies potentially dangerous conditions that could result in harm and automatically enables corrective actions to avoid or reduce the impact of an incident. It is part of the overall safety of a system or device that depends on automatic safeguards responding to a hazardous event. Functional relies on active systems that can respond to a potentially dangerous situation.”
IEC 61508 “Functional Safety of Electrical/Electronic/Programmable Electronic Safety-related Systems” provides a comprehensive framework for managing safety throughout the development lifecycle. In additional to being directly applicable across the development of such systems, it is also a foundational standard – that is, it many industry-specific standards have been derived from it to address the unique requirements of different sectors. Some of these are illustrated below.
The IEC definition of Functional Safety implies a subtle difference of emphasis as compared with Safety by Design.
Safety by Design requires the developer to design and develop the system to meet the needs implied by the criticality of the system. Functional Safety standards require the developer to demonstrate that the developed system has a level of integrity proportionate to the criticality of the system.
A system that is Safe by Design may well comply with a Functional Safety standard, but it can comply with such as standard without being Safe by Design.
Safety of the Intended Functionality (SOTIF) addresses potential hazards that arise from situations where the system’s design or environment leads to unintended consequences, rather than hazards associated with system failures or malfunctions.
Examples of such hazards include interactions with unpredictable elements or unforeseen user actions. SOTIF aims to identify and mitigate these risks during the design and development stages to enhance overall safety performance beyond functional correctness alone.
Functional Safety (FuSa) primarily focuses on ensuring that safety-related functions within a system operate correctly, even in the presence of faults or failures. Safety of the Intended Function (SOTIF) addresses risks that arise when a system’s intended functions lead to hazardous situations despite performing correctly. FuSa and SOTIF are therefore complementary.
Safety-related coding standards have a role to play in safety-critical systems whether they are developed in accordance with safety by design, functional safety, or SOTIF principles. They provide guidelines and best practices to ensure that software code is reliable, can be trusted to perform correctly, and is less likely to cause errors or accidents. The standards help prevent common coding flaws, improve overall code quality, and ensure compliance with regulatory requirements, playing a crucial role in promoting safe practices throughout the software development lifecycle.
Examples of safety-related coding standards include:
The term aerospace and defense (often abbreviated to A&D) encompasses a wide variety of activities within both civilian and military sectors. Despite this diversity, they are united by the common need for software that is critical to safety.
The civil aviation authorities deal with cybersecurity concerns in embedded systems through the application of avionics software safety standards which provide a holistic and cohesive approach to Safety by Design across the sector.
DO-178C/ED-12C is the primary document referenced by certification authorities to approve all commercial software-based civil aviation systems. It is supplemented by several documents, many of which supporting the use of particular development approaches or technologies. Examples of supporting documents include:
Different countries have their own safety standards relating to defense equipment, including:
There are also several initiatives to align these national standards, including those from the EU and NATO. In many cases, defense software developers must also comply with civil standards. Examples include DO-178C/ED-12C and DO-278A/ED-190D in aviation, and ISO 26262 for ground vehicles.
In the automotive industry, software safety is ensured through guidelines that focus on the reliable functioning of electronic systems in vehicles, especially as they become more autonomous and connected.
ISO 26262 – Road vehicles – Functional safety is a derivative of IEC 61508. It provides a comprehensive framework for achieving functional safety in electrical and electronic systems within road vehicles. It covers the entire product development lifecycle and is widely used in the automotive industry to address the safety of software-intensive systems.
Other functional safety standards further derive ISO 26262 guidance to provide more specialist advice. For example, ISO 25119 (Tractors and agricultural machinery) combines modified and simplified ISO 26262 recommendations (automotive safety) and ISO 13849 (machinery safety).
ISO/PAS 21448 Road vehicles — Safety of the intended functionality addresses the safety of the intended functionality (SOTIF) of automotive systems. It focuses on the safety considerations related to the proper functioning of a system, specifically focusing on scenarios where the system operates as intended but might still lead to hazardous situations. It is especially relevant to autonomous vehicles.
The industrial & energy sector covers a broad range of commercial and production activity and so there are many standards that relate to it. These range from the generic to the highly specific. They include:
All these functional safety standards have much in common because they are all derived from IEC 61508. For example, they all emphasize a safety life cycle, risk reduction, and the need to consider common cause failures.
Safety standards for software in electronic medical devices include ISO 14971 which is primarily concerned with risk management, and IEC 82304-1 which focuses on the safety and security of health software products that operate on general purpose computing platforms.
IEC 62304 – Medical device software – Software lifecycle processes, is the document of primary interest to embedded software developers. Like many other safety-specific functional safety standards, it is a derivative of IEC 61508.
The FDA and European authorities recognize these standards as demonstrating compliance with their regulations. For instance, IEC 62304 and ISO 14971 are frequently referenced in FDA guidance documents and are harmonized under the European Medical Device Regulation (MDR).
In the rail and GTS industry, the evolution from closed, wired isolated networks to open, interconnected networks has led to a new generation of threats. EN 50128 and the EN 5012x series, its functional safety models, the concepts, and the risk assessment process it describes are based on or derived from the IEC 61508 standard and adapted to a rail-specific context. Additionally, the Railway Safety Directive and the Interoperability Directive set out essential requirements for safety and interoperability across the European rail network.
Outside Europe, rail safety standards for software include IEC 62279 which is the international equivalent of EN 50128. In the United States, the Federal Railroad Administration (FRA) and the American Public Transportation Association (APTA) provide guidelines and standards for rail safety.
Software safety standards are crucial due to the high stakes involved in the space sector.
NASA guidance documents relating to the development of embedded software fall into two groups – standards and procedural requirements. NPRs ensure that the processes and management aspects align with NASA’s goals, while STDs set the technical and engineering standards for achieving those goals. NP 7150.2D Software Engineering Requirements is the document most directly pertinent to safety critical embedded software development.
Additionally, the ECSS series of standards issued by the European Cooperation for Space Standardization (ECSS) cover all aspects of space software engineering, including requirements definition, design, production, verification, validation, and maintenance. They emphasize rigorous testing, validation, and risk management to prevent failures that could jeopardize missions or safety, making particular reference to source to object code traceability for the most critical systems.
Although the advice offered within the different sectors varies in content, detail, and maturity, there are many common themes. These include:
LDRA’s development tools, including the LDRA tool suite, help to alleviate the overhead faced by development teams looking to comply with the pertinent safety standards, and with the traceability of requirements to the design and verification of code.
Unclear or undocumented requirements can lead to miscommunication, resulting in rework, changes, bug fixes, and security vulnerabilities. To ensure smooth project development, every team member must have a shared understanding of all product components and the development process. Clearly defined functional and security requirements are essential for this alignment.
For V-model developers, these requirements typically define a complete system, while for iterative processes like DevOps they may outline just an iteration. Either way, although software can be used as “intellectual modelling clay” for proof of concept, the formal development process should involve clearly defined requirements followed by code that has been developed to meet them.
The IEEE Standard Glossary of Software Engineering Terminology defines traceability as “the degree to which a relationship can be established between two or more products of the development process, especially products having a predecessor-successor or master-subordinate relationship to one another.” Bidirectional traceability means that traceability paths are maintained both forwards and backwards
Automation makes it much easier to maintain traceability in a changing project environment.
Forward traceability demonstrates that all requirements are reflected at each stage of the development process, including implementation and test. The impact of any changes to requirements or of failed test cases can be assessed by applying impact analysis, which can then be addressed. The resulting implementation can then be retested to present evidence of continued adherence to the principles of bidirectional traceability.
Equally important is backward traceability, which highlights code that fulfills none of the specified requirements. Oversight, faulty logic, feature creep, and the insertion of malicious backdoor methods can all introduce security vulnerabilities or errors.
Automated traceability as facilitated by the TBmanager component of the LDRA tool suite is invaluable in keeping track of progress, especially when requirements change.
For development in C or C++, research has long shown that roughly 80 percent of software defects stem from the incorrect usage of about 20 percent of the language. To address this, developers can use language subsets (also known as “coding standards”) that improve both safety and security by disallowing problematic constructs.
The diligent application of a standard such as MISRA C or BARR-C will likely result in safer, higher quality code. The manual enforcement of such standards on a code base of any significant size is not practical. A static analysis tool is required to automate source code “inspection”.
The static analysis provided by the TBvision component of the LDRA tool suite and the point product LDRArules can both help in that regard.
Adherence to safety-focused standards is frequently wise, and often mandatory. The TBmanager component of the LDRA tool suite can also integrate developer workflows for security-critical and functional safety concurrently, should the need arise.
LDRAvault is complementary to TBmanager. It is a web-based, enterprise level application certification aggregation tool that can handle huge amounts of data across multiple projects. An add-on to the LDRA tool suite, LDRAvault provides a web-interface that automatically and securely aggregates reports and results that are suitable for use as evidential artefacts for certification purposes. Examples include code reviews, code coverage analysis, and unit testing results.
Unlike static analysis, dynamic analysis involves the execution of some or all of the code base under test.
The LDRA tool suite offers a range of dynamic testing capabilities designed to enhance software quality and ensure compliance with safety-related standards. Some of the key dynamic testing features include, but are not limited to:
These facilities help developers identify and fix issues early in the development process, improving the overall reliability and security of the software.
All the safety-related tools, tests, and techniques described here have a place in each life cycle model. The illustration showing the ISO 26262 model shows that they are largely analogous and complementary to the processes described in the standards. Each technique is designed to be leveraged as early as possible, simply because problems that are identified early are the easiest to fix.
The same principle applies equally to other process models too, with iterative process models being especially popular in the automotive sector – DevOps, Spiral, Agile, Scrum…
“Tool qualification” is a generic term to describe a process designed to ensure that the risk of a tool error impacting the safety of a system is acceptably low – either because the errors are few, or because they cannot impact safety. Most functional safety standards reference a need to achieve tool qualification by considering the application of the tool, and the environment in which it is deployed.
In the avionics world (particularly DO-178C and DO-278A), the tool qualification process carefully detailed in the document DO-330 is applicable to most projects. In practice, that is usually achieved with the support of tool providers. For example, TQSP is an optional module available for the LDRA tool suite. Each TQSP module provides artefacts and guidance to simplify the process of qualifying the LDRA tool suite for use as a verification tool in a project-specific environment.
Except for ISO 26262, IEC 61508 and its derivatives only mention that tool qualification must be achieved for highly critical systems. For that reason, many developers turn to ISO 26262 or DO-330 for guidance outside the automotive and avionics sectors. In acknowledgement of that challenge, DO-330 is purposely designed to help provide appropriate guidance irrespective of sector.
SGS TÜV SAAR and TÜV SÜD are both independent certifying agencies who have evaluated LDRA’s development and testing practices and issued certificates for the tool suite verifying it is qualified to be used in safety-related software development. TÜV validation of LDRA tools is adequate assurance of their suitability for projects compliant with IEC 61508 and its derivatives.
Technical Briefing: DO-178C: Get on a High with your software development
Technical White Paper: Verification of Airborne Software in Compliance with DO-178C
On Demand DO-178C “First Flight” Self-paced online training course
Technical briefing: Test tool qualification for ISO 26262 compliant automotive applications
Technical white paper: Implementing ISO 26262 second edition with the LDRA tool suite
Technical white paper: ISO 26262 and Automotive SPICE: A meeting of fire and ice?
Technical briefing: IEC 61508: Know your SILs from your elbow
Technical white paper: implementing IEC 61508:2010 with the LDRA tool suite
Technical briefing: Keeping EN 5012X compliant development on track with the LDRA tool suite
Technical white paper: Implementing the EN 5012X standards with the LDRA tool suite
Technical Briefing: Ease the Heartache of Medical Device Software Certification
Data sheet: Compliance with ECSS-E-ST-40C and ECSS-Q-ST-80C Rev1
Technical white paper: Developing compliant critical software systems with multicore processors
Technical briefing: The significance of Object Code Verification: An overview
Technical white paper: Object code verification: Why it matters
Technical white paper: Test tool qualification for functional safety
Technical briefing: Clarifying and fulfilling test tool qualification requirements
Video – MISRA C:2012 Demonstration with the LDRA tool suite
Video – Software engineering: Being compliant with MISRA C and MISRA C++
Video – Ensuring MISRA compliance through the application of MISRA Compliance:2020
Video – Compliance with EN 50128 and the EN 5012X (CENELEC) standards series
Case study – Functional safety with legacy software
Case study – United Space Alliance Selects LDRA tool suite to Verify Software on Orion
Email: info@ldra.com
EMEA: +44 (0)151 649 9300
USA: +1 (855) 855 5372
INDIA: +91 80 4080 8707