Channels ▼

Embedded Systems

Designing for an Open Control Platform Using the Intel Atom Processor

Systems Architecture Considerations for Embedded PC-based Platforms versus Dedicated Hardware

In contrast to traditional PLCs, the next-generation industrial controllers based on embedded PC processors, which are sometimes also referred to as programmable automation controllers, handle multiple domains: not only logic, but motion, drives, and process control on a single platform. This brings key advantages including the ability to use a single development environment and also enables the use of open architectures for programming languages, and network interfaces.

  • Characteristics of industrial controllers with embedded PC processors:
  • Tight integration of controller hardware and software
  • Programmable to enable design control programs to support a process that "flows" across several machines or units
  • Operation on open, modular architectures that mirror industry applications, from machine layouts in factories to unit operation in process plants
  • Employment of de facto standards for network interfaces, languages, and protocols
  • Provision of efficient processing and I/O scanning

The key to realizing industrial control designs is to incorporate support for the many bus networks that exist in the factory environment. This takes into account the situation today in which machine builders, OEMs, systems integrators, and users have a plethora of fieldbus solutions they have to consider for use on their automation projects. These fieldbus solutions allow the common support of field measurement, control, status, and diagnostic information. For motion control and real-time tasks this information needs to be exchanged in a deterministic manner

Commonly accepted fieldbus protocols for industrial automation applications are summarized in Table 1.

Table 1: Fieldbus protocols (Source: Intel Corporation, 2009

The industrial automation community often refers to "real-time" when discussing capabilities of industrial automation systems. But what are the requirements for industrial real-time? It needs to be put into context as different applications have different real-time needs. The most stringent requirements for motion control involve cycle times of around 50 microseconds and permissive jitter (deviation from the desired cycle time) of around 10 microseconds. Special applications with requirements tighter than this must be handled with application-specific hardware; normal industrial field bus-based systems cannot handle those applications. Typical cycle times for position control lie in the 1 to 4 milliseconds range, but have very short jitter times, usually less than 20 microseconds. Pure PLC sequential logic usually does not require less than 10 milliseconds cycle times and jitter can be in milliseconds range. Communication with higher level computers will be in the seconds range.

Architecturally embedded PC industrial control systems can be split into the following subsystems:

  • physical I/O modules
  • fieldbus network
  • interface card
  • OPC client/server for connecting the interface card and the soft PLC
  • the soft PLC package
  • OPC client/server between the SoftPLC and the HMI
  • the HMI

The key to unlocking the power of these new industrial controllers is the software. Software must provide the stability and reliability of the real-time OS to handle IO and system timing, execution priorities, and to enable multi-loop execution. The software must also offer a breadth of control and analysis functions. This should include typical control functions such as digital logic and PID, and less common algorithms such as fuzzy logic and the capability to run model-based control. The software must also provide the analysis algorithms for machine vision and motion control, the capability to log data, and the network communications support to connect into back-end IT office systems, and to other systems on the factory floor.

In an embedded PC-based industrial control solution there are several software components interacting for determining the final behavior.

The Soft PLC

One of the core software components for the new class of controllers based on embedded PC technology is a soft PLC. A soft PLC is a runtime environment used for simulation of a PLC in an embedded PC. Using the soft PLC, part of the CPU is reserved for simulation of the PLC system for controlling a machine and the other part is designated to the operating system. The soft PLC operation is identical to normal PLC operation: it implements the control logic with the standard IEC 61131-3 programming syntax. It receives data from field devices, processes them through the logic implemented with an IEC 61131-3 compliant language, and at the end of the cycle it sends the outputs to the field devices and to the HMI.

Key to accepting the design concept for PC-based industrial controller is verification of the real-time performance of the soft PLC application. The sometimes random behavior of PCs cannot be accepted for applications of industrial control. The most important feature of a controller is not only to perform the task in a certain time slot, but also the ability to perform the cyclic tasks always with the same time.

OLE for Process Control

A key part of a PC-based system is the interface between the field devices and the soft PLC. Logically, the interface is between data transmitted by a fieldbus and a software tool running in the PC. This connection is obtained by means of an I/O interface that communicates with the fieldbus devices and transfers data to the PC by means of a software interface. One such interface is defined by the OPC Foundation: OLE for Process Control (OPC). This defines a set of standard interfaces based upon Microsoft OLE/COM technology. The application of the OPC standard interface makes possible interoperability between automation/control applications, field systems/devices and business/office applications, typically an OLE for Process Control (OPC) server. The OPC server guarantees a standard data format that can be accessed and used by every OPC client, like the soft PLC itself. The soft PLC acts as an OPC client for reading and writing the data received from the field through the interface card that integrates an OPC server.

The OPC client/server architecture is used not only for the interface between the field and the control layers, but also for the interface between the soft PLC and the HMI.

Considering the above described SW architecture, The data exchange between separate software packages plays a fundamental role in the PC-based solutions and cannot be neglected. Data conversion may become a task with longer time requirements that the control functions. A control system in PC environment is made of a set of cyclic processes, mainly the soft PLC and the OPC client/server cycles.

When analyzing the time behavior of a PC-based solution, it is mandatory to measure the regularity of each cycle time under different system conditions. In the overall system, we also have other processes that consume time, such as the fieldbus communication, the interface card conversion time, the I/O module response time.

Operating System Considerations

Different scenarios are possible for these types of systems based on the choice of operating system (OS).

The embedded PC could run a general purpose multitasking OS where several applications run in time sharing with the soft PLC sharing the same computational resources (CPU and memory). The OS guarantees the multitasking by setting the time scheduling of the running tasks. There are three different types of scheduling algorithms: timesharing, multi-programming, and real-time.

In a timesharing scheduler, a precise time slot is assigned to each running task. The task must abandon the CPU before the assigned time expiration either voluntarily (the operation has finished) or by the action of the OS (hardware interrupt). The time-sharing scheduler is designed to execute several processes simultaneously, or better in rapidly successive time slots. The CPU communicates with all the peripherals of the embedded PC via one or more internal buses. Several processes manage these buses and must be scheduled by the OS together with the soft PLC and the other applications. The time assignment to each process depends on its priority that can be only partially defined by the user. For this reason, it is not easy to determine which processes are served by the OS in a given time slot. In the default conditions all the processes have the same priority level. This means they have the same CPU time at their disposal. Therefore, a general purpose, multitasking OS is intrinsically not deterministic in running concurrent applications. The running time of a control application (like a soft PLC) cannot be guaranteed with these operating systems. This is a theoretical limit that cannot be overcome unless an RTOS is used.

The real-time operating system performances can be divided into two different categories according to the effects on the system of the missing of a deadline: hard real-time and soft real-time.

In a hard real-time behavior, a specific action must be performed at a given time that cannot be missed unless losing the performance. A RTOS for hard real-time applications operates at low level, with a close interaction with the hardware platform. These RTOSs are normally based on a priority driven preemptive scheduler that allocate a fixed bandwidth of the processor capacity to the real-time processes or threads.

For less critical applications (soft real-time) it is possible to use conventional PCs running a real-time extension of a general purpose multitasking OS. The real-time applications are scheduled by the real-time extension that guarantees an almost deterministic behavior. In such application, all the wanted real-time applications must run the real-time environment.

A further possibility is simply running the real-time applications in a non-RTOS verifying that the system performances are adequate for reaching the desired results. In other words, we can run the soft PLC in a normal Windows or Linux PC, accepting that the PC response is driven by a nondeterministic operating system, provided that the overall performances are anyway sufficient for ensuring the control functions effectiveness. Such an approach means that the PC environment is performing so well that the random variations of its throughput remains well within the acceptable limits for a given control application. This process is in progress for the soft PLCs that will run more and more in conventional PCs. For this reason, it is mandatory to define a benchmark for evaluating the performances of such PC-based systems. The benchmark should include:

  • The definition of the PC environment where the control applications run
  • The tools for measuring the time behavior of the system in terms of response time to events for interrupt based functions, and jitter for cyclic functions

Referencing requirements and concepts presented in this section, the hardware and software requirements are summarized in Figure 3.

Figure 3: Summary of rugged modular hardware

Related Reading

More Insights

Currently we allow the following HTML tags in comments:

Single tags

These tags can be used alone and don't need an ending tag.

<br> Defines a single line break

<hr> Defines a horizontal line

Matching tags

These require an ending tag - e.g. <i>italic text</i>

<a> Defines an anchor

<b> Defines bold text

<big> Defines big text

<blockquote> Defines a long quotation

<caption> Defines a table caption

<cite> Defines a citation

<code> Defines computer code text

<em> Defines emphasized text

<fieldset> Defines a border around elements in a form

<h1> This is heading 1

<h2> This is heading 2

<h3> This is heading 3

<h4> This is heading 4

<h5> This is heading 5

<h6> This is heading 6

<i> Defines italic text

<p> Defines a paragraph

<pre> Defines preformatted text

<q> Defines a short quotation

<samp> Defines sample computer code text

<small> Defines small text

<span> Defines a section in a document

<s> Defines strikethrough text

<strike> Defines strikethrough text

<strong> Defines strong text

<sub> Defines subscripted text

<sup> Defines superscripted text

<u> Defines underlined text

Dr. Dobb's encourages readers to engage in spirited, healthy debate, including taking us to task. However, Dr. Dobb's moderates all comments posted to our site, and reserves the right to modify or remove any content that it determines to be derogatory, offensive, inflammatory, vulgar, irrelevant/off-topic, racist or obvious marketing or spam. Dr. Dobb's further reserves the right to disable the profile of any commenter participating in said activities.

Disqus Tips To upload an avatar photo, first complete your Disqus profile. | View the list of supported HTML tags you can use to style comments. | Please read our commenting policy.