[liketochill]

It is strange that there isn’t more overlap between tech software monitoring and metrics products and industrial historians and HMI products. Osisoft was purchased by Aveva/Schneider for 5 billion despite them already owning citect, wonderware, and probably 6 other historian products.

The industrial historians solve the same problems - collect data at nodes that might have intermittent connectivity, send to a centralized server/service that can handle lots of data, and allow users to plot it.

I wonder if we’ll start to see more open source monitoring on the factory floor. While it will be easy for a product to work as well as industrial offerings, maybe their value is in the long term support (usually close to a decade) and supporter upgrade paths.

[zwayhowder]

At my work (A university) We setup a TIG stack to monitor IT systems and then one of our facilities management people saw it and we got chatting. We have just setup a POC to pipe metrics out of multiple proprietary building management systems into a single Grafana dashboard.

We've also updated all our tender documents for future projects to include a requirement that we can query metrics and logs through an API or direct DB access.

A recent project I worked on identified over 500 applications whose only use is to provide monitoring to a bespoke system or tool. This isn't uncommon at a university as different faculties and departments will buy "the best tool for XYZ" without ever asking IT if perhaps there is a tool that is almost as good that we already have.

[camtarn]

Yes, agreed. This is basically what we do at my work: plot stuff from PLCs onto Grafana, while coping with intermittent connectivity. I'd love to buy a ready-made product that could do it, but there's literally nothing out there that quite comes close.

As well as the things you identified, I suspect that there's just a lot of mistrust of open source in the industrial world - there's that whole thing of perceived value being directly proportional to product cost, plus commercial vendors also tend to at least offer training and tech support, even if they're not always the most helpful.

[jimmySixDOF]

A roll your own open source method works if you have a good low level understanding of what you are listening to and can organize your own alarm thresholds and groupings etc. Dealing with a large number of modbus/BACnet endpoints with vendor specific device profiles and PLC logic means the vendors backend systems will handle events and trend paterns better than what most facility teams can put together. However, the history retention data by itself will have more flexibility to do it yourself, I do agree with that.

[mhall119]

There are open source projects like EdgeX and Fledge that can do this also

[liketochill]

Wonderware historian, inductive automation ignition, and osi pi all can buffer data at a collection or edge node that it collects from a Plc and then forward it on to the central database historian when connectivity is present. Grafana might have a better web ui but they all offer some client for plotting.

I am curious in what regard nothing comes close to grafana? I am Currently paying a lot for citect and wonderware support across a couple dozen facilities.

[camtarn]

We're a bit of a weird case in that we log data at 20Hz and 100Hz for prototypes, so we need custom queries and/or aggregation to reduce that down for display. We had a good chat with Inductive earlier this year, but even they said that might be a bit much for them. Other than that, though, Ignition is literally everything we want in a single product.

[liketochill]

You are logging data in to grafana at 100 Hz from a Plc? That’s pretty quick for a plc, I’d definitely have either a tiny program or a fast periodic task to be generating new samples every 10 ms, although I’m sure there are faster PLCs out there than m340

[camtarn]

Hehe, yeah. We run B&R PLCs which are fairly beefy Atom processors under the hood.

[mhall119]

Telegraf can do this too, in a more limited capacity. It keeps an in-memory buffer of collected data points so if a write to an output fails it'll try again on the next interval without losing the data it has already collected.