\chapter{Literature Review and State of the Art}
\label{chap:lit_review}

\section{Introduction}
\label{sec:lit_intro}


In Chapter 1, we introduced the main problem that this thesis will solve. We explained that the railway industry has big challenges with asset management. Their traditional systems often have problems with data integrity, trust, and transparency. We proposed that our new system, which uses blockchain technology, can be a good solution.

Before we can explain our technical contribution (in Chapter 3), we must first do a deep review of the existing academic and technical literature. This chapter is the foundation for our entire research. The main goal is to review all the relevant studies to build a strong base of knowledge. This is a very important step. Without a good literature review, we cannot know if our idea is truly new, or if we are just repeating work that other people have already done.

To build a practical system, our research must understand two main areas at the same time. This is a common challenge when applying a new digital technology (like blockchain) to a traditional industry (like railways) \cite{al-zaga2021systematic}.

\begin{enumerate}
    \item \textbf{The Problem Domain:} We must first be experts in the problem we are trying to solve. This means we must do a deep analysis of the railway industry's current challenges. Why are their traditional asset management systems not good enough? What are the specific limitations and data problems they face every day?
    
    \item \textbf{The Solution Domain:} We must also be experts in the technology we are using as a solution. This means we must explain the fundamentals of blockchain. What is it? How does it work? What is a smart contract and why is it useful for our project?
\end{enumerate}

Only after we understand both the problem and the technology, we can then look at the ``State of the Art``. This is where we will review other academic papers where researchers have already tried to combine these two domains. We will look for other projects that used blockchain for supply chain or asset tracking.

This whole review process allows us to find what is *missing* from the existing research. This is called the ``research gap``. Our thesis is important because our project is designed to fill this gap.

This chapter is organized to build this knowledge step-by-step:
\begin{itemize}
    \item \textbf{Section 2.2} will analyze the challenges of traditional railway asset management and its data systems.
    \item \textbf{Section 2.3} will explain the fundamentals of blockchain, DLT, and smart contracts.
    \item \textbf{Section 2.4} will review the ``State of the Art`` by looking at other academic projects that use blockchain for asset management.
    \item \textbf{Section 2.5} will conclude the chapter by analyzing what we have found and clearly identifying the ``research gap`` that our thesis will fill.
\end{itemize}



\section{Traditional Railway Asset Management: Challenges and Limitations}
\label{sec:lit_traditional_am}


In this section, we will do a deep dive into the ``problem domain`` of our thesis. To justify building a new, complex system using blockchain, we must first prove that the current systems are not good enough. We need to analyze the specific challenges that the railway industry faces in managing its physical assets. This section will show that the problems are not small, but are fundamental issues of safety, cost, and trust.

\subsection{The Importance of Maintenance in Railway Operations}
\label{sec:lit_importance_maintenance}

The railway system is a ``safety-critical`` industry. This term means that the failure of even a small component can lead to catastrophic events, including loss of life and massive environmental damage. Because of this, asset management is not just an accounting problem or a way to save money; it is the most important part of the industry's safety and operational strategy.

In academia and in the industry, this concept is standardized as \textbf{RAMS} (Reliability, Availability, Maintainability, and Safety). This is a engineering framework used to guide the management of railway systems \cite{stanciu2020rams}. All of our work is about improving these four points.

We can break down the importance into three main areas:

\begin{itemize}
    \item \textbf{Safety:} This is the first and most important reason. The safe operation of trains, signals, and tracks depends on every component working perfectly. The failure of a single, small component that is not maintained correctly—like a wheel bearing that overheats, a braking system that loses pressure, or a signal that gives the wrong light—can lead to a derailment or collision. Therefore, having a perfect, auditable, and trustworthy record of every part's history and maintenance is a fundamental safety requirement. We cannot have safety without knowing the state of our assets.
    
    \item \textbf{Service Reliability and Availability:} Railway networks are the backbone of a country's economy, especially here in Europe. They move millions of passengers to their jobs and tons of cargo to factories and ports. The ``product`` that a railway sells is reliable transportation. 
    \begin{itemize}
        \item \textbf{Availability} means the train is ready to use when it is scheduled.
        \item \textbf{Reliability} means the train does not break down during its journey.
    \end{itemize}
    When a train breaks down (a ``service failure``), it causes huge delays. These delays have a big economic cost and make customers and businesses lose trust in the railway. Good asset management and maintenance is the only way to make sure the trains are ``available`` and ``reliable``.
    
    \item \textbf{Regulatory Compliance:} Because it is so important for safety, the railway industry is under very strict rules from governments and international bodies (like the European Union Agency for Railways, ERA). These regulators demand that companies *prove* they are following all safety and maintenance procedures. After any accident, investigators will demand to see the full maintenance history of every part involved. Companies must keep perfect records for auditing. If they fail an audit, or if their records are bad, they can get very large fines or even be shut down.
\end{itemize}

These three factors—safety, reliability, and compliance—are all linked by one single, fundamental need: \textbf{trusted data}. The entire industry runs on data, and if the data is bad, all three of these pillars can fail.

\subsection{Current Asset Management Models}
\label{sec:lit_am_models}

To manage their assets and ensure safety, railway companies have used different maintenance strategies over the years. We can see an evolution in these strategies, from simple to very complex. Each model has a different need for data, and understanding them shows us *why* our system is needed.

\subsubsection{Reactive Maintenance (RM)}
This is the oldest and most basic model. It is often called the \textbf{``run-to-failure``} or ``breakdown`` model. In this system, you do not fix a part until it is broken. A part is installed and then ignored until it fails.

This is a very bad model for a safety-critical industry like the railway. It is extremely dangerous because parts can fail at any time, which could cause an accident. It is also very expensive. An emergency repair for a train that is broken down in the middle of the tracks is much, much more costly than a planned repair in a maintenance yard. This model also causes the worst service reliability, because failures are a surprise. Today, this model is only used for non-critical parts, like a lightbulb in a passenger cabin, but it is not used for any serious equipment.

\subsubsection{Preventive Maintenance (PM)}
This is the most common model used in the railway industry today. It is also called ``prophylactic`` or \textbf{``time-based`` maintenance}.

In this model, parts are replaced on a fixed schedule, no matter what their real condition is. The schedule is based on time (e.g., ``service all wagons every 12 months``) or on usage (e.g., ``replace all brake pads every 50,000 km``).

\begin{itemize}
    \item \textbf{Pros:} This model is much, much safer than Reactive Maintenance. Because parts are replaced *before* they are expected to fail, the risk of a surprise breakdown is very low. It also allows for planning. The company knows in January that it needs to order 500 brake pads for the maintenance scheduled in March. This makes logistics much easier.
    
    \item \textbf{Cons:} This model is very \textbf{inefficient and wasteful}. A company might replace a brake pad that is still 50\% good, just because the schedule said to. This wastes time, money, and valuable parts. This ``over-maintenance`` is a huge part of the railway's operating budget. Furthermore, it does not stop all failures. It is possible for a part to fail *before* its scheduled maintenance, so the risk is not zero.
\end{itemize}
The industry uses this model because it is a safe, simple, and low-data solution. You do not need smart sensors; you only need to track the date or the mileage.

\subsubsection{Predictive Maintenance (PdM)}
This is the modern, data-driven goal that the entire industry is moving towards. This is also called \textbf{``Condition-Based Maintenance`` (CBM)}.

In this model, you do not use a fixed schedule. Instead, you use sensors to monitor the *actual condition* of the part in real-time. For example, you put a vibration sensor on a wheelset or a temperature sensor on a braking system. This data is then fed into a software model (maybe using Artificial Intelligence, AI) to *predict* when the part will *actually* fail. The system can then alert the crew to ``replace the brake pads on Train 102 in the next 5 days, because they are 95\% worn out``.

\begin{itemize}
    \item \textbf{Pros:} This is the best possible model. It is very safe (because you fix parts *before* they break) and it is extremely efficient (because you use 100\% of a part's life and do not waste good parts). This is the main goal of modern railway asset management \cite{deng2023review}.
    
    \item \textbf{Cons:} This model has a very high barrier. It requires a huge amount of high-quality, real-time, and *trusted* data. You must have many sensors, and you must be able to trust the data they are sending.
\end{itemize}

The main argument of this thesis is that the railway industry is ``stuck`` using inefficient Preventive Maintenance because their traditional data systems make it impossible to get the *trusted data* that is needed for Predictive Maintenance.

\subsection{Limitations of Centralized Data Systems}
\label{sec:lit_centralized_limitations}

This section is the core of our problem statement. The reason the industry is stuck in PM is because of its *data infrastructure*. The problem is the traditional, centralized database model (like a private SQL server). This model has three main limitations that make it impossible to build a trusted, industry-wide system.

\subsubsection{Data Silos and Lack of Interoperability}
This is the biggest problem. The railway network is not one single company. It is a large, complex \textbf{ecosystem} of different stakeholders. For example:
\begin{itemize}
    \item The company that builds the train (e.g., Siemens, Alstom).
    \item The company that owns the train (e.g., a leasing company).
    \item The company that operates the train (e.g., Trenitalia).
    \item The many different third-party maintenance crews.
    \item The government regulators.
\end{itemize}

Each of these stakeholders has their own private, centralized database. These databases are \textbf{``data silos``}. They do not talk to each other, they use different data formats, and they are not ``interoperable``.

When a maintenance crew services a wagon, they update *their own* database. The train operator might get a PDF or an email, but their main database is not updated. The train manufacturer never knows how their part is performing in the real world. This means it is impossible to get one single, complete life-cycle history of an asset. This lack of interoperability and data sharing is a well-known, major challenge in the industry \cite{singh2021railway}. You cannot do predictive maintenance if you only have 1/3 of the data.

\subsubsection{Data Integrity and Trust}
This is the *human* problem. Even if the databases *could* be connected, the stakeholders do not trust each other. This is a rational choice, because a centralized database has no guarantee of data integrity.

\begin{itemize}
    \item \textbf{No Guarantee of Integrity:} A record in a private SQL database can be changed. An administrator can edit a row. A ``bad actor`` could go into the database and change a maintenance date to pass an audit. A simple employee can make a mistake and type the wrong part number, and this error might be saved forever. There is no way to *prove* that the data in the database is the original, correct, and 'immutable' record.
    
    \item \textbf{Lack of Trust:} Because the integrity cannot be guaranteed, there is no trust. An operator cannot 100\% trust a PDF report from a maintenance crew. They must spend time and money on their own *audits* to verify the work. This lack of trust is a major barrier to data sharing. Companies will not share their data if they cannot trust the other company's data. This problem of creating trust between partners is a huge topic in all supply chains, and it is a key reason why researchers are interested in blockchain \cite{kshetri2021blockchain}.
    
    \item \textbf{Difficult to Audit:} It is very difficult for a government regulator to audit the system. They have to ask many different companies for their private records (which might be in different formats) and they have no way to prove that the records are the original data and were not changed last week just for the audit.
\end{itemize}

\subsubsection{Inefficiency and Paper-Based Processes}
Finally, the current system is very inefficient because it is still based on slow, manual, and paper-based processes. The railway industry has been very slow to adopt new digital technologies \cite{van2020digital}.

A very common workflow is:
\begin{enumerate}
    \item A mechanic in the railyard performs maintenance on a wagon.
    \item The mechanic writes the details (part numbers, actions taken) on a \textbf{paper logbook} or a form on a clipboard.
    \item At the end of the day, the mechanic gives this paper to an office administrator.
    \item Sometime later (maybe days later), the administrator manually types this information from the paper into a computer, maybe in an Excel file or a local database.
\end{enumerate}

This process is a disaster for a modern data-driven system.
\begin{itemize}
    \item \textbf{It is Slow (High Latency):} The data in the central database is days or even weeks old. This makes real-time predictive maintenance completely impossible. You cannot predict a failure if your data is from last month.
    \item \textbf{It is Error-Prone:} This manual process has many places for errors. The mechanic's handwriting might be bad. The data-entry person might make a typo (e.g., type '100' instead of '1000').
    \item \textbf{It is Fragile:} Paper records can be easily lost in a fire, damaged by water, or just lost in an office.
\end{itemize}

These three major limitations—data silos, a fundamental lack of trust, and inefficient paper-based processes—show that the traditional, centralized model is broken. It is not safe enough, fast enough, or trustworthy enough for a modern railway system.

This is the foundation for our research. We need a new system that is:
\begin{enumerate}
    \item \textbf{Shared and Interoperable} (to break the silos).
    \item \textbf{Immutable and Trusted} (to guarantee data integrity).
    \item \textbf{Digital and Real-Time} (to replace paper).
\end{enumerate}
These three needs are the exact features that blockchain technology (which we will explain in the next section) promises to deliver.




\section{Fundamentals of Blockchain Technology}
\label{sec:lit_blockchain_fundamentals}

In the last section, we showed the big problems with traditional, centralized data systems. We found that they have problems with data silos, a lack of trust, and inefficiency. Because our proposed solution uses blockchain to solve these problems, it is very important to explain what this technology is. This section will explain the ``solution domain`` for our thesis. We will build the concepts from the ground up, so that the reader can understand our technical design in Chapter 3.

\subsection{Distributed Ledger Technology (DLT)}
\label{sec:lit_dlt}

The first, and most important, idea is \textbf{Distributed Ledger Technology (DLT)}. This is the big category of technology where blockchain belongs.

A ``ledger`` is a simple idea, it is just a book of records. For thousands of years, banks, governments, and businesses have used ledgers to track value (e.g., ``Farid has 100 euro,`` ``Wagon 101 belongs to Company A``). A traditional ledger is \textbf{centralized}. This means one single entity (like a bank) owns the ledger. They are the only one who can write in it, and they are the only one who has the ``master copy``. This is the system we have today. It has a big weakness: you must \textbf{trust the central party}. You must trust the bank to not make a mistake, to not get hacked, and to not cheat you. This is the ``trusted third-party`` problem.

A DLT is a completely new model for a ledger. Instead of one central copy, the ledger is \textbf{``distributed``} (copied) to many different computers in a network. These computers are called ``nodes`` or ``peers``. When a new record (a ``transaction``) is added to the ledger, it is sent to all the nodes, and they all update their copy of the book at the same time.

This model has three main features:
\begin{enumerate}
    \item \textbf{It is Decentralized:} There is no single, central boss. No one person or company owns the data or controls the network. All the nodes must agree on the rules.
    \item \textbf{It is Transparent:} In a public DLT, everyone in the network (all the nodes) can see all the records. This makes it very easy to audit.
    \item \textbf{It is Resilient:} In a centralized system, if the main server fails, the entire system stops. In a DLT, if one node fails (or 1,000 nodes fail), it does not matter. The other nodes in the network still have the full copy of the ledger, so the system cannot shut down. It has no single point of failure.
\end{enumerate}

A \textbf{blockchain} is the most famous and most widely-used *type* of DLT \cite{yaga2019blockchain}. It is a special DLT that organizes the records in a way that makes them immutable, or unchangeable.

\subsection{Core Components of a Blockchain}
\label{sec:lit_core_components}

A blockchain is not just a shared database. It has special features that make it ``immutable``, which means the records cannot be changed or deleted once they are added. This is the most important feature for our thesis, because it is how we create *trust*. It does this by ``chaining`` records together in ``blocks`` using cryptography.

\subsubsection{Cryptography and Hashing}
\label{sec:lit_hashing}
The most important tool in a blockchain is a \textbf{cryptographic hash function}. Because our thesis is based on the Ethereum platform, we will talk about the main hash function used by Ethereum, which is \textbf{KECCAK-256}. This is the function that is used inside the Ethereum Virtual Machine, and it is a modern and secure hash function \cite{wood2014ethereum}. This function was also chosen by the U.S. National Institute of Standards and Technology (NIST) to become the official \textbf{SHA-3} standard \cite{sha3_standard}.

A hash function is a math algorithm that can take any data (like a name, a whole book, or a list of our maintenance transactions) and turn it into a unique, fixed-length code. For KECCAK-256, this code is 256 bits (64 characters) long. This code is like a \textbf{``digital fingerprint``} for the data.

A hash function has three important properties:
\begin{enumerate}
    \item \textbf{It is Deterministic:} The same input will *always* produce the same hash.
    \item \textbf{It is a One-Way Function:} It is very easy to find the hash from the data, but it is (for all practical purposes) impossible to find the original data if you only have the hash.
    \item \textbf{It is Highly Sensitive (The Avalanche Effect):} If we change just *one letter* or one small piece of the original data, the hash (the fingerprint) will change completely.
\end{enumerate}

This is how a blockchain makes sure data is not tampered with. If anyone changes even one comma in an old record, the hash of that record will change, and the whole network will know.

This is very relevant to our own project. As we will show in Chapter 3, we use the \texttt{keccak256()} function in our Solidity code to create the unique keys for our search indexes (for example, to turn the wagon name ``Cargo 101`` into a unique \texttt{bytes32} key for the mapping).

\subsubsection{Blocks and Chains}
\label{sec:lit_blocks_chains}
A blockchain does not just record one transaction at a time. It groups transactions together into a \textbf{``block``}. A block is just a list of transactions that happened in a certain time (e.g., the last 10 minutes).

When a new block is created, it also contains two very important pieces of data in its ``header``:
\begin{itemize}
    \item The hash of all the transactions inside it.
    \item The hash of the \textit{previous} block.
\end{itemize}

This is the ``chain`` part. Block 5 has the hash of Block 4 in its header. Block 4 has the hash of Block 3 in its header. This creates a ``chain`` of blocks that are cryptographically linked all the way back to the very first block (the ``genesis block``).

This is what makes the ledger \textbf{immutable}. If an attacker wants to change a transaction in our railway ledger, (for example, to delete a maintenance record from Block 100), they would have to do this:
\begin{enumerate}
    \item Change the record in Block 100.
    \item This change would change the ``fingerprint`` (hash) of Block 100.
    \item Because the hash of Block 100 is *inside* Block 101, this change would ``break`` Block 101.
    \item The attacker would have to re-calculate Block 101 with the new, fake hash.
    \item This would then change the hash of Block 101, which would break Block 102.
    \item The attacker would have to re-calculate every single block, all the way to the end of the chain, all at the same time, and do it faster than all the other honest nodes in the network.
\end{enumerate}
This is ``computationally infeasible``, which is a computer science way of saying it is impossible. This is how we get our trust. We do not have to trust a company, we just have to trust the math.

\subsubsection{Consensus Mechanisms}
\label{sec:lit_consensus}
This is the last big, complex problem. We have a network of 10,000 nodes. There is no central boss. If two nodes propose a new block at the same time, which one is the correct one?

How does a decentralized network agree on ``the`` single source of truth? They use a \textbf{consensus mechanism}. This is a set of rules for the nodes to agree \cite{saad2022comparative}. There are many types, but the two most famous are Proof-of-Work and Proof-of-Stake.

\begin{itemize}
    \item \textbf{Proof-of-Work (PoW):} This was the first consensus mechanism, and it is used by Bitcoin. It works like a ``computational race`` or a lottery.
    \begin{itemize}
        \item Nodes called ``miners`` use very powerful, special computers (ASICs) to try and solve a very, very hard math puzzle.
        \item They are all ``racing`` to be the first one to find the answer.
        \item The first miner to find the answer (the ``proof`` that they did the ``work``) gets to add the new block to the chain.
        \item As a reward, they get paid in new Bitcoin.
        \item \textbf{Pros:} It is the most secure and most proven consensus mechanism.
        \item \textbf{Cons:} It is very slow (Bitcoin only handles ~7 transactions per second). More important, it uses a huge, huge amount of electricity. This is a very big environmental problem.
    \end{itemize}
    
    \item \textbf{Proof-of-Stake (PoS):} This is the modern model. Ethereum (the platform we are using) famously ``merged`` from PoW to PoS in 2022. This is the model that is relevant to our thesis.
    \begin{itemize}
        \item In PoS, there are no ``miners`` and there is no ``race``. Instead, there are ``validators``.
        \item A validator is a node that wants to help create blocks. To do this, they must first ``stake`` (lock up) their own money (e.g., 32 ETH) as a collateral.
        \item The network then randomly chooses one validator and says, ``It is your turn to propose the next block.``
        \item The validator proposes the block, and other validators ``attest`` (vote) that it is a good block.
        \item If the block is good, the validator gets a small reward (like interest on their stake).
        \item \textbf{Security:} This is how PoS is secure. If a validator tries to cheat (e.g., proposes a fake block with bad transactions), the network will find out, and the validator's stake is \textbf{``slashed``} (taken away and destroyed). This is a very strong financial incentive to be honest.
        \item \textbf{Pros:} It is much faster than PoW and, most important, it is \textbf{99.9\% more energy-efficient}.
        \item \textbf{Cons:} It is a more complex system, and some people argue it is less ``decentralized`` than PoW.
    \end{itemize}
\end{itemize}
For our thesis, we are building on the Ethereum platform, so we are using the Proof-of-Stake model. This is important because it shows our solution is built on a modern, sustainable, and fast technology.

\subsection{Ethereum and Smart Contracts}
\label{sec:lit_smart_contracts}

This is the most important part of the ``solution domain`` for our thesis. Why did we choose Ethereum, and not Bitcoin?

\subsubsection{Bitcoin vs. Ethereum}
Bitcoin is ``Blockchain 1.0``. It is a DLT, but its purpose is very simple and limited: it is a ``peer-to-peer electronic cash system``. The code inside Bitcoin's transactions is very simple. It can only do one thing: move money (bitcoins) from one address to another.

In 2013, a developer named Vitalik Buterin had a new idea. He asked, ``What if the blockchain could do more than just move money? What if it could run *any* computer program?`` This idea became \textbf{Ethereum}.

Ethereum is ``Blockchain 2.0``. It is not just a decentralized ledger; it is a \textbf{decentralized ``world computer``} (or Ethereum Virtual Machine, EVM). It is a platform that can run *code*.

\subsubsection{Smart Contracts}
The ``code`` that runs on the Ethereum platform is called a \textbf{Smart Contract}.

This is the key concept of our entire thesis. A smart contract is a ``self-enforcing agreement`` that is written in code (like Solidity) and deployed to the blockchain \cite{christidis2016blockchains}.

We can think of a smart contract like a ``trusted robot`` or a digital vending machine. A vending machine is a simple, physical smart contract:
\begin{itemize}
    \item \textbf{The Rule is:} IF you (the user) put in 1.50 euro, THEN the machine (the contract) will give you a coke.
    \item \textbf{It is Automatic:} You do not need to ask a human.
    \item \textbf{It is Trusted:} You know that if you put the money in, you will get the coke. The rules are locked in the machine.
\end{itemize}
A smart contract is the same, but for digital business logic. Our \texttt{RailwayAssetRegistry} contract is an agreement. It has rules, like:
\begin{itemize}
    \item \textbf{IF} a user calls the \texttt{addWagon} function,
    \item \textbf{AND} the user proves the parent \texttt{trainId} is real,
    \item \textbf{THEN} the contract will run the code to create a new wagon and save it to the ledger.
\end{itemize}
The most important part is that the smart contract code *also* lives on the blockchain, so it is also \textbf{immutable}. Once we deploy our contract, its rules can never be changed. This creates ``trustless execution``. We do not have to trust a company to follow their own rules; we just have to trust the *code* that is locked on the blockchain. This is how we solve the ``trust`` problem between the railway stakeholders.

\subsection{Public vs. Private (Consortium) Blockchains}
\label{sec:lit_public_private}

Finally, it is important to know that there are different *types* of blockchains. This is a very important choice for a business.

\begin{enumerate}
    \item \textbf{Public Blockchains (Permissionless):}
    \begin{itemize}
        \item \textbf{Who can join?} Anyone in the world (e.g., Bitcoin, Ethereum).
        \item \textbf{Pros:} This is true decentralization. It is highly secure (censorship-resistant) and transparent.
        \item \textbf{Cons:} It is slow, it is very expensive (you must pay ``gas fees`` for every transaction, like `addWagon`), and there is \textbf{zero privacy}. All our railway maintenance data would be visible to the public. This is not acceptable for a real business.
    \end{itemize}
    
    \item \textbf{Private Blockchains (Permissioned):}
    \begin{itemize}
        \item \textbf{Who can join?} Only one single company (e.g., a company uses Hyperledger to build its own internal blockchain).
        \item \textbf{Pros:} It is very fast, transactions are free, and it is 100\% private.
        \item \textbf{Cons:} It is not decentralized. It is just a normal database with cryptography. You must trust the one single company that owns it. This does not solve our ``trust problem`` between different stakeholders.
    \end{itemize}
    
    \item \textbf{Consortium Blockchains (Permissioned):}
    \begin{itemize}
        \item \textbf{Who can join?} A pre-selected *group* of trusted organizations. This is the perfect model for our railway problem. The ``consortium`` would be our stakeholders: the operator, the maintenance crew, the part manufacturer, and the government regulator.
        \item \textbf{Pros:} It is the ``best of both worlds`` for business \cite{golosova2021public}. It is \textbf{private} from the public, so our railway data is safe. It is \textbf{fast} and has low (or zero) transaction fees. But, it is still \textbf{decentralized *among the members*}. No single member can cheat the others.
        \item \textbf{Example Platforms:} Hyperledger Fabric, Corda.
    \end{itemize}
\end{enumerate}

For our thesis, this is our justification: for a real-world, production deployment, a \textbf{consortium blockchain} would be the correct and final choice.

However, for this thesis, our goal is to prove the *concept*, the *smart contract logic*, and the *3-tier architecture*. We chose to build on the \textbf{Ethereum} platform (using the \textbf{Sepolia testnet}). We did this because it is a public network that anyone can audit, and it has the best and most mature tools in the world (like Solidity, Hardhat, and Ethers.js). Our system's logic and our 3-tier architecture can be moved to a consortium chain in the future with very few changes.




\section{State of the Art: Blockchain in Asset Management}
\label{sec:lit_state_of_art}


Now that we have established the ``problem domain`` (the challenges in railway asset management, Section 2.2) and the ``solution domain`` (the fundamentals of blockchain, Section 2.3), we must review the ``State of the Art``. This is where we combine the two areas. We must find out what other researchers have already done.

The key question for our thesis is: ``Has someone already used blockchain to solve the problems of asset tracking and maintenance?``

We will review the literature in three parts. First, we will look at the general topic of supply chain management, which is very similar to our problem. Second, we will look at the integration of Internet of Things (IoT) sensors, which is important for our future work. Finally, we will look for research that is *specifically* about the railway industry.

\subsection{Blockchain for General Supply Chain Management (SCM)}
\label{sec:lit_supply_chain}

The most common use for blockchain (after cryptocurrency) is in Supply Chain Management (SCM). The problems in SCM are almost the same as our railway problem. A supply chain has many stakeholders (like the farm, the factory, the shipping company, the customer) who all need to share data, but they do not trust each other. They need a single, trusted source of truth for tracking an asset.

A lot of research has been done on this topic. In a major review of this area, \cite{saberi2019blockchain} analyzed many papers. They found that the main benefits of using blockchain in SCM are: \textbf{transparency}, \textbf{traceability}, \textbf{security}, and \textbf{trust}. They argue that blockchain is not just a technical tool, but a tool for ``inter-organizational collaboration``, which is exactly what our railway stakeholders need.

We can look at some specific examples from different industries.

\subsubsection{Food Supply Chains}
The food industry is a very popular area for blockchain research. This is because ``provenance`` (knowing where something came from) is very important for food safety. When there is an *E. coli* outbreak, the government needs to know *immediately* which farm the bad lettuce came from.

A study by \cite{syliman2021blockchain} proposed a full blockchain-based system for tracking food products. They used smart contracts on Ethereum to track a product from the farm, to the processor, to the distributor, and finally to the retailer. Their system created a ``transparent and trusted`` record. The main result was that a customer could scan a QR code on a product and see its entire history. This is very similar to our goal of tracking a railway part from its manufacturer to its installation.

\subsubsection{Pharmaceutical Supply Chains}
The pharmaceutical industry has a very dangerous and expensive problem: counterfeit (fake) drugs. These fake drugs can harm or kill patients. The problem is that it is very easy for a fake product to enter the supply chain.

Researchers like \cite{musamih2021blockchain} have proposed blockchain systems to solve this. They proposed an ``anti-counterfeiting`` system using blockchain and smart contracts. In their system, the original manufacturer (like Pfizer) creates a unique digital 'token' for every single bottle of medicine. This token is then tracked on the blockchain as it moves from the factory to the distributor, to the hospital. A pharmacist can scan the bottle and the smart contract will prove if it is the real, official product. This is a very strong comparison to our project, where we need to prove that a railway part is an ``official`` part and not a cheap, uncertified fake.

\subsubsection{Maritime Logistics (Shipping)}
The global shipping industry (like Maersk) has the same problems as the railway industry. They have many stakeholders (the factory, the port, the customs office, the ship, the customer) and they use a huge amount of slow, paper-based documents, like the ``Bill of Lading``.

A study by \cite{ahmed2022blockchain} reviewed the use of blockchain for ``maritime logistics``. They found that using a blockchain system (like the real-world TradeLens platform by Maersk and IBM) can solve many of these problems. By putting all the documents on a shared ledger, they can reduce the amount of paper, speed up customs, and reduce fraud. Their findings show that this technology can be used to manage very large, heavy, and complex assets (like shipping containers), which is very similar to our goal of managing wagons.

\subsubsection{High-Value Goods (Diamonds)}
Another area of research is in tracking high-value goods to prove they are ``ethically sourced``. The diamond industry has a big problem with ``conflict diamonds`` (or ``blood diamonds``) being sold to fund wars.

To solve this, companies like De Beers created a blockchain platform called ``Tracr``. Academic studies like \cite{iyer2022tracr} have analyzed this system. They explain how a unique digital ID is created for a rough diamond when it is mined. This ID is stored on the blockchain. As the diamond is cut, polished, and sold, its certificate is updated on the ledger. This creates a permanent, immutable record of the diamond's ``provenance``. This proves to the customer that their diamond is not a conflict diamond. This is another example of using blockchain to create trust and a verifiable history for a physical asset.

\subsubsection{Limitations and Barriers}
It is also important to be realistic. Blockchain is not a perfect solution. A very important review by \cite{queiroz2019blockchain} studied the ``barriers to adoption`` for blockchain in supply chain. They found that even if the technology is good, there are many challenges. The biggest problems are:
\begin{itemize}
    \item \textbf{Scalability:} Public blockchains (like Ethereum) can be slow and can only handle a small number of transactions per second.
    \item \textbf{High Cost:} The ``gas fees`` on Ethereum can be very expensive.
    \item \textbf{Interoperability:} It is hard to connect the new blockchain system to the old, ``legacy`` databases that companies already use.
    \item \textbf{Privacy:} Companies do not want to put all their secret business data (like prices or customer lists) on a public blockchain for their competitors to see.
\end{itemize}
This is very important for our thesis. This is *why* we chose a \textbf{hybrid architecture}. Our system (in Chapter 3) is designed to solve these problems. We keep user data *off-chain* to protect privacy. We use a high-performance backend to manage the system, so the user does not feel the ``slowness`` of the blockchain. This article helps us justify our hybrid design.

\textbf{Summary of this section:} The literature on SCM is very strong. It proves that the basic concept of using blockchain to track physical assets, prevent fakes, and share data with partners is a very successful and well-researched idea. This gives us a strong foundation.

\subsection{Blockchain and Internet of Things (IoT) for Asset Tracking}
\label{sec:lit_iot}

The next step in the research is to *automate* the data collection. The problem with the SCM systems we just discussed is that a human must still scan the QR code or enter the data. This means a human can still make a mistake or cheat.

The ``Internet of Things`` (IoT) is the idea of using small sensors to get real-world data, like temperature, vibration, or GPS location. The research in this area tries to connect these IoT sensors *directly* to the blockchain. This is called the ``Blockchain of Things`` (BCoT). The goal is to create a trusted record of data from the real world, with no human in the middle.

A major review by \cite{samaniego2020iot} studied how to combine IoT and blockchain for traceability. They argued that this combination is very powerful. The IoT sensor provides the real-time data, and the blockchain provides the immutable, trusted ``backend`` to store this data.

\subsubsection{Cold Chain Monitoring}
A classic example is ``cold chain`` monitoring. This is for products (like vaccines or fresh food) that must stay at a cold temperature.
A study by \cite{samaniego2020iot} designed a system for this. They proposed putting an IoT temperature sensor in the shipping container with the food. This sensor would automatically send the temperature to a smart contract every 30 minutes. The smart contract would have a rule, like \verb|if (temperature > 8) { record_violation(); }|.
This is a very powerful idea. It creates a *provable, automated* record of the food's quality. This is very relevant to our project. We can (and will) propose in our ``Future Work`` that our system could be upgraded with IoT sensors to automatically track an asset's condition.

\subsubsection{Connected Vehicles and Data Integrity}
This area of research is the most similar to our thesis. Some researchers have studied using blockchain for ``connected vehicles`` or ``Vehicular Ad-hoc Networks (VANETs)``.
A study by \cite{singh2020blockchain} proposed a blockchain-based system for vehicles to share data in a trusted way. They were focused on vehicles sharing data about traffic or accidents.
Other research has looked at using this for insurance. A sensor in the car could write the car's mileage and speed data to a blockchain. The insurance company could then read this trusted data to give the driver a discount.

This is a direct parallel to our project. One of our biggest ``Future Work`` ideas is to use an IoT sensor on the train to automatically update the \texttt{mileage} field in our smart contract. This literature proves that this idea is a very active and important area of research.

\textbf{Summary of this section:} The literature shows that connecting IoT sensors to the blockchain is a very powerful idea. It allows us to automate data collection and create a trusted record of real-world data, like temperature or mileage. This strongly supports the ``Future Work`` section of our thesis.

\subsection{Specific Research on Blockchain for Railways}
\label{sec:lit_railway}
This is the most important part of our review. Now that we know blockchain is good for SCM and IoT, we must ask: \textbf{has anyone already solved our exact problem?}

We searched for academic papers that specifically mention both ``blockchain`` and ``railway``. We found that there is *interest* in this topic, but the research is very new and is not very ``mature`` (it is not fully developed).

\subsubsection{Conceptual Frameworks}
Most of the papers we found are \textbf{``conceptual frameworks``}. This means they are high-level ideas, not working systems.

A key paper by \cite{lohmer2020blockchain} proposed one of these frameworks. The authors did a very good analysis, very similar to our Section 2.2. They identified the same problems: many stakeholders (operators, manufacturers, maintainers) who do not trust each other, and a need for a ``single source of truth`` for maintenance data. They *proposed* that a blockchain system (they suggested Hyperledger Fabric) could be a good solution. They drew diagrams of how the system *could* work.
This paper is very important for us, because it proves that our ``problem statement`` (in Section 2.2) is correct and is a real problem that other academics are also trying to solve. But, this paper is only a ``framework``. They did not *build* the smart contracts, they did not *build* a backend API, and they did not *build* a user interface.

Another paper by \cite{khan2022railway} also proposed a ``blockchain-based system for secure and transparent railway maintenance``. This paper is also a very high-level model. It focuses on the data-sharing agreements and proposes a system architecture. It is a very good paper, but again, it does not show a full implementation. It does not include the smart contract code, the API logic, or any user interface.

\subsubsection{Research on Different Railway Problems}
We also found papers that use blockchain for *different* problems in the railway industry, which are not our problem.
\begin{itemize}
    \item \textbf{Ticketing:} Some researchers, like \cite{pal2020blockchain}, have proposed using blockchain for railway ticketing. Their idea is to create a decentralized system where users can buy, sell, or trade their train tickets in a peer-to-peer way, without a central company controlling everything.
    
    \item \textbf{Signaling:} Other researchers, like \cite{sharma2022blockchain}, have looked at using blockchain for railway *signaling systems*. Their goal was to improve the cybersecurity of the signals, so that a hacker cannot cause an accident. They proposed using a blockchain to create a trusted log of all signal commands.
\end{itemize}
These papers are useful because they show that ``blockchain for railways`` is an active area of research. But, they are not trying to solve our problem, which is *asset management and maintenance*.

\textbf{Summary of this section:} Our review of the specific railway literature is the most important part of this chapter. We found that while there is a lot of *interest* in this topic, the research is almost all \textbf{theoretical}. We found ``conceptual frameworks`` and ``models``, but we could not find any academic papers that showed a *complete, end-to-end, working system* with all three layers: a smart contract, a backend API, and a frontend.







\section{Analysis and Identification of the Research Gap}
\label{sec:lit_gap}

This is the final and most important section of our literature review. In the previous sections, we have built the foundation for our research. We have analyzed the ``problem domain`` and shown that traditional railway asset management systems suffer from serious problems of data silos, a lack of trust, and inefficiency (Section 2.2). We have also analyzed the ``solution domain`` and shown that blockchain technology, with its features of immutability, transparency, and smart contracts, is a powerful tool for building trust (Section 2.3).

Finally, we reviewed the ``State of the Art`` (Section 2.4), where we saw how other researchers have used blockchain for supply chain management, IoT, and even for the railway industry.

Now, we must do the most important step. We must critically analyze this existing research to find what is *missing*. This analysis will allow us to identify the ``research gap`` that our thesis will fill.

\subsection{Summary of Existing Literature}
\label{sec:lit_gap_summary}

Our review of the State of the Art shows that the idea of using blockchain for asset management is very strong and well-supported by many researchers.

\begin{itemize}
    \item \textbf{The SCM literature} (e.g., \cite{saberi2019blockchain}, \cite{musamih2021blockchain}) has clearly proven that blockchain is an effective tool for improving \textbf{traceability} and \textbf{transparency}. It can be used to track everything from food to pharmaceuticals, giving a single, shared source of truth to all stakeholders. This proves our basic idea is correct.
    
    \item \textbf{The IoT literature} (e.g., \cite{samaniego2020iot}, \cite{salah2019blockchain}) shows that it is possible to connect real-world sensors to the blockchain. This creates a trusted, automated record of an asset's condition (like temperature or location), which is a powerful concept for our future work.
    
    \item \textbf{The railway-specific literature} (e.g., \cite{lohmer2020blockchain}, \cite{khan2022railway}) is the most relevant. It confirms that the problems we identified in Section 2.2 are real and that other academics agree. These papers specifically propose blockchain as a ``conceptual solution`` to the problems of data silos and lack of trust in railway maintenance.
\end{itemize}

So, the existing research gives us a strong foundation. We know the *problem* is real and we know the *technology* is a good fit. However, a deeper analysis shows that there is a large gap between these high-level proposals and a practical, working, and user-friendly system.

\subsection{Identified Gaps and Limitations}
\label{sec:lit_gap_limitations}

While the existing literature is a good starting point, we have identified three major gaps. The research tends to be ``technology-centric,`` focusing on high-level ideas, and it often ignores the practical challenges of implementation, user-friendliness, and system architecture.

\subsubsection{Gap 1: Lack of Full-Stack Implementation (From Theory to Practice)}
The single biggest gap we found, especially in the railway domain, is the gap between *theory* and *practice*.

The vast majority of the papers we found, like \cite{lohmer2020blockchain} and \cite{khan2022railway}, are \textbf{``conceptual frameworks``} or \textbf{``architectural proposals``}. They do an excellent job of drawing diagrams and explaining how a blockchain system *could* work. They propose ``models`` and ``frameworks`` for data sharing.

However, this is a very serious gap. A theoretical model on paper does not have to deal with any real-world engineering problems. The number of academic papers that *propose* a blockchain system is very high, but the number that *actually build and test* a full system is very small \cite{bdiwi2019exploring}.

A theoretical framework does not have to solve these hard questions:
\begin{itemize}
    \item \textbf{Smart Contract Complexity:} It is easy to draw a box that says ``Smart Contract``. It is very difficult to actually write a smart contract that is secure, gas-efficient, and can handle complex, three-level hierarchical relationships (Train $\rightarrow$ Wagon $\rightarrow$ Equipment). How do you search this data? How do you update it? The existing literature does not show this.
    
    \item \textbf{Middleware Development:} A blockchain cannot be used like a normal database. It is slow and hard to talk to. You need a ``middleware`` (our backend API) to manage this. This backend must handle user requests, manage a queue for slow blockchain transactions, and securely store the private keys for signing. This complex ``orchestration`` layer is a critical piece of software, and the conceptual papers we found do not design or build it.
    
    \item \textbf{Gas and Performance Evaluation:} A theoretical paper does not have any ``numerical results``. It cannot tell us how much the system *costs* to run. How much gas does it cost to add a new wagon? Is it \$0.01 or \$50? Is the API fast enough for a user, or does it take 30 seconds to load a page?
\end{itemize}
There is a large gap in the research for a \textbf{fully-implemented, full-stack solution}. We could not find any academic papers that present a complete, working, and tested system with all three layers: a smart contract, a backend API, and a frontend.

\subsubsection{Gap 2: Ignoring the User Experience (UX) and Mobile Needs}
The second major gap we found is that the existing literature is almost 100\% \textbf{``technology-centric``}. It focuses on the blockchain, the cryptography, and the data. It almost never talks about the \textbf{``user-centric``} side of the system.

This is a critical failure. A system, no matter how technically brilliant, is a complete failure if the end-users cannot or will not use it. The success of any new enterprise system depends on **user acceptance** \cite{kholofelo2020impact}.

Our problem domain has a very specific type of user: the \textbf{railway mechanic or inspector}. We must ask:
\begin{itemize}
    \item Where does this user work? They are not at a desk in an office. They are in a railyard, on the tracks, or in a maintenance tunnel.
    \item What device do they use? They do not have a desktop computer. They have a \textbf{mobile phone} or a rugged tablet.
    \item What is their environment like? It is loud, it is dirty, and they may be wearing gloves. Most importantly, the \textbf{internet connection} might be very bad or non-existent (like in a tunnel).
\end{itemize}
A regular website that requires a perfect, fast internet connection will not work for this user. The existing literature on blockchain for railways does not address this problem at all.

This is a major gap. There is no research on building a \textbf{Progressive Web App (PWA)} for this problem. A PWA is a special type of web application that can be ``installed`` on a phone, and it can be designed with **offline-first capabilities**. This would allow a mechanic to load all the asset data when they have Wi-Fi in the office, then go into the railyard (with no internet), update the maintenance records, and have the app automatically ``sync`` the new data to the blockchain when they get back to Wi-Fi.

This focus on the real-world \textbf{User Experience (UX)} and the need for a \textbf{mobile-first, offline-capable PWA} is a practical, user-centric gap that is almost completely ignored by the current academic literature.

\subsubsection{Gap 3: Naive Architectures (Privacy, Cost, and the Hybrid Model)}
The final gap we identified is that many of the proposed ``frameworks`` are \textbf{``architecturally naive``}. They often make a simple, and very wrong, assumption: that all data can just be put ``on the blockchain``.

This is a very bad design, and it shows a lack of practical experience. This ``all-on-chain`` model has three huge, fatal flaws:
\begin{enumerate}
    \item \textbf{Cost:} It is extremely expensive. Storing data on the Ethereum blockchain is the most expensive data storage in the world. Storing every maintenance log, every photo, and every user's name on-chain would cost millions of dollars in gas fees.
    
    \item \textbf{Performance (Speed):} A public blockchain is slow. It can take 15 seconds, or even minutes, for a transaction to be confirmed. A user will not wait 2 minutes to log in or to save a simple form.
    
    \item \textbf{Privacy and Security:} This is the most serious flaw. You \textit{cannot} put all your data on a public (or even consortium) blockchain. What about user accounts? Employee lists? User email addresses and passwords? It is a terrible, insecure idea to put this private, sensitive data on an immutable ledger. What about business secrets? Does a railway operator want their competitors to see their maintenance schedule or their list of suppliers? No.
\end{enumerate}
These problems of cost and privacy are the main reasons why companies are slow to adopt blockchain. The solution is to use an \textbf{``off-chain``} storage strategy \cite{zheng2020off}.

The research gap is the lack of a clear, practical \textbf{hybrid architecture} designed for this specific railway problem. We need a system that intelligently separates the data. We need to put:
\begin{itemize}
    \item \textbf{On-Chain:} Only the data that *must* be trusted and immutable (like the asset's ID, its current owner, and a hash of its maintenance report).
    \item \textbf{Off-Chain:} All the private, large, or changeable data (like user accounts, passwords, and the full maintenance report text) in a traditional, fast, and secure database.
\end{itemize}
While hybrid models are known, their specific application to solve this user-privacy-vs-asset-transparency problem in a full-stack, 3-tier system for railways has not been designed or built in the academic literature.

\subsection{Thesis Contribution}
\label{sec:lit_gap_contribution}

This thesis is designed to fill these three major gaps. The main contribution of our work is not just the *idea* of using blockchain, but the \textbf{design, implementation, and evaluation of a complete, practical, and user-focused solution}.

Our contribution is the answer to the gaps we just identified:

\begin{enumerate}
    \item \textbf{In response to Gap 1 (Lack of Full-Stack Implementation):}
    We are not just proposing a ``framework``. The main contribution of this thesis (in Chapter 3) is a \textbf{complete, full-stack, and implemented system}. We have built all three layers, from the gas-efficient Solidity smart contract (with hierarchical logic and search indexes), to the secure Python backend, to the final frontend. In Chapter 4, we will *evaluate* this system's real-world performance, providing the ``numerical results`` (like gas costs and API latency) that the conceptual papers are missing.
    
    \item \textbf{In response to Gap 2 (Ignoring the User Experience):}
    Our project is ``user-centric,`` not ``technology-centric``. We have designed our solution for the *real user*. Our contribution is the design and implementation of a \textbf{mobile-first Progressive Web App (PWA)}. This shows a practical solution for the mobile mechanic in the field, addressing the real-world challenges of a bad internet connection, which is a key part of our ``Main Contribution`` (Section 3.6).
    
    \item \textbf{In response to Gap 3 (Naive Architectures):}
    Our thesis presents a \textbf{practical hybrid architecture} that solves the cost and privacy problems. We show (in Section 3.1) a 3-tier system that intelligently separates data. We use the blockchain for what it is good at (immutable asset integrity) and a traditional, off-chain SQLite database for what it is good at (fast, private, and secure user authentication). This hybrid model is a key part of our contribution.
\end{enumerate}

By filling these gaps, our project is a significant and new contribution to the field of railway asset management. The following chapters will now present the design, implementation, and evaluation of this novel system.



