Pointers to implementing a new Tag-Historian for Apache IoTDB?

Hi,
I am currently working hard on getting Apache IoTDB deployed on various platforms, that would benefit from a high performant time-series DB. As part of this, would I love to implement a Tag-Historian extension for IoTDB for Ignition. As IoTDB is implemented in Java, running it inside Ignition would also be an option.

As I am really new to Ignition (even if I did have contact with it at a previous employer) I would really appreciate some pointers to APIs, documentation regarding the development of a Tag-Historian for Ignition.

From what I've read here in the forum, the pretty unique way IoTDB stores data, would eliminate moste of the disadvantages of storing data in a tag-historian.

Here some pretty fresh benchmark results that were done by an independent company:
https://benchant.com/blog/apache-iotdb-performance

Help greatly appreciated,
Chris

1 Like

Welcome Christofer,
are you the man behind apache plc4x ?

https://plc4x.apache.org/

The most relevant ressources for Ignition SDK are:

Perhaps this repo can be interesting for implementing tag Historian

A new major version of Ignition 8.3 is on the road for the end of this year.
Some API refactor could occur around Tag historian.
Perhaps @PGriffith could give you some clarifications.

Expect significant refractors to the tag historian interfaces in 8.3.0. I wouldn't start a greenfield project until mid 2024, when we're expecting to have API changes finalized or at least close to so module authors can start developing against the new version of the platform.

1 Like

Awww! I have one in mind...

But, if you make it possible to select historians in the tag editor that don't use the SQLTAGS data flavor, I suppose it will be worth the wait.

Hi,

guilty as charged :wink: ... yeah Apache PLC4X is my baby, indeed ... new big update coming pretty soon :wink:

Thanks for the pointers. They will definitely help a lot.
Right now there's one customer interested in this and I guess I'll whip up something and we can start learning with that ... once the major refactoring is done, I guess it makes sense to concentrate on building something "product-wise".

Will look into this tomorrow ... but a huge help .. thanks :wink:

1 Like

Great, otherwise for waiting the new major release you can train with the SDK by adding a Profinet IO driver for Ignition :stuck_out_tongue_winking_eye:.
Driver expose data with @Kevin.Herron Opcua Milo stack you are already known.

Oh gee ... with the PROFINET stuff ... I think my hair is getting gray because of it ... We've come pretty far, but making it usable and stable is a hell of a job.

At least now I know why no other open-source profinet-master exists out there :-/

1 Like

Regarding your links AT mazeyrat (As I seem to be not allowed to mention you ... yet) it seems that the last link would be interesting for an Apache PLC4X Adapter, right? I should probably check the licenses the required API modules are available under (Being an Apache project does restrict us a bit with what we are able to do)

Hi all,

so I've started inspecting things and I've setup a base module using the archetype. So my first steps were to build a module based on that, deploying it and then continuing from there on.

So as I didn't quite like doing manual steps in my builds, I whipped up a little maven plugin that uses the module-signer to sign the finished modules. However when installing the modules I got "signature verification failed" errors. When trying to install it the first time, Ignition asked me about the risk of using self signed modules, but I accepted. Unfortunately I seem to be unable to deploy the modules I built.

As I didn't trust my own plugin, I tried using the module-signer according to this: Sign a Module | Ignition SDK Programmer's Guide (However I had to build a fat-jar first, as the one I got from here: Index of /com/inductiveautomation/ignitionsdk/module-signer/0.0.1 didn't contain it's dependencies.

I'm a bit stuck here now ... any help greatly appreciated.

So I've created the files the tool is looking for with this:

## Generate a self-signed CA certificate

openssl genrsa -des3 -out server.key 4096
openssl req -new -key server.key -out server.csr
openssl x509 -req -days 1024 -in server.csr -signkey server.key -out server.crt
openssl crl2pkcs7 -nocrl -certfile server.crt -out server.p7b -certfile server.crt

## Generate a key-signing certificate

openssl genrsa -des3 -out code-signing.key 4096
openssl req -new -key code-signing.key -out code-signing.csr
openssl x509 -req -in code-signing.csr -CA server.crt -CAkey server.key -CAcreateserial -out code-signing.pem -days 1024 -sha256
openssl pkcs12 -inkey code-signing.key -in code-signing.pem -export -out code-signing.p12
keytool -importkeystore -srckeystore code-signing.p12 -srcstoretype pkcs12 -destkeystore code-signing.jks

Any ideas?

You have to build the module-signer from here:

perhaps a post relative to your issue:

For dev and test purpose you can allow unsigned modules on your gateway:

https://docs.inductiveautomation.com/display/DOC81/Gateway+and+Gateway+Network+Parameters#GatewayandGatewayNetworkParameters-LoadingUnsignedModules-DeveloperMode

Ignition.conf

wrapper.java.additional.1=-Dignition.allowunsignedmodules=true

and restart ignition service

As a side note:
It's better to open a new post for a new subject (and to tag it).
You will have much more response :slight_smile: !

To sign your module at the end of the build with maven you can add something like:

            <plugin>
                <groupId>org.codehaus.mojo</groupId>
                <artifactId>exec-maven-plugin</artifactId>
                <version>1.5.0</version>
                <executions>
                    <execution>
                        <phase>package</phase>
                        <goals>
                            <goal>exec</goal>
                        </goals>
                    </execution>
                </executions>
                <configuration>
                    <executable>${java.home}/bin/java</executable>
                    <arguments>
                        <argument>-jar</argument>
                        <jar>${signer-jar}</jar>
                        <argument>-keystore=${signer-export-certif}</argument>
                        <argument>-keystore-pwd=${signer-pwd}</argument>
                        <argument>-alias=byes-siai</argument>
                        <argument>-alias-pwd=${signer-pwd}</argument>
                        <argument>-chain=${signer-certif}</argument>
                        <argument>-module-in=${signer-in_module}</argument>
                        <argument>-module-out=${signer-out_module}</argument>
                    </arguments>
                </configuration>
            </plugin>
3 Likes

Hi,
Ok ... with disabling the module signatures I was able to deploy my module ... let's just shift the whole module signing to when I've managed to get something working :wink:

Thanks for your help and I'll open new threads for anything new that I run into.

But even with a locally build module-signer was my module not accepted in the end.

Chris

It also seems that my maven plugin actually seems to be working now ... not sure what it didn't like about the signatures earlier. Just happy it's working now.