Simulation verification system of electric vehicle V2G direct current charging based on MATLAB simulink

Abstract

The application discloses a kind of electric vehicle V2G direct current charging simulation verification system based on MATLAB Simulink, and V2G protocol stack module library is encapsulated as standard function module by Simulink environment;EVCC charging control logic model includes charging process state machine, input parameter processing, sub-service processing, output parameter processing and V2G information transceiver module;Fault management module comprehensively judges charging process state, S2 switch state, EVCC internal error and BMS fault signal, and outputs fault flag;Simulation verification unit supports signal observation and fault injection function;Code generation unit generates embedded C code for the model that passes verification.This application can complete V2G function verification and debugging under pure simulation environment, significantly reduce development difficulty and cost, shorten development cycle, and ensure that simulation result and actual product behavior are consistent.

Description

Technical Field

[0001] This invention belongs to the field of computer simulation technology, specifically relating to a V2G DC charging simulation and verification system for electric vehicles based on MATLAB Simulink. Background Technology

[0002] With the booming development of the global new energy vehicle industry, the communication needs between electric vehicles and charging infrastructure have evolved from simple state synchronization to complex smart grid interaction scenarios. V2G technology, as a key technology for realizing bidirectional energy interaction between electric vehicles and the power grid, focuses on achieving a safe and reliable connection between vehicles and charging facilities through standardized communication protocols. V2G DC charging involves multiple layers of protocol specifications, including ISO 15118 and DIN SPEC 70121, covering everything from physical layer power line communication to application layer charging session management. This requires the controller to simultaneously handle PLC physical layer communication, the TCP / IP protocol stack, and the complex V2G application layer protocols.

[0003] The complexity of the V2G protocol stack directly leads to severe constraints on development efficiency. Engineers typically need to write a large amount of C code by hand to implement protocol stack functions, involving many low-level details such as EXI format encoding and decoding, TCP / IP protocol stack tuning, and session state machine management. This makes development difficult, time-consuming, and prone to errors. This hand-written code development model not only requires developers to have a deep understanding of every detail of the protocol specification, but also results in extremely poor code maintainability and reusability. Once the protocol version is updated or requirements change, large-scale refactoring is required.

[0004] The simulation and verification of V2G functionality faces significant challenges due to the limitations of hand-written code implementation. Typical hand-written code logic cannot be easily simulated online and rapidly iterated like MATLAB / Simulink, forcing the verification of control strategies to be delayed until after hardware design is complete. In traditional V2G controller development processes, control strategy development and hardware design are often performed sequentially, requiring engineers to wait for the hardware platform to be ready before conducting simulation verification. This wastes considerable design time and significantly increases design costs. More importantly, the later a problem is discovered, the higher the cost of fixing it, severely impacting project schedule and quality.

[0005] Existing simulation platforms struggle to support the verification requirements of the complete V2G protocol, further exacerbating development inefficiency. Currently, mainstream vehicle control strategy simulation platforms, such as the co-simulation of MATLAB / Simulink and CRUISE, are primarily used for verifying vehicle dynamics and fuel economy. Their model libraries lack simulation support for the V2G communication protocol stack and DC charging logic, making comprehensive verification of V2G functionality impossible during the simulation phase. While hardware-in-the-loop testing (HIL) offers high accuracy, it is expensive, has a long setup cycle, and can only be performed after the hardware is completed, hindering rapid iteration in the early stages of development. These factors collectively constitute the technical bottleneck in V2G functionality development, necessitating a solution that enables efficient simulation verification in the early stages of development. Summary of the Invention

[0006] To achieve the above objectives, this application provides the following technical solution: A simulation and verification system for V2G DC charging of electric vehicles based on MATLAB Simulink includes: Hardware platform, V2G protocol stack module library, EVCC charging control logic model, fault management module, and simulation verification and code generation unit; The hardware platform is a controller, including a main control chip and a communication chip; The V2G protocol stack module library is encapsulated using the MATLAB Simulink environment to form a series of standard functional modules; The EVCC charging control logic model includes a charging process state machine and control command output module, an input parameter processing module, a charging process sub-service processing module, an output parameter processing module, and a V2G information transceiver module. The fault management module performs comprehensive logical judgment on the charging process status signal, the S2 switch status signal in the CP signal, the internal logic error status signal of the EVCC, and the fault status signal reported by the BMS, and outputs a fault flag signal. The simulation verification unit is equipped with a signal observation module and supports fault injection function; The code generation unit generates embedded C code from the EVCC model that has passed simulation verification.

[0007] Furthermore, the system also includes: After the system is powered on, it completes hardware initialization and self-test, calls the V2G protocol initialization module to complete the initialization configuration of the protocol stack, and enters the idle state. Detect the CP signal status. When the charging gun connection is detected, enter the physical connection establishment state and start the SLAC connection establishment process. After the SLAC connection is successful, the EVCC charging process state machine sequentially drives the execution of SECC discovery, application protocol negotiation, session establishment, service discovery, service and payment selection, and contract authentication sub-services. Entering the charging parameter configuration stage, the charging parameter discovery request module is called to obtain the charging pile parameters, the cable inspection request module is executed to perform insulation detection, and the pre-charging request module is executed to perform pre-charging. After pre-charging is completed, the system enters the power transmission state, calls the power transmission request module to start charging, periodically calls the charging current demand request module to update the real-time charging demand during the charging process, calls the power transmission request module to stop power transmission when charging is complete, executes the contactor adhesion detection request module to perform contactor adhesion detection, and calls the charging session end request module to end the charging session.

[0008] Furthermore, the V2G protocol stack module library includes: The module includes: V2G protocol initialization module, V2G protocol basic function module, SECC discovery protocol request module, SECC discovery protocol response module, support application protocol request module, support application protocol response module, session establishment request module, session establishment response module, service discovery request module, service discovery response module, service and payment selection request module, service and payment selection response module, contract authentication request module, contract authentication response module, charging parameter discovery request module, charging parameter discovery response module, cable inspection request module, cable inspection response module, pre-charging request module, pre-charging response module, power delivery request module, power delivery response module, current charging demand request module, current charging demand response module, contactor adhesion detection request module, contactor adhesion detection response module, charging session end request module, and charging session end response module.

[0009] Furthermore, the V2G protocol initialization module is used to complete the memory allocation, state machine initialization, timer configuration, and EXI codec initialization of the V2G protocol stack. The V2G protocol initialization module is repeatedly called at the application layer to reset the entire protocol stack to its initial state.

[0010] Furthermore, the V2G protocol functional basic module is responsible for implementing the functions of CP signal acquisition, filtering, and status judgment, including the identification of statuses A, B, C, D, E, and F; The V2G protocol functional basic module implements the functions of establishing and maintaining SLAC connections, establishing, keeping alive, and disconnecting TCP and UDP communication links, and implementing the periodic scheduling and task management functions of the protocol stack.

[0011] Furthermore, the EVCC charging process sub-service processing module includes a request sub-service module and a response sub-service module. The request sub-service module and the response sub-service module contain a state machine, which includes a Free state, an UpdateSendData state, a WaitResponse state, a Response state, and a Fault state.

[0012] Furthermore, the state transition logic of the request-type sub-service module is as follows: Enter the Free state to clear variables and reset the state; If there are no faults and the master state machine has the corresponding command, enter the UpdateSendData stage and send the requested data out through the V2G transceiver module; Transition to WaitResponse state, awaiting a response from SECC; Upon receiving a correct response, the service enters the Response state, updates the service status to Complete, and returns to the Free state, thus completing the current sub-service. If a timeout or verification error occurs during any state transition, the system will be switched to the Fault state for processing.

[0013] Furthermore, the response sub-service module includes a data processing sub-module and a service status comprehensive output sub-module. The data processing sub-module completes the protocol parsing and validity judgment of the received data, and the service status comprehensive output sub-module completes the comprehensive determination of the final service status.

[0014] Furthermore, the implementation logic of the fault management module is as follows: By judging the charging process status signal, it is determined whether the S2 switch is closed at the specified charging process stage. If it is closed, the output is normal; if it is open, the output is faulty. Determine whether the internal logic error status of the EVCC and the fault status reported by the BMS are both normal. If both are normal, output "normal"; otherwise, output "fault".

[0015] Furthermore, the simulation verification unit sets up a SCOPE viewer, a Display module, and a To Workspace data recording module at the key signal output end of the model to perform real-time observation and post-processing analysis of charging voltage, charging current, SOC, SOH battery parameters, V2G protocol interaction message sequences and timestamps, main state machine state and sub-service state transitions, and system response after fault injection. The simulation verification unit simulates abnormal operating conditions such as communication timeout, contactor sticking, insulation fault, BMS alarm, and protocol error by setting fault injection switches or signal sources in the simulation model, in order to verify the correctness and robustness of the EVCC control logic under various abnormal conditions.

[0016] Compared with the prior art, the advantages and positive effects of the present invention are as follows: This invention encapsulates the complex V2G protocol stack into standardized MATLAB Simulink functional modules. Engineers can implement V2G communication functions by dragging and dropping modules and simple configuration without having to delve into the underlying implementation details of the protocol stack. This significantly reduces the difficulty of V2G function development, shortens the development cycle, improves development efficiency by more than 50%, and shortens the development cycle by about 40%.

[0017] This invention enables the development of V2G functionality to be fully verified and debugged in a pure simulation environment without hardware. The verification of control strategies no longer needs to wait for the completion of hardware design, and problems can be found early in the project. The cost of defect repair is only one-tenth to one-fifth of that of problems found in the hardware stage. The number of defects found in the hardware testing stage of V2G functionality is reduced by more than 60%.

[0018] This invention uses closed-loop simulation with MATLAB Simulink and V2G protocol modules, combined with fault injection function, to systematically verify various fault triggering conditions, debouncing time, fault handling strategies, and fault recovery conditions. This effectively improves the integrity and correctness of the control strategy and ensures that the strategy meets functional safety requirements.

[0019] This invention supports rapid modification simulation verification loops, with a single iteration completed within minutes. Combined with automated test scripts, it enables continuous integration and regression testing of V2G functions, further improving development efficiency and ensuring product quality.

[0020] The V2G protocol module encapsulated in this invention follows standard interface specifications, allowing for convenient functional expansion and upgrades. As the V2G protocol evolves, only the corresponding protocol module needs to be updated to support the new version of the protocol, without the need to redevelop the entire system. Furthermore, these modules can be reused in multiple projects, reducing the development investment for subsequent projects.

[0021] This invention can complete the verification of most V2G functions in a pure software simulation environment, with almost zero hardware investment costs. At the same time, due to the shortened development cycle and reduced defects, labor costs and test verification fees are also significantly reduced, and the overall development cost can be reduced by 40% to 60%.

[0022] This invention utilizes automatic code generation technology, allowing simulation-verified models to directly generate embedded code and deploy it to actual controllers. This eliminates potential deviations and errors introduced by handwritten code, ensuring a high degree of consistency between simulation verification results and actual product behavior, and shortening the productization cycle. Attached Figure Description

[0023] Figure 1 The structural block diagram of the MATLAB Simulink-based electric vehicle V2G DC charging simulation and verification system claimed in the embodiments of the present invention; Figure 2 The system architecture diagram of the EV22377A controller of the MATLAB Simulink-based electric vehicle V2G DC charging simulation verification system claimed in the embodiments of the present invention; Figure 3 The DC charging flowchart of the MATLAB Simulink-based electric vehicle V2G DC charging simulation verification system claimed in this embodiment of the invention is shown. Detailed Implementation

[0024] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of this application, and not all of the embodiments. Based on the embodiments of this application, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the scope of protection of this application.

[0025] The terms "first," "second," and "third" in this application are for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of technical features indicated. Therefore, a feature defined as "first," "second," or "third" may explicitly or implicitly include at least one of that feature. In the description of this application, "multiple" means at least two, such as two, three, etc., unless otherwise explicitly specified. All directional indications (such as up, down, left, right, front, back, etc.) in the embodiments of this application are only used to explain the relative positional relationships and movements between components in a specific orientation (as shown in the figures). If the specific orientation changes, the directional indications also change accordingly. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion. For example, a process, method, system, product, or device that includes a series of steps or units is not limited to the listed steps or units, but may optionally include steps or units not listed, or may optionally include other steps or units inherent to these processes, methods, products, or devices.

[0026] In this document, the term "embodiment" means that a particular feature, structure, or characteristic described in connection with an embodiment may be included in at least one embodiment of this application. The appearance of this phrase in various places throughout the specification does not necessarily refer to the same embodiment, nor is it a mutually exclusive, independent, or alternative embodiment. It will be explicitly and implicitly understood by those skilled in the art that the embodiments described herein can be combined with other embodiments.

[0027] According to a first embodiment of the present invention, the present invention claims protection for a MATLAB Simulink-based V2G DC charging simulation and verification system for electric vehicles, comprising: Hardware platform, V2G protocol stack module library, EVCC charging control logic model, fault management module, and simulation verification and code generation unit; The hardware platform is a controller, including a main control chip and a communication chip; The V2G protocol stack module library is encapsulated using the MATLAB Simulink environment to form a series of standard functional modules; The EVCC charging control logic model includes a charging process state machine and control command output module, an input parameter processing module, a charging process sub-service processing module, an output parameter processing module, and a V2G information transceiver module. The fault management module performs comprehensive logical judgment on the charging process status signal, the S2 switch status signal in the CP signal, the internal logic error status signal of the EVCC, and the fault status signal reported by the BMS, and outputs a fault flag signal. The simulation verification unit is equipped with a signal observation module and supports fault injection function; The code generation unit generates embedded C code from the EVCC model that has passed simulation verification.

[0028] Furthermore, the system also includes: After the system is powered on, it completes hardware initialization and self-test, calls the V2G protocol initialization module to complete the initialization configuration of the protocol stack, and enters the idle state. Detect the CP signal status. When the charging gun connection is detected, enter the physical connection establishment state and start the SLAC connection establishment process. After the SLAC connection is successful, the EVCC charging process state machine sequentially drives the execution of SECC discovery, application protocol negotiation, session establishment, service discovery, service and payment selection, and contract authentication sub-services. Entering the charging parameter configuration stage, the charging parameter discovery request module is called to obtain the charging pile parameters, the cable inspection request module is executed to perform insulation detection, and the pre-charging request module is executed to perform pre-charging. After pre-charging is completed, the system enters the power transmission state, calls the power transmission request module to start charging, periodically calls the charging current demand request module to update the real-time charging demand during the charging process, calls the power transmission request module to stop power transmission when charging is complete, executes the contactor adhesion detection request module to perform contactor adhesion detection, and calls the charging session end request module to end the charging session.

[0029] Furthermore, the V2G protocol stack module library includes: The module includes: V2G protocol initialization module, V2G protocol basic function module, SECC discovery protocol request module, SECC discovery protocol response module, support application protocol request module, support application protocol response module, session establishment request module, session establishment response module, service discovery request module, service discovery response module, service and payment selection request module, service and payment selection response module, contract authentication request module, contract authentication response module, charging parameter discovery request module, charging parameter discovery response module, cable inspection request module, cable inspection response module, pre-charging request module, pre-charging response module, power delivery request module, power delivery response module, current charging demand request module, current charging demand response module, contactor adhesion detection request module, contactor adhesion detection response module, charging session end request module, and charging session end response module.

[0030] Furthermore, the V2G protocol initialization module is used to complete the memory allocation, state machine initialization, timer configuration, and EXI codec initialization of the V2G protocol stack. The V2G protocol initialization module is repeatedly called at the application layer to reset the entire protocol stack to its initial state.

[0031] Furthermore, the V2G protocol functional basic module is responsible for implementing the functions of CP signal acquisition, filtering, and status judgment, including the identification of statuses A, B, C, D, E, and F; The V2G protocol functional basic module implements the functions of establishing and maintaining SLAC connections, establishing, keeping alive, and disconnecting TCP and UDP communication links, and implementing the periodic scheduling and task management functions of the protocol stack.

[0032] Furthermore, the EVCC charging process sub-service processing module includes a request sub-service module and a response sub-service module. The request sub-service module and the response sub-service module contain a state machine, which includes a Free state, an UpdateSendData state, a WaitResponse state, a Response state, and a Fault state.

[0033] Furthermore, the state transition logic of the request-type sub-service module is as follows: Enter the Free state to clear variables and reset the state; If there are no faults and the master state machine has the corresponding command, enter the UpdateSendData stage and send the requested data out through the V2G transceiver module; Transition to WaitResponse state, awaiting a response from SECC; Upon receiving a correct response, the service enters the Response state, updates the service status to Complete, and returns to the Free state, thus completing the current sub-service. If a timeout or verification error occurs during any state transition, the system will be switched to the Fault state for processing.

[0034] Furthermore, the response sub-service module includes a data processing sub-module and a service status comprehensive output sub-module. The data processing sub-module completes the protocol parsing and validity judgment of the received data, and the service status comprehensive output sub-module completes the comprehensive determination of the final service status.

[0035] Furthermore, the implementation logic of the fault management module is as follows: By judging the charging process status signal, it is determined whether the S2 switch is closed at the specified charging process stage. If it is closed, the output is normal; if it is open, the output is faulty. Determine whether the internal logic error status of the EVCC and the fault status reported by the BMS are both normal. If both are normal, output "normal"; otherwise, output "fault".

[0036] Furthermore, the simulation verification unit sets up a SCOPE viewer, a Display module, and a To Workspace data recording module at the key signal output end of the model to perform real-time observation and post-processing analysis of charging voltage, charging current, SOC, SOH battery parameters, V2G protocol interaction message sequences and timestamps, main state machine state and sub-service state transitions, and system response after fault injection. The simulation verification unit simulates abnormal operating conditions such as communication timeout, contactor sticking, insulation fault, BMS alarm, and protocol error by setting fault injection switches or signal sources in the simulation model, in order to verify the correctness and robustness of the EVCC control logic under various abnormal conditions.

[0037] Reference Figure 1 , Figure 1 The electric vehicle V2G DC charging simulation and verification system based on MATLAB Simulink proposed in one embodiment of this application includes: a hardware platform, a V2G protocol stack module library, an EVCC charging control logic model, a fault management module, and a simulation verification unit and a code generation unit.

[0038] In this embodiment, the MATLAB Simulink-based electric vehicle V2G DC charging simulation verification system encapsulates the core functions of the V2G protocol stack into standardized Simulink functional modules, enabling V2G charging function verification and debugging in a pure simulation environment. Engineers do not need to delve into the underlying implementation details of the V2G protocol stack; they can implement V2G communication functions by dragging and dropping modules and simple configuration, significantly reducing the difficulty of V2G function development and shortening the development cycle.

[0039] In one embodiment, this application also provides a MATLAB Simulink-based V2G DC charging simulation verification system for electric vehicles. The hardware platform is implemented using an EV22377A controller, which includes an Infineon TC377 automotive-grade tri-core microcontroller as the main control chip with a clock frequency of 300MHz; it integrates a Qualcomm QCA7005 automotive-grade broadband power line communication chip, supporting the HomePlug Green PHY standard; it supports various vehicle network communication methods such as CAN, LIN, and in-vehicle Ethernet; and it provides rich digital and analog input / output interfaces.

[0040] In this embodiment, refer to Figure 2 The EV22377A controller, as the core hardware platform of the V2G charging system, utilizes the Infineon TC377 automotive-grade tri-core microcontroller to run the V2G protocol stack and EVCC charging control logic. The TC377 chip adopts a TriCore architecture with a maximum clock speed of 300MHz, featuring independent program and data memory, supporting a real-time operating system, and meeting the stringent real-time requirements of V2G communication. The integrated Qualcomm QCA7005 automotive-grade broadband power line communication chip supports the HomePlug Green PHY standard, operating at a frequency range of 2MHz to 30MHz, enabling low-speed power line communication between the electric vehicle and the charging station with a transmission rate of up to 10Mbps. The controller also supports multiple vehicle network communication methods such as CAN, LIN, and in-vehicle Ethernet, allowing data interaction with the vehicle's internal network. Furthermore, the controller provides abundant digital and analog input / output interfaces, including several digital input channels, several digital output channels, several analog input channels, and several analog output channels, for connecting external devices such as charging interface signals, contactor control signals, and current and voltage sampling signals.

[0041] In one embodiment, this application also provides a simulation verification system for V2G DC charging of electric vehicles based on MATLAB Simulink. The V2G protocol stack module library is encapsulated in the MATLAB Simulink environment, integrating the core functions of the DINSPEC 70121 protocol and the ISO 15118 protocol into the Simulink model to form a series of standard functional modules, including request class modules and response class modules. Each module encapsulates the corresponding V2G message construction, sending, receiving and parsing functions.

[0042] In this embodiment, the V2G protocol stack module library is the foundational component library of the entire simulation verification system. This module library abstracts and encapsulates the core functions of the international standard V2G communication protocols DIN SPEC 70121 and ISO 15118, forming functional modules that can be directly called in the MATLAB Simulink environment. The DIN SPEC 70121 protocol is a communication standard between electric vehicles and charging piles based on power line communication, defining the communication process and data format between electric vehicles (EVCCs) and charging piles (SECCs). The ISO 15118 protocol is an IP-based communication standard between electric vehicles and charging piles, defining richer charging services and implementation methods that support plug-and-charge functionality. This system integrates the core functions of the above two protocols to form a unified modular interface. Engineers can choose to use the appropriate protocol for V2G communication according to actual needs. Each functional module in the module library encapsulates complete V2G message processing logic, including four core functions: message construction, sending, receiving, and parsing, and interacts with other modules through standardized input / output ports.

[0043] In one embodiment, this application also provides a MATLAB Simulink-based V2G DC charging simulation and verification system for electric vehicles. The V2G protocol stack module library includes a V2G protocol initialization module, a V2G protocol function base module, an SECC discovery protocol request module, an SECC discovery protocol response module, an application support protocol request module, an application support protocol response module, a session establishment request module, a session establishment response module, a service discovery request module, a service discovery response module, a service and payment selection request module, a service and payment selection response module, a contract authentication request module, a contract authentication response module, a charging parameter discovery request module, a charging parameter discovery response module, a cable inspection request module, a cable inspection response module, a pre-charging request module, a pre-charging response module, a power delivery request module, a power delivery response module, a current charging demand request module, a current charging demand response module, a contactor adhesion detection request module, a contactor adhesion detection response module, a charging session end request module, and a charging session end response module.

[0044] In this embodiment, the V2G protocol stack module library defines complete request and response modules according to the interaction flow of the V2G communication protocol. The V2G protocol initialization module is used to complete the memory allocation, state machine initialization, timer configuration, and EXI codec initialization of the V2G protocol stack. This module can be repeatedly called at the application layer to reset the entire protocol stack to its initial state. The V2G protocol function basic module is responsible for implementing the acquisition, filtering, and state judgment functions of CP signals, including the identification of states A, B, C, D, E, and F; implementing the establishment and maintenance functions of SLAC connections; implementing the establishment, keep-alive, and disconnection functions of TCP and UDP communication links; and implementing the periodic scheduling and task management functions of the protocol stack. The SECC discovery protocol request module and SECC discovery protocol response module are used to implement the interaction flow of EVCC discovering SECC, supporting the discovery of available charging pile devices through power line communication. The application protocol support request module and application protocol support response module are used to negotiate the V2G protocol versions and function sets supported by both parties. The session establishment request module and session establishment response module are used to establish a V2G communication session. The Service Discovery Request and Service Discovery Response modules are used to query the types of charging services provided by the charging pile. The Service and Payment Selection Request and Service and Payment Selection Response modules are used to select the desired charging service and payment method. The Contract Authentication Request and Contract Authentication Response modules are used to authenticate the user's identity and payment contract. The Charging Parameter Discovery Request and Charging Parameter Discovery Response modules are used to obtain the charging pile's charging parameter capabilities. The Cable Inspection Request and Cable Inspection Response modules are used to detect the connection status and insulation performance of the charging cable. The Pre-Charging Request and Pre-Charging Response modules are used to establish the pre-charging process for the charging circuit. The Power Transmission Request and Power Transmission Response modules are used to start or stop power transmission. The Current Charging Demand Request and Current Charging Demand Response modules are used to periodically update the charging demand during the charging process. The Contactor Adhesion Detection Request and Contactor Adhesion Detection Response modules are used to detect the contactor's adhesion status after charging is completed. The Charging Session End Request and Charging Session End Response modules are used to normally end the charging session.

[0045] In one embodiment, this application also provides a simulation and verification system for V2G DC charging of electric vehicles based on MATLAB Simulink, wherein the V2G protocol initialization module is used to complete the memory allocation, state machine initialization, timer configuration and EXI codec initialization of the V2G protocol stack. This module can be repeatedly called at the application layer to reset the entire protocol stack to the initial state.

[0046] In this embodiment, the V2G protocol initialization module is the entry point module of the entire V2G protocol stack, and it is the first module called to perform initialization operations after the system powers on. The initialization process of this module includes the following steps: First, memory allocation is performed. The protocol stack allocates memory space for storing protocol states, message buffers, and temporary variables according to a preset configuration file, and establishes memory management data structures. Then, state machine initialization is performed, resetting each state machine within the protocol stack to its initial state, including the communication session state machine, message processing state machine, and error handling state machine. Next, timer configuration is performed, setting the initial values ​​and operating parameters of each timer used within the protocol stack, including the message sending timeout timer, response wait timer, and heartbeat keep-alive timer. Finally, EXI codec initialization is performed, configuring the EXI codec parameters, including maximum string length, maximum number of elements, maximum number of attributes, and byte order. After initialization, the module outputs an initialization completion flag signal, informing the upper-layer module that the subsequent charging process can begin. This module supports repeated calls at the application layer. When a serious fault occurs requiring a reset of the entire protocol stack, the application layer can call this module again to restore the protocol stack to its initial state without restarting the entire control system.

[0047] In one embodiment, this application also provides a MATLAB Simulink-based V2G DC charging simulation verification system for electric vehicles, wherein the V2G protocol functional basic module is responsible for implementing the functions of CP signal acquisition, filtering, and state judgment, including the identification of states A, B, C, D, E, and F; implementing the functions of establishing and maintaining SLAC connections; implementing the functions of establishing, keeping alive, and disconnecting TCP and UDP communication links; and implementing the functions of periodic scheduling and task management of the protocol stack.

[0048] In this embodiment, the V2G protocol function basic module is the core support module of the entire V2G protocol stack, providing the basic functions required for the protocol stack to run. The CP signal is the control and guidance signal on the charging interface. By detecting the voltage value of the CP signal, the connection status of the charging gun and the status of the S2 switch can be determined. CP signal status A indicates the charging gun is not connected; status B indicates the charging gun is connected but the S2 switch is open; status C indicates the charging gun is connected and the S2 switch is closed but the charging pile is not ready; status D indicates the charging gun is connected, the S2 switch is closed, and the charging pile is ready; status E indicates a charging pile output fault; and status F indicates the charging pile is unavailable. This module collects the analog voltage value of the CP signal through the AD sampling channel, processes it using a digital filtering algorithm to eliminate noise interference, and then determines the status based on the voltage threshold. SLAC, or Signal Attenuation Link Negotiation, is a link layer protocol for power line communication, used to establish a reliable communication link between the EVCC and SECC. This module implements the complete SLAC process, including SLAC parameter configuration, SLAC startup, SLAC response, and SLAC completion confirmation. TCP and UDP communication links are the network layer transport protocols of the V2G protocol stack. TCP is used for reliable data transmission, such as V2G message exchange, while UDP is used for sending broadcast messages, such as SECC discovery messages. This module implements the complete functionality of TCP and UDP clients, including connection establishment, data transmission, data reception, connection keep-alive, and connection termination. The periodic scheduling and task management functions are responsible for triggering the execution of each protocol module according to a preset scheduling period, managing task priority and execution order, and ensuring the real-time performance of the protocol stack.

[0049] In one embodiment, this application also provides a simulation verification system for V2G DC charging of electric vehicles based on MATLAB Simulink, wherein the EVCC charging control logic model includes an EVCC charging process state machine and control command output module, an EVCC module input parameter processing module, an EVCC charging process sub-service processing module, an EVCC module output parameter processing module, and an EVCC V2G information transceiver module.

[0050] In this embodiment, the EVCC charging control logic model is the core control model of the entire simulation verification system, realizing the complete charging control logic of the electric vehicle as the EVCC. This model adopts a modular design, decomposing the complex charging control logic into five cooperative sub-modules. The EVCC charging process state machine and control command output module is the main control module, implementing the EVCC charging master state machine and responsible for managing the stage transitions and control command generation of the entire charging process. The EVCC module input parameter processing module is responsible for receiving and processing all input signals, including battery status information sent by the BMS, vehicle status signals, charging pile feedback signals, and user setting signals, and performing validity verification, filtering, and calibration conversion on the input signals. The EVCC charging process sub-service processing module implements the functional logic of each charging sub-process, with each sub-service corresponding to a request and response pair in the V2G protocol. The EVCC module output parameter processing module is responsible for summarizing all output signals, including charging control commands, charging status information, fault diagnosis information, and statistical information. The EVCC V2G information transceiver module is responsible for the actual sending and receiving of V2G protocol messages according to the commands of the master state machine and the sub-service modules. These five modules interact through a standardized data interface to jointly complete the charging control function of EVCC.

[0051] In one embodiment, this application also provides a simulation and verification system for V2G DC charging of electric vehicles based on MATLAB Simulink, wherein, referring to Figure 2 The EVCC charging process state machine and control command output module implement the EVCC charging main state machine, which includes idle state, physical connection establishment state, SLAC connection establishment state, protocol negotiation state, session establishment state, service discovery state, service and payment selection state, contract authentication state, charging parameter configuration state, cable inspection state, pre-charging state, power transmission state, charging monitoring state, charging end state, contactor adhesion detection state, session end state, and fault state.

[0052] In this embodiment, the EVCC charging process state machine is the core of the entire EVCC charging control logic. It defines the transition relationships between each stage in the complete process of an electric vehicle from inserting the charging gun to removing the charging gun after charging is complete. The idle state is the initial state of the charging process, in which the system waits for the charging gun to connect. When a charging gun connection is detected, the state machine transitions to the physical connection establishment state, in which the CP signal status is checked and physical layer preparation is performed. After the physical connection is established, the state machine transitions to the SLAC connection establishment state, in which the SLAC negotiation process is initiated to establish a power line communication link. After the SLAC connection is successfully established, the state machine transitions to the protocol negotiation state, in which the V2G protocol versions and feature sets supported by both parties are negotiated with the SECC. After the protocol negotiation is completed, the state machine transitions to the session establishment state, in which a V2G communication session is established. After the session is established... The state machine transitions to the service discovery state, where it queries the types of charging services offered by the charging pile. After service discovery, the state machine transitions to the service and payment selection state, where it selects the desired charging service and payment method. After service and payment selection, the state machine transitions to the contract authentication state, where it authenticates the user's identity and the payment contract. After contract authentication, the state machine transitions to the charging parameter configuration state, where it acquires and configures the charging parameters. After charging parameter configuration, the state machine transitions to the cable inspection state, where it checks the connection status and insulation performance of the charging cable. After the cable inspection passes, the state machine transitions to the pre-charging state, where it establishes the pre-charging process for the charging circuit. After pre-charging is complete, the state machine transitions to the power transmission state, where it starts the charger to begin charging. In the power transmission state, the state machine maintains the charging monitoring state, monitoring the charging process in real time. When charging is complete or the user actively stops charging, the state machine transitions to the charging end state, in which the charger stops and the charging end process begins. After charging is complete, the state machine transitions to the contactor adhesion detection state, in which the adhesion status of the charging contactor is detected. After the detection is completed, the state machine transitions to the session end state, in which the V2G communication session ends and the connection is disconnected. If a fault is detected in any state, the state machine transitions to the fault state, performs fault handling, and attempts to recover. The transitions between the above states are subject to strict condition constraints to ensure the safety and reliability of the charging process.

[0053] In one embodiment, this application also provides a MATLAB Simulink-based V2G DC charging simulation and verification system for electric vehicles. The EVCC charging process sub-service processing module implements the functional logic of each charging sub-process, with each sub-service corresponding to a request-response pair in the V2G protocol. The sub-service processing module includes request-type sub-service modules and response-type sub-service modules. Each module contains a state machine, which includes Free, UpdateSendData, WaitResponse, Response, and Fault states.

[0054] In this embodiment, the EVCC charging process sub-service processing module encapsulates each complete request-response interaction in the V2G charging process into a sub-service module; the sub-service module is the basic unit constituting the EVCC charging control logic, and each sub-service module corresponds to a request message and a corresponding response message in the V2G protocol. The sub-service processing modules are divided into two categories: request-type sub-service modules and response-type sub-service modules. Request-type sub-service modules are responsible for constructing and sending V2G request messages, while response-type sub-service modules are responsible for receiving and parsing V2G response messages. Each sub-service module contains a state machine to manage the execution flow of that sub-service. The state machine includes the following five states: Free (initial state), where variables are cleared and the state is reset to prepare for executing new sub-service requests; UpdateSendData (data update and sending state), where request data is updated according to commands from the main state machine and the request message is sent out through the V2G transceiver module; WaitResponse (waiting response state), where the system waits for the response message from SECC; Response (response processing state), where the system receives and parses the SECC response message, updates the service state to complete, and then returns to the Free state to complete the current sub-service; and Fault (fault handling state), where the system transitions to this state when an exception such as a timeout, verification error, or protocol error occurs during any state transition, performs fault recording and processing, and then returns to the Free state. This state machine design ensures that each sub-service module can independently and reliably complete its corresponding V2G message interaction.

[0055] In one embodiment, this application also provides a MATLAB Simulink-based V2G DC charging simulation verification system for electric vehicles, wherein the State Machine state transition logic of the request-type sub-service module is as follows: First, it enters the Free state to clear variables and reset the state; if there is no fault and the main state machine has a corresponding command, it enters the UpdateSendData stage to send the request data through the V2G transceiver module; then it enters the WaitResponse state to wait for the SECC response; after receiving a correct response, it enters the Response state, updates the service status to complete, and returns to the Free state to complete the current sub-service; if any timeout, verification error, or other abnormality occurs during any state transition, it enters the Fault state for processing.

[0056] In this embodiment, the state machine of the request-type sub-service module strictly follows the following logic for state transitions. Upon system initialization or completion of the previous sub-service, the state machine is in the Free state, where internal variables are cleared and state flags are reset, preparing to receive new service requests. When the main state machine issues a command to execute the current sub-service, the module checks for any unprocessed fault flags. If there are no faults and the main state machine command is valid, it transitions to the UpdateSendData state. In the UpdateSendData state, the module constructs a complete V2G request message based on the type and context information of the current sub-service, including request headers, request parameters, and a checksum, and then sends the request message to the SECC by calling the sending interface of the V2G transceiver module. After the request is sent, the state machine transitions to the WaitResponse state and begins timing to wait for the SECC's response. In the WaitResponse state, if a response message from the SECC is received, message parsing and validity verification are performed. If the response message format is correct and the content is valid, it transitions to the Response state. If the response message times out or parsing and verification fail, it transitions to the Fault state. In the Response state, the module updates the execution status of the current sub-service to complete, saves the relevant parameters in the response message for use by the main state machine, and then the state machine returns to the Free state to prepare for the execution of the next sub-service. In any state of the state machine, if an abnormal situation is detected, including communication timeout, protocol parsing error, data verification failure, or cancellation command by the main state machine, the state machine immediately transitions to the Fault state. In the Fault state, the module records the fault type and fault parameters, sets the fault flag, and reports the fault information to the main state machine when necessary. Then the state machine returns to the Free state to wait for the next service request.

[0057] In one embodiment, this application also provides a simulation verification system for V2G DC charging of electric vehicles based on MATLAB Simulink, wherein the response class sub-service module includes a data processing sub-module and a service status comprehensive output sub-module. The data processing sub-module completes the protocol parsing and validity judgment of the received data, and the service status comprehensive output sub-module completes the comprehensive determination of the final service status.

[0058] In this embodiment, the response sub-service module processes the response messages returned by SECC. This module consists of two sub-modules: a data processing sub-module and a service status comprehensive output sub-module. The data processing sub-module receives response message data from the V2G transceiver module, first performing protocol parsing to extract various fields from the response message, including the response code, parameter list, and diagnostic information. Then, it performs validity checks, verifying whether the response code is a success flag, whether the parameter values ​​are within a valid range, and whether there is any abnormal data. Finally, it outputs the parsing and judgment results to the service status comprehensive output sub-module. The service status comprehensive output sub-module performs a final comprehensive service status determination based on the output results of the data processing sub-module. This sub-module maintains a service status variable, comprehensively considering the parsing results, validity, and current context information of the response message to determine the final execution status of the current sub-service. The output of the service status comprehensive output sub-module includes service execution result flags, service completion flags, response data validity flags, and fault flags. These output signals are sent to the main state machine to control the state transitions of the main state machine and the execution of subsequent sub-services. This modular design ensures the reliability and maintainability of response message processing.

[0059] In one embodiment, this application also provides a MATLAB Simulink-based V2G DC charging simulation verification system for electric vehicles, wherein the EVCC module input parameter processing module is responsible for receiving and processing all input signals, including battery status information sent by the BMS, vehicle status signals, charging pile feedback signals, and user setting signals, and performs validity verification, filtering, and calibration conversion on the input signals, converting the original signals into standardized internal variables for use by the state machine.

[0060] In this embodiment, the EVCC module input parameter processing module is the input interface module of the EVCC charging control logic model, which is responsible for converting various external input signals into standardized internal variables for use by other modules. The input signals processed by this module mainly include the following four categories: The first category is battery status information sent by the BMS, including the current battery voltage, current current, SOC (State of Charge), SOH (State of Health), maximum allowable charging voltage, maximum allowable charging current, minimum allowable discharging voltage, maximum allowable temperature, minimum allowable temperature, and charging mode. This information reflects the current state and charging capacity of the battery. The second category is vehicle status signals, including vehicle readiness status, door open / closed status, charging gun connection status, vehicle type identification, and maximum supported charging power. This information reflects the current state and charging capacity of the vehicle. The third category is charging pile feedback signals, including charging pile output voltage, charging pile output current, maximum charging pile output power, supported charging types, and charging pile authentication status. This information reflects the current state and capability of the charging pile. The fourth category is user setting signals, including the user's desired charging capacity, desired charging time, selected charging service type, and selected payment method. This information reflects the user's personalized needs.

[0061] In this embodiment, the module implements a complete signal processing flow for the four types of input signals mentioned above. First, validity verification is performed to check for any anomalies in the input signal, including whether the signal value exceeds a reasonable range, whether the signal has not been updated for a long time, or whether signal communication has timed out. If an anomaly is detected, a fault mark is made and a default value is used as a replacement. Next, filtering is performed. For analog input signals, a digital filtering algorithm is used to eliminate noise interference, and for digital input signals, debouncing is performed to ensure the stability of the state determination. Finally, calibration conversion is performed, converting the original engineering values ​​into internally standardized variables, including unit conversion, proportional transformation, and offset compensation. The standardized variables after the above processing are stored in the module's internal input variable mapping table for the EVCC charging process state machine and other modules to read and use as needed.

[0062] In one embodiment, this application also provides a MATLAB Simulink-based V2G DC charging simulation verification system for electric vehicles, wherein the EVCC module output parameter processing module is responsible for summarizing all output signals, including charging control commands, charging status information, fault diagnosis information, and statistical information, and formatting and normalizing the output signals to meet the requirements of communication interfaces such as CAN bus or Ethernet.

[0063] In this embodiment, the EVCC module output parameter processing module is the output interface module of the EVCC charging control logic model. It is responsible for converting various internally generated output signals into a format that meets the requirements of the external communication interface. The output signals processed by this module mainly include the following four categories: The first category is charging control commands, including charger enable commands, charger disable commands, charging power adjustment commands, charging stop commands, contactor closing commands, contactor opening commands, etc. These commands are used to control the operation of the charger and the action of the contactor. The second category is charging status information, including current charging status, amount charged, charging time, current charging power, current charging current, current charging voltage, estimated remaining charging time, etc. This information is used to display or report to the outside world. The third category is fault diagnosis information, including fault type, fault code, fault occurrence time, fault-related parameters, etc. This information is used for fault recording and diagnosis. The fourth category is statistical information, including cumulative charging times, cumulative charging amount, maximum charging power, number of charging interruptions, etc. This information is used for operation statistics and performance evaluation.

[0064] In this embodiment, the output parameter processing module formats and normalizes the above four types of output signals. For signals that need to be sent to the CAN bus, the module packages them into data conforming to the CAN frame format, including message ID, data length, and data byte sequence. For messages that need to be sent to the Ethernet, the module encapsulates them into data packet formats conforming to the TCP or UDP protocol. For display data that needs to be sent to the display screen or human-machine interface, the module converts it into a human-readable string format. The module maintains an output signal mapping table internally, which records information such as the target interface, signal format, transmission period, and priority of each output signal. The module determines when and how to send each output signal based on this configuration information.

[0065] In one embodiment, this application also provides a MATLAB Simulink-based V2G DC charging simulation verification system for electric vehicles. The EVCC V2G information transceiver module is responsible for the actual sending and receiving of V2G protocol messages according to the commands of the main state machine and the sub-service module. This module interacts with the SECC of the charging pile through the PLC physical layer and supports the complete sending and receiving process of TCP and IP protocol stacks.

[0066] In this embodiment, the EVCC V2G message transceiver module is the actual execution module for V2G communication between EVCC and SECC, responsible for sending and receiving V2G protocol messages. The module's sending function includes: receiving V2G request messages to be sent from the request class sub-service module, performing EXI encoding on the messages to compress the data volume, sending the encoded messages to SECC via TCP or UDP protocol, processing the sending result, and returning the sending status to the calling module. The module's receiving function includes: receiving V2G response messages returned by SECC from the TCP or UDP port, performing EXI decoding on the received messages to restore the original data, parsing the decoded messages into structured data, and returning the parsing result to the response class sub-service module for processing. This module supports complete TCP and IP protocol stack functions, including TCP connection establishment three-way handshake, TCP connection closure four-way handshake, TCP keep-alive mechanism, UDP broadcast and unicast, IP fragmentation and reassembly, flow control and congestion control, etc. The module internally maintains communication state variables, including connection status, send buffer status, receive buffer status, error counter, and performance statistics, which can be used for communication fault diagnosis and performance monitoring.

[0067] In one embodiment, this application also provides a MATLAB Simulink-based V2G DC charging simulation verification system for electric vehicles, wherein the fault management module performs comprehensive logical judgment on the EVCC charging process status signal, the S2 switch status signal in the CP signal, the EVCC internal logic error status signal, the fault status signal reported by the BMS, and the error code signal, and outputs a fault flag signal for use by each sub-service module.

[0068] In this embodiment, the fault management module is the safety assurance module of the entire system, responsible for real-time monitoring and judgment of various fault states during system operation. The input signals collected by this module include the following five categories: The first category is the EVCC charging process status signal, reflecting which stage the current charging process is in, and different charging stages correspond to different fault detection strategies; the second category is the S2 switch status signal in the CP signal, used to determine whether the mechanical connection of the charging interface is properly closed; the third category is the EVCC internal logic error status signal, which comes from the self-check results of each module within the EVCC charging control logic model, including message parsing errors, state machine anomalies, parameter over-limits, etc.; the fourth category is the fault status signal reported by the BMS, which comes from the battery management system, including battery overvoltage, battery undervoltage, battery overcurrent, battery overtemperature, battery short circuit, etc.; the fifth category is error code signals, including communication error codes, protocol error codes, and system error codes, used to accurately locate the cause of the fault.

[0069] In this embodiment, the fault determination logic of the fault management module adopts a multi-level, multi-condition comprehensive determination method. The module maintains a fault determination matrix, recording the correspondence between each charging stage and various fault signals. Upon receiving the five types of input signals, the module first performs time synchronization and alignment to ensure that all signals are consistent in time. Then, based on the current charging process stage, it searches for the corresponding fault detection rule in the fault determination matrix. Next, it performs logical judgment on each input signal according to the detection rule to determine whether a fault condition exists. Finally, it synthesizes all judgment results and generates a fault flag signal, which is output to each sub-service module. The fault flag signal includes information such as the overall fault flag, fault type code, fault level, and detailed fault description, which are queried and used by the sub-service modules during execution.

[0070] In one embodiment, this application also provides a V2G DC charging simulation verification system for electric vehicles based on MATLAB Simulink, wherein the implementation logic of the fault management module is as follows: by judging the charging process status signal, it judges whether the S2 switch is closed at a specified charging process stage. If it is closed, it outputs normal; if it is open, it outputs fault. At the same time, it judges whether the internal logic error status of EVCC and the fault status reported by BMS are both normal. If both are normal, it outputs normal; otherwise, it outputs fault.

[0071] In this embodiment, the core fault determination logic of the fault management module is strictly implemented according to the following rules. For determining the S2 switch status, the module judges whether an S2 switch status check is needed based on the current charging process status signal. The module only performs the S2 switch status check when the charging process is in a stage requiring S2 switch closure, including the pre-charging stage, power delivery stage, charging monitoring stage, and contactor adhesion detection stage. If the S2 switch is detected to be open in any of these stages, a fault is immediately determined, and a fault flag is output. For the comprehensive determination of the EVCC internal logic error status and the BMS fault status, the module simultaneously reads the EVCC internal logic error status signal and the fault status signal reported by the BMS. A normal flag is output only when both signals show a normal state. If either signal shows an abnormal state, a fault is determined, and a corresponding fault flag is output. This dual-check mechanism ensures the comprehensiveness and reliability of fault determination, effectively preventing continued charging operations in the presence of potential faults and ensuring the safety of the charging process.

[0072] In one embodiment, this application also provides a simulation verification system for V2G DC charging of electric vehicles based on MATLAB Simulink. The simulation verification unit fully utilizes the advantages of the MATLAB Simulink simulation environment, and sets up a SCOPE viewer, a Display module, and a To Workspace data recording module at the key signal output end of the model to perform real-time observation and post-processing analysis of battery parameters such as charging voltage, charging current, SOC, and SOH, message sequences and timestamps of V2G protocol interaction, main state machine state and sub-service state transitions, and system response after fault injection.

[0073] In this embodiment, the simulation verification unit is the core verification tool of the entire system. Utilizing the rich simulation and debugging capabilities provided by the MATLAB Simulink environment, it achieves comprehensive verification of the V2G charging process. This unit is configured with various observation and recording tools at each key signal output of the model. The SCOPE viewer is used to display the waveform changes of the signals in real time. Users can configure the display parameters of SCOPE, including the time axis range, signal scaling ratio, trigger conditions, etc., to observe the real-time changing trends of analog signals such as charging voltage and charging current. The Display module is used to display the current values ​​of the signals. Users can place multiple Display modules at different locations on the model to simultaneously observe the current values ​​of multiple key variables, such as SOC, SOH, current charging power, and current state machine state. The To Workspace data recording module is used to save the signal data during the simulation process to the MATLAB workspace. Users can perform post-processing analysis on the recorded data after the simulation, including statistical analysis, spectrum analysis, and time series analysis.

[0074] In this embodiment, the simulation verification unit focuses on the following four types of signals: The first type is battery parameters, including charging voltage, charging current, SOC (State of Charge), SOH (State of Health), battery temperature, and battery voltage equalization status. These parameters reflect the current state and health of the battery. The second type is V2G protocol interaction information, including the sequence of sent and received V2G messages, message content, timestamps, and communication status. This information is used to verify the correctness and timing of V2G protocol interaction. The third type is state machine status, including the current state of the main state machine, the status of each sub-service module, state transition time, and transition reason. This information is used to verify the correctness of the state machine logic. The fourth type is fault response information, including the injected fault type, the time of fault occurrence, the time when the system detects the fault, the fault handling measures taken by the system, and the fault recovery status. This information is used to verify the correctness and completeness of the fault handling logic.

[0075] In one embodiment, this application also provides a simulation verification system for V2G DC charging of electric vehicles based on MATLAB Simulink. The simulation verification unit supports fault injection function. By setting a fault injection switch or signal source in the simulation model, abnormal operating conditions such as communication timeout, contactor sticking, insulation fault, BMS alarm and protocol error are simulated to verify the correctness and robustness of EVCC control logic under various abnormal conditions.

[0076] In this embodiment, the fault injection function is an important extended function of the simulation verification unit, used to simulate various abnormal operating conditions in the simulation environment and verify whether the behavior of the EVCC control logic under fault conditions meets expectations. Fault injection is implemented in two ways: a fault injection switch and a fault injection signal source. The fault injection switch is a Boolean control signal, and the user can manually set or automatically control the switch's state through a script. When the switch is true, the corresponding fault injection is activated. The fault injection signal source is a signal generator that can be configured to produce different waveforms, and the user can configure parameters such as the timing, duration, and triggering conditions of the fault signal.

[0077] In this embodiment, the system supports the injection of the following five types of faults: The first type is a communication timeout fault, simulating a SECC response timeout during V2G communication to verify the correctness of the EVCC's timeout handling logic; the second type is a contactor adhesion fault, simulating a contactor failing to disconnect properly after charging to verify the correctness of the EVCC's contactor adhesion detection and handling logic; the third type is an insulation fault, simulating a deterioration in the insulation performance of the charging cable or a grounding fault to verify the correctness of the EVCC's insulation detection and protection logic; the fourth type is a BMS alarm fault, simulating a battery management system detecting a battery abnormality and reporting an alarm to verify the correctness of the EVCC's response and handling logic to the BMS alarm; and the fifth type is a protocol error fault, simulating a SECC returning an error response or sending an illegal message to verify the correctness of the EVCC's protocol error handling logic. Users can combine different fault injection scenarios to verify the correctness and robustness of the EVCC control logic under various complex abnormal operating conditions.

[0078] In one embodiment, this application also provides a MATLAB Simulink-based V2G DC charging simulation verification system for electric vehicles. The code generation unit uses Simulink Coder and Embedded Coder tools to generate efficient embedded C code from the EVCC model that has passed the simulation verification, and automatically compiles it into an executable file, which is then downloaded to the TC377 chip of the EV22377A controller for execution. The generated code remains strictly consistent with the model, ensuring that the simulation verification results are consistent with the actual controller behavior.

[0079] In this embodiment, the code generation unit is a crucial link connecting simulation verification and actual hardware deployment. It utilizes MathWorks' Simulink Coder and Embedded Coder tools to achieve automatic conversion from model to code. The code generation process includes the following steps: First, model checking is performed to confirm that the EVCC model, which has passed simulation verification, meets the requirements for code generation. This includes checking the data type compatibility of modules, the dimensional matching of modules, and whether there are any unsupported Simulink modules in the model. Next, code generation configuration is performed, setting the target hardware platform for code generation to the EV22377A controller, configuring the code optimization level, configuring code generation report options, and configuring the code interface style. Then, code generation execution is performed. Simulink Coder generates corresponding C code files based on the model structure and configuration parameters, including the model main source file, model header file, model parameter file, and data type definition file. Embedded Coder further optimizes the generated code, adding target hardware-specific optimization instructions and data layouts. Afterward, code compilation configuration is performed, configuring the cross-compiler path, compiler options, linker options, etc. Finally, code compilation execution is performed, compiling the generated C code files into executable files or library files.

[0080] In this embodiment, the generated embedded C code maintains strict consistency with the original Simulink model. This is ensured through the following mechanisms: the code generation tool employs a model-based design approach, ensuring that each Simulink module has a corresponding C code implementation; the code generation process retains signal names, module names, and comment information from the model, facilitating code debugging and maintenance; the code generation tool supports traceability, allowing tracing from the generated code back to the corresponding module in the original model; and the code generation tool supports verification, automatically performing equivalence verification between the model and the code. Through these mechanisms, the simulation verification results are highly consistent with the actual controller behavior, eliminating deviations and errors that may be introduced by hand-written code and significantly shortening the productization cycle.

[0081] In one embodiment, this application also provides a MATLAB Simulink-based V2G DC charging simulation verification system for electric vehicles. The method includes the following steps: after power-on, the system completes hardware initialization and self-test; it calls the V2G protocol initialization module to complete the initialization configuration of the protocol stack and enters an idle state; it detects the CP signal status, and upon detecting a charging gun connection, it enters the physical connection establishment state and initiates the SLAC connection establishment process; after successful SLAC connection, the EVCC charging process state machine sequentially drives the execution of sub-services such as SECC discovery, application protocol negotiation, session establishment, service discovery, service and payment selection, and contract authentication; it enters the charging parameter configuration stage, calling the charging parameter discovery request module to obtain charging pile parameters. Then, the cable inspection request module is executed sequentially to perform insulation testing, and the pre-charge request module is executed to perform pre-charging. After pre-charging is completed, the power transmission state is entered, and the power transmission request module is called to start charging. During the charging process, the charging current demand request module is periodically called to update the real-time charging demand. When charging is complete, the power transmission request module is called to stop power transmission, and then the contactor adhesion detection request module is executed to perform contactor adhesion detection. Finally, the charging session end request module is called to end the charging session. Throughout the simulation process, key signals are observed in real time through the SCOPE viewer, the correctness of the fault handling logic is verified through the fault injection module, simulation data is recorded, and a verification report is generated.

[0082] In this embodiment, the MATLAB Simulink-based V2G DC charging simulation verification system for electric vehicles executes according to the following process. The first step is the system initialization phase. After the system is powered on, it executes hardware initialization and self-test programs. Hardware initialization includes configuring GPIO pin functions, configuring ADC sampling parameters, configuring communication peripherals, etc. The self-test program includes checking whether the memory is normal, checking whether the communication peripherals are normal, and checking whether key signals are normal. After the self-test passes, the V2G protocol initialization module is called to complete the initialization configuration of the protocol stack, including memory allocation, state machine initialization, timer configuration, and EXI codec initialization, etc. After initialization is completed, the system enters an idle state, waiting for the charging gun to connect.

[0083] The second step in this embodiment is the physical connection establishment phase. The system continuously monitors the status of the CP signal. When it detects that the charging gun is connected to the vehicle's charging port, the CP signal status changes from state A to state B, and the system enters the physical connection establishment state. In this state, the system completes the physical layer preparation work, including configuring PLC communication parameters and initializing the communication buffer, and then starts the SLAC connection establishment process to negotiate the link with the charging pile and establish a power line communication link.

[0084] The third step in this embodiment is the protocol interaction phase. After the SLAC connection is successful, the EVCC charging process state machine enters the protocol negotiation state and begins to execute each V2G protocol sub-service in sequence. First, the SECC discovery sub-service is executed to discover available charging pile SECCs through broadcast messages and obtain the SECC's network address; then, the application protocol negotiation sub-service is executed to negotiate the V2G protocol versions and feature sets supported by both parties with the SECC; next, the session establishment sub-service is executed to establish a V2G communication session with the SECC; then, the service discovery sub-service is executed to query the SECC for available charging service types; next, the service and payment selection sub-service is executed to select the desired charging service and payment method; finally, the contract authentication sub-service is executed to authenticate the user's identity and payment contract.

[0085] The fourth step in this embodiment is the charging parameter configuration stage. After the protocol interaction stage is completed, the system enters the charging parameter configuration state. First, the charging parameter discovery request module is called to request the charging pile's charging parameter capabilities from the SECC, including maximum output voltage, maximum output current, and maximum output power. Then, based on the charging pile parameters and vehicle battery parameters, the parameters for this charging are calculated and configured. Next, the cable inspection sub-service is executed sequentially to perform insulation testing on the charging cable and confirm that the cable connection is normal. Finally, the pre-charging sub-service is executed to establish the pre-charging process of the charging circuit and pre-charge the charging capacitor to prepare for subsequent power transmission.

[0086] The fifth step in this embodiment is the power delivery stage. After pre-charging is completed, the system enters the power delivery state. First, the power delivery request module is invoked to send a charging start request to the SECC, starting the charger to begin charging the battery. During the charging process, the system enters the charging monitoring state, periodically invoking the charging current demand request module to update the real-time charging demand to the SECC based on the current battery status, including the required current, required voltage, and required power. The SECC adjusts the charger's output according to the updated charging demand. When the battery is fully charged or the user actively stops charging, the system invokes the power delivery request module to send a charging stop request to the SECC, stopping the charger's output.

[0087] The sixth step in this embodiment is the charging completion stage. After the power transmission is completed, the system enters the charging completion state. First, the contactor adhesion detection sub-service is executed to detect adhesion of the charging contactor and confirm that the contactor can disconnect normally. Then, the charging session termination sub-service is executed to send a session termination request to the SECC and disconnect the V2G communication session. Finally, the system returns to the idle state, waiting for the next charging process. Throughout the charging process, the simulation verification unit observes the changes in key signals such as charging voltage, charging current, and SOC in real time through the SCOPE viewer. Various faults are injected through the fault injection module to verify the correctness of the fault handling logic, and the simulation data is recorded in the workspace. After the simulation is completed, the system automatically generates a verification report, recording the execution status of the charging process, the timing information of each stage, the state machine state transition records, and the test results of the fault injection.

[0088] Thus, in this application's MATLAB Simulink-based V2G DC charging simulation and verification system for electric vehicles, the complex V2G protocol stack is encapsulated into standardized MATLAB Simulink functional modules, enabling rapid development and verification of V2G charging functionality. Engineers do not need to delve into the underlying implementation details of the protocol stack; they can implement V2G communication functionality through drag-and-drop modules and simple configuration, significantly reducing the difficulty of V2G function development, shortening the development cycle, improving development efficiency by more than 50%, and reducing the development cycle by approximately 40%.

[0089] This invention enables the development of V2G functionality to be fully verified and debugged in a pure simulation environment without hardware. The verification of control strategies no longer needs to wait for the completion of hardware design, and problems can be found early in the project. The cost of defect repair is only one-tenth to one-fifth of that of problems found in the hardware stage. The number of defects found in the hardware testing stage of V2G functionality is reduced by more than 60%.

[0090] This invention uses closed-loop simulation with MATLAB Simulink and V2G protocol modules, combined with fault injection function, to systematically verify various fault triggering conditions, debouncing time, fault handling strategies, and fault recovery conditions. This effectively improves the integrity and correctness of the control strategy and ensures that the strategy meets functional safety requirements.

[0091] This invention supports rapid modification simulation verification loops, with a single iteration completed within minutes. Combined with automated test scripts, it enables continuous integration and regression testing of V2G functions, further improving development efficiency and ensuring product quality.

[0092] The V2G protocol module encapsulated in this invention follows standard interface specifications, allowing for convenient functional expansion and upgrades. As the V2G protocol evolves, only the corresponding protocol module needs to be updated to support the new version of the protocol, without the need to redevelop the entire system. Furthermore, these modules can be reused in multiple projects, reducing the development investment for subsequent projects.

[0093] This invention can complete the verification of most V2G functions in a pure software simulation environment, with almost zero hardware investment costs. At the same time, due to the shortened development cycle and reduced defects, labor costs and test verification fees are also significantly reduced, and the overall development cost can be reduced by 40% to 60%.

[0094] This invention utilizes automatic code generation technology, allowing simulation-verified models to directly generate embedded code and deploy it to actual controllers. This eliminates potential deviations and errors introduced by handwritten code, ensuring a high degree of consistency between simulation verification results and actual product behavior, and shortening the productization cycle.

[0095] The various embodiments in this specification are described in a progressive manner, with each embodiment focusing on the differences from other embodiments. The same or similar parts between the various embodiments can be referred to each other.

[0096] Those skilled in the art will understand that embodiments of this application can be provided as methods, apparatus, or computer program products. Therefore, embodiments of this application can take the form of entirely hardware embodiments, entirely software embodiments, or embodiments combining software and hardware aspects. Furthermore, embodiments of this application can take the form of computer program products implemented on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0097] The above provides a detailed description of the MATLAB Simulink-based V2G DC charging simulation and verification system for electric vehicles. Specific examples have been used to illustrate the principles and implementation methods of this application. The descriptions of the above embodiments are only for the purpose of helping to understand the method and core ideas of this application. At the same time, for those skilled in the art, there will be changes in the specific implementation methods and application scope based on the ideas of this application. Therefore, the content of this specification should not be construed as a limitation of this application.

[0098] In the several embodiments provided in this application, it should be understood that the disclosed systems, apparatuses, and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces, or indirect coupling or communication connection between apparatuses or units, and may be electrical, mechanical, or other forms.

[0099] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated units described above can be implemented in hardware or as software functional units. The above are merely embodiments of this application and do not limit the patent scope of this application. Any equivalent structural or procedural transformations made based on the description and drawings of this application, or direct or indirect applications in other related technical fields, are similarly included within the patent protection scope of this application.

[0100] The specific embodiments of the invention have been described in detail above, but they are only examples, and this application is not limited to the specific embodiments described above. For those skilled in the art, any equivalent modifications or substitutions to the invention are also within the scope of this application. Therefore, all equivalent changes, modifications, and improvements made without departing from the spirit and principles of this application should be covered within the scope of this application.

Claims

1. A simulation and verification system for V2G DC charging of electric vehicles based on MATLAB Simulink, characterized in that, include: Hardware platform, V2G protocol stack module library, EVCC charging control logic model, fault management module, and simulation verification and code generation unit; The hardware platform is a controller, including a main control chip and a communication chip; The V2G protocol stack module library is encapsulated using the MATLAB Simulink environment to form a series of standard functional modules; The EVCC charging control logic model includes a charging process state machine and control command output module, an input parameter processing module, a charging process sub-service processing module, an output parameter processing module, and a V2G information transceiver module. The fault management module performs comprehensive logical judgment on the charging process status signal, the S2 switch status signal in the CP signal, the internal logic error status signal of the EVCC, and the fault status signal reported by the BMS, and outputs a fault flag signal. The simulation verification unit is equipped with a signal observation module and supports fault injection function; The code generation unit generates embedded C code from the EVCC model that has passed simulation verification.

2. The MATLAB Simulink-based V2G DC charging simulation and verification system for electric vehicles as described in claim 1, characterized in that, Also includes: After the system is powered on, it completes hardware initialization and self-test, calls the V2G protocol initialization module to complete the initialization configuration of the protocol stack, and enters the idle state. Detect the CP signal status. When the charging gun connection is detected, enter the physical connection establishment state and start the SLAC connection establishment process. After the SLAC connection is successful, the EVCC charging process state machine sequentially drives the execution of SECC discovery, application protocol negotiation, session establishment, service discovery, service and payment selection, and contract authentication sub-services. Entering the charging parameter configuration stage, the charging parameter discovery request module is called to obtain the charging pile parameters, the cable inspection request module is executed to perform insulation detection, and the pre-charging request module is executed to perform pre-charging. After pre-charging is completed, the system enters the power transmission state, calls the power transmission request module to start charging, periodically calls the charging current demand request module to update the real-time charging demand during the charging process, calls the power transmission request module to stop power transmission when charging is complete, executes the contactor adhesion detection request module to perform contactor adhesion detection, and calls the charging session end request module to end the charging session.

3. The simulation verification system according to claim 2, characterized in that, The V2G protocol stack module library includes: The module includes: V2G protocol initialization module, V2G protocol basic function module, SECC discovery protocol request module, SECC discovery protocol response module, support application protocol request module, support application protocol response module, session establishment request module, session establishment response module, service discovery request module, service discovery response module, service and payment selection request module, service and payment selection response module, contract authentication request module, contract authentication response module, charging parameter discovery request module, charging parameter discovery response module, cable inspection request module, cable inspection response module, pre-charging request module, pre-charging response module, power delivery request module, power delivery response module, current charging demand request module, current charging demand response module, contactor adhesion detection request module, contactor adhesion detection response module, charging session end request module, and charging session end response module.

4. The simulation verification system according to claim 2, characterized in that, The V2G protocol initialization module is used to complete the memory allocation, state machine initialization, timer configuration, and EXI codec initialization of the V2G protocol stack. The V2G protocol initialization module is repeatedly called at the application layer to reset the entire protocol stack to its initial state.

5. The simulation verification system according to claim 2, characterized in that, The V2G protocol functional basic module is responsible for implementing the functions of CP signal acquisition, filtering and status judgment, including the identification of status A, B, C, D, E and F; The V2G protocol functional basic module implements the functions of establishing and maintaining SLAC connections, establishing, keeping alive, and disconnecting TCP and UDP communication links, and implementing the periodic scheduling and task management functions of the protocol stack.

6. The simulation verification system according to claim 2, characterized in that, The EVCC charging process sub-service processing module includes a request sub-service module and a response sub-service module. The request sub-service module and the response sub-service module contain a state machine, which includes a Free state, an UpdateSendData state, a WaitResponse state, a Response state, and a Fault state.

7. The simulation verification system according to claim 5, characterized in that, The state transition logic of the request-type sub-service module is as follows: Enter the Free state to clear variables and reset the state; If there are no faults and the master state machine has the corresponding command, enter the UpdateSendData stage and send the requested data out through the V2G transceiver module; Transition to WaitResponse state, awaiting a response from SECC; Upon receiving a correct response, the service enters the Response state, updates the service status to Complete, and returns to the Free state, thus completing the current sub-service. If a timeout or verification error occurs during any state transition, the system will be switched to the Fault state for processing.

8. The simulation verification system according to claim 5, characterized in that, The response sub-service module includes a data processing sub-module and a service status comprehensive output sub-module. The data processing sub-module performs protocol parsing and validity judgment of the received data, and the service status comprehensive output sub-module performs a comprehensive judgment of the final service status.

9. The simulation verification system according to claim 1, characterized in that, The implementation logic of the fault management module is as follows: By judging the charging process status signal, it is determined whether the S2 switch is closed at the specified charging process stage. If it is closed, the output is normal; if it is open, the output is faulty. Determine whether the internal logic error status of the EVCC and the fault status reported by the BMS are both normal. If both are normal, output "normal"; otherwise, output "fault".

10. The simulation verification system according to claim 1, characterized in that, The simulation verification unit sets up a SCOPE viewer, a Display module, and a To Workspace data recording module at the key signal output end of the model to perform real-time observation and post-processing analysis of charging voltage, charging current, SOC, SOH battery parameters, V2G protocol interaction message sequences and timestamps, main state machine state and sub-service state transitions, and system response after fault injection. The simulation verification unit simulates abnormal operating conditions such as communication timeout, contactor sticking, insulation fault, BMS alarm, and protocol error by setting fault injection switches or signal sources in the simulation model, in order to verify the correctness and robustness of the EVCC control logic under various abnormal conditions.

Images