Automatic switching method and system adaptive to multiple communication protocols

Abstract

The invention relates to an automatic switching method and system adaptive to multiple communication protocols, and the method comprises the steps: executing the wake-up operation of a controller after an instrument is powered on, and monitoring a data frame on a CAN bus; extracting a CANID (Controller Area Network Identifier) in the data frame, matching the CANID with a preset manufacturer handshake command list, and judging whether a handshake command exists or not; if the matched handshake instruction exists, determining a corresponding manufacturer communication protocol type; according to the manufacturer communication protocol type, determining a corresponding CAN message analysis method and a CAN message sending method; receiving a first CAN message, and analyzing the first CAN message by using a CAN message analysis method to generate display data; and obtaining operation data of the user, converting the operation data into a second CAN message according to the CAN message sending method, and sending the second CAN message to the controller. The application has the effect of improving the communication efficiency.

Description

Technical Field

[0001] The present application relates to the technical field of E-BIKE instruments, and in particular to an automatic switching method and system for adapting to multiple communication protocols. Background Art

[0002] With the widespread use of electronic devices, the demand for communication between devices from different manufacturers is increasing. However, due to the lack of unified communication protocols among manufacturers, it is difficult to achieve interoperability between different devices. For example, between the instrument and controller of an electric vehicle, because manufacturers use different communication protocols (such as different CAN message formats, frame specifications, etc.), the instrument cannot correctly parse and send the CAN messages required by the controller, thus affecting the system's functions and user experience.

[0003] The above-mentioned prior art solutions have the following defects: the prior art cannot achieve fast and automatic adaptation of multiple communication protocols between the E-BIKE instrument and the controller, and it is difficult to dynamically load new protocol methods, so there is room for improvement. Summary of the invention

[0004] In order to improve communication efficiency, the present application provides an automatic switching method and system adapted to multiple communication protocols.

[0005] The above-mentioned invention objective of the present application is achieved through the following technical solutions: An automatic switching method for adapting multiple communication protocols, the automatic switching method for adapting multiple communication protocols comprising: After the instrument is powered on, the controller wakes up and monitors the data frames on the CAN bus. Extracting the CAN_ID in the data frame, matching the CAN_ID with a preset manufacturer handshake command list, and determining whether a handshake command exists; If there is a matching handshake instruction, the corresponding manufacturer communication protocol type is determined; According to the manufacturer's communication protocol type, determine the corresponding CAN message parsing method and CAN message sending method; Receiving a first CAN message, parsing the first CAN message using the CAN message parsing method, and generating display data; The user's operation data is obtained, and the operation data is converted into a second CAN message according to the CAN message sending method and sent to the controller.

[0006] By adopting the above technical solution, the controller wake-up operation is executed immediately after the instrument is powered on to ensure that the controller enters the communication preparation state, establish a foundation for subsequent communication, and capture the handshake information sent by the controller in real time by monitoring the data frames on the CAN bus, and quickly enter the protocol identification process; by extracting the CAN_ID in the data frame, the key fields related to the handshake are screened out, and the interference of irrelevant data is effectively reduced. By matching with the preset manufacturer's handshake command list, it is quickly determined whether there is a handshake command, thereby improving the protocol identification efficiency; by matching the handshake instructions, the manufacturer to which the controller belongs and its communication protocol type are automatically identified, and the automatic adaptation of the protocol is realized, avoiding the tedious operation of the user manually configuring the protocol type, and improving the intelligence of the system and the user Experience; by loading the parsing method and sending method according to the manufacturer's communication protocol type, it ensures that the communication data of the controller can be processed correctly, improves the scalability and compatibility of the system, and supports dynamic adaptation of multiple manufacturers and multiple protocols; by receiving the first CAN message and using the corresponding parsing method, it accurately extracts the valid data in the message to avoid parsing failure caused by protocol mismatch, and by generating display data, it presents the vehicle status information to the user in a timely manner, thereby improving the user experience; by obtaining the user's operation data and converting it into the second CAN message, it ensures that the user's control instructions meet the communication protocol requirements of the controller, and by sending the second CAN message to the controller, it realizes effective control of the controller and ensures the real-time and reliability of user operations.

[0007] In one example, the present application may be further configured as follows: after the meter is powered on, executing the wake-up operation of the controller includes: After the meter is powered on, sending a set of preset wake-up data frames; After receiving the wake-up data frame, the controller sends a handshake response signal to the instrument to complete the wake-up operation of the controller.

[0008] By adopting the above technical solution, by actively sending a preset wake-up data frame after the instrument is powered on, the controller can be awakened in time to enter the working state, ensuring the initialization of the communication link. By sending a wake-up data frame in a specific format, the error probability in the communication process is reduced and the reliability of the wake-up operation is improved. The controller receives the wake-up data frame and returns a handshake response signal to ensure that the instrument can confirm that the controller has been successfully awakened, thereby improving the stability of the communication initialization process. Through the feedback of the handshake response signal, the communication status of the instrument and the controller can be synchronized, providing a guarantee for subsequent protocol identification and data interaction.

[0009] In one example, the present application may be further configured as follows: extracting the CAN_ID in the data frame, matching the CAN_ID with a preset manufacturer handshake command list, and determining whether a handshake command exists includes: Extracting the CAN_ID from the data frame, and checking whether the CAN_ID complies with a predefined frame format rule; If the CAN_ID conforms to the predefined frame format rule, the CAN_ID is compared with the identifiers in the preset manufacturer handshake command list one by one to generate a comparison result; If the comparison result is that the CAN_ID successfully matches the identifier in the preset manufacturer handshake command list, the corresponding matching manufacturer identifier is recorded.

[0010] By adopting the above technical solution, by extracting CAN_ID from the data frame, the key identification information of the communication data can be quickly located, avoiding processing the entire data frame, and improving the parsing efficiency. By checking whether the CAN_ID conforms to the predefined frame format rules, abnormal or invalid data frames can be effectively filtered to ensure the accuracy and reliability of subsequent processing of the system; by comparing the CAN_ID that conforms to the rules with the identifiers in the manufacturer's handshake command list one by one, the manufacturer's protocol type of the controller can be quickly identified. By generating the comparison results, the system can intuitively determine the manufacturer type of the current communication, providing a basis for subsequent protocol parsing and sending method selection; by recording the manufacturer identifiers of successful matches, the current communication environment can be associated with the specific manufacturer's protocol type, ensuring that subsequent data interactions conform to communication specifications, and by accurately recording the matching results, the computational overhead of repeated identification and parsing is reduced, thereby improving the system operation efficiency.

[0011] In one example, the present application may be further configured as follows: the CAN_ID is compared with the identifiers in the preset manufacturer handshake command list one by one, and the generation of the comparison result includes: Assigning matching priorities to the preset manufacturer handshake command list according to protocol types; Based on the matching priority, the CAN_ID is compared with the identifiers in the preset manufacturer handshake command list one by one to generate the comparison result.

[0012] By adopting the above technical solution and assigning matching priorities according to protocol types, it is possible to give priority to commonly used or key protocols, reduce unnecessary comparison operations, and improve protocol matching efficiency. By prioritizing protocol types, it is possible to ensure that important protocols are identified first in multi-protocol scenarios, thereby improving system initialization speed and communication reliability. Through a priority-based one-by-one comparison mechanism, the target manufacturer's protocol type can be quickly locked in fewer matches, reducing the time consumption of protocol matching. By generating comparison results, the system can intuitively confirm the protocol type of the current communication device, providing a basis for subsequent loading of parsing methods and sending methods.

[0013] In one example, the present application may be further configured as follows: determining the corresponding CAN message parsing method and CAN message sending method according to the manufacturer communication protocol type includes: According to the manufacturer's communication protocol type, query the CAN message parsing script and CAN message sending rules corresponding to the manufacturer's communication protocol type from the protocol module built into the instrument to obtain the query result; If the query result is that there is a match, determining the CAN message parsing method and the CAN message sending method according to the corresponding CAN message parsing script and CAN message sending rule; If the query result is that there is no match, the parsing method and sending method corresponding to the manufacturer's communication protocol type are dynamically downloaded through a network connection, and the dynamically downloaded parsing method and sending method are loaded into the protocol module.

[0014] By adopting the above technical solution, by querying the corresponding CAN message parsing script and sending rules in the built-in protocol module of the instrument, the communication method required by the current manufacturer's protocol can be quickly located, reducing the initialization time; through the feedback of the query results, the system can determine in real time whether the required parsing methods and sending rules are available, thereby improving the immediacy and reliability of protocol adaptation; by directly loading the built-in parsing script and sending rules by matching the query results, the system's dependence on external resources can be reduced and the operating efficiency can be improved; by determining the specific parsing method and sending method, it is ensured that the subsequent data parsing and sending comply with the current manufacturer's protocol specifications, thereby improving the accuracy and stability of communication; by dynamically downloading unmatched parsing methods and sending methods through the network, the system's support for new manufacturer protocols can be expanded and the compatibility of the equipment can be improved; by loading the dynamically downloaded parsing methods and sending methods into the protocol module, real-time updating of the local method library is achieved, avoiding subsequent repeated downloads, and improving the scalability and resource utilization of the system.

[0015] In one example, the present application may be further configured as follows: the receiving of the first CAN message, parsing the first CAN message using the CAN message parsing method, and generating display data includes: Checking the frame header information of the first CAN message, the frame header information including CAN_ID, data length code and frame format, and determining whether the first CAN message complies with the frame specification of the manufacturer communication protocol type; If the first CAN message complies with the frame specification of the manufacturer's communication protocol type, extracting the valid data field in the first CAN message by using the CAN message parsing method; The display data is generated according to the valid data field and a predefined display rule, and the display data is loaded into a display module of the instrument.

[0016] By adopting the above technical solution, by checking the frame header information of the first CAN message, the basic attributes and data validity of the message can be quickly determined, and invalid or erroneous messages can be avoided, thereby improving the parsing efficiency of the system; by determining whether the message complies with the frame specification of the manufacturer's communication protocol, it is ensured that subsequent data parsing is strictly carried out in accordance with the manufacturer's protocol, thereby ensuring the reliability and standardization of communication; by extracting valid data fields based on the parsing method of the manufacturer's protocol, it is possible to accurately locate key information in the message and ensure the integrity and accuracy of the data content; by extracting valid data fields, redundant information in the message is filtered out, the system processing burden is reduced, and the data parsing speed is improved; by generating display data based on the valid data fields, the technical information in the message can be converted into user-readable status information, thereby improving the user's operating experience; by loading the display data into the instrument display module, real-time visualization of the vehicle status can be achieved, thereby ensuring that users can quickly obtain key information and improving the interactivity and user-friendliness of the system.

[0017] In one example, the present application may be further configured as follows: the obtaining of the user's operation data, converting the operation data into a second CAN message according to the CAN message sending method and sending the second CAN message to the controller includes: Generate an operation data field according to the operation data, wherein the operation data field includes target control parameters and operation type information; Calling the CAN message sending method to encapsulate the operation data word into the second CAN message; Check whether the format of the second CAN message complies with the message sending rules of the manufacturer's communication protocol type; If the format of the second CAN message complies with the message sending rule, the second CAN message is sent to the controller.

[0018] By adopting the above technical solution, by converting the operation data into a standardized operation data field, the operation information input by the user can be structured and processed to ensure the accuracy of subsequent packaging and sending; by including the target control parameters and operation type information, the specific content and execution method of the control operation are clarified, and the readability and logic of data transmission are improved; by calling the CAN message sending method, the operation data field is encapsulated into a second CAN message that complies with the manufacturer's communication protocol, ensuring that the data encapsulation process meets the frame format and content requirements of the protocol; by converting the operation data field into a CAN message, the standardized transmission of user control instructions can be achieved, and the compatibility and reliability of system communication can be improved; by checking the format of the second CAN message, it can be verified whether the generated message complies with the specifications of the manufacturer's protocol, avoiding communication failure due to message format errors; through format checking, abnormal messages can be discovered and filtered in advance, improving the success rate of data transmission and the stability of system operation; by sending the second CAN message that complies with the rules to the controller, it is ensured that the controller can correctly receive and execute the user's operation instructions, improving the execution efficiency of the user's operation instructions and the accuracy of the controller's response, and realizing reliable device control and data interaction.

[0019] The second object of the invention is achieved by the following technical solutions: An automatic switching system adapted to multiple communication protocols, the automatic switching system adapted to multiple communication protocols comprising: The wake-up module is used to execute the controller wake-up operation after the instrument is powered on and monitor the data frames on the CAN bus; An extraction module, used for extracting the CAN_ID in the data frame, matching the CAN_ID with a preset manufacturer handshake command list, and determining whether a handshake command exists; A type determination module is used to determine the corresponding manufacturer communication protocol type if there is a matching handshake instruction; A determination method module, used to determine the corresponding CAN message parsing method and CAN message sending method according to the manufacturer's communication protocol type; A display module, used for receiving a first CAN message, parsing the first CAN message using the CAN message parsing method, and generating display data; The conversion module is used to obtain the user's operation data, convert the operation data into a second CAN message according to the CAN message sending method, and send the second CAN message to the controller.

[0020] By adopting the above technical solution, the controller wake-up operation is executed immediately after the instrument is powered on to ensure that the controller enters the communication preparation state, establish a foundation for subsequent communication, and capture the handshake information sent by the controller in real time by monitoring the data frames on the CAN bus, and quickly enter the protocol identification process; by extracting the CAN_ID in the data frame, the key fields related to the handshake are screened out, and the interference of irrelevant data is effectively reduced. By matching with the preset manufacturer's handshake command list, it is quickly determined whether there is a handshake command, thereby improving the protocol identification efficiency; by matching the handshake instructions, the manufacturer to which the controller belongs and its communication protocol type are automatically identified, and the automatic adaptation of the protocol is realized, avoiding the tedious operation of the user manually configuring the protocol type, and improving the intelligence of the system and the user Experience; by loading the parsing method and sending method according to the manufacturer's communication protocol type, it ensures that the communication data of the controller can be processed correctly, improves the scalability and compatibility of the system, and supports dynamic adaptation of multiple manufacturers and multiple protocols; by receiving the first CAN message and using the corresponding parsing method, it accurately extracts the valid data in the message to avoid parsing failure caused by protocol mismatch, and by generating display data, it presents the vehicle status information to the user in a timely manner, thereby improving the user experience; by obtaining the user's operation data and converting it into the second CAN message, it ensures that the user's control instructions meet the communication protocol requirements of the controller, and by sending the second CAN message to the controller, it realizes effective control of the controller and ensures the real-time and reliability of user operations.

[0021] In summary, this application includes the following beneficial technical effects: 1. By executing the controller wake-up operation immediately after the instrument is powered on, ensure that the controller enters the communication preparation state, establish a foundation for subsequent communication, and capture the handshake information sent by the controller in real time by monitoring the data frames on the CAN bus, and quickly enter the protocol identification process; by extracting the CAN_ID in the data frame, filter out the key fields related to the handshake, effectively reduce the interference of irrelevant data, and quickly determine whether there is a handshake command by matching with the preset manufacturer's handshake command list, thereby improving the efficiency of protocol identification; by matching the handshake instructions, automatically identify the manufacturer to which the controller belongs and its communication protocol type, and realize automatic adaptation of the protocol, avoiding the tedious operation of users manually configuring the protocol type, and improving the intelligence of the system and user experience; by loading the parsing method and sending method according to the manufacturer's communication protocol type, ensure that the communication data of the controller can be correctly processed, improve the scalability and compatibility of the system, and support dynamic adaptation of multiple manufacturers and multiple protocols; 2. By receiving the first CAN message and using the corresponding parsing method, the valid data in the message can be accurately extracted to avoid parsing failure caused by protocol mismatch. By generating display data, the vehicle status information can be presented to the user in a timely manner to improve the user experience. By obtaining the user's operation data and converting it into the second CAN message, it is ensured that the user's control instructions comply with the communication protocol requirements of the controller. By sending the second CAN message to the controller, effective control of the controller is achieved to ensure the real-time and reliability of user operations. BRIEF DESCRIPTION OF THE DRAWINGS

[0022] Figure 1 This is a flow chart of an automatic switching method for adapting multiple communication protocols in one embodiment of the present application; Figure 2 This is a flowchart for implementing step S10 in an automatic switching method for adapting multiple communication protocols in one embodiment of the present application; Figure 3 This is a flowchart for implementing step S20 in an automatic switching method for adapting multiple communication protocols in one embodiment of the present application; Figure 4 It is a flowchart for implementing step S22 in an automatic switching method for adapting multiple communication protocols in one embodiment of the present application; Figure 5 It is a flowchart for implementing step S40 in an automatic switching method for adapting multiple communication protocols in one embodiment of the present application; Figure 6 This is a flowchart for implementing step S50 in an automatic switching method for adapting multiple communication protocols in one embodiment of the present application; Figure 7 This is a flowchart for implementing step S60 in an automatic switching method for adapting multiple communication protocols in one embodiment of the present application; Figure 8 It is a principle block diagram of an automatic switching system adapted to multiple communication protocols in one embodiment of the present application; DETAILED DESCRIPTION The present application is further described in detail below in conjunction with the accompanying drawings.

[0023] In one embodiment, if Figure 1 As shown, the present application discloses an automatic switching method for adapting multiple communication protocols, which specifically includes the following steps: S10: After the instrument is powered on, the controller wakes up and monitors the data frames on the CAN bus.

[0024] Specifically, when the instrument is powered on, the communication module inside the instrument will actively send a set of wake-up signals in a specific format to the CAN bus. These signals are sent continuously at a preset fixed time interval, for example, once every 10 milliseconds, to ensure that the controller can receive the wake-up signal and switch from sleep mode to working state. At the same time, the instrument switches to monitoring mode after completing the sending of the wake-up signal, and continuously monitors all communication data frames on the CAN bus through its built-in CAN bus transceiver module. The capture of data frames is achieved through a filtering mechanism. For example, all received signals are first passed through a hardware filter to remove electrical noise and then passed to the processing unit, and the processing unit caches the data frames in RAM memory for subsequent processing.

[0025] S20: Extract the CAN_ID in the data frame, match the CAN_ID with a preset manufacturer handshake command list, and determine whether there is a handshake command.

[0026] Specifically, after the data frame is captured, the CAN_ID is extracted by parsing the frame header of the data frame. The extraction process can be implemented through bit operations. For example, according to the frame format of the CAN bus protocol, the first 11 bits or the first 29 bits of the data frame (the two are defined according to the standard frame or the extended frame, respectively) are stored in the variable as the CAN_ID, and then the extracted CAN_ID is compared with the manufacturer's handshake command list stored in the instrument one by one. The comparison is performed in a byte-by-byte matching manner, and the CAN_ID is compared with each record in the list in turn. The logical operator is used to determine whether they are the same. If a matching record is found, the comparison is stopped immediately and the matching result is recorded, and it is determined that there is a handshake command; if no matching record is found after the comparison, it is considered that the data frame does not contain a valid handshake command.

[0027] S30: If there is a matching handshake instruction, determine the corresponding manufacturer communication protocol type.

[0028] Specifically, after successfully matching the handshake instruction, the communication protocol type of the current controller is determined based on the correspondence between the instruction and the record in the manufacturer's protocol table. This is achieved through a table lookup method. For example, the matched CAN_ID is used as a key value to query the corresponding protocol identifier in the protocol type table. The table is usually stored in the non-volatile memory of the instrument in the form of a hash table for quick access. The protocol identifier can be an integer value or a string used to identify the communication protocol type supported by the current controller. After the query is completed, the result is saved in a global variable for subsequent calls.

[0029] S40: Determine the corresponding CAN message parsing method and CAN message sending method according to the manufacturer's communication protocol type.

[0030] Specifically, after obtaining the manufacturer's communication protocol type, communication is achieved by loading the message parsing rules and sending rules corresponding to the protocol type. The message parsing rules define how to extract valid data fields from the received CAN messages, such as extracting status parameters by configuring specific offsets and byte lengths; the sending rules define how to encapsulate user operation instructions into CAN messages that conform to the protocol format, such as specifying the data field filling order in the message, the calculation method of the check field, etc. These rules are stored in the instrument's built-in protocol library. After finding the corresponding rules using the protocol type as an index, the memory address of the rules is passed to the message processing module for subsequent execution.

[0031] S50: receiving a first CAN message, parsing the first CAN message using a CAN message parsing method, and generating display data.

[0032] Specifically, after monitoring the first CAN message that meets the frame format requirements, the data field in the message is first decoded through a parsing method, such as extracting parameter values ​​one by one according to the offset and field length defined by the protocol, and converting them into a user-understandable form according to the type of the field, such as multiplying the original voltage value by a proportional coefficient to convert it into a battery power percentage, or decoding the binary value of the speed field into an actual speed value. After the parsing is completed, the field values ​​are assembled into a set of display data, and visual content is generated by formatting a string, such as combining information such as power and speed into a format such as "power: 80%, speed: 25km / h" for loading into the display module.

[0033] S60: Acquire the user's operation data, convert the operation data into a second CAN message according to the CAN message sending method, and send the second CAN message to the controller.

[0034] Specifically, when receiving the user's operation input, such as pressing the light switch button or selecting the riding mode, the operation data is first recorded in the operation buffer in a standardized form, for example, the "turn on the lights" instruction is recorded as "operation type = light control, target state = on", and then according to the sending rules of the current protocol type, the instruction data in the operation buffer is encapsulated into a second CAN message according to the message format requirements, for example, the target state value is written into the specified data segment by byte filling, and the check field is calculated and attached at the same time, and finally the encapsulated message is sent to the controller through the CAN bus sending interface. After receiving the message, the controller parses the operation instruction and performs corresponding actions, such as turning on the vehicle lights or adjusting the power output mode.

[0035] By adopting the above technical solution, the controller wake-up operation is executed immediately after the instrument is powered on to ensure that the controller enters the communication preparation state, establish a foundation for subsequent communication, and capture the handshake information sent by the controller in real time by monitoring the data frames on the CAN bus, and quickly enter the protocol identification process; by extracting the CAN_ID in the data frame, the key fields related to the handshake are screened out, and the interference of irrelevant data is effectively reduced. By matching with the preset manufacturer's handshake command list, it is quickly determined whether there is a handshake command, thereby improving the protocol identification efficiency; by matching the handshake instructions, the manufacturer to which the controller belongs and its communication protocol type are automatically identified, and the automatic adaptation of the protocol is realized, avoiding the tedious operation of the user manually configuring the protocol type, and improving the intelligence of the system and the user Experience; by loading the parsing method and sending method according to the manufacturer's communication protocol type, it ensures that the communication data of the controller can be processed correctly, improves the scalability and compatibility of the system, and supports dynamic adaptation of multiple manufacturers and multiple protocols; by receiving the first CAN message and using the corresponding parsing method, it accurately extracts the valid data in the message to avoid parsing failure caused by protocol mismatch, and by generating display data, it presents the vehicle status information to the user in a timely manner, thereby improving the user experience; by obtaining the user's operation data and converting it into the second CAN message, it ensures that the user's control instructions meet the communication protocol requirements of the controller, and by sending the second CAN message to the controller, it realizes effective control of the controller and ensures the real-time and reliability of user operations.

[0036] In one embodiment, if Figure 2 As shown, in step S10, that is, after the instrument is powered on, the controller wake-up operation is executed, which specifically includes: S11: After the meter is powered on, a set of preset wake-up data frames are sent.

[0037] Specifically, after the instrument completes power-on initialization, it immediately starts sending wake-up data frames through the built-in CAN communication module. The content of the wake-up data frame consists of a pre-defined fixed format. For example, the CAN_ID in the frame header can be set to a specific wake-up identifier (such as 0x7FF), and the data field is filled with a fixed value or a specific sequence to identify the wake-up request. The sending of the wake-up data frame is achieved through a timer trigger mechanism. A frame is sent at a fixed time interval (for example, 10 milliseconds) to ensure that the wake-up signal can be received multiple times within the controller's listening window, while avoiding wake-up failures due to network fluctuations or data loss. The sending process includes formatting the data frame and passing it to the CAN bus sending interface, which is then sent to the controller by the hardware module through the bus protocol. After receiving the wake-up frame, the controller stores it in the receiving buffer for subsequent parsing. S12: After receiving the wake-up data frame, the controller sends a handshake response signal to the instrument to complete the controller wake-up operation.

[0038] Specifically, the controller monitors all data frames on the bus through its CAN bus receiving module. After receiving the wake-up data frame, it compares the CAN_ID in the frame header with the preset wake-up identifier. When the comparison is successful, the wake-up data frame is determined to be valid. At the same time, the communication module of the controller will enter the working mode and prepare to establish a communication link with the instrument. Then the controller generates a set of handshake response signals and sends them through the CAN bus. The format of the handshake response signal is defined by the protocol. For example, the frame header CAN_ID is set to a specific response identifier (such as 0x100), and the data field can contain device status information or version information, etc. During the sending process, the frame content is filled in by the frame generation module inside the controller and passed to the CAN sending interface to output to the bus. After the instrument receives the handshake response signal, it confirms the completion of the wake-up operation through frame header matching and content verification, thereby starting the subsequent communication process.

[0039] In one embodiment, if Figure 3 As shown, in step S20, the CAN_ID in the data frame is extracted, and the CAN_ID is matched with the preset manufacturer handshake command list to determine whether there is a handshake command, which specifically includes: S21: Extract CAN_ID from the data frame and check whether CAN_ID complies with the predefined frame format rule.

[0040] Specifically, when a data frame on the CAN bus is received, the CAN_ID value is first extracted by parsing the frame header of the data frame. The extraction process is processed separately according to the different formats of the standard CAN frame and the extended CAN frame. For example, for a standard frame, the CAN_ID usually occupies 11 bits of the frame header, and for an extended frame, the CAN_ID is 29 bits. During parsing, the corresponding CAN_ID field is gradually extracted through bit shifting and bitwise AND operations. For example, the frame header data is stored in the memory in binary form. By right shifting the start bit of the frame header and bitwise ANDing the result with a mask (such as 0x7FF or 0x1FFFFFFF), the CAN_ID of the corresponding length can be extracted. After the extraction is completed, the CAN_ID is further verified according to the predefined frame format rules. For example, the frame format rules may include a legitimacy check of the CAN_ID value range (such as a manufacturer identification limited to a certain range), a frame type check (such as whether it is a standard frame or an extended frame), and whether the CAN_ID is associated with a specific field value. A series of logical judgments and conditional operations are used to finally confirm whether the CAN_ID complies with the frame format rules.

[0041] S22: If the CAN_ID complies with the predefined frame format rule, the CAN_ID is compared with the identifiers in the preset manufacturer handshake command list one by one to generate a comparison result.

[0042] Specifically, after confirming that the extracted CAN_ID complies with the frame format rules, it is compared one by one with each identifier in the preset manufacturer handshake command list to generate a comparison result. The comparison process adopts a one-by-one traversal method. For example, the handshake command list is stored in an array in the memory, and each identifier is a unique numeric value or string. During the comparison, the array is traversed and the CAN_ID is compared with the current array item one by one. For example, a direct equality judgment method (such as if_CAN_ID==command list item) is adopted. For large command lists, the comparison process can be accelerated by a hash table or binary search. The comparison result is updated to a Boolean value or integer identifier after each match is completed. For example, the result is updated to 1 when the match is successful, and the next record is compared if there is no match until the entire command list is matched.

[0043] S23: If the comparison result is that the CAN_ID successfully matches the identifier in the preset manufacturer handshake command list, the corresponding matching manufacturer identifier is recorded.

[0044] Specifically, when the comparison result shows that CAN_ID successfully matches an identifier in the manufacturer's handshake command list, the corresponding manufacturer identifier is obtained by finding the index position of the matching record in the list. The manufacturer identifier is usually stored as a field associated with the handshake command list item. For example, the handshake command identifier and the corresponding manufacturer ID are stored in the list structure at the same time. When the match is successful, the manufacturer ID value can be directly read through the index position of the matching command identifier and recorded in the system's temporary variable for subsequent operations. For example, the manufacturer identifier is a string "Vendor_A", which can be stored in the memory buffer when recording, and a debug log is printed to record detailed information on the successful match to ensure data traceability and accuracy.

[0045] In one embodiment, if Figure 4 As shown, in step S22, the CAN_ID is compared with the identifiers in the preset manufacturer handshake command list one by one to generate a comparison result, which specifically includes: S221: Assign matching priorities to the preset manufacturer handshake command list according to the protocol type.

[0046] Specifically, by analyzing the protocol types in the preset vendor handshake command list, an association relationship is established between each handshake command and its corresponding protocol type. The priority allocation is defined based on the commonness and criticality of the protocol type and the real-time requirements of the device. For example, commonly used protocols or protocols involving critical operations are assigned higher priority values. When allocating priorities, the protocol types can be sorted according to the frequency of use and assigned priority identifiers. For frequently used protocols, lower priority values ​​(such as 1) are assigned, and for less frequently used protocols, higher priority values ​​(such as 2 or 3) are assigned. After the priority allocation is completed, the allocation result is stored as a ternary data structure including the protocol type, handshake command identifier and priority. For example, each record in the list includes a handshake command identifier (such as 0x01A), a corresponding protocol type (such as Vendor_A_Protocol) and a priority (such as 1). This structure is stored in the memory for subsequent comparison.

[0047] S222: Based on the matching priority, the CAN_ID is compared with the identifiers in the preset manufacturer handshake command list one by one to generate a comparison result.

[0048] Specifically, after receiving the CAN_ID, by reading the assigned priority in the handshake command list, the list is sorted from low to high according to the priority. For example, protocol records with higher priorities (such as commands with a priority of 1) are arranged in front of the list, and the received CAN_ID is compared with each handshake command identifier one by one by traversing the sorted list. The comparison process can be completed by logical judgment, for example, the received CAN_ID value is compared with the handshake command identifier value byte by byte, and when the match is successful, the comparison result is recorded as successful and the subsequent comparison operation is stopped immediately. The comparison result can be represented by a Boolean value or a status code, for example, a successful match is recorded as status 1 or True, and a failed match is recorded as status 0 or False. By recording the index position or protocol identifier of the comparison, the specific matching protocol type can be further tracked. If the entire list is traversed and still no match is successful, a default comparison result (such as an unmatched status code) is generated. The comparison process is combined with priority sorting to enable common protocols to complete the match first, thereby improving overall efficiency and reducing unnecessary comparison operations.

[0049] In one embodiment, if Figure 5 As shown, in step S40, the corresponding CAN message parsing method and CAN message sending method are determined according to the manufacturer's communication protocol type, specifically including: S41: According to the manufacturer's communication protocol type, the CAN message parsing script and CAN message sending rules corresponding to the manufacturer's communication protocol type are queried from the protocol module built into the instrument to obtain the query result.

[0050] Specifically, after determining the manufacturer's communication protocol type, the corresponding parsing script and sending rules are searched from the built-in protocol module of the instrument based on the communication protocol type as the query condition. The protocol module usually stores different protocol types and their associated parsing and sending methods in the form of a database or hash table. When querying, the communication protocol type is input as the key value, and the associated data entries are quickly retrieved using the hash search algorithm. For example, when the protocol type is "Vendor_A_Protocol", the query condition is directly matched with the key in the hash table. If the match is successful, the parsing script path (such as "parse_script_vendor_A.py") and sending rule description file (such as "send_rules_vendor_A.json") associated with the protocol type are returned. These files are usually stored in non-volatile memory. The storage location of these resources can be determined through the query results for subsequent loading and execution.

[0051] S42: If the query result shows that there is a match, the CAN message parsing method and the CAN message sending method are determined according to the corresponding CAN message parsing script and CAN message sending rule.

[0052] Specifically, when parsing scripts and sending rules matching the current communication protocol type are found in the query results, the specific CAN message parsing method and sending method are determined by loading these resources and parsing their contents. The parsing script usually exists in the form of executable code, and the extraction of valid fields in the message is completed by calling the parsing function of the script, such as mapping the field offset, data length and field type in the script to specific parsing operations. When the parsing method is determined, these rules are dynamically loaded into the runtime environment for data processing; the sending rules define specific message assembly rules in the form of configuration files, including the filling order of fields, byte alignment, checksum calculation method, etc. After reading the configuration file and parsing its parameters one by one, these rules are stored as a data structure for generating a sending message. After completing these operations, the parsing method and sending method can be loaded into the memory for direct call in subsequent steps.

[0053] S43: If the query result is that there is no match, the parsing method and the sending method corresponding to the manufacturer's communication protocol type are dynamically downloaded through the network connection, and the dynamically downloaded parsing method and the sending method are loaded into the protocol module.

[0054] Specifically, when the query result fails to match the current communication protocol type, a network connection is initiated to dynamically download the parsing method and sending method associated with the protocol type from the remote server. During the download process, a request containing the communication protocol type is sent to the server through a network protocol (such as HTTPS). The server returns the corresponding parsing script and sending rule file based on the request. For example, the parsing script is transmitted in the form of a binary data stream and is stored in a temporary cache directory after the download is complete. The file integrity is verified by calculating a hash value, for example, by executing the SHA256 algorithm on the file content and comparing the result with the verification value provided by the server. After confirming that the file has not been tampered with, it is loaded into the operating environment and a preliminary test is performed to ensure compatibility. After verification is completed, the dynamically downloaded script and rule files are stored in the permanent storage of the protocol module to update the protocol library for subsequent direct calls without repeated downloads.

[0055] In one embodiment, if Figure 6 As shown, in step S50, that is, receiving a first CAN message, parsing the first CAN message using a CAN message parsing method to generate display data, specifically includes: S51: Check the frame header information of the first CAN message, where the frame header information includes CAN_ID, data length code and frame format, and determine whether the first CAN message complies with the frame specification of the manufacturer's communication protocol type.

[0056] Specifically, after receiving the first CAN message, the CAN_ID, data length code and frame format are extracted by parsing the frame header information. The extraction process adopts different methods according to the different frame structures of the standard CAN message or the extended CAN message. For example, for the standard message, the first 11 bits of the frame header are extracted as the CAN_ID through the shift and mask operation, and the data length code (DLC) field is read to extract the number of bytes of the data field in the message, and then the frame control bit is parsed to determine whether the message is a standard frame or an extended frame; after the extraction is completed, each item is compared according to the frame specification defined in the manufacturer's communication protocol type, for example, it is determined whether the CAN_ID falls within the range allowed by the protocol, whether the data length code matches the value range required by the protocol (such as limited to 8 bytes or less), and whether the frame format is consistent with the frame type supported by the protocol. The above verification is completed by logical judgment and conditional matching methods. If each content of the frame header information meets the requirements of the frame specification, it is confirmed that the CAN message complies with the frame specification of the manufacturer's protocol type. If any item is not met, it is determined to be a non-compliant message and discarded.

[0057] S52: If the first CAN message complies with the frame specification of the manufacturer's communication protocol type, a CAN message parsing method is used to extract a valid data field in the first CAN message.

[0058] Specifically, after confirming that the first CAN message complies with the frame specification of the protocol type, the valid data field is extracted according to the parsing rules defined in the protocol. For example, the protocol may define a specific data offset and field length. By aligning the byte index in the data frame with the offset in the protocol, data of the specified length is extracted as the valid field. This process can be implemented through memory pointer operations, such as moving the pointer from the starting address of the data frame plus the offset defined in the protocol and reading data of the corresponding length, and then converting the extracted field data according to the unit and precision defined in the protocol. For example, if the field is a binary-encoded speed value, it can be divided by a predetermined scale factor (such as 10) to convert it into an actual speed value (unit: km / h), and finally a parsed valid data field is generated for subsequent processing.

[0059] S53: Generate display data according to the valid data field and predefined display rules, and load the display data into the display module of the instrument.

[0060] Specifically, after extracting and parsing the valid data fields, the parsed data is converted into user-readable display information according to predefined display rules. For example, the display rules may include concatenating multiple fields into a string and appending a unit identifier. The complete display content is generated by formatting the field values ​​and filling them into a predefined template. For example, the parsed data includes a speed field (25km / h) and a battery field (80%). The display information generated by formatting is "Speed: 25km / h Battery: 80%". The display data is loaded into the display area of ​​the instrument by calling the interface of the display module. The display module may include a liquid crystal display or an LED screen. During loading, the generated display data is converted into a data stream in a display format and written into a display buffer. The content is presented to the user through a refresh operation, thereby realizing real-time display of vehicle status information.

[0061] In one embodiment, if Figure 7 As shown, in step S60, the user's operation data is obtained, and the operation data is converted into a second CAN message according to the CAN message sending method and sent to the controller, which specifically includes: S61: Generate an operation data field according to the operation data, where the operation data field includes target control parameters and operation type information.

[0062] Specifically, when the user performs an operation, such as pressing the vehicle's light switch button or selecting a different riding mode, operation data is generated by reading the corresponding input signal. These input signals can be received and processed through the hardware interface. For example, the input signal of the light switch can be a level signal, and the selection of the riding mode can be a coded value. After processing the input signal, it is converted into operation data in a logical sense, such as "light switch = on" or "riding mode = sports mode". Subsequently, an operation data field is generated based on these operation data. The operation data field contains target control parameters and operation type information. For example, for "light switch = on", the target control parameter can be defined as the target state of the light, and the operation type information can be defined as the control instruction type of the light. These fields are generated through a mapping relationship. For example, the target state code corresponding to the switch is recorded in the configuration table as "0x01" and the control type code is "0x10". The final operation data field "target control parameter = 0x01, operation type information = 0x10" is generated by searching the table. These fields are stored in the memory in the form of a byte sequence for subsequent packaging.

[0063] S62: Call the CAN message sending method to encapsulate the operation data word into a second CAN message.

[0064] Specifically, after the operation data field is generated, these fields are encapsulated into the second CAN message by calling the predefined CAN message sending method. The message encapsulation process is performed in accordance with the provisions of the manufacturer's protocol. For example, the operation data field needs to be written to a specific offset address of the message data part. First, a blank CAN message buffer is created in the memory, and then the target control parameters in the operation data field are written into the 1st-2nd bytes of the message according to the protocol requirements, and the operation type information is written into the 3rd-4th bytes. The remaining bytes are filled with reserved values ​​or check fields specified in the protocol. Then, the checksum of the message is calculated according to the protocol requirements. For example, all data bytes in the message are bitwise added and the low byte is taken as the checksum. In this way, a complete CAN message that meets the manufacturer's protocol requirements is generated and saved in the buffer. Finally, the sending interface is called to load the contents of the buffer into the CAN sending module to complete the encapsulation.

[0065] S63: Check whether the format of the second CAN message complies with the message sending rules of the manufacturer's communication protocol type.

[0066] Specifically, after completing the CAN message encapsulation, further check whether the generated second CAN message complies with the sending rules specified in the manufacturer's protocol, such as checking whether the frame header information of the message is correct, the frame header information includes CAN_ID, data length code and frame format, whether the value of CAN_ID is within the range specified by the protocol (such as 0x100-0x1FF), whether the data length code is consistent with the length of the operation data field (such as DLC=8), and whether the frame format is consistent with the protocol requirements (such as extended frame or standard frame). These checks are completed one by one through logical judgment, such as reading the value of CAN_ID in the encapsulated CAN message buffer, completing the CAN_ID check by comparing whether the value falls within the range specified by the protocol, and completing the data length code check by comparing whether the data length code field is equal to the actual number of bytes in the operation data field. If the results of the above checks all meet the protocol requirements, the message format is determined to be compliant.

[0067] S64: If the format of the second CAN message complies with the message sending rule, the second CAN message is sent to the controller.

[0068] Specifically, after confirming that the second CAN message complies with the sending rules of the manufacturer's protocol, the message is sent to the controller by calling the hardware interface of the CAN sending module, for example, the data in the message buffer is written into the CAN bus sending register and the sending operation is triggered. During the sending process, the hardware module will perform underlying serialization and encoding on the data, for example, converting the data bytes into CAN bus physical layer signals and sending them to the controller through the bus. The controller listens to the message through its receiving module and decodes it, completes the reception and parsing of the message, and finally identifies and processes the operation data field in the message. For example, when the controller receives the target control parameter "0x01", it parses it as "light on" and performs corresponding actions, thereby completing the transmission and execution of the operation instruction.

[0069] It should be understood that the size of the serial numbers of the steps in the above embodiments does not mean the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of the present application.

[0070] In one embodiment, an automatic switching system for adapting multiple communication protocols is provided, and the automatic switching system for adapting multiple communication protocols corresponds one-to-one with the automatic switching method for adapting multiple communication protocols in the above embodiment. Figure 8 As shown, the automatic switching system adapted to multiple communication protocols includes a wake-up module, an extraction module, a type determination module, a determination method module and a display module. The detailed description of each functional module is as follows: The wake-up module is used to execute the controller wake-up operation after the instrument is powered on and monitor the data frames on the CAN bus; An extraction module is used to extract the CAN_ID in the data frame, match the CAN_ID with the preset manufacturer handshake command list, and determine whether there is a handshake command; A type determination module is used to determine the corresponding manufacturer communication protocol type if there is a matching handshake instruction; A determination method module is used to determine the corresponding CAN message parsing method and CAN message sending method according to the manufacturer's communication protocol type; A display module, used for receiving a first CAN message, parsing the first CAN message using a CAN message parsing method, and generating display data; The conversion module is used to obtain the user's operation data, convert the operation data into a second CAN message according to the CAN message sending method, and send the second CAN message to the controller.

[0071] Optionally, the wake-up module includes: The data frame sending submodule is used to send a set of preset wake-up data frames after the instrument is powered on; The response submodule is used for the controller to send a handshake response signal to the instrument after receiving the wake-up data frame to complete the wake-up operation of the controller.

[0072] Optionally, the extraction module includes: The ID extraction submodule is used to extract the CAN_ID from the data frame and check whether the CAN_ID conforms to the predefined frame format rules; The comparison submodule is used to compare the CAN_ID with the identifiers in the preset manufacturer handshake command list one by one if the CAN_ID meets the predefined frame format rules, and generate a comparison result; The recording submodule is used to record the corresponding matching manufacturer identifier if the comparison result is that the CAN_ID successfully matches the identifier in the preset manufacturer handshake command list.

[0073] Optionally, the comparison submodule includes: A priority allocation unit is used to allocate matching priorities to the preset manufacturer handshake command list according to the protocol type; A comparison unit is generated, which is used to compare the CAN_ID with the identifiers in the preset manufacturer handshake command list one by one based on the matching priority, and generate a comparison result.

[0074] Optionally, the determination method module includes: The query submodule is used to query the CAN message parsing script and CAN message sending rules corresponding to the manufacturer's communication protocol type from the built-in protocol module of the instrument according to the manufacturer's communication protocol type, and obtain the query result; A rule determination submodule is used to determine a CAN message parsing method and a CAN message sending method according to corresponding CAN message parsing scripts and CAN message sending rules if the query result shows that there is a match; The download submodule is used to dynamically download the parsing method and sending method corresponding to the manufacturer's communication protocol type through a network connection if the query result is that there is no match, and load the dynamically downloaded parsing method and sending method into the protocol module.

[0075] Optionally, the display module includes: A check specification submodule is used to check the frame header information of the first CAN message, the frame header information includes CAN_ID, data length code and frame format, and determine whether the first CAN message complies with the frame specification of the manufacturer's communication protocol type; The valid extraction submodule is used to extract the valid data field in the first CAN message by using the CAN message parsing method if the first CAN message meets the frame specification of the manufacturer's communication protocol type; The display submodule is used to generate display data according to the valid data fields and predefined display rules, and load the display data into the display module of the instrument.

[0076] Optionally, the conversion module includes: Generate an operation submodule, used to generate an operation data field according to the operation data, the operation data field including target control parameters and operation type information; The encapsulation submodule is used to call the CAN message sending method and encapsulate the operation data word into a second CAN message; A check sending submodule is used to check whether the format of the second CAN message complies with the message sending rules of the manufacturer's communication protocol type; The transmission submodule is used to send the second CAN message to the controller if the format of the second CAN message complies with the message sending rule.

[0077] For the specific definition of an automatic switching system that adapts to multiple communication protocols, please refer to the definition of an automatic switching method that adapts to multiple communication protocols above, which will not be repeated here. Each module in the above-mentioned automatic switching system that adapts to multiple communication protocols can be implemented in whole or in part through software, hardware and a combination thereof. The above-mentioned modules can be embedded in or independent of the processor in the computer device in the form of hardware, or can be stored in the memory of the computer device in the form of software, so that the processor can call and execute the operations corresponding to the above modules.

[0078] Those skilled in the art will clearly understand that for the sake of convenience and brevity of description, only the division of the above-mentioned functional units and modules is used as an example. In actual applications, the above-mentioned functions can be distributed and completed by different functional units and modules as needed, that is, the internal structure of the system can be divided into different functional units or modules to complete all or part of the functions described above.

[0079] The embodiments described above are only used to illustrate the technical solutions of the present application, rather than to limit them. Although the present application has been described in detail with reference to the aforementioned embodiments, a person skilled in the art should understand that the technical solutions described in the aforementioned embodiments may still be modified, or some of the technical features may be replaced by equivalents. Such modifications or replacements do not deviate the essence of the corresponding technical solutions from the spirit and scope of the technical solutions of the embodiments of the present application, and should all be included in the protection scope of the present application.

Claims

1. An automatic switching method for adapting multiple communication protocols, characterized in that: The automatic switching method adapted to multiple communication protocols comprises: After the instrument is powered on, the controller wakes up and monitors the data frames on the CAN bus. Extracting the CAN_ID in the data frame, matching the CAN_ID with a preset manufacturer handshake command list, and determining whether a handshake command exists; If there is a matching handshake instruction, the corresponding manufacturer communication protocol type is determined; According to the manufacturer's communication protocol type, determine the corresponding CAN message parsing method and CAN message sending method; Receiving a first CAN message, parsing the first CAN message using the CAN message parsing method, and generating display data; The user's operation data is obtained, and the operation data is converted into a second CAN message according to the CAN message sending method and sent to the controller.

2. The automatic switching method for adapting multiple communication protocols according to claim 1, characterized in that: After the instrument is powered on, executing the controller wake-up operation includes: After the meter is powered on, sending a set of preset wake-up data frames; After receiving the wake-up data frame, the controller sends a handshake response signal to the instrument to complete the wake-up operation of the controller.

3. The automatic switching method for adapting multiple communication protocols according to claim 1, characterized in that: The extracting the CAN_ID in the data frame, matching the CAN_ID with a preset manufacturer handshake command list, and determining whether a handshake command exists comprises: Extracting the CAN_ID from the data frame, and checking whether the CAN_ID complies with a predefined frame format rule; If the CAN_ID conforms to the predefined frame format rule, the CAN_ID is compared with the identifiers in the preset manufacturer handshake command list one by one to generate a comparison result; If the comparison result is that the CAN_ID successfully matches the identifier in the preset manufacturer handshake command list, the corresponding matching manufacturer identifier is recorded.

4. The automatic switching method for adapting multiple communication protocols according to claim 3 is characterized in that: The step of comparing the CAN_ID with the identifiers in the preset manufacturer handshake command list one by one to generate a comparison result includes: Assigning matching priorities to the preset manufacturer handshake command list according to protocol types; Based on the matching priority, the CAN_ID is compared with the identifiers in the preset manufacturer handshake command list one by one to generate the comparison result.

5. The automatic switching method for adapting multiple communication protocols according to claim 1, characterized in that: Determining the corresponding CAN message parsing method and CAN message sending method according to the manufacturer communication protocol type includes: According to the manufacturer's communication protocol type, query the CAN message parsing script and CAN message sending rules corresponding to the manufacturer's communication protocol type from the protocol module built into the instrument to obtain the query result; If the query result is that there is a match, determining the CAN message parsing method and the CAN message sending method according to the corresponding CAN message parsing script and CAN message sending rule; If the query result is that there is no match, the parsing method and sending method corresponding to the manufacturer's communication protocol type are dynamically downloaded through a network connection, and the dynamically downloaded parsing method and sending method are loaded into the protocol module.

6. The automatic switching method for adapting multiple communication protocols according to claim 1, characterized in that: The receiving a first CAN message, parsing the first CAN message using the CAN message parsing method, and generating display data comprises: Checking the frame header information of the first CAN message, the frame header information including CAN_ID, data length code and frame format, and determining whether the first CAN message complies with the frame specification of the manufacturer communication protocol type; If the first CAN message complies with the frame specification of the manufacturer's communication protocol type, extracting the valid data field in the first CAN message by using the CAN message parsing method; The display data is generated according to the valid data field and a predefined display rule, and the display data is loaded into a display module of the instrument.

7. The automatic switching method for adapting multiple communication protocols according to claim 1, characterized in that: The acquiring of the user's operation data, converting the operation data into a second CAN message according to the CAN message sending method and sending the second CAN message to the controller comprises: Generate an operation data field according to the operation data, wherein the operation data field includes target control parameters and operation type information; Calling the CAN message sending method to encapsulate the operation data word into the second CAN message; Check whether the format of the second CAN message complies with the message sending rules of the manufacturer's communication protocol type; If the format of the second CAN message complies with the message sending rule, the second CAN message is sent to the controller.

8. An automatic switching system adapted to multiple communication protocols, characterized in that: The automatic switching system adapted to multiple communication protocols comprises: The wake-up module is used to execute the controller wake-up operation after the instrument is powered on and monitor the data frames on the CAN bus; An extraction module, used for extracting the CAN_ID in the data frame, matching the CAN_ID with a preset manufacturer handshake command list, and determining whether a handshake command exists; A type determination module is used to determine the corresponding manufacturer communication protocol type if there is a matching handshake instruction; A determination method module, used to determine the corresponding CAN message parsing method and CAN message sending method according to the manufacturer's communication protocol type; A display module, used for receiving a first CAN message, parsing the first CAN message using the CAN message parsing method, and generating display data; The conversion module is used to obtain the user's operation data, convert the operation data into a second CAN message according to the CAN message sending method, and send the second CAN message to the controller.

Images