Software programs contain instructions that execute specific tasks. Using the right programming model saves time debugging, improves code readability, and reduces costs. Designers can choose from several models: ladder, sequential-function charts, data flow, event, text-based, or integral solvers. While any model can potentially program all tasks in an application, the one most suited to a particular type of system will optimize metrics and save development time.
A system's key performance metrics influence which programming model to employ. For example, when optimizing a system's reaction time to faults, designers should select an event-based programming model. An automated inspection system analyzing images should employ a model offering signal processing. And, machines taking high-speed measurements in real-time benefit from a data flow model. An appropriate selection depends on understanding the types available, matching application requirements to possible models, and investigating development platforms.
Consider all options
The first step in choosing a programming model is recognizing the differences among each. One difference is whether the model is imperative or declarative. Imperative programming models contain a sequence of commands and are either sequential or state-based. Examples of imperative models are C/C++, Java, Visual Basic, ladder logic, sequential-function charts, block diagrams, instruction lists, and structured text. Commands include C functions such as add (myint1, myint2) or initprocess (mypara1, mypara2).
As their name implies, sequential commands execute one after another without any transitional condition. State-based commands, on the other hand, carry out actions in response to explicit instructions. These commands flow from one set (state) to the next after passing through a transitional condition. An example is graphical state charts.
Unlike imperative, declarative programming models consist of constructs that declare relationships between components sharing data. LabVIEW, for instance, is a data flow language in which wires send data to a function block, which executes when all data is available on the input terminals. SCADE, by contrast, executes commands on a time-triggered basis and calculates a new value for every wire that connects blocks in a program. Data, time, or events can drive actions in declarative models.
In process networks, a programming language can implement continuous-time semantics and solve integral equations to optimize system simulation and control design applications. Process networks are often considered a superset of dataflow.
It is also possible to pass just one token of data across each wire. This is done in homogenous, dynamically scheduled programming models, so portions of a program can execute based on input data. Such models help acquire, analyze, and present data in real-time settings.
In synchronous, statically scheduled flow, many predefined tokens of data pass across a wire, resulting in a program that runs within fixed memory constraints. Examples include Boolean and integer-controlled data flow.
Time flow, a second declarative programming model, is considered synchronous because it controls reactive physical systems and executes when divided into discrete instants. At each instant, all data points in the program contain a calculated value. Synchronous programming models such as SCADE and Signal can be applied in various safety-critical applications.
A third declarative programming model is events, which falls under the category of a discrete language. With this model, designers can exchange events (data values with a timestamp) between program components and process them chronologically based on their timestamp. Often found in hardware design, discrete-event languages model circuits, control network traffic, and queue systems.
Matching applications with programs
After considering programming models available, it's time to match an application's requirements to the most appropriate model. Suppose an automation project with four heat exchangers must cool air passing through a duct and rely on a control algorithm to regulate the amount of water passing through each heat exchanger. An operator needs to switch between algorithms, regulate water flow, and monitor vibration on the pumps for predictive maintenance.
This application consists of five requirements. Recall that one programming model can probably address all requirements, but that matching each requirement to a suitable model may improve operation and save programming and debugging time. Here are the requirements:
-
Closed loop analog control
Closed loop analog control with multiple control algorithms
-
Digital and analog measurements
-
Digital and analog measurements
Analysis for predictive maintenance
-
Analysis
Discrete logic for turning pumps on and off
-
Discrete logic
Operator interface and real-time reporting
Closed loop analog control
Process networks can implement a control algorithm that regulates water flow through the heat exchangers. A well-designed algorithm can decrease settling time and reduce downtime during changeovers. These algorithms may involve solving integral equations in real-time, and therefore, programming models that follow continuous or discrete-time semantics are most suitable.
Control design tools model and simulate a physical system, transfer algorithms into real-time processing targets for interfacing with I/O, and deploy embedded code into production. Simulation loops can create algorithms in the LaPlace, state space, discrete time, or frequency domains and execute them using integral solvers. With this approach, designers employ one development environment when producing algorithms and performing I/O.
Digital and analog measurements
Measurements from thermocouples, flowmeters, pressure transducers, and load cells typically involve analog signals, which entail I/O operations such as buffering and scaling. While temperature measurements don't need high sampling rates, acquiring data from accelerometers for vibration monitoring does require high-speed analog I/O. For such measurements in the air-cooling application, data flow programming with integrated I/O is most applicable.
Analysis
Programming models that analyze and predict maintenance must execute all functions in real-time while gathering data. For predictive maintenance in the air-cooling example, development environments offering tight I/O integration and libraries with order and spectrum analysis are recommended. Data flow models suit applications involving acquisition, signal processing, and decision-making based on processed data.
Discrete logic
Discrete logic operations assist with sensing and turning valves, pumps, proximity switches, and light curtains. Programming models such as ladder logic can execute logic parameters at greater than millisecond intervals. When loops must run at precise intervals, a timed sequence structure can be implemented.
Operator interface, real-time reporting
Typically, IEC 61131-3-based development environments require a different programming model for human-machine-interface (HMI). However, some imperative and declarative languages, such as Visual Basic and LabVIEW, provide integrated HMI capability.
Development platforms
Besides matching an application's requirements to an appropriate programming model, designers must also consider a software development platform. Important considerations are handling I/O, setting up scheduling and synchronization, and available hardware targets.
I/O and program logic are tightly coupled functions in many development environments relying on text-based and data flow programming models. Declarative programming works best for analog I/O operations because parameters are defined as relationships among components. This improves buffering, simultaneous sampling, anti-aliasing, scaling, and triggering.
In models such as ladder logic, function-block diagrams, structured text, or sequential-function charts, I/O and program logic are decoupled — meaning functions for I/O do not exist in the main program. Instead, variables, or tags, are used to link to I/O, which is configured separately. On a PLC, for instance, a scanner reads physical inputs and stores them in a memory area called the process image. The scanner periodically reads these tag values and writes them to physical outputs.
Each program must share its given processor bandwidth with simultaneous tasks. This is similar to a multitasking operating system that allocates CPU time to each process running on the system. Some examples are user-interface updates, multiple “while” loops, and I/O processing.
In text-based models, programmers schedule tasks by using constructs for multithreads. With some models, constructs inherently support multithreaded programming. For example, the Thread Class and Runnable Interface in Java use monitors to support multiple threads, priorities, and synchronization. Multiple “while” loops in LabVIEW generate many threads to execute commands in each loop.
While ladder logic, function-block diagrams, structured text, and sequential-function charts have no concept of multithreading, PLCs offer built-in support for it. On a PLC, task scheduling is defined outside of a control program so designers can modify control-loop timing at the system level, rather than accessing individual programs.
Hardware is also an important choice, as each programming model executes differently on each target. Designers can choose from PLCs, programmable automation controllers (PAC), microprocessors, digital signal processors (DSP), and field programmable gate array (FPGA) targets.
Models such as ladder logic, function-block diagrams, and sequence structures performing many digital I/O, simple arithmetic, and comparison logic should run on PLCs or PACs. Text-based models, event structures, and data flow models that execute processor intensive calculations run best on industrial PCs and single-board computers. Sequential function charts and state diagrams are best targeted on PLCs and PACs. Process networks work well when programming DSPs. Finally, discrete event-based languages such as VHDL and Verilog are traditionally used when programming FPGAs.
For more information, contact National Instruments at (800) 531-5066, visit www.ni.com, or email the editor at [email protected].