S32K142: understanding the FMEDA, SCST execution rate, ADC safety measures and cyclic resets

[Matthias_LEHMANN]

Dear SafeAssure Team,

I've got a few questions around the use of the S32K142 in an ASIL-B application, most of them related to assumptions in the safety manual.

1. [SM_019] It is assumed that the application identifies, and signals, continuous switching between reset and standard operating mode as a failure condition. 
   1. Do you have any suggestion, how a continuous reset condition could be detected? There are various sources of resets, externally triggered by a WDT or a under/overvoltage monitor or internally triggered by SCST tests, as a reaction to ECC errors or wrong content in config registers, etc. For the latter case, it's a conscious SW-decision to go into reset. I'm wondering if it's somehow possible to store the information about the impending reset in something like an error counter. However it would need to be in a memory type that's not affected by the reset? Something similar would also be required to implement a function that sets and transmits a fault message via LIN if the processor resets (too often). But currently we haven’t yet managed to come up with a concept for this function.
2. [SM_130] When Analog-to-Digital Converter (ADC) of the S32K1xx and S32K14xW are used in a safety function, suitable system level functional safety integrity measures must be implemented once per L-FTTI. 
   1. Which measures are considered sufficient here? Reading the safety manual, we would certainly convert the ground reference and the controller-internal bandgap voltage reference. Would these two things already be sufficient to fulfil this assumption? Or is another external voltage reference required that's cyclically converted?
3. We're also going to use the SCST library. To reach ASIL-B targets, is it mandatory to run the SCST in a certain period? The FMEDA for the core seems to assume that the SCST runs once per FTTI? what's the impact of exceeding this cycle time? apparently the static FMEDA doesn't givge
4. And finally I'd like to get a short general introduction to the FMEDAs, e.g. how to read these tables and how to change settings (dynamic FMEDA?). Are there any assumptions that need to be fulfilled in order to use the numbers as stated in the tables, how to combine the numbers to overall failure rates for the overall controller, etc. 
   1. In this context I'd like to get some aid on section 5.7.2 I/O functions in the safety manual. That section suggests to use redundant inputs for safety-critical signals, but also says that sufficient integrity might be achieved also with simplex inputs. My understanding is that using redundant inputs would essentially eliminate any contribution of the Controller’s I/O to the failure rate of the affected function. Where can I find the failure rate in question in the FMEDA? Checking "Peripheral Failure Rates (ISO 26262-5 D.1: Digital I/O, Analog I/O, Communication)", is the entry for "I/O pads logic" (2.053e-11) the relevant failure rate?

1. huh, a lot of questions, I would be grateful to get some feedback. 

Best regards

Matthias

[nxf55526]

Hello Matthias,

Please find the answers to above queries:

1. Each reset source has an associated field in the Reset Control Module (RCM) System Reset Status (RCM_SRS) register. This register includes read-only status flags to indicate the source of the most recent reset. Multiple flags can be set if multiple reset events occur at the same time. The reset value of this register depends on the reset source:

POR (including LVD) — 0x82

LVD (without POR) — 0x02

Other reset — a bit is set if its corresponding reset source caused the reset

Refer to section “26.4.3 System Reset Status Register (RCM_SRS)” of “S32K1xx_RM_Rev13.pdf” for more details.

The status in the RCM_SRS register could be transmitted via LIN to a counter present in ECU that maintains the information about various reset sources. The SW can then take decision to shutdown in case of continuous reset condition.

SRAM retention feature could to be used to monitor some of the reset sources. Refer to section “31.3.4 SRAM retention: power modes and resets” of “S32K1xx_RM_Rev13.pdf” for more details.

2. When the ADC is used as a Safety Mechanism, the calibration function should be used once per L-FTTI. This is done to ensure the correct functionality of the ADC. This calibration should be done once after every reset. Please refer to section ‘44.5.6 Calibration function’ in ‘S32K1xx_RM_Rev13.pdf’ for more details. 

3. According to ISO26262:2018, FTTI is defined as:

"minimum time-span from the occurrence of a fault in an item to a possible occurrence of a hazardous event, if the safety mechanisms are not activated."

Hence, we need to run SCST on the core once per FTTI (as it is the safety mechanism of core) to ensure that a single point fault in core doesn’t lead to a hazard.

4. Please contact your NXP representative to understand the settings of FMEDAs and to have the dynamic FMEDA configured according to your application. The Safety Manual assumption(s) being fulfilled for a safety mechanism is specified under that Safety Mechanism name in the “Select Safety Measures” tab in the Customer FMEDA. The assumption gets fulfilled if that safety measure is enabled. According to the Safety Measures that are enabled in that tab, the failure rates (and the metrics) get computed and the these values are present in the “Module FMEDA” tab.

In section 5.7.2, it says that “Functional safety-relevant peripherals are assumed to be used redundantly in some way.” I am unable to find reference in this section that implies “sufficient integrity might be achieved also with simplex inputs.” The failure rate for this can be found as the entry “Pin example” in the Peripheral FMEDA.

Hope this helps.

Kind Regards,

Avni

[Matthias_LEHMANN]

Thanks a lot Avni for clarifying and explaining these things. I'll pass the answers on to our SW guys for consideration. 

When it comes to point 4.1, I think I interpreted the implementation hint in section 5.7.2.1.1 ("Functional safety digital inputs may need to be acquired redundantly") such that one might also get away when they're not acquired redundantly, i.e. simplex. The "pin example" in the peripheral FMEDA shows a failure rate of 9E-10. Ist that number only valid for redundant acquisition or is it for a single pin, such that for redundant acquisition it becomes 8.1E-19?

[aarul]

Hi Matthias

Yes, if you have system level measures (eg: plausability checks), that enable you to achieve the required safety integrity then you do not need the redundant communication.

The failure rate of pin example for FMEDA is for a single Pin. Please note that this is based on a certain mission profile and package. The number can change for different package/mission profile and that is why it is recommended to contact your NXP representative to understand the settings of FMEDAs and to have the dynamic FMEDA configured according to your application.

Regards

-Aarul