If you purchase prebuilt (Automotive) Safety Integrity Level – ISO 26262/IEC 61508 or other – packages, what kind of guarantees do you need from the vendor to ensure it is compliant in the larger sense?
This question assumes that as an OEM, you are purchasing subsystems from vendors that claim Automotive Safety Integrity Level (ASIL), A, B, C, or D per ISO 26262 or Safety Integrity Level (SIL) 1-4 per IE C 61508, or similar per other safety standards. The standard could be in any industry, automotive, or otherwise. The supplier’s intent in claiming a SIL is to sell their product into a safety-critical application rather than in the general commercial products. Therefore, they are claiming that they have taken steps to achieve that purpose. However, the exact steps a supplier takes define the credibility of that solution, and the steps an OEM takes to validate the overall implementation and the final system solution are key to the “guarantee” of that SIL. In order to understand this better, let’s use specific examples of hardware and a software solution.
The examples selected do not reflect recommendations for these specific vendors. The specific vendors offer “certified solutions” in the marketplace that are available for purchase today and are known across industries.
Common Application: High-Voltage Motor Controller for Automotive Electric Vehicle (EV) applications:
- Hardware Purchased: Texas Instruments (TI) Hercules Processor
- Software Purchased: Green Hills Safety-Certified RTOS Platform
Texas Instruments (TI) Hercules Processor Definition of Prebuilt SIL Package
Both of the packages above have been certified as compliant to safety certification standards. The TI Hercules set offers the following information:
- IEC 61508 SIL 3-certified by TÜV SÜD
- Up to 330 MHz
- Industrial automation and control applications
- 105C ambient temperature
- Ethernet, USB, CAN, timers, ADCs and more
- ISO 26262 ASIL D- and SIL 3-certified by TÜV SÜD
- Up to 300 MHz
- Transportation applications
- 125C ambient temperature
- FlexRay, ethernet, CAN, timers, ADCs and
The general applications are identified, as well as the temperature range, the SIL certification, and major internal features (e.g., FlexRay, ethernet).
Furthermore, a specific certification section is provided with a list of documentation included. Deciphering this documentation is key to understanding the usage of the package.
- Functional safety development process certification: The process followed by TI in the development of this chip was compliant to the methods described in ISO 26262/IEC 61508 for the assumptions listed. As a chip provider they are responsible for only certain parts of the standards, given they meet the criteria of a hardware component (ISO 26262 Part 8). Note that it does NOT meet the intent of Parts 3, 4, 5, or 6 for the final application, but is “capable” of being used in such an application.
- Request SafeTI™ SoC documentation (safety analysis reports and SafeTI E2E™ community forum): User forums and safety documentation related to the above-listed efforts.
- SafeTI™ Compiler Qualification Kit: TI provides compilers that go with their processors. Those compilers must meet tool qualification standards in safety-related product development (ISO 26262 Part 8). This is a method that can be used to meet tool qualification for ISO 26262.
- SafeTI™ HALCoGen compliance support package: This package assists customers using HALCoGen to comply with functional safety standards by providing documentation, reports, and unit test capability. This is a TI-based tool that meets some instances of traceability and testing, but is very limited in the overall application.
- SafeTI™ diagnostic library compliance support package: Any library used in the safety-critical application must be qualified as a software component (ISO 26262 Part 8). The diagnostic library compliance support package is an example of such certified libraries.
These are the documents we can find to support the certification of this chip. Since TI is not an automotive OEM, they have made assumptions around the usage of their product (i.e., safety certification standards are written from the perspective of the vehicle). And then they seem to have followed a rigorous process to get certification of this chip with those given assumptions. On top of that, they provide some user tools that help meet some parts of the standards. From a technical standpoint, the user must be aware of those assumptions and utilize the product only in the intended methods described in the given list of documentation. Furthermore, the user must integrate all the tools into a full workflow that meets the entire intent of the safety standards.
In a motor controls application, a drive section and surrounding printed circuit board (PCB) circuitry must be designed around the TI Hercules chip to drive the motor. None of that is described or supported by the TI certification. The design of the circuitry and its associated safety certification is ultimately what the end user needs. Buying a certified chip is a good start but only a very small piece of the overall puzzle.
If you search online for a safety-certified real-time operating system (RTOS), you will find a few niche suppliers. For the purpose of this example, the Green Hills platform is being used. The Green Hills platform for industrial safety lists the following as main features.
Green Hills Safety-Certified RTOS Platform Definition of Prebuilt SIL Package
- A complete solution
- IEC 61508 SIL 3-certified RTOS
- Proven in safety-critical systems
- Integrated middleware
- Development tools
- Platform services
These features wrap around an integrity-certified kernel with platform components such as:
- Integrity RTOS:
- Pre-certified to IEC 61508 (SIL 3) and EN 50128 (Software SIL 4)
- Safety manual for INTEGRITY
- Safety report describing applicable certification and use
- RTOS for memory-constrained applications
- Optional middleware components:
- File systems, USB, TCP/IP, graphics
- Industrial protocols: Ethernet/IP, EtherCAT, CANopen, PROFIBUS, PROFINET
- Embedded firewall, secure communications protocols
- IEC 61131 run-time environment
- Development tools:
- MULTI IDE and Green Hills Compiler – qualified to IEC 61508 (SIL 4), EN 50128 (SIL 4), and ISO 26262 (Automotive SIL D)
- Integration of third-party tools and services
From a safety perspective, the kernel and the tools are pre-certified by TÜV NORD. That is a significant savings from both a software-safety standpoint (ISO 26262 Part 6) and a tool-qualification standpoint (ISO 26262 Part 8). What it does NOT offer is a complete solution to the safety certification problem. It offers a CAPABLE platform.
For motor controls applications, a commutation algorithm (switching) and controls application (e.g., traction) need to be built on top of the Green Hills platform. These tools need to be integrated into the developer’s workflow, with coverage for all aspects of safety certification (management, systems, hardware, software, config management, change management). The purchasers must also assess the cost of purchasing certified systems and the overhead in an RTOS relative to the work of custom targeted development. In smaller applications like motor controls, a simple deterministic scheduler is often preferable and more cost effective than a full-blown RTOS. However, that is a discussion for a future blog post, as it is a far more specific target-technical tradeoff discussion.
In summary, the purchase of a TI-certified processor and a Green Hill-certified kernel and toolchain is a good start towards safety certification of your product. Unfortunately, it does NOT relieve you as the user of the components from having to implement functional safety and assess the final application (i.e., ISO 26262 Parts 2-8). It does relieve you from having to audit these suppliers, as they have already received third-party certification. The real question becomes: Is it worth it to pay a premium for certified product, or should you develop the application with non-certified components and certify the final application? Both options are very possible, and the answer to that is very application specific.
Going back to the original question of what guarantees that you get a pre-certified package (or system) meeting the intent of functional safety, the answer is: You don’t get any guarantees! It is almost always a user-beware and a risk assessment process.
Product vs. Process Certification
Most of this discussion has revolved around a tier I or tier II supplier buying certified components. In the case of an OEM buying a system, a different approach must be taken. A tier I or tier II supplier that claims safety certification (for a motor drive, for example) should be identified and managed within the supply chain of the OEM. Audits should be performed to ensure that the process was followed (and maintained!) and that the safety goals and mitigations were implemented. These audits become a price of entry with corrective actions for failures. These are no different than the manufacturing audits that are performed as a part of AS9100 or ISO 9001, with the exception that there is a much stronger engineering focus when safety in the design is being assessed.
An additional detail that needs to be understood is the difference between product certification and process certification. If a supplier is certifying their process, they are ensuring the company has the methods, tools, and training in place to develop safety-based products. Therefore, the guarantee is that the company operates per safety standards recommendations and NOT that the product in questions has gone through the rigorous efforts of certification. If they are certifying a product, they are stating that the product has met all the requirements of the SIL or ASIL, and therefore, is ready to be used in safety-based applications. There are many tradeoffs and reasons why to choose either option. They are summarized in the table below.