Libraries in Critical Systems: Efficiency Boost or Hidden Liability?
In safety-critical environments, even a single software error can lead to catastrophic consequences. Developers are under constant pressure to deliver reliable solutions quickly, and software libraries seem like the perfect shortcut. These pre-built components promise faster development, enhanced performance and reduced costs.
However: can we truly trust pre-written code? Are libraries silent heroes of functional safety or hidden risks waiting to surface at the worst possible moment?
Libraries offer significant advantages:
Save Time & Effort: No need to write hundreds of lines of code from scratch.
Improve Reliability: Well-tested libraries can reduce bugs.
Enhance Code Quality & Maintainability: Standardized components simplify long-term support.
Boost Performance & Add Advanced Features: Access optimized algorithms and capabilities.
Simplify Integration: Easier to connect with larger systems.
When multiple libraries are used, the time savings across a project can be substantial.
Library Qualification operates within strict regulatory frameworks that vary by industry:
Aviation:
DO-178C sets the gold standard for airborne software development. Compliance is mandatory for flight-critical components, including embedded libraries, under FAA and EASA regulations.
Automotive:
ISO 26262 governs functional safety for road vehicles. Libraries used in critical systems like braking or steering must meet stringent ASIL requirements, with ASIL D being the highest level.
Medical Devices:
IEC 62304 regulates software in medical devices. Compliance is essential for Class II and III devices, as required by the FDA and other medical device regulatory bodies worldwide where failures could pose serious health risks.
Non-compliance can lead to recalls, legal liability, and severe financial penalties.
Library Qualification is the rigorous process of testing and verifying that pre-existing software components behave as expected under all required conditions.
Why does it matter? Because an unqualified or poorly tested library can introduce hidden risks. In the worst case, a single undetected bug could lead to catastrophic failure once the product is deployed.
In safety-critical software, qualification is essential, but not all components are treated equally:
Tool Qualification: Validates development tools (e.g., compilers, code analyzers) to ensure they operate safely.
Library Qualification: Confirms that embedded software libraries perform reliably and safely without modification.
The key distinction is this: Libraries become part of the final product, so any flaw directly impacts system behavior. While libraries often contain hundreds of functions, qualification focuses only on the parts you use, but even that subset must meet rigorous safety standards.
Different types of libraries present unique challenges in safety-critical systems:
Mathematical Libraries: Functions for floating-point arithmetic, trigonometry, and linear algebra can introduce precision errors or fail at boundary conditions. Libraries like BLAS require extensive numerical validation.
Communication Protocol Libraries: TCP/IP stacks, CAN bus libraries, and wireless protocols must ensure reliable data transmission which is critical in automotive and aerospace applications.
Cryptographic Libraries: Security libraries (e.g., OpenSSL) need qualification for functional correctness, resistance to side-channel attacks, and compliance with standards like FIPS 140-2.
Real-Time Operating System (RTOS) Libraries: Kernel libraries, scheduling functions, and IPC mechanisms must meet strict timing requirements and demonstrate predictable behavior under all load conditions.
In safety-critical software, even the smallest change matters. If a library is modified, even slightly, it’s treated as new software and must undergo full qualification under applicable safety standards.
Unmodified libraries, however, follow specialized qualification processes. These include rigorous positive and negative testing and achieving maximum code coverage metrics, such as Modified Condition/Decision Coverage (MC/DC).
MC/DC is a white box testing criterion that ensures every condition in a decision independently affects the outcome.
Example:
In a Boolean expression like
(A && B) || C
MC/DC requires demonstrating that changing each variable (A, B, or C) alone can alter the result.
This level of testing is mandated by standards like DO-178C for the highest safety levels and provides strong assurance that the software logic has been thoroughly exercised.
In domains like automotive, aerospace, and medical systems, Library Qualification requires greater scrutiny than Tool Qualification.
We have already stated:
Tool Qualification verifies that development tools (e.g., compilers, code analyzers) meet their intended purpose.
Library Qualification goes further, demonstrating how the library behaves under normal and extreme conditions.
To meet safety standards, a qualified library must:
Provide clear specifications, including resource usage and failure behavior.
Undergo rigorous validation testing with both expected (positive) and unexpected (negative) inputs.
Achieve high code coverage, including metrics like MC/DC.
Be developed in accordance with recognized international safety standards.
In everyday tech, a software glitch might just mean a mobile app crash. But in safety-critical domains like automotive, aerospace, medical devices, software failures can be life-threatening.
Two real-world examples:
Over 9 million Toyota vehicles were recalled due to unintended acceleration issues. Investigations revealed software-related problems in the engine control system, including inadequately qualified mathematical libraries used in throttle control. Read more here and here.
In 2008, an Airbus A330 experienced sudden pitch-down movements due to faulty air data computations. Among the contributing factors were unqualified sensor data processing libraries. Read more here and here.
A clear pattern emerges in these cases: assuming library safety can lead to expensive mistakes. Developers often presume that qualifying an operating system automatically covers its bundled libraries. In truth, libraries frequently demand their own thorough, independent qualification, particularly when they influence critical system behavior.
Library Qualification is just the beginning. Long-term safety and compliance require addressing these challenges:
Licensing & IP: Qualified libraries often have complex licensing terms. Open-source may impose copyleft obligations; commercial libraries can be costly and restrictive. Legal clarity is as critical as technical assurance.
Maintenance & Updates: Even minor updates like bug fixes or security patches, trigger costly requalification. Many organizations adopt frozen versions supported by robust change management.
Third-Party Assessment: Independent certification adds credibility and streamlines regulatory approvals, though it increases cost and time.
Documentation & Traceability: Qualification generates extensive documentation—specifications, test plans, coverage reports, traceability matrices—all version-controlled for audits.
With thousands of libraries (and many of them open source), developers face a critical challenge: how can you qualify software responsibly in safety-critical systems?
Here are actionable steps to help you navigate the process:
Clearly identify which libraries you use and the specific functions they call. Precision is essential to define the qualification scope accurately.
Choose libraries that already provide certifications or documented qualification artifacts. This reduces both risk and workload significantly.
Even when reusing libraries, perform positive and negative testing tailored to your application’s requirements. Context-specific validation is key.
Any modification effectively creates new software, requiring full re-qualification. Whenever possible, stick to unmodified versions.
Frameworks like those from Validas streamline compliance and enable safe reuse, saving time and effort.
