top of page
background.jpg
Paraj Kayande

The Case for Apps in Automation

What are apps?

We use the term "apps", which is short for "applications", to refer to standardized and configurable programs that integrate with programmable logic controllers (PLCs), remote terminal units (RTUs), or other real-time controllers. Reverity's PLC Shift apps run on a Linux-based computer and synchronize tag data with the controller once per second using real-time industrial protocols like Modbus, Ethernet/IP, and others. Apps extend the functionality of the controller; they do not replace the controller. The controller is still responsible for process safety, communicating with IO, and other functions that PLCs are good at. The figure below shows a basic PLC Shift system. A more sophisticated architecture can be found on our website.


PLC Shift basic architecture
PLC Shift Basic Architecture

Why do we need apps?

PLCs and RTUs are programmable devices, which means that they are inherently very flexible. However, they are not programmed using general-purpose programming languages, but using IEC-61131-3 languages. These languages are very much suited to real-time control, but they are not suitable for general-purpose programming.


Additionally, PLCs are designed to provide guarantees around the time it takes for a program to execute. This makes sense for hard real-time applications like motion control, but the paradigm is wrong for general-purpose computing, like pulling power pricing from a 3rd party like OpenADR using a RESTful interface, which may take many seconds to execute.


The advantages of each type are listed below.


PLC Advantages

  • Fully programmable for great flexibility

  • Deterministic hard real-time control

  • Hardened IO

  • Safety rated

  • High reliability, including redundant architectures


App Advantages

  • Standardized solutions to common problems

  • Math-heavy algorithms and optimization

  • Make app configuration changes without modifying PLC logic

  • Vendor supportable

  • Scalable and flexible deployment

Modern automation systems need to do many other things outside of real-time control. In addition to communications with external APIs as mentioned previously, functionality like recipe management, batching, logging data, machine learning, optimization, data export, and others are well suited to apps, but poorly suited to PLCs. As a specific example, let's look at a gas flow computer. A flow computer calculates temperature and pressure-corrected flow using algorithms designed by the American Gas Association (AGA). Calculating corrected flow in a PLC is fairly straightforward if you have function blocks that encapsulate the required algorithms. However, a flow computer does a lot more than just calculate corrected flow. To meet regulatory and operational requirements, a flow computer also has to:

  • Generate hourly and daily accumulations

  • Log configuration changes and operational changes (event log)

  • Log alarms (alarm log)

  • Average inputs and generate hourly and daily records

  • Make history and logs available to other systems

  • Keep history and logs in memory for later retrieval


Gas flow history in xlsx format
Gas Flow History

This functionality is very poorly suited to PLCs, which is why you won't see a gas flow computer implemented directly in a PLC. A gas flow computer is an extreme case, but there are any number of processes that PLCs are used for that would benefit from the app approach, especially once optimization, history, and other complicated features are layered in.


With PLC Shift apps, we combine the best features of general-purpose computers and apps with the best features of PLCs. We free each system to do things that they are good at without burdening them with the things that they are not good at. This leads to robust, configurable, and scalable systems that are easy to deploy and maintain.


What are the benefits of apps?


Configuration vs. Custom Code

A PLC needs a program to do anything useful. Writing a reliable, fully featured, and documented program is a time-consuming task, and requires a very specialized skill set. It is possible to write PLC programs in a modular fashion, but it's difficult, and the resulting programs are not truly modular like general-purpose applications. In other words, the configuration of the PLC program is usually mixed in with the execution, because the PLC programming paradigm does not allow for any other approach. To modify the configuration of the program in the PLC, the program itself must be modified. With multiple sites, the program in each PLC ends up being slightly different to account for site-to-site variations even when PLCs at each site are ostensibly doing the same thing. Apps, however, are configurable. Each configurable parameter has an explanation of what it does, and each value is validated before being accepted by the app. Validation is not just limited to making sure that a value is within a certain range, but also includes cross-validation, where any configuration value is also validated against all other values, to make sure that the new value is legal in the context of the current operating state. The screen grab below shows that the methane portion of the gas composition cannot be changed to 0.8 because this would cause the sum of all components to not be exactly 1.0. The change remains in the pending state. If another component is changed such that sum becomes 1.0, all of the pending changes will be accepted and the flow computer will calculate compressibility based on the new gas composition. Validation of this type is very difficult to do in a PLC.


Gas composition change is not accepted because sum of all components is not 1.0
Cross Validation

The end result is that configurable applications make it easy to implement complicated processes quickly in your automation system. To change the behavior of the app, only the configuration of the app needs to be modified, not the PLC program itself. Apps allow you to build reliable, repeatable, and configurable systems quickly with minimal custom code.


Scalable Integration

Standardization is key to building out scalable integration with other systems, such as SCADA, enterprise historians, or data lakes. Without standardization, each integration needs to be tweaked with site-specific information. It doesn't take many sites until this becomes overwhelming and stops working. In the previous section, we showed that the PLC programming paradigm results in a lack of standardization. With fully-custom code, sites that are doing the same thing invariably end up with different programs. The opposite is true for configurable applications, which are inherently standardized. This makes it easy to move the data that is generated by apps into other systems, with no site-specific tweaking required. With PLC Shift apps specifically, because we have so much context around the application and the data that it's generating, we can even automate the creation of data models.


Contextualized Data and Automated Export

Check out our blog post on Levels of Context for some background on this. Configurable and standardized apps are the best way to easily implement all of the levels of context described in that post, especially the high-level behavioral context.

PLC Shift apps can export contextualized data to the cloud or other systems with just a bit of configuration. This eliminates tedious and error-prone manual tag mapping. Data is immediately useful for analysis, with no further processing required. PLC Shift can also export record-based data, like flow computer history, directly to the cloud or to other systems. This is trivial to set up compared to legacy approaches like custom drivers and 3rd party polling engines.


Diagnostic Logging

When things go wrong, as they inevitably do, how quickly can you figure out what's going on and get back online? PLC ladder logic is extremely easy to debug visually, which is why it remains popular. However, as a PLC ladder program gets more complicated and larger, it gets harder and harder to debug. PLC Shift apps generate sophisticated diagnostic logs and configuration change logs that make it easy to understand what's gone wrong, which makes it easy to get back on track. We also understand our program in great detail, and support you to help you get back online.


PLC Shift controller driver logs shows performance information and one error
PLC Shift Controller Driver Log

PLC Shift configuration change log shows all configuration changes and their source
PLC Shift Configuration Change Log

All configuration changes are logged automatically, and include a source, which makes it easy to understand when a change happened and where it came from.


Conclusion

Apps extend the functionality of PLCs, but they do not replace them. Combining apps with PLCs allows each system to do what they're inherently good at, which ultimately leads to full-featured, reliable, and scalable automation systems. With our in-house automation application framework, we can deliver fully-featured applications for your specific needs in weeks, not months or years. Get in touch and let us know what you need!

bottom of page