With few exceptions, control architecture has changed little over the past 40 years. However, advances in processing power, network technologies and software, will enable greater value for end users in the near future by changing the way controllers are implemented and interface to the field. ARC Advisory Group believes that these new controller architectures, which support our evolving collaborative process automation system (CPAS) vision, will improve simplicity, flexibility and efficiency.
Tightly coupled
With few exceptions, the basic architecture of a process (DCS) or discrete (PLC) control system consists of a set of I/O cards logically connected or assigned to a single control processor housed in dedicated hardware. This has been the general state of affairs since the first digital controllers were introduced over 40 years ago. Initial control system incarnations consisted of a card rack in which a local real-time control processor communicated to a set of I/O directly coupled to the same backplane.
As network technologies advanced, systems began to employ architectures in which a single control processor might support several card racks of I/O connected via proprietary, deterministic protocols. While still widely employed today, this predominant architectural approach is effective, but potentially wasteful.
Wasted potential
Generally speaking, every control processor is limited by three main parameters: the ability of the controller to handle I/O scans, diagnostics, and program execution in a timely fashion; the capacity to store code, I/O maps, and program variables; and the ability to handle the data transfer with the I/O and the level 2 network. This often results in wasted potential.
An application may reach the limit of the number of supported I/O for a single controller, but the controller may be able to support much more logic processing than the application requires. This means that the user has probably paid for processing that is either not required or unable to be properly used. Alternatively, logic-intensive applications, like some batch applications, reduce the amount of I/O the control processor can support. If the application requires high availability, the extra hardware and software required amplifies the waste.
For remote I/O applications, the user may be required to have multiple racks of co-located I/O assigned to different control processors. Alternatively, the user might choose to have all the field data pass through one processor and pass those values (or other relevant field data) to another controller with available processing capability.
Controller and I/O interfacing
Unlike most current architectures, a new approach would have a common I/O network shared by all controllers and all field devices. This network would support a deterministic communication standard and allow any controller to address any field device. It would even allow multiple controllers and/or other applications to access the same data without intermediaries and permit peer-to-peer communications between field devices. The I/O network would support both traditional (analog) and intelligent (digital) field devices. Because such a network would support peer-to-peer communications, some applications would be implemented at the field level.
Through this decoupling of previously dedicated I/O and controllers, end users would be able to buy the appropriate amount of I/O for each physical area without the constraints of the controllers. Controllers would less likely have unused processing and/or unused I/O connectivity. Details that would need to be worked out include the number of network connections an I/O device or a controller could handle, network efficiencies, speed impediments, and how to migrate existing users. However, ARC does not believe that these are insurmountable challenges.
Control in the ‘Cloud’
The Cloud, as used in the IT world, is not deterministic enough, available enough, or fast enough for most level 2 control applications; though it may be in the future. However, the decoupled architecture would enable a ‘local cloud’ or virtualised control platform much like today’s virtualised IT environments. This architecture could meet the requirements of determinism, availability and speed of response.
In this scenario, ARC envisions a set of hardware hosting multiple real-time control instances or hosting a single control entity that grows with the application.
The hardware would run a real-time virtualisation platform similar to the corresponding IT equivalent, and could be dispersed throughout the facility. This platform would ensure real-time communications between the virtualised controller instance(s), and between the controller instance(s) and the I/O. In a manner similar to IT virtualisation, the platform would also handle load balancing and failure mode recovery.
The hosted controller instance(s) would run in a real-time manner similar to current controller implementations, with each instance running similar execution environments to today’s equivalents. From a user standpoint, the interface to these controller interfaces could be nearly identical. Because of the purely software nature of the controllers, they could be licensed just like any other virtualised software platform, ‘spun-up’ nearly as quickly, and the virtualised instances could be managed with tools similar to the current IT virtualisation tools.
For more information contact Paul Miller, ARC Advisory Group, +1 781 471 1141, pmiller@arcweb.com, www.arcweb.com
© Technews Publishing (Pty) Ltd | All Rights Reserved
printer friendly version