The Functional Safety Mirror

June 20, 2020, Issue no.21, ISO 26262-4:2018, Development on System Level

This series is dedicated to absolute functional safety beginners, system engineers or software engineers, or anyone who wants to know about automotive functional safety ISO 26262 standard from ZERO. Disclaimer, this series only expresses the author's view of ISO 26262 and not the view of any company, institution, or organization.

Introduction

In the?last article, we covered how to integrate Hardware-Software Integration. In this article, we will briefly cover the integration of the system elements to build the safe item definition. The item integration of the safety-related functionalities against the FSR & TSRs is crucial to the safety validation on the vehicle level.

System integration and testing

In this context, the system is the item definition.

Let us see system integration and testing

System Integration

You have followed the specification of the integration testing plan to assure by testing the following:

• integrated elements interact correctly
• integrated elements comply with FSRs & TSRs
• absence of unintended behavior that could violate the safety goal; there are unintended faults that might not violate the safety goal

Test goals and test methods during system testing

the notations: a,b, and c ...

A requirements-based test denotes a test against functional and non-functional requirements.

Regardless that safety requirements are non-functional, or general, the integration testing team tests both functional and non-functional requirements.

How will they test that?

Against the system: test plan & test specs

b test cases that will cover all scenarios that might trigger hazards on the system are endless. Therefore, you have to develop test cases that generate faults into your system to measure the performance of your safety mechanisms. Why?

As the normal operation scenarios of the item will not invoke the hazardous events.

c A back-to-back test compares the responses of the test object with the responses of a simulation model to the same stimuli, to detect differences between the behavior of the model and its implementation. Therefore, it is used for ASIL-D as it is implemented as model-based.

The correct functional performance, accuracy, coverage of failure modes at the system level, and timing of the safety mechanisms at the system level shall be demonstrated using test methods listed in Table 10. This requirement applies to ASIL (A), (B), (C), and D.

b In the context of demonstrating the effectiveness of the safety mechanisms' failure mode coverage at the system level, a fault injection method-based test means to introduce faults into the test object during runtime. This can be done within the software via a special test interface or specially prepared hardware.

This approach is valid for a limited set of fault models, i.e. the simple ones that can be realistically injected at the system level (like reproducing a stuck-at in a component pin). For fault models at the semiconductor level (like soft errors or transistor stuck-at), the fault injection method is applied at a more detailed level as described in ISO 26262-11:2018, 4.8.

c A performance test can verify the performance (e.g. actuator speed or strength, whole system response times) of the safety mechanisms of the system.

d An error guessing test uses expert knowledge and data collected through lessons learned to anticipate errors in the system. Then a set of tests along with adequate test facilities is designed to check for these errors. Error guessing is an effective method given to a tester who has previous experience with similar systems.

e A test derived from field experience and data gathered from the field, see fig.1

Fig1. WAYMO car collects data from the field

Evidence for the consistent and correct implementation of the external and internal interfaces at the system level shall be provided by using test methods listed in Table 11.

the notations: a and b ...

An interface test of the system includes tests of analog and digital inputs and outputs, boundary tests, and equivalence-class tests, to completely test the specified interfaces, compatibility, timings, and other specified characteristics of the system. Internal interfaces of the system can be tested by static tests (e.g. match of plug connectors) as well as by dynamic tests concerning bus communications or any other interface between system elements.

b A communication and interaction test includes tests of the communication between the system elements, as well as between the system under test and other vehicle systems during runtime, against the functional and non-functional requirements.

The level of robustness at the system level shall be demonstrated using test methods listed in Table 12.

At the system level, resource usage testing is usually performed in dynamic environments (e.g. lab cars or prototypes). Issues to test include power consumption and bus load.

How can I calculate the bus load of my CAN bus based on frame sending intervals?

1 CAN frame contains approximately 125 bit. (classic CAN, not CANFD)

Given we are using 500 kBit/s bit rate:

bit time = 1 / bit rate = 1 / (500 * 1000) s = 2 * 10-6?s = 2 μs

This means 1 bit will take 2 μs to transfer on bus when using 500 kBit/s.

So the approximate time to transfer 1 frame is? (2 μs/bit * 125 bit) = 250 μs.

The bus load for 1 message every 100 ms with 500 kBit/s can be calculated as below:

Given that every 100 ms one (1) message will be sent

In 100 ms the bus will be occupied for 250 μs.

So the bus load from these cyclic messages is
250 μs / 100 ms = (250 / (100*1000)) * 100 % = 25000 / 100000 % = 0.25 %

Let assume you have below multiple sending intervals on the bus as:

1 frame every 10 ms???? =? 100 frames every 1000 ms
1 frame every 100 ms??? =?? 10 frames every 1000 ms
1 frame every 1000 ms?? =??? 1 frame? ?every?1000 ms

This is in total? ??????????????????111 frames every 1000 ms

Total time on bus is????????? 111 * 250 μs

Total time is????????????????????? 1000 ms = 1000 * 1000 μs

Bus load is???????????????????????? ((111 * 250) / (1000 * 1000)) * 100 % =2.775 %        

This is just an estimated calculation based on some assumptions to get an overview. Please note that the CAN bus is not deterministic and bus load cannot be calculated exactly

b A stress test verifies the correct operation of the system under high operational loads or high demands from the environment. Therefore, tests under high loads on the system, or with extreme user inputs or requests from other systems, as well as tests with extreme temperatures, humidity or mechanical shocks, can be applied.

c A test for interference resistance and robustness, under certain environmental conditions, is a special case of stress testing. This includes EMC and ESD tests (e.g. see [4], [5], [6], [7]).

[4] ISO 11451 (all parts), Road vehicles — Vehicle test methods for electrical disturbances from narrowband radiated electromagnetic energy

[5] ISO 11452 (all parts), Road vehicles — Component test methods for electrical disturbances from narrowband radiated electromagnetic energy

[6] ISO 7637 (all parts), Road vehicles — Electrical disturbances from conduction and coupling

[7] ISO 10605, Road vehicles — Test methods for electrical disturbances from electrostatic discharge

Conclusion

We have seen how to apply the different types of integration tests that are tabulated in the above requirements. Once these requirements are implemented, our item becomes safe. That being said, the item definition complies with functional and technical safety requirements.

We are still in the Product development at the system level

Next, we will integrate the item into the vehicle level and safety validation.

Stay tuned!

Feel free to send me your opinion/findings, we learn from each other.

References

• ISO 26262:2018
• Google Images
• Vector Bus Load