Diagnostics

I’m in Tampa for a few days of scuba diving and touring the area. I was able to dive the Crystal River north of Tampa for two days. It’s a really cool place to learn to dive. There’s no current, it’s not very deep and the water’s clear. In addition to all that you sometimes will run into a Manatee or a Dolphin. And if you show up in November the river is loaded with hundreds of Manatee’s. But that attracts a lot of tourists so there’s really no peace and quiet in the water.

In the midst of that I worked in a few customer teleconferences. Diagnostics was a very hot topic on yesterday’s call. Specifically it was about our CAN protocols; DeviceNet, J1939 and CANopen. The architecture of all these protocols is the same. They are simply formatted application layer
protocols that ride inside CAN messages.

Think about TCP. EtherNet/IP Explicit messages ride inside a TCP packet. Profinet IO acyclic messages ride inside a TCP packet. Those protocols are just specific ways to format the bytes inside a TCP message.

It’s almost exactly the same with CAN. DeviceNet, J1939 and
CANopen are ways of formatting the messages that ride inside of a CAN message.
The CAN controller chips which are now usually part of the silicon of the
microprocessor move CAN messages from place to place just like TCP messages are
moved around an Ethernet network. The controllers (Ethernet or CAN) know
nothing at all about what is in those messages, they just know to move them
from point A to point B.

And just like Ethernet, CAN messages have a CRC to verify
the validity of a message. A receiver knows that the message is valid because
the message doesn’t get received by the target node unless it is valid.

In CAN it’s even a little stronger than that. CAN messages
use a recessive bit to identify valid messages. A zero, the recessive bit, in
the ACK bit field indicates that devices on the network have validated the
message and found it to be valid. Any node that doesn’t think it is valid
writes a one, a dominant bit. No other node that thinks the message is valid
can override that dominant bit from the node that disqualified it.  IN a CAN network every valid message has to
be accepted by every node on the network to be valid.

I described this in our discussion yesterday and my customer
still didn’t think that was enough validation. I described how our entire line
of gateway products (Modbus,
Ethernet, Profinet IO gateways) all have diagnostics screens. And these
diagnostic data that can be accessed from any network. They can tell a target
node what nodes are online and what have failed, what nodes are online but
experiencing problems and so on. The RTA Gateways Diagnostics are pretty
powerful.

They decided in the end to do a full loop check in addition
to all the diagnostic data available to both sides in an RTA gateway. With this
full loop check, a device that writes data through our gateway is going to be
able to read that value back to check that it was written. This is largely not
part of our gateway but has to be programmed at the application level by our customers
devices.

To implement full loop diagnostics like this, one side will
write a value. Our gateway will send that value on the other network. The
receiving device will accept that value, validate it as a valid application
layer value and then send it back to the original sender through the RTA
gateway.

In mission critical systems like this, this
truly is the best way to make sure that a message is received by the target.
It’s just like diving. It’s mission critical that you don’t run out of air and
that you make a decompression stop if you dive below a
certain limit. That’s how you stay alive. And that’s how you make sure that
your mission critical applications stay online.