Vehicle end communication system, operation method and related equipment

Abstract

The embodiment of the invention provides a vehicle end communication system, an operation method and related equipment, and belongs to the technical field of vehicle communication. According to the embodiment of the invention, by introducing the unified vehicle-mounted gateway, standardization of a vehicle cloud communication protocol, fine control of authority, intelligent scheduling of traffic and effective isolation of resources are realized, the development complexity is remarkably reduced, and the reliability and maintainability of the system are improved.

Description

Technical Field

[0001] This application relates to the field of vehicle communication technology, and in particular to a vehicle-side communication system, operating method, and related equipment. Background Technology

[0002] With the development of intelligent connected vehicles, scenarios involving collaboration between vehicle-side applications and the cloud are increasing, and vehicle-side software architecture is transforming towards Service-Oriented Architecture (SOA). In traditional architectures, each application on the vehicle side establishes an independent communication connection with the cloud, and each application needs to independently implement network connections and data transmission, resulting in redundant consumption of computing and memory resources. At the same time, application developers need to be proficient in multiple communication protocols (such as HTTP and MQTT), and each application needs to communicate independently, making communication setup cumbersome.

[0003] Therefore, there is an urgent need for a unified communication protocol between vehicles and the cloud to improve system reliability and development efficiency. Summary of the Invention

[0004] The main objective of this application is to propose a vehicle-to-everything (V2X) communication system, operating method, and related equipment to address the problems of inconsistent protocols, resource waste, complex management, and low reliability in existing vehicle-to-cloud (V2X) communication technologies.

[0005] To achieve the above objectives, one aspect of this application proposes a vehicle-mounted communication system, integrated with an in-vehicle gateway installed in a vehicle. The in-vehicle gateway is connected to both an in-vehicle host and a cloud processor. The system includes: The access control module is configured to perform access verification based on the vehicle application identifier, application service identifier, or request service interface identifier in the communication service request when a communication service request is received, and to determine the access permissions of the communication service request through an access whitelist mechanism. The routing strategy module, connected to the access control module, is configured to determine the routing strategy information of the communication service request based on the access permissions of the communication service request. The routing strategy information includes the communication protocol, maximum concurrency, and task priority. The module forwards the communication service request according to the routing strategy information. When configuring the routing strategy information, the routing strategy module allocates the communication service request to task queues of different priorities.

[0006] In some embodiments, the routing strategy module is configured to send communication service requests in different priority queues. The communication service requests are divided into a first priority, a second priority, and a third priority according to their priority. When the priority of a target communication service request is higher than the second priority but lower than the first priority, the routing strategy module is configured to allocate the target communication service request to the front of the second priority queue.

[0007] In some embodiments, the permission control module is configured to update the permission dictionary according to the permission configuration table issued by the cloud processor. The permission configuration table includes a permission version number and a permission list, wherein the permission list includes a mapping relationship between the application identifier, the application service identifier and the request business interface identifier stored in the form of a JSON array. The permission control module is configured to use the permission dictionary to determine the access permissions of the communication request business request.

[0008] In some embodiments, the communication service request is an upload communication service and a download communication service. The upload communication service is the vehicle host sending information to the cloud processor through the vehicle gateway, and the download communication service is the cloud processor sending information to the vehicle host through the vehicle gateway. The communication protocol includes an internal protocol and an external protocol. The internal protocol supports communication between the vehicle host and the vehicle gateway, and the external protocol supports communication between the vehicle gateway and the cloud processor. The routing strategy module is configured to convert the internal protocol of the upload communication service into an external protocol when executing the upload communication service; and to convert the external protocol of the download communication service into an internal protocol when executing the download communication service. The internal protocol includes at least one of a message identifier, a timestamp, and an associated message identifier, and the external protocol includes at least one of a vehicle identifier, a host identifier, a message identifier, a timestamp, and an associated message identifier.

[0009] In some embodiments, the routing strategy module is configured to set a quota dictionary, which displays at least the optional concurrency of the vehicle application identifier, the application service identifier, or the request service interface identifier, and modifies the optional concurrency based on the occupancy of the communication service requests.

[0010] Another aspect of this application proposes a method for operating a vehicle-mounted communication system, applied to an in-vehicle gateway. The in-vehicle gateway is installed in a vehicle, connected to an in-vehicle host, and connected to a cloud processor, including: Upon receiving a communication service request, the vehicle application identifier, application service identifier, or request service interface identifier in the communication service request are subject to permission verification. The communication service request includes an upload communication service sent by the vehicle host to the cloud processor through the vehicle gateway, and a download communication service sent by the cloud processor to the vehicle host through the vehicle gateway. After the communication service request passes the permission verification, the routing policy information of the communication service request is determined according to the request service interface identifier. The routing policy information includes the communication protocol, maximum concurrency, and task priority. The communication service request is forwarded according to the routing policy information.

[0011] In some embodiments, before performing permission verification on the vehicle application identifier, application service identifier, or requested service interface identifier in the communication service request after receiving the communication service request, the method further includes: According to the permission configuration table issued by the cloud processor, the permission dictionary is updated. The permission configuration table includes a permission version number and a permission list. The permission list includes a mapping relationship between the application identifier, the application service identifier and the request business interface identifier stored in the form of a JSON array. The permission dictionary is used to store the pre-stored access permissions of the communication request business.

[0012] In some embodiments, the communication service request is an upload communication service sent by the vehicle host to the cloud processor through the vehicle gateway, and when the routing policy information is a communication protocol, the communication protocol includes internal protocols and external protocols. Forwarding the communication service request according to the routing policy information includes: Obtain the internal protocol data of the aforementioned internal protocol; The internal protocol data is modified using vehicle data to generate external protocol data, which includes at least a vehicle identifier and a host identifier. The external protocol is generated based on the external protocol data; The external protocol is used to send communication service requests to the cloud processor.

[0013] To achieve the above objectives, another aspect of this application provides a vehicle-side communication system operating device, the device comprising: The verification module, upon receiving a communication service request, performs permission verification on the vehicle application identifier, application service identifier, or requested service interface identifier in the communication service request. The communication service request includes an upload communication service sent by the vehicle host to the cloud processor through the vehicle gateway, and a download communication service sent by the cloud processor to the vehicle host through the vehicle gateway. The strategy module is used to determine the routing strategy information of the communication service request based on the request service interface identifier after the communication service request passes the permission verification. The routing strategy information includes the communication protocol, maximum concurrency, and task priority. The communication module is used to forward the communication service request according to the routing policy information.

[0014] To achieve the above objectives, another aspect of this application provides an electronic device, which includes a memory and a processor. The memory stores a computer program, and the processor executes the computer program to implement the method described above.

[0015] To achieve the above objectives, another aspect of the embodiments of this application proposes a computer-readable storage medium storing a computer program that, when executed by a processor, implements the methods described above.

[0016] To achieve the above objectives, another aspect of the embodiments of this application proposes a computer program product, including a computer program that, when executed by a processor, implements the aforementioned method.

[0017] The embodiments of this application include at least the following beneficial effects: This application provides a vehicle-side communication system, operating method, and related equipment. By introducing a unified vehicle gateway, this application achieves standardization of vehicle-to-cloud communication protocols, fine-grained control of permissions, intelligent traffic scheduling, and effective resource isolation, significantly reducing development complexity and improving system reliability and maintainability. Attached Figure Description

[0018] Figure 1 This is a system architecture diagram of the vehicle-to-everything (V2X) communication system provided in the embodiments of this application; Figure 2 This is a flowchart of the vehicle-side communication system operation method provided in the embodiments of this application; Figure 3 This is a schematic diagram of the priority queue provided in an embodiment of this application; Figure 4 This is a schematic diagram of the structure of the vehicle-end communication system operating device provided in the embodiments of this application; Figure 5 This is a schematic diagram of the hardware structure of the electronic device provided in the embodiments of this application. Detailed Implementation

[0019] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative of this application and are not intended to limit it. In the following description, when referring to the accompanying drawings, unless otherwise indicated, the same numbers in different drawings represent the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with those of this application; they are merely examples of apparatuses and methods consistent with some aspects of the embodiments of this application as detailed in the appended claims.

[0020] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this application belongs. The terminology used herein is for the purpose of describing embodiments of this application only and is not intended to limit this application.

[0021] Before providing a detailed description of the embodiments of this application, some of the nouns and terms involved in the embodiments of this application will be explained first. The nouns and terms involved in the embodiments of this application are subject to the following interpretations.

[0022] 1) Vehicle-side CCM (Central Computing Module): refers to the main computing unit integrated in the vehicle. It is usually responsible for integrating functions such as intelligent cockpit system (IVI), intelligent driving system (ADAS) and in-vehicle communication system. It can integrate most of the traditional ECU (electronic control unit).

[0023] 2) Vehicle gateway: In this application, it refers to the software gateway system deployed on the vehicle CCM, which serves as the sole exit point for all vehicle applications to communicate with the cloud.

[0024] 3) appid (vehicle application identifier): A string used to uniquely identify a vehicle application (such as flexible data collection or scene engine).

[0025] 4) serviceid (application service identifier): A string used to uniquely identify a service or process that can run independently within a vehicle application.

[0026] 5) funcid (request business interface identifier): A string used to uniquely identify a specific business request interface or API.

[0027] 6) Internal protocol: refers to the protocol format followed by the vehicle application and the vehicle gateway for communication.

[0028] 7) External protocol: refers to the protocol format followed by the communication between the vehicle gateway and the cloud processor (such as the cloud device gateway).

[0029] 8) Permission whitelist: A permission control mechanism that only allows access to applications, services or interfaces that are explicitly listed in the whitelist; otherwise, access is prohibited by default.

[0030] 9) Concurrency Quota Method: A flow control method that presets a maximum concurrent execution number (quota) for each funcid. Requests consume the quota, which is returned upon completion. New requests are rejected when the quota is zero.

[0031] 10) Task Priority Queue: A collection of queues managed according to task priority, used to schedule communication tasks of different priorities, ensuring that high-priority tasks are processed first.

[0032] In related technologies, direct communication between vehicle-side applications and the cloud leads to problems such as resource waste, complex development, poor reliability, and management difficulties.

[0033] In view of this, this application provides a vehicle-side communication system, operating method, and related equipment. This solution, by deploying a unified intelligent gateway on the vehicle-side CCM, achieves the standardization of communication protocols, the service-oriented nature of communication capabilities, and the refined management and control of communication, thereby significantly improving the reliability, security, and development efficiency of the system.

[0034] The vehicle-to-everything (V2X) communication system and application method provided in this application relate to the field of vehicle communication. The V2X communication system and application method provided in this application can be applied to a terminal, a server, or software running on a terminal or server. In some embodiments, the terminal can be a smartphone, tablet, laptop, desktop computer, smart speaker, smartwatch, or in-vehicle terminal, but is not limited to these. The server can be configured as an independent physical server, a server cluster or distributed system composed of multiple physical servers, or a cloud server providing basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, CDN, and big data and artificial intelligence platforms. The server can also be a node server in a blockchain network. The software can be an application implementing the V2X communication system and application method, but is not limited to the above forms.

[0035] This application can be used in a wide variety of general-purpose or special-purpose computer system environments or configurations. Examples include: personal computers, server computers, handheld or portable devices, tablet devices, multiprocessor systems, microprocessor-based systems, set-top boxes, programmable consumer electronics devices, network PCs, minicomputers, mainframe computers, and distributed computing environments including any of the above systems or devices. This application can be described in the general context of computer-executable instructions executed by a computer, such as program modules. Generally, program modules include routines, programs, objects, components, data structures, etc., that perform specific tasks or implement specific abstract data types. This application can also be practiced in distributed computing environments where tasks are performed by remote processing devices connected via a communication network. In distributed computing environments, program modules can reside in local and remote computer storage media, including storage devices.

[0036] It should be noted that in all specific embodiments of this application, when processing data related to vehicle identity or characteristics, such as vehicle information, vehicle operation data, and vehicle location information, user permission or consent is obtained first. Furthermore, the collection, use, and processing of this data comply with relevant laws, regulations, and standards. In addition, when embodiments of this application require access to sensitive personal information of users, separate permission or consent from the user is obtained through pop-ups or redirects to confirmation pages. Only after obtaining the user's separate permission or consent is the necessary user-related data required for the normal operation of embodiments of this application obtained.

[0037] Figure 1 This application provides a vehicle-to-everything (V2X) communication system, which is mounted on an in-vehicle gateway 10. The in-vehicle gateway 10 is connected to both an in-vehicle host 11 and a cloud processor 12. The V2X communication system includes: The 101 access control module is configured to perform access verification based on the vehicle application identifier, application service identifier, or request service interface identifier in the communication service request when a communication service request is received, and determine the access permissions of the communication service request through an access whitelist mechanism. The 102 routing strategy module, connected to the access control module, is configured to determine the routing strategy information for communication service requests based on their access permissions. The routing strategy information includes the communication protocol, maximum concurrency, and task priority. The module then forwards the communication service requests according to the routing strategy information. When configuring the routing strategy information, the routing strategy module allocates communication service requests to task queues of different priorities.

[0038] Figure 2 This is an optional flowchart of the vehicle-side communication system operation method provided in the embodiments of this application. Figure 2 The method may include, but is not limited to, steps S201 to S203.

[0039] Step S201: After receiving the communication service request, perform permission verification on the vehicle application identifier, application service identifier or requested service interface identifier in the communication service request. The communication service request includes the upload communication service sent by the vehicle host to the cloud processor through the vehicle gateway, and the download communication service sent by the cloud processor to the vehicle host through the vehicle gateway.

[0040] When the vehicle is powered on or the CCM is started, the onboard gateway service is initiated. The initialization process includes: Load the permission configuration table and routing policy information stored locally or synchronized from the cloud during the last startup. This information is typically stored in the non-volatile memory of the vehicle-mounted CCM in the form of files or an embedded database.

[0041] The loaded permission configuration table is parsed and constructed into a permission dictionary in memory. It is preferable to use a two-level nested dictionary structure. The first level key is serviceid, and the second level is the list of allowed funcids (funcIdList) under that serviceid.

[0042] The permission configuration table can be shown in Table 1.1:

[0043] Table 1.1 Permission Configuration Table The authList message format is as follows:

[0044] Table 1.1 authList Message Format The vehicle-side CCM gateway uses a permission dictionary to store control permission information. Conventional logic requires three levels of dictionary nesting. However, in this design, appId and serviceId are guaranteed to be globally unique (funcId is also globally unique, but this business interface can be called by multiple application services, resulting in duplication). Therefore, only two levels of dictionary nesting are needed: serviceId and funcIdList.

[0045] Step S202: After the communication service request passes the permission verification, the routing policy information of the communication service request is determined according to the request service interface identifier. The routing policy information includes the communication protocol, maximum concurrency, and task priority.

[0046] When a request is received from the vehicle application, the system searches for the serviceId in the request protocol header. If the serviceId is not found, it may be because the appId or serviceId permissions are prohibited. If the serviceId is found, the system then searches for it in the corresponding nested funcIdList dictionary. If the funcId is not found, then the permissions for that funcId are prohibited.

[0047] The in-vehicle gateway listens for and receives communication service requests from various applications running on the vehicle's main unit. These requests follow internal protocol formats. Simultaneously, the gateway also receives downlink requests from the cloud processor (via the cloud device gateway), which follow external protocol formats.

[0048] After the permission verification is passed, the routing policy information is determined based on the requested business interface identifier.

[0049] After successful authorization, the routing policy module is triggered. This module extracts the `funcid` from the request header and uses it as the key to query the routing policy dictionary in memory. The routing policy dictionary includes:

[0050] Table 1.3 Routing Policy Dictionary The routeList includes:

[0051] Table 1.4 RouteList Message Format When a communication service request is received and the permissions are verified, the system checks the routing policy dictionary to see if a routing policy is set. If no routing policy is set, the system processes the request according to the default value. If a routing policy is set, the system processes the communication service request according to the routing policy information.

[0052] The routing policy module is configured with concurrency control. Specifically, the routing policy dictionary maintained by the routing policy module contains a quota dictionary, which is used to represent the remaining quota for the maximum concurrency.

[0053] When a communication service request is received, the module queries the current quota value.

[0054] If the current quota value is greater than 0, then the operation of "quota value = quota value - 1" is performed, and the request is then allowed to continue. This "decrement by one" operation must be atomic to avoid race conditions under concurrent conditions.

[0055] If the current quota value is 0, the request is immediately rejected, and the requester is returned a response message such as "System busy" or "Concurrency limit exceeded," and the process terminates. This method strictly ensures that the number of requests at the same time will not exceed the preset limit, effectively preventing system overload and network congestion.

[0056] The routing policy module is configured with a protocol conversion module, which performs protocol conversion according to the routing policy and communication direction.

[0057] Communication service requests are divided into uploading communication services and sending communication services.

[0058] When the communication service request is an upload communication service, the internal protocol request packet from the vehicle application is first parsed. Secondly, based on the internal protocol data, add global vehicle identification information to the beginning of the protocol header. This mainly includes: vin (Vehicle Identifier): uniquely identifies a vehicle; devType (Device Type): indicates the onboard host device is a CCM (e.g., a value of 1).

[0059] Then, the protocol header with added VIN and DevType is reassembled with the original message body to form an external protocol request packet. For example, if the external protocol is HTTP, appid, serviceid, funcid, vin, devType, etc., will be used as HTTP headers or URL / Query parameters, and the body will be used as the HTTP body; if it is MQTT, it will be mapped to a specific topic based on funcid, and the assembled data will be used as the payload.

[0060] When the communication service request is an upload communication service, the protocol conversion module strips the vin and devType fields from the external protocol, restores it to the standard internal protocol format, and then forwards it to the target vehicle application.

[0061] The routing strategy module includes a queue sorting function, which is specifically executed by the priority scheduling module. The priority scheduling module determines the task priority of the communication service request and places the protocol-converted request tasks into the corresponding task priority queue. The system maintains multiple priority queues, such as... Figure 3 As shown, for example: Priority 1 queue: Used for urgent and important tasks, such as vehicle safety alarms.

[0062] Priority 2 queue: Used for important but not urgent tasks, such as routine data reporting.

[0063] Priority 3 queue: Used for normal tasks.

[0064] Priority 4 queue: Used for secondary tasks.

[0065] Queues are typically implemented using singly linked lists. In particular, priority 2 task queues are special because they are important but not urgent, and they are inserted at a higher position than ordinary tasks. Therefore, the linked list of the priority 2 queue points to the last priority 2 task in the priority 3 queue. The gateway's sending thread (or thread pool) continuously retrieves tasks from these priority queues and sends them. The scheduling strategy is typically: Tasks in the priority 1 queue are checked and sent first, until that queue is empty; then tasks in the priority 3 queue are checked and sent; finally, tasks in priority 4 and lower queues are processed. This scheduling method ensures that high-priority services receive lower communication latency.

[0066] The routing strategy module sends external protocol requests to the cloud device gateway based on the external protocol (HTTP / MQTT) between the cloud processor and the cloud device. A timeout period is also set. If a successful response is received from the cloud, the routing strategy module converts the response information back to the internal protocol format and returns it to the vehicle-side application that initially initiated the request. If the request times out or fails, the gateway will retry according to a preset retry strategy (such as an exponential backoff algorithm) to avoid exacerbating the pressure on the cloud during temporary failures.

[0067] Step S203: Forward communication service requests according to routing policy information.

[0068] This embodiment introduces a unified in-vehicle gateway and a series of refined management and control mechanisms, unifying the protocols, security, and interface standards for vehicle-to-cloud communication, and reducing the coordination costs associated with multiple developers. Application developers do not need to concern themselves with complex communication protocols and network details, and can focus on business logic development, achieving remote, refined, and real-time control over vehicle-side communication behavior, greatly shortening fault response and handling time.

[0069] The following section provides a detailed introduction and explanation of the solution in this embodiment of the invention, using a specific vehicle-side data reporting scenario as an example: Scenario: The vehicle's scene engine application needs to report a "rapid acceleration" driving event to the cloud-based driving behavior analysis service.

[0070] The scene engine application constructs a communication service request and calls the interface. It assembles the data according to the internal protocol format and sends the request to the vehicle gateway via a local socket.

[0071] The vehicle gateway receives the request, and the access control module extracts the application service identifier and the requested business interface identifier. It then queries the memory permission dictionary, and the verification passes.

[0072] The routing policy module looks up the routing policy dictionary. Assume the found configuration is: tspType=2 (MQTT), tpc=5, priority=2 (important but not urgent), timeout=10 seconds. It checks the current quota of upload_driving_event. Assuming the current quota is 3 (greater than 0), the quota is reduced by 1 to 2, and the request is allowed. The vehicle's VIN (e.g., "LSVAU000012345678") and devType=1 (CCM) are added to the internal protocol header to form the external protocol. Based on the routing policy, the target URL is mapped to an MQTT Topic, such as / vehicle / LSVAU000012345678 / upload_driving_event. Since the priority is 2, the task is placed in the priority 2 queue. The sending thread quickly retrieves the task from the queue and publishes the external protocol data packet to the specified Topic via the established MQTT connection. The cloud service receives the message and processes it. Upon successful processing, the cloud service returns an ACK via MQTT. After receiving the ACK, the gateway will successfully convert the response back to the internal protocol and return it to the scene engine application.

[0073] Please see Figure 4 This application also provides a vehicle-side communication system operating device that can implement the above-described method. The device includes: After receiving a communication service request, the verification module 41 performs permission verification on the vehicle application identifier, application service identifier, or request service interface identifier in the communication service request. The communication service request includes the upload communication service sent by the vehicle host to the cloud processor through the vehicle gateway, and the download communication service sent by the cloud processor to the vehicle host through the vehicle gateway. The strategy module 42 is used to determine the routing strategy information of the communication service request based on the request service interface identifier after the communication service request passes the permission verification. The routing strategy information includes the communication protocol, maximum concurrency, and task priority. The communication module 43 is used to forward the communication service request according to the routing policy information.

[0074] In some embodiments, the policy module 42 is used to update the permission dictionary according to the permission configuration table issued by the cloud processor. The permission configuration table includes a permission version number and a permission list, wherein the permission list includes a mapping relationship between the application identifier, the application service identifier and the request service interface identifier stored in the form of a JSON array. The permission dictionary is used to store the pre-stored access permissions of the communication request service.

[0075] In some embodiments, the communication module 43 is used to acquire internal protocol data of the internal protocol; Based on the internal protocol data, vehicle data is added to generate external protocol data, which includes at least the vehicle identifier and the host identifier. The external protocol is generated based on the external protocol data; The external protocol is used to send communication service requests to the cloud processor.

[0076] It is understood that the content of the above method embodiments is applicable to the present device embodiments. The specific functions implemented by the present device embodiments are the same as those of the above method embodiments, and the beneficial effects achieved are also the same as those achieved by the above method embodiments.

[0077] This application also provides an electronic device, which includes a memory and a processor. The memory stores a computer program, and the processor executes the computer program to implement the above-described method. This electronic device can be any smart terminal, including tablet computers, in-vehicle computers, etc.

[0078] It is understood that the content of the above method embodiments is applicable to this device embodiment. The specific functions implemented by this device embodiment are the same as those of the above method embodiments, and the beneficial effects achieved are also the same as those achieved by the above method embodiments.

[0079] Please see Figure 5 , Figure 5 The hardware structure of an electronic device according to another embodiment is illustrated. The electronic device includes: The processor 501 can be implemented using a general-purpose CPU (Central Processing Unit), microprocessor, application-specific integrated circuit (ASIC), or one or more integrated circuits, and is used to execute relevant programs to implement the technical solutions provided in the embodiments of this application. The memory 502 can be implemented as a read-only memory (ROM), a static storage device, a dynamic storage device, or a random access memory (RAM). The memory 502 can store the operating system and other applications. When the technical solutions provided in the embodiments of this specification are implemented through software or firmware, the relevant program code is stored in the memory 502 and is called and executed by the processor 501 using the methods described in the embodiments of this application. The input / output interface 503 is used to implement information input and output; The communication interface 504 is used to enable communication and interaction between this device and other devices. Communication can be achieved through wired means (such as USB, network cable, etc.) or wireless means (such as mobile network, WIFI, Bluetooth, etc.). Bus 505 transmits information between various components of the device (e.g., processor 501, memory 502, input / output interface 503, and communication interface 504); The processor 501, memory 502, input / output interface 503, and communication interface 504 are connected to each other within the device via bus 505.

[0080] This application also provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the above-described method.

[0081] It is understood that the content of the above method embodiments is applicable to this storage medium embodiment. The specific functions implemented in this storage medium embodiment are the same as those in the above method embodiments, and the beneficial effects achieved are also the same as those achieved in the above method embodiments.

[0082] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the above-described method.

[0083] It is understood that the content of the above method embodiments is applicable to the embodiments of this program product. The specific functions implemented by the embodiments of this program product are the same as those of the above method embodiments, and the beneficial effects achieved are also the same as those achieved by the above method embodiments.

[0084] Memory, as a non-transitory computer-readable storage medium, can be used to store non-transitory software programs and non-transitory computer-executable programs. Furthermore, memory may include high-speed random access memory, and may also include non-transitory memory, such as at least one disk storage device, flash memory device, or other non-transitory solid-state storage device. In some embodiments, memory may optionally include memory remotely located relative to the processor, and these remote memories can be connected to the processor via a network. Examples of such networks include, but are not limited to, the Internet, intranets, local area networks, mobile communication networks, and combinations thereof.

[0085] This application provides a vehicle-to-everything (V2X) communication system, operating method, and related equipment. By introducing a unified vehicle gateway, it achieves standardization of the vehicle-to-cloud communication protocol, fine-grained control of permissions, intelligent traffic scheduling, and effective resource isolation, significantly reducing development complexity and improving system reliability and maintainability.

[0086] The embodiments described in this application are for the purpose of more clearly illustrating the technical solutions of the embodiments of this application, and do not constitute a limitation on the technical solutions provided by the embodiments of this application. As those skilled in the art will know, with the evolution of technology and the emergence of new application scenarios, the technical solutions provided by the embodiments of this application are also applicable to similar technical problems.

[0087] Those skilled in the art will understand that the technical solutions shown in the figures do not constitute a limitation on the embodiments of this application, and may include more or fewer steps than shown, or combine certain steps, or different steps.

[0088] The device embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate; that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs.

[0089] Those skilled in the art will understand that all or some of the steps in the methods disclosed above, as well as the functional modules / units in the systems and devices, can be implemented as software, firmware, hardware, or appropriate combinations thereof.

[0090] The terms “first,” “second,” “third,” “fourth,” etc. (if present) in the specification and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of this application described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms “comprising” and “having,” and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0091] It should be understood that in this application, "at least one (item)" means one or more, and "more than" means two or more. "And / or" is used to describe the relationship between related objects, indicating that three relationships can exist. For example, "A and / or B" can represent three cases: only A exists, only B exists, and both A and B exist simultaneously, where A and B can be singular or plural. The character " / " generally indicates that the preceding and following related objects are in an "or" relationship. "At least one (item) of the following" or similar expressions refer to any combination of these items, including any combination of single or plural items. For example, at least one (item) of a, b, or c can represent: a, b, c, "a and b", "a and c", "b and c", or "a and b and c", where a, b, and c can be single or multiple.

[0092] In the several embodiments provided in this application, it should be understood that the disclosed apparatus and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of the units described above is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between apparatuses or units may be electrical, mechanical, or other forms.

[0093] The units described above as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0094] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0095] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes multiple instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods of the various embodiments of this application. The aforementioned storage medium includes various media capable of storing programs, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0096] The preferred embodiments of the present application have been described above with reference to the accompanying drawings, but this does not limit the scope of the claims of the present application. Any modifications, equivalent substitutions, and improvements made by those skilled in the art without departing from the scope and substance of the embodiments of the present application shall be within the scope of the claims of the present application.

Claims

1. A vehicle-to-vehicle communication system, characterized in that, The system comprises: an in-vehicle gateway installed in a vehicle, the in-vehicle gateway connected to an in-vehicle host, and the in-vehicle gateway connected to a cloud processor; The access control module is configured to perform access verification based on the vehicle application identifier, application service identifier, or request service interface identifier in the communication service request when a communication service request is received, and to determine the access permissions of the communication service request through an access whitelist mechanism. The routing strategy module, connected to the access control module, is configured to determine the routing strategy information of the communication service request based on the access permissions of the communication service request. The routing strategy information includes the communication protocol, maximum concurrency, and task priority. The module forwards the communication service request according to the routing strategy information. When configuring the routing strategy information, the routing strategy module allocates the communication service request to task queues of different priorities.

2. The system according to claim 1, characterized in that, The routing strategy module is configured to send communication service requests in different priority queues. The communication service requests are divided into first priority, second priority and third priority according to their priority. When the priority of the target communication service request is higher than the second priority and lower than the first priority, the routing strategy module is configured to allocate the target communication service request to the front of the second priority queue.

3. The system according to claim 1, characterized in that, The permission control module is configured to update the permission dictionary based on the permission configuration table issued by the cloud processor. The permission configuration table includes a permission version number and a permission list. The permission list includes a mapping relationship between the application identifier, the application service identifier, and the request business interface identifier stored in the form of a JSON array. The permission control module is configured to use the permission dictionary to determine the access permissions of the communication request business request.

4. The system according to claim 1, characterized in that, The communication service requests are upload communication services and download communication services. The upload communication service is when the vehicle host sends information to the cloud processor through the vehicle gateway. The download communication service is when the cloud processor sends information to the vehicle host through the vehicle gateway. The communication protocol includes an internal protocol and an external protocol. The internal protocol supports communication between the vehicle host and the vehicle gateway. The external protocol is used to support communication between the vehicle gateway and the cloud processor. The routing strategy module is configured to convert the internal protocol of the upload communication service into an external protocol when executing the upload communication service; and to convert the external protocol of the download communication service into an internal protocol when executing the download communication service. The internal protocol includes at least one of a message identifier, a timestamp, and an associated message identifier, and the external protocol includes at least one of a vehicle identifier, a host identifier, a message identifier, a timestamp, and an associated message identifier.

5. The system according to claim 1, characterized in that, The routing strategy module is configured to set a quota dictionary, which displays at least the optional concurrency of the vehicle application identifier, the application service identifier, or the request service interface identifier. The optional concurrency is modified according to the occupancy of the communication service requests.

6. A method for operating a vehicle-to-everything (V2X) communication system, characterized in that, An application for an in-vehicle gateway, wherein the in-vehicle gateway is installed in a vehicle, the in-vehicle gateway is connected to an in-vehicle host, and the in-vehicle gateway is connected to a cloud processor, comprising: Upon receiving a communication service request, the vehicle application identifier, application service identifier, or request service interface identifier in the communication service request are subject to permission verification. The communication service request includes an upload communication service sent by the vehicle host to the cloud processor through the vehicle gateway, and a download communication service sent by the cloud processor to the vehicle host through the vehicle gateway. After the communication service request passes the permission verification, the routing policy information of the communication service request is determined according to the request service interface identifier. The routing policy information includes the communication protocol, maximum concurrency, and task priority. The communication service request is forwarded according to the routing policy information.

7. The method according to claim 6, characterized in that, Before performing permission verification on the vehicle application identifier, application service identifier, or requested service interface identifier in the communication service request after receiving the communication service request, the method further includes: According to the permission configuration table issued by the cloud processor, the permission dictionary is updated. The permission configuration table includes a permission version number and a permission list. The permission list includes a mapping relationship between the application identifier, the application service identifier and the request business interface identifier stored in the form of a JSON array. The permission dictionary is used to store the pre-stored access permissions of the communication request business.

8. The method according to claim 6, characterized in that, The communication service request is an upload communication service sent by the vehicle host to the cloud processor through the vehicle gateway, and when the routing policy information is a communication protocol, the communication protocol includes internal protocols and external protocols. Forwarding the communication service request according to the routing policy information includes: Obtain the internal protocol data of the aforementioned internal protocol; The internal protocol data is modified using vehicle data to generate external protocol data, which includes at least a vehicle identifier and a host identifier. The external protocol is generated based on the external protocol data; The external protocol is used to send communication service requests to the cloud processor.

9. A vehicle-side communication system operating device, characterized in that, The device includes: The verification module, upon receiving a communication service request, performs permission verification on the vehicle application identifier, application service identifier, or requested service interface identifier in the communication service request. The communication service request includes an upload communication service sent by the vehicle host to the cloud processor through the vehicle gateway, and a download communication service sent by the cloud processor to the vehicle host through the vehicle gateway. The strategy module is used to determine the routing strategy information of the communication service request based on the request service interface identifier after the communication service request passes the permission verification. The routing strategy information includes the communication protocol, maximum concurrency, and task priority. The communication module is used to forward the communication service request according to the routing policy information.

10. An electronic device, characterized in that, The electronic device includes a memory and a processor, the memory storing a computer program, and the processor executing the computer program to implement the method of any one of claims 6 to 8.

Images