Enterprise Information Solutions can have a very wide scope of software components including SCADA Software, SCADA Historian (Data Historian for short), edge technologies like software device drivers, advanced applications, Control Systems, EAM gateways and the list goes on.
- What is an Enterprise Information Solution for Industrial Automation?
- Can Enterprise Information Systems be highly available?
- What are the benefits of enterprise wide SCADA
- Where is the data lake for Industrial Automation System?
- What is a Process Data Historian (Data Historian for short)
- What is a Time Series Historian?
- Who uses Enterprise Information Solutions?
- What data types does an Enterprise Data Historian include?
- How important is the selection of Enterprise Information System core technologies?
- Where are Operational Historians used?
- What are the important features or differentiators between the Tier 1 Enterprise Historians?
- What are the most common Tier 1 Historians?
- Can SQL or a relational database be used as an Enterprise Historian?
- What is the role of a relational database for Industrial Automation?
What is an Enterprise Information System for Industrial Automation?
At the core of an Industrial Automation solution is SCADA and a Process Data Historian (click here to learn about Industrial Automation). These mature product types have become the main staple for managing critical infrastructure associated with intelligent assets. Evidence of how stable some of these systems are, is measured in “up time”, and for some systems this is in the order of 99.999% availability. More recently, edge devices are increasing the data capture and intelligence capability placing even greater emphasis on the criticality of information infrastructure software components.
Can Enterprise Information Systems be highly available?
Parasyn designs, implements and supports various process historian technologies for industry. We also procure and provision all of the software products, transition onto existing data centre infrastructure or work closely with 3rd party service providers and the client’s internal IT personnel to scope and specify what is required to establish suitable software solution infrastructure. To achieve this, a managed service arrangement or a turnkey project structure can be the delivery platform. In the case of critical infrastructure High Availability components and products can be specified at the plant and enterprise level to ensure the necessary overall reliability is achieved. The specification, selection and licensing of enterprise information solutions can create a world of pain if not approached from a system’s engineering practice perspective (OT – Operational Technology bias).
What are the benefits of enterprise wide SCADA?
Organisations which take an enterprise view of SCADA, widen their scope and improve operations as the feedback loop envelope for operational systems widens. This is more a human benefit more than anything, however the technology platform exposes the data sets so that humans can consume trusted data and essential information and then demonstrate their findings with ease. For repeatable processes, these system wide optimisations can be captured using information management techniques and are less dependent on intimate user knowledge, which is typical for plant-based SCADA systems. The typical enterprise data consumer’s less “technical” perspective on “what they see” drives better metadata management adding context and meaning to everything the business does from that day forward. The business assets are linked to other enterprise systems.
Where is the data lake for Industrial Automation System?
The process data historian is the key software component for enterprise information solutions for managing critical plant, critical remote assets and metering devices. Virtually anything that is instrumented is ripe for “harvesting”. How the system is designed to reliably collect information is more than a basic opinion about which is the “best brand”. How the collected information is displayed, often by dashboards or other “visualisation”, is only as good as the underlying data. The data needs to be trusted. The data needs to be of value to the organisation. Data Management is key to creating a useful data lake which hosts process data. If you need help deciding what to use or how to design your first or next system, this is something we passionate about.
What is a Process Data Historian (Data Historian for short)
A Data Historian (also known as a Process Historian or Operational Historian) is a software application that stores and serves out production and process data to other software applications or consumers. A process historian differs to a relational database as it natively stores raw data as “time series” (value and actual time stamp). The Data Historian is typically high performance and is supplied with analytical client tools which bring raw data to life.
What is a Time Series Historian?
High performance data historians store time series data (i.e. the value of a data sample, the time and date and some metadata to provide context for the data sample) as efficiently as possible to minimise the disk space required. Fast retrieval is paramount for accessing the vast amounts of information gathered by process data historians. Information is stored efficiently in the sequence of the events (as they occurred in time) even if the data was received out of sequence.
Who uses Enterprise Information Solutions?
Governments, regulatory bodies and business have all been steadily increasing their demand for more accurate, validated and timely data. Organisation Compliance Reporting & Data Analysis requirements have therefore naturally become increasingly important as deregulation and privatisation takes a hold across the globe. Managing assets holistically according to how the business manages the asset and not how the operations group repairs and maintains the asset, no longer needs to be managed in isolation. mutually exclusive. More and more organisations are turning to enterprise data historians as the vehicle to store critical information that they rely on and trust. The strongest benefit of implementing and ENTERPRISE wide historian is sharing of information outside the boundaries of geography, divisions and areas of responsibility. The silos are removed.
What data types does an Enterprise Data Historian include?
When designed and implement correctly, an enterprise data historian creates a lifelong dependency for organisational user groups that are serious about sharing information and quality management.
Technology now delivers high speed data acquisition, abstracted data structures which fit specific asset models, mega storage, caching of enterprise KPIs and production performance management information. This means that at all levels of the organisation the appropriate information can be presented to all user groups. The enterprise historian liberates asset performance information and exposes information historically only considered precious by Operators and Maintenance personnel.
The data historian usually augments with other software tools to create data structures which can be harvested by business analysts and other data consumers who don’t need to understand how the data has been organised or “connected” into one view. Viewing data from an asset, geographical perspective or by instrument types creates a different value proposition for each user groups.
How important is the selection of Enterprise Information System core technologies?
The choice of which technology platform to use can be an expensive one. Overall, if the process data historian is over specified for the application, when expansion time comes it will be painful. Factors include; speed of data storage, storage efficiency, connectivity to source devices, interoperability, client access methods and speed of data retrieval. Each vendor’s product differs from another. None of them are the same. Getting this right is something Parasyn can help with.
Where are Operational Historians used?
Sometimes plant historians are required close to plant, which may or may not be remote to a centralised control room or the “head office”. Sometimes local historians are called plant historians. The value of plant historians is usually related to the need for the localised capability if the remote connection (internet or private network) is unavailable. When the local plant historian is tiered with an enterprise historian, the enterprise user does not need to be concerned with connecting to multiple systems. The value of tiering historians at the corporate level includes running enterprise class applications with may not be cost effective or even useful at the plant level. Some of these enterprise applications include asset optimisation, predictive analytics (machine learning), workflow, advanced analytics and production and compliance reporting.
What are the important features or differentiators between the Tier 1 Enterprise Historians?
Tier 1 is a generic term frequently used for the large and enterprise wide process historian. Local Plant Historians are usually not suitable for this type of application unless the architecture supports a cascaded model where the plant historian being used rolls up into the enterprise historian and is used to mimic or present aggregated values and the single source of truth. However, there are high end historians suitable as a single layer Tier 1 Historian which do not need to use a cascaded architecture.
When choosing a Tier 1 Enterprise Historian, it often comes down to price as the top performing products outperform other products available in the marketplace. The product features to carefully consider in detail are listed as follows:
What are the most common Tier 1 Historians?
To answer this question with a degree of accuracy, we first need to add context around the scope of the question to be answered. An enterprise may manage a handful of points and make use of any Industrial plant historian available in the market (eg Wonderware Historian, Aspen InforPlus.21, GE Proficy) to manage an asset or group of assets cost effectively. If the scope of the system is small and time series data is of little or no concern, then any relational database could be used. There is much hype around SQL/Cloud ready IoT devices that can be easily hooked up and produce suitable results for a very low cost. This is not what we are discussing here and is not a scalable solution. To qualify the answer, let’s restrict the scope of the Tier 1 historian to greater than 1,000,000 points (or tags). Taking this position reduces the options to OSIsoft Pi and Aveva eDNA (Formally Instep Software). This single qualification will rule out other important factors like the data acquisition rate which impacts on speed of storage and the cost of managing the data payload. It is interesting to note, that other Automation Vendors have been required to implement the above products when project specifications imposed by customers have outlined performance and speed requirements that only Tier 1 Historians can match. So, it seems based on the experience of those with very large systems, its PI or eDNA if you are trying to keep things simple.
Can SQL or a relational database be used as an Enterprise Historian?
If the answer to the question had to be one word and it needed to be answered with today’s technology, it would be; No. The emphasis here should be on the world “Enterprise”. For many vendors, including Industrial Automation Vendors who don’t own a Tier 1 Enterprise Historian, they often use SQL or Oracle as a means to an end. Putting aside data payload costs for the moment which is a massive show stopper in certain locations, by leveraging cloud-based servers with “unlimited” resources, relational databases are most certainly a viable option for low volume non Time Series data warehousing of process data. Because of the performance of cloud servers, it can appear that relational databases are also suitable for Tier 1 solutions, however this is not the case, yet.
What is the role of a relational database for Industrial Automation?
Even the Tier 1 Historian Vendors embed relational databases into their total solutions for organising information including Asset Hierarchy and enterprise integrations. This is what relational databases were designed to do. For the small end of town, it makes sense to use SQL/Oracle for everything. For the “big end of town” it doesn’t. Unfortunately, sometimes Operational Historian products (or SCADA products with a relational database interface), ie the lower end of town, make claims about storage rates, acquisition rates and storage capabilities. It is important to compare apples with apples when making these claims. Some items to consider are:
- Does the device support Time Series data (time and date stamping the events in the field device). This is not native for a relational databases and solutions that claim this functionality have masked the issue and produced work arounds. The astute end user may not be aware because the data volume rates and reporting requirements are minimal.
- Are the performance figures being quoted describing the cloud infrastructure or the performance of the instance of the Server farm that is being provisioned for the specific application?
- What are the security and multi-tenanting limitations imposed by the cloud technology provider (in some cases the cloud provider provisions a much superior solution so this must be considered in context with all of the requirements including scalability and cost per point). Size of the infrastructure is only part of the picture.
Relational database like interfaces to SCADA though functional on some products should be carefully implemented. Best practice is to avoid external access into SCADA unless very tight controls are imposed on the interface to limit bulk data access and avoid performance degradation which can lead to data loss and operational issues in the SCADA system.