History of PLC Programming | PLC Programming Language: Ladder Logic | PLCs Programming in the Era of IoT | 5 Architectural Considerations & Approaches for Connected PLCs | PLC Programming with Temboo’s Kosmos

What do the baggage claims at airports, cement mixing machines, and roller coasters all have in common?

As different as all of these things are, on the backend they are all controlled by the same type of sturdy computer – the PLC.

Programmable Logic Controllers, more commonly referred to as PLCs, are the ruggedized computers that have been at the heart of industrial automation applications since the 1970s. They’re used to automate industrial control systems that have strict requirements around real-time controls and fault tolerance and are a critical part of many types of automated physical systems.

Now, in the Age of IoT, there’s more interest than ever in harnessing their data and capabilities for the Internet of Things, particularly when upgrading existing offline systems that already use PLCs.

In this post we’ll recap the history of PLC programming and go over 5 PLC programming considerations to take into account when building industrial IoT systems.

Already an expert in PLC Programming? Skip ahead to the 5 considerations by clicking here.

PLC Programming Throughout the Years

PLCs were designed to replace complex systems of physical electrical components (wired relays, sequencers, and timers) that prior to the 1970s were used to automate industrial processes.

As these electrical systems grew, the time needed to alter them in response to changing product requirements grew too, demanding a prohibitively expensive number of electrician hours per update.

PLCs were born out of a desire to harness emerging digital technology in order to make maintenance of industrial automation systems less labor intensive.

The first PLCs were programmed with proprietary programming languages using custom computer terminals that featured input keys mapped to specific PLC functionality.

The lack of commonality between the various PLC models and programming approaches eventually led to standardization, and in the 1990s a number of official programming languages were defined by the International Electrotechnical Commission (IEC). Their initial standard defined two graphical and two textual approaches for programming PLCs, with Ladder Logic proving to be the most popular.

Ladder Logic: The Official Programming Language for PLCs

The software was designed for the problem, to be implemented by the electrician.

-Dick Morley, Inventor of the PLC

Ladder Logic is a visual programming language that is meant to encapsulate the essence of the physical electrical systems that PLCs replaced.

More specifically, Ladder Logic was based on relay logic hardware, which made it an easy language for automation technicians to be immediately productive with (because they didn’t have to learn a brand new text-based programming language).

Engineers or technicians use a graphical interface to define contact-coil logic, developing digital programs in the same manner as the traditional electrical control systems they replaced. In Ladder Logic the physical coils and contacts are replaced with bits at numbered PLC memory locations.

The IEC ultimately defined five standard PLC programming languages, with the last major update to the IEC 61131-3 standard coming in 2013. These languages are intended to be used in combination, with logical organization and encapsulation of operations being the IEC’s major design goal.

The five standard PLC programming languages are as follows:

• Ladder Diagram: this graphical language is used to used to define sequences of control operations using a relatively limited set of logical operators.
• Function Block Diagram: another graphical language that is used to organize blocks of textual source code into visual diagrams so that PLC programs can be more easily understood.
• Structured Text: a high-level textual language based on PASCAL that supports variables and nested functions.
• Instruction List: a low-level textual language that most closely resembles assembly language.
• Sequence Functional Chart: visually similar to UML activity diagrams, these charts enable graphical description of more complex application flows and can be composed of Ladder Logic steps.

Now that we’ve taken a quick tour through the history of PLC programming, we’ll switch gears and look at how the meaning of PLC programming expands in an IoT context, and what that means for developers of IoT systems involving PLCs.

PLC Programming in the IoT Era

PLCs were not built with the internet, not to mention the Internet of Things, in mind.

Yet today, the IoT space has matured to the point that it is driving real business value to industrial customers. It goes to follow that people are naturally starting to ask questions about the impact IoT will have on the established field of PLC programming.

There are many options available when it comes to combining PLCs and IoT technologies, all of which share the common goal of successfully merging the hard real-time guarantees and rugged form factor of PLCs with the remote monitoring, alerting, and advanced data analytics of the IoT.

So what do companies need to think about when working with PLCs in an Industrial IoT system?

5 Architectural Considerations & Approaches for Connected PLCs

PLC technicians were previously concerned only with specification of the PLC application logic itself. Networking, which was always wired, didn’t extend beyond the factory floor.

Now, the advent of wireless industrial interfaces, low-cost sensors, and cloud computing has given rise to a set of emerging requirements for industrial applications. These PLC IoT applications center around sensor-based alerts in various mediums (email, SMS, push notifications), easy access to data on PC and mobile devices, and increasingly sophisticated data analytics.

Consequently, programming a PLC application takes on a new meaning, with most of the impact manifesting not in the core PLC code (which is still specified in Ladder and the other standardized languages), but at the interfaces between the PLC and the other components that make IoT systems a reality.

Here are the five things to keep in mind when deciding on how to program PLCs to be part of an IoT system.

1. Data Acquisition

The manner in which a PLC exposes its inputs and outputs (sensors and actuators) to external hardware and software components is the primary determinant of much of the impact there will be on the PLC code.

At one extreme, the code running on the PLC can be updated to make specific values available as outputs, or to process new external inputs like remote control requests.

At the other extreme, you can simply ingest a PLC’s existing outputs using a standard industrial communication protocol (e.g., Modbus) and base your IoT system requirements on what the PLC already exposes.

For diagnostic information, different PLC models make diagnostic data available in a variety of non-standard manners (often via an onboard web server) and these web servers need to be configured on a case-by-case basis to facilitate access by other IoT system components like internet-connected gateways.

As a general rule, it is typically best to minimize the amount of PLC code modification required when designing an IoT system. The focus should be on feeding the existing output of the PLC into the IoT system via Modbus, thereby avoiding invasive and potentially error prone PLC code edits.

2. Communication Method

PLC communication interfaces can be either wired or wireless.Wired interfaces are by far the most common (e.g., serial cable), and in an IoT context they imply the use of an internet-connected gateway that collects local PLC data via cable and transports to its final destination (e.g., a public or private cloud datastore).

However, industrial interfaces using standards-based radio technologies like Zigbee, or proprietary sub-1Ghz solutions, are becoming more common and are a great option when minimizing cabling is a requirement.

A less common option is to connect PLCs directly to the internet by way of a cellular modem. The communication method that you choose will impact the amount of configuration on a per-PLC basis, with wired interfaces typically requiring less developer effort.

3. Core Behavior Impact

PLCs are typically used for their hard real-time capabilities, and it is generally not advisable to introduce IoT functionality directly into their application logic.

Any new system functionality that involves networking should be kept completely isolated from a PLC’s core control loop. This applies to both local networking and especially to remote networking, with external network communication being particularly unsuited to involvement in driving real-time controls due to its nondeterministic nature.

Leveraging a gateway-based architecture enables you to get the best of both worlds, with PLCs continuing to take care of automated control tasks while sending their data into the IoT infrastructure via a standard communication protocol like Modbus.

4. Reusability

In order to get the maximum return on your PLC development effort, you should aim to build your system in a way that is PLC vendor-independent by adhereing to standards as much as possible.

The vast majority of PLCs can communicate over the Modbus communication protocol, and basing your IoT system on the Modbus outputs of a given PLC is the best way to achieve portability across different PLC models in the most seamless manner.

5. Security

Security is understandably a major concern when considering whether to extend a PLC-based system with IoT capabilities, particularly when external networks e.g., the internet, are involved.

While Modbus is a great option for communicating with a wide and disparate range of PLCs, as a protocol it is inherently insecure and must therefore be used within an appropriately security conscious system architecture.

By designing your system to proxy network activity via a secure, internet-connected gateway, and avoiding directly connecting Modbus devices to the internet, you can achieve the benefits of IoT systems while mitigating the associated security risks.

PLC Programming with Temboo’s Kosmos

At Temboo, we know how hard it can be get industrial-scale IoT applications off the ground, particularly when you’re combining legacy PLC hardware with emerging networking and data technologies.

Our Kosmos IoT System makes it easy for engineers of all types to create data monitoring, alerting, and analytical applications for PLCs and industrial equipment by leveraging Temboo’s technology for machine-generating source code which produces all of the necessary application files for PLCs, gateways, sensor devices, and more via an intuitive, visual user interface.

Kosmos empowers people and organizations to build, configure, manage, monitor and analyze their own industrial IoT systems.

If you are interested in learning more about how to use Temboo’s code generation technology to program your PLCs as part of an IoT system, get started by signing up for Kosmos today.