Using Blockchains to Implement Distributed Measuring Systemsbessani/publications/tim19-blockchain.pdf · preventing the whole chain from being modiﬁed and requir-ing an agreement

This article has been accepted for inclusion in a future issue of this journal. Content is final as presented, with the exception of pagination.

IEEE TRANSACTIONS ON INSTRUMENTATION AND MEASUREMENT 1

Using Blockchains to Implement DistributedMeasuring Systems

Wilson S. Melo Jr. , Alysson Bessani, Nuno Neves, Member, IEEE, Altair Olivo Santin, Member, IEEE,and Luiz F. Rust C. Carmo

Abstract— In recent years, measuring instruments havebecome quite complex due to the integration of embedded systemsand software components and the increasing aggregation ofnew features. Consequently, metrological regulation and controlrequire more efforts from notified bodies, becoming slower andmore expensive. In this paper, we evaluate the use of blockchainsas a resource to overcome such challenges. We start with aconceptual model for implementing measuring instruments in adistributed blockchain-based architecture and compare it withtraditional measuring instruments and distributed measuringmodels discussed in previous works. We also made a securityanalysis, demonstrating that blockchain-based measuring sys-tems can impact the way measuring instruments are used inconsumer relations while improving security and simplifyingmetrological regulation and control. We implement a vehiclespeed measuring system using the Hyperledger Fabric blockchainplatform. We evaluate the security and performance of ourblockchain-based measuring system by executing tests with datafrom real speed meter sensors. The results are promising andvalidate the feasibility of our idea. Finally, we point out themain challenges related to our approach, suggesting alternativesand potential issues to be addressed by future works.

Index Terms— Blockchains, distributed measuring (DM), legalmetrology, security, software protection.

I. INTRODUCTION

MEASUREMENT instruments (MIs) are used inmany application domains, including industry, com-

merce, energy, transportation, health care, and environmentprotection [1]. In Europe alone, MI are responsible for anannual turnover of more than 500 billion Euros [2]. In devel-oping countries, the demand for MI has increased substantially

Manuscript received July 24, 2018; revised January 12, 2019; acceptedJanuary 14, 2019. This work was supported in part by the Coordina-tion for the Improvement of Higher Education Personnel (CAPES), underGrant 99999.008512/2014-0; in part by the EU-BR SecureCloud project(MCTI/RNP 3rd Coordinated Call); in part by FCT through the Abyssproject under Grant PTDC/EEI-SCR/1741/2041 and the project ResilientSupervision and Control in Smart Grids, and in part by the LaSIGEresearch unit under Grant UID/CEC/00408/2019. The Associate Editorcoordinating the review process was José Pereira. (Corresponding author:Wilson S. Melo, Jr.)

W. S. Melo Jr., and L. F. R. C. Carmo are with the National Institute ofMetrology, Quality and Technology, Duque de Caxias 25250-020, Brazil, andalso with PPGI/DCC, Federal University of Rio de Janeiro, Rio de Janeiro21941-916, Brazil (e-mail: [email protected]).

A. Bessani and N. Neves are with LaSIGE, Faculdade de Ciências, Univer-sidade de Lisboa, 1749-016 Lisboa, Portugal.

A. O. Santin is with the Graduate Program in Computer Science, thePontifical Catholic University of Parana, Curitiba 80215-901, Brazil.

Color versions of one or more of the figures in this paper are availableonline at http://ieeexplore.ieee.org.

Digital Object Identifier 10.1109/TIM.2019.2898013

due to the adoption of technologies and methods well estab-lished in developed countries [1]. MI can also be seen as thefundamental building blocks for new technologies, such asthe Internet of Things and cyber physical systems (e.g., smartgrids) [1]–[6].

MI are nowadays quite complex, since they are stronglybased on embedded systems and are often connected andaccessible by the Internet [2], [3]. This kind of scenariomight expose MI to security gaps that can be exploredwith malicious intent [4], [5]. Legal metrology is respon-sible for promoting MI metrological assurance, establish-ing security requirements and technical activities, such astype approval, verification, and metrological supervision [1].However, the increasing complexity of MI affects suchactivities substantially. Type approval requires more effort,while verification can involve use cases which are hardto reproduce inside labs. In turn, metrological supervisionbecomes difficult due to the diversity of MI models, theirgeographic spread, and the limited resources owned byregulatory agencies.

We work with the hypothesis that the aforementioned dif-ficulties should be overcome with alternative approaches thatsimplify MI design while employing strategies to decentral-ize metrological supervision. Such idea finds many aspectsin common with a new trendy technology: blockchains [7].A blockchain can be described as a distributed data structurewhich assures information integrity and authenticity whileproviding a platform for executing self-enforced software pro-cedures, called smart contracts [8]. Blockchain solutions havebeen very successful in financial applications (e.g., Bitcoinand Ethereum), inspiring its use in different applications andknowledge areas [7], [8]. More recently, a few works haveproposed blockchain applications in legal metrology, whichinclude decentralized audit, mechanisms for software loading,public key infrastructure (PKI) for MI manufacturers, anddistributed measuring systems (DMSs) [9], [10].

In this paper, we discuss how blockchains can improvemeasuring applications, evaluating two main aspects: distrib-uted measuring (DM) and decentralized surveillance. Thispaper extends the ideas presented in our previous work [10].We start from preliminary concepts already consolidatedin legal metrology about MI regulation and control. Then,we explore ideas related to the integration of MI in DMS,proposing a blockchain-based model. Such aspects result inan innovative concept that dissociates the measurement service

0018-9456 © 2019 IEEE. Personal use is permitted, but republication/redistribution requires IEEE permission.See http://www.ieee.org/publications_standards/publications/rights/index.html for more information.

https://orcid.org/0000-0002-7710-7995


2 IEEE TRANSACTIONS ON INSTRUMENTATION AND MEASUREMENT

from the measurement quantity, while it improves MI securityand makes metrological assurance simpler and less expensive.

Our main contributions can be summarized as follows.1) We introduce the idea of DM using blockchains and

describe its advantages when compared to traditional MIand other DM models. To the best of our knowledge, thisis the first paper to describe a blockchain-based DMS.

2) We propose an architectural model for implementingour idea, showing that MI and blockchains enable anew business model where the measuring process is anindependent service, reducing conflicts of interest.

3) We present a security analysis, showing that our modelimproves MI security since it constrains the attackercapabilities, thus simplifying MI regulation and control.

4) We develop a practical case study using the HyperledgerFabric [11] platform. We create a blockchain networkthat implements legally relevant (LR) software usingsmart contracts for measuring vehicle speed. We alsopresent results that demonstrate the feasibility of ouridea.

5) We point out challenges that shall be addressedin the future works using blockchains in measuringapplications.

II. BACKGROUND

A. Legal Metrology and MI Reliability

Legal metrology embraces MI regulation and control. It iscrucial to assure the correctness of measurements [1] andregulate consumer relations [6]. Usually, legal metrology reg-ulations are defined by government agencies or internationalcommittees. Regulation directives traditionally establish a setof requirements and activities [1]. The main ones are related tolegal control of MI and type approval, which can include docu-mentation and code inspection, validation and verification; andmetrological supervision, including quality, market, and fieldsurveillance. These activities are usually executed by notifiedbodies1 that are designated to assert MI conformity [2], [6].

Legal metrology activities related to electronic- andsoftware-controlled MI can demand more complex proceduresand specialized knowledge. Usually, regulation adopts securityrequirements and good practices from the well-known techni-cal standards [2], [5], [12]. The OIML D 31(E) document [13]and WELMEC Software Guide 7.2 [14] are probably themore widespread standards for software-controlled MI design,deployment, and inspection.

The majority of security issues with MI arise from partiesseeking undue economic advantages. A classical exampleoccurs in the commerce of measured goods, where vendors andconsumers have conflicting interests [1]. Malicious vendorscan try to maximize profits, while malicious consumers can tryto minimize prices by frauding measurements. Measurementfrauds against MI (such as scales, energy meters, and fuelpumps) are very common in developing countries [3], [12].Attacks can also intend to steal sensitive information andintellectual property [3], [6]. In some cases, they even threaten

1Notified bodies are public or private parties organized for verifying MI.

people’s physical integrity (e.g., tampering measurementsrelated to medical procedures) [4].

B. Distributed Measuring

DM, where components are connected through a network,is well studied. Boccardo et al. [4] described a strategy tosimplify MI type approval and supervision activities relatedto medical MI. Their proposal consists in signing sensing rawdata of a sphygmomanometer immediately after analog-to-digital (AD) conversion. Although it is not a DM case, thisapproach suggests that part of the measurement computing canbe done externally to the sphygmomanometer hardware coredue to the use of a digital signature to check sensing dataintegrity and authenticity. Peters et al. [5] described an MIsecurity framework using virtual machines to separate LR andnonlegally relevant (NLR) software.2 The authors propose dif-ferent virtual machines to execute LR and NLR functions anddefine secure interfaces for communicating among them. Thisapproach is presented as an alternative to improve security andreduce MI complexity. Additionally, it enables virtualizationusing different hardware cores and consequently allows theimplementation of DMSs. Finally, a DM architecture usingcloud computing is discussed by Oppermann et al. [6]. Theauthors present advantages related to IT infrastructure costsavings and the possibility of MI manufacturers to offermodern interconnected devices and features. They also presenta comprehensive example of how to integrate energy metersin a DMS. In contrast, they also point out issues relatedto communication security, data management, and reliability.Roughly speaking, they assert that the following challengesneed to be addressed.

1) DM instruments must be as secure as their classicalcounterparts.

2) Large amounts of data will be accumulated in distributedrepositories, requiring proper treatment.

3) If distributed service providers are considered untrust-worthy, then data security is very difficult to assure.

C. Blockchains

Blockchain is an emerging technology which has caughtthe attention of stakeholders in different industry segments.Initially associated with crypto-currency markets due toBitcoin popularity [7], blockchain-based architectures havebeen proposed for a wide set of application areas, includingsensor networks, Internet of Things, smart cities, amongothers [8].

Conceptually, a blockchain can be regarded as a distributedappend-only data structure (designated as ledger), which isreplicated and shared among a set of network peers [8]. Thisstructure consists of a sequence of blocks, where block nis cryptographically linked to the block n − 1 using a hashfunction. Consequently, block n cannot be changed withoutmodifying all subsequent blocks n+ i, . . . , n+k [15]. Being adecentralized model, blockchains’ availability does not depend

2OIML D 31(E) and WELMEC 7.2 use LR to designate any componentwhich can affect measuring final results, while NLR cannot do that.


MELO JR. et al.: USING BLOCKCHAINS TO IMPLEMENT DMSs 3

on third parties, which can greatly save costs. In turn, integrityand availability are ensured by consensus among the peers,preventing the whole chain from being modified and requir-ing an agreement about any block to be appended to theledger [15], [16]. Blockchain platforms can be classified aspermissionless, in which anybody can join and participate inthe network consensus, or permissioned, in which consensusis achieved by a set of known and identifiable peers [16].Usually, permissioned blockchain consensus protocols expendless computational resources and can reach better transactionlatency and throughput.

A blockchain can store virtually any digital asset, from datato self-executing scripts, usually defined as smart contracts.This makes blockchains not only a data storage solution butalso a complete distributed platform for proper and distributedautomated workflow [8]. Once smart contracts are executed atevery network peer in an independent and automatic manner,software integrity is achieved from blockchains’ integrity as awhole.

III. DEFINING MI SECURITY SCOPE

In this paper, we want to evaluate the security level of differ-ent measuring systems’ models and point out the advantagesand drawbacks of these models. We are especially interested inMI reliability and the required effort for providing MI metro-logical assurance. Metrological requirements and activities arevery particular for different MI classes. However, a simple setof requirements and activities are the representative of mostsoftware-controlled MI concerning security properties. Fromthat point of view, we define our MI security scope based on ageneric attack model and its respective metrological assuranceframework. We described both in this section.

A. Attack Model

We consider a simple attack model that can be built fromMI use cases according to OIML D 31(E) and WELMEC7.2 guides. MI are targeted by malicious entities trying to getundue economic advantages by tampering with measurements.Basically, the attacker capability consists of changing theMI expected behavior, tampering any LR component, andcompromising the reliability of the measurements.

We assume that the attacker could be any entity withaccess to the MI components or sensitive features, at anymoment of its lifecycle. Attackers can be manufacturers,vendors, clients, and other entities. Malicious manufacturerstaff (e.g., a malicious programmer) can inject software vul-nerabilities and backdoors, “selling” them to other potentialattackers. Once an MI is deployed, vendors and clients canhave access to its resources, exploring eventual failures andmisbehaviors or changing sensitive parameters related to MIaccuracy. Furthermore, modern MI usually provide interfacesfor loading software updates and upgrades. Such features canbe explored by malicious vendors and clients for loadingtampered LR software or for modifying critical MI parameters.

Conversely, we establish that an attacker cannot compromisetamper-proof hardware devices, or cryptographic primitivesand communication protocols from algorithms recognized as

secure. In addition, we also define that an attacker cannot takepart in collusion attacks with more than a fraction of peers thatintegrates the network. The exact value of this fraction dependson the blockchain implementation [16].

B. Basic Metrological Assurance Framework

We assume the existence of a Basic Metrological AssuranceFramework (BMAF) tailored to implement MI regulation andcontrol, which works as a countermeasure to the previouslydescribed attack model. Such a BMAF gives a minimal setof requirements and activities, which is very realistic since itsstatements can be found in regulation directives implementedin several countries [2]–[4], [12].

Our BMAF sets the following protection requirements.

1) R1: MI have reliable physical sealing to protect physicalcomponents, such as sensors and electronic circuits.

2) R2: MI implement acceptable mechanisms for LR soft-ware identification and integrity checking by notifiedbodies during MI supervision;

3) R3: MI implement security mechanisms for LR softwareloading that accept only software modules signed bymanufacturers and responsible notification bodies.

In turn, BMAF also establishes the following control andsupervision activities.

1) A1: MI hardware and software detailed analysis,LR software source code inspection, and conformityassessment regarding the MI protection requirements.

2) A2: MI validation and verification of all relevant MI usecases identified during type approval.

3) A3: MI supervision by periodic inspection in bothmanufacturing site and application field. Activities mustinclude MI seal verification and LR software identifica-tion and integrity check.

IV. BLOCKCHAINS IN MEASURING SYSTEMS

In this section, we compare three different measuringsystem models: the traditional MI, a cloud-based measuringsystem, and our blockchain-based measuring system model(see Fig. 1). For each model, we describe the relevant super-vision activities, using different sized icons to represent theexpected magnitude of effort and cost associated with it.

A. Traditional MI

Traditional MI can be seen as dedicated computers, calculat-ing measurements of a physical quantity (e.g., size, weight, andspeed). They include sensors for interfacing with the physicalworld and AD converters for gathering data, besides other LRand NLR components, which are usually software modules.Sensors and AD converters are also LR components, beingusually immutable hardware components [see Fig. 1(a)].

Although LR and NLR software separation is a well-knownconcept, many MI manufacturers do not adopt such a prac-tice. The claimed reasons are costs, computational resourcerestrictions, or the existence of legacy software. However,despite their complexity, traditional MI software modules areusually monolithic systems [17]. This fact affects metrological



Fig. 1. Comparing measuring models. (a) Traditional MI. (b) Cloud measuring system. (c) Blockchain measurement system.

assurance activities substantially, making MI regulation andcontrol more expensive and complex, due to the followingaspects.

1) Type approval can demand MI hardware and soft-ware evaluation and check against a set of integrityrequirements. Since, LR and NLR are usually tightlycoupled, notified bodies leading type approval needto evaluate and attest the compliance of all softwaremodules. In some cases, LR software source code mustbe inspected for assuring their correctness.

2) Software validation and verification can become moredifficult due to the diversity of MI use cases, many ofthem being hard to reproduce out of the real measure-ment environment.

3) Metrological supervision requires notified bodies to havesufficient staff to proceed with MI surveillance activitiesin both manufacturing and the field. Although physicalseals can be helpful to protect physical components, theyare ineffective for protecting software components.

Due to their complexity, the activities also demand a highlyqualified professional profile, complementary checking, andgreater supervision staff proficiency. These factors contributeto make MI regulation and control a very expensive andtime-consuming process.

B. Cloud-Based Measuring System

When LR and NLR components are properly separated intoindependent modules, one could run these modules in differentdevices connected by well-defined interfaces. Such architec-ture leads to a DMS. For evaluating its properties, we take acloud-computing MI model inspired by Oppermann et al. [6].In this model, LR and NLR software are running as cloudservices, outside of MI physical set [see Fig. 1(b)]. We assumethat MI communicate with the cloud services using a securechannel (e.g., TLS) and that side channel attacks are infeasible.

When traditional and cloud models are compared, one canobserve that the distributed architecture simplifies MI devices.MI practically do not include software components anymore,once both LR and NLR software modules are running in

the cloud. In practice, MI are now set up as a blend of sensorsand AD converters. A communication interface allows theMI to send sensing raw data to the cloud measuring system.Basically, the MI could be designed only based on hardwarecomponents (e.g., smart sensors and cryptographic chips),although one should consider that some simple software couldbe necessary. In any case, a significant amount of software ismoved from the MI to the cloud, being provided as a service.Consequently, LR and NLR software can be scaled accordingto the demand.

A DMS easily enables software separation. This happensbecause LR and NLR software do not run over a monolithicplatform anymore and that encourages manufacturers to decou-ple LR and NLR software, which consequently makes LRsoftware less complex. Such aspect also impacts LR softwaretype approval efforts, saving time and costs associated withdocumentation analysis, code inspection, and testing.

C. Blockchain-Based Measuring System

Now, we introduce the blockchain model [see Fig. 1(c)].We consider that MI generate and store reliable measure-ments of physical quantities while managing the interests ofdifferent involved parties (e.g., consumption relations). Thus,measurements can be seen as transactions, whose values mustbe protected against tampering and accidental changes [2].Such aspects make DM a typical use case for blockchains’applications.

As a first and intuitive insight, we devise a distributedledger, storing reliable measurement transactions which canbe checked by any involved party. Also, the blockchain wouldsupport the execution of LR (and even NLR) software usingsmart contracts, which process information from sensors andgenerate a consolidated measurement value. The integrityof measurements and LR software (as smart contracts) ispreserved by the blockchain inherent properties [18]. Theledger accounting enables the management of cumulative con-sumption transactions, such as energy and gas metering. If afinancial blockchain platform is used, it can integrate billing



TABLE I

TRADITIONAL MI, CLOUD MODEL, AND BLOCKCHAIN MODEL SECURITY ANALYSIS SUMMARY

and payment functions, and this is an interesting additionalresource when compared to the cloud model.

We can glimpse a practical implementation of such DMSin the following example related to energy measuring.Smart meters can be designed in a straightforward way:a tamper-proof hardware with only: 1) voltage and currentsensors and 2) a module able to sign sensors’ raw data andsend them as a blockchain transaction. In the blockchainnetwork, the peers invoke a smart contract that implementsall remaining LR computation (e.g., signal processing, noisereduction, and values’ integration). The blockchain ledgerstores the final measurement. In turn, one obtains the cumu-lative energy consumption by querying each meter’s storedmeasurements.

There is a crucial difference between blockchain and cloudmodels: the liability of the distributed services. In most usecases, MI belong to one of the parties interested in themeasurement computing result. Energy and fuel are typicalexamples, where vendors of goods own the MI. In the cloudmodel, one can expect that an interested party will hold thecloud measuring services. On the other hand, the blockchainis a truly decentralized architecture, being held potentially byseveral parties. Thus, one can expect that a blockchain modelwill require the contribution of different parties interested inthe measurement activities, and consequently, it will need tobe designed following a different philosophy.

In the blockchain model, we devise measuring as a serviceoffered by someone without any interest in the measuredquantity. This idea is remarkably distinct to the traditionalscenario where a vendor provides MI for measuring and isrewarded proportionally to the measurement. This idea fitsvery well in the blockchain model. Smart contracts can be usedfor computing measurements based on sensing information.However, they are coded by different parties that do nothave conflicts of interest related to the measured quantity.Whatever the measurement result is, these parties shall berewarded by a preset value, and this motivates new playersto provide better measuring algorithms. Additionally, thisstrategy creates incentives for keeping the blockchain networksince that becomes profitable. This concept also breaks thetraditional way MI are used in consumer relations, creating anew market for players who want to offer computing servicesfor measuring.

The blockchain model also enables a set of complementaryactivities involving MI market and field surveillance that canbe done by checking measurements inserted in the distributedledger. Besides notified bodies, any entity representing societyinterests, consumers, and goods providers, among others, cantake part in additional supervision activities. We call thatpublic surveillance. Such efforts can include smart contractsfor generating redundant measurements for counter-proofing,or statistical analyses against the ledger looking for fraudevidence or patterns, for instance.

A last important aspect is the intrinsic blockchain robustnessagainst attacks and failures. Since blockchains make extensiveuse of cryptography in both transactions and storing, informa-tion reaches a high level of protection regarding authenticityand integrity assurance. The known security attacks that cancompromise a blockchain network are related to collusionamong the stakeholders that participate in the consensusdecision [19]. However, as more organizations take part inthe consensus, more expensive and unfeasible these attacksbecome. Thus, blockchains can provide a secure mechanismfor assuring the legal liability and trustworthiness of instru-ments and measurements.

V. SECURITY ANALYSIS

In this section, we present a security analysis by comparingthe measuring models discussed in Section IV. We considerthe attacks and the metrological assurance framework BMAFdescribed previously. We demonstrate how the traditional MIand DMS impact BMAF requirements and activities. Table Ishows such analysis.

Initially, we evaluate traditional MI security. In this sce-nario, one should note that BMAF requirements and activitiesare necessary to prevent attacks. As already discussed inSection IV-A, the activities of control and supervision of tradi-tional MI involve a substantial effort. Documentation analysis,code inspection, and software validation and verification needto be done on all components and software modules. In turn,supervision also requires experienced surveillance techniciansto implement inspection and software integrity checks.

When the cloud model is analyzed, one can notice thatMI become simpler because LR and NLR software are nowrunning in the cloud. Additionally, such situation reducesthe capabilities of a typical attacker (e.g., consumers do not



have physical access to MI software interfaces anymore). TheBMAF protection requirements are still necessary; however,requirements R2 and R3 are applied on the LR software imple-mented in the cloud. Supervision activities are also impacted,requiring fewer efforts to be executed. In A1, the documentanalysis and the code inspection of LR software running inthe cloud are expected to require less effort than embeddedsoftware evaluation. Activity A2 is also made simpler onceLR software tests can now be performed using interface stubs,without the need of real MI physical environment. Simi-larly, A3 also becomes less expensive because LR softwareidentification and integrity check are executed against cloudservers, which are far fewer than the deployed MI. Finally,field surveillance for checking MI physical seals can alsobe eliminated. If we assume simplified MI as immutableinstruments, they can be conceived as tamper-proof devices,and this approach could eliminate the need for verifying MIseals, as it implies that the MI will be permanently damagedand any attack trying to explore such vulnerability will notsucceed.

Finally, we evaluate the blockchain model. In additionto presenting the same characteristics of the cloud model,the blockchain security properties also affect BMAF require-ments and activities. LR software is now a smart con-tract whose deployment rules can be enforced for requiringdevelopers and notified bodies’ attestation, something thatautomatically satisfies R3 and makes its regulation unnec-essary. Once deployed, LR software is distributed amongthe peers, and it cannot be changed anymore. Blockchainpeers cannot execute a different smart contract code. Oth-erwise, blockchain security assumptions will be violated.In consequence, R2 also becomes unnecessary. Regardingthe activities, although A1 and A2 are still necessary, theyshould become much simpler when compared to the othermodels. This happens because the structure of smart con-tracts significantly limits the complexity resulting from havingdifferent technologies, software components, and program-ming languages while imposing software separation. Finally,A3 becomes unnecessary in a blockchain network for the samereasons as R2.

We conclude that while DM already reduces attackers’ capa-bilities, such reduction is more accentuated in the blockchainmodel. Once LR software is produced by players who areexempted from conflicts of interest, many activities relatedto the assurance of software correctness and integrity aremade simpler or even unnecessary. The blockchain securityproperties play an important role in this context.

VI. CASE STUDY

A. Speed Meters and the Case Study Scenario

In this section, we develop an experiment to demonstratethe feasibility of our proposal. It consists of a vehicle speedDMS using blockchains (see Fig. 2). These meters are effi-cient solutions for estimating vehicle speed on public roads,generating traffic statistics, and enforcing speed limits fordrivers [20], [21]. The meter detects each vehicle, determinesits speed, and captures one or more pictures identifying the

Fig. 2. Blockchain-based vehicle speed DMS.

vehicle’s license plate when necessary. The measurement andthe license plate image constitute the LR record, which isexpected to be reliable and protected against frauds.

We choose the city of Sao Paulo, in Brazil, as a case study.Sao Paulo has a vehicular fleet with more than 8 millionvehicles and about one-thousand speed meters deployed alongits roads [22]. Furthermore, over the last two years, we haveproceeded with formal type approval of speed meters inthe Brazilian National Institute of Metrology, Quality andTechnology (Inmetro3). This experience provides valuableinformation that supports the analysis in this section.

Developing countries are essentially guided for legalmetrology policies related to fraud detection andavoidance [1], [3], [12]. In the majority of cases, thesecountries adopt restrictive legal metrology activities, whichinclude detailed type approval processes and intensivemetrological inspection, especially field surveillance, andthis is the Brazilian reality regarding vehicle speed meters.These instruments are under restrictive regulation and controldirectives, which associate them to a WELMEC 7.2 class-Drisk level [14]. In this aspect, the blockchain-based DMScan introduce promising advantages, as it simplifies themetrological assurance framework activities, while preservingmany of the advantages from a DMS in terms of performanceand cost saving.

B. Conceiving a Vehicle Speed Meter DMS

In Brazil, vehicle speed meters are usually built asType-U instruments. WELMEC 7.2 [14] defines this classi-fication as instruments that run their software in universalcomputer hardware. This happens because speed meters nowa-days have an extensive list of requirements and aggregate alarge number of NLR features. Consequently, their software isusually quite complex and hard to evaluate and test. Besides,speed meters’ manufacturers complain about opening theirsolutions for inspection due to intellectual property issues,and this is the case of the speed meters evaluated in Inmetro.So, they are the representative cases of the traditional MImodel described in this paper.

3http://www.inmetro.gov.br



Another aspect is that speed meter owners usually deploytheir equipment at far places along roads spread over largegeographic areas, and this increases the difficulty of regularinspection activities and consequently increases costs associ-ated with metrological surveillance. Thus, all those aspectsmake speed meters strong candidates for solutions that helpto separate LR and NLR software.

We implement such a solution creating a blockchain net-work for DM. We integrate the speed meter’s LR features in asimple tamper-proof hardware that uses two inductive sensorsto capture the vehicle’s magnetic profile [21]. After detectinga vehicle, this hardware uses a private key to sign the sensor’sraw data and sends that to a blockchain-based DMS. Theblockchain executes the LR software as a smart contract andcomputes the vehicle speed. The vehicle detection event alsotriggers any other device used for providing complementaryevidence (e.g., a camera that captures the vehicle license plate).Furthermore, manufacturers may aggregate any other modulenecessary for implementing NLR functionalities or even usethe blockchain to do that. Their decision does not affect thelegal metrology activities once NLR features are not underregulation.

C. Architecture Using Hyperledger Fabric

Our prototype uses Hyperledger Fabric [11] as a permis-sioned blockchain, where the peers cooperate to store mea-surements and execute LR software. Fabric is an open sourceblockchain platform that includes two concepts that are veryhelpful for implementing our idea: endorsers and securitypolicies.

Endorsers are peers that effectively execute smart contracts,which are called chaincodes in Fabric. The way endorsersoperate has significant implications concerning intellectualproperty and performance. First, a manufacturer needs toreveal its LR software only to peers contracted to executetheir measuring chaincode as a service and to the notifiedbody responsible for approving it. Second, a manufacturer cansize their solution performance by providing as many endorserpeers as necessary, resulting in a scalable architecture.

Security policies can set the way the network validates themeasurement provided by endorsers. These policies can alsowork as a protection mechanism against collusion attacks andimplement metrological surveillance. Blockchain networks areconstituted by peers that belong to different stakeholders ororganizations. Although they do not need to trust each other,each peer continually verifies other peers’ behavior. Securitypolicies define rules for such monitoring. They can specify,for instance, which organizations must take part in a transac-tion endorsement (i.e., a measurement calculation). The moreorganizations are involved, the more expensive it becomes tocarry out a collusion attack. Such monitoring activities are asort of metrological surveillance, since different organizationsare continually checking the measurements resulting from achaincode execution.

Since we resort to a permissioned blockchain, the consensusprotocol plays an important role in our experiment. Fabricrefers to consensus as an orderer service. We perform our

Fig. 3. Vehicle speed DMS solution scheme.

experiment with two different types of orderer services: thesolo orderer and the Byzantine fault-tolerant (BFT) orderer.The solo orderer service is native from Fabric distribution,and it is very practical to implement tests and develop proof-of-concept prototypes. However, regarding security, the soloorderer cannot be considered a suitable solution because itimplies that consensus come from only one organization.In turn, the BFT orderer [15] is fully replicated for toleratingByzantine failures. Thus, one can configure the BFT ordererwith several replicas, with different organizations controllingeach one of them. Such an approach employs a decen-tralized consensus provided by the BFT-SMaRt replicationlibrary [23], thus providing security against collusion attacks.

D. Describing MI Regulation and Control Activities

We set up our vehicle speed DMS, as shown in Fig. 3.Inmetro and LaSIGE represent two independent organizationswith distinct functions. Inmetro is a notified body responsiblefor regulating and controlling such instruments. LaSIGE pro-vides computational resources for executing LR software fromspeed meters.

The speed meter manufacturer implements LR software as achaincode. We create a chaincode written in Go that analysesraw data from both sensors and finds the moment when thevehicle activates each sensor. Once the samples are taken inregular periods and we know the distance between the sensors,it becomes trivial to determine the vehicle speed. When themeter also enforces speed limits, one or more images fromthe vehicle’s license plate can be necessary. Such requirementbrings some concerns about privacy. Although the image ispart of the LR information, it is not necessary for determiningthe vehicle speed. So, one can use different approaches toavoid problems with privacy. One idea consists of encryptingthe images using asymmetric cryptography before sendingthem to the blockchain. One can do that using the public keyof the legal authority responsible for issuing traffic tickets.A better alternative is to send only the image digital signatureto the blockchain. The image is kept in a private data storage,and the blockchain can attest its integrity and authenticitywhenever necessary. Such an approach improves performanceand eliminates privacy concerns. We consider this approach inour solution.



Our experiment assumes the implementation of legal metrol-ogy activities as follows. Firstly, the notified body proceedswith the MI type approval. He does that by evaluating the MIdevice (i.e., inspecting sensors and cryptographic and com-munication features) and the LR source code (i.e., the Fabricchaincode). Then, the notified body executes the applicabletests for assuring all MI LR functionalities. Once MI hardwareand software are approved, the notified body is responsible forinstantiating the chaincode in the blockchain.

In Fabric, a chaincode instantiation includes the notificationof endorsers that will execute that chaincode. To do that,the notified body inserts into the blockchain a new transactioncomprised by the chaincode fingerprint (i.e., the softwareimage hash) and its respective security policy. Thus, all thepeers in the network know how to validate the chaincodeexecution by checking the applicable security policies. Afterinstantiation, the chaincode fingerprint becomes immutable,following the intrinsic blockchain properties. Any futureupdate in the chaincode will require a new instance of it, whichmeans to create a new chaincode version.

After Inmetro instantiates the LR chaincode, any MI ownercan contract computing services from the LaSIGE organizationfor executing the respective LR software. In practice, LaSIGEprovides endorser peers. One must note that LaSIGE is theonly one possible organization that can offer such a service.Although we have only two organizations in our experiment,a real scenario can include several independent organizations.Each one of them could have endorser peers offering measur-ing services. Once the MI owner finds an available endorserpeer, it need to install the approved LR chaincode, and thisenables any MI in the field to generate transactions, askendorsers to determine the vehicle speed, and store the vehiclespeed LR information in the blockchain ledger.

E. Security Analysis

We verify how our implementation offers countermeasuresagainst the common attacks associated with the capabilitiesdescribed at Section III-A. These countermeasures match theproperties already discussed in Section V. In the following,we describe some attacks and how our blockchain-based DMSdeals with them.

1) Attacker Tries to Compromise the Speed Meter Hard-ware Integrity: We conceive the speed meter hardware as atamper-proof device. Consequently, any attempt at violatingseals or stealing a private key shall destroy the speed meterhardware, forcing its replacement and exposing the attacker.

2) Attacker Tries to Install a Malicious Chaincode in anEndorser Peer: The blockchain ledger contains the fingerprintof every instantiated chaincode, and legitimate endorsers auto-matically check the LR chaincode integrity on deploy time.If a malicious speed meter owner tries to install a modifiedLR chaincode version, the endorser refuses such software.Furthermore, the endorser appends a transaction registry inthe blockchain, and this can be useful in audits for detectingattacks against software integrity in the future.

3) Attacker Can Collude With an Organization for LoadingMalicious Chaincode in Endorser Peers: Security policies

assure protection against collusion attacks. For instance, sup-pose that an attacker colludes with LaSIGE, making com-promised peers accept a modified LR chaincode. One canavoid such attack by enforcing security policies defining thatat least N peers of different organizations must endorse thechaincode execution. Thus, a collusion attack, including onlythe LaSIGE organization, will not succeed. The attacker needsto compromise more organizations, which makes the attack tooexpensive and, consequently, unfeasible.

4) Attacker Has Success in Colluding With Enough Peers forInjecting Fraudulent Measurements in the Blockchains: Oneshould remember that, in the proposed DMS, organizationscompute measurements as an independent service (i.e., they donot have any advantage or reward regarding the measurementresult). Such business model discourages collusion and makesthese attacks disadvantageous. Even so, assuming that anattacker succeeds in compromising a sufficiently large numberof peers for endorsing a malicious transaction, one can exposesuch fraud by auditing the measurement record. Since, Inmetrokeeps any approved LR chaincode and the blockchain recordsall information used in any transaction, Inmetro can reexecutethe LR chaincode and compare the obtained measurements.The sensor raw data can easily have its integrity verifiedby using the MI public key. Regarding the MI private keyintegrity, we already discussed this issue in the first attackdescribed in this section.

VII. PERFORMANCE ISSUES

An essential step in our experiment is the speed meter DMSperformance evaluation. We try to estimate the blockchainpeers’ behavior without considering network communicationissues. Essentially, we are interested in two main aspects.

1) The throughput and latency within each endorser peer.This subject is important because it helps to estimatehow many peers a speed meter owner will need, consid-ering a specific demand.

2) The throughput of a simple blockchain network config-uration. We test a high number of transactions against anetwork consisting of only two peers (one of them as anendorser) and two different types of consensus service.

A. Demand Goals

We estimate the experimental demand based on vehi-cles’ traffic real data. According to a technical report fromSao Paulo’s Traffic Engineering Company [22], there were,in 2016, approximately one thousand speed meters spreadalong the city. The same report analyses the vehicles’ flowon the main roads in the city and points out an aver-age of 2772 vehicles/h (or 0.76 vehicles/s) during rushhour. Assuming such demand for a total of one thou-sand speed meters, we need a blockchain network able toprocess something around 800 transactions per second (tps).Androulaki et al. [11] benchmarked Fabric performance insomething between 2000 and 3000 tps. However, they considerspecific scenarios with proper customizations for evaluat-ing particular performance issues. Our experiment does notemploy any specific customization. We use Fabric just as pro-vided by its developers, in an ordinary hardware infrastructure



Fig. 4. Throughput and latency using native Fabric solo orderer.

available in any datacenter. The objective is to evaluate theresults that a speed meter solution owner can obtain by usingFabric.

B. Test Environment Setup

Our blockchain network environment consists of three nodesfrom a Dell PowerEdge R410 cluster. Each node has twoCPUs’ Intel Xeon Processor E5520 with 2.27 GHz and 32 GBof RAM. Fabric standard distribution version 1.14 runs overdocker containers, so that each physical node can host severalpeers. For the sake of simplicity, we use three nodes forallocating the orderer service, the LaSIGE peers, and theInmetro peers, respectively.

Regarding the orderer service, we test two different scenar-ios. The first one is the native Fabric’s solo orderer service,which is provided primarily for testing. The second scenariouses the orderer service developed by Sousa et al. [15], whichtolerates Byzantine failures.

The client transactions’ load is mimicked using four nodesfrom a Dell PowerEdge R300 cluster, each one with an IntelXeon Processor L5410 with 2.33 GHz and 8 GB of RAM.The transactions simulation uses real data from speed metersdeveloped by the company Perkons5 SA, which kindly granteda data set for this experiment.

C. Test Methodology

The performance tests execute as follows. Each physicalmachine creates the respective Fabric docker containers (peersor clients). Client containers are responsible for generatingtransactions. We use Fabric as an off-the-shelf solution, withoutany customization. Each client instance corresponds to acontainer process that sends transactions to the blockchain.We try to produce a maximum workload by increasing thenumber of clients.

When a client instance is created, it selects a vector of bytescontaining the sensors’ raw data from the data set mentionedabove, for each transaction. Clients use the Fabric protocol toinvoke an LR chaincode and send such data as an argument toan endorser peer from LaSIGE organization. The endorser peerreceives the vector of bytes, calculates the vehicle speed, and

4http://hyperledger-fabric.readthedocs.io/en/release-1.15http://www.perkons.com

Fig. 5. Throughput and latency using BFT orderer with four replicas.

returns an endorsed package with the respective measurement.The client uses such package for composing the completetransaction and sends it to the orderer service responsible forgenerating the ledger blocks and disseminating them to theother peers. The client also keeps the records of timestampsand the elapsed time for completing the transaction. Suchinformation gives the throughput and latency of the system.

D. Performance Test Results

Figs. 4 and 5 show our tests results for the system using thesolo orderer and the BFT orderer with four replicas, respec-tively. With the solo orderer service, throughput and latencyreach a better tradeoff around 300 tps and 1 s, respectively.The workload necessary to get such results corresponds to600 simultaneous clients. With a higher workload, perfor-mance degrades substantially. We reach a throughput of around260 tps and a high latency of 12 s when testing a workloadfrom 1200 clients. This high latency can be explained by thetransactions queuing in the solo orderer.

The BFT orderer service with four replicas performs better.It reaches the best tradeoff with a throughput of 380 tps and alatency in 1.6 s with the same workload of 600 simultaneousclients. The BFT orderer also keeps throughput stable at about360 tps even with a workload of 1200 clients, presentingonly a slight increase of 1 s in latency. The BFT ordereroptimizes latency by discarding the exceeding of transactionsafter reaching its max throughput. However, clients need tocontrol refused transactions, creating their queue and resendingthe transaction again after some time.

The BFT orderer service also includes an important aspect.It enables a truly distributed consensus service, once eachreplica belongs to a different organization. Although thenumber of replicas impacts performance [23], it aggregatessecurity by preventing collusion attacks.

One can observe that our results point out a difficulty indealing with the estimated peak demand of 800 tps. However,we understand that the blockchain can absorb such demandalong the day, since the number of transactions goes down afterthe rush hour. We conclude that Fabric performs satisfactorilyfor implementing a speed meter DMS. Furthermore, if neces-sary, one can even reach a better performance by customizingFabric features, something indeed feasible once the platformis an open source software product.



TABLE II

ADVANTAGES AND DRAWBACKS OF THE TRADITIONAL MIAND OUR FABRIC DMS IMPLEMENTATION

VIII. QUANTITATIVE ASSESSMENT

In this section, we provide some quantitative assessmentregarding the adoption of the blockchain-based DMS model,when compared with traditional MI. We do that by evaluat-ing advantages and drawbacks related to both technologies(see Table II). The discussions present in the section arenot exhaustive. Actually, they are the preliminary results ofa risk analysis study in progress at the moment. However,we believe that the discussed aspects are useful for providingassessment information to people interested in implementinga blockchain-based DMS.

A. Software Vulnerabilities

There is a direct relation between the size of asoftware product and the number of software defects.Alhazmi et al. [24] estimated that the ratio of remaining vul-nerabilities to the total number of software defects is often inthe range of 15%. Considering that, we estimate how much theamount of LR software can impact the security of traditionalMI and blockchain-based DMS. In our analysis, we adoptthe average ratio of approximately 6 D/kLOC (defects bythousands of lines of code) reported by Carrozza et al. [25].In our experience with speed meters’ type approval at Inmetro,we found that LR software average size is around 3000 LOCs.This software size statistically suggests the existence of about18 software defects and, consequently, a high probability ofhaving a vulnerability. Such LR software size is a consequenceof the strong coupling between LR and NLR modules. Whenone considers only the software effectively used in measuring,the LR software size can be remarkably reduced. We confirmthat in our speed meter DMS implementation. Its LR softwareconsists of a Go language chaincode that requires no morethan 200 LOCs. Such size points out an estimate of no morethan two remaining software defects, which also reduces thechances of potential vulnerabilities.

B. Code Inspection Efforts

The LR software size also affects the efforts requiredby the MI type approval, especially code inspection activ-ities. We evaluate such impact by using the studies ofEbert and Jones [26] about the quality of embedded software.Their work reports an average production rate of 60 func-tion points (FP) by men/month in code inspection. Sincethe majority of the manufacturers implement their softwarein C language, we adopt the FP/kLOC conversion rate

6The analysis do not include the hardware required for NLR software.

in the QSM Function Point Languages Table7 of approxi-mately 100 LOCs per FP. Considering the LR software sizesestimated previously, we have an expected code inspectioneffort of 0.5 men/month in the traditional MI model against0.033 men/month in the blockchain-based DMS.

C. Costs With Hardware

Other important aspect concerns the costs associated withthe Type-U hardware adopted by speed meters’ manufacturers.In Brazil, due to the high temperatures associated with thetropical climate, manufacturers need to build their metersusing specific motherboards and components. Such hardwareeasily exceeds U.S. $ 500, something that makes the Braziliantraditional speed meters a quite expensive product. In ourexperiment, we consider the deployment of 1000 speed meters,which corresponds to the number of such devices in Sao Paulo.Traditional speed meters using Type-U hardware imply a directcost of approximately U.S. $ 500,000. In our implementationusing Fabric, we succeeded in executing the LR software of thesame number of MI in only three nodes of a Dell PowerEdgeR410 cluster, which represents a cost with hardware that doesnot exceed U.S. $ 5000. We cannot directly compare bothscenarios because manufacturers avail the Type-U hardwaredeployed in the field to provide NLR features. However,we understand that the NLR software can also be providedby independent remote services. Furthermore, the requiredhardware becomes less expensive once remote services runfrom data centers where the environment does not present thesame inclement weather found in the field. Thus, cost savingis evident in the adoption of a distributed and decentralizedsolution.

D. Connectivity Dependence and Demand

Connectivity is a critical requirement in theblockchain-based DMS. The simple MI hardware needs tosend sensing information to the blockchain on every vehicledetection. If the device loses connectivity, the informationmust be discarded or stored in temporary memory. Suchscenarios can require a more sophisticated MI hardware(e.g., additional memory for temporary data and a statemachine to deal with connectivity restrictions) or evencompromise MI availability. On the other hand, the traditionalMI includes enough computational resources to manageinformation when there is no connectivity. They can evenoperate offline for several days without any problem relatedto information loss.

Concerning the demand by connectivity, we can state thatboth solutions are similar. Although the traditional MI cansend information in the batch mode, the expected amount ofinformation is practically the same as in the blockchain-basedDMS. Furthermore, despite the extensive use of cryptographyin a blockchain application, that does not represent a signifi-cant overhead regarding the amount of propagated information.Roughly speaking, the use of connectivity resources dependson the number of detected vehicles and not from the adoptedmodel.

7http://www.qsm.com/resources/function-point-languages-table



E. Service Reliability and Availability

We evaluate the reliability and availability of the servicesprovided by both speed meter models by comparing the prop-erties of a centralized and a distributed system. In ReliabilityTheory, the mean time between failures (MTBF) and the meantime to repair (MTTR) are the traditional measures of thereliability and availability of a system [27].

Traditional MIs are centralized solutions and can easilybecome a single point of failure. Although the same happenswith the simple MI hardware in the blockchain-based DMS,one knows that complex systems fail more often than simplerones. So we can state that the MTBFh of the simple MIhardware used in the blockchain-based DMS is expected to behigher than the MTBFH of traditional MI. Regarding the peersproviding LR software execution, we claim that blockchainsare based on distributed trust instead of a single point oftrust, and this means the blockchain fails only if multiplestakeholders collude against the system. Our implementationuses redundant peers (or replicas) with Byzantine consensus,which tolerates F faults for N = 3F + 1 nodes [15]. Everyreplica has its own MTBFR . The blockchain-based DMS totalMTBF needs to consider that the replicas can present parallelfaults, while the simple MI hardware and the set of replicasaffect each other in serial faults. In turn, availability estimativedepends primarily on the MTTR [27]. Consequently, if theorganizations integrating the blockchain consensus can restoreany faulty replica in an interval time T ≤ MTBFR ∗ F , theycan assure the service availability.

At the moment we write this paper, we do not have enoughquantitative information for estimating the MTBF and MTTRof each solution model. However, we can state two crucialaspects.

1) The blockchain-based DMS is expected to present ahigher MTBF due to its simpler hardware in the fieldand because it does not have a single point of failure atthe blockchain.

2) The blockchain-based DMS is expected to present abetter availability ratio due to its inherent fault tolerance.

Considering this discussion, we estimate the traditionalMI model as presenting a fair availability level, while theblockchain-based DMS is expected to offer high availability.

IX. CHALLENGES AHEAD

Although blockchain-based DMS is a promising approach,several challenges need to be addressed for their use. Some ofthem become very clear after we proceed with our practicalexperiment. We highlight the following main issues that shouldbe addressed in the future works.

1) The Measurement Big Data: MI usually manipulate ahigh amount of data. In a large-scale scenario (e.g.,energy meters in a smart grid), MI can update theirmeasurements faster, generating lots of transactions.A network connecting millions of meters may gen-erate a transaction load unfeasible to be processedby existing blockchains. In our tests with Fabric, forinstance, we reach a max throughput of 380 tps, althoughAndroulaki et al. [11] points out a performance more

than of 2000 tps in their benchmark. However, even suchperformance may not be enough to meet the demandfor measurements on a smart grid, for instance. In suchscenarios, solutions can require different workaroundsand creative alternatives. We recall the use of endorsers,an idea that we explored with success in our experiment.Besides, one can try to use aggregated measurements forreducing transactions in a blockchain. Also, one can trysmarter MI for determining transactions on demand.

2) Measuring and Privacy: Measurements assigned to aspecific person allow to infer information about theirhabits and lifestyle. In a blockchain with a publicledger, this problem becomes more serious. One needsto establish an acceptable tradeoff between privacy andefficiency. In our experiment, we faced such a problemwith the vehicle license plate image and solved it by stor-ing such information outside of the blockchain. How-ever, depending on the application scenario, privacy canrequire more sophisticated mechanisms for protecting orobfuscating identities, such as pseudonyms or identityprotection layers. Permissioned blockchains constitutea suitable alternative once they contemplate an accesscontrol layer built into blockchain nodes [16]. One canalso constrain access policies in such a manner that theysatisfy privacy rules and restrictions.

3) Communication Issues: Although we consider MI asconnected devices, communication can be a problem inapplications demanding real-time decisions, and this isa restriction for any DMS over asynchronous networks.Thus, blockchain-based measuring is not appropriate forall MI applications. Furthermore, attacks targeting com-munication (e.g., DDoS) represent an additional risk,although decentralized systems, such as blockchains, aremore resilient to such attacks than conventional cloudarchitectures.

4) Oracles Authentication: External information providersare usually called oracles in blockchain architectures.In the described model, MI sensors can be seen asoracles since they are responsible for providing informa-tion from the physical world. Even though sensors aresmall components which can be protected using physicalseals, sensors authentication can be necessary to assuremeasuring reliability.

X. CONCLUSION

In this paper, we discussed how blockchains can be usedto support DMS. Due to their intrinsic security proper-ties, blockchains can improve MI metrological assurance byimposing restrictions against potential attacks while reducingtechnical efforts related to regulation and control activities.We demonstrated those properties by implementing a vehiclespeed meter DMS using Hyperledger Fabric. Our results wereconsistent, and they support the feasibility of our proposal.However, despite its promising application, blockchains poseseveral challenges that need to be faced. The main ones arerelated to the amount of data, privacy, communication, andoracles authentication. Future work shall include a complete



risk analysis of our blockchain-based model to develop newstrategies for addressing the challenges discussed here.

ACKNOWLEDGMENT

The authors would like to thank Perkons SA for kindlyproviding the speed meters’ data set used in the experimentsof this paper.

REFERENCES

[1] B. A. R. Filho and R. F. Gonçalves, “Legal metrology, the economyand society: A systematic literature review,” Measurement, vol. 69,pp. 155–163, Jun. 2015.

[2] M. Esche and F. Thiel, “Software risk assessment for measuring instru-ments in legal metrology,” in Proc. Federated Conf. Comput. Sci. Inf.Syst., vol. 5, 2015, pp. 1113–1123. [Online]. Available: https://fedcsis.org/proceedings/2015/drp/127.html

[3] S. Camara, R. Machado, and L. F. R. C. Carmo, “A consumption authen-ticator based mechanism for time-of-use smart meter measurements ver-ification,” Appl. Mech. Mater., vols. 241–244, pp. 218–222, Feb. 2012.[Online]. Available: http://www.scientific.net/AMM.241-244.218

[4] D. R. Boccardo et al., “Software validation of medical instruments,” inProc. IEEE Int. Symp. Med. Meas. Appl. (MeMeA), Oct. 2015, pp. 1–4.[Online]. Available: http://ieeexplore.ieee.org/document/6860090/

[5] D. Peters, F. Thiel, M. Peter, and J.-P. Seifert, “A secure softwareframework for Measuring Instruments in legal metrology,” in Proc. IEEEInt. Instrum. Meas. Technol. Conf. (I2MTC), May 2015, pp. 1596–1601.[Online]. Available: http://ieeexplore.ieee.org/document/7151517/

[6] A. Oppermann et al., “Secure cloud computing: Reference archi-tecture for measuring instrument under legal control,” Secur.Privacy, vol. 1, no. 3, pp. 1–26, 2018. [Online]. Available:https://onlinelibrary.wiley.com/doi/full/10.1002/spy2.18

[7] S. Nakamoto. (2008). Bitcoin: A Peer-to-Peer Electronic Cash System.[Online]. Available: https://bitcoin.org/bitcoin.pdf

[8] K. Christidis and M. Devetsikiotis, “Blockchains and smart contracts forthe Internet of Things,” IEEE Access, vol. 4, pp. 2292–2303, 2016.

[9] D. Peters, J. Wetzlich, F. Thiel, and J.-P. Seifert, “Blockchain applica-tions for legal metrology,” in Proc. IEEE Int. Instrum. Meas. Technol.Conf., Houston, TX, USA, 2018, p. 6.

[10] W. S. Melo, Jr., L. F. Carmo, A. Bessani, N. Neves, and A. Santin,“How blockchains can improve measuring instruments regulation andcontrol,” in Proc. IEEE Int. Instrum. Meas. Technol. Conf., Houston,TX, USA, 2018, p. 6. [Online]. Available: https://ieeexplore.ieee.org/document/8409724/

[11] E. Androulaki et al., “Hyperledger fabric: A distributed operating systemfor permissioned blockchains,” in Proc. 13th EuroSys Conf., Porto,Portugal, 2018, p. 30.

[12] H. Luchsinger, C. Cajica, M. Maldonado, and I. Castelazo, “Are gaspumps measuring up? The mexican experience,” NCSLI Measure, vol. 3,no. 2, pp. 62–68, 2008.

[13] OIML D 31, Editon 2008: General Requirements for Software ControlledMeasuring Instruments, Int. Org. Legal Metrol., Paris, France, 2008,p. 53.

[14] WELMEC 7.2 Guide, Eur. Cooperation Legal Metrol. (WELMEC),Braunschweig, Germany. [Online]. Available: https://www.welmec.org/

[15] J. Sousa, A. Bessani, and M. Vukolic, “A Byzantine fault-tolerantordering service for the hyperledger fabric blockchain platform,” in Proc.48th Annu. IEEE/IFIP Int. Conf. Dependable Syst. Netw. (DSN), 2018,pp. 51–58.

[16] M. Vukolic, “The quest for scalable blockchain fabric: Proof-of-work vs. BFT replication,” in Open Problems in Network Secu-rity (Lecture Notes in Computer Science), vol. 9591. Cham,Switzerland: Springer, 2016, pp. 112–125. [Online]. Available:https://link.springer.com/chapter/10.1007/978-3-319-39028-4_9

[17] V. Abreu et al., “A smart meter and smart house integrated to an IdMand key-based scheme for providing integral security for a smart gridICT,” Mobile Netw. Appl., vol. 23, no. 4, pp. 967–981, 2017.

[18] Z. Zheng, S. Xie, H.-N. Dai, and H. Wang, “Blockchain challenges andopportunities: A survey,” Int. J. Web Grid Services, vol. 14, no. 4, p. 352,2018. [Online]. Available: http://inpluslab.sysu.edu.cn/files/blockchain/blockchain.pdf

[19] G. O. Karame and E. Androulaki, Bitcoin and Blockchain Security.Norwood, MA, USA: Artech House, 2016.

[20] Y.-K. Ki and D.-K. Baik, “Model for accurate speed measurementusing double-loop detectors,” IEEE Trans. Veh. Technol., vol. 55, no. 4,pp. 1094–1101, Jul. 2006.

[21] S. S. M. Ali, B. George, L. Vanajakshi, and J. Venkatraman, “A multipleinductive loop vehicle detection system for heterogeneous and lane-lesstraffic,” IEEE Trans. Instrum. Meas., vol. 61, no. 5, pp. 1353–1360,May 2012.

[22] “Pesquisa de monitoramento da mobilidade: Mobilidade no sistemaviário principal: Volume e velocidade-2015,” Companhia EngenhariaTráfego, Sao Paulo, Brazil, CET Rep., Jun. 2016.

[23] A. Bessani, J. Sousa, and E. E. P. Alchieri, “State machine replicationfor the masses with BFT-SMaRt,” in Proc. 44th Annu. IEEE/IFIP Int.Conf. Dependable Syst. Netw. (DSN), Jun. 2014, pp. 355–362.

[24] O. H. Alhazmi, Y. K. Malaiya, and I. Ray, “Measuring, analyzing andpredicting security vulnerabilities in software systems,” Comput. Secur.,vol. 26, no. 3, pp. 219–228, May 2007.

[25] G. Carrozza, R. Pietrantuono, and S. Russo, “Defect analysis in mission-critical software systems: A detailed investigation,” J. Softw., Evol.Process, vol. 27, no. 1, pp. 22–49, 2015.

[26] C. Ebert and C. Jones, “Embedded software: Facts, figures, and future,”Computer, vol. 42, no. 4, pp. 42–52, Apr. 2009.

[27] I. Koren and C. M. Krishna, Fault-Tolerant Systems. Amsterdam,The Netherlands: Elsevier, 2010.

Wilson S. Melo Jr. received the Ph.D. degree in computer science from theFederal University of Rio de Janeiro, Rio de Janeiro, Brazil.

He is currently a Researcher with the Brazilian National Institute ofMetrology, Quality, and Technology (Inmetro), Duque de Caxias, Brazil.He has more than 20 years of experience in software development andtesting projects. His main expertise is software for industrial applications,especially solutions related to measurement, control, patterns’ recogniz-ing, and cybersecurity. More information about him can be found athttps://www.researchgate.net/profile/Wilson_Melo_Junior.

Alysson Bessani is an Associate Professor of the Faculty of Sciences of theUniversity of Lisboa, Portugal, and a member of LASIGE research unit. Heholds a Ph.D. in Electrical Engineering from UFSC (Brazil) and was a visitingprofessor in Carnegie Mellow University (2010) and a visiting researcherin Microsoft Research Cambridge (2014). He is the co-author of morethan 100 peer-reviewed publications on dependability, security, Byzantinefault tolerance, and cloud. More information about him can be found athttp://www.di.fc.ul.pt/∼bessani/.

Nuno Neves (M’95) is Professor with the Department of Computer Science,Faculty of Sciences, University of Lisboa, Lisbon, Portugal, where he alsoleads the Navigators Research Group and is on the Coordination Board ofthe LaSIGE Research Unit. He is Vice-Chair of the IEEE TC on DependableComputing and Fault Tolerance. His main research interests include securityand dependability aspects of distributed systems.

Dr. Neves is currently an investigator in several national and EU projects,such as SEAL and uPVN. His work has been recognized in several occasions,for example with the IBM Scientific Prize and the William C. CarterAward. He is on the Editorial Board of the International Journal of CriticalComputer-Based Systems. More information about him can be found athttp://www.di.fc.ul.pt/∼nuno.

Altair Olivo Santin (M’00) received the B.S. degree in computer engineeringfrom the Pontifical Catholic University of Paraná (PUCPR), Curitiba, Brazil,in 1992, the M.Sc. degree from the Universidade Tecnológica Federal doParaná, Curitiba, Brazil, in 1996, and the Ph.D. degree from the UniversidadeFederal de Santa Catarina, Florianopolis, Brazil, in 2004.

He is currently a Full Professor of the Graduate Program in ComputerScience and the Head of the Security and Privacy Laboratory, PUCPR.

He is a member of the ACM and the Brazilian Computer Society.

Luiz F. Rust C. Carmo received the Ph.D. degree in computer science fromthe LAAS/CNRS, Toulouse, France, in 1994.

He is currently a Senior Specialist in computer science with the BrazilianInstitute of Metrology, Technology and Quality (Inmetro), Duque de Caxias,Brazil, where he is the General Coordinator of the Education Center. He isalso an Active Lecturer of both the doctoral programs in computer scienceof the Federal University of Rio de Janeiro, Rio de Janeiro, Brazil and inmetrology of Inmetro. His research interests include information security andembedded systems.

Documents

Using Blockchains to Implement Distributed Measuring Systemsbessani/publications/tim19-blockchain.pdf · preventing the whole chain from being modiﬁed and requir-ing an agreement