S32K342 Recalculation without some SM

[davidfantl]

We get from NXP web site the FMEDA file: S32K342.CUT_1.0.RELEASE.2022_R2.002_100QFP.xls

In our application we have not activated the following SM:LBIST/MBIST, CMU, INTM, sBoot, eMcem, Scheck. Is it possible for you to recalculate the Metrics spreadsheet without the contribution of the above and send to us the screen shot of it or at the minumum the SPF Combined Fault Metric and LF Combined Fault Metric. We need it to evaluate the reached ASIL.

[OliveroA]

Hi,

Are you able to confirm if your uC without those 3 SM (sCheck, sBoot, MPU) should be recommended for an ASIL B target ? According with your FMEDA the coverage still reach Single 99% and Latent 99% . We need to use this processor only in an ASIL B application so those coverage will be more then enought for us. 

[davidfantl]

Hello,

Attached are the updated metrics.

Thanks,

-Dave

[OliveroA]

Dear Dave,

From the FMEDA file you provided in the column named "SM prevents FM from being latent" (It is column R in excell) all SM are removed and all coverage are 0% without lines from 179 till 14, having coverage of 65% but no SM described). In any case also with no SM capable to detect latent the final Latent coverage inside spreadsheet Metrics is >99% (cell B25 , B26, B27).

May you confirm if inside the file you sent out only sCheck, sBoot and MPU was removed ? 

[Yashwant_Singh]

Hello,

It seems some modules in the FMEDA were hidden because of an active filter on the report worksheet. When regenerating the report without the filter the other latent mechanisms are very well visible. The metric numbers remain the same and are inline nonetheless.

Yes the metrics quoted by David are the ones after removing only the Scheck and Sboot safety mechanisms.

Since you've mentioned your target ASIL as ASIL B we can further recalculate the metric with the split lock configuration of the M7 cores. However since the chip targets an ASIL D metric the rest of the architecture and the coverages provided by a majority of the safety mechanism remain the same even in the split lock or ASIL B configuration. Therefore even in the split lock configuration the metrics fall only slightly. The Latent fault coverages provided by the other latent safety mechanisms also remain the same. This explains why we can see more than sufficient metric targets being met in spite of removing schecks and sboot from the FMEDA.

However please refer my other response in the thread regarding the importance of implementing latent fault checks (scheck and sboot). Quoting it below for reference.

"However please be aware that it’s the system integrator's responsibility to implement latent checks if they choose not to implement our SAF modules (Schecks) irrespective of whether or not the FMEDA meets the metrics with these checks deactivated. FMEDA is only a verification step to ensure we are meeting the metric and not a tool to define the safety concept/architecture. We do not recommend to remove some tests just to achieve coverage numbers because the absence of some tests may result in comprise of the safety of the device/system. Also the system integrator is responsible to justify the changes during assessments/audits.

The FMEDA assumes that SM2 are implemented. Here as well, we recommend to not disable SM2."

Hope this helps!

Thanks!

-Yashwant

[OliveroA]

Please consider the below with a different list of Safety Mechanis not implemented:

We get from NXP web site the FMEDA file: S32K342.CUT_1.0.RELEASE.2022_R2.002_100QFP.xls

Question 1:

In our application we have not activated the following SM: sBoot, Scheck. Is it possible for you to recalculate the Metrics spreadsheed without the contribution of the above and send to us the screen shot of it or at the minimum the Permanent Fault Metric and Combined Fault Metric of SPF and LF. We need it to evaluate the reached ASIL.

Additionally the uC provide a MPU (Memory partition unit) tha we have not activated. May you tell us what ASIL we should reach without using it ? I'm asking as a separate question because into FMEDA the MPU is not visible as a mechanism able to reduce/incrase the coverage.

[Yashwant_Singh]

Hello OliveroA,

Dave will be sharing with you the updated metrics shortly.

However please be aware that it’s the system integrator's responsibility to implement latent checks if they choose not to implement our SAF modules (Schecks) irrespective of whether or not the FMEDA meets the metrics with these checks deactivated. FMEDA is only a verification step to ensure we are meeting the metric and not a tool to define the safety concept/architecture. We do not recommend to remove some tests just to achieve coverage numbers because the absence of some tests may result in comprise of the safety of the device/system. Also the system integrator is responsible to justify the changes during assessments/audits.

The FMEDA assumes that SM2 are implemented. Here as well, we recommend to not disable SM2.

Additionally regarding the point on MPU, we have XRDC in S32K342 which acts as the MPU to provide isolation/partitioning of memories/peripherals based on PID or DID.  XRDC is used as a safety mechanism against dependent failures(quantitative analysis hence no coverage for SM1.XRDC) and is therefore mentioned in the DFA. It is also a functional IP and it has been modeled as such in the FMEDA where it is checked for latent failures only (being a safety mechanism).

Thanks!

-Yashwant