The distributed digital ledger technology is making waves in business applications, but not so much for engineering use cases. The technology is still too immature.
Blockchain. It’s the basis for cryptocurrency and now businesses are looking into other use cases. Engineering use cases have been proposed, though implementations are essentially nonexistent at this early stage in the distributed digital ledger’s development. That’s what EDN learned from speaking with several instrument makers and publishers of calibration software who, when asked, replied “not thinking about it” or “no comment.”
Why the lack of enthusiasm in the engineering community? Despite the hype and large number of blockchain descriptions and tutorials available, there is still not even a formal, accepted definition of a blockchain. See “Blockchain resources,” for links to papers and articles where you can learn how the technology works.
Computer scientists at NIST have written a paper that contains the closest thing to a standard description. NISTIR 8202, Blockchain Technology Overview describes a blockchain:
Blockchains are distributed digital ledgers of cryptographically signed transactions that are grouped into blocks. Each block is cryptographically linked to the previous one (making it tamper evident) after validation and undergoing a consensus decision. As new blocks are added, older blocks become more difficult to modify (creating tamper resistance). New blocks are replicated across copies of the ledger within the network, and any conflicts are resolved automatically using established rules.
The NIST Blockchain Technology Overview, which I highly recommend as a starting point, describes permissioned and permissionless blockchain digital ledgers. In a permissionless blockchain such as cryptocurrency, anyone with the software and enough computing power can become a node in the blockchain network. People who add blocks to the chain use public addresses, concealing their true identities.
Permissioned blockchains—where the identity of those able to add blocks is known—have so far received considerably less discussion, but that’s changing. In a permissioned blockchain, only those computers with permission can become nodes in a blockchain network. Such blockchains might have value in documenting engineering activities and storing engineering data as a product moves from design to production. NIST has proposed using blockchain to securely store manufacturing data.
Blockchains might find a place in the supply chain to provide proof of origin for parts and prove authentication. In the related articles at the end of this article, you can find updates on using blockchain technology in the supply chain. Another potential application is to store data as components are assembled onto boards and boards go into systems. EDN spoke with Dylan Yaga, author of NISTIR 8202, who noted this possible use.
In addition to its use in the supply chain, blockchain has been proposed as a method for storing calibration data. The authors of Blockchain-based for Calibration of Digital Multimeter System Design point to blockchain’s ability to store data in a way that makes it difficult to change once a block of data is added to a chain.
The paper’s authors propose a permissioned blockchain where only authorized parties add blocks of data to the chain. Because the calibration data is stored on every computer in this private blockchain network, it can’t be lost in the event of a data breach, fire, or other calamity occurring at a single location. Today, each lab maintains its own database of equipment it’s calibrated. Many users keep their own copies of data on calibrations performed on their equipment. Figure 1 shows how data might be stored in a blockchain from more than one lab. Each lab would have its own application software (single app shown).
Query a blockchain?
The paper’s authors note that simply storing data in a blockchain isn’t enough. The data needs additional software to be organized and needs software to calculate a measurement’s uncertainty and verify traceability to a national lab such as NIST. Michael Schwartz, automation engineer at CalLab Solutions echoed that need. In developing metrology.net, Schwartz and others considered in 2015 implementing a blockchain database for storing calibration data but ran into problems when designing the database for storing data but ran into issues. “We needed a way to query the blockchain data and couldn’t find one,” he told EDN. Instead, Schwartz chose to store the data in XML files.
When asked about Schwartz’s claim of no queries, Yaga replied by saying, “Blockchains need additional software to make them usable. You can construct a relational database that uses the blockchain-stored data to perform queries.”
“It’s possible,” he continued, “to query a blockchain’s data block by block, but that’s inefficient. The relational database can cache the blockchain’s data for queries, provide a more useable interface for the data, and perform data processing.” Figure 2 shows a relational database with data copied from a blockchain. “Most people aren’t comfortable with command lines found in most blockchain software. The primary reason for storing the data in a blockchain is because changing the data is difficult.” Yaga added that labs would need to verify that data in the relational database has not been altered by comparing its contents against that of the blockchain.
You can also use a block explorer to search data in a blockchain. They’re mostly used for searching cryptocurrency blockchains and go by names such as Blockchair, Gold Explorer, and Cardano Blockchain Explorer.
“Trust” means different things
In blockchain terms, trust refers to the integrity of a transaction and in the decentralized database’s underlying cryptographic mechanisms as well. Permissionless blockchains rely on a rigorous mathematical process that results in consensus from the community, which creates trust in a transaction’s validity. That’s essential for a permissionless cryptocurrency blockchain because there’s no central authority as there is in traditional currency.
According to Yaga, permissioned blockchains might not have the same level of trust (in blockchain terms) as permissionless blockchains because of the limited number of users available to mathematically reach consensus. He noted that a blockchain with a single user has no way to assign such trust to anything put into it.
In a permissioned blockchain, anyone with data-entry permission can add blocks to the chain. With few nodes in the network, the users must implicitly trust each other to keep the data valid. But, engineers usually trust the work performed at a calibration lab anyway. If you don’t trust a lab’s procedures and results, look for another lab regardless of how the lab stores test results.
In measurement and calibration, it’s trust in the data that counts. The metrology industry has established calibration procedures that accreditation bodies audit when they visit a lab. In the blockchain paper on DMM calibration, labs are the nodes of the blockchain network. But, before data is entered in the blockchain, software calculates uncertainty, creates a calibration certificate for an instrument, and establishes traceability to a national lab before writing to the blockchain. A lab’s customers can log in to an account at a lab and retrieve calibration certificates created by the external software, but not have access to the blockchain.
While not blockchain based, Schwartz’s software calculates the uncertainty in a calibration. That software also compares calibration data against a lab’s “scope of uncertainty,” a set of data that results from a lab’s audit, which is based on calibration procedures, equipment used, and the equipment’s traceability to a national lab. The calculated uncertainty can’t be less than a lab’s scope of uncertainty for a given measurement, lest the data be invalid in a calibration sense. Although blockchains rely on “trust,” that trust has nothing to with trusting the quality of the data itself. Thus, s blockchain can have invalid data even though the blockchain software concludes that the data entered is “trusted” from a blockchain perspective. In other words, “garbage in, garbage out.”
Who gets in?
Who should have permission to use a blockchain that stores calibration data? Should permission to add blocks be limited to commercial calibration labs? Not all commercial calibration labs have accreditation. Should they be excluded? If access to a calibration blockchain is limited to calibration labs, equipment users must rely on the labs to supply and store data. Some companies are large enough to have internal calibration labs that may or may not be accredited. If a company were to set up in internal blockchain-based ledger, it will store data that’s trusted from a calibration perspective but not from a blockchain perspective, which is all that counts.
Should each commercial lab create its own blockchain for storing data on calibrations it performs? Under that situation, a lab might choose to set up its blockchain and assign permission to customers who can then view test results and obtain calibration certificates only. That's already in place at many labs regardless of database technology. Might it make sense for an accreditation body or a third-party organization such as NCSLI to assign access to an industry-wide calibration blockchain network for all commercial labs? That creates the condition of having a central authority overseeing access to the blockchain, even though the blockchain data is distributed to multiple nodes.
Even if a single or multiple blockchains were used to store calibration data, the industry would have to agree on which information the blocks should hold. Test-equipment manufacturers present their measurement tolerances differently. For example, one multimeter manufacturer might specify "1% of reading + 2 digits" while another might say "1% of full scale." Would those differences would need to be reconciled if there were to be an industry wide calibration blockchain?
Although the calibration industry evolves slowly, it does evolve. Schwartz explained that new data types may be required over time. For example, the risk of an actual value falling outside the measurement value plus its uncertainty is under consideration. For the new data field, Yaga explained that each new block can have an additional data field not in previous blocks, but previous blocks are locked.
The blockchain software may need to be changed to accommodate these changes – depending on the robustness of a blockchain’s transaction structure.
Say for example, an entry was made in block #14 box_32, but you wanted to change that data later or add additional data to it. You would issue a new transaction to be included that would deprecate/modify/add to the entry made in block #14. Assume this new transaction is now in block #20.
- Block #14 records box_32’s width and height
- Block #20 records box_32’s depth
In your associated relational database, you can log box_32’s width and height as being recorded in block #14, and the depth in block #20.
The system that uses the blockchain data and turns it into something more useful than pure data (the application or web interface) would see that the transaction made in block #20 adds additional data to what is in block #14. This is not limited to adding new data, it could be corrections to data as well. Block #20 could have easily provided an updated height or width which would have overwritten the data found in block #14 from the application’s view – but not the blockchain’s.
Most people see this as a positive feature, in that you can see the entire history of something in a blockchain’s data structure. It can’t be removed or overwritten at the data level. Applications can recognize updates and additions. The application can show when each recording was added. (Figure 3)
While you can find stories of enterprises that are using blockchain, they are mostly for transactions where the “data” is a transaction record. Engineering data varies greatly with use case, making Blockchain less exciting, at least for now. To tame the current “wild west” of blockchain, we’ll need not only standards for data fields in each industry, we’ll also need some way to prove that the blockchain is functioning properly, especially where sensitive data is involved. Getting back to calibration, a new data-storage technology for heavily regulated industries such as pharmaceuticals or medical equipment needs to be proven before anyone will adopt it. In the calibration world, “new” is a synonym for “unproven.”
Despite these issues, you might still find an engineering use case for a blockchain. The list of resources can help you find software tools, which are generally open source. You can find software that includes a user interface and the blockchain or you can use an online service. Yaga noted that an online service might reduce the level of trust from a blockchain perspective, but not from a calibration/metrology perspective.
There’s no shortage of online blockchain descriptions, tutorials and software ratings. Here’s a sampling.
NIST papers and articles