The Functional Safety Mirror
Feb 24th, 2020, Issue no.17, ISO 26262-4:2018, Technical Safety Concept (TSC)
This series is dedicated to the absolute functional safety beginners, system engineers or software engineers or anyone who wants to know about automotive functional safety ISO 26262 standard from ZERO.
Introduction
In this article, we will talk about the Hardware-Software Interface section of the technical safety concept at ISO 26262-4. Nevertheless, the norm did not mention that the HSI is for safety-related interfaces but we understand that from the context. The Hardware-Software Interface Specification (HSI) shall be provided as an input for the product development on the hardware level and on the software level and it will be refined further at HW and SW. That being said, you can make an initial version of HSI on the system level to set the outline for further development on HW and SW levels, see fig.1
Figure 1: Abstract concept of HSI
Why HSI So Important
HSI is used to describe the configuration and functionality of the SOC/processor/ microcontroller peripherals and how they interact with CPUs.
In figure.2, each programmable slave can be any kind of peripherals and CPU interact with via registers (R/W)
Figure 2: HSI
I remember when we are going to deliver our product and we needed to increase our resources to meet the deadline. Our technical manager requested a C# developer from another business line to help us for the next two weeks. I was responsible to update some configuration of the bootloader and asked him to update the application of battery management. I sent him the HW schematic to check for the correct ADC and Mux channels. " What are these rectangular drawings? I can't understand these 42 pages of many Boxes" he replied!
HSI document is used to communicate how we talk to HW elements (sensor, register, slave, memory, converter, multiplexer, IO, watchdog, CAN, LIN) via software code with the stakeholders: system engineers, system architects, software developers, safety engineers, and testers to name a few.
You will find different types of registers: indirect, UART, shadow, lock, interrupt, FIFO to name a few. Not all stakeholders are aware by all of these types; that being said, clear word/spreadsheet format is easy to understand.
Why Safety-related HSI Only
If you mention all Hardware-software interfaces of your complex system, it will yield gigantic documents that need a tool for easy access and the engineers will be lost in the details. Look at the following figure.3, each item can be decomposed into multiple systems and each system is composed of ECU at least and each ECU contains a system-on-chip, SOC.
If you have a 32-bit address bus, you can access 2^32 registers
Imagine a 64-bit address bus!
Imagine a multi-core SOC!
Thus, the documentation of the entire interface is mundane and is not manageable at all. So we select the safety-related interfaces to be documented.
Figure 3: Top-bottom view of Vehicle level
Hardware-software interface (HSI) specification
The specification of the HSI is initiated during the sub-phase “Technical safety concept.” The HSI specification is refined as development continues through hardware and software development, see the following figure of the HSI interaction with different phases.
In this part, the following requirements are applied to the HSI according to the ISO 26262-4 and the HSI can be in a standalone document and you just reference it in the TSC document.
1 The HSI specification shall specify the hardware and software interaction and be consistent with the technical safety concept.
The HSI specification shall include the component's hardware parts that are controlled by software and hardware resources that support the execution of the software.
To aid the specification of the HSI, the following HSI elements can be considered:
a) memory:1) volatile memory (e.g. RAM); 2) non-volatile memory (e.g. NVRAM)
b) bus interfaces [e.g. controller area network (CAN), local interconnect network (LIN), internal highspeed serial link (HSSL)]
c) converter:1) A/D converter;2) D/A converter;3) pulse-width modulation (PWM)
d) multiplexer; write down the channels that interact with the safety-related signals only
e) electrical I/O; write down the input/output digital/analog channels that receive/transmit safety-related signals, see figure 5.
领英推荐
f) watchdog:1) internal, 2) external.
Figure 5: Snapshot of HSI Signal List Attributes
2 The HSI specification shall include the following characteristics
a) interrupts; b) timing consistency;c) data integrity
d) initialization:1) memory and registers;2) boot management
e) message transfer:1) send message;2) receive message
f) network modes:1) sleeping;2) awakening
g) memory management:1) reading;2) writing;3) diagnostic;4) address space;5) data types
h) real-time counter:1) start counter;2) stop counter;3) freeze counter;4) load counter.
3 The relevant diagnostic capabilities of the hardware, and their use by the software, shall be specified in the HSI specification
a) the hardware diagnostic features shall be defined; and
example Detection of over-current, short-circuit or over-temperature.
b) the diagnostic features concerning the hardware, to be implemented in software, shall be defined.
4 The HSI shall be specified during the system architectural design
The HSI is refined during hardware development (see ISO 26262-5:2018, Clause 6) and during software development (see ISO 26262-6:2018, Clause 6), see figure.6 from ISO 26262-4 Annex-B that demonstrates signal list template
HSI & Automotive SPICE
If you opened the ASPICE, you will figure out the artifact outputs that mentioned hardware-software interface in the following Base Practices:
The following figure illustrates the affected consumers(to name a few) of the HSI specification:
Figure 6: Consumers of the HSI
Conclusion
HSI document plays an important role in the communication of the hardware-software interface between the key stakeholders. Unfortunately, as important as the HSI is in theory, the devil is in the details. When you go into practice, you will figure out challenges in making traceability of HSI and all affected consumers and to make it up to date so that all stakeholders can depend on it. There are many trials for developing HSI tools to make life easier. Finally, at the system phase, you just need to outline the initial interface specification before refining it in the SW and HW development phases.
We are still in the technical safety concept.
If you have best practices in this topic, kindly share with us.
Stay tuned!
Feel free to send me your opinion/findings, we learn from each other.
References
Considering the point 3 (i.e. the clause 6.4.7.3): - what do you mean for "hardware diagnostic features"? - what do you mean for "diagnostic features concerning the hardware, to be implemented in software"? I'd like to have your interpretation of this clause even giving a practical example. Thanks :)
Strategic Cybersecurity Expert: Securing Digital Assets, Driving Innovation, and Ensuring Cyber Resiliency.
4 年Abdelrahman Hassan Would love to have more insight from you about ISO 26262 Part 6 and it's implementation aspects
SW Technical Product Manager, Product owner, SW Expert, Embedded Software Architect, technical lead
5 年Great article, but I think most of section #2 HSI characteristics are TSC requirements more than HSI.
Functional Safety lead/ADAS/ EV/Clusters/FuSa
5 年Also I believe , HSI spec is not just about in defining a input and output details, it should have a hardware capabilities and limitations metrics. According to me the best practice would be in derriving a HSI document is by doing a HSI testing using a dedicated software and updating it with realistic data always!