S32K1 Safety Questions to meet ASIL B from Safety Manual

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

S32K1 Safety Questions to meet ASIL B from Safety Manual

327 Views
john_floros
NXP Employee
NXP Employee

Hello,

BCS is asking the following questions on the S32K MCU Safety Manual, please comment or respond:

 

Safety Manual Assumption

Question

Recommendations versus Assumptions.

The S32K safety manual contains Assumptions and Recommendations. Our understanding is Assumptions are requirements and Recommendations are implementation suggestions, but not requirements. Is this correct?

[SM_094] It is assumed that the system MPU is checked for correct functionality before it is used in safety applications. One can configure the possible access rights of each present master and check for expected system reaction. The check shall be done once within L-FTTI (at start up).

Is there a Fast WDOG test function in the MCAL 1.0.2 release?

[SM_104] If safety-relevant software is using the eDMA to transfer data to a non-replicated peripheral or within the RAM, the following holds: "always on" channels of the eDMA Channel Mux should not be used. Instead, the eDMA should be triggered by software. If "always on" channels are used, their failure has to be detected by software. In this case, software must ensure that the eDMA transfer was triggered as expected at the correct rate and the correct number of times. This test should detect unexpected, spurious interrupts.

Need clarification. Not sure what the conditions are and if they pertain to our DMA usage. DMA is used on one SPI port for SPI Tx & Rx with the external FLASH.

5.6.9.2 Fast Testing of the Watchdog

Assumption [UN_3]  Before executing application code in safety critical applications, you must test that the watchdog works as expected and resets the MCU.

The  S32K Safety manual microprocessor recommends performing the Fast Watchdog Test prior to using the watchdog. Our application uses the MCU internal watchdog plus an external SBC watchdog running in Windowed mode. Our product is ASIL B. Is the Fast Watchdog Test a requirement? (It wasn’t actually marked that way.) Is the presence of the external watchdog sufficient to meet the safety case for the MCU watchdog? The faults seem covered: 1) Trip too soon: The control resets and does not result in a safety critical failure. 2) Trip too late or not at all: External watchdog trips at its programmed interval and does not result in a safety critical failure.

 

[SM_133] Comparison of redundant operation of I/O modules is the responsibility of the application software, as no hardware mechanism is provided for this.

In our design architecture shown below, we use an S32K1xx ASIL B MCU to communicate with two ASIL B Hall Effect sensors to output via CAN an ASIL B signal. SPI data is protected by CRC and missing SPI communication or incorrect communication corrupting the CRC is safe. Since our design is fail-silent rather than fail-operational, we believe that the SM_133,137 and UN_4 are not applicable for the system. Is this true?

 

 

john_floros_0-1643820129485.jpeg

 

conditions:[SM_137] When safety functions use digital input, system level functional safety mechanisms have to be implemented to achieve required functional safety integrity.

5.7.2.2 Digital Outputs

Assumption [UN_4] Functional safety digital outputs are always assumed to be written either redundantly or with read back. In case of single output with read back, the feedback loop should be as large as possible to cover faults on system level also.

 

Thank you,

John

0 Kudos
1 Reply

308 Views
naveenm
NXP Employee
NXP Employee

 

Hi John,

Please find the replies below:

Safety Manual Assumption Question  
Recommendations versus Assumptions. The S32K safety manual contains Assumptions and Recommendations. Our understanding is Assumptions are requirements and Recommendations are implementation suggestions, but not requirements. Is this correct? Assumptions are mandatory requirements.
Recommendations : It says Recommendations can be standalone or can be associated with an assumption. The safety system developer has the choice whether or not to adhere to the recommendation. Kindly refer to section “1.3 – Safety Manual guidelines” in S32K1xx Series Safety Manual, Rev. 7.1, 12/2021.
[SM_094] It is assumed that the system MPU is checked for correct functionality before it is used in safety applications. One can configure the possible access rights of each present master and check for expected system reaction. The check shall be done once within L-FTTI (at start up). Is there a Fast WDOG test function in the MCAL 1.0.2 release? Yes,
Test ID : tc_fnc_wdog_00201
Test Configuration : tse_bbx_fnc_wdg_00100
Objective :  Switch mode to FAST mode then check timer not expired and time expired

Test ID : tc_fnc_wdog_00201
Test Configuration : wdg_tse_eqapi_001_cfglt
objective : Verify switch mode of Wdg module with "fast" mode.

 Test ID : tc_fnc_wdog_00201
Test Configuration : wdg_tse_eqapi_001_cfgpb
objective : Verify switch mode of Wdg module with "fast" mode.
[SM_104] If safety-relevant software is using the eDMA to transfer data to a non-replicated peripheral or within the RAM, the following holds: "always on" channels of the eDMA Channel Mux should not be used. Instead, the eDMA should be triggered by software. If "always on" channels are used, their failure has to be detected by software. In this case, software must ensure that the eDMA transfer was triggered as expected at the correct rate and the correct number of times. This test should detect unexpected, spurious interrupts. Need clarification. Not sure what the conditions are and if they pertain to our DMA usage. DMA is used on one SPI port for SPI Tx & Rx with the external FLASH. The recommendation is to use another/separate DMA channel for transferring the safety related data along with other checks to prevent corruption of data, unintended data and no/missing data.


5.6.9.2 Fast Testing of the Watchdog The  S32K Safety manual microprocessor recommends performing the Fast Watchdog Test prior to using the watchdog. Our application uses the MCU internal watchdog plus an external SBC watchdog running in Windowed mode. Our product is ASIL B. Is the Fast Watchdog Test a requirement? (It wasn’t actually marked that way.) Is the presence of the external watchdog sufficient to meet the safety case for the MCU watchdog? The faults seem covered: 1) Trip too soon: The control resets and does not result in a safety critical failure. 2) Trip too late or not at all: External watchdog trips at its programmed interval and does not result in a safety critical failure.  
Assumption [UN_3]  Before executing application code in safety critical applications, you must test that the watchdog works as expected and resets the MCU. This is OK, no addition test required over watchdog.
[SM_133] Comparison of redundant operation of I/O modules is the responsibility of the application software, as no hardware mechanism is provided for this.
 

 

In our design architecture shown below, we use an S32K1xx ASIL B MCU to communicate with two ASIL B Hall Effect sensors to output via CAN an ASIL B signal. SPI data is protected by CRC and missing SPI communication or incorrect communication corrupting the CRC is safe. Since our design is fail-silent rather than fail-operational, we believe that the SM_133,137 and UN_4 are not applicable for the system. Is this true?

As long as the Sensor data (via CAN) is CRC protected, and it is ensured that CRC engine (or MCU S/W) evalutes is for correctness, then SM_133, SM_137 and UN_4 can be ignored. The assumption here are considered as fulfilled. We assume that the failure of the sensor is covered by your concept. 

 

conditions:[SM_137] When safety functions use digital input, system level functional safety mechanisms have to be implemented to achieve required functional safety integrity.
5.7.2.2 Digital Outputs
Assumption [UN_4] Functional safety digital outputs are always assumed to be written either redundantly or with read back. In case of single output with read back, the feedback loop should be as large as possible to cover faults on system level also.
0 Kudos