I'm no electrical engineer (just mechanical) but I would like to apply some of my hobbyist experience to my job and implement various automated systems in an industrial (manufacturing) environment.

Traditionally, automation in the industrial setting consists of either engineered systems or PLCs. Engineered systems are too expensive and PLCs lack flexibility (and they can get pretty expensive as well).

I would like to replace traditional PLCs with more flexible, powerful, and cheaper Arduinos but I'm concerned about the Arduino's reliability. PLCs evolved in the industrial setting and are thus very rugged and reliable but how does the Arduino platform compare?

Assuming that proper measures are taken to protect the Arduino from mechanical and electrical damage, how reliable is the platform? Would you trust it to replace a traditional PLC that controls say a machine's safety interlock system to prevent people from getting too close to a machine in operation?

Edit: What about non safety critical systems? For example, introducing intelligence into say a fixture which a PLC would not be capable of?

  • 20
    \$\begingroup\$ You should not even consider, even for a minute, using an Arduino in a life safety situation. \$\endgroup\$
    – Mark
    Commented Jun 17, 2011 at 1:18
  • 4
    \$\begingroup\$ My opinion is, no I would not trust an Arduino for safety interlock systems. I will leave it up to others who actually have reasoning to do the answering. \$\endgroup\$
    – Kellenjb
    Commented Jun 17, 2011 at 1:18
  • 1
    \$\begingroup\$ @Mark - that goes for about every component. The datasheet almost always forbids this in a disclaimer at the end of the document. \$\endgroup\$
    – stevenvh
    Commented Jun 21, 2011 at 9:32
  • 1
    \$\begingroup\$ @stevenvh This is certainly not true of all components. A module designed and built for random hobbyist use is simply not tested and designed with the constant thought that if this fails someone can be hurt or killed. That is just on the best practices side of things without even getting into possible regulatory requirements that would depend on its use. You won't see an arduino running the air bag deployment system of your car any time soon despite the fact that there are plenty of components and micro-controllers involved in that process. \$\endgroup\$
    – Mark
    Commented Jun 21, 2011 at 22:09
  • \$\begingroup\$ NI's cRIO is what you are looking for. It is a realtime computer can survive anything. \$\endgroup\$
    – Sponge Bob
    Commented Feb 4, 2013 at 4:05

12 Answers 12


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.

  • 12
    \$\begingroup\$ I think with light-curtains and safety interlocks, the functionality generally isn't even implemented in code - It's plain discrete logic. I'd sure feel much safer trusting in an AND gate then a MCU in a safety-critical, time-dependent situation. \$\endgroup\$ Commented Jun 17, 2011 at 5:12
  • 4
    \$\begingroup\$ I agree with the sentiment-- I'd trust discrete logic over code too-- but empirically, I've seen lots of PLCs that check safety sensors with code. The best setup I've seen are multiple e-stop buttons in series with a contactor that supplies power to a system-- that seems better even than discrete logic. \$\endgroup\$
    – pingswept
    Commented Jun 17, 2011 at 12:31
  • 3
    \$\begingroup\$ @Fake Name that depends on situation. Every time you sit in a car your very much trusting your safety and possibly your life to a network of micro-controllers. It absolutely is possible to build relatively fail safe system with micro-controllers, but you don't be using an ardunio. \$\endgroup\$
    – Mark
    Commented Jun 21, 2011 at 22:14
  • 5
    \$\begingroup\$ @Mark - That scares the bejeezus out of me. \$\endgroup\$ Commented Jun 23, 2011 at 0:55
  • 2
    \$\begingroup\$ @Mark - I looked it up, The BMW M3 still has mechanical brakes, and I cannot find any information about steering, but I have significant doubts it lacks a mechanical fallback. The throttle is certainly entirely electronic (and possibly the gearshift), but my original point stands. I do not think mechanical fallbacks will disappear from Brakes/Steering within the next 20-30 years, if ever, at least until we get flying cars. \$\endgroup\$ Commented Jun 23, 2011 at 1:02

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 (:)

  • 1
    \$\begingroup\$ Excellent writeup. Engineering is a lot about right trade-offs than one fixed solution. More stringent conditions always need specialized hardware/software, however there is definitely a niche for [ AVR kind of general MCU + robust software ] controller. Also saying things like anyone can program a PLC is definitely marketing at work. \$\endgroup\$
    – rjha94
    Commented Dec 29, 2013 at 7:42

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.


I am not an engineer of any type. I am an electronics technician at a large aerospace company and have to retrofit and/or upgrade numerically controlled machinery like this all the time due to ancient equipment that we can no longer source parts for. While cost is a big issue the one that will get you in big trouble is the safety concern.

In the 2012 edition of the NFPA 79 (The electrical standard for Industrial Machinery) subpart it states:

"Control systems incorporating software- and firmware- based controllers performing safety related functions shall be self monitoring and conform to all of the following:

  1. In the event of any single failure, the failure shall:
    a. not lead to the loss of the safety related functions
    b. Lead to the shutdown of the system in a safe state
    c. Prevent subsequent operation until the component failure has been corrected
    d. Prevent unintended startup of equipment upon correction of the failure

  2. Provide protection equivalent to that of control systems incorporating hardwired/hardware components

  3. Be designed in conformance with an approved standard that provides requirements for such systems"

If you are capable of ensuring you meet provisions 1 and 2 I know you will not be able to meet provision 3 (unless you are accustomed to dealing with regulatory authorities)


If you use the arduino just to monitor and advise that a safety condition has occurred not control the actual safety circuitry itself you should not be in violation of this legal requirement.

i.e. An e-stop chain is in place that disconnects power from all motor contactors/drives from a main E-stop contactor when broken by any e-stop switch in the circuit. You would not want to use the arduino to control the e-stop circuit but you should be fine using an auxilary contact switch on the E-stop buttons to tell the operator which E-stop has been pressed on a display.

In this way even if the arduino is trying to drive a motor with control signals there will not be any actual power available because a main E-stop contactor has dropped out controlled by a hard energized e-stop chain - not your microcontroller.

Make sure you are aware of all of the regulations in the NFPA70E and NFPA79 and meet all of them. Trust me you do not want to find yourself in a litigation setting trying to answer questions without full knowledge of these regulations before you design something.

i.e. other things to consider are stopping motion too quickly - sometimes things have to remain energized for a set period of time before stopping to prevent a safety hazard - i.e. a large grinding wheel must spin down at a set rate so that it does not explode from stopping abruptly - in this instance you would want a large resistor that would use the motors Counter EMF to safely slow the rotational speed. You would want the contactor that dropped out the motor drive to put this resistor in line with the motor windings - not the arduino

These scenarios are also covered in the NFPA79.

Make sure you and your employer are comfortable meeting these regulations and accepting any potential liabilities.

definitely use a ruggeduino (it is worth the 45.oo for the added protection) and optical isolation for anything attached to the circuitry over 24 volts. Most of the arduino compatible relay controls on the same site are OMRON and used for many industrial applications. Have someone with experience and qualifications review your design before implementation - remember none of us is as smart as all of us

The only way to test it for your application for durability would be to design it and see how long it works. Definitely have an identical spare ready to replace on the shelf if cost/time are big considerations.

Let me know if you have any questions.

  • \$\begingroup\$ Thanks for the info, always good to hear from someone who has experience in the field. What about DC systems under 24v? \$\endgroup\$
    – Faken
    Commented Oct 15, 2012 at 18:01

There is what is claimed to be an industrial quality Arduino clone named the Ruggeduino that has input and output protection, their website makes interesting reading on the topic of ruggedising an Arduino.


Basically ... I don't have support for Arduino. Arduino is exposed, it has no case and does not give warranty about some IEC standards you have to meet. For example how Arduino runs with 2 or 3 years of dust on its top.

On the long run, as somebody already said, if a machine costs $1M a day, it is cheaper not to use Arduino. Mainly because it will die, later than sooner and in 6 to 10 years, the Arduino you use today will no longer be available for you to repair a machine in a suitable time (being opensource you can produce it ... but).

OTOH ... if you use Arduino as PLC you have to develop auxiliary circuits, develop tons of software and in the end, after tons of time and equipment you will see that you will have the same that Allen Bradley, Siemens et al. but with a superior cost.

Not only the manufacturing cost is huge, but modifying it in a few years will be, mostly if you try to integrate fieldbus technology like profibus or ASi.

It is fun to play ... but it is not THE solution.

  • 3
    \$\begingroup\$ I have use the Arduino in a project and I regret nothing! Using the Arduino, I was able to complete the project in record time (parts available at digikey, 2 week development time vs 3 week lead time just to get the PLC ordered in), at a quarter the cost (vs PLC), and learn A LOT about electronics (sensors, motors, PID control, and basic wireless communications)! Honestly, this answer sounds like it was written by a PLC manufacture themselves. \$\endgroup\$
    – Faken
    Commented Nov 8, 2011 at 2:04
  • \$\begingroup\$ Hah, it really does sound like a shill. \$\endgroup\$ Commented Oct 13, 2017 at 0:42

They are selling MSP430 with circuitry for usage in cars.

Because I don't know anything about industrial approvals, I don't know what kind of approval for safety applications these "Micro-PLCs" have.

However, for a safety interlock I wouldn't trust anything with a software more complicated than a simple switch.


Most of the ruggedness comes from the EE put behind the electrical design of the whole schematic and PCB. There is nothing special about the chips 'certified' companies are using - they are just cheaper in quantities and perhaps have certifications of their own. But I would assume Atmel and Microchip already match those. Real strength comes from a lot of testing, various backup methods (brownout/overvoltage detectors, watchdogs) and careful layout. My impression is that PIC/Arduino aren't used on a large scale because they are more expensive and provide more than needed actually.

  • \$\begingroup\$ You can't really compare the entire PIC line to Arduino, and what's more PICs are used on a "large scale" -- they turn up in places expected and not. \$\endgroup\$ Commented Oct 13, 2017 at 0:44

I am electronic Engineer and using Arduino mega board for my some educational applications and I am also the user of Labview DAQ Modules like DAQ-6009 /6008 and etc... i am also the user of PLC from allen-bradelly and etc... but I find the suitability of Arduino must be tested in industrial harsh environments like temperature fluctuation , dust and humidity conditions and also the vibration and EM radiations and even reliable connection to the sensors or actuators and also to the other data processing cards need prior to give the signal i?p and before giving it to the final end-effectors like valves and etc...

from this web page and discussion I am going to generate the testing facility of Arduino cards for industrial applications.. for different types of environments.. and for different parameters.. etc.

  • \$\begingroup\$ And please report back your findings. Welcome to EE.SE \$\endgroup\$
    – Andrew
    Commented Nov 14, 2012 at 8:45

The Atmel microcontroller that runs the Arduino is also available for automotive and industrial control systems. So far, so good!

[quote]Their hardware is made with the same manufacturing processes as Arduinos[/quote]

Unfortunately, the rest of the Arduino board probably isn't so ruggedized.

There's a number of design compromises that may reduce lifetime to lower cost. For example, capacitors may not be rated for 10k-hours at 105C, but instead for2k-hours at 80C, and there's a real difference in lifetime there! Similarly, the regulator on the Arduino is a cheap high-dropout version, rather than a more capable ultra-low-dropout version. (Ever wondered why the Arduino needs 7V or more to generate 5V? This is why -- with an ULDO regulator, 5.3V would have been enough.) And will your power supply ever go into brown-out? How do you know the entire system is in a safe state if it does? There's not even a fuse on the board!

Similarly, there is next to no protection against a harsh environment on the Arduino board. The contacts are cheap, consumer-grade female contacts rated for a few dozen insertions, not IP-65 rated contacts (for cost.) The I/O pins rely on the built-in weak ESD protection of the Atmega MCU, with no external protection.

If I were to build a safety-critical system, I may very well use an Atmega MCU, but I would not use the Arduino board as-is. The cost of spinning a new board with new components designed for the situation would be small by comparison. And on that board, I could put all the driver hardware I need, and interface protection, and use real, ruggedized connectors. Not that I'm actually qualified to build a safety-critical electronic system -- I'm a software guy!

For a take on the Arduino with some electrical protection (but still no protection on the other failure modes,) check out the Ruggeduino: http://ruggedcircuits.com/html/ruggeduino.html


I think the issues with dust, humidity, vibration, etc., can be easily addressed. I have worked in automotive collision repair for 30 years and service all manner of controllers. The simple solution used in automobiles to address the harsh environment is to encase the control module in a non-conductive resin which prevents any moisture or dust from coming in contact with the controller and at the same time it makes the controller impervious to vibrations.

I am also a kayaker and built an electric pump system for my boat to address the life threatening issue of trying to pump out a flooded boat in storm conditions. Over the years the issue with electric pumps in kayaks has been the electronics being accessible to use but protected from salt water. No one seemed to have anything but temporary success doing it.

Turns out, by using a magnetic switch and encasing switch and controller in urethane, I have a system that has survived 3 years of salt, and fresh, water submersions as well as all the poundings the waves, and car transport, can throw at the boat.

I am no expert on electronics, mind you. So maybe there is a weakness in Arduinos that makes them unsuitable for safety systems but there is nothing in the environment that they couldn't be protected against with a little thought.


Using Arduino in industrial environment can be acceptable if:

  1. You protect your inputs and outputs as good as PLCs do
  2. You implement brown out detection and watchdog in your application or with help of external hardware
  3. Your application takes care that your outputs are always in a known safe state
  4. You implement all interlocks and safety directly in code
  5. You spend more time testing then writing code
  6. You do not need certification for your custom built device

You will probably need to provide MODBUS or PROFIBUS protocol interface, and make drivers to interface 0..20mA, 4..20mA, 0..10V, TC, motors, encoders (or use MODBUS/PROFIBUS slave cards with built in such drivers)...

If you want to program your device in ladder logic instead of C/ASM/PAS/BAS, you can. This software provides that.

Ladder Logic Compiler


Not the answer you're looking for? Browse other questions tagged or ask your own question.