Digital Transformation (DX) with Industrie 4.0
DX is about changing how work is done in the plant to achieve the operational excellence goals; transforming the way the plant is run and maintained, from manual and paper-based tasks, to automatic, digital, software-based, and data-driven ways of working. This requires automation. Therefore, business objectives ultimately translate into technology requirements.
Industrie 4.0, Digital Transformation, and IIoT is a new era in automation
It is clear the existing automation in the plant is insufficient for DX. More automation is required. The corporate engineering center and the local engineering department in the plant must choose the right architecture among all those suggested by various vendors:
- Where shall the wireless sensor gateway connect?
- How will integration with the ERP and other IT systems in the admin building be done?
- Is a new “platform” above the ERP and CMMS required?
- Should custom programed software APIs be used?
- Which network protocols shall be used for sensors, other devices, and any cloud backhaul?
- Which standards apply?
- Where is the boundary between IT and I&C responsibility?
- Will cloud computing, storage, or notification relaying be required?
- Is an internet connection a must?
- How does this fit into the plant’s existing Purdue / ISA95 / IEC62264 model?
It is usually up to the local site to deploy the DOI for DX.
Second Layer of Automation
The member companies of the International User Association of Automation Technology in Process Industries (NAMUR) have jointly developed an open basic architecture for unlocking the potentials of Industrie 4.0 called the NAMUR Open Architecture (NOA).
NAMUR recognizes there would be challenges using the DCS for the new automation of reliability, maintenance, energy efficiency, and personnel safety etc. At their very core, DCS are not open systems, so it is not easy to get data out of a DCS. Also, new technologies are incorporated slowly or not at all. Stand-alone parallel installation of new systems for new functions, not integrated with each other, results. There are no possibilities for quick testing of new apps on the DCS without risk to plant safety and availability. Process automation lags behind modern technology: IoT, cloud, big data, and mobile devices.
The NOA was designed taking several important factors in mind. The existing DCS is proven and has widely accepted architecture. These are highly available and mature systems that supports sustainable operations with long life cycles. Plants cannot risk losing these advantages.
To protect the DCS, the NOA is based on a second layer of automation beside the existing plant automation, complementing the DCS, stretching from level 0 to level 3, connecting to level 4, in the Purdue / ISA95 / IEC62264 reference model.
Thus the existing DCS for Core Process Control (CPC) need not be replaced or dramatically changed. The key principle is to not touch the DCS. However, the plant automation has to be expanded with additional Digital Operational Infrastructure (DOI) for monitoring and optimization (M+O) for reliability, maintenance, energy efficiency, and personnel safety etc. beyond the P&ID.
Another interesting trend is significant improvements of cost per sensor thanks to open and integrative approaches: digital communication technologies like wireless, fieldbus, Ethernet in the field (Advanced Physical Layer). And, non-intrusive sensors and provide lower total installed cost per sensor, enabling new applications.
The NOA is designed for no compromise on plant availability and safety of existing DCS. The NOA is additive to existing automation, there is no need to replace the existing DCS. A key technology at the heart of the NOA is OPC-UA to read the data in the DCS and the field instruments from the new DOI to enable new Industrie 4.0 solutions for M+O. The NOA is based on existing standards like established I&C fieldbus protocols and software interfaces such as OPC-UA to enable simple integration of digital components from the field level up to the enterprise level. This approach suits both new and existing production plants. Automation security is an integral design aspect (security by design) of the architecture.
Image courtesy: NAMUR
Lastly, usability, reduction of complexity, and cost-effectiveness are the main success factors.
Plant specific M+O services are those which are directly related to the process like Advanced Process Control (APC) and alarm management. Central M+O services are not directly related to the process, such as equipment maintenance. The related tasks can be carried out from the offices in the admin building, or from an enterprise fleet management center in another location common for multiple plants with experts supporting multiple plants.
To more easily visualize how the NOA maps to the plant’s existing automation the NOA can be illustrated overlaid on top of the Purdue / ISA95 / IEC62264 model with some of my own personal interpretation with more specific implementation detail.
Distributed Control System (DCS)
The NOA is not so much about the traditional DCS or M+C field instruments. The NOA is mostly about the new DOI hardware and software for M+O. Nevertheless, the NOA has some implications on the DCS as well.
DCS Hardware and Software
With the NOA the DCS remains mostly as-is. Not disrupting the DCS is one of the key design principles of the NOA. At level 1 the DCS hardware includes I/O-subsystem and controllers. At level 2 the DCS has a server responsible for historical process data, alarms, and event logs. The DCS has an engineering station where I/O, control strategy, and graphics are configured. A DCS is ‘monolithic’ in that all these software and hardware components are provided by a single vendor that takes responsibility for their interoperability at initial deployment, and at future component upgrades.
With the NOA the DCS is provided with a DCS OPC-UA server to let software in the DOI read data from the DCS to use for M+O, as well as a DCS OPC-UA client software to read data from software in the DOI to be used in the DCS for CPC functions.
DCS OPC-UA Server
OPC-UA is the standard (IEC62541) software interface for automation software. OPC-UA is the Open Interface for the NOA. The DCS OPC-UA server converts from the proprietary DCS protocols and data formats to open OPC-UA interface for the M+O software in the DOI to easily read data from the DCS. The DCS is one kind of data aggregator. Therefore the DCS OPC-UA server enables M+O software in the DOI to read data from the multiple underlying data sources including package unit PLC and machinery protection systems etc.
OPC has a long history starting with the original OPC Classic (OPC-DA, OPC-A&E, and OPC-HDA) being the standard automation software interfaces for over two decades. Now the unified architecture OPC-UA has taken over as the standard automation software interface. Proxy/wrapper/gateway software to interface between older OPC Classic and new OPC-UA software is available. The NAMUR organization collaborates with OPC Foundation on this standard.
OPC-UA (like its predecessor OPC Classic) includes a flexible information model which organizes the data contents in a hierarchical tree structure and includes the metadata for the data. This framework contextualizes the data, usually per the ISA88/IEC61512-1 physical model of Enterprise\Site\Area\Unit\Equipment etc. making the data easy to browse, find, and use with minimal configuration effort in the client software.
Data Direction Control
Data direction control is a mechanism to protect the DCS and the data in it. A bidirectional DCS interface direct to the DCS database would enable other software to write unsolicited changes to the DCS database which could jeopardize the integrity of the DCS. This is not permitted in NOA. All systems shall follow the security by design principle in the IEC62443 standard. Therefore, OPC-UA provides a form of data direction control. OPC-UA has a client-server architecture with read-only option: clients make read or write request to a server for a specific piece of information. Only configured pieces of information can be accessed. The OPC-UA server should be designed to enable configuration to accept reads or writes to each piece of information. By configuring a parameter as read-only, it cannot be written. Thus the OPC-UA server provides data direction control. That is, data can be made to flow in only one direction. There is no direct writing to the database provided. Thus there is no influence from M+O on core process control availability and safety. An OPC-UA data diode is another future possibility to reduce complexity in corporate infrastructure and work processes.
Similarly, gateways and linking devices with HART-IP, FF-HSE, and PROFINET-IO should be designed to enable configuration to accept reads or writes to each device.
There are also a number of plants that have deployed DOI for M+O without any connection to the DCS. This solution is suitable for many use-cases such as vibration, steam trap, and corrosion analytics etc. which are sensors which have no connection to the DCS.
DCS OPC-UA Client and Verification of Request
The DCS OPC-UA client software reads data from M+O software in the DOI. It converts the open OPC-UA interface to the proprietary DCS protocols and data formats for the DCS to easily read data from M+O software in the DOI. That is, OPC-UA is also a means to get data from M+O into the DCS for CPC functions. For instance, Advanced Process Control (APC) is located in the DOI then the DCS must read the APC outputs.
Note that the M+O software in the DOI doesn’t “write” or “push” the data the DCS. OPC-UA has a client-server architecture meaning the DCS OPC-UA client must send requests for the data it needs to the M+O software OPC-UA server which responds with that data. The DCS only gets the data it needs. No flooding with unsolicited data.
Verification of Request (VoR) is one of the security mechanisms in the NOA to make sure requests come from trusted M+O services, are syntactically and semantically "clean" (verified), and that the DCS is protected against request flooding. Therefore, OPC-UA security provides peer authentication to ensure it reads data from trusted and authorized M+O software in the DOI. Message integrity protect against malformed messages. In OPC-UA the DCS OPC-UA client must request data. It only requests data it needs, so it doesn’t get data it doesn’t want. There is no flooding. That is, when the DCS OPC-UA client receives the response it will verify it as per security by design principles.
Measurement and Control (M+C) Devices
Traditional Measurement and Control (M+C) field devices include M+C sensors plus actuators and valves at level 0 connected to the DCS I/O at level 1.
M+C Device Auxiliary Measurements
M+C field devices such as sensors for pressure, temperature, flow, level, and analyzers, as well as valves and electric actuators etc. have auxiliary measurements that can be used in M+O software in the DOI as an additional data source. Digital networks like WirelessHART (IEC62591) and FOUNDATION fieldbus (IEC61784-1 profile 1/1) enable access to further data from existing devices. The NAMUR organization collaborates with the FieldComm Group (FCG) and Profibus User Organization (PNO) on these standards. PROFIBUS-DP (IEC61784-1 profile 3/2) and PROFINET-IO (IEC61784-1 profile 3/5) are ideal for motor controls. These standard protocols are all open interfaces, not proprietary interfaces.
The NAMUR organization has the intention to drive development of IP based fieldbus technologies over the Advanced Physical Layer (APL) for the next generation of real time communication for safe and reliable plant operations.
M+C Device OPC-UA Server
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
