InTech Home1 August 2006
Open should mean open
Yes, you can model Linux to work in an automation environment
By Edson Watanabe and José Manoel Fernandes
Automation system users need the latest interoperable architectures that provide high performance and highly available controls. This much is known. The systems must be highly flexible and able to control the entire plant, transfer information, and provide places to store history and information. In addition, users want greater flexibility to modify without shutting down and the ability to network easily to existing and future control components.
In the past, a distributed control system (DCS) and programmable logic controllers (PLC) would have been the only means to apply those types of control applications. You could network these older systems together, and then an engineer would have to manually route each point, which costs a user time and money. On top of all that, a huge amount of time would be necessary to install and set up special cables and hardware to connect the systems to work as one.
But the days of DCSs and PLCs being the only game in town are going away. In just about any industry, if a manufacturer uses open networks like Linux, fieldbuses and protocols can provide a common functionality that will provide an easy transportable solution to any suppliers’ product. The biggest advantage is it gives the necessities of the industry but limits the cost to users. Consequently, standardized networks reduce the installation time, training, and global acceptance of the technology, which can only promote installation of new networks and help in reducing maintenance and support costs.
Bus technology
|
Fast Forward
|
A fieldbus bus network is a digital serial two-way communication bus that connects control and field devices. Fieldbus is an open standard bus that allows devices of different manufacturers to integrate in one system. The devices and data can communicate by using standardized messages within the fieldbus protocol.
Fieldbus devices have microprocessor-based communications capabilities that allow process variables to carry a data quality signal, which can recognize errors faster. As a result, plant operators can get quick notification of abnormal conditions or the system can send out reminders for preventive maintenance. This can provide a more efficient plant and allow operations to make better decisions. One of the main aspects in the definition of fieldbus is interoperability. A user can replace one fieldbus device with a similar device with added functionality from a different supplier on the same fieldbus network while maintaining specified operations. Fieldbus reduces complexity of the project and provides the needed versatility in most projects. Also, fieldbus provides easy installation and reduces physical maintenance of the system, which provides cost benefits. Overall, there is quite a list of open protocols to choose from, including: CAN, Fieldbus Foundation, CEBus, WorldFIP, BitBus, ProfiBUS, Lonworks, BACNet, X10, EIB, and CAB.
Division of control
As the control systems become more complex, with a large amount of variables, applications, and interlocks, it can become expensive, complex, and even cause unacceptable system performance. When the system becomes too unwieldy, one consideration would be to divide it into smaller parts the user can individually control. This method of partitioning the control becomes an attractive solution since it allows for simple development, and it is easier to maintain, operate, and administrate with a more predictable performance. The DCS, which has been in action since the 1970s, provides a data concentrator console connected to automation controllers that connect with remote I/O modules. These remote I/O modules connect to devices in the field and also connect to the controller with a proprietary communication network still in use today. With the concept of fieldbus in the market, the distributed control concept can work in conjunction with intelligent devices. These fieldbus devices with processing capability allow the devices in the fieldbus network to talk to one another, apply system control, and also transfer data to an operator human machine interface (HMI) console. By using these fieldbus devices, the control moves away from the controller and into the actual field devices, which is even more distributed.
One example of an open network protocol is the controller area network (CAN). Robert Bosch created CAN in 1986 for use in the automobile industry. The idea was to simplify the complex wiring systems in vehicles. While simplifying wiring systems, multiple microcontrollers must coordinate to manage the engine and control the braking systems and the suspension systems, among others. The CAN is a synchronous serial communications protocol that supports distributed real-time control that has the following features: a high level of security, a high speed of transmission rate, a great immunity to the electric interferences, and cost-effective data bus for multi-master and real-time applications. In addition to automotive applications, the CAN protocol is suitable as a general data bus for industrial process control applications. Most older connection techniques of point-to-point widely accepted in most industrial control systems do not provide easy sharing and multiplexing of data on a common bus like CAN.
The main idea behind CAN was to provide interoperability. The big advantage of defining an open architecture would be enabling the people to develop sub systems and later merge them together to form a commissionable system with little integration. The benefit of open architectures is the overall attention of diversified users focused on different application context, which can lead to a wider and deeper test bench.
Some of advantages that come into such analysis are:
-
Users of open systems are already testifying about the quality of such systems.
-
This technology lowers the costs associated to licensing the software and reduces the costs of the services and the maintainability of the end user.
Beyond interoperability, there are also other characteristics for an open operating system that brings usefulness in industrial automation systems:
-
Interoperability
-
Modularity
-
Scalability
-
Portability
Case in point: Linux
Linux/GNU, derived from Unix to run on personal computers, continues to grow (see related story on page 53). Linux provides features equivalent to the most up-to-date proprietary offerings of an operating system.
Among those features:
-
Memory management to provide virtual memory for processes running into user space
-
Real-time support for embedded and time-critical applications
-
Multi-processing and portable operating system interface threads
-
Inter-processing communications using files and/or pipe;
-
Several internal synchronization resources like semaphores, message queues, and shared memory
The system can go from very small deployment up to big servers gathering processors together. In the case of a CAN network, it will integrate the very end of it at the production ground up to the big PC that will configure the overall network.
Splitting a kernel
Embedded systems are those that have specific hardware and software designed to reach a specific purpose and, because of that, have some constraints regarding the time spent between when an input event triggers and the system output results show up.
An embedded device has a combination of hardware and software to perform a specific function and interacts continuously with the environment around it through sensors and actuators. The overall system for these types of devices must be sufficiently compact and efficient, implementing specific and dedicated resources to the hardware and in the layer of application.
Proprietary embedded systems simply cost more, and in most of the cases, they require fees to allow usage for each unit. The most recent Linux kernel can fit in several families of processors as well as different platforms. In order to have a Linux kernel running in a new platform, you could split the task into five different branches:
-
To mount a complete Cross Development Kit system that will build the complete target system into a different host system.
-
To define means by which the code gets loaded into the embedded system and get the processor control at the most privileged level.
-
To implement the architecture dependent functions, which means the central processor unit (CPU) and platform procedures.
-
To implement the coding for the hardware devices when the kernel source tree does not have that yet.
-
To test the overall system build.
The development work may take a few hundred man-hours or up to several thousands of them, depending on the pre-developed code that is available. Keep in mind, it is possible to choose hardware components for which there is code available already in the literature, and this is the exact reason companies provide the drivers for such open operating systems. The size of a complete software build for a CPU family may span a program size of few kilobytes up to gigabytes, but for an embedded system with no human interface, it may build into 1 megabyte of program memory, 4 megabytes of volatile memory, and 16 kilobytes of nonvolatile memory to hold the configuration.
The minimal hardware support to host a Linux kernel would be the CPU; non volatile memory (normally Flash memory + NVRAM); volatile memory (Random Access Memory or RAM); clocks for system and communication; console port; and communication ports.
Among the main functionalities that must port to the target platform/ processor are: the interrupt controller; pre-emptive kernel functions; virtual memory in systems with Memory Management Unit; and threads functions, processes functions, semaphores, atomic operations, and queue management.
A new configuration
One way to go is to make a CAN network reachable into a Linux network that then can work in an industrial automation setting. The Linux Electronic Control Unit (LECU) is an electronic device responsible for executing a specific control, made up basically of digital and analog input/output interfaces. To increase its performance, flexibility, and connectivity and its actuation in the network, the device embeds into the Linux operating system. Control applications will run in the device while scanning practically all points simultaneously within the plant network, improving significantly the performance time of the control algorithms. This module has two configurations—master and slave—the first type to build in a total distributed network, and the second to build in a traditional network connecting to the PLC equipment. The Internet Protocol (IP) is the core for Linux as messaging system, and every protocol inside Linux should merge into an IP stack in order to have their packets routed and forwarded through the Linux network as well as be reached through the socket layer. In order to have CAN integrating into this network, it must define an address family and protocol family according (AF_CAN and PF_CAN) as the key way of integrating CAN into Linux. As a high level layer, we plan to implement a top- level “cand” (CAN daemon) that will create a CAN socket of AF_CAN family in order to control the CAN connections through the CAN network. To simplify such development, the whole CAN network will be a single whole subnet inside the Linux kernel, avoiding further splitting of such network into subnets. Such function will run into the LECU Master that will also implement Network Address Translation/ Masquerading to provide gateway services between the general IP networks with the LECU slave devices.
It will mean the LECU Master is a must into such network. The same daemon will manage the creation/ destruction of CAN multicast groups, gathering all the LECU slaves that interconnect and exchange data as needed. As the matter of low level, the idea is to implement the CAN link layer in order to glue the IP layer of Linux proceeding the appropriate Link Layer Interface.
LECU master
This control module embeds with the complete Linux operating system to offer multiple resources to the scan and control applications that will run in it. It is remotely managed for supervisory software responsible for information acquisition of each node located in the industrial network. The LECU supports multiprotocol CAN to change information packages between the LECU Slaves and Master and Transmission Control Protocol/Internet Protocol (TCP/IP) for communication with the supervisory software to connect through the Ethernet standard. A great advantage is its multitask monitoring speeding the scan of the monitored points and updating results at a much faster rate. The Master, even while monitoring all the slaves, has greater functionality to detect and correct the process better than most systems sold today.
The LECU slave control module embeds with the compact Linux operating system to offer the specific resources to the scan and control applications that will run in it to monitor and control all points located throughout the plant. It is managed by the LECU Master or a PLC connected through a DeviceNet interface for information acquisition of each node located in the industrial network. The LECU Slave gets support for multiprotocol interfaces, CAN to change information packages between the LECU slaves and Masters and or PLCs, and is supported with TCP/IP interface to connect with the remote system for configuration and maintenance being able to be connected through the Ethernet standard. This module consists of hardware and software that executes the reading of the inputs and information processing, and acts on the outputs. The advantage to this solution is the high speed scanning of its multitask monitoring.
A PLC with Linux
Keeping all the known features of the PLC industrial equipment, the porting of Linux operating system will be a plus to improve its capability to scan and act on the monitored points. Linux will give to the PLC all open system characteristics—interoperability, modularity, scalability, and portability—and will increase its performance in executing its tasks.
The first configuration presents a traditional dedicated industrial network with a central logic controller, a supervisory system, and intelligent devices—all these network elements ported with Linux operating system. The main characteristic in this configuration is the improvement offered by the open systems philosophy to some commercially available industrial equipment as a PLC and the facility to create and manage the system.
A second configuration deals with a new architecture based on open components where a user can run a management system based on the Linux environment with windows and menus to facilitate the navigation for the elements on the network, alarm monitoring, and report generation. The LECU Master communicates with the manager through TCP/IP protocol and the LECU Slave through the CAN protocol. This configuration provides many advantages; therefore it inherits all the properties of an open system as well as of the CAN fieldbus and of all Linux operating system network and functional characteristics.
Studies on existing process control systems show a trend toward a wide usage of open software standards. This move will provide advances of open software applications that already gained widespread adoption among domestic users, governments, and commerce and could gain additional traction throughout the automation industry. The great paradigm in the way of products distribution will be broken—before what was open and free were synonymous of low quality and without technical support will eventually change into high quality and acceptance.
About the authors
Edson Watanabe (ehwatanabe@uol. com.br) and José Manoel Fernandes (fernandez@ufpr.eletrica.br) are with the Federal University of Parana in Brazil.
|
Resources Linux www.Linux.org GNU Programmable Controllers, 4th Edition www.isa.org/plc |
