Your use case sounds a bit like a problem on my la...
# general
d
Your use case sounds a bit like a problem on my last job, where we tried to ingest data from the historian into a cloud data lake. The tag names in the historian were just like TI123/PV.CV (so just the IO tag). We ended up managing large Excel files for each historian that mapped the tag names from the historian to column names of a table in the data lake. So TI123/PV.CV -> temperature-123-process-value-percent. Honestly this approach was a complete mess to manage. I asked why we couldn't just connect the sensors to a UNS via MQTT to bypass the existing historian (ibaPDA), and just store the data in Timescale DB of the UMH. However, the company decided against it because 1) OT refused to give anyone access to the PLCs and 2) we needed some exotic features from the existing historian. Both of these points were debatable in my opinion. Not sure if this helps, but maybe you could check if you really need your current historian. In my experience, the historians I've worked with were more of an obstacle in an event-driven architecture