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

SafetyLon 47-9
base. Typically, such a timer is called watchdog timer and realized in hardware. So software functions
are monitored by measuring the execution time. After completion of a function the watchdog is reset by
a software command. If the execution takes too long, the watchdog is triggered and predefined actions
are taken. The type of monitoring is integrated to check if the system is blocked or modified in a way, so
that execution takes much longer than expected.
Logic-based monitoring is used to check if functions have not been bypassed. Therefore, a counter
is implemented that is increased every time the function has been executed. Such a counter is available
for every safety function. The counter values are exchanged within fixed periods of time between the
safety chips to detect a fault in the firmware. If the counter values are not equal on both safety chips,
predefined actions are taken.
The SafetyLon protocol stack incorporates functionality to send and receive sensor/actuator data in a
safe way. Additionally, it supports network management activities such as configuring a node and allows
time synchronization [12]. The message structure used for the different tasks is shown in Figure 47.7.
Every safe message starts with a specific header called ID. It specifies the message type (data or command
message) and the data length n. The ID follows a 3 byte address field. It includes the safe source
address of a node. Every safe node holds a table with a list of valid sources. The safe address (of network
variables that is different from a safe node address mentioned in Section 47.3) guarantees that only
safe devices (valid sources) can exchange safety-related messages. The ID and safe address prevent that
unsafe messages look like safe messages.
The next field consists of the upper 2 bytes of the timestamp in the first part of the message and the
lower 2 bytes in the second part of the message. By checking the timestamp at the destination, a delay,
repetition, wrong sequence, and, in conjunction with safe addresses, an insertion of messages is avoided.
In addition, for detecting data corruption during transmission, two CRCs with different generator
polynomials are used. In case of a payload smaller than 8 bytes a 1-byte CRC, otherwise a 2-byte CRC
is appended. The CRCs and the comparison of the duplicated message parts (i.e., ID, safe address, and
data) finally satisfy the requirements for a safe data transmission sufficiently.
In the case of sending a sensor value, each safety chip builds message part 1 and message part 2 and
calculates the CRC. Safety Chip 1 receives the complete message from the other chip and compares
the whole message. If the CRCs and the two message parts are identical, the message is sent, otherwise
discarded. Consequently, faulty messages due to a node internal failure are not sent. That avoids
wastage of bandwidth and saves computational resources on receiver side since it need not process
the faulty message.
On the receiver side, the message is forwarded from Safety Chip 1 to Safety Chip 2 and processed by
both (two-channel structure): first, the CRC is checked in order to verify integrity; second, the timestamp
is used to check for insertion, repetition, and wrong sequence of a message; third, the payload
field is compared bit by bit to detect other integrity failures not being revealed by the CRC. Results on
the checks are exchanged between both safety chips. Only if both agree on a positive result, the payload
is released for further processing for example by the user-application software.
Safety functions must be called and executed on a regular base. For that reason, a scheduler and
a state machine are included in the firmware. To avoid computational overhead and to ease the integration
of safety requirements, no commercial operating system is used. However, a static scheduling
mechanism is realized with a fixed cycle time and a static sequence of functions, i.e., a single-task
scheduling. Such an approach first of all ensures a deterministic timing behavior. It guarantees that test
pulses are sent or the RAM test is executed in fixed time intervals that cannot be ensured for example by
ID
Safe address
Time stamp
MSWord
Safety-related data:
n byte
CRC
a
ID
Safe address
Time stamp
LSWord
Safety-related data:
n byte
CRC
b
FIGURE 47.7
SafetyLon message structure.
© 2011 by Taylor and Francis Group, LLC