RS IoT Blockchain Demonstrators Part 7: Expanding the Blockchain
Adding a new Workshop Safety use case to the IoT blockchain network.
Previous posts in this series have looked at the mechanical and electronics build, together with the creation of a private Ethereum blockchain and Python applications, for a set of IoT blockchain demonstrator units. These covered an initial four use cases and this post takes a look at the creation of a new fifth ‘Workshop Safety’ use case, and its integration into the blockchain network.
The mechanical design for the Workshop Safety unit is similar to previous and makes use of aluminium 2020 extrusion to create a robust frame, plus custom laser cut acrylic parts. The workshop environment is represented by a set of miniature models of machine tools that are driven by a small 12VDC motor with an integrated reduction gearbox (042-0637) .
Now that we have our dangerous machine tools, we need a way of making them safe in potentially hazardous situations. This is achieved via a 2-channel safety relay (701-9216) , with the output contacts wired in serial meaning that two positive inputs are required in order for an output to be provided. This output is then fed into the coil of a contactor (776-8485) , which when energised provides power to the motor.
One of the inputs to the safety relay is provided by a photoelectric sensor (022-8992) inverted output and the second from the normally closed contacts of an emergency stop button. Hence the motor will run provided that the beam is not interrupted and the emergency stop button is not pressed.
The Raspberry Pi has a GPIO pin configured as an input and this is connected to a spare set of contacts on the contactor. Another GPIO is connected to a run/stop switch at the rear. Meaning the Pi is able to ascertain when the demo is in the run state and the motor supply is interrupted.
As with most of the existing units we also have a DesignSpark Pmod HAT (144-8419) , with an OLED Pmod (134-6481) that indicates status. For added industrial feel we also have a tower beacon (849-5374) .
In Part 4 we previously looked at the blockchain configuration and how this starts with the genesis block, which was initialised on each node via a JSON configuration file. This configuration was also used to pre-allocate funds to a number of accounts, which would then be used by the applications which need to write to the blockchain in order to log transactions.
The first thing we did was to update the configuration in iotbc.json to also pre-allocate funds to a new account that is configured on the Workshop Safety unit. We then deleted the old blockchain database on each node — including the miner — and reinitialised the blockchain network to create a new genesis block on each.
geth --datadir /data/bc init iotbc.json
At this point we had a new blockchain with an additional account that has pre-allocated funds.
Just to re-state that, as made clear previously, this is a private blockchain and the ‘funds’ are not related to any sort of real-world currency. Rather instead this is simply credit in our private network, that allows only permitted devices to write to the blockchain and within set limits.
Next, we created a new smart contract which the Workshop Safety unit would use to register the time of the last safety incident. This is essentially the same as the one used by Machine Failure, albeit with the following changes:
- Different contract name (WorkshopSafety instead of MachineFailure)
- Different function names (setLastIncident and getLastIncident, instead of setLastFailure and getLastFailure)
- Different variable names (machine and healthsafety, instead of owner and maintainer)
All five smart contracts were then deployed to the freshly initialised blockchain network.
In practice, a blockchain network might have many smart contracts that are similar and with just some relatively minor differences, such as their name, that of variables and who can interact with them. Of course, another approach would be to have fewer smart contracts that are instead more complex, with more functions and which can service the needs of more than one use case. Here we opted for the former and decided to keep things simple for the sake of clarity.
Smart contracts can actually also create other smart contracts. Which is to say that we could have built a smart contract that would enable us to create new ones whenever we like. Or we could have just deployed a new contract that we manually created to the existing blockchain network, rather than reinitialising it and then having to deploy all five (previous four, plus a new one).
In addition to which, we didn’t really have to reinitialise the entire blockchain network in order to allocate funds to a new account — instead we could have simply transferred them from an existing account! However, once again we decided to keep it simple and have all the use cases with the same amount of funds preallocated to their accounts and fewer overall steps involved.
Of course, in real-world applications it would likely be impossible or extremely time consuming to fully reinitialise a blockchain. So instead you might have a small number of accounts that act like ‘banks’ and are preallocated with significant funds, which then transfer relatively small amounts to other accounts as and when required. Similarly, when a new application came along and with it, new smart contracts, these would simply be deployed to the existing blockchain.
The Python application is similar again to that for the Machine Failure use case, which also senses GPIO inputs via the DesignSpark Pmod HAT and has an OLED display for status indication. It essentially runs in a loop, examining the state of the two inputs, updating the text on the display and invoking the smart contract on the blockchain as appropriate.
As we can see, updating the blockchain network to add a new node and associated smart contract is not difficult. Furthermore, here we took a number of steps which typically would not be necessary and did this just to keep everything simple and as straightforward as possible. To see all the changes made you can take a look at a git commit which adds support for the new use case (note that iotbc.json had previously not been added to the repo and so shows as being entirely new).