Week 28:

Final Week!

The main aim for this week was to get this rewrite function working, once and for all.

The rewrite function needed to comprise of a sender, a receiver, a hash broadcast and a most common hash detector.

I decided it was best first delve into the emitter() function, as this was responsible for letting other nodes know the quality of it's data.

After some tests I realised that by importing time, the nodes could all broadcast their hash at the same time. This would make it easier for the node detector as all the information should arrive within milliseconds of each other.

Problem:

The emitter creates a hash the same as before using a For loop nested in two other For loops. There was no way of finding out how long it takes the For loop to finish as more data was always being added but I needed a way to broadcast every multiple of 5 seconds, like all the other nodes.

Solution:

Using the modulus maths operator returns a remainder. For example, 5 % 5 = 0, 4 % 5 = 4. Usage this operator, I was able to find how far away from a multiple of five was.

If the For loop finished at an unknown time, taking a reading of time at that point and feeding it into a modulus function it will return the time needed to wait before publishing the data. For example, time.sleep(5 - (seconds % 5)). The modulus function is subtracted from 5 because modulus normally says how far away, lower or higher. In order for it to say how long to wait until the next multiple, subtracting from five works well.

A revamp of the detector was needed as well. I realised that if a node is restarted in the middle of an order due to power loss, etc, using the rosnode.rosnode_ping_all() function, it was able to update an array if nodes were online or not. This was another preemptive move for being one step closer to the eluding node rewrite function.

When a node is being rewritten, it's last hash does not want to be considered again for being compromised if it's already in the process of being rewritten. If that happens, like it has before, the node only gets half rewritten, therefore never being able to fully rewrite.

Problem:

Once a node was detected as being hacked there was always a possibility that the node's hash was just received late.

Solution:

To combat this, that node's name was saved. When the loop came round again to the next multiple of five, if that node was still being the one accused of false data, it meant that node is highly likely to be compromised.

The rewrite function:

After many different tests and design iterations I finally settled on a way to send the most data in the quickest way.

Sending data over ROS line by line is slow and data can be missed, however, sending one long string of all the concatenated array data is very fast.

This long string is created and separated in by either ';' or '?'.

'?' separates each block in the blockchain and ';' separates each item of data in that block.

Parsing the data on the other side first splits the string into an array with each index beginning and end where the '?' was.

Finding the length of this array give the amount of loops the For loop had to do in order to parse all the data successfully.

The second split separated each index of the first split into a new array that gets rewritten at each loop. All the data can then be collected into arrays separated by [order][carrier][block] again, like before.

While still in the For loop, the blockchain be rebuilt as soon as the variables are assigned, which is quicker than before. The picture above shows if the station name = 'Start Production', it meant it was a genesis block. If the station name was a number, the blockchain was appended with new data.

In testing on the laptop, the program works flawlessly without any errors. The nodes only get rewritten once they are compromised.

In testing on the Pi's, the program is a bit too CPU intensive for rapid concatenation in that kind of time frame.

In future, a more powerful single board computer might be better equipped at handling the CPU surges.

Week 27:

Starting out this week, I decided it was time to add some extra data into the blockchain. At station 5 - the pneumatic press station, the PLCs gather the amount of force the press produces in Newtons and also provides the pressure inside the muscles at this pressing force. Station 6 - the heating station, also sends data to the PLCs with current temperature, target temperature and total heating time.

On reflection, it was probably a bad idea to add extra to upload to the blockchain when the second island's stations were still not uploading to the blockchain properly.

The last two lines after 'Previous Hash' at each block read in the extra data from the PLCs, over the same TCP Server.

Problem:

CPU usage on the laptop for each node is at 25%. Clearly, when the time comes to migrate to the Raspberry Pi's, it's highly likely they won't run properly.

Solution:

After trolling through the code a realised the mainProg() function that reads in the raw data and inputs into the blockchain, was looping unnecessarily when there was no data to be uploaded which just equated to wasted performance. I decided to call the mainProg() function at the end of the TCP Server function so the mainProg() would only run when the server receives data. This cut the CPU usage from 25% to practically 0%.

Problem:

QR Code reading for the Raspberry Pi was not as simple in OpenCV when usage the Raspberry Pi Camera.

Solution:

At first I tried over complicating it but then discovered there was a library for the camera called pyCamera. From that library it was possible to set up a video stream variable that could then talk to OpenCV.

Mounting the camera far above, shown above, allowed the workers to still be able to reach the product to install the circuit board but was also incredibly reliable due to the high resolution of the camera.

The video below was of a QR Code scanning test, earlier in the week.

Problem:

Once the Raspberry Pi's had the blockchain code, the Pi's would keep missing data. The MES would then try to complete a product and get the carrier ready for the next order. Missing data would then stop the product from getting a 'Comp' receipt because the stationHistory array would not match up.

Solution:

I noticed when the scripts were initialising all the arrays, they were taking a considerably long time to start than the laptop was doing. The hunch a got was that when a station was trying to publish data, the script would move on before the message manged to send. This stopped the message sending as the message pending got over written. The solution I found was to just add 300ms timers after each attempted to publish data and that solved it because it forced the scripts to wait.

The final addition to the project is week is a customer user interface. One of the objectives of the project stated that there could be some was of including some sort of payment and order customisation for a customer. I created a bank of unique hashes that could potentially be given to customers after payment as an order token/voucher.

The customer can input the unique hash into the program which will then be sent to a licencing server on one of the Raspberry Pi's. This licencing server has the bank of hashes and if a hash is received that matches one in the bank then the server will send either 'success' or 'fail' in response. If the hash was successful, the customer will be prompted to enter the details of their order in the form 'product code, quantity, customer number'. They would receive their customer number on purchase of the hash token.

The order request gets sent to the MES Message server which processes the order and sends back a reply with the order number.

Week 26:

Problem:

Since the last blog post, there have been some errors revealing themselves in the system.

When the log files are trying to be completed, their data keeps getting changed and because the stationHistory has been wiped, stations will start uploading data again.

Solution:

Sending a custom message with just the carrier number and station name so callback can rename the file to be completed. Once the blank message is published, a stationFinish boolean is set to True so the next lines don't try and add the data to the file.

I spent the rest of this week once again focused on trying to invent a way to send all the data from node node to another in the quickest, most efficient way possible.

To start with I was looking at sending the completed receipt data by reading in the file and sending each line over custom message.

Testing this idea was hard in the main script because there are so many unknowns. I created a test script that could read in a file and send it's contents over ROS which worked quite well. Implementing the test script after debugging was a lot easier and it seemed to work most of the time. This could be a different matter when I try and run it on a Raspberry Pi.

Improvements:

In the emitter() function that broadcasts the block's hash, I've included a variable reading in the amount of files in that node's directory as a salt hash. This means that the node is hashed with an extra number in it. I did this in being preemptive of the rewrite function when I eventually solve it. When a node is fully rewritten with all the correct data, the amount of files contained in it's directory should be the same.

I've ended this week still without managing to crack rewrite function, however, I did manage solve another problem which is as follows..

Problem:

One of the objectives talks about the end user being able to reveal the blockchain of their product away from the factory so they have proof of authenticity.

Solution:

I created custom QR Codes that contained a web link to a file server running on one of the Raspberry Pi's. My original idea was to somehow create a QR code from the raw blockchain receipt data, therefore, not having to access a server to retrieve the information. When I created the first QR code as a test, I decided wholeheartedly that this was not the best solution.

This is obviously totally impractical, the slightest bit of dirt or the wrong lighting could make this not work.

Upon the decision not to do it that way, it also made more sense to use a file server for security purposes.

In the end, creating QR codes with file server links made a lot more sense, with a much more practical QR Code.

The next steps for this are when a receipt is completed, the file is copied across to the file server directory to reveal the blockchain automatically.