In terms of data creation and usage PLC programming is bizarre. The process database is copied to the instrumentation and control design database which is copied to the PLC program. Continuous synchronization of these databases is resource-consuming and leads to poor programming and chronic delays in the project execution.
This challenge is well-known in the water industry. Recently a leading desalination company decided to switch from its PLC-based design to third-party DCS in a BOT megaproject of 670 MLD (under overdue construction) because it did not find experienced engineers for existing PLC program customization and upgrade.
The enormity and ubiquity of the challenge in question and failing attempts to resolve it indicate that it is time to try a different strategy. It is to standardize programming PLC and reduce its time by automating the boilerplate tasks. And that leads us to the design philosophy as a starting point.
Philosophy deals with the fundamental part of knowledge or experience that works in any project. In other words, philosophy sets boundaries in which the control engineer executes the following steps of PLC programming.
- Data Interpretation
- Data Transfer
- Data Engineering
- Data Structuring
- Data Tagging
- PLC programming
- Code validation
Data interpretation relates to learning. It is a mental extraction of control-related data from the bulk of the process design one.
The task of the data transfer and engineering is to move from the process perspective on the project to the control one. It includes building a database and populating it with the data representing a mix of the process one and new control-related data like instrument signals and voltage, cables, junction boxes, I/O modules, etc.
Data structuring is the essence of the control philosophy. It turns the plant data space into a hierarchy of relatively stable data blocks. Data tagging is creating an identifier for each data piece. It should be unique and readable - two sides of the coin.
As the list suggests programming itself is essential but not critical, other preceding steps may send it down the drain.
In isolation from other steps all languages specified by IEC 61131-3 for PLC programming - LD, FBD, IL, SFC, and ST - seem equal. The holistic view leads us to a clear winner - Structured Text (ST). Its philosophy transforms every step described above.
ST is simple
The process engineer may equally learn and use ST for control data description like operation points, alarms, and interlocks. If the process data transfer is made in ST, the data interpretation is redundant.
The snippet below is taken from www.pdhonline.com. It illustrates how readable the ST program is.
ST program is shareable
ST program is just plain text to be copied, mailed, or uploaded to running PLC. Any text editor may be used for ST program editing. No proprietary PLC software is needed.
Open-source libraries of ST programs validated and debugged may be shared and re-used through the GitHub website. Code sharing will skyrocket the PLC programming.
Such libraries may include generic math algorithms, engineering calculators, algorithms for the maintenance logic, or simulators and signal generators for program validation,
Similar to JSON format in web development, the ST structures may be developed for the database import from P&ID. It is discussed elsewhere.
ST is OOD language
Object Oriented Design (OOD) implies that the designer creates its own language - a set of higher-level abstractions (aka ST structures) - out of primitive types that come with ST and uses them for replicating the plant as a hierarchy of subsystems described by PFD and P&ID.
An ST structure may contain another structure. Such a style of programming hides the complexity of compound objects and makes ST programs much simpler to understand.
ST arrays of user-defined type are a big leap forward, as they make similar device state scanning simple.
ST program often uses data collected from different sources. Stucture is ideal for grouping equally critical data and maintaining its consistency across continuous fixed-time-interval scanning of the ST program.
Introducing standard structures that make control information interoperable and understandable to contractors is a sure way to avoid the disaster described above.
ST changes process engineering
From ST's perspective, P&ID shall be an extended view of PFD. In its turn, PFD shall depict process modules, not equipment pieces like pumps, valves, or filters.
Today crenger.com is the only software that implements these logic requirements. In practical terms, it means that OOD should start from the process engineering. This point is extensively discussed in "PFD and P&ID".
ST matches ISA88 and EN60848 standards
ISA88 defines basic structures for batch control programming - equipment module, control module, mode, state, step, and transition. It gives clear instructions on how the puzzle of the plant may be assembled from these parts. Remarkably, ISA88 uses the OOD style for describing the content.
Structures simplify PLC variable tagging - a critical task in PLC programming dealing with thousands of variables. The ISA88 way of tagging is tied to structures. For example, FZ.MM01.UE01.PO2 maps hierarchy where process module PO contains equipment module UE pointing to process cell MM.
EN60848 details the sequence control programming strategy. It is rooted in structures and program execution modules - the ST backbone