6 Application-specific Task Partitioning and Safety Concept for Tell-tales

Tell-tales are the warning lights or indicators on the digital cluster that are crucial for the safety of the vehicle. Tell-tales can be used to convey different types of information from failure, such as low oil level, high engine temperature, and low tire pressure, to information like brake lights and turn signals. As tell-tales are safety critical, there are two main methods in which tell-tale displays are supported in AM62x, either hardware- or software-based.

The hardware-based method for supporting tell-tale displays in the AM62x uses the Safety Island Cortex® M4F to directly run the hardware tell-tale signs driver. Figure 6-1 shows this hardware-based method for tell-tale display.

The software-based method is to have the tell-tales supported in software with the tell-tales directly overlayed on the main cluster display. Figure 6-2 shows a high-level partitioning of the various functions within a software tell-tale cluster application (without GPU rendering).

The Device Manager (DM) R5F performs tell-tale rendering along with the Display Subsystem (DSS) driver that renders data to an independent display pipeline in the DSS. Primary display cluster data is rendered by the A53 cores through another DSS pipeline. The DM R5 also executes the AUTOSAR® and CAN stacks.

The MCU domain, which has Freedom from Interference (FFI) from the rest of the device, executes the safety cross-monitoring of the tell-tale reference signature that is loaded by DM R5F. MCU M4F checks that MISR reference signature is loaded correctly by R5 into the DSS. Additional checks include the MISR reference signature and calculated MISR comparison. Program sequence monitoring of the M4F core and DM R5 core must be performed to protect safety core execution from random faults.

Software diagnostics and hardware diagnostics for each IP within the data flow, provide fault detection and reporting within the required fault-tolerant time interval (FTTI). Fault indications in terms of events or interrupts are routed to the error signal monitor (ESM) on the device, which provides configurable low-priority and high-priority interrupts to the safety core. Software running on MCU M4F can then take necessary action based on these interrupts. Another feature of the ESM is the safety error signal, which is routed to the error pin of the device. This error pin can be used by an external monitoring device to detect if the AM62x is in an unresponsive state and if intervention is required to bring the system to a safe state. For example, resetting the AM62x device or disabling downstream actuators.

FFI features that isolate the MCU domain from the main domain aid in restricting accesses to the MCU domain and performing functions of different safety integrity on the device. Mixed criticalilty can also be further extended to the main domain with the use of firewalls.