TÜV-Certified Generic ASIL-C Control Units

Electronic vehicle functions are increasingly gaining in importance in the commercial vehicles sector. To ensure that these functions are safe and reliable, the International Organization for Standardization (ISO) has developed the ISO 26262 standard. In addition, requirements for the cybersecurity of the EE architecture must be met in accordance with ISO 21434. These two standards are specifically designed for the development of safety-critical electronic systems in vehicles and specify detailed requirements for the individual steps of the development process.

The requirements derived from the standards create a massive need for adjustment for many manufacturers and OEMs, and especially for small and medium-sized enterprises:

• Sharply rising costs for documentation and processes
• More complex hardware and software development
• Certified, generic control systems for small production volumes are hard to come by

The results: Development projects are becoming expensive, time-consuming and extremely hard to tackle for some enterprises.

To overcome these obstacles, Fraunhofer IVI, ECUtronic GmbH and Sontheim Industrie Elektronik GmbH have dveloped a continouos process chain, from concept stage to series production. It meets the requirements of the relevant ISO standards without the need for complex application-specific hardware development. At its heart is a TÜV-certified, generic control unit with a large number of secure inputs and outputs at ASIL-C level and a separate QM area for less safety-relevant functions.

Complemented by certified middleware, the unit fulfills the requirements of ISO 26262 and also takes into account solutions according to ISO 21434. This allows customer-specific functions to be implemented in a standards-compliant way without requiring complex application-related hardware development each time.

In this first process step, companies lay the foundation for developing a safe product in accordance with ISO 26262 and ISO 21434. This includes:

• Definition of safety-related requirements (identification of potential hazards and specification of safety objectives)
• Developing the system architecture and design
• Formal safety management
• Implementation of a requirements management system (if this has not been part of the product development process before).

Fraunhofer IVI has over twenty years of experience in innovative and safety-oriented functional development for the commercial and special-purpose vehicle industry and is therefore the ideal partner for this process step. Its employees are familiar with the relevant constraints and have expertise in both ISO 26262 and typical small- and medium-volume applications in the truck, bus, trailer, agricultural and construction machinery, and special-purpose vehicle sectors.

At the end of the concept phase, it often becomes apparent that electronic control systems are required to implement the planned functions. For small to medium quantities, it makes sense to use generic, pre-developed control systems in order to stay within the projects' time and cost limits. Although this approach is state of the art and widely used for mobile and stationary machines, such control systems are still rare within the scope of ISO 26262 and ISO 21434.

The generic contro unit is certified according to lSO 26262:2011 ASIL C. It covers a broad spectrum of applications and its use is economical even for small to medium quantities. Thanks to its generic principle, it can service a diverse range of applications, whether in agriculture or in the construction, truck, trailer or bus sectors.

Hardware security

The basic hardware security principle for the control unit (ECU) consists of using a security microcontroller with a monitoring function, including a watchdog (the so-called companion chip), all of which are pre-certified. The security microcontroller has a built-in self-diagnostic function, which is also activated and read back by the firmware. In the event of a failure, the control unit is safely muted. In this error case, the ECU outputs are deactivated and communication with the surrounding systems is interrupted. In addition, the ECU architecture for the secure IOs is redundant and equipped with diagnostics.

Software security

In line with the requirement to be able to implement customer-specific projects with the control unit as quickly as possible, particular emphasis was placed on designing and completing the lower software layers in a largely project-independent manner. The security concept of the ECU software consists of a separation in the firmware between a secure partition with extended, fairly strict control mechanisms and a QM partition with less strict software specifications. These are separated by the Memory Protection Unit (MPU) and supported by the real-time operating system.

Technical details of the control unit

• VielMultitude of secure input and output options at ASIL-C level
• QM area for less critical functions
• Support for hydraulic valves with high current carrying capacity
• Robust design for rough application areas (trucks, buses, trailers, special-purpose vehicles in agriculture and construction)
• Redundant security architecture with comprehensive diagnosis system
• Secure firmware partitioning (secure area and QM area, MPU-aided)
• Basic software with secure drivers
• Implementation options according to AUTOSAR or Complex Device Driver (CDD)
• Integrated E2E communication library

The close networking between the control hardware, its operating system, and the intended software and security architecture is a complex and costly challenge in the development of customer-specific application software. Through the established cooperation between the partners Sontheim and ECUtronic, all interfaces and procedures for a joint service offer were coordinated and the networking of the software modules across projects was implemented.

As a result, it is possible to focus on the specific customer-specific application with a few adjustments to the surrounding software modules during functionally safe software development.

The specific process steps in application development include:

• Development of the software architecture, taking into account the existing architectural features of the control unit solution
• Creation of module specifications for all components involved in the application
• Programming and implementation of the software
• Integration and testing of components (functional and non-functional)
• Verification of the functions and interaction of hardware and software
• Approval, provided that all safety-related requirements are met and risks have been minimized to an acceptable level