Embedded Software Development

Software design challenges for real-time multicore MCU systems

Seite: 2/4

Anbieter zum Thema

AUTOSAR – a software standardization approach

Figure 2: AUTOSAR intra-core and inter-core communication
Figure 2: AUTOSAR intra-core and inter-core communication
(Image: MicroConsult)

The automotive sector was an important driving factor for new designs of powerful multicore microcontroller architectures. Automotive manufacturers (OEMs), component suppliers (Tier 1) as well as chip and software tool producers have defined the AUTOSAR standard (AUTomotive Open System ARchitecture) to reduce the effort for resp. improve the implementation of distributed systems in automotive applications.

AUTOSAR was developed for singlecore architectures. Some extensions have been implemented for multicore, including multicore operation for software processing. The architecture model defines a Virtual Function Bus (VFB) for task communication.

One new aspect was the extension of the communication layer (AUTOSAR includes the service Run-Time Environment RTE for the VFB) defined for intra-core task communication to intra-/inter-core communication (for core-to-core synchronized data exchange).

For the application described above, the RTE layer is completely ECU independent. The RTE transfer interface can be used
without the knowledge of the existing microcontroller hardware. This approach is very smart for the development of hardware independent and reusable software.

However, if you don’t know on which core your software task is executed and inter-task communication may require interrupt-driven data exchange, the result is probably not really efficient and predictable as regards timing. Hard real-time applications will not be able to guarantee very fast and time-critical processing. For safety relevant applications, the program flow for inter-core communication has to be supervised by a specific program flow service, e.g. to avoid data delivery timeouts.

Software safety and security considerations

Another aspect is the requirement for safety software processing that has to operate at a functional safety layer (like SIL or ASIL). Depending on the risk level, software tasks for safety applications have to be supervised through different methods, like the following:

  • Error correction codes (ECC) for supervising and correcting memory contents and inter-chip data communication (ECC detect and correct errors stored in memory, e.g. single bit errors are corrected and multiple uncorrectable errors are monitored).
  • Guaranteed error responses solved by a safety management unit (SMU) or fault
    collection and control unit (FCCU) – all detected failures respective errors are monitored and reported to this system, resulting in a user-defined response, such as error function, reset or signaling error via pin to an external environment.
  • A memory protection unit (MPU) can be programmed to allow access to preselected memory space for execute, read, write, or read + write. Access to other areas without access enable results in an error signaling.