Feature: EDA
railway control and protection systems) for rail transport, and IEC 61508 (functional safety of electrical/electronic/programmable electronic safety-related systems) for industrial applications. Te responsibility for demonstrating that application soſtware and
Qualifying the C standard library for use in safety-critical applications
By Solid Sands software developers S
oſtware solutions play an ever-increasing role in safety-critical and safety-related systems, with the result that soſtware malfunctions now represent liabilities and a real threat in terms of injury, loss of life, the interruption of essential services, or damage to the environment. As a result, international
standards organisations such as ISO and the International Electrotechnical Commission (IEC) have published widely-recognised and widely-adopted standards against which soſtware developers can certify the safety of their soſtware. Examples include ISO 26262 (road vehicles – functional safety) for automotive, EN 50128 (communication, signalling and processing systems – soſtware for
26 October 2021
www.electronicsworld.co.uk
the methods, processes and toolchains used to develop it comply with the relevant functional safety standards lies firmly with the application developer. However, it’s still a fact that significant parts of the toolchain lie outside the developer’s control – one of the reasons compiler validation has become a key issue for developers of safety-critical systems. Virtually no compiler is bug-free, so it is extremely important to know where a compiler malfunctions so that future errors can be avoided. It is also true that a significant section of the code that becomes part
of the complete application is likely to be compiled with a different application, compiler options and compilation environment from those being used by the developer. Tis is because part of the code that typically ends up in an application includes pre-compiled library functions, such as those in the C standard library (libc) that is oſten supplied in binary format as part of a soſtware development kit (SDK). Contrary to the commonly-held belief that because a library
is supplied in binary format it is insensitive to any particular applications, i.e. the code is invariant, in practice this is not the case. Te inclusion of macros and type-generic templates frequently makes library components application sensitive. So, even if the library was pre-qualified by the SDK supplier using the same compiler delivered with the SDK, the application, compiler options and target hardware environment requirements are almost certainly not to have been met, making it difficult to demonstrate functional safety standard compliance. To overcome this limitation, Solid Sands has introduced a new
library qualification tool called the SuperGuard C Library Safety Qualification Suite – a requirements-based test suite for the C standard library with full traceability from individual test results back to requirements derived from the ISO C language specification. SuperGuard can be used to support qualification of C standard library implementations for safety-critical applications both for unmodified third-party library implementations and self-developed or self- maintained implementations.
Page 1 |
Page 2 |
Page 3 |
Page 4 |
Page 5 |
Page 6 |
Page 7 |
Page 8 |
Page 9 |
Page 10 |
Page 11 |
Page 12 |
Page 13 |
Page 14 |
Page 15 |
Page 16 |
Page 17 |
Page 18 |
Page 19 |
Page 20 |
Page 21 |
Page 22 |
Page 23 |
Page 24 |
Page 25 |
Page 26 |
Page 27 |
Page 28 |
Page 29 |
Page 30 |
Page 31 |
Page 32 |
Page 33 |
Page 34 |
Page 35 |
Page 36 |
Page 37 |
Page 38 |
Page 39 |
Page 40 |
Page 41 |
Page 42 |
Page 43 |
Page 44 |
Page 45 |
Page 46
