<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On 23 September 2015 at 18:51, Damon Hart-Davis <span dir="ltr"><<a href="mailto:dhd@exnet.com" target="_blank">dhd@exnet.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<br>
<br>
In the case of (legally) important IoT data, such as food store temperatures, in Launchpad we’d like to be able to posit some mechanisms to make it hard to tamper with or repudiate the data in the sensor and all the way to the data store and afterwards.<br>
<br>
(Such entries might be a unique sensor ID, timestamp, temperature and some other sensor data and metadata, generated every few minutes by (say) 1–100 devices in a building.)<br></blockquote><div><br></div><div>We are talking to potential customers who have exactly this requirement. The generic use case is industrial fridges that store perishable good and where the owners have a legal requirement to 1) keep the fridges within a certain temperature range and 2) demonstrate this is the case when they get audited. The 3 specific use cases are:</div><div>- bakery</div><div>- butchers</div><div>- school canteens</div><div><br></div><div>From a business perspective, the detailed requirements are:</div><div>1. Reliable data: the equipment needs to be calibrated and proved correct within a certain error range;</div><div>2. Current data: they need to know as soon as any of the equipment fails;</div><div>3. Proof that the sensor measures data in the expected equipment:</div><div>3.1: at installation: prove that the meter planned for fridge A was actually installed in fridge A and not B,</div><div>3.2: post-installation: make sure that the sensor that was in fridge A wasn't moved to fridge B;</div><div>4. The data displayed is the one that was read by the sensor and not tampered with in transit or at rest.</div><div><br></div><div>#1 and #2 are your classic sensor and data quality problem so nothing really new there.</div><div><br></div><div>#3 is where additional sensors for positioning and movement can be useful, although some of it can be manual too (e.g. take a picture of the install and attach it to the meter info for #3.1). The implication is that there's also a need to ensure #1 and #2 for all additional sensors that are used to detect tampering.</div><div><br></div><div>#4 is about securing the whole chain and where it gets complicated because you need some level of signing on the sensors themselves. So I assume this is the part of the problem that blockchain could help solve.</div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
In a chat with Viv today (helping us with out business plan, but also a blockchain whiz) the possibility of using a blockchain mechanism to provide at least these two features in the long-term data store came up.<br></blockquote><div><br></div><div>I've been trying to understand blockchain to see if we could use it for our own purposes and I can't see how it would be used for that particular use case. If I understand things correctly, blockchain is a distributed ledger where every transaction is signed and all nodes have a full copy of the ledger. I think there are also variations to allow some nodes to only have a partial copy of the ledger.</div><div><br></div><div>I'm not sure where this ledger would go: it can't be stored on the sensors nodes as they don't have the capacity for it and even concentrators would be hard pressed to deal with it. That leaves a data platform but doesn't that go against the OpenTRV principle of having something that can work without that data platform?</div><div><br></div><div>Even assuming you could have a lightweight ledger that is suitable for concentrators, I'm not sure how that would work as OpenTRV is designed to work in a star topology where you have a single concentrator for a bunch of sensors, in which case you don't benefit from the distributed aspect of the blockchain ledger and could go with a simpler solution. On the other hand, that could work with a mesh network topology where you would have multiple concentrators.</div><div><br></div><div>All this to say that I don't understand how blockchain would help and I'm probably missing something important. Do you have the details of how Viv envisaged this working?</div><div><br></div><div><br></div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
We’ve thought of some pros and cons, but I’m very interested in the views of our hive mind here!<br></blockquote><div><br></div><div>I'm not sure whether my ramblings above make sense so please tell me if they don't.</div><div><br></div><div>Cheers,</div><div><br></div><div>Bruno</div><div><br></div></div></div></div>