Enterprise Solutions in the World of Process Automation with FAST/TOOLS

Charlie Horevoorts¹ Neil Unwin¹

The requirements for Enterprise Automation Solutions are driving the needs for any- to-any 'collaboration' across different platforms, geographies and corporate networks. The ability for the underlying technology and network to allow any device or application to connect to others seamlessly, managed as a single system, from operations, engineering and maintenance point of view, is the objective. An integrated approach of applications and connected platforms results in a robust, secure, high quality experience reducing the engineering, maintenance and training costs considerably. This will assure far greater adoption and impact since in the end, it is all about the enterprise working more effectively and achieving better results.

1. Global SCADA Center, Yokogawa Europe B.V.

INTRODUCTION

For large scale geographically dispersed projects, there may be a hierarchy of individual Process Automation systems, which in turn are each responsible for a specific region, and are managed by a higher level system. Engineering of systems on this scale is a huge challenge, because each individual system has its own database and its own configuration.

In addition, the information obtained through a local automation system often has to be integrated into an enterprise information system, which is itself composed of many other subsystems. Engineering and maintenance of these systems is a complex and labor intensive task because, although the systems are interrelated, each has its own method of configuration based on different user interfaces and engineering principles. In practice, things must be duplicated and configured multiple times.

FAST/TOOLS provides a flexible, scalable architecture for Enterprise Automation Solutions, by supporting a high number of multi-level/multi-node configurations. It is possible to balance server functions over multiple machines, for example for data acquisition or for supporting many HMI clients. This feature lends itself very well to large scale infrastructure projects such as pipeline grids and wellhead management environments. Engineering is done in a single environment, from which the application objects & database can be deployed to the appropriate server levels.

PROCESS AUTOMATION LEVELS

Figure 1 Typical Enterprise Automation System

Nowadays process automation within a company is scattered across several autonomous systems. This is not an ideal situation from the maintenance and operational point of view. Therefore, companies tend to see the individual systems more and more as a single Enterprise Automation System. Increasingly companies are moving in this direction, and FAST/TOOLS provides innovation in this direction by deploying such Enterprise Automation Systems. In ISA-95 (1), the functional levels of an Enterprise Control System are defined. Note that the levels presented in this paper relate to a physical business model in which a company consists of a headquarters, regional offices and local offices. All these locations can contain systems which together form the Enterprise Automation System. This should not be confused with the automation levels defined in ISA-95, in which the logical information layers of a control system are defined. In Figure 1, a typical Enterprise Automation System is depicted. In the Enterprise Automation System, four levels are identified. Each level has its typical characteristics and usage.

Process level

The Process level contains DCS/SCADA/PLC systems or other automation control systems that directly control the process. Figure 1 shows a typical offshore well that is controlled by a CENTUM VP DCS system, and exchanges process information with the Area level. Another typical example shown in Figure 1 is a pipeline control system using various FAST/TOOLS systems along the pipeline. Typically, the Process level has its private network connected to the Area level. The wells and pipelines are controlled locally by Process Operators.

Area level

The Area level combines all processes within a graphical area to provide control over this area. It contains a FAST/ TOOLS system that is connected to all DCS or SCADA systems in the Process Level. A typical usage is to control the total amount of gas or oil production within the area, and to supply production KPIs. The area is controlled by Area Operators which, for example, can take over control of an offshore well during nighttime.

Business Unit level

The Business Unit level is typically responsible for all areas within the business unit. The Business Unit contains a FAST/TOOLS system that exchanges KPIs and other process data with the Area level via the Business Unit network, which may be isolated from Plant networks and the Corporate network using firewalls. At the Business Unit level, users require well data to optimize production of a well. They want to see detailed well information using the same process displays that the Well Operator uses to control the well. Of course, by authorization rules, they are not allowed to control the well directly, only to watch the current situation of the well.

Corporate level

At the Corporate level, all KPIs and other process data of all the Business Units come together. Here, the total production is monitored and controlled. KPIs are supplied to the financial systems of the corporation. Geologists use well data to optimize well production and to predict production capacity of the well. Incidental users want to see detailed information of a well using the same process displays that the Well Operator uses to control the well.

ENTERPRISE SOLUTION ENGINEERING

Enterprise Solution Engineering offers cost reduction of engineering, maintenance and training by:

• Reducing redundant engineering—Manages the data that needs to be exchanged at area boundaries.
• Managing revisions—Each change that is applied to the configuration can be marked as a revision. This allows for tracing back of all changes made to the configuration, and for the rollback of the whole configuration or parts of the configuration to a certain revision.
• Discovering configuration—The configuration of equipment or of a server which has been autonomously engineered can be imported and converted to the object model and deployed in various servers.
• Security model—The rule based security model authorizes users to perform common tasks.
• Ease of engineering that results in ease of training.

Reducing redundant engineering

Figure 2 Typical Example of an Object Model

The Enterprise Automation System is experienced as a single system environment from an engineering point of view. The first step is to build the object based model of the Enterprise Automation System using the Enterprise Engineering Module. At this moment, the engineer does not need to have knowledge about the physical layout of the automation system but can concentrate on the functionality of the process. The final step is to deploy the model of the process to the physical servers and the equipment in the field.

a) The object model
The object model mimics the functionality of the Enterprise Automation System. For example, at the process level, an oil well is defined. At the area level, an accumulator can be defined that accumulates all the oil production of the area. At the business unit level, an accumulator is defined that accumulates all the oil production of the Area level accumulators. It is possible that there are different types of oil wells in the process, whose characteristics are defined in different well types.

Figure 2 shows a typical example of an object model.

b) Deploying the object model
After building the object model of the Enterprise Automation System, the object model is brought to life by deploying it. Each object is deployed at a certain server. Once the objects are deployed, all the servers in the Enterprise Automation System are updated with runtime configuration data. By using the object model and deployment model, each server is aware of the data that is required to feed the objects that are deployed on the server, and where to find this data. The servers will establish communication with other servers or equipment in order to obtain the required data.

In an ideal world, objects from the object model can be deployed in equipment. For FAST/TOOLS this means for example that it is even possible to define a PID loop by using the Enterprise Engineering Module and deploying it in a STARDOM. This provides a single engineering environment for FAST/TOOLS and the equipment. In the case of ProSafe- RS, this operation is restricted for safety reasons. As for safety control systems, an isolated certified engineering tool is required.

Managing revisions

An important function of Enterprise Engineering is managing revisions. At all times, it must be possible to label a certain configuration as a revision. Comparisons between the current configuration and a previous revision and between revisions can be made. If necessary a rollback can be made to a certain revision as a whole, or only rollback certain parts. Besides revisions, all changes by engineers to the configuration are labeled with their name, change time and reason for the change. A modern web-enabled user interface helps the engineer to maintain the revisions and the change log.

Discovering configuration

Figure 3 Changes in the Configuration of CENTUM VP

An important aspect of Enterprise Engineering is that the local configuration of a server and equipment can be discovered and imported into the enterprise configuration, both as the object model and the deployment model. Local configuration is marked as such and can be used to deploy it in other servers throughout the system. It can be possible that the equipment does not allow configuration discovery. In such a case, any available offline configuration files of the equipment can be imported into the enterprise configuration. An example of discovering would be detecting a change in a CENTUM VP configuration, signaling this change in the Enterprise Engineering Module, and enabling the system engineer to deploy this change manually or automatically to one or more servers.

Figure 3 shows an example of discovering and deploying a change in the configuration of CENTUM VP. A local engineer adds a PID function block to CENTUM VP. The discover function detects the added function block and informs the Enterprise Engineering Module about this new function block. The enterprise engineer decides to deploy the PID in the Business Unit Server to make its faceplate available at this level, and he decides to deploy the PID at the Area level to make its tuning panel available at this level.

Security model

The security model protects the Enterprise Engineering from unauthorized access and modification. Different engineering roles can be defined. An engineer can be assigned a certain role or a number of roles. A role dictates what an engineer can perform using Enterprise Engineering or only local engineering. Roles can be very detailed, to prevent engineers from making changes to the configuration for which they are not capable or trained. A local engineer may be authorized to change the configuration of a specific Process Server, while an enterprise engineer may be authorized to change the configuration on any server, but he may not be authorized to change certain local configurations on a Process Server.

ENTERPRISE SOLUTION OPERATIONS

Enterprise Solution Operations brings the process data to the users of each automation level as depicted in Figure 1. A process operator controls the process on the Process level, up to KPIs that are supplied to the financial systems of the corporation at the Corporate level.

The engineer uses the Enterprise Engineering Module to create optimized user interfaces for each type of use within the automation system. Effective user interfaces for the process operators are created by the engineer. The engineer builds the Collaboration centers at the Corporate level that present the KPIs of the whole process, combined with other information.

The FAST/TOOLS Enterprise Operation Module is responsible for gathering the data to be displayed to the user, and to process the user responses. Some key topics for the Enterprise Operation Module are:

• Name space server—The Enterprise Operation Module uses the name space server to establish the most optimal path to access data to be presented to the user. It tries to find alternative paths to the data if access to a certain server is temporarily not possible.
• Security model—The rule based security model authorizes a user to perform certain operational tasks.

ENTERPRISE SOLUTION NETWORK

To facilitate Enterprise Engineering and Operation in an optimal way, a number of network facilities are available:

• Automatic topology discovery—Changes to the physical server configuration is detected and made available for enterprise engineering and operation.
• Network transparency—The automation network is one logical network, independent from the physical layout of the network
• Scalability—New servers and equipment can be added to the Enterprise Automation System. Objects can be redeployed from one server to another.

Automatic topology discovery

The Enterprise Engineering Module detects that a server is added somewhere to the Enterprise Automation System and tries to detect the role of the server. If such a role is not available, the engineer can define it. Using the configuration discovery functions, the local configuration of the server can be added to the enterprise object and deployment model. Its configuration is marked as a local configuration, to distinguish it from the configuration defined for the enterprise.

If equipment is added somewhere to a server in the system, this is also detected provided the equipment type is supported by the system.

Network transparency

Figure 4 Logical Connection between Enterprise Engineering Module and Process Servers

In Figure 1, four networks are depicted: the Corporate network, the Business Unit network, the Area network and the Process network. These networks can be one physical network where the sections are separated by routers and firewalls, or these networks can be physically separated. In the latter case, a Business Unit server may have two network cards, one that connects the server to the Business Unit network, and one that connects the Business Unit server to the Corporate network. FAST/TOOLS uses a proprietary communication protocol that lies on top of the User Datagram Protocol (UDP), to facilitate communication between the servers. An Enterprise Engineering Module requires access to all servers in the Enterprise Automation System to distribute configurations to the servers in the network. Therefore, a server can act as a network bridge to other servers. This way, the whole Enterprise Automation System interconnects via one logical automation network.

In Figure 4, a logical connection between an Enterprise Engineering Module located at the Corporate level and one of its Process Servers is depicted. The logical automation network supports plug and play. If at any level a server is added to the physical network, then the logical automation network will discover this and update its routing tables with the new server.

Scalability

An Enterprise Automation System in particular is very dynamic in its configuration. Servers and equipment are added or removed daily. The Enterprise Engineering Module detects such changes and enables the engineer to redeploy objects to another server. If a server or equipment where objects are deployed is removed from the system, then the engineer can redeploy objects to other servers, or decide to remove them. Note that this is a different situation from when communication with a server or equipment is temporarily not available.

CONCLUSION

Engineering an Enterprise Automation System, often extending over large geographical areas with many servers, networks and equipment, is a tedious, error prone and time consuming task.

The FAST/TOOLS Enterprise Solution philosophy addresses this task in order to make it far less tedious, error prone and time consuming, resulting in significantly less engineering, maintenance and training costs, by reducing configurations that must be duplicated and configured multiple times throughout the Enterprise Automation System.

In this paper, a number of areas were addressed that enable FAST/TOOLS to facilitate the Enterprise Solution in the next release or subsequent releases of FAST/TOOLS.

REFERENCES

1. ANSI/ISA 95.00.01-2010, Enterprise-Control System Integration - Part 1: Models and Terminology

• FAST/TOOLS, CENTUM VP and Pro Safe is a registered trademark of Yokogawa Electric Corporation. Other brand names in this paper are the trademarks or registered trademarks of each company.