Black Channel
Black channel is the mechanism used to encrypt and validate transmitted safety data:
Only Schneider Electric safety equipment can encrypt and decrypt the data sent via the black channel in an M580 safety system.
The health of each safety data transmission is tested by both the transmitting and receiving safety module for each transmitted message.
The effect of using the black channel is to permit the transmission of safety data through non-safe intermediate equipment, such as backplanes, Ethernet cabling, communication adapters, and so forth. Because black channel transmissions are encrypted, the intermediate equipment cannot read or alter the content of the transmitted safety data without being detected.
Black channel transmissions operate independently of the communication protocol used for the transmission:
X Bus is the carrier for backplane transmissions between safety devices on the same rack (e.g. from the CPU to local I/O, or from a communication remote adapter (CRA) to local I/O).
EtherNet/IP is the carrier for data transmissions between racks (e.g. from the CPU to a CRA).
The Safety I/O modules and the CPU can send and receive black channel communications. For each transmission, the transmitting device (CPU or I/O) adds the following information to the message:
a CRC tag to enable testing of the message content.
a time stamp to enable testing of the timeliness of the message.
other information– including the application version and the I/O configuration used – that identifies the I/O module in the transmission.
With CPU firmware 3.10 or earlier, when using safety I/O modules on a remote rack, configure the CPU as either an NTP client or NTP server.
If one of these designs is not implemented, the time settings of the safety I/O modules and CPU will not be synchronized and black channel communication will not operate properly. Inputs and outputs of safety I/O modules in RIO drops will enter the safe (de-energized) or the fallback state.
| CAUTION | |
|---|---|
RISK OF UNINTENDED OPERATION If you are placing safety I/O modules in an RIO drop,
the current time needs to be configured for the PAC with CPU firmware
3.10 or earlier. Enable the NTP service for your M580 system and configure the safety CPU as an NTP server or an
NTP client. Failure to follow these instructions can result in injury or equipment damage. | |
The receiving device (I/O or CPU) decrypts the message and tests the accuracy of its content. The following conditions can be detected:
Condition |
Description |
|---|---|
Transmit errors |
Error detected in the message address or routing. |
Repeats |
Message sent multiple times. |
Deleted data |
Part of the message is missing, or the message is lost. |
Inserted data |
Extra data is added to the message. |
Out of sequence data |
The message order is changed. |
Corrupted data |
One or more bit errors detected in the message. |
Delays |
The message delivery time is excessively long. |
Masquerade |
The source of the message is not permitted to send data. |
When any of these errors are detected, the channel is determined to be unhealthy and the appropriate safety function is executed:
If the CPU detects that a transmission from an input module is unhealthy, the CPU sets input values from that module to the safe (de-energized) or the fallback state).
If an output module detects a transmission from the CPU is unhealthy, it places its outputs into their pre-configured fallback state.
The outputs automatically enter the state commanded by the CPU after communication between the CPU and the output module is correctly re-established.
| NOTICE | |
|---|---|
UNEXPECTED OUTPUT STATE CHANGE UPON RE-ESTABLISHING
COMMUNICATION Program logic must monitor the health status of the output
channels, and activate the safety function accordingly, by setting
the output commands to the safe state. Failure to follow these instructions can result in equipment damage. | |