Multi-protocol intelligent cockpit interconnection integrated system

Abstract

The invention discloses a multi-protocol intelligent cockpit interconnection integrated system, which relates to the field of communication compatibility, and comprises the following steps: S1, a hardware interface module of a universal interconnection interface layer receives an access request of a mobile phone, and establishes communication connection between the mobile phone and a vehicle machine; original data transmitted by the mobile phone is subjected to standardized primary processing through a unified data transmission protocol of the software interface module; s2, a dynamic identification module of the protocol adapter layer adopts a feature code scanning technology to identify the type of an interconnection protocol accessed to a mobile phone within 100ms; the type of the interconnection protocol comprises a CarPlay, an Android Auto, a HiCar and a CarLink; calling a protocol conversion engine to carry out adaptation aiming at different protocols, and converting data in a mobile phone protocol format into data in a system general data format; and S3, a resource scheduler of the central control layer adopts a DWRR dynamic weighted polling algorithm to dynamically allocate CPU and memory resources of the vehicle machine according to the protocol type identified in the step S2 and the current service scene.

Description

Technical Field

[0001] This application relates to the field of communication compatibility, and in particular to multi-protocol smart cockpit interconnection integration systems, multi-protocol smart cockpit interconnection protocol adaptation methods, electronic devices, storage media, and vehicles. Background Technology

[0002] Currently, the main protocols used in the field of smart cockpit mobile phone-vehicle connectivity include Apple CarPlay, Google Android Auto, Huawei HiCar, and ICCOA Alliance CarLink. Existing technologies suffer from the following pain points:

[0003] High development costs: Each protocol requires independent development of an adaptation module. For example, when a car company develops a dual-protocol solution for CarPlay and Android Auto, it needs to invest in two development teams, extending the development cycle to 6 months and increasing costs by 40%.

[0004] Compatibility issues are prominent: the underlying architectures of different protocols differ greatly. For example, CarPlay is based on the iOS ecosystem, while Android Auto relies on Google services, which makes it easy for communication interruptions to occur when the vehicle system switches protocols. A test of a certain model showed that the protocol switching success rate was only 82%.

[0005] High maintenance difficulty: The versions of various protocols are updated frequently (e.g., CarPlay is updated 2-3 times a year), and each update requires separate debugging. One manufacturer caused 100,000 vehicle infotainment systems to experience black screen failures because it failed to adapt to the new CarPlay protocol in time.

[0006] Serious waste of resources: Independent protocol modules occupy more than 30% of the vehicle's CPU resources. A certain model of vehicle system experienced a 25% increase in navigation lag due to the simultaneous running of multiple protocol background processes.

[0007] Therefore, a solution for multi-protocol intelligent cockpit interconnection, integration, and adaptation is needed to solve the problem of wasted human resources caused by independent development of multiple protocols; overcome the problem of insufficient system stability caused by poor compatibility of different protocols; eliminate the problem of low maintenance efficiency caused by frequent protocol iterations; and optimize the problem of vehicle system performance loss caused by excessive resource consumption. Summary of the Invention

[0008] The purpose of this invention is to provide a multi-protocol intelligent cockpit interconnection integration system, a multi-protocol intelligent cockpit interconnection protocol adaptation method, electronic devices, storage media, and vehicles, at least solving one of the technical problems of wasted human resources caused by independent development of multiple protocols, insufficient system stability caused by poor compatibility of different protocols, low maintenance efficiency caused by frequent protocol iterations, and performance loss of vehicle systems caused by excessive optimization of resource consumption.

[0009] This invention provides the following solution:

[0010] According to a first aspect of the present invention, a multi-protocol intelligent cockpit interconnection and integration system is provided, comprising: a universal interconnection interface layer, a protocol adapter layer, and a central control layer;

[0011] The communication connection between the general interconnection interface layer, the protocol adapter layer, and the central control layer is used to achieve multi-protocol interconnection and adaptation between the mobile phone and the vehicle system;

[0012] The general interconnect interface layer includes hardware interface modules and software interface modules;

[0013] The hardware interface module is used to be compatible with multiple communication methods and to receive access requests from mobile phones.

[0014] The software interface module defines a unified data transmission protocol, adapting to the underlying system interfaces of various system architectures;

[0015] The protocol adapter layer includes a dynamic identification module and a protocol conversion engine;

[0016] The dynamic identification module uses signature scanning technology to identify the Internet protocol type of the connected mobile phone;

[0017] The protocol conversion engine is used to convert data from different protocol formats into a unified system-wide data format.

[0018] The central control layer includes a resource scheduler, an error handling module, and a data cache pool;

[0019] The resource scheduler uses a priority queue algorithm to allocate vehicle system resources according to the protocol type.

[0020] The error handling module is used to establish a unified error code system across protocols, supporting automatic retries and fault isolation;

[0021] The data cache pool uses the LRU algorithm to manage cross-protocol data caching and improve data interaction speed.

[0022] Furthermore, the hardware interface module, designed to be compatible with multiple communication methods, receives access requests from mobile phones, including:

[0023] It is compatible with USB, Bluetooth and WiFi communication methods and is used to receive access requests from mobile phones and transmit data.

[0024] Furthermore, the software interface module defines a unified data transmission protocol and adapts to the underlying system interfaces of various system architectures, including: adapting to the underlying system interfaces of iOS, Android, and HarmonyOS, to achieve standardized underlying processing of data from different mobile phone systems.

[0025] Furthermore, the dynamic identification module uses signature scanning technology to identify the Internet protocol type of the accessing mobile phone, including:

[0026] The dynamic identification module uses signature scanning technology to identify the Internet protocol type of the accessing mobile phone within 100ms;

[0027] Protocol types include Apple CarPlay, Google Android Auto, Huawei HiCar, and ICCOA Alliance CarLink;

[0028] The signature scan includes the "CP_SIGNAL" handshake packet of the CarPlay protocol and the "AA_IDENT" frame structure of the AndroidAuto protocol.

[0029] Furthermore, the protocol conversion engine is used to uniformly convert data from different protocol formats into a system-wide data format, including:

[0030] The protocol conversion engine includes adaptation for different protocols;

[0031] The adaptation includes developing an API proxy layer for the CarPlay protocol to convert iOS private protocols into a universal data format;

[0032] The adaptation also includes refactoring the Google service interface for AndroidAuto to enable function mapping in environments without GMS;

[0033] The adaptation also includes a HAP component adapter for the HiCar protocol, for compatibility with Huawei's distributed communication protocol;

[0034] The adaptation also includes an ISO21434 security protocol encapsulation layer for the CarLink protocol to ensure automotive-grade communication security.

[0035] Furthermore, the resource scheduler employs a priority queue algorithm to allocate vehicle system resources based on protocol type, including:

[0036] Priority queue algorithms include DWRR (Dynamic Weighted Round Robin);

[0037] Allocate CPU / memory resources according to protocol type;

[0038] CPU / memory resource allocation includes allocating 60% of resources during CarPlay navigation;

[0039] The allocation of CPU / memory resources also includes allocating 30% during Android Auto music playback.

[0040] Furthermore, the error handling module is used to establish a unified error code system across protocols, supporting automatic retries and fault isolation, including:

[0041] In the unified error code system, error code 0x001 represents a protocol handshake failure, and error code 0x002 represents a data verification error.

[0042] Furthermore, the data caching pool employs the LRU algorithm to manage cross-protocol data caching, improving data interaction speed by including:

[0043] Eliminating Least Recently Used data optimizes cross-protocol data caching efficiency and improves data interaction speed.

[0044] According to a second aspect of the present invention, a multi-protocol smart cockpit interconnection protocol adaptation method is provided, based on a multi-protocol smart cockpit interconnection integration system. The multi-protocol smart cockpit interconnection protocol adaptation method includes:

[0045] S1: The hardware interface module of the general interconnection interface layer receives the access request from the mobile phone and establishes a communication connection between the mobile phone and the vehicle system.

[0046] The raw data transmitted by the mobile phone is standardized and preliminarily processed through the unified data transmission protocol of the software interface module.

[0047] S2: The dynamic identification module of the protocol adapter layer uses signature scanning technology to identify the Internet protocol type of the access mobile phone within 100ms;

[0048] Connectivity protocols include CarPlay, AndroidAuto, HiCar, and CarLink.

[0049] The protocol conversion engine is invoked to adapt to different protocols and convert data in the mobile phone's protocol format into the system's common data format.

[0050] S3: The resource scheduler of the central control layer adopts the DWRR dynamic weighted round-robin algorithm to dynamically allocate the CPU and memory resources of the vehicle system according to the protocol type and current business scenario identified in step S2.

[0051] The error handling module monitors errors during data interaction through a unified error code system and triggers automatic retry or fault isolation mechanisms.

[0052] The data cache pool uses the LRU algorithm to cache and manage interactive data, thereby improving data interaction efficiency.

[0053] According to a third aspect of the present invention, an electronic device is provided, comprising: a processor, a communication interface, a memory, and a communication bus, wherein the processor, the communication interface, and the memory communicate with each other via the communication bus;

[0054] The memory stores a computer program, which, when executed by the processor, causes the processor to perform the steps of the multi-protocol smart cockpit interconnection protocol adaptation method.

[0055] According to a fourth aspect of the present invention, a computer-readable storage medium is provided storing a computer program executable by an electronic device, which, when run on the electronic device, causes the electronic device to perform the steps of a multi-protocol smart cockpit interconnection protocol adaptation method.

[0056] According to a fifth aspect of the present invention, a vehicle is provided, comprising:

[0057] Electronic devices, steps for implementing a multi-protocol smart cockpit interconnection protocol adaptation method;

[0058] The processor runs a program, and when the program runs, it executes the steps of the multi-protocol smart cockpit interconnection protocol adaptation method from the data output by the electronic device.

[0059] A storage medium for storing a program that, when running, performs steps of a multi-protocol smart cockpit interconnection protocol adaptation method on data output from an electronic device.

[0060] The above solution achieves the following beneficial technical effects:

[0061] This application achieves multi-protocol interconnection and adaptation between mobile phones and vehicle systems through communication connections via a general interconnection interface layer, a protocol adapter layer, and a central control layer. This improves development efficiency, increases system stability, reduces maintenance costs, saves resource consumption, and enhances user experience.

[0062] This application uses a hardware interface to be compatible with multiple communication methods and receive access requests from mobile phones using different communication methods. Through a software interface, it defines a unified data transmission protocol to adapt to the underlying system interfaces of various system architectures, thereby shortening the protocol iteration and adaptation time.

[0063] This application uses signature scanning technology to identify the Internet protocol type of the accessing mobile phone within 100ms, thereby improving the success rate of protocol switching.

[0064] This application uses a priority queue algorithm to allocate vehicle system resources according to protocol type, thereby reducing CPU resource utilization and navigation lag rate. Attached Figure Description

[0065] Figure 1 This is a flowchart of a multi-protocol smart cockpit interconnection protocol adaptation method provided by one or more embodiments of the present invention.

[0066] Figure 2 This is a structural diagram of a multi-protocol intelligent cockpit interconnection and integration system provided by one or more embodiments of the present invention.

[0067] Figure 3 This is a block diagram of an electronic device structure for a multi-protocol smart cockpit interconnection protocol adaptation method provided in one or more embodiments of the present invention. Detailed Implementation

[0068] The technical solution of the present invention will now be clearly and completely described with reference to the accompanying drawings. Obviously, the described embodiments are only some, not all, of the embodiments of the present invention. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0069] Figure 2 This is a structural diagram of a multi-protocol intelligent cockpit interconnection and integration system provided by one or more embodiments of the present invention.

[0070] like Figure 2 The multi-protocol intelligent cockpit interconnection and integration system shown includes: a universal interconnection interface layer, a protocol adapter layer, and a central control layer;

[0071] The communication connection between the general interconnection interface layer, the protocol adapter layer, and the central control layer is used to achieve multi-protocol interconnection and adaptation between the mobile phone and the vehicle system;

[0072] The general interconnect interface layer includes hardware interface modules and software interface modules;

[0073] The hardware interface module is used to be compatible with multiple communication methods and to receive access requests from mobile phones.

[0074] The software interface module defines a unified data transmission protocol, adapting to the underlying system interfaces of various system architectures;

[0075] The protocol adapter layer includes a dynamic identification module and a protocol conversion engine;

[0076] The dynamic identification module uses signature scanning technology to identify the Internet protocol type of the connected mobile phone;

[0077] The protocol conversion engine is used to convert data from different protocol formats into a unified system-wide data format.

[0078] The central control layer includes a resource scheduler, an error handling module, and a data cache pool;

[0079] The resource scheduler uses a priority queue algorithm to allocate vehicle system resources according to the protocol type.

[0080] The error handling module is used to establish a unified error code system across protocols, supporting automatic retries and fault isolation;

[0081] The data cache pool uses the LRU algorithm to manage cross-protocol data caching and improve data interaction speed.

[0082] In this embodiment, the hardware interface module is used to be compatible with multiple communication methods and receives access requests from mobile phones, including:

[0083] It is compatible with USB, Bluetooth and WiFi communication methods and is used to receive access requests from mobile phones and transmit data.

[0084] In this embodiment, the software interface module defines a unified data transmission protocol and adapts to the underlying system interfaces of various system architectures, including: the underlying system interfaces of iOS, Android and HarmonyOS, to achieve standardized underlying processing of data from different mobile phone systems.

[0085] In this embodiment, the dynamic identification module uses signature scanning technology to identify the Internet protocol type of the accessing mobile phone, including:

[0086] The dynamic identification module uses signature scanning technology to identify the Internet protocol type of the accessing mobile phone within 100ms;

[0087] Protocol types include Apple CarPlay, Google Android Auto, Huawei HiCar, and ICCOA Alliance CarLink;

[0088] The signature scan includes the "CP_SIGNAL" handshake packet of the CarPlay protocol and the "AA_IDENT" frame structure of the AndroidAuto protocol.

[0089] In this embodiment, the protocol conversion engine, used to uniformly convert data from different protocol formats into a system-wide common data format, includes:

[0090] The protocol conversion engine includes adaptation for different protocols;

[0091] The adaptation includes developing an API proxy layer for the CarPlay protocol to convert iOS private protocols into a universal data format;

[0092] The adaptation also includes refactoring the Google service interface for AndroidAuto to enable function mapping in environments without GMS;

[0093] The adaptation also includes a HAP component adapter for the HiCar protocol, for compatibility with Huawei's distributed communication protocol;

[0094] The adaptation also includes an ISO21434 security protocol encapsulation layer for the CarLink protocol to ensure automotive-grade communication security.

[0095] In this embodiment, the resource scheduler uses a priority queue algorithm to allocate vehicle system resources according to the protocol type, including:

[0096] Priority queue algorithms include DWRR (Dynamic Weighted Round Robin);

[0097] Allocate CPU / memory resources according to protocol type;

[0098] CPU / memory resource allocation includes allocating 60% of resources during CarPlay navigation;

[0099] The allocation of CPU / memory resources also includes allocating 30% during Android Auto music playback.

[0100] In this embodiment, the error handling module is used to establish a unified error code system across protocols, supporting automatic retries and fault isolation, including:

[0101] In the unified error code system, error code 0x001 represents a protocol handshake failure, and error code 0x002 represents a data verification error.

[0102] In this embodiment, the data cache pool uses the LRU algorithm to manage cross-protocol data caching and improve data interaction speed, including:

[0103] Eliminating Least Recently Used data optimizes cross-protocol data caching efficiency and improves data interaction speed.

[0104] Specifically, in one particular embodiment, a "three-tier architecture + dynamic adaptation" model is adopted, and the core components include:

[0105] 1. General Interconnection Interface Layer

[0106] 1.1 Hardware Interface: Compatible with USB, Bluetooth, and WiFi;

[0107] 1.2 Software Interface: Define a unified data transmission protocol (such as byte stream encapsulation format) to adapt to the underlying interfaces of systems such as iOS, Android, and HarmonyOS.

[0108] 2. Protocol Adapter Layer

[0109] 2.1 Dynamic Identification Module: Based on feature code scanning technology (such as CarPlay's "CP_SIGNAL" handshake packet and AndroidAuto's "AA_IDENT" frame structure), it identifies the access protocol type within 100ms;

[0110] 2.2 Protocol Conversion Engine:

[0111] For CarPlay: Develop an API proxy layer to convert iOS private protocols into a universal data format;

[0112] For AndroidAuto: Refactor the Google service interface to enable function mapping in a GMS-free environment;

[0113] For HiCar: Develop a HAP component adapter that is compatible with Huawei's distributed communication protocol;

[0114] For CarLink: Design an ISO21434 security protocol encapsulation layer to ensure automotive-grade communication security.

[0115] 3. Central control layer

[0116] 3.1 Resource Scheduler: Employs a priority queue algorithm (such as DWRR dynamic weighted round-robin) to allocate CPU / memory resources based on the protocol type. For example, 60% of resources are allocated during CarPlay navigation, while 30% is allocated during Android Auto music playback.

[0117] 3.2 Error Handling Module: Establish a unified cross-protocol error code system (e.g., 0x001 represents protocol handshake failure, 0x002 represents data verification error), and support automatic retry and fault isolation;

[0118] 3.3 Data Cache Pool: The LRU (Least Recently Used) algorithm is used to manage cross-protocol data cache, improving data interaction speed by more than 3 times.

[0119] Figure 1 This is a flowchart of a multi-protocol smart cockpit interconnection protocol adaptation method provided by one or more embodiments of the present invention.

[0120] like Figure 1 The multi-protocol smart cockpit interconnection protocol adaptation method shown is based on a multi-protocol smart cockpit interconnection integration system. The multi-protocol smart cockpit interconnection protocol adaptation method includes:

[0121] S1: The hardware interface module of the general interconnection interface layer receives the access request from the mobile phone and establishes a communication connection between the mobile phone and the vehicle system.

[0122] The raw data transmitted by the mobile phone is standardized and preliminarily processed through the unified data transmission protocol of the software interface module.

[0123] S2: The dynamic identification module of the protocol adapter layer uses signature scanning technology to identify the Internet protocol type of the access mobile phone within 100ms;

[0124] Connectivity protocols include CarPlay, AndroidAuto, HiCar, and CarLink.

[0125] The protocol conversion engine is invoked to adapt to different protocols and convert data in the mobile phone's protocol format into the system's common data format.

[0126] S3: The resource scheduler of the central control layer adopts the DWRR dynamic weighted round-robin algorithm to dynamically allocate the CPU and memory resources of the vehicle system according to the protocol type and current business scenario identified in step S2.

[0127] The error handling module monitors errors during data interaction through a unified error code system and triggers automatic retry or fault isolation mechanisms.

[0128] The data cache pool uses the LRU algorithm to cache and manage interactive data, thereby improving data interaction efficiency.

[0129] Specifically, in one particular embodiment, a step for integrating a vehicle infotainment system is disclosed:

[0130] 1. Hardware deployment:

[0131] 1.1 The vehicle infotainment system motherboard integrates a Qualcomm SA8155P chip and is equipped with 8GB RAM + 128GB ROM;

[0132] 1.2 The general interface module uses TI's USB3.1 controller and QCA's WiFi6E chip.

[0133] 2. Software Implementation:

[0134] 2.1 Operating System: Deeply customized based on Android 12 automotive version, with added protocol integration middleware;

[0135] 2.2 Protocol Adapter Development:

[0136] 2.2.1 CarPlay Adapter: Based on Apple's publicly available MFi protocol specification, an API conversion layer was developed to realize the format conversion of Siri voice commands and map data;

[0137] 2.2.2 AndroidAuto Adapter: Adopts Google's open-source AAAPI framework and refactors the GMS dependency interface, such as mapping Google Maps service to the vehicle's built-in map SDK;

[0138] 2.3 Central Control Layer: A resource scheduler is developed using C++, combined with Python scripts to automatically generate and manage error codes.

[0139] 3. Testing and verification:

[0140] 3.1 Compatibility Test: Connected to 100 mobile phones (iOS 15-17, Android 11-14, HarmonyOS 3.0), with a protocol recognition success rate of 99.8% and data transmission latency of <50ms;

[0141] 3.2 Stress test: After 10,000 consecutive protocol switching cycles, the system did not crash, and the resource scheduling response time was less than 10ms.

[0142] It is worth noting that although this system / device only discloses the aforementioned general interconnection interface layer, protocol adapter layer, central control layer, hardware interface module, software interface module, dynamic identification module, protocol conversion engine, resource scheduler, error handling module, and data cache pool, this does not mean that this system / device is limited to the aforementioned basic functional modules. Rather, what this invention intends to express is that, based on the aforementioned basic functional modules, those skilled in the art can arbitrarily add one or more functional modules in combination with existing technology to form an infinite number of embodiments or technical solutions. In other words, this system is open rather than closed. The fact that this embodiment only discloses a few basic functional modules should not be interpreted as the scope of protection of the claims of this invention being limited to the aforementioned disclosed basic functional modules.

[0143] In one specific embodiment, a multi-protocol intelligent cockpit interconnection and integration system is disclosed, including: a general interconnection interface layer, a protocol adapter layer, and a central control layer;

[0144] The communication connection between the general interconnection interface layer, the protocol adapter layer, and the central control layer is used to achieve multi-protocol interconnection and adaptation between the mobile phone and the vehicle system;

[0145] The universal interconnect interface layer includes a hardware interface module and a software interface module. The hardware interface module is compatible with USB, Bluetooth and WiFi communication methods and is used to receive access requests from mobile phones and transmit data. The software interface module defines a unified data transmission protocol, adapts to the underlying system interfaces of iOS, Android and HarmonyOS, and realizes standardized preliminary processing of data from different mobile phone systems.

[0146] The protocol adapter layer includes a dynamic identification module and a protocol conversion engine. The dynamic identification module uses signature scanning technology to identify the interconnection protocol type of the connected mobile phone within 100ms. The protocol types include Apple CarPlay, Google Android Auto, Huawei HiCar, and ICCOA Alliance CarLink. The protocol conversion engine includes adaptation sub-modules for different protocols: an API proxy layer for the CarPlay protocol (used to convert iOS private protocols into a universal data format), a GMS interface reconstruction sub-module for the Android Auto protocol (used to implement function mapping in environments without GMS), a HAP component adapter for the HiCar protocol (used to be compatible with Huawei's distributed communication protocol), and an ISO21434 security protocol encapsulation layer for the CarLink protocol (used to ensure automotive-grade communication security). The protocol conversion engine is used to uniformly convert data from different protocol formats into the system's universal data format.

[0147] The central control layer includes a resource scheduler, an error handling module, and a data cache pool. The resource scheduler uses the DWRR dynamic weighted round-robin algorithm to allocate the vehicle's CPU and memory resources according to the protocol type and business scenario. The error handling module establishes a unified cross-protocol error code system to support automatic error retries and fault isolation. The data cache pool uses the LRU (Least Recently Used) algorithm to manage cross-protocol data caching, improving data interaction speed.

[0148] It also includes the hardware interface module of the universal interconnect interface layer, in which the vehicle motherboard integrates the Qualcomm SA8155P chip, and is equipped with 8GB RAM and 128GB ROM; the hardware interface module uses TI's USB3.1 controller to realize USB communication and QCA's WiFi6E chip to realize WiFi communication.

[0149] It also includes a deeply customized operating system based on the automotive version of Android 12, which integrates protocol integration middleware to connect the data interaction between the general interconnection interface layer, the protocol adapter layer and the central control layer.

[0150] It also includes protocol signatures identified by the dynamic identification module, such as the "CP_SIGNAL" handshake packet of the CarPlay protocol and the "AA_IDENT" frame structure of the AndroidAuto protocol.

[0151] It also includes the resource allocation strategy of the resource scheduler: when the mobile phone is using the CarPlay protocol for navigation, 60% of the CPU and memory resources of the vehicle system are allocated; when the mobile phone is using the AndroidAuto protocol for music playback, 30% of the CPU and memory resources of the vehicle system are allocated.

[0152] It also includes a unified error code system, where error code 0x001 represents a protocol handshake failure and error code 0x002 represents a data verification error.

[0153] It also includes a data cache pool that uses the LRU algorithm to improve data interaction speed by more than 3 times.

[0154] It also includes a protocol conversion engine that can be hardware accelerated using FPGA chips, reducing the protocol conversion latency from 10ms to less than 5ms, which is suitable for the vehicle-machine interconnection needs in autonomous driving scenarios.

[0155] In another specific embodiment, a multi-protocol smart cockpit interconnection protocol adaptation method is further disclosed, which is applied to a multi-protocol smart cockpit interconnection integration system:

[0156] A1: The general interconnection interface layer receives the access request from the mobile phone through the hardware interface module, establishes a communication connection between the mobile phone and the vehicle system, and performs standardized preliminary processing on the raw data transmitted by the mobile phone through the unified data transmission protocol of the software interface module.

[0157] A2: The dynamic identification module of the protocol adapter layer uses signature scanning technology to identify the interconnection protocol type of the connected mobile phone (including CarPlay, AndroidAuto, HiCar, CarLink) within 100ms. Then, it calls the corresponding protocol adaptation sub-module in the protocol conversion engine to convert the mobile phone protocol format data into the system's general data format.

[0158] A3: The resource scheduler of the central control layer adopts the DWRR dynamic weighted round-robin algorithm to dynamically allocate the CPU and memory resources of the vehicle system according to the protocol type identified in step A2 and the current business scenario. At the same time, the error handling module monitors errors in the data interaction process through a unified error code system and triggers automatic retry or fault isolation mechanisms. The data cache pool uses the LRU algorithm to cache and manage the interactive data, thereby improving the efficiency of data interaction.

[0159] It also includes step A2, in which the dynamic identification module identifies the protocol type by detecting the handshake packet or frame structure sent by the mobile phone: if the "CP_SIGNAL" handshake packet is detected, it is determined to be the CarPlay protocol; if the "AA_IDENT" frame structure is detected, it is determined to be the AndroidAuto protocol.

[0160] It also includes the following in step A2: the protocol conversion engine's processing includes: for the CarPlay protocol, converting iOS private JSON format instructions into the system binary universal format through the API proxy layer; for the AndroidAuto protocol, converting Protobuf format instructions into the system binary universal format through the GMS interface refactoring submodule.

[0161] It also includes that in step A3, when the resource scheduler allocates resources, if the current service is CarPlay navigation, it allocates 60% of the vehicle's CPU and memory resources; if the current service is Android Auto music playback, it allocates 30% of the vehicle's CPU and memory resources.

[0162] It also includes that, in step A3, when the error handling module detects a 0x001 error code (protocol handshake failure), it automatically triggers a retry mechanism; when it detects a 0x002 error code (data verification error), it triggers fault isolation and cuts off the data transmission channel of the current protocol to avoid affecting other protocols.

[0163] It also includes step A4: cloud adaptation or machine learning optimization can be used to optimize protocol adaptation efficiency; the cloud adaptation solution deploys some protocol adaptation logic to the cloud server, and the vehicle system only retains lightweight interfaces; the machine learning optimization solution uses a neural network model to predict the next access protocol based on the user's historical connection records, which improves the protocol recognition speed by 50%.

[0164] Figure 3 This is a block diagram of an electronic device structure for a multi-protocol smart cockpit interconnection protocol adaptation method provided in one or more embodiments of the present invention.

[0165] like Figure 3 As shown, this application provides an electronic device, including: a processor, a communication interface, a memory, and a communication bus, wherein the processor, the communication interface, and the memory communicate with each other through the communication bus;

[0166] The memory stores a computer program, which, when executed by the processor, causes the processor to perform steps of a multi-protocol smart cockpit interconnection protocol adaptation method.

[0167] This application also provides a computer-readable storage medium storing a computer program executable by an electronic device, which, when run on the electronic device, causes the electronic device to perform the steps of a multi-protocol smart cockpit interconnection protocol adaptation method.

[0168] This application also provides a testing platform, including:

[0169] Electronic devices, steps for implementing a multi-protocol smart cockpit interconnection protocol adaptation method;

[0170] The processor runs a program, and when the program runs, it executes the steps of the multi-protocol smart cockpit interconnection protocol adaptation method from the data output by the electronic device.

[0171] A storage medium for storing a program that, when running, performs steps of a multi-protocol smart cockpit interconnection protocol adaptation method on data output from an electronic device.

[0172] The communication bus mentioned in the above electronic devices can be a Peripheral Component Interconnect (PCI) bus or an Extended Industry Standard Architecture (EISA) bus, etc. This communication bus can be divided into address bus, data bus, control bus, etc. For ease of illustration, only one thick line is used to represent it in the diagram, but this does not indicate that there is only one bus or one type of bus.

[0173] The electronic device comprises a hardware layer, an operating system layer running on top of the hardware layer, and an application layer running on the operating system. The hardware layer includes hardware such as a central processing unit (CPU), a memory management unit (MMU), and memory. The operating system can be any one or more computer operating systems that control the electronic device through processes, such as Linux, Unix, Android, iOS, or Windows. Furthermore, in this embodiment of the invention, the electronic device can be a smartphone, tablet computer, or other handheld device, or a desktop computer, portable computer, or other electronic device; there is no particular limitation in this embodiment.

[0174] In this embodiment of the invention, the executing entity for electronic device control can be an electronic device itself, or a functional module within an electronic device capable of calling and executing a program. The electronic device can obtain the firmware corresponding to the storage medium. This firmware is provided by the supplier, and different storage media may have the same or different firmware; no limitation is made here. After obtaining the firmware corresponding to the storage medium, the electronic device can write this firmware into the storage medium; specifically, it burns the firmware corresponding to the storage medium into the storage medium. The process of burning the firmware into the storage medium can be implemented using existing technology, and will not be elaborated upon in this embodiment of the invention.

[0175] Electronic devices can also obtain reset commands corresponding to the storage media. The reset commands corresponding to the storage media are provided by the supplier. The reset commands corresponding to different storage media can be the same or different, and no restrictions are imposed here.

[0176] At this time, the storage medium of the electronic device is a storage medium on which the corresponding firmware has been written. The electronic device can respond to the reset command corresponding to the storage medium on which the corresponding firmware has been written, thereby resetting the storage medium on which the corresponding firmware has been written according to the reset command. The process of resetting the storage medium according to the reset command can be implemented by existing technology and will not be described in detail in this embodiment of the invention.

[0177] For ease of description, the above devices are described separately by function as various units and modules. Of course, in implementing this application, the functions of each unit and module can be implemented in one or more software and / or hardware.

[0178] It will be understood by those skilled in the art that, unless otherwise defined, all terms used herein (including technical and scientific terms) have the same meaning as commonly understood by one of ordinary skill in the art to which this invention pertains. It should also be understood that terms such as those defined in general dictionaries should be understood to have the meaning consistent with their meaning in the context of the prior art, and should not be interpreted in an idealized or overly formal sense unless specifically defined.

[0179] For the sake of simplicity, the method embodiments are described as a series of actions. However, those skilled in the art should understand that the embodiments of the present invention are not limited to the described order of actions, because according to the embodiments of the present invention, some steps can be performed in other orders or simultaneously. Furthermore, those skilled in the art should also understand that the embodiments described in the specification are preferred embodiments, and the actions involved are not necessarily essential to the embodiments of the present invention.

[0180] As can be seen from the above description of the embodiments, those skilled in the art can clearly understand that this application can be implemented by means of software plus necessary general-purpose hardware platforms. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product can be stored in a storage medium, such as ROM / RAM, magnetic disk, optical disk, etc., and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute the methods described in various embodiments or some parts of the embodiments of this application.

[0181] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention, and not to limit them; although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some or all of the technical features; and these modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of the present invention.

Claims

1. A multi-protocol intelligent cockpit interconnection and integration system, characterized in that, The multi-protocol intelligent cockpit interconnection and integration system includes: a general interconnection interface layer, a protocol adapter layer, and a central control layer; The communication connection between the general interconnection interface layer, the protocol adapter layer, and the central control layer is used to achieve multi-protocol interconnection and adaptation between the mobile phone and the vehicle system; The general interconnect interface layer includes hardware interface modules and software interface modules; The hardware interface module is used to be compatible with multiple communication methods and to receive access requests from mobile phones. The software interface module defines a unified data transmission protocol, adapting to the underlying system interfaces of various system architectures; The protocol adapter layer includes a dynamic identification module and a protocol conversion engine; The dynamic identification module uses signature scanning technology to identify the Internet protocol type of the connected mobile phone; The protocol conversion engine is used to convert data from different protocol formats into a unified system-wide data format. The central control layer includes a resource scheduler, an error handling module, and a data cache pool; The resource scheduler uses a priority queue algorithm to allocate vehicle system resources according to the protocol type. The error handling module is used to establish a unified error code system across protocols, supporting automatic retries and fault isolation; The data cache pool uses the LRU algorithm to manage cross-protocol data caching and improve data interaction speed.

2. The multi-protocol intelligent cockpit interconnection and integration system according to claim 1, characterized in that, The hardware interface module is compatible with multiple communication methods and receives access requests from mobile phones, including: It is compatible with USB, Bluetooth and WiFi communication methods and is used to receive access requests from mobile phones and transmit data.

3. The multi-protocol intelligent cockpit interconnection and integration system according to claim 1, characterized in that, The software interface module defines a unified data transmission protocol and adapts to the underlying system interfaces of various system architectures, including those for iOS, Android, and HarmonyOS, to achieve standardized underlying processing of data from different mobile phone systems.

4. The multi-protocol intelligent cockpit interconnection and integration system according to claim 1, characterized in that, The dynamic identification module uses signature scanning technology to identify the Internet protocol type of the accessing mobile phone, including: The dynamic identification module uses signature scanning technology to identify the Internet protocol type of the accessing mobile phone within 100ms; Protocol types include Apple CarPlay, Google Android Auto, Huawei HiCar, and ICCOA Alliance CarLink; The signature scanning includes the CP_SIGNAL handshake packet of the CarPlay protocol and the AA_IDENT frame structure of the AndroidAuto protocol.

5. The multi-protocol intelligent cockpit interconnection and integration system according to claim 1, characterized in that, The protocol conversion engine is used to uniformly convert data from different protocol formats into a system-wide common data format, including: The protocol conversion engine includes adaptation for different protocols; The adaptation includes developing an API proxy layer for the CarPlay protocol to convert iOS private protocols into a universal data format; The adaptation also includes refactoring the Google service interface for AndroidAuto to enable function mapping in environments without GMS; The adaptation also includes a HAP component adapter for the HiCar protocol, for compatibility with Huawei's distributed communication protocol; The adaptation also includes an ISO21434 security protocol encapsulation layer for the CarLink protocol to ensure automotive-grade communication security.

6. The multi-protocol intelligent cockpit interconnection and integration system according to claim 1, characterized in that, The resource scheduler uses a priority queue algorithm to allocate vehicle system resources according to protocol type, including: Priority queue algorithms include DWRR (Dynamic Weighted Round Robin); Allocate CPU / memory resources according to protocol type; CPU / memory resource allocation includes allocating 60% of resources during CarPlay navigation; The allocation of CPU / memory resources also includes allocating 30% during Android Auto music playback.

7. The multi-protocol intelligent cockpit interconnection and integration system according to claim 1, characterized in that, The error handling module is used to establish a unified error code system across protocols, supporting automatic retries and fault isolation, including: In the unified error code system, error code 0x001 represents a protocol handshake failure, and error code 0x002 represents a data verification error.

8. The multi-protocol intelligent cockpit interconnection and integration system according to claim 1, characterized in that, The data cache pool uses the LRU algorithm to manage cross-protocol data caching and improve data interaction speed, including: Eliminating Least Recently Used data optimizes cross-protocol data caching efficiency and improves data interaction speed.

9. A method for adapting multi-protocol smart cockpit interconnection protocols, characterized in that, The multi-protocol smart cockpit interconnection integration system according to any one of claims 1 to 8 is characterized in that the multi-protocol smart cockpit interconnection protocol adaptation method includes: S1: The hardware interface module of the general interconnection interface layer receives the access request from the mobile phone and establishes a communication connection between the mobile phone and the vehicle system. The raw data transmitted by the mobile phone is standardized and preliminarily processed through the unified data transmission protocol of the software interface module. S2: The dynamic identification module of the protocol adapter layer uses signature scanning technology to identify the Internet protocol type of the access mobile phone within 100ms; Connectivity protocols include CarPlay, AndroidAuto, HiCar, and CarLink. The protocol conversion engine is invoked to adapt to different protocols and convert data in the mobile phone's protocol format into the system's common data format. S3: The resource scheduler of the central control layer adopts the DWRR dynamic weighted round-robin algorithm to dynamically allocate the CPU and memory resources of the vehicle system according to the protocol type and current business scenario identified in step S2. The error handling module monitors errors during data interaction through a unified error code system and triggers automatic retry or fault isolation mechanisms. The data cache pool uses the LRU algorithm to cache and manage interactive data, thereby improving the efficiency of data interaction.

10. An electronic device, characterized in that, include: The processor, communication interface, memory, and communication bus are connected, with the processor, communication interface, and memory communicating with each other via the communication bus. The memory stores a computer program that, when executed by a processor, causes the processor to perform the steps of the multi-protocol smart cockpit interconnection protocol adaptation method as described in claim 9.

Images