Multi-standard compatible charging simulator system and method based on plug-in architecture

Abstract

The invention relates to a charging simulator system and method, in particular to a multi-standard compatible charging simulator system and method based on a plug-in architecture. The system comprises a unified hardware platform and a simulator software platform, the simulator software platform comprises a unified driving interface layer, a protocol abstraction adaptation layer and a dynamic library loading and managing device; the unified driving interface layer receives a test instruction of an upper layer and routes the test instruction to the currently loaded protocol dynamic link library through the protocol abstraction adaptation layer; the dynamic library loading and managing device is configured to be capable of creating independent and isolated contexts according to a plurality of protocol dynamic link libraries corresponding to different charging standards respectively, and capable of loading the plurality of protocol dynamic link libraries corresponding to different charging standards respectively into the runtime contexts in an isolated manner; and the unified hardware platform is used for executing the hardware operation command generated by the protocol dynamic link library. According to the invention, multi-protocol dynamic compatibility and lossless switching can be realized.

Description

Technical Field

[0001] This invention relates to a charging simulator system and method, specifically to a multi-standard compatible charging simulator system and method based on a plug-in architecture. Background Technology

[0002] With the rapid popularization of new energy vehicles globally, various incompatible charging standards have emerged in different countries and regions, including China's GB / T 27930, Japan's CHAdeMO, and Europe and the United States' CCS / ISO 15118 and DIN 70121 series. These standards differ significantly in communication protocols, physical interfaces, and charging procedures, placing higher demands on the compatibility and flexibility of testing equipment. Existing technologies mainly achieve multi-standard testing through the following two approaches: Protocol conversion scheme: For example, Chinese patent CN209372993U discloses a European standard charging pile testing system, which realizes the conversion of communication protocols between European and Chinese standards through a protocol conversion module. However, it only supports a small number of standards and cannot meet the global multi-standard testing needs.

[0003] Hardware controller integration solution: For example, Chinese patent CN117741299A proposes a multifunctional mobile DC charging pile testing system that integrates a BMS power controller, a CCS electric vehicle controller, and a CHAdeMO electric vehicle controller to support testing of four charging standards. This system achieves protocol conversion through hardware controllers, but suffers from problems such as hardware redundancy (requiring independent controllers for each standard, such as CCS and CHAdeMO controllers, resulting in high cost and complex structure) and poor scalability (hardware modification is required when adding a new standard, leading to severe software-hardware coupling).

[0004] For example, patent CN118671476A further optimizes the hardware architecture and proposes a load platform for testing various charging piles. The system includes hardware units such as contactors, adjustable loads, and voltage and current sampling modules. After identifying the type of charging gun, the main controller switches the communication mode (such as PLC or CAN) to achieve protocol switching and physical load response. This solution has strong capabilities in actual electrical characteristic testing, but its communication architecture is simple (protocol conversion is only achieved through a single CAN or PLC, which cannot support complex fault simulation scenarios, such as CAN short circuits and open circuits) and its functions are coupled (protocol conversion is bound to the test control logic, making it difficult to flexibly configure test cases).

[0005] The common shortcomings of the aforementioned existing technologies are: The protocol stack is coupled with the test scripts: the test scripts are written for specific protocols, have very poor reusability, and require rewriting a large number of scripts when the protocol changes.

[0006] Protocol stack and hardware driver coupling: Adding or upgrading a protocol requires modifying the main system software and even the hardware structure, resulting in high expansion costs and long cycles.

[0007] Multi-version protocol library conflict: The versions of third-party libraries (such as encryption libraries and encoding libraries) that different protocols depend on are incompatible and cannot coexist stably in the same system.

[0008] Weak hardware redundancy and fault simulation capabilities: Multi-controller solutions are costly and lack accurate, programmable communication fault injection capabilities.

[0009] Therefore, a solution is needed that decouples hardware and software, supports dynamic isolation loading of protocols, and provides a unified test interface to shield the underlying differences between different standards, so as to achieve low-cost and highly flexible multi-standard testing. Summary of the Invention

[0010] To address the technical problems of existing charging simulator systems, such as coupling between the protocol stack and test scripts, coupling between the protocol stack and hardware drivers, conflicts between multiple version protocol libraries, hardware redundancy, and weak fault simulation capabilities, this invention provides a multi-standard compatible charging simulator system and method based on a plug-in architecture.

[0011] To achieve the above objectives, the present invention adopts the following technical solution: A multi-standard compatible charging simulator system based on a plug-in architecture, characterized by: This includes a unified hardware platform and an simulator software platform; The simulator software platform is mounted on an external carrier and includes a unified driver interface layer, a protocol abstraction and adaptation layer, and a dynamic library loading and manager. The unified driver interface layer is used to receive test commands from the upper layer and route them to the currently loaded protocol dynamic link library through the protocol abstraction and adaptation layer. The dynamic library loader and manager is configured to create independent, isolated contexts based on multiple protocol dynamic link libraries that correspond to different charging standards, and to load multiple protocol dynamic link libraries that correspond to different charging standards into the runtime context in an isolated manner. The protocol dynamic link library is an independent functional module pre-encapsulated with all the logic of the complete charging standard; The unified hardware platform is connected to an external carrier equipped with a simulator software platform and the charging pile under test, respectively; the unified hardware platform is used to execute hardware operation commands generated by the protocol dynamic link library.

[0012] Furthermore, the dynamic library loader and manager uses the .NET AssemblyLoadContext mechanism to create the context.

[0013] Furthermore, the simulation software platform also includes a data recording module; The data recording module is used to capture and store the runtime data of the protocol abstraction adaptation layer and the protocol dynamic link library in real time.

[0014] Furthermore, the unified hardware platform includes a main control microprocessor unit, a CAN control domain, a boot / signal conditioning domain, an output coupling / interface group, and a PLC / isolation communication module; The CAN control domain is a dual-channel CAN FD bus controller that integrates two completely independent high-speed CAN FD channels; The first high-speed CAN FD channel is a hardware control CAN channel used to transmit hardware operation commands; The second high-speed CAN FD channel is a protocol communication CAN channel used to transmit application layer protocol messages; The input terminal of the main control microprocessor unit is connected to an external carrier equipped with a simulator software platform through a first high-speed CAN FD channel, and the output terminal is connected to the output coupling / interface group through a second high-speed CAN FD channel and a PLC / isolation communication module, respectively. The main control microprocessor unit is used to receive hardware operation instructions and schedule the CAN control domain, the boot / signal conditioning domain and the PLC / isolation communication module according to the hardware operation instructions. The guidance / signal conditioning domain is used to switch controllable guidance signals according to the selected protocol to simulate different vehicle states and charging needs; The PLC / isolation communication module integrates a PLC modem chip and its coupling circuit that conform to the HomePlug Green PHY standard, for processing power line carrier communication as specified in European and American standard protocols; The output coupling / interface group is used to achieve a physical connection with the charging pile under test via the charging gun line.

[0015] Furthermore, the unified hardware platform also includes a fault injection and simulation unit; The fault injection and simulation unit is used to simulate faults under the scheduling of the main control microprocessor unit. The faults include communication faults, signal faults, and protocol faults.

[0016] Meanwhile, this invention also provides a multi-standard compatible charging simulation method based on a plug-in architecture, employing the aforementioned multi-standard compatible charging simulator system based on a plug-in architecture, characterized by the following steps: Step 1: Mount the simulator software platform on an external carrier and connect the unified hardware platform to the charging pile to be tested. The external carrier contains multiple protocol dynamic link libraries that correspond to different charging standards. Step 2: Receive test commands from the upper layer through the unified driver interface layer, and abstractly call the protocol abstraction adaptation layer according to the test commands; Step 3: Output the request loading context and the instructions to call the protocol dynamic link library through the protocol abstraction adaptation layer; Step 4: Based on the request, load the context through the dynamic library loader and manager, and call the protocol dynamic link library. Create an independent and isolated context, and load the protocol dynamic link library of the charging standard into the runtime context in an isolated manner. Generate hardware operation commands through the protocol dynamic link library and output them to the unified hardware platform. Step 5: Execute hardware operation commands through a unified hardware platform.

[0017] Furthermore, during the execution of any of steps 1 to 5, fault injection tests are selectively performed through fault injection and simulation units.

[0018] Furthermore, in step 1, when it is necessary to expand the charging test standard, a new protocol dynamic link library corresponding to the new charging standard is added, specifically including the following steps: S1. Develop a new protocol dynamic link library that conforms to the unified driver interface layer; S2. Deploy the new protocol dynamic link library file to the specified plugin directory in the external carrier; S3. Load the new protocol dynamic link library into the independent runtime context through the dynamic library loader and manager.

[0019] The beneficial effects of this invention are: 1. Achieve true multi-protocol dynamic compatibility and lossless switching: By encapsulating the protocol stacks of each charging standard into independent protocol dynamic link libraries (DLLs), and utilizing runtime isolation loading mechanisms such as .NET AssemblyLoadContext, an independent loading context is created for each DLL. This not only enables hot-swapping of protocols but also completely resolves the version conflict issue of third-party libraries that different protocols depend on, achieving low-cost software-level expansion and security isolation, and significantly improving system compatibility and flexibility.

[0020] 2. Completely decouple test scripts from underlying protocols to improve reusability and development efficiency: By providing a unified driver interface layer independent of charging standards, abstract methods are provided to upper-layer test scripts. Testers only need to write scripts based on this general interface without needing to care about the specific underlying protocols, achieving high reusability of test scripts across protocols, significantly reducing script development and maintenance costs, and improving test automation capabilities.

[0021] 3. Reduce hardware redundancy and system cost, and improve integration: Adopting a highly integrated unified hardware platform (single-board architecture), all standards share a single EVSE control board. Through a dual-channel CAN FD design (one channel dedicated to hardware control commands, and the other dedicated to application layer protocol message pass-through), and supporting dynamic switching of control strategies according to protocol modules, it replaces the multi-controller discrete solution, significantly reducing hardware costs, shrinking device size, and improving system integration and reliability.

[0022] 4. Enhanced Complex Fault Simulation and Precise Testing Capabilities: The unified hardware platform integrates a software-controlled fault simulation unit, capable of dynamically simulating complex fault scenarios such as CAN bus short circuits, open circuits, and grounding. Combined with the physical isolation characteristics of dual CAN channels, it supports more realistic and comprehensive fault injection testing, meeting the needs of high reliability testing and diagnosis.

[0023] 5. Enhanced System Scalability and Maintainability: When adding or upgrading charging standards, developers only need to develop new protocol DLLs following the unified interface specification and deploy them to the plugin directory. No modifications to the main system software, test scripts, or hardware structure are required, enabling low-cost, rapid iterative expansion and significantly improving the system's ability to adapt to future standard evolutions. Attached Figure Description

[0024] Figure 1 This is a schematic diagram showing the connection between the unified hardware platform and the simulator software platform and the vehicle or charging pile to be tested in an embodiment of a multi-standard compatible charging simulator system based on a plug-in architecture according to the present invention. Figure 2 This is a diagram showing the composition relationship between the unified hardware platform and the simulator software platform in this embodiment of the invention; Figure 3 This is a diagram showing the composition of the simulator software platform in this embodiment of the invention; Figure 4 This is a schematic diagram of S301 of the simulation process of the European and American standard charging process in the embodiment of the present invention; Figure 5 This is a schematic diagram of S302 of the simulation process of the European and American standard charging process in the embodiment of the present invention; Figure 6 This is a schematic diagram of S303 of the simulation process of the European and American standard charging process in the embodiment of the present invention; Figure 7 This is a schematic diagram of S304 of the simulation process of the European and American standard charging process in the embodiment of the present invention; Figure 8 This is a schematic diagram of S305 of the simulation process of the European and American standard charging process in the embodiment of the present invention; Figure 9 This is a schematic diagram of S401 of the protocol extension implementation process in an embodiment of the present invention; Figure 10 These are schematic diagrams of S402 and S403 of the protocol extension implementation process in this embodiment of the invention; Figure 11 This is a schematic diagram of S404 of the protocol extension implementation process in an embodiment of the present invention; Figure 12 This is a schematic diagram of S405 of the protocol extension implementation process in an embodiment of the present invention; Figure 13 This is a schematic diagram of S406 of the protocol extension implementation process in an embodiment of the present invention. Detailed Implementation

[0025] The technical solution of the present invention will be clearly and completely described below with reference to the accompanying drawings and embodiments. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0026] See Figure 1 The present invention provides a multi-standard compatible charging simulator system based on a plug-in architecture, which mainly includes two parts: a unified hardware platform (hardware architecture) and a simulator software platform (software architecture).

[0027] The simulator software platform is mounted on an external carrier and includes a unified driver interface layer, a protocol abstraction and adaptation layer, and a dynamic library loading and management system.

[0028] The unified driver interface layer receives test commands from the upper layer and routes them to the currently loaded protocol dynamic link libraries through the protocol abstraction and adaptation layer. The dynamic library loading and manager is configured to create independent and isolated contexts based on multiple protocol dynamic link libraries corresponding to different charging standards, and to load multiple protocol dynamic link libraries corresponding to different charging standards into the runtime context in an isolated manner. The protocol dynamic link libraries are independent functional modules that pre-encapsulate all the logic of the complete charging standard. The unified hardware platform connects to the external carrier equipped with the simulator software platform and the charging pile under test. The unified hardware platform is used to execute hardware operation commands generated by the protocol dynamic link libraries to achieve simulated charging.

[0029] Hardware architecture like Figure 2 As shown, the present invention provides a highly integrated unified hardware platform (EVSE control board), which connects to an external carrier running simulator software and the charging pile to be tested through various interfaces.

[0030] The unified hardware platform adopts a single-board integrated architecture, which mainly includes the following components: Main control microprocessor unit: As the platform control center, it is responsible for scheduling various functional domains (CAN control domain, fault injection and simulation unit, boot / signal conditioning domain and PLC / isolation communication module, etc.) and exposing a unified control and diagnostic interface to the outside world.

[0031] The CAN control domain is a dual-channel CAN FD bus controller: integrating two completely independent high-speed CAN FD channels. The first channel is the hardware control CAN channel, used to communicate with the running simulator software and transmit hardware operation commands.

[0032] The second channel is the CAN communication channel, used to process message pass-through that conforms to the CAN bus application layer protocol (such as the Chinese national standard GB / T27930 and the Japanese standard CHAdeMO).

[0033] The input of the main control microprocessor unit is connected to an external carrier equipped with a simulator software platform through the first high-speed CAN FD channel, and the output is connected to the output coupling / interface group through the second high-speed CAN FD channel and the PLC / isolation communication module.

[0034] Fault injection and simulation unit: used to simulate faults under the scheduling of the main control microprocessor unit, including communication faults, signal faults and protocol faults.

[0035] Signal control and conditioning unit: Switches controllable guide signals according to the selected protocol. For example, European and American standards can generate precise control guide (CP) PWM signals. The voltage range, frequency and duty cycle of these signals can be precisely programmed and controlled by software to simulate different vehicle states and charging needs.

[0036] Communication interface set: CAN interface: Corresponds to dual-channel CAN FD controllers.

[0037] Ethercat interface: Enables future expansion to achieve high-precision synchronous control or connect more IO modules, thereby enhancing system scalability.

[0038] USB interface: used for system debugging, log downloading, and as an auxiliary communication channel.

[0039] PLC / Isolated Communication Module: Integrates a PLC modem chip and its coupling circuit that conforms to the HomePlug Green PHY standard, used for handling power line carrier communication as specified in European and American standard protocols. This module achieves message transmission through coupling with the output interface.

[0040] Output interfaces include DC high voltage terminals (DC+, DC-), CP / PP signal terminals, communication lines (CAN_H, CAN_L), etc., using standard connectors that match the vehicle charging interface, for physical connection to the charging pile under test via the charging gun line.

[0041] Software architecture diagram like Figure 3 As shown, the vehicle simulator software adopts a layered, plug-in architecture to achieve protocol stack isolation and dynamic loading. It mainly includes the following layers and modules: Unified Driver Interface Layer: This is the sole programming interface provided to upper-level test scripts or automated testing frameworks. It defines a set of abstract methods independent of charging standards, such as: SelectSimulator(simulator type, standard type), ConfigMessage(message name, parameter name array, value array, period), StartCharging(charging phase), StopCharging(stopping phase), SetPilot(signal type, signal amplitude, frequency, duty cycle), SetLine(signal type, signal state), ProcessStage(out current test phase), ChargingRequest(mode, voltage, current), etc., serving as the sole entry point for test scripts. Testers only need to write scripts based on these general interfaces, completely unconcerned about the specific standard implemented at the lower level.

[0042] Protocol Abstraction Adapter Layer: This layer acts as a bridge between the unified interface and the specific protocol implementation. It receives general calls from the unified interface and translates them into instructions for calling a specific protocol dynamic link library (DLL) at the underlying level.

[0043] Dynamic Library Loader and Manager: This module is responsible for the lifecycle management of DLLs. It is built upon the .NET AssemblyLoadContext mechanism. When a standard (such as a European standard) protocol DLL needs to be loaded, the manager creates a separate, isolated context (AssemblyLoadContext) for it. This means: Dependency isolation: Each protocol's DLL and all its private dependencies (such as specific versions of the CAN library, encryption library, and EXI encoding library) are loaded into their own sandbox-like contexts, without interfering with each other, completely resolving the issue of third-party library version conflicts.

[0044] Hot-swappable: Supports dynamic loading, unloading, or replacement of a protocol's DLL at runtime without restarting the main program, greatly facilitating protocol debugging, updates, and expansion.

[0045] Protocol Dynamic Link Libraries (DLLs) (1013a, 1013b, 1013c, ...): Each DLL encapsulates all the logic of a complete charging standard and is an independent functional module.

[0046] Data logging module: Captures and stores all messages, signal changes, events and errors throughout the entire test process in real time, with timestamps.

[0047] This architecture supports rapid expansion to future standards, requiring only the replacement of DLLs. At the same time, the test scripts are isolated from the protocol stack, which can improve script reusability.

[0048] Charging process simulation method Step 1: Connect the unified hardware platform to the charging station to be tested; Step 2: Receive test commands from the upper layer through the unified driver interface layer, and abstractly call the protocol abstraction adaptation layer according to the test commands; Step 3: Output the request loading context and the instructions to call the protocol dynamic link library through the protocol abstraction adaptation layer; Step 4: Using the dynamic library loader and manager, load the context according to the request and the instruction to call the protocol dynamic link library, create an independent and isolated context, and be able to load the protocol dynamic link library of the charging standard into the runtime context in isolation. Generate hardware operation commands through the protocol dynamic link library and output them to the unified hardware platform. Step 5: Execute hardware operation commands through a unified hardware platform to achieve simulated charging.

[0049] In this embodiment of the invention, combined with Figures 4-8 The flowchart shown illustrates the steps of a system simulating a complete charging test according to European and American standards: S301: Initialization The test script calls the SelectSimulator (CCS2EV, ISO15118DC) method through a unified interface, specifying the simulator type and test standard.

[0050] The simulator software loads and activates the European standard DLL through the dynamic library manager.

[0051] S302: Protocol Handshake and Parameter Configuration The test script calls the StartCharging method through a unified interface to specify the simulator to start the charging process.

[0052] The European standard DLL calls the SetPilot interface and communicates with the EVSE control board through the CAN1 channel, outputting a specific CP voltage (9V±1V) to simulate the vehicle's plug-in behavior.

[0053] The EVSE control board monitors the CP signal duty cycle, confirms that the physical connection has been established, and reports this status to the vehicle simulator.

[0054] The European standard DLL communicates with the EVSE control board via the CAN2 channel. The messages are converted by the PLC module to initiate a communication establishment sequence (SLAC process) and complete the power line network pairing with the charging pile.

[0055] After successful pairing, both parties perform a TLS handshake, exchange supported services and payment methods (EXI encoding), and complete authentication and payment preprocessing (in a simulated manner).

[0056] S303: Charging Start-up and Power Transfer The European standard DLL initiates an insulation test and pre-charge request. Upon successful completion, it sends a PowerDeliveryReq request, instructing the charging station to close the contactor and begin outputting electrical energy.

[0057] During the charging process, the European standard DLL periodically sends a "CurrentDemandReq" message to request specific current / voltage values ​​to simulate real vehicle battery behavior.

[0058] The test script can call the parameters of ChargingRequest(mode, voltage, current) at runtime to test the dynamic response capability of the charging pile. S304: Exception Injection Test (Optional) The test script can call the SetLine(signal type, signal state) interface and ConfigMessage(message name, parameter name array, value array, period) at any step to inject various faults, such as: Communication failure: Disconnect the CAN line or short-circuit the PLC signal through the fault simulation unit.

[0059] Signal Fault: The signal control and conditioning unit suddenly sets the CP PWM signal to 0V or 12V, simulating a disconnection.

[0060] Protocol failure: By configuring various message contents, the timing can be guided to different processing branches or a message timeout failure can be simulated.

[0061] S305: Normal Termination and Report Generation The test script calls the StopCharging (active shutdown) interface, and the European standard DLL generates a "SessionStopReq" message to notify the charging pile to stop output and disconnect the contactor.

[0062] All messages, signal changes, events, and errors throughout the process are captured and stored in real time by the data logging module.

[0063] After the test is completed, a custom report (Word) can be edited through the Automated Test Host Computer (ATS) or the TestReport (report name) interface can be called by the test script to generate a structured report (Html) and output the test results (pass / fail).

[0064] Protocol Extension Implementation Combination Figures 9-13 The flowchart shown illustrates the steps for extending the system and testing a new charging standard (such as Standard X): S401: Developing a new protocol dynamic library Based on the unified driver interface layer specification provided by this invention, a protocol implementation for a new target charging standard (such as a future standard X) is developed. This implementation needs to fully encapsulate the protocol stack logic of the new standard, including but not limited to: message encoding / decoding, state machine management, timeout handling, security algorithms, etc., and compile it into a standalone dynamic link library (standardX.dll). This DLL does not need to concern itself with the underlying hardware operations; it only needs to interact with the system through the specifications defined in the interface layer.

[0065] S402: Deployment Plugin Copy the compiled new protocol dynamic library file (standard X.dll) and any of its private dependencies to the plugin directory specified by the emulator software. No need to modify the main program or reinstall the system.

[0066] S403: System Automatic Discovery and Loading When the emulator software starts, its dynamic library loader and manager automatically scans the plugin directory. Upon discovering a new DLL, the manager uses the .NET AssemblyLoadContext mechanism to create a new, independent loading context for it and loads the DLL and its dependencies into the runtime environment in isolation. This process is transparent to the user and does not affect the stable operation of existing loaded protocol modules.

[0067] S404: Selecting and Invoking a New Protocol User or upper-layer test scripts call the SelectSimulator() method of the unified driver interface, passing in the identifier of the new standard (such as standard X). After receiving the instruction, the protocol abstraction adaptation layer routes it to the newly loaded standard X.dll instance.

[0068] S405: Execute new protocol test From this point onward, all operation commands initiated through the unified interface (such as StartCharging(), ConfigMessage(), etc.) will be processed by the standard X.dll. This DLL generates corresponding message sequences or hardware operation commands according to the new standard's specifications, which are then executed through the system driver's unified hardware platform, thereby realizing a complete testing process for charging piles supporting the new standard.

[0069] S406: Verification and Maintenance All data generated during testing by the new protocol module is also captured uniformly by the data logging module. Developers can debug and optimize the new protocol DLL based on the test results; updates can be completed simply by replacing the DLL file, achieving low-cost iteration and maintenance of the protocol.

[0070] The above description is merely a specific embodiment of the present invention, but the scope of protection of the present invention is not limited thereto. Any changes or substitutions within the technical scope disclosed in the present invention should be covered within the scope of protection of the present invention. Therefore, the scope of protection of the present invention should be determined by the scope of the claims.

Claims

1. A multi-standard compatible charging simulator system based on a plug-in architecture, characterized in that: it comprises a unified hardware platform and a simulator software platform; the simulator software platform is carried in an external carrier and comprises a unified driving interface layer, a protocol abstract adaptation layer, and a dynamic library loading and manager; the unified driving interface layer is configured to receive test instructions from an upper layer and route them to a currently loaded protocol dynamic link library through the protocol abstract adaptation layer; the dynamic library loading and manager is configured to create independent and isolated contexts according to a plurality of protocol dynamic link libraries corresponding to different charging standards respectively, and to load the plurality of protocol dynamic link libraries corresponding to different charging standards respectively into the contexts at runtime; the protocol dynamic link library is an independent functional module pre-encapsulating all logic of a complete charging standard; the unified hardware platform is connected with the external carrier carrying the simulator software platform and a charging pile to be tested respectively; and the unified hardware platform is configured to execute hardware operation commands generated by the protocol dynamic link library.

2. The multi-standard compatible charging simulator system based on the plug-in architecture according to claim 1, characterized in that: the dynamic library loading and manager uses the AssemblyLoadContext mechanism of.NET to create the contexts.

3. The multi-standard compatible charging simulator system based on the plug-in architecture according to claim 2, characterized in that: the simulator software platform further comprises a data recording module; and the data recording module is configured to capture and store running data of the protocol abstract adaptation layer and the protocol dynamic link library in real time.

4. The multi-standard compatible charging simulator system based on the plug-in architecture according to any one of claims 1-3, characterized in that: the unified hardware platform comprises a master microprocessor unit, a CAN control domain, a boot / signal conditioning domain, an output coupling / interface group, and a PLC / isolation communication module; the CAN control domain is a dual-CAN FD bus controller integrating two completely independent high-speed CAN FD channels; a first high-speed CAN FD channel is a hardware control CAN channel for transmitting hardware operation instructions; a second high-speed CAN FD channel is a protocol communication CAN channel for transmitting application layer protocol messages; an input end of the master microprocessor unit is connected with the external carrier carrying the simulator software platform through the first high-speed CAN FD channel, and an output end thereof is connected with the output coupling / interface group through the second high-speed CAN FD channel and the PLC / isolation communication module respectively; the master microprocessor unit is configured to receive hardware operation instructions and dispatch the CAN control domain, the boot / signal conditioning domain, and the PLC / isolation communication module according to the hardware operation instructions; the boot / signal conditioning domain is configured to switch controllable boot signals according to a selected protocol to simulate different states and charging requirements of a vehicle; and the PLC / isolation communication module integrates a PLC modem chip and a coupling circuit thereof conforming to the HomePlug Green PHY standard and is configured to process power line carrier communication specified in the European and American standards protocol. ​ ​ ​ ​ ​ ​ ​ ​ ​ ​ ​ ​ ​ ​ ​ ​ ​ The output coupling / interface group is used to realize physical connection with the charging pile to be tested through the charging gun line. 5.The multi-standard compatible charging simulator system based on the plug-in architecture according to claim 4, characterized in that: The unified hardware platform further comprises a fault injection and simulation unit. The fault injection and simulation unit is used to simulate faults under the scheduling of the master microprocessor unit, and the faults include communication faults, signal faults and protocol faults.

6. A multi-standard compatible charging simulation method based on a plug-in architecture, using the multi-standard compatible charging simulator system based on a plug-in architecture according to any one of claims 1 to 5, characterized by, The method comprises the following steps: Step 1, the simulator software platform is carried in an external carrier, and the unified hardware platform is communicatively connected with the charging pile to be tested. The external carrier loads a plurality of protocol dynamic link libraries corresponding to different charging standards respectively; Step 2, the test instruction of the upper layer is received through the unified driving interface layer, and the protocol abstract adaptation layer is called according to the test instruction; Step 3, the request loading context and the instruction of calling the protocol dynamic link library are output through the protocol abstract adaptation layer; Step 4, the request loading context and the instruction of calling the protocol dynamic link library are loaded according to the request through the dynamic library loading and manager, an independent and isolated context is created, the protocol dynamic link library of the charging standard is loaded into the context of runtime in isolation, the hardware operation command is generated through the protocol dynamic link library, and the hardware operation command is output to the unified hardware platform; Step 5, the hardware operation command is executed through the unified hardware platform. 7.The multi-standard compatible charging simulation method based on the plug-in architecture according to claim 6, characterized in that: During the execution of any one of steps 1 to 5, the fault injection and simulation unit selectively performs fault injection testing.

8. The multi-standard compatible charging emulation method based on the plug-in architecture according to claim 6 or 7, characterized in that, In step 1, when it is necessary to expand the charging test standard, a new protocol dynamic link library corresponding to a new charging standard is added, which specifically comprises the following steps: S1, a new protocol dynamic link library conforming to the unified driving interface layer is developed; S2, the new protocol dynamic link library file is deployed to the specified plug-in directory in the external carrier; S3, the new protocol dynamic link library is loaded into an independent runtime context through the dynamic library loading and manager.

Images