Vehicle-mounted communication method and device for multi-protocol type signals, and vehicle

Abstract

The invention provides a multi-protocol type signal-oriented vehicle-mounted communication method and device, and a vehicle. The method comprises the steps of obtaining a target signal processing request initiated by calling a target signal processing function by an application end; determining a target channel corresponding to the target signal based on the transmission demand characteristics of the target signal and the current states of a plurality of candidate channels corresponding to the target signal; loading a conversion rule, serializing the target signal processing request into a request format corresponding to the target signal processing function and conforming to the target channel protocol, and transmitting the serialized target signal request to an adapter of the target channel; obtaining target return information responded by the request object based on the target communication request from the adapter of the target channel; loading an inverse conversion rule, and deserializing the target return information into a data format capable of responding to the target signal processing function; and sending the deserialized target return information to an application end.

Description

Technical Field

[0001] This specification relates to the field of automotive communication technology, and more particularly to an in-vehicle communication method, device, and vehicle for multi-protocol signal types. Background Technology

[0002] With the rapid development of automotive electronics technology and the widespread adoption of intelligent connected vehicles, the complexity of in-vehicle systems is constantly increasing, and the types of signals that need to be processed inside vehicles are becoming increasingly diverse, including integer, Boolean, floating-point, string, and vector data types. Simultaneously, in-vehicle communication protocols are also showing a trend of diversification. In addition to traditional Vehicle HAL (Hardware Abstraction Layer) and CAN bus communication, emerging communication methods such as TCP / IP network communication and 5G-V2X vehicle-to-everything (V2X) communication are also widely used in modern in-vehicle systems. This multi-protocol communication environment places higher demands on the signal processing and data transmission of in-vehicle systems.

[0003] However, existing in-vehicle systems still suffer from significant technical deficiencies in signal communication. First, the complexity of data type handling is a major issue. The processing logic for different signal types is scattered across various system modules, making it difficult for upper-layer applications to implement a unified calling interface, resulting in low development efficiency and maintenance difficulties. Second, the type mapping mechanism is imperfect. There is no unified mapping relationship between signal types and actual data structures. Developers need to handle data parsing and format conversion for each signal type themselves, which not only increases development difficulty and the probability of errors but also affects system reliability. Finally, the existing solutions have excessive architectural dependencies, particularly the tight coupling with the Vehicle HAL, which limits system scalability and lacks effective adaptability to other transmission methods such as TCP / IP, CAN bus, and 5G-V2X, failing to meet the communication needs of modern in-vehicle systems with multiple protocols coexisting. These problems severely restrict the development efficiency, operational performance, and future scalability of in-vehicle systems. Summary of the Invention

[0004] In view of this, the purpose of this specification is to solve the technical problems of complex data types, difficult type mapping, and strong architectural dependencies in the application layer accessing the underlying vehicle attribute signals in existing vehicle systems, and to realize the communication requirements of modern vehicle systems with multiple protocols coexisting.

[0005] To achieve the above objectives, one or more embodiments of this specification provide a vehicle-mounted communication method for multi-protocol type signals, applied to a vehicle's communication control device, wherein the communication control device is connected to an adapter for the vehicle's multi-protocol type channels; multiple applications of the vehicle are uniformly configured with various signal processing functions; the type registry of the communication control device registers candidate channel types corresponding to various signals, as well as conversion rules and inverse conversion rules corresponding to various signal processing functions; the conversion rules are used to serialize the call request of any signal processing function into a request format conforming to different channel protocols; the inverse conversion rules are used to deserialize the return information of different channel responses into a response format conforming to the response requirements of the signal processing function; the method includes: Obtain the target signal processing request initiated by any application terminal of the vehicle by calling the target signal processing function; Based on the transmission requirement characteristics of the target signal and the current state of multiple candidate channels corresponding to the target signal, the target channel corresponding to the target signal is determined; The conversion rule is loaded, the target signal processing request is serialized into a request format that corresponds to the target signal processing function and conforms to the target channel protocol, and the serialized target signal request is transmitted to the adapter of the target channel; Obtain the target return information from the adapter of the target channel in response to the target communication request; Load the inverse conversion rule to deserialize the target return information into a data format that can respond to the target signal processing function; and send the deserialized target return information to any of the application terminals.

[0006] More preferably, the communication control device is equipped with a trusted security environment; the type registry is stored in the trusted security environment; the loading of the conversion rule to serialize the target signal processing request into a request format corresponding to the target signal processing function and conforming to the target channel protocol includes: In the trusted and secure environment, the conversion rule is loaded from the type registry, and the target signal processing request is serialized into a request format that corresponds to the target signal processing function and conforms to the target channel protocol; The target signal request is output in a format converted from the trusted security environment to transmit it to the adapter of the target channel.

[0007] More preferably, the target signal processing function is used to acquire, set, or subscribe to the target signal; the multiple channels include different channels based on communication protocols such as Vehicle HAL, TCP / IP, CAN bus, and 5G-V2X.

[0008] More preferably, the transmission requirements of the target signal include one or more of the following: the data volume of the target signal, the real-time requirements of the target signal processing request, and the security level of the target signal processing request.

[0009] More preferably, the transmission requirement characteristics of the target signal are pre-registered in the controller; the controller deploys a weighted scoring formula to score the transmissibility of multiple channels; each item in the weighted scoring formula is used to evaluate the channel's score in terms of bandwidth, load, and security level; The step of determining the target channel corresponding to the target signal based on the transmission demand characteristics of the target signal and the current state of multiple candidate channels available for transmission of the target signal includes: Obtain the transmission requirement characteristics of the pre-registered target signal; Based on the transmission demand characteristics, generate corresponding weights for each item in the weighted scoring rule formula; Based on the current bandwidth, current load status, security level, and weight of each candidate channel, a transmissibility score is calculated for each candidate channel, and the channel with the highest transmissibility score is determined as the target channel corresponding to the target signal.

[0010] More preferably, the controller also registers load thresholds for multiple channels respectively, and the vehicle is configured with a resource prediction model. Before obtaining a target signal processing request initiated by any application terminal of the vehicle calling the target signal processing function, the following steps are also included: The resource prediction model is invoked at a preset time to obtain the load forecast of the multiple channels in the target future period; If the estimated load of any of the multiple channels exceeds its corresponding preset load threshold, the transmittability score of that channel at the current moment is reduced, so as to reduce the load occupancy of that channel in future time periods.

[0011] More preferably, the controller further deploys a scheduling model, wherein the adapter that requests the serialized target signal to be transmitted to the target channel includes: Based on the vehicle's operating status, the target signal's attributes, and the target channel's load status, the scheduling model is invoked to request the allocation of a corresponding priority for the serialized target signal. The serialized target signal request is sent to the priority queue, awaiting processing instructions from the adapter to be transmitted to the target channel.

[0012] More preferably, the vehicle is also equipped with a signal communication delay monitoring program; the method further includes: The timestamps of one or more preset nodes are obtained during the process of the target signal processing request being initiated, serialized, and transmitted to the adapter of the target channel, and the target return information being responded to, returned to the adapter of the target channel, deserialized, and transmitted to any of the applications. Based on the timestamps of the one or more preset nodes, the signal communication delay monitoring program is run to obtain the delay status characteristics of the target signal processing request.

[0013] Another aspect of this specification provides an in-vehicle communication control device for multi-protocol signal types, applied to a vehicle; the communication control device is connected to an adapter for the multi-protocol channel of the vehicle; multiple applications of the vehicle are uniformly configured with multiple signal processing functions, and the controller's type registry registers candidate channel types corresponding to multiple signals, as well as conversion rules and inverse conversion rules corresponding to multiple signal processing functions. The conversion rules are used to serialize the call request of any signal processing function into a request format conforming to different channel protocols, and the inverse conversion rules are used to deserialize the return information of different channel responses into a response format conforming to the response requirements of the signal processing function; the communication control device includes: The acquisition unit is used to acquire a target signal processing request initiated by any application terminal of the vehicle by calling the target signal processing function; The channel determination unit is used to determine the target channel corresponding to the target signal based on the transmission requirement characteristics of the target signal and the current state of multiple candidate channels corresponding to the target signal. A serialization unit is used to load the conversion rules, serialize the target signal processing request into a request format that corresponds to the target signal processing function and conforms to the target channel protocol, and transmit the serialized target signal request to the adapter of the target channel; A receiving unit is used to obtain target return information from the adapter of the target channel in response to the target communication request; The deserialization unit is used to load the inverse conversion rule, deserialize the target return information into a data format that can respond to the target signal processing function, and send the deserialized target return information to any of the application terminals.

[0014] Another aspect of the embodiments of this specification provides a vehicle. The vehicle includes a plurality of adapters adapted to channels of different protocol types, as well as the communication control device described above.

[0015] The communication method, device, and vehicle for multi-protocol signal types described in one or more embodiments of this specification achieve centralized management of different signal processing logics by uniformly managing candidate channel types and conversion and inverse conversion rules corresponding to signal processing functions through a type registry; intelligent routing decision-making is achieved by dynamically selecting target channels based on signal transmission demand characteristics and channel load status; the storage security of the type registry and the security of signal serialization / deserialization processes are ensured through a trusted and secure environment; predictive resource allocation is achieved through a resource prediction model; dynamic priority scheduling is achieved through a scheduling model; and accurate end-to-end latency monitoring is achieved through a latency monitoring program. These features effectively solve problems such as complex data types, difficult type mapping, strong architectural dependencies, and insufficient security protection in existing technologies. Attached Figure Description

[0016] Figure 1 This is a schematic diagram of the architecture of a vehicle communication system for multi-protocol signal processing provided in an exemplary embodiment.

[0017] Figure 2 This is a flowchart of a communication process for signals of multiple protocol types, provided in an exemplary embodiment.

[0018] Figure 3 This is a schematic diagram of the structure of a device provided in an exemplary embodiment.

[0019] Figure 4 This is a structural block diagram of a communication control device provided in an exemplary embodiment. Detailed Implementation

[0020] To enable those skilled in the art to better understand the technical solutions in this specification, the technical solutions in the embodiments of this specification will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this specification, and not all embodiments. Based on the embodiments in this specification, all other embodiments obtained by those skilled in the art without creative effort should fall within the scope of protection of this specification.

[0021] With the rapid development of vehicle intelligence technology and the implementation of functions such as intelligent cockpits, autonomous driving, and vehicle-to-everything (V2X) connectivity, the number of in-vehicle intelligent hardware has exploded. In addition to traditional engine control units and sensors, new hardware such as LiDAR, millimeter-wave radar, high-definition cameras, and domain controllers are widely used. At the signal acquisition level, vehicles no longer rely solely on the Vehicle HAL (Vehicle Hardware Abstraction Layer) to interact with hardware, but have formed a multi-communication collaborative architecture—TCP / IP protocol supports high-speed data transmission within the in-vehicle Ethernet, CAN bus ensures real-time communication between various control units in the vehicle body, and 5G technology enables remote data interaction between the vehicle and the cloud and roadside facilities. These communication methods jointly undertake the task of transmitting signals from the in-vehicle hardware.

[0022] While the parallel application of multiple communication protocols meets the complex data requirements of intelligent vehicles, it also brings the challenge of chaotic signal processing. Different protocols have significantly different transmission characteristics and data formats. For example, CAN bus signals prioritize real-time performance and have smaller data volumes, while TCP / IP protocols transmit larger data volumes and have relatively higher latency. The traditional Vehicle HAL was designed for direct interaction with the underlying hardware; its instruction set is only compatible with its own hardware interfaces and cannot recognize or process heterogeneous signals from other protocol channels such as TCP / IP, CAN bus, and 5G. The lack of a unified standard for signal types and actual transmitted data structures requires developers to handle signal parsing and format conversion themselves, increasing development complexity and increasing the risk of data transmission errors due to conversion logic mistakes, thus affecting system stability. Furthermore, different vehicle models have different hardware architectures, requiring extensive code modifications for each model to adapt, resulting in long development cycles, high maintenance costs, and difficulties in achieving standardized deployment.

[0023] In view of this, in one embodiment shown in this specification, a vehicle communication system for multi-protocol signal processing is provided, the main architecture and data transmission direction of which are as follows: Figure 1 As shown. The vehicle communication system 100 can be functionally divided into an application layer 110 that implements various vehicle functions, a unified adaptation layer 120, protocol adaptation layers 130 consisting of multiple adapters conforming to various communication protocols, and a hardware layer 140 consisting of various onboard hardware devices and vehicle-controllable cloud and remote devices. Generally, each hardware device in the hardware layer connects to one or more corresponding adapters using its preset communication protocol to achieve corresponding instruction parsing and signal processing functions.

[0024] The communication method for multi-protocol signal processing provided in this embodiment can be applied to... Figure 1The unified adaptation layer 120 of the system shown is typically configured in the vehicle's central control unit (VCU), or it can be configured in a controller (such as an MCU) specifically designed for multi-type signal communication in the vehicle. Those skilled in the art will understand that the communication control logic implemented by the unified adaptation layer 120 can also be deployed in the vehicle's multi-protocol adapter (such as a Vehicle HAL adapter), utilizing the existing adapter hardware environment to achieve unified processing of various protocol signals. Therefore, this specification does not limit the hardware devices deployed in the unified adaptation layer 120, and they are collectively referred to as "communication control devices" in this specification.

[0025] In this embodiment, the signal processing functions uniformly configured for multiple vehicle applications can be encapsulated in an independent function library. This function library supports dynamic updates, facilitating subsequent functional expansion. The unified interface for the signal processing functions can be defined as follows: [… / / Signal acquisition function virtual int get(const std::string&signalName, void outputData, size_tdataLen) = 0; / / Signal setting function virtual int set(const std::string&signalName, const void inputData,size_t dataLen) = 0; / / Signal subscription function virtual int subscribe(const std::string&signalName, std::function<void(const void data, size_t dataLen)> callback) = 0; …] In the above interface, `signalName` is the unique identifier of the signal, `outputData` / `inputData` are pointers to the data buffer, `dataLen` is the data length, and `callback` is the subscription callback function used to receive real-time data from the subscribed signal. Applications initiate signal processing requests by calling this unified interface, eliminating the need to concern themselves with underlying channel protocol differences and reducing application development complexity.

[0026] The registration form for communication control equipment can store data using a key-value pair structure. Specifically, it stores: a unique signal identifier (Key1) - a list of candidate channel types (Value1), a signal processing function identifier (Key2) - a conversion rule (Value2), and a signal processing function identifier (Key2) - a reverse conversion rule (Value3). The conversion rule serializes the call request of any signal processing function into a request format conforming to different channel protocols. The reverse conversion rule deserializes the return information of different channel responses into a response format conforming to the response requirements of the signal processing function. The conversion and reverse conversion rules can be stored in XML format, defining data type mapping relationships, protocol field encapsulation formats, and other information. For example, the XML fragment for the conversion rule corresponding to the "VehicleSpeed" signal is as follows: … <conversionrule function="get" channeltype="VehicleHAL"> <datamapping> <sourcetype> float< / sourcetype> <targettype> VehiclePropertyValue< / targettype> < / datamapping> <packageformat> <field name="propertyId" type="int" value="0x0001" / > <field name="valueType" type="int" value="0x0002" / > <field name="floatValue" type="float" source="outputData" / > < / packageformat> < / conversionrule> … The aforementioned XML fragment defines the conversion rules for the `get` function under the Vehicle HAL channel, mapping float type data from the application side to the `VehiclePropertyValue` type, and specifying the encapsulation format of the protocol fields. In this embodiment, the target signal processing function can be used to implement the functions of getting, setting, or subscribing to the target signal; the multiple channels include different channels based on communication protocols such as Vehicle HAL, TCP / IP, CAN bus, and 5G-V2X, which can meet the signal transmission needs in different scenarios.

[0027] The specific process of the multi-protocol type signal communication method provided in this embodiment can be described as follows: Figure 2 As shown, the specific steps may include the following: S202: Obtain the target signal processing request initiated by any application terminal of the vehicle calling the target signal processing function.

[0028] Specifically, the vehicle's application layer comprises multiple application modules, such as the autonomous driving control module, the intelligent cockpit interaction module, and the remote diagnostic module. Each application module can call a unified signal processing function library via a dynamic link library (DLL). When an application module needs to perform signal interaction, it initiates a target signal processing request by calling the corresponding target signal processing function. For example, when the autonomous driving control module needs to obtain the current vehicle speed, it calls the `get` function to initiate a request to obtain the "VehicleSpeed" signal. The request parameters are the signal's unique identifier "VehicleSpeed", a data buffer pointer, and the data length.

[0029] The communication control device receives the target signal processing request through a unified application interface (such as IS2SClient), enabling unified access between the application and the communication control device. Upon receiving the request, the communication control device first verifies its validity, including whether the application ID is valid, whether the request parameters are complete, and whether the data length matches. If the verification fails, an error code is returned (e.g., 0x0001 indicates invalid identity, 0x0002 indicates incomplete parameters). If the verification passes, key information such as the target signal processing function identifier, unique signal identifier, and data cache pointer are extracted from the request, and the process proceeds to subsequent steps.

[0030] S204: Based on the transmission requirement characteristics of the target signal and the current state of multiple candidate channels available for transmission of the target signal, determine the target channel corresponding to the target signal.

[0031] In this embodiment, the transmission requirement characteristics of the target signal include one or more of the following: the data volume of the target signal, the real-time requirements of the target signal processing request, and the security level of the target signal processing request. These transmission requirement characteristics can be pre-registered in the aforementioned type of registry of the communication control device via a configuration file. The configuration file supports offline modification and online updates. An example of configuring the transmission requirement characteristics is shown in the table below: Table 1. Example of Signal Transmission Requirement Feature Configuration Table 1 shows that vehicle braking signals have a relatively small data volume but extremely high real-time requirements (millisecond-level response), thus requiring the highest security level. Vehicle entertainment systems have a larger multimedia data volume, moderate real-time requirements, and a lower security level. This table categorizes security levels into four levels: Top Secret, Confidential, Secret, and Standard. Different security levels correspond to different encryption algorithms and access control strategies: for example, Top Secret uses AES-256 encryption algorithm + two-factor authentication, Confidential uses AES-128 encryption algorithm + identity authentication, Secret uses DES encryption algorithm, and Standard requires no encryption. The candidate channel type list is pre-screened based on the signal's application scenario, data volume, real-time requirements, and encryption security needs to ensure that all candidate channels meet the signal transmission requirements.

[0032] The current state of the candidate channel described in this embodiment typically includes the candidate channel's current bandwidth, current load, and security attributes. Developers can deploy specific channel selection strategies based on the transmission requirements of the target signal and the current state of the candidate channels. For example, they can select the candidate channel with the highest matching degree to the target signal as the target channel, or select the candidate channel with the shortest transmission time as the target channel, and so on.

[0033] In another embodiment, to achieve precise selection of the target channel, the communication control device deploys a weighted scoring formula to score the transmissibility of multiple channels; the components of the weighted scoring formula are used to evaluate the channel's performance in terms of bandwidth, load, security level, etc. For example, the mathematical model of the weighted scoring formula is as follows: in, A transmittability score is given (the score can be set to a range of 0-10). For bandwidth weight, For load weight, For security level weighting, Score the bandwidth item (value range 0-10). Score the load item (value range 0-10). The security level is scored (range 0-10 points). Those skilled in the art can also set more attribute scoring items according to specific transmission requirements, such as scoring items for transmission stability, etc., and these must meet the following requirements. .

[0034] In yet another embodiment shown, the weights can be adjusted based on the attribute characteristics of the target signal. Dynamic adjustments are performed to customize the selection of corresponding target channels for different types of target signals. Specifically, step S204 includes the following sub-steps: S2041: Obtain the transmission requirement characteristics of the pre-registered target signal.

[0035] The communication control device queries and retrieves the transmission requirement characteristics corresponding to the target signal from the signal unique identifier registration file. For example, for the "VehicleSpeed" signal, its pre-registered transmission requirement characteristics are: small data size (≤1KB), high real-time requirement (response time ≤50ms), high security level (confidential), and the candidate channel type list is Vehicle HAL and CAN. After retrieving the characteristics, the communication control device loads them into memory for subsequent weight allocation and scoring calculation.

[0036] S2042: Generate corresponding weights for each item of the weighted scoring rule formula based on the transmission demand characteristics.

[0037] The communication control equipment has a built-in weight allocation strategy that dynamically assigns weights to each component based on the priority characteristics of the target signal's transmission requirements. The core logic of the weight allocation strategy can be set as follows: If the signal real-time requirement is high (response time ≤ 50ms), then the load weight... ≥0.4; if the signal data size is large (≥10MB), then the bandwidth weight is... ≥0.5; if the signal security level is Top Secret or Confidential, then the security level weight is... ≥0.4; the sum of weights is guaranteed to be 1, and the remaining weights are evenly distributed according to other features.

[0038] For example, the "VehicleSpeed" signal has high real-time requirements, a high safety level, and a small data volume, therefore the weights of the load items are... The weight of the security level sub-item is set to 0.4. Set the weight to 0.4 for the bandwidth component. Set the weight to 0.2; for the "CloudMusic" signal, which has a large data volume, moderate real-time requirements, and ordinary security level, the weight of the bandwidth component will be adjusted accordingly. Set the weight to 0.5 for the load component. The weight of the security level sub-item is set to 0.3. Set to 0.2; for the "BrakeCommand" signal, which has extremely high real-time requirements (≤20ms), a top-secret security level, and a small data volume, the weight of the load items will be... Set the weight to 0.5 for the security level sub-item. Set the weight to 0.5 for the bandwidth component. Set it to 0.

[0039] S1023: Based on the current bandwidth, current load status, security level and weight of each candidate channel, calculate the transmissibility score corresponding to each candidate channel, and determine the channel with the highest transmissibility score as the target channel corresponding to the target signal.

[0040] The communication control equipment can collect the current status parameters of each candidate channel in real time through the status feedback interface of each channel adapter. The calculation method for each sub-item score is as follows: Bandwidth sub-score Calculated based on the degree of matching between the currently available bandwidth of the channel and the required signal bandwidth. If the currently available bandwidth is greater than or equal to 1.5 times the required signal bandwidth, =10 points; if the current available bandwidth is greater than or equal to the required signal bandwidth and less than 1.5 times, =8 points; If the current available bandwidth is ≥ 0.8 times the required signal bandwidth and < the required signal bandwidth, =6 points; if the current available bandwidth is less than 0.8 times the required signal bandwidth, =0 points. For example, the "VehicleSpeed" signal requires a bandwidth of 10Kbps, and the currently available bandwidth of the Vehicle HAL channel is 100Kbps (≥10×1.5=15Kbps), then... =10 points; The current available bandwidth of the CAN channel is 20Kbps (≥15Kbps), then =10 points.

[0041] Load sub-item scoring The load rate is calculated based on the current channel load rate: Load rate = Current task queue length / Maximum task queue length × 100%. If the load rate is ≤30%, =10 points; if 30% < load rate ≤ 50% =8 points; if 50% < load rate ≤ 70% =6 points; if 70% < load rate ≤ 90% =4 points; if the load rate is >90% =0 points. For example, if the current task queue length of the Vehicle HAL channel is 10, the maximum task queue length is 50, and the load rate is 20% ≤ 30%, then... =10 points; The current task queue length of the CAN channel is 15, the maximum task queue length is 50, and the load rate is 30%. =10 points.

[0042] Safety level sub-item scoring Calculated based on the degree of matching between the security mechanisms supported by the channel and the signal security level. If the security mechanisms supported by the channel fully meet the signal security level requirements, =10 points; If the basic requirements are met but some safety redundancy exists, =8 points; if only the minimum safety requirements are met =6 points; if safety requirements cannot be met =0 points. For example, the "VehicleSpeed" signal security level is confidential (requires AES-128 encryption + authentication), and the Vehicle HAL channel supports AES-128 encryption + authentication, fully meeting the requirements. =10 points; The CAN channel supports AES-256 encryption and authentication, exceeding the requirements. =8 points.

[0043] After obtaining the scores for each item according to the above calculation method, substitute them into the weighted scoring formula to calculate the transmissibility score. For example, the Vehicle HAL channel score for the "VehicleSpeed" signal: S = 0.2 × 10 + 0.4 × 10 + 0.4 × 10 = 10 points; the CAN channel score: S = 0.2 × 10 + 0.4 × 10 + 0.4 × 8 = 9.2 points.

[0044] The communication control device sorts all candidate channels by their transmissibility scores in descending order and selects the channel with the highest score as the target channel. If multiple channels have the same score (e.g., all 10 points), the historical transmission stability of each channel is further compared. Historical transmission stability = number of error-free transmissions / total number of transmissions × 100%, and the channel with the highest historical transmission stability is selected.

[0045] If the transmittability scores of all candidate channels are lower than the preset threshold (e.g., 6 points), the communication control device will trigger a channel switching alarm and select the channel with the highest score as the temporary target channel. At the same time, the backup channel detection process will be started to try to enable the preset backup channel (e.g., emergency communication channel).

[0046] Furthermore, to optimize channel traffic configuration and prevent excessive channel load from causing transmission performance degradation during certain periods, thus enabling advance load control, the communication control device also registers load thresholds for multiple channels. These load thresholds are determined based on the channel's hardware performance, transmission protocol characteristics, and historical load data, and are stored in the communication control device's registration file. The vehicle is equipped with a resource prediction model, and before executing step S201, the following resource prediction and load control steps are also included.

[0047] S2001: At a preset time, the resource prediction model is invoked to obtain the load forecast of the multiple channels in the target future time period.

[0048] The preset call timing can be set based on vehicle operating patterns and peak signal transmission periods. For example, the first call can be made 5 minutes after vehicle startup, followed by calls every 5 minutes. During peak signal transmission periods (such as when vehicles are traveling at high speeds or multiple applications are making simultaneous requests), the call cycle can be shortened to once every 2 minutes. The target future time period can be set to the next 30 minutes. The model output is a load prediction curve for each channel in the next 30 minutes, with the horizontal axis representing time (minutes) and the vertical axis representing load rate (%). For example, it is predicted that the load rate of the Vehicle HAL channel will reach 85% in the next 10-15 minutes, exceeding its preset load threshold of 80%.

[0049] The resource prediction model is built on a Long Short-Term Memory (LSTM) network. The feature vector of the input layer may include: channel load rate data of the same historical period, date type encoding, current vehicle speed, current road segment type encoding, navigation-predicted path information encoding, current number of active application terminals, and historical signal transmission volume of the same period. The output layer outputs the load rate prediction result.

[0050] S2002: If the estimated load of any channel among multiple channels exceeds its corresponding preset load threshold, reduce the transmittability score of the channel at the current time to reduce the load occupancy of the channel in future time periods.

[0051] The communication control device compares the load forecast for each channel with the corresponding preset load threshold. If the load forecast for a channel exceeds the preset threshold in any future time window, it is determined that the channel may experience excessive load in the future. At this point, the communication control device calculates the load component of that channel in its current transmittance score. Deductions will be made, and the specific deduction strategy is not limited. For example, the deduction amount can be determined based on the extent to which the estimated load exceeds the threshold. If the estimated load exceeds the threshold by 5% or less (including 5%), deduct 2 points; If the estimated load exceeds the threshold by 5%-10% (inclusive), 4 points will be deducted; If the estimated load exceeds the threshold by more than 10%, deduct 6 points.

[0052] The transmissibility score of a channel is reduced, thereby decreasing the probability of that channel being selected as a target channel, reducing the transmission tasks assigned to that channel at the current moment, and avoiding excessive load in future periods. If the estimated load exceeds the threshold by more than 10%, in addition to reducing the score, the communication control equipment will also send a load warning message to the vehicle's communication control unit (VCU) to remind the driver or the background management system to pay attention to the channel status.

[0053] Once the target channel is determined, the communication control equipment can continue execution. Figure 2 The following steps are shown.

[0054] S206: Load the conversion rule, serialize the target signal processing request into a request format that corresponds to the target signal processing function and conforms to the target channel protocol, and transmit the serialized target signal request to the adapter of the target channel.

[0055] In this embodiment, serialization refers to the process of converting complex target signal processing requests (such as structured data containing function identifiers, signal parameters, etc.) into binary streams or data in a specific protocol format that can be transmitted in the target channel, so that the signal source can identify and process them; deserialization is the reverse process, which refers to restoring the binary streams or data in a specific protocol format transmitted in the channel back to the original structured data, so that the application can identify and process them.

[0056] For example, if the target channel is the Vehicle HAL channel, the target signal processing request is a GET request, and the conversion rule defines mapping of application-side float type data to VehiclePropertyValue type, with encapsulated fields including propertyId (property ID), valueType (value type), and floatValue (floating-point value), then the serialization process is as follows: 1. Extract the unique signal identifier "VehicleSpeed" from the request parameters, query the attribute ID mapping stored in the above type registry, and obtain the propertyId corresponding to "VehicleSpeed" as 0x0001; 2. Determine valueType as 0x0002 based on the signal data type (float); 3. Use the float type data (such as 60.0) passed in from the application as the value of the floatValue field; 4. Encapsulate the above three fields into a binary data stream according to the byte order (big-endian) of the Vehicle HAL protocol to generate serialized request data.

[0057] An adapter is an intermediate component connecting communication control equipment and the channel. It has built-in protocol parsing and data forwarding modules, responsible for protocol adaptation and data transmission between the communication control equipment and the channel. Different types of adapters correspond to different communication protocols, for example: Vehicle HAL Adapter: Supports the Vehicle HAL protocol and communicates with the Vehicle HAL layer through the Vehicle Manager interface of Android Automotive, enabling interaction between the communication control device and the Vehicle HAL layer signal source; TCP / IP Adapter: Supports the TCP / IP protocol and has a built-in TCP client / server module, communicating with the cloud or in-vehicle Ethernet devices through an Ethernet interface; CAN Bus Adapter: Supports CAN 2.0 and CAN FD protocols, has a built-in CAN communication control device and transceiver, and communicates with the vehicle ECU and sensors through the CAN bus; 5GV2X Adapter: Supports 5G-V2X protocols (such as NR-V2X), has a built-in 5G module, and communicates with the cloud, other vehicles, and roadside units (RSUs) through the 5G network.

[0058] After receiving the serialization request transmitted by the communication control device, the adapter performs integrity verification on the requested data (such as CRC32 verification). If the verification passes, the data is forwarded to the corresponding channel and signal source.

[0059] Furthermore, to optimize signal transmission scheduling efficiency, avoid channel congestion, and ensure real-time transmission of critical signals, the communication control device is also equipped with a scheduling model that can work in conjunction with the aforementioned resource prediction model. The process of transmitting the serialized target signal request to the adapter of the target channel also includes the following scheduling steps: Based on the vehicle's operating status, the target signal's attributes, and the target channel's load status, the scheduling model is invoked to allocate a corresponding priority to the serialized target signal request; the serialized target signal request is sent to the priority queue, awaiting processing instructions from the adapter of the target channel.

[0060] The vehicle's operating status is obtained through communication between the communication control equipment and the vehicle communication control equipment (VCU) and body communication control equipment (BCM), including vehicle speed, driving mode (high speed / low speed / congestion), whether it is in autonomous driving mode, braking status, steering status, etc.; the attributes of the target signal include signal type (control signal / sensing signal / entertainment signal / diagnostic signal), real-time requirements, safety level, etc.; the load status of the target channel includes data such as the real-time load rate of the current channel and the task queue length.

[0061] The scheduling model employs an AI real-time signal classification engine based on reinforcement learning algorithms, specifically constructed using a Deep Q-Network (DQN) algorithm. The model's state space S includes vehicle operating state parameters, target signal attribute parameters, and target channel load state parameters; the action space A represents priority levels (high, medium, low), corresponding to action values ​​1, 2, and 3; and the reward function... The design aims to minimize end-to-end signal processing latency while also considering channel load balancing. The specific formula can be expressed as follows: In one of the illustrated embodiments, , Weighting coefficients ( =0.7, =0.3); As a delay reward, if the end-to-end delay is less than or equal to the signal real-time requirement threshold, =10, otherwise = - (delay / threshold - 1) × 10; As a load balancing reward, if the channel load rate is ≤50%, =5, if 50% < load rate ≤ 70% =3, if the load rate is >70%. = -2.

[0062] The model obtains observations of vehicle operating status and network status by interacting with the environment, selects priority actions based on these observations, obtains reward values ​​from environmental feedback after executing the actions, updates model parameters using these reward values, and dynamically outputs and adjusts the priority configuration. In this embodiment, priorities are divided into three levels: high, medium, and low, and the scheduling strategies for each level are as follows: High priority: Employs preemptive scheduling, allowing interruption of currently executing medium and low priority tasks for priority transmission; suitable for safety-critical signals such as autonomous driving control signals and braking signals. Medium priority: Employs non-preemptive scheduling, transmitting signals after high priority tasks have completed; suitable for intelligent cockpit interaction signals and general perception signals. Low priority: Employs batch scheduling, transmitting signals in batches after accumulating a certain number of tasks; can be interrupted by high and medium priority tasks; suitable for non-real-time signals such as diagnostic log uploads and software update package transmissions.

[0063] The communication control equipment sets up an independent priority queue for each target channel. Each queue is divided into three priority sub-queues: high, medium, and low. The queues manage tasks according to the FIFO (First-In, First-Out) principle. The scheduling model can also dynamically adjust the processing order of requests in the queues based on the real-time load status. The specific scheduling logic is as follows: When the target channel load rate is ≤50%, the tasks in each sub-queue are processed in the order of high, medium, and low priority, and within each sub-queue, they are processed in FIFO order; when 50% < target channel load rate ≤70%, the processing of tasks in the low-priority sub-queues is suspended, and only the tasks in the high and medium-priority sub-queues are processed; when the target channel load rate is >70%, only the tasks in the high-priority sub-queues are processed, and the processing of tasks in the medium and low-priority sub-queues is suspended until the load rate drops below 70%.

[0064] Based on the scheduling arrangements described in one or more embodiments of this specification, the communication control device can efficiently transmit the target signal to the adapter of the target channel.

[0065] S208: Obtain the target return information from the adapter of the target channel in response to the target communication request.

[0066] After receiving the serialized target signal request, the adapter of the target channel will parse the request and obtain the specific address of the request object based on the signal address mapping within the channel. The request object can be the specific signal source connected to the adapter. The adapter will then transmit the serialized target signal request to the corresponding signal source (such as a vehicle ECU, sensor, or cloud service). The signal source will perform corresponding processing operations based on the request content and generate target return information. Alternatively, the request object can be the adapter's memory. For example, a signal source following this protocol may report signals to the adapter of the target channel based on settings that request the target signal at fixed intervals.

[0067] The returned information is encapsulated in the same protocol format as the requested information, including fields such as status code (success = 0, failure = non-zero), data length, and data content. After receiving the returned information, the adapter performs integrity verification and protocol parsing, extracts the data content, and then transmits the returned information to the receiving buffer of the communication control device via a secure communication interface. The communication control device reads the target returned information from the receiving buffer and proceeds to the subsequent deserialization step. For example, when the signal source is a vehicle speed sensor, it collects current vehicle speed data (e.g., 60 km / h) based on the GET request, generates returned information containing the vehicle speed value, and transmits it to the VehicleHalAdapter via the Vehicle HAL channel.

[0068] S210: Load the inverse conversion rule, deserialize the target return information into a data format that can respond to the target signal processing function; and send the deserialized target return information to any of the application terminals.

[0069] Deserialization is the inverse operation of serialization, strictly following the protocol field parsing format and data mapping relationships defined in the inverse conversion rules. Taking the response deserialization corresponding to a GET request serialization as an example: If the target channel is the Vehicle HAL channel, the previous serialization process of the GET request (such as obtaining the "VehicleSpeed" signal) encapsulated the application-side float-type request parameters into a Vehicle HAL protocol binary stream containing propertyId (0x0001), valueType (0x0002), and floatValue fields; then the corresponding response deserialization process is as follows: 1. Parse the binary data stream returned by the Vehicle HAL channel, and extract the propertyId (verified as 0x0001, corresponding to the "VehicleSpeed" signal), valueType (verified as 0x0002, confirming it is floating-point data), and floatValue field values ​​(e.g., 60.0, i.e., current vehicle speed data) in the byte order (big-endian) agreed by the protocol. 2. Verify whether the propertyId matches the signal unique identifier "VehicleSpeed" in the original GET request, and ensure that the returned information is the response data of the target signal. If they do not match, return a data error code (such as 0x0003). 3. According to the reverse conversion rule, restore the extracted floatValue field value (60.0) to a float type data that the application's get function can receive, ensuring that the data type is consistent with the parameter type when the application calls it; 4. Generate the deserialized return data and return it to the application layer (specifically, it can be returned to the application that sent the function call, or another application specified by that application).

[0070] In another embodiment shown in this specification, to ensure the security of the signal processing process and prevent the conversion rules from being tampered with and the signal data from being stolen, the communication control device is equipped with a Trusted Security Environment (TEE in this embodiment, specifically implemented using ARM TrustZone technology). The TEE is hardware isolated from the normal execution environment (REE), has an independent processor core, memory, storage, and peripherals, and only allows authorized security applications (TAs) to run. The type registry is encrypted and stored in the secure storage area of ​​the TEE. The encryption algorithm can be AES-256, and the key is generated and managed by the hardware security module (HSM) of the TEE to ensure the storage security of the type registry. Therefore, step S206 specifically includes the following sub-steps: S2061: Load the conversion rule from the type registry in the trusted security environment, and serialize the target signal processing request into a request format that corresponds to the target signal processing function and conforms to the target channel protocol.

[0071] Specifically, the REE environment of the communication control equipment sends a conversion rule loading request to the TEE through the Secure Call interface. The request carries the target signal processing function identifier and the target channel type. After receiving the request, the TEE first authenticates the request, verifying whether the application in the REE environment has permission to access the type registry. After successful authentication, the TEE reads the encrypted type registry from the secure storage area, decrypts it using the key in the HSM, and then queries the corresponding conversion rule based on the target signal processing function identifier and the target channel type. The secure application (TA) running in the TEE is responsible for performing the serialization operation, which strictly follows the data mapping relationship and protocol field encapsulation format defined in the conversion rule.

[0072] For SET requests involving safety-critical signals (such as vehicle braking commands and steering commands), the REE environment can only send encrypted signal data to the TEE. The TEE decrypts the data within a secure enclave, verifies the request initiator's identity and permissions (via APP ID and digital signature verification), and upon successful verification, performs parsing and outputs the plaintext serialized result, ensuring the secure processing of sensitive signals. If identity and permission verification fails, the TEE returns a permission error code and terminates the serialization process. Upon successful verification, parsing and outputting the plaintext serialized result ensures the secure processing of sensitive signals.

[0073] S2062: Request the output of the target signal in its format converted from the trusted security environment to transmit it to the adapter of the target channel.

[0074] After serialization, the TEE requests and transmits the serialized target signal to the secure buffer of the REE environment via the secure output interface. The secure buffer stores the data in an encrypted manner to prevent data theft within the REE environment. After reading the data from the secure buffer, the REE environment of the communication control device transmits the data to the adapter of the target channel through the communication interface (such as SPI or Ethernet) corresponding to the target channel adapter.

[0075] After the adapter in the target channel sends the target return information back to the communication control device, the reverse conversion operation continues to be performed in the trusted and secure environment. Step S210 specifically includes: The communication control device invokes the TEE again to load the inverse conversion rules corresponding to the target signal processing function and the target channel from the type registry. Within the TEE, the target return information is deserialized into a data format that can respond to the target signal processing function according to the inverse conversion rules. For example, binary data returned by the Vehicle HAL layer is deserialized into floating-point vehicle speed data supported by the application, and data packets returned by the TCP / IP channel are deserialized into structure data supported by the application. After deserialization, the deserialized target return information is sent to the requesting application through the unified application interface, completing the entire signal communication process.

[0076] Furthermore, to ensure that the signal communication delay meets service requirements and to promptly detect and handle delay anomalies, the vehicle is also equipped with a signal communication delay monitoring program. This program can be deployed in the processor core of the communication control equipment and runs in an interrupt-driven manner to ensure the real-time performance of delay monitoring. The method also includes the following delay monitoring steps: S212: Obtain the timestamps of one or more preset nodes during the process of the target signal processing request being initiated, serialized, and transmitted to the adapter of the target channel, and the target return information being responded to, returned to the adapter of the target channel, deserialized, and transmitted to any of the applications.

[0077] The preset nodes are configured according to the entire signal communication process. Each node is equipped with a high-precision timestamp acquisition module, which can be implemented using the hardware timer of the communication control equipment. When each node is triggered, the timestamp acquisition module reads the current value of the hardware timer and uses it as the timestamp of that node, storing it in the timestamp buffer of the communication control equipment.

[0078] S214: Based on the timestamps of the one or more preset nodes, run the signal communication delay monitoring program to obtain the delay status characteristics of the target signal processing request.

[0079] The delay monitoring program calculates the delay for different stages based on the timestamps of each node, such as request transmission delay (the time difference between the communication control device receiving the request and the request being transmitted to the adapter), signal source response delay (the time difference between the request being transmitted to the adapter and the adapter receiving the return information), return information transmission delay (the time difference between the adapter receiving the return information and the application receiving the return information), and end-to-end total delay (the time difference between the application initiating the request and the application receiving the return information). If the delay of a certain stage or the end-to-end total delay exceeds the preset delay threshold of the target signal, an alarm mechanism is triggered, sending an alarm message to the relevant management module through the communication control device to remind staff to troubleshoot and optimize. For example, if the end-to-end total delay of the "VehicleSpeed" signal exceeds the 50ms threshold, an alarm is triggered, indicating that there may be a problem of excessive channel load or slow signal source response.

[0080] Furthermore, the communication control device described in this embodiment can be extended to vehicles of different models. Specifically, the communication control device can define a set of standard operation primitives independent of vehicle model, including initialization, data read / write, status query, and interrupt registration. Different vehicle models achieve adaptation by implementing specific drivers of this set of standard primitives, mapping the signal configurations of different vehicles to the conversion and inverse conversion rules of the type registry. The configuration-driven architecture adaptation engine automatically completes service discovery, address mapping, and communication topology configuration by parsing a configuration file describing the target hardware architecture, achieving seamless deployment from a single software image to different hardware platforms.

[0081] For example, "VehicleSpeed" might be mapped to CAN ID 0x0A on one vehicle model, while it might be mapped to a different ID on another. This mapping is managed by a configuration-driven architecture adaptation engine, requiring no code modification. When a vehicle needs to adapt to a new hardware architecture, no core code modification is required; only a configuration file describing the new hardware architecture needs to be written. After parsing this configuration file, the configuration-driven architecture adaptation engine automatically completes service discovery and address mapping between the communication control device and the new hardware adapter. The communication control device then loads the corresponding driver for the new hardware to achieve compatibility. This design significantly improves code reusability and system maintainability, and reduces the development cost of cross-vehicle adaptation.

[0082] For a GET request initiated by the application layer to obtain the vehicle battery status, the request is transmitted to the controller via the unified application interface. The routing gateway, based on signal transmission requirements (medium real-time performance, confidential security level), prioritizes the Vehicle HAL channel as the primary path and calls the corresponding VehicleHal Adapter to execute the request. When the VehicleHal Adapter call times out or returns a failure response code, the routing gateway immediately triggers a fast failure transfer mechanism. It queries the candidate channel list from the type registry, recalculates the transmissibility score of the candidate channels, and finally reroutes the request to the TCP / IP Adapter corresponding to the TCP / IP channel. The TCP / IP Adapter obtains battery status data from the remote server through a stable TCP connection, transmits the data to the controller, loads the inverse conversion rules in the type registry, performs data deserialization in the TEE environment, converts it into a structure object recognizable by the application layer, and sends it to the application. During this process, the latency awareness system accurately records the entire process time from request initiation to failure confirmation (including routing decision time, adapter call time, etc.). This data is automatically synchronized to the training dataset of the resource prediction model, providing data support for subsequent optimization of channel priority allocation and improvement of fault prediction accuracy. The entire process took 65ms, which did not exceed the preset 100ms real-time threshold of the signal, ensuring the continuous availability of application layer services.

[0083] Furthermore, the communication method provided in this embodiment can also be applied to subscribe-type requests. The application layer (such as the intelligent cockpit temperature control module) initiates a subscribe request to subscribe to the in-vehicle temperature signal, carrying the signal's unique identifier "InteriorTemperature" and the callback function address. Upon receiving the request, the routing gateway completes application-side identity verification and permission verification, registers the callback function's associated information locally, and selects the CAN bus channel as the subscription data transmission channel based on the signal attributes (high-frequency change, low data volume), simultaneously registering the subscription information to the communication link corresponding to the signal source. When the in-vehicle temperature sensor detects a data change (e.g., from 25℃ to 27℃), it actively pushes the change event through the IVehehback mechanism. The event is transmitted to the CanBusAdapter via the CAN bus, and after protocol parsing, the adapter pushes the change event to the routing gateway. Upon receiving the change event, the routing gateway calls the type registry to load the corresponding inverse conversion rule, deserializes the changed data into floating-point temperature data (27.0℃) in the TEE environment, and then directly triggers and calls back the function pre-registered by the application layer, pushing the temperature change data to the intelligent cockpit temperature control module in real time. The entire process adopts an event-driven model, eliminating the need for continuous polling at the application layer, reducing system resource consumption, and enabling real-time perception and rapid response to signal changes.

[0084] The multi-protocol signal communication method provided by one or more of the above embodiments can also be applied to other scenarios, which are not specifically limited in this specification. By uniformly managing channel types and conversion rules related to signal processing through a type registry, the problems of complex data types and difficult type mapping in the prior art are solved, reducing application development and maintenance costs. Through multi-protocol channel adaptation and intelligent routing decisions based on transmission demand characteristics and channel status, the dependence on a single Vehicle HAL architecture is broken, achieving signal transmission adaptation in multiple scenarios. The TEE trusted security environment ensures the security of type registry storage and the serialization / deserialization process of key signals, reducing the risk of data tampering and theft. The LSTM-based resource prediction model enables advance prediction and control of channel load, avoiding excessive load in future periods. The reinforcement learning-based scheduling model enables dynamic priority scheduling of signal requests, ensuring real-time transmission of key signals. A high-precision delay monitoring program enables accurate end-to-end delay monitoring, promptly detecting delay anomalies. The signal communication method provided in this specification is efficient, secure, flexible, and reliable, significantly improving the performance of vehicle signal communication.

[0085] Figure 3 A schematic block diagram of an in-vehicle communication device for multi-protocol signal types, according to another embodiment of this specification, is shown. Figure 3 As shown, the vehicle communication device 700 includes a processor 701, an internal bus 702, a network interface 703, a memory 704, and a non-volatile memory 705, and may also include other hardware required for other services. The processor 701 can read the corresponding computer program from the non-volatile memory 705 into the memory 704 and then run it to implement the steps of the vehicle energy management method described above. Of course, in addition to the software implementation, this application does not exclude other implementation methods, such as logic devices or a combination of hardware and software, etc. That is to say, the execution subject of the following processing flow is not limited to individual logic units, but can also be hardware or logic devices.

[0086] Please see Figure 1 The communication control device is connected to the adapters of the vehicle's multiple channels; the vehicle's multiple applications are uniformly configured with a variety of signal processing functions, and the controller's type registry registers candidate channel types corresponding to various signals, as well as conversion rules and inverse conversion rules corresponding to various signal processing functions. The conversion rules are used to serialize the call request of any signal processing function into a request format that conforms to different channel protocols, and the inverse conversion rules are used to deserialize the return information of different channel responses into a response format that conforms to the response requirements of the signal processing function.

[0087] Figure 4This is a structural block diagram of the vehicle communication control device 40 for multiple protocol types in an embodiment of the present invention, as shown below. Figure 4 As shown, the device 40 includes: The acquisition unit 402 is used to acquire a target signal processing request initiated by any application terminal of the vehicle by calling the target signal processing function.

[0088] The channel determination unit 404 is used to determine the target channel corresponding to the target signal based on the transmission demand characteristics of the target signal and the current load status of multiple candidate channels available for transmission of the target signal.

[0089] The channel determination unit 404 includes a feature acquisition subunit 4041, a weight allocation subunit 4042, a score calculation subunit 4043, and a channel selection subunit 4044. Specifically: the feature acquisition subunit 4041 acquires the transmission requirement features of the target signal from a locally pre-stored signal feature registry; the weight allocation subunit 4042 generates corresponding weights for each item in the weighted scoring formula based on the transmission requirement features; the score calculation subunit 4043 collects the current state parameters of candidate channels and calculates the transmissibility score of each candidate channel based on the weights; and the channel selection subunit 4044 sorts the transmissibility scores and selects the channel with the highest score as the target channel.

[0090] Furthermore, the channel determination unit 404 also includes a resource prediction subunit 4045 and a load control subunit 4046. The resource prediction subunit 4045 is used to call the resource prediction model to obtain the load forecast of multiple channels in the future period. The load control subunit 4046 is used to reduce the current transmittability score of a channel and reduce the transmission tasks allocated to the channel if the load forecast of a certain channel exceeds a preset threshold.

[0091] The serialization unit 406 is used to load the conversion rule, serialize the target signal processing request into a request format that corresponds to the target signal processing function and conforms to the target channel protocol, and transmit the serialized target signal request to the adapter of the target channel.

[0092] The communication control device is equipped with a TEE (Trusted and Secure Environment), and the type registry is stored in the TEE. The serialization unit 406 includes a rule loading subunit 4061, a serialization processing subunit 4062, and a secure output subunit 4063. The rule loading subunit 4061 is used to load conversion rules from the type registry in the TEE; the serialization processing subunit 4062 is used to serialize the target signal processing request into a format conforming to the target channel protocol according to the conversion rules. For safety-critical signals, serialization is completed in the secure enclave of the TEE; the secure output subunit 4063 is used to output the serialized target signal request from the TEE and transmit it to the adapter of the target channel.

[0093] Furthermore, the serialization unit 406 also includes a priority allocation subunit 4064 and a queue scheduling subunit 4065. The priority allocation subunit 4064 is used to call the scheduling model and assign priorities to the serialized requests based on the vehicle operating status, target signal attributes and channel load status. The queue scheduling subunit 4065 is used to send the requests to the corresponding priority queue and wait for the adapter's processing instructions.

[0094] The receiving unit 408 is used to obtain target return information from the adapter of the target channel in response to the target communication request.

[0095] The receiving unit 408 receives the target return information generated by the signal source response in real time through the communication interface with the target channel adapter, and verifies the integrity of the return information to ensure that the received data is error-free.

[0096] The deserialization unit 410 is used to load the inverse conversion rule, deserialize the target return information into a data format that can respond to the target signal processing function, and send the deserialized target return information to any of the application terminals.

[0097] The deserialization unit 410 can load inverse conversion rules in the TEE, deserialize the target returned information into a data format that the application can process according to the inverse conversion rules, and send the data to the application that initiated the request through the unified application interface after deserialization.

[0098] Furthermore, the device 40 also includes a delay monitoring unit 412, which is used to obtain the timestamps of the target signal processing request and the target return information at each preset node, run a delay supervision program, calculate the delay of each stage and the total end-to-end delay, and trigger an alarm if the delay threshold is exceeded.

[0099] The communication device for multi-protocol signal types in this embodiment corresponds one-to-one with the aforementioned communication method embodiments for multi-protocol signal types. It can realize all the technical solutions in the aforementioned embodiments and has the corresponding technical effects, which will not be repeated here.

[0100] In another embodiment shown in this specification, a vehicle for signal communication based on multiple protocol types is provided, including a communication control device and an adapter for multiple channels connected to the communication control device. Multiple applications of the vehicle are uniformly configured with various signal processing functions. The type registry of the communication control device registers candidate channel types corresponding to various signals, as well as conversion rules and inverse conversion rules corresponding to various signal processing functions. The conversion rules are used to serialize the call request of any signal processing function into a request format conforming to different channel protocols. The inverse conversion rules are used to deserialize the return information of different channel responses into a response format conforming to the response requirements of the signal processing function. The vehicle performs signal communication based on the methods described in the above embodiments.

[0101] Specifically, the vehicle's communication control equipment can achieve functions such as multi-protocol channel adaptation, intelligent routing decision-making, secure signal serialization / deserialization, dynamic priority scheduling, resource prediction, and latency monitoring. The multi-channel adapters include VehicleHalAdapter, TCP / IPAdapter, CanBusAdapter, and 5GV2XAdapter, corresponding to Vehicle HAL, TCP / IP, CAN bus, and 5G-V2X communication channels respectively, enabling transmission adaptation of different protocol signals.

[0102] In summary, the multi-protocol signal communication method, device, and vehicle provided by this invention achieve centralized management of data types by managing signal processing rules through a unified type registry; break the dependence on a single architecture through multi-protocol channel adaptation and intelligent routing decisions; ensure the security of critical signal processing through a TEE trusted security environment; improve the real-time performance and reliability of signal transmission through resource prediction, dynamic scheduling, and latency monitoring; and achieve cross-platform compatibility through a configuration-driven architecture adaptation engine and a general hardware abstraction interface layer. This invention effectively solves many technical defects of existing vehicle signal communication solutions and has significant practical application value and promotional significance.

[0103] The above description is only a preferred embodiment of the present invention. It should be noted that for those skilled in the art, several improvements and refinements can be made without departing from the principle of the present invention, and these improvements and refinements should also be considered within the scope of protection of the present invention.

[0104] What those skilled in the art will understand is: In this specification, the terms "comprising," "including," or any other variations thereof are intended to cover a non-exclusive inclusion, such that a process, method, product, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, product, or apparatus. Without further limitation, the presence of additional identical or equivalent elements in a process, method, product, or apparatus that includes said elements is not excluded.

[0105] In this specification, “a,” “an,” and “the” do not specifically refer to the singular, but may also include the plural.

[0106] In this specification, ordinal numbers such as "first," "second," etc., do not necessarily indicate order; they are often used to distinguish between objects. For example, "first server" and "second server" usually refer to two servers. To differentiate between these two servers, they are described as "first server" and "second server." Of course, sometimes these two servers may be the same server.

[0107] In this specification, unless explicitly stated otherwise, "receiving and sending data" does not necessarily mean direct receiving and sending; it can also mean indirect receiving and sending. For example, A receiving data sent by B can be understood as A directly receiving the data sent by B, or it can be understood as A indirectly receiving the data sent by B through other entities such as C. Similarly, B sending data to A can be understood as B sending the data directly to A, or it can be understood as B indirectly sending the data to A through other entities such as C. Here, C can be one entity, or it can be two or more entities.

[0108] In this specification, unless explicitly stated otherwise, the relationships between structures can be direct or indirect. For example, when describing "A is connected to B," unless it is explicitly stated that A and B are directly connected, it should be understood that A can be directly connected to B or indirectly connected to B. Similarly, when describing "A is on top of B," unless it is explicitly stated that A is directly above B (AB is adjacent and A is above B), it should be understood that A can be directly above B or indirectly above B (AB is separated by other elements, and A is above B). And so on.

[0109] This specification uses specific terms to describe embodiments thereof. For example, "an embodiment" and / or "some embodiments" refer to a particular feature, structure, or characteristic related to at least one embodiment of this specification. Therefore, it should be emphasized and noted that "an embodiment" or "an alternative embodiment" mentioned two or more times in different places in this specification do not necessarily refer to the same embodiment. Furthermore, those skilled in the art can combine and integrate the different embodiments or examples described in this specification, as well as the features of those different embodiments or examples, without contradiction.

[0110] Although one or more embodiments of this specification provide method steps as described in the embodiments or flowcharts, it is understood that the order of steps listed in the embodiments or flowcharts is only one of many possible execution orders and does not represent the only execution order. Therefore, when the claims involve method steps, any changes or adjustments to the order of such steps, or the parallelism between steps, are also within the scope of protection of the claims.

[0111] The above description is merely a preferred embodiment of this specification and is not intended to limit the technical solutions provided herein. Various modifications and variations can be made to the above embodiments by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this specification should be included within the scope of protection of this specification.

Claims

1. A vehicle-mounted communication method for multi-protocol signal types, applied to a vehicle's communication control device, wherein the communication control device is connected to an adapter for the vehicle's multi-protocol channel; multiple applications of the vehicle are uniformly configured with various signal processing functions; the type registry of the communication control device registers candidate channel types corresponding to various signals, as well as conversion rules and inverse conversion rules corresponding to various signal processing functions; the conversion rules are used to serialize the call request of any signal processing function into a request format conforming to different channel protocols; the inverse conversion rules are used to deserialize the return information of different channel responses into a response format conforming to the response requirements of the signal processing function; the method includes: Obtain the target signal processing request initiated by any application terminal of the vehicle by calling the target signal processing function; Based on the transmission requirement characteristics of the target signal and the current state of multiple candidate channels corresponding to the target signal, the target channel corresponding to the target signal is determined; The conversion rule is loaded, the target signal processing request is serialized into a request format that corresponds to the target signal processing function and conforms to the target channel protocol, and the serialized target signal request is transmitted to the adapter of the target channel; Obtain the target return information from the adapter of the target channel in response to the target communication request; Load the inverse conversion rule to deserialize the target return information into a data format that can respond to the target signal processing function; The deserialized target return information is then sent to any of the application terminals.

2. The method according to claim 1, wherein the communication control device is equipped with a trusted security environment; the type registry is stored in the trusted security environment; and loading the conversion rule to serialize the target signal processing request into a request format corresponding to the target signal processing function and conforming to the target channel protocol includes: In the trusted and secure environment, the conversion rule is loaded from the type registry, and the target signal processing request is serialized into a request format that corresponds to the target signal processing function and conforms to the target channel protocol; The target signal request is output in a format converted from the trusted security environment to transmit it to the adapter of the target channel.

3. The method according to claim 1 or 2, wherein the target signal processing function is used to realize the acquisition, setting or subscription functions of the target signal; the multiple channels include different channels based on communication protocols such as Vehicle HAL, TCP / IP, CAN bus and 5G-V2X.

4. The method according to claim 1, wherein the transmission requirement characteristics of the target signal include one or more of the following: the data volume of the target signal, the real-time requirements of the target signal processing request, and the security level of the target signal processing request.

5. The method according to claim 4, wherein the transmission requirement characteristics of the target signal are pre-registered in the communication control device; the communication control device deploys a weighted scoring formula to score the transmissibility of multiple channels; each item included in the weighted scoring formula is used to evaluate the channel's score in terms of bandwidth, load, and security level; The step of determining the target channel corresponding to the target signal based on the transmission demand characteristics of the target signal and the current state of multiple candidate channels available for transmission of the target signal includes: Obtain the transmission requirement characteristics of the pre-registered target signal; Based on the transmission demand characteristics, generate corresponding weights for each item in the weighted scoring rule formula; Based on the current bandwidth, current load status, security level, and weight of each candidate channel, a transmissibility score is calculated for each candidate channel, and the channel with the highest transmissibility score is determined as the target channel corresponding to the target signal.

6. The method according to claim 5, wherein the communication control device further registers load thresholds for multiple channels respectively, the vehicle is configured with a resource prediction model, and before obtaining a target signal processing request initiated by any application terminal of the vehicle calling the target signal processing function, the method further includes: The resource prediction model is invoked at a preset time to obtain the load forecast of the multiple channels in the target future period; If the estimated load of any of the multiple channels exceeds its corresponding preset load threshold, the transmittability score of that channel at the current moment is reduced, so as to reduce the load occupancy of that channel in future time periods.

7. The method according to claim 1, wherein the communication control device further comprises a scheduling model, and the adapter that requests the serialized target signal to be transmitted to the target channel comprises: Based on the vehicle's operating status, the target signal's attributes, and the target channel's load status, the scheduling model is invoked to request the allocation of a corresponding priority for the serialized target signal. The serialized target signal request is sent to the priority queue, awaiting processing instructions from the adapter for transmission to the target channel.

8. The method according to claim 1, wherein the vehicle is further provided with a signal communication delay monitoring program; the method further includes: The timestamps of one or more preset nodes are obtained during the process of the target signal processing request being initiated, serialized, and transmitted to the adapter of the target channel, and the target return information being responded to, returned to the adapter of the target channel, deserialized, and transmitted to any of the applications. Based on the timestamps of the one or more preset nodes, the signal communication delay monitoring program is run to obtain the delay status characteristics of the target signal processing request.

9. A vehicle-mounted communication control device for multi-protocol type signals, applied to a vehicle; the communication control device is connected with an adapter of a multi-protocol type channel of the vehicle; a plurality of application of the vehicle are uniformly configured with a plurality of signal processing functions; a type registry of the communication control device registers a candidate channel type corresponding to a plurality of signals and conversion rules and inverse conversion rules corresponding to a plurality of signal processing functions; the conversion rules are used to serialize a calling request of any signal processing function into a request format conforming to different channel protocols; and the inverse conversion rules are used to deserialize a return information of different channel responses into a response format conforming to a response requirement of the signal processing function; The communication control device includes: The acquisition unit is used to acquire a target signal processing request initiated by any application terminal of the vehicle by calling the target signal processing function; The channel determination unit is used to determine the target channel corresponding to the target signal based on the transmission requirement characteristics of the target signal and the current state of multiple candidate channels corresponding to the target signal. A serialization unit is used to load the conversion rules, serialize the target signal processing request into a request format that corresponds to the target signal processing function and conforms to the target channel protocol, and transmit the serialized target signal request to the adapter of the target channel; A receiving unit is used to obtain target return information from the adapter of the target channel in response to the target communication request; The deserialization unit is used to load the inverse conversion rule, deserialize the target return information into a data format that can respond to the target signal processing function, and send the deserialized target return information to any of the application terminals.

10. A vehicle for multi-protocol signal communication, comprising multiple adapters adapted to channels of different protocol types, and the communication control device as described in claim 9.

Images