Industrial Data Xchange

This case study describes the process, the challenges and the outcomes of a historical data migration project. This project consisted of migrating data from two Wonderware (Industrial SQL) Historians to a single OSISoft PI Historian. The PI Historian had replaced the InSQL Historians, but this resulted in valuable historical data being split across three historians. By migrating the historical data from the two InSQL Historians to the PI Historian, all the historical data became available in the PI Historian, and the two InSQL Historians could be decommissioned. We will refer to the 2 InSQL Historians as ‘InSQL 1’ and ‘InSQL 2’. These two historians had the following properties: InSQL 1: Time span: 4 year and 7 months. No. of Tags: approx. 23 000. InSQL 2:  Time span: 1 years and 11 months. No. of Tags: approx. 40 000. The InSQL Historians not only overlapped in time, but also had common tags which extracted their data from the same source. The tags in the PI Hist

When an organisation makes a decision to introduce a different Plant Data Historian the requirement to retain visibility and access to existing historical data can be a challenge. There might be multiple years’ worth of valuable plant data associated with the legacy Plant Data Historian which somehow needs to be migrated to the new Plant Data Historian. Typically the same or a similar tag set is established on the new Data Historian and plant data will start to be recorded in the new system. There might be a switch over period where both the old and new systems each record data until the Plant is convinced that the new system is fully commissioned. All reports and web-portal views will now reference the new Plant Data Historian. Data migration is typically done in one or two tranches and the legacy Data Historian is finally decommissioned and all costs associated with its maintenance cease. In our experience the users of plant data are not empowered to attempt this onerous

Organisations that wish to change the data Historian they use are often faced with the challenge of what to do with the data contained in the existing historian. Simply powering the old historian server off is usually not a viable option, and maintaining two parallel systems introduces additional complexity and cost. Clearly, migrating the data in the existing system to the new system is the preferred route, but when large quantities of data are involved over extended time periods, this is not as straight forward as it may appear. Historians often include tools such as an OLEDB client that can be used to import data from other OLEDB-compliant sources. These tools are usually fairly limited, single query-based affairs that return and insert data in large lumps and tend to be slow given the quantity of data queried.  Also, the data is inserted blindly into the new historian, without providing any way of validating the inserted data, bar manually eye-balling trends of the inserted

Tag management of real-time data systems can prove challenging. As an industrial IT company we frequently come across the problem where tags need to be migrated from one system to another or where tags need to be synchronised and maintained between systems including historians. Generally, this ends up being a manual process, often involving Excel and much diligence and patience of the maintainer’s behalf. IDX Unifig was the first incarnation of a tool we designed with the aim to simplify the migration and management of tags between systems. The tool worked, but with as with most first editions of software tools, we could see the need for improvement and refinement of the approach used. Thus Tag Manager was born, and has become the key stone in the IDX 8 software suite. All other IDX 8 modules, such as Data Exchange, Alarms and Events and the Historian use Tag Manager to store and reference tags. The comparison result we like to see - no changes.   Tag Manager employs a plug

Data Exchange has been the core of the IDX suite since its first inception in 1995. Data Exchange allows real-time tag data to be shared between various, usually incompatible, systems with IDX being the intermediary that converts the data between the systems.  Up to IDX 7, IDX was exclusively a Data Exchange engine with a reliable industry track record. IDX 7 still exists today, and provides the bulk to the Data Exchange requirements to service our clients’ needs. This includes special connectors such as the Gensym G2 Expert Sytem bridge, as well as more common OPC DA, MODBUS, and OPC DA tunnelling via TCP. IDX 8 introduces its own implementation of the Data Exchange engine. The intention is to mirror the functionality of common IDX 7 connectors, such as the OPC DA client, in native IDX 8 connectors to provide general data exchange ability to service functionality such as Alerting (more below). However, in the near future, the IDX 7 runtime will become a “proxy” data exchange engi

Industrial Data Historians are fairly common place. Generally they fall into two categories: enterprise-class historians such as OSISoft PI and Wonderware Historian, which bristle with features and carry a correspondingly enterprise-class price tag, and then there are the “cheap” historians (or sometimes glorified file loggers), that log data, but usually have significant performance or other functional limitations. The IDX 8 Historian is aimed at users that don’t want to spend the earth to get a solution that fits in between these two cases, that will provide data logging that is extensible to fairly large capacities and without the multitude of features most users don’t know how to or even wish to use. Our historian is built on Microsoft SQL 2008 (or above). Certain features introduced in SQL 2008 have made it viable to implement data logging with performance we were happy with (rough ball park figures show we routinely achieve around 20-30K sustained writes and 30-50K reads