Feeling trapped by your Vendor

Unfortunately this is a common phenomenon. The forces of supply and demand and customer need can mean that you do not always receive the service you pay for or deserve. Perhaps there is an option that allows you to demonstrate that "your need" is "a choice" without making any radical changes.

This article focuses on real-time historian and MES systems but hopefully is food for thought in other markets too.

Let's start by painting a picture of the scene. Your company has purchased licenses in a real-time historian product that carried a premium price tag at the time and also carries a significant annual maintenance charge. The value that this capability offers you is worth the cost but you do feel that ongoing improvements and product support received is declining in quality at a rising cost. You have voiced your concerns but it is falling on deaf ears and the invoices keep arriving. The system has 10-20 years of high frequency data stored in a proprietary filesystem, surely there is very little that can be done !!

Hold on a minute, is that really the case ?...

Aside from an intensive data migration from the existing system over to a new system which carries in itself a large price tag and a significant risk, "What else could I do ?".

 The example below show a process trend of 2 tags that used to exist on a Counterpoint supported real-time Historian that we will call "vendor A" and at 2 different points in time they were built and started collecting data on a different Counterpoint supported real-time Historian provided by "Vendor B". All Excel access, web based trending and web based mimics and calculations use the data provided by Counterpoint. They do not care if the underlying data source is "Vendor A" between 1st January 1990 and 25th March 2017 and that we switched to "Vendor B" at 10:00am on the 25th March for FI1004.PV for example. The end user accesses the data in a standard way and is totally unaffected by the underlying system or which vendor provides that service. The data is seamlessly collected and provided to the end user. This new build on another real-time historian can be done in parallel without affecting data collection to the original system.

That's all very good I hear you say but what about aggregated data ? It is true to that the core system aggregate functions provided by "Vendor A" will not be able to traverse the cut-over to "Vendor B" but the Counterpoint aggregates are unaffected. One hourly average may contain 40 minutes of data from "Vendor A" and 20 minutes from "Vendor B" but you still receive the correct hourly average values and status.

This capability can be used as a corporate standard with different underlying historians or as in this case where both Historians are retained for the same system. This obviates the need to move all of your eggs from basket A to basket B or feeling stuck with basket you were given 20 years ago. The suitability of this approach is largely driven by your licensing arrangements with your original vendor. If it is a service based license with an annual charge then it is unlikely to be cost effective. If you own the software then this is a more viable proposition. You would be looking to run an old out of support version for history data, the cut-over points for each tag would gradually fade further and further back with no new data arriving on that server. That stored data essentially becomes an archived copy and the risks of losing it diminish over time to some extent.

Having this capability makes it extremely easy to keep your vendor competitive, is does not mean that you need to change suppliers but it does mean that you can !