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.

[SiliconWizard]

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.

Yes, but they are plugged in with "flimsy" connectors with absolutely no locking mechanism. I wouldn't trust it for an industrial use in any kind of harsh environment.
I'd definitely favor the boards that embed soldered eMMC flash (and of course use "read-only" Linux distributions.)

That said, you still have absolutely 0 guarantee with those "hobbyist" SBCs. They are not designed to be reliable. The other factor is software. One of the points of using those is having a Linux OS. Problem is, practically none have Linux distributions that are dependable enough to be used in an industrial setting IMO. Are you skilled/willing or have the time to be rolling your own?

As always, don't be fooled by the low cost. The real cost for any serious use is another story entirely.

[rx8pilot]

As always, don't be fooled by the low cost. The real cost for any serious use is another story entirely.

You are correct on this one. The hidden costs of applying endless band-aids on the low cost hardware will ultimately make me wish I just designed and built a a system from the ground up to be in an industrial application.

The efforts I have seen so far to put RPi systems into a hardened shell are interesting, but sadly end up being the similar cost as many industrial options. The big question I need to answer on my own is this: How robust does the solution need to be in order to be effective at achieving the stated goals. Technically, I could design and build to aerospace standards with multiple levels of redundancy and tolerance to the harshest of environments....but does that help solve the problem or simply add enormous cost? Is it reasonable to simply have enough redundancy by way of super low cost hardware that faults can be managed?

My basic intent is/was to leverage the ultr-low-cost RPi clones in a fairly large non-real-time, non-safety-critical application of gathering and displaying data related to process control. In that concept, serious reliability can be sacrificed to some extent in favor of having ready to deploy backups that can be dropped in for very little money. The larger scheme can tolerate numerous dead nodes and still be effective. I would think that with some basic precautions in power, IO, and software - the reliability could be at a level where having a few plug-in spares that are used periodically could be enough to actually benefit from the lower costs.

From the customer point of view: This is the $100,000 solution vs the $10,000 solution where the $10,000 solution is advertised and expected to require more hand-holding than the big-boy option but still deliver 95% of the $100k system.

[rx8pilot]

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.

I love this. 

Boot time is not really an issue, so the time needed to create a ram disk is not a problem. This concept would eliminate any need for battery backup or super caps.

[westfw]

I dunno.  Sort of standard "industrial SBC" is like PC104, right?  Not a lot different from RPi boards in some vague hand-wavy way.  You can even get linux SBCs and such in PC104 format.

Except for "support."  Most PC104 vendors exist to support the industrial SBC market, while RPi aims at the hobbyist and educational markets.  That's likely (unfortunately) to end up being a significant problem at some point.  Just the "churn rate" is awful; how'd you like to have a really successful product based on an RPi2 board?  (we used to have heavy debates on replacing custom hardware with "commodity PC stuff" like some of our competitors.)  Industrial product end-customers tend not to be happy with with churn either, and there are all those certification issues and such...

[frogg]

My only real issue with using raspberry Pi's in an industrial application is that the NVRAM on which the OS resides is not particularly robust, nor is it particularly deterministic in terms of performance. That could probably be fixed to some level by hacker types, but depending on the hard real-time  or high availability needs, the amount of effort may quickly eclipse the convenience/cost of the cheap SBC.

Many real-time systems are not designed to have backup power systems, even though many of them end up having them attached.  Rather, they are designed to start up 100% reliably to a known, operable state no matter how badly power has been cycled to the unit.

Like others have said, hard real-time capability is hindered by the OS, but for very hard real-time systems, the CPU may have to provide some guaranteed parameters in how deep the execution pipelines are, the type of speculation, the cache/memory arrangement, and how preemption occurs with interrupts. This is why research is done on "Worst Case Execution Time" as a sort-of-standard metric on real-time hardness.

So I guess in summary - it all depends on how real-time or robust you want it to be. Keeping in mind, of course, that some industrial SBCs have very soft real-time requirements and some are not particularly robust at all.

[rx8pilot]

Like others have said, hard real-time capability is hindered by the OS, but for very hard real-time systems, the CPU may have to provide some guaranteed parameters in how deep the execution pipelines are, the type of speculation, the cache/memory arrangement, and how preemption occurs with interrupts. This is why research is done on "Worst Case Execution Time" as a sort-of-standard metric on real-time hardness.

I definitely do not see a Pi type device as real-time or mission critical. For the real-time tasks, I am expecting to design and manufacture custom MCU based interfaces that run in a stand-alone configuration. The MCU modules will be able to tolerate all sorts of poor treatment and still deliver excellent availability. Those modules would be sending status updates to the Pi on request. The expectation is that the MCU based devices have enough on-board memory to easily deal with any of the typical latencies in the Pi and will continue to operate normally if the Pi burns to the ground.

Essentially, the task of the Pi would be to handle periodic operational updates to the various connected devices and gather data as needed and report that to a server. This arrangement ensures the Pi's are not going to stop production. With that said, if they are fiddly and need regular attention - the crew on the factory floor will likely start a mutiny.

[Zucca]

In my experience a Raspi work fine for about 5 days 24/7 top, then I had always to fight some sporadic issues  .
Not to blame the raspi platform, but me: in my eyes you need to get deep into linux to debug or understand what is going on or to prevent crashes.

Surely a learning experience as you pointed out in another thread, but you need to plan (maybe?) 1 year in advance to get the desired industrial production stability.

[PlainName]

I have a RPi2 at a remote site that I forget about until I need it for some reason (VPN down, so remote access to internal infrastructure via SSH, perhaps). Always there regardless of anything else happening except for two circumstances: 1. mains powercut, and 2. broadband down.

Before installing I put in a software watchdog. Don't know if that's ever tripped, and it wouldn't handle the worst case scenarios, but all I can say is the RPi2 has never let me down. (A quick check indicates it's been there for four years, completely unloved and unmaintained.)

[Zucca]

Interesting to know if I am an unlukcy user or you are a lucky user.
I hope it is me to have bad luck.

[PlainName]

So do I 

[SiliconWizard]

Apart from the mass storage potential issue (SD cards are not all that great, bad things can happen at power loss, etc.), there's one definite thing to consider when using those small SBCs: heat management.

Many of them, RPi included, are sold without any kind of heatsink. And if you think it doesn't need any, think again very hard. Unless you're running some code that is very light on CPU (idles most of the time) AND GPU, the processor (and RAM) gets very hot. You can't let it run for any extended period of time like this. So add a proper heatsink. That will certainly help reliable functioning a lot.

[rx8pilot]

. So add a proper heatsink. That will certainly help reliable functioning a lot.

For sure....before the first boot, I designed and machined my own heat sink for my test Pi.
It has a fan option, but I don't think it is needed unless the ambient temp is unusually high. I did some days long stress tests with CPU/GPU/RAM all running at max, and the temp stayed very comfortable in roughly 90F/ 32C ambient. Not too bad. The RAM did not have a direct connection to this heatsink, but they did not get all that warm either (to my surprise).

A future rev would make thermal contact with the RAM chips.

[Zucca]

For sure....before the first boot, I designed and machined my own heat sink for my test Pi.

You should sell them.

[Zucca]

Did anyone spot the Compute module?

https://uk.farnell.com/raspberry-pi/rpi-compute-module/compute-module-raspberry-pi-dev/dp/2427122?gclid=Cj0KCQiAvJXxBRCeARIsAMSkAprZTE20cRp9w0tYqE-BDVx7agjYIzoF6jtV50PMtYzleN5F6b-XSKEaAorVEALw_wcB&mckv=sYzmG8S34_dc|pcrid|377992558200|kword|rpi%20compute%20module|match|p|plid||slid||product||pgrid|13887941408|ptaid|kwd-90106367354|&CMP=KNC-GUK-GEN-SKU-MDC

https://www.raspberrypi.org/blog/raspberry-pi-compute-module-new-product/

Interesting, please read also the comments:



 

[nctnico]

. So add a proper heatsink. That will certainly help reliable functioning a lot.

For sure....before the first boot, I designed and machined my own heat sink for my test Pi.
It has a fan option, but I don't think it is needed unless the ambient temp is unusually high. I did some days long stress tests with CPU/GPU/RAM all running at max, and the temp stayed very comfortable in roughly 90F/ 32C ambient. Not too bad. The RAM did not have a direct connection to this heatsink, but they did not get all that warm either (to my surprise).

Typically memory is not much of a problem where it comes to heat. On the board I designed I use a standard quarter brick DC-DC converter heatsink which is screwed to the board:


There is a bit of soft thermal interface material between the heatsink and the SoC chip. Ofcourse in my case I could design the PCB to match the heatsink.

[Zucca]

Interesting, maybe a SSD will improve reliability?

[rx8pilot]

Interesting, maybe a SSD will improve reliability?

I would think this configuration would be considerably more reliable. Being faster is a good by-product as well.

From an error situation where the OS has been corrupted, I wonder how difficult it would be to have another partition boot if the primary fails. The alternate partition could rebuild the primary partition from an image and then reboot from the primary. Not sure how to accomplish that in Linux, but surely it is possible, right?

[nctnico]

I have implemented a dual-boot system in the past. If you boot from a (Q)SPI flash rom for example you can have a bootloader (like u-boot) figure out which device (for example SD or Sata) is bootable. Another option is to have the bootloader in the SoC sort it out or both. In a current project the SoC can boot from both eMMC and SD (it will try to read a bootloader in that order) so if the eMMC fails an SD card can serve as a backup. From there the bootloader can figure out which device should be booted from.

In the system I implemented things got complicated because both software updates and data had to be kept synchronised on both devices.

[rx8pilot]

In the system I implemented things got complicated because both software updates and data had to be kept synchronised on both devices.

I suspect that is a common scenario. Although the data updates would have an element of risk - the core OS data would be safe. Perhaps you lose some percentage of the last incoming data, but that seems like a workable risk for many applications.

[nctnico]

Well, in that particular case the data was part of the product (electronic art). But if you are dealing with live incoming data then there isn't much you can do to prevent data being out of sync on two storage devices.

[Zucca]

From an error situation where the OS has been corrupted

It is still obscure to me how the first corrupted OS will then automatically reboot to the second good OS partition.
Maybe it's a kernel panic and it reboots anyway.

[PlainName]

Your OS sets a boot-protected flag once it's running properly. The bootloader checks the flag on boot and if it's not set then the OS is borked and you use the other one. An alternative, if your CPU has it, is to check for the reason of a boot - if it's a power or user event then it's probably OK, but a watchdog timeout is suspicious. You can use a time-from-boot to figure out if it's a one-off thing the OS should handle or the OS itself having issues.

[Zucca]

The bootloader checks

So you can mod the bootloader to do that? Wow, I need to move to Linux soon, it's becoming too attractive...

[PlainName]

It depends on your particular bootloader. We are talking embedded systems, don't forget, and not your average PC. Something has to start the OS load from whatever storage it is on, and that something is usually your bootloader. It will be specific to your system, not the OS.

[SiliconWizard]

The bootloader checks

So you can mod the bootloader to do that? Wow, I need to move to Linux soon, it's becoming too attractive...

The bootloader of what? What platform are we talking about here in the end?

On conventional PC motherboards, the "BIOS" is what you could call this (at least it's one of its tasks). You could take a look at the OpenBIOS and Coreboot projects for instance. They of course don't support everything, and it's not for the faint of heart.

For SBCs, things are not necessarily much easier. The "bootloader" of the RPis, for instance, actually runs on the Video chip, and it's closed source, they only provide binaries. I'm not aware of any existing and fully working open-source replacement, if you find one, please share.

[nctnico]

It depends on your particular bootloader. We are talking embedded systems, don't forget, and not your average PC. Something has to start the OS load from whatever storage it is on, and that something is usually your bootloader. It will be specific to your system, not the OS.

Well... even an OS on a PC is booted through a bootloader (like Grub for Linux) and you can modify the open source ones. On a PC it is not the BIOS which loads the OS; the BIOS loads an OS loader. On an embedded system it works in a similar way where a low-lever ROM routine probes/accesses various storage devices to look for a bootloader which then gets started.

[rx8pilot]

It depends on your particular bootloader. We are talking embedded systems, don't forget, and not your average PC. Something has to start the OS load from whatever storage it is on, and that something is usually your bootloader. It will be specific to your system, not the OS.

Well... even an OS on a PC is booted through a bootloader (like Grub for Linux) and you can modify the open source ones. On a PC it is not the BIOS which loads the OS; the BIOS loads an OS loader. On an embedded system it works in a similar way where a low-lever ROM routine probes/accesses various storage devices to look for a bootloader which then gets started.

It seems like it would be easier to have an external MCU that is connected to the console serial port of the RPi hardware to monitor system status. If it fails to boot - the MCU could manage a recovery routine. Perhaps shutting down the RPi, cloning a read-only image to the system storage and rebooting the RPi. At least the designer would have total control over the process.

[daveyk]

The single board computers, other than an ETX form factor, I am thinking of, are a full-length or 3/4 length card, and plug in to a backplane in order to access the PCI/ISA buses and cards plugged in to those busses.  Typically, they must be capable of running Windows XP 32 bit SP3, or Windows 7 Pro 32 Bit.  Few SBC systems in industry, assuming not connected to the network, run Windows 10.  In fact, there are still a lot of SBCs out there still running Windows 98SE, or older.   So, no, I do not see how a Rasberry pi could replace the typical SBC in the majority of industrials environments.

If you are thinking of a Pi replacing a PLC, you might be able to do that, but acceptance might be an issue.  PLCs are good for maintenance as most electrical maintenance guys can hook their laptop up to the PLC and trouble-shoot the input signals and the output signals of the PLC via ladder logic.  I doubt there are many out there in a factory that could handle trouble-shooting in Python, let alone make minor code changes.

[nctnico]

It depends on your particular bootloader. We are talking embedded systems, don't forget, and not your average PC. Something has to start the OS load from whatever storage it is on, and that something is usually your bootloader. It will be specific to your system, not the OS.

Well... even an OS on a PC is booted through a bootloader (like Grub for Linux) and you can modify the open source ones. On a PC it is not the BIOS which loads the OS; the BIOS loads an OS loader. On an embedded system it works in a similar way where a low-lever ROM routine probes/accesses various storage devices to look for a bootloader which then gets started.

It seems like it would be easier to have an external MCU that is connected to the console serial port of the RPi hardware to monitor system status. If it fails to boot - the MCU could manage a recovery routine. Perhaps shutting down the RPi, cloning a read-only image to the system storage and rebooting the RPi. At least the designer would have total control over the process.

That depends on whether the RPi's processor has some ways to recover internally (like a bootloader which can start from several different media). Otherwise you'll need external intervention indeed.

[MarkR42]

Absolutely yes. Use a Pi as an industrial computer.

I've seen stuff fail in industry. I've seen stuff work in industry. It seems semi-random what works and what fails.

By all means, try to make a "hardened" version of the Raspberry Pi - lots of companies make them - for your application. It will make it more robust but it doesn't guarantee anything.

But nor does buying a super-expensive industrial PC.

With the position of RaspberryPI in the embedded computing space at the moment, they are a sure choice. Their firmware updates happen, their new revisions are released, and there is heaps of community support (and professional, should you need it).

No other vendor has *anywhere* near as many units in the field. That alone has something to commend it.

I certainly wouldn't trust most of the "Pi wannabe" boards, because although they often tout good hardware specs, they're "here today, gone tomorrow". Pi is here to stay, and the RPF has a good attitude to supporting older models.

Loads of people like to complain about Pi, the hardware, the foundation, the "it's not as open-source as I'd like", but honestly, I think it's a good thing that we have something like this to make a standard for cheap embedded systems.

So your choice- buy an embedded PC from a big vendor for 10x more than a Pi, with worse long-term support, or get a Pi and know that it will still be around for a number of years, and you have enough budget to have several spares in the store room. The Pi device might fail, but the Foundation and the community probably won't.

[grifftech]

smartphone with custom os and power supply