Charging pile end communication platform, data interaction method and charging pile

Abstract

The invention relates to the technical field of charging piles, and discloses a charging pile end communication platform, a data interaction method and a charging pile, and the architecture comprises a service layer, a business layer and a communication layer. The service layer comprises a plurality of independent service modules; each service module is used for monitoring a corresponding trigger event in the operation process of the charging pile and generating corresponding business data; the service layer is used for receiving the service data of the service layer, carrying out message processing, and establishing and maintaining a service context for recording a communication state in the processing process; and the communication layer is used for packaging the processed service data into an uplink transmission frame, sending the uplink transmission frame to a remote platform, performing type identification on the received downlink transmission frame, and executing a corresponding recombination strategy according to an identification result so as to restore the downlink transmission frame into a complete application layer message and then transmit the complete application layer message to the service layer, thereby completing bidirectional communication interaction with the remote platform.

Description

Technical Field

[0001] This application relates to the field of charging pile technology, and in particular to a charging pile terminal communication platform, data interaction method and charging pile. Background Technology

[0002] With the rapid development of new energy vehicles, the Open Charging Protocol (OCPP) 2.0 has become the mainstream international communication standard, offering significant improvements in functional completeness and security compared to OCPP 1.6. This protocol expands the number of functional modules from 6 to 16, the number of protocol messages from 28 to 64, and the number of configuration items from 44 to 143. It also changes the descriptions of core functional modules in OCPP 1.6, instead defining each module independently and clearly. The original comprehensive functions are broken down into multiple specialized modules, leading to a significant increase in system complexity. However, OCPP 2.0 only provides theoretical specifications for communication processes and message formats, without addressing the specific implementation architecture, posing challenges for charging pile manufacturers in technology implementation. Traditional software architectures based on OCPP 1.6 are no longer adequate for the high concurrency, multi-scenario, and high security requirements of the new version. Summary of the Invention

[0003] In view of this, embodiments of this application provide a charging pile terminal communication platform, a data interaction method, and a charging pile.

[0004] In a first aspect, embodiments of this application provide a charging pile terminal communication platform, including: a service layer, a business layer, and a communication layer; The service layer includes multiple independent service modules; Each of the aforementioned service modules is used to monitor the corresponding trigger events during the operation of the charging pile and generate corresponding business data; The service layer is used to receive the service data from the service layer and process the messages, and to establish and maintain a service context that records the communication status during the processing. The communication layer is used to encapsulate the processed service data into uplink transmission frames and send them to the remote platform. At the same time, it performs type identification on the received downlink transmission frames and executes the corresponding reassembly strategy according to the identification result to restore them into complete application layer messages before transmitting them to the service layer, so as to complete the bidirectional communication interaction with the remote platform.

[0005] In an optional implementation, the service layer further includes a service center; The service center includes a port class table; the port class table is used to record all the service modules and their corresponding service ports; when any of the service modules generates the business data and submits it to its distribution queue, the service center retrieves the business data from the distribution queue and forwards the business data to one or more service modules that have subscribed to the current business data source and the business layer according to the corresponding service port subscription class table; if there is no subscriber, the business data is transmitted to the business layer.

[0006] In an optional implementation, the service center and the business layer interact with each other through an inter-layer communication interface, which includes a consumption queue for caching downlink business data passed down by the business layer. When the service center obtains the downlink service data from the consumption queue of the inter-layer communication interface, it parses the target service identifier in the downlink service data and queries the port class table to determine whether the corresponding service module has been registered. If already registered, the downlink service data is written into the service port consumption queue of the corresponding service module, and the downlink service data is shared with other subscribed service modules according to the corresponding service port subscription class table.

[0007] In an optional implementation, the business layer includes a context factory, a context queue, and the context task scheduler; The context factory is used to create a context object for each communication interaction and store the context object in the context queue; wherein, the context object includes an initiator, data context, transmission mode, service identifier, and expected response deadline; The context task scheduler is used to poll the context queue at preset time intervals to determine whether there is a context object that exceeds the expected response deadline. If there is, the current context object is marked as a timeout task and a retransmission task is triggered.

[0008] In an optional implementation, the triggering of the retransmission task specifically includes: for the timeout task in the uplink direction, retransmitting according to the retry method specified in the preset charging protocol; for the timeout task in the downlink direction, calling the corresponding service data stored in the context queue, reconstructing the response context, and generating a corresponding acknowledgment response message to be sent back to the remote platform.

[0009] In an optional implementation, the communication layer includes a connection checking module, a processing module, and a communication layer task scheduler; The communication layer task scheduler is configured to periodically run multiple communication tasks; wherein, the communication tasks include fragmentation tasks, packet assembly tasks, connection detection tasks, and activity detection tasks; Before each execution of the sharding task or the activity detection task, if the connection checking module determines that no open WebSocket connection or encrypted WebSocket connection has been established according to the preset security policy, then the connection reconstruction process is triggered. The processing module is used to perform fragmentation and encapsulation on uplink data and send it through a non-blocking interface, perform type identification on received downlink data frames and execute corresponding reassembly strategies based on the type identification results; wherein, the fragmentation and encapsulation operation is triggered by the fragmentation task, and the parsing and submission of downlink data is driven by the packet assembly task; the type identification results include heartbeat packets, reconnection packets and data packets.

[0010] In an optional implementation, if the type identification result is the data packet, the processing module performs corresponding processing based on the identified type, including: If the downlink data is a single packet, it is submitted to the inter-layer communication queue of the service layer; If the downlink data is multi-packet data, then after all fragments arrive, perform packet reassembly to restore it into a complete application layer message and submit it to the inter-layer communication queue of the service layer. If the downlink data is concatenated data, then the multiple tightly arranged application layer messages are sequentially split into independent messages and submitted to the inter-layer communication queue of the service layer respectively. If the downlink data is mixed packet data, then the corresponding reassembly strategy is executed for each type of data in the mixed packet data, and submitted to the inter-layer communication queue of the service layer respectively.

[0011] In an optional implementation, each of the service modules interacts with the charging pile main control program by calling a predefined application programming interface; wherein, the application programming interface includes an acquisition interface function and a distribution interface function; The acquisition interface function is used to obtain specified data from the charging pile main control program; The aforementioned interface function is used to send operation instructions to the main control program of the charging pile.

[0012] Secondly, embodiments of this application provide a data interaction method, the method being applied to the aforementioned charging pile terminal communication platform, comprising: Each service module monitors the triggering events during the operation of the charging pile, generates corresponding business data, and submits it to the corresponding service port's distribution queue. The service center retrieves the business data from the distribution queue, queries the service port subscription class table corresponding to the current business data, and transmits the business data to the business layer; If a service module has been subscribed to, the business data will be forwarded to the consumption queue corresponding to the subscribed service module. If no subscribed service module exists, the business data will be transmitted to the business layer. The business layer performs protocol message encapsulation on the business data and creates a context object containing the expected response deadline, which is then stored in the context queue. The context task scheduler periodically scans the context queue, identifies tasks that exceed the expected response deadline, and triggers retransmission tasks.

[0013] Thirdly, embodiments of this application provide a charging pile, including a charging pile main control program and a processor; The processor runs the aforementioned charging pile terminal communication platform; The charging pile terminal communication platform interacts with the charging pile main control program through an application programming interface.

[0014] The embodiments of this application have the following beneficial effects: By constructing a multi-layered communication software architecture comprising a service layer, a business layer, and a communication layer, this application enables efficient and reliable bidirectional communication between the charging pile and the remote platform. Specifically, the service layer employs multiple independent service modules to monitor various triggering events during the charging pile's operation and generate corresponding business data, thereby improving the independence and maintainability of the functional modules. The business layer encapsulates, parses, and manages the status of received business data. By establishing and maintaining a business context, it can accurately track the status of each communication interaction, ensuring the integrity of the communication process. The communication layer possesses the ability to encapsulate uplink data transmission frames and the ability to identify and reassemble downlink transmission frames, adapting to various data transmission forms in complex network environments. The overall architecture of this application, through a clear layered design, achieves functional decoupling, with each layer having distinct responsibilities and working collaboratively. This not only improves the system's stability and response efficiency but also enhances its ability to cope with network fluctuations and protocol complexity in actual deployment, thereby enabling the stable operation of the OCPP2.0 protocol. Attached Figure Description

[0015] To more clearly illustrate the technical solutions of the embodiments of this application, the accompanying drawings used in the embodiments will be briefly introduced below. It should be understood that the following drawings only show some embodiments of this application and should not be regarded as a limitation of the scope. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort.

[0016] Figure 1 A schematic diagram of a charging pile terminal communication platform according to an embodiment of this application is shown; Figure 2 A schematic diagram of the service layer structure according to an embodiment of this application is shown; Figure 3 This illustration shows a schematic diagram of the service center's scheduling process for the data to be distributed after the service completes the business data processing, according to an embodiment of this application. Figure 4 This diagram illustrates the service center's process for handling inter-layer communication data and the subscription and sharing of inter-service linkage / private data. Figure 5 A schematic diagram of the business layer structure according to an embodiment of this application is shown; Figure 6 A schematic diagram of the communication layer structure according to an embodiment of this application is shown; Figure 7 This illustration shows a schematic diagram of the service module of this application interacting with the charging pile main control program through an application programming interface; Figure 8 This application illustrates a schematic diagram of the upstream business data reporting process according to an embodiment of the present application. Figure 9 A schematic diagram of the downlink service data processing flow according to an embodiment of this application is shown; Figure 10 A flowchart illustrating a data interaction method according to an embodiment of this application is shown. Detailed Implementation

[0017] The technical solutions in the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments.

[0018] The components of the embodiments of this application described and illustrated in the accompanying drawings can be arranged and designed in a variety of different configurations. Therefore, the following detailed description of the embodiments of this application provided in the drawings is not intended to limit the scope of the claimed application, but merely to illustrate selected embodiments of the application. All other embodiments obtained by those skilled in the art based on the embodiments of this application without inventive effort are within the scope of protection of this application.

[0019] In the following text, the terms "comprising," "having," and their cognates, which may be used in various embodiments of this application, are intended only to indicate a particular feature, number, step, operation, element, component, or combination thereof, and should not be construed as primarily excluding the presence of one or more other features, numbers, steps, operations, elements, components, or combinations thereof, or adding the possibility of one or more combinations thereof. Furthermore, the terms "first," "second," "third," etc., are used only for distinguishing descriptions and should not be construed as indicating or implying relative importance.

[0020] Unless otherwise specified, all terms used herein (including technical and scientific terms) shall have the same meaning as commonly understood by one of ordinary skill in the art to which the various embodiments of this application pertain. Terms (such as those defined in commonly used dictionaries) shall be interpreted as having the same meaning as in their contextual meaning in the relevant technical field and shall not be construed as having an idealized or overly formal meaning, unless clearly defined in the various embodiments of this application.

[0021] The following detailed description of some embodiments of this application is provided in conjunction with the accompanying drawings. Unless otherwise specified, the following embodiments and features can be combined with each other.

[0022] The following describes the communication platform for the charging pile using specific embodiments.

[0023] Figure 1 A schematic diagram of a charging pile terminal communication platform according to an embodiment of this application is shown. Exemplarily, the charging pile terminal communication platform includes a service layer, a business layer, and a communication layer. Data interaction between the layers is achieved through well-defined interfaces, thereby realizing functional decoupling and independent module operation.

[0024] The service layer, located at the top of the architecture, is responsible for interfacing with the charging pile's main control program, sensing changes in device operating status, and generating corresponding OCPP2.0 protocol business processes. The business layer, located in the middle layer, is responsible for processing business data from the service layer or downlink messages from the communication layer, executing the encapsulation, parsing, verification, and context management operations specified by the protocol. The communication layer, located at the bottom layer, is responsible for establishing connections with remote platforms, completing data frame fragmentation, transmission, reception, reassembly, and connection state maintenance.

[0025] like Figure 2As shown, the service layer includes multiple independent service modules; there are sixteen service modules, each corresponding to one of the sixteen functional modules defined by the OCPP2.0 protocol, including but not limited to authentication service, diagnostic service, remote update service, configuration management service, charging control service, transaction processing service, etc. Each service module has the same internal structure design, including a business scheduler, data cache management unit, uplink / downlink processing unit, subscription class table, application programming interface (API interface) and service port.

[0026] Each service module monitors corresponding trigger events during the operation of the charging pile and generates corresponding business data. Essentially, each service module obtains relevant status information during the charging pile's operation by calling predefined application programming interfaces (APIs) to detect trigger events. Trigger events include, but are not limited to, plug-in signal, plug-out signal, start charging command, stop charging request, fault alarm, billing start, billing end, and time synchronization requirements. When a service module detects a related trigger event through the API interface, its internal business scheduler generates the corresponding business process based on the current scenario and fills in the necessary business parameters to form business data. After filling in the parameters, the service module records the business data to be transmitted, along with the initiator identifier, business identifier, and data context, into its local buffer and submits it to the distribution queue of its service port, awaiting unified scheduling and processing by the service center.

[0027] The service layer also includes a service center; the service center maintains a port class table; the port class table is used to record all service modules and their corresponding service ports; when any service module generates business data and submits it to its distribution queue, the service center retrieves the business data from the distribution queue and forwards the business data to one or more service modules and business layers that have subscribed to the current business data source according to the corresponding service port subscription class table; if there is no subscriber, the business data is transmitted to the business layer.

[0028] The service center and the business layer interact with each other through an inter-layer communication interface. This interface includes a consumption queue, which is used to cache downlink business data passed down from the business layer. When the service center obtains downlink business data from the consumption queue of the inter-layer communication interface, it parses the target service identifier in the downlink business data and queries the port class table to determine whether the corresponding service module has been registered. If it has been registered, the downlink business data is written to the service port consumption queue of the corresponding service module, and the downlink business data is shared with other subscribed service modules according to the corresponding service port subscription class table. At the same time, the business data is transmitted to the business layer.

[0029] Exemplarily, after obtaining business data, the service center first performs basic format verification on the business data. If it is found that there are obvious errors in the business data, the data is released and a log is recorded; if the verification passes, the service port subscription class table associated with the service port from which the business data is sourced is further queried. Among them, this subscription class table is used to record which other service modules have subscribed to the data content published by this service port.

[0030] If there are one or more subscribed service modules, the service center forwards the business data to the service port consumption queues of these subscribers respectively for their secondary processing or linkage response. For example, when a charging start event occurs, the transaction processing service may need to notify the log service to record the operation and at the same time notify the billing service to initialize the metering information. At this time, multi-service collaborative work can be achieved through the subscription mechanism. When forwarding the business data to each subscribed service, the service center also transmits the business data to the inter-layer communication interface of the business layer to enter the protocol encapsulation and remote reporting process. If it is confirmed through query that there are no subscribers, the service center directly transmits the business data to the inter-layer communication interface of the business layer to enter the next stage of the processing flow. Thus, it can be seen that the linkage response between services and the protocol message reporting to the platform are two parallel and independent processing paths that do not interfere with each other.

[0031] Furthermore, the service center is also responsible for processing the downstream business data transmitted from the lower layer. Specifically, two-way data interaction is carried out between the service center and the business layer through the inter-layer communication interface. The inter-layer communication interface includes a consumption queue for caching the downstream business data packets transmitted from the business layer. When the service center obtains new downstream business data from the consumption queue of the inter-layer communication interface, it first analyzes the target service identification field in the data packet to determine the target service module to which it should be delivered. Subsequently, the service center queries the port class table it maintains to determine whether the target service module has been registered in the system. If the query result is unregistered, it is considered that the service is currently unavailable or has been disabled, and the service center discards the downstream business data and may optionally record an exception event; if the query result is registered, the service center writes the downstream business data into the service port consumption queue of the corresponding service module so that it can be normally received and processed by the service module.

[0032] In addition, when writing the downstream business data into the target service port consumption queue, the service center will also read the service port subscription class table corresponding to the target service module again and share the downstream business data to all other service modules that have subscribed to this service port. This method in this embodiment can support cross-service data linkage.

[0033] Furthermore, Figure 3 and Figure 4 respectively show the specific implementation methods of two data flow paths inside the service layer.

[0034] Figure 3 This illustrates the data dispatching process by the service center after the service has completed business data processing. For example... Figure 3 As shown, this process is applicable to scenarios where any service module, after independently completing the business data processing of the OCPP2.0 protocol functional module, needs to report the data to a remote platform or notify other services for a coordinated response. Before executing this process, each service module must first register its own information with the service center. Specifically, when service a starts, it will actively call the registration interface to submit its service port information to the service center. After receiving it, the service center adds it to the maintained port class table. The port class table is used to record all registered service modules and their corresponding service port addresses, consumption queue pointers, distribution queue pointers, and subscription indexes, etc. From then on, all interactive data of service a is uniformly scheduled and processed by the service center.

[0035] After service a completes its local business logic processing independently, it writes the resulting business data, along with the initiator identifier, business identifier, and data context, into the local buffer and submits it to the distribution queue of its service port.

[0036] Subsequently, the service center periodically polls the service port of service a's distribution queue. When new data is detected, the service center retrieves the business data packet and performs basic format validation on the data. If obvious errors are found (such as missing fields), the data is released and optionally logged; if the validation passes, the process proceeds to the next step.

[0037] The service center reads the service port subscription table associated with the service port corresponding to service a. The subscription table records which other service modules have subscribed to the data output of service a.

[0038] If a subscribed service module exists, the service center copies the current business data and delivers it to the service port consumption queue of the subscribed service module for secondary processing. During this process, service a and the subscribed service module do not establish a direct connection, nor do they call each other's internal functions or access shared memory. All data transmission is handled by the service center as a relay node, achieving complete decoupling between services. If it is confirmed that the service port has no subscribers, the service center will not perform shared distribution but will directly transmit the original business data to the inter-layer communication distribution queue of the business layer, preparing for the encapsulation and communication phase.

[0039] Throughout the process, the following interaction rules are followed: data is centrally relayed by the service center and services do not transmit data directly to each other; the subscription mechanism is optional, and services that have not subscribed will not receive irrelevant data; each service processes the shared data it receives independently without affecting the running status of the source service or other subscribed services.

[0040] Figure 4 shows the subscription and sharing process of the service center for processing inter-layer communication data and service-to-service linkage / private data, as Figure 4 shown. This embodiment provides another data flow path, covering two application scenarios. One is to process the downstream service data from the remote platform; the other is to support the linkage service processing and private data interaction between services.

[0041] First, for the downstream service data processing flow from the remote platform, when the service layer receives the complete downstream message passed by the communication layer and completes the parsing, it generates the corresponding downstream service data packet and submits it to the consumption queue of the inter-layer communication interface. This consumption queue is regularly read by the service center.

[0042] After the service center retrieves the new downstream service data from the inter-layer communication consumption queue, it first parses the target service identification field contained therein to determine the associated service module (such as Service A). Then, the service center queries the port class table it maintains to determine whether Service A is already registered in the system. If the query result is unregistered (for example, the service has been deactivated due to a fault or is in a disabled state), it is considered that the service is currently unavailable, and the service center discards the downstream service data and may record the abnormal event for operation and maintenance troubleshooting. If the query result is registered, the service center writes the downstream service data into the service port consumption queue of Service A so that it can be normally received and processed by Service A. Subsequently, the service center reads the service port subscription class table corresponding to Service A again and shares the downstream service data to all other service modules that have subscribed to the data output of Service A. For example, if Service B has subscribed to the input data channel of Service A, the service center also forwards the downstream service data to the service port consumption queue of Service B to achieve cross-service status synchronization or linkage response. Second, for the data interaction requirements between services, including linkage services and private data transfer, in the mutually linked service scenarios, Service A and Service B can establish a shared data channel through the subscription class table. For example, when Service A generates a certain status change event, it sends its service data to its service port downstream queue, and then the service center identifies that Service B has subscribed to its output according to the subscription class table and shares the data to the consumption queue of Service B.

[0043] In addition, private data interaction not specified by the OCPP2.0 protocol can also be carried out between services. For example, Service A generates a set of diagnostic information for internal debugging only, which does not belong to the standard protocol content but still needs to be transmitted to Service B for monitoring and analysis. At this time, Service A can also write its private data into the downstream queue of its own service port, and the service center broadcasts it according to the subscription class table.

[0044] Throughout the entire data interaction process between services, a subscription-sharing approach is always adopted. That is, if service b does not subscribe to the data output of service a, it will not receive any data. There are no direct function calls or memory references in the data transmission process, and there is no coupling. Each service processes the received data independently without affecting each other.

[0045] It is understandable that the service center not only serves as the routing hub for uplink and downlink data, but also enables loosely coupled data sharing between services. Both platform command distribution and service internal state synchronization are accomplished through a unified registration and subscription model, thereby improving the system's scalability and flexibility. For example, when a service malfunctions, simply deregistering it from the port class table isolates its impact without interfering with the normal operation and authentication process of other services.

[0046] like Figure 5 As shown, the business layer is used to receive business data from the service layer and perform format verification and encapsulation processing. During the processing, it establishes and maintains a business context that records the communication status. In addition, it is also used to receive downlink raw messages from the communication layer, perform parsing, verification and context matching operations to ensure the integrity and reliability of the communication process.

[0047] In some implementations, the business layer includes a context factory, a context queue, and a context task scheduler; the context factory is used to create a context object for each communication interaction and store the context object in the context queue; wherein, the context object includes the initiator (the service module ID that generated the request), the data context containing the original business parameters or response content, the transmission mode, the business identifier (corresponding to a specific functional scenario in the OCPP2.0 protocol), and the expected response deadline.

[0048] When the service layer submits business data to the business layer, the business layer first performs a necessity check on the data according to the OCPP2.0 protocol specification, verifying only necessary data fields, required parts of optional data, consistency of associated data, and data rationality. If the verification passes, the encapsulation process begins: the business data is encapsulated into a standard OCPP2.0 request message according to a preset format, and a corresponding context object is created by the context factory. The created context object is stored in the context queue as a status record of the current pending communication transaction. The expected response deadline for this context object is set according to a preset strategy, such as 30 seconds, but can also be dynamically adjusted based on network quality. This time stamp is used as a basis for subsequent timeout judgment.

[0049] The context task scheduler polls the context queue at preset time intervals to determine if any context objects have exceeded the expected response deadline. If so, the current context object is marked as a timeout task, and a retransmission task is triggered. Triggering the retransmission task specifically includes: for uplink timeout tasks, retransmitting according to the retry method specified in the OCPP2.0 protocol; for downlink timeout tasks, retrieving the corresponding service data stored in the context queue, reconstructing the response context, and generating a corresponding acknowledgment response message to be sent back to the remote platform.

[0050] Specifically, the context task scheduler runs periodically, polling all context objects in the context queue at preset time intervals and comparing their current time with their expected response deadline. If a context object has exceeded its expected response deadline and has not received a response, the communication task is determined to be a timeout task. For tasks marked as timeout, the business layer triggers a retransmission task for processing. The execution method of the retransmission task varies depending on the communication direction. For uplink timeout tasks, i.e., when a request is sent from the local machine to the remote platform but no response is received, the business layer retransmits the original message according to the retry mechanism specified in the OCPP2.0 protocol. The number of retransmissions can be set according to configuration options, for example, a maximum of 3 retries, with each retry interval increasing. After each retransmission, the expected response deadline of the corresponding context object is updated, and the system continues to wait for a response.

[0051] For timeout tasks in the downlink direction, i.e., when the remote platform sends a request to the local machine but does not receive an acknowledgment response, the business layer does not discard the transaction. Instead, it calls the corresponding business data already stored in the context queue, reconstructs the response context, generates the corresponding acknowledgment response message, and sends it back to the remote platform through the communication layer.

[0052] Upon receiving the complete downlink message from the communication layer, the business layer first performs a parsing operation to extract key fields such as message type, message ID, and payload content. Then, a data format check is performed, following the same rules as the uplink direction. If the check passes, it further checks for a context object matching the message ID. If a match is found, it indicates the message is a response to a previous request, and the system releases the corresponding context object. If no match is found, it is considered a newly initiated request, and the context factory creates a new context object for it, which is then distributed by the service center to the target service module for processing.

[0053] In this embodiment, the business layer, through the collaborative operation of a context factory, context queue, and context task scheduler, can achieve full lifecycle management of every communication interaction. Whether it's waiting for confirmation after a request is sent or automatically resending a lost response, both can be completed autonomously without external intervention.

[0054] like Figure 6 As shown, the communication layer is used to encapsulate the processed business data into uplink transmission frames and send them to the remote platform. At the same time, it performs type identification on the received downlink transmission frames and executes the corresponding reassembly strategy according to the identification results to restore them into complete application layer messages before transmitting them to the business layer, so as to complete the bidirectional communication interaction with the remote platform.

[0055] Exemplarily, the communication layer includes a connection checking module, a processing module, and a communication layer task scheduler; the communication layer task scheduler is configured to periodically run multiple communication tasks; wherein, the communication tasks include fragmentation tasks, packet assembly tasks, connection detection tasks, and activity detection tasks.

[0056] Before each sharding task or activity detection task is executed, if the connection check module determines that no open WebSocket connection or encrypted WebSocket connection has been established according to the preset security policy, it will trigger the connection reconstruction process. The processing module is used to perform fragmentation and encapsulation on uplink data and send it through a non-blocking interface, and to perform type identification on received downlink data frames and execute the corresponding reassembly strategy according to the type identification result. The fragmentation and encapsulation operation is triggered by the fragmentation task, and the parsing and submission of downlink data is driven by the packet assembly task.

[0057] Specifically, when business data from the upper layer enters the communication layer, the connection check module first determines whether a valid WebSocket connection has been established. If the connection is not established or has been broken, it decides to establish an open WebSocket connection or an encrypted WebSocket connection (i.e., WSS) based on a preset security policy. The security policy can be configured as no security mode, one-sided signature verification mode, two-sided signature verification mode, one-sided authorization signature verification, two-sided authorization signature verification, etc. Once the connection is successfully established, the subsequent data transmission process remains consistent under both connection types, without needing to change the processing logic due to differences in security levels.

[0058] For the uplink data transmission process, the communication layer only performs encapsulation operations on the received service data. It's important to note that the handshake data packets and control command data packets are generated and managed by the communication layer itself, independent of upper-layer input. The encapsulation process is controlled by the fragmentation task's periodic scheduling, which involves slicing the application layer message to be sent according to the maximum transmission unit limit and sequentially pushing each data fragment into the fragmentation task queue. Subsequently, the fragmentation task sends each data fragment to the network channel step by step through the non-blocking interface of the send buffer. This non-blocking interface allows the communication layer to complete high-concurrency data output without blocking the main thread, making it suitable for resource-constrained embedded environments such as charging piles.

[0059] For the downlink data reception process, the communication layer continuously listens for raw data frames from the remote platform through a non-blocking interface of the receive buffer. The received data is first parsed and categorized into reconnection packets, heartbeat packets, and data packets based on their type. If a reconnection packet is identified, it indicates that the current connection has failed. The communication layer immediately clears its local connection status flag and active status flag, and emptys the upper-layer communication data buffer. Subsequently, the connection detection task scheduler automatically attempts to re-initiate the handshake process at specified time intervals to rebuild the connection with the remote platform, thereby maintaining the system's connected state. If a heartbeat packet is identified, the activity detection process begins. The communication layer, through the activity detection task, periodically sends Ping messages to the remote platform and expects a Pong message response. If no Pong response is received within the expected time, the connection is considered abnormal. The communication layer actively resets the connection state and triggers the reconnection mechanism, while simultaneously clearing the relevant data buffer to prevent stale data from interfering with subsequent communication. If a data packet is identified, it is further processed by the packet assembly task. The packet assembly task distinguishes between the following four scenarios based on the actual reception: If the downlink data is single-packet data, it means that a complete WebSocket frame carries a complete OCPP application layer message. In this case, the communication layer directly submits the data packet to the inter-layer communication queue of the business layer. If the downlink data is multi-packet data, it means that an application layer message is divided into multiple WebSocket frames for transmission. The communication layer buffers each fragment through a packet reassembly task until all fragments are received, then reassembles them into a complete message and submits it to the upper-layer inter-layer communication queue. If the downlink data is packet-merged data, it means that multiple independent WebSocket frames are continuously encapsulated in a TCP segment. The communication layer can automatically identify the boundaries of each frame, split them into independent messages one by one, and submit them to the inter-layer communication queue respectively. If the downlink data is mixed packet data, it means that a complex data stream contains both multi-packet and packet-merged characteristics. For example, the first half is a multi-packet sequence, and the second half is two adjacent single packets. For such mixed packets, the communication layer adopts a composite processing strategy: performing packet reassembly on the multi-packet part, performing packet disassembly on the packet-merged part, and finally submitting the restored multiple complete application layer messages to the business layer for processing in sequence.

[0060] All of the above tasks are managed and scheduled by the communication layer task scheduler. As the core scheduling carrier of the communication layer, the scheduler is responsible for driving the periodic operation of fragmentation tasks, packet assembly tasks, connection detection tasks, and activity detection tasks, ensuring the stability and efficiency of the entire communication process.

[0061] Furthermore, the communication layer facilitates data interaction with upper and lower layers through standardized interfaces. On one hand, it exchanges data with the business layer via inter-layer communication interfaces; on the other hand, it physically sends and receives data with the underlying network module through transmit-buffered non-blocking interfaces and receive-buffered non-blocking interfaces. This design allows the communication layer to adapt to different hardware platforms and operating system environments while effectively reducing CPU utilization and peak memory usage.

[0062] Furthermore, such as Figure 7 As shown, each service module interacts with the charging pile main control program by calling predefined application programming interfaces (APIs). The APIs include retrieval interface functions and distribution interface functions. The retrieval interface functions are used to retrieve specified data from the charging pile main control program, while the distribution interface functions are used to send operation instructions to the charging pile main control program.

[0063] Specifically, the application programming interface (API) constitutes the sole interaction channel between the service program and the charging pile main control program. All data reading and control commands are completed through this interface layer. The service module must not directly access the internal variables, global state, or execute its core logic code of the charging pile main control program, thereby achieving functional isolation and data decoupling between the communication software architecture and the original program.

[0064] In this embodiment, the application programming interfaces (APIs) are categorized into several types based on their functional uses, including but not limited to time interaction, network, diagnostics, device management, authorization, and transaction interfaces. Each category contains one or more specific interface functions, each with clearly defined input parameters and return values ​​to adapt to the data requirements of different business scenarios. Time interaction interfaces are used to obtain the system's current time, UTC timestamp, or perform time synchronization operations. Network interfaces are used to query the current network connection status, IP address, signal strength, etc. Diagnostic interfaces are used to read internal operation logs, fault codes, or hardware self-test results. Device management interfaces are used to query firmware versions, restart devices, or trigger configuration updates. Authorization interfaces are used to request RFID card authentication results, query authorization lists, or clear cached permissions. Transaction interfaces are used to start charging sessions, stop charging, or obtain metering data.

[0065] The Get() function is used to read a specified data item from the charging pile main control program. The implementation method is as follows: the service module sends a request with the target data identifier to the API interface layer. The API interface layer forwards the request to the API implementation submodule of the charging pile main control program. The latter reads the corresponding field from the local data area and encapsulates it into a standard format and returns it.

[0066] The `Put()` function is used to send control commands to the charging pile's main control program. It works as follows: the service module constructs a command structure containing the operation type and parameters, passes it to the original program through the API interface layer, and its internal logic parses and executes the corresponding action. Upon completion, a standard result code is returned, indicating whether the operation was successful.

[0067] Understandably, in practical applications, one or more API interface implementation versions can be independently developed for different models or brands of charging pile main control programs. Each API interface follows the same function naming rules, parameter structure, and return conventions, differing only in the underlying interface logic. The service program selects which API interface to use through configuration files, thereby shielding the underlying platform differences and improving the portability and adaptability of this communication software architecture.

[0068] Furthermore, the application programming interface (API) supports dynamic expansion and version compatibility. When adding new features, new Get() or Put() functions can be added to the existing API set; for deprecated older APIs, they are retained in the API set but marked as deprecated to ensure that service modules from previous versions can still be called normally, achieving backward compatibility.

[0069] It should also be noted that this communication software architecture does not directly reference or modify any data generated by the charging pile's main control program during operation; it can only access data with authorized permissions through the aforementioned API interfaces. This ensures that even if the communication architecture itself fails due to network anomalies, memory leaks, or logical errors, it will not interfere with the basic charging functions of the charging pile, thus achieving high reliability and operational safety.

[0070] To more clearly illustrate the working process of the charging pile terminal communication platform in this embodiment in a practical application scenario, the following is combined with... Figure 8 and Figure 9 The process of uplink communication (from the charging pile to the remote platform) and downlink communication (from the remote platform to the charging pile) is explained in detail.

[0071] Figure 8 This describes the upstream business data reporting process in this embodiment. This process is applicable to scenarios where a user's operation on the charging pile triggers a status change event, and the local service module generates and reports an OCPP2.0 protocol message to the remote platform. Specifically, it includes steps S101-S114: Step S101: The service module monitors the charging pile's operating status in real time.

[0072] As an example, each service module periodically or event-triggeredly obtains the current operating data and status information of the charging pile by calling a predefined application programming interface (API), such as plug-in signal, charging start command, fault alarm, billing start flag, etc.

[0073] Step S102: A trigger event is detected, and the service module identifies the business scenario.

[0074] As an example, when a service module obtains a key state change related to it through an API interface (for example, the transaction processing service detects a charging start event), it determines that the event belongs to a business scenario that needs to be reported to the platform and enters the subsequent processing flow.

[0075] Step S103: Trigger the service business task, apply for resources and build the data structure.

[0076] For example, the service module initiates the corresponding business task, requests a business data buffer, creates a business constraint structure containing necessary fields, and initializes the data context to record the context information of this communication, such as the initiator identifier, business identifier, and original parameters.

[0077] Step S104: Determine whether it involves linked services or requires triggering data interaction between services.

[0078] As an example, in this step, the service module queries the service center to see if its output data has been subscribed to by other services. If at least one service module has registered and subscribed to the current service port, it is determined that a collaborative business is involved.

[0079] If so, proceed to step S105, whereby the service center forwards the data to the subscriber to complete the inter-service synchronization.

[0080] It's understandable that the service center reads the subscription table corresponding to the current service port, copies the business data to be reported, and transmits it to the consumption queues of all service modules that have subscribed to this data source, for secondary processing or status updates. For example, at the start of charging, the transaction processing service can notify the log service to record operation logs and simultaneously notify the billing service to initialize the metering unit. Each subscription service processes shared data independently without affecting others.

[0081] If not, proceed to step S106 to perform uplink data processing and submit it to the inter-layer communication interface.

[0082] Understandably, when there is no need for linkage or all subscription services have been processed, the service module records its final business data in a local buffer and submits it to the distribution queue of its own service port. Subsequently, the service center retrieves the data from this distribution queue, performs format verification, and then transmits it to the inter-layer communication distribution queue of the business layer.

[0083] Step S107: The business layer performs a format check on the business data.

[0084] As an example, after receiving a data packet from the inter-layer communication interface, the service layer performs an integrity check on the data according to the message format specified in the OCPP2.0 protocol. The checks include, but are not limited to: the existence of necessary data fields, the compliance of required fields in optional data, the consistency of associated data, and the reasonableness of the numerical range.

[0085] Step S108: Determine if the data is correct.

[0086] If an error is found during the inspection, step S109 is executed. The business layer discards the data packet and may selectively log it for subsequent investigation. The process ends.

[0087] If the check passes, proceed to step S110 to encapsulate the service message and create a communication context.

[0088] It's understandable that the business layer can encapsulate legitimate business data into a standard OCPP2.0 request message using the JSON-RPC2.0 format. Simultaneously, the context factory creates a new context object for this communication and stores it in the context queue. This context object includes: initiator, data context, transport mode, business identifier, and expected response deadline.

[0089] Step S111: The encapsulated message is transmitted to the communication layer.

[0090] As an example, the encapsulated OCPP message is submitted to the input queue of the communication layer through the inter-layer communication interface, awaiting transmission and processing.

[0091] Step S112: Determine if the communication connection is normal.

[0092] In this step, the communication layer checks the current WebSocket connection status with the remote platform. If the connection is established and active, it proceeds directly to the sending process.

[0093] If the connection is broken or not initialized, proceed to step S113 to attempt to rebuild the connection and cache the data to be sent.

[0094] Understandably, the communication layer initiates a connection detection task, automatically launching a WebSocket handshake process at specified intervals to attempt to re-establish the connection with the central system. During this period, data to be sent is retained in the sending buffer and will continue to be transmitted once the connection is restored.

[0095] If the connection is available, proceed to step S114, where the communication layer performs non-blocking transmission.

[0096] It is understandable that when a connection is available, the communication layer will send data frames one by one through the non-blocking interface of the send buffer to avoid blocking the main thread and improve system response performance.

[0097] like Figure 9 This is a schematic diagram of the downlink business data processing flow in this embodiment. This flow is applicable to scenarios where a remote platform sends control commands or query requests to a charging pile, and the local system responds.

[0098] Specifically, this includes steps S201-S214: Step S201: The communication layer receives the raw data frames and classifies and processes them.

[0099] As an example, the communication layer continuously listens for data streams from the network channel through a receive-buffered non-blocking interface. The received data is first parsed and categorized by type as reconnection packets, heartbeat packets, or data packets.

[0100] In step S202, the communication layer executes single packet, multiple packet, packet merging, and mixed packet reassembly strategies.

[0101] Step S203: The complete message is transmitted to the service layer.

[0102] In this step, after each complete message is restored, the communication layer submits it to the inter-layer communication consumption queue of the business layer.

[0103] Step S204: The business layer obtains the data packet and performs parsing and detection.

[0104] As an example, the business layer obtains downlink messages from the inter-layer communication interface, first performing a parsing operation to extract key fields such as message ID and payload content. Then, it validates the data format according to predetermined protocol specifications, including field types, required fields, and the reasonableness of value ranges.

[0105] Step S205: Determine whether the data detection is correct.

[0106] If the detection is incorrect, step S206 is executed, the business layer directly discards the erroneous data packet and does not pass it to the upper layer, and the process ends.

[0107] If the detection is correct, proceed to step S207 to find and match the business context.

[0108] It's understandable that the business layer checks if a corresponding context object exists in the context queue based on the message ID. If it exists, it means the message is a response to a previous local request; if it doesn't exist, it's considered a new request initiated by the platform (i.e., downlink business data).

[0109] Step S208: Determine whether it is downlink service data for the charging terminal.

[0110] If the message is a command message initiated by the platform to the charging pile, it is determined to be downlink business data, and step S209 is executed. Otherwise, it is considered a response to a local request, and step S210 is executed.

[0111] Step S209: Perform downlink business processing, generate a response, and send it back.

[0112] As an example, the business layer creates a new context object for the command, records the request content, and passes the data to the service center. The service center parses the target service identifier and queries the port class table to confirm whether the service is registered. If it is registered, the data is written to the service port consumption queue of the corresponding service module for processing.

[0113] Step S210: Release the context or restore the historical response.

[0114] In this step, if the message is a response message, the corresponding context object is released; if it is a downlink command but the response is lost due to network issues, the context task scheduler can restore the stored response data and resend the acknowledgment message after a timeout to ensure communication integrity.

[0115] Step S211: The service layer obtains data and performs internal synchronization.

[0116] In this step, the target service module obtains downlink data and its associated data context from its service port consumption queue, and completes local state synchronization or performs corresponding actions.

[0117] Step S212: Determine whether it involves linked services or triggers data interaction between services.

[0118] In this step, the service center reads the service port subscription table corresponding to the service module again. If other services have already subscribed to the input channel, step S213 is executed to share the downlink data to the consumption queues of all subscribers, achieving cross-service status linkage. If no such service exists, step S214 is executed to complete the inter-service collaborative processing, and the process ends.

[0119] Understandably, once all subscription services have completed their respective processing logic, the communication process ends, and each service module resumes its normal monitoring mode.

[0120] Therefore, the charging pile communication platform in this embodiment can effectively support the bidirectional communication requirements of the OCPP2.0 protocol in complex business scenarios. Whether actively reporting events locally or responding to remote commands from the platform, the system can ensure the integrity, reliability, and maintainability of communication through layered collaboration, context management, and subscription sharing mechanisms. In addition, since the entire communication process is completely decoupled from the original program based on the API interface, even in the event of communication anomalies or module failures, the core charging function of the charging pile will not be affected.

[0121] This embodiment constructs a service-oriented OCPP2.0 charging pile terminal multi-layer communication software architecture to achieve modular, hierarchical, and decoupled design of communication functions, and improves the stability, maintainability, and adaptability of the protocol implementation. Specifically, the service layer adopts an independent service module combined with a unified scheduling mechanism of the service center, ensuring that the functional modules do not interfere with each other, supporting dynamic registration and uninstallation, facilitating flexible handling of service anomalies during OCA certification, and improving the certification pass rate. In addition, by introducing a subscription class table, loosely coupled data sharing between services is achieved, avoiding the strong dependency problem caused by direct calls, and enhancing the system's scalability and fault tolerance. The business layer establishes a collaborative working mechanism between a context factory and a context task scheduler to perform full lifecycle management of each communication interaction. Combined with data inspection, encapsulation and parsing, and timeout retransmission mechanisms, it effectively ensures the integrity and reliability of the communication process. In particular, for the problem of downlink response loss, it can automatically reconstruct and send back confirmation messages based on the stored context, avoiding the platform's misjudgment of connection interruption. The communication layer fully supports data processing strategies for single packets, multiple packets, packet aggregation, and mixed packets, and integrates connection detection and activity monitoring tasks to ensure stable and reliable long-term communication even in complex network environments. The entire architecture interacts with the charging pile's main control program in isolation through a predefined application programming interface (API). All data reading and control commands are completed through standardized interfaces, shielding the differences between different main control programs and ensuring that even if the communication module fails, the core charging function of the charging pile will not be affected, thereby improving system safety.

[0122] This application also provides a data interaction method, which is applied to the aforementioned charging pile terminal communication platform, such as... Figure 10 As shown, the method includes steps S301-S304: In step S301, each service module monitors the triggering events during the operation of the charging pile to generate corresponding business data and submit it to the corresponding service port distribution queue.

[0123] In step S302, the service center retrieves business data from the distribution queue and queries the service port subscription class table corresponding to the current business data.

[0124] If a subscribed service module exists, proceed to step S303 to forward the business data to the consumption queue corresponding to the subscribed service module; if no subscribed service module exists, proceed to step S304 to transfer the business data to the business layer.

[0125] In step S305, the business layer performs protocol message encapsulation on the business data and creates a context object containing the expected response deadline, which is then stored in the context queue.

[0126] In step S306, the context task scheduler periodically scans the context queue, identifies tasks that exceed the expected response deadline, and triggers retransmission tasks.

[0127] It is understood that the options in the above embodiments also apply to this embodiment, so they will not be described again here.

[0128] This application also provides a charging pile, which, exemplary, includes a processor, a memory, and a charging pile master control program. The memory stores a computer program, and the processor runs the aforementioned charging pile end communication platform. The charging pile end communication platform interacts with the charging pile master control program through an application programming interface.

[0129] The processor can be an integrated circuit chip with signal processing capabilities. The processor can be a general-purpose processor, including at least one of a Central Processing Unit (CPU), Graphics Processing Unit (GPU), Network Processor (NP), Digital Signal Processor (DSP), Application-Specific Integrated Circuit (ASIC), Field-Programmable Gate Array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components. The general-purpose processor can be a microprocessor or any conventional processor, capable of implementing or executing the methods, steps, and logic block diagrams disclosed in the embodiments of this application.

[0130] The memory can be, but is not limited to, Random Access Memory (RAM), Read Only Memory (ROM), Programmable Read-Only Memory (PROM), Erasable Programmable Read-Only Memory (EPROM), Electrically Erasable Programmable Read-Only Memory (EEPROM), etc. The memory is used to store computer programs, and the processor can execute the computer programs accordingly after receiving execution instructions.

[0131] This application also provides a computer-readable storage medium for storing the computer program used in the aforementioned charging pile. For example, the computer-readable storage medium may include, but is not limited to, various media capable of storing program code, such as a USB flash drive, a portable hard drive, a read-only memory (ROM), a random access memory (RAM), a magnetic disk, or an optical disk.

[0132] In the several embodiments provided in this application, it should be understood that the disclosed apparatus and methods can also be implemented in other ways. The apparatus embodiments described above are merely illustrative. For example, the flowcharts and block diagrams in the accompanying drawings show the architecture, functionality, and operation of possible implementations of apparatus, methods, and computer program products according to various embodiments of this application. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that, in alternative implementations, the functions marked in the blocks may occur in a different order than those marked in the drawings. For example, two consecutive blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagram and / or flowchart, and combinations of blocks in the block diagram and / or flowchart, can be implemented using a dedicated hardware-based system that performs the specified function or action, or using a combination of dedicated hardware and computer instructions.

[0133] In addition, the functional modules or units in the various embodiments of this application can be integrated together to form an independent part, or each module can exist independently, or two or more modules can be integrated to form an independent part.

[0134] If the aforementioned functions are implemented as software functional modules and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or a part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a smartphone, personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application.

[0135] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any changes or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application.

Claims

1. A communication platform for a charging pile, characterized in that, include: Service layer, business layer, and communication layer; The service layer includes multiple independent service modules; Each of the aforementioned service modules is used to monitor the corresponding trigger events during the operation of the charging pile and generate corresponding business data; The service layer is used to receive the service data from the service layer and process the messages, and to establish and maintain a service context that records the communication status during the processing. The communication layer is used to encapsulate the processed service data into uplink transmission frames and send them to the remote platform. At the same time, it performs type identification on the received downlink transmission frames and executes the corresponding reassembly strategy according to the identification result to restore them into complete application layer messages before transmitting them to the service layer, so as to complete the bidirectional communication interaction with the remote platform.

2. The charging pile terminal communication platform according to claim 1, characterized in that, The service layer also includes a service center; The service center includes a port class table; the port class table is used to record all the service modules and their corresponding service ports; when any of the service modules generates the business data and submits it to its distribution queue, the service center obtains the business data from the distribution queue, and forwards the business data to one or more service modules that have subscribed to the current business data source and the business layer according to the corresponding service port subscription class table. If there is no subscriber, the business data will be transmitted to the business layer.

3. The charging pile terminal communication platform according to claim 2, characterized in that, The service center and the business layer interact with each other through an inter-layer communication interface, which includes a consumption queue for caching downlink business data transmitted by the business layer. When the service center obtains the downlink service data from the consumption queue of the inter-layer communication interface, it parses the target service identifier in the downlink service data and queries the port class table to determine whether the corresponding service module has been registered. If already registered, the downlink service data is written into the service port consumption queue of the corresponding service module, and the downlink service data is shared with other subscribed service modules according to the corresponding service port subscription class table.

4. The charging pile terminal communication platform according to claim 1, characterized in that, The business layer includes a context factory, a context queue, and a context task scheduler; The context factory is used to create a context object for each communication interaction and store the context object in the context queue; wherein, the context object includes an initiator, data context, transmission mode, service identifier, and expected response deadline; The context task scheduler is used to poll the context queue at preset time intervals to determine whether there is a context object that exceeds the expected response deadline. If there is, the current context object is marked as a timeout task and a retransmission task is triggered.

5. The charging pile terminal communication platform according to claim 4, characterized in that, The triggering of the retransmission task specifically includes: for the timeout task in the uplink direction, retransmitting according to the retry method specified in the preset charging protocol; for the timeout task in the downlink direction, calling the corresponding service data stored in the context queue, reconstructing the response context, and generating a corresponding acknowledgment response message to be sent back to the remote platform.

6. The charging pile terminal communication platform according to claim 1, characterized in that, The communication layer includes a connection checking module, a processing module, and a communication layer task scheduler; The communication layer task scheduler is configured to periodically run multiple communication tasks; wherein, the communication tasks include fragmentation tasks, packet assembly tasks, connection detection tasks, and activity detection tasks; Before each execution of the sharding task or the activity detection task, if the connection checking module determines that no open WebSocket connection or encrypted WebSocket connection has been established according to the preset security policy, then the connection reconstruction process is triggered. The processing module is used to perform fragmentation and encapsulation on uplink data and send it through a non-blocking interface, perform type identification on received downlink data frames and execute corresponding reassembly strategies based on the type identification results; wherein, the fragmentation and encapsulation operation is triggered by the fragmentation task, and the parsing and submission of downlink data is driven by the packet assembly task; the type identification results include heartbeat packets, reconnection packets and data packets.

7. The charging pile terminal communication platform according to claim 6, characterized in that, If the type identification result is the data packet, the processing module performs corresponding processing based on the identified type, including: If the downlink data is a single packet, it is submitted to the inter-layer communication queue of the service layer; If the downlink data is multi-packet data, then after all fragments arrive, perform packet reassembly to restore it into a complete application layer message and submit it to the inter-layer communication queue of the service layer. If the downlink data is concatenated data, then the multiple tightly arranged application layer messages are sequentially split into independent messages and submitted to the inter-layer communication queue of the service layer respectively. If the downlink data is mixed packet data, then the corresponding reassembly strategy is executed for each type of data in the mixed packet data, and submitted to the inter-layer communication queue of the service layer respectively.

8. The charging pile terminal communication platform according to claim 1, characterized in that, Each of the aforementioned service modules interacts with the charging pile main control program by calling a predefined application programming interface (API); wherein, the API includes an acquisition class interface function and a distribution class interface function; The acquisition interface function is used to obtain specified data from the charging pile main control program; The aforementioned interface function is used to send operation instructions to the main control program of the charging pile.

9. A data interaction method, characterized in that, The method is applied to the charging pile terminal communication platform according to any one of claims 1-8, comprising: Each service module monitors the triggering events during the operation of the charging pile, generates corresponding business data, and submits it to the corresponding service port's distribution queue. The service center retrieves the business data from the distribution queue and queries the service port subscription class table corresponding to the current business data. If a subscribed service module exists, the service data is forwarded to the consumption queue corresponding to the subscribed service module, and the business data is transmitted to the business layer. If no subscribed service module exists, the business data is transmitted to the business layer. The business layer encapsulates the business data using protocol messages and creates a context object containing the expected response deadline, which is then stored in the context queue. The context task scheduler periodically scans the context queue, identifies tasks that exceed the expected response deadline, and triggers retransmission tasks.

10. A charging pile, characterized in that, Including the charging pile's main control program and processor; The processor runs the charging pile terminal communication platform according to any one of claims 1-8; The charging pile terminal communication platform interacts with the charging pile main control program through an application programming interface.

Images