Key activities to improve value return from an established AVEVA PI System

Synopsis

An AVEVA PI System performs a crucial role within many industrial organisations in ingesting, storing, contextualising and serving operational time-series data to end-users and business systems.

As the system grows, organisations face challenges in ensuring high value use cases are realised, and maintained:

• Security and reliability of the PI system becomes increasingly important as business dependency grows, and especially when interfacing with critical operational technology (OT) networks
  • For backwards compatibility, the PI system supports a broad range of application security configurations, including authentication protocols which are now considered legacy and less secure.
  • The PI System typically spans corporate networks, border zones/DMZ and OT networks. Legacy integrations may not meet modern security standards.
  • Enforcing Role-based Access Controls (RBAC) is critical for securing data, both to ensure integrity by only allowing authorised writes, but also in restricting read access to sensitive data which is subject to regulatory restrictions.
• Data quality management effort increases as point count grows or assets change – and may be exacerbated by long-existing issues within SCADA/control systems or instrumentation
• Traditional OT architecture patterns struggle to support modern usage at scale
  • The shift towards more distributed assets (such as battery systems or renewable generation), as well as a general increase in the volume and resolution of signals required to support industrial analytics poses a substantially larger bandwidth demand on OT networks
  • The traditional model of utilising centralised local interfaces against SCADA historians or RTUs is not horizontally scalable, or practical to support with these distributed assets,
• Industrial Analytics often require time series data to be used in combination with other business data sets
  • Relational sources such as asset management records, metering, MES or LIMS systems are often analysed alongside corresponding time-series measurements.
  • It is common for these systems to adopt unique identification standards and data structures – which can be difficult to link together.
  • Engineers and Data Analysts expect to use familiar tools (such as Python or R based notebooks) to interrogate, merge and analyse data from these various sources in a straightforward and efficient way.
  • Enterprise Technology teams expect operational data to be made compatible for use in enterprise information and reporting systems, without requiring proprietary technologies or protocols.

This paper outlines four key exercises which we endorse as best practices for maximising the value of the PI system, minimising waste and mitigating typical pain points: 

1. Getting the house in order – a secure, stable and streamlined system
2. Formalising the role of the PI System within the broader Operational and Information Technology architecture
3. Utilising Asset Framework to translate operational signals to an enterprise compatible data structure
4. Augmenting native calculation technologies

Getting the house in order – a secure, stable and streamlined system

Performing a technical review of the PI System can both identify areas for immediate improvement, and serve as a foundation before conducting a broader, future state architecture review.

Depending on the findings of the review, a system upgrade migration may be warranted – or incremental improvements may be applied in-place.

Typical areas of focus include:

• PI Data Archive sizing, configuration and general health
  • Reviewing hardware sizing and utilisation – and potentially increasing resources as an immediate step
  • Examining operating system and application logs for errors which may indicate performance or security issues
  • Reviewing and validating the backup scheme
  • Reviewing and testing PI collective failover (if applicable)
  • Reviewing archive files for corruption or integrity issues, and reprocessing if necessary
  • Reviewing Data Archive tuning parameters and general configuration

• Patching of critical vulnerabilities
  • Reviewing currently installed versions for all PI System software components and applying critical security patches.

• System and Network Topology
  • Reviewing application configuration, logs and documentation to document all hosts and application components of the system, as well as interface/ingestion sources and downstream system connections
  • Use of network zones and compliance with internal and industry standards (such as IEC 62264)

• System security and Access Management model
  • Assessing use of Windows Integrated Security and Active Directory for system and data access controls, and migrating any legacy application-based methods (such as PI trusts or PI users)
  • Design of the PI role-based access control (RBAC) model, and implementation across PI Data Archive, PI Asset Framework and PI Vision
  • Compliance with internal and industry standards (such as IEC 62443)

• OT Ingestion patterns
  • Reviewing the use of legacy protocols such as OPC DA/HDA and considering adopting more modern and secure protocols such as OPC UA (for minimal refactoring) or MQTT (for greatly flexibility, horizontally scalability of sources and alignment with industry standards such as Unified Namespace).
  • Reviewing the use of legacy PI System integration technologies such as PI Interfaces and PI Connectors, in favour of the modern PI Adaptors.
  • Assessing data availability and completeness needs including the use of buffers, redundant data feeds (with or without high availability failover) and the inclusion of site historians for local access. This can highlight both areas where more robust reliability measures are needed as well as overengineered integration which present an opportunity to reduce ongoing costs and simplify support.

• Deprecated technologies which should be substituted out and retired
  • Engaging any end users still utilising PI Processbook (now end-of-life) and developing a migration strategy to PI Vision and third-party tools
  • Identifying any use of PI Manual Logger which may be migrated to an alternative technology (such as enterprise web forms)
  • Assessing use of PI Egress technologies (PI OLEDB Provider, PI OLEDB Enterprise, PI SQL Provider) which may be migrated the PI SQL RTQP based clients, or PI Web API based queries.
  • Reviewing PI Performance Equations and PI Totaliser calculations which may be refactored in PI Asset Analytics
  • Formulating a strategy for migrating more complex, legacy PI ACE models, which are not practical to migrate to PI Asset Analytics – see the later section for further discussion.

Formalising the role of the PI System within the broader Operational and Information Technology architecture 

While achieving a stable, secure and efficient PI system is an immediate priority, an important subsequent step to improving the ongoing utilisation of PI data is to correctly define the role of the PI system, as part of a broader data and technology ecosystem. 

Historically PI was seen as the final technology stage when accessing operational data – the majority of end users would directly interact with the system through tools such as PI Processbook and PI Datalink/Microsoft Excel.  Technologies such as the PI ACE engine performed the role of an industrial analytical engine and the majority of data driven insights were both developed and consumed within the PI system.

These solutions were valid for the time, and effective – however organisations increasingly faced challenges around scalability and supportability as the demand for, and availability of data increased.  There still is an ongoing need for PI native client tools for general business users; especially PI Vision – however many proactive initiatives such as predictive maintenance, condition monitoring and operational or dispatch efficiency models require a broader set of tools and processes to fully realise. 

In today’s data and technology landscape: 

• Both end users, and dependent applications require a consistent, structured view of operational datasets which supports templatised and dynamic queries against classes of assets. 
• Operational end-users are seeking to seamlessly leverage PI data with off-the-shelf industrial intelligence technologies as front-line tools 
• Specialist information producers such as engineers, data analysts and data scientists require broader sets of data (e.g. relational data from business systems) and want to use the tools they are familiar with (Python/R notebooks, specialist engineering application, cloud-based data platforms) – this is further discussed in the later section. 
• Enterprise IT and support teams want to consolidate to standard technologies and patterns 
  • Use of cloud-based object storage, modern Lakehouse platforms as well as traditional Data Warehouses are often first-choice for staging and merging data sources from across an organisation 
  • Standard protocols (MQTT, ODBC) and APIs (RESTful Web APIs) are easier to develop against and manage than propriety integration technologies for each system 
  • Enterprise BI tools such Power BI, Tableau and Amazon QuickSight are often the end-user visualisation tools of choice, especially for presenting curated data in an interactive report format 

A modern and enterprise data ready PI system: 

• Serves as the source of truth for operational time series data 
• Continues to perform a critical role in providing real-time, operational dashboards and trends through PI Vision 
• Utilises the Asset Framework layer to present a conformed view of operational time series data which employs enterprise compatible asset identifiers and hierarchal structure 
  • This is a departure from the traditional approach of designing an Asset Framework structure as an all-encompassing “Operational data source of truth”.   
  • Instead, the goal is to make PI data accessible, unambiguous and readily combined with broader data sets; recognising the shifting role of PI from an end-data-state to a mid-data-state system. 
  • Within AVEVA CONNECT Data Services, the same identifiers and structure are converted to Stream metadata and Assets for data linkage 
  • Embedding of relational data in Asset Framework tables is minimised apart from providing asset identifiers 
• Employs the PI Asset Analytics engine to cleanse and standardise time series data – utilising the Asset Framework structure and templatised analyses to scale efficiently – but delegates more complex analytical models to systems downstream of PI – see the later section for further discussion. 
• Depending on the cloud strategy of an organisation: 
  • Utilises AVEVA PI Agents to integrate the PI System with AVEVA CONNECT Data Services (CDS) – which may then be leveraged by industrial intelligence tools within the CONNECT industrial data platform, while simultaneously integrating into more general-purpose cloud-based data platforms – via native connectors 
  • Provides cloud-ready, direct integration patterns based on the PI Web API, which depending on use cases, may involve batch, continuous streaming or data virtualisation into Azure, Amazon or other cloud vendor-based data and analytics platforms.  Operational time series data may be then incorporated into enterprise data warehouse/lake house platforms, BI/reporting tools, advanced analytics/machine learning models, or third-party specialist engineering applications.

Utilising Asset Framework to translate operational signals to an enterprise compatible data structure

Although Asset Framework provides the flexibility to create any number of hierarchies, the first priority should be defining an enterprise data view of PI data – which is compatible with organisation endorsed asset identifiers and structure.  The rationale and benefits of this approach are as follows: 

• When data is being consumed downstream of PI, it is more important that the structure it is presented in aligns with enterprise naming standards then application or operations specific conventions 
  • Conversely, PI point tag naming generally reflects OT conventions such as nameplate identifiers – and is available as a method of querying data if direct end users of PI require it.  Asset Framework provides the mapping between these two conventions. 
  • Other naming structures may be subsequently developed within Asset Framework if required 
• Although a complex task, many organisations are gradually developing and embedded common data models (CDM) across systems – sometimes even OT systems as in the emerging Unified Namespace standard.  Aligning Asset Framework to the CDM is future proofing the data structure. 
• Mapping of identifiers is required within Asset Framework regardless of the target structure.  Choosing to align to an enterprise naming standard here removes the need to develop additional mapping logic and transformation steps within the enterprise data platform. 
• A well-structured Asset Framework structure is highly beneficial prior to establishing a CONNECT Data Services tenant: 
  • Although CDS does not directly implement the Asset Framework hierarchal structure, the Stream Metadata Rules and Asset Type features can store this hierarchy and template information, enabling the same benefits of data structure and linkage when integrating data from CDS into models and other data systems. 
  • As assets change within Asset Framework, CDS can dynamically reflect these changes in downstream queries 

There is no singular approach to defining an enterprise data view within Asset Framework, however the following recommendations may assist: 

• The PI System should not define the data structure or naming conventions – Asset Framework should align to an endorsed organisational standard. 
• Data structuring and identification standards are available for certain industries, such as the Common Information Model (CIM) defined in IEC 61970-301 within the electricity utility sector.  Aligning where possible to such standards improves compatibility of data and ease of joining or merging datasets. 
• Aiming for a minimal level of depth and ensuring assets of the same type are located at the same depth are generally accepted practices which improve useability. 
• It may not be necessary to populate the entire hierarchy immediately.  Establishing a representative sub-structure may be sufficient to design downstream integration and realise use cases with immediate value return. 
• Optimate endorses the following technical practices for Asset Framework development: 
  • Ensuring Element names are unique – for example using “Site A-Pump 1” and “Site B Pump 1” rather than simply “Pump 1” for both elements.  This allows elements to be searched for directly, without using metadata of pathing information, and offers an improved user experience in native tools 
  • Ensuring all Elements are based on templates and extending elements is disabled.  This ensures predictability and enables dynamic queries across asset types. 
  • Utilising common base templates and template derivation.  Attributes common to all instances of an asset class may be defined in a base template e.g. “Pump”.  Signals specific to only a subset of assets may be defined in a derived class, which may represent a specific location, model or asset configuration.  This approach improves manageability of templates and supports differing asset configuration while still enabling comparison analysis across broad groups of assets. 
  • Utilising PI Point name substitution rules within attribute templates.  Directly maintaining PI Point mappings within Asset Framework is time consuming and impractical at scale.  Even if some exceptions are required, adopting a default approach of using substitution parameters and metadata within Asset Framework to indirectly map PI Points is a far more sustainable approach, 
  • Ensuring that Asset Framework developers are trained, AVEVA certified and experienced.  Whilst Asset Framework is flexible and approachable to develop against, there are common pitfalls which can lead to a non-performant system, or simply a data structure which is difficult to leverage. 

Augmenting native calculation technologies

The majority of insights derived from operational data require a degree of transformation, or calculation. 

The PI Asset Analytics engine is an accessible tool, which is designed to dynamically leverage a templatised Asset Framework structure to efficiently manage multiple instances of standard models.  It is well suited for: 

• Data cleansing – such as filtering out of range values, error states and correcting for accumulator resets 
• Time interval normalisation – applying sampled interpolation or time aggregation to raw signals and conforming to a fixed time resolution 
• Performance Equation/Single-line formula expressions – as streaming calculations against real-time data 
• Event detection – based on rising edge or threshold rules 

These features – and the coupling with Asset Framework make the PI Asset Analytics a powerful tool for: 

• Preliminary, data preparation 
• Single line, pointwise expressions performing engineering and business logic transformations for PI Vision dashboards. 

As organisations mature in their utilisation of the PI System, they may experience limitations in realising data transformations via PI Asset Analytics alone.  Key indicators for when an alternate, or augmented solution is required include: 

• Looping or recursion is required 
• Statistical or machine learning models are required 
• Event detection involves frequency domain analysis or use of trained models (e.g. anomaly detection) 
• Transformation is required in batch, or with significant time delay 
• When there is a high degree of dependent steps across the hierarchy, and using Asset Analyses would cause the solution: 
  • To be less performant 
  • Consume a high number of tags 
  • Become difficult to manage and troubleshoot 
  • In general, a script or routine would be more suitable 

In these scenarios, a third-party calculation engine, or an off-the-shelf model will be better suited.  The choice of technology will depend on both the specific problem, and the broader architectural strategy of the organisation.  As a general rule, Optimate recommends performing business analysis to define archetype transformation and analytical use cases, and from this analysis, define a minimal set of architectural patterns.  Example patterns may include: 

Conclusion

The PI System is an investment in operational data and insights to drive decision making and timely intervention of emerging plant issues. The four topics outlined in this paper can provide a starting point for reviewing the state of this investment, and ensuring that it continues to provide optimal value to the organisation.