Safety and security in multicore systems: How to successfully implement them

The demands placed on safety-relevant control systems are constantly increasing. Multicore architectures are best suited to handle these tasks and are therefore being offered and used more frequently. 

Safety standards are defined in various industries according to the potential hazards posed by, for example, a device, machine, or vehicle. To ensure the functional safety of the system or machine, a higher level of hazard necessitates more monitoring mechanisms. Well-known examples of this are the SIL and ASIL (Automotive SIL) specifications.

The new Multicore microcontroller architectures They offer multiple processing cores (CPUs) on one chip and have shared global resources.

Figure 1: Global and shared resources in a multicore microcontroller architecture

The processing cores can handle tasks with varying safety requirements in parallel. In such applications, it is crucial to isolate the resources required for each task and protect them from unauthorized modification. Therefore, we must guarantee the integrity of the application data, its processing, and transmission to ensure secure applications.

The multicore microcontroller components therefore contain a number of monitoring mechanisms and function blocks that monitor the correct operation of safety-relevant functions. In the event of a detected error or malfunction, the system must trigger a predefined error response within a precisely defined time period (e.g., within 10 ms).

The Monitoring mechanisms include:

• surveillance error-free system functionalities (vital System Parts):
  • Voltage monitoring for over- and undervoltage detection
  • Operating frequency monitoring for exceedance or undershooting
  • Silicon temperature monitoring
• Monitoring of Data:
  • Through error detection and error correction mechanisms by using error correction codes (ECC) for the data in all SRAMs and flash memory.
• Monitoring of internal data communication:
  • By transferring data Error Correction Codes (ECC) and checking or correcting in the data destination
• Monitoring of Access authorization on memory- and Peripheral modules with Access protection units for monitoring:
  • Write and read access to data storage via Memory Protection Units (MPUs)
  • Write access permission to (peripheral) modules via Access Control Units
• Monitoring of Software processing (Software Expiration Backup):
  • Command processing of safety-relevant software in the Safety CPU (CPU with checker / lockstep core)
  • Software execution protection through core-specific watchdog timers and
    Safety-relevant software through the global Safety Watchdog Timer
  • Differentiation between safety-relevant and non-safety-relevant software through Safety Status Bits

Central fault reporting unit with individually programmable fault responses (Fault Collection and Control Unit FCCU or Safety Management Unit SMU):

All errors are reported to this central unit. The user can program individual error responses for each error type:

• Calling an interrupt function with selectable interrupt priority
• Calling a trap function
• Triggering a reset to restart the software
• Signaling the fault condition externally via specific signaling ports or pins.

Figure 2: Central fault reporting and fault response unit (SMU)

What expertise is required for the error correction mechanisms?

The advantage of this safety implementation lies in the possibility of software-independent fault response: The fault response can be individually configured by the user for each fault type and reacts to faults in the vital parts of the system (e.g., faults in the power and clock supply) in a hardware-controlled manner, meaning no software processing is required. The sum of all implemented safety methods guarantees that the system can be brought to a safe state in the event of a fault, thus serving to protect against hazards, prevent damage, and minimize risks.

The following knowledge is required to create systems with multicore microcontrollers that can trigger fault monitoring and the necessary fault responses according to the different safety classes:

• knowledge of Requirements Engineering and Requirements Management
  • How do I define and manage correct and meaningful requirements for a safety-relevant system?
• Knowledge for the correct Module selection from Multicore microcontroller architectures
  • How do I choose the right multicore microcontroller?
• knowledge of Software architecture for Hard realtime multicore systems
  • How do I design a software architecture that properly addresses the challenges of a multicore architecture for hard real-time applications?
• knowledge of Resource Management
  • How do I allocate the available multicore resources to meet the system's requirements?
• knowledge of Multicore–Debugging, Multicore–Tracens and the Software testing of safety-relevant multicore systems
  • What do I need to consider when debugging safety-relevant multicore systems?
  • What challenges do multicore systems pose when debugging?
  • How can I ensure that my safety-relevant multicore system meets the time requirements and prove this through trace recordings?
  • How do I handle trace recordings with bandwidth-limited trace interfaces?
  • What do I need to know and consider when testing multicore systems to ensure that the tests are truly comprehensive?

Security aspects of multicore systems

Depending on the type of system, different security requirements (confidentiality, availability, and data integrity) are placed on it. Millions of euros in damages are incurred annually.

• In the automotive industry, this is achieved by modifying the control software in the vehicle (so-called software tuning, e.g. to increase engine power).
• In the world of IoT (Internet of Things): How can we protect our accounts from unauthorized access via the internet?

The new multicore microcontrollers incorporate their own security cores. These are protected against unauthorized access within the multicore microcontroller by an internal firewall. These security architectures include encryption and decryption modules, such as:

• AES modules (Advanced Encryption Standard Module)
• Random Number Generator (RNG)
• Access-protected storage for the security core (secure RAM for storing security keys, protected programs or functions and data)

Figure 3: Example of a security module in an Infineon AURIX multicore microcontroller

By strictly separating this security domain from the rest of the system (Trust Zone for Security Application), external attacks can be better defended against.

Further information

MicroConsult expertise on the topic of multicore & microcontrollers

MicroConsult Training & Coaching on the topic of multicore

MicroConsult Training & Coaching on the topic of Safety & Security