Читать книгу Multi-Processor System-on-Chip 1 - Liliana Andrade - Страница 32

In the case of automated driving applications (Figure 2.5), the perception and the path planning functions require programmability, high performances and energy efficiency, which leads to the use of multi-core or GPGPU many-core processors. Multi-core processing entails significant execution resource sharing on the memory hierarchy, which negatively impacts time predictability (Wilhelm and Reineke 2012). Even with a predictable execution model (Forsberg et al. 2017), the functional safety of perception and path planning functions may only reach ISO 26262 ASIL-B. Conversely, vehicle control algorithms, as well as sensor and actuator management, must be delegated to electronic control units that are specifically designed to host ASIL-D functions.

Similarly, unmanned aerial vehicle applications targeted by the MPPA processor are composed of two criticality domains, one being safety-critical and the other non-safety-critical (Figure 2.6). On the MPPA processor, these two domains can be segregated by physical isolation mechanisms, ensuring that no execution resources can be shared between them. The safety-critical domain hosts the trajectory control partition (DO-178C DAL-A/B). The non-critical domain hosts a secured communication partition (ED-202 SAL-3), a data management partition (DAL-E) running on Linux, machine learning and other embedded high-performance computing partitions running on a lightweight POSIX OS. Of interest is the fact that the secured partition is located in the non-safety-critical domain, as the availability requirements of functional safety are incompatible with the integrity requirements of cyber-security.

Figure 2.5. Autoware automated driving system functions (CNX 2019)

Figure 2.6. Application domains and partitions on the MPPA3 processor

Finally, embedded applications in the areas of defense, avionics and automotive have common requirements in the area of cyber-security (Table 2.1). The foundation is the availability of a hardware root of trust (RoT), i.e. a secured component that can be inherently trusted. Such RoT can be provided either as an external hardware security module (HSM), or integrated into the system-on-chip as a central security module (CSM). In both cases, this security module maintains the device’s critical security parameters (CSP) such as public authentication keys, device identity and master encryption keys in a non-volatile secured memory. The security module embeds a TRNG, hashing, symmetric and public-key cryptographic accelerators, in order to support the chain of trust through digital signature verification of firmware and software.

Table 2.1. Cyber-security requirements by application area

	Defense	Avionics	Automotive
Hardware root of trust
Physical attack protection
Software and firmware authentication
Boot firmware confidentiality
Application code confidentiality
Event data record integrity