Critical real-time aviation control systems demand quick decision-making processes. They deploy closed-loop control, allowing only a tight time window to gather data, process that data, and update the system.
DO-178C establishes a need for the analysis of WCET, highlighting it in §6.3 (Software Reviews and Analyses), §6.3.4 (Reviews and Analyses of Source Code), and §11.20 (Software Accomplishment Summary).
The challenge for developers is that proving that execution times never exceed their allotted window is difficult when using multicore processors. AC 20-193 & AMC 20-193 (collectively A(M)C 20-193) guide developers in their quest to rise to that challenge.
A(M)C 20-193 is a collective term used to describe EASA AMC 20-193 and FAA AC 20-193 (“Acceptable Means of Compliance” and “Advisory Circular”) non-prescriptive documents. These harmonized standards are often known collectively as A(M)C 20-193. A(M)C 20-193 inherits the guidance contained within the CAST-32A paper.
A(M)C 20-193 complements the pre-existing DAL framework used in documents like DO‑178C and DO-254 and addresses the challenges in the adoption of MCPs in hard real-time safety-critical embedded applications including non-deterministic behaviour, interference channels, and increased complexity.
Although A(M)C 20-193 was written specifically for airborne systems, most of the issues it raises are equally applicable to safety-critical systems in other sectors.
FAA CAST-32A was an informational position paper written “to identify topics that could impact the safety, performance and integrity of a software airborne system executing on Multi-Core Processors (MCP)”. It was developed to offer guidance in addition to that provided by existing standards such as DO-178C and DO-278A, which including no guidance that is specific to the use of multicore processors.
Although CAST-32A is written specifically for airborne systems, most of the issues it raised are equally applicable to safety-critical systems in other sectors.
CAST-32A has now been superseded by A(M)C 20-193 which adopted its guidance almost entirely.
The diagram shows how A(M)C 20-193 relates to some aviation standards and recommendations concerning software system development.
DO-297 “Integrated Modular Avionics (IMA) Development Guidance and Certification Considerations” deals with use of powerful computing hardware to host software functions of differing safety criticality. The benefits of deploying multicore devices in this context are centred around SWaP (Size, Weight and Power) considerations, as well as the promise of reduced cost.
The IEEE paper “A Framework for Analyzing Shared Resource Interference in a Multicore System” discusses the common issues of partitioning, domain separation, and isolation techniques at length.
The UK Ministry of Defence has formally incorporated AMC 20-193 into its military airworthiness standards. Specifically, Defence Standard 00-970 has been updated to reference AMC 20-193 as the Acceptable Means of Compliance (AMC) for certifying multi-core processors (MCPs) in safety-critical applications with Item Development Assurance Levels (IDAL) A to C. This integration aligns military certification practices with EASA‘s guidance.
The worst-case execution time (WCET) of a computational task is the maximum length of time that task could take to execute in a specific environment. Hard real-time systems need to satisfy stringent timing constraints imposed by the nature of the functions they fulfil. Unfortunately, it is not possible in general to calculate definitive upper bounds on execution times for programs.
There are further complications in the case of multicore processors. The use of additional cores results in resources being shared between them. Time-related delays occur as users wait for access.
These interference channels cause the execution-time distribution to spread. Instead of a tight peak, the distribution of execution times becomes wide with a long tail.
This page presents a practical, A(M)C 20-193 compliant approach to addressing the multicore WCET problem. It involves the optimisation of system configuration by means of interference research through measured execution times. The TBwcet component of the LDRA tool suite of the LDRA tool suite provides a unique, “wrapper” based approach to WCET analysis by measurement, and it is complemented by the TBexec component which captures whole-application timing and coverage metrics. Both TBwcet and TBexec are based on proven technology, and are available for developers to use without committing to a consultancy package – although that support is available if needed.
TBwcet adopts a “wrapper” principle which affords the flexibility to perform execution time analysis from a complete software component (perhaps a thread or process), right down to class/function/procedure level. This approach provides the ability to both “drill in” to problem areas, and to analyse the complete system.
The choice of stressor mechanism is left to the user. Open-source solutions such as Stress‑ng provides specific stressors for Hardware Shared Resources (HSRs). The flexibility of the test harness presents the opportunity for these stressors to be adapted to suit specific circumstances, or for new ones to be developed from first principles.
TBwcet is complemented by the TBexec component of the LDRA tool suite which captures whole-application timing and coverage metrics.
Three of the documents’ clauses are particularly significant:
“The applicant has identified the interference channels that could permit interference to affect the software applications hosted on the MCP cores, and has verified the applicant’s chosen means of mitigation of the interference”
This places the onus on the developer to demonstrate that all interference channels are known and have been adequately dealt with.
“The applicant has identified the available resources of the MCP and of its interconnect in the intended final configuration, has allocated the resources of the MCP to the software applications hosted on the MCP, and has verified that the demands for the resources of the MCP and of the interconnect do not exceed the available resources when all the hosted software is executing on the target processor.”
The need for the analysis of execution times is implicit in this objective.
“Applicants who have verified that their MCP Platform provides both Robust Resource and Time Partitioning … may verify applications separately on the MCP and determine their WCETs separately.”
As the documents highlight there are many highly effective robust partitioning mechanisms available. These mitigate for many of the most significant interference channels. However, there are two caveats.
Whether robust partitioning is in place or not, the onus remains on the developer to demonstrate that interference mitigation is effective which can only be achieved through measurement. A CAST-32A & A(M)C 20-193 compliant mechanism for doing so is discussed here.
Software issues such as flawed coupling can also introduce delays and variation in execution times. A(M)C 20-193 addresses this issue in detail.
“The applicant has verified that the data and control coupling between all the individual software components hosted on the same core or on different cores of the MCP has been exercised during software requirement-based testing, including exercising any interfaces between the applications via shared memory and any mechanisms to control the access to shared memory, and that the data and control coupling is correct.”
The control coupling and data coupling analysis features of the LDRA tool suite support the analysis of explicit data and control flow between software components and applications.
The guidance in the documents also references the possibility of coupling on a platform level, and the WCET capabilities of the LDRA tool suite support analyses relate to that.
The empirical nature of verification and validation in the multiprocessor environment as compared to single core makes it imperative that project managers can adapt readily to changing requirements and configurations while remaining compliant with CAST-32A, A(M)C 20-193, and DO-178C.
As illustrated below, the iterative nature of interference research to minimize the impact of interference channels makes it important to integrate feedback loops into the development process.
Dan Iorga et al. recommend a slow and steady approach to measuring and tuning interference. It is highly likely that such interference research will lead to changes in system or software requirements, and conversely that changes in system functional requirements will drive new interference channels or affect existing ones.
Under these circumstances, an automated mechanism is vital to keep track of what needs revisiting for renewed verification and validation, and hence to keep the project on schedule, and within budget. The TBmanager component of the LDRA tool suite provides just such a mechanism.
It is important to remember that in the development of a safety-critical system, the considerations given to multicore are merely supplemental to that of a functional safety related process. For example, systems achieving A(M)C 20-193 compliance are also likely to be compliant with DO-178C.
The TBmanager component of the LDRA tool suite provides bidirectional traceability to both project requirements (illustrated above), and to the objectives of one or more process standards and guidance documents.
Most functional safety standards promote the use of coding standards (or language subsets). The TBvision component of the LDRA tool suite is used to verify compliance with coding standard, such as MISRA C/C++, JSF++ AV, and CERT C/C++ . That is significant in the context of A(M)C 20-193 because the rules promoted by coding standards guard against the insertions of runtime defects that have the potential to compromise shared resources.
DO-178 requires coverage analysis. Achieving that at the software level requires instrumentation probes within the code to track execution. Minimising the resulting impact on both performance and resources is particularly important for multicore processors. More information on LDRA’s approach is discussed here.
Technical briefing: Getting to grips with A(M)C 20-193
Technical white paper: Following the recommendations of A(M)C 20-193
Technical white paper: Developing compliant critical software systems with multicore processors
Technical briefing: DO-178C: Get on a High with your software development
Technical white paper: Verification of Airborne Software in Compliance with DO-178C
Website: The TBwcet optional module
Blog: Multicore processors and Worst-Case Execution Times (WCET): Why static analysis matters
Article: Solving the safety certification challenge for multicore?
Webinar (with SYSGO): The multicore challenge – A practical approach to CAST-32A compliance
Press release: LDRA’s latest integration with DDC-I accelerates compliance for multicore aerospace systems
Press release: LDRA and Green Hills Software deliver industry-leading multicore development and verification
Email: info@ldra.com
EMEA: +44 (0)151 649 9300
USA: +1 (855) 855 5372
INDIA: +91 80 4080 8707