Functional Safety and Networking

Functional Safety and Networking

After writing my blog on the functional safety requirements for robots, cobots and mobots I thought it would be interesting to tackle functional safety requirements for networking. The two topics are linked as most robots will be networked as robots are an important part of Industrie 4.0.

Mentions of networking within IEC 61508 are few with only IEC 61508-2:2010 clause 7.4.11 offering much guidance where it offers white channel and a black channel approaches and refers the user to IEC 61784-3 or the IEC 62280 series. Using the white channel approach, the entire network including the communication devices at both ends are developed to the relevant functional safety standards. This would be a lot of work and limit the use of standard networking components. The more common approach is the use of the black channel where no assumptions are made about the channel and safety is taken care of with an additional SCL (safety communication layer) in the application software. This SCL is developed to the safety standards but everything else in the communication system is just a standard component. The picture below is taken from the IEC 61784-3 standard.

IEC 61784-3 is a fieldbus standard and the IEC 62280 series (also known as EN 50159) covers trains. EN 50159 gives a series of threats and a list of possible defenses against those threats. For each threat the SCL must implement at least one defense, see below.

For safety of machinery the time-out defense is of particular interest. It effectively implements a watchdog timer so that if for instance a robot receives no communications then after a specified interval it takes the robot to it’s safe state.

Also, table B.2 of EN50159 is of interest. It lists various categories of networks and identifies each of the threats as either negligible, needing some protection or needing strong countermeasures. A Category 1 network might be considered as the closed network within a robot or cobot or perhaps the interface between an analog to digital converter and a local micro-controller. A category 1 network has a known fixed maximum number of users and limited opportunity for unauthorized access. A category 3 network on the other hand might be something like a wireless network which typically has a lot more opportunities for unauthorized access than a wired network.

The white channel approach is not widely used but I wonder will new requirements such as those for TSN (time-sensitive networking) change that. This might be a good topic for a future blog.

I have struggled to find a good video related to functional safety and networking – this one is even more tenuous than normal. For anyone who doesn’t spot the link – leave a comment in the comments section and I will get back to you – see https://www.youtube.com/watch?v=yBBWUZfgRiw

Actually, this week there is a bonus video which discusses how to decide if your CRC is good enough. It shows how to combine the hamming distance of the CRC, the expected bit error rate of the network, the number of bits transferred per second and the required SIL level to determine if your CRC is good enough the meet the PFH requirements from IEC 61508 or indeed ISO 13849 – see http://www.analog.com/en/education/education-library/videos/4592427497001.html

Follow EngineerZone Spotlight to be notified of new safety blogs.

  • Hi Mkorejwo,

            I have played with the SmartMesh starter kit but I must admit my knowledge of their internals is not great. While playing with them I got them to work both with a PC and a Raspberry Pi with almost zero effort. However I have not programmed them or looked at their internal architecture in good detail. 

    Security requirements were definitely taken on board during the SmartMesh development as was the reliability of the connection in industrial environments. These are a good basis on which to build a functional safety solution using a black channel approach.  This would involve implementing safety in the application layer using the defences already outlined in my article. A key requirement would be to demonstrate sufficient independence between the safety rated software and the non-safety rated software. Depending on the target SIL level the requirements would be more or less severe. The easiest way would be to use a separate uC for the safety rated software but this also takes the most PCB space. I was going to say costs more also but that is not true as the safety case would be simplified which might make it cheaper in the long run. A lot depends on your application and your chosen safety concept. 

  • Hello Tom,

    Really enjoying the blog. The "Cat-Herding" video is a bit like selecting applicable standards.

    https://www.youtube.com/watch?v=m_MaJDK3VNE

    A recent blog cleared up my standards type A, B, C confusion with your reference to ISO 12100. Thank you!