The rapid global transition towards new energy vehicles has placed unprecedented demands on the supporting supply chain and manufacturing infrastructure. At the heart of the charging ecosystem for an electric vehicle car lies a critical component: the Charging Communication Controller. This compact module acts as the essential communication bridge between the electric vehicle car and the charging station, managing the complex exchange of signals and data packets that enable safe and efficient energy transfer. Its production is characterized by high mix, low-to-medium volume batches with diverse software and hardware configurations. Traditional, paper-based manufacturing processes for such a sophisticated component often lead to significant challenges, including chaotic process management, inconsistencies between the final product and its technical specifications, and formidable difficulties in tracing faults back to their root cause in the production line. These issues pose direct risks to the reliability and safety of the electric vehicle car charging experience.
To address these critical challenges, the adoption of a digital production management system is not merely an upgrade but a necessity. A Manufacturing Execution System (MES) provides the foundational layer for smart manufacturing, enabling precise control over batch processes, eliminating human procedural errors, ensuring state consistency across all units in a batch, and establishing robust mechanisms for product traceability. This article details the design, architectural decisions, and practical implementation of a bespoke MES developed specifically for the production of electric vehicle car charging communication controllers. The system is engineered to seamlessly integrate with manual assembly and testing stations, automate data collection and process guidance, and enforce strict configuration management from the initial PCB test to final packaging.
1. System Architecture Design
The proposed MES is a composite system, architected as a cohesive unit comprising a central B/S (Browser/Server) platform and distributed client applications running on test station PCs. This hybrid architecture balances centralized management with decentralized execution, which is crucial for a flexible production line for electric vehicle car components.
The MES Platform System resides on a dedicated server and follows a layered design pattern for maintainability and scalability:
- Presentation Layer: Built using modern web technologies (HTML5, Vue.js), this layer provides the human-machine interface for production managers and supervisors. Key functional pages include:
- Technical Work Order (TWO) Management
- PCB Tracking and Management
- Finished Product Management
- Inventory/Shipping Management
- Software/Firmware Version Management
- System Administration and User Roles
- Business Logic Layer: This core layer encapsulates the application’s business rules and workflows. It processes requests from the presentation layer, executes complex logic (e.g., batch state validation, process routing), and interacts with the persistence layer. Key modules manage the lifecycle of a Technical Work Order, coordinate PCB testing data flow, handle product serialization, and control firmware distribution.
- Persistence Layer: This layer abstracts all data access operations. It implements the interfaces defined by the business logic layer to perform CRUD (Create, Read, Update, Delete) operations on the relational database. It manages entities such as TWO data, product records, PCB test logs, firmware metadata, and user permissions.
The Test Station Client Software is installed on industrial PCs (IPCs) at each key production station: Initial Test, Re-test, Programming, and Final Verification. This client software serves as the digital gateway for production operators. Its primary functions are:
- Providing a streamlined GUI for the operator to initiate station-specific tasks.
- Communicating via CAN bus with the physical test fixture to send commands and retrieve test results from the unit under test (UUT).
- Interacting with the central MES database over a secured production Local Area Network (LAN) to fetch configuration data, upload test results, and download the correct firmware files for programming.
This architecture ensures that all critical production data converges into a single source of truth (the database), while control and interaction remain intuitive and localized at the point of work, a vital aspect for assembling sensitive components for the electric vehicle car industry.
2. Database Schema and Core Data Model
A robust and well-structured data model is the backbone of an effective MES. For the production of electric vehicle car charging controllers, the database must track the unique identity and complete history of each component. The core entities and their relationships are designed to enforce data integrity and support full traceability.
The Media Access Control (MAC) address, a globally unique identifier burned into the controller’s network interface, serves as the primary key for all entities representing a physical communication module, whether as a bare PCB or a finished product. This guarantees uniqueness and provides a consistent anchor for tracking.
The Technical Work Order (TWO) is the digital blueprint for a production batch. It defines the immutable technical state for all units in that batch, including target firmware version, hardware revision, customer specifications, quantity, and allocated serial/MAC number ranges. It is the master document against which all production steps are validated.
The Firmware entity represents a specific software version destined to be programmed into the Flash memory of the controller for an electric vehicle car. Its attributes include version number, release date, compatible hardware revisions, and a critical file-path mapping to the actual binary file stored on the MES server’s secured filesystem. This enables precise version control and automated distribution.
The PCB entity tracks the core printed circuit board post-SMT (Surface-Mount Technology). It is uniquely identified by its laser-etched serial number and MAC address. Its ‘status’ field is a finite-state machine value (e.g., Awaiting_Initial_Test, Tested, Aged, Programmed) that dictates the next permissible production operation.
Test_Result entities store detailed records for each test case executed on a PCB. A single PCB undergoes multiple tests, establishing a one-to-many relationship. This granular data is essential for quality analysis and failure diagnosis.
The Product entity is created upon successful programming and casing of a PCB. It inherits the PCB’s identifiers and adds the final product serial number, creating a complete genealogy. User and Role entities manage authentication and authorization through a many-to-many relationship, allowing flexible assignment of permissions (e.g., Operator, Technician, Supervisor) to personnel on the electric vehicle car component line.
| Entity Name | Primary Key | Critical Fields | Description/Purpose |
|---|---|---|---|
| Technical_Work_Order | TWO_ID | Batch_Number, Firmware_Version_Ref, HW_Revision, Qty, Serial_Start, Serial_End | Defines the technical configuration and scope for a production batch. |
| Firmware | Firmware_ID | Version, Release_Date, HW_Compatibility, Binary_File_Path | Manages all releasable software versions for the electric vehicle car controller. |
| PCB | MAC_Address | PCB_Serial, Status, TWO_Ref, Creation_Timestamp | Tracks each individual circuit board through the production process. |
| Test_Result | Result_ID | MAC_Address_Ref, Test_Name, Pass/Fail, Value, Timestamp | Stores granular results for every test performed on a PCB. |
| Product | Product_Serial | MAC_Address_Ref, PCB_Serial_Ref, TWO_Ref, Final_Test_Status | Represents the final, assembled unit ready for shipment. |
| User | User_ID | Username, Hashed_Password, Name | Authenticates personnel accessing the system. |
| Role | Role_ID | Role_Name, Permissions_Bitmask | Defines permission sets (e.g., data entry, approval, admin). |
3. Production Process Flow and MES Integration
The production process for the electric vehicle car charging controller, after SMT assembly, is decomposed into six sequential stages. The MES actively controls and documents four of these, while the remaining two (aging and packaging) are monitored as logistical milestones.
- Preparation & TWO Creation: The process is initiated by a production planner or engineer who creates a Digital Technical Work Order in the MES platform, defining all batch parameters.
- Initial Test:
- The operator at the Initial Test station scans a QR code on the physical TWO document.
- The Test Station Client software validates the TWO and guides the operator to connect the PCB.
- The software commands the test fixture via CAN bus. The fixture powers the PCB, and the board’s built-in self-test routines execute.
- Test results (Pass/Fail for each sub-test) are captured, associated with the PCB’s MAC address, and uploaded to the MES database. The PCB’s status transitions to “Initially Tested.”
- Passing PCBs are grouped for Aging; failures are quarantined.
- Aging (MES-Logged Event): Batches of PCBs undergo a stress test in an environmental chamber. The batch transfer to and from aging is logged in the MES, providing temporal context but without direct instrument control.
- Re-test: Identical to the Initial Test but performed post-aging to catch early-life failures. Results are logged, updating the PCB’s history. Status becomes “Re-tested.”
- Programming (Burn-in): This is a critical step where the controller’s firmware is permanently installed.
- The operator simply scans the product serial number barcode label intended for the final unit.
- The client software queries the MES to find the active TWO governing that serial number range.
- It then fetches the corresponding firmware binary file from the server and automatically initiates the programming sequence via the test fixture.
- Upon success, the system creates the final Product record, binding the PCB’s MAC/Serial to the product’s serial number. PCB status updates to “Programmed.”
- Final Verification: After the programmed PCB is installed in its casing, a final check is performed.
- The operator scans the three identifiers: PCB serial (on board), MAC address (on board), and Product Serial (on case).
- The client software retrieves the product record from the MES and performs an automatic cross-check for consistency.
- A verification log is saved. Status becomes “Verified_Ready_for_Packaging.”
- Packaging & Shipping (MES-Logged Event): Final units are packed, and the shipping transaction is recorded in the MES, completing the batch lifecycle.
| Process Step | MES Control Level | Key MES Action | Data Recorded / State Change |
|---|---|---|---|
| 1. TWO Creation | Full | Digital TWO creation and QR generation. | Batch configuration defined in DB. |
| 2. Initial Test | Full | Guides test, collects results. | PCB test log; Status -> ‘Initially_Tested’. |
| 3. Aging | Event Logging | Logs batch in/out times. | Adds event to PCB/batch history. |
| 4. Re-test | Full | Guides test, collects results. | PCB re-test log; Status -> ‘Re-tested’. |
| 5. Programming | Full | Fetches correct firmware, executes burn-in. | Creates Product record; Status -> ‘Programmed’. |
| 6. Final Verification | Full | Performs 3-way label consistency check. | Verification log; Status -> ‘Verified’. |
| 7. Packaging | Event Logging | Records final shipment data. | Product status -> ‘Shipped’; closes batch. |
4. Poka-Yoke (Error-Proofing) Mechanisms and Automated Logic
A primary objective of this MES is to engineer out the possibility of human error, especially critical when manufacturing a safety-adjacent component for an electric vehicle car. Two cornerstone poka-yoke mechanisms were implemented.
4.1 Technical Summary QR Code for TWO Creation
Manually entering the multi-faceted technical configuration of a batch into the MES is prone to errors. To eliminate this, a pre-production serialization and encoding step is introduced.
A standalone configuration tool is used by engineering to define the batch parameters: Batch Number (B), Order Number (O), Customer (C), Model (M), Quantity (Q), Bootloader Version (vboot), Hardware Revision (vhw). This structured data is serialized into a JSON string, forming a Technical State Summary (TSS). This process can be formally represented as:
$$TSS = S(B, O, C, M, Q, v_{boot}, v_{hw})$$
Where \( S \) is the serialization function (e.g., to JSON). This TSS string is then encoded into a QR code, which is printed on the official paper TWO. The production manager only needs to scan this QR code at the MES terminal. The system decodes the JSON and populates the TWO form automatically and accurately, ensuring the digital instruction matches the engineering intent perfectly for the electric vehicle car controller batch.
4.2 Autonomous Firmware Selection and Programming
The programming station presents a high risk: selecting an incorrect firmware version for a given hardware revision can render the entire batch of electric vehicle car controllers non-functional. Our MES automates this decision entirely.
The logic is based on the pre-defined serial number ranges within each active TWO. When an operator scans a product serial number label (PSN), the client software performs a deterministic lookup. It retrieves the set of all active TWOs and their corresponding serial number intervals \([SN_{start}, SN_{end}]\). It finds the unique TWO, T, such that:
$$PSN \in [SN_{start}(T), SN_{end}(T)]$$
Once T is identified, the associated firmware version FT is retrieved. The client software checks a local cache for FT. If absent, it downloads the binary from the MES server via HTTP. The programming process then commences automatically. This logic ensures a one-to-one, unambiguous mapping between a physical unit’s serial number and its destined firmware, a critical requirement for configuration management in electric vehicle car component manufacturing.
The state transition for a PCB/Product during this key phase can be modeled. Let \( State(P) \) represent the state of product entity P. The programming and verification steps enforce:
$$
\begin{aligned}
&\text{If } PSN \text{ is scanned and } \exists T: PSN \in [SN_{start}(T), SN_{end}(T)] \\
&\quad \text{Then } F_T \text{ is fetched and programmed.} \\
&\quad \text{Then } State(P) \leftarrow \text{“Programmed”} \\
&\quad \text{Then after casing, if } Verify(PSN, MAC_{PCB}, Serial_{PCB}) = True \\
&\quad \quad \text{Then } State(P) \leftarrow \text{“Verified”}
\end{aligned}
$$
Where the \( Verify() \) function checks the triple-label consistency against the Product record created during programming.
| Mechanism | Process Step | Potential Error Mitigated | MES Solution |
|---|---|---|---|
| TWO QR Code Scan | Batch Setup / TWO Creation | Manual data entry mistakes for batch configuration. | Automated data import via encoded QR code. |
| Autonomous Firmware Mapping | Programming / Burn-in | Selecting wrong firmware version for hardware. | Firmware is auto-selected based on serial number lookup in active TWO. |
| Triple-Label Verification | Final Verification | Mismatch between PCB, MAC, and final product label. | Automated scan and cross-reference with MES product record. |
| State Machine Enforcement | All Steps | Performing operations out of sequence (e.g., programming before testing). | The system checks PCB ‘Status’ field before allowing any operation. |
5. Physical Deployment and System Benefits
The system was deployed on a dedicated production line. A local area network was established using a central switch, connecting the MES server, database server, and all the industrial PCs at the test and programming stations. Each station was equipped with a barcode/QR scanner and a custom test fixture interfacing with the IPC via USB-CAN adapters.
The implementation of this targeted MES for electric vehicle car charging controller production yielded significant, measurable benefits that directly address the shortcomings of the prior analog process:
- Elimination of Batch Configuration Errors: The QR-code-based TWO entry reduced batch setup errors to zero, ensuring every unit in a lot was built to the exact same specification.
- Guaranteed Software-Hardware Consistency: The automated firmware programming logic completely prevented the shipment of units with incorrect software, a critical quality metric for the functionality of the electric vehicle car charger interface.
- Complete Digital Traceability: Every unit can be traced from final product serial number back through its test history, programming event, and to its specific PCB and component batch. This is invaluable for quality audits and failure analysis.
- Process Standardization and Enforcement: The MES acts as a digital work instruction, guiding operators step-by-step and preventing procedural deviations.
- Real-Time Production Visibility: Supervisors gain a live dashboard view of Work-In-Progress (WIP), station yield, and batch completion status, enabling proactive management.
| Aspect | Previous State (Manual) | New State (MES-Integrated) | Impact |
|---|---|---|---|
| Configuration Accuracy | Reliant on manual transcription; prone to errors. | Automated via QR code; 100% accurate data transfer. | Eliminates batch-wide build errors. |
| Firmware Compliance | Manual file selection by operator; high risk. | Fully automated selection based on serial number. | Prevents costly rework of mis-programmed units. |
| Traceability Depth | Paper logs; difficult and time-consuming to search. | Full digital genealogy in a query-able database. | Reduces root-cause analysis time from hours to minutes. |
| Process Adherence | Reliant on operator training and memory. | Enforced by system-controlled state machine. | Ensures consistent, repeatable production quality. |
| Data Accessibility | Data siloed at individual stations on paper. | Centralized, real-time data accessible to authorized roles. | Enables data-driven decision making and OEE tracking. |
6. Conclusion
The design and practical implementation of a dedicated Manufacturing Execution System for electric vehicle car charging communication controllers demonstrate a potent solution to the challenges of modern, high-mix, configuration-sensitive electronic manufacturing. By integrating a central B/S management platform with intelligent, networked client applications at each production station, the system achieves a seamless fusion of digital control and physical assembly. The introduction of advanced poka-yoke mechanisms—specifically the Technical Summary QR code and the autonomous firmware programming logic—has fundamentally eliminated key sources of human error, ensuring batch-level consistency and integrity that is paramount for components in the electric vehicle car ecosystem.
This MES goes beyond simple data logging; it actively governs the production process, enforces workflow rules, and maintains a complete digital thread for each unit from bare PCB to shippable product. The resulting benefits—flawless configuration management, robust traceability, enforced process adherence, and real-time operational visibility—translate directly into higher product quality, reduced operational risk, and lower total cost of non-conformance. As the demand for electric vehicle cars and their supporting infrastructure continues to accelerate, such targeted, intelligent manufacturing systems will become increasingly critical for suppliers aiming to achieve excellence in reliability, efficiency, and scalability.