Raspberry Pi for Industrial Uses

While a Pi might seem to be an attractive solution, I can't exactly advocate its use in true industrial circumstances for a number of reasons:

• Raspberry Pi is for the most part, a low-cost consumer product. While they could be applied in industrial situations, they're not designed to be as robust as true industrial solutions. When in industry, you might be controlling extremely expensive equipment, controlling something that could involve safety-of-life or you might be dealing with clients with high expectations, so failures are not acceptable. Further to this, the cost of providing support (e.g. a truck-roll to premises to fix the equipment) could very much outweigh any savings that you might get. Additionally, clients may demand systems which are built with reputable parts to alleviate risk regarding lack of support, satisfy their stakeholders that they're making an appropriate choice of equipment and allow service personnel from different companies to work on the equipment to bring it back into operation whenever a failure occurs.
• Consumer products typically do not cover the same level of operating temperature range, nor do they have things like conformal coatings to handle the dusty, greasy and sometimes humid environments encountered. They're also potentially not able to handle high vibration environments, along with potential voltage/current spikes/surges which can occur in automotive/industrial equipment settings. EMI from a heavy current-handling contactor could be sufficient to reboot or cause strange operating behaviour of microcontrollers/SBCs.
• Raspberry Pi SBC itself is very much "naked", so I suppose some of these points can be alleviated through careful treatment of the board with conformal coating, enclosure in an aluminium chassis for heatsinking and shielding, using specially designed HATs etc. But then that's a lot of work, it voids warranty and it's not guaranteed.
• Depending on how you utilise the Raspberry Pi - if you're just running a regular Linux OS, there are a few issues - for example:
  • It's a fully-fledged operating system, it takes a while to start up which can be unacceptable.
  • It also is based on open source code that evolves rapidly - this can break software as it is updated, and there can be security holes that need to be urgently patched at time without any centralized management mechanism.
  • It is a multitasking operating system - so the delay involved when servicing requests can vary depending on CPU load and how the I/O is being performed (e.g. interrupt or polled) which could be unacceptable.
  • The board itself also uses regular consumer RAM without any error correction - in case of memory corruption (which can happen organically due to charged particles, or due to power fluctuations), the board could crash or execute incorrectly - are there any failsafes that stop people from getting hurt or equipment from getting damaged?
  • The board is pretty sensitive to power - how are you going to supply good quality power to the board at all times and ensure that it never improperly shuts down (at the risk of corrupting the SD card requiring intervention)? Even having a UPS is no guarantee as batteries fail and servicing can be missed.
• You might need to develop your own software to network them "safely" - a lot of existing proprietary solutions have evolved over time which have helped their safety, but of course, some process controls stuff is not safe by design (e.g. vulnerable to replay attacks) and is only safe due to air gapping, but you'd always hope to advance the state of the art.
• SD card issues can be common. Early Raspberry Pis had contact issues with full-sized SD cards, whereas the later push-push type sockets with microSD generally work well, at least when not being vibrated. The big issue is the variance in flash memory quality - many consumer SD cards are TLC/QLC flash with very low endurance, meaning that they cannot sustain more than about 100-500 full cycle writes before they fail. Many are also optimised for large block writes rather than small block writes, making for a slightly reduced user experience when it comes to updating the OS for example. Opting for a high-endurance MLC industrial flash card is a better option, but these cards often have to be specially ordered at a higher price.
• Sometimes you can be caught out by unexpected issues - e.g. use a small microSD card with slightly wrong settings and you might find your system logs somehow fill up the storage, making the system completely unworkable. Besides, even things like system logs often will eat at flash write cycles whenever the unit is operational and something happens.
• Long term reliability is an unknown - I've had no major issues with well made boards, but early Raspberry Pi Model B boards had some BGA soldering issues, and some late boards are seemingly having some through-hole soldering issues with some Pi 3 B+'s failing randomly ... but since most of my critical stuff still runs on the original Model B, I've had very good luck with most of my Pis with the 5V supply failing frequently before the board does.

If you're looking to RPi as a money saving option, better think twice. In industry, the downtime could indeed eat up any savings, along with the need to engineer custom interfaces, treat boards specially, run updates, provide failsafes, provide documentation/support, ruggedize the unit and cover your legals.

- Gough

Hi Gough,

Thankyou very much for your response - you have made some really good and valid points! 

I guess that there are a whole host of factors that would need to be taken into account when selecting some hardware for a particular task whether it be consumer based or industrial based.  Following on from the points you have made, some considerations could be:

• Will it be used for monitoring and / or control? - If it is only monitoring, early failure may be acceptable risk, for control maybe not.

• What environment would it operate in? - If it is operating in a semiconductor fab plant the conditions are going to be pretty good, if it is on an oil rig in the North Sea then probably quite the opposite!

• Does it interact with any safety-of-life functions and does it need to meet SIL requirements?  A pi in its standard form certainly does not meet any SIL requirements.

• Where is the board going to be mounted - will it be housed in a control panel, metal enclosure or would it be exposed?  If it can be mounted in a good quality metal enclosure then perhaps some environmental issues could be alleviated.

• What sources of EMI are nearby? As you say there is risk from EMI causing issues - certainly on a 'naked' board and in a factory where there may be noise generated from large drives, contactors, switchgear etc. EMI would be a big issue.

• What software / OS will it run?  - There are a number of options that could be used on a Pi - Rasbian, Ubuntu Mate, Ubuntu Snappy Core, Windows IoT Core, Risc OS.  As is in the case of the netPi board highlighted above, a customised hardened platform could be used based on Yocto and Docker. I guess software selection again depends on a number of factors:

• • What start up time is acceptable? - in some scenarios it may be left running for years.  In the plant I work in, some of our machinery can take days to start up - which is acceptable as it is only taken down for overhaul every few years and start-up times are factored into machine startup planning - it is otherwise left running all the time.
  • What I/O response time is required?  Some machinery will require very quick sub second response times, other equipment may only need a response within a minute or more.
  • What would be the consequences of software failure due to a bug in the code or even RAM errors?  If the device is used purely for monitoring a non critical system then this may not be a problem, but if it could lead to a safety incident or machine damage then operational reliability may be really critical.

• What power supplies are available?  How robust are they?  At the plant I work at, there is lots of process control equipment - PLC's, DCS controllers, bespoke controllers etc. that are sensitive to power supply issues.  For anything that is critical, quite often it will be fed with 2 supplies where one supply might be UPS backed.  As you say though, batteries can and do fail and as you have pointed out improper shut downs can be an issue.

• How would the board be connected to other systems?  Does it need to be networked, or can it accomplish it's function as a standalone device? If used for an IoT application then probably not, but if used to give a discrete output based on some other input such as analysing an image from a camera then it may not need network connectivity.   If it is not connected via ethernet / WiFi then the risk of attack through the network is virtually eliminated.  There is of course always the risk of attack if someone has physical access to the device.

• What type of storage is required?  In the case of the Raspberry Pi Compute module it has an on board 4GB eMMC flash chip which I believe is MLC memory so should offer better reliability and lifetime than a standard pi.

• What is the required life-cycle time?   It may be expected to last for the lifetime of the plant - which could be 20 years or more, or it may only be required for a short term monitoring application to collect some data on a machine to determine a specific problem or optimise a process. This may require something quick, cheap and with high flexibility.

I have based the above points on what you have highlighted, but I am sure that many more factors could be listed here.

You make a really great point that downtime, engineering custom interfaces, covering legals, ruggedizing, running updates, providing failsafes and providing adequate support could soon eat away any savings that would be made in the cost of the device alone.

IMHO I don't believe a device like this should be completely written off for use in industry however - I think it really does depend on the application and considerations above.  Certainly in some circumstances, it would be a definite DO NOT USE - especially if it will effect safety, but others uses in industry may fall into a grey area.  Also with the likes of the netPi, myPi and other industrialised versions, some of the issues with using a standard Pi in an industrial environment are solved.

Thanks again for your response - it has been very thought provoking reading through your response and replying!

Cheers

--------------------------------------------

Tony

Hi Gough,

Thankyou very much for your response - you have made some really good and valid points! 

I guess that there are a whole host of factors that would need to be taken into account when selecting some hardware for a particular task whether it be consumer based or industrial based.  Following on from the points you have made, some considerations could be:

• Will it be used for monitoring and / or control? - If it is only monitoring, early failure may be acceptable risk, for control maybe not.

• What environment would it operate in? - If it is operating in a semiconductor fab plant the conditions are going to be pretty good, if it is on an oil rig in the North Sea then probably quite the opposite!

• Does it interact with any safety-of-life functions and does it need to meet SIL requirements?  A pi in its standard form certainly does not meet any SIL requirements.

• Where is the board going to be mounted - will it be housed in a control panel, metal enclosure or would it be exposed?  If it can be mounted in a good quality metal enclosure then perhaps some environmental issues could be alleviated.

• What sources of EMI are nearby? As you say there is risk from EMI causing issues - certainly on a 'naked' board and in a factory where there may be noise generated from large drives, contactors, switchgear etc. EMI would be a big issue.

• What software / OS will it run?  - There are a number of options that could be used on a Pi - Rasbian, Ubuntu Mate, Ubuntu Snappy Core, Windows IoT Core, Risc OS.  As is in the case of the netPi board highlighted above, a customised hardened platform could be used based on Yocto and Docker. I guess software selection again depends on a number of factors:

• • What start up time is acceptable? - in some scenarios it may be left running for years.  In the plant I work in, some of our machinery can take days to start up - which is acceptable as it is only taken down for overhaul every few years and start-up times are factored into machine startup planning - it is otherwise left running all the time.
  • What I/O response time is required?  Some machinery will require very quick sub second response times, other equipment may only need a response within a minute or more.
  • What would be the consequences of software failure due to a bug in the code or even RAM errors?  If the device is used purely for monitoring a non critical system then this may not be a problem, but if it could lead to a safety incident or machine damage then operational reliability may be really critical.

• What power supplies are available?  How robust are they?  At the plant I work at, there is lots of process control equipment - PLC's, DCS controllers, bespoke controllers etc. that are sensitive to power supply issues.  For anything that is critical, quite often it will be fed with 2 supplies where one supply might be UPS backed.  As you say though, batteries can and do fail and as you have pointed out improper shut downs can be an issue.

• How would the board be connected to other systems?  Does it need to be networked, or can it accomplish it's function as a standalone device? If used for an IoT application then probably not, but if used to give a discrete output based on some other input such as analysing an image from a camera then it may not need network connectivity.   If it is not connected via ethernet / WiFi then the risk of attack through the network is virtually eliminated.  There is of course always the risk of attack if someone has physical access to the device.

• What type of storage is required?  In the case of the Raspberry Pi Compute module it has an on board 4GB eMMC flash chip which I believe is MLC memory so should offer better reliability and lifetime than a standard pi.

• What is the required life-cycle time?   It may be expected to last for the lifetime of the plant - which could be 20 years or more, or it may only be required for a short term monitoring application to collect some data on a machine to determine a specific problem or optimise a process. This may require something quick, cheap and with high flexibility.

I have based the above points on what you have highlighted, but I am sure that many more factors could be listed here.

You make a really great point that downtime, engineering custom interfaces, covering legals, ruggedizing, running updates, providing failsafes and providing adequate support could soon eat away any savings that would be made in the cost of the device alone.

IMHO I don't believe a device like this should be completely written off for use in industry however - I think it really does depend on the application and considerations above.  Certainly in some circumstances, it would be a definite DO NOT USE - especially if it will effect safety, but others uses in industry may fall into a grey area.  Also with the likes of the netPi, myPi and other industrialised versions, some of the issues with using a standard Pi in an industrial environment are solved.

Thanks again for your response - it has been very thought provoking reading through your response and replying!

Cheers

--------------------------------------------

Tony