Is cross system model synchronization still a nightmare?
How does everything know what’s what?
In any complex manufacturing environment, it is a real problem to ensure consistency across all the applications that care about the plant hierarchy – and believe me, there are a large number of systems that should care about it! The ERP system may care down to assets (or asset sub-assemblies if using SAP PM), reliability systems from the asset to the tag, maintenance systems need to know from the plant to the asset sub-assembly, document management needs the plant hierarchy, process historians the tag to assets, and – well, I think you get the picture. Many of these systems likely had an accurate version of the plant model when first implemented; it is reasonable to assume that for that snapshot in time they were correct. However, as the plant changes, names changes, assets get reconfigured and what was correct even a year or two ago may not be now. On top of that, if processes are inherited or moved, there may be multiple references for the same thing, which just causes even more confusion in determining what is what.
What’s the problem?
One of IT Vizion’s Oil & Gas customers was looking to define an asset model to support the configuration in their Maintenance Management System (MMS). This is important for a lot of reasons – it is straightforward to write work orders against an asset and get the work done. However, if you want to manage budgets, KPIs, define bad actors by class and other analytics, it is imperative to have an asset model to tie everything together. In addition, while building the model in the MMS is a valid approach, most MMS are not architected to support proper modeling, nor do they allow for seamless integration with other applications wishing to take advantage of the effort that went into construction and maintenance of the MMS model. It is a worthwhile endeavor, but it is a one-off approach that does not help solve the bigger problem of a common asset model.
Who knows the real asset model?
To solve this in a more generic manner, and ideally in a self-sustaining manner, the “owner” of the asset model pieces needed to be determined and have an understanding around the maintenance processes of those pieces. In this case, we were able to leverage work that was being done by the engineering team and their conversion of the plant process drawings into intelligent P&ID’s. This provided a managed data source that gave us the relationship between assets tied into the process units. This, coupled with the plant / complex / area / unit model coming from the financial systems gave us a complete plant asset model sourced from updated systems of record. Using the intelligent tag naming convention will allow us to complete the last step of bind the tags to the CAD defined assets – from plant to sensor.
Where to manage the Model?
As mentioned, the MMS permits the definition of a model but really is not built for complex inheritance models and master data management. Fortunately, the customer had OSI Soft Asset Framework, aka PI AF, which is a platform designed for building and managing complex process models. This environment not only allows us to manage things based on class templates, but also provides the flexibility for multiple references and multiple perspectives, as well as many other possibilities.
Synchronization
A comprehensive analysis was done to define what process owned what pieces of the information. Also, the types of supported change events were defined. Adds, deletes, and changes were included in the initial scope, but it was decided that deletes would be handled manually as there might be data artifacts that needed to be retained in some of the targeted systems. A decision was made for PI AF to own the asset class definitions as that platform “cared” more about the asset as a whole: what attributes and metadata defined the asset and had a repository in which to store it as reusable templates. To make the asset class available at the source – where the asset is actually being added to the drawing – the class list is pushed from PI AF to the CAD system for the operator’s selection as they are adding / modifying elements in a drawing.
Because the unit of work from the CAD team is a drawing, a work process needed to be defined that recognized when an approved document was posted for release. Workflow was created using Microsoft’s SSIS that allowed us to define business rules for data processing and minimize custom coding. This process resulted in an “integration registry” where all changes coming from the data sources were identified so they could be routed to those systems that registered for those changes. As changes are made in the integration registry, PI AF is updated to reflect those changes – the Asset Model is now in sync with the latest iteration of the processing drawings. Based on other rules, the integration registry can now take the model data from PI AF and style it in a manner that is appropriate for each targeted system. This allows synchronized updates triggered by an approved drawing by the engineering team to update the standard AF process model, and other systems updated based on that.
Initially, the update to the final systems is being done via a manual process so that the system owners can “approve” changes before they are pushed to their respective software. Ultimately, this will be an automated process.
Enhancing the Process
The Siemens XHQ platform is being used to provide Operations Intelligence process monitoring at this facility, and it was a simple exercise to extend that user visualization environment to include the status of the model synchronization, the log files, and giving approval for model updates. As the model is completed, the XHQ application will be switched to use dynamic modeling driven by the AF configuration so it too will be coordinated.
PI AF allows the ability to manage the asset classes as well as to monitor the created model. Additionally, complex event processing can be built on the AF classes and configured through event frames. The ability to build reliability KPIs on asset classes and for that information to be calculated in an automated fashion is just one of many examples of the value of building the asset model in AF rather than the MMS.
In this initial project phase, the MMS, PI AF, CAD, Microsoft SSIS, and XHQ products were defined to be in scope. However, the system will soon be expanded to include the reliability system, document management system, electronic permitting system, and others that are dependent on a process model. Data ownership will be extended, allowing attribute configuration from systems other than CAD or PI AF – where the MMS folks need to configure data pertinent to that asset, that data can be pushed to AF and to other systems. More and more capability will be added to the AF model classes to automate more complex calculations, KPIs and many other process data analytics that are now being done manually through spreadsheets.
While not complete, this 4 month pilot has gone a long way towards proving that the nightmare of cross system model synchronization can be a thing of the past!
Integration technologies/software used:
Source system:
CAD: Intergraph CADWorx: software that was used to create the P&ID drawing used as a source to create the asset model for the refinery.
Target system:
MMS: IBM Maximo: is an Enterprise Asset Management system that provides comprehensive support for asset, maintenance, resource and parts supply chain management needs.
Supporting Systems:
DB: Microsoft SQL Server & SSIS: software used to manage the integration registry and to define the business processing rules.
Historian: OSISoft PI Asset Framework: software used to store centrally the hierarchical asset model of the refinery.
Data Visualization: Siemens XHQ: software used for operations intelligence – to support plant KPIs, event notification and process analytics.
Maximo® is a registered trademark of IBM Corporation. PI Asset Framework® is a registered trademark of OSISoft, LLC. CADWorx® is a registered trademark of Intergraph. SSIS®, SQL Server® and Visual Studio® are registered trademarks of Microsoft Corporation. XHQ is a registered trademark of Siemens Corporation.