Embedded guys view PLC engineers as dinosaurs. PLC experts view embedded systems as finicky, risky and overly complex. Which is best? The answer of course is that it depends on your situation and objectives. This article explores 12 factors which can help structure the decision making process.
Physical integration into product
An embedded system can be fully integrated into a product. For an example, a smart TV has its embedded system integrated into the TV body. A PLC is a larger standalone unit which is pre-packaged and typically rack-mounted in a cabinet near to the process it’s controlling.
Physical environment e.g. vibration, shock and temperature
PLCs are ruggedized and pre-tested to withstand certain physical environments. Depending on the physical environment, an embedded system may need to be custom-packaged and tested to make sure it can withstand the conditions.
Certification
If a certain certificate is needed, e.g. SIL (Safety Integrity Level) or RoHS (Restriction of Hazardous Substances), PLCs can be found pre-certified. With embedded systems, certified boards and modules can be found but the integrated solution may need to be further assessed and tested to demonstrate conformance with certification standards.
Unit cost and Development cost
Once developed, an embedded system can easily be less than 10% of a PLC unit cost. To develop however, embedded systems typically cost more as there’s more integration and interfacing to be built-up. In addition to the hardware unit costs, PLCs often have reoccurring software license costs which must be renewed annually. Embedded software stacks tend to be open source and therefore free, with some exceptions. A key trade-off here is the expected production volume, balancing the non-reoccurring costs (development) with the reoccurring costs (unit).
Flexibility
PLCs come with many of the technology decisions already made e.g. CPU, operating system, compiler, programming language, development environment, user interface etc. With embedded, we are free to make all these choices ourselves. This situation has pros and cons. Making the technology choices in embedded can be daunting and confusing but this gives considerable flexibility. A PLC on the other hand is ready to go out of the box but we are constrained with the technology decisions already made by the vendor. For example, if we don’t like the user interface library of a PLC, we’re stuck with it.
Code libraries and languages
PLCs are usually restricted to IEC 61131 languages e.g. ladder, function block, sequential function chart etc. These languages are simple to use but limited in the complexity of functionality they can implement. Linux-based embedded systems can be programmed in any language e.g. C, C++, C#, Java, Python etc. This gives us considerably more power and flexibility but requires more skills. Additionally, if we want to standardize code across an installed base of products, embedded languages support this better due to their object-orientated nature.
Version control
PLCs typically save their source code into a ‘binary blob’ i.e. a vendor-proprietary file format. Embedded systems are programmed in text-based source e.g. C/C++. Version control for text-based source is very well developed with tools such as Git. Version control for PLCs however remains a challenge, relying on vendor-specific tools which don’t provide the power of Git.
User Interfaces
PLCs are renowned for having dated UIs which look like 1990s websites. This is of course improving but it doesn’t compare to what can be achieved with embedded UI frameworks. In embedded, we have the choice of more powerful UI frameworks such as Qt and JavaFX.
Remote updates and remote monitoring
PLCs were initially conceived as being isolated, factory or industrial-setting based i.e. not connected to the internet. The major PLC vendors are making steps to improve this, but they don’t have the power of an embedded system. With embedded, we can easily set up a web server on the board and configure CI/CD pipelines to push new code improvements out to the field.
Real-Time
PLCs come with real-time schedulers which facilitate running specific loops at desired timing intervals. To achieve this with an embedded system, an RTOS (Real-Time Operating System) may be required, which needs more skills to select and configure than a PLC.
QA (Quality Assurance)
The technologies available on embedded systems have many choices available for testing frameworks. This makes it very easy to setup and automate testing e.g. running regression testing following a code modification. PLCs are not as mature in this area and usually don’t include even a simple unit testing framework.
Support
PLC vendors have support teams which you can call if you have problems or questions. Clearly this comes at a cost. With embedded, you’re usually on your own. Some board manufacturers offer application support, but it’s typically not as well developed as with the PLC vendors.
In conclusion, the choice of Embedded Systems vs PLCs depends heavily on project circumstances, as described by the 12 factors above. Contrary to popular belief among embedded systems engineers, PLCs still have their place and are an excellent choice when straightforward functionality is required without space constraints. Managers and Engineers facing this choice are encouraged to be as objective as possible, assessing their circumstances against the 12 factors above using a structured tool such as Quality Function Deployment.
Great summary. Too bad PLCs aren’t recognized for their place. But also, PLC engineers know their way around power equipment. Less likely to electrocute themselves on the customer site.