Mitigate Timing and Interference Issues on Multicore Processors

Missing multicore timing deadlines in a driver safety or aviation system is potentially catastropic. Adhering to guidance documents, and employing the appropriate testing and analysis methods ensures the efficient and deterministic execution of critical workloads.

Embedded software developers face unique challenges when dealing with timing and interference issues on heterogeneous multicore processor (MCP) based systems. Such systems offer higher CPU workload capacity and performance than single core processor (SCP) setups, but their complexity can make strict timing requirements extremely difficult to meet.

In hard real-time systems, deterministic execution is crucial for meeting operational and safety goals. Although MCP-based systems generally exhibit lower average execution times for a given set of tasks than do SCP systems, the distribution of these times is more variable. This makes it difficult for developers to ensure precise timing for tasks, creating significant problems when they are building applications where meeting the worst execution times for individual tasks is more critical than meeting goals for average times.

To address such challenges, embedded software developers can turn to guidance documents like CAST-32A, AMC 20-193, and AC 20-193. In CAST-32A, the Certification Authorities Software Team (CAST) outlines important considerations for MCP timing and sets Software Development Life Cycle (SDLC) objectives for a better understanding of the behavior of a multicore system. While not prescriptive requirements, these objectives guide and support developers toward adhering to widely accepted standards like DO-178C.

In Europe, the AMC 20-193 document has superseded and replaced CAST-32A, and in the U.S., the AC 20-193 document has done the same. These successor documents, collectively referred to as A(M)C 20-193, largely duplicate the principles outlined in CAST-32A.

To apply the guidance from A(M)C 20-193, developers can employ various techniques for measuring timing and interference on MCP-based systems.

WORST-CASE EXECUTION TIMING

In hard real-time systems, meeting strict timing requirements is essential for ensuring predictability and determinism. Such systems run mission- and safety-critical applications like advanced driver assistance systems (ADAS) and automatic flight control systems. In contrast to soft real-time systems, where missing a timing deadline has less severe consequences, understanding the worst-case execution time (WCET) for hard real-time tasks is essential because missed deadlines can be catastrophic.

Developers often consider both the best-case execution time (BCET) and the WCET for each CPU task. The BCET represents the shortest execution time, while the WCET represents the longest execution time. Figure 1 illustrates how these values are determined given an example set of timing measurements.

Figure 1 Different execution times and guarantees for a given real-time task.

Measuring the WCET is particularly important because it provides an upper bound on the task’s execution time, ensuring that critical tasks complete within the required time constraints.

In SCP-based systems, meeting upper timing bounds can be guaranteed as long as there is sufficient CPU capacity planned and maintained. In MCP-based systems, meeting such bounds is more difficult due to the lack of effective methods for calculating a guaranteed tasking schedule that accounts for multiple processes running in parallel across heterogeneous cores. This complexity increases when applications share hardware among processor cores. Contention for the use of these Hardware Shared Resources (HSR) is largely unpredictable, disrupting the measurement of task timing.

Developers of hard real-time systems on MCPs – unlike their counterparts working with single-core systems – cannot rely on static approximation methods to generate usable approximations of BCETs and WCETs. Instead, they must use iterative tests and measurements to gain as much confidence as possible in understanding the timing characteristics of tasks.

WHAT IS A(M)C 20-193?

To better understand the landscape of guidance available to developers, Figure 2 provides a visual representation of the relationships among key civil aviation documents.

Figure 2 Relationships among civil aviation regulatory and advisory documents.

A(M)C 20-193 places significant focus on developers providing evidence that the allocated resources of a system are sufficient to allow for worst-case execution times. Such evidence requires that developers adapt development processes and tools to iteratively collect and analyze execution times in controlled ways that help them to optimize code throughout the lifecycle. A(M)C 20-193 does not specify exact methods for achieving objectives, leaving developers to implement in ways that best suit their projects.

DEVELOPER GUIDANCE

A(M)C 20-193 specifies MCP timing and interference objectives for software planning through to verification that includes the following:

Documentation of MCP configuration settings throughout the project lifecycle, as the nature of software development and testing makes it likely that configurations will change. (MCP_Resource_Usage_1)
Identification of and mitigation strategies for MCP interference channels to reduce the likelihood of runtime issues. (MCP_Resource_Usage_3)
Ensure that MCP tasks have sufficient time to complete execution and adequate resources are allocated when hosted in the final deployed configuration. (MCP_Software_1 and MCP_Resource_Usage_4)
Exercising data and control coupling among software components during testing so as to demonstrate that their impacts are restricted to those intended by the design. (MCP_Software_2)
A(M)C 20-193 covers partitioning in time and space, enabling developers to determine WCETs and verify applications separately if they have verified that the MCP-based system itself supports robust resource and time partitioning. Making use of these partitioning methods helps developers to mitigate interference issues. But note that not all HSRs can be partitioned in this way. In either case, the specifics of DO-178C require evidence of adequate resourcing.

ANALYSIS AND TESTING

The methods that follow are proven effective to meet the needs of WCET analysis and to meet the guidance of A(M)C 20-193 guidelines.

METRICS AND STATIC ANALYSIS

Halstead’s complexity metrics can act as an early warning system for developers, providing insights into the complexity and resource demands of specific code segments. By employing static analysis[1] (More information can be found on Circuit Cellar’s Article Materials and Resources webpage), developers can use Halstead data with real-time measurements from the target system, resulting in a more efficient path to ensuring adequate application resourcing.

Such metrics and others shed light on timing-related aspects of code, like module size, control flow structures, and data flow. Identifying sections of larger size, higher complexity, and more intricate data flow patterns helps developers to prioritize their efforts and fine-tune code segments that incur the highest demands on processing time. Optimizing these resource-intensive areas early in the lifecycle reduces the mitigation effort and risks of timing violations.

DYNAMIC ANALYSIS

Measuring, analyzing, and tracking individual task execution times can help mitigate issues in modules that fail to meet timing objectives. Empirical dynamic analysis is essential to this process, as it automates the measurement and reporting of task timings to reduce developer workloads.

To ensure accuracy, developers must consider the following:

The analysis must occur in the actual environment where the application will run to eliminate the influence of configuration differences between development and production, such as compiler options, linker options, and hardware features.
To ensure reliable and consistent results, sufficient tests must be executed repeatedly to account for environmental and application variations between runs.
Automation is highly recommended for executing sufficient tests within a reasonable timeframe and for eliminating the influence of relatively slower manual actions.
An example of this type of analysis is demonstrated by the LDRA tool suite in Figure 3. A “wrapper” test harness is employed to exercise modules on the target device to automate timing measurements. Developers can define specific components under test, whether at the function level within a subsystem, or as part of the overall system. Additionally, CPU stress tests can be specified, like using the open-source Stressing workload generator, to further improve confidence in the analysis results.

Figure 3
Execution time histograms from the LDRA tool suite (Source: LDRA).

APPLICATION CONTROL

Control and data coupling analysis play a crucial role in identifying task dependencies within applications. Through control coupling analysis, developers examine how the execution and data dependencies among tasks affect one another. The standards insist on such analyses not only to ensure that all couples have been exercised, but also because of their capacity to reveal potential problems.

The LDRA tool suite provides robust support for control and data coupling analyses. As illustrated in Figure 4, such analyses help developers to identify critical sections of code requiring optimization or restructuring to improve the timing predictability and resource utilization of the application.

Figure 4
Data coupling and control coupling analysis reports from the LDRA tool suite (Source: LDRA).

CONCLUSION

By understanding the A(M)C 20-193 guidance and applying appropriate testing and analysis methods, embedded software developers can better manage the complexities of Hardware Shared Resource interference and address coding issues that impact it – essential in ensuring the efficient and deterministic execution of critical workloads in MCP-based systems.

Written by Steve Di Camillo
Technical Marketing and Business Development Manager at LDRA.

PUBLISHED IN CIRCUIT CELLAR MAGAZINE
AUGUST 2024 #409
Read Full article here – Mitigate Timing and Interference Issues on Multicore Processors