search.noResults

search.searching

saml.title
dataCollection.invalidEmail
note.createNoteMessage

search.noResults

search.searching

orderForm.title

orderForm.productCode
orderForm.description
orderForm.quantity
orderForm.itemPrice
orderForm.price
orderForm.totalPrice
orderForm.deliveryDetails.billingAddress
orderForm.deliveryDetails.deliveryAddress
orderForm.noItems
Feature: Tools


Qualifying the C Standard Library for safety-critical applications By Marcel Beemster, CTO, Solid Sands


S


oſtware solutions play an ever-increasing role in safety-critical and safety- related systems, where soſtware malfunctions now represent liabilities and


a real threat in terms of essential service interruptions, environmental damage, injury, and even loss of life. Organisations such as the ISO and


International Electrotechnical Commission (IEC) have published widely-adopted standards against which soſtware safety can be certified. Examples include ISO 26262 (Road vehicles – Functional safety) for automotive, EN 50128 (Communication, signalling and processing systems – Soſtware for railway control and protection systems) for rail transport, and IEC 61508 (Functional Safety of Electrical/Electronic/ Programmable Electronic Safety-related Systems) for industrial applications. Application developers must demonstrate


that the soſtware and the methods, processes and toolchains used to develop it comply with relevant standards. However, much of the toolchain lies outside developer control, making compiler validation vital. Few compilers are bug-free, so knowing where they malfunction will help avoid errors. Source code typically ending up as


compiled binary never goes through the compiler under identical use case, compiler options and target hardware environment. Part of this code comprises pre-compiled library functions, such as those in the C Standard Library (libc) oſten supplied in binary format within a soſtware development kit (SDK). Including macros frequently makes library components use-case sensitive.


26 October 2022 www.electronicsworld.co.uk


Even in a library pre-qualified by the SDK supplier using the same compiler delivered with the SDK, the same use-case, compiler options and target hardware environment requirements may not have been met, making it difficult to demonstrate compliance. To overcome this, the Solid Sands


SuperGuard C Library Safety Qualification Suite provides full traceability from individual test results back to requirements derived from the ISO C language specification. It can support qualification of C Standard Library implementations for safety-critical applications both for unmodified third-party libraries and for self-developed or self-maintained implementations.


The aim of qualification Soſtware library qualification is critical because library code is linked into the application and installed on the target device. A defective library component jeopardises the entire application’s functional safety. Soſtware library usage objectives within functional safety standards generally share a common goal: to verify the library implementation complies with its specification. For example, ISO 26262 provides two library qualification routes, detailed in ISO 26262 Part 8 and ISO 26262 Part 6; SuperGuard works in both cases.


The SuperGuard tests When implementing the requirements- based testing recommended in ISO 26262’s Parts 6 and 8, the main issue with the C Standard Library specifications is that, whilst they provide a detailed behavioural description for each function, neither


defines clear requirements; see Figure 1. Tese must therefore be created from those descriptions. SuperGuard incorporates the proven


C Standard Library test suite from Solid Sands’s SuperTest compiler test and verification suite, but with greater capabilities in reporting and documenting requirements, individual tests and their results according to key standards. Suitable for a wide range of development


environments, SuperGuard tests verify that implementation behaviour complies with the library specification. Each executes the construct or function under test, and compares the execution results with the expected (‘model’) results defined in the library specification. Te test itself reports success or failure to the test driver. To check implementation behaviour, tests


are compiled and executed in an execution environment, meaning the entire toolchain, including the target processor, is involved in each test. Tis makes SuperGuard suitable for hardware-in-the-loop library verification. Te tests for the freestanding part of


the library (typically used in bare-metal systems) require minimal resources. Most SuperGuard tests can run on systems with less than 4k memory, making SuperGuard suitable for very small embedded systems. To implement requirements-based


testing, SuperGuard breaks down C Standard Library specifications into testable implementation requirements, together with test specifications describing how each requirement is tested. By linking individual test execution results back to the corresponding test specification, requirement and standard library function,


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