Before the controller architecture is presented, some terms should be explained.
The word 'system' is used for a engineering entity which is defined by the system's
Since boundaries can be chosen arbitrarily, the consequences are:
Any granularity is possible.
In this context a system is considered to be 'open', if the aforementioned system interfaces (internal and external)
So whenever the word 'open' is applied to 'system', it should be understood in the context of the above items as it refers to an interface. Only such open interfaces can be called standards, otherwise they are corporate proprietary technology or practices.
Nothing is open per se, but there might be a 'degree' of openness. Granularity plays a key role and will determine the 'degree' of openness: given a system with a number of subsystems, something like the product or the sum of the numbers of choices of components for each sub-system can be a measure for 'openness', the openness indicator.
Applying the above definition to industrial control and automation systems yields open control systems. On a large scale these definitions and applications can influence the entire control system, as well as system sub-components, such as the HMI or PLC, or even their sub-elements like CPU boards or protocols.
This architecture refers to a controller with its subsystems, in particular a PLC. Traditionally, such a controller can be sliced into functional layers as depicted in Figure 1 (dashed green lines will be open interfaces, red will be proprietary interfaces, and brown ones a mixture).
There are several layers which themselves may be composed of modules. Interfaces exist between the layers and the outside world, but these interfaces are not publicly accessible in most cases, and in some cases might be proprietary. Such a controller is modular, but not open. This type of controller is a monolithic component of a larger system. On a scale from 1 to 10 the degree of openness might be a '1', meaning that the user has no choices.
Separating Hardware from Software adds one internal interface into a controller, e.g. ISA/PCI busses and the instruction set of a general purpose CPU. Also separating the operating system from the run time system adds another interface. The result is something referred to as SoftPLC as depicted in Figure 2 (the dotted red line indicates an interface).
Figure 2.: Decomposition of a softPLC.
The resulting controller is a four component system allowing some flexibility in the choice of the hardware and operating systems, and also for the run time and programming environment. So the openness indicator increases considerably. But still, the system could be more modular with more truly open interfaces.
There is no necessity to cut the controller down to the transistor level, but separating in key functionalities could result in an open controller at a higher degree of openness. A first draft is depicted in Figure 3.
Figure 3.: Architecture of a controller.
The dotted green lines indicate open interfaces which are explained in more detail in the following sections. The architecture description proceeds from the bottom to the top layers of Figure 3.
On the hardware level, the bottom line #1 of Figure 3, consists of interfaces to the outside world of the controller, which include:
There are many devices on the market which offer such interfaces, like sensors and actuators for local I/O, remote I/O units or motion units such as drives. This collection of devices constitutes a broad basis the controller can rely on.
Hardware elements can be combined into a working system if they share an interface, which is true for both general purpose computers and PLCs. However, PC-based systems combine busses which are public standards (PCI and ISA), some bus controller, memory and general purpose CPUs whose instruction sets conform to published standards, too (i86, mk68, ppc or others). So these products which follow existing and available standards are considered to be open. Form-factors such as cPCI and PC104 do not really change the functional behavior, but only their appearance.
Concerning automation, an enormous variety of boards for local or remote I/O and motion control are available. Sites including http://www.pcisource.com/, http://www.picmg.org/ and http://www.pc104.com/ describe available components.
Both the busses used in a computer and the CPU instruction set will determine the interface to the operating system kernel and to drivers. Boards in such busses offer an API over registers so that they can be programmed to do useful work. The APIs are the relevant part for the controller architecture, like line #2 in Figure 3 illustrates.
Any operating system has usually something like a kernel, i.e. trusted system software, implementing resource management and abstraction, e.g. some low level functions, handling interrupts etc. A driver can implement such functions for a special hardware. In UNIX systems those special functions are entered in a file operations structure and then registered to the kernel. To use this functionality from user space programs, system calls are used which are typical for an operating system (line #3 in Figure 3). This interface, which is vendor independent, is essential for an open architecture. POSIX (http://standards.ieee.org/regauth/posix/ or http://www.pasc.org/) or the Single UNIX specification, http://www.opengroup.org/, are strong candidates.
When writing some drivers for multi-function PCI and ISA local I/O boards (i.e. analog in and out, digital in and out, e.g. boards like ICPDAS pci1800/pci1802, ICPDAS pioda4/pioda8/pioda16, ICPDAS piod48, Advantech a626, Advantech acl6126, Advantech pcl818, BMC 1000, Kolter 16/4), it can be found that most boards are very similar. Therefore, a common API should be defined. But where the application starts and where it stops, the hardware abstraction ends is difficult to discern. Drawing such a line is not easy. A possible approach is that the API level should only abstract board similarities but should not include functions which are application or even board specific. For the Linux kernel, rtdaq.tgz offers some kernel level functions written in the C programming language. These functions are sufficient for many real time and control applications.
For automation, boards and their drivers can be separated into three classes: local I/O, remote I/O and motion. To make implement vendor-independence on the driver level, a common model has to be found. One cannot rely on vendors drivers, as in most cases, source code is not provided, and so one cannot know whether the drivers are well behaved. Drivers from different companies offer different APIs, a reason why SoftPLC implementation is not that easy. For this reason a generic interface for drivers is proposed, tailored for their use in control. It should be a canonical set of functions, or an Application Interface which abstracts board similarities to a higher level of generalization.
3.3.1. local I/O driver model
Multi function DAQ boards offer fancy functionality, like scanning a set of channels at a certain speed up to the MHz range and put the values into FIFOs or transfer it over DMA. For control, however, you may want to get the values, do some control work and then output results. For this reason, kernel level functions are proposed which offer an interface to other kernel modules in a generic way, see board.h.An implementation of the first driver will follow soon.
3.3.2. remote I/O driver model
No implementation, but something similar as local I/O.
3.3.3. motion driver model
No implementation, but something similar as local I/O.
Driver libs translate the driver API from user space into system calls. This API should offer the same driver API in user space as it offers the kernel module in kernel space. For an example, see board.h. By doing so, a symmetric implementation of the driver is the result. An application could be programmed in user or kernel space using the same API.
This lib could also fork processes or threads for a device to periodically update a local copy of values.
Given that all I/O boards offer a canonical set of functions, the function of this lib is to maintain the entire set of I/O points. This library could be a linked list of points with information on board, status, values, and owner and other information in it. An API has to be worked out implementing functions like initialize, configure, read, write, synchronize, and the shutdown of I/O.
This is the part particular to control, the soft control part.
3.6.1. run time
This might be a logic engine, an executable acting on the I/O, or a byte code interpreter with byte code libs which interprets PLC code represented by some byte code (should be close to the IEC-61131-3 IL code). The interface could be something like an object definition (like ELF) with context information (object type) and commands in XML (this is just a thought).
A service which is synchronized with run time to the I/O lib. The service configures the I/O lib. The interface could be something like XML wrapped command, XML-RPC (this is just a thought).
Apparently some communication service has to listen on some port. Possible examples of UNIX daemons include htppd, tcp.d, and stty.d as servers. They have to fork run time system?, TCP/IP ?
This is the mirror to another component in the control system.
3.8.1 on line service and debugging
Takes compiler output, wraps information and commands, then ships over to target.
3.8.2 HMI or other
Just something taking informations through the interface of the "controller". No idea yet.
Compiler eats IL, context info and comments in XML, Makefile? Compiled object in format for which a lib is available on the target. The type of code is shipped over in the context information, such that the run time knows which engine to fork.
Graphical editor, ASCII editor ... IEC 61131-3 compliant. All programs have to be portable over this interface. XML wrapped PLC code in ST, IL, etc.