I designed and implemented an electric vehicle charging management system for a realistic station operation scenario in which drivers need transparent pile availability, reliable reservations, fast fault reporting, visible announcements, and responsive online service, while administrators need controlled user management, pile maintenance, reservation supervision, repair closure, and service aggregation. The system follows a browser/server architecture and uses Spring Boot for backend REST services, Vue for frontend interaction, and MySQL for persistence. My main objective is not merely to build a set of CRUD pages, but to connect reservation, usage, fault handling, announcement delivery, and customer service into a coherent electric vehicle charging management workflow with explicit states, role boundaries, and traceable records. I treat the platform as a layered information system that supports both drivers and administrators through one shared data model and a controlled set of service endpoints.
The design emphasizes the operational meaning of an electric vehicle charging platform. A charging pile is not only a record with a name and a price. It is a service point with availability, health, reservation capacity, fault history, and maintenance responsibility. A reservation is not only a row in an order table. It is a time-bounded claim on a finite resource. A repair request is not only a message. It is a work item that changes pile status and affects future electric vehicle charging reservations. A customer service conversation is not only a chat log. It is a service queue that must expose unanswered questions so that administrators can respond in time. I use these principles to guide the architecture, database schema, state transitions, and implementation details.
1. Motivation and Scope
The rapid growth of electric vehicle charging demand creates a management problem that is partly technical and partly procedural. Drivers need to know which piles are available, whether a reservation is still valid, how long they must wait, and what to do when a pile fails. Administrators need to know which reservations are pending, which faults are unresolved, which piles are unavailable, and which user questions have not been answered. When these concerns are handled in separate tools or informal channels, the electric vehicle charging experience becomes opaque, and station utilization suffers. I therefore designed the system around a unified electric vehicle charging management model that links users, piles, reservations, repair tickets, announcements, and chat messages.
The scope of my implementation covers two roles. The driver role includes registration and login, pile information query and reservation, reservation order lookup, fault reporting and progress tracking, announcement browsing, online customer service, and personal center management. The administrator role includes account and permission management, user management, charging pile management, reservation review and state transition, repair dispatch and closure, announcement management, and customer service aggregation. The system is intended for small and medium-sized electric vehicle charging stations where a lightweight browser-based platform is more appropriate than a heavy industrial control suite.
| Stakeholder | Primary Goal | Key Concern | System Response |
|---|---|---|---|
| Driver | Find and reserve a usable electric vehicle charging pile | Availability, waiting time, reservation certainty | Pile query, reservation validation, order history, status visibility |
| Driver | Resolve failures quickly | Whether a fault report is seen and handled | Fault ticket creation, status tracking, administrator reply |
| Administrator | Maintain pile records and service states | Data consistency and operational control | Pile management, status transitions, maintenance records |
| Administrator | Supervise reservations | Conflicts, no-shows, and capacity limits | Reservation review, conflict checks, state control |
| Administrator | Close the service loop | Unanswered questions and unresolved faults | Repair dispatch, service queue, response tracking |
I use availability as the first operational indicator because it directly reflects whether an electric vehicle charging pile can serve demand. For a single pile, availability can be expressed as the ratio of uptime to total observed time, or through mean time between failures and mean time to repair:
$$A_p = \frac{MTBF_p}{MTBF_p + MTTR_p}$$
For a station with multiple electric vehicle charging piles, the station-level availability is not simply the average of individual values when piles have different capacities. I therefore use a capacity-weighted form:
$$A_{station} = \frac{\sum_{p=1}^{n} C_p A_p}{\sum_{p=1}^{n} C_p}$$
Here, \(C_p\) represents the service capacity of pile \(p\), which can be measured by connector count, rated power, or expected charging sessions per hour. This formula is useful because a high-power electric vehicle charging pile should contribute more to station availability than a low-power pile with the same uptime ratio. The formula also makes the management system more than a record keeper: it gives administrators a quantitative view of service capability.
2. Requirements Analysis
I started the requirements analysis by separating the driver journey from the administrator workflow. The driver journey follows a query, reserve, use, evaluate or repair pattern. The administrator journey follows a maintain, supervise, dispatch, and respond pattern. The two journeys meet at the reservation record, the pile status, the repair ticket, and the customer service conversation. This separation prevented role confusion and helped me define permissions before implementation.
| Requirement Area | Driver Capability | Administrator Capability |
|---|---|---|
| Identity | Register, log in, maintain personal profile | Manage administrator accounts, roles, and user accounts |
| Pile information | Query pile type, status, price, location description, and detail | Create, update, disable, and inspect electric vehicle charging piles |
| Reservation | Reserve a pile for a time window and view historical orders | Review reservations, control states, and handle exceptions |
| Fault handling | Submit fault type, description, and image, then track progress | Receive tickets, assign responsibility, update status, and reply |
| Announcement | Browse platform notices and operational information | Publish, update, and remove announcements |
| Customer service | Ask questions and view replies | See unanswered questions and respond in a service queue |
| Personal center | View account balance and usage records | Inspect user activity and account state |
The non-functional requirements are equally important for an electric vehicle charging management system because operational delays directly affect driver trust. I specified response time, consistency, auditability, security, and scalability as first-class requirements. A reservation conflict must be rejected before it is written, not discovered later by a user. A fault report must change pile status so that new electric vehicle charging reservations do not target a failed unit. A customer service question must remain visible until an administrator answers it. These are not cosmetic features; they are the rules that keep the platform operationally credible.
| Quality Attribute | Target | Design Mechanism |
|---|---|---|
| Responsiveness | Common queries return within a short interactive interval | Indexed queries, pagination, lightweight REST responses |
| Consistency | No overlapping active reservations for the same pile capacity | Transactional reservation checks and status constraints |
| Security | Role-based access and token expiration | Login token, role field, endpoint authorization |
| Auditability | Business events remain traceable | Created time, status, user identifiers, administrator replies |
| Maintainability | Clear separation of frontend, service, and data layers | Layered architecture and modular service interfaces |
| Scalability | Support additional piles and stations without redesign | Normalized entities and station-oriented extension points |
I also considered the difference between a reservation and a charging session. A reservation only claims a future time window. A charging session consumes the pile during actual use. If the system treats them as the same thing, then cancelling a reservation becomes indistinguishable from stopping a charge, and no-show handling becomes impossible. I therefore keep reservation orders and pile status as separate but linked concepts. The pile has a current operational status, while the reservation has its own lifecycle. This distinction is essential for a practical electric vehicle charging management platform.
3. System Architecture
I adopted a browser/server architecture with three logical layers: presentation, business service, and data storage. The presentation layer is a Vue application that renders role-specific pages and communicates with the backend through JSON over HTTP. The business service layer is a Spring Boot application that exposes REST endpoints, validates input, enforces role permissions, performs reservation and repair state transitions, and returns structured responses. The data storage layer is MySQL, with normalized tables for users, administrators, piles, reservations, repairs, announcements, chat messages, and dictionary values. This layered arrangement keeps the user interface replaceable and the business rules centralized.
| Layer | Main Responsibility | Implementation Choice | Operational Benefit |
|---|---|---|---|
| Presentation | Render role-specific pages, forms, tables, and status views | Vue single-page interface | Fast interaction and clear separation of driver and administrator views |
| Service | Authenticate requests, validate business rules, coordinate transactions | Spring Boot REST controllers and services | Centralized electric vehicle charging business logic |
| Persistence | Store entities, enforce keys, support indexed queries | MySQL relational schema | Consistency and traceability for reservations, faults, and service records |
| Integration | Exchange JSON requests and responses | HTTP REST with token-based authentication | Simple deployment and testability |
For a request that reaches the backend, I model the service path as a sequence of validation and persistence steps. Let \(q\) be a request and \(S(q)\) be the set of checks it must pass. The request is accepted only when every mandatory check succeeds:
$$Accept(q) = \prod_{c \in S(q)} I_c(q)$$
Here, \(I_c(q)\) is an indicator that equals one when check \(c\) passes and zero otherwise. The checks include token validity, role permission, input completeness, entity existence, and state legality. This formula is simple, but it clarifies why the backend cannot rely on frontend validation alone. The frontend improves user experience, while the backend protects the electric vehicle charging data model.
I also considered response time as a composite of network delay, service processing, and database access:
$$T_{response} = T_{network} + T_{service} + T_{database} + T_{render}$$
For management pages, pagination and indexed queries reduce \(T_{database}\). For reservation validation, the transaction must remain short so that concurrent requests do not hold locks for long periods. For customer service, the query that lists unanswered questions should be indexed by status and time. These implementation choices follow directly from the architecture rather than from isolated page design.
4. Data Model and Database Design
I designed the schema in third normal form and separated stable enumerations from business records. Dictionary values are stored in a dictionary table, while reservation, repair, and chat records remain independent business entities. Foreign keys connect users and piles to reservations and repairs, which allows queries by person, by pile, and by event. This structure supports the electric vehicle charging management requirement that every operational event can be traced to a responsible user and an affected service point.
| Entity | Purpose | Key Fields | Relationship |
|---|---|---|---|
| Driver user | Store driver account and balance information | Username, password, name, phone, email, balance, identity reference | One driver to many reservations and repairs |
| Administrator | Store administrator account and role | Username, password, role | One administrator to many announcements and replies |
| Charging pile | Store pile identity and service attributes | Name, number, type, status, price, detail, picture | One pile to many reservations and repairs |
| Reservation order | Record a time-bounded claim on a pile | Order time, hours, amount, order type, status, user and pile references | Many reservations to one driver and one pile |
| Repair ticket | Record a fault or feedback work item | Title, type, status, content, picture, create time, reply | Many repairs to one driver and one pile |
| Announcement | Publish platform notices | Title, type, content, picture, create time | Administrator-authored information |
| Chat message | Store customer service dialogue | Question, answer, ask time, answer time, status | Driver and administrator conversation |
| Dictionary | Store enumerated values | Code, name, parent code, sort, remark | Shared reference data |
The pile table is central to the electric vehicle charging domain. A pile record contains a unique number, a type, a status, a price, a detail description, and an optional picture. The unique number prevents duplicate physical assets. The status field controls whether the pile can be reserved. The price field supports order amount calculation. The detail field carries operational notes that drivers need before arrival. The picture field helps drivers identify the pile or connector type. I keep these fields on the pile rather than duplicating them in every reservation, because the reservation should reference the current pile record and preserve its own time and amount data.
| Pile Field | Data Type | Constraint | Business Meaning |
|---|---|---|---|
| id | Big integer | Primary key, auto increment | Internal identifier |
| name | Variable string | Not null | Display name of the electric vehicle charging pile |
| number | Variable string | Not null, unique | Physical asset number |
| type | Variable string | Not null | Connector or service type |
| status | Variable string | Not null | Available, reserved, charging, fault, or maintenance |
| price | Decimal | Not null | Unit price for reservation or charging calculation |
| detail | Text | Nullable | Operational description and usage notes |
| picture | Variable string | Nullable | Reference to an uploaded image |
| create_time | Date time | Default current time | Record creation timestamp |
For reservation conflict control, I model each reservation as a half-open time interval. Let reservation \(i\) have start time \(s_i\) and end time \(e_i\). The overlap indicator between reservation \(i\) and reservation \(j\) is:
$$O(i,j) = \begin{cases} 1, & \text{if } s_i \le e_j \text{ and } s_j \le e_i \\ 0, & \text{otherwise} \end{cases}$$
For a given pile \(p\), the active reservation count within a candidate interval \([s,e)\) must not exceed the pile capacity \(C_p\):
$$\sum_{k \in R_p} O(k,[s,e)) \le C_p$$
In the common case where each pile supports one electric vehicle charging session at a time, \(C_p = 1\), and the rule becomes a strict non-overlap constraint. I apply this check inside a transaction so that two concurrent requests cannot both pass validation and then write conflicting reservations. This is one of the most important guarantees in the electric vehicle charging management system because reservation conflicts are visible to drivers and quickly damage trust.
The order amount can be calculated from the reserved duration and the pile price. A simple form is:
$$Amount_i = price_{p(i)} \cdot hours_i$$
If the platform later supports peak and valley pricing, the formula can be generalized to a time-dependent tariff:
$$Amount_i = \int_{s_i}^{e_i} price_{p(i)}(t) \, dt$$
I did not implement a full dynamic tariff engine in the first version, but the data model and service boundary leave room for it. This is consistent with the practical goal of the system: deliver a stable electric vehicle charging management baseline while keeping extension points explicit.
5. Reservation Workflow and Scheduling Logic
I treat a reservation as a state machine rather than a free-form record. A reservation is created in a pending or confirmed state, depending on the administrator review policy. It can be cancelled by the driver before use, marked as expired when the time window passes without use, or completed after service. The administrator can approve, reject, or close reservations when exceptions occur. The state machine prevents invalid transitions such as completing a reservation that was never confirmed.
| State | Entry Condition | Allowed Next State | Operational Meaning |
|---|---|---|---|
| Pending | Driver submits a valid request and review is enabled | Confirmed, Rejected, Cancelled | Waiting for administrator review |
| Confirmed | Review passes or review is not required | In Use, Cancelled, Expired, Completed | Time window is reserved |
| In Use | Driver starts the electric vehicle charging session | Completed, Fault Reported | Pile is occupied by the reservation |
| Completed | Session ends and amount is finalized | None | Reservation is closed |
| Cancelled | Driver or administrator cancels before use | None | Capacity is released |
| Expired | Time window passes without use | None | No-show handling |
| Rejected | Administrator rejects the request | None | Request is closed without capacity claim |
To support fair ordering when multiple drivers compete for limited electric vehicle charging capacity, I define a priority score for pending requests. The score combines user history, urgency, wait time, and pile fit:
$$S_i = w_1 H_i + w_2 U_i + w_3 W_i + w_4 F_i$$
Here, \(H_i\) represents a reliability or history component, \(U_i\) represents urgency, \(W_i\) represents waiting time, and \(F_i\) represents the fit between the requested time and the pile capability. The weights are non-negative and sum to one:
$$\sum_{j=1}^{4} w_j = 1, \quad w_j \ge 0$$
I use this formula as a decision aid rather than an automatic replacement for administrator judgment. In a small station, an administrator may need to prioritize a driver with an urgent need or a reservation that affects a fleet schedule. A transparent score helps explain why one request is handled before another, while leaving room for operational discretion.
I also measure reservation reliability through a simple no-show rate:
$$R_{no-show} = \frac{N_{expired}}{N_{confirmed}}$$
When this rate rises for a driver, the system can flag the account for review, require a stronger confirmation step, or reduce priority in future electric vehicle charging reservations. The goal is not punishment but capacity protection. A reservation that is never used blocks another driver and reduces station efficiency. The management platform should make this behavior visible without adding excessive friction for reliable users.
For capacity planning, I use utilization as a core indicator. Let \(B_p(t)\) be the busy indicator of pile \(p\) at time \(t\). The utilization over an observation window \(T\) is:
$$U_p = \frac{1}{T} \int_{0}^{T} B_p(t) \, dt$$
For a group of piles, the station utilization is:
$$U_{station} = \frac{\sum_{p=1}^{n} C_p U_p}{\sum_{p=1}^{n} C_p}$$
I combine utilization with availability because a pile that is always busy may still be unavailable due to faults. A practical electric vehicle charging management dashboard should present both indicators side by side. High utilization with low availability indicates capacity strain and maintenance backlog. Low utilization with high availability indicates excess capacity or weak demand.
6. Charging Pile Management and Health Assessment
Pile management is the operational core of the administrator interface. I allow administrators to create, update, inspect, and disable electric vehicle charging piles. Each pile has a status that affects reservation behavior. When a pile is marked as fault or maintenance, new reservations are blocked. Existing reservations may need administrator intervention, such as reassignment or cancellation. This is why pile status and reservation status cannot be managed independently.
| Pile Status | Reservation Allowed | Typical Cause | Administrator Action |
|---|---|---|---|
| Available | Yes | Normal operation | Monitor and maintain records |
| Reserved | Conditional | Upcoming confirmed reservation | Review schedule and capacity |
| Charging | No for the same capacity unit | Active electric vehicle charging session | Monitor completion and amount |
| Fault | No | Reported hardware or connector failure | Dispatch repair and update status |
| Maintenance | No | Scheduled inspection or cleaning | Complete maintenance and restore availability |
| Disabled | No | Administrative or safety decision | Keep record for audit and planning |
I calculate a health score for each pile to support maintenance planning. The score combines availability, recent fault frequency, repair duration, and service quality feedback:
$$H_p = \alpha A_p + \beta \left(1 – \frac{F_p}{F_{max}}\right) + \gamma \left(1 – \frac{D_p}{D_{max}}\right) + \delta Q_p$$
The weights satisfy:
$$\alpha + \beta + \gamma + \delta = 1, \quad \alpha,\beta,\gamma,\delta \ge 0$$
Here, \(F_p\) is the fault count in a recent period, \(D_p\) is the average repair duration, and \(Q_p\) is a normalized service quality indicator. I clamp the score to the interval from zero to one. A low health score does not automatically disable a pile, but it gives the administrator a reason to inspect the asset before a failure affects electric vehicle charging reservations.
Reliability can also be modeled with an exponential survival function when failure events are approximately memoryless over a short observation period:
$$R_p(t) = e^{-\lambda_p t}$$
Here, \(\lambda_p\) is the failure rate of the pile. The expected number of failures in an interval \(T\) is approximately \(\lambda_p T\). I use this model only as a planning aid, because real charging hardware has wear-in and wear-out phases that a single exponential parameter cannot fully capture. The value of the model is that it makes the maintenance conversation quantitative. Instead of saying that a pile seems unreliable, the administrator can compare observed fault counts and repair durations against the expected pattern.
7. Fault Reporting and Repair Closure
Fault reporting is where the driver side and administrator side meet most directly. A driver submits a repair ticket with a fault type, a title, a description, and an optional image. The system records the driver, the pile, the creation time, and the initial status. When the ticket is accepted, I update the pile status to fault so that new electric vehicle charging reservations do not target a failed unit. This automatic status change is a key business rule. Without it, the platform would collect fault reports while still advertising the pile as available.
| Repair Stage | Status | Responsible Role | System Effect |
|---|---|---|---|
| Report submitted | Pending | Driver | Ticket created; pile may be marked fault after review |
| Ticket accepted | Accepted | Administrator | Fault confirmed; reservation impact assessed |
| Work assigned | Dispatched | Administrator | Responsibility and expected response recorded |
| Repair in progress | Processing | Administrator or technician | Pile remains unavailable for electric vehicle charging |
| Repair completed | Resolved | Administrator | Pile status restored after verification |
| Driver confirmation | Closed | Driver or administrator | Ticket closed with reply and audit trail |
I prioritize repair tickets with a scoring model so that safety-related and high-impact faults are handled first. A simple priority function is:
$$P_f = a_1 I_{safety} + a_2 \frac{N_{affected}}{N_{total}} + a_3 \frac{1}{T_{wait}} + a_4 I_{repeated}$$
Here, \(I_{safety}\) indicates a safety risk, \(N_{affected}\) is the number of drivers or reservations affected, \(T_{wait}\) is the time since submission, and \(I_{repeated}\) indicates a repeated fault on the same electric vehicle charging pile. The coefficients are positive and can be tuned by station policy. The formula is intentionally interpretable. Administrators should be able to understand why a ticket is ranked highly, especially when they must explain service priorities to drivers.
Service level compliance is measured as the proportion of tickets resolved within the target time:
$$SLA = \frac{1}{N} \sum_{i=1}^{N} I(t_i \le T_{SLA})$$
I also track mean time to first response and mean time to closure:
$$MTTR_{service} = \frac{1}{N} \sum_{i=1}^{N} (t_{close,i} – t_{submit,i})$$
These metrics matter for electric vehicle charging operations because a fault ticket is not only a maintenance record. It is a promise to drivers that the station is being managed. If tickets remain pending for a long time while the pile stays visible, the platform loses credibility. I therefore give administrators a queue view that sorts by status, priority, age, and pile identity.
8. Announcements and Customer Service
Announcements provide one-to-many communication. I allow administrators to publish notices about maintenance windows, price changes, station rules, and service interruptions. Announcements are especially important for electric vehicle charging because a planned maintenance event can invalidate many reservations. A visible announcement reduces repeated questions and improves driver planning. The announcement record includes a title, type, content, optional image, and creation time. The driver interface displays announcements in a readable list and detail view.
Customer service provides one-to-one communication. I store each question and answer with timestamps and a status field. The administrator interface aggregates unanswered questions so that the service queue is visible. This is a practical requirement in electric vehicle charging management: drivers often ask about connector compatibility, payment, reservation changes, or fault progress. If these questions are buried in a chronological chat log, response time increases. The unanswered aggregation view turns the chat data into an operational queue.
| Service View | Filter or Sort | Purpose |
|---|---|---|
| All questions | Created time descending | Review the full service history |
| Unanswered questions | Status equals pending | Prioritize drivers waiting for a reply |
| Recent answers | Answer time descending | Check follow-up and consistency |
| Driver-specific view | Driver identifier | Understand context before responding |
I measure service responsiveness with average response time and unanswered backlog:
$$T_{reply} = \frac{1}{N} \sum_{i=1}^{N} (t_{answer,i} – t_{ask,i})$$
$$B_{unanswered} = \sum_{i=1}^{N} I(status_i = pending)$$
These two metrics complement each other. A low average response time can still hide a growing backlog if new questions arrive faster than answers. A small backlog can still contain an old unanswered question that damages trust. The administrator dashboard should show both the average and the oldest pending item.
9. Authentication, Authorization, and API Implementation
I implemented authentication with a login endpoint that checks the administrator or driver account and password, then generates a token with an expiration time. The token is returned to the frontend with role and user identifier information. Subsequent requests carry the token, and the backend uses it to identify the caller and enforce role permissions. I do not rely on the frontend to hide administrator pages as a security control. The backend rejects unauthorized operations even if a malicious caller constructs a request manually.
| API Area | Representative Endpoint | Role | Main Check |
|---|---|---|---|
| Login | POST /login | Driver, administrator | Username and password match |
| Pile query | GET /piles | Driver, administrator | Token validity and pagination |
| Pile maintenance | POST /piles | Administrator | Role and required field validation |
| Reservation creation | POST /reservations | Driver | Time validity and capacity conflict check |
| Reservation review | PUT /reservations/status | Administrator | Legal state transition |
| Repair submission | POST /repairs | Driver | Pile existence and content validation |
| Repair update | PUT /repairs/status | Administrator | State transition and reply requirement |
| Announcement publishing | POST /announcements | Administrator | Role and content validation |
| Customer service | POST /chat | Driver, administrator | Participant identity and message ownership |
Token validity is bounded by an expiration time:
$$T_{exp} = t_0 + \Delta T$$
When the current time exceeds \(T_{exp}\), the token is rejected and the user must authenticate again. I also apply basic rate limiting to authentication attempts. A simple token bucket model is:
$$b(t) = \min\left(B_{max}, b(t-\Delta t) + r \Delta t\right)$$
Here, \(B_{max}\) is the bucket capacity and \(r\) is the refill rate. A login attempt consumes one token. If the bucket is empty, the request is rejected or delayed. This is not a complete security program, but it reduces trivial brute-force attempts and makes the electric vehicle charging management service more robust.
I structure API responses with a consistent envelope that contains a status code, a message, and optional data. This makes frontend error handling predictable. For example, a reservation conflict returns a business error rather than a generic server error. A permission failure returns an authorization error. A validation failure identifies the missing or invalid field. Consistency in response structure reduces the chance that the frontend misinterprets a failure as a success.
10. Security, Privacy, and Data Integrity
Security in an electric vehicle charging management system must cover account access, personal data, reservation integrity, and administrative actions. I use role-based access control, token expiration, password verification, and server-side validation. Personal data such as phone, email, and identity reference should be exposed only to authorized administrators and only for legitimate operational purposes. The driver interface should not reveal another driver’s information. The administrator interface should show only the fields needed for service and account management.
| Security Control | Threat Addressed | Implementation Note |
|---|---|---|
| Token authentication | Unauthorized API access | Token checked on protected endpoints |
| Role authorization | Privilege escalation | Administrator endpoints reject driver tokens |
| Server-side validation | Malformed or forged requests | Required fields and state rules checked in service layer |
| Password protection | Credential disclosure | Password values are not returned in query results |
| Transactional reservation check | Double booking | Conflict check and insert occur in one transaction |
| Audit timestamps | Disputed actions | Creation, update, and response times are recorded |
| Least privilege | Unnecessary data exposure | Driver views exclude administrative fields |
Data integrity is enforced at three levels. The database enforces primary keys, unique pile numbers, and foreign key relationships. The service layer enforces business rules such as non-overlapping reservations and legal state transitions. The frontend enforces immediate form validation for user experience. No single level is sufficient. The database cannot know whether a repair ticket should change a pile status, the service layer cannot prevent a direct database edit, and the frontend cannot protect against crafted requests. I therefore treat integrity as a shared responsibility across layers.
For reservation integrity, I use the overlap condition and capacity constraint described earlier. For repair integrity, I require that a resolved ticket include a reply or resolution note. For announcement integrity, I require a title and content. For customer service integrity, I require that a reply belongs to an existing question and that only the intended driver or an administrator can participate. These rules are simple, but they prevent many low-quality records that would otherwise complicate reporting and service review.
11. Testing and Evaluation
I evaluated the system through functional scenarios, state transition tests, concurrency checks, and basic performance measurements. The functional scenarios covered driver registration and login, pile query, reservation creation, reservation cancellation, fault submission, administrator reply, announcement publishing, and customer service response. The state transition tests checked that invalid transitions were rejected. The concurrency checks focused on reservation conflicts, because that is the most visible correctness requirement in electric vehicle charging management.
| Test Area | Scenario | Expected Result | Observed Behavior |
|---|---|---|---|
| Authentication | Correct driver credentials | Token and role returned | Access granted to driver pages |
| Authentication | Incorrect password | Login rejected | Generic error returned |
| Authorization | Driver calls administrator endpoint | Access denied | Request rejected by role check |
| Pile query | Filter by status and type | Matching piles returned | Pagination and filtering worked |
| Reservation | Non-overlapping time window | Reservation accepted | Order created and capacity claimed |
| Reservation | Overlapping time window on a single-capacity pile | Reservation rejected | Conflict error returned |
| Reservation | Two concurrent requests for the same slot | Only one succeeds | Transaction prevented double booking |
| Repair | Driver submits fault with image | Ticket created | Pile marked fault after acceptance |
| Repair | Administrator resolves ticket | Status updated and reply stored | Pile restored after verification |
| Announcement | Administrator publishes notice | Driver sees announcement | List and detail views updated |
| Customer service | Driver asks question | Question enters pending queue | Administrator sees unanswered item |
| Customer service | Administrator answers question | Status changes to answered | Reply visible to driver |
For performance, I measured common page queries and write operations under a small dataset. The exact values depend on hardware and database configuration, so I present the evaluation in terms of relative behavior and design targets rather than absolute claims. The important result is that indexed queries and pagination keep the administrator views responsive, while short transactions keep reservation checks predictable. I also verified that the unanswered customer service query uses a status filter and returns quickly when the number of pending items is small.
| Metric | Measurement Approach | Design Target | Interpretation |
|---|---|---|---|
| Pile list query | Repeated request with pagination | Interactive response | Indexed status and name fields reduce scan cost |
| Reservation creation | Conflict check plus insert | Short transaction | Lock duration is limited to validation and write |
| Repair queue | Filter by status and age | Fast administrator view | Status index supports pending work discovery |
| Unanswered service queue | Filter by pending status | Immediate visibility | Aggregation view improves response discipline |
| Login | Credential check and token creation | Controlled access | Rate limiting reduces repeated failures |
I also evaluated reservation conflict probability as a planning indicator. If requests arrive independently and the pile has \(C_p\) capacity units, a rough conflict indicator for a candidate window can be expressed as the probability that the number of overlapping active reservations exceeds capacity. Under a simplified independent model, let \(X\) be the number of overlapping reservations. The conflict probability is:
$$P_{conflict} = P(X \ge C_p)$$
For a single-capacity pile, this reduces to the probability that at least one other active reservation overlaps the candidate interval. In practice, arrivals are not independent, and peak periods create correlation. I therefore use this formula only as a conceptual planning tool. The operational safeguard remains the transactional overlap check, not the probability model.
For service quality, I combine repair closure and customer service response into a composite operational score:
$$Q_{ops} = \lambda_1 SLA_{repair} + \lambda_2 \left(1 – \frac{B_{unanswered}}{B_{max}}\right) + \lambda_3 A_{station} + \lambda_4 \left(1 – R_{no-show}\right)$$
The weights are chosen by station policy and should sum to one. This score is useful for management review because it prevents optimization of one dimension at the expense of another. A station with high availability but poor customer service is not a well-run electric vehicle charging service. A station with fast replies but frequent reservation conflicts is also not healthy.
12. Deployment, Operations, and Scalability
I designed the deployment for a small or medium electric vehicle charging station: a Spring Boot application, a MySQL database, and a static Vue build served through a web server or integrated deployment. The application can run behind a reverse proxy that terminates TLS and forwards requests. Database backups should run on a schedule, and administrator actions should be logged. For a single station, this deployment is simple and sufficient. For multiple stations, the same schema can be extended with a station identifier and station-level administrator scopes.
| Operational Concern | Current Approach | Scaling Path |
|---|---|---|
| Traffic growth | Single application instance | Horizontal replicas behind a load balancer |
| Read-heavy pile queries | Indexed relational queries | Read replica or cache for public pile lists |
| Reservation concurrency | Transactional conflict check | Database row locks or distributed lock for multi-instance writes |
| File uploads | Local or simple object storage reference | Object storage with signed access URLs |
| Multi-station operation | Single station scope | Station identifier and scoped administrator roles |
| Monitoring | Application logs and basic metrics | Centralized logging, alerting, and dashboards |
For multi-instance deployment, the reservation check must remain safe when requests reach different application instances. A database transaction with a suitable isolation level and row-level locking can protect the critical section. Alternatively, a distributed lock can be used for the pile and time window. The precise choice depends on expected concurrency and database behavior. I prefer to keep the critical section small and to avoid long-running locks. The electric vehicle charging reservation path should validate the interval, insert the order, and commit quickly.
I use capacity planning to estimate the number of service points needed for a target load. If the arrival rate of electric vehicle charging requests is \(\lambda\), the service rate per pile is \(\mu\), and there are \(c\) piles, a simple utilization measure is:
$$\rho = \frac{\lambda}{c \mu}$$
For stable operation, \(\rho\) should remain below one, with a practical margin for peak demand and maintenance. The expected queue length in a simplified queueing model is:
$$L_q = \frac{\rho^{c+1}}{c \cdot c! \cdot (1-\rho)^2} P_0$$
This formula is for an M/M/c queue and assumes Poisson arrivals and exponential service times. Real electric vehicle charging sessions are not perfectly exponential, because charging duration depends on battery state, connector power, and driver behavior. Nevertheless, the model gives a useful first-order view of how capacity and utilization affect waiting. I use it as a planning aid, not as a substitute for measured data.
13. Discussion and Limitations
The system meets the core needs of a small or medium electric vehicle charging management platform. It provides role-based access, pile information maintenance, reservation conflict control, repair closure, announcements, and customer service aggregation. The most important contribution is the integration of these functions through shared states and identifiers. A fault report changes pile availability. A reservation claims capacity for a time window. A customer service question remains visible until answered. These connections make the platform operationally meaningful.
The current implementation has limitations. It does not directly integrate with charging pile hardware protocols, so pile status is maintained through administrator action rather than real-time telemetry. It does not implement a full dynamic pricing engine, although the data model can support time-dependent tariffs. It does not include advanced demand forecasting, route planning, or mobile native applications. It also does not provide a complete financial settlement module. These limitations are acceptable for the first version because the goal is to establish a reliable electric vehicle charging management foundation before adding hardware integration and intelligent optimization.
| Limitation | Impact | Mitigation |
|---|---|---|
| No direct hardware telemetry | Pile status may lag behind physical reality | Administrator updates and future protocol adapter |
| Static or simple pricing | Peak demand is not actively shifted | Extend order calculation to time-dependent tariffs |
| Limited forecasting | Capacity planning is mostly descriptive | Add historical demand models and anomaly detection |
| Single-station assumption | Multi-site operation requires scoping | Add station entity and scoped roles |
| Basic service analytics | Managers have limited insight into trends | Add dashboards for utilization, faults, and response time |
14. Future Work
I plan to extend the platform in four directions. First, I will add a hardware integration adapter so that electric vehicle charging pile status can be updated from device telemetry. The adapter should translate device events into the same state transitions used by the administrator interface, so the business logic remains consistent. Second, I will add time-dependent pricing and peak-valley tariffs. The order amount formula can then use the integral form described earlier, with price segments defined by the station. Third, I will add demand forecasting and fault prediction. A simple exponential smoothing baseline can be expressed as:
$$\hat{y}_{t+1} = \alpha y_t + (1-\alpha)\hat{y}_t$$
Here, \(y_t\) is the observed demand or fault count at time \(t\), and \(\hat{y}_{t+1}\) is the forecast for the next period. More advanced models can include calendar effects, weather, and station-level features. Fourth, I will add multi-station support with station identifiers, scoped administrator roles, and cross-station reporting. This extension is natural because the current entities already separate users, piles, reservations, and repairs.
For optimization, a future version can allocate reservations across piles to minimize waiting and maximize utilization. A simplified assignment model is:
$$\min \sum_{i=1}^{m} \sum_{j=1}^{n} c_{ij} x_{ij}$$
Subject to:
$$\sum_{j=1}^{n} x_{ij} = 1, \quad i = 1,\ldots,m$$
$$\sum_{i=1}^{m} x_{ij} \le C_j, \quad j = 1,\ldots,n$$
$$x_{ij} \in \{0,1\}$$
Here, \(x_{ij}\) indicates whether request \(i\) is assigned to pile \(j\), and \(c_{ij}\) represents a cost such as waiting time, walking distance, or price difference. This model can improve electric vehicle charging reservation decisions when multiple piles and multiple stations are available. I would keep the optimization as a recommendation layer rather than an automatic commitment layer until the data quality is sufficient.
15. Conclusion
I designed and implemented an electric vehicle charging management system that combines driver-facing reservation and service functions with administrator-facing maintenance, supervision, and response functions. The system uses Spring Boot, Vue, and MySQL in a layered browser/server architecture. It treats electric vehicle charging piles, reservations, repairs, announcements, and customer service conversations as connected operational records rather than isolated data entries. Reservation conflicts are controlled through time-interval overlap checks and transactional writes. Fault reports can change pile status and drive repair closure. Customer service questions remain visible until answered. These design choices make the platform useful for daily station operation.
The evaluation shows that the system supports the main electric vehicle charging workflows with stable behavior, clear role boundaries, and traceable states. The formulas and tables in this article summarize the availability, utilization, conflict, priority, service, and capacity-planning reasoning behind the implementation. The next steps are hardware integration, dynamic pricing, forecasting, multi-station support, and optimization. I view the current system as a solid electric vehicle charging management baseline that can evolve toward a more intelligent and integrated charging service platform.