Communication connection method for controller outside vehicle

Abstract

The invention relates to the technical field of communication, and discloses an out-of-vehicle controller communication connection method, which comprises the following steps: step 1, a modular edge identification node is integrated in an out-of-vehicle infrastructure, and the modular edge identification node loads a preset lightweight neural network model and a protocol conversion module library to complete initialization when the out-of-vehicle infrastructure is started, the modularized edge identification node is composed of a network interface unit, an edge reasoning chip and a cache unit. And step 2, capturing an initial data packet generated when the controller outside the vehicle is accessed by the initialized modular edge identification node. According to the technical scheme, the modular edge identification node and dynamic protocol adaptation is adopted, so that the technical effects of automatically identifying private protocols of controllers of different manufacturers and loading corresponding conversion modules in real time are achieved; and the defects of high system integration difficulty and high construction cost caused by non-uniform protocols are overcome.

Description

Technical Field

[0001] This invention relates to the field of communication technology, specifically to a communication connection method for an external vehicle controller. Background Technology

[0002] The rapid popularization of new energy vehicles presents a significant challenge to the system integration and equipment compatibility of charging stations, which serve as core infrastructure. Current charging station systems need to integrate multiple types of equipment, including vehicle BMS, smart charging piles, and energy storage controllers. However, different manufacturers generally use proprietary communication protocols (such as CAN bus variants and custom TCP / IP messages), leading to severe protocol heterogeneity issues. Against this backdrop, the development of a communication connection method for external controllers has become a key technological direction for solving the interconnection problem of charging station equipment.

[0003] In existing technologies, controllers within charging station systems typically originate from different manufacturers, each employing their own proprietary communication protocols. This results in inconsistent communication standards between devices within the charging station. Consequently, when integrating controllers using different communication protocols, direct data interoperability cannot be achieved. Additional R&D resources must be invested in cumbersome protocol adaptation, significantly increasing the difficulty and cost of system integration.

[0004] Currently, data exchange between controllers in charging stations relies on temporary protocol conversions. This conversion method is prone to data transmission delays or losses. The instability of communication directly leads to charging service interruptions or incorrect billing information, severely reducing the reliability of the charging service and greatly harming the user's charging experience.

[0005] Current charging station systems employ hard-coded protocol connections, resulting in a lack of flexibility and scalability. Upgrading a charging station, replacing controllers, or adding new equipment requires complex redevelopment and debugging of the existing communication links. This leads to high maintenance and upgrade costs, severely limiting the technological updates and long-term development of the charging station network.

[0006] To address these issues, the present invention proposes a communication connection method for an external vehicle controller. Summary of the Invention

[0007] To address the shortcomings of existing technologies, this invention provides a communication connection method for an external vehicle controller, thereby resolving the problems mentioned in the background section.

[0008] To achieve the above objectives, the present invention provides the following technical solution: a communication connection method for an external vehicle controller, comprising:

[0009] Step 1: Integrate a modular edge recognition node within the external infrastructure. The modular edge recognition node is initialized by loading a pre-built lightweight neural network model and protocol conversion module library when the external infrastructure is started. The modular edge recognition node consists of a network interface unit, an edge inference chip, and a cache unit.

[0010] Step 2: The modular edge recognition node, after initialization, captures the initial data packet generated when the vehicle external controller accesses the system, and extracts multi-dimensional features from the initial data packet to generate a protocol feature vector. The multi-dimensional features include structural features, statistical features, and content features extracted from the initial data packet.

[0011] Step 3: Input the protocol feature vector into the lightweight neural network model to calculate and obtain the protocol identification result and confidence score. When the confidence score is higher than the preset threshold, load the corresponding protocol conversion module from the protocol conversion module library according to the protocol identification result.

[0012] Step 4: Use the loaded protocol conversion module to establish a two-way communication channel between the vehicle external controller and the charging pile main control system. The two-way communication channel is used to convert and transmit the private protocol data of the vehicle external controller and the standardized data structure of the charging pile main control system.

[0013] Step 5: When the confidence score is not higher than the preset threshold or the communication anomaly rate of the bidirectional communication channel exceeds the fault tolerance limit, the modular edge recognition node uploads the unknown protocol sample containing the initial data packet to the cloud server. After receiving the unknown protocol sample, the cloud server generates or updates the protocol conversion module and sends it to the modular edge recognition node. The unknown protocol sample contains the protocol feature vector and related diagnostic logs.

[0014] Preferably, the lightweight neural network model is used to perform classification calculations on the protocol feature vectors to output the protocol identification result;

[0015] The protocol identification result is loaded into the protocol conversion module, which includes loading an adaptation configuration file that matches the protocol conversion module. The adaptation configuration file is used to define the field mapping relationship between private protocol data and standardized data structures.

[0016] Preferably, the standardized data structure is a predefined data object that is independent of any specific private protocol. The data object includes a unified command identifier, data source, timestamp, and data payload fields.

[0017] The real-time conversion and transmission include uplink conversion of parsing and encapsulating the private protocol data into the standardized data structure, and downlink conversion of parsing and encapsulating the standardized data structure into the private protocol data.

[0018] Preferably, the cloud server is specifically used to receive the unknown protocol sample, analyze the unknown protocol sample to generate a new protocol conversion module, and remotely deploy the new protocol conversion module to the modular edge recognition node.

[0019] Preferably, the communication error rate exceeding the fault tolerance limit means that the number of consecutive parsing errors that occur when the protocol conversion module parses the private protocol data reaches a preset error count value.

[0020] Preferably, step 1 further includes the following sub-steps:

[0021] Sub-step 1.1: Hardware self-test and resource allocation

[0022] When the external infrastructure is activated, the modular edge recognition node executes a hardware self-test program, which determines the hardware unit status using the following formula:

[0023]

[0024] Among them, S i The self-test status of the i-th hardware unit, T max The preset maximum response time threshold;

[0025] If all S i =1, the node enters the resource allocation phase, and memory address space is allocated to each unit according to the following rules:

[0026] A net =M base A 推理 =A net +Δ net A 缓存 =A 推理 +Δ 推理 ,

[0027] Among them, A net 、A 推理 、A 缓存 The starting memory addresses for the network interface unit, edge inference chip, and cache unit are listed in order, M. base As the base address, Δ net Δ 推理 This is the preset address offset;

[0028] Sub-step 1.2: Loading and Integrity Verification of Lightweight Neural Network Model

[0029] After resource allocation is completed, the node reads the pre-set lightweight neural network model file from the cache unit. The model file is stored in binary format, and its integrity is verified by a hash check formula:

[0030] H 实际 =SHA-256(F 模型 ), H 预期 =Pre-stored hash value,

[0031] If H 实际 =H 预期 The model parameters are loaded into the specified memory region of the edge inference chip according to the following mapping rules:

[0032] θ k →A 推理 +k·δ, k=0,1,…,N param -1,

[0033] Where, θ k Let N be the k-th parameter of the model, δ be the number of bytes occupied by a single parameter, and N be the number of bytes occupied by a single parameter. param Where k is the total number of parameters and k is the sequential index.

[0034] If the hash verification fails, an alarm will be triggered and initialization will be terminated.

[0035] Sub-step 1.3: Loading and indexing the protocol conversion module library

[0036] After the model is loaded, the node reads the protocol conversion module library from the cache unit. This library contains the protocol conversion module {M}. p |p∈P}, where P is the set of protocol identifiers, and each module is associated with an adaptation configuration file C. p ;

[0037] The node is a fast retrieval module that constructs a hash index table based on protocol identifiers:

[0038] Index(p) = Hash(p) mod B size ,

[0039] Where Index(p) is the storage index of the protocol identifier p in the hash table, B size Let p be the number of hash table buckets, and Hash(p) be the hash value of the protocol identifier p.

[0040] Each bucket stores the corresponding module M p Storage address L in the cache p and configuration file C p Metadata.

[0041] Preferably, step 2 further includes the following sub-steps:

[0042] Sub-step 2.1: Packet capture and time window triggering

[0043] The network interface unit monitors the communication port in real time. When it detects a data packet sent by the external controller, it activates a dynamic time window T. win In T win The subsequent N were captured continuously. pkt Bit data packets constitute the initial data packet set.

[0044] The triggering condition for the time window is:

[0045] T win =max(t) first +Δ base ,t last +Δ extend ),

[0046] Among them, t first t represents the arrival time of the first data packet. last Δ represents the arrival time of the last data packet. base Δ is the base window length. extend Expand the window incrementally;

[0047] If in T win Number of packets N captured pkt <N min N min If the minimum number of valid packets is reached, the connection is deemed invalid and its data is discarded.

[0048] Sub-step 2.2: Multi-dimensional feature extraction and quantization

[0049] For each data packet d in set D i Extract three types of features according to the following rules:

[0050] Structural feature extraction:

[0051] Matching data packet d i Calculate the structural feature vector based on the frame header and frame tail patterns.

[0052]

[0053] Among them, P h and P f For a predefined library of frame header and frame tail patterns, Match(·) is the function return value of the matching degree, ||d i || represents the data packet length, L max Maximum allowed packet length;

[0054] Statistical feature extraction:

[0055] Calculate the mean and variance of the arrival time intervals between adjacent data packets to construct a statistical feature vector F. stat :

[0056]

[0057] Where, μ t t is the average time interval between the arrival of adjacent data packets. k For the k-th data d k Arrival timestamp, t k-1 For the (k-1)th data packet d k-1 The arrival timestamp, where k is the sequential index. N is the variance of the arrival time interval between adjacent data packets. pkt For dynamic time window T win The initial total number of packets captured, N cmd The number of data packets containing the preset command word in set D;

[0058] Content feature extraction:

[0059] Scan the data packet payload, identify the frequency of occurrence in a predefined keyword set K, and generate a content feature vector F. cont :

[0060] F cont =[∑ d∈D I(k1∈d),…,∑ d∈D I(k m ∈d)],

[0061] Where I(·) is the indicator function, k1, k m d represents an element in the font library, and d represents a data packet instance in the data packet set D.

[0062] Sub-step 2.3: Feature fusion and normalization to generate protocol feature vectors

[0063] The three types of features mentioned above are concatenated and normalized according to the following rules to generate the final protocol feature vector V:

[0064]

[0065] V = [v′1, v′2, ..., v′] n ],

[0066] Among them, V raw v′ is the original multidimensional feature vector. j The original feature vector V raw The result after standardization of the j-th eigenvalue, v j The original feature vector V raw The original eigenvalue of the j-th dimension, μ j and σ j The mean and standard deviation of the j-th feature are pre-computed, where j is the dimension index of the feature vector;

[0067] If the feature does not appear in the training data, then v′ j =0.

[0068] Preferably, step 3 further includes the following sub-steps:

[0069] Sub-step 3.1: Model forward propagation and protocol probability distribution calculation

[0070] Input the protocol feature vector V generated in step 2 into the lightweight neural network model, perform forward propagation calculation, and output the probability distribution vector P = [p1, p2, ..., p...] for the protocol category. n ], where n is the total number of known protocol categories;

[0071] The forward propagation formula is:

[0072] Z (1) =W (1) V+b (1) A (1) =ReLU(Z) (1) ),

[0073] Z (2) =W (2) A (1) +b (2) P = Softmax(Z) (2) ),

[0074] Among them, W (1) 、b (1) W represents the first-layer weight matrix and bias vector. (2) 、b (2) Here are the output layer parameters, ReLU is the activation function, and Softmax is...

[0075] Sub-step 3.2: Confidence score calculation and threshold determination

[0076] Extract the maximum probability value p from the probability distribution P max =max(P) and the corresponding protocol identifier c id =argmax(P), calculates the confidence score s:

[0077]

[0078] Where, μ p and σ p Let τ be the mean and standard deviation of the maximum probability of all samples in the model training set, and τ be the temperature coefficient.

[0079] If s≥θ, where θ is a preset threshold, the protocol identification is deemed valid; otherwise, it is considered a low-confidence or unknown protocol.

[0080] Sub-step 3.3: Protocol conversion module retrieval and dynamic loading

[0081] When s≥θ, according to the protocol identifier c id The protocol conversion module can be quickly located using a pre-built hash index table. and adaptation configuration files Storage address in cache

[0082] The loading process follows these rules:

[0083]

[0084] Where Load is the loading operation, Memcpy is the memory copy function, and A runtime Runtime memory addresses allocated to edge inference chips;

[0085] After loading, the module With configuration file Enter the ready state and wait for step 4 to be called.

[0086] Preferably, step 4 further includes the following sub-steps:

[0087] Sub-step 4.1: Communication channel initialization and resource binding

[0088] Load-based protocol conversion module A two-way communication channel is established between the vehicle external controller and the charging pile main control system. The initialization of this channel requires the following resource allocation:

[0089] Channel up =CreateSocket(IP ctrl Port ctrl ),

[0090] Channel down =CreateSocket(IP main Port main ),

[0091] Among them, Channel up For the one-way communication link from the vehicle external controller to the charging pile main control system, Channel down This is a one-way communication link from the charging pile main control system to the vehicle external controller. `CreateSocket(·)` is an IP address. ctrl Port ctrl For the network address and port of the external controller, IP address main Port main This refers to the address and port of the charging pile's main control system.

[0092] Bandwidth allocation for channels follows:

[0093] B alloc =min(B max ,α·B req ),

[0094] Among them, B alloc For dynamically allocated communication bandwidth, B max B is the maximum allowed bandwidth of the system. req The required bandwidth is declared by the external controller, and α is the dynamic adjustment coefficient.

[0095] Sub-step 4.2: Uplink data parsing and standardized encapsulation

[0096] The external controller is controlled via Channel up Private protocol data D sent priv According to the adaptation configuration file C cid The defined rules are parsed:

[0097] Field extraction:

[0098] According to C cid The offset is defined in D. priv Extract the values ​​of each field:

[0099] v k =D priv [o k :o k +l k ], k = 1, 2, ..., K,

[0100] Among them, v k For the raw byte value of the k-th bit field extracted from the private protocol data, o k l is the starting offset of the k-th bit field. k K is the field length, and K is the total number of fields;

[0101] Type conversion:

[0102] according to A type mapping table converts raw byte data into values ​​of standardized data types. k ′:

[0103]

[0104] Standardized packaging:

[0105] The converted field values ​​are encapsulated into a standardized data structure S. std :

[0106] S std=

[0107] {command id :c id ,source:IP ctrl ,timestamp:t now payload:{v1′,...,v K ′}},

[0108] Among them, command id For the command identifier field in the standardized data structure, source is the data source field in the standardized data structure, timestamp is the timestamp field in the standardized data structure, payload is the data payload field in the standardized data structure, and t is the data payload field in the standardized data structure. now This is the current timestamp;

[0109] Sub-step 4.3: Downlink Data Parsing and Private Protocol Reconstruction

[0110] Channel for charging pile main control system down Standardized instruction S issued std Reconstructed into private protocol data D′ according to the reverse rules priv :

[0111] Field reverse mapping:

[0112] By S std Extracting the field value v′ from the payload k ,according to Convert the rules to raw bytes:

[0113]

[0114] Data frame reconstruction:

[0115] according to Define the frame structure, concatenate the bytes of each field, and add a checksum:

[0116]

[0117] Among them, D′ priv For the reconstructed private protocol data frame, P h For frame header, P f The frame end is indicated by ⊕, which represents byte concatenation. CRC32 is the cyclic redundancy check function. v″ K This is the byte encoding result for the Kth bit field.

[0118] Preferably, step 5 further includes the following sub-steps:

[0119] Sub-step 5.1: Exception triggering condition determination and sample encapsulation

[0120] The sample upload process is triggered when any of the following conditions are met:

[0121] Low confidence trigger: The confidence score s output in step 3 is less than θ, where θ is a preset threshold;

[0122] Communication anomaly triggered: within time window T monitor Within, the number of parsing errors E in the protocol conversion module err ≥E max E max Preset error count value;

[0123] Upon triggering, the modular edge recognition node encapsulates the following data into an unknown protocol sample packet S. sample :

[0124] S sample ={D raw ,V,log diag},

[0125] Among them, D raw Let V be the initial set of data packets, and V be the protocol feature vector, log diag Includes trigger type, timestamp, device ID, and error details;

[0126] Sub-step 5.2: Secure transmission and cloud task queue management

[0127] S sample After encryption and compression, the samples are uploaded to the cloud server via HTTPS. Upon receiving the samples, the cloud server adds them to the analysis queue according to the following priority formula:

[0128] Q priority =w1·T 紧急度 +w2·N 同类样本数 ,

[0129] Among them, T 紧急度 Determined by the trigger type, N 同类样本数 For the same type of c within 24 hours id Or the number of samples similar to V, where w1 and w2 are weighting coefficients;

[0130] Q in the queue priority ≥Q threshold Samples that are processed first are given priority.

[0131] Sub-step 5.3: Protocol Module Generation and Remote Deployment

[0132] Cloud server to S sample Perform the following processing flow:

[0133] Protocol Reverse Engineering:

[0134] Using dynamic taint analysis technology, by D raw Extract protocol syntax and semantic rules to generate protocol description file F. proto ;

[0135] Conversion module development:

[0136] According to F proto Automatically generate protocol conversion module M new and the C configuration file new Verify correctness through simulation testing:

[0137]

[0138] Remote deployment:

[0139] M new With C new Packaged as an update package U pkg It is distributed to all online modular edge recognition nodes via an incremental update protocol;

[0140] After receiving the data, the node updates its local database according to the following rules:

[0141] Update(M new =HashInsert(c new ,L new ),

[0142] Among them, c new L is the new protocol identifier. new This is the module's storage address.

[0143] This invention provides a communication connection method for an external vehicle controller. It has the following advantages:

[0144] 1. This invention adopts a modular edge recognition node and dynamic protocol adaptation technology to achieve the technical effect of automatically identifying the private protocols of controllers from different manufacturers and loading the corresponding conversion modules in real time. Compared with the existing technology that relies on manually developing protocol adapters, this invention solves the problem of high system integration difficulty and high construction cost caused by inconsistent protocols.

[0145] 2. This invention adopts a standardized data structure and a two-way real-time conversion technology to achieve the technical effect of establishing a stable, low-latency communication channel between the vehicle external controller and the charging pile main control system. Compared with the temporary protocol conversion technology in the prior art, this invention solves the problem of poor charging service reliability and impaired user experience caused by data transmission delay or loss.

[0146] 3. This invention adopts a cloud-based collaborative dynamic update and self-learning technology solution to achieve the technical effect of automatically identifying unknown protocols and remotely updating the local protocol library. Compared with the existing technology that uses hard-coded protocol connections, this invention solves the shortcomings of high maintenance costs and difficulty in technology updates caused by the lack of system flexibility and scalability. Attached Figure Description

[0147] Figure 1 This is a flowchart of the present invention. Detailed Implementation

[0148] To enable those skilled in the art to understand the present invention, the technical solutions of the present invention will be clearly and completely described below with reference to the accompanying drawings of the embodiments of the present invention. Obviously, the described embodiments are some, but not all, of the embodiments of the present invention. Other embodiments obtained by those skilled in the art based on the embodiments of the present invention without creative effort should fall within the scope of protection of the present invention.

[0149] The present invention will now be described in detail with reference to the accompanying drawings:

[0150] Example:

[0151] Please see the appendix Figure 1 This invention provides a method for communication connection of an external vehicle controller, comprising:

[0152] Step 1: Integrate modular edge recognition nodes within the external infrastructure. When the external infrastructure is started, the modular edge recognition nodes load a pre-built lightweight neural network model and protocol conversion module library to complete initialization. The modular edge recognition node consists of a network interface unit, an edge inference chip, and a cache unit.

[0153] Step 1 further includes the following sub-steps:

[0154] Sub-step 1.1: Hardware self-test and resource allocation

[0155] When the external infrastructure is activated, the modular edge recognition node executes a hardware self-test program, which determines the hardware unit status using the following formula:

[0156]

[0157] Among them, S i The self-test status of the i-th hardware unit, T max The preset maximum response time threshold;

[0158] If all S i =1, the node enters the resource allocation phase, and memory address space is allocated to each unit according to the following rules:

[0159] A net =M base A 推理 =A net +Δ net A 缓存 =A 推理 +Δ 推理 ,

[0160] Among them, A net 、A 推理 、A 缓存 The starting memory addresses for the network interface unit, edge inference chip, and cache unit are listed in order, M. base As the base address, Δ net Δ 推理 This is the preset address offset;

[0161] Sub-step 1.2: Loading and Integrity Verification of Lightweight Neural Network Model

[0162] After resource allocation is complete, the node reads the pre-configured lightweight neural network model file from the cache unit. The model file is stored in binary format, and its integrity is verified using a hash check formula:

[0163] H 实际 =SHA-256(F 模型 ), H 预期 =Pre-stored hash value,

[0164] If H 实际 =H 预期 The model parameters are loaded into the specified memory region of the edge inference chip according to the following mapping rules:

[0165] θ k →A 推理 +k·δ, k=0,1,…,N param -1,

[0166] Where, θ k Let N be the k-th parameter of the model, δ be the number of bytes occupied by a single parameter, and N be the number of bytes occupied by a single parameter. param Where k is the total number of parameters and k is the sequential index.

[0167] If the hash verification fails, an alarm will be triggered and initialization will be terminated.

[0168] Sub-step 1.3: Loading and indexing the protocol conversion module library

[0169] After the model is loaded, the node reads the protocol conversion module library from the cache unit. The library contains the protocol conversion module {M}. p |p∈P}, where P is the set of protocol identifiers, and each module is associated with an adaptation configuration file C. p ;

[0170] The node is a fast retrieval module that constructs a hash index table based on protocol identifiers:

[0171] Index(p) = Hash(p) mod B size ,

[0172] Where Index(p) is the storage index of the protocol identifier p in the hash table, B size Let p be the number of hash table buckets, and Hash(p) be the hash value of the protocol identifier p.

[0173] Each bucket stores the corresponding module M p Storage address L in the cache p and configuration file C p Metadata;

[0174] Step 2: The modular edge recognition node that has completed initialization captures the initial data packet generated when the external controller accesses the vehicle, and extracts multi-dimensional features from the initial data packet to generate a protocol feature vector. The multi-dimensional features include structural features, statistical features and content features extracted from the initial data packet.

[0175] Step 2 further includes the following sub-steps:

[0176] Sub-step 2.1: Packet capture and time window triggering

[0177] The network interface unit listens to the communication port in real time. When it detects a data packet sent by the external controller, it starts a dynamic time window T. win In T win The subsequent N were captured continuously. pkt Bit data packets constitute the initial data packet set.

[0178] The triggering condition for the time window is:

[0179] T win =max(t) first +Δ base ,t last +Δ extend ),

[0180] Among them, t first t represents the arrival time of the first data packet. last Δ represents the arrival time of the last data packet. base Δ is the base window length. extend Expand the window incrementally;

[0181] If in T win Number of packets N captured pkt <N min Nmin If the minimum number of valid packets is reached, the connection is deemed invalid and its data is discarded.

[0182] Sub-step 2.2: Multi-dimensional feature extraction and quantization

[0183] For each data packet d in set D i Extract three types of features according to the following rules:

[0184] Structural feature extraction:

[0185] Matching data packet d i Calculate the structural feature vector based on the frame header and frame tail patterns.

[0186]

[0187] Among them, P h and P f For a predefined library of frame header and frame tail patterns, Match(·) is the function return value of the matching degree, ||d i || represents the data packet length, L max Maximum allowed packet length;

[0188] Statistical feature extraction:

[0189] Calculate the mean and variance of the arrival time intervals between adjacent data packets to construct a statistical feature vector F. stat :

[0190]

[0191] Where, μ t t is the average time interval between the arrival of adjacent data packets. k For the k-th data d k Arrival timestamp, t k-1 For the (k-1)th data packet d k-1 The arrival timestamp, where k is the sequential index. N is the variance of the arrival time interval between adjacent data packets. pkt For dynamic time window T win The initial total number of packets captured, N cmd The number of data packets containing the preset command word in set D;

[0192] Content feature extraction:

[0193] Scan the data packet payload, identify the frequency of occurrence in a predefined keyword set K, and generate a content feature vector F. cont :

[0194] F cont =[∑ d∈D I(k1∈d),…,∑d∈D I(k m ∈d)],

[0195] Where I(·) is the indicator function, k1, k m d represents an element in the font library, and d represents a data packet instance in the data packet set D.

[0196] Sub-step 2.3: Feature fusion and normalization to generate protocol feature vectors

[0197] The three types of features mentioned above are concatenated and normalized according to the following rules to generate the final protocol feature vector V:

[0198]

[0199] V = [v′1, v′2, ..., v′] n ],

[0200] Among them, V raw v′ is the original multidimensional feature vector. j The original feature vector V raw The result after standardization of the j-th eigenvalue, v j The original feature vector V raw The original eigenvalue of the j-th dimension, μ j and σ j The mean and standard deviation of the j-th feature are pre-computed, where j is the dimension index of the feature vector;

[0201] If the feature does not appear in the training data, then v′ j =0;

[0202] Step 3: Input the protocol feature vector into the lightweight neural network model to calculate the protocol recognition result and confidence score. When the confidence score is higher than the preset threshold, load the corresponding protocol conversion module from the protocol conversion module library according to the protocol recognition result.

[0203] Step 3 further includes the following sub-steps:

[0204] Sub-step 3.1: Model forward propagation and protocol probability distribution calculation

[0205] Input the protocol feature vector V generated in step 2 into the lightweight neural network model, perform forward propagation calculation, and output the probability distribution vector P = [p1, p2, ..., p...] for the protocol category. n ], where n is the total number of known protocol categories;

[0206] The forward propagation formula is:

[0207] Z (1) =W (1) V+b(1) A (1) =ReLU(Z) (1) ),

[0208] Z (2) =W (2) A (1) +b (2) P = Softmax(Z) (2) ),

[0209] Among them, W (1) 、b (1) W represents the first-layer weight matrix and bias vector. (2) 、b (2) Here are the output layer parameters, ReLU is the activation function, and Softmax is...

[0210] Sub-step 3.2: Confidence score calculation and threshold determination

[0211] Extract the maximum probability value p from the probability distribution P max =max(P) and the corresponding protocol identifier c id =argmax(P), calculates the confidence score s:

[0212]

[0213] Where, μ p and σ p Let τ be the mean and standard deviation of the maximum probability of all samples in the model training set, and τ be the temperature coefficient.

[0214] If s≥θ, where θ is a preset threshold, the protocol identification is deemed valid; otherwise, it is considered a low-confidence or unknown protocol.

[0215] Sub-step 3.3: Protocol conversion module retrieval and dynamic loading

[0216] When s≥θ, according to the protocol identifier c id The protocol conversion module can be quickly located using a pre-built hash index table. and adaptation configuration files Storage address in cache

[0217] The loading process follows these rules:

[0218]

[0219] Where Load is the loading operation, Memcpy is the memory copy function, and A runtime Runtime memory addresses allocated to edge inference chips;

[0220] After loading, the module With configuration file Enter the ready state and wait for step 4 to be called;

[0221] Step 4: Use the loaded protocol conversion module to establish a two-way communication channel between the vehicle external controller and the charging pile main control system. The two-way communication channel is used to convert and transmit the private protocol data of the vehicle external controller and the standardized data structure of the charging pile main control system.

[0222] Step 4 further includes the following sub-steps:

[0223] Sub-step 4.1: Communication channel initialization and resource binding

[0224] Load-based protocol conversion module A two-way communication channel needs to be established between the vehicle external controller and the charging pile main control system. The initialization of the channel requires the following resource allocation:

[0225] Channel up =CreateSocket(IP ctrl Port ctrl ),

[0226] Channel down =CreateSocket(IP main Port main ),

[0227] Among them, Channel up For the one-way communication link from the vehicle external controller to the charging pile main control system, Channel down This is a one-way communication link from the charging pile main control system to the vehicle external controller. `CreateSocket(·)` is an IP address. ctrl Port ctrl For the network address and port of the external controller, IP address main Port main This refers to the address and port of the charging pile's main control system.

[0228] Bandwidth allocation for channels follows:

[0229] B alloc =min(B max ,α·B req ),

[0230] Among them, B alloc For dynamically allocated communication bandwidth, B max B is the maximum allowed bandwidth of the system. req The required bandwidth is declared by the external controller, and α is the dynamic adjustment coefficient.

[0231] Sub-step 4.2: Uplink data parsing and standardized encapsulation

[0232] The external controller is controlled via Channel up Private protocol data D sent priv According to the adaptation configuration file C cid The defined rules are parsed:

[0233] Field extraction:

[0234] According to C cid The offset is defined in D. priv Extract the values ​​of each field:

[0235] v k =D priv [o k :o k +l k ], k = 1, 2, ..., K,

[0236] Among them, v k For the raw byte value of the k-th bit field extracted from the private protocol data, o k l is the starting offset of the k-th bit field. k K is the field length, and K is the total number of fields;

[0237] Type conversion:

[0238] according to A type mapping table converts raw byte data into values ​​of standardized data types. k ′:

[0239]

[0240] Standardized packaging:

[0241] The converted field values ​​are encapsulated into a standardized data structure S. std :

[0242] S std =

[0243] {command id :c id ,source:IP ctrl ,timestamp:t now payload:{v1′,...,v K ′}},

[0244] Among them, command idFor the command identifier field in the standardized data structure, source is the data source field in the standardized data structure, timestamp is the timestamp field in the standardized data structure, payload is the data payload field in the standardized data structure, and t is the data payload field in the standardized data structure. now This is the current timestamp;

[0245] Sub-step 4.3: Downlink Data Parsing and Private Protocol Reconstruction

[0246] Channel for charging pile main control system down Standardized instruction S issued std Reconstructed into private protocol data D′ according to the reverse rules priv :

[0247] Field reverse mapping:

[0248] By S std Extracting the field value v′ from the payload k ,according to Convert the rules to raw bytes:

[0249]

[0250] Data frame reconstruction:

[0251] according to Define the frame structure, concatenate the bytes of each field, and add a checksum:

[0252]

[0253] Among them, D′ priv For the reconstructed private protocol data frame, P h For frame header, P f For the end of the frame, For byte concatenation, CRC32 is the cyclic redundancy check function, v″ K This is the byte encoding result of the Kth bit field;

[0254] Step 5: When the confidence score is not higher than the preset threshold or the communication anomaly rate of the two-way communication channel exceeds the fault tolerance limit, the modular edge recognition node uploads the unknown protocol sample containing the initial data packet to the cloud server. After receiving the unknown protocol sample, the cloud server generates or updates the protocol conversion module and sends it to the modular edge recognition node. The unknown protocol sample contains the protocol feature vector and related diagnostic logs.

[0255] Step 5 further includes the following sub-steps:

[0256] Sub-step 5.1: Exception triggering condition determination and sample encapsulation

[0257] The sample upload process is triggered when any of the following conditions are met:

[0258] Low confidence trigger: The confidence score s output in step 3 is less than θ, where θ is a preset threshold;

[0259] Communication anomaly triggered: within time window T monitor Within, the number of parsing errors E in the protocol conversion module err ≥E max E max Preset error count value;

[0260] Upon triggering, the modular edge recognition node encapsulates the following data into an unknown protocol sample packet S. sample :

[0261] S sample ={D raw ,V,log diag},

[0262] Among them, D raw Let V be the initial set of data packets, and V be the protocol feature vector, log diag Includes trigger type, timestamp, device ID, and error details;

[0263] Sub-step 5.2: Secure transmission and cloud task queue management

[0264] S sample After encryption and compression, the samples are uploaded to the cloud server via HTTPS. Upon receiving the samples, the cloud server adds them to the analysis queue according to the following priority formula:

[0265] Q priority =w1·T 紧急度 +w2·N 同类样本数 ,

[0266] Among them, T 紧急度 Determined by the trigger type, N 同类样本数 For the same type of c within 24 hours id Or the number of samples similar to V, where w1 and w2 are weighting coefficients;

[0267] Q in the queue priority ≥Q threshold Samples that are processed first are given priority.

[0268] Sub-step 5.3: Protocol Module Generation and Remote Deployment

[0269] Cloud server to S sample Perform the following processing flow:

[0270] Protocol Reverse Engineering:

[0271] Using dynamic taint analysis technology, by Draw Extract protocol syntax and semantic rules to generate protocol description file F. proto ;

[0272] Conversion module development:

[0273] According to F proto Automatically generate protocol conversion module M new and the C configuration file new Verify correctness through simulation testing:

[0274]

[0275] Remote deployment:

[0276] M new With C new Packaged as an update package U pkg It is distributed to all online modular edge recognition nodes via an incremental update protocol;

[0277] After receiving the data, the node updates its local database according to the following rules:

[0278] Update(M new =HashInsert(c new ,L new ),

[0279] Among them, c new L is the new protocol identifier. new This is the module's storage address.

[0280] Step 1 utilizes a hardware self-test program and dynamic resource allocation mechanism to ensure that modular edge recognition nodes quickly complete hardware status verification and memory space planning during the startup phase. The judgment logic of the hardware self-test formula can identify faulty units, preventing system crashes due to single-point hardware failures. The linear mapping strategy of memory address allocation rules effectively isolates data access conflicts between different functional units, improving the computational efficiency of the edge inference chip. The hash verification mechanism and parameter loading rules of the lightweight neural network model ensure the integrity of the model file and memory alignment, avoiding inference errors caused by model corruption or loading offsets. The hash index construction of the protocol conversion module library significantly improves the module retrieval speed, with measured protocol matching latency reduced to milliseconds, laying the foundation for subsequent real-time communication.

[0281] Step 2's dynamic time window triggering mechanism can flexibly handle differences in data packet transmission frequencies across different protocols, avoiding incomplete feature sampling or resource waste caused by a fixed window length. The calculation of the frame header / tail matching degree of the structural feature vector, combined with packet length normalization, characterizes the protocol frame structure and effectively distinguishes similar protocol variants. The calculation of the mean and variance of the statistical feature vector and command word frequency statistics quantify the characteristics of protocol interaction patterns, enhancing the robustness of identifying periodic or bursty protocols.

[0282] Step 3 employs a lightweight neural network model with a two-layer forward propagation design. While ensuring computational efficiency, it achieves an effective mapping from the high-dimensional feature space to protocol categories through a non-linear activation function and Softmax output. The confidence score s is calculated by incorporating statistical priors from the training set and a temperature coefficient, dynamically adjusting the scoring scale to avoid misjudgments caused by model overfitting. The dynamic loading mechanism of the protocol conversion module achieves zero-latency switching through direct memory copying and runtime address binding. The measured protocol switching time is less than 50ms, meeting automotive-grade real-time requirements.

[0283] Step 4 implements dynamic bandwidth allocation rules for the communication channel. While ensuring system stability, it adaptively increases the communication resource allocation of high-priority controllers by adjusting coefficients, resulting in a measured bandwidth utilization improvement of over 30%. The field extraction rules and type conversion logic for uplink data parsing, combined with standardized encapsulated predefined structures, achieve a one-to-one mapping from private protocols to standardized data, avoiding data semantic distortion caused by field misalignment.

[0284] Step 5's anomaly triggering condition determination formula uses a dual threshold mechanism to distinguish between occasional noise and truly unknown protocols, reducing invalid sample uploads. Cloud task queue priority calculation, combined with weighting coefficients, prioritizes high-frequency or high-risk protocol samples, shortening the response cycle for unknown protocols to within 24 hours. Dynamic taint tracking technology for protocol reverse analysis automatically generates protocol description files through data flow tracing and syntax rule extraction, improving efficiency by more than 10 times compared to traditional manual reverse engineering. Incremental protocol updates require the transmission of differential data packets, reducing the time for edge node protocol library updates from minutes to seconds, supporting seamless upgrades of charging station networks.

[0285] Although embodiments of the invention have been shown and described, it will be understood by those skilled in the art that various changes, modifications, substitutions and alterations can be made to these embodiments without departing from the principles and spirit of the invention, the scope of which is defined by the appended claims and their equivalents.

Claims

1. A communication connection method for an external vehicle controller, characterized in that, include: Step 1: Integrate a modular edge recognition node within the external infrastructure. The modular edge recognition node is initialized by loading a pre-built lightweight neural network model and protocol conversion module library when the external infrastructure is started. The modular edge recognition node consists of a network interface unit, an edge inference chip, and a cache unit. Step 2: The modular edge recognition node, after initialization, captures the initial data packet generated when the vehicle external controller accesses the system, and extracts multi-dimensional features from the initial data packet to generate a protocol feature vector. The multi-dimensional features include structural features, statistical features, and content features extracted from the initial data packet. Step 3: Input the protocol feature vector into the lightweight neural network model to calculate and obtain the protocol identification result and confidence score. When the confidence score is higher than the preset threshold, load the corresponding protocol conversion module from the protocol conversion module library according to the protocol identification result. Step 4: Use the loaded protocol conversion module to establish a two-way communication channel between the vehicle external controller and the charging pile main control system. The two-way communication channel is used to convert and transmit the private protocol data of the vehicle external controller and the standardized data structure of the charging pile main control system. Step 5: When the confidence score is not higher than the preset threshold or the communication anomaly rate of the bidirectional communication channel exceeds the fault tolerance limit, the modular edge recognition node uploads the unknown protocol sample containing the initial data packet to the cloud server. After receiving the unknown protocol sample, the cloud server generates or updates the protocol conversion module and sends it to the modular edge recognition node. The unknown protocol sample contains the protocol feature vector and related diagnostic logs.

2. The communication connection method for an external vehicle controller according to claim 1, characterized in that, The lightweight neural network model is used to perform classification calculations on the protocol feature vectors to output the protocol identification results; The protocol identification result is loaded into the protocol conversion module, which includes loading an adaptation configuration file that matches the protocol conversion module. The adaptation configuration file is used to define the field mapping relationship between private protocol data and standardized data structures.

3. The communication connection method for an external vehicle controller according to claim 1, characterized in that, The standardized data structure is a predefined data object that is independent of specific private protocols. The data object contains a unified command identifier, data source, timestamp, and data payload fields. The real-time conversion and transmission include uplink conversion of parsing and encapsulating the private protocol data into the standardized data structure, and downlink conversion of parsing and encapsulating the standardized data structure into the private protocol data.

4. The communication connection method for an external vehicle controller according to claim 1, characterized in that, The cloud server is specifically used to receive the unknown protocol sample, analyze the unknown protocol sample to generate a new protocol conversion module, and remotely deploy the new protocol conversion module to the modular edge recognition node.

5. The communication connection method for an external vehicle controller according to claim 1, characterized in that, The communication error rate exceeding the fault tolerance limit means that the protocol conversion module, when parsing the private protocol data, has encountered a number of consecutive parsing errors that reach a preset error count value.

6. The communication connection method for an external vehicle controller according to claim 1, characterized in that, Step 1 further includes the following sub-steps: Sub-step 1.1: Hardware self-test and resource allocation When the external infrastructure is activated, the modular edge recognition node executes a hardware self-test program, which determines the hardware unit status using the following formula: Among them, S i The self-test status of the i-th hardware unit, T max This is the preset maximum response time threshold; If all S i =1, the node enters the resource allocation phase, and memory address space is allocated to each unit according to the following rules: A net =M base ,A 推理 =A net +D net ,A 缓存 =A 推理 +D 推理 , Among them, A net A 推理 A 缓存 The starting memory addresses for the network interface unit, edge inference chip, and cache unit are listed in order, M. base As the base address, Δ net Δ 推理 This is the preset address offset; Sub-step 1.2: Loading and Integrity Verification of Lightweight Neural Network Model After resource allocation is completed, the node reads the pre-set lightweight neural network model file from the cache unit. The model file is stored in binary format, and its integrity is verified by a hash check formula: H 实际 =SHA-256(F 模型 ), H 预期 =Pre-stored hash value, If H 实际 =H 预期 The model parameters are loaded into the specified memory region of the edge inference chip according to the following mapping rules: i k →A 推理 +k·δ,k=0,1,…,N param -1, Where, θ k Let N be the k-th parameter of the model, δ be the number of bytes occupied by a single parameter, and N be the number of bytes occupied by a single parameter. param Where k is the total number of parameters and k is the sequential index; If the hash verification fails, an alarm will be triggered and initialization will be terminated. Sub-step 1.3: Loading and indexing the protocol conversion module library After the model is loaded, the node reads the protocol conversion module library from the cache unit. This library contains the protocol conversion module {M}. p |p∈P}, where P is the set of protocol identifiers, and each module is associated with an adaptation configuration file C. p ; The node is a fast retrieval module that constructs a hash index table based on protocol identifiers: Index(p)=Hash(p)mod B size , Where Index(p) is the storage index of the protocol identifier p in the hash table, B size Let p be the number of hash table buckets, and Hash(p) be the hash value of the protocol identifier p. Each bucket stores the corresponding module M p Storage address L in the cache p and configuration file C p Metadata.

7. The communication connection method for an external vehicle controller according to claim 1, characterized in that, Step 2 further includes the following sub-steps: Sub-step 2.1: Packet capture and time window triggering The network interface unit monitors the communication port in real time. When it detects a data packet sent by the external controller, it activates a dynamic time window T. win In T win The subsequent N were captured continuously. pkt Bit data packets constitute the initial data packet set. The triggering condition for the time window is: T win =max(t first +Δ base ,t last +Δ extend ), Among them, t first t represents the arrival time of the first data packet. last Δ represents the arrival time of the last data packet. base Δ is the base window length. extend Expand the window incrementally; If in T win Number of packets N captured pkt <N min N min If the minimum number of valid packets is reached, the connection is deemed invalid and its data is discarded. Sub-step 2.2: Multi-dimensional feature extraction and quantization For each data packet d in set D i Extract three types of features according to the following rules: Structural feature extraction: Matching data packet d i Calculate the structural feature vector based on the frame header and frame tail patterns. Among them, P h and P f For a predefined library of frame header and frame tail patterns, Match(·) is the function return value of the matching degree, ||d i || represents the data packet length, L max Maximum allowed packet length; Statistical feature extraction: Calculate the mean and variance of the arrival time intervals between adjacent data packets to construct a statistical feature vector F. stat : Where, μ t t is the average time interval between the arrival of adjacent data packets. k For the k-th data d k Arrival timestamp, t k-1 For the (k-1)th data packet d k-1 The arrival timestamp, where k is the sequential index. N is the variance of the arrival time interval between adjacent data packets. pkt For dynamic time window T win The initial total number of packets captured, N cmd The number of data packets containing the preset command word in set D; Content feature extraction: Scan the data packet payload, identify the frequency of occurrence in a predefined keyword set K, and generate a content feature vector F. cont : F cont =[∑ d∈D I(k1∈d),…,∑ d∈D I(k m ∈d)], Where I(·) is the indicator function, k1, k m d represents an element in the font library, and d represents a data packet instance in the data packet set D. Sub-step 2.3: Feature fusion and normalization to generate protocol feature vectors The three types of features mentioned above are concatenated and normalized according to the following rules to generate the final protocol feature vector V: V=[v′1,v′2,...,v′ n ], Among them, V raw v′ is the original multidimensional feature vector. j The original feature vector V raw The result after standardization of the j-th eigenvalue, v j The original feature vector V raw The original eigenvalue of the j-th dimension, μ j and σ j The mean and standard deviation of the j-th feature are pre-computed, where j is the dimension index of the feature vector; If the feature does not appear in the training data, then v′ j =0.

8. The communication connection method for an external vehicle controller according to claim 1, characterized in that, Step 3 further includes the following sub-steps: Sub-step 3.1: Model forward propagation and protocol probability distribution calculation Input the protocol feature vector V generated in step 2 into the lightweight neural network model, perform forward propagation calculation, and output the probability distribution vector P = [p1, p2, ..., p...] for the protocol category. n ], where n is the total number of known protocol categories; The forward propagation formula is: WITH (1) =In (1) V+b (1) ,AND (1) =ReLU(Z (1) ), Z (2) =W (2) A (1) +b (2) ,P=Softmax(Z (2) ), Among them, W (1) b (1) W represents the first-layer weight matrix and bias vector. (2) b (2) Here are the output layer parameters, ReLU is the activation function, and Softmax is... Sub-step 3.2: Confidence score calculation and threshold determination Extract the maximum probability value p from the probability distribution P max =max(P) and the corresponding protocol identifier c id =argmax(P), calculates the confidence score s: Where, μ p and σ p Let τ be the mean and standard deviation of the maximum probability of all samples in the model training set, and τ be the temperature coefficient. If s≥θ, where θ is a preset threshold, the protocol identification is deemed valid; otherwise, it is considered a low-confidence or unknown protocol. Sub-step 3.3: Protocol conversion module retrieval and dynamic loading When s≥θ, according to the protocol identifier c id The protocol conversion module can be quickly located using a pre-built hash index table. and adaptation configuration files Storage address in cache The loading process follows these rules: Where Load is the loading operation, Memcpy is the memory copy function, and A runtime Runtime memory addresses allocated to edge inference chips; After loading, the module With configuration file Enter the ready state and wait for step 4 to be called.

9. The communication connection method for an external vehicle controller according to claim 1, characterized in that, Step 4 further includes the following sub-steps: Sub-step 4.1: Communication channel initialization and resource binding Load-based protocol conversion module A bidirectional communication channel needs to be established between the vehicle external controller and the charging pile main control system. The initialization of this channel requires the following resource allocation: Channel up =CreateSocket(IP ctrl ,Port ctrl ), Channel down =CreateSocket(IP main ,Port main ), Among them, Channel up For the one-way communication link from the vehicle external controller to the charging pile main control system, Channel down This is a one-way communication link from the charging pile main control system to the vehicle external controller. `CreateSocket(·)` is an IP address. ctrl Port ctrl For the network address and port of the external controller, IP address main Port main This refers to the address and port of the charging pile's main control system. Bandwidth allocation for channels follows: B alloc =min(B max ,a·B req ), Among them, B alloc For dynamically allocated communication bandwidth, B max B is the maximum allowed bandwidth of the system. req The required bandwidth is declared by the external controller, and α is the dynamic adjustment coefficient. Sub-step 4.2: Uplink data parsing and standardized encapsulation The external controller is controlled via Channel up Private protocol data D sent priv According to the adaptation configuration file C cid The defined rules are parsed: Field extraction: According to C cid The offset is defined in D. priv Extract the values ​​of each field: in k =D priv [about k :o k +l k ], k=1,2,...,K, Among them, v k For the raw byte value of the k-th bit field extracted from the private protocol data, o k l is the starting offset of the k-th bit field. k K is the field length, and K is the total number of fields; Type conversion: according to A type mapping table converts raw byte data into values ​​of standardized data types. k ′: Standardized packaging: The converted field values ​​are encapsulated into a standardized data structure S. std : S std ＝ {command id :c id ,source:IP ctrl ,timestamp:t now ,payload:{v1′,...,v K ′}}, Among them, command id For the command identifier field in the standardized data structure, source is the data source field in the standardized data structure, timestamp is the timestamp field in the standardized data structure, payload is the data payload field in the standardized data structure, and t is the data payload field in the standardized data structure. now This is the current timestamp; Sub-step 4.3: Downlink Data Parsing and Private Protocol Reconstruction Channel for charging pile main control system down Standardized instruction S issued std Reconstructed into private protocol data D′ according to the reverse rules priv : Field reverse mapping: By S std Extracting the field value v′ from the payload k ,according to Convert the rules to raw bytes: Data frame reconstruction: according to Define the frame structure, concatenate the bytes of each field, and add a checksum: Among them, D′ priv For the reconstructed private protocol data frame, P h For frame header, P f For the end of the frame, For byte concatenation, CRC32 is the cyclic redundancy check function, v″ K This is the byte encoding result for the Kth bit field.

10. The communication connection method for an external vehicle controller according to claim 1, characterized in that, Step 5 further includes the following sub-steps: Sub-step 5.1: Exception triggering condition determination and sample encapsulation The sample upload process is triggered when any of the following conditions are met: Low confidence trigger: The confidence score s output in step 3 is less than θ, where θ is a preset threshold; Communication anomaly triggered: within time window T monitor Within, the number of parsing errors E in the protocol conversion module err ≥E max , E max Preset error count value; Upon triggering, the modular edge recognition node encapsulates the following data into an unknown protocol sample packet S. sample : S sample ={D raw ,V,log diag }, Among them, D raw Let V be the initial set of data packets, and V be the protocol feature vector, log diag Includes trigger type, timestamp, device ID, and error details; Sub-step 5.2: Secure transmission and cloud task queue management S sample After encryption and compression, the samples are uploaded to the cloud server via HTTPS. Upon receiving the samples, the cloud server adds them to the analysis queue according to the following priority formula: Q priority =w1·T 紧急度 +w2·N 同类样本数 , Among them, T 紧急度 Determined by the trigger type, N 同类样本数 For the same type of c within 24 hours id Or the number of samples similar to V, where w1 and w2 are weighting coefficients; Q in the queue priority ≥Q threshold Samples that are processed first are given priority. Sub-step 5.3: Protocol Module Generation and Remote Deployment Cloud server to S sample Perform the following processing flow: Protocol Reverse Engineering: Using dynamic taint analysis technology, by D raw Extract protocol syntax and semantic rules to generate protocol description file F. proto ; Conversion module development: According to F proto Automatically generate protocol conversion module M new and the C configuration file new Verify correctness through simulation testing: Remote deployment: M new With C new Packaged as an update package U pkg It is distributed to all online modular edge recognition nodes via an incremental update protocol; After receiving the data, the node updates its local database according to the following rules: Update(M new )=HashInsert(c new ,L new ), Among them, c new L is the new protocol identifier. new This is the module's storage address.

Images