The Frankenstein Automation Gateway can now write OPC UA tag values to the Apache IoTDB. Did some rough performance tests with 50 OPC UA servers and one IoTDB… the IoTDB is pretty impressive fast. Also the data model and terminology is interesting and it seems to fit good to a hirarchical structure in OPC UA.
In this lab I have connected 50 OPC UA servers (based on a .NET OPC UA server example) to Frankenstein. Each OPC UA server publishes 1000 tags of different type, so in summary we have 50000 tags connected to Frankenstein. The publish rate can be adjusted by setting an OPC UA tag. Sure, we do that via GraphQL over Frankenstein. On my commodity hardware I ended with writing about 250Khz to the IoTDB with an CPU load of ~200%. So, I assume the IoTDB is able to handle much more value changes per second.
Figured out that one DB Logger inside of Frankenstein roughly is able to handle 100000 events per second. We can spawn multiple DB Logger for scalabilty. Vert.X can then use multiple cores (Vert.X calls this pattern the Multi-Reactor Pattern to distinguish it from the single threaded reactor pattern).
Just to note: there is only a memory buffer implemented, so if the DB is down, then the values will be lost if the buffer runs out of space. But I think to handle such situations it would make sense to put Apache Kafka between the Gateway and the Database.
GraphQL Query to set the simulation interval:
query ($v: String) {
Systems {
opc1 { Demo { SimulationInterval { SetValue(Value: $v) } } }
opc2 { Demo { SimulationInterval { SetValue(Value: $v) } } }
opc3 { Demo { SimulationInterval { SetValue(Value: $v) } } }
opc4 { Demo { SimulationInterval { SetValue(Value: $v) } } }
opc5 { Demo { SimulationInterval { SetValue(Value: $v) } } }
opc6 { Demo { SimulationInterval { SetValue(Value: $v) } } }
opc7 { Demo { SimulationInterval { SetValue(Value: $v) } } }
opc8 { Demo { SimulationInterval { SetValue(Value: $v) } } }
opc9 { Demo { SimulationInterval { SetValue(Value: $v) } } }
...
}
}
Query Variables: {"v": "250"}
