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

47-8 Industrial Communication Systems
A part of the first safety-related firmware layer is called network access layer interface. It is an abstraction
layer that makes access to the LON possible regardless of the underlying third-party software.
Functions of the network access layer are declared in such a way that they encapsulate functions of
the third-party API. Since only Safety Chip 1 is connected to the LON, the network access layer is not
implemented on Safety Chip 2. Another part of the first safety-related firmware layer is the safety chip
interface that handles data exchange between both safety chips. It includes a hardware dependent driver
and a software API that interfaces with the safety layer. It offers a function to send data to and receive
data from the corresponding safety chip.
The safety layer is located in the middle of the software design and comprises all software functionality
directly referring to safety. It interfaces with the application layer interface, and the network access
layer interface and safety chip interface. The safety layer is surrounded by two other layers; in other
words, the safety firmware is separated into three layers, to make it absolutely independent from the
third-party software. Second, the third layer is specified to hide safety functionality from the application
programmer. Such a layer eases programming and avoids misuse of safety functions since it must
be assumed that application programmers are not familiar with details of the firmware functionality.
The safety firmware layer 2 consists of multiple parts related to safety, i.e., so-called primary functions:
online self test module, safety-related input/output module, software monitoring, or the SafetyLon
protocol stack. Other parts are supporting the desired functionality called supporting functions like the
Safety Chip interface. Albeit not part of layer 2, the scheduler and state machine, and the safety chip
interface are also supporting functions.
The online self test module includes online tests that are executed to guarantee a high integrity of
the hardware by revealing faults in the different parts of the hardware. Tests are separated into volatile
memory (RAM), nonvolatile read only memory (FLASH), and CPU tests. In [8], implementation
examples are presented. In [9] different test algorithms are outlined.
In general, volatile memory test algorithms differ in test effort and diagnostic coverage. A high test
effort and a high diagnostic coverage is ensured when using the galloping pattern test, a low one when
implementing the marching bit test [10]. The level of the diagnostic coverage depends on the faults
revealed by the test. Test with a high-level detect faults according to the DC-fault model [1] others only
detect stuck-at faults.
Tests of the nonvolatile read only memory rely on parity bits, checksums or CRCs whereas diagnostic
coverage of the first is low and the last is high. In case of a SafetyLon node, the nonvolatile memory is
grouped in blocks of 256 bytes since CRC polynomials do not guarantee a defined level of integrity for
indefinite data length. Every block is used as input to calculate a CRC. The CRCs of the various blocks
are stored in the nonvolatile memory at a predefined area. During run time, the CRC of every block is
recalculated and compared to the stored one. Such an approach is an effective means to check integrity
of data stored in the nonvolatile memory [8].
Safety-related input/output module is responsible for testing the inputs and outputs and to provide
functionality to set/reset an input and to get the value of an output. Testing of the safe I/Os has to be
synchronized between the safety chips. In contrast to the aforementioned online self tests, safe I/O tests
are performed in close cooperation between the safety chips. Hardware schematics are designed in such
a way that inputs signal is received and output signal set by both chips and that test signals can be sent
from one chip and received and evaluated by the other chip (cf. Figures 47.3 and 47.4). As a consequence,
a software function of the module triggers a test pulse on the first safety chip and a software function on
the other safety chip checks if the test pulse has been received.
The objective of software monitoring is to ensure software integrity being part of the systematic integrity,
in contrast to self tests that care for the hardware integrity. It is a means to detect if safety functions located
in the volatile memory were executed according to specification or have been altered due to accidental
modification. Such misbehavior is possible because of software faults during the design or implementation.
Software monitoring can be distinguished between time-based and logic-based monitoring [11]. Both
are integrated into the safety-related firmware. The first type uses a timer with an independent time
© 2011 by Taylor and Francis Group, LLC