44 lines
2.6 KiB
Markdown
44 lines
2.6 KiB
Markdown
# tech choices
|
||
|
||
## overview
|
||
|
||
the CIM itself is not prescriptive about how we should build interfaces, but most of the existing tooling is built around java.
|
||
## Data
|
||
|
||
### RDF
|
||
this is the main format used to store the huge graph of objects that make up the grid. you can see it in use in the [nordic 44 repo](https://github.com/statnett/Nordic44/tree/main/instances/Grid/jsonld)
|
||
comes in a bunch of flavours, this is heavily used in europe, even in the transport sector.
|
||
**schenider will love it if we start working with this.**
|
||
|
||
- `cimxml` – *IEC 61970-600-1*
|
||
XML text format, we will in all likelihood encounter this
|
||
- `jsonld` – *IEC 61970-553*
|
||
JSON Linked Data. also available and promoted by IEC but not as widespread
|
||
|
||
looking forward, this seems like a great tech to look into to store a graph of the network so we can extend the data the DERMS has / gives us with our own knowledge of the network. for example which DER are connected to which substation
|
||
### XML
|
||
the test script uses plain old xml as SOAP+HTTP as a sort of reference implementation.
|
||
without knowing much about our interface to gridsite / energisa they will likely want to use this as our interface.
|
||
conceivably would could do a whole SOAP+JSON+HTTP thing if we can get buyin from energisa, that would help reduce the appeal of java
|
||
|
||
### WSDL / XSD
|
||
when we actually get the models from IEC there are a bunch of tools we can use to codegen classes for whatever lang
|
||
https://github.com/cimug-org/CIMTool
|
||
IEC has a section about JSON schemas as well as XML. we can conceivably
|
||
|
||
|
||
## java
|
||
it might actually be worth it for us to just bite the bullet and build some java services. prabhu has some experience with it and so do i, while i'm away might be a good use of time to do some quick investigations and see how it feels.
|
||
|
||
https://github.com/apache/jena
|
||
apache db specifically for storing and querying RDF
|
||
aws has their own hosted version of this
|
||
|
||
## rust
|
||
most of my POC has been in rust because i think we can use its [into](https://doc.rust-lang.org/rust-by-example/conversion/try_from_try_into.html) traits to convert to and from different representations, it's super fast, the type system is really powerful etc etc.
|
||
there are some cool tools (alpha) like [camel](https://github.com/IkoAfianando/rust-camel) that use native java bridges to abstract away all the apache stuff and let you write rust business logic
|
||
reality is we might have to build a bunch of stuff ourselves if we don't want to use java/apache type tools, my preference would be to do it in rust because we can use them to write very high quality and fast code, as opposed to trying to strongarm them into making half decent python code
|
||
|
||
## python
|
||
|