Reliability of the Arduino platform for industrial use
PLC manufacturers would like you to believe that their software is more reliable and more thoroughly tested. My impression is that the core OS components of PLCs are usually quite well designed and tested, but the drivers for external hardware (motion systems and the like) are often libraries hacked together by applications engineers and then passed around the company. The hardware in PLCs is often antiquated-- a lot of them are running old, hot Geode processors.
When you buy a PLC from Allen-Bradley, B&R, Siemens, or any of the other big players, you're mostly paying for support when things go wrong. Their hardware is made with the same manufacturing processes as Arduinos, and there's nothing magical about the real-time operating systems running on PLCs that makes them bug-free. But, I think that support is often worth paying for. If it's a machine that costs the company $1M every day it's not operating, I'd be damn sure that when something went wrong, there was a team of professionals who could help fix it, not just me and Google. For the specific case of light curtains or other safety interlocks, I would want to make sure that the manufacturer had a hefty insurance policy in place, rather than a statement that tries to disclaim all merchantability for any particular purpose.
Even so, if I were designing (for example) a bit of simple pneumatic actuation for some fixture, and I was willing to shoulder the support burden of fixing the machine when it broke (or if I wasn't able to get the resources allocated to pay for the PLC), and safety wasn't an issue, I'd happily use an Arduino.
I'd probably prototype the system with an Arduino and then rewrite the code in pure C once it was working, so that my code was the only code on the microcontroller.
Arduino itself is not good for industrial applications due to lack of proper protection & shielding. But it is possible to make industrial-grade AVR-based controllers:
You should have shielding, power filtering/regulation/protection, optopairs to drive external things, decent decoupling caps on each digital chip.
You should test it very carefully when switching on/off high loads, it's better to check if you have any glitches on ground/power/data lines during this commutation with oscilloscope (down to 1ns range).
You should check your clock source very carefully - AVR does not fallback into RC oscillator in case of crystal oscillator fail. So you'd better stick to internal RC if you don't need clock accuracy or pay extra attention to crystal routing, load capacitors, PCB quality(=flux reminders, moisture protection) and shielding around crystal.
There are better uC for industrial applications, notably having this RC-fall-back feature.
Prior to the PLC, industrial process control was performed by relay logix (for digital control) and PID controllers for analogue control. Relays were notoriously unreliable, the failure of which in some cases had serious consequences. Despite this, the suggestion that this could be better performed by a computer running software with semiconductor outputs instead of relays horrified most electrical engineers at the time. The arguments against the adoption of PLC's in those days were similar to some of the arguments in the answers in this forum. Resist interesting suggestions and you are certain to be in good company. Economics, downtime and maintenance considerations drove (slowly) the transition from hard-wired control to micro-controller/software control. I recall more recently, the horror with which Ethernet and the various associated protocols at the time were greeted by the control establishment. Ethernet is now fast becoming the de facto standard for process control.
Nowadays, in the most sophisticated control systems, safety-critical processes always have a hard-wired/pneumatic/hydraulic/mechanical backup, or at least a fail-safe state. The operator interface to the control system is an essential part of the control system, which outside of machine control, is in most cases a desktop computer from the local PC store, with a buggy/crash-prone operating system that runs buggy/crash-prone process-control applications. This is no exaggeration. We have designed and built plants in the most challenging environments in the chemical and mining industries where dust and fumes are part of life, even in the control room, and have no more failures from standard off-the-shelf consumer/commercial equipment than from industrial equipment. Hard-drives fail but they are sealed. They fail anyway. We regularly blow clouds of industrial dust of PC motherboards that run the HMI's. The trick is to have dual/triple redundancy in all important/critical systems. Anything can fail. That is why safety-critical stuff is always backed up by hardware, and this is a legislative requirement in most countries and common-sense in others.
If one wants to bring aviation into the discussion, remember the horror with which non-Airbus aircraft manufacturers met the suggestion of fly-by-wire. In air accidents, human error (mostly pilot but also maintenance staff), not engineering/systems failure still accounts for most accidents by far. In the PLC/micro-controller industrial/commercial space, I would argue that the human at the programming terminal is still the most critical element. Software DESIGN, STRUCTURE and MAINTAINABILITY are the essential ingredients rather than the hardware.
Rockwell offer the SoftLogix product which is a software PLC running on a standard store PC. Think about it. The argument that the PC's run in a more protected electrical/atmospheric environment than the PLCs/controllers can be true for some cases, but not in most, and very few in the plants we service. The irony is that the proliferation of Ethernet requires Ethernet switches in the field. We don't, as a rule, use industrial switches, but standard commercial stuff and have yet to have a switch failure after 10 years and hundreds of installs. These switches reside in the same panels as the PLC I/O. What DOES fail, but rarely, is the cheap power supply that accompanies the switch. Avoid that and the switch will not be the most unreliable component in the installation.
As for rigorous testing/quality control of industrial PLC equipment, I recently commissioned a plant where EVERY ONE of the 8 or 10 remote I/O analogue input cards was DOA. The supplier, one of the biggest name brands in the world, didn't bat an eye and replaced all immediately. I guess it was a bad batch and they might have known of the problem before our report. The replacements worked perfectly and still do 3 years later.
Fear is used everywhere these days to intimidate us. Use reason and as some old-timers used to say, 'suck it and see (for yourself)'. I would have no hesitation in trialling 'non-industrial' micro-controllers anywhere. Just follow good engineering practice, quantify the risk and act appropriately. Incidentally, motor vehicles operate in conditions not too dissimilar to to some industrial conditions (wet, hot, vibration) but have many electronic safety-critical systems. Now try suggesting to an industrial control systems engineer that you are about to trial an automotive component in your plant! CANbus or DNET anyone? Go figure (:)