Software has become the foundation for enabling rapid adoption and development of innovative technology in embedded systems, and avionics is no exception. Avionic subsystems are increasingly “software-defined,” allowing for greater flexibility with increased functionality and customization. However, as the software in these systems becomes more complex, especially those running on multicore processors, there are more opportunities for potential vulnerabilities to arise that can affect safety, security, and reliability.

Further complicating design is the rising pace of development demanded by the marketplace. Systems need to be updated more frequency, not only to remain competitive with new features and capabilities, but also to meet the increasing challenge of maintaining security in complex connected systems. Development approaches like DevSecOps that employ development methodologies like Continuous Integration/Continuous Deployment (CI/CD) are essential for developers to be able to deliver functionality faster than ever before (see Figure 1 above).

Functional safety and security

The avionics system must comply with a wide range of standards to ensure they meet strict government and idustry regulations for functional safety, security, and reliability. These standards outline varying levels of compliance, depending upon the criticality of the software in the system. The more critical the code, the more comprehensive the testing and validation that will be required.

Consider CAST-32A, AMC 20-193, and AC 20-193 (see Figure 2). CAST-32A outlines important considerationsfor designing with multicore processors, including non-prescriptive Software Development Life Cycle (SDLC) objectives that can guide and support developers toward adhering to industry standards like DO-178C. Note that in Europe, AMC 20-193 has superseded CAST-32A, and AC 20-193 is expected to do the same in the U.S.

Figure 2: The relationship between civil aviation regulatory and advisory documents like CAST-32A and A(M)C 20-193. (Source: LDRA)

Worst-Case Execution Time

One of the most important – and difficult to assess – characteristics of a multicore-based system is its Worst-Case Execution Time (WCET). Because tasks running on different cores on the same processor share resources, there is the possibility of contention for these resources. Resource contention can occur at the application level. Consider a task on Core A that needs to modify a shared system parameter. At the same time, a task on Core B needs this system parameter to make a decision. To ensure validity of the system parameter and integrity of the resulting decision, Core B must wait to access the system parameter until Core A has completed its modification and released the shared resource to be used by other cores.

However, this is not the only source of resource contention – there is also contention at the hardware level. The processor cores on a embedded target are typically wired to a shared cache and shared memory. Often, these shared resources add additional delays and contentions – from the hardware – that are entirely invisible at the application level.

Such contention delays add variability to execution time. As delays may or may not be experienced during a particular run-time instance, this causes the expected execution time of code to vary across a widespread. For example, Figure 3 shows the range of possible execution times for a task.

Figure 3: Multicore processor contention for shared resources adds variability to a task’s execution time. Developers can analyze the Worst-Case Execution Time (WCET) of a task over multiple runs to gain confidence that real-time timing constraints for the system will be maintained. (Source: LDRA)

It is important to note that the best- and worst-case execution time (WCET) for a task is based on a sample of observed execution times. Given the unpredictable variability of contention between cores from run to run, it is extremely difficult to calculate the maximum possible (actual) WCET. This is because what matters here is the contention that arises between cores is dependent upon the tasks other cores are actually executing at run-time. This means that it is often not feasible to verify the impact of every possible contention between cores. In fact, the circumstances that trigger the actual WCET may happen so infrequently that they are never observed in the lab. This does not, however, mean they won’t ever occur out in the field. Rather, they are a potential failure waiting to happen with the possible outcome of injury or death.

This is what functional safety standards aim to prevent. The goal of WCET analysis is to use observed execution times to estimate the WCET. To guarantee that all real-time timing requirements are met, developers add a buffer to provide an upper timing bound that ensures the actual WCET falls within an acceptable range.