Rasberry PI and clones as industrial SBC's?

[rx8pilot]

I have been engaged in industrial automation for the past 6 months or so and one question comes up all the time.....
Can Pi style SBC's be a practical option for commercial products targeting industrial automation?

There are plenty of DEV Board styles of RPi's that miss the mark on form factor alone, but I have been experimenting with long-term support editions form Friendly Elec with mixed results. The overall compute performance is fantastic relative to the cost, but I have the usual concerns:
A: Running from microSD card makes me nervous
B: Power disruptions cause problems
C: Not 100% compatible with RPi pins

They are, however, a huge bang for the buck. Adding LCD touchscreen is trivial. Cameras, keyboard, mice, code scanners, etc, etc. After some experiments pulling the power mid-process resulted in a dead system that needed a fresh image on the microSD card. About 2 years ago I worked on product with an SBC running Windows. I had to design and integrate a custom internal mini-UPS that alerted the main application to shutdown since the battery was only able to last about a minute. I really don't want to build/support an internal battery system for an industrial product. It would be nice if it simply booted up after a power loss regardless of what was happening when power was pulled.

Are these things going beyond hobby novelty and educational lab platform? Am I dreaming (or crazy) thinking about using them as a centerpiece of a custom industrial process monitoring and control?

[PS: No life safety applications at all. Failures would not be dangerous to people or property - but would cost money for downtime]

[Mr.B]

What a coincidence.
I too am looking at integrating a Pi into an industrial application.
I will be interested in the feedback and advice from this community.

[rx8pilot]

Interesting find a few moments ago.......

https://revolution.kunbus.com/revpi-core/

DIN mounted Rasberry Pi compute module 12-24VDC power input.

[Mr.B]

Interesting.
My challenge has the following requirements:
Compute module (Pi ?)
Accelerometer
RTC
1024x768 (or better) camera with wide angle lens
Buffer 2 or 5 minute video files to SD card
Offload files to FTP server or similar when connected to WiFi
Handle WiFi roaming between multiple access points on the site – same network
48vDC power supply – automotive – battery forklift

[rx8pilot]

Ok - not the most popular thread 

I plan to start with some effort into improving the power system on my NanoPi Fire3. Using a USB phone charger is unlikely to pass the 'industrial use' test. First effort is to add a PCB underneath that will have one my 9-36v commercial DC-DC converters with multiple inputs and LiFePO4 charge controller. They are from a previous product design and have a micro controller providing monitoring services that can be fed into the Pi over UART/I2C/SPI. My preference is to avoid batteries if at all possible, but perhaps supercaps could be used to get me the 3-5 seconds needed to accomplish a safe shutdown. Say 10 watts for 3-5 seconds with an alert signal to Linux for an immediate safe shutdown.

The next consideration is a watchdog concept that has a backup image of the system. The idea here would be to have a microcontroller doing some basic watchdog effort - in the event the system is failing on boot - it would shutdown the Pi, copy a backup image to the primary flash (SD Card or eMMC) and try to boot again. I could even store user parameters / settings on uC managed flash. Hopefully this would reliably recover from a system failure due to corruption.

None of this sounds too crazy - unless there are some Linux trickery to make the system tolerate unexpected power loss better than it has been doing for my tests.

[Mr.B]

I am going to use a LiPo battery and appropriate management system to hold mine up after power loss.
I need to keep recording video for at least 2 minutes after the forklift power disappears.
Then a graceful shutdown.

[Someone]

None of this sounds too crazy - unless there are some Linux trickery to make the system tolerate unexpected power loss better than it has been doing for my tests.

Trickery depends on what you see as linux, some people have no problem building their own root file system from scratch and assembling a system on top of that. Its possible to make robust linux platforms but they will have trade offs. One project I found in the hunt for a sturdy embedded platform was Nard:
http://www.arbetsmyra.dyndns.org/nard/index.html
Read only filesystem is a basic precaution for sudden loss of power, but it grows from there.

[nctnico]

I have been engaged in industrial automation for the past 6 months or so and one question comes up all the time.....
Can Pi style SBC's be a practical option for commercial products targeting industrial automation?

No. Not by a long shot. For industrial applications you'll need industrial temperature grade components. And gobbling something together from seperate boards is asking for EMC problems. Even if the boards are connected using board-to-board connectors thing can get iffy especially if there are connectors on both boards. A better way is to get industrial SOMs (system on modules) which are designed to be incorporated into a product. However having everything integrated in a full custom design (typically viable for >100 units) is the best way forward.

And yes, you can make Linux be resillient against power loss. Make the root filesystem read-only and only enable it for writing momentarily when you need to write data (on a seperate partition). Make sure to sync the filesystem before going back to read-only mode. There is a Howto for Debian on how to run it from a read-only root filesystem.

[george.b]

For industrial applications, I wouldn't touch a Raspberry Pi with a 10-foot pole. Just look at the recent HDMI/WiFi SNAFU - doesn't give you much confidence in its reliability/ruggedness/EMI compliance/etc.
Not to mention availability issues - seems difficult enough to get hold of one at times, let alone a bunch of them for some industrial product.
That's not what it was meant for.

[rx8pilot]

No. Not by a long shot.

Fair enough for sure. The time-to-market element is the crushing element. For some of the modules that I looked at, I am sure they are better in many respects but they still have many of the same limitations - Linux, connectors, power requirements. I would also be beholden to the manufacturer for support. I am not arguing against a 'proper' solution, I just saw so many of the same challenges, a higher price, and the possible learning curve of a an unknown architecture.

For industrial applications, I wouldn't touch a Raspberry Pi with a 10-foot pole.

There are a few companies making Pi-ish modules that are targeted at embedded applications. Are they any better? I don't know, but at least they are LTS and physically more appropriate for embedding.

The $30-40 price point makes them interesting for applications where a ton of modules would be deployed for somewhat simple tasks.

[Ed.Kloonk]

For industrial applications, I wouldn't touch a Raspberry Pi with a 10-foot pole. Just look at the recent HDMI/WiFi SNAFU - doesn't give you much confidence in its reliability/ruggedness/EMI compliance/etc.
Not to mention availability issues - seems difficult enough to get hold of one at times, let alone a bunch of them for some industrial product.
That's not what it was meant for.

Yeah.

If you must use a Pi, keep it sealed up because of dust bunnies. Harden any I/O. Keep a snapshot of the OS handy and possibly a entire drop-in replacement if you have to warrant this thing. Heat is a concern if a long life-span is your goal. Document all configuration and setups if you even think are going to have to deal with problems later.

Ask Jonathan Oxer (super house tv) about the full time job it is to maintain these things.

Whilst they have their use for hobbyist and even enthusiastic hobbyist, remember they are designed and built with cost in mind not industrial reliability.

Weather you put the OS on a SD card or USB stick, buy a good quality one. Make it reboot daily.

[george.b]

There are a few companies making Pi-ish modules that are targeted at embedded applications. Are they any better? I don't know, but at least they are LTS and physically more appropriate for embedding.

The $30-40 price point makes them interesting for applications where a ton of modules would be deployed for somewhat simple tasks.

Hmm, I don't know, it depends on how reliable they are and/or how reliable you need them to be, on how hostile an environment they'll be used in. For factory floor operation you'd want something with industrial temperature grade components, as nctnico pointed out, robust I/O and decent thermals, as Ed.Kloonk said, and in an enclosure providing reasonable protection from the environment (mechanical and electrical). Of course, a similarly rugged power supply would also be important.

So I was looking around and found this, which seems to be decent for industrial applications (I wouldn't know first hand, just found the thing), although the temperature rating doesn't seem stellar: https://www.netiot.com/netpi/industrial-raspberry-pi-3/
Still, personally, I'd prefer something with the least fluff possible, just the bare minimum features for the application I'd have in mind. Fewer things to go wrong that way. HDMI, for instance, is something I imagine you could do without in an industry setting. I can understand them trying to cover as many usage cases as possible with their product, though.

[nctnico]

No. Not by a long shot.

Fair enough for sure. The time-to-market element is the crushing element. For some of the modules that I looked at, I am sure they are better in many respects but they still have many of the same limitations - Linux, connectors, power requirements. I would also be beholden to the manufacturer for support. I am not arguing against a 'proper' solution, I just saw so many of the same challenges, a higher price, and the possible learning curve of a an unknown architecture.

This year one of the projects I created is a SoC core design I can use as a base for other SoC designs. But this isn't at the $40 price point. The SoC alone is about that price. But it is an industrial grade device with 10 years of availability from the manufacturer. It was a major investment in time and money (new PCB package and learning to use it too) but in the end I think it will serve my customers well. I have been down the SOM route before but 4 years down the road the specific module is obsolete and subject to MOQ because the manufacturer decided to make a major design change which isn't compatible with the existing software.

[rx8pilot]

Hmm, I don't know, it depends on how reliable they are and/or how reliable you need them to be, on how hostile an environment they'll be used in. For factory floor operation you'd want something with industrial temperature grade components, as nctnico pointed out, robust I/O and decent thermals, as Ed.Kloonk said, and in an enclosure providing reasonable protection from the environment (mechanical and electrical). Of course, a similarly rugged power supply would also be important.

So I was looking around and found this, which seems to be decent for industrial applications (I wouldn't know first hand, just found the thing), although the temperature rating doesn't seem stellar: https://www.netiot.com/netpi/industrial-raspberry-pi-3/

I don't think that temperature will be restrictions will be a major factor in most of my potential use cases. Physically rugged? Yes. EMI shielding? Yes. Robust I/O? Definitely. On and on.....
The NetIOT company [and a few others] appear to have need to add an enormous amount of effort to get a generic PI to satisfy typical industrial requirements. By the time they are done, they price is back to what I would expect of a dedicated industrial solution - at least for the hardware.

This year one of the projects I created is a SoC core design I can use as a base for other SoC designs. But this isn't at the $40 price point. The SoC alone is about that price. But it is an industrial grade device with 10 years of availability from the manufacturer. It was a major investment in time and money (new PCB package and learning to use it too) but in the end I think it will serve my customers well. I have been down the SOM route before but 4 years down the road the specific module is obsolete and subject to MOQ because the manufacturer decided to make a major design change which isn't compatible with the existing software.

I would love to create my own long term support architecture - but even though I have the skills and infrastructure to do so.....time is not on my side. Perhaps I should at least consider using an off-the shelf solution as a development and launch platform that will be replaced by our own design as we gather a head of steam.

On the other hand.....taking something like a FriendlyElec NanoPi Fire3
https://www.friendlyarm.com/index.php?route=product/product&path=69&product_id=206
They claim LTS, but who knows what that really means. If I designed my own [low-cost and flexible] power management and IO PCB - that could overcome many of the most severe limitations including the issue of the Pi layout changing. Updating an IO interface PCB is trivial and I can control any amount of protection and shielding the application may require. I still need to consider, design, build a solution for dealing with any image corruption automatically but I would have to deal with that element no matter what hardware is chosen.

Also......not excited about microSD cards being the primary storage although that seems to be fairly straightforward to overcome with eMMC options that are already developed.

[james_s]

The SD card is what would make me nervous. I would look at one of the similar SBCs that has onboard SATA and use a real SSD. Other than that I think it could be reasonable, I mean I have RPis that have been in 24/7 service for years without any real issues, 99% of the problems people have seem to come down to inadequate power supplies. They are afterall little more than a breakout board for the SOC.

[nctnico]

A good quality SD card and good quality socket go a long way. Not sure whether eMMC is any better. The downside is that an eMMC can't be replaced very easely. An SSD or SATA is not better or worse when it comes to reliability. It is still flash.

[rstofer]

It seems to me that the latency around Linux would kill off the opportunity for industrial applications.  It could send commands for peripheral processors to handle, it could certainly handle networking and files but 'real time' it isn't.  PLCs are designed for industrial applications, toy computers are not.

Power interruptions?  Well, a $75 UPS system will take care of that.  Maybe it adds too much to the cost or bulk but I have a couple of PiDP-11s that lose the file system on power failure so they are running on a UPS.  Basically, these are Raspberry Pi boards running a PDP-11 simulator.  Great fun - until you lose the file system.

If you said "Hey, I'm going to blow off Linux and use FreeRTOS as the underlying OS", that might be workable.  Except you will never get the documentation for the Pi processor.  That's pretty much constrained by an NDA to a select few developers.

There are a lot of industrial rated x86 and ARM boards that offer all kinds of features and are much more suited to an industrial environment.

https://www.onlogic.com/

[nctnico]

It seems to me that the latency around Linux would kill off the opportunity for industrial applications.  It could send commands for peripheral processors to handle, it could certainly handle networking and files but 'real time' it isn't. 

Not quite. Many modern SoCs (like the one I have used in my design) have a microcontroller on-chip which can run realtime tasks. Also modern SoCs support secure virtualisation which allows to seperate a HMI from a safety critical control process. You could make a single chip car ECU with it which can run the engine iginition system, instrument cluster and entertainment / navigation. Still Linux by itself has enough realtime abilities; certainly at the kernel level. Not every realtime process need microsecond response / resolution.

[rstofer]

A good quality SD card and good quality socket go a long way. Not sure whether eMMC is any better. The downside is that an eMMC can't be replaced very easely. An SSD or SATA is not better or worse when it comes to reliability. It is still flash.

How about a cron job that periodically copies important stuff to a NAS box?  Maybe even invoke the job at shutdown - automagically.  It won't help for sudden power failures but a UPS will.

I can't imagine a large scale industrial installation that wouldn't have a NAS server.  In fact, I would probably try to get all the clients to boot from images on the server.  BOOTP or similar.

[nctnico]

A good quality SD card and good quality socket go a long way. Not sure whether eMMC is any better. The downside is that an eMMC can't be replaced very easely. An SSD or SATA is not better or worse when it comes to reliability. It is still flash.

How about a cron job that periodically copies important stuff to a NAS box?  Maybe even invoke the job at shutdown - automagically.  It won't help for sudden power failures but a UPS will.

A UPS is a no-go for industrial electronics. Just like test equipment it needs to be able to handle sudden power loss. The gigantic amount of (test) equipment which runs on Linux nowadays shows that power loss doesn't have to be a problem at all. Just configure the system to be able to deal with it.

[rstofer]

It seems to me that the latency around Linux would kill off the opportunity for industrial applications.  It could send commands for peripheral processors to handle, it could certainly handle networking and files but 'real time' it isn't. 

Not quite. Many modern SoCs (like the one I have used in my design) have a microcontroller on-chip which can run realtime tasks. Also modern SoCs support secure virtualisation which allows to seperate a HMI from a safety critical control process. You could make a single chip car ECU with it which can run the engine iginition system, instrument cluster and entertainment / navigation.

Absolutely!  Use a peripheral processor for real-time requirements and let Linux handle the bigger picture.  My CNC Mill uses an Ethernet based control board for all the stepping and the PC just sends move commands.  I don't know why I picked Ethernet instead of USB but it's been working for 4 or 5 years.

https://warp9td.com/index.php/products

[rx8pilot]

It seems to me that the latency around Linux would kill off the opportunity for industrial applications.  It could send commands for peripheral processors to handle, it could certainly handle networking and files but 'real time' it isn't.  PLCs are designed for industrial applications, toy computers are not.

In my case, I am only hoping to use the Pi/SoC/Linux system for non-real-time tasks like gathering data from real-time systems and prompting users. The real-time controls are separate MCU based custom designs. The major task for the Pi system is to collect, parse, and send data to and from a server. All of that is rather slow and none of it is particularly critical. If the Pi dies, the process continues albeit the server will be sending a notification to someone that a node has disappeared. It is fairly trivial to add a watchdog for a reset but that will not help if the SD card has been corrupted beyond it's ability to boot the system.

I will say this....so far in my tests: power has been the biggest problem and the easiest to solve. Most Pi enthusiasts use phone chargers with long micro-USB cables to power the unit. I have been powering from one of my own DC-DC converters solder hardwired right at the Pi. It does nothing for abrupt power failure, but it does keep a very clean 5v. My test power board does have a LiFePO4 input with charger that can act as a backup - but I don't want to have any batteries if there is any way to avoid it. I would consider super-caps if I was unable to figure out how to tolerate an abrupt power loss. Batteries are a too big of a liability and a service concern down the road.

I like the idea that @nctnico brought up to use a read-only configuration of Linux (as much as possible). That is outside of my personal set of skills, but my brain is not full yet. Another option I considered is an external SD Cartd control sub-system that can pull a read-only image on a separate card or a separate partition in the event of a boot failure. That arrangement would would be triggered by the watchdog system declaring a failed boot. At that point, it would automatically prepare a new image for the system and boot itself up. User config data could be managed in a similar way and would also be saved and available from the server side if needed. As long as it could automatically recover from a failed boot, contact a server for configuration data - it should work ok. 

I will spend some time looking at how other Linux based systems deal with sudden power loss. If I can solve the bulk of that problem in software - it would be really nice.

[nctnico]

Some Linux based devices create a ram-disk at boot, copy a firmware image into it and run the software from there. This means that the system gets a fresh install at every boot so having a read-only root filesystem isn't needed.

[Fred27]

A BeagleBone addresses some of the issues with a Pi - namely the SD card storage and real time capabilities. There is also an industrial version. Any opinions on how much better that is as an option?

[TK]

Odroid boards use socketed eMMC that you need to buy separately but they are replaceable, and I estimate more reliable and faster than microSD card.