Vehicle-end and cloud-end communication processing method and device, electronic equipment and storage medium

Abstract

Embodiments of the present application provide a communication processing method and device between a vehicle end and a cloud end, electronic equipment and a storage medium. The method comprises: in response to a received first service request, obtaining a protocol identifier of a vehicle end SDK; obtaining a latest target SDK protocol corresponding to the protocol identifier; converting the first service request into a second service request according to the target SDK protocol; and sending the second service request to the cloud end SDK. Through the embodiments of the present application, the request compatibility of multiple communication protocols between the vehicle end and the cloud end is realized.

Description

Technical Field

[0001] This invention relates to the field of data processing technology, and in particular to a vehicle-to-cloud communication processing method, a vehicle-to-cloud communication processing device, an electronic device, and a computer-readable storage medium. Background Technology

[0002] With the development of computer technology and the popularization of miniaturized computer equipment, high-performance computers have gradually begun to be widely used in the field of vehicle systems. The business demand for in-vehicle high-performance computer services has begun to grow explosively, and the corresponding need to manage these service interfaces has emerged.

[0003] Currently available service interface management tools on the market are mostly geared towards mobile devices or desktop devices, and cannot smoothly support the vehicle-to-cloud (V2X) link, resulting in poor compatibility. Summary of the Invention

[0004] In view of the above problems, a vehicle-to-cloud communication processing method, a vehicle-to-cloud communication processing apparatus, an electronic device, and a computer-readable storage medium are proposed to overcome or at least partially solve the above problems, comprising:

[0005] This invention provides a communication processing method between a vehicle and the cloud, applied to a vehicle, the method comprising:

[0006] In response to the first received service request, obtain the protocol identifier of the vehicle-side SDK;

[0007] Obtain the latest target SDK protocol corresponding to the protocol identifier;

[0008] The first service request is converted into a second service request according to the target SDK protocol;

[0009] The second service request is sent to the cloud SDK.

[0010] Optionally, it also includes:

[0011] Receive the first response data sent by the cloud SDK in response to the second service request;

[0012] The first response data is verified in accordance with the target SDK protocol;

[0013] Upon successful verification, the first response data is parsed according to the target SDK protocol to obtain the business service result corresponding to the first business request.

[0014] Optionally, parsing the first response data according to the target SDK protocol to obtain the service result corresponding to the first service request includes:

[0015] Obtain the response data format defined by the target SDK protocol;

[0016] The service results are parsed from the first response data according to the specified response data format.

[0017] Optionally, the step of verifying the first response data according to the target SDK protocol includes:

[0018] Determine the preset verification method according to the target SDK protocol;

[0019] The first verification information is determined from the first response data according to the verification method described above;

[0020] Verification is performed based on the first verification information and the second verification information obtained by the vehicle.

[0021] Optionally, it also includes:

[0022] Determine the interception configuration items based on the target SDK protocol;

[0023] Determine the interception interface according to the aforementioned interception configuration items;

[0024] Obtain the status information of the interception interface. When the status information is in the maintenance state, execute the preset abnormal interception processing.

[0025] Optionally, it also includes:

[0026] Obtain the timestamp of the first service request;

[0027] Obtain historical query rate data per second based on the timestamp;

[0028] The historical query rate per second data is used as the input value of a preset prediction function to obtain the predicted query rate per second data;

[0029] Determine whether the predicted query rate per second data matches the query rate per second data that the vehicle-side SDK can support;

[0030] If the predicted query rate per second data and the vehicle-side SDK's capacity query rate per second data do not match, the vehicle-side SDK will be scaled down or expanded.

[0031] This invention also provides a communication processing method between a vehicle and the cloud, applied in the cloud, the method comprising:

[0032] In response to the received second service request, obtain the protocol identifier of the vehicle-side SDK;

[0033] Obtain the latest target SDK protocol corresponding to the protocol identifier;

[0034] The second service request is verified in accordance with the target SDK protocol.

[0035] After the verification is passed, the second service request is processed in accordance with the target SDK protocol to generate the first response data;

[0036] The first response data is sent to the vehicle-side SDK.

[0037] This invention also provides a communication processing device between a vehicle and the cloud, applied to a vehicle, the device comprising:

[0038] The first protocol identifier acquisition module is used to obtain the protocol identifier of the vehicle-side SDK in response to the received first service request;

[0039] The first SDK protocol acquisition module is used to acquire the latest target SDK protocol corresponding to the protocol identifier;

[0040] The second service request generation module is used to convert the first service request into a second service request according to the target SDK protocol;

[0041] The second service request sending module is used to send the second service request to the cloud SDK.

[0042] This invention also provides a communication processing method between a vehicle and the cloud, applied in the cloud, the method comprising:

[0043] The second protocol identifier acquisition module is used to obtain the protocol identifier of the vehicle-side SDK in response to the received second service request;

[0044] The second SDK protocol acquisition module is used to acquire the latest target SDK protocol corresponding to the protocol identifier;

[0045] The second service request verification module is used to verify the second service request in accordance with the target SDK protocol;

[0046] The first response data generation module is used to process the second service request according to the target SDK protocol after the verification is passed, and generate the first response data.

[0047] The first response data sending module is used to send the first response data to the vehicle-side SDK.

[0048] This invention also provides an electronic device, including a processor, a memory, and a computer program stored in the memory and capable of running on the processor. When the computer program is executed by the processor, it implements the above-described vehicle-to-cloud communication processing method.

[0049] This invention also provides a computer-readable storage medium storing a computer program, which, when executed by a processor, implements the above-described vehicle-to-cloud communication processing method.

[0050] The embodiments of the present invention have the following advantages:

[0051] In this embodiment of the invention, the vehicle can obtain the protocol identifier of the vehicle SDK in response to a received first service request; obtain the latest target SDK protocol corresponding to the protocol identifier; and then convert the first service request into a second service request according to the target SDK protocol, and send the second service request to the cloud SDK. Thus, the vehicle can convert the generated first service request according to the latest target SDK protocol, and the cloud can also process the converted second service request according to the latest target SDK protocol. Therefore, the vehicle and the cloud are not limited to a fixed communication protocol, and can communicate between the vehicle and the cloud based on different SDK protocols, realizing request compatibility between multiple communication protocols between the vehicle and the cloud. Attached Figure Description

[0052] To more clearly illustrate the technical solution of the present invention, the accompanying drawings used in the description of the present invention will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0053] Figure 1a This is a flowchart illustrating the steps of a vehicle-to-cloud communication processing method according to an embodiment of the present invention.

[0054] Figure 1b This is a schematic diagram of a business request processing logic according to an embodiment of the present invention;

[0055] Figure 1c This is a schematic diagram of another business request processing logic according to an embodiment of the present invention;

[0056] Figure 1d This is a schematic diagram of an automatic expansion / contraction process according to an embodiment of the present invention;

[0057] Figure 2 This is a flowchart of another communication processing method between the vehicle and the cloud according to an embodiment of the present invention;

[0058] Figure 3 This is a flowchart of another communication processing method between the vehicle and the cloud according to an embodiment of the present invention;

[0059] Figure 4 This is a structural flowchart of another vehicle-to-cloud communication processing device according to an embodiment of the present invention;

[0060] Figure 5 This is a structural flowchart of another vehicle-to-cloud communication processing device according to an embodiment of the present invention. Detailed Implementation

[0061] To make the above-mentioned objects, features, and advantages of the present invention more apparent and understandable, the present invention will be further described in detail below with reference to the accompanying drawings and specific embodiments. Obviously, the described embodiments are only some, not all, of the embodiments of the present invention. All other embodiments obtained by those skilled in the art based on the embodiments of the present invention without inventive effort are within the scope of protection of the present invention.

[0062] Reference Figure 1a The diagram illustrates a flowchart of a vehicle-to-cloud communication processing method according to an embodiment of the present invention. Applied to a vehicle, it may include the following steps:

[0063] Step S101: In response to the received first service request, obtain the protocol identifier of the vehicle-side SDK (Software Development Kit);

[0064] In practical applications, the vehicle-side refers to the onboard computer within the vehicle. An onboard computer is a multifunctional electronic device integrated into the vehicle, primarily used to enhance the driving experience, vehicle management, and passenger entertainment. The specific functions of an onboard computer may include any one or more of the following:

[0065] Navigation and positioning, entertainment functions, communication connectivity, vehicle information display, driving assistance, voice control, voice control.

[0066] The vehicle computer can be equipped with a vehicle-side SDK, which is a toolkit for developing applications for the vehicle system. It can provide APIs (Application Programming Interfaces), libraries, documentation, and sample code to help developers create applications that integrate with vehicle hardware and software.

[0067] The API interfaces provide access to in-vehicle hardware (such as GPS, cameras, and sensors) and software functions (such as navigation and entertainment systems). Development tools can include simulators and debugging tools to help developers test their applications. Documentation and sample code provide development guidelines and examples to reduce development difficulty. Additionally, security mechanisms can be configured in the vehicle-side SDK to provide data encryption, authentication, and other functions to ensure application security.

[0068] The functions of the vehicle-side SDK can include: (i) helping developers quickly integrate the functions of the vehicle system; (ii) providing standardized interfaces to reduce development complexity; and (iii) supporting interaction with vehicle hardware (such as CAN bus and sensors).

[0069] The vehicle-side SDK defines an SDK protocol, a set of rules and standards that specifies how developers interact with the in-vehicle system, including data formats, communication methods, and API call specifications. Specifically, the communication protocol defines the communication methods between the in-vehicle system and the application (e.g., HTTP, WebSocket, CAN bus protocol). The data format specifies the data transmission format (e.g., JSON, XML, binary). The API specification clarifies the API calling methods, parameters, and return values. The security specification defines security mechanisms such as data encryption and authentication.

[0070] In this embodiment of the invention, the vehicle and the cloud interact through the vehicle SDK, the cloud SDK, and the communication protocol used by the vehicle SDK and the cloud SDK. The communication protocol used by the vehicle SDK and the cloud SDK is the SDK protocol in this embodiment of the invention.

[0071] In practical applications, relevant SDK data can be pre-configured on the vehicle side, such as the SDK protocol identifier, which is the protocol ID of the SDK protocol and is unique.

[0072] When the vehicle receives the first service request from the user, this request may be a service request associated with the cloud, requiring data transmission between the cloud and the vehicle. At this time, the protocol identifier of the vehicle's SDK can be obtained to invoke the vehicle's SDK protocol through this protocol identifier. The cloud and the vehicle share the same SDK protocol.

[0073] In practical applications, SDK protocol settings may include, but are not limited to, the following:

[0074] Request method: Defines which communication protocol, such as HTTP, is used for the interface requests that need to be proxied.

[0075] Method: The method used to request the interface, such as HTTP POST.

[0076] Path: The path to the requested interface. In HTTP, this is the request URI; in Dubbo, it is the method path.

[0077] Parameter list: The parameter list of the proxied interface, in array form.

[0078] Return value: A list of specific properties of the returned class of the proxied interface, in array format.

[0079] Description: Description information of the proxied interface.

[0080] Plugin information: Optional content. This part is defined when the proxy interface needs to use a plugin. It is in class form.

[0081] Version: The version number of the protocol, used for cloud authentication and vehicle-side maintenance verification.

[0082] The detailed format of the parameter list, return value plugin, and other related sections is as follows:

[0083] Name: Defines the name of the property.

[0084] Type: Defines the attribute type.

[0085] Coordinates: Defines the coordinates of the attribute in the return value or input parameter. Optional.

[0086] Placement: Optional field, defines the parameter location, exclusive to the parameter list.

[0087] Default value: Not required. When this field is empty in the definition of input parameters or return value, the default value will be used.

[0088] Mock value: Optional field, used as an alternative value when defining a request as mock mode.

[0089] Description: Optional field, describing the attribute.

[0090] Fixed value: Not required, it defines the attribute as a constant value.

[0091] Required field validation: Non-required fields, define whether attribute values ​​require mandatory field validation.

[0092] Member list: Not required. When the attribute is a complex type such as object or array, expand the detailed information.

[0093] Success indicator: Not a required field, unique to the return value, verifies whether the status code of the return value is the provided status code.

[0094] Value mapping: Optional field, specific to the return value, replaces the mapping relationship of status codes.

[0095] Step S102: Obtain the latest target SDK protocol corresponding to the protocol identifier;

[0096] Typically, the cloud uses the latest version of the SDK protocol, while the vehicle's SDK protocol may not be the latest version, for example, in scenarios where the vehicle system is an older version. Therefore, after obtaining the protocol identifier, to ensure that the cloud and vehicle use the same SDK protocol, it is necessary to obtain the latest SDK protocol according to the protocol identifier. In practical applications, the latest SDK protocol can be provided through SDK toolkits. The vehicle-side SDK is the specific implementation of the SDK toolkit in in-vehicle system development, specifically designed for developing applications that integrate with vehicle hardware and software. The cloud SDK is the specific implementation of the SDK toolkit in cloud service development, specifically designed for developing applications that interact with cloud services. Specifically, by connecting the SDK toolkit to the vehicle or cloud, the vehicle or cloud can obtain the latest configured protocol through the protocol services of the SDK toolkit. This method facilitates rapid service access, and the SDK toolkit can be set in a plug-and-play access component.

[0097] Step S103: Convert the first service request into a second service request according to the target SDK protocol;

[0098] After obtaining the target SDK protocol, the format of the first business request can be converted using the target SDK protocol to obtain the second business request. By converting business requests through the SDK protocol, compatibility with various different business requests can be achieved. Thus, based on the SDK protocol shared between the vehicle and the cloud, it is compatible with the description specifications of all interfaces in the existing vehicle-cloud link and cloud-link, facilitating the management of all SDK interfaces.

[0099] Step S104: Send the second business request to the cloud SDK.

[0100] In practical applications, a cloud SDK can be configured in the cloud. The cloud is a platform that provides computing, storage, and networking services, while the cloud SDK is a toolkit used by developers to access and operate these services. Data interaction between the vehicle and the cloud can be achieved based on both the vehicle SDK and the cloud SDK.

[0101] Therefore, after generating the second business request, the business request can be sent directly to the cloud SDK for business processing in the cloud based on the latest SDK protocol.

[0102] like Figure 1b This is a schematic diagram of a business request processing logic in an embodiment of the present invention. Specifically, it includes the following process:

[0103] The cloud-based or vehicle-side SDK protocol is developed and sent to the interface operation and management platform via the office network gateway. The platform then reports the interface to the business backend service based on the protocol service. Simultaneously, the protocol service can push new protocols to the vehicle-side app or in-vehicle infotainment system. Furthermore, the protocol service can obtain and manage the latest version of the protocol currently used by the in-vehicle app or service, such as modifying its content. When the in-vehicle app or service receives the first business request, it can convert the first business request into an actual request (i.e., the second business request) based on the latest SDK protocol from the business backend service and send it to the third-party cloud service for processing. In practical applications, the first business request can be validated; only after successful validation can the request be allowed.

[0104] Specifically, LI-MESH can push protocols to in-vehicle apps or services. Based on the Bluetooth Mesh protocol, LI-MESH extends the traditional point-to-point communication mode to support many-to-many communication. LI-MESH transmits messages through broadcast and flooding mechanisms, allowing nodes to forward messages to each other, thereby expanding network coverage.

[0105] In one embodiment of the present invention, interception configuration items are determined based on the target SDK protocol; interception interfaces are determined according to the interception configuration items; status information of the interception interfaces is obtained, and when the status information is in the maintenance state, preset abnormal interception processing is performed.

[0106] In practical applications, a unified exception interception and handling mechanism can be configured for the integrated SDK. Specifically, developers can specify the interception path to intercept interface data by reading configuration items; otherwise, the default path will be selected. When the intercepted interface is already under maintenance in the system, the request context log can be automatically printed, and a unified exception interception and handling mechanism can be provided. The handling method can provide a default handling method, or a custom implementation can be used to replace the default value.

[0107] like Figure 1c This diagram illustrates another business request processing logic in an embodiment of the present invention, specifically including the following process: After a request begins, it is determined whether the developer is within the scope of an aspect. Specifically, this can be achieved by intercepting the request using Aspect-Oriented Programming (AOP) to determine whether the current request is within the defined scope of an aspect. The scope of an aspect can be defined through annotations, configuration files, or code logic. By determining whether the current request is within the defined scope of an aspect, the execution scope of the logic can be controlled, ensuring that request operations are executed only under specific conditions, thereby improving the flexibility, maintainability, and security of the code.

[0108] When the developer is within the scope of the aspect, it indicates that the request is executable under the current conditions. Therefore, the corresponding protocol ID can be obtained based on the path. The system then determines whether the protocol ID was successfully obtained. If retrieval fails, it means the protocol ID is not registered, and the ID value defaults to 0. The start time and input parameters are recorded, and the corresponding business logic is executed. During business logic processing, it checks for exceptions. If the business logic is normal, the end time is recorded, and a success log is printed to the specified target file. If the business logic is abnormal, the end time and exception information are recorded, and unified exception handling is implemented, printing a failure log to the specified directory file.

[0109] In one embodiment of the present invention, the timestamp of the first service request is obtained; historical query rate data per second is obtained according to the timestamp; the historical query rate data per second is used as the input value of a preset prediction function to obtain predicted query rate data per second; it is determined whether the predicted query rate data per second matches the query rate data that the vehicle-side SDK can support; when it is determined that the predicted query rate data per second does not match the query rate data that the vehicle-side SDK can support, the vehicle-side SDK is scaled down or expanded.

[0110] In practical applications, the query data per second in the future can be predicted based on the query data per second in the past period, and then the capacity can be reduced or expanded according to the prediction results and the capacity of the device itself.

[0111] For example, for interfaces that have already been connected, the SDK will automatically report request logs and intelligently predict request QPS (Queries Per Second). Based on the request time, the maximum QPS per minute from the previous week to the current time is taken as the input for prediction. The SLS prediction function is used to calculate the QPS value for the next 5 minutes. Then, the value of these 5 minutes is multiplied by a fixed coefficient to obtain the predicted QPS value. Based on this predicted QPS and the configured QPS value that a single machine can handle, it is determined whether to scale down or up.

[0112] Reference Figure 1dThis diagram illustrates an automatic scaling-up / scaling process according to an embodiment of the present invention. The specific process is as follows: First, the number of machines and the dynamic scaling-up range configuration are obtained. Then, the maximum QPS per minute for the past week is retrieved based on SLS (Simple Log Service). A prediction function is used to estimate the end time over 5 minutes. It is then determined whether a predicted value is generated. If no predicted value is generated, an alarm is triggered and the process exits. If a predicted value exists, the predicted value is averaged and multiplied by a coefficient to obtain the prediction result. Next, it is determined whether the current serviceable range QPS of the device meets the prediction requirements. If it does, the process exits. If it does not, and scaling up or down is required, the number of machines after scaling up or down can be calculated. Then, it is determined whether to enable the dynamic scaling-up / scaling. If enabled, the number of machines is adjusted based on the dynamic scaling-up / scaling. If not enabled, the calculated number of machines is adjusted.

[0113] In this embodiment of the invention, based on the SDK protocol settings, it is also possible to complete integrated viewing, operation, debugging, maintenance and other business through a single platform, thereby integrating common operational functions into one: common interface documentation maintenance, log collection and query, monitoring, alarms, dashboard viewing, rate limiting and degradation, automated early warning, third-party dependency packaging, plugins and other functions.

[0114] The specific functions are described below:

[0115] (1) Degradation and rate limiting based on access SDK: The Sentinel component is encapsulated for interfaces that are already maintained in the system, and degradation and rate limiting functions are provided based on interface configuration.

[0116] (2) Log collection: Request log collection based on access SDK: The interface SDK performs aspect on the interface requests maintained in the system and prints request log information. The log SDK prints in a specified format. After the logs are collected by the SLS component, the service logs are filtered out in the SLS service.

[0117] (3) Multiple functions of the operating platform:

[0118] The operation protocol page: Based on the protocol maintained by the interface backend, it provides query, save, edit, and batch import functions. MOCK request: Based on the protocol maintained by the interface backend, it uses the value of the mock field (a placeholder field used in software development to simulate data or behavior) in the protocol to replace the return value, providing a MOCK interface accessible to the vehicle system.

[0119] Log Query: Based on the query capabilities provided by the log platform, this function encapsulates the context log query functionality of the platform's interfaces.

[0120] Monitoring dashboards and overall system dashboards: Based on SDK logs, provide monitoring dashboards such as request QPS and issue statistics.

[0121] Alarms: Based on SDK logs, alarms for issues of interest can be configured in the alarm system.

[0122] (4) Safety:

[0123] Operations page authentication request: Integrate with company-level authentication components and specify visible areas and content by configuring permissions.

[0124] Gateway filtering and interception: The interface is configured in the gateway, which is responsible for filtering and intercepting blacklisted parameters that do not conform to the request rules.

[0125] Request header processing: For HTTP requests, the integration SDK provides header processing, extracts the X-CHJ request header (the X-CHJ request header is a predefined request header field name used to parse vehicle model information), parses the vehicle model information, and facilitates parameter verification by users.

[0126] In this embodiment of the invention, the vehicle can obtain the protocol identifier of the vehicle SDK in response to the received first service request; obtain the latest target SDK protocol based on the protocol identifier; then convert the first service request into a second service request according to the target SDK protocol; and send the second service request to the cloud SDK, thereby achieving request compatibility between the vehicle and the cloud for multiple communication protocols.

[0127] Reference Figure 2 The diagram illustrates a flowchart of another vehicle-to-cloud communication processing method according to an embodiment of the present invention. Applied to the vehicle, it may include the following steps:

[0128] Step S201: In response to the received first service request, obtain the protocol identifier of the vehicle-side SDK;

[0129] Step S202: Obtain the latest target SDK protocol corresponding to the protocol identifier;

[0130] Step S203: Convert the first service request into a second service request according to the target SDK protocol;

[0131] Step S204: Send the second service request to the cloud SDK;

[0132] Step S205: Receive the first response data sent by the cloud SDK in response to the second service request;

[0133] After the vehicle sends a second service request to the cloud SDK, the cloud SDK can process the second service request and obtain the first response data corresponding to the second service request. The first response data includes the service processing result of the second service request. Then, the first response data is sent back to the vehicle.

[0134] Step S206: Verify the first response data according to the target SDK protocol;

[0135] In practical applications, to ensure the security of data transmission, security checks can be set in the first response data. The specific check logic can be set in the target SDK protocol.

[0136] In one embodiment of the present invention, verifying the first response data according to the target SDK protocol includes: determining a preset verification method according to the target SDK protocol; determining first verification information from the first response data according to the verification method; and performing verification based on the first verification information and the second verification information obtained by the vehicle.

[0137] In practical applications, to ensure data security, verification methods can be set, such as setting the SDK's signature and VIN verification in the data for verification.

[0138] Step S207: When the verification is successful, the first response data is parsed according to the target SDK protocol to obtain the business service result corresponding to the first business request.

[0139] If the verification passes, the data is confirmed to be secure, and further data parsing can be performed to obtain the results from the business server.

[0140] In one embodiment of the present invention, parsing the first response data according to the target SDK protocol to obtain the service result corresponding to the first service request includes: obtaining the response data format defined by the target SDK protocol; and parsing the service result from the first response data according to the response data format.

[0141] In this embodiment of the invention, the following measures can be adopted to ensure data security:

[0142] The security measures are as follows:

[0143] 1. The vehicle-mounted SDK and cloud SDK are not open-source SDKs. Their source code is protected by the company's security components and packaged using components provided by the company's security group.

[0144] 2. The plugins used in the SDK complete business logic such as signing, and the signing key is distributed through a dedicated limesh channel.

[0145] 3. The plugin is updated with OTA version. The plugin can complete the signature encapsulation logic of business requests. The business side is unaware of it and cannot easily view its original logic.

[0146] 4. The requests proxied by the SDK carry the SDK's request signature, and upstream and downstream services using the SDK can authenticate through the signature.

[0147] 5. The SDK proxy's request contains an encrypted vehicle VIN code, which can be used to trace the origin of the request.

[0148] In this embodiment of the invention, the vehicle can obtain the protocol identifier of the vehicle SDK in response to the received first service request; obtain the latest target SDK protocol corresponding to the protocol identifier; then convert the first service request into a second service request according to the target SDK protocol; and send the second service request to the cloud SDK. This achieves request compatibility between the vehicle and the cloud for multiple communication protocols. At the same time, the received response data can be verified based on the SDK protocol to ensure data security.

[0149] Reference Figure 3 The diagram illustrates a flowchart of another communication processing method between the vehicle and the cloud according to an embodiment of the present invention. Applied to the cloud, it may include the following steps:

[0150] Step S301: In response to the received second service request, obtain the protocol identifier of the vehicle-side SDK;

[0151] Step S302: Obtain the latest target SDK protocol corresponding to the protocol identifier;

[0152] The SDK protocol set up in the cloud is used to interact with the vehicle. In order to ensure the compatibility of requests for multiple communication protocols between the cloud and the vehicle, the latest target SDK protocol can be obtained according to the protocol identifier of the vehicle SDK, so as to parse the second business request based on the SDK protocol.

[0153] Step S303: Verify the second service request according to the target SDK protocol;

[0154] Step S304: After the verification is passed, the second business request is processed in accordance with the target SDK protocol to generate the first response data;

[0155] Step S305: Send the first response data to the vehicle-side SDK.

[0156] In this embodiment of the invention, by receiving a second response request and verifying the request based on the SDK protocol, and then performing business processing, it is possible to achieve request compatibility between multiple communication protocols between the vehicle and the cloud. At the same time, the received response data can be verified based on the SDK protocol to ensure data security.

[0157] It should be noted that, for the sake of simplicity, the method embodiments are all 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.

[0158] Reference Figure 4 The diagram illustrates a structural schematic of a vehicle-to-cloud communication processing device according to an embodiment of the present invention. Applied to a vehicle, it may include the following modules:

[0159] The first protocol identifier acquisition module 401 is used to acquire the protocol identifier of the vehicle-side SDK in response to the received first service request.

[0160] The first SDK protocol acquisition module 402 is used to acquire the latest target SDK protocol corresponding to the protocol identifier;

[0161] The second service request generation module 403 is used to convert the first service request into a second service request according to the target SDK protocol;

[0162] The second service request sending module 404 is used to send the second service request to the cloud SDK.

[0163] In an optional embodiment of the present invention, it further includes:

[0164] The first response data receiving module is used to receive the first response data sent by the cloud SDK in response to the second service request;

[0165] The second verification module is used to verify the first response data in accordance with the target SDK protocol;

[0166] The business service result acquisition module is used to parse the first response data according to the target SDK protocol when the verification is successful, and obtain the business service result corresponding to the first business request.

[0167] In an optional embodiment of the present invention, the business service result acquisition module may include the following sub-modules:

[0168] The response data format acquisition submodule is used to acquire the response data format defined by the target SDK protocol;

[0169] The business server result parsing submodule is used to parse the business service result from the first response data according to the response data format.

[0170] In an optional embodiment of the present invention, the second verification module may include the following sub-modules:

[0171] The verification method determination unit is used to determine a preset verification method according to the target SDK protocol;

[0172] The first verification information determining unit is used to determine first verification information from the first response data according to the verification method;

[0173] The verification subunit is used to perform verification based on the first verification information and the second verification information obtained by the vehicle terminal.

[0174] In an optional embodiment of the present invention, the apparatus further includes:

[0175] An interception configuration item determination module is used to determine interception configuration items based on the target SDK protocol;

[0176] An interception interface determination module is used to determine the interception interface according to the interception configuration items;

[0177] The interception processing module is used to obtain the status information of the interception interface, and to perform interception processing when the status information is in the maintenance state.

[0178] In an optional embodiment of the present invention, the apparatus further includes:

[0179] The timestamp acquisition module is used to acquire the timestamp of the first business request;

[0180] The historical query rate per second data determination module is used to obtain historical query rate per second data according to the timestamp;

[0181] The predictive query rate per second data module is used to take the historical query rate per second data as the input value of a preset prediction function to obtain the predicted query rate per second data;

[0182] The matching module is used to determine whether the predicted query rate per second data and the vehicle-side SDK's load capacity query rate per second data match;

[0183] The scaling-down or scaling-up module is used to scale down or expand the vehicle-side SDK when it is determined that the predicted query rate per second data and the vehicle-side SDK's capacity query rate per second data do not match.

[0184] In this embodiment of the invention, the vehicle can obtain the protocol identifier of the vehicle SDK in response to a received first service request; based on the protocol identifier, it can obtain the latest target SDK protocol, and then convert the first service request into a second service request according to the target SDK protocol, and send the second service request to the cloud SDK, thereby achieving request compatibility between the vehicle and the cloud for multiple communication protocols.

[0185] Reference Figure 5 The diagram illustrates a structural schematic of a vehicle-to-cloud communication processing device according to an embodiment of the present invention. Applied to the cloud, it may include the following modules:

[0186] The second protocol identifier acquisition module 501 is used to acquire the protocol identifier of the vehicle-side SDK in response to the received second service request.

[0187] The second SDK protocol acquisition module 502 is used to acquire the latest target SDK protocol corresponding to the protocol identifier;

[0188] The second service request verification module 503 is used to verify the second service request in accordance with the target SDK protocol;

[0189] The first response data generation module 504 is used to process the second service request according to the target SDK protocol after the verification is passed, and generate the first response data.

[0190] The first response data sending module 505 is used to send the first response data to the vehicle-side SDK.

[0191] In this embodiment of the invention, by receiving a second response request and verifying the request based on the SDK protocol, and then performing business processing, it is possible to achieve request compatibility between multiple communication protocols between the vehicle and the cloud. At the same time, the received response data can be verified based on the SDK protocol to ensure data security.

[0192] This invention also provides an electronic device, including a processor, a memory, and a computer program stored in the memory and capable of running on the processor. When the computer program is executed by the processor, it implements the above-described vehicle-to-cloud communication processing method.

[0193] This invention also provides a computer-readable storage medium storing a computer program, which, when executed by a processor, implements the above-described vehicle-to-cloud communication processing method.

[0194] As the apparatus embodiment is basically similar to the method embodiment, it is described in a relatively simple manner. For relevant details, please refer to the description of the method embodiment.

[0195] The various embodiments in this specification are described in a progressive manner, with each embodiment focusing on the differences from other embodiments. The same or similar parts between the various embodiments can be referred to each other.

[0196] Those skilled in the art will understand that embodiments of the present invention can be provided as methods, apparatus, or computer program products. Therefore, embodiments of the present invention can take the form of entirely hardware embodiments, entirely software embodiments, or embodiments combining software and hardware aspects. Furthermore, embodiments of the present invention can take the form of computer program products implemented on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0197] Embodiments of the present invention are described with reference to flowchart illustrations and / or block diagrams of methods, terminal devices (systems), and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing terminal device to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing terminal device, create means for implementing the functions specified in one or more blocks of the flowchart illustrations and / or one or more blocks of the block diagrams.

[0198] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing terminal device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means that implement the functions specified in one or more flowcharts and / or one or more block diagrams.

[0199] These computer program instructions may also be loaded onto a computer or other programmable data processing terminal equipment to cause a series of operational steps to be performed on the computer or other programmable terminal equipment to produce a computer-implemented process, such that the instructions, which execute on the computer or other programmable terminal equipment, provide steps for implementing the functions specified in one or more flowcharts and / or one or more block diagrams.

[0200] Although preferred embodiments of the present invention have been described, those skilled in the art, upon learning the basic inventive concept, can make other changes and modifications to these embodiments. Therefore, the appended claims are intended to be interpreted as including the preferred embodiments as well as all changes and modifications falling within the scope of the embodiments of the present invention.

[0201] Finally, it should be noted that in this document, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or terminal device that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or terminal device. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or terminal device that includes said element.

[0202] The foregoing has provided a detailed description of a vehicle-to-cloud communication processing method, a vehicle-to-cloud communication processing device, an electronic device, and a computer-readable storage medium. Specific examples have been used to illustrate the principles and implementation methods of the present invention. The descriptions of the above embodiments are only for the purpose of helping to understand the method and core ideas of the present invention. At the same time, for those skilled in the art, there will be changes in specific implementation methods and application scope based on the ideas of the present invention. Therefore, the content of this specification should not be construed as a limitation of the present invention.

Claims

1. A communication processing method between a vehicle and a cloud, characterized in that, Applied to the vehicle end, the method includes: In response to the first received service request, obtain the protocol identifier of the vehicle-side SDK; Obtain the latest version of the target SDK protocol corresponding to the protocol identifier; The first service request is converted into a second service request according to the target SDK protocol; The second service request is sent to the cloud SDK.

2. The method according to claim 1, characterized in that, Also includes: Receive the first response data sent by the cloud SDK in response to the second service request; The first response data is verified in accordance with the target SDK protocol; Upon successful verification, the first response data is parsed according to the target SDK protocol to obtain the business service result corresponding to the first business request.

3. The method according to claim 2, characterized in that, The step of parsing the first response data according to the target SDK protocol to obtain the business service result corresponding to the first business request includes: Obtain the response data format defined by the target SDK protocol; The service results are parsed from the first response data according to the specified response data format.

4. The method according to claim 2, characterized in that, The step of verifying the first response data according to the target SDK protocol includes: Determine the preset verification method according to the target SDK protocol; The first verification information is determined from the first response data according to the verification method described above; Verification is performed based on the first verification information and the second verification information obtained by the vehicle.

5. The method according to any one of claims 1 to 4, characterized in that, Also includes: Determine the interception configuration items based on the target SDK protocol; Determine the interception interface according to the aforementioned interception configuration items; Obtain the status information of the interception interface. When the status information is in the maintenance state, execute the preset abnormal interception process.

6. The method according to claim 1, characterized in that, Also includes: Obtain the timestamp of the first service request; Obtain historical query rate data per second based on the timestamp; The historical query rate per second data is used as the input value of a preset prediction function to obtain the predicted query rate per second data; Determine whether the predicted query rate per second data matches the query rate per second data that the vehicle-side SDK can support; If the predicted query rate per second data and the vehicle-side SDK's capacity query rate per second data do not match, the vehicle-side SDK will be scaled down or expanded.

7. A communication processing method between a vehicle and a cloud, characterized in that, Applied to the cloud, the method includes: In response to the received second service request, obtain the protocol identifier of the vehicle-side SDK; Obtain the latest target SDK protocol corresponding to the protocol identifier; The second service request is verified in accordance with the target SDK protocol. After the verification is passed, the second service request is processed in accordance with the target SDK protocol to generate the first response data; The first response data is sent to the vehicle-side SDK.

8. A communication processing device between a vehicle and a cloud, characterized in that, Applied to a vehicle, the device includes: The first protocol identifier acquisition module is used to obtain the protocol identifier of the vehicle-side SDK in response to the received first service request; The first SDK protocol acquisition module is used to acquire the latest target SDK protocol corresponding to the protocol identifier; The second service request generation module is used to convert the first service request into a second service request according to the target SDK protocol; The second service request sending module is used to send the second service request to the cloud SDK.

9. A communication processing device between a vehicle and a cloud, characterized in that, Applied to the cloud, the method includes: The second protocol identifier acquisition module is used to obtain the protocol identifier of the vehicle-side SDK in response to the received second service request; The second SDK protocol acquisition module is used to acquire the latest target SDK protocol corresponding to the protocol identifier; The second service request verification module is used to verify the second service request in accordance with the target SDK protocol; The first response data generation module is used to process the second service request according to the target SDK protocol after the verification is passed, and generate the first response data. The first response data sending module is used to send the first response data to the vehicle-side SDK.

10. An electronic device, characterized in that, It includes a processor, a memory, and a computer program stored in the memory and capable of running on the processor, wherein the computer program, when executed by the processor, implements the vehicle-to-cloud communication processing method as described in any one of claims 1 to 6.

11. A computer-readable storage medium, characterized in that, A computer program is stored on the computer-readable storage medium, and when the computer program is executed by a processor, it implements the vehicle-to-cloud communication processing method as described in any one of claims 1 to 6.

Images