Functional safety requirements for application software
Safety Manual for MPC5777M, Rev. 1.1
NXP Semiconductors 47
3.3.15 Periodic Interrupt Timer (PIT)
If a failure in the PIT can cause the violation of a safety goal, some software mechanisms are needed to
guarantee the integrity of the PIT module.
Assumption: [SM_FMEDA_090]PIT operations (for example, the number of periodic triggers) are
checked and compared against the expected values every FTTI. [end]
To implement this test, the number of interrupts generated by the PIT within a given time period shall be
compared with the expected number of interrupts. To avoid CCF, the reference for the time period shall be
independent from the PIT (for example, SWT).
If not covered by other means, software shall read back the PIT configuration and compare it with the
expected configuration (for example, check for enabled channels and compared values, and so on.).
In all cases, when timing/latency of PIT interrupts is important, software shall check that the PIT interrupts
are generated within the expected time.
3.3.16 System Timer Module (STM) usage
Assumption: [SCG18.075]Since a failure in the System Timer Module (STM) can cause a violation of the
safety goal, one of the two assumptions below shall be satisfied. [end]
Assumption: [SCG18.076]At every STM interrupt, the IRQ handler shall compare the elapsed time since
the previous interrupt versus a free running counter to check whether the interrupt time is consistent with
the STM setting, or[end]
Assumption: [SCG18.077]The STM IRQ handler shall be under SWT protection. [end]
A second timer may be used to measure STM interrupts and compare with the STM measured time.
3.3.17 I/O and Peripheral Bridge
Assumption: [SCG18.084]The integrity of safety relevant periphery will be mainly ensured by
application-level measures (for example, connecting one sensor to different I/O modules, sensor validation
by sensor fusion, and so on) which are enabled on the hardware level by a replication of all potentially
safety-relevant I/O with appropriate freedom of interference but no hardware checkers. This replication
starts at the I/O bridges (including them). [end]
Safety relevant peripherals are assumed to be used redundantly in some way. Different approaches can be
used, for example by getting replicated input, (for example, connect one sensor to two DSPIs or even
connect two sensors measuring the same quantity to two ADCs) or by cross-checking some I/O operations
with different operations (for example, using sensor values of different quantities to check for validity).
Recommendation: The usage of different data coding (for example, inversion) is recommended for
redundant communication over safety relevant peripherals (for example, DSPI or LINFlex).
Assumption: [SCG18.952] Different data coding or message transfer timing is used for redundant
communication over DSPI_4 and DSPI_5. [end]
Users can choose the approach that better fits their needs.
To Next Page
Loading...
