Architecting for the Unexpected
When deploying an EIDI system across one or more operating facilities, it is essential that subject matter experts, business users, and software applications are able to access and ingest information about various aspects of the operating facility without having to know the unique features of the plant equipment, its control system, or its instrumentation nomenclature. The way to do this is through an asset framework (AF) model that we have described in the various chapters of the book. Through use of these meta-data models, a layer of standardization is created for consistent data access, online analytics, and real-time notifications. The mechanism to accomplish this is to build standard, reusable templates (think of them as Lego blocks) so that portions of an operating facility or an entire plant can be reconstructed virtually as a digital twin in the span of weeks or months, not years.
Over the past few decades, we have seen many enterprises revise or refocus their strategic business objectives. To accomplish these goals, many companies must sell and purchase operating assets that are more closely aligned with these new goals. We all have witnessed many mergers and acquisitions to achieve these objectives. In any case, these new operating facilities must be brought into the infrastructure of the acquiring enterprise. To do this without these standard building blocks (templates) is a daunting undertaking.
Effective Use of Analytics
As we write this book in early 2020, it seems the answer to every question in the world can be solved by advanced analytics and artificial intelligence (AI). While these technologies are powerful and solve many things, we have found that not all analytics are cloud-based or require AI. Our most successful customers have developed an analytics strategy that categorizes analytics from technical to business related and from simple operating calculations to complex and predictive analysis to integrated real-time business optimization. The best practice that we have found is to distribute the analytic as close to the edge, or to the manufacturing sensor, as reasonably possible, but no closer.
The reasons for this are speed of resolution, elimination of duplicating or transporting the data to different physical environments, and reduction of required labor. An EIDI system is quite capable of integrating time-series data and executing online analytics, whether diagnostic or descriptive. Some predictive analytics may be done within the EIDI if the EIDI has future time capability.
Complex modeling, rules-based analytics, data-based analytics, broad predictive analytics, and most business and financial analytics that integrate operations and production data should be performed with a specific time domain and scope relevant to the data and value. Often as the scope of data increases, the need to do this at the edge is lessened. The scope of the data (one or many sensors/sites) and the integration of multiple data sources will drive analytics to a more centralized configuration. These can be either on-premises or cloud-based. For those analytics, we recommend standard software utilities that extract, cleanse, contextualize, and publish data as input to analytics, machine learning, and analysis studios. Please refer to Chapter 10 for a more extensive description of this capability.
Self-Serve Access to Needed Information
The most successful enterprises set up work processes and software systems so that everyone needing the EIDI information has access to the information they need in the way they best consume it. Eliminating data silos and removing gatekeepers of information certainly help, but any EIDI system should be deployed in a manner that everyone can visualize, analyze, or configure what they need with a minimum of assistance. We have also seen a great many companies democratizing the information, allowing everyone from management to specialized knowledge workers, subject matter experts, operations, and maintenance personnel access to key information at all times, from any place via mobile devices. To do otherwise would be to take a fundamental tool out of the hands of the user. Imagine if spreadsheets needed to be created by an central IT-only function.