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