Facility management deals with all activities that are not core business for a company and are consequently outsourced to specilized companies. Maintenance is a fundamental activity in facility management and it is often handled by Global Maintenance Services (GMS) where some maintenance activities are delegated by the company to service providers and are remunerated according to measurable results expressed as Key Performance Indicators. In this context, it would be desirable to have information systems trustable by all involved actors. In this paper, we discuss the design of a blockchain solution capable to support a GMS on-chain. We first introduce the GMS concept and how it is related to the Principal-Agent relationship, then we show a reference architecture to implement GMS on-chain. We discuss a use case of on-chain GMS in a hospital showing how smart contracts and oracles can be used in this context. We present the advantages of this approach and we discuss the open problems for realizing a proof-of-concept.
Facility Management (FM) deals with managing the facilities, namely all assets, both tangible and intangible, that support a company’s core business making the life of occupants of residential buildings, shops, ofices or factories more pleasant and safe. Within FM, a Global Maintenance Service (GMS), is a form of outsourcing contract specifically related to maintenance and based on measurable results. Through a GMS contract, a client, or principal, entrusts a series of activities aimed at the maintenance of the facilities to a single primary service provider, or agent, for a well defined period of time. The following elements are relevant to this paper for a GMS contract. • The contract is based on results. The remuneration is a function of a series of Key Performance Indicators (KPIs) through which it is possible to measure the quality, eficiency and efectiveness of the performed activities. • There is a working group made up of representatives of the client and the primary service provider, whose function is to ensure the correct start and execution of the project, with particular regard to the implementation of integrated management tools. • The primary service provider appoints a single manager, with respect to which the client can refer as the sole interlocutor and who has responsibility for the activity of all the personnel involved in the performance of the services covered by the contract. The primary service provider can delegate some activities to secondary service providers. Real estate assets. Their ordinary and extraordinary maintenance, plant maintenance, cleaning and surveillance services.
Green. Paving, cleaning, cutting of the grass, refurbishment of green areas. Heat. Ensure the heating and air conditioning system including the supply of fuel, gas and electricity.
GMS can be modelled as a relationship between a Principal (P) and an Agent (A) [
Usually, the client pays the provider either on the basis of measurements declared by the provider or by performing measurements by themselves. In the first approach, the client must trust the provider. In the second approach, the costs of the client for autonomously performing the measurements might be too high with respect to the benefits of the outsourcing approach.
In this paper, we propose an architecture based on blockchain and IoT technologies to address this problem. We also provide details for a sample use case of this approach encompassing oracles to acquire measurements from IoT devices into the blockchain. Our sample use case Use
1..1 0..n
1..1 Client (P) 1..1
KPI
Refer
1..1 1..1 Measured with
Facility Manager
Partner 1..n GMS Contract (C) 1..1 1..1
Maintain Name 1..1
0..n 1..1
Primary Service
Provider (A)
0..1 Delegate
1..1
Secondary Service Provider is taken from a real tender for heat maintenance related to an Italian hospital. We provide examples of smart contract code to realize that use case.
This paper is structured as follows. In Section 2, we provide background notions about blockchain technologies and how they are able to access of-chain data through oracles. In Section 3, we describe the architecture of a blockchain-based GMS and how it benefits from this technology. Finally, Section 4 draws the conclusions of the paper and provides some discussion about open problems.
A blockchain is a type of Distributed Ledger Technology (DLT) where transactions, new records
to the ledger, are recorded according to an immutable order obtained by means of cryptographic
hash functions that chain the blocks in which transactions are recorded. Unlike a centralized
database, a blockchain is decentralized, namely there is no need for a central authority or
intermediary for processing, validating, and/or authenticating transactions. A blockchain is
typically managed by a set of autonomous nodes that collectively create a peer-to-peer (p2p)
network adhering to a protocol for inter-node communication and validating new blocks. Nodes
do not trust each other and malicious nodes are tolerated, within certain limits that depends
on the consensus algorithm. The most common blockchains can be abstracted as a key-value
database. For example, in a blockchain implementing a cryptocurrency, keys are addresses
(or accounts), while values are the balances of their wallets. In this scenario, a transaction
is an operation that transfer some cryptocurrency from a wallet to another. For eficiency
reasons, transactions are not confirmed one-by-one but aggregated into blocks. Transactions
are confirmed when a new block is created (or mined). The mining of a new block requires
to verify that all transactions of the block, considered in the chosen order, comply to certain
consensus rules (that depends also on the application domain). When a new block is mined by a
node of the network, all the other peers verify that it respects the consensus rules in a process
called validation. The consensus (for more details, see [
There are two types of blockchains that can be categorized according to the access in reading and writing to the content of the ledger and to the access in participating to the consensus. In public blockchains, everyone can read the content of the ledger and propose new transactions that, if successfully validated by the consensus, will be eventually stored in the ledger. On the contrary, in private blockchains, users are authenticated and access control allows or denies each user operation as occurs for access control of regular information systems. Similarly, in permissionless blockchain every user can participate in the consensus, while in permissioned one the participation in the consensus is allowed only to specific users.
While initially blockchain has been primarily conceived to implement cryptocurrency trading, it can now be adopted to realize general-purpose applications through the use of smart contracts. They consist of pieces of code that are executed as part of a transaction. In simple terms, in these cases, the blockchain implements a global decentralized virtual machine and smart contracts are the programs running on it.
Smart contracts can process only data that are stored in the blockchain. However, in the
GMS use case that we consider in this paper, there is the need of accessing of-chain data. This
is possible using an Oracle (for more details, see [
We have seen that GMS can be modeled as a P/A relationship (see Figure 1). In such a relationship, the agent acts on behalf of the principal and should not have a conflict of interest in carrying out its task. An agent may act in its own best interests and in a way that is contrary to the best interests of the principal, generating the so-called P/A Problem. This problem typically arises when P has into enough information to directly ensure that A is always acting in P’s best interest.
The transparency, immutability, traceability and algorithmic governance ofered by Blockchain
technologies can contribute to mitigate the P/A Problem [
The employment of the blockchain, allows us to envision new models of governance, where trust between the actors is substituted by A and P relying on the consensus within the P2P blockchain infrastructure, i.e. relying on a community rather than on the trust in individual actors. In this perspective, the natural diferent interests of P/A, at least economically-wise, as well as the participation of diferent providers competing in the market, are guarantees to the achievement of a real consensus among the parties, even in less open infrastructure such as the permissioned blockchains. In particular, the Blockchain can provide: • algorithmic governance autonomously managed by smart contracts capable to implement decentralized decision-making processes providing the highest guarantee of impartiality to all the involved stakeholders; • a transparent and immutable bidding process to select the service providers (i.e. Agents); • a minimization of the information coordination costs on a shared infrastructure, making the organization’s data accessible to new customers and suppliers; • a reduction of verification costs, namely costs involved in verifying the transactions between Principal and Agent. • a reduction of intermediation costs, i.e. the costs due to the certification activities by a third party, external to the contractors.
The architecture of the on-chain GMS modeled as P/A relationship is represented in Figure 2.
Here we assume that both the Principal and the Agent are entities on-chain identified by an
address. Note that we currently assume the pseudoanonymity suficient to carry on the economic
transaction behind the GMS contract, however, while this is technically more convenient, we
have not yet properly investigated all the complexity of managing identity on-chain [
In the following, we will use Solidity code sketches to illustrate the structure and main
components of the necessary smart contracts. Smart contracts of the following examples refer
to the hospital heating use-case described in Section 3.2. The GMS contract is translated into a
smart contract (see Listing 1). The function payAgent, at Line 23, performs the payment if the
KPI are satisfied. In this case, this occurs when the level of CO emission measured by a sensor
is below a given threshold (see line 27). To access the data of the IoT sensors [
In some cases, primary service providers can take advantage of sub furniture provided by secondary service providers. Also in this case, a smart contract can be employed to manage this relationship as a P/A one as shown in Listing 3.
In this section, we show how the components of Figure 2 can be mapped to a real tender
specifications document [
Art. 6 of [
Combustion control according to Legislative Decree 152/06
The sheet mandates that every year, the combustion of thermo-mechanical systems must be
checked according to the D.L.gs 152/06 [
Principal and Agent The Principal is the hospital company. The Agent is the primary
service provider taking care of the maintenance of the hospital facilities as foreseen in the GMS
according to the specification provided [
• The atmospheric emissions of civil thermal plants with nominal thermal power above the threshold value must comply with the limit values set out in part III of Annex IX to part ifve of D.Lgs 152/06 (see Table 2). • The emission values of the plants must be checked at least annually by the person in charge of the operation and maintenance of the plant during normal inspection and maintenance operations. The measured values, with the indication of the relative dates, of the measurement methods used and of the person who carried out the measurement, must be attached to the plant logbook. • For the purposes of sampling, analysis and assessment of emissions from thermal plants referred to in paragraph 1, the methods provided for in part III of Annex IX (see Table 2) are applied.
• The installer verifies compliance with the emission limit values.
Total dust Total organic carbon (TOC)
Installed Electrical Rated Output (MW)
[
> 20 30/ 20/ 10/
According to the GMS, the smart contract will (a) verify the satisfaction of the requirements
for the emissions according to the measured KPIs and the limit defined in [
KPI and sensors The KPI to measure the satisfaction of the contract terms is clearly defined in Table 2. As an example, if we consider the Total Suspended Particles and a heating system with nominal installed power between 3 and 6 MW, the threshold is 30mg/Nm3.
The measurements of the satisfaction of the KPI are provided by the sensors of Table 2, namely Total Suspended Particles, Total Organic Carbon, Carbon Monoxide, Nitrogen Oxides, Sulfur Oxides. Sensors should sample the environment with accuracy and a sampling period defined by the regulation. Smart Contract examples. Listing 1 illustrates how Principal and Agent can manage their collaboration with a smart contract. “PayCOContract" accesses external data through the contract oracle in Listing 2. Finally, “Subcontract" in Listing 3, demonstrates how a primary service provider can delegate a secondary service provider on a blockchain through a specific smart contract.
ExampleContract_CO_ORACLE private OracleContract; address public P; address public A; uint public CO_Threshold; uint public lastPayment; uint public payment; uint public INTERVAL = 10; Listing 1: A sketch of a smart contract to execute the payment from the Principal to Agent if specific conditions are met. For the sake of brevity “stringToUint" function is omitted but it casts a string into an unsigned integer in Solidity. 1 pragma solidity ^0.4.22; 2 import "github.com/provable-things/ethereum-api/provableAPI_0.4.25.sol"; 3 4 contract ExampleContract_CO_ORACLE is usingProvable { 5 6 string public CO; 7 event LogConstructorInitiated(string nextStep); 8 event LogCOUpdated(string CO); 9 event LogNewProvableQuery(string description); 10 11 12 function ExampleContract() payable {
LogConstructorInitiated("Constructor was initiated. Call ’updateCO()’ to send the
Provable Query."); function __callback(bytes32 myid, string result) { if (msg.sender != provable_cbAddress()) revert(); CO = result;
LogCOUpdated(result); function updateCO() payable { if (provable_getPrice("URL") > this.balance) {
LogNewProvableQuery("Provable query was NOT sent, please add some ETH to cover for the query fee"); } else {
LogNewProvableQuery("Provable query was sent, standing by for the answer.."); provable_query("URL", "json(https://api.sensor.it).CO"); Listing 2: A sketch of a smart contract to get data from a CO sensor by Provable Things Oracles.
Provable Things provide oracles for a number of Blockchain Technologies, including Ethereum, EOS, R3 Corda and Hyperledger Fabric 1 pragma solidity ^0.4.22; 2 import "./PayCOContract.sol"; 3 4 contract Subcontractor is PayCOContract { 5 address public Secondary; 6 uint public SecondaryPayment; 7 8 constructor (address _OracleContract, address _P, address _A, uint _CO, uint _payment, address _S, uint _secondary_payment) PayCOContract(_OracleContract, _P, _A,_CO, _payment) { Secondary = _S;
SecondaryPayment = _secondary_payment; function paySecondary() public { require(block.number > lastPayment + INTERVAL); require(msg.value == SecondaryPayment); require(msg.sender == A); if (stringToUint(this.OracleContract.CO) < CO_Threshold) revert();
Listing 3: A sketch of a smart contract to execute the payment from the Primary Service (A) to Secondary Service provider if specific conditions are met. Note that, since this is a special case of contract where the agent delegates to another entity the management of some facility, Subcontract inherits the main contract “PayCOContract"
In this paper, we discuss the design of a blockchain solution capable to support the Global Maintenance Service on-chain, the implementation of the Principal/Agent relationship and how modeling of the GMS on-chain provides several advantages. The transparency of Blockchain can eliminate the asymmetry of information and consequently, it reduces (or even eliminate) the P/A problem and allows a transparent and immutable bidding process for the selection of Agents. The algorithmic governance autonomously managed by smart contracts is capable to implement decentralized decision-making processes providing the highest guarantee of impartiality to all the involved stakeholders and the shared blockchain infrastructure allows us to minimize the information coordination, verification and intermediation costs.
All these arguments encourage us to proceed in this investigation, however, a number of relevant questions still need to be properly handled.
The selection of the most suitable blockchain technology is the first relevant issue. Public/permissionless blockchains provide the highest guarantees but could be dificult to be implemented in an industrial context where some information is necessarily sensitive and private. However, the natural diferent interests of Principal and Agents, at least economically-wise, as well as the participation of diferent providers competing in the market, are guarantees to the achievement of a real consensus among the parties, even in less open infrastructure such as the permissioned blockchains.
The employment of the blockchain, allows us to envision new models of governance, where
trust to individuals is overcome by consensus from a community. However, it is not yet clear
what are the implications in legal terms of this new governance in particular in terms of
accountability. More in general, the applicability of the algorithmic governance provided by the
blockchain should be better investigated in view of current laws, norms and regulations [
Finally, the concept of identity on-chain should be better explored, also in view of the
Self-Sovereign Identity [