Historian for SNAP PAC

Great topic and one which I am happy to weigh in on…

Our plant has groov EPIC and Rio units (no SNAP PAC stuff). On the EPICs we are running PAC Control Programs, while the Rio’s are used mainly to grab various I/O info (temperatures, on/off status, etc.). We do not have 1000s of tags on our PAC Control programs, but we do have perhaps 100 or so, but I do not think the number of tags to be stored with 1 second resolution should be an issue.

Overview:

  1. groov EPIC & Rio units do their thing and every bit of info they have is accessible via Node-RED. We use the InfluxDB node to send our data to InfluxDB. We also have MODBUS data from controllers, etc. and locally generated MQTT data being grabbed via Node-RED and being sent to InfluxDB.
  2. Field values and tags are ingested into on-prem InfluxDB (v2.7) with values every 1 second.
  3. On-prem Grafana OSS (v. 11.2), running on the same Ubuntu server as the InfluxDB, is used to display / chart and alert users on anything going wrong. Approx. 25 users are viewing Grafana at any time and there is no latency or delay.

Nobody but me goes into InfluxDB. That’s just the database that nobody needs to look at. Everyone (even low tech people) uses Grafana and finds it easy and intuitive using the time selector. It’s easy to build different dashboards, charts, etc. for different needs. We regularly destroy and rebuild dashboards and are continuously making things better.

We have about 5 years of data in InfluxDB and have no trouble querying large spans of data over this time period. The queries are all written in Flux and are very performant. The key is to very carefully plan out your fields and tags. This video is ~8 years old, but I still found it valuable to help plan out everything.

2 Likes