Objective

In a modern centralized core computing architecture, software of different integrity level (ASIL) has to co-exist on a single system-on-chip (SoC).

We need to show that we have sufficient measures in place to ensure that the operation of safety-related software on this SoC cannot be compromised by non-safety software applications on the same platform, or by any of the non ASIL qualified parts of the platform or external elements with which it interfaces.

Factors to be considered

The operating system for the SoC is not designed to provide deterministic behaviour, or to fully partition the SoC hardware, as is for example AUTOSAR; it is a UNIX type OS. Although it is safety qualified it cannot guarantee timing, or manage access to all shared hardware resources.

On top of the OS is a layer of additional platform software. On top of that are the applications. There are hundreds of applications, being separately developed and integrated. The software applications depend on a number of external elements. Each of these external elements on which the software application immediately depends also depends on other elements. There is a network of dependencies. Interference with the application could come via any of these elements, but could originate in another element. We have to analyse a complex system.

The SoC hardware is considerably more complex than a simple micro-controller, with multiple CPU cores, and numerous shared hardware accelerators such as: GPU (graphics processing unit), DLA (neural net inference), PVA (image processing), OFA (optical flow).

The SoC sits at the centre of a complex network for communicating with other ECUs (electronic control units). Most of the applications are parts of larger systems that involve not only the core compute, but also these other ECUs.

Approach

Usually, either FTA (fault tree analysis) or FMEA (failure modes and effects analysis) is used to analyze risks of interference between software applications coexisting on the same platform. However, as the complexity of the execution platform rises, these methods become increasingly difficult to apply effectively. FFI is primarily a resource-contention and performance-interaction problem, whereas FTA and FMEA were developed primarily for fault analysis. To be effective, these methods need a single coherent design description to analyze, which does not exist for this platform, in which design information is spread between the SoC documentation, the platform software documentation, network documentation, and documentation for individual software applications. Initial attempts at analysis of this system using FTA resulted in very large fault trees, with many undeveloped branches, and many overlaps.

Another point to note is that purely fault-based analysis is not sufficient for emergent properties of a system such as FFI. It is possible for interference to occur, even though there is no fault that is the origin. This is particularly the case for complex software-based systems such as the automotive core.

As a result of the above considerations, it was decided to carry out an analysis using a scenario-based method in which a team of engineers with knowledge of the system work together to analyze risks of interference using a defined process to guide the work. The method used is similar to the threat and risk analysis (TARA) process used for cybersecurity in the ISO 21434 standard.

The process

The main steps of the analysis process used are:

• Step 1. Identify the element that is to be analyzed, its boundary, and its operational environment.
• Step 2. Consider for each element whether interference with aspects such as the following is a potential safety risk:
  – software programs
  – data in RAM (stack, heap, static data, shared data areas)
  – data in ROM (files, databases)
  – platform software services
  – operating system services
  – calibration data (data used at run-time)
  – configuration data (data used at build-time)
  – network communication
  – application to application interfaces
  – hardware-software interfaces (peripherals, accelerators)
  For each aspect, identify the interference outcomes that could result in a safety risk. Use guide-words such as the following to assist the analysis:
  – none (unavailable / missing / lack)
  – more (increased / excessive / faster /additional / repeated)
  – less (reduced / insufficient)
  – wrong (incorrect / inaccurate)
  – late (delayed / slower)
  – erratic (unpredictable / intermittent / oscillatory)
  – unintended (unexpected / undemanded / out-of-sequence)
  – other (different)
  – partial (incomplete)
  For each interference outcome assign a risk level: negligible; low; medium; or high.
• Step 3. For each combination of aspect and interference outcome with a risk level of medium or high, identify scenarios that could result in that outcome. Each scenario is a combination of events that together result in the interference outcome. Events could be: faults in no-or-lower elements; failures of design mechanisms intended to prevent interference; failures of development-time safety measures intended to prevent interference; non-fault events; operational situations; modes; or states.
• Step 4. For each interference scenario, evaluate whether it is a plausible risk of interference, taking into account the inclusion in the scenario of safety mechanisms or safety measures intended to prevent interference, and the different operational situations and operating modes or states.
  For each interference scenario assign a plausibility level : negligible; low; medium; or high.
  Provide a rationale for the plausibility level with reference to the existing safety mechanisms and safety measures.
• Step 5. For each interference scenario, decide how it is to be handled (treatment):
  retain – there are sufficient measures already in place to reduce the risk to a tolerable level
  reduce – additional measures will be put in place to reduce the risk to a tolerable level
  avoid – the risk will be removed by a design change other than adding safety mechanisms
  Treatment should be decided based on the combination of risk level and plausibility level.
• Step 6. For each aspect/outcome for which the risk is rated as low specify a verifiable claim to support this rating.
  For each interference scenario for which the treatment decision is “retain” specify the existing safety measures that are claimed that reduce the risk to a tolerable level.
• Step 7. For each interference scenario for which the treatment decision is “reduce” design and specify safety measures sufficient to reduce the risk to a tolerable level. Measures may be either additional safety mechanisms in the design of the element or related elements, or development-time safety measures.

The results

The process was applied for analysis of interference risks to a generic application. This meant that some aspects, which are dependent of the specific design of particular applications could not be analysed, as the scope of the analysis did not include this design. In particular, the risks of interference via shared hardware resources other than RAM could not be covered.

The analysis was able to show that there were existing measures in place to sufficiently reduce most of the identified risk scenarios. These measures were a combination of mechanisms in the design of the SoC and the platform software, and design constraints placed on the software developers. This is as expected, given the maturity of the system at the time of the analysis.

A few additional safety measures were identified from the analysis, these were additional design constaints and guidance to application developers, and constraints on configuration data for application scheduling.