Implementing the NAMUR Open Architecture (NOA)

The M+C field device OPC-UA server enables M+O software in the DOI to read data from M+C sensors without passing through the DCS. It is possible to add sensors onto existing fieldbus infrastructure, and use the data in M+O software in the DOI, ideal when fast measurement updates are required, like for pump discharge pressure. This could be an OPC-UA server for a WirelessHART gateway or FOUNDATION fieldbus linking device.

For the future, NAMUR is developing this further with a standardized device information model such that all OPC-UA servers for devices will appear the same for some additional benefits.

M+C Device 2nd Channel Output to Industrie 4.0

The NOA provides a 2nd channel for M+C field devices. This is a means to connect installed base via 2nd connectivity channel to use stranded information (e.g. for device management) in M+O software in the DOI. This second channel is a direct M+C field device output to the Industrie 4.0 systems (4.0 Out), not going through the OPC-UA server. That is, M+O software in the DOI like Intelligent Device Management (IDM) software can use the IP-version of each bus protocol to access device management data for configuration, calibration, and diagnostics etc. directly in M+C field devices, thereby also preserving the semantics of the data and retaining the native support for DD/EDDL/FDI files. For instance, HART-IP to access data in 4-20 mA/HART devices through a HART multiplexer (MUX) and WirelessHART devices through a wireless gateway, FF-HSE for FOUNDATION fieldbus H1 devices through a linking device.

Digital Operational Infrastructure (DOI)

DX of how the plant is run and maintained requires additional automation; a DOI added to perform new Monitoring and Optimization (M+O) functions. This is the pink sliver beside the traditional automation pyramid.

Historian

The historian reads data from underlying sensors, package unit PLCs, machinery monitoring systems, and the DCS etc. acting as a data aggregator. A plant can have multiple control systems connected to a one historian as a “single platform” for data aggregation. Historians also support OPC-UA to get data from other software. The plant historian is designed for time-series process variables, and for time-stamped alarm and event logs.

Add-on Sensors

Plants have many sensors, but they tend to be mostly process sensors, and you can’t predict equipment problems using only process data. Many have tried and failed. You need equipment data. Plants need equipment sensors: add-on sensors as enabler for additional services e.g. advanced analytics.

You can’t predict equipment problems using only process data

The first step in DX is therefore often to automate data collection. Automating manual data collection requires many add-on sensors. These additional sensors include classic measurement like pressure, temperature, level, and flow as well as new “human senses” like acoustic, camera, vibration, and analyzers. This includes multi-input sensors.

In order to reduce total installed cost and installation time, these additional sensors can be wireless and non-intrusive, thereby eliminating the need for power cords, signal wires, and I/O cards, as well as cutting, drilling, and welding for the mechanical installation. Depending on the specific requirements it may be possible to use lower tier accuracy and stability than M+C sensors. Housing can be engineered polymer instead of powder coated aluminium or stainless steel. Use of intrinsic safety mode of explosion protection instead of flame proof / explosion proof also reduces cost. Lower tier, less advanced, diagnostics than for M+C sensors can also be specified.

Wireless devices are not used for functional safety or process control. Wireless devices are ideal for non-real-time measurements like vibration, corrosion, acoustic noise, louver position, and lube oil level etc. for analytics.

App Platforms

An app platform is a framework that enables software applications (apps) to read data from the add-on sensors and the DCS as well as its many underlying data sources including the M+C field devices. Many plant historians are capable of this. That is, the plant’s existing historian can potentially be used as the app framework. Note however that historians are not open systems, they are monolithic; their internal software components integrated through proprietary API. Licensed software vendors use these proprietary APIs to get data from the historian into their apps, for instance, into analytics. The analytics software gets the data from underlying sensors and other data sources through the historian platform.

For plants that do not have a historian, or the historian does not support an app framework, a platform independent app framework can be used. OPC-UA and the M+C device 2nd channel allow those apps in the framework to read data from those same sources directly.

It could also be that the plant does have a historian but needs an app of a type not available for their historian’s app framework. In this case, a platform independent app can be used.

This common data aggregation is one aspect of an app framework. Other attributes of an app framework includes common user accounts, meaning a user that need access to multiple apps use the same login credential for all apps for simplicity. Lastly, an app framework provides a common look & feel; all the apps in the framework work in the same basic way. Once you have learnt how one app works you know how to use the others as well.

Although an app framework can support lots of apps for different tasks, most people only use a single app. For instance, the energy manager may use the Energy Management Information System (EMIS) app, the integrity engineer may use the corrosion/erosion app, and the instrument technician uses the valve diagnostics app a.s.o. Nobody uses all these apps.

Lastly, OPC-UA and the M+C device 2nd channel let stand-alone software from multiple vendors read data freely. A very open system. Software in the DOI support OPC-UA so all other software in DOI can read their data. That is, OPC-UA is a single virtual platform.

Device Management 4.0

Traditionally Intelligent Device Management (IDM) server has been deployed together with the DCS, with the IDM client workstation located in the control room. However, this was not convenient for the instrument technicians and engineers which are the intended users of the software, since they do not work in the CCR. They prefer to use the IDM software from the desk in their office cubicle, or on their smartphone on-the-go. This is now possible with IDM 4.0.

Moreover, M+C field device wiring in most plants were made to 4-20 mA standards, not to HART specifications, which causes HART communication error messages to appear, so in many systems HART is disabled. Plants are now auditing their instrument wiring to make both 4-20 mA and HART work error free, and perform diagnostics rationalization as well.

Advanced Analytics

“Advanced analytics” is higher-level operational analytics which includes software for equipment condition analytics such as for predicting pump failures, equipment performance analytics such as for heat exchanger efficiency detecting fouling, process analytics such as for predicting process upsets or lab data, and many more.

Operational analytics is about analyzing operational data coming from operational systems like DCS, PLC, RTU, machinery monitoring systems, and wireless add-on sensors etc. which is done at level 3 in real-time, to gain insights around the production and maintenance. This is very different from business analytics which is about analyzing transactional business data from the ERP.

There are really two kinds of analytics: engineered analytics and data science.

Data science is based on Artificial Intelligence (AI) such as various Machine Learning (ML) algorithms. ML tools can be used to analyze historical data using algorithms such as regression, principal component analysis (PCA), clustering, and training of artificial neural networks (ANN) and many more to generate a model of the process from that historical data.

Engineered analytics is based on well-known physics first principles (1P) and equipment Failure Mode and Effect Analysis (FMEA). FMEA fault trees are used for equipment condition analytics and first principles (1P) for equipment performance analytics. These apps are readymade so data scientists are not required for these types of apps.

The key to successful analytics is knowing when to apply the right analytics tool to the job. AI/ML is not the best tool for all jobs, neither is 1P/FMEA.

Ready-made, pre-engineered for specific well-known problems using FMEA-based models for equipment condition analytics of steam traps, relief valves, pumps, cooling towers, and air-cooled heat exchangers etc. and 1P-based models for performance analytics of heat exchangers, compressors, and pumps etc. Very easy to deploy. ML would be overkill in applications like these.

ML can be used for complex unit processes or the whole plant for which first principle models and FMEA have not been documented. The ML tools are first used to analyze existing historical data to uncover correlations in the data (relations between process variables and modes of operation or lab data etc.) which can be used for prediction. Based on this a model of the process is created. This model is then used in the online mode of the ML software to help the operator see upsets coming and guide the operator to the correct action.

There are analytics software that can do both data science and engineered analytics.

Reliability Center

The plant historian is designed for structured data; time-series variables and time-stamped logs. The historian does not store unstructured data like vibration spectrums, corrosion signatures, chromatograms, valve signatures, and other reliability data. These all have their own unique data formats. Note that analytics does not do prediction based on historical data from a database. Prediction is based on the data that streams in from sensors live. Therefore predictive analytics does not require a data lake or additional platform with a copy of every database, spreadsheet, or maintenance log in the plant.

Predictive analytics does not require a data lake

In the pharmaceutical, bio tech, and life science industries the historian is an integral part of the CPC and validated according to GAMP just like the DCS. Therefore plants in these particular industries are reluctant to make any changes to the process historian. For these plants it makes sense to use the reliability center as a separate reliability historian, including some time-series data, for non-process data and functionality which does not fall under GAMP. This gives these plants the flexibility to freely add sensors and apps for reliability, maintenance, and energy efficiency functions to the reliability historian without requiring revalidation. Note the process data in the plant historian is not duplicated.

The reliability center is also responsible for the integration with CMMS and ERP system for a complete digital maintenance workflow. For instance to trigger a ticket in the CMMS when a problem is predicted with a pump such that the maintenance planner can release a workorder. This in turn integrates with the maintenance technician’s tablet or smartphone so they can manage the workorder from the app.

Central HMI

In a digitally transformed plant, work by everyone from the plant manager down is data driven. Therefore information cannot only be available in the control room. Information must reach the person responsible wherever they are: in the plant, admin building, boardroom, or on their way to or from work. Each person needs data relevant to their responsibility to do their job better. A role-based dashboard provides an on-the-go at-a-glance overview of the domain of responsibility for each role. For instance, the reliability manager has a dashboard on their smartphone and tablet very different from the production manager. Dashboards are generated by mobility software often part of the plant historian using information from underlying analytics apps like equipment condition analytics. Operational dashboards contain real-time operational indexes; real-time information that impact their KPIs, specific to the person's responsibilities displayed on tablets or smartphones, making information immediately available wherever you are.

Process Simulation

Process simulation is used for the Operator Training Simulator (OTS) software and for optimization. The process model is a digital twin of the actual physical process. This virtual plant process model has to be maintained, to keep true to actual process as changes are made. It can be done by the process engineers or system engineers in the plant, it does not require data scientists. The OTS is connected to an off-line control system (not the production system) having the same operator graphics and control strategies as the production system to train operators to take appropriate action in various scenarios like process upsets or batch switching etc., all without disturbing the actual plant. The process model is also used to try out new control strategies and logic improvements, tuning, and setpoints etc. for process optimization, especially for batch recipe optimization. At FAT, process simulation is used for configuration validation and logic test to speed up the process. The digital twin is also used for Virtual Reality (VR).

Use Case Examples

There are lots of readymade DX solutions for process plants. The NOA presentations typically include two use cases: fouling prediction in heat exchangers, and condition analytics of pumps.

Fouling Prediction of a Heat Exchanger

Predicting fouling in heat exchangers is a good example of additional measurements for process optimization. Benefits of fouling predication of a heat exchanger include reduction of production losses due to increasing transparency of plant assets, and optimization and planning of maintenance and production schedules. Production plants are normally not instrumented for optimization purposes, due to the cost factor of additional instrumentation. This example has low requirements on availability because it is not mission-critical, and no direct integration into the control system required either. For this use case the NOA enables an easy and flexible integration of required sensor data into monitoring and optimization systems. Some of the required measurements may be available in the DCS or historian, such as product flow and outlet temperature. If so, these measurements can be used, without the need to duplicate those transmitters. Add-on sensors are deployed for missing measurements.

Condition analytics of pumps

Plant asset management includes condition analytics of pumps. The condition monitoring systems used for turbomachinery has no economic viable transfer to standard equipment (e.g. Pumps) due to the high cost of such traditional systems. However, the NOA enables a cost-efficient alternative for the collection and integration of additional sensor data. Some of the required measurements may be available in the DCS or historian, such as mechanical seal flush fluid reservoir pressure and level as well as discharge pressure. If so, these measurements can be used, without the need to duplicate those transmitters.

Industrie 4.0 Migration

The NOA is a very good approach for modernizing existing plants as the existing DCS is left intact. The NOA is independent of the existing DCS, so migration to Industrie 4.0 is possible regardless of the DCS in the plant.

The NOA is also a good way to make sure new plants are not built the old-fashioned way with manual data collection and interpretation for maintenance, reliability, integrity, energy efficiency, and other operations beyond the DCS.

Although details of the NOA is still being worked out such as specifications for the data diodes, information model, and Verification of Request, plants can already implement the high-level concept of DOI for M+O as a second layer of automation added beside their existing automation.

Deployment

In summary, the key attributes of the NOA:

• DCS remains as-is
• DOI added as 2nd layer on the side of the DCS
• Based on existing I&C standards
• Platform independent OPC-UA interface from DCS
• 2nd channel interface to auxiliary measurements and data in networked instruments
• Digitally networked add-on sensors
• Open OPC-UA application platform
• DCS reads and verifies data over OPC-UA

Most plants already have initiatives for Industrie 4.0 (I4.0) and digital transformation (DX) of how the plant is run and maintained. The NOA is the standard system architecture for the required digital infrastructure for process industries. You can deploy a solution aligned with the NOA. Using these best practices and rolling out DX as many small projects, not as a big bang, plants avoid ‘pilot purgatory’.

Jonas Berge,Senior Director, Applied Technology at Emerson Automation Solutions