Vehicle-cloud communication method and storage medium based on service-oriented architecture

Abstract

The present invention relates to the field of vehicle-to-cloud communications, and more specifically to a vehicle-to-cloud communications method, an in-vehicle network terminal, a cloud service platform, and a computer storage medium based on a service-oriented architecture. The method is applied to a vehicle and includes the following steps: receiving an in-vehicle service list from a cloud, wherein the in-vehicle service list includes the identifiers, existence status, and service status of multiple in-vehicle services; monitoring the multiple in-vehicle services included in the in-vehicle service list and updating the in-vehicle service list based on the monitoring results; and uploading the updated in-vehicle service list to the cloud, so that a cloud service platform deployed on the cloud can register and call corresponding in-vehicle services based on the updated in-vehicle service list.

Description

Technical Field

[0001] The present invention relates to the field of vehicle-cloud communications, and more specifically to a vehicle-cloud communications method based on a service-oriented architecture, an on-board network terminal, a cloud service platform, and a computer storage medium. Background Art

[0002] With the rapid development of the automotive industry, while vehicles are becoming fully connected, autonomous, and data-driven, they are also becoming more and more user-friendly, enhancing the user experience and serving their personalized needs. At the same time, the introduction of high-computing chips, sensing technologies, data intelligence, and other technological products has also led to the emergence of new electronic and electrical architectures.

[0003] At present, the services abstracted by the service-oriented architecture (SOA) used in the design of the entire vehicle architecture are the most core and basic units. Each service component has independent functions, and the interfaces between service components follow unified standards, are mutually accessible, and can be combined and extended. The business process is the combination and extension of service components with status and service scheduling strategies, which are characterized by loose coupling, reusability, and high cohesion. SOA transforms intra-domain or cross-domain interactions from "signal-based communication" to "service-based communication." However, according to the current vehicle-cloud interconnection solution, the vehicle and the cloud need to perform protocol conversion when communicating with the vehicle-cloud. The service caller must know where the called service is deployed and needs to have a detailed understanding of the protocol and format of the other party's interface, which leads to problems such as low efficiency and poor flexibility in vehicle-cloud communication. Summary of the Invention

[0004] In order to solve or at least alleviate one or more of the above problems, the following technical solutions are provided. The embodiments of the present application provide a vehicle-to-cloud communication method, an in-vehicle network terminal, a cloud service platform, and a computer storage medium based on a service-oriented architecture, thereby enabling the cloud to call indiscriminately on in-vehicle services.

[0005] According to a first aspect of the present invention, a vehicle-cloud communication method based on a service-oriented architecture is provided, which is applied to a vehicle side and includes the following steps: receiving a vehicle service list sent from a cloud side, wherein the vehicle service list includes identifications, existence status and service status of multiple vehicle services; monitoring the multiple vehicle services included in the vehicle service list and updating the vehicle service list based on the monitoring results; and uploading the updated vehicle service list to the cloud side, so that a cloud service platform deployed on the cloud side can register and call corresponding vehicle services according to the updated vehicle service list.

[0006] As an alternative or supplement to the above scheme, in a method according to an embodiment of the present invention, the in-vehicle service includes static services deployed on all vehicle ends and dynamic services deployed on specific vehicle ends, and monitoring the in-vehicle service and updating the in-vehicle service list based on the monitoring results includes: monitoring and updating the service status of the static services included in the in-vehicle service list; and monitoring and updating the existence status and service status of the dynamic services included in the in-vehicle service list, wherein the existence status indicates whether the dynamic service is deployed on the vehicle end, and the service status indicates whether the in-vehicle service deployed on the vehicle end is online.

[0007] As an alternative or supplement to the above solution, the method according to one embodiment of the present invention further includes: receiving an in-vehicle service call request from the cloud, wherein the vehicle side and the cloud side communicate through a message queue telemetry transmission connection; obtaining the processing result of the called in-vehicle service according to the in-vehicle service call request; and uploading the processing result to the cloud side, so that the cloud side returns the processing result according to the callback address.

[0008] As an alternative or supplement to the above solution, the method according to an embodiment of the present invention further includes: receiving a cloud service list issued by the cloud, the cloud service list including identifiers of multiple cloud services, wherein the cloud services are homogeneous services that meet the requirements of the vehicle-side service-oriented architecture and the cloud services are converted by the cloud service platform from heterogeneous cloud services read from one or more cloud service sources using universal interface description information; and registering the cloud service on the vehicle side according to the cloud service list.

[0009] As an alternative or supplement to the above scheme, the method according to an embodiment of the present invention further includes: in response to receiving a cloud service call request initiated by the vehicle side, determining whether the message queue telemetry transmission connection is in a connected state, wherein the vehicle side and the cloud side communicate through the message queue telemetry transmission connection; and if the message queue telemetry transmission connection is in a connected state, uploading the cloud service call request to the cloud side via the message queue telemetry transmission connection.

[0010] As an alternative or supplement to the above scheme, the method according to an embodiment of the present invention further includes: if the message queue telemetry transmission connection is not in a connected state, querying whether there is a simplified version service on the vehicle side corresponding to the cloud service called by the cloud service call request; if the simplified version service exists on the vehicle side, obtaining the processing result of the simplified version service and responding with the processing result; if the simplified version service does not exist on the vehicle side, returning a call failure response.

[0011] According to a second aspect of the present invention, a vehicle-cloud communication method based on a service-oriented architecture is provided, which is applied to the cloud and includes the following steps: sending an on-board service list to the vehicle side, so that the vehicle side monitors the on-board services included in the on-board service list and updates the on-board service list based on the monitoring results, wherein the on-board service list includes the identification, existence status and service status of multiple on-board services; receiving the updated on-board service list returned by the vehicle side, and registering and calling the corresponding on-board services according to the updated on-board service list by a cloud service platform deployed on the cloud.

[0012] As an alternative or supplement to the above scheme, in a method according to one embodiment of the present invention, the in-vehicle service includes a static service deployed on all vehicle ends and a dynamic service deployed on a specific vehicle end, the existence status indicates whether the dynamic service is deployed on the vehicle end and the service status indicates whether the in-vehicle service deployed on the vehicle end is online.

[0013] As an alternative or supplement to the above scheme, in a method according to an embodiment of the present invention, the cloud service platform deployed on the cloud side registers the corresponding in-vehicle service according to the updated in-vehicle service list, including: if the existence status of the dynamic service indicates that the dynamic service is deployed on the vehicle side, the cloud service platform is allowed to send a call request for the dynamic service; if the existence status of the dynamic service indicates that the dynamic service is not deployed on the vehicle side, the cloud service platform is not allowed to send a call request for the dynamic service.

[0014] As an alternative or supplement to the above scheme, in a method according to an embodiment of the present invention, the cloud service platform deployed on the cloud calls the corresponding in-vehicle service according to the updated in-vehicle service list, including: in response to receiving an in-vehicle service call request from a third party or from within the cloud, querying the in-vehicle service list, wherein; if the in-vehicle service called by the in-vehicle service call request is a static service that has been put online, the in-vehicle service call request is sent to the vehicle end; if the in-vehicle service called by the in-vehicle service call request is a static service that has not been put online, the call is returned to the third party or from within the cloud. Failure response; if the in-vehicle service called by the in-vehicle service call request is a dynamic service not deployed on the vehicle side, a prohibition call response is returned to the third party or the cloud; if the in-vehicle service called by the in-vehicle service call request is a dynamic service deployed on the vehicle side and not online, a call failure response is returned to the third party or the cloud; if the in-vehicle service called by the in-vehicle service call request is a dynamic service deployed on the vehicle side and online, the in-vehicle service call request is sent to the vehicle side, wherein the vehicle side and the cloud communicate through a message queue telemetry transmission connection.

[0015] As an alternative or supplement to the above solution, the method according to an embodiment of the present invention further includes: reading heterogeneous cloud services from one or more cloud service sources and using universal interface description information to convert the heterogeneous cloud services into homogeneous cloud services that meet the requirements of the vehicle-side service-oriented architecture; and sending a cloud service list including the identification of the homogeneous cloud services to the vehicle-side, so that the vehicle-side can register and call the homogeneous cloud services.

[0016] As an alternative or supplement to the above solution, the method according to an embodiment of the present invention further includes: receiving interface description information defined by the first in-vehicle service and sent by the vehicle end; generating a service simulation instance corresponding to the first in-vehicle service based on the interface description information; and in response to receiving a call request for the first in-vehicle service, running the service simulation instance on the cloud and returning the service simulation result based on the input configuration information.

[0017] According to a third aspect of the present invention, there is provided an in-vehicle network terminal comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein when the processor executes the program, any one of the methods described in the first aspect of the present invention is implemented.

[0018] According to a fourth aspect of the present invention, a cloud service platform is provided, comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein when the processor executes the program, any one of the methods described in the second aspect of the present invention is implemented.

[0019] According to a fifth aspect of the present invention, a computer storage medium is provided, wherein the computer storage medium comprises instructions, and the instructions, when run, execute any one of the methods according to the first aspect or the second aspect of the present invention.

[0020] According to one or more embodiments of the present invention, the vehicle-cloud communication solution based on a service-oriented architecture can realize the indiscriminate calling of various in-vehicle services by the cloud with the help of an in-vehicle service list stored and managed by the cloud and monitored and updated by the vehicle side, so that service users can conveniently call various in-vehicle services through the cloud without having to understand the interface protocol, format, and service deployment address, thereby realizing the expansion of in-vehicle service capabilities and promoting the realization of vehicle-cloud integration. BRIEF DESCRIPTION OF THE DRAWINGS

[0021] The above and / or other aspects and advantages of the present invention will become clearer and easier to understand through the following description of various aspects in conjunction with the accompanying drawings, in which the same or similar elements are represented by the same reference numerals. In the accompanying drawings:

[0022] Figure 1is a schematic block diagram of a vehicle-to-cloud communication system 10 based on a service-oriented architecture according to one or more embodiments of the present invention;

[0023] Figure 2 is a schematic flow chart of a vehicle-cloud communication method 20 based on a service-oriented architecture according to one or more embodiments of the present invention; and

[0024] Figure 3 3 is a schematic flow chart of a vehicle-to-cloud communication method 30 based on a service-oriented architecture according to one or more embodiments of the present invention. DETAILED DESCRIPTION

[0025] The description of the following specific embodiments is merely exemplary in nature and is not intended to limit the disclosed technology or the application and use of the disclosed technology. In addition, there is no intention to be bound by any express or implied theory presented in the foregoing technical field, background technology or the following specific embodiments.

[0026] In the following detailed description of the embodiments, numerous specific details are set forth to provide a more thorough understanding of the disclosed technology. However, it will be apparent to one of ordinary skill in the art that the disclosed technology can be practiced without these specific details. In other instances, well-known features are not described in detail to avoid unnecessarily complicating the description.

[0027] Terms such as "comprising" and "including" indicate that, in addition to the units and steps directly and explicitly stated in the specification, the technical solution of the present invention does not exclude the presence of other units and steps not directly or explicitly stated. Terms such as "first" and "second" do not indicate the order of units in terms of time, space, size, etc., but are merely used to distinguish between units.

[0028] Hereinafter, exemplary embodiments according to the present invention will be described in detail with reference to the accompanying drawings.

[0029] Figure 1 FIG is a schematic block diagram of a vehicle-to-cloud communication system 10 based on a service-oriented architecture according to one or more embodiments of the present invention. Figure 1 As shown, the vehicle-to-cloud communication system 10 includes a vehicle-side 110 and a cloud-side 120. The vehicle-side 110 is equipped with an onboard network terminal 111 and an SOA framework module 112. The cloud-side 120 is equipped with a cloud service platform 121. Optionally, the vehicle-to-cloud communication system 10 may further include a third-party service provider 130 that communicates with the cloud-side 120.

[0030] Optionally, the vehicle-side 110 and the cloud-side 120 communicate via a Message Queuing Telemetry Transport (MQTT) connection. For example, the cloud-side 120 is deployed with an MQTT server 122 and the vehicle-side 110 is deployed with an MQTT client 113, so that the cloud service platform 121 can use the MQTT server 122 to send an in-vehicle service call request to the vehicle-side 110, and the vehicle-side 110 can use the MQTT client 113 to receive the in-vehicle service call request. For example, the cloud-side 120 can also be deployed with an MQTT client 123, so that the cloud service platform 121 can receive a response from the in-vehicle network terminal 111.

[0031] According to one or more embodiments of the present invention, the vehicle-to-cloud communication system 10 enables the registration and invocation of in-vehicle services on the cloud 120. Exemplarily, the cloud service platform 121 stores and manages a list of in-vehicle services available to the cloud. Optionally, in-vehicle services according to the present invention can be divided into static services and dynamic services. Static services are services that are common to all vehicles by default and are bound to the vehicle-side firmware version. All vehicles with that firmware version can provide the same static services, such as low-beam headlight service. Dynamic services are only available on some vehicles and are not bound to the vehicle-side firmware version. They may vary depending on the vehicle hardware, service provider, or vehicle location, making it impossible to guarantee that a vehicle will have them. For example, services such as lidar pedestrian detection or weather forecasting are available. It should be noted that the cloud service platform 121 initially stores a complete list of in-vehicle services for all vehicles. This list includes the identifiers of all in-vehicle services that may be available on each vehicle, their default presence status, and their default service status. The presence status indicates whether the dynamic service is deployed on the vehicle side, while the service status indicates whether the in-vehicle service deployed on the vehicle side is online. The cloud service platform 121 can send the in-vehicle service list to the in-vehicle network terminal 111, and the in-vehicle network terminal 111 is responsible for monitoring the multiple in-vehicle services (e.g., static services and dynamic services) included in the in-vehicle service list and updating the in-vehicle service list based on the monitoring results. Since static services are always present on all vehicle terminals, the in-vehicle network terminal 111 only needs to request the service status of the static services included in the in-vehicle service list from the SOA framework module 112, without having to pay attention to the existence status of the static services. Since dynamic services only exist on some vehicle terminals, the in-vehicle network terminal 111 needs to request the service status and existence status of the dynamic services included in the in-vehicle service list from the SOA framework module 112. After obtaining the information fed back by the SOA framework module 112 (i.e., the service status of static services, the service status of dynamic services, and the existence status), the in-vehicle network terminal 111 synchronizes the updated in-vehicle service list to the cloud service platform 121, so that it can register and call the corresponding in-vehicle services based on the updated in-vehicle service list.

[0032] Optionally, during the registration process of the in-vehicle service, the cloud service platform 121 completes the following configuration process: if the existence status of the dynamic service indicates that a dynamic service is deployed on the vehicle side, sending a call request for the dynamic service is allowed; if the existence status of the dynamic service indicates that no dynamic service is deployed on the vehicle side, sending a call request for the dynamic service is not allowed; if the service status of the dynamic service or the static service indicates that it is online, sending the call request to the vehicle side is allowed; if the service status of the dynamic service or the static service indicates that it is not online, a call failure response is returned to the service caller.

[0033] Optionally, when receiving an in-vehicle service call request from a third-party service provider 130 or the cloud, the cloud service platform 121 will query the in-vehicle service list and perform the following operations based on the query results: if the in-vehicle service called by the in-vehicle service call request is a static service that is already online, the in-vehicle service call request will be sent to the vehicle end; if the in-vehicle service called by the in-vehicle service call request is a static service that is not online, a call failure response will be returned to the third party or the cloud; if the in-vehicle service called by the in-vehicle service call request is a dynamic service that is not deployed on the vehicle end, a call prohibition response will be returned to the third party or the cloud; if the in-vehicle service called by the in-vehicle service call request is a dynamic service that is deployed on the vehicle end and is not online, a call failure response will be returned to the third party or the cloud; if the in-vehicle service called by the in-vehicle service call request is a dynamic service that is deployed on the vehicle end and is online, the in-vehicle service call request will be sent to the vehicle end.

[0034] Furthermore, the vehicle-cloud communication system 10 according to one or more embodiments of the present invention can realize the registration and calling functions of cloud services on the vehicle side 110. Exemplarily, the cloud service platform 121 reads heterogeneous cloud services from one or more cloud service sources (for example, Dubbo, K8S, Spring Cloud), and the cloud service platform 121 provides the ability to convert Restful APIs into services using the metadata of Rest APIs. After obtaining the metadata from the cloud service source, the cloud service platform 121 uses the general interface description information to convert heterogeneous cloud services into homogeneous cloud services that meet the requirements of the vehicle-side service-oriented architecture (vehicle-side SOA), and sends the cloud service list including the identifiers of the homogeneous cloud services to the vehicle-side on-board network terminal 111 for registration by the on-board network terminal 111 and calling of the homogeneous cloud services by the SOA framework module 112.

[0035] The vehicle-side request for cloud services can be divided into two scenarios according to the connection status of the MQTT connection. Specifically, when the vehicle-mounted network terminal 111 receives a cloud service call request initiated by the SOA framework module 112, it first determines whether the MQTT connection between the vehicle-side and the cloud is in a connected state. If the MQTT connection is in a connected state (for example, the connection is good), the vehicle-mounted network terminal 111 uploads the cloud service call request to the cloud via the MQTT connection. If the MQTT connection is not in a connected state (for example, the connection is disconnected or weakly connected), the vehicle-mounted network terminal 111 will query whether there is a simplified version of the service (lite service) corresponding to the cloud service called by the cloud service call request on the vehicle-side, wherein the simplified version of the service can be configured on the vehicle-side in the form of a runtime plug-in, or it can be an item in the cloud service list as a substitute when the cloud service is unavailable, to perform some simple calculations on behalf of the cloud, thereby ensuring the continuity of the service in a weak network or no network state. If the vehicle network terminal 111 finds that the simplified service exists on the vehicle side, it will run the simplified service and obtain the processing results in response. If the query finds that the simplified service does not exist on the vehicle side, the vehicle network terminal 111 will return a call failure response. In this way, under the SOA architecture of the entire vehicle service, various heterogeneous cloud services can be serviced through the cloud service platform 121 and integrated with the vehicle-side SOA framework module 112, thereby achieving full and seamless integration of cloud and vehicle services.

[0036] Furthermore, the vehicle-cloud communication system 10 according to one or more embodiments of the present invention can implement a simulation process of a cloud service on an in-vehicle service. For example, the vehicle-side 110 first defines an interface based on a first in-vehicle service (for example, a vehicle-side service for turning on the low-beam headlights) and provides the interface description information to the cloud service platform 121. The cloud service platform 121 generates a service simulation instance corresponding to the first in-vehicle service based on the interface description information. When the service simulation instance is executed on the cloud in response to receiving a call request for the first in-vehicle service, the cloud can achieve a simulation effect of the first in-vehicle service (for example, simulating the low-beam headlight service on the cloud). Optionally, during the simulation process, the service simulation result can also be returned based on the input configuration information. For example, the cloud service platform 121 can receive configuration information input by a simulation tester. For example, the configuration information indicates that after receiving a command to turn on the lights, a successful turn-on is returned. At this time, if the service simulation instance is executed on the cloud in response to receiving a call request for the first in-vehicle service, a successful turn-on result can be returned according to the requirements of the configuration information. In this way, the problem of dependence on other services and hardware when developing in-vehicle services can be solved, so that in the new car-cloud integrated architecture, the cloud can arbitrarily simulate in-vehicle services, realize the decoupling of mutual dependence between developers, and thus improve the efficiency of in-vehicle function development.

[0037] Continue to refer to Figure 2 , Figure 2 FIG2 is a schematic flow chart of a vehicle-to-cloud communication method 20 based on a service-oriented architecture according to one or more embodiments of the present invention. It should be noted that the method 20 is applied to the vehicle side (for example, Figure 1 The vehicle end 110 or the vehicle network terminal 111 is shown).

[0038] In step S210, a list of in-vehicle services is received from the cloud, where the in-vehicle service list includes the identifiers, presence status, and service status of multiple in-vehicle services. Optionally, the in-vehicle services include static services deployed on all vehicles and dynamic services deployed on specific vehicles. The presence status indicates whether the dynamic service is deployed on the vehicle, and the service status indicates whether the in-vehicle service deployed on the vehicle is online.

[0039] In step S220, the multiple in-vehicle services included in the in-vehicle service list are monitored and the in-vehicle service list is updated based on the monitoring results. Optionally, monitoring the in-vehicle services and updating the in-vehicle service list based on the monitoring results includes: monitoring and updating the service status of the static services included in the in-vehicle service list; and monitoring and updating the existence status and service status of the dynamic services included in the in-vehicle service list. Since static services always exist on all vehicle terminals, it is only necessary to monitor the service status of static services without paying attention to their existence status. Since dynamic services only exist on some vehicle terminals, it is necessary to monitor both their service status and existence status.

[0040] In step S230, the updated in-vehicle service list is uploaded to the cloud, so that the cloud service platform deployed on the cloud can register and call the corresponding in-vehicle service based on the updated in-vehicle service list. Optionally, calling the in-vehicle service includes: receiving an in-vehicle service call request from the cloud, wherein the vehicle and the cloud communicate via a message queue telemetry transmission connection; obtaining a processing result of the called in-vehicle service based on the in-vehicle service call request; and uploading the processing result to the cloud, so that the cloud returns the processing result according to the callback address.

[0041] Optionally, method 20 may also include a registration step (step S240) and / or a calling function (step S250) of the cloud service on the vehicle side. In step S240, a cloud service list sent by the cloud side is received, the cloud service list includes identifiers of multiple cloud services, wherein the cloud service is a homogeneous service that meets the requirements of the vehicle-side service-oriented architecture and the cloud service is converted by the cloud service platform from heterogeneous cloud services read from one or more cloud service sources using general interface description information; and the cloud service is registered on the vehicle side according to the cloud service list. In step S250, in response to receiving a cloud service call request initiated by the vehicle side, it is determined whether the message queue telemetry transmission connection is in a connected state, wherein the vehicle side and the cloud side communicate through the message queue telemetry transmission connection; and if the message queue telemetry transmission connection is in a connected state, the cloud service call request is uploaded to the cloud via the message queue telemetry transmission connection. Optionally, step S250 further includes: if the message queue telemetry transmission connection is not in a connected state, querying whether there is a simplified version of the service corresponding to the cloud service called by the cloud service call request on the vehicle side; if the simplified version of the service exists on the vehicle side, obtaining the processing result of the simplified version of the service and responding with the processing result; if the simplified version of the service does not exist on the vehicle side, returning a call failure response. For example, the simplified version of the service can be configured on the vehicle side in the form of a runtime plug-in, or it can be an item in the cloud service list as an alternative when the cloud service is unavailable, to perform some simple calculations on behalf of the cloud, thereby ensuring service continuity in weak or no network conditions.

[0042] Continue to refer to Figure 3 , Figure 3 FIG3 is a schematic flow chart of a vehicle-to-cloud communication method 30 based on a service-oriented architecture according to one or more embodiments of the present invention. It should be noted that the method 30 is applied to the cloud (e.g., Figure 1 The cloud 120 or cloud service platform 121 is shown).

[0043] In step S310, a vehicle-mounted service list is sent to the vehicle-side, so that the vehicle-side can monitor the vehicle-mounted services included in the vehicle-mounted service list and update the vehicle-mounted service list based on the monitoring results. The vehicle-mounted service list includes the identification, existence status, and service status of multiple vehicle-mounted services. Optionally, the vehicle-mounted services include static services deployed on all vehicle-sides and dynamic services deployed on specific vehicle-sides. The existence status indicates whether the dynamic service is deployed on the vehicle-side, and the service status indicates whether the vehicle-mounted service deployed on the vehicle-side is online.

[0044] In step S320, the updated in-vehicle service list returned by the vehicle is received, and the cloud service platform deployed on the cloud registers and calls the corresponding in-vehicle service according to the updated in-vehicle service list. Optionally, the in-vehicle service list registration step includes: if the existence status of the dynamic service indicates that the dynamic service is deployed on the vehicle, then allowing the cloud service platform to send a call request for the dynamic service; if the existence status of the dynamic service indicates that the dynamic service is not deployed on the vehicle, then not allowing the cloud service platform to send a call request for the dynamic service. Optionally, the step of calling the in-vehicle service list includes: in response to receiving an in-vehicle service call request from a third party or the cloud, querying the in-vehicle service list, wherein; if the in-vehicle service called by the in-vehicle service call request is a static service that is already online, the in-vehicle service call request is sent to the vehicle side; if the in-vehicle service called by the in-vehicle service call request is a static service that is not online, a call failure response is returned to the third party or the cloud; if the in-vehicle service called by the in-vehicle service call request is a dynamic service that is not deployed on the vehicle side, a call prohibition response is returned to the third party or the cloud; if the in-vehicle service called by the in-vehicle service call request is a dynamic service that is deployed on the vehicle side and is not online, a call failure response is returned to the third party or the cloud; if the in-vehicle service called by the in-vehicle service call request is a dynamic service that is deployed on the vehicle side and is online, the in-vehicle service call request is sent to the vehicle side, wherein the vehicle side and the cloud communicate through a message queue telemetry transmission connection.

[0045] Optionally, method 30 may further include a cloud service discovery and registration step (step S330). In step S330, heterogeneous cloud services are read from one or more cloud service sources and converted into homogeneous cloud services that meet the requirements of the vehicle-side service-oriented architecture using the common interface description information; and a cloud service list including the identifiers of the homogeneous cloud services is sent to the vehicle side for the vehicle side to register and call the homogeneous cloud services.

[0046] Optionally, method 30 may further include a step of simulating the in-vehicle service by the cloud service (step S340). In step S340, interface description information defined according to the first in-vehicle service, sent by the vehicle, is received; a service simulation instance corresponding to the first in-vehicle service is generated based on the interface description information; and in response to receiving a call request for the first in-vehicle service, the service simulation instance is executed in the cloud and a service simulation result is returned based on the input configuration information.

[0047] It should be noted that the steps of methods 20 and 30 can be carried out with reference to the specific workflow of the vehicle-to-cloud communication system 10 described above, and the relevant content is also cited here. Due to space limitations, they are not detailed here.

[0048] In addition, the present invention can also be implemented as an in-vehicle network terminal, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the program to implement the following Figure 2 Any embodiment of the method 20 shown.

[0049] The present invention can also be implemented as a cloud service platform, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the program to implement the following Figure 3 Any embodiment of the method 30 shown.

[0050] In addition, as described above, the present invention can also be implemented as a computer storage medium, in which a program for causing a computer to execute the following steps is stored. Figure 2 or Figure 3 Here, as a computer storage medium, various computer storage media can be used, such as disks (e.g., magnetic disks, optical disks, etc.), cards (e.g., memory cards, optical cards, etc.), semiconductor memories (e.g., ROMs, non-volatile memories, etc.), and tapes (e.g., magnetic tapes, cassettes, etc.).

[0051] First, the vehicle-cloud communication solution based on a service-oriented architecture according to one or more embodiments of the present invention can realize the indiscriminate calling of various in-vehicle services by the cloud with the help of an in-vehicle service list stored and managed by the cloud and monitored and updated by the vehicle side, so that service users can conveniently call various in-vehicle services through the cloud without having to understand the interface protocol, format, and service deployment address, thereby realizing the expansion of in-vehicle service capabilities and promoting the realization of vehicle-cloud integration.

[0052] Secondly, the vehicle-to-cloud communication solution based on a service-oriented architecture according to one or more embodiments of the present invention can, within the SOA architecture of the entire vehicle service, enable the various heterogeneous cloud services to be service-oriented through the cloud service platform and integrated with the vehicle-side SOA architecture, thereby achieving full and seamless integration of cloud-based and vehicle-side services. With this solution, service callers need not worry about the location of the service; they only need to request the corresponding service, thus shielding the differences in service requests from each end. This allows upper-level applications and services at the same level to directly and uniformly access services on each end according to defined interfaces.

[0053] Furthermore, the vehicle-cloud communication solution based on a service-oriented architecture according to one or more embodiments of the present invention can solve the problem of dependence on other services and hardware when developing in-vehicle services, so that in the new vehicle-cloud integrated architecture, the cloud can arbitrarily simulate in-vehicle services, and realize the decoupling of vehicle software development from hardware, thereby improving the efficiency of in-vehicle function development.

[0054] In the case of applicable, hardware, software or a combination of hardware and software can be used to realize the various embodiments provided by the present invention. Moreover, in the case of applicable, without departing from the scope of the present invention, the various hardware components and / or software components set forth herein can be combined into composite components comprising software, hardware and / or both. In the case of applicable, without departing from the scope of the present invention, the various hardware components and / or software components set forth herein can be divided into subcomponents comprising software, hardware or both. In addition, in the case of applicable, it is contemplated that software components can be implemented as hardware components, and vice versa.

[0055] Software according to the present invention (such as program code and / or data) can be stored on one or more computer storage media. It is also contemplated that the software identified herein can be implemented using one or more general or special computers and / or computer systems, networked and / or otherwise. Where applicable, the order of the various steps described herein can be changed, combined into composite steps and / or divided into sub-steps to provide the features described herein.

[0056] The embodiments and examples set forth herein are provided to best illustrate embodiments according to the present invention and its specific applications, and thereby enable those skilled in the art to make and use the invention. However, those skilled in the art will appreciate that the above description and examples are provided for ease of illustration and example only. The descriptions set forth are not intended to encompass all aspects of the invention or to limit the invention to the precise forms disclosed.

Claims

1. A vehicle-cloud communication method based on a service-oriented architecture, characterized in that: The method is applied to the vehicle side and comprises the following steps: receiving a vehicle service list sent from the cloud, wherein the vehicle service list includes identifiers, existence status, and service status of multiple vehicle services; Monitoring the plurality of in-vehicle services included in the in-vehicle service list and updating the in-vehicle service list based on monitoring results; The updated in-vehicle service list is uploaded to the cloud, so that the cloud service platform deployed on the cloud can register the corresponding in-vehicle service according to the updated in-vehicle service list and query the updated in-vehicle service list in response to receiving an in-vehicle service call request from a third party or within the cloud, and determine whether to send the in-vehicle service call request to the vehicle end based on the query result.

2. The method according to claim 1, wherein The in-vehicle services include static services deployed on all vehicle terminals and dynamic services deployed on specific vehicle terminals, and monitoring the in-vehicle services and updating the in-vehicle service list based on the monitoring results includes: Monitoring and updating the service status of the static services included in the in-vehicle service list; and Monitor and update the existence and service status of dynamic services included in the in-vehicle service list, The presence status indicates whether the dynamic service is deployed on the vehicle side, and the service status indicates whether the vehicle-mounted service deployed on the vehicle side is online.

3. The method according to claim 1, wherein The method further comprises: Receiving an in-vehicle service call request from the cloud, wherein the vehicle and the cloud communicate via a message queue telemetry transmission connection; Obtaining a processing result of the called in-vehicle service according to the in-vehicle service calling request; and The processing result is uploaded to the cloud, so that the cloud returns the processing result according to the callback address.

4. The method according to claim 1, wherein The method further comprises: receiving a cloud service list issued by the cloud, the cloud service list including identifiers of a plurality of cloud services, wherein the cloud services are homogeneous services that meet requirements of a vehicle-side service-oriented architecture and are converted by the cloud service platform from heterogeneous cloud services read from one or more cloud service sources using universal interface description information; and Register the cloud service on the vehicle side according to the cloud service list.

5. The method according to claim 4, wherein The method further comprises: In response to receiving a cloud service call request initiated by the vehicle, determining whether a message queue telemetry transmission connection is in a connected state, wherein the vehicle and the cloud communicate via the message queue telemetry transmission connection; and If the message queue telemetry transmission connection is in a connected state, the cloud service call request is uploaded to the cloud via the message queue telemetry transmission connection.

6. The method according to claim 5, wherein: The method further comprises: If the message queue telemetry transmission connection is not in a connected state, querying whether there is a simplified version of the cloud service called by the cloud service call request on the vehicle side; If the simplified version service exists on the vehicle side, obtaining a processing result of the simplified version service and responding with the processing result; or If the simplified version service does not exist on the vehicle side, a call failure response is returned.

7. A vehicle-cloud communication method based on a service-oriented architecture, characterized in that: The method is applied in the cloud and comprises the following steps: Sending an in-vehicle service list to the vehicle end, so that the vehicle end monitors the in-vehicle services included in the in-vehicle service list and updates the in-vehicle service list based on the monitoring results, wherein the in-vehicle service list includes identifiers, existence status, and service status of multiple in-vehicle services; Receiving the updated in-vehicle service list returned by the vehicle end, and registering corresponding in-vehicle services according to the updated in-vehicle service list by the cloud service platform deployed on the cloud end; In response to receiving an in-vehicle service call request from a third party or the cloud, query the updated in-vehicle service list, and determine whether to send the in-vehicle service call request to the vehicle end based on the query result.

8. The method according to claim 7, wherein: The in-vehicle service includes static services deployed on all vehicle ends and dynamic services deployed on specific vehicle ends. The existence status indicates whether the dynamic service is deployed on the vehicle end and the service status indicates whether the in-vehicle service deployed on the vehicle end is online.

9. The method according to claim 8, wherein Registering corresponding in-vehicle services according to the updated in-vehicle service list by the cloud service platform deployed on the cloud includes: If the existence status of the dynamic service indicates that the dynamic service is deployed on the vehicle side, allowing the cloud service platform to send a call request for the dynamic service; or If the existence status of the dynamic service indicates that the dynamic service is not deployed on the vehicle side, the cloud service platform is not allowed to send a call request for the dynamic service.

10. The method according to claim 8, wherein In response to receiving an in-vehicle service call request from a third party or within the cloud, querying the in-vehicle service list, and determining whether to send the updated in-vehicle service call request to the vehicle end based on the query result includes: If the in-vehicle service called by the in-vehicle service call request is an online static service, sending the in-vehicle service call request to the vehicle end; If the in-vehicle service called by the in-vehicle service call request is a static service that is not online, a call failure response is returned to the third party or the cloud; If the in-vehicle service called by the in-vehicle service call request is a dynamic service that is not deployed on the vehicle side, a call prohibition response is returned to the third party or the cloud; If the in-vehicle service called by the in-vehicle service call request is a dynamic service deployed on the vehicle side and not online, a call failure response is returned to the third party or the cloud; or If the in-vehicle service called by the in-vehicle service call request is a dynamic service deployed on the vehicle side and online, the in-vehicle service call request is sent to the vehicle side. The vehicle side and the cloud side communicate via a message queue telemetry transmission connection.

11. The method according to claim 7, wherein: The method further comprises: Reading heterogeneous cloud services from one or more cloud service sources and converting the heterogeneous cloud services into homogeneous cloud services that meet the requirements of the vehicle-side service-oriented architecture using common interface description information; and A cloud service list including the identifier of the homogeneous cloud service is sent to the vehicle side, so that the vehicle side can register and call the homogeneous cloud service.

12. The method according to claim 7, wherein: The method further comprises: Receiving interface description information defined according to a first in-vehicle service sent by the vehicle end; generating a service simulation instance corresponding to the first in-vehicle service based on the interface description information; and In response to receiving the call request for the first in-vehicle service, the service simulation instance is run in the cloud and a service simulation result is returned according to the input configuration information.

13. An in-vehicle network terminal comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that: When the processor executes the program, the method according to any one of claims 1 to 6 is implemented.

14. A cloud service platform comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that: When the processor executes the program, the method according to any one of claims 7 to 12 is implemented.

15. A computer storage medium, characterized in that The computer storage medium comprises instructions that, when executed, perform the method according to any one of claims 1-12.

Images