Transforming the Enterprise One App at a Time

Imagine an app that tells you a pump will soon fail, and why, or that the compressor is under-performing, or an app notifying you the boiler is consuming too much fuel gas, or recommending actions to prevent the process going off-spec etc. Such a data-driven way of working is the digital transformation vision of many plants. But with so many people in the plant, having so many roles, performing so many varied tasks, can one single software do it all? Or do you use specialized apps? Do you deploy it all at once, or one at a time? Where do you start? And how do apps integrate with your existing automation? Here are my personal thoughts:

People, Roles, and Tasks – Digitally Transformed

There are dozens if not hundreds of roles in a plant depending on the product produced and capacity. Each role with its tasks and responsibilities. Many of these tasks are still manual and paper-based which limits the effectiveness of those tasks; obstacles to operational excellence and top quartile performance. Digitization boils down to transforming these manual and paper-based tasks one-by-one to new automatic, digital, software-based, and data-driven ways of working. Enterprises do this plant-by-plant, area-by-area, unit-by-unit, department-by-department, and task-by-task until the whole enterprise is transformed. This is a multi-year journey. This journey starts with a digital transformation discovery workshop at each site to uncover where the challenges are and where digitalization can be applied. Next, solution mapping follows; matching challenges to readymade solutions; or co-creating new innovative solutions where none exist. Engineers are very good at problem solving; they’ve got the “knack”.

Each task in a plant requires a different software tool; an app. Apps is what give personnel the insight into what is going on in their area of responsibility so they can make better decisions, faster. Depending on their role, personnel use different tools. Just like a mechanic use one set of tools and a carpenter a different set of tools. And just like in the office; for some tasks you use Outlook, for some you use Word, others you use Excel, or PowerPoint etc. There are many more software tools used in the office when you take the ERP system apps into account. Each tool is specialized for a specific task. Depending on your role you use some tools more than others.

Readymade Apps for Digital Transformation

That is, a plant will need many specialized apps to digital transform the many tasks for the people in the plant. But as the old iPhone commercial goes; “There’s an App for That”. That is, you don’t have to develop these apps for your plant yourself. There are ready-made apps for lots of job functions in plant operations. This is operational analytics, not Business Intelligence (BI). These include for instance:

• High-level equipment condition analytics
• High-level equipment performance analytics
• Energy Management Information System (EMIS)
• Operator logbook
• High-level process analytics through Artificial Intelligence (AI)
• Intelligent Device Management (IDM)
• Detail vibration analytics
• Detail integrity analytics (corrosion and erosion)
• Field inspection rounds
• Radio Frequency IDentification (RFID) access
• Operational Dashboards
• Augmented Reality (AR)
• Notifications
• Virtual Reality (VR)
• Location Awareness
• Batch Analytics
• Alarm Management
• Operator Training Simulator (OTS)
• Advanced Process Control (APC)
• Real-Time Optimization (RTO)
• Procedural Automation
• Auto-Tuning
• Tank farm inventory
• Statistical Process Control (SPC)
• Terminal Scheduling

There is no one “single software” that does it all, the plant needs many apps.

Using ready-made apps instead of custom programming can save months and years of coding and testing work, and many thousands or even millions of dollars in development cost. Not to mention ongoing maintenance throughout the life of the system. You can’t custom program all this software. Readymade software is the most practical solution. Ready-made apps have built-in domain knowledge from Subject Matter Experts (SMEs); know-how about pumps, steam traps, and control valves etc. providing actionable information. Equipment analytics apps using first principles (1P) and FMEA are robust and easy to use; not requiring data science skills.

Apps are modular software. You can deploy apps one-by-one as needed. You don’t have to do all at once. Modular software enables a phased implementation. You may wish to start with steam trap analytics, then corrosion, followed by pumps a.s.o.; Think Big, Start Small, and Scale Fast is the formula for avoiding the so-called ‘pilot purgatory’ stall of digital transformation. The success of an app in one area is expanded across the plant and then the entire company.

These apps are not installed on the DCS itself. They run on the historian server or on a separate app server. Apps can take data from the DCS using OPC-UA, as per the NAMUR Open Architecture (NOA). That is, apps have no impact on the availability and safety of the DCS.

The most interesting fact is, the unified architecture which plants are looking for already exists, and OPC-UA is at the heart of it. UA means unified architecture.

Integrated Platforms and Frameworks for Industrie 4.0

The good news is that these ready-made apps can be used in your plant with your existing automation systems. Your existing plant historian can be your data aggregation platform, or if you don’t have a historian, live data can be aggregated directly through OPC-UA as a “virtual platform”. Your existing plant historian can also be your application framework, or if you don’t have a historian, the apps can run independently or in a dedicated framework.

Most plants already have a ‘single software platform’; their historian

Raw data from multiple sources flow into the historian: from DCS, package unit PLCs, wireless sensors, MCC, machinery protection system etc. Raw data is not so useful. You need actionable information. Analytics turns raw data into actionable information; DIKW model. But the historian itself does not do analytics. Apps do the analytics. Analytics apps take raw data from the historian to generate the actionable information. Different analytics tools are required for each role/persona. You don’t have to program your own analytics in the historian. Use readymade apps – it saves a lot of time and cost.

Most plants prefer the platforms and apps on-premises, within the plant perimeter. Some plants want the platforms and apps in the cloud.

Data Aggregation Platform

Some apps need data from multiple sources; from multiple systems through a data aggregation platform. For instance, an Energy Management Information System (EMIS) app for ISO50001 style energy management to manage consumption of utilities such as Water, compressed Air, fuel Gas, Electricity, and Steam (WAGES) as well as others may get a measurement from DCS of the overall consumption metered as it comes into the plant across the battery limits, or as it leaves the boiler or compressor. To enable energy balancing to narrow down overconsumption to a specific area, unit, or piece of equipment, the EMIS app also gets electricity consumption for each circuit from Motor Control Centers (MCC) and power meters, plus fluid consumption in each branch from lots of additional wireless flow meters through a wireless gateway. The EMIS app gets this data through a data aggregation platform; typically through the plant’s existing process historian, or direct from the source through real-time data aggregation like OPC-UA. Apps can tap into a particular historian using native historian interface, or into any historian through OPC-UA. Older systems not yet supporting OPC-UA may support the earlier OPC Classic interfaces (DA, A&E, and HDA) for which proxy software is available. There is no need to spend millions of dollars on an additional ‘single software platform’ that duplicates that data in the historian and other systems. Build on the historian you already have. Don’t fall for the "single source of truth" fallacy that you need to add yet another new platform above the DCS, above the historian, and above the ERP. There will always be another proponent of yet another platform layer above the one you just bought. It never ends. Instead standardize on OPC-UA and make sure the subsystems and software you buy support OPC-UA. This way they will work together without layer upon layer of platforms.

Similarly, equipment performance analytics apps also need data from multiple sources. For instance, some fluid flows and pressure measurements may already be available from the DCS, but other measurements required have been added later coming in through a wireless gateway. Again, this can be brought in through the historian or directly through OPC-UA.

A third example is equipment condition analytics apps using some data already available from sensors wired to the DCS, while other measurements come in through machinery health monitors, or a via a wireless gateway in case of wireless sensors.

Lower-level detail analytics like vibration and corrosion take data straight from single sensors; but the output result of lower-level analytics, such as alarms and computed variables, feed into the historian platform. The same applies to control valve analytics. These apps also need to store data so you can review the history and make comparison etc.

Apps can be standards-based and platform independent, or platform-specific. Standards-based, platform independent, apps have OPC-UA interface to the data sources so they can be used with any platform, or other data source supporting the OPC-UA standard directly or through proxy. Platform-specific apps only work on a specific platform; a specific plant historian. Standards-based, platform independent, apps based on OPC-UA has the advantage that if the platform vendor can’t keep up with your plant’s demands on performance and connectivity options you can change the platform without changing the apps.

The historian mostly stores time-series process data including alarms and events. The historian does not store reliability data in complex formats like valve signatures (historian can store deviation and friction time-series), vibration spectrums, waveforms, chromatogram, and orbits (historian can store velocity and PeakVue time-series), radar level transmitter echo curves (historian can store signal strength time-series), and corrosion signature (historian can store wall thickness) etc.

A Digital Operational Infrastructure (DOI) accepts raw data from control systems, machinery protection systems, and historian etc. through OPC-UA or native interfaces, and also provides information to other systems through OPC-UA.

As always, be careful with proprietary software “API” (interface technology owned by a single company as opposed for a multi-vendor consortia) as the vendor can make changes to the API at any time rendering software incompatible requiring expensive and time-consuming code fixes. Expressions like “exposed API” and “open API” are sometimes used in a confusing manner.

Plants have lots of historical data, terabytes of data, but it is the wrong data for many of the tasks they want to accomplish. Plants only have process data good for process analytics, but you can’t predict equipment problems using only process data. Many data scientists have tried but invariably find they need more data. To reliably predict equipment problems you need equipment data; you need to add-in equipment sensors. There is no need to replace existing pumps and heat exchangers, just fit sensors on them to make them smart connected equipment.

App Framework

There is some advantage in having apps in a common framework as it provides a more uniform look and feel, common login, and preferences etc. among apps which make it easier to use multiple apps as required by some personnel.

Presentation

Dashboards and notifications on your tablet and smartphone are part of the Industrie 4.0 vision of many plants. It is not always practical to have to return to your desk to get information. It is even less practical having to go to a Central Control Room (CCR) or workshop for information. Today the information is required on-the-go on the plant floor, at a toolbox meeting, in the boardroom, or offsite conference. Wherever you are. Using a web browser interface is the most practical way to display information on gadgets with different screen sizes: computers, tablets, and smartphones.

Operational Dashboards

The information from various apps and direct from other sources are consolidated and displayed in personalized operational dashboards. It may be presented as real-time indexes relevant to the area of responsibility that impact the longer term KPIs for the person to help them do their job better. The energy manager may want to have EMIS data, steam trap, PRV, flaring, and heat exchanger data as well as equipment efficiency and energy intensity indexes on the dashboard. The safety manager wants to have risk profile data on the dashboard. The reliability engineer wants OEE etc. on the dashboards. A dashboard is just graphics rendered from information that comes from the underlying analytics apps. The dashboard web interface may already be provided by your existing historian as an optional module. You may already use dashboards for production data. Now you can add dashboards for reliability, maintenance, energy efficiency, integrity, safety, and compliance etc. Operational dashboards are displayed using the historian platform’s web interface.

At a lower level there are other dashboards used by specialists; such as equipment dashboards for assets like pumps and heat exchangers used by mechanical engineers, and device dashboards for assets like transmitters and valves for instrument engineers.

Notifications

Alarms from various apps and direct from other sources are marshalled as personalized notifications on your mobile phone depending on your area of responsibility such that you only get notifications relevant to you, anything else would be spam. That is, maintenance-related alarms become notifications for the maintenance team. Safety-related alarms become notifications for the safety team a.s.o. Notifications may already be provided by your existing historian as an optional module. Notifications can also be handled by an independent software. Notifications provide not only the alarm message, but additional information such as time to respond, consequences of inaction, recommended action, probable cause, and design information – information you need to take the correct action.

Reports

The information from various apps and direct from other sources are consolidated and displayed in personalized operational reports. It may be reported as the KPIs for the person during the reporting period, but may also include current real-time indexes. The energy manager may want the report to have consumption data per ton of product produced. The quality manager wants percentage yield or off-spec in the report. A report is just graphics rendered from information that comes from the underlying analytics apps. The report generation may already be provided by your existing historian as an optional module. You may already use reports for production. Now you can add reports for reliability, maintenance, energy efficiency, integrity, safety, and compliance etc. Operational reports are generated using the historian platform’s Excel interface.

Industry 4.0

The future is digital. Industry 4.0 is upon us. One single software cannot do it all, you need multiple specialized apps and you deploy them one at a time. Start with use-cases that give quick and easy to demonstrate returns. Use your existing historian as a platform to save time and cost. Well, that’s my personal opinion. If you are interested in digital transformation in the process industries click “Follow” by my photo to not miss future updates. Click “Like” if you found this useful to you and “Share” it with others if you think it would be useful to them.