Service orchestration filtering vehicle available service method, device, vehicle and storage medium

Abstract

The present application relates to the technical field of vehicle service orchestration, and provides a service orchestration filtering vehicle available service method, steps comprising: orchestration object configuration; collecting vehicle option or plug-in information; collecting vehicle software version information; filtering out unavailable services of a user vehicle non-orchestrable service list or a user vehicle non-subscribable system recommended scene to obtain a recommended list. Through orchestration object configuration, in combination with vehicle option or plug-in information and vehicle software version information, the present application filters out services or scenes unavailable for a user vehicle from an orchestrable service list and a subscribable scene list of a vehicle type to which the vehicle belongs, and ensures that a system recommended scene and a self-defined orchestration service subscribed by the user are available.

Description

Technical Field

[0001] This invention relates to the field of vehicle service orchestration technology, and more specifically to a method, apparatus, vehicle, and storage medium for service orchestration filtering of available services for vehicles. Background Technology

[0002] In recent years, the concept of SOA (Service-Oriented Architecture) has emerged in the automotive industry, and vehicle service orchestration, its most prominent application, has become a field of intense research for major automakers. This is because the automotive industry generally faces pain points such as the labor-intensive and time-consuming development of new applications or functions, and the inconvenience of system upgrades. However, a large portion of new functions are not built from scratch, but rather by combining many simple vehicle control and entertainment capabilities based on certain logic to form a more intelligent, scenario-based function—this is service orchestration. The core of service orchestration is to abstract vehicle capabilities and orchestrate them in the form of services. When a certain scenario is triggered, the pre-defined orchestration is executed. This orchestration can be recommended by the automaker to the user or defined by the user themselves. In a sense, the user truly participates in the software-defined vehicle.

[0003] Regarding service orchestration, Chinese Patent CN112346618A discloses a vehicle service processing method and apparatus. The method includes: when a service orchestration instruction is detected, displaying a service orchestration interface, wherein the service orchestration interface includes a trigger event editing area and an action event editing area; detecting a user's first selection operation in the trigger event editing area and responding to the first selection operation to determine the corresponding target trigger event; detecting a user's second selection operation in the action event editing area and responding to the second selection operation to determine the corresponding target action event; and generating corresponding target vehicle service information based on the target trigger event and the target action event.

[0004] This technical solution integrates various vehicle networking functions into a service platform. Users can customize new vehicle services by orchestrating trigger events and action events through the service platform. While this eliminates the need for user coding and offers a simple and quick orchestration process, improving the efficiency and cost of vehicle service customization, vehicle software is often capable of OTA (Over-The-Air) upgrades. If the system scenarios or customizable services released by the automaker require OTA upgrades to become available, users who haven't upgraded will encounter service call failures and other anomalies. Currently, many automakers offer diverse choices through model option schemes or pluggable components, which can also lead to the unavailability of user-defined scenarios or orchestratable services. Therefore, how to ensure that users can access these scenarios and services is a pressing issue that needs to be addressed. Summary of the Invention

[0005] In view of this, the purpose of this application is to provide a service orchestration filtering method, device, vehicle and storage medium for vehicle available services. By configuring the orchestration object and combining vehicle optional or plug-in component information and vehicle software version information, services or scenarios that are unavailable to the user's vehicle are filtered out from the orchestratable service list and subscribed scenario list of the vehicle model, so as to ensure that the scenario composed of the system recommended scenario and the custom orchestration service subscribed by the user is available.

[0006] To achieve the above technical objectives, the technical solution adopted in this application is as follows:

[0007] In the first aspect, this application provides a service orchestration filtering method for available services on a vehicle, the steps of which include: configuring orchestration objects; collecting vehicle optional or plug-in component information; collecting vehicle software version information; filtering out unavailable services from the user vehicle's unorchestratable service list or system recommendation scenarios that the user vehicle cannot subscribe to, to obtain a recommendation list.

[0008] Furthermore, the orchestration object configuration includes:

[0009] S101. Manage services by grouping them according to the orchestration object. Under one orchestration object, configure several levels of sub-orchestration objects. Under the lowest level sub-orchestration object, configure the service list of the lowest level sub-orchestration object.

[0010] S102. Add constraint configurations to the sub-level orchestration objects and services;

[0011] S103. The software IDs of the sub-level orchestration objects and services are each set to a minimum version to accommodate software version differences when new services are added. In this solution, the software IDs of the sub-level orchestration objects and services are the same as those of the top-level orchestration object, so configurations such as software ID, whether they are pluggable, and whether they support OTA are no longer required. However, a minimum version can be set separately to accommodate software version differences when new services are added.

[0012] Furthermore, the constraint configuration includes software number, minimum version, whether it is a pluggable component, and whether it supports OTA.

[0013] Furthermore, the collection of vehicle optional or plug-in component information includes first collecting the status of the vehicle's optional or plug-in components, determining whether the optional or plug-in components are available, and then synchronizing the information to the cloud system, where the cloud system records the vehicle's optional or plug-in component information. In this technical solution, collecting the status of the vehicle's optional or plug-in components first can determine the vehicle's optional or plug-in component situation. This setup allows us to know which functions the vehicle has currently been equipped with and which plug-in components need to be added later.

[0014] Furthermore, the collection of vehicle software version information includes first collecting the vehicle's current software version status, then synchronizing the vehicle's current version information to the cloud system. The cloud system records the version information of the vehicle's currently OTA-enabled software and queries the vehicle's current software version status. Since OTA upgrades cause changes in the vehicle's software version status, the vehicle periodically queries the software version information that needs OTA upgrades. Once the cloud system records the version information of the vehicle's currently OTA-enabled software, it can determine the vehicle's current software version status.

[0015] Furthermore, the list of services that cannot be arranged for user vehicles includes:

[0016] S201. Users dynamically obtain a customizable and programmable service list;

[0017] S202. Obtain the list of programmable objects and their services for each vehicle model.

[0018] S203. Filter out the configuration items of the orchestration object as plug-in components, and obtain the orchestration object of the vehicle configuration or plug-in component, as well as the sub-orchestration object and service.

[0019] S204. Select the orchestration objects and their sub-orchestration objects and services from the obtained service list, where the configuration items of the orchestration objects require OTA and the lowest version of the software in the corresponding configuration items is less than or equal to the current software version information of the vehicle obtained from the vehicle software version information.

[0020] S205. For non-optional or plug-in components and non-OTA configuration items, they are directly included in the service list by default, resulting in the final service list that can be configured for the user vehicle.

[0021] In this technical solution, when defining orchestration, the user first needs to dynamically obtain a list of orchestratable services, and then combine the services into the desired scenario. The system needs to ensure that all services in the orchestratable service list are usable by the vehicle. First, the system obtains the orchestratable objects and their service lists for the vehicle model. It then filters out orchestratable objects whose configuration items are plug-in components and exist in the vehicle's optional or plug-in component information, along with their sub-orchestration objects and services. From the obtained service list, it filters out orchestratable objects whose configuration items require OTA updates and whose minimum software version is less than or equal to the current vehicle software version obtained from the vehicle software version information, along with their sub-orchestration objects and services. Orchestration objects that are not optional or plug-in components and are not OTA-enabled are directly included in the service list by default. This yields the final orchestratable service list for the user's vehicle.

[0022] Furthermore, the filtering of system recommendation scenarios that the user's vehicle cannot subscribe to includes: the user obtaining a list of system recommendation scenarios that can be subscribed to; obtaining a list of programmable services for the user's vehicle; filtering system recommendation scenarios based on the list of programmable services; and obtaining a list of system recommendation scenarios that the user's vehicle can subscribe to.

[0023] In this technical solution, when a user obtains subscribing-available system-recommended scenarios, these scenarios are pre-arranged combinations of services by the automaker for user convenience. The services within each system-recommended scenario must be available for that specific vehicle. First, a list of subscribing-available system-recommended scenarios for each vehicle model is obtained. Then, the final list of services that can be arranged for the user's vehicle is obtained using the method described above. If a service included in a system-recommended scenario is not included in the user's vehicle's list of services that can be arranged, that system-recommended scenario will be unavailable on that vehicle and should be filtered out. Finally, a list of subscribing-available system-recommended scenarios for the user's vehicle is obtained.

[0024] Secondly, the present invention also discloses a service orchestration and filtering device for available vehicle services, applied to a service platform. The device includes: an orchestration object configuration module for managing the combination of services by orchestration objects and adding constraint configurations to orchestration objects and services; a vehicle optional or plug-in component information collection module for collecting the status of optional or plug-in components of the vehicle, determining whether optional or plug-in components are available, and synchronizing the information to a cloud system; a vehicle software version information module for periodically querying the software version information that needs OTA upgrades in the vehicle and synchronizing the current version information of the vehicle to a cloud system; and an unavailable service filtering module for filtering unavailable services.

[0025] Thirdly, the present invention also discloses a vehicle that performs OTA upgrades using the above-described service orchestration filtering method for vehicle available services.

[0026] Fourthly, the present invention also discloses a computer-readable storage medium storing a computer program that, when run on a computer, causes the computer to perform the above-described method.

[0027] The invention employing the above technical solution has the following advantages:

[0028] This invention, through configuration of orchestration objects and by combining vehicle optional or plug-in component information and vehicle software version information, filters out services or scenarios unavailable to the user's vehicle from the orchestratable service list and subscribed scenario list of the vehicle model. This ensures the availability of scenarios composed of system-recommended scenarios and custom orchestrated services subscribed to by the user. It effectively solves the service availability problem provided by optional or plug-in components in service orchestration, and also addresses service availability issues caused by vehicle software upgrades. The invention achieves simple and clear management, a simple filtering algorithm, and guarantees the availability of services used, including custom and system-recommended services, thereby improving the user experience of service orchestration. Attached Figure Description

[0029] This application can be further illustrated by the non-limiting embodiments given in the accompanying drawings. It should be understood that the following drawings only illustrate some embodiments of this application and should not be considered as limiting the scope. For those skilled in the art, other related drawings can be obtained from these drawings without any inventive effort.

[0030] Figure 1 The logical flowchart of the service arrangement and filtering method for available vehicle services in this invention is shown below.

[0031] Figure 2 This is a schematic diagram of the configuration structure of the arrangement objects in this invention.

[0032] Figure 3 A flowchart illustrating the logic of filtering the programmable service list for user vehicles.

[0033] Figure 4 A flowchart illustrating the logic of filtering the system's recommended scenario list for user vehicles. Detailed Implementation

[0034] The present application will be described in detail below with reference to the accompanying drawings and specific embodiments. It should be noted that similar or identical parts are referred to by the same reference numerals in the drawings or description. Implementations not shown or described in the drawings are forms known to those skilled in the art. In the description of this application, terms such as "first" and "second" are used only to distinguish descriptions and should not be construed as indicating or implying relative importance.

[0035] Example 1

[0036] This embodiment describes a service orchestration and filtering method, apparatus, vehicle, and storage medium available for vehicles, such as... Figure 1As shown, the scenario and orchestration management system collects information on vehicle optional or plug-in components, the latest vehicle software and its version information. Through orchestration object configuration, services and scenarios can be filtered, thereby providing users with a list of services that can be orchestrated for their vehicle and a list of recommended system scenarios that can be subscribed to. Users can subscribe to recommended system scenarios that can be used by their vehicle, or they can create their own desired scenarios by customizing service orchestration through the list of orchestratable services.

[0037] The orchestration objects mentioned above are combinations of services, such as Figure 2 As shown, a single orchestration object can be configured with secondary and tertiary orchestration objects, and at the lowest level, the service list for that orchestration object can be configured. For example, a primary orchestration object can be configured as a seat, and secondary orchestration objects for seats include driver's seat and passenger seat. Services under the driver's seat include driver's seat backrest adjustment, driver's seat height adjustment, driver's seat fore-and-aft adjustment, driver's seat ventilation, and driver's seat heating. Services under the passenger seat include passenger seat backrest adjustment, passenger seat height adjustment, passenger seat fore-and-aft adjustment, passenger seat ventilation, and passenger seat heating. Constraint configurations are added to the orchestration objects and services to allow for subsequent comparison with actual vehicle information to filter the service list. These constraints include: software number, minimum version, whether it is a plug-in component, and whether it supports OTA upgrades. For example, the seat's constraint configuration includes software number 9111701-CD01, a minimum version requirement of SWC:1.0.0, it is not a plug-in component, and it supports OTA upgrades. The software IDs of child orchestration objects and services are the same as those of the top-level orchestration object, so configurations such as software ID, whether they are pluggable, and whether they support OTA are no longer required. However, a minimum version can be set separately to accommodate software version differences brought about by the addition of new services. For example, if a passenger seat footrest adjustment service is added during a subsequent OTA iteration, and this service is not present in software version 9111701-CD01 (SWC:1.0.0), but is added in version SWC:1.2.0, then the minimum version requirement for the passenger seat footrest can be configured to be SWC:1.2.0.

[0038] The aforementioned collection of vehicle optional or plug-in component information is for determining the availability and status of these components. The vehicle collects signals from in-vehicle optional or plug-in components to determine their usability and then synchronizes this information to the cloud system. For example, if a user has selected a HUD (Hardware Utility Device), with part number 9111861-HM01 and version SWC:1.5.0, but has not installed Bluetooth (part number 9231801-LY01), the vehicle will inform the cloud of the optional and plug-in component information. The cloud system will record this information, indicating that the vehicle has HUD functionality but lacks Bluetooth functionality.

[0039] The aforementioned collection of the vehicle's latest software and version information is necessary because OTA upgrades can change the vehicle's software version status. Therefore, the vehicle periodically queries the software version information that requires OTA upgrades and then synchronizes the vehicle's current version information to the cloud system. The cloud system records the version information of the vehicle's currently available OTA software, thus revealing the vehicle's current software version status. For example, the vehicle synchronizes the current version SWC:1.2.0 for 9111701-CD01 and the current version SWC:1.5.0 for 9111861-HM01 to the cloud system. The cloud records the current latest version of 9111701-CD01 as SWC:1.0.0 and the current latest version of 9111861-HM01 as SWC:1.5.0.

[0040] When defining the orchestration, such as Figure 3 As shown, the system first needs to dynamically obtain a list of programmable services, and then combine these services into the desired scenario. The system must ensure that all services in the programmable service list are usable by the vehicle. First, the system obtains the programmable objects and their service list for the vehicle model, such as seats, HUD, Bluetooth, and doors, along with their provided services. Seats and HUD are OTA-enabled software, while HUD and Bluetooth are optional or plug-in components. Doors are non-OTA software and neither optional nor plug-in components. The system filters out programmable objects whose configuration items are optional or plug-in components, and which exist in the obtained vehicle optional or plug-in component information, along with their sub-programmable objects and services. Bluetooth is filtered out because it is not installed on the vehicle. From the obtained service list, configuration items requiring OTA updates are selected, and the lowest software version in the corresponding configuration item must be less than or equal to the current vehicle software version information obtained above for the configuration item, its sub-configuration items, and services. In this case, the latest version of 9111701-CD01 is SWC:1.0.0, and the latest version of 9111861-HM01 is SWC:1.5.0. The passenger seat footrest adjustment service is filtered out. Configuration items that are not optional or plug-in components and are not OTA-enabled are directly included in the service list by default. In this case, door and related services are not filtered out. Thus, the final service list that can be configured for the user's vehicle is obtained.

[0041] When a user accesses a system-recommended scenario that can be subscribed to, this scenario is actually a pre-arranged combination of services by the automaker to facilitate user use. The services within this recommended scenario should also be guaranteed to be usable by that specific vehicle. For example... Figure 4As shown, the process first obtains a list of system-recommended scenarios available for subscription based on the vehicle model. Then, the final list of services that can be programmed for the user's vehicle is obtained using the method described above. If a system-recommended scenario in the system-recommended scenario list contains a service that is not in the user's programmable service list, then that system-recommended scenario will be unavailable on that vehicle and should be filtered out. For example, the "Nap Mode" system-recommended scenario uses the passenger seat footrest adjustment service. However, since the current latest version of 9111701-CD01 is SWC:1.0.0, while the passenger seat footrest adjustment service requires at least SWC:1.2.0, this version does not have the passenger seat footrest adjustment service. In other words, the "Nap Mode" system-recommended scenario is unusable on this vehicle and is filtered out. All other system-recommended scenarios satisfy the requirement that the service is in the programmable service list. Finally, the list of system-recommended scenarios that the user's vehicle can subscribe to is obtained.

[0042] Example 2

[0043] This embodiment is a device for service orchestration and filtering of available vehicle services, applied to a service platform. The device includes: an orchestration object configuration module for managing the combination of services by orchestration objects and adding constraint configurations to orchestration objects and services; a vehicle optional or plug-in component information collection module for collecting the status of vehicle optional or plug-in components, determining whether optional or plug-in components are available, and synchronizing the information to a cloud system; a vehicle software version information module for periodically querying the software version information in the vehicle that requires OTA upgrades and synchronizing the current version information of the vehicle to a cloud system; and an unavailable service filtering module for filtering unavailable services.

[0044] Example 3

[0045] This embodiment describes a vehicle that uses the service orchestration filtering method described in Embodiment 1 above to perform OTA upgrades.

[0046] Example 4

[0047] This embodiment is a computer-readable storage medium storing a computer program. When the computer program is run on a computer, it causes the computer to execute the method described in Embodiment 1 above. Through the above description of the embodiments, those skilled in the art can clearly understand that this application can be implemented in hardware or by using software plus a necessary general-purpose hardware platform. Based on this understanding, the technical solution of this application can be embodied in the form of a software product. This software product can be stored in a non-volatile storage medium (such as a CD-ROM, USB flash drive, or portable hard drive), including several instructions to cause a computer device (such as a personal computer, braking device, or network device, etc.) to execute the methods described in the various implementation scenarios of this application.

[0048] In the embodiments provided in this application, it should be understood that the disclosed apparatus, systems, and methods can also be implemented in other ways. The apparatus, systems, and methods embodiments described above are merely illustrative. For example, the flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of this application. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code, which includes one or more executable instructions for implementing a specified logical function. It should also be noted that each block in a block diagram and / or flowchart, and combinations of blocks in block diagrams and / or flowcharts, can be implemented using a dedicated hardware-based system that performs the specified function or action, or using a combination of dedicated hardware and computer instructions. Furthermore, the functional modules in the various embodiments of this application can be integrated together to form an independent part, or each module can exist independently, or two or more modules can be integrated to form an independent part.

[0049] The above description is merely an embodiment of this application and is not intended to limit the scope of protection of this application. Various modifications and variations can be made to this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the scope of protection of this application.

Claims

1. A method for service orchestration and filtering of available services for vehicles, characterized in that the steps include: include: Orchestration object configuration; Collect information on vehicle optional or plug-in components; Collect vehicle software version information; Filter out unavailable services or system recommendation scenarios that the user's vehicle cannot subscribe to from the service list, and obtain the recommendation list; The orchestration object configuration includes: managing services by orchestration object; configuring several levels of sub-orchestration objects under one orchestration object; configuring the service list of the lowest-level sub-orchestration object under the lowest-level sub-orchestration object; adding constraint configurations to the sub-orchestration objects and services; setting a minimum version for the software number of the sub-orchestration objects and services separately to accommodate software version differences when adding new services; filtering out unavailable services from the user's vehicle's unorchestration service list includes: dynamically obtaining a custom orchestrated service list for the user; obtaining orchestratization objects and their service lists for the vehicle model; filtering out configuration items of orchestration objects that are plug-in components and exist in the vehicle's optional or plug-in component information, and obtaining the orchestration of the vehicle's optional or plug-in components. The system includes: 1) an object, and sub-arrangement objects and services; 2) filtering the configuration items of the orchestration objects from the obtained service list that require OTA updates and whose corresponding software version is less than or equal to the current vehicle software version obtained from the vehicle software version information; 3) the orchestration objects and their sub-arrangement objects and services; 4) orchestration objects that are not optional or plug-in components and are not OTA-enabled, which are directly included in the service list by default, thus obtaining the final list of services that can be orchestrated for the user's vehicle; 5) filtering out system recommendation scenarios that the user's vehicle cannot subscribe to includes: obtaining a list of subscribing system recommendation scenarios; obtaining a list of orchestratable services for the user's vehicle; filtering system recommendation scenarios based on the list of orchestratable services; and obtaining a list of system recommendation scenarios that the user's vehicle can subscribe to.

2. The service orchestration and filtering method for available vehicle services according to claim 1, characterized in that: The constraint configuration includes software number, minimum version, whether it is a pluggable component, and whether it supports OTA.

3. The service orchestration and filtering method for available vehicle services according to claim 2, characterized in that: The collection of vehicle optional or plug-in parts information includes: first collecting the status of vehicle optional or plug-in parts, determining whether the optional or plug-in parts are available, and then synchronizing the information to the cloud system, whereby the cloud system records the vehicle optional or plug-in parts information.

4. The service orchestration and filtering method for available vehicle services according to claim 3, characterized in that: The collection of vehicle software version information includes: first collecting the current software version status of the vehicle, and then synchronizing the current software version information of the vehicle to the cloud system. The cloud system records the version information of the software that can be OTA-enabled in the vehicle and queries the current software version status of the vehicle.

5. A device for service orchestration and filtering of available services for vehicles, characterized in that: Applied to a service platform, the device includes: an orchestration object configuration module for managing the combination of services by orchestration objects and adding constraint configurations to orchestration objects and services; a vehicle optional or plug-in component information collection module for collecting the status of vehicle optional or plug-in components, determining whether optional or plug-in components are available, and synchronizing the information to the cloud system; a vehicle software version information module for periodically querying the software version information that needs OTA upgrades in the vehicle and synchronizing the current vehicle version information to the cloud system; and an unavailable service filtering module for filtering unavailable services. The orchestration object configuration module is used to: manage the combination of services according to orchestration objects, configure several levels of sub-orchestration objects under one orchestration object, and configure the service list of the lowest-level sub-orchestration objects under the lowest-level sub-orchestration objects; add constraint configurations to sub-orchestration objects and services; set a minimum version for the software number of sub-orchestration objects and services separately to adapt to the software version differences brought about by the addition of services; and filter out unavailable services from the user's vehicle's unorchestration service list. The service is used for: dynamically obtaining a customizable programmable service list for users; obtaining programmable programmable objects and their service lists for vehicle models; filtering programmable object configuration items as plug-in components that exist in vehicle optional or plug-in component information, obtaining the programmable objects of vehicle optional or plug-in components, as well as their sub-programmable objects and services; filtering programmable object configuration items that require OTA updates and whose corresponding software minimum version is less than or equal to the current vehicle software version obtained from the vehicle software version information, as well as their sub-programmable objects and services; for non-optional or plug-in component programmable objects and non-OTA programmable objects in the configuration items, they are directly included in the service list by default, resulting in the final programmable service list for the user's vehicle; filtering out system recommendation scenarios that the user's vehicle cannot subscribe to is used for: obtaining a list of subscribing system recommendation scenarios for users; obtaining the user's programmable service list for vehicles; filtering system recommendation scenarios based on the programmable service list; and obtaining a list of subscribing system recommendation scenarios for the user's vehicle.

6. A vehicle, characterized in that: The vehicle uses the service orchestration filtering method for available vehicle services as described in claim 1 for OTA upgrades.

7. A computer-readable storage medium, characterized in that: The computer-readable storage medium stores a computer program that, when run on a computer, causes the computer to perform the method of claim 1.

Images