DocID026216 Rev 1

7/27

AN4475

Functional safety requirements for application software

26

2

Functional safety requirements for application

software

This section gives an overview of suggested measures when using the individual modules

of the SPC563Mxx.

It is possible to ignore aspects of the text if equivalent measures are considered to manage

the same failures. Modules not explicitly covered by this document are assumed not safety

relevant and do not require any software measures.

2.1

Application software requirements

Application software is developed according to safety requirements.

The following sections contain suggested assumptions and requirements for using the

SPC563Mxx devices in a safety application.

2.2

Core

Suggested: [covers: HW_CORE_EXCEPTION] all exception are enabled, if not enabled by

default, and managed. These specific software countermeasures can run once after the

Power-On Reset (POR) before the safety function starts. [end]

Suggested: [covers: SW_CODE_REDUND] this safety mechanism consists of two

redundant diverse software implementations in one hardware channel. Using different

hardware resources (e.g. different RAM, ROM memory ranges) can increase the diagnostic

coverage. For more details see ISO26262-5 D.2.3.4 technique. [end]

Suggested: [covers: SW_PROG_FLOW_MONIT] this safety mechanism checks the

sequence of executed program tasks in order to detect a defective program sequence. A

defective program sequence exists if the individual tasks of a program (e.g. software

modules, functions or statements) are processed in the wrong sequence. For more details

see ISO26262-5 D.2.9.5 technique. These specific software countermeasures can run once

per FTTI. [end]

Suggested: [covers: SW_PROG_TEMPORAL_MONIT] this safety mechanism is intended

to supervise the reliability of program execution in consideration of periodicity and maximum

timing constraints of periodicity. For more details see ISO26262-5 D.2.9.5 technique. These

specific software countermeasures can run once per FTTI. [end]

Suggested: [covers: SW_CORE_SELF_TEST] specific software countermeasures are

implemented to detect Core permanent faults. These specific software countermeasures

can run once after the Power-On Reset (POR) before the safety function starts and/or once

per FTTI depending on the type of faults to be detected. [end]

2.3

System Clock and Frequency-Modulated Phase-Locked

Loop (FMPLL)

External oscillator (XTAL_OSC) and FMPLL output are monitored by the hardware module

called Clock Quality Monitor (CQM).