Within the suggested framework, process management is facilitated through the use of smart contracts powered by blockchain technology. These smart contracts are self-executing agreements with predefined rules that automatically execute actions when certain conditions are met. Within the system, two primary smart contracts are utilized: the Stakeholder Contract and the EVB Identity Contract. Both contracts are developed using the Solidity programming language and implemented with the REMIX IDE, a popular tool for building and deploying Ethereum-based smart contracts.
4.3.2. EVB Identity Contract
The EVB Identity Contract is designed to define and manage the identities of EVBs. The system ensures the tracking and management of critical information at each stage. The contract is organized into four key categories, each serving a specific purpose in storing essential data: General Information, Technical Information, Electric Vehicle Information, and Stakeholder Information. Together, these categories facilitate comprehensive lifecycle management by capturing the relevant status, specifications, and stakeholder details associated with each EVB.
The General Information category contains the basic details of the EVB. This includes brand, model, production date, unique serial number, quality control status, second-use suitability, and lifecycle stages. These details are registered on the blockchain by the EVB manufacturer.
The Technical Information category covers the physical and performance characteristics of the EVB. This includes data such as height, width, weight, battery capacity, voltage, and battery life that the electric vehicle battery manufacturer adds.
The Electric Vehicle Information category includes data on the EV to which the EVB is integrated. This information comprises the vehicle’s brand and model, chassis number, and assembly date. These details are recorded by the electric vehicle manufacturer.
The Stakeholder Information category maintains the public Ethereum addresses related to stakeholders. This category plays a crucial role in ensuring transparency and traceability by securely linking stakeholders to their respective blockchain identities.
The relationships between the categories are visualized in
Figure 7. The General Information category is directly related to the Stakeholder Information, Technical Information, and Electric Vehicle Information categories. These relationships are defined using the Solidity
struct data structure, which helps to organize the information systematically across categories and ensures the integrity of the system.
The EVB identity contract is designed to facilitate the creation and management of EVB identities. Two essential verifications are conducted in the EVB identities creation procedure, as illustrated in Algorithm 1. The first verification involves confirming the uniqueness of the serial number for the battery being registered. The second verification requires ensuring that the stakeholder executing the action possesses the EVB manufacturer role. Upon successful completion of these verification steps, the EVB identity is created and registered on the blockchain.
The EVB identity that has been created is upgraded to EV Manufacturer status by calling the change status EV manufacturer method in the contract. The flow of the algorithm for this method is shown in Algorithm 2. As input to this method, the EV manufacturer provides information about the vehicle in which the battery will be integrated. Before proceeding, it is verified that the battery serial number exists on the blockchain, that the current status of the battery is assigned to the EVB manufacturer, and that the transaction details are correctly recorded. The stakeholder performing the operation is an EV manufacturer. Following these verifications, vehicle data is inscribed on the EVB ID, the status of the EVB ID is revised to reflect the EV manufacturer, and the information is stored on the blockchain.
| Algorithm 1: Register EVB: Algorithm for registering a new EVB on the blockchain. This process validates the serial number and ensures that the operation is performed by a legitimate EVB manufacturer. If valid, it creates a new EVB identity with default values and records it on the blockchain. Otherwise, it prompts an error message for invalid serial numbers or unauthorized stakeholders. |
![Electronics 14 04854 i001 Electronics 14 04854 i001]() |
| Algorithm 2: Change status EV manufacturer: Algorithm for updating the status of an Electric Vehicle Battery (EVB) to reflect its assignment to an Electric Vehicle (EV) Manufacturer. The process verifies the serial number, checks the current status of the EVB, and ensures the operation is performed by an authorized EV manufacturer. If valid, it updates the EVB identity with vehicle information and changes its status. Otherwise, an error message is displayed for invalid serial numbers or unauthorized actions. |
![Electronics 14 04854 i002 Electronics 14 04854 i002]() |
An EVB identifier associated with an EV in the role of an EV producer can be updated to the next role, that of a retailer, using the changeStatusRetailer method. This method requires two inputs: the EVB serial number and the account address of the stakeholder in the retailer role. Using this input, the system performs checks to ensure that the battery serial number exists on the blockchain, that the battery’s status is currently in the EA producer role, and that the stakeholder initiating the transaction is authorized as a retailer. Once these checks are successfully validated, the status of the EVB identifier is provided to the retailer.
When an electric vehicle equipped with an EVB is sold by a retailer to a customer, the EVB’s status is updated for the customer using the changeStatusCustomer method. Similar to the retailer method, this method requires the EVB serial number and the account address of the stakeholder in the customer role as input. Based on this information, the system verifies that the battery serial number exists on the blockchain, that the battery status is currently in the retailer role, and that the stakeholder initiating the transaction is authorized as a customer. Following these verifications, the EVB identifier’s status is updated and communicated to the customer and recorded on the blockchain.
Additionally, the changeLifeCycle method in the contract is used to update the battery lifecycle of the EVBs in the customer role. This method ensures that the battery can be tracked throughout its entire lifecycle, providing valuable information for recycling processes. Furthermore, the presence of such a method in the contract enables automated updates of the battery status on the blockchain through application programming interfaces (APIs) in next-generation smart electric vehicles.
The contract contains the changeStatusEVService method to change the status of the EVB from a customer to an EV service. This method, similar to the others, requires the EVB serial number and the account address of the stakeholder in an EV service role. It performs checks to ensure that the battery serial number exists on the blockchain, that the battery’s status is currently in the customer role, and that the stakeholder initiating the transaction is authorized as an EV service provider.
Algorithm 3 formalizes the decision-making logic of the proposed MCDM by computing the relative utility of second-life reuse and direct recycling for battery. The algorithm evaluates all criteria using their assigned weights, aggregates the normalized performance scores, and applies the SOH threshold as a mandatory eligibility constraint. By comparing the resulting utility values, the algorithm determines the optimal routing outcome and outputs a binary decision variable indicating whether the battery should proceed to second-life applications or be directed to material recovery.
The recycling or second-use processes of an EVB are carried out in collaboration with the stakeholder assigned to the recycling role. When an EVB arrives at an electric vehicle service center and is removed from the vehicle, its transition to the recycling stage is executed through the
changeStatusRecycling method defined in the smart contract. Algorithm 4 presents the procedure, which incorporates embedded MCDM to autonomously determine second-use suitability. Before the decision process begins, the system verifies that the EVB’s serial number is registered on the blockchain, that its current status is “Electric Vehicle Service,” and that the stakeholder initiating the operation possesses the recycling role. Once these conditions are satisfied, the smart contract invokes the MCDM algorithm (Algorithm 3) internally. This algorithm evaluates the battery’s weighted criteria scores together with its SOH value and SOH threshold, producing an automated on-chain decision indicating whether the battery is suitable for second-life reuse. If the computed decision is positive, the EVB’s status is updated to “SecondUse” and the information is recorded on the blockchain. If the MCDM evaluation determines that the battery is unsuitable for reuse, the EVB identifier is updated to “Recycling” and recorded accordingly. In both cases, the account address of the recycling stakeholder is appended to the EVB record, ensuring that all actions remain transparent, traceable, and tamper-proof. Through this integration, the routing of EVBs no longer depends on stakeholder judgment but is performed fully automatically by the smart contract logic.
| Algorithm 3: MCDM Algorithm for Determining EVB End-of-Life Routing. The algorithm computes reuse and recycling utility scores based on weighted criteria, checks SOH eligibility, and assigns each battery to second-life reuse or material recycling. Ineligible or low-utility batteries are routed directly to recycling. |
![Electronics 14 04854 i003 Electronics 14 04854 i003]() |
| Algorithm 4: Change status recycling: This algorithm updates the status of an EVB by combining conventional recycling verification steps with MCDM procedure. The smart contract internally calls the MCDM function (Algorithm 3) to autonomously determine whether the battery is suitable for second-life reuse based on its technical condition, weighted criteria scores, and SOH threshold. The final routing decision—either “SecondUse” or “Recycling”—is executed on-chain. |
![Electronics 14 04854 i004 Electronics 14 04854 i004]() |
If an EVB is considered suitable for the second use, the changeStatusSecondUses method is activated. Similar to other methods, the EVB serial number and the account address of the relevant stakeholder are checked. Once these checks are validated, the EVB status is updated to ‘second use’, and the stakeholder’s account address is appended to the identifier, recording all changes on the blockchain.