• 

• 

• 

Inspiration

A while ago I used to work with Environmental Monitoring Systems (EMS), and then recently I participated in the Cosmonic hackathon, which involved building a distributed system from functional webassembly components.

This got me thinking about integrating a distributed system with an IIoT (Industrial Internet of Things) based EMS. Control and monitoring systems would be able to handle multiple facilities as if it were all in the same place, and a multiple parts of a facility losing communications wouldn't effect its overall functionality (for example, if you have three WiFi access points in three different parts of the facility, and two of them go down, the sensors would all still be connected to each other as a mesh and traffic would be re-routed to the remaining access point).

The only problem (well, one of many) is that I wasn't quite sure how to handle the tamperproof audit logging, which is a requirement for 21 CFR Part 11 compliance.

Two weeks ago I started working on this hackathon, and after looking into Pangea's services I noticed their audit log isn't just tamperproof, but it's trustless and the integrity of the logs can be verified by anyone using cryptography. Problem solved.

What it does

This is just a proof of concept, and I only had two weeks to build it (half of that time was spent figuring out how to get an rp-pico-w to communicate with a NATS server via MQTT), so it doesn't do everything I want it to.

At the moment, there's a simulation running on a droplet in Singapore, which sends all of its "readings" to a local wasmCloud host so they can be processed within the super cluster. After being processed, the readings are written to the Pangea audit logs. I did also manage to get my rp-pico-w to connect to the cluster via WiFi at a friend's house, but back at my student accommodation (where the internet has a bunch of weird restrictions) I was unable to get it to work. UPDATE: I managed to get it working now

Most of the business logic regarding the sensor readings is handled by the polling provider (a design decision I would change if I could go back), which listens for heartbeats on a NATS subject and once it receives a heartbeat it begins polling that sensor at the specified interval. For most sensors, it's better to poll them than to passively consume their readings because it makes it much easier to detect communications errors if a sensor doesn't respond to its poll request in a reasonable time. Once the polling provider receives a response, or the response times out, it sends the results to the sensor-reader actor, which processes them and sends them to the PangeaApi actor so they can be written to the logs.

There's also an EventLogger, which I haven't used yet in this proof of concept, but it listens on NATS for events and then uses the PangeaApi to log them. This can be used for events such as a user logging in, changing permissions for another user etc. It can also be used for more passive types of sensor readings, such as a door being opened/closed, an item/vehicle reaching a specific location, or an alarm indicating that another sensor has gone outside acceptable levels.

The HttpGateway actor is meant to allow public access to the audit logs for demonstration purposes (it also fetches the UI, but I haven't built the UI). Although it worked fine locally, once I deployed it on Cosmonic it seems to exceed the RPC timeout (2000ms on Cosmonic's managed host, and it can't be changed at the moment).

Because the HttpGateway doesn't seem to be working too reliably, I've generated a public Pangea token that can only be used to search the audit logs. which is at the bottom of this README with an example.

How I built it

Painfully.

Challenges I ran into

Mostly just a lack of time. If i had 1-3 months I would have been able to create a much more polished end product, and I might have been able to get the hardware side of things working.

Accomplishments that I'm proud of

Considering that most of the actual software was built within the last week, I guess I'm proud of that, although it's not quite what it could be with a bit more time.

What I learned

The majority of the business logic regarding sensor readings is handled by the NatsPollingProvider. About 2-3 days ago I realised this isn't ideal, because it makes it more difficult to scale different aspects of the system. If I ever come back to this, I'll most likely start by reducing that provider down to a simple service which just keeps track of polling intervals and wakes up some actors to handle the rest of the heavy lifting.

What's next for Distributed IIoT EMS

After sorting out all the issues I mentioned above and redoing the architecture completely, I'd like to purchase a few more microcontrollers so I can test out connecting sensors together to form a self healing "mesh" network.

How to use it

The public key: pts_5nqt3idyvm52n75qijlo7zxyoo6wmqta The domain: https://audit.aws.eu.pangea.cloud

You can use this public key to the query the logs the same way you'd query your own audit logs via the search endpoint.

For example, to query all the logs:

curl -sSLX POST 'https://audit.aws.eu.pangea.cloud/v1/search' \
-H 'Authorization: Bearer pts_5nqt3idyvm52n75qijlo7zxyoo6wmqta' \
-H 'Content-Type: application/json' \
-d '{"max_results":100,"verbose":false}' 

or to query just the hardware sensor in my room (it's just the internal temperature sensor for the microcontroller's CPU):

curl -sSLX POST 'https://audit.aws.eu.pangea.cloud/v1/search' \
-H 'Authorization: Bearer pts_5nqt3idyvm52n75qijlo7zxyoo6wmqta' \
-H 'Content-Type: application/json' \
-d '{"max_results":100,"verbose":false,"search_restriction":{"source":["rp-pico-w.temp_01"]}}'

I'd advise piping to jq to make it a bit more readable, like so:

curl -sSLX POST 'https://audit.aws.eu.pangea.cloud/v1/search' \
-H 'Authorization: Bearer pts_5nqt3idyvm52n75qijlo7zxyoo6wmqta' \
-H 'Content-Type: application/json' \
-d '{"max_results":100,"verbose":false,"search_restriction":{"source":["rp-pico-w.temp_01"]}}' | jq

Built With

• cosmonic
• pangea
• rust
• wasm
• wasmcloud
• webassembly