Aurix microcontrollers: Playing it safe

12/15/2020 Know-How

The importance of safety is growing in all technical areas. Developers are therefore increasingly required to design conclusive safety concepts that take the individual components into account, right down to the smallest detail. At the heart of a system are its microcontrollers.

In terms of functional safety, IEC 61508 provides the key specifications. It comprises a series of standards for the “functional safety of electrical/electronic/programmable electronic safety-related systems”. In addition, there are slightly adapted standards for certain areas of application, which are subordinate to IEC 61508. The respective adaptation of IEC 61508 to the specific conditions in the automotive sector is the ISO 26262 series of standards – “electrical/electronic safety-relevant systems in road vehicles”.


Numerous safety features

Besides meeting the requirements of ISO 26262 to ASIL-D, Infineon’s Aurix 32-bit microcontroller was also developed as an SEooC (Safety Element out of Context). This means that the derivatives of the Aurix range can be integrated into a safety-relevant overall system due to their safety features.
The second generation of the Aurix range is manufactured in 40nm embedded flash technology and is fully automotive qualified. Thanks to six TriCore processor cores with up to 300 MHz, it offers significantly more computing power than its predecessor (1st generation, TC2x: 740DMIPS; 2nd generation, TC3x: 2400DMIPS).
The functional safety support also makes the Aurix microcontroller particularly interesting for industrial applications. The following hardware and software safety features ensure the Aurix microcontroller is highly suited for safety-critical applications:

  • Checker cores
  • Flash & RAM ECC (Error Correcting Code)
  • Safe SRI (crossbar)
  • Voltage, frequency and peripheral monitoring
  • Safety Management Unit (SMU)
  • SafeTpack safety manager
  • Logic Built-In Self-Test (LBIST)


Safety characteristics

The checker cores run in the background and monitor the processor. All operations are executed twice. As soon as varying results are achieved, an error message is issued by the SMU.
Both the Flash and the RAM have an integrated ECC function. This error detection procedure determines whether there is an error relating to the storage or transmission of data. If such an error is detected, it can be corrected.
Via SRI (Shared Resource Interconnection), also known as crossbar, data is transmitted back and forth between the cores and the memory. These connections are secured by hardware mechanisms in the form of end-to-end connections.
The second generation of Aurix microcontrollers is based on an operating voltage of 3.3V and a frequency of 300MHz. An alarm is generated if the permissible tolerances are exceeded or undercut. Peripheral devices can, for example, be monitored via a CRC (Cyclic Redundancy Check). Checksums are used to check correct data transmission during this procedure.
As an integrated hardware IP in the Aurix microcontroller, the Safety Management Unit is responsible for recording, processing and evaluating all safety-related errors.
SafeTpack is a comprehensive safety manager for the second generation of Aurix microcontrollers developed by Hitex. It coordinates the execution of commissioning and cyclic tests that ensure correct operation of the Aurix processor cores and internal buses through a blend of hardware and software modules.
The Logic Built-In Self-Test is part of the SafeTpack software library. It gives developers the opportunity to use software to ensure the Aurix microcontroller functions correctly each time the controller is started.
These hardware and software features create a level of safety that cannot be achieved easily with a standard microcontroller.


Implementing functional safety

Functional safety, however, cannot be achieved with the microcontroller alone; rather, it must be seen as a central component of the overall design. The safety of the overall system can only be guaranteed when developing a safety concept from the outset and pursuing it with intensity. This complex process can be summarized in five steps.

1. Performing a hazard and risk analysis
The risk analysis must determine the extent to which safety-critical applications are taken into consideration and the extent to which they must be complied with in relation to legal functional safety requirements. A variety of methods are available for this purpose. For example, HARA (Hazard Analysis and Risk Assessment) is popular. It can be used to determine whether a system is a safety-relevant system and, if so, how high the degree of safety relevance is.

2. Defining the safety requirement level
Depending on the standard, there are various safety requirement levels. For industrial applications, IEC 61508 defines the so-called “Safety Integrity Level (SIL)”, featuring the levels SIL1 to SIL4. Which level is actually relevant can be determined in a matrix using the combination of the parameters ‘extent of damage’, ‘length of stay’, ‘protection against danger’ and ‘likelihood of occurrence’.
Similarly, ISO 26262 defines the adequate safety criteria for automotive environments. In this case, the safety levels are referred to as ASIL-A to ASIL-D.

3. Determining components and implementing the design
The most suitable component is chosen for implementation of a desired application. To achieve this goal, specific safety functions must be taken into account. It is then possible to design the layout of the board and populate it accordingly. Once the hardware has been set up, the software can be implemented. A conclusive safety concept must be developed and put into practice, especially when programming the microcontroller. Since the microcontroller is the central control unit.

4. Validating the safety function
The validation procedure shows whether all safety-relevant functions are working properly – i.e. each individual function, independent of the overall system. If one or more of them do not work according to the specifications, they can be revised during the development phase. This procedure is repeated as often as necessary until all the safety functions meet the requirements.

5. Verifying safety
Verification is the second part of the check that occurs after validation. It involves checking the flawless operation of the system using checklists. In contrast to validation, verification considers the system as a whole. Independent certification authorities, such as TÜV in Germany, support this step and certify safety according to the legal requirements.


Comprehensive support from the network of partners

Programming an intricate microcontroller such as Aurix is complex, especially when safety aspects are added. To support developers and accelerate programming, Infineon has developed the PDH (Preferred Design House) concept for all customers. An overview of all the partner companies included in the PDH and their expertise is listed at
The PDH model includes free and paid support services. For example, customers receive 1st level support as well as consulting and training services free of charge. While complete implementation of hardware and software components is available to customers at a charge. Rutronik partner Hitex also offers corresponding support. Over the years, the company has earned a reputation as a functional safety specialist. While Rutronik provides developers with comprehensive support during the development phase, customers enjoy on-going support from Hitex for complete and successful implementation of a complex functionality.


Find components at

Subscribe to our newsletter and stay updated.