METHOD AND TOOLS This chapter deals with task

In document MULCORS-UseofMULticore procesorsinairbornesystems (Page 120-123)

MULCORS EASA 14 Interconnect

SHARED CACHE IN SRAM

9.8. METHOD AND TOOLS This chapter deals with task

9.8.1. Summary of task 9

Identify which methods and tools would be suitable and / or necessary in order to conduct ED-12B / DO- 178B verification of the Airborne Software hosted on multi-core processors. The study shall determine (if possible) whether the WCET of tasks could be measured or analyzed for each type of processor hardware / software architecture and identify any aspects of particular processor groups that might either facilitate that measurement or make it more difficult.

9.8.2. Methods and tools analysis

Most of the verification methods and tools already used to perform software verification activities required by the ED-12B/DO-178B industry standard for certification are also usable for software running on multi- core processors. This remains particularly true when Airborne Software runtime partitions are properly controlled under an Operating System environment, and when the multi-core processor features are themselves under control of a Hypervisor, which is identified as of central importance in the approach to mastering complexity of multi-core processors.

Methods supported by tools that are useful for instrumentation and testing of Airborne Software running on COTS Multi-Core processors include:

 WCET tool based on worst case execution path,

 Miscellaneous trace, monitoring or reporting tools,

 Processor driver (e.g. Hypervisor) seen as a tool,

 Usage Domain Verification /early Validation tool,

 Test means, test scripts, dummy Airborne Software,

 Miscellaneous Debugging and Measuring tools.

As already addressed in this report, the feature of WCET analysis of Software running on multi-core processors is more difficult to achieve when execution time variability is increased due to such a technology.

A 10 to 20 time increase in the WCET variability has been reported by some studies. In that situation, the measured WCET, even complemented by analysis and corrected using safety margins, may no longer provide significant useful and reliable information on the actual WCET to be claimed as part of certification.

The problem of WCET calculus is extremely complex to resolve exactly. WCET estimation methods will determine approximations of the real WCET. When considering a WCET calculus method for highly

MULCORS

EASA

critical Airborne Software, we must have the insurance that the method is pessimistic, that means it will always provide an upper bound of the real WCET.

WCET measurement methodologies can be divided in two categories (see (Wilhelm, et al., 2008) for more details):

 Based on static analyses.

 Based on measurements under a worst case scenario.

The WCET calculus based on static analyses relies on a model of the processor to determine the worst case path in the Airborne Software Control Flow Graph within a Path Enumeration. The processor model has to contain information that describe the processor behavior so that the CFG34 can be accurately determined, and timing information for various operations (processor services and eventual Operating System calls) so that the CFG can be annotated with timing weights. Care has to be taken when using those timing annotations. Indeed, optimizations mechanisms such as pipelines that are present inside the cores will significantly decrease the real execution time while the estimated WCET won’t. Moreover, a WCET analysis contains in particular a cache content analysis that may be difficult to fulfill (refer to (Hardy, Analyse pire cas pour processeur multi-coeurs disposant de caches partagés, 2010) for more details).

Today, this kind of methods is applied on simple architectures such as microcontrollers and academic processors. To the best of our knowledge, no complex multicore COTS are supported yet. We can identify the following tools that implement such methods:

 OTAWA: This open-source tool is developed at laboratory IRIT located at Toulouse, France. It has a large support for ARM, PowerPC and INTEL® processors. It implements several algorithms for pipeline behavior prediction, cache content prediction...

 aIT: This is a proprietary tool developed by AbsInt Angewandte Informatik in Germany

 Bound-T: This is a proprietary tool that is maintained by Tidorum in Finland. It is involved in European Space Agency programs.

The WCET calculus methods based on measures performed under Worst Case Scenario are usually

optimistic methods. That means they estimate a WCET with some level of confidence, but do not guarantee

that it is an upper bound. Yet such a method can be further corrected to provide pessimistic bounds on the WCET. It requires the determination of a Worst Case Scenario of input parameters for the tested Airborne Software.

However, this Worst Case Scenario may be difficult to determine accurately. Indeed, it would require itself timing information on the processor services. Moreover, Worst Case Scenario definition has to take into account all possible states for the processor (but corrections may be done to simplify this step). However, this family of methods saves the human and technical cost of defining an accurate model of the platform. Today, it is more widely used in the industry. We identified the following tools:

 RapiTime: This proprietary tool is based on a hand definition of the worst case scenario, with automated assist for program analysis. It provides a framework under which a code coverage analysis can be done so that the Worst Case Scenario can be ensured. Finally, it determines the key

MULCORS

EASA

Processing a WCET on a multicore processor introduces additional issues that are linked to:

 The impact of concurrent accesses to the interconnect. Here, considering that each interconnect access will occur in the worst case situation may lead to an over approximation of the real WCET. We refer here to the RGL n°9

 The impact of concurrent accesses to the main memory that can be interleaved in an inefficient way. We refer to the RGL n°21.

In the case of IMA, we consider that in the case of incremental certification, the platform provider does not have any visibility into the embedded Airborne Software, and the system integrator cannot suppose it has visibility. Thus the WCET analysis method must be applied to all Airborne Software applications independently.

MULCORS

EASA

9.9. EASA GUIDELINE FOR MULTI-CORE PLATFORMS

In document MULCORS-UseofMULticore procesorsinairbornesystems (Page 120-123)