The Black Channel: Moving Network Safety to the Sender and Receiver

An electric parking brake looks like a small function. The driver pulls a switch on the centre console, a module reads it and sends a request, and a motor at each rear caliper clamps or releases. On its way from the switch to the caliper, though, that request crosses two buses and a gateway, and none of them were designed around this one signal.

Engineers new to functional safety tend to put their trust in that path. CAN has a 15-bit CRC, the controllers retransmit on errors, the gateway is a mature product. But a mature product is not a safety argument. There are two ways to build one for data in transit, and the one most projects pick does not lean on the network's own checks at all. It rests on what the sender puts into the data and what the receiver checks when the data arrives.

White channel, black channel

The terms come from IEC 61508-2:2010, Clause 7.4, which describes two ways to argue about safety-related communication. In a white channel, every part of the transmission path is developed to the safety standard and contributes to the claim. In a black channel, the path is treated as untrusted, and the measures that make the communication safe live in the safety-related elements at each end.

ISO 26262 uses neither term and prescribes neither approach. A gateway developed to the data's ASIL, with communication safety requirements allocated to it and verified, is a legitimate answer. Whichever route is taken, ISO 26262-6:2018, Annex D asks you to consider, for each sender and each receiver, what can happen to exchanged information: messages repeated, lost, delayed or corrupted, among others. ISO 26262-5:2018, Annex D adds a pointed remark about checksums. A CRC over the data and the identifier cannot tell you that a message went missing or showed up twice. High diagnostic coverage needs the CRC together with a frame counter and timeout monitoring.

A release request that arrives twice

Back to the parking brake. Assume the hazard analysis gave an unintended release while parked a safety goal at ASIL C, and, to keep the example short, that the actuator acts on the release request alone. The switch module sits on the body CAN. The rear actuator sits on a chassis CAN FD bus. A central gateway, developed as QM and shared by dozens of other signals, routes the request between the two.

Now a fault, invented for this article but ordinary in kind. The driver released the brake when leaving the office car park, drove home, stopped on a steep driveway and pulled the switch. The brake clamps. With the driver still in the seat and the ignition on, a software fault in the gateway re-sends an entry left in one of its routing buffers: the release request from twenty minutes earlier.

Look at what each layer reports. The gateway reads the stale bytes from its own memory, packs them into a chassis CAN FD frame and computes a fresh CRC. The frame wins arbitration, gets acknowledged, and arrives with an intact checksum and an identifier the actuator expects. Every check the buses offer passes, because nothing about the bits is wrong. A receiver that relies on those checks releases the caliper, and the car starts to roll.

That is the case for the black channel in one event. A hop CRC protects bits on one wire segment, from the moment one controller latches the bytes until the next controller reads them. Whatever happens inside a gateway, in its buffers, its copy routines or its re-packing, happens between two hop CRCs, and the outgoing one faithfully certifies whatever the gateway produced.

Moving the checks to the ends

This project takes the black channel route. Give the switch module's application a protection layer that runs before the data reaches its CAN driver. It adds a counter that increments with every frame, a data ID that identifies this signal from this sender, and a CRC computed over the payload and the data ID. In AUTOSAR systems this is the job of the E2E library. The gateway does not interpret those bytes. It copies them. The actuator's application checks them before it acts.

Against the stale frame, the end-to-end CRC passes, because the bytes match what the switch module once sent. The data ID matches, because the frame really did come from the switch module. The counter fails. The last frame the actuator accepted carried 41, and this one carries 07. The actuator rejects it, keeps the brake applied and records the fault. If the switch module went silent instead, a timeout at the receiver would notice, which is something no single frame can show.

What moving the claim buys

The payoff shows up in the development effort. Because the integrity claim rests on the two ends, the transceivers, the wiring and the gateway do not have to carry the ASIL C integrity claim themselves. The protection code in the switch module and the checking code in the actuator do. The gateway is not off the hook: it can still delay the request, drop it or flood the bus, and timing and availability requirements can still land on it. The black channel takes one claim away from the network, not every claim. That trade is why it is the common choice: developing a gateway full of unrelated traffic to ASIL C, for the sake of one signal, rarely pays off.

It also changes where the hard design questions sit. Rejecting a frame is easy. Deciding how many missing requests the actuator tolerates, how fast it must react, and what it does while it waits for valid data again depends on the function, and those answers belong to the receiver.

The In-Vehicle Network Safety concept page goes from here to the communication failure modes of each bus technology, receiver-driven requirements, the AUTOSAR E2E profiles and their configuration traps, the timing budget from fault to reaction, what gateways do to protected data, and a complete worked signal path with its pitfalls checklist.

Abbreviations & Key Definitions

• ASIL - Automotive Safety Integrity Level, A to D.
• CAN, CAN FD - Controller Area Network, and its flexible data rate variant.
• CRC - Cyclic Redundancy Check, a checksum that detects corrupted bits.
• E2E - End-to-end protection, added by the sending application and checked by the receiving application.
• Data ID - An identifier for one signal from one sender, covered by the end-to-end CRC.