Hi team,
I've got an inquiry from the customer about the safety mechanism/safe measure of AD conversion.
While triggering 9 ADC channels using PDB under back-to-back mode, a delayed trigger from PDB1 should be inserted after PDB0 since each 8 channel of PDB instance is matched ADC0 and ADC1 accordingly.
If the user doesn't put an appropriate delay between PDB0 and PDB1, PDB stops triggering ADC, and it looks the ADC made a failure at a system level.
In order to prevent this phenomena, any safety mechanisms or measures should be provided. But this is not the error directly from ADC, there's no indication or no safety mechanism on ADC.
Also, I tried to find PDB part of the safety manual, but I didn't find any meaningful safety measures or SM.
In case of the ADC is treated as a safety related component, this might be a kind of a cascading failure so that the failure should be handled appropriately.
Do we have any guidance or related safety measures about this failure?
Regards,
Byungmin Hwang
Solved! Go to Solution.
From a safety and ISO26262 perspective, this particular case is a systematic fault (a bug in software). I do not think there is any hardware safety mechanism/measure to prevent this systematic failures. Such failures usually need to be taken care through a strong development process (which appears to be the case here). In the event, such a case arises due to a random HW failure where ADC is just stuck and ADC is used in a safety application, system level measures are required to address the corresponding failure modes as applicable to customer use-case. This is reflected in the Safety Manual - Rev 5 as:
"Section 5.7.4: Analog to Digital Converter (ADC):
Parts of the Successive Approximation Register (SAR) Analog-to-Digital Converter
(ADC) of the S32K1xx and S32K14xW do not provide the functional safety integrity to
achieve high functional safety integrity targets. Therefore, system level measures are
required."
The Safety Manual also describes an example of possible software implementation in eDMA/PDB/ADC subsystem to protect against spurious or missing transfer requests in Section 5.6.7 Enhanced Direct memory Access (eDMA). In short, to address this failure mode application software must monitor that ADC is doing conversions actively.
Hope this helps,
Regards
-Aarul
From a safety and ISO26262 perspective, this particular case is a systematic fault (a bug in software). I do not think there is any hardware safety mechanism/measure to prevent this systematic failures. Such failures usually need to be taken care through a strong development process (which appears to be the case here). In the event, such a case arises due to a random HW failure where ADC is just stuck and ADC is used in a safety application, system level measures are required to address the corresponding failure modes as applicable to customer use-case. This is reflected in the Safety Manual - Rev 5 as:
"Section 5.7.4: Analog to Digital Converter (ADC):
Parts of the Successive Approximation Register (SAR) Analog-to-Digital Converter
(ADC) of the S32K1xx and S32K14xW do not provide the functional safety integrity to
achieve high functional safety integrity targets. Therefore, system level measures are
required."
The Safety Manual also describes an example of possible software implementation in eDMA/PDB/ADC subsystem to protect against spurious or missing transfer requests in Section 5.6.7 Enhanced Direct memory Access (eDMA). In short, to address this failure mode application software must monitor that ADC is doing conversions actively.
Hope this helps,
Regards
-Aarul