ความน่าเชื่อถือของแพลตฟอร์ม Arduino สำหรับใช้ในอุตสาหกรรม

ฉันไม่ใช่วิศวกรไฟฟ้า (แค่เครื่องกล) แต่ฉันต้องการใช้ประสบการณ์งานอดิเรกของฉันกับงานของฉันและนำระบบอัตโนมัติต่าง ๆ มาใช้ในสภาพแวดล้อมอุตสาหกรรม (การผลิต)

ตามเนื้อผ้าระบบอัตโนมัติในการตั้งค่าอุตสาหกรรมประกอบด้วยระบบวิศวกรรมหรือ PLC ระบบวิศวกรรมที่มีราคาแพงเกินไปและ PLC ขาดความยืดหยุ่น (และอาจมีราคาแพงเช่นกัน)

ฉันต้องการแทนที่ PLC แบบเดิมด้วย Arduinos ที่ยืดหยุ่นมีประสิทธิภาพและราคาถูกกว่า แต่ฉันกังวลเกี่ยวกับความน่าเชื่อถือของ Arduino PLC มีวิวัฒนาการในอุตสาหกรรมและมีความทนทานและเชื่อถือได้มาก แต่แพลตฟอร์ม Arduino เปรียบเทียบอย่างไร

สมมติว่ามีการใช้มาตรการที่เหมาะสมเพื่อป้องกัน Arduino จากความเสียหายทางกลและไฟฟ้าความน่าเชื่อถือของแพลตฟอร์มเป็นอย่างไร คุณจะเชื่อใจได้หรือไม่ที่จะเปลี่ยน PLC ดั้งเดิมที่ควบคุมว่าระบบความปลอดภัยของอินเตอร์ล็อคเพื่อป้องกันไม่ให้ผู้คนเข้าใกล้เครื่องที่ใช้งานมากเกินไป?

แก้ไข: ระบบความปลอดภัยที่ไม่เกี่ยวกับความปลอดภัยเป็นอย่างไร ตัวอย่างเช่นการใช้ปัญญาในการพูดฟิกซ์เจอร์ซึ่ง PLC จะไม่สามารถทำได้?

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

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 9.4.3.4.2 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)

HOWEVER,

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.

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.

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.

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.

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.

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.

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.