Overview

Bluewind explains the process of integrating iLLDs Aurix software drivers to enable a project compliant with IEC 61508 (or other similar Safety International Standards referred by the Construction, Agriculture, Off-highway and Heavy duty industries). Similarly, the same approach has been exploited for Automotive “non-AUTOSAR” designs.

Infineon Aurix is a very powerful CPU capable of solving projects, both in the automotive and industrial, fields, due to its sophisticated peripherals. Complex architectures can be designed based on the configuration and combination of these devices.

To simplify the use of peripherals Infineon provides a set of related drivers, collected in two types of libraries: iLLD and MCAL. We will explain briefly what these drivers are, what are the basic principles of IEC 61508 involved in the integration, and when iLLD should be suggested for specific project types.

Solution

The IEC 61508 provides a well-defined development process aimed to design electronic products that work correctly (or fail in a controlled and predictable way, for the matter). It is widely adopted in the Industrial sectors, and a number of derived international standards are related to it. The principles explained in the White Paper can be applied to most non-AUTOSAR electronic designs including Automotive.

A team must decide to include a driver library by evaluating its impact in terms of safety.
During the architecture phase, when all Safety Functions are “translated” into Safety Requirements, it has to be estimated whether it is better to include a “certified” library, (i.e. MCAL) or a non certified one (i.e. iLLD).

As a further step, in the latter case the team has to evaluate: is it required to certify the new library, or rather avoid this by encapsulating it in a “software architecture” that intrinsically protects it?
These are some recurrent questions emerging during the first design phase in a Safety context.

Implementation

PXROS-HR (Portable eXtendible Realtime Operating System – High Reliability) is a realtime operating system for embedded systems. In comparison to other realtime operating systems, PXROS-HR has some special features, such as Encapsulated Tasks, assisted by hardware memory protection.

We focuses on Encapsulated Tasks, assisted by hardware memory protection, because by encapsulating a iLLD driver inside a task we are isolating it from other processes (Tasks). In case of failure, the system detects it and can define the action for that event. This is why we are going to include an iLLD driver (for instance the CAN driver) in a task by interfacing it with the application.

Conclusions: benefits and constraints

In general the use of iLLD in a IEC 61508 development has to be evaluated according to the SIL (Safety Integrity level), to the safety functions, and to the project investments trade-offs.
Obvious immediate benefits are low or zero costs for driver licenses.

Much more meaningful, is the opportunity to design simpler, more maintainable code, in a less expensive project environment. This is due to the lack of the complexity of the AUTOSAR framework.

On the other hand, the integration of a non certified driver set like iLLD may imply more engineering work for the analysis, documentation and test process.
The choice between the iLLD, MCAL or other libraries is not normally a black-or-white decision, but there is a suggested process to follow in order to take the best direction.