\chapter{Introduction}
\label{chap:introduction}

\section{Research Background}
\label{sec:intro_background}

The railway industry is one of the most important parts of the global economy and transportation. It moves billions of passengers and huge amounts of cargo every year. This industry is a very complex system. It is not one single company, but a large network of stakeholders. These include the train operators, the national infrastructure managers, private maintenance crews, part suppliers, and government regulators.

All of these different groups must work together to manage a very large and very valuable inventory of physical assets. A single train is made of thousands of individual components, from the main engine and wagons, down to single pieces of equipment like braking systems, wheelsets, and safety sensors. The process of managing this is called \textbf{Asset Management}. This means tracking the complete life cycle of every single part, from the day it is manufactured, to its installation, all of its maintenance cycles, and finally its retirement.

This is not just an accounting problem, it is one of the biggest challenges for the industry. The safety and reliability of the entire railway network depends on knowing the exact condition and history of these assets.

\section{Problem Statement}
\label{sec:intro_problem}

The main problem with traditional asset management in the railway industry is the lack of a single, trusted source of truth. The data is fragmented, disconnected (siloed), and not transparent. This creates several big problems:

\begin{itemize}
    \item \textbf{Data Silos:} Each stakeholder in the network (the operator, the maintenance crew, the part supplier) keeps its own private, centralized database. When a part is serviced, this information is not automatically or easily shared with everyone else. This is a known challenge in the industry, where this lack of data interoperability makes it very hard to get a full picture of an asset's health \cite{singh2021railway}.
    
    \item \textbf{Lack of Trust and Transparency:} Because the data is in silos, there is no trust. How can a train operator be 100\% sure that the maintenance crew *really* used the correct, official part? How can a government regulator easily audit the full history of a safety-critical part?
    
    \item \textbf{Data Integrity Issues:} The current systems are not immutable. A record in a centralized database can be changed, hacked, or just lost. Paper records, which are still very common, can be faked, damaged, or lost in a fire. This makes it impossible to guarantee the integrity of the maintenance log.
    
    \item \textbf{Inefficiency and High Costs:} This old system is very slow and expensive. To find the history of one wagon, a person might have to check three different systems or even make phone calls. This leads to high administrative costs and long delays.
\end{itemize}

\section{Motivation}
\label{sec:intro_motivation}

The motivation for this thesis comes from these big, real-world problems. These challenges are not just about saving money, they have very serious consequences.

\begin{enumerate}
    \item \textbf{Safety:} This is the most important motivation. If maintenance records are lost, faked, or untrusted, a train with a faulty part could be put into service. This can lead to derailments and put human lives at risk. A trusted, auditable log of every single part is necessary for modern safety.
    
    \item \textbf{Economic Cost:} The current system is very expensive. Companies must spend a lot of money on ''preventive'' maintenance (e.g., replacing parts every 6 months, ``just in case``). They do this because they cannot trust the data to perform ''predictive'' maintenance (e.g., replacing a part only when it is needed). This wastes a lot of time and money.
    
    \item \textbf{Regulatory Compliance:} Railway companies are under very strict rules from governments. They must be able to *prove* they are following safety rules. An immutable and auditable record of all maintenance actions would make this process much simpler and more reliable.
\end{enumerate}

We need a new system. We need a platform where all the partners can share data, where the data cannot be secretly changed, and where the history of any asset can be trusted by everyone.

\section{Proposed Solution: A Hybrid Blockchain System}
\label{sec:intro_solution}

This thesis proposes a new system to solve these problems. The proposed solution is a \textbf{Decentralized Asset Tracking and Maintenance Platform for Railway Systems}.

The core of our solution is the use of \textbf{blockchain technology}. A blockchain is a shared, distributed database. Its special feature is that it is ``immutable,`` which means once data is written, it cannot be changed or deleted. This technology has been widely studied as a way to improve transparency and traceability in complex supply chains \cite{choi2021blockchain}. We believe this is a perfect technology for our problem. By storing the record of every train, wagon, and maintenance action on a blockchain, we can create the single, trusted source of truth that the industry needs.

But, a ''pure'' blockchain application (DApp) is often slow, very expensive (it costs ``gas`` for every action), and not user-friendly. It is also a very bad for storing private data like user accounts.

Therefore, our main proposal is a \textbf{hybrid, three-tier architecture}. This system is the main contribution of our work. It combines the trust of the blockchain with the speed and privacy of a normal web application. Our system, which we built, is made of three layers:

\begin{enumerate}
    \item \textbf{The Data Layer (The Blockchain):} A Solidity smart contract that lives on the blockchain. This contract defines the assets (\texttt{Train}, \texttt{Wagon}, \texttt{Equipment}) and acts as the trusted, immutable ledger for all asset history.
    
    \item \textbf{The Logic Layer (The Backend API):} A centralized backend server (which we built with Python and FastAPI). This server acts as the ``middleware``. It manages user accounts and passwords in a private SQLite database (this is the ``off-chain`` part). It is the only part of the system that talks to the blockchain. This makes the system secure and easy to use.
    
    \item \textbf{The Presentation Layer (The Frontend):} A user-friendly web application (which we built with React). As we can see in our frontend project, this is a \textbf{Progressive Web App (PWA)}, so it can be ``installed`` on a mobile phone for mechanics to use in the field, even with a bad internet connection.
\end{enumerate}

This hybrid design gives us the best of both worlds. We get the speed of a normal database for user logins, but we get the trust and immutability of the blockchain for the important asset data.

\section{Aims and Objectives}
\label{sec:intro_aims}

To build this solution, this thesis has several main goals, or objectives:
\begin{itemize}
    \item \textbf{To design} a hybrid, three-tier system architecture that balances decentralization, performance, and security.
    \item \textbf{To implement} a gas-efficient Solidity smart contract for managing the lifecycle of railway assets and their hierarchical relationships.
    \item \textbf{To develop} a secure backend API that acts as a middleware, handling user authentication off-chain and managing all blockchain transactions.
    \item \textbf{To create} a user-friendly, mobile-first Progressive Web App (PWA) that allows staff to manage assets and update maintenance records from any device.
    \item \textbf{To evaluate} the practicality of the system by measuring its performance, including the gas costs of smart contract functions.
\end{itemize}

\section{Thesis Contribution}
\label{sec:intro_contribution}

The main contribution of this work is not just one thing, but the design and implementation of the whole, integrated system. While many papers *talk* about using blockchain for asset tracking (as we will see in Chapter 2), this thesis presents a complete, practical, and full-stack solution. Research in this area has often focused on the high-level benefits, but has not shown a full end-to-end implementation \cite{khan2022railway}.

Our key contributions are:
\begin{enumerate}
    \item \textbf{A Practical Hybrid Architecture:} We show a complete, working model of a 3-tier system that solves the ``on-chain vs. off-chain`` data problem.
    \item \textbf{A Full-Stack Implementation:} We built all three layers, from the database and smart contract to the backend API and the final user interface.
    \item \textbf{A Focus on User Experience (UX):} By building a PWA, we show a solution that is designed for the *real user* (the mobile mechanic), which is a step that many academic projects ignore.
\end{enumerate}

\section{Thesis Outline}
\label{sec:intro_outline}

The rest of this thesis is organized as follows:

\textbf{Chapter 2 - Literature Review and State of the Art:} This chapter reviews the existing academic literature. We first analyze traditional asset management, then we explain the fundamentals of blockchain, and finally we review other projects that have used blockchain for asset tracking. This chapter ends by identifying the ``research gap`` that our thesis will fill.

\textbf{Chapter 3 - Methodology:} This is the core technical chapter. It presents the design and implementation of our three-layer system in detail. We will explain the System Architecture, the Smart Contract logic, the Backend API, and the Frontend PWA.

\textbf{Chapter 4 - Experimental Evaluation:} This chapter presents the results of our work. We evaluate the system by measuring its performance, including the smart contract's gas costs, the API response times, and the frontend's usability. We then discuss what these results mean.

\textbf{Chapter 5 - Conclusion and Future Work:} This final chapter concludes the thesis. We summarize our findings, we state how we achieved our goals, and we discuss the limitations of our work and suggest ideas for ``future work`` that could be built on top of our project.