- Software
- IQANdesign
-
Questions
CAN Open Safety Device Communication
I'm researching CAN open safety sensors and trying to establish how the communication works. I'm under the impression that CAN Open safety is not a totally new protocol but rather a way of transmitting data between devices in a safe way, using standard CAN Open protocol by anti-phasing some of the message contents.
Will the MC4xFS modules support CAN Open Safety communication with the specification of a device that is compliant with SIL 2, pLd as detailed below?
CAN interface (hardware):
According to ISO 11898-1 & ISO 11898-2 (also known as CAN 2.0 A/B)
CANopen application layer and communication profile:
CANopen Safety protocol: EN 50325-5, CANopen protocol: EN 50325-4 (CiA 301 v4.0 & and 4.2.0)
CANopen device profile for inclinometers: CiA 410 version 2.0.0
The common ground between the two is the CAN 2.0A and CAN 2.0B, does this mean i can achieve CAN safety communication?
Has anyone had any experience with these devices or perhaps a template application they could share?
Thanks.
Customer support service by UserEcho
Can anyone advise if this is possible please?
Yes, the basic CAN standard is the same as regular CANopen, there is no difference there. You can implement the communication using the IQAN channels for generic CAN in the same way as you would for other CANopen devices.
But the real question is whether an implementation you can build using the IQAN generic CAN channel will be safe enough for an application requiring IEC 61508 SIL2 ?
The basic concept of CANopen safety is to double up on the CAN frames.
In the IQAN application, you could use GFIN:s to read the contents of the two CAN frames, and add some math to compare the data from the first frame with the bit-wise inverted data of the second frame.
CANopen safety has a timing requirements between the frames with inverted data, the second one has to arrive within the SRVT-time. Depending on the application cycle time, the message refresh time and this SRVT, it could be tricky to check this timing requirement in the IQANdesign application.
In IEC61508, there is a list of possible threats that needs to be managed (repetitions, deletion, insertion, resequencing, corruption, delay and masquerade)
The concept with dual CAN frames in CANopen safety is good for reducing the risk of reading a corrupted message on the bus, but what I struggle to understand is how one could ensure protection against message repetition from a CANopen safety device, it doesn't have any running counters in the messages.
In my opinion, using a protocol that adds a running counter and additional checksum of the message contents in the datafield is a better way of meeting the IEC 61508 requirements on data communication.
Also note that with the current version of IQANdesign (5.03), you will get a project check error if GFIN:s are used in a function group marked as safety related.
For some more in-depth reading on what CANopen safety is good and bad at, this is an interesting paper:
https://www.vtt.fi/inf/pdf/tiedotteet/2004/T2265.pdf
For a feature request on adding CANopen safety support to IQANdesign as a built-in feature, see this forum idea:
https://forum.iqan.se/communities/1/topics/384-canopen-and-canopen-safety-in-iqan-design