Data interaction method and device, computer equipment, readable storage medium and program product
By receiving the pending data in the general communication mode in the vehicle communication system, determining the target electronic control unit and converting it into a proprietary communication mode, the problem that modules can only adapt to non-standardized protocols in the existing system is solved, and unlimited communication between the module and the electronic control unit is achieved.
Patent Information
- Application Number
- CN202411254803.X
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2024-09-09
- Publication Date
- 2025-04-01
AI Technical Summary
In existing in-vehicle communication systems, modules can only adapt to non-standardized protocols and cannot interact with other modules through the intermediate layer, resulting in restrictions on the communication mode that can be applied to the module.
By receiving the pending data in the general communication mode sent by the interactive module, the target electronic control unit is determined, and the proprietary communication mode is determined from its identifiable communication mode, the pending data is converted into data in the proprietary communication mode, and sent to the target electronic control unit for processing through the proprietary communication mode.
It realizes communication between the switching module and the electronic control unit, regardless of the communication mode adapted to the interactive module or the electronic control unit, and avoids the limitation of the communication mode that can be applied to the module.
Smart Images

Figure CN119743524A_ABST
Abstract
Description
Technical Field
[0001] The present application relates to the field of vehicle technology, and in particular to a data interaction method, device, computer equipment, computer-readable storage medium, and computer program product. Background Art
[0002] In the field of in-vehicle communication technology, especially in the middleware communication architecture of in-vehicle electronic systems, the in-vehicle communication middle layer is a bridge for information exchange between various electronic control units (ECUs) inside the vehicle. The middle layer is a software layer located between the ECU and the application layer. The middle layer facilitates information exchange between other devices and the ECU by providing a unified interface and protocol, thereby realizing the overall intelligence and networking of the vehicle.
[0003] In the existing in-vehicle communication system, it is necessary to define a unified standardized communication mode in the middle layer. All modules that exchange data through the middle layer need to follow the standardized communication mode. However, if a module can only adapt to non-standardized protocols, it will not be able to exchange data with other modules through the middle layer. Therefore, the existing solution has imposed restrictions on the communication modes that can be applied to the modules. Summary of the invention
[0004] Based on this, it is necessary to provide a data interaction method, device, computer equipment, computer-readable storage medium and computer program product that can avoid limiting the applicable communication mode of the module in response to the above technical problems.
[0005] In a first aspect, the present application provides a data interaction method, the method comprising:
[0006] Receive the data to be processed in the general communication mode sent by the interaction module;
[0007] determining a target electronic control unit for processing the data to be processed, and determining a proprietary communication mode from identifiable communication modes of the target electronic control unit;
[0008] Converting the data to be processed into first target data in a proprietary communication mode;
[0009] The first target data is sent to the target electronic control unit for processing via the proprietary communication mode.
[0010] In one embodiment, determining the proprietary communication mode from the identifiable communication modes of the target electronic control unit includes:
[0011] determining at least two communication modes recognizable by the electronic control unit;
[0012] Determining data transmission requirements for the data to be processed;
[0013] Based on the data transmission requirement, the dedicated communication mode is determined from the at least two communication modes.
[0014] In one embodiment, converting the data to be processed into first target data in a proprietary communication mode includes:
[0015] Based on the proprietary communication mode, determining a value of a protocol identification field;
[0016] Determine the protocol related fields according to the value of the related identification field;
[0017] Generate a universal protocol code based on the data to be processed, the protocol-related fields and the preset values of the protocol-related fields; the data to be processed includes at least one vehicle operation parameter field and a corresponding value;
[0018] The values of the protocol-related fields in the universal protocol code are loaded into the values of the corresponding fields in the proprietary protocol code, and the values of the vehicle operation parameter fields in the universal protocol code are loaded into the values of the corresponding fields in the proprietary protocol code to obtain the first target data under the proprietary communication mode.
[0019] In one of the embodiments, when the value of the related identification field is a service-oriented communication protocol value, the protocol-related field includes a service identification field and a method identification field;
[0020] The step of loading the value of the protocol-related field in the general protocol code into the value of the corresponding field in the proprietary protocol code includes:
[0021] Loading the value of the service identification field in the universal protocol code into the value of the corresponding service identification field in the proprietary protocol code;
[0022] The value of the method identification field in the general protocol code is loaded into the value of the corresponding method identification field in the proprietary protocol code.
[0023] In one of the embodiments, when the value of the related identification field is a data distribution service protocol value, the protocol-related field includes an entity name field;
[0024] The step of loading the value of the protocol-related field in the general protocol code into the value of the corresponding field in the proprietary protocol code includes:
[0025] The value of the entity name field in the universal protocol code is loaded into the value of the corresponding entity name field in the proprietary protocol code.
[0026] In one embodiment, after sending the first target data to the target electronic control unit for processing through the proprietary communication mode, the method further includes:
[0027] receiving processed data in the proprietary communication mode sent by the target electronic control unit;
[0028] converting the processed data in the proprietary communication mode into the processed data in the universal communication mode;
[0029] determining an electronic control unit for processing the processed data, and determining a target specific communication mode from identifiable communication modes of the electronic control unit;
[0030] The processed data in the universal communication mode is used as the second target data in the target proprietary communication mode; the target proprietary communication mode is different from the proprietary communication mode;
[0031] The second target data is sent to the electronic control unit for processing via the target-specific communication mode.
[0032] In one embodiment, the interaction module includes an external plug-in, and the communication mode recognizable by the external plug-in is different from the proprietary communication mode.
[0033] In a second aspect, the present application further provides a data interaction device, the device comprising:
[0034] A receiving module, used for receiving the data to be processed in the general communication mode sent by the interaction module;
[0035] a determination module, configured to determine a target electronic control unit for processing the data to be processed, and to determine a proprietary communication mode from identifiable communication modes of the target electronic control unit;
[0036] A conversion module, used for converting the data to be processed into first target data in a proprietary communication mode;
[0037] The sending module is used to send the first target data to the target electronic control unit for processing through the proprietary communication mode.
[0038] In a third aspect, the present application further provides a computer device, including a memory and a processor, wherein the memory stores a computer program, and the processor implements the steps of the method of each embodiment when executing the computer program.
[0039] In a fourth aspect, the present application further provides a computer-readable storage medium having a computer program stored thereon, wherein the computer program implements the steps of the method of each embodiment when executed by a processor.
[0040] In a fifth aspect, the present application also provides a computer program product, including a computer program, which implements the steps of the methods of each embodiment when executed by a processor.
[0041] The above-mentioned data interaction method, device, computer equipment, computer-readable storage medium and computer program product can receive the data to be processed in the universal communication mode sent by the interaction module, so that no matter which communication mode the interaction module is adapted to, the universal communication mode can be used to receive the data to be processed. After determining the target electronic control unit for processing the data to be processed, the proprietary communication mode is determined from the identifiable communication modes of the target electronic control unit, and then the data to be processed is converted into the first target data under the proprietary communication mode, that is, the first target data can be converted into the first target data under the proprietary communication mode adapted by the target electronic control unit, so that the first target data can be sent to the target electronic control unit for processing through the proprietary communication mode. Therefore, no matter what communication mode the interaction module or the electronic control unit is adapted to, the present application can realize the communication between the exchange module and the electronic control unit, and will not limit the applicable communication mode of the module. BRIEF DESCRIPTION OF THE DRAWINGS
[0042] In order to more clearly illustrate the technical solutions in the embodiments of the present application or related technologies, the drawings required for use in the embodiments of the present application or related technical descriptions will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present application. For ordinary technicians in this field, other related drawings can be obtained based on these drawings without paying creative work.
[0043] Figure 1 is an architectural diagram of an in-vehicle communication system in one embodiment;
[0044] Figure 2 A schematic diagram of a flow chart of a data interaction method in an embodiment;
[0045] Figure 3 is a flow chart of a data interaction method in another embodiment;
[0046] Figure 4 is a flow chart of a data interaction method in another embodiment;
[0047] Figure 5 A schematic diagram of a scenario for a data interaction method;
[0048] Figure 6 It is another scenario diagram of the data interaction method;
[0049] Figure 7 It is a structural schematic diagram of a data interaction device in another embodiment;
[0050] Figure 8 FIG. 4 is a diagram showing the internal structure of a computer device in one embodiment. DETAILED DESCRIPTION
[0051] In order to make the purpose, technical solution and advantages of the present application more clearly understood, the present application is further described in detail below in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are only used to explain the present application and are not used to limit the present application.
[0052] First, the key terms of this application are explained as follows:
[0053] Reflection: The ability of a program to access, examine, and modify its own state or behavior.
[0054] Dynamic characteristics: The functions of a program are determined at runtime, which is called dynamic characteristics.
[0055] Application layer: Applications and services that users interact directly with.
[0056] ECU: Electronic Control Unit or other service unit.
[0057] Model-driven design: Using the model-driven design approach, developers can design communication protocols in a graphical or declarative way instead of writing code directly.
[0058] The communication mode defines the protocol followed by the data interaction between two devices (or two modules). The general communication mode refers to a communication mode that can support multiple different data interaction protocols (multiple different data interaction protocols include all currently developed data interaction protocols) for communication. The advantage of this general communication mode lies in its flexibility and wide applicability, because it can be compatible with multiple protocols. For example, for interactive devices that only adapt to the SOME / IP protocol, or only adapt to the DDS protocol, or only adapt to other custom protocols for data interaction, since the general communication mode supports the SOME / IP protocol, DDS protocol and other custom protocols at the same time, the following enhancements can all use the general communication mode to interact with the interactive device for data.
[0059] A proprietary communication mode refers to a communication mode that can only support a specific data interaction protocol for communication. For example, a proprietary communication mode only supports the SOME / IP protocol, or only supports the DDS protocol.
[0060] The recognizable communication mode refers to the communication mode corresponding to the data interaction protocol adapted by the electronic control unit. If the electronic control unit adapts one or more data interaction protocols to interact with other devices, then one or more data interaction protocols correspond to one or more communication modes. This one or more communication modes are the recognizable communication modes of the electronic control unit. With the rapid development of the automotive industry towards intelligence, electrification and interconnection, vehicle communication technology is also constantly improving. At present, vehicle communication mainly adopts the service-oriented architecture (SOA) model, which enables ECUs (referring to multiple different ECUs) to communicate and exchange data independently by defining service interfaces. The advantage of SOA architecture lies in its modularity and flexibility, but it also faces some challenges, such as the complexity of service discovery, communication efficiency, and support for different protocol stacks.
[0061] At present, all modules that interact with data in the middle layer need to follow standardized communication modes. Specifically, a model-based protocol stack usually refers to the use of pre-defined models in the communication system to guide the implementation of the communication protocol and the generation of code. This model can be a data model, a communication model, or a behavior model, which defines the format of the data, the rules and processes of communication. Overall working principle:
[0062] Model definition: First, the developer defines the communication model, which may include data structure, communication interface, message type, protocol rules, etc.
[0063] Model-Driven Design (MDD): Using the model-driven design approach, developers can design communication protocols in a graphical or declarative way instead of writing code directly.
[0064] Code generation tools: Based on the defined model, code generation tools are used to automatically generate the code required for communication. These tools are usually integrated with model definition languages (such as UML-Unified Modeling Language) or domain-specific languages (DSL-Domain-Specific Language).
[0065] Protocol stack implementation: The automatically generated code implements each layer of the protocol stack, such as the physical layer, data link layer, network layer, transport layer, session layer, presentation layer, and application layer.
[0066] Configuration and extension: The generated code can be configured and extended as needed to meet specific communication requirements or adapt to different hardware platforms.
[0067] Integration and deployment: The final generated code is integrated into the vehicle system and deployed to the corresponding ECU or communication node.
[0068] The existing solution, model-based protocol stack, provides a standardized communication method for vehicle systems, ensuring compatibility between different manufacturers and different models, but it also brings the following defects:
[0069] Adaptability to new protocols: Model-based protocol stacks usually need to be pre-defined and implemented for each communication protocol, which limits their adaptability to new or non-standard protocols, resulting in the inability of modules to exchange data through the middle layer, thus limiting the applicable communication modes of the modules.
[0070] Scalability issues: As vehicle functionality increases, model-based protocol stacks may be difficult to flexibly expand to adapt to new communication requirements or technological changes.
[0071] Maintenance costs: As the complexity of the protocol stack increases, the cost of maintenance and updates will also increase accordingly, especially in the face of changing market demands and technical standards.
[0072] Insufficient flexibility: For application scenarios that require a high degree of customization or specific optimization, model-based protocol stacks may not provide sufficient flexibility.
[0073] In order to solve the above problems, Figure 1 As shown, the present application provides a data interaction method. This embodiment takes the method applied to the enhancement of the middleware enhancement layer as an example. The middleware enhancement layer is located between the application layer and the middle layer. As a bridge between the existing middleware layer and the application layer, it provides additional abstraction and flexibility to adapt to the ever-changing communication needs and application scenarios. The functional modules of the middleware enhancement layer include a reflection loading interface definition module, a dynamic communication behavior adjustment module, an automatic service discovery and binding module, a dynamic code generation and optimization module, an error handling and debugging module, and a modularization and plug-in support module. Specifically:
[0074] Reflective loading interface definition module: Using the reflection mechanism, the middleware enhancement layer can dynamically load and parse the interface definitions of different ECUs or services to achieve automatic adaptation to different communication protocols and data formats.
[0075] Dynamic communication behavior adjustment module: Through dynamic language features such as dynamic type checking and dynamic code execution, the middleware enhancement layer can adjust its behavior at runtime to adapt to different communication scenarios and performance requirements.
[0076] Automated service discovery and binding module: The middleware enhancement layer can implement automated service discovery and binding mechanisms without manual configuration, thus improving the system's response speed and flexibility.
[0077] Dynamic code generation and optimization module: Based on real-time communication patterns and performance indicators, the middleware enhancement layer can dynamically generate or optimize code to improve communication efficiency and reduce latency.
[0078] Error handling and debugging module: By utilizing reflection and dynamic features, the middleware enhancement layer can provide more detailed error information and debugging support, simplifying problem diagnosis and system maintenance.
[0079] Modularity and plug-in support modules: The middleware enhancement layer supports modularity and plug-in, allowing third-party developers to easily expand system functionality while maintaining the stability of the core system.
[0080] The method comprises the following steps:
[0081] Step 102: receiving the data to be processed in the general communication mode sent by the interaction module;
[0082] In this embodiment, the interaction module may be a module located at the application layer, such as an application program at the application layer, so one scenario of the present application is to involve data interaction between the application layer and the target electronic control unit;
[0083] In this embodiment, the interaction module may also be located in the ECU, so another scenario of the present application is data interaction between the ECU and the target ECU, that is, interaction between two ECUs;
[0084] In this embodiment, the universal communication mode includes a universal communication protocol and a universal communication framework. The enhancement component can interact with the interaction module adapted to any communication protocol (scalable object model over IP (SOME / IP) protocol, data distribution service (DDS) protocol and other custom or emerging protocols) through the universal communication protocol. The universal framework does not depend on a specific communication protocol and can simultaneously support SOME / IP protocol, DDS protocol and other custom or emerging protocols.
[0085] Therefore, in the present application, no matter which communication mode the interaction module is adapted to, the enhancement component can interact with the interaction module in the universal communication mode, thereby receiving the data to be processed sent by the interaction module.
[0086] Step 104, determining a target electronic control unit for processing the data to be processed, and determining a proprietary communication mode from identifiable communication modes of the target electronic control unit;
[0087] A target electronic control unit for processing the data to be processed can be determined from one or more electronic control units. The identifiable communication mode of the target electronic control unit is related to the communication protocol supportable by the target electronic control unit. The target electronic control unit may support the SOME / IP protocol, the DDS protocol, or other custom or emerging protocols.
[0088] The target electronic control unit may have one identifiable communication mode, and the proprietary communication mode is the identifiable communication mode;
[0089] If there are multiple identifiable communication modes for the target electronic control unit, the proprietary communication mode can be determined from the multiple identifiable communication modes.
[0090] Step 106, converting the data to be processed into first target data in a proprietary communication mode;
[0091] Step 108: Send the first target data to the target electronic control unit for processing through a proprietary communication mode.
[0092] The data to be processed is converted into the first target data under the proprietary communication mode, that is, the first target data that conforms to the data format corresponding to the general communication mode is converted into the first target data that conforms to the data format corresponding to the proprietary communication mode, so that the enhancement component sends the first target data to the target electronic control unit for processing through the proprietary communication mode.
[0093] In this embodiment, the data to be processed in the universal communication mode sent by the interaction module can be received, so that no matter which communication mode the interaction module is adapted to, the universal communication mode can be used to receive the data to be processed, and after determining the target electronic control unit for processing the data to be processed, the proprietary communication mode is determined from the identifiable communication modes of the target electronic control unit, and then the data to be processed is converted into the first target data under the proprietary communication mode, that is, the first target data can be converted into the first target data under the proprietary communication mode adapted by the target electronic control unit, so that the first target data can be sent to the target electronic control unit for processing through the proprietary communication mode. Therefore, no matter which communication mode the interaction module or the electronic control unit is adapted to, the present application can realize the communication between the exchange module and the electronic control unit, and will not limit the applicable communication mode of the module.
[0094] In one embodiment, determining the proprietary communication mode from the identifiable communication modes of the target electronic control unit includes: determining at least two identifiable communication modes of the electronic control unit; detecting a vehicle operation scenario to determine a data transmission requirement for the data to be processed; and determining the proprietary communication mode from the at least two communication modes based on the data transmission requirement.
[0095] In this embodiment, the data transmission requirements of the data to be processed include the requirements for transmitting data of a small data volume and the requirements for transmitting real-time reliable data.
[0096] There are several situations in which communication modes can be identified for the target ECU:
[0097] When there is a need to transmit a small amount of data, such as when transmitting control instructions, the SOME / IP protocol can be selected after identification through the communication configuration parameters because it is simple and responsive.
[0098] When there is a need to transmit real-time reliable data, such as transmission speed and steering wheel angle, the DDS protocol can be selected after identification through communication configuration parameters, because DDS provides a quality of service strategy that supports efficient data distribution and real-time performance.
[0099] Situation where there is only one identifiable communication mode for the target ECU:
[0100] When the communication protocol of the target ECU is static, such as the target ECU only supports the lightweight protocol SOME / IP, select the SOME / IP protocol for communication.
[0101] In this embodiment, a more suitable communication mode can be selected based on the data transmission requirements of the data to be processed, so that the selection of the communication mode is more reasonable.
[0102] In one of the embodiments, the data to be processed is converted into the first target data under the proprietary communication mode, including: determining the value of the protocol identification field based on the proprietary communication mode; determining the protocol-related field according to the value of the relevant identification field; generating a general protocol code based on the data to be processed, the protocol-related field and the preset value of the protocol-related field; the data to be processed includes at least one vehicle operating parameter field and the corresponding value; loading the value of the protocol-related field in the general protocol code into the value of the corresponding field in the proprietary protocol code, and loading the value of the vehicle operating parameter field in the general protocol code into the value of the corresponding field in the proprietary protocol code, to obtain the first target data under the proprietary communication mode.
[0103] In this embodiment, the value of the protocol identification field is different for different proprietary communication modes. For example, when the proprietary communication mode is the SOME / IP protocol, the value of the protocol identification field is 1; when the proprietary communication mode is the DDS protocol, the value of the protocol identification field is 2; when the proprietary communication mode is the universal communication mode, the value of the protocol identification field is 3.
[0104] When the proprietary communication mode is the SOME / IP protocol, the determined protocol-related fields are the service identification (service-id) field and the method identification (method-id) field; when the proprietary communication mode is the DDS protocol, the determined protocol-related field is the entity name field.
[0105] The general protocol code may be generated based on the protocol identification field, the value of the protocol identification field, the data to be processed, the protocol related fields, and the preset values of the protocol related fields.
[0106] The data to be processed may be at least one vehicle operation parameter field and a corresponding value, wherein the vehicle operation parameter field includes speed (speed), fuel level (fuelLevel) and engine temperature (engineTemperature);
[0107] The values of the protocol-related fields in the general protocol code are loaded into the values of the corresponding protocol-related fields in the proprietary protocol code. The data types of the protocol-related fields are defined in the proprietary protocol code. At the same time, the values of the vehicle operating parameter fields in the general protocol code are loaded into the values of the corresponding vehicle operating parameter fields in the proprietary protocol code. The data type of the vehicle operating parameter fields is also defined in the proprietary protocol code, thereby realizing the conversion of the data to be processed into the first target data under the proprietary communication mode.
[0108] This embodiment provides a specific method for mapping a general protocol code to a proprietary protocol code, so that the data to be processed in the general communication mode can be converted into the target data in the proprietary communication mode, realizing data format conversion to conform to the data format defined by the proprietary communication mode, thereby sending the first target data to the target electronic control unit for processing through the proprietary communication mode, realizing data interaction between the interactive module and the target ECU without limiting the communication mode adapted to the interactive module or the target ECU.
[0109] Specifically, for different proprietary communication modes, the communication protocols and communication frameworks are different. When converting data in the universal communication mode into data in the proprietary communication mode, this application is mainly divided into two steps: protocol conversion and process conversion.
[0110] like Figure 3 As shown, protocol conversion: the application layer uses a general communication protocol to replace a proprietary communication protocol; process conversion: the application layer uses a general communication framework to replace a proprietary communication framework.
[0111] Reference Figure 4 , the protocol conversion process is as follows:
[0112] Universal protocol interface: Regardless of which communication protocol the application layer module is adapted to, the middleware enhancement layer can interact with the application layer through the universal protocol interface;
[0113] Dynamic protocol identification and loading: Use the reflection mechanism to dynamically identify and load different proprietary communication protocols; perform a bilateral protocol handshake in the dynamic protocol identifier and feed the handshake result back to the protocol converter.
[0114] Proprietary communication protocol library: The proprietary communication protocol library includes a variety of proprietary communication protocols;
[0115] Protocol converter: can convert data under general communication protocols into data under proprietary communication protocols;
[0116] The final conversion is to obtain data under proprietary communication protocols such as SOME / IP or DDS.
[0117] Communication protocol conversion has the following effects:
[0118] Reduced coupling: The coupling between system components is reduced because they are decoupled from specific communication protocols through middleware;
[0119] Improved flexibility: The system can quickly adapt to new or changing communication requirements without requiring large-scale reconfiguration;
[0120] Simplified upgrade process: Adding or updating communication protocols becomes easier because these changes can be implemented locally in the middleware.
[0121] The communication framework conversion process also refers to Figure 4 ,Among them, the protocol converter can also convert the data under the ,universal communication framework into the data under the ,proprietary communication framework;
[0122] Communication framework adapter: Provides adapters for different communication frameworks, allowing enhancements to dynamically adjust the communication framework based on different application scenarios and requirements.
[0123] Intelligent process optimization: The enhancements not only convert protocols, but also intelligently optimize the communication framework based on the contextual information of the communication, thereby improving efficiency and responsiveness.
[0124] User-defined communication framework: allows developers or users to customize the communication framework according to specific needs, and the enhancements can flexibly adapt to these customized communication frameworks.
[0125] Communication frame conversion also has the following effects:
[0126] Multi-protocol support: The universal communication framework does not rely on a specific communication protocol and can support SOME / IP, DDS and other custom or emerging communication protocols at the same time. The universal communication framework provides predefined rules and automation mechanisms to achieve seamless conversion between different protocols, such as automatically matching the header fields of SOME / IP, DDS and other protocols.
[0127] Intelligent process optimization:
[0128] The universal communication framework has intelligent optimization capabilities and can dynamically select the most appropriate communication protocol based on factors such as communication destination, data type, and service quality requirements.
[0129] In addition, the general communication framework can also optimize the data structure and convert the general dynamic data structure into a static data structure, thereby simplifying the serialization and deserialization process and improving data transmission efficiency.
[0130] Simplify development and maintenance:
[0131] Developers can use the general communication framework to focus on the development of business logic without having to delve into the specific details of the underlying communication protocol. This not only improves development efficiency, but also reduces the complexity and cost of system maintenance.
[0132] The following describes the specific implementation of converting data under the general communication protocol into data under the SOME / IP protocol or data under the DDS protocol:
[0133] In one of the embodiments, when the value of the relevant identification field is a service-oriented communication protocol value, the protocol-related fields include a service identification field and a method identification field; loading the values of the protocol-related fields in the universal protocol code into the values of the corresponding fields in the proprietary protocol code includes: loading the value of the service identification field in the universal protocol code into the value of the corresponding service identification field in the proprietary protocol code; loading the value of the method identification field in the universal protocol code into the value of the corresponding method identification field in the proprietary protocol code.
[0134] Taking the general protocol interface (JSON) as an example, after dynamic protocol identification and loading, real-time protocol conversion is achieved:
[0135] The general protocol code includes a protocol identification field protocol, which can take different values, and different values represent different protocols. For example, the value of the protocol identification field is 1, 2, or 3, 1 represents the SOME / IP protocol, 2 represents the DDS protocol, and 3 represents the general protocol; the initial general protocol code includes a main identification (main_id) field and a sub-identification (sub_id) field. Based on different values of protocol, the main identification field and the sub-identification field can be changed to protocol-related fields;
[0136] For example, the above-mentioned general protocol code also includes data to be processed;
[0137] The proprietary protocol code includes protocol-related fields and defines the data types of the protocol-related fields;
[0138] The proprietary protocol code also includes a vehicle operation parameter field and defines the data type of the protocol-related fields.
[0139] For different proprietary communication modes, the communication protocol framework is different, specifically:
[0140] The main identification field and sub-identification field in the general protocol code can be modified to the protocol-related fields of the corresponding protocol. For example, when the value of protocol is 1, the main_id field is modified to the service identification (service_id) field in the SOME / IP protocol definition, and the sub_id field is modified to the method identification (method_id) field in the SOME / IP protocol definition.
[0141] For different proprietary communication modes, the communication protocol is different: when the proprietary communication protocol is some / ip protocol, protocol is set to 1, the service_id field in the general protocol code is loaded into the service_id field of the proprietary protocol code, and the method_id field of the general protocol code is loaded into the method_id field of the proprietary protocol code for matching the protocol header; after that, the reflection mechanism is used to dynamically load the data to be processed, which does not need to be implemented manually, and the subsequent fields such as speed and engineTemperature are loaded into the vehicle operation parameter field under the structure (struct) of the proprietary protocol code, and then loaded into the SOME / IP payload (someip_payload). When loading the fuel level (fuelLevel) field, no value is assigned because the someip protocol segment does not have this part defined.
[0142] In one of the embodiments, when the value of the relevant identification field is a data distribution service protocol value, the protocol-related fields include an entity name field; loading the value of the protocol-related fields in the universal protocol code into the value of the corresponding field in the proprietary protocol code includes: loading the value of the entity name field in the universal protocol code into the value of the corresponding entity name field in the proprietary protocol code.
[0143] For different proprietary communication modes, the communication protocol framework is different: The main identification field and sub-identification field in the general protocol code can be modified to the protocol-related fields of the corresponding protocol. For example, when the value of protocol is 2, the main_id field and sub_id field are modified to the entity name field defined by the DDS protocol. The entity name field can be the TOPC name field;
[0144] The communication protocol is different for different proprietary communication modes: when the proprietary communication protocol is the DDS protocol, protocol is set to 2, and the TOPC name field in the general protocol code is loaded into the TOPC name field of the proprietary protocol code for matching the protocol header; thereafter, the reflection mechanism is used to dynamically load the data to be processed. This part does not need to be implemented manually, and the subsequent fields such as speed, engineTemperature, and fuelLevel are loaded into the vehicle operation parameter field under the structure (struct) of the proprietary protocol code.
[0145] It can be seen that the above-mentioned communication protocols and communication frameworks are different for different proprietary communication modes. Therefore, based on the corresponding communication protocols and communication frameworks, the data to be processed in the general communication mode can be converted into the target data in the proprietary communication mode, thereby realizing data format conversion to conform to the data format defined by the proprietary communication mode, thereby sending the first target data to the target electronic control unit for processing through the proprietary communication mode, thereby realizing data interaction between the interaction module and the target ECU without limiting the communication mode adapted to the interaction module or the target ECU.
[0146] The data to be processed may need to be processed jointly by the target ECU and other ECUs, that is, after the target ECU completes the processing, the processed data needs to be sent to other ECUs for further processing. When the communication modes adapted to the target ECU and other ECUs are different, in one embodiment, after the first target data is sent to the target electronic control unit for processing through a proprietary communication mode, the method also includes: receiving the processed data under the proprietary communication mode sent by the target electronic control unit; converting the processed data under the proprietary communication mode into processed data under the universal communication mode; determining the electronic control unit for processing the processed data, and determining the target proprietary communication mode from the identifiable communication modes of the electronic control unit; converting the processed data under the universal communication mode into the second target data under the target proprietary communication mode; the target proprietary communication mode is different from the proprietary communication mode; and sending the second target data to the electronic control unit for processing through the target proprietary communication mode.
[0147] After receiving the processed data in the proprietary communication mode sent by the target ECU through the proprietary communication mode, the enhanced component first converts the processed data in the proprietary communication mode into the processed data in the universal communication mode, and then realizes the above Figure 1 The specific implementation of the illustrated embodiment is similar, and the processed data under the universal communication mode is converted into second target data under the target-specific communication mode, thereby sending the second target data to the electronic control unit for processing through the target-specific communication mode. In this way, for the case where the communication modes adapted to the target ECU and other ECUs are different, it is possible to achieve the common processing of the data to be processed by multiple ECUs in this way without restricting the adaptable communication protocols of multiple ECUs.
[0148] In this embodiment, the innovation of the communication protocol conversion is that it can provide a mechanism to enable the enhancement component to understand and convert different communication protocols without the need for large-scale modification or recompilation of the existing system, which greatly enhances the compatibility and flexibility of the system.
[0149] The innovation of communication frame conversion is that it allows the enhancement to dynamically adjust its communication frame according to communication needs and context, which not only improves communication efficiency, but also allows more advanced communication modes and intelligently optimizes the process.
[0150] In summary, this application has the following effects:
[0151] Improve adaptability: Regardless of the communication mode that the application layer module is adapted to, through this application solution, the interactive module can interact with the ECU, enabling the communication system to quickly adapt to new communication protocols and technical standards, reducing the complexity of system upgrades and maintenance.
[0152] Enhanced scalability: The protocol conversion mechanism allows the system to easily integrate new communication protocols, thereby improving the scalability of the system. As the functions of the vehicle system increase, the middleware can quickly adapt and support new communication requirements without large-scale modifications to the entire system architecture.
[0153] Reduce maintenance costs: Since the middleware provides an abstraction layer (middleware enhancement layer) that separates the specific implementation of the communication protocol from the application logic, it simplifies system maintenance and updates. Developers can independently update or replace the protocol conversion logic without affecting other system components, thereby reducing maintenance costs.
[0154] The following is an example of scenarios in which this application can be applied:
[0155] Scenario 1:
[0156] In communication systems, debugging and diagnosing communication problems is a complex process, especially when the system involves multiple ECUs and multiple communication protocols. Existing debugging tools are generally based on a certain application software sniffing data and echoing it, which usually lacks flexibility and automation, making the debugging process time-consuming and error-prone.
[0157] The debugging module of the present application provides a comprehensive set of debugging tools for monitoring, analyzing and optimizing the performance of the vehicle communication system.
[0158] The debugging module includes the following key functions:
[0159] 1. Data shows:
[0160] The reflection characteristics are used to read data definitions and values in real time and display data debugging information.
[0161] Provides real-time data display function, capable of displaying communication data flow and status information between multiple ECUs.
[0162] Supports multiple data views, including charts, lists, and graphical interfaces to meet different analysis needs.
[0163] 2. Data transmission:
[0164] Allows users to manually send customized data packets or signals to test the system's response and processing capabilities.
[0165] Supports simulation of different communication scenarios and failure modes to evaluate the robustness of the system.
[0166] 3. Recording:
[0167] Implement the communication data recording function, allowing users to capture communication data over a period of time for subsequent analysis.
[0168] Provides efficient data storage mechanism to ensure that large amounts of data are captured without loss of information.
[0169] 4. Recharge:
[0170] Allows users to inject recorded data back into the system to test the system's exception handling and data consistency.
[0171] Supports data re-injection under different conditions, such as different network delays or data loss rates.
[0172] 5. Automated Testing:
[0173] By using reflection and dynamic features, the debugging module can automatically generate test scripts and perform automated communication tests.
[0174] Dynamically adjust test strategies based on predefined test cases or real-time monitored communication patterns.
[0175] 6. Error detection and diagnosis:
[0176] Provides advanced error detection and diagnostic capabilities to quickly locate communication problems and provide possible solutions. Using dynamic language features, the debugging module can adapt to different communication protocols and data structures.
[0177] The vehicle communication protocol module interacts with the middleware layer through a proprietary communication protocol (SOME / IP, DDS or vehicle communication protocol stack) to communicate with the framework code, which is processed by the middleware enhancement layer and converted into a general data structure and a general communication framework bottom software by the data conversion module. The data conversion module applies a reflection mechanism and then adjusts the communication behavior according to dynamic interactive instructions. The general data structure and the general communication framework bottom software are converted into data structures and proprietary communication frameworks under the proprietary communication protocol adapted by the middleware layer. The peer ECUs also adapt to the proprietary communication protocol and the proprietary communication framework, so that the middle layer sends data to the peer ECUs for processing through the communication protocol and the proprietary communication framework.
[0178] By implementing the debugging module of this application, developers and maintainers of vehicle communication systems will be able to perform debugging and diagnosis work more efficiently and accurately. This will significantly improve the reliability and performance of the system while reducing maintenance costs and time.
[0179] By implementing this debugging module, developers and maintainers of vehicle communication systems will be able to perform debugging and diagnosis work more efficiently and accurately, significantly improving system reliability and performance while reducing maintenance costs and time.
[0180] Scenario 2: With the rapid development of vehicle systems, new communication protocols and technologies continue to emerge, while existing systems may still use old communication protocols. This coexistence of new and old protocols leads to compatibility issues, making it difficult for newly developed plug-in application modules to run in old systems, or requiring a lot of adaptation work.
[0181] In one of the embodiments of the present application, the interaction module includes an external plug-in, and the communication mode recognizable by the external plug-in is different from the proprietary communication mode.
[0182] The plug-in application module of this application realizes protocol conversion through the middleware enhancement layer, and converts the data sent by the plug-in adapted to the new protocol into data under the old protocol adapted by the system after being processed by the middleware enhancement layer, thereby ensuring seamless communication between the new version of the communication protocol and the old version of the communication protocol. The solution includes the following key components:
[0183] Protocol abstraction layer: A protocol abstraction layer is set up in the middleware enhancement layer to define a unified communication interface so that upper-layer applications do not need to worry about the specific implementation of the underlying communication protocol.
[0184] Plug-in registration mechanism: Design a plug-in registration mechanism to allow newly developed plug-in application modules to register their communication requirements and interfaces in the system.
[0185] Dynamic protocol identification: The middleware enhancement layer has the ability to dynamically identify the plug-in communication protocol. Whether it is a new version of the communication protocol or an old version of the communication protocol, it can be identified and processed by the system.
[0186] Protocol converter: Based on the identified communication protocol, the protocol converter in the middleware enhancement layer is responsible for converting the data format and communication process between the new version of the communication protocol and the old version of the communication protocol to ensure compatibility.
[0187] Plug-in interface adapter: Provide an interface adapter for each plug-in application module, which is responsible for interacting with the protocol converter to ensure that the plug-in data can be sent and received in the correct format.
[0188] Configuration Manager: Implement a configuration manager to manage the communication configuration of different plug-ins, including protocol type, data format, and communication parameters.
[0189] Compatibility testing tools: Provides a set of compatibility testing tools to verify the communication compatibility and performance of new plug-ins in old systems.
[0190] The new version of the communication protocol application sends the data of the new version of the general data structure to the middleware enhancement layer. The middleware enhancement layer performs a compatibility test. If it is found that the system applies the old version of the communication protocol, the data of the general data structure is sent to the protocol converter through the interface adapter. The data of the general data structure is converted into the data of the old version of the data structure through the protocol converter, and then sent to the peer ECUS for processing through the middleware layer.
[0191] By implementing the plug-in application module compatibility solution of this application, developers of vehicle-mounted systems can easily integrate newly developed plug-ins without worrying about compatibility issues between the new version of the communication protocol and the old version of the communication protocol. This will speed up the development and deployment of new functions and improve the scalability and maintainability of the system.
[0192] It should be understood that, although the various steps in the flowcharts involved in the above-mentioned embodiments are displayed in sequence according to the indication of the arrows, these steps are not necessarily executed in sequence according to the order indicated by the arrows. Unless there is a clear explanation in this article, the execution of these steps does not have a strict order restriction, and these steps can be executed in other orders. Moreover, at least a part of the steps in the flowcharts involved in the above-mentioned embodiments can include multiple steps or multiple stages, and these steps or stages are not necessarily executed at the same time, but can be executed at different times, and the execution order of these steps or stages is not necessarily to be carried out in sequence, but can be executed in turn or alternately with other steps or at least a part of the steps or stages in other steps.
[0193] Based on the same inventive concept, the embodiment of the present application also provides a data interaction device for implementing the data interaction method involved above. The implementation scheme for solving the problem provided by the device is similar to the implementation scheme recorded in the above method, so the specific limitations in one or more data interaction device embodiments provided below can refer to the limitations on the data interaction method above, and will not be repeated here.
[0194] In an exemplary embodiment, Figure 7 As shown, a data interaction device 700 is provided, including:
[0195] The receiving module 701 is used to receive the data to be processed in the general communication mode sent by the interaction module;
[0196] A determination module 702 is used to determine a target electronic control unit for processing the data to be processed, and to determine a proprietary communication mode from identifiable communication modes of the target electronic control unit;
[0197] A conversion module 703, used for converting the data to be processed into first target data in a proprietary communication mode;
[0198] The sending module 704 is used to send the first target data to the target electronic control unit for processing through the proprietary communication mode.
[0199] In one embodiment, when determining the proprietary communication mode from the identifiable communication modes of the target electronic control unit, the determination module 702 is specifically configured to:
[0200] determining at least two communication modes recognizable by the electronic control unit;
[0201] Determining data transmission requirements for the data to be processed;
[0202] Based on the data transmission requirement, the dedicated communication mode is determined from the at least two communication modes.
[0203] In one embodiment, the conversion module 703 is specifically configured to:
[0204] Based on the proprietary communication mode, determining a value of a protocol identification field;
[0205] Determine the protocol related fields according to the value of the related identification field;
[0206] Generate a universal protocol code based on the data to be processed, the protocol-related fields and the preset values of the protocol-related fields; the data to be processed includes at least one vehicle operation parameter field and a corresponding value;
[0207] The values of the protocol-related fields in the universal protocol code are loaded into the values of the corresponding fields in the proprietary protocol code, and the values of the vehicle operation parameter fields in the universal protocol code are loaded into the values of the corresponding fields in the proprietary protocol code to obtain the first target data under the proprietary communication mode.
[0208] In one of the embodiments, when the value of the related identification field is a service-oriented communication protocol value, the protocol-related field includes a service identification field and a method identification field;
[0209] When the conversion module 703 loads the value of the protocol-related field in the general protocol code into the value of the corresponding field in the proprietary protocol code, it is specifically used to:
[0210] Loading the value of the service identification field in the universal protocol code into the value of the corresponding service identification field in the proprietary protocol code;
[0211] The value of the method identification field in the general protocol code is loaded into the value of the corresponding method identification field in the proprietary protocol code.
[0212] In one of the embodiments, when the value of the related identification field is a data distribution service protocol value, the protocol-related field includes an entity name field;
[0213] When the conversion module 703 loads the value of the protocol-related field in the general protocol code into the value of the corresponding field in the proprietary protocol code, it is specifically used to:
[0214] The value of the entity name field in the universal protocol code is loaded into the value of the corresponding entity name field in the proprietary protocol code.
[0215] In one embodiment, the device further includes a control unit interaction module, after the sending module 704 sends the first target data to the target electronic control unit for processing through the proprietary communication mode, the control unit interaction module is used to:
[0216] receiving processed data in the proprietary communication mode sent by the target electronic control unit;
[0217] converting the processed data in the proprietary communication mode into the processed data in the universal communication mode;
[0218] determining an electronic control unit for processing the processed data, and determining a target specific communication mode from identifiable communication modes of the electronic control unit;
[0219] The processed data in the universal communication mode is used as the second target data in the target proprietary communication mode; the target proprietary communication mode is different from the proprietary communication mode;
[0220] The second target data is sent to the electronic control unit for processing via the target-specific communication mode.
[0221] In one embodiment, the interaction module includes an external plug-in, and the communication mode recognizable by the external plug-in is different from the proprietary communication mode.
[0222] Each module in the above data interaction device can be implemented in whole or in part by software, hardware, or a combination thereof. Each module can be embedded in or independent of a processor in a computer device in the form of hardware, or can be stored in a memory in a computer device in the form of software, so that the processor can call and execute operations corresponding to each module.
[0223] In an exemplary embodiment, a computer device is provided. The computer device may be a terminal, and its internal structure diagram may be as shown in FIG. Figure 8As shown. The computer device includes a processor, a memory, an input / output interface, a communication interface, a display unit and an input device. The processor, the memory and the input / output interface are connected through a system bus, and the communication interface, the display unit and the input device are connected to the system bus through the input / output interface. The processor of the computer device is used to provide computing and control capabilities. The memory of the computer device includes a non-volatile storage medium and an internal memory. The non-volatile storage medium stores an operating system and a computer program. The internal memory provides an environment for the operation of the operating system and the computer program in the non-volatile storage medium. The input / output interface of the computer device is used to exchange information between the processor and an external device. The communication interface of the computer device is used to communicate with an external terminal in a wired or wireless manner, and the wireless manner can be implemented through WIFI, a mobile cellular network, near field communication (NFC) or other technologies. When the computer program is executed by the processor, a data interaction method is implemented. The display unit of the computer device is used to form a visually visible picture, which can be a display screen, a projection device or a virtual reality imaging device. The display screen can be a liquid crystal display screen or an electronic ink display screen, and the input device of the computer device can be a touch layer covering the display screen, or a button, trackball or touchpad set on the computer device shell, or an external keyboard, touchpad or mouse.
[0224] Those skilled in the art will understand that Figure 8 The structure shown in the figure is only a block diagram of a part of the structure related to the solution of the present application, and does not constitute a limitation on the computer device to which the solution of the present application is applied. The specific computer device may include more or fewer components than those shown in the figure, or combine certain components, or have a different arrangement of components.
[0225] In an exemplary embodiment, a computer device is provided, including a memory and a processor, wherein a computer program is stored in the memory, and the processor implements the steps in the above-mentioned method embodiments when executing the computer program.
[0226] In one embodiment, a computer-readable storage medium is provided, on which a computer program is stored. When the computer program is executed by a processor, the steps in the above-mentioned method embodiments are implemented.
[0227] In one embodiment, a computer program product is provided, including a computer program, which implements the steps in the above method embodiments when executed by a processor.
[0228] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, stored data, displayed data, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties, and the collection, use and processing of relevant data must comply with relevant regulations.
[0229] A person of ordinary skill in the art can understand that all or part of the processes in the above-mentioned embodiment method can be completed by instructing the relevant hardware through a computer program, and the computer program can be stored in a non-volatile computer-readable storage medium. When the computer program is executed, it can include the processes of the embodiments of the above-mentioned methods. Among them, any reference to the memory, database or other medium used in the embodiments provided in the present application can include at least one of non-volatile memory and volatile memory. Non-volatile memory can include read-only memory (ROM), magnetic tape, floppy disk, flash memory, optical memory, high-density embedded non-volatile memory, resistive random access memory (ReRAM), magnetic random access memory (MRAM), ferroelectric random access memory (FRAM), phase change memory (PCM), graphene memory, etc. Volatile memory can include random access memory (RAM) or external cache memory, etc. As an illustration and not limitation, RAM can be in various forms, such as static random access memory (SRAM) or dynamic random access memory (DRAM). The database involved in each embodiment provided in this application may include at least one of a relational database and a non-relational database. Non-relational databases may include distributed databases based on blockchains, etc., but are not limited to this. The processor involved in each embodiment provided in this application may be a general-purpose processor, a central processing unit, a graphics processor, a digital signal processor, a programmable logic device, a data processing logic device based on quantum computing, an artificial intelligence (AI) processor, etc., but are not limited to this.
[0230] The technical features of the above embodiments may be combined arbitrarily. To make the description concise, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this application.
[0231] The above-described embodiments only express several implementation methods of the present application, and the descriptions thereof are relatively specific and detailed, but they cannot be understood as limiting the scope of the present application. It should be pointed out that, for a person of ordinary skill in the art, several variations and improvements can be made without departing from the concept of the present application, and these all belong to the protection scope of the present application. Therefore, the protection scope of the present application shall be subject to the attached claims.
Claims
1. A data interaction method, characterized in that: The method comprises: Receive the data to be processed in the general communication mode sent by the interaction module; determining a target electronic control unit for processing the data to be processed, and determining a proprietary communication mode from identifiable communication modes of the target electronic control unit; Converting the data to be processed into first target data in a proprietary communication mode; The first target data is sent to the target electronic control unit for processing via the proprietary communication mode.
2. The method according to claim 1, characterized in that: The determining of the proprietary communication mode from the identifiable communication modes of the target electronic control unit comprises: determining at least two communication modes recognizable by the electronic control unit; Determining data transmission requirements of the data to be processed; Based on the data transmission requirement, the dedicated communication mode is determined from the at least two communication modes.
3. The method according to claim 1 or 2, characterized in that: The converting the to-be-processed data into first target data in a proprietary communication mode comprises: Based on the proprietary communication mode, determining a value of a protocol identification field; Determine the protocol related fields according to the value of the related identification field; Generate a universal protocol code based on the data to be processed, the protocol-related fields and the preset values of the protocol-related fields; the data to be processed includes at least one vehicle operation parameter field and a corresponding value; The values of the protocol-related fields in the universal protocol code are loaded into the values of the corresponding fields in the proprietary protocol code, and the values of the vehicle operation parameter fields in the universal protocol code are loaded into the values of the corresponding fields in the proprietary protocol code to obtain the first target data under the proprietary communication mode.
4. The method according to claim 3, characterized in that: In the case where the value of the related identification field is a service-oriented communication protocol value, the protocol-related field includes a service identification field and a method identification field; The step of loading the value of the protocol-related field in the general protocol code into the value of the corresponding field in the proprietary protocol code includes: Loading the value of the service identification field in the universal protocol code into the value of the corresponding service identification field in the proprietary protocol code; The value of the method identification field in the general protocol code is loaded into the value of the corresponding method identification field in the proprietary protocol code.
5. The method according to claim 4, characterized in that In the case where the value of the relevant identification field is a data distribution service protocol value, the protocol-related field includes an entity name field; The step of loading the value of the protocol-related field in the general protocol code into the value of the corresponding field in the proprietary protocol code includes: The value of the entity name field in the universal protocol code is loaded into the value of the corresponding entity name field in the proprietary protocol code.
6. The method according to any one of claims 1 to 5, characterized in that After sending the first target data to the target electronic control unit for processing through the proprietary communication mode, the method further includes: receiving processed data in the proprietary communication mode sent by the target electronic control unit; converting the processed data in the proprietary communication mode into the processed data in the universal communication mode; determining an electronic control unit for processing the processed data, and determining a target specific communication mode from identifiable communication modes of the electronic control unit; The processed data in the universal communication mode is used as the second target data in the target proprietary communication mode; the target proprietary communication mode is different from the proprietary communication mode; The second target data is sent to the electronic control unit for processing via the target-specific communication mode.
7. The method according to any one of claims 1 to 5, characterized in that The interaction module includes an external plug-in, and the communication mode recognizable by the external plug-in is different from the proprietary communication mode.
8. A data interaction device, characterized in that: The device comprises: A receiving module, used for receiving the data to be processed in the general communication mode sent by the interaction module; a determination module, configured to determine a target electronic control unit for processing the data to be processed, and to determine a proprietary communication mode from identifiable communication modes of the target electronic control unit; A conversion module, used for converting the data to be processed into first target data in a proprietary communication mode; The sending module is used to send the first target data to the target electronic control unit for processing through the proprietary communication mode.
9. A computer device comprising a memory and a processor, wherein the memory stores a computer program, wherein: When the processor executes the computer program, the steps of the method according to any one of claims 1 to 7 are implemented.
10. A computer-readable storage medium having a computer program stored thereon, characterized in that: When the computer program is executed by a processor, the steps of the method according to any one of claims 1 to 7 are implemented.
11. A computer program product, comprising a computer program, characterized in that When the computer program is executed by a processor, the steps of the method according to any one of claims 1 to 7 are implemented.