wilamowski-b-m-irwin-j-d-industrial-communication-systems-2011

Functional Safety 21-15
implementing the marching bit test [HOE86]. The level of the diagnostic coverage depends on the faults
revealed by the test. Tests with a high level detect faults according to the DC-fault model, others only
detect stuck-at faults [IEC61508].
Tests of the nonvolatile read-only memory rely on safety measures like parity bits, checksums, or
CRCs, whereas diagnostic coverage of the first is low and the last is high. The data stored is split up in
blocks of equal length and each block is safeguarded with a safety measure. During operation, the CRC
or checksum of the block is recalculated and verified with the stored one. In case of equality, the integrity
of data is guaranteed.
The CPU test consists of the test of the registers used (equal to the test of the volatile memory), the
stack test, the flag test, and the test of the CPU’s arithmetic logic unit (ALU):
• Stack test: Testing the stack pointer without manipulation of the program flow is not possible.
Consequently, the stack test is reduced to the verification of a stack overflow, which is the most
common stack fault. Therefore, a defined bit mask is stored at the upper and lower bound of the
stack. It is checked periodically, if the bit mask remains unchanged. In case of a changed bit mask,
it is obvious that a stack overflow occurred resulting in an undefined and unsafe behavior.
• Flag test: Testing the flags is done by setting and resetting the CPU flags and verification of the
results. In addition, the conditional execution of instructions has to be verified.
• Arithmetic logic unit: The test of the ALU should cover all physical paths within the CPU.
Obviously, the problem is that the entire CPU layout is unknown and, more important, too complex
for a comprehensive analysis. In order to address this problem, the instruction set of the
microcontroller is separated into command classes. Command classes are, e.g., the AND and
the MOV command. For every command class, the input values are chosen so that every bit of the
output performs a “1–0” and a “0–1” transition.
All the safety requirements and safety measures result in additional safety-related firmware. In most
cases, it is logically located above ISO/OSI layer 7 of the standard protocol stack. And another consequence
is that mostly a dual channel hardware architecture (see Table 21.4) is required. In other words,
the standard hardware of a node is extended with a safety controller to allow cross-comparison of data.
Acronyms
1oo2
DC
EUC
FIT
FMEA
FTA
GSN
HAZOP
SIL
One out of two
Direct current
Equipment under control
Failure in time
Failure mode and effect analysis
Fault tree analysis
Goal structuring notation
Hazard and operability study
Safety integrity level
References
[BOE04] J. Börcsök. Electronic Safety Systems. Hüthig Verlag, Heidelberg, Germany, 2004, 107 pp.
[DS00-58] Ministry of Defence. HAZOP studies on systems containing programmable electronics. U.K.
Defence Standard. Def Stan 00-58. Ministry of Defence, Glasgow, U.K., 2000.
[GIE95] K. Gieck and R. Gieck. Technische Formelsammlung. Gieck Verlag, Germering, Germany, 1995.
[GS-ET26] BG-PRÜFZERT, Fachausschuss Elektrotechnik. GS-ET-26—Bussysteme für die Übertragung
sicherheitsrelevanter Nachrichten. Prüfgrundsätze, Köln, Deutschland, Germany, 2002.
© 2011 by Taylor and Francis Group, LLC