Suppliers of automation and instrumentation systems to process plants sometimes stress the technologies embedded in their products and services, but focusing on technology alone does not solve problems. End users know this and are usually much more interested in specific applications and use cases than technology details.

While only a limited subset of plant personnel may have knowledge of or interest in Industrial Internet of Things (IIoT) and other enabling technology details, all personnel have plant issues they would like to address. And, all need solutions to process and other problems. Focusing on applications, rather than technologies, allows a much wider range of plant personnel to participate on a project team instead of just those intimately familiar with the technology.

For example, many organizations have installed WirelessHART networks on a limited basis to solve a specific problem in a cost-effective manner. Most often, they are related to process monitoring. Due to the benefits received, many organizations are starting to deploy site-wide coverage to extend benefits beyond process monitoring. These include maintenance; health, safety, social and environmental (HSSE); and plant safety applications.

Emerson

Many end users see value in improving reliability, HSSE and compliance, but these are very broad categories. Tangible and more specific applications must be identified. Examples include monitoring critical pumps to improve reliability and pressure-relief valve monitoring for HSSE compliance.

But, many of the people expected to design these applications may not be familiar with wireless instrumentation and other automation system technologies. They may not have the capacity to support these technologies after installation. The solution is to focus on the problem and the solution first, then the technology second.

This article discusses some of the key steps a facility or corporate organization can take to provide solutions to process plant problems through the implementation of wireless instruments and networks. Although this article focuses on wireless, the concept of putting applications before technologies is applicable to many situations where relatively complex technologies are used to solve process plant problems.

Building the Project Team

Building the project team is an essential first step, and this team should consist of owners and users of the technology. The team creates and implements the project vision and drives awareness of how the technology can be used to solve problems in different areas of the plant across multiple disciplines. The team requires diverse perspectives to reflect the needs of the end users and ensure value is achieved.

For example, if the WirelessHART installation is to be used for improving reliability, it needs to be shaped to reflect reliability cases. The same is true for process, HSSE and other types of use cases. Getting back to reliability, multiple use cases can be included. Perhaps the solution starts with a focus on critical pump monitoring, but it can be architected to support other use cases such as monitoring other types of rotating equipment.

The team must define the required areas of wireless coverage, types of variables to be measured, number of data points, data rates, and integration and presentation of data. In the broader view of IIoT enablement, the conversation also may include data analytics to turn the data into actionable information, and to deliver this information to mobile end users via smartphone or tablet.

Each group of end users will have unique needs, but many technologies can be leveraged across different application areas, allowing groups to share costs. For example, WirelessHART networks can deliver data for process, HSSE and reliability applications on a shared network. But, because multiple use cases are represented in the design, the WirelessHART networks are designed with the required host system integration to ensure each end user group gets the data they need.

Each application can be looked at individually, but the common technology components can be shared among applications to deliver scalability and more value. By developing the applications individually and then looking at them holistically, the common technology requirements can be identified and included in the general architecture for the infrastructure.

Some users may not have short-term needs, but if their needs are reflected in the long-term vision, then they too can be part of the adoption process. This is best achieved by having cross-functional representation on the team.

Because groups outside of process control and IT do not typically deploy and maintain automation systems, the team needs expertise in these areas. It will typically be drawn from the process automation and IT groups. This ensures the technical aspects of securely deploying and maintaining the technology are handled correctly, both currently and in the long term.

As with any project team, there must be a team leader along with executive support. If a corporate team is developed, there should be reciprocal teams in the field to apply guidelines and recommendations suited to the unique requirements of a specific site. Different sites may have different short- and long-term needs, and it is important to start where the highest value is easiest to achieve. Sites should share successes with the corporate team, helping to facilitate best practices and knowledge sharing.

For example, one site might have an urgent need to monitor critical pumps, whereas another may have to focus on environmental compliance. In the long term, both groups may want to enable both these applications, but they will have different starting points. In these two examples, the funding for the WirelessHART infrastructure would be driven by different applications, but the infrastructure would be available for multiple applications driven by different end users.

Creating the Vision

The project team should establish a broad vision based on return on investment (ROI), with deployment of any solution planned in phases to comply with timelines and budgets. Basing the vision on ROI produces several benefits:

  • It makes project approval more likely because financial benefits are calculated.
  • It puts the focus on problem solving rather than on technology.
  • It allows full participation by all team members even those not intimately familiar with the technologies proposed to solve the problems.
  • It only requires calculation of the cost of implementing the technology for each use case and not detailed design.
  • It reduces or eliminates expenditures not focused on solving the problem as these would decrease ROI.
  • It forces estimation of not only project costs but also benefits.

Many clients see value in improving reliability, HSSE and compliance, but these are very broad categories. Tangible and more specific applications must be identified. Examples include monitoring critical pumps to improve reliability and pressure-relief valve monitoring for HSSE compliance.

The vision guides the development of use cases along with organizational adoption and roll out of the technology. The key to maximizing value is picking the right use cases — those which will produce the greatest ROI and justify the initial infrastructure investment.

Using a phased approach allows the projects with the highest ROI to be implemented first, producing significant wins. They can be shared across the organization to generate acceptance of and enthusiasm for further projects. Often, one or two key applications with high ROI can justify the cost of a site-wide WirelessHART infrastructure. They then reduces the implementation cost for lower ROI projects that could not justify the infrastructure on their own.

Once the infrastructure is in place, especially with wireless instruments, most of the cost of new applications is just purchasing and installing pressure, level, temperature, flow and other transmitters. If integration was included as part of the fundamental infrastructure design, the data points just need to be enabled over the existing connections.

One way to create a project vision based on use cases and applications is to use the See-Decide-Act methodology (figure 1). The See step defines the data required and quantifies the number of data points available in the field. The Decide step determines where that data needs to go and what type of analytics are required to create actionable information. The Act step determines how users will access and act upon the data, often using mobility tools such as smartphones and tablets.

Understanding the Use Cases

Using the See-Decide-Act methodology, the use cases need to be well documented so the organization knows when and where the technology can be used to address issues. It is also important to document successful use cases and then share these internally at the plant and with the corporate fleet. Successful use cases may not have used the technology being considered to solve current problems. But, they can show the way to solutions, speed up decision making and drive value.

For example, if Site A adds a wireless temperature sensor to a critical asset at a cost of less than $10,000 and saves $25,000 annually, the rest of the organization should be aware of it as they may have the potential for hidden ROI as well. By employing modern technologies such as wireless, the cost of adding the sensor could drop by 75 percent or more, making this type of project viable in areas with lower anticipated savings.

Once all the use cases are defined — both existing and new — ROI can be calculated to support prioritization of use cases and definition of the general infrastructure. An individual use case may not deliver enough ROI by itself to justify the required accompanying infrastructure investment, but the infrastructure could enable low-cost implementation of many other projects, which added together, would justify the investment. When developing the general architecture, the primary design should be driven by the applications providing the highest ROI and the infrastructure in place to support future applications. 

Fundamental Design and Scalability

The fundamental infrastructure design includes several aspects to provide enhanced connectivity to the field, including:

  • Capacity for current and future wireless transmitters.
  • Network infrastructure to support field connectivity to the transmitters.
  • Integration into host system locations to provide data to end users.
  • Application-specific analytics to transform data into actionable information.
  • Mobility solutions to deliver actionable information to end users.

In many instances, existing infrastructure such as control systems, historians and existing software analytics can be leveraged and combined with new data from wireless transmitters.

For an IIoT infrastructure implemented with WirelessHART transmitters and network technologies, the design should reflect the vision developed in the use cases. This includes wireless network coverage of the plant areas where transmitters will be installed and integration into key systems. Technical ownership of the infrastructure should also be defined along with processes for change management. These requirements define the fundamental infrastructure requirements, including how it will be deployed, who can use it and how it will be maintained.

All these details do not have to be developed on day one for the entire plant. There should be a fundamental plan in place such that additional areas will have wireless coverage when needed, either in the initial installation or as a simple add on later. This will allow the wireless installation to proceed in phases and per a plan with highest ROI projects first (figure 2).

Emerson Automation

FIGURE 2. Proper initial design of the wireless network will accommodate each new project as it is installed without any major modifications to the infrastructure.

Creating Implementation Guidelines

Many clients have wireless standards covering what wireless technologies may be used, and the type of applications for which wireless is acceptable. For example, wireless may be deemed acceptable for monitoring but not for real-time control.

But, these standards do not define how to implement specific applications. This can result in different functional groups duplicating efforts when it comes to integration, security and ownership methods. It can also lead to inconsistent deployment methods across a company along with isolated adoption due to higher costs and complexity.

Implementation guidelines address these and other issues by capturing the work of the project team and by translating these technical guidelines into useful methods for using the technology to solve the use case problems. If there is a corporate implementation guideline, there may also need to be a local version to account for site-specific needs. It should be based upon the corporate guideline.

The implementation guideline should be evergreen, with updates made as time progresses to account for changes in technology and new use cases. It should cover the following areas:

  • Technology overview to brief users.
  • Clear use case guidelines.
  • Exception approval process.
  • Methodology for calculating ROI.
  • Integration standards reflecting use case data connections into host systems.
  • Security provisions.
  • Network design standards, including when to use existing versus expanded infrastructure.
  • Lifecycle maintenance standards.
  • Ownership and documentation standards.

A good implementation guideline captures the efforts of the project team and develops a vision based on use cases. It acts as a playbook for others to follow to achieve maximum ROI. It provides consistent best practices to ensure long-term reliability, along with security and scalability.

In conclusion, end users at process plants are typically much more interested in solutions solving their problems and delivering ROI than the details of the technology used to address their issues. Using the See-Decide-Act methodology allows end users and technology owners to focus first on applications and their specific use cases, and second on the underlying technologies. This creates a vision based on ROI, which in turn justifies the required infrastructure investment for initial and subsequent applications.