The Wikibook of

Embedded Control Systems Design

Broadly speaking there are two fundamentally different types of control systems:

Process control occurs typically in the chemical or food processing industry, oil and gas refineries, etc. These kind of installations have as components devices such as valves, temperature sensors, flow rate sensors, etc., and need to control the continuous flow of material through a large set of subsequent operations.
System control deals with the appropriate functioning of (semi-)autonomous devices, i.e., making sure that it performs the expected set of actions at the appropriate times. This involves switching between various control actions, decision making under uncertainty, etc.

Another major difference between process and system control is the large scale at which the former is implemented.

Process control

In general, looking at process control there will be multiple sensors, actuators and controllers distributed over a sometimes very large area. Such a system always has a lot of distributed hardware.

Despite this distributed nature, it is necessary to have a central control to oversee, manage and monitor everything at a distance. This does not how ever mean to ‘control’ everything. Every slave will mostly have its own processing capabilities to control its immediate surroundings.

To use a metaphor: it can be seen as an army general and subordinate platoons. The general (central control) needs to know what is going on with each platoon in the battle field to make upper level strategic decisions and give orders. While each platoon (slaves) decides for itself how it will perform these orders and then report the result back to the general.

To bring it back into the engineering world. The central control will be used to monitor safety issues, functioning levels and set system levels and properties. This is also called the human-machine interface or HMI.

Each slave in the plant or factory will be controlling the temperature, flow rate or volume of a smaller section of the whole. These are individually independent and are able to function as a complete unit on its own.

The actual control happens locally, with the SCADA main controller collecting and interpreting all the data throughout the complete system. Also the main controller is used to change and set operating levels.

Connecting all these independent systems is where it starts to get tricky. Everything has to function in combination, and means that information needs to be inter exchanged: information from an upstream or down stream slave may be necessary for it to make proper controlling decisions.

There are many ways to implement such a distributed hardware-centralise controller system. One such an implementation is called SCADA.

Design considerations

During the design of a distributed hardware system, there are some designs considerations and decisions to be made that will have noticeable effects in the end product.

The four main aspects, although there are many others, to consider are: safety, cost, optimisation and robustness. In a design such as this, there is a definite link between these four, and changing one has an automatic effect on the rest. The designer is constantly faced by such trade-off decisions.

Main considerations

Safety: As with any system where humans are involved safety is of very high importance. In some situations more so that in others: a nuclear energy plant vs. a water bottling plant for instance.

With an increase in safety measures, there is also an increase of eventual implementation cost (extra shut valves, redundant controllers) and a decrease in robustness. Safety could also mean a better communication system to ensure that the correct data is transmitted between the central control and slaves, and between individual slaves.

Implementing multiple master stations running in parallel for in case onse should fail, linking to a single SCADA main terminal. Safety is, as control, also localised but not limited to being locally implemented. The main controller can and will have some safety control.

Robustness: It is wished for the system to keep functioning even with some interferences and non intentional events. Robustness means a decrease in safety.

The question then arises: Should small problems be allowed? Small issues can be corrected by the slaves themselves. If handled incorrectly, these small problems can lead to much bigger ones. Cascading failures of interconnected parts result from small problems not being correctly handled.

Cost: Eventually it is wished for the design to be implemented, therefore costs kept to a minimum for the system to be lucrative to the market. But with cutting costs, you have a decrease in safety and robustness.

Optimisation: With this design factor the goal is to have an increase in quality, and cost minimisation (minimal product or raw material waste). With optimisation again comes the decrease of robustness.

Thus, the most difficult part of such a design is finding the optimal balance between cost, robustness, optimisation and safety for each project.

Human influence/interface

Due to the nature of this kind of systems and an ever changing environment (different products to be manufactured, or a change in the product mixture) there needs to be human interaction with the system. Also it is necessary for a human to be able to tell at a glance if a problem exists, where and what kind of problem.

The importance of proper human-machine interaction was shown in the Three Mile Island accident. Incomplete and incorrect information is thought to be the eventual reason for an otherwise preventable accident.

This adds to the safety side of the design decisions, added redundancy, and then increase in cost. But from the Three Mile Island accident, the necessity of proper and timely system information can be seen.

Furthermore the human interface is an easily reachable tool for information or hardware that would otherwise be difficult to reach. It should also have an attention grabbing setup to be able to make a system assessment at a glance.

Interdependency

Although previously said that all the slaves can operate independently, in a major industrial system this is not the case for each and every part. Some are directly dependent on information from another slave.

For instance, if a valve is to control the flow rate into some container, it needs to know to shut off if the container gets full. It is therefore necessary to have a reliable inter-slave communication network.

This interdependency shifts some of the central systems responsibility to manage safety, to a more localised area.

Data handling

Because eventually all the independent systems have to work together to form the final product, some sort of data handling system is necessary. This is where the central control system comes into play and fulfils its main role.

Due to the fact that lots of the actual control and safety is managed by the slaves system, a SCADA installation deals mostly with a bottom-up data structure. The main controller does not need all the information that is available in the complete system.

The central controller can thus be seen as an information gathering unit. This data, other than the safety information, could be calculating trends and monitoring quality.

System control

Most of the examples in the rest of this Wikibook are system control applications.