Integrating Blockchain in Safety-Critical Systems: An Application to the Nuclear Industry

Safety-Critical Systems (SCSs) often manage sensible data that must be trustworthy, especially in many cases in which different actors participate whose interests may not coincide. Blockchain is a disruptive technology that has emerged to ensure the trustfulness of data. The nuclear industry incorporates many SCSs where blockchain can be applied. This paper focuses on the use of blockchain for the inspection of steam generators of a nuclear power plant. This is a critical process where different actors participate: plant property, external companies in charge of the inspection itself and different administrations. It typically consists of a number of processes that explore the state of different components of the plant in order to find any kind of failure or defect and it generates a great amount of data that must be verifiable and trustworthy. A distributed blockchain-based system is presented where all the nodes share the information and it cannot be altered. As a novelty, automatic inspection algorithms are stored in the blockchain itself by means of smart contracts. The benefits of blockchain are studied for the nuclear industry in general and for the inspection process in particular. In order to explore the possible drawbacks of a blockchain-based system for data management, a simulator has been implemented to recreate the scenario of an inspection. The results obtained show that blockchain architectures are a good alternative to traditional information repositories for nuclear power plant inspections.


I. INTRODUCTION
Safety-Critical Systems are those systems whose failure could result in loss of lives and significant property or in environment damage [1]. One important sector with many critical activities is the generation of power in a nuclear power plant (NPP). Nowadays, nuclear power provides about 11 percent of the world's electricity.
As any other safety-critical facility, they must be inspected to explore the state of the different parts of the plant in order to find any kind of defect and for maintenance activities. Obviously, in the case of a NPP, the inspection is a critical process that requires highly specialized staff and equipment. There are two types of inspections, the so-called The associate editor coordinating the review of this manuscript and approving it for publication was Eklas Hossain .
Pre-Service Inspections (PSIs) and the periodical inspections that are generally performed during fuel recharge (also called In-Service Inspection or ISI). Although the scope of an inspection includes all the areas of a nuclear power plant (reactor vessels, pipes and turbines), this paper concerns automated eddy current inspections of steam generators and heat exchanger tubes [2], [3]. The steam generator (SG) is one of the most critical components of a Pressurized Water type nuclear power plant; its function is to transfer the heat from the reactor cooling system to the secondary side of the tubes which contain feed water. As the feed water passes through the tube, it picks up heat and eventually gets converted to steam. Typically, Pressurized Water Reactors (PWRs) consist of three or four steam generators each one containing up to 15,000 tubes which are reviewed periodically to avoid leaks. SG tubes are inspected by means of Non Destructive Testing (NDT) technique that consists of the detection, characterization and measurement of loss of tube wall thickness, VOLUME 8, 2020 This work is licensed under a Creative Commons Attribution 4.0 License. For more information, see https://creativecommons.org/licenses/by/4.0/ erosion, cracking, etc, with a view to increasing the safety and availability of the component. This check is performed using multi-frequency, digital, robot-operated, remote-controlled equipment. In order to reduce the time the plant is idle, the inspection is carried out in turns by acquisition operators/analyst teams during the 24 hours of the day until the inspection is finished [4]. A huge amount of sensitive data is generated during the inspection. It must be noted that different actors take part in this process and accountability and trustfulness of the information is of paramount importance, as it may become one of the main evidences in accident analysis. The immutability of the inspection results is especially relevant because it gives confidence to the different stakeholders of the process, that include owners, the companies in charge of the inspections, institutions and even residents of the surroundings of the NPP. On the other hand, the guarantee that the results of the inspections cannot be tampered by any of the actors participating in the process provides another degree of confidence in the procedure. It must be highlighted that the integrity and veracity of tamper-proof data are even more important in nuclear industry than in other SCSs since the consequences of an accident can lead to enormous disasters that cost billions USD and cause the loss of hundreds of human lives [5]. In [6] the authors claim that a fully transparent source of reliable data on nuclear accidents is needed that enables planners, investors, and even nuclear regulators to better comprehend, and then weigh, nuclear risks. Having access to historical, immutable and tamper-proof inspection information can also be another source of confidence in the nuclear industry.
In this sense, blockchain is presented as a technology that can help to achieve these goals. This work proposes the use of blockchain as a tool to foster trust in the information exchanged between the actors involved in the inspection. A blockchain is a distributed ledger consisting of a chronological chain of records in the form of encrypted blocks made up of all the transactions executed by the participants. In the blockchain, systems can directly communicate with one another: each system can use a pair of private/public keys to be identified and the communication between the systems is secure because each communication is signed by the private key of the sender [7].
The main contributions of this paper are: • A novel method to store automatic analysis algorithms in a smart contract.
• An analysis of the suitability of blockchain to meet the rigorous requirements of nuclear industry.
• A new platform based on Hyperledger framework [8] to store and retrieve the information of a SG inspection process in NPPs.
• A study of performance and scalability of the proposed platform. The rest of the paper is organized as follows: Those readers familiar with blockchain may wish to skip Section II which overviews the application of distributed ledger technologies. The suitability of blockchain for the nuclear industry is studied in Section III. The particular problem context, i.e. SG inspection, is sketched in Section IV. The proposed blockchain-based architecture is described in Section V. Section VI lays out the simulation and discusses the results. Lastly, our conclusions and future work are presented in Section VII.

II. BLOCKCHAIN BACKGROUND
In order to trust in applications which deal with sensitive information new automatic audit mechanisms are necessary. Blockchain technologies are an interesting approach which can be applied to different contexts from economic applications to NPP inspections.
Blockchain is the mechanism that allows transactions to be verified by a group of unreliable actors [7]. The blockchain protocol [9] structures information in a chain of blocks, where each block stores a hash of the previous block, a timestamp and data.
The way to ensure information integrity in the blockchain is by using consensus mechanisms [10]- [12]. The final goal is to achieve consensus in a distributed network without central authorities and with participants who do not necessarily trust each other.
The use of smart contracts is one of the interesting proposals of the blockchain technology which fits the application area of this paper, where automatic inspection needs to be applied. A smart contract refers to the computer protocols or programs that allow a contract to be automatically executed/enforced, taking into account a set of predefined conditions.
For example, smart contracts define the application logic that will be executed whenever a transaction takes place. Ethereum [13] was one of the pioneer blockchains to include smart contracts. Smart contracts have been included in the majority of existing blockchain implementations, such as Hyperledger [8], an umbrella project of open source blockchains and related tools, started in December 2015 by the Linux Foundation [14], which has received contributions from IBM, Intel and SAP Ariba, to support the collaborative development of blockchain-based distributed ledgers [15].
In this paper we use Hyperledger Fabric. It provides a distributed and scalable ledger focused on enterprise environments. To provide blockchain networks with privacy control, Hyperledger Fabric provides an identity control service and access control lists through private channels where users can control and restrict the access to their shared information in the network. Thanks to this mechanism, members of the network know each other through their public identities, but they do not have to know the information that it is shared in the network.
With the aim of improving the business processes, there exist many different application fields for the blockchain, ranging from financial services [16] applied to banking systems or on-line platforms to government [17], healthcare [18] or industry. The concept of Industry 4.0 is behind modern factories for integrating the latest technologies in their processes [19]. The blockchain will facilitate its development by addressing application decentralization, improving the security of software/firmware and assuring the data authenticity and algorithms. As described in [20], blockchain in industry provides the identification of assets and owners, secure asset transference and transparency. In [21] ARC examined 24 blockchain pilots applied to the industry and identified the business improvements described in Table 1. Other state-ofthe-art papers which deal with industrial blockchain are [22], [23] and [24].
The authors in [25] propose an evaluation framework that comprises a list of criteria and a typical process for practitioners to assess the suitability of applying blockchain using those criteria based on the characteristics of the use cases. The benefits and challenges that arise when using blockchain and smart contracts to develop Industry 4.0 applications are analyzed in [19].
Our proposal will allow a new business line to be opened related to the integration of blockchain in the NPP inspection processes. The following section outlines the use of blockchain in the nuclear sector.

III. APPLYING BLOCKCHAIN IN THE NUCLEAR INDUSTRY
With the widespread concern over global warming, nuclear power was proposed as a clean alternative to other sources of energy [26]. However, the Fukushima Daiichi accident renewed fears and voices against this industry. In order to provide a new source of confidence, blockchain technology is proposed to convince regulators or local residents that the actual state of the plant cannot be tampered with. In [27] a tamper-free plant operation system by applying blockchain to the integrated plant management system of Korea Hydro and Nuclear Power (KHNP) is described. The authors highlight that this work contributes to improving public acceptance by eliminating distrust of safe operation of nuclear power plants.
When applied to the energy sector in general, blockchain has the potential to reduce business complexity and improve profitability. It has immediate application in energy asset management and energy trading. In particular, when applied to the nuclear power sector, it can increase supply chain transparency, effectively monitor and track the life cycle of assets, enhance site security and improve regulatory oversight. In [28] the authors envisaged several key applications of blockchain for the civil nuclear sector: • Uranium fuel supply chain. Different parties from different countries are involved in this activity from the extraction of the mineral to the plant operation. Blockchain can help to carry out a strict tracking to meet international regulations and there is also a feasible possibility to increase uranium control using blockchain, which is of paramount importance for nuclear nonproliferation. In Russia [29], the application to fresh and spent nuclear fuel handling and storage is proposed to create control and monitoring measures using blockchain.
• Inventory of parts and materials used in construction, operation and post-operation. By securely tracking ownership, custody and location of components and materials, blockchain technology could ensure effective management of these materials, monitoring their movement and helping to reduce the risk of delay.
• Assurance of the consistence of software and physical reality. NPP simulators are a key element in a plant's life cycle since the staff in charge of the operation must be trained in all kinds of circumstances. Tracking discrepancies between models and reality can be implemented by means of blockchain-based applications, since any change in plants or in the models that simulate them must be tracked and reported to the corresponding institution.
• Facility event recorder. In this sense, blockchain can work as a tamper-proof record of events, enabling guarantees to be provided to regulators, insurers, and business partners. The events that can be recorded are several fold, from facility access to the registry of incidents with different degrees of severity.
• Effective and efficient interface with regulators. It is important that the government entities responsible for the proper functioning of the infrastructure have easy and secure access. Blockchain provides the necessary mechanisms to assure confidentiality and trustfulness. In addition, we have identified three other applications where blockchain could be used in the near future to take advantage of all the benefits of this technology: • Decommissioning. When a plant comes to the end of its operational life, the process of dismantling is undertaken until such a point that it no longer requires measures for radiation protection. The presence of radioactive material necessitates processes that are expensive and pose environmental risks which must be addressed to ensure radioactive materials are either transported or stored on-site in a safe manner. Blockchain can be used to track the components, movement and final destination, including control and monitoring by government entities.
• Waste Treatment. Radioactive waste is hazardous to most forms of life and is regulated by government agencies in order to protect human health and the environment [30]. Waste is classified according to radioactivity levels and treated differently depending on this classification. It can vary from geological disposal to complex reprocessing that allows for a significant amount of plutonium to be recovered from used fuel, which is then VOLUME 8, 2020 mixed to make fresh fuel. Blockchain can be used to ensure reliable monitoring and regulation compliance.
• Inspection. This paper is mainly focused on tube inspection of SGs. However, many other parts of the plant must also be inspected periodically. According to the characteristics of those parts, the corresponding processes can be studied and implemented using blockchain to guarantee their traceability. Table 2 analyzes when it is appropriate to use blockchain in the civil nuclear sector. Each row refers to a factor where blockchain can contribute. Columns contain different processes of this industry. The cells of the table are labeled 1, 2 or 3 depending on the suitability of the factor to the process (1-low, 2-medium, 3-high).
Although the analysis of all the possible applications of blockchain in the nuclear sector is beyond the scope of this paper, some of them are sketched in [28]. This paper focuses on SG inspection, so the suitability of blockchain in terms of Table 2 is outlined below: • Information shared among different actors: As stated above, some entities usually collaborate to carry out the inspection, but the number is not very high. In general, the organizations involved are the owner of the plant, the different companies in charge of the inspection itself and the Nuclear Regulatory Body. Moreover, taking into account decentralization, server failure is still a possibility in a typical client-server scheme. Although this is now less likely, it is worth mentioning that one day of station shutdown can represent $1,000,000 in lost revenue. Thus, shorter inspections and the prevention of unplanned shutdowns can help the stations to save millions of dollars. Blockchain solves server failures due to its decentralized architecture.
• Digital records of physical assets: The result of the inspection, i.e. the state of each tube, must be strictly recorded and the information should be tamper-proof. Blockchain offers perfect mechanisms for data storage and trust.
• Strict inventories: Regulators require strict inventories of parts and materials used in the construction, operation and post-operation of a nuclear power facility. By securely tracking ownership, custody and location of components and materials, a further application of blockchain technology could ensure effective management of these materials even after the decommissioning of nuclear facilities [28]. Although physical tubes of an SG are usually recorded, we think that this is not a key concept in inspection because the tubes are installed together with the SG and this occurs very occasionally in an NPP's life cycle. Only probes and other equipment used should be recorded in the blockchain for each inspection.
• Data tampering affects other entities: In case a company alters the result of an inspection, the consequences can be extremely dangerous. A tube where a crack has been detected must be plugged because it can produce a leak of contaminated water. Tube plugging decreases the efficiency of the power plant (less heat is transferred from the SG to the turbines), but it prevents accidents. In these circumstances, the history of the inspection of the tube is needed and responsibilities can be identified using blockchain data.
• Governments or administrations need mechanisms to trust the truthfulness of the data: Obviously, administrations must be aware of the actual state of the NPP and blockchain can be a good mechanism to provide and share this information with the corresponding institution. Reporting and compliance applications can be a continuous consensus process through permission-less or public permissioned blockchains instead of a timediscrete (e.g., annual) report. It could increase the confidence in the regulatory and the nuclear sector [31].
• Secure tracking: In case of an incident it is necessary to know not only the last inspection but also the complete history of the tube state in order to find out the cause and be able to predict similar behaviours in the future.
• Algorithms tracking: Since some analyses can be performed automatically, it is necessary to know precisely the algorithm that has carried out the analysis. Smart contracts can be a good mechanism to store and execute the program. If needed, the institutions can require the code from the blockchain. Obviously, the algorithms can be modified creating different versions, but the exact version used must be recorded together with the corresponding indications generated by it.
• Domestic or international regulations involved: Different regulations and laws apply to the inspection of NPP. In order to meet these regulations, they can be implemented in the blockchain and then, depending on the country where the inspection is to take place, assure the compliance of the regulations by means of smart contracts. As described in the introduction, SG tube inspections are important stages of the life cycle of the facilities. Hardware technology is well established as described in [2] and [3] but, as explained above, blockchain can be applied to simplify and improve the inspection process by assuring the inspection confidence and reducing the time needed to carry it out.
Next section details the problem context of SG inspection.

IV. PROBLEM CONTEXT: STEAM GENERATOR TUBE INSPECTION
The inspection process comprises a multi-layer system, which provides an in-depth safety scheme that ensures high detection rate and reporting accuracy. Up to fifty clients (operators and analysts) share their information using a central database server where the inspection plan data have been previously published. Fig. 1 shows the main tasks carried out and the principal actors: • Setup: The process of planning and defining the scope of an SG inspection needs to take into account different requirements, which are normally defined in governing documents issued by regulators such as Nuclear Energy Institutes. The planning process also considers other factors such as the degradation history of the component and operational experience of similar plants. The output of this phase is the set of tubes to be inspected. In a PSI all the tubes must be selected although in an ISI only some of them are inspected.
• Acquisition: These activities are carried out in areas with high levels of radiation with difficult access. The information obtained is this phase is called raw data (Acq Raw Files) and is grouped in the so-called calibrations. In this context, this term refers to the set of tubes acquired between two equipment calibrations.
• Analysis: The raw data must be studied by qualified staff using specific applications in order to detect anomalies. Due to the critical importance of the inspection, each acquired tube must be analyzed by several analysts. Two teams of independent analysts evaluate the data in parallel roles called primary and secondary.
Depending on the legislation of each country, the analysis may be done automatically but, in general, at least one of the analyses must be performed manually.
• Resolution: The analyzed data for each tube in the different roles must be compared in order to detect discrepancies among the analyses. A resolution analyst must hold the highest qualification and be the one who decides on the final report for each tube. Often, the primary and secondary analysts operate in a highly demanding production mode, flagging indications and performing only a preliminary analysis. The resolution analysts perform the detailed analysis, using more complex characterization procedures and comparing the indications to historical data. In order to carry out these activities, the operator/analyst teams use applications that follow a client/server architecture where all information about the inspection is stored in a central server.
The acquisition phase generates a significant amount of data, which is transmitted from the instruments to the acquisition computers via Ethernet connections and stored on highspeed large-capacity storage devices. These data, called Acq Raw Files (Fig. 1), are transmitted using high-speed communication lines to analysis centres that are usually located offsite and can even be in different parts of the continent. This amount of data needs to be managed efficiently and, more importantly, reliably. Data management systems handle the data from thousands of tubes and several SGs. In addition, historical data related to previous inspections are loaded into the database before starting the current one to enable the analysts to use them for comparison purposes.
Often, primary and secondary analyses are carried out by different job contractors located at different sites. The data management systems integrate these locations inside their network sending the data, receiving the reports and frequently operating in parallel with other management systems or protocols. Once the data management systems complete processing the information and all the requirements have been fulfilled, the inspection is officially finished and the equipment can be removed [2]. Fig. 2 shows a simplified Entity Relationship diagram of the data involved in an inspection. The inspection plan or WORK is divided into a set of calibrations. CALIBRATION groups a set of tubes that are actually acquired until the acquisition equipment is calibrated again. The entity TUBE refers to the actual tubes that belong to a SG of the NPP. Once the data of a tube has been acquired (ACQUIRED_TUBE), the information generated by the probe introduced inside the tube is stored in a raw data file. The analysts can then begin their task (ANALYZED_TUBE) in the corresponding role. The inspection result is stored in INDICATION and reveals the state of each tube. Each piece of data stored must contain the person who has generated it, and so, the relation to STAFF entity is mandatory.
In order to reduce costs and analysis time, automatic analysis systems have been developed. They are typically used for one level of analysis, either primary or secondary, but they can be used by both teams, provided each one uses different detection algorithms. Currently, some efforts in the field of machine learning [32] try to take advantage of this technique so as to reduce the pressure that can affect the analysts' performance and reliability.

V. A BLOCKCHAIN-BASED ARCHITECTURE FOR SG TUBE INSPECTION
Section IV described the current approach of the SG inspection process, including the client-server-based architecture. In this section we describe a new architecture based on the use of blockchain for data integrity and trust management. From the inspection requirements we need a framework which meets the following: • A permissioned blockchain. Different stakeholders, with different duties and responsibilities in the inspection work, who must trust each other. In addition, not everyone can be part of the system.
• A federated network. External entities such as Nuclear Power Regulatory Body could validate the transactions to accept the results of the inspections and this could be carried out by means of smart contracts.
• Non-tokenized. This concept is linked to private and permissioned blockchain networks. This type of networks uses consensus algorithms that are different to Proof-of-Work (PoW), the algorithm used by public blockchains. Unlike PoW, algorithms employed in permissioned blockchains do not require a token. So, entities involved in an NPP inspection system do not need a token or cryptocurrency to interact with the blockchain network.
• Smart contracts. It is necessary to include some logic in the transactions thanks to which agreements between the entities involved are registered. In addition, automatic analysis is implemented using a smart contract. This way, every modification in the algorithm is tracked as a transaction. Administrations can obtain the exact version of the code applied in the analysis, which cannot be modified later to elude responsibilities. The proposed blockchain-based architecture fulfills those requirements thanks to the use of Hyperledger Fabric framework. Fabric allows the generation, deployment and management of new permissioned blockchain networks.
Unlike public blockchains like Bitcoin or Ethereum, this framework does not include the terms of token or cryptocurrency. Smart contracts are defined with Fabric's related tool: Hyperledger Composer. Composer eases the interaction with Fabric, helping users to generate, deploy and manage their own blockchain networks.

A. HYPERLEDGER FABRIC
This section describes two main concepts used in the proposed architecture. Subsection V-A1 explains how users can authenticate themselves in the deployed blockchain network and how they can sign transactions with their credentials, while subsection V-A2 shows how smart contracts work in the Hyperledger Composer environment.

1) AUTHENTICATION AND TRANSACTION SIGNATURE
As stated above, the Hyperledger Composer tool has been used to interact with the generated blockchain network. Inside Composer project there are some utilities (all of them Node.js modules), but the only one that is pertinent here is a REST server called composer-rest-server. This server acts as the intermediary between users of the inspection process and the blockchain deployed. By default, the server only needs an identity to be launched, but this approach has no user authentication and it signs all transactions executed by the participants with that identity. To guarantee that users have to authenticate themselves in the server and to ensure that they sign transactions with their own identities, it is required to enable authentication and multiple user mode in the server.
On the one hand, authentication in the Composer REST Server is carried out by the open source Passport authentication middleware. On the other hand, multiple user mode needs an identity repository in which to store user identities. This repository is also called wallet storage and it can be implemented in a NoSQL document-based database, such as MongoDB or CouchDB.
Once authentication and multiple user mode have been enabled, users of the inspection system can authenticate themselves in the server and sign transactions. The data flow of authentication and transaction signature is shown in Fig. 3. The sequence of steps is explained as follows: 1) This data flow begins with the user accessing the URL of the Composer REST server. 2) The server redirects login to Passport authentication middleware. 3) Passport.js returns authentication result to REST server. 4) If authentication has been successful, the server sends an API Token to the user. 5) Now, this user can send a request (retrieve data or execute a transaction) with this API token. 6) The server searches the user's identity in the wallet storage. 7) Wallet storage returns the identity to the server. 8) With this identity, the server executes the request in Fabric network.

2) SMART CONTRACTS
In Hyperledger Fabric, the widely-used term smart contract is referred to as 'chaincode', i.e. self-executing logic that encodes the rules for a specific blockchain network. Chaincode runs network transactions, which, if validated, are appended to the shared ledger and modify the so called world state (the current state of the ledger). The creation of smart contracts is much simpler using the tool Hyperledger Composer. In its environment, there exists a key concept called Business Network Definition which comprises a set of model files, a set of JavaScript files, and an access control file (optionally also a query file). The model files define the domain for a business network, in this case, the nuclear inspection process. JavaScript files contain transaction processor functions. These functions run on a Hyperledger Fabric network and have access to the world state of the ledger.
The access control file contains a set of rules that define the rights of the different participants in the network.
We have already mentioned and briefly explained each kind of file composing a Business Network Definition, but we must focus on the model file. This type of file is the most important because it is here where the developer is shaping his/her system. A model file is coded using the Hyperledger Composer Modeling Language which is an object-oriented modeling language. Inside this type of file, developers can define network resources such as participants, assets, transactions or events. Each resource is explained below: • Participants. A participant is an actor in a business network who can create assets and exchange them with other participants. This actor works with assets by submitting transactions. In order to grant the participant access to interact with the business network, an identity (tuple of digital certificate and private key) must be issued to that participant. Participants must have an unique identifier and can have any other properties as required.
• Assets. An asset is a property, good or service stored in the blockchain. Assets, like participants, must have a unique identifier, can contain properties and may be related to other assets or participants.
• Transactions. Transactions are the mechanism by which participants interact with assets. They are defined in the model file but coded in a JavaScript file.
• Events. Events can be defined in the same way as other types of network resources. Once events have been defined, they can be emitted by transaction processor functions to indicate that something important has happened to the ledger. External systems can subscribe to emitted events. Fig. 4 shows the diagram of the blockchain architecture implemented. In this proposal, each organization involved in the NPP SG inspection process has two Hyperledger Fabric elements: a Certificate Authority and a peer node. The former signs certificates for all existing peer nodes within an organization while the latter maintains a copy of the data existing in the blockchain (stored in a NoSQL database like CouchDB). A key element also exists in the Fabric blockchain network, namely the Orderer Node, in charge of keeping the state of all existing peer nodes consistent. All these types of elements (CA, peer node, CouchDB and Orderer Node) are Docker containers [33] running in different machines. The Docker images of these Fabric elements are provided by the Hyperledger Fabric development team. In order to encode the NPP inspection process, we have modeled this procedure as an Hyperledger Composer Business Network Definition. As explained in Section V-A1, the most important file of the defined domain is the model file. Fig. 5 shows the relationship between the different types of participants (staff) and the types of assets (tube, work, calibration, acquisition and analysis) established to implement our study case. This class diagram also displays the enumerated types defined (state, role and method).

B. ARCHITECTURE DESCRIPTION
Depending on their role, a staff member can execute some transactions or others. Different roles are acquisitor, administrator, advanced analyst, analyst and automatic analyst. The asset types defined in the model are as follows: • Tube. This asset describes the properties of one steam generator tube: its position and length.
• Acquisition. It stores the acquisition date, the filename of the raw data obtained and the hash value (SHA-256) of the file with the data. Due to the size of a raw data file (up to 1 Megabyte), acquired raw data are not stored in the blockchain itself but in a file repository (off-chain data storage). For this reason, an acquisition asset has the properties filename and hash value. A resource of this type also keeps relationships with the staff member who acquired the data, the tube acquired and the calibration to which it belongs.
• Analysis. An analysis is described by the date and method of analysis and by a list of indications. If the list is not empty, these indications points out some tube defects. In addition, an analysis asset is related to an acquisition and the staff member who carried out the analysis.
• Calibration. A set of acquired tubes, called acquisition in this business network definition. This kind of resource is defined by a start date, the equipment used to acquire tube data and the state of primary, secondary and advanced analysis. A calibration asset is also related to the work to which it belongs and to the three staff members who analyze it (two analysts and one advanced analyst for resolution).
• Work. A work asset has three attributes: a start date, the state of the work (planned, in progress or finished) and a description. Up to six use cases have been defined and each of them can only be carried out by a specific type of participant. These use cases correspond to the main tasks described in section IV and are explained below: • Tubes register. This use case is executed only once per SG and before starting any inspection. All tubes are registered.
• Work preparation. Before starting the SG inspection process, the admin creates a new work resource with the subset of tubes to be inspected. These tubes are grouped in calibrations. When the work asset is created, the acquisitors can begin their job.
• Tube data acquisition. Participants with role 'Acquisitor' must get information about a group of SG tubes (calibration). The information obtained per tube generates a raw data file and this file is stored in a repository.
• Tube data analysis. Analysts and automatic analysts retrieve those raw data files, then check the content of the files and, finally, write a report with the indications found, which are stored on the distributed ledger.
• Resolution. Participants with role 'Advanced Analyst' must recover all the analyses written about one single raw data file and compare the differences (if any) between them. Advanced analysts are responsible for resolving those differences and indicating which is the correct analysis.
• Final Report Access. Authorized staff can retrieve all the information about the work (acquisitions, analyses and resolutions) and verify it is correct. Fig. 6 summarizes the use cases given and which participants carry them out, whereas Table 3 shows which blockchain transactions coded on the smart contract implement each use case. Transaction functional behaviour is explained below: • RegisterTube. It registers a new SG tube in the system. • CreateWork. It allows a new NPP inspection work plan to be created.
• CloseWork. To close a SG inspection work plan, all the calibrations related with this work must be finished.
• AddCalibration. It adds a new calibration to an existing and unfinished work plan.
• GetCalibration. The participant addresses the set of acquired tubes for primary, secondary or resolution analysis.
• EndCalibration. This transaction sets the status of primary, secondary or resolution analysis to finished.
• AddAcquisition. This adds a new acquisition asset to the distributed ledger. This transaction also emits the event Acquisition Added. Subscribers to the event will receive the unique identifier of the newly create Acquisition asset, in addition to the raw data filename and the hash value of this acquired data file.
• AddAnalysis. The participant creates an asset of type analysis. This transaction can only be executed once per analyst and acquisition. VOLUME 8, 2020 FIGURE 5. UML class diagram that describes the relationships between participants and assets defined in our business network. • AddAutomaticAnalysis. It is similar to AddAnalysis but here analysis indications are generated automatically by the transaction processor function.

VI. PROCESS SIMULATION AND RESULTS
In order to quantitatively assess the good performance of the blockchain-based application, a simulation has been implemented to measure the execution times of the main transactions needed. The structure of the information used in the simulation is the same as that used in a real inspection. Since the values do not affect performance, they have been generated randomly. Some parameters have been fixed according to the experience of qualified staff whereas. For those parameters that can vary from one inspection to another and can affect performance, several tests have been performed with appropriate different values. Subsection VI-E shows the parameters employed and the data obtained.
To define the blockchain network used in the simulation, it is also necessary to define an endorsement policy. Endorsement policies define which peer nodes need to agree with the results of a transaction before it can be added to the ledger. Fabric includes a small domain-specific language for specifying endorsement policies. The endorsement process works as follows: • One node creates a transaction proposal and sends it to some other peer nodes for endorsement.
• Those nodes locally execute the chaincode, sign the transaction and return it to the proposer.
• The creator of the proposal submits the transaction to be added to the ledger once it has received enough signatures to satisfy the endorsement policy. The policies that we have defined for each network are the same: at least one peer node of each participant orga-nization must endorse all received transaction proposals. In this way, all organizations have to agree to accept a new transaction.
We have simulated the execution of the three main transactions of the deployed Business Network: AddAcquisition, AddAnalysis and AddAutomaticAnalysis. We consider these transactions the most important because they implement the main tasks of the inspection process already discussed in Section IV: acquisition, analysis and resolution. The simulations for each task are detailed in the subsections below.

A. ACQUISITION PROCESS SIMULATION
For this first task of the inspection process, we have coded a simulation like the one shown in Algorithm 1. Each acquisitor has to get data from numacqs tubes. For each tube a file is generated, and the hash value (SHA-256) of this file is calculated. Then, transaction AddAcquisition is executed. Finally, the file so generated is uploaded to a repository and deleted from the local machine.

Algorithm 1 Acquisition Process Pseudocode
Input: numacqs number of acquisitions this acquisitor must do 1: function ADDMULTIPLEACQUISITIONS(numacqs) 2: for i ← 1 to numacqs do 3: filename ← generateFilename(i) 4: file ← generateFile(filename) 5: hash_value ← calculateHashSHA256(file) 6: addAcquisition(i, filename, hash_value) Blockchain transaction 7: uploadFileToRepository(file) 8: deleteLocalFile(file) 9: end for 10: end function During the execution of the acquisition, another process is also running and listening events emitted by AddAcquisition transaction. The event AcquisitionAdded provides information about the new acquisition stored in the distributed ledger. With the information emitted, this second process downloads a copy of the file from the repository, checks its validity, gets the file content and executes the transaction AddAutomatic-Analysis. After this, the local copy is deleted. Algorithm 2 summarizes the steps carried out by the event listener process.
Both processes perform different tasks, but we only wish to measure the average elapsed time when blockchain transactions AddAcquisition and AddAutomaticAnalysis are called and the total elapsed time during processes execution. On the one hand, the acquisition process calls AddAcquisition transaction and a timer is placed to measure the elapsed time between file uploading and hash calculation. On the other hand, the automatic analysis process executes AddAutomat-icAnalysis after the acquisition data retrieval and before the local copy deletion, where another timer is set. while true do 3: if new_event then 4: acqId, filename, hash ← getEventData() 5: file ← downloadFileFromRepo(filename) 6: file_valid ← checkHash(file, hash) 7: if file_valid then 8: acqData ← getFileContent(file) 9: addAutoAnalysis(acqId, acqData) Blockchain transaction 10: deleteLocalFile(file) 11: end if 12: end if 13: end while 14: end function

B. ANALYSIS PROCESS SIMULATION
The second main step of the SG inspection process is the analysis of previously acquired tube data. In the simulation, we have tested the blockchain network with different numbers of analysts working at the same time.
Algorithm 3 illustrates how we have coded the analysis process. Each analyst must analyze numanalysis acquisitions. First of all, the analysts have to retrieve acquisition information from the blockchain, download a copy of the raw data file and validate this file's hash value. If the check is successful, the process gets the length of the tube, generates some indications and executes the transaction AddAnalysis. Finally, the local copy of the raw data file is deleted.

C. RESOLUTION PROCESS SIMULATION
The comparison of the previous analyses and the detection of discrepancies among them is the last main step of VOLUME 8, 2020 the nuclear inspection process. The implementation of this procedure is shown in Algorithm 4. Each advanced analyst must perform numres resolutions. In the same way, as in the analysis process, the advanced analysts have to recover acquisition info, download a copy of raw data file and validate its hash value. After this, the advanced analyst's process retrieves the three previous analyses (automatic, primary and secondary). In order to simulate a real scenario, this procedure generates some indications and executes transaction AddAnalysis. Finally, the local copy of the raw data file is deleted.

end function
Here we only want to measure the time elapsed when recovering previous analyses, because the times obtained during the execution of the transaction and the retrieval of the acquisition information are already quantified through the analysis process.

D. DEPLOYMENT
In order to test the proposed architecture and the developed business network definition, we have used two scenarios with different numbers of peer nodes. This way, we can measure whether or not the number of nodes affects performance. The minimum number of organizations participating in the inspection is three, i.e. the owner of the plant, the company in charge of the inspection and the corresponding administration, although others can also participate. So, the first scenario has three organizations with one peer node each, while the second includes five peer nodes, one per organization too. Hereinafter, the first scenario will be abbreviated as 3-PN (three peer nodes) and the second one as 5-PN (five peer nodes). As said at the beginning of this section, there exist some parameters on NPP inspection process can vary from one inspection to another and can affect system performance. Table 4 summarizes all those parameters.  Both blockchain networks have been deployed using the Google Cloud Compute Engine utility. All virtual machines created have the following requirements: • Ubuntu 16.04 LTS as operating system. • 1 virtual CPU, 6.5 GB RAM. If the machine is running the REST server, we recommend to increment to 2 virtual CPUs, 7.5 GB RAM.
• 20 GB HDD. Each virtual machine hosts one single organization software system (peer node + Certification Authority), i.e., these machines simulate the web application servers for each entity. Fig. 7 shows the simulated deployment that we have used to test the 3-PN scenario. Participants of each organization interact with the blockchain network through client apps. Those private apps communicate with the REST server and, finally, servers link with peer nodes.
Additionally, there exists another virtual machine in which Orderer Node is deployed. To authenticate users in the pair of networks, we have chosen Github authentication strategy. To implement the wallet storage we have used MongoDB.
All transactions require validation by endorsing peer nodes (peers that have to validate transaction proposals in order to  add new transactions to the ledger). In both scenarios, the peer node of each organization is also an endorsing node. This is the reason why average response times are slightly higher in 5-PN scenario than in 3-PN: each endorsing peer has to execute the transaction locally and, the greater the number of endorsing peers, the more local executions of transactions are necessary to perform validation.

E. RESULTS
All the figures in this section are composed by two charts: a) and b). Charts labeled a) show results of tests where parameter NTubes changes, while charts b) display results of tests where parameter RSize varies.
Execution times obtained for the acquisition process are shown in Fig. 8. As expected, the raw data file size and the number of organizations do not affect the total elapsed time, but the increase of the number of tubes makes this measure to grow. On the other hand, when executing the blockchain transaction AddAcquisition, the average times are not affected by the number of tubes or the raw data file size.
The whole automatic analysis process and the blockchain transaction AddAutomaticAnalysis are affected by the number of organizations involved, by the number of tubes to analyze and, especially, by the raw data file size. Fig. 9 and 10 show average and total times obtained during this test.
In the case of the analysis process, the number of analysts working at the same time has to be considered. As explained on subsection V-A2, there are two kinds of ordinary analysts:   primary and secondary. In total, this test has been run with 20 and 40 analysts (one half of each type) working at the same time (parameter NAnalysts on Table 4).
The results of this test are shown in Fig. 11 and 12. The chart displayed on Fig. 11a shows that the execution of the blockchain transaction AddAnalysis does not depend on the raw data file size, while Fig. 11b shows that the number of tubes analyzed does not affect the process performance. Likewise, both charts indicate that the number of analysts working at the same time has a small impact on the process throughput (average response times are slightly higher with a greater number of analysts). On the other hand, charts displayed on Fig. 12 show that, as expected, the analysis algorithm performance is affected linearly by the number of tubes and the number of analysts working at the same time, but not by the raw data file size.
The results of the resolution test are highly similar to the analysis test outcome because both processes use the same blockchain transaction, AddAnalysis. The only difference between the resolution and analysis algorithms is that the first one has also to recover information about previous analyses (automatic, primary and secondary), but this operation has no impact on the average response or the total elapsed times.

VII. CONCLUSION AND FUTURE WORK
A study of the suitability of the integration of blockchain in different activities of the civil nuclear industry has been presented. Different processes of this sector have been analyzed to determine when it is appropriate to use blockchain. The importance and the confidence levels of the tasks involved in these processes make them first-class candidates to take advantage of the main benefits of this disruptive technology. In addition, we have proposed a new platform based on Hyperledger framework for tube inspection of nuclear power plants to increase the trust in the processes involved. The use of this well-known framework proves that no specific blockchain implementation is needed to take approach of its benefits. As a novelty, smart contracts are used to implement automatic analysis algorithms that are stored in the blockchain itself and cannot be tampered with. A simulator has been developed and a set of simulations has been carried out to measure the response times of the different stages of the inspection. The results obtained prove that the proposed blockchain-based architecture can meet the most demanding requirements since, as expected, the total elapsed time is decreased in a linear way by the number of analysts and increased also linearly by the number of tubes. Only the automatic analysis process shows a relatively poor performance when the raw data file is large because smart contracts are not designed to manage large amounts of data. The next step is to integrate the proposed architecture into a real scenario. Integrating the blockchain technology in other inspection activities and building a more complete platform is another future line of work.