Solving the safety certification challenge for multicore?
CODE QUALITY Blog: It’s no secret that multicore systems have continued to be an attractive option for the military and aerospace fields. With the drive toward reducing the size, weight, and power (SWaP) of embedded systems, the push to rely on multicore systems continues.
It’s easy to see why. Dual cores on the same die increase performance without demanding more power or an increase in footprint or weight. A reduced chip count equals less physical space — helpful for fitting into a tiny space on an aircraft, for example, or for a soldier’s handheld device on a recon mission. Never mind the reduced power, heat, etc. You know the benefits!
However, in the military/aerospace market, the obvious benefits have always been offset by the challenge of testing and certifying a multicore system – particularly when trying to meet DO-178 standards. The same advantage of moving from single to multicore – parallel processing – is what increases the challenges.
The dynamics of safety-critical testing
Before looking at the multicore challenge, we need to look at the typical dynamics of safety-critical development, which must be tested at the systems level. This is when the challenges begin. Target systems never have the same memory and run-time performance as the development platforms. The instrumentation of the code necessary to prove structural coverage tends to bog systems down, particularly if onboard I/O is needed to export test results.
Because of the impact on system performance, it is not normally possible to instrument an embedded system in its entirety due to limited target resources. This limitation is typically addressed by verifying and analyzing the code one component at a time and then aggregating the results.
In the safety-critical world, this step-by-step process is made more challenging by the fact that processors and tool chains used are typically not the latest and so have even greater resource limitations. Traditional processes therefore require that system-level testing be repeated for each component, significantly extending the overall verification schedule.
Multicore ups the certification ante
Testing on multicore systems further complicates these challenges. When multiple processes run on different cores, collecting structural coverage data efficiently can be hampered by con-currency, reliability, and robustness roadblocks.
For example, the typical approach to creating thread-safe instrumentation data logging functions relies on the use of synchronization objects such as mutexes. This ensures that only one process can execute the data logging code at a time; the first process to execute the function “grabs” the mutex, blocking any other process attempting to use the same function from executing.
Once the first function has completed the data logging process, it “releases” the mutex and the next process in the execution list then “grabs” it and continues its processing. With all the con-concurrent processes of a multicore system, it’s not hard to see that this hand-off method could adversely affect the run-time performance of the system.
New lightweight instrumentation addresses issues
With increasingly tight development schedules and industry’s drive to reducing the SWaP of embedded systems, the memory and run-time overhead of traditional instrumentation and data collection techniques has become a productivity and application performance barrier. Traditional instrumentation and data collection techniques are simply not viable with the multicore systems increasingly used to meet SWaP requirements.
Meeting the verification requirements for safety-critical industry standards requires that all testing be performed at the system level on the final system hardware, and test completeness must be proven through the use of structural coverage analysis.
New lightweight instrumentation techniques address both of these objectives. In my next post, I’ll examine some promising breakthroughs for cost-effectively testing multicore systems to meet safety-critical standards.