We help clients create trusted data for critical operations.

We create IoT solutions that transform how our customers manage their business assets

need-advice
need-design-help
need-support
solutions that transform

Enterprise Information Solutions

Enterprise Information Solutions has a wide scope of software solutions 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. At the core of Industrial Automation, is SCADA and Process Data Historian. 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 is in the order of 99.999% available.

Parasyn designs, implements and supports various process historian technologies for industry. We also procure and provision the software products, transition onto existing data centre infrastructure or work closely with 3rd party service providers or 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 which include process data historians can create a world of pain if not approached from a system’s engineering practice perspective (OT – Operational Technology bias).

Organisations which take an enterprise view of SCADA sourced data, widen their scope and improve operations as the feedback loop envelope for operational systems widens. This is more a human interaction activity than anything, however the technology platform exposes the data sets so that humans can consume and demonstrate their findings with ease. For repeatable processes, these optimisations can be captured 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 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 some other “visualisation”, is only as good as the underlying data. If you need help deciding what to use or how to design your first or next system, this is something we love to help with.

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).

Time Series Historian

High performance 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 sequence of the events as they occurred even if the data was received out of sequence.

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 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.

Enterprise Data Historian

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. Those days are over.

Enterprise Information Systems

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. Getting this right is something Parasyn can help you with.

Operational Historian

When the data storage platform is appropriately implemented and operational, it opens the flood gate to other enterprise applications including 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 as an enterprise historian is used to mimic or present aggregated values rather than the single source of truth main repository. However, there are high end historians suitable as a single layer Tier 1 Historian. With this model, cascading is not required.

When choosing a Tier 1 Enterprise Historian, it often comes down to price as the top performing products outperform other products available in the market place. The product features to carefully consider in detail are listed as follows:

  • Production Server price (this is the core product)
  • Production Server price to support high availability or redundancy. These are not necessarily the same thing.
  • Pre-Production Server (expected to be a lower cost that the Production Server), Test Server, Development Server.
  • Enterprise connector access (SDKs, API and other interfaces). It is important to understand how this affects the licensing and costs.
  • Webserver Licensing
  • Interfaces (e.g. OPC, OPC HDA, DNP3 etc). Be very clear and specific. Some interfaces are out of the box however, they may not meet operational requirements.
  • Web Client Licensing (unlimited, per seat, etc)
  • Desktop Client Licensing (unlimited, per seat, etc)
  • Application Add-ins (e.g. Excel)
  • Manual Data Insert (Tool for Operator inserts)
  • Asset Hierarchy Model which supports multiple views (e.g. Asset, GIS, Devices etc)
  • Support for Business Intelligence (dimensionalised data sets which reduce the need for complex data manipulation)
  • Analytics (Alerts, Events, Notifications)
  • Annual Support cost as a percentage of which Price List
  • Price Breaks for extending the license to expand the system
  • Local or International pricing (are you exposed to variances)

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 be 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.

What is the role of a relational database for Industrial Automation?

Even the Tier 1 Historian Vendors embed relation 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:

  1. 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.
  2. 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?
  3. 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.

 

SCADA Relational Database interfaces though functional on some products should be outward going only. Best practice is to avoid external access into SCADA unless very tight controls are imposed on the interface to limit performance degradation which can lead to data loss and operational issues in the SCADA system.