Representative End User Clients
Representative Automation Clients
Representative Software Clients
Overview
There’s a dilemma for process industries as they struggle to choose between best-in-class products versus integrated solutions 
from a single supplier. For distributed control systems (DCS), owner-operators across the process industries have chosen integrated, single-supplier solutions.
While a process plant may have DCSs installed from multiple suppliers, these do not interoperate at the control level for (historically) a good reason. Plant safety and reliability depend on the DCS operating in a deterministic and guaranteed manner.
Far greater control-level interoperability is one possible outcome of a recent ExxonMobil initiative. In January 2016, ExxonMobil announced a contract with Lockheed Martin to architect and develop a proof-of-concept for a highly open process automation system. This proof-of-concept system will be developed during 2016. The advent of this program raises a number of new questions about the future of process automation.
The DCS Installed Base Keeps Growing Older
For more than a decade, ARC Advisory Group has noted that many process automation systems are very old and reaching the end of their expected life. During that time, the age of the DCS installed base has probably grown older, not younger. Many systems installed in the 1990s and even the 1980s are still in service, though most owners of the oldest systems have plans to replace them. The fundamental reasons why these systems operate for so long is that owner-operators expect that replacing them would require a large investment that would not necessarily deliver significant business value or operational improvements. They see a DCS replacement project as a move to a newer version of the same DCS paradigm. The primary benefit of system replacement is simply that the new system will have many more years of vendor support. Thus many DCS replacement project decisions hinge on the availability of vendor support for legacy products, making this factor critical in purchase decisions and also making it a chronic point of friction between DCS suppliers and their installed base of customers.
ExxonMobil’s Viewpoint
At the 2015 ARC Industry Forum, automation leaders from ExxonMobil explained their pain points with the present state of DCS technology and articulated a vision of a much different future DCS in which information technology (IT) saturates the DCS products, such that many DCS operating and maintenance (O&M) practices would closely resemble practices of IT.
ExxonMobil articulated four major areas the company feels are underserved by today’s DCS products:
Closed architecture – There is no question that in the past a fully proprietary architecture was required to deliver DCS controllers with acceptable reliability. However, in today’s high technology environment end users question its value. Due to Moore’s Law, the price of compute power, storage, and network communication has dropped by a factor of roughly 100,000 during the 25 year life of many DCS installations and this trend continues. Internet services hosted in large data centers now exhibit very high reliability. Could such high-reliability technology be effectively scaled down to the level of a process unit control system? ExxonMobil believes this question merits a solidly researched answer.
Fixed physical hierarchy – While manufacturing automation is modeled as a hierarchy, DCS usually implements a fixed hierarchical network, with one or more I/O networks dedicated to a single controller that performs some subset of control for a process unit. End users want to maintain the hierarchical model, but do not want the model enforced at the physical level. They would prefer a flat and virtualized I/O network in which sensor information is a resource that could be directly shared as widely as desired. Maintaining the fixed I/O-to-controller relationship makes incremental additions complex, limits flexibility, and makes system expansion more costly and complex than would a flat and virtualized I/O network model. The end result of a fixed physical hierarchy is an automation system that remains static and does not evolve.
Lack of independent software – The market for third-party software (by independent software vendors or ISVs) running on DCS environments is quite limited. DCS controller platforms are not available to ISVs at any level. ISVs must invest a great deal to develop, integrate, test, and support product variations for each DCS platform. This makes the commercial DCS market unattractive for all but the highest value products, such as advanced process control (APC) and data historians.
Cyber security – It is difficult or impossible for end users to assess (or even monitor) the security of DCS servers or embedded systems such as DCS controllers. Yet these systems are a high-value target for the growing cyber threat from what are euphemistically called “state actors.” The long controller lifecycle, difficult patching process, and defensive extrinsic nature of many cyber remedies (for example dedicated firewall appliances and application whitelisting) make end users anxious and understandably so.
High complexity – DCS O&M tasks require a very wide variety of specialized skills that are not widely known, practiced, or even supported. These skill sets are entirely orthogonal to the deep knowledge of the production process that end users want to infuse into their technical workforce. Rather, these skills often involve use of archaic configuration software tools. For example, more than one ARC end user client has run Alpha/VMS emulation software on a new server farm so that they can still use a control configuration software tool developed in the 1980s; one for which the control configuration process has not improved in decades. In many ways these support difficulties result from a multiplicity of software tools, each supporting a narrow domain of functionality. Again this situation results from static DCS systems that cannot easily be changed incrementally.
Selecting Best-in-Class DCS May Become an Option
The question of “single source” versus “best in class” for DCS may soon have a new answer. The current dominance of proprietary systems may be supplanted by a movement toward open automation. In the open automation strategy, more components, applications, and suppliers will be able to “plug-and-play” within a platform that supports secure openness. The contract that ExxonMobil recently awarded to Lockheed Martin represents an important opportunity for the industry to move in this direction.
An Aerospace-Like Program Organization
This contract is unlike any ARC has seen in the automation industry. It more closely resembles procurement in the aerospace and defense (A&D) industries (see figure). Lockheed Martin takes the role of system integrator. In this role, the firm leads in defining system requirements for both hardware and software. The advantage of this, in ExxonMobil’s view, is that its system integrator will be more focused on detailed requirements and more neutral with respect to hardware and software suppliers.
Also notable are the compliance and testing activities, with a commercial consortium determining software standards compliance. For the ExxonMobil contract, this activity will be modeled on the FACE Consortium (Future Airborne Capability Environment). FACE is a real-time system interoperability initiative for avionics systems that has been used in both defense and commercial aerospace. FACE is managed by The Open Group.
Important steps following the proof-of-concept include having the resulting system architecture adopted by multiple owner-operators. ExxonMobil has stated clearly that its initiative wants to attract other firms as well, and is absolutely not intended to become an architecture used only by ExxonMobil. For this to happen, other owner-operators have to voluntarily adopt these standards and structures for their internal use.
ExxonMobil’s commitment will move this initiative forward to some degree. If other operating companies across the process industries also eventually get behind this initiative, it offers greater promise.
ARC to Research Questions Raised by the Initiative
New technologies such as cloud computing, virtualization, high-capacity networks, and the Industrial IoT make aspects of this initiative easier to achieve. Today this program is in its infancy. While Lockheed Martin has nurtured many such programs in the past, at this early stage there are (understandably) many unanswered questions. Many of the technical questions should be answered during the next year or so. It may take several years for the answers to business-related questions to take shape. These questions will become an important part of ARC’s research agenda in automation. ARC’s initial list of 20 questions relate to business model, standardization, hardware, software and services:
Business Model Questions
1) Business Case - How should process manufacturing end users compare the benefits and costs of such a new architecture versus today’s DCS?
2) Service Delivery - DCS has become mainly a service business. Project services, commissioning, lifecycle support, and remote operational services represent major fractions of supplier revenue. What will be the service requirements for these new products be and who should end users expect to provide these services effectively?
3) Expected Life - In the new architecture, what are the most likely drivers that would cause end users to adopt a more rapid control system/component refresh?
4) Value Chain - How does the system integrator measure the costs and value of specific requirements when choosing them? What is the role of suppliers and subsystem integrators in defining system requirements?
5) System Integration - What will be the role of the system integrator during the operating life of the system?
6) Impact of Standardization - How has greater standardization impacted the business of avionics suppliers and what is likely to happen if a similar development occurs in the process automation business?
Standardization Questions
7) Technology Maturity - Control system representation using IEC 61499 seems central to this vision. Today, only a handful of industrial control software products implement IEC 61499. How mature is this technology today? What practices will maximize portability of end user control configurations?
8) Phasing – This initiative includes many work areas. There are new I/O devices, controllers, servers, and software. How long will this development take? If the initiative will be accomplished in several phases, what will they consist of?
9) Compliance Certification - What is the process for certifying compliance with the standards and/or reference architecture for this initiative?
10) Versioning - How is versioning of the architecture/standards decided upon and managed and what are the implications for interoperability?
Hardware Questions
11) Migration - Any system update or replacement program requires both a migration plan and periods of operation using both the new and the legacy systems. How will this be handled?
12) Hardware Form Factors - Avionics hardware, which must fit in a cockpit, may demand extensive hardware standardization. But what level of hardware standardization is optimal for automation systems that will be installed in a rack room? Is a greater level of standardization required for field I/O systems?
13) Field Devices - Field device management technology is converging albeit slowly. All existing device management software tools will soon support FDI device packages, if they don’t already. How and when will these software tools (or new ones) manage field devices on the new systems?
Software Questions
14) Incorporating Existing Software - Many plants now use a number of applications from independent software vendors (ISVs) who in turn build their products out of software components, some of which they obtain from their suppliers/partners. How will an ISV software supply chain be verified and certified for this initiative?
15) HMIs - Many end users would be happy to temporarily move their existing HMI software to a new system. Is this feasible and what is required?
16) Intellectual Property – IP is an important asset for all suppliers, especially software suppliers. How will supplier IP rights be cared for under this new structure?
Services Questions
17) Project Services - Designing, installing, and commissioning these new systems is going to require a variety of skill sets, including deep process knowledge, systems engineering, and expertise in both legacy and new software tools. How will these projects be staffed?
18) Training - What skill sets will end users need to operate and manage these systems effectively?
19) Testing – Today, system-level testing is contracted between the end user and the DCS supplier. In the new structure what organizations can serve as independent testers?
20) Long-Term Support – Owner-operators expect existing DCS hardware products to come with 15 to 20 years of vendor support. They also are accustomed to ample vendor notification and gradual support reductions for old products. Should they be willing to accept different support policies for these new products? If so, how will they be different and why?
Recommendations
ARC recommends these actions for owner-operators:
- Re-assess your process automation system strategies and factor this new initiative into your assessment.
- Consider your own participation. The initiative is designed to permit input and eventual participation by multiple end user firms.
- Discuss this initiative with your preferred automation suppliers.
If you would like to buy this report or obtain information about how to become a client, please Contact Us
Keywords: Best-in-Class, Best-of-Breed, DCS, ExxonMobil, Lockheed Martin, Open Automation, ARC Advisory Group.