Service orchestration system, method and apparatus

Abstract

Disclosed are a service orchestration system, method and apparatus, applied to the technical field of vehicles. The service orchestration system comprises a script execution module, an interface management module, and a service management module. The script execution module is configured to execute a first script, wherein the first script is used for implementing a first service, and the first service depends on at least a first sub-service. The interface management module is configured to determine that the invocation of a first standardized interface of the first sub-service by the first script satisfies a functional safety condition corresponding to the first standardized interface, and convert the first standardized interface into a corresponding first service-based interface. The service management module is configured to communicate with the first sub-service on the basis of the first service-based interface. The first service herein is a newly added service of a vehicle. In this way, rapid development of newly added services of vehicles can be achieved, thereby improving development efficiency. In addition, performing functional safety checks when scripts invocate interfaces of services is conducive to improving the safety of vehicles.

Description

A service orchestration system, method and apparatus Technical Field

[0001] This application relates to the field of vehicle technology, and more particularly to a service orchestration system, method and apparatus. Background Technology

[0002] With the continuous development of vehicle technology, service-oriented architecture (SOA) has been implemented. SOA is a system architecture design under software-defined vehicles. SOA abstracts the capabilities of a system into multiple services and meets the various needs of the vehicle system based on the dependencies between these services.

[0003] Today, users have increasingly higher demands for vehicles in terms of entertainment, comfort, safety, and handling. To provide better service, when automakers collect user requests for new vehicle features, they organize developers to code these features as services, integrate the code into the vehicle's software, and finally release a new over-the-air (OTA) software package to update users' vehicles. This process results in long development times and low efficiency, even for simple features. Summary of the Invention

[0004] This application discloses a service orchestration system, method, and apparatus that enables rapid development of new vehicle services, improving development efficiency. Furthermore, it performs functional safety checks when scripts call service interfaces, which helps improve vehicle safety.

[0005] In a first aspect, this application provides a service orchestration system, which includes a script execution module, an interface management module, and a service management module. The script execution module is used to execute a first script, which implements a first service, which is a new service for a vehicle and depends on at least a first sub-service. The interface management module is used to determine whether the call of the first script to a first standardized interface of the first sub-service satisfies the functional safety conditions corresponding to the first standardized interface, and to convert the first standardized interface into a corresponding first service-oriented interface. The service management module is used to communicate with the first sub-service based on the first service-oriented interface.

[0006] For example, the first service generally involves enhancing the user's cabin experience, vehicle experience, driving experience, and other user-friendly aspects, but does not involve vehicle driving safety. For instance, enhancing the cabin experience could involve improving functions or services such as in-vehicle entertainment system, ambient lighting control, fragrance control, seat control, and air conditioning control, while enhancing the vehicle experience could involve enhancing remote vehicle control services such as door control, seat preheating control, valet parking, and welcome services.

[0007] For example, the first service depending on the first sub-service means that, from the perspective of functional implementation, the functions provided by the first sub-service may include those provided by the first sub-service; from the perspective of data support, the operation of the first service may require data provided by the first sub-service as input or reference.

[0008] The aforementioned standardized interfaces can also be called software-defined vehicles (SDV) standardized interfaces. Standardized interfaces are industry-unified abstract specifications designed to solve compatibility issues across different automakers and hardware. However, the definitions of standardized interfaces are relatively general and not optimized for specific vehicle models or SOA architectures. Service-oriented interfaces, on the other hand, are communication interfaces designed by automakers or platforms based on their own SOA architecture and tailored to specific functionalities (such as dynamic service discovery and specific algorithm logic). Converting standardized interfaces into proprietary service-oriented interfaces for automakers or platforms achieves adaptation between industry standards and automaker-specific architectures, resolving the contradictions between generality and customization, and between static specifications and dynamic services, while simultaneously improving service flexibility, maintainability, and development efficiency.

[0009] Script calls to standardized interfaces should not affect the vehicle's functional safety. For example, functional safety encompasses the system's core safety functions (e.g., braking, steering, power control, autonomous driving), software safety (i.e., software meeting safety integrity levels), and cybersecurity. Setting functional safety conditions for interfaces ensures that script calls to standardized interfaces do not cause systemic software malfunctions or functional conflicts in the vehicle, thus avoiding unacceptable risks to personnel, the vehicle, or the environment.

[0010] The aforementioned service orchestration system uses scripts to develop new services for vehicles. Scripting languages ​​typically have concise and flexible syntax, significantly shortening the development cycle and allowing developers to quickly implement service orchestration, thus reducing development costs. In terms of deployment, scripts are easily integrated into existing vehicle systems without requiring large-scale modifications to the entire system, enabling rapid deployment of new services. Furthermore, during script execution, functional safety checks are performed on interface calls to prevent improper interface calls from causing abnormalities or malfunctions in vehicle functions. This ensures the vehicle operates safely and reliably under various conditions, providing safety guarantees for drivers and passengers and improving the overall security and reliability of the vehicle service system.

[0011] In one possible implementation of the first aspect, the script execution module is specifically used to: execute a first script in response to a service request, wherein the service request includes an identifier of a first service and an identifier of a first user, and the first user is associated with the first service; the interface management module is also used to determine whether the first user has permission to call the first standardized interface.

[0012] Here, the first user is the user who triggers the execution of the first script. The first user is associated with the first service, meaning that one execution of the first script corresponds to one user triggering that execution.

[0013] By implementing the above method, permission checks are performed on the interface calls during script execution to strictly control the legality of interface access. Only entities with the corresponding permissions can call specific interfaces, thereby effectively preventing unauthorized access and data leakage, protecting information security within the vehicle system, and ensuring stable system operation.

[0014] In one implementation, the first service is an extension of the vehicle's second service, wherein the second service is implemented via an OTA software package.

[0015] By implementing the above method, after implementing the second service of the vehicle through OTA software, and if there are any extensions or enhancements to the second service, the first service can be developed in the form of scripts. This can quickly extend the existing second service of the vehicle, improve software development efficiency, and increase the launch rate of new services.

[0016] Optionally, if the first service is an extension of the vehicle's second service, the service management module is also used to bind the first service to the communication address of the second service.

[0017] Implementing the above method, the communication address of the first service is the same as the communication address of the second service. This allows the first service to reuse the communication address of the second service during service additions or upgrades, eliminating the need for large-scale configuration changes by external systems or clients that depend on the second service. It also reduces the management cost and complexity of communication addresses within the system. External systems can continue to use their original communication addresses to interact with the system, enabling the first service to also communicate with external systems. This ensures compatibility with these external systems, avoids errors and failures caused by address changes, and guarantees the stable operation of the entire business ecosystem.

[0018] Furthermore, during the execution of the first script, the first script is also used to determine, based on the acquired business scenario information, to enable at least one of the first service and the second service.

[0019] In other words, the execution logic for determining whether to enable the first service and / or the second service is carried out within the script code of the first script. Due to the high readability and maintainability of the script code, developers can flexibly customize service content according to vehicle characteristics and user needs.

[0020] In another implementation, the first service is used to implement the function of the first component, which is a newly added component of the vehicle.

[0021] It's understandable that for high-value components in a vehicle (such as higher-performance processor modules, more sensitive sensor modules, etc.), automakers can provide OTA support by planning new software versions to enable the launch of new services. However, for some small components in the cabin that enhance the user's cabin experience (such as air quality sensors, air fresheners, function buttons, etc.), these components vary in form and function and iterate rapidly. Developing them using scripts, compared to OTA version development, can greatly reduce development costs and efficiency, enabling the rapid launch of new services.

[0022] Optionally, the script execution module is also used to execute a second script, which converts the user's operation on the first component into a service request, wherein the user is a person who enjoys the first service.

[0023] By implementing the above method, the second script provides hardware support for the first component, converting user operations on the new component into service requests that trigger the execution of the first script. The first script includes the execution logic for the new service, thus providing application support for the first component. This makes it possible to develop new services for new vehicle components via scripts. Furthermore, it decouples hardware and application logic, allowing for independent modification of the corresponding scripts when hardware or application requirements change, which improves code maintainability and portability.

[0024] Optionally, the first script is further used to provide control parameters for the first component; the second script is further used to control the first component based on the acquired control parameters of the first component.

[0025] As an example, suppose the first service implemented by the first script is the temperature control of the cabin air conditioning. The control parameter of the first component can be the current temperature of the cabin air conditioning. The second script is used to control the first component based on the acquired control parameter of the first component. This can be: the second script is used to control the first component to display based on the acquired current temperature of the cabin air conditioning.

[0026] By implementing the above method, when the first component supports bidirectional communication, the second script can also be used to achieve reverse control of the first component based on the control parameters of the first component provided by the first script.

[0027] In one possible implementation of the first aspect, the script execution module is further configured to obtain the first script from the user terminal or network-side device.

[0028] Implementing the above methods, the first script is obtained from the user terminal side, which allows users to independently develop scripts according to their own needs and preferences. This enables personalized customization of the services implemented by the script, enhances user participation, and helps improve user loyalty to the product. Obtaining the first script from network-side devices results in higher quality and standardization of the first script, and it also has good compatibility with the vehicle's hardware and software systems, facilitating remote management and maintenance of the script.

[0029] In one possible implementation of the first aspect, the interface management module is specifically used to: retrieve, from the permission database, a whitelist of target users corresponding to the provider of the first script, the identifier of the first sub-service, and the identifier of the first standardized interface; the whitelist of target users is used to indicate users allowed to use the first standardized interface; and determine that the first user belongs to the whitelist of target users. Here, the permission database includes the correspondence between the provider of the first script, the identifier of the first sub-service, the identifier of the first standardized interface, and the whitelist of target users.

[0030] By implementing the above method, different script providers offer different service interfaces to different users. If the first user belongs to the target user whitelist corresponding to the first script provider, the first sub-service, and the first standardized interface, then the first user has permission to use the first standardized interface of the first sub-service in the script provided by the first script provider. This ensures the legitimacy of interface access; only entities with the corresponding permissions can call the corresponding interface, effectively preventing unauthorized access and protecting information security within the vehicle system.

[0031] In one possible implementation of the first aspect, the script execution module is further configured to receive permission update information from the network-side device; the interface management module is further configured to update the permission database based on the permission update information.

[0032] For example, the permission update information includes at least one mapping relationship to be updated. One mapping relationship in the permission update information records the mapping relationship between the script provider, the service identifier, the interface identifier, and the user whitelist. Here, updating includes at least one of the operations of adding, modifying, and deleting.

[0033] Implementing the above method supports dynamically updating interface permissions, which not only allows for timely responses to security vulnerabilities and enhances system security, but also increases the flexibility of interface permission control, enabling more granular and precise interface access control.

[0034] In one possible implementation of the first aspect, the interface management module is specifically used for: retrieving a target inspection script from an inspection database based on the identifier of the first sub-service and the identifier of the first standardized interface; the target inspection script is used for functional safety judgment when calling the first standardized interface; and executing the target inspection script to determine whether the call of the first script to the first standardized interface satisfies the functional safety conditions corresponding to the first standardized interface. Here, the inspection database includes the identifier of the first sub-service, the identifier of the first standardized interface, and the correspondence between the target inspection script.

[0035] Since different services may have different or the same interfaces, and the same service may have different interfaces, the corresponding inspection scripts for the same interface of different services may be different, and the corresponding inspection scripts for different interfaces of the same service may also be different. Different inspection scripts correspond to different functional safety conditions. Therefore, by using the service identifier and the interface identifier, the inspection script corresponding to the interface of the service can be accurately found from the inspection database. In this way, functional safety checks on the interface of the service can be achieved.

[0036] In one possible implementation of the first aspect, the script execution module is further configured to receive security update information from the network-side device; the interface management module is further configured to update the inspection database based on the security update information.

[0037] For example, the security update information includes at least one mapping relationship to be updated. One mapping relationship in the security update information is used to record the mapping relationship between the service identifier, the interface identifier, and the inspection script. Here, updating includes at least one of the operations of adding, modifying, and deleting.

[0038] Implementing the above method supports dynamically updating the inspection scripts corresponding to the interfaces, thus updating the functional safety conditions or rules that the interface calls must meet. This effectively addresses emerging security threats and significantly reduces the risks posed to vehicles by the script mechanism. Furthermore, it increases the flexibility of updating the inspection scripts, allowing for adaptability to system updates and hardware configuration changes.

[0039] In one possible implementation of the first aspect, the script execution module is further configured to send operation and maintenance observation information to the network-side device, the operation and maintenance observation information including at least one of the following:

[0040] Execution information for each script;

[0041] Resource consumption for each script;

[0042] The invocation of standardized interfaces during script execution; and,

[0043] Statistical information on communication between various services during script execution.

[0044] By implementing the above methods, the service orchestration system can provide operational and maintenance observation information for network-side devices, supporting OEMs in performing operations and maintenance to obtain user interests. This allows developers to provide script services that are closer to user habits and preferences. Furthermore, it can determine the direction of system optimization, improve script performance, and enhance system efficiency.

[0045] Secondly, this application provides a service orchestration method, which includes: executing a first script, wherein the first script is used to implement a first service, the first service being a new service for a vehicle, and the first service depending on at least a first sub-service; during the execution of the first script, communicating with the first sub-service based on a first service-oriented interface; wherein the first service-oriented interface is obtained by converting a first standardized interface of the first sub-service, and the call of the first script to the first standardized interface satisfies the functional safety conditions corresponding to the first standardized interface.

[0046] In one possible implementation of the second aspect, executing the first script includes: responding to a service request and executing the first script. The service request includes an identifier of a first service and an identifier of a first user, and the first user is associated with the first service. Before communicating with the first sub-service based on the first service interface, the service orchestration method further includes: determining that the first user has permission to call the first standardized interface.

[0047] In one implementation, the first service is an extension of the vehicle's second service, wherein the second service is implemented via an OTA software package.

[0048] Optionally, if the first service is an extension of the second service of the vehicle, the service orchestration method further includes binding the first service to the communication address of the second service.

[0049] Furthermore, during the execution of the first script, the first script is also used to determine, based on the acquired business scenario information, to enable at least one of the first service and the second service.

[0050] In another implementation, the first service is used to implement the function of the first component, which is a newly added component of the vehicle.

[0051] Optionally, before executing the first script, the service orchestration method further includes executing a second script, wherein the second script is used to convert the user's operation on the first component into a service request, and the user is a person who enjoys the first service.

[0052] In one possible implementation of the second aspect, the first script is further used to provide control parameters for the first component, and the second script is further used to control the first component based on the obtained control parameters of the first component.

[0053] In one possible implementation of the second aspect, the service orchestration method further includes: obtaining a first script from a user terminal or network-side device.

[0054] In one possible implementation of the second aspect, determining whether the first user has permission to call the first standardized interface includes: retrieving a target user whitelist from the permission database corresponding to the provider of the first script, the identifier of the first sub-service, and the identifier of the first standardized interface; the target user whitelist is used to indicate users permitted to use the first standardized interface; and determining that the first user belongs to the target user whitelist. Here, the permission database includes the correspondence between the provider of the first script, the identifier of the first sub-service, the identifier of the first standardized interface, and the target user whitelist.

[0055] In one possible implementation of the second aspect, the service orchestration method further includes: receiving permission update information from network-side devices; and updating the permission database based on the permission update information.

[0056] In one possible implementation of the second aspect, the process of determining that the call of the first script to the first standardized interface satisfies the functional safety conditions corresponding to the first standardized interface includes: retrieving a target inspection script from an inspection database based on the identifier of the first sub-service and the identifier of the first standardized interface; the target inspection script is used for functional safety checks when the first standardized interface is called; and executing the target inspection script to determine that the call of the first script to the first standardized interface satisfies the functional safety conditions corresponding to the first standardized interface. Here, the inspection database includes the identifier of the first sub-service, the identifier of the first standardized interface, and the correspondence between the target inspection script.

[0057] In one possible implementation of the second aspect, the service orchestration method further includes: receiving security update information from network-side devices; and updating the inspection database based on the security update information.

[0058] In one possible implementation of the second aspect, the service orchestration method further includes: sending operation and maintenance observation information to network-side devices, wherein the operation and maintenance observation information includes at least one of the following:

[0059] Execution information for each script;

[0060] Resource consumption for each script;

[0061] The invocation of standardized interfaces during script execution; and,

[0062] Statistical information on communication between various services during script execution.

[0063] Thirdly, this application provides an apparatus for service orchestration, the apparatus including a processor and a memory, wherein the memory is used to store program instructions; the processor invokes the program instructions in the memory to cause the apparatus to perform the method in the second aspect or any possible implementation of the second aspect.

[0064] Fourthly, this application provides a vehicle that includes the service orchestration system of the first aspect or any possible implementation thereof, or includes the apparatus described in the third aspect.

[0065] Fifthly, this application provides a computer-readable storage medium including computer instructions that, when executed by a processor, implement the method in the second aspect or any possible implementation thereof.

[0066] Sixthly, this application provides a computer program product that, when executed by a processor, implements the methods described in the second aspect or any possible embodiment of the second aspect. The computer program product may, for example, be a software installation package. When the methods provided by any possible design of the second aspect are required, the computer program product can be downloaded and executed on a processor to implement the methods described in the second aspect or any possible embodiment of the second aspect.

[0067] The technical effects of the second to sixth aspects mentioned above can be referred to the description of the first aspect above, and will not be repeated here. Attached Figure Description

[0068] Figure 1 is a schematic diagram of the architecture of a communication system for service orchestration provided in an embodiment of this application;

[0069] Figure 2 is a schematic diagram of the architecture of a service orchestration system provided in an embodiment of this application;

[0070] Figure 3 is a flowchart of a service orchestration method provided in an embodiment of this application;

[0071] Figure 4 is an example diagram of permission judgment and functional security check for executing interface calls provided in an embodiment of this application;

[0072] Figure 5 is a flowchart of another service orchestration method provided in an embodiment of this application;

[0073] Figure 6 is a flowchart of another service orchestration method provided in an embodiment of this application;

[0074] Figure 7 is a flowchart of an operation and maintenance method provided in an embodiment of this application;

[0075] Figure 8 is a flowchart of a method for updating interface permissions provided in an embodiment of this application;

[0076] Figure 9 is a flowchart of a method for updating an interface check script provided in an embodiment of this application;

[0077] Figure 10 is a schematic diagram of script debugging provided in an embodiment of this application;

[0078] Figure 11 is a schematic diagram of a service orchestration apparatus provided in an embodiment of this application;

[0079] Figure 12 is a schematic diagram of the structure of a computing device provided in an embodiment of this application. Detailed Implementation

[0080] In this scheme, prefixes such as "first" and "second" are used solely to distinguish different descriptive objects and do not impose any restrictions on the position, order, priority, quantity, or content of the described objects. For example, if the described object is a "field," the ordinal numbers preceding "field" in "first field" and "second field" do not restrict the position or order of the "fields." "First" and "second" do not restrict whether the modified "fields" are in the same message, nor do they restrict the order of "first field" and "second field." Similarly, if the described object is a "level," the ordinal numbers preceding "level" in "first level" and "second level" do not restrict the priority of the "levels." Furthermore, the number of described objects is not limited by prefixes; it can be one or more. For example, in "first device," the number of "devices" can be one or more. Furthermore, the objects modified by different prefixes can be the same or different. For example, if the object being described is "device," then "first device" and "second device" can be the same device, devices of the same type, or devices of different types. Similarly, if the object being described is "information," then "first information" and "second information" can be information with the same content or information with different content. In summary, the use of prefixes to distinguish the objects being described in the embodiments of this application does not constitute a limitation on the objects being described. The description of the objects being described is based on the claims or the context of the embodiments, and should not constitute an unnecessary limitation due to the use of such prefixes.

[0081] To facilitate understanding, the relevant terms that may be involved in the embodiments of this application will be introduced below.

[0082] (1)Script

[0083] A script is a program written in a programming language that is typically used to automate certain tasks or operations. For example, scripting languages ​​can be Python, JavaScript, Shell, Ruby, and PHP, among others. These scripting languages ​​are cross-platform; provided the system has the appropriate interpreter or virtual machine installed, scripts written in cross-platform scripting languages ​​can run on different operating systems (such as Windows, Linux, macOS, etc.).

[0084] Unlike traditional compiled programs, scripts are generally interpreted, meaning their code is not compiled into machine code but is read and executed line by line by an interpreter or virtual machine. Furthermore, scripts can be embedded into other programs or interact with them as needed. This makes scripts more flexible and efficient during development and debugging.

[0085] (2) Script execution environment

[0086] A script execution environment (SEX) is the hardware and software environment used to run and execute script code (such as Python, JavaScript, and Shell). It provides an infrastructure that supports script code interpretation and execution, including an interpreter, runtime libraries, and system resources. The interpreter parses and executes the script code. The runtime library includes standard libraries (or program libraries) and extension libraries. The standard libraries provide general functions such as mathematical calculations, system resource allocation / release, and exception handling. The extension libraries include pre-defined functions that demonstrate how scripts can interoperate with services of other parts of the system (e.g., control systems). Script execution depends on the runtime library. System resources include memory, hard disk, network, and other resources that the script needs during execution. A script execution environment is typically a runtime environment that helps scripts interact with the operating system, hardware, and other applications.

[0087] (3) Standardized Interface

[0088] Standardized interfaces can also be called software-defined vehicle (SDV) standardized interfaces. SDV standardized interfaces are a series of standardized interface specifications developed by the China Association of Automobile Manufacturers in the context of software-defined vehicles (SDV) to promote the decoupling of automotive software and hardware and accelerate the application and iteration of new technologies.

[0089] The SDV-defined service software architecture is divided into four layers: the application layer (composite services), the atomic service layer (basic functional modules), the device abstraction layer (hardware resource abstraction), and the basic platform layer (hardware / OS). The application layer is used to define and combine enhanced vehicle services, applications, and user experiences based on atomic services, building differentiated software programs. The atomic service layer consists of functional modules that implement data fusion or control logic, generally serving as the smallest unit and single execution entity of a service. It provides on-demand orchestratable basic services to applications through application programming interfaces (APIs), enabling development once and reuse multiple times, maximizing development efficiency. The device abstraction layer abstracts hardware resources such as sensors, actuators, and electronic control units (ECUs), providing device access interfaces to services through APIs, shielding differences in device functionality (e.g., hardware differences, manufacturer differences), and reducing customization and repetitive work. The basic platform layer includes hardware and the operating system, primarily providing the basic operating environment required for vehicle operation.

[0090] Standardized interfaces are industry-wide unified abstract specifications (such as device abstract APIs and atomic service APIs) designed to solve compatibility issues across different automakers and hardware. For example, standardized interfaces mainly include atomic service APIs and device abstract APIs. Atomic service APIs primarily provide unified interface specifications for systems such as the body control module (BCM), thermal management system (TMS), vehicle control system (VCS), energy management system (EMS), and human-machine interface (HMI). Device abstract APIs primarily provide unified interaction interface specifications for devices in the body domain, thermal management domain, powertrain domain, chassis domain, and intelligent driving domain. This simplifies the communication complexity between devices and systems, enhancing system interoperability and compatibility.

[0091] Taking intelligent vehicle lighting control service as an example, assume that its standardized interface includes the device abstract API "Lighting.SetBrightness(light_id, value)" and the atomic service API "BCM.SetHeadlightMode(mode)".

[0092] 1) `Lighting.SetBrightness()` is used to set the brightness of specific lighting devices. `light_id` uniquely identifies the lighting device to be controlled, such as the ID of different lights like headlights, taillights, or ambient lighting. `value` represents the brightness value to be set, which can be a specific integer between 0 and 255, corresponding to different brightness levels. This standardized interface, `Lighting.SetBrightness()`, shields the differences in hardware control between different brands and models of lighting devices (such as different drive circuits and dimming methods), and provides a unified operating interface for upper-layer software. This allows different applications or services to control the brightness of vehicle lights in the same way (i.e., by passing the corresponding parameters according to the interface specifications). Furthermore, when lighting devices are upgraded or replaced, as long as the new lighting device supports the device abstraction layer interface, it can be seamlessly integrated into the system, reducing the impact of hardware upgrades on the software system. In summary, this improves software portability and hardware compatibility.

[0093] 2) `BCM.SetHeadlightMode()` is used to set the operating mode of the headlights. `mode` can represent different modes, such as low beam, high beam, and automatic. The Body Control Module (BCM) controls the headlights accordingly based on the passed mode parameters. Encapsulating headlight mode control as an atomic service makes the system's functional division clearer and facilitates management and maintenance. At the same time, the standardized interface `BCM.SetHeadlightMode()` also facilitates interaction and calls between different software modules. For example, it can be called by multiple modules such as the vehicle's central control system and intelligent driving assistance system to control the headlight mode, improving system reusability.

[0094] (4) Service-oriented interface

[0095] Generally, vehicle SOA adopts a layered development model with upper-layer applications, a middle-layer operating system, and lower-layer hardware, achieving decoupling between automotive software systems and hardware. SOA modularizes different functional units of upper-layer applications (such as applications on the vehicle's ECU), breaking them down into different services and defining corresponding service interfaces. Service interfaces are channels used to enable communication between services after abstracting the capabilities of the vehicle system into multiple services. Services are discoverable software entities. Services communicate with each other through service interfaces and can dynamically discover and invoke other services.

[0096] Service-oriented interfaces (SAAs) are communication interfaces designed by automakers or platforms based on their own SOA architecture (such as atomic service interfaces of IP-based scalable service-oriented middleware SOME / IP). These interfaces must be tailored to specific functionalities (such as dynamic service discovery or specific algorithm logic). SAAs design references SOA middleware principles, selecting different interface protocols based on different use cases. Therefore, different automakers or component suppliers may design different SAAs.

[0097] Taking intelligent headlight control services as an example, for a specific automaker, the standardized interface "BCM.SetHeadlightMode()" can be broken down into two finer-grained service interfaces: service interface 1 "HeadlightService::SetMode()" and service interface 2 "HeadlightService::AdjustBrightness()". Service interface 1 implements headlight mode control, while service interface 2 implements dynamic headlight dimming. This allows for finer-grained and more precise control of the headlights. For example, in some scenarios, it might only be necessary to adjust the headlight brightness without changing the mode, or simply switch modes without adjusting brightness. Furthermore, some users might want to customize the headlight brightness in specific modes. Through these fine-grained service interfaces, developers can perform more precise operations based on actual needs, improving the system's functional scalability and flexibility. In some solutions, standardized interfaces may lack the ability to link different services. Automakers can also add a service interface 3 "AmbientLightService::GetLux()" for the ambient light sensor service to implement automatic dimming logic. In this way, by introducing new services and combining them, service interfaces can achieve more intelligent and adaptive functions.

[0098] The aforementioned standardized interfaces are industry-wide abstract specifications (such as device abstract APIs and atomic service APIs) designed to address compatibility issues across different vehicle manufacturers and hardware. However, the definitions of these standardized interfaces are quite general and not optimized for specific vehicle models or SOA architectures. In a vehicle's SOA architecture, these standardized interfaces are converted into proprietary service interfaces for vehicle manufacturers or platforms. This achieves adaptation between industry standards and vehicle manufacturer-specific architectures, resolving the conflict between generality and customization, and between static specifications and dynamic services. Simultaneously, it improves service flexibility, maintainability, and development efficiency.

[0099] The above terms may optionally be used in the embodiments described below.

[0100] This solution provides a service orchestration system that enables the rapid development of new vehicle services via scripts, improving development efficiency. Furthermore, when executing scripts, the service orchestration system can perform functional safety checks on the standardized interface calls of services within the scripts, which contributes to improved vehicle safety.

[0101] Referring to Figure 1, Figure 1 is a schematic diagram of a communication system for service orchestration provided in an embodiment of this application. The communication system includes at least one of a network-side device and a terminal device, as well as a service orchestration system. The service orchestration system is deployed on a vehicle. Communication between the network-side device and the service orchestration system, and between the terminal device and the service orchestration system, is wireless.

[0102] Here, the network-side device provides scripts developed by script developers to implement a new service for the vehicle. For example, the script developer could be a vehicle engineer from an original equipment manufacturer (OEM) or a vehicle engineer from an OEM component supplier. For example, the network-side device could be a server deployed on the network side (e.g., a server providing script development services), or a component within that server (e.g., a chip). In some solutions, the network-side device can also be a system-level device composed of multiple servers. The network-side device can be deployed in a cloud environment or an edge environment.

[0103] Here, the terminal device can also be used to provide user-developed scripts to implement a new service for the vehicle. For example, the user can be the vehicle owner, a vehicle user, etc. For example, the terminal device can be a portable mobile device that provides script development capabilities, such as a mobile phone, tablet, or PDA.

[0104] It is understandable that both network-side devices and terminal devices belong to the front-end development platform. For example, after a script developer completes the script for adding a new vehicle service on the network-side device, the script is deployed to the vehicle, where the service orchestration system parses and executes it. Similarly, after a user completes the script for adding a new vehicle service on the terminal device, the script can also be deployed to the vehicle. This supports users in customizing their own vehicle's functions, improving the development efficiency of simple vehicle functions and enhancing the user experience.

[0105] The composition of the service orchestration system is described below. Referring to Figure 2, which is a schematic diagram of the architecture of a service orchestration system provided in an embodiment of this application, the service orchestration system includes a script execution module, an interface management module, and a service management module.

[0106] For example, the script execution module includes functions such as script engine, resource management, monitoring and statistics, user management, and data management.

[0107] The script engine is responsible for installing, activating, executing (or calling), and uninstalling scripts.

[0108] Resource management is used to allocate system resources required for script execution, such as central processing unit (CPU), memory, API call frequency, priority, etc.; and to reclaim system resources used by the script when the script finishes running or exits abnormally.

[0109] Monitoring and statistics provide at least one of the following functions: monitoring script execution status, performance metrics statistics, error and exception logging, and historical data analysis. For example, script execution status monitoring includes monitoring the script's startup, running, paused, and stopped states, as well as monitoring the script's resource usage during runtime; performance metrics statistics refer to acquiring performance data during script execution (such as runtime, response time, throughput, etc.), and further, statistical analysis of this performance data can be performed; error and exception logging refers to capturing errors and exception information that occur during script execution, including syntax errors, runtime errors, and system call failures; historical data analysis refers to analyzing stored historical data of script execution (such as execution status, performance metrics, error information, etc.) to discover patterns and trends in script execution, providing convenience for subsequent operation and maintenance and data mining.

[0110] User management is used to manage the users of scripts. Different developers (such as developers from OEMs and component suppliers, car owners, vehicle users, etc.) provide different scripts through network-side devices or terminal devices. Different scripts have different API sets. User management can obtain different users' execution permissions for scripts.

[0111] Data management is used to store scripts and related data (such as script configuration files, dependent libraries, execution results, etc.). When the same script is applied to different vehicles, different configuration files will be used to adapt to different vehicle models and users. Data management persistently stores the phased data generated during script execution so that it can be easily restored after the next restart.

[0112] It is understood that the functional division of the script execution module shown in Figure 2 is only an example. In some solutions, resource management and monitoring statistics shown in Figure 2 can also be integrated together.

[0113] Here, the interface management module includes interface conversion functionality. Specifically, it provides standardized interfaces to upper-layer scripts and vehicle-native service interfaces to lower-layer services. The interface conversion function maps standardized interfaces to service interfaces, achieving adaptation between industry standards and automaker-specific architectures. In some solutions, the interface management module can also provide a channel for scripts to directly access service interfaces, thus enabling developers to orchestrate more personalized and efficient script functionalities.

[0114] Furthermore, in this solution, the interface management module also includes a functional safety judgment management function. Functional safety judgment management applies when a script calls a standardized interface. Each standardized interface has corresponding functional safety conditions required for execution; for example, calling standardized interface 1 requires the car door to be unlocked; calling standardized interface 2 requires the vehicle to be parked, etc. For another example, when script 1 calls standardized interface A, if the call to standardized interface A meets the corresponding functional safety conditions, then script 1 is allowed to call standardized interface A. In some solutions, if the call to standardized interface A does not meet the corresponding functional safety conditions, then script 1 is denied the right to call standardized interface A.

[0115] In other words, script calls to standardized interfaces should not affect the vehicle's functional safety. For example, functional safety encompasses the system's core safety functions (such as braking, steering, power control, and autonomous driving), software safety (i.e., software meeting safety integrity levels), and cybersecurity. Setting up functional safety judgment management ensures that script calls to standardized interfaces do not cause systemic software malfunctions or functional conflicts in the vehicle, thus avoiding unacceptable risks to personnel, the vehicle, or the environment.

[0116] In some solutions, the interface management module also includes interface call permission management functionality. Interface call permission management applies when scripts call standardized interfaces. Developers pre-set a user whitelist for each standardized interface call; users on the whitelist have permission to call the corresponding standardized interface. For example, assuming user 1 is the user triggering script 1 to call standardized interface A, if the interface call permission management function determines that user 1 is on the user whitelist for standardized interface A, then script 1 is allowed to call standardized interface A. In some solutions, if user 1 is not on the user whitelist for standardized interface A, then script 1's call to standardized interface A is denied.

[0117] Here, the service management module is used to handle communication between services. For example, the core functions of the service management module include service discovery / publishing, service state maintenance, service message transformation, and service priority arbitration.

[0118] Service discovery / publishing is used to dynamically locate available services in the SOA architecture. The service management module can discover services already online in the system, and publish services implemented by installed and activated scripts to the system, based on the service registry or built-in communication protocols.

[0119] For example, the communication protocols supported by the service management module include scalable service-oriented middleware over IP (SOME / IP), data distribution service (DDS), hypertext transfer protocol (HTTP), robot operating system (ROS), and message queuing telemetry transport (MQTT). Specifically, SOME / IP is used for service communication in the vehicle control and cockpit domains, DDS / ROS is used in the intelligent driving domain, HTTP and MQTT are used for service communication in the vehicle cloud, and scripts use internal message queues for communication.

[0120] Service status maintenance is used to monitor the operational status of services. It can update the service list according to different communication protocols to maintain the availability of each service. For example, it can provide a service launch event when a service is online, and a service offline event when a service is offline.

[0121] Service message conversion is used to convert messages between different services. Different services may use different communication protocols, data formats, and message structures. Service message conversion enables effective communication between different services. For example, service message conversion can convert the internal message format of a script into SOME / IP or DDS encoded messages. Exemplary internal message formats of scripts include json, msgpack, protobuf, etc.

[0122] Service priority arbitration is used to prioritize services in resource contention or high-load scenarios. For example, service priority arbitration can arbitrate the processing priority of simultaneously arriving service requests based on user settings and / or business rules (such as security levels, functional importance, etc.). This effectively coordinates relationships between different services, avoiding system failures or security risks caused by conflicts.

[0123] It is understood that the functional division of the service management module shown in Figure 2 is only an example. In some solutions, service discovery / publishing and service status maintenance shown in Figure 2 can also be integrated together.

[0124] For example, referring to Figure 1, network-side devices or terminal devices can issue script installation, deletion, and upgrade commands to the service orchestration system through a user command interface, thus supporting network-side devices or terminal devices to issue script-specific operation commands to vehicles. In some solutions, in development mode, network-side devices can also perform online debugging of scripts through the script interface.

[0125] In some solutions, network-side devices can also perform update operations on the interface management module of the aforementioned service orchestration system through the OEM maintenance interface, such as updating interface call permissions and updating functional safety judgment logic. Furthermore, network-side devices can also perform operation and maintenance on the service orchestration system through the OEM maintenance interface, such as obtaining operation logs, runtime performance statistics, number of user script calls, script usage frequency, and other operation and maintenance statistics.

[0126] In one implementation, a script execution module is used to execute a first script, wherein the first script is used to implement a first service, the first service being a new service for the vehicle, and the first service depends on at least a first sub-service; an interface management module is used to determine whether the call of the first script to the first standardized interface of the first sub-service meets the functional safety conditions, and to convert the first standardized interface into a corresponding first service-oriented interface; and a service management module is used to communicate with the first sub-service based on the first service-oriented interface.

[0127] The service orchestration system shown in Figure 2 can be applied to a variety of application scenarios, such as: mobile internet (MI), industrial control, self-driving, transportation safety, internet of things (IoT), smart city, or smart home.

[0128] The service orchestration system shown in Figure 2 can be applied to various network types, such as one or more of the following: SparkLink, Long Term Evolution (LTE) networks, 5th generation mobile communication technology (5G), wireless local area networks (e.g., Wi-Fi), Bluetooth (BT), Zigbee, or vehicular short-range wireless communication networks, etc.

[0129] Figure 2 is merely an exemplary architecture diagram, and does not limit the number of network elements included in the system shown in Figure 2. Although not shown in Figure 2, Figure 2 may include other functional entities besides those shown. Furthermore, the method provided in this application embodiment can be applied to the communication system shown in Figure 2; of course, the method provided in this application embodiment can also be applied to other communication systems, and this application embodiment does not impose any limitations on this.

[0130] Referring to Figure 3, which is a flowchart of a service orchestration method provided in an embodiment of this application, this method can be applied to the service orchestration system shown in Figure 1 or the service orchestration system shown in Figure 2. The service orchestration system is deployed on a vehicle and includes the script execution module, interface management module, and service management module described above. The method shown in the embodiment of Figure 3 includes, but is not limited to, the following steps S301-S306.

[0131] S301: The script execution module obtains a first script from the network-side device or the terminal device. The first script is used to implement a first service, and the first service depends on at least a first sub-service.

[0132] Here, the first service refers to a new service for the vehicle. For example, the first service can be an atomic service or a composite service. Here, an atomic service is an indivisible basic service unit, while a composite service refers to using multiple atomic services to achieve a specific function or logic.

[0133] For example, the first sub-service can be an atomic service or a composite service.

[0134] For example, the first service generally involves enhancing the user's cabin experience, vehicle experience, driving experience, and other user-friendly aspects, but does not involve vehicle driving safety. For instance, enhancing the cabin experience could involve improving functions or services such as in-vehicle entertainment system, ambient lighting control, fragrance control, seat control, and air conditioning control, while enhancing the vehicle experience could involve enhancing remote vehicle control services such as door control, seat preheating control, valet parking, and welcome services.

[0135] In one implementation, the first service being a new service for the vehicle refers to an extension of a second service, implemented via an OTA (Over-The-Air) software package. In other words, the first service is an extension of an existing second service within the vehicle. For example, the second service might be a basic welcome service, while the first service is a premium welcome service.

[0136] In another implementation, the first service is a new service for the vehicle, meaning it's a service provided by a first component of the vehicle, which is a newly added component. This implementation can be applied to developing new hardware devices to add vehicle functionality. It's understood that for high-value components within the vehicle (such as higher-performance processor modules, more sensitive sensor modules, etc.), OEMs can provide OTA support by planning new software versions. However, for smaller components in the cabin that enhance the user's cabin experience (such as air quality sensors, aromatherapy systems, and function expansion button control panels), these components vary in form and function, iterate rapidly, and developing them using scripts, compared to OTA version development, can significantly reduce development costs and improve efficiency.

[0137] In some solutions, the aforementioned first component may also be a component that exists when the vehicle leaves the factory (such as a function expansion button control panel), but the corresponding function is not set when the component leaves the factory, and the function of the component can be customized by the vehicle user.

[0138] For example, the first script is a script file containing the execution logic of the first service. That is, the first script includes multiple script statements that implement the execution logic of the first service. Since the first service depends on at least the first sub-service, the script statements of the first script contain the standardized interface of the sub-service (i.e., the first sub-service) that the first service depends on.

[0139] In one implementation, the script execution module obtains a first script from a network-side device or a terminal device, including: the script execution module receiving a script addition event from the network-side device or the terminal device; and in response to the script addition event, the script execution module downloading and obtaining script information from the network-side device or the terminal device, the script information including the first script. In some solutions, the network-side device or the terminal device may also transmit the script information directly to the script execution module on the vehicle side.

[0140] For example, the script information also includes dependency information and configuration files for the first service. The dependency information is used to determine whether the system supports the operation of the first service, and the configuration file is used to configure the communication channels between the first service and other services. In some implementations, the script information also includes other data files and resource files used to assist in completing the first service.

[0141] As an example, the dependency information of the first service includes the computing resources (such as CPU, memory, etc.) required for the first service to run, the system information (such as operating system version information, script engine version information, SDV standardized interface version information, etc.) required for the first service to run, and the service information (such as the identifiers and version information of the sub-services that the first service depends on).

[0142] For example, the configuration file of the first service includes communication information of the sub-services that the first service depends on (e.g., at least one of the sub-service identifier, instance identifier, and sub-service communication address). This communication information is used by the service management module to establish a communication channel between the first service and the sub-services it depends on. As another example, if the first service is an extension of the second service of a vehicle, the configuration file of the first service also includes communication information of the second service (e.g., at least one of the second service identifier, instance identifier, and second service communication address). Here, the communication information of the second service is used by the service management module to switch the second service to shadow mode, meaning the first service uses the communication channel between the second service and other services to communicate with other services, and the second service can only communicate with the first service.

[0143] In some implementations, the script execution module can also obtain the script information containing the first script via a diagnostic tool. This implementation is suitable for launching new vehicle services in maintenance mode, such as writing test tasks in script form to discover potential vehicle problems.

[0144] In some possible embodiments, for the security of script information, the script information obtained by the script execution module can be digitally signed script information. In this case, after obtaining the script information, the script execution module needs to verify the signature of the script information to ensure the integrity and authenticity of the script information. Then the first script obtained from the script information is also complete, secure and tamper-free.

[0145] In this solution, after the script execution module obtains the first script, it installs and activates the first script locally using its built-in script engine. Installing the first script refers to deploying the first script and its related dependent resources (such as software libraries, modules, and tools that the first script depends on) to the system or software environment. Activating the first script puts it into a state where it can be called and run. During activation, the first script loads its related dependent resources and initializes its internal resources.

[0146] For example, installing and activating the first script includes performing the following operations: allocating corresponding resources to the first script based on the dependency information of the first service; and sending a first notification message to the service management module based on the configuration file of the first service, wherein the first notification message is used to instruct the service management module to update the service information based on the configuration file of the first service.

[0147] As an example, if the configuration file of the first service includes communication information of the sub-services that the first service depends on and the communication information of the second service, the service management module updates the service information based on the configuration file of the first service, including performing the following steps 1-3.

[0148] Step 1: Obtain the communication address of the second service based on the communication information of the second service, and bind the first service to the communication address of the second service. Thus, the communication address of the first service becomes the communication address of the second service, and the first service can use the communication channel between the second service and other services to communicate with other services.

[0149] Step 2: Based on the communication information of the sub-services that the first service depends on, open a communication channel between the first service and the sub-services that it depends on.

[0150] Step 3: Assign an internal communication address to the second service, which is only visible to the first service. In this way, the first service can communicate with the second service through this internal communication address, thus opening an internal communication channel between the two services and reclaiming the second service's ability to communicate with services other than the first service.

[0151] It is understandable that, when the configuration file of the first service only includes the communication information of the sub-services that the first service depends on, the service management module updates the service information based on the configuration file of the first service by executing the above step 2 and broadcasting the communication address of the first service to the system, thus realizing the publication of the first service.

[0152] S302: The script execution module responds to the service request and executes the first script.

[0153] The service request includes the identifier of the first service, and the first script is used to implement the first service.

[0154] In some schemes, the service request also includes the identifier of the first user, who is associated with the first service. The first user refers to the one that triggered the first script execution interface call.

[0155] For example, the triggerers can be categorized as local login users, remote login users, and system users.

[0156] In this context, "near-end login user" refers to the user currently logged into the vehicle. Near-end login is typically triggered via physical buttons, in-vehicle screen buttons, Bluetooth keys, or Bluetooth / NFC commands from a mobile phone. For example, the screen may include one or more of the following: a physical screen (such as a central control screen), a projection system, a smart entity, or a button panel. Projection systems may include light field screens, head-up displays (HUDs), or other projection systems.

[0157] Remote login users refer to users who log in to the vehicle cloud via a webpage or terminal application to assist vehicle occupants in using the vehicle. For example, a remote login user generates a service request by clicking the corresponding control button on the vehicle cloud interface. The service request is forwarded by the vehicle cloud to the vehicle to trigger the execution of the first script. Applicable scenarios include vehicle owners assisting vehicle occupants and remote vehicle control when no one is in the vehicle.

[0158] A system user refers to a system event that triggers the execution of a script statement during script execution. For example, the function of script 1 is to automatically cool an outdoor parking lot. One script statement in script 1 executes the logic of closing the sunroof and windows that were opened for cooling when sensor 1 detects rain, to prevent rainwater from wetting the interior. In this case, "sensor 1 detects rain" is a system event, and this system event originates from sensor 1.

[0159] It can be understood that the process of executing the first script refers to parsing the script statements in the first script one by one to determine whether to execute the execution logic represented by the script statements.

[0160] In one implementation, the script execution module receives service requests from the service management module. For example, in a welcoming scenario, when an atomic service detects a key approaching a vehicle, it generates a service request and sends it to the service management module, which then forwards the request to the script execution module.

[0161] S303: During the execution of the first script, the interface management module determines that the call of the first script to the first standardized interface of the first sub-service satisfies the functional safety conditions corresponding to the first standardized interface.

[0162] In one implementation, when the script execution module executes the first script, it notifies the interface management module that the first script calls the first standardized interface of the first sub-service. The interface management module determines that the call of the first script to the first standardized interface of the first sub-service satisfies the functional safety conditions corresponding to the first standardized interface. This includes: the interface management module searching the inspection database for the target inspection script corresponding to the identifier of the first sub-service and the identifier of the first standardized interface, wherein the target inspection script includes the judgment logic for the functional safety conditions corresponding to the first standardized interface; the interface management module executes the target inspection script and determines, based on the execution result of the target inspection script, that the call of the first script to the first standardized interface of the first sub-service satisfies the functional safety conditions corresponding to the first standardized interface. The execution result of the target inspection script is used to indicate that the functional safety check has passed. Here, please refer to the description of the corresponding content above; it will not be repeated here.

[0163] The database includes the correspondence between the identifiers of the first sub-service, the identifiers of the first standardized interface, and the target inspection script. For example, the database is stored in the form of a table or graph.

[0164] Refer to Table 1, which provides an example of how the database is stored in tabular form. Table 1 shows the correspondence between service identifiers, interface identifiers, and inspection scripts. As shown in Table 1, the services listed include "BCM_Door" and "TMS_AC," where "BCM_Door" represents the door service and "TMS_AC" represents the cabin temperature control service. The standardized interface "Open" for the service "BCM_Door" corresponds to two inspection scripts: "Parking Inspection.script" and "Occupant Inspection.script"; similarly, the standardized interface "setTargetTemp" for the service "TMS_AC" corresponds to two inspection scripts: "Parking Inspection.script" and "Occupant Inspection.script."

[0165] Referring to Table 1, taking the service "BCM_Door" as an example, when a script calls the standardized interface "Open" of the service "BCM_Door", it needs to sequentially perform functional safety checks on the call to the standardized interface "Open" of the service "BCM_Door" through the check scripts "Parking Check.script" and "Occupant Check.script". When the execution results of both check scripts "Parking Check.script" and "Occupant Check.script" indicate that the functional safety check has passed, it is determined that the call to the standardized interface "Open" of the service "BCM_Door" meets the functional safety conditions corresponding to the standardized interface "Open". When the execution result of either check script "Parking Check.script" or "Occupant Check.script" indicates that the functional safety check has failed, it is determined that the call to the standardized interface "Open" of the service "BCM_Door" does not meet the functional safety conditions corresponding to the standardized interface "Open".

[0166] Table 1 Database Check

[0167] It is understood that Table 1 is merely an example of how the database stores data in tabular form, and does not limit the number of correspondences stored in the database. In the inspection data, the number of inspection scripts corresponding to standardized interfaces can be multiple or one. Inspection scripts corresponding to different standardized interfaces can be completely identical, completely different, or partially identical. In practical applications, the text content and storage method of the correspondences recorded in the database can also be other forms. In some solutions, the inspection database can also store information about the script provider (as shown in Table 1), thus identifying the provider of each inspection script. Additionally, the inspection database can also store information such as the name of the inspection script, the storage path of the inspection script, and the identifier of the service instance.

[0168] It is understandable that when the first service depends on multiple sub-services, the script statements of the first script include the interfaces of these multiple sub-services (in most cases, they are standardized interfaces). When the first script calls the standardized interface of each sub-service in its own script statements, the interface management module will determine whether the call to the standardized interface meets the functional safety conditions corresponding to the standardized interface in the above manner.

[0169] In some possible embodiments, when the interface management module determines that the first script's call to the first standardized interface of the first sub-service does not meet the functional safety conditions corresponding to the first standardized interface, the interface management module sends the functional safety check result of the first standardized interface to the script execution module, wherein the functional safety check result of the first standardized interface indicates that the first script's call to the first standardized interface does not meet the functional safety conditions corresponding to the first standardized interface.

[0170] Optionally, in some possible embodiments, S304 may also be executed. Here, the execution order of S303 and S304 is not limited; for example, S304 may be executed before S303, after S303, or both may be executed simultaneously. As an example, the interface call permission determination precedes the interface functional security check. That is, the interface management module only performs the functional security check shown in S303 on the first standardized interface after determining that the first user has permission to call the first standardized interface.

[0171] S304: During the execution of the first script, the interface management module determines that the first user who triggered the execution of the first script has the authority to call the first standardized interface.

[0172] In one implementation, when the script execution module executes the first script, it notifies the interface management module that the first script calls the first standardized interface of the first sub-service. The interface management module determines that the first user who triggered the execution of the first script has permission to call the first standardized interface. This includes: the interface management module searching the permission database for a whitelist of target users corresponding to the identifier of the first sub-service, the identifier of the first standardized interface, and the provider of the first script. If the target user whitelist includes the first user, the interface management module determines that the first user has permission to call the first standardized interface of the first sub-service.

[0173] The permission database includes the correspondence between the provider of the first script, the identifier of the first sub-service, the identifier of the first standardized interface, and the target user whitelist. The target user whitelist stores users who are authorized to call the first standardized interface of the first sub-service. For example, the permission database is stored in the form of a table or a graph.

[0174] Refer to Table 2, which is an example of how the permissions database is stored in tabular form. Table 2 shows the correspondence between script providers, service identifiers, interface identifiers, and user whitelists. As can be seen from Table 2, for scripts provided by the OEM, all types of users (including local login users, remote login users, and system users) are supported to call the standardized interface "Lock" of the service "BCM_Door"; for scripts provided by third-party developers, only remote login users are supported to call the standardized interface "setTargetTemp" of the service "TMS_AC"; for scripts provided by end users, only remote login users are supported to call the standardized interface "Lock" of the service "EMS_ChargePort". Here, please refer to the descriptions of the corresponding content in S302 above for local login users, remote login users, and system users, which will not be repeated here. For example, the third-party developer is certified by the OEM, and the end user generates the script using the online editing tool provided by the OEM.

[0175] Table 2 Permission Database

[0176] It is understood that Table 2 is merely an example of how the permission database is stored in tabular form, and the number of correspondences stored in the permission database is not limited. The correspondences shown in Table 2 are only an example. In practical applications, the textual content and storage method of the correspondences recorded in the permission database can also be in other forms.

[0177] In some solutions, the permission database can also store supplementary information (as shown in Table 2). For example, the "Supplementary Information" column in Table 2 shows that "remote login users" need authorization to call the standardized interface "setTargetTemp" of the service "TMS_AC" in the script provided by the third-party developer. The corresponding implementation scenario could be: when a user installs the script on the vehicle, a prompt appears asking for authorization if the script will call the standardized interface "setTargetTemp" of the service "TMS_AC". After receiving confirmation from the user, the "remote login user" has permission to call the standardized interface "setTargetTemp" of the service "TMS_AC" during subsequent script execution. Alternatively, during script execution, when the standardized interface "setTargetTemp" is called, a corresponding authorization request is displayed. With user authorization, the "remote login user" has permission to call the standardized interface "setTargetTemp" of the service "TMS_AC". In some solutions, if a call to a standardized interface involves user privacy data, a privacy reminder and authorization request will be displayed, allowing the user to call the standardized interface only after authorization. In addition, the permissions database can also store information such as the identifier and priority of storage instances.

[0178] In some possible embodiments, if the target user whitelist does not include the first user, the interface management module determines that the first user does not have permission to call the first standardized interface. The interface management module sends the permission check result to the script execution module, wherein the permission check result indicates that the first user does not have permission to call the first standardized interface.

[0179] S305: The interface management module converts the first standardized interface into the corresponding first service interface.

[0180] In one implementation, if the interface management module determines that the call of the first script to the first standardized interface of the first sub-service satisfies the functional safety conditions corresponding to the first standardized interface, the interface management module will convert the first standardized interface into the corresponding first service-oriented interface.

[0181] In another implementation, when executing S304 above, if the interface management module determines that the call of the first script to the first standardized interface of the first sub-service meets the functional safety conditions corresponding to the first standardized interface and the first user has the right to call the first standardized interface, the interface management module will replace the first standardized interface with the corresponding first service interface.

[0182] For example, the interface management module converts the first standardized interface into a corresponding first service-oriented interface, including: the interface management module converts the first standardized interface into a corresponding first service-oriented interface based on interface mapping information, wherein the interface mapping information includes the correspondence between the first standardized interface and the first service-oriented interface. For explanations of standardized interfaces and service-oriented interfaces, please refer to the preceding descriptions; they will not be repeated here.

[0183] As described above, standardized interfaces are industry-wide abstract specifications designed to solve compatibility issues across different automakers and hardware. However, the definitions of standardized interfaces are quite general and not optimized for specific vehicle models or SOA architectures. Different automakers may have different service-oriented interfaces for the same standardized interface definition based on their own needs. Therefore, converting the first standardized interface into its corresponding first service-oriented interface within the vehicle enables adaptation between industry standards and automakers' proprietary architectures, and also supports automakers in implementing more intelligent and adaptive functions.

[0184] S306: The service management module communicates with the first sub-service based on the first service interface.

[0185] In one implementation, the service management module communicates with a first sub-service based on a first service-oriented interface, including: the service management module calling the first sub-service through the first service-oriented interface to implement corresponding vehicle control. For example, the first sub-service is used to implement air conditioning temperature control; the service management module calls the first sub-service through the first service-oriented interface, causing the first sub-service to set the air conditioning temperature to the target temperature set in a first script.

[0186] In one possible implementation, when the first service is an extension of the second service for the vehicle, during the execution of the first script, the first script is further used to determine whether to enable at least one of the first and second services based on the acquired business scenario information. That is, the execution logic for determining whether to enable the first and / or second service is pre-set in the first script; this execution logic is carried in the script code of the first script, and the script engine in the script execution module does not participate. This implementation can be referred to in the description of the embodiment in Figure 5 below.

[0187] For example, for scripts related to security functions, the business scenario information can be lighting information, which is used to distinguish whether it is daytime or nighttime. In daytime scenarios, the sensors on the vehicle monitor the surrounding environment more frequently than in nighttime scenarios.

[0188] For example, in a welcoming scenario, different users may have different welcoming modes or different users may have set different welcoming modes. In this case, the business scenario information can be the user's characteristic information, which may include one or more of the user's gender, height, welcoming configuration information, etc.

[0189] In one implementation, the business scenario information can be obtained by the first script through calling at least one standardized interface, with each standardized interface corresponding to a sub-service that the first service depends on. For example, in a welcoming scenario, these at least one standardized interface include standardized interface 1 and standardized interface 2. Standardized interface 1 obtains the target recognition results of the image of the user captured by the camera, and standardized interface 2 obtains the user's height information from the LiDAR. In some solutions, the first script can also obtain the user's feature information through other standardized interfaces.

[0190] Taking a welcoming scenario as an example, different users have different welcoming configuration information when using the welcoming service. For example, user 1 sets the car lights to flash automatically in welcoming mode, user 2 sets the car doors to open automatically and the suspension height to drop in welcoming mode, and user 3 sets the car lights to flash automatically, the car doors to open automatically, and the suspension height to drop in welcoming mode. Here, it is assumed that the automatic flashing of the car lights is implemented through the aforementioned second service, and the automatic opening of the car doors and the drop in suspension height are implemented through the aforementioned first service. For example, in the welcoming scenario, when a user is detected approaching the vehicle, the execution of the first script is triggered. The execution logic of the first script can be as follows: during the execution of the first script, if the first script determines that the user is user 1 by obtaining the user's characteristic information, then the second service is activated; if the first script determines that the user is user 2 by obtaining the user's characteristic information, then the first service is activated; if the first script determines that the user is user 3 by obtaining the user's characteristic information, then both the first and second services are activated.

[0191] In some possible embodiments, when developing the first service for the first component, before obtaining the first script, the script execution module also obtains a second script from the network-side device and installs and activates the second script locally through the script engine. The second script is used to convert user operations on the first component into service requests. Here, the user is the person enjoying the first service. Please refer to the description of the embodiment in Figure 6 below for this implementation.

[0192] Implementing the example shown in Figure 3, new vehicle services are developed using scripts. From a development perspective, scripting languages ​​typically have concise and flexible syntax, significantly shortening the development cycle. Developers can quickly orchestrate services, reducing development costs. Their code is highly readable and maintainable, facilitating subsequent service expansion and bug fixing. In terms of deployment, scripts are easily integrated into existing vehicle systems without requiring large-scale system modifications, enabling rapid deployment of new services. From a functional implementation perspective, scripts allow for flexible customization of service content based on different vehicle characteristics and user needs, achieving personalized services. Furthermore, during script execution, functional safety checks are performed on interface calls, preventing improper interface calls from causing vehicle function anomalies or malfunctions. This ensures the vehicle operates safely and reliably under various conditions, providing safety guarantees for drivers and passengers, and helps comply with the stringent functional safety standards and regulations of the automotive industry, improving the overall safety and reliability of the vehicle service system. During script execution, permission checks are performed on interface calls to strictly control the legality of interface access. Only entities with the corresponding permissions can call specific interfaces, thereby effectively preventing unauthorized access and data leakage, protecting information security within the vehicle system, and ensuring stable system operation.

[0193] The judgment process of S303 and S304 described above is illustrated below with a specific example using Figure 4. Figure 4 is an example diagram of permission judgment and functional safety check for executing interface calls provided by an embodiment of this application. In Figure 4, the content of the first script is simply shown as an example. The first script is used to set the air conditioner temperature to 22 degrees. Here, the content of the first script is not limited to what is shown in Figure 4. The execution logic shown in Figure 4 can be referred to in steps S10-S17 below.

[0194] S10: During the execution of the first script, the script execution module notifies the interface management module to "call TMS_AC.setTargetTemp", where "TMS_AC" represents a dependent first sub-service, and "setTargetTemp" is the first standardized interface of the first sub-service "TMS_AC".

[0195] S11: The interface management module determines whether it has permission to call the first standardized interface "setTargetTemp" by querying the permission database.

[0196] For example, assuming the permission database is represented as shown in Table 2 above, and assuming the provider of the first script is a third-party developer, the interface management module queries the permission database to obtain the target user whitelist corresponding to the first sub-service "TMS_AC" and the first standardized interface "setTargetTemp". This whitelist includes remote login users. If the first user who triggers the execution of the first script belongs to the target whitelist (i.e., the first user is a remote login user), the interface management module determines that the first user has permission to call the first standardized interface "setTargetTemp", and then executes step S12; if the first user who triggers the execution of the first script does not belong to the target whitelist (i.e., the first user is not a remote login user), the interface management module determines that the first user does not have permission to call the first standardized interface "setTargetTemp", and then executes the following step S15.

[0197] S12: The interface management module queries and checks the database to determine whether the first standardized interface "setTargetTemp" is configured with a check script.

[0198] For example, assuming the inspection database can be represented as shown in Table 1 above, the interface management module queries the inspection database based on the identifier of the first sub-service "TMS_AC" and the identifier of the first standardized interface "setTargetTemp". If the inspection database contains inspection scripts corresponding to both the identifier of the first sub-service "TMS_AC" and the identifier of the first standardized interface "setTargetTemp", the interface management module determines that the first standardized interface "setTargetTemp" is configured with an inspection script, and then executes step S13; if the inspection database does not contain inspection scripts corresponding to both the identifier of the first sub-service "TMS_AC" and the identifier of the first standardized interface "setTargetTemp", the interface management module determines that the first standardized interface "setTargetTemp" is not configured with an inspection script, and then executes step S16.

[0199] S13: If a check script is configured in the first standardized interface "setTargetTemp", the interface management module executes the corresponding check script.

[0200] For example, when the database is represented as Table 1 above, the inspection scripts corresponding to the first standardized interface "setTargetTemp" include "Parking Inspection.script" and "Occupant Inspection.script". The inspection script "Parking Inspection.script" is used to determine whether the vehicle is currently parked, and the inspection script "Occupant Inspection.script" is used to determine whether there are passengers in the vehicle. The interface management module executes "Parking Inspection.script" and "Occupant Inspection.script" to obtain the execution result of each inspection script. These two inspection scripts can be executed simultaneously or one after the other.

[0201] S14: The interface management module determines whether the functional safety check has passed based on the execution result of the inspection script.

[0202] Taking the check script "Parking Check.script" as an example, if the vehicle is currently in a parked state, the execution result of "Parking Check.script" is "TRUE"; if the vehicle is not currently in a parked state, the execution result of "Parking Check.script" is "False". Here, the execution result of "Parking Check.script" being "TRUE" means that the interface "setTargetTemp" has passed the functional safety check of "Parking Check.script", that is, the call to the interface "setTargetTemp" satisfies the functional safety conditions represented by "Parking Check.script".

[0203] Furthermore, when there are multiple check scripts corresponding to the first standardized interface "setTargetTemp", if the execution result of each check is "TRUE", the interface management module determines that the first standardized interface "setTargetTemp" has passed the functional safety check and executes S16; if one of the multiple check scripts corresponding to the first standardized interface "setTargetTemp" has an execution result of "False", the interface management module determines that the first standardized interface "setTargetTemp" has failed the functional safety check and executes S15.

[0204] S15: The interface management module returns an interface call failure to the script execution module.

[0205] For example, if the interface management module determines that there is no permission to call the first standardized interface "setTargetTemp" or that the call to the first standardized interface "setTargetTemp" fails the functional safety check, the interface management module returns an interface call failure message to the script execution module. It can be understood that returning this interface call failure information to the script execution module allows the first script to quickly locate the problematic interface and take appropriate action. If the first script does not take any action, the script execution module can terminate the execution of the first script and record relevant logs for backend maintenance and optimization.

[0206] S16: The interface management module converts standardized interfaces into corresponding service interfaces.

[0207] For example, the interface management module converts the first standardized interface "setTargetTemp" into the corresponding first service interface inside the vehicle.

[0208] S17: The service management module obtains service interface messages based on the service interface. The service interface messages are used to instruct the first sub-service "TMS_AC" to set the execution temperature to 22 degrees.

[0209] Here, Figure 4 is only an example of performing permission checks and functional safety checks on interface calls during script execution. In some solutions, step S11 may be skipped after S10, and step S12 may be executed directly.

[0210] The embodiment shown in Figure 4 implements new vehicle services through scripts. During script execution, permission checks and functional safety checks are performed on interface calls. This not only ensures the legality of interface calls and protects the information security of the vehicle system, but also effectively prevents interface calls from causing abnormalities or malfunctions in vehicle functions. This ensures the vehicle operates safely and reliably under various conditions, providing safety guarantees for drivers and passengers. Furthermore, it helps to comply with the stringent functional safety standards and regulations of the automotive industry, improving the safety and reliability of the entire vehicle service system.

[0211] Referring to Figure 5, which is a flowchart of a service orchestration method provided in an embodiment of this application, the method shown in Figure 5 is applicable to scenarios where the first service is an extension service of a second service within the vehicle, wherein the second service is implemented through an OTA software package. The method shown in Figure 5 can be executed by the aforementioned service orchestration system. The method shown in the embodiment of Figure 5 includes, but is not limited to, the following steps S501-S505.

[0212] S501: The script engine obtains the first script from the OEM network-side device or terminal device.

[0213] S502: Install and activate the first script for the script engine.

[0214] S503: When the first script is activated, the service management module publishes the first service and converts the communication of the second service into internal communication.

[0215] The first service is for adding new services for vehicles.

[0216] For example, publishing the first service includes several of the following: the system broadcasts the communication address of the first service (represented as the communication address of the second service), declares the interfaces and functions provided by the first service, the version number of the first service, and the dependencies between the first service and other services.

[0217] It's understandable that representing the communication address of the first service as the communication address of the second service allows external systems or clients that depend on the second service to avoid large-scale configuration changes during service additions or upgrades, reducing the management cost and complexity of communication addresses within the system. External systems can continue to use their original communication addresses to interact with the system, enabling the first service to also communicate with external systems, ensuring compatibility with these systems, avoiding errors and failures caused by address changes, and guaranteeing the stable operation of the entire business ecosystem. Furthermore, converting the communication of the second service into internal communication visible only to the first service not only allows communication between the two services but also effectively restricts direct external access to the second service, reducing the risk of malicious attacks. Internal communication typically has lower latency and higher bandwidth, enabling faster data transmission and request response between the first and second services, improving overall system performance and response speed, and providing a better user experience.

[0218] S504: The script engine executes the first script.

[0219] In Figure 5, the script engine executes the first script to launch the first script instance. Here, the first script instance refers to an independent runtime environment and context created during the execution of the first script.

[0220] The first script instance only begins executing its logic upon receiving a service request. This approach allows the system to pre-allocate necessary basic resources, such as memory and file handles, to the first script instance when it is launched. When the first script instance receives a service request, because some resources are already prepared, it can quickly respond to the request and execute its logic, reducing resource allocation overhead for each request. Furthermore, when there are no service requests, the first script instance remains in a standby state, not consuming excessive additional resources, thus achieving efficient resource utilization.

[0221] In some possible embodiments, the execution of the first script can also be as follows: the script engine receives a service request from an atomic service or device abstraction, the service request carrying the identifier of the first service; in response to the service request, the script engine executes the first script, and in this case, the first script instance launched directly executes the execution logic in the first script. This approach executes the first script only when a service request is received, meaning the system only allocates resources to run the first script when there is an actual demand. For services with low usage frequency, this approach avoids long-term occupation of system resources, reduces resource idleness and waste, and is suitable for resource-constrained environments. Furthermore, if the external resources that the first script depends on (such as database connection parameters, configuration files, etc.) change, the first script will automatically use the latest information on the next request, improving the system's flexibility and maintainability.

[0222] S505: During the execution of the first script, the interface management module performs permission checks and functional security checks on the interface calls in the first script. For the permission checks of the interface calls, please refer to the description in the corresponding content of embodiment S304 in Figure 3 above; for the functional security checks of the interface calls, please refer to the description in the corresponding content of embodiment S303 in Figure 3 above. These details will not be repeated here.

[0223] As shown in Figure 5, once the first script instance receives a service request from an atomic service or device abstraction, it begins to execute the execution logic of the first script. For example, the execution logic in the first script includes the following:

[0224] 1) In the scenario where the first service is enabled, trigger the execution of other sub-services that the first service depends on.

[0225] 2) When it is determined that the second service is enabled, the second service instance is invoked via an internal message. That is, when the first script instance determines that the second service is enabled, the first script instance notifies the second service instance to execute through the internal communication channel between the first and second services.

[0226] 3) In scenarios where the first and second services are determined to be enabled, trigger the operation of other sub-services that the first service depends on, and call the second service instance through internal messages.

[0227] Implementing the example shown in Figure 5, when extending existing vehicle services, developing new services in the form of scripts not only significantly shortens the development cycle and reduces development costs, but also allows for easy integration into existing vehicle systems without requiring large-scale modifications to the entire system. This enables rapid deployment of new services and enhancements to existing ones. Furthermore, the high readability and maintainability of the code allow developers to flexibly customize service content according to vehicle characteristics and user needs, better achieving personalized services. During script execution, permission checks and functional security checks are performed on interface calls. This not only ensures the legality of interface calls and protects the information security of the vehicle system, but also effectively prevents interface calls from causing abnormalities or malfunctions in vehicle functions, ensuring the vehicle operates safely and reliably under various conditions.

[0228] Referring to Figure 6, which is a flowchart of another service orchestration method provided in an embodiment of this application, the method shown in Figure 6 is applicable to a scenario where the first service is a service developed for a first component of a vehicle, wherein the first component is a newly added component of the vehicle. For example, the first component may be an in-vehicle component that can enhance the user's cabin experience, driving experience, etc., such as a physical button / button, an air quality sensor, or an aromatherapy device.

[0229] The method shown in Figure 6 can be executed by the service orchestration system described above. The method shown in the embodiment of Figure 6 includes, but is not limited to, the following steps S601-S611. Among them, S601-S605 correspond to the driving stage of the first component, and S606-S611 correspond to the application stage of the first component.

[0230] First, describe the driving phase of the first component.

[0231] S601: The script engine obtains a second script from the OEM network-side device or terminal device.

[0232] S602: Install and activate the second script using the script engine.

[0233] S603: When the second script is activated, the service management module publishes the first service.

[0234] S604: The script engine executes the second script.

[0235] For example, the script engine executes a second script to launch a second script instance.

[0236] The second script is used to convert user actions on the first component into service requests.

[0237] For example, the second script instance can configure signal forwarding rules for atomic service A. These rules include guidelines for processing and forwarding signals received from a specific address to convert them into corresponding events. For instance, the signal forwarding rules include address matching rules and forwarding rules, which guide the method of converting signals into corresponding events. The address matching rules include matching the source address and specifying the destination address. The source address can be the communication address of the signal source, which can be an IP address, MAC address, or an identifier of the signal source. The destination address refers to the address where the event is received after the signal is converted, such as the address of a service or the address of a specific processing module.

[0238] Here, atomic service A converts the received first signal into a first event based on the signal conversion rules. The first signal is generated when the user performs an operation on the first component, and the first event is used to indicate that the first signal has been received from the communication address of the first component.

[0239] For example, the first signal may be bitstream information generated when the user operates the first component, or it may be an electrical signal generated when the user operates the first component.

[0240] For example, a user's operation on the first component can be pressing (e.g., single click, double click, etc.), long press, tapping (if the first component has touch sensing functionality), swiping, etc. In some solutions, where the first component has multiple buttons, a user's operation on the first component refers to the user's operation on a specific button on the first component.

[0241] Figure 6 provides a functional example of the second script. Please refer to steps 01-03 below for the execution logic in the second script.

[0242] Step 01: In response to the user's operation on the first component, the first component generates a first signal and sends the first signal to atomic service A.

[0243] Here, the first signal is used to characterize user operation information, which includes the operation performed by the user on the first component. In some embodiments, where the first component has multiple buttons, the operation information also includes the identifier of the button on the first component operated by the user.

[0244] Step 02: Atomic service A converts the first signal into a first event based on the configured signal forwarding rules and sends the first event to the second script instance. The first event indicates that the first signal has been received from the communication address of the first component.

[0245] Step 03: The second script instance decodes the first signal in the first event to obtain the user's operation information, generates a service request, and sends the service request to the service management module.

[0246] The service request includes the user's operation information and instructs the user to perform an operation on the first component.

[0247] Here, steps 01-03 above are merely examples of some functions of the second script.

[0248] S605: During the execution of the second script, the interface management module performs permission checks and functional security checks on the interface calls in the second script. For the permission checks of the interface calls, please refer to the description in the corresponding content of embodiment S304 in Figure 3 above; for the functional security checks of the interface calls, please refer to the description in the corresponding content of embodiment S303 in Figure 3 above. These details will not be repeated here.

[0249] The application phase of the first component is described below.

[0250] S606: The script engine obtains the first script from the OEM network-side device or terminal device.

[0251] S607: Install and activate the first script for the script engine.

[0252] S608: When the first script is activated, the service management module searches for the first service.

[0253] S609: The script engine receives service requests from the service management module.

[0254] For example, the service request is associated with the user's operation on the first component. The process of the service request originating from steps 01-03 above is explained as follows: In response to the user's operation on the first component, the first component generates a first signal and sends the first signal to atomic service A; atomic service A converts the first signal into a first event based on the configured signal forwarding rules and sends the first event to the second script instance; the second script instance performs signal decoding of the first event to generate a service request and transmits the service request to the service management module, which then forwards the service request to the script engine, thereby allowing the script engine to receive the service request from the service management module.

[0255] S610: In response to a service request, the script engine executes the first script.

[0256] For example, the script engine executes a first script to launch a first script instance, which then runs the execution logic in the first script, such as calling other sub-services that the first service depends on.

[0257] S611: During the execution of the first script, the interface management module performs permission checks and functional security checks on the interface calls in the first script. For the permission checks of the interface calls, please refer to the description of the corresponding content in embodiment S304 of Figure 3 above; for the functional security checks of the interface calls, please refer to the description of the corresponding content in embodiment S303 of Figure 3 above. These details will not be repeated here.

[0258] The implementation of the first service is illustrated below using a physical button as an example of the first component. Here, a first script and a second script are provided. The second script drives the first component, converting user actions on the first component into service requests that trigger the first service. The first script includes the execution logic of the first service to implement its application. For example, the second script originates from the OEM's network-side device; the first script can originate from either the OEM's network-side device or the user's terminal device. If the first script originates from the user's terminal device, it indicates that the user has customized the newly added first service for the vehicle.

[0259] Assume a physical button has two states: function on and function off. For example, when a user performs a first operation on the first component, the physical button is in the on state; when the user performs a second operation on the first component, the physical button is in the off state. Assume a first script originates from the user's terminal device, and the user defines in the first script that "when the physical button is in the on state, automatically raise the air conditioner temperature by 1 degree." For example, when the user performs the first operation on the first component, in response to the first operation, the first component generates a first signal and transmits the first signal to atomic service A (e.g., a 2.4G device). Atomic service A converts the first signal into a first event according to the signal forwarding rules pre-configured in the second script. The first event indicates that the first signal has been received from the communication address of the first component. Subsequently, atomic service A transmits the first event to the second script instance launched when the second script is executed. The second script instance decodes the first signal in the first event to obtain that the user performed the first operation on the first component and the physical button is in the on state. Therefore, it generates a service request and transmits the service request to the service management module. The service request is used to instruct the user to perform the first operation on the first component, causing the physical button to be in the on state. The service management module forwards the service request to the script engine. In response to the service request, the script engine executes the first script, which in turn calls other sub-services that the first service depends on, thereby raising the air conditioner temperature by 1 degree.

[0260] In some possible embodiments, the first script is also used to provide control parameters for the first component. In this case, the second script is also used to control the first component based on the acquired control parameters. That is, the first component supports bidirectional communication. Taking a physical button as an example, the physical button can also receive feedback on the button status to guide the on / off display of the button indicator light, or receive control parameters of the physical button to guide the display of the control parameters, etc.

[0261] Taking the first component as a physical button as an example, after the script engine executes the first script to raise the air conditioner temperature by 1 degree, the first script instance can also send feedback information about the air conditioner temperature (i.e., the control parameters of the first component) to the second script instance. For example, the feedback information about the air conditioner temperature indicates that the current air conditioner temperature is "25℃". The second script instance performs signal encoding processing on the feedback information about the air conditioner temperature to obtain a second event, and transmits the second event to atomic service A. Atomic service A converts the second event into a second signal and transmits the second signal to the first component. The first component parses the second signal to determine that the current air conditioner temperature is "25℃". Furthermore, the first component displays "The current air conditioner temperature is 25℃" on its own display device based on the second signal. In this way, reverse control of the first component is realized.

[0262] The embodiment shown in Figure 6 develops new services for newly added vehicle components using scripts. One script implements the hardware driver for the new component, translating user actions on the component into service requests that trigger the new service. The other script includes the execution logic for the new service, enabling its application. This significantly shortens the development cycle and reduces costs. Furthermore, the scripts are easily integrated into existing vehicle systems without requiring large-scale system modifications, allowing for rapid service deployment. During script execution, permission checks and functional safety checks are performed on interface calls. This ensures the legitimacy of interface calls, protects the vehicle system's information security, and effectively prevents interface calls from causing abnormalities or malfunctions in vehicle functions, ensuring safe and reliable vehicle operation under various conditions.

[0263] In some possible embodiments, this solution can also provide post-operation and maintenance functions. That is, during the execution of each script, the script execution module can also obtain operation and maintenance observation information and feed it back to the OEM vehicle manufacturer. The OEM vehicle manufacturer can then perform user interest point analysis, operation and maintenance optimization, etc., based on the operation and maintenance observation information to improve the efficiency of the service orchestration system.

[0264] Referring to Figure 7, which is a flowchart of an operation and maintenance method provided in an embodiment of this application, the method shown in Figure 7 is applied between a service orchestration system and an OEM network-side device. The service orchestration system includes a script execution module, an interface management module, and a service management module. For a description of the service orchestration system, please refer to the description of the embodiment in Figure 2 above, which will not be repeated here.

[0265] The method shown in the embodiment of Figure 7 includes, but is not limited to, the following steps S701-S703.

[0266] S701: The script execution module obtains operation and maintenance observation information.

[0267] The operation and maintenance observation information includes at least one of the following:

[0268] Execution information for each script;

[0269] Resource consumption for each script;

[0270] The invocation of standardized interfaces during script execution; and,

[0271] Statistical information on communication between various services during script execution.

[0272] For example, the script execution information includes the script execution time, the script execution status, and error information.

[0273] For example, a script's execution time includes at least one of the following: the script's start time (representing the starting point of script execution), the end time (e.g., the moment the script finishes running normally or the moment it is interrupted due to an error), and the execution duration. The execution duration can be obtained by subtracting the start time from the end time. The script's runtime reflects its speed and can be used to evaluate its performance and efficiency, and determine whether it meets business requirements.

[0274] For example, the execution status of a script can include at least one piece of information, such as the script's execution result (e.g., recording whether the execution result of each script statement is successful or failed) and execution progress (i.e., indicating what percentage of the entire script task has been completed). Providing the script's execution result makes it easy to quickly locate the problem based on the error message in the event of execution failure. The script's execution progress allows users to understand the real-time status of the script's operation.

[0275] For example, error messages include at least one of the following: error code, error description, and error stack trace. The error code can be a system-defined error code or a code defined by the script itself; each code corresponds to a specific type of error, allowing developers to quickly pinpoint the problem type. The error description is a textual description of the cause of the error, typically containing key information such as the function or module where the error occurred, and the operations that might have caused the error. The error stack traces the function call path from the start of script execution to the point where the error occurred, helping developers track the specific location and execution flow of the error.

[0276] For example, the resource consumption of a script includes the usage of at least one system resource such as CPU, memory, disk I / O, and network I / O during script runtime.

[0277] For example, CPU usage includes CPU utilization rate and CPU core usage. CPU utilization rate indicates the proportion of CPU time occupied by the script during its operation, reflecting the script's demand for CPU resources. Excessive CPU utilization rate may cause system lag. CPU core usage rate can indicate whether the script uses multiple CPU cores evenly or is mainly concentrated on a few cores, which can be used to determine whether the script can effectively utilize the performance of multi-core processors.

[0278] Memory usage includes at least one piece of information such as memory usage (i.e., the amount of memory space occupied by the script during runtime) and memory leaks.

[0279] Disk I / O includes at least one piece of information such as the number of times the script performs read and write operations on the disk, and read / write traffic (representing the amount of data the script reads and writes from the disk per unit of time). Understandably, frequent disk I / O operations may affect the script's execution speed.

[0280] For example, network I / O includes at least one piece of information such as the amount of network data sent and received by the script during execution (i.e., network traffic) and the number of network connections established by the script. Network traffic can be used to assess the script's network bandwidth usage.

[0281] For example, the invocation status of standardized interfaces during script execution includes the number of times the standardized interface is invoked during script execution, the interface response time, interface call failure events (also known as functional safety violation events), interface authentication failure events, etc.

[0282] For example, API call counts include at least one piece of information such as the total number of calls to each API and the number of calls to the API within different time periods. The total number of calls to each API can measure its usage frequency in the script. By statistically analyzing the number of API calls within different time periods, the frequency distribution of API calls can be analyzed to determine if there are any abnormally high-frequency or low-frequency call patterns.

[0283] For example, API response time includes at least one of the following: maximum response time, minimum response time, and average response time. The minimum response time can serve as a benchmark for API performance, the maximum response time can be used to identify long latency issues, and the average response time can be used to evaluate API performance.

[0284] For example, the statistical information of various service communications during script execution includes at least one of the following: the number of communications between the script and each related service, the communication frequency, the communication latency, and the communication success rate. For instance, the types of service communications include vehicle control services, intelligent driving services, vehicle-cloud services, cockpit services, and script services.

[0285] Communication frequency is related to the number of communications. By monitoring the communication frequency, we can understand how often the script interacts with various services and determine the script's dependence on different services. For example, communication latency includes information such as average latency and latency distribution over different time periods. Monitoring communication latency prevents excessive latency from impacting script execution efficiency and user experience.

[0286] In one implementation, the script execution module obtains operation and maintenance observation information, including:

[0287] The monitoring and statistics in the script execution module receive execution information for each script from the script engine within the script execution module;

[0288] The monitoring and statistics in the script execution module receive the resource consumption information for each script from the resource management section of the script execution module.

[0289] The monitoring and statistics in the script execution module receive information from the interface management module regarding the invocation of standardized interfaces during script execution; and,

[0290] The monitoring and statistics module in the script execution module receives statistical information on various service communications during script execution from the service management module.

[0291] S702: The script execution module sends operation and maintenance observation information to the OEM network-side equipment.

[0292] In some possible embodiments, after the script execution module obtains the operation and maintenance observation information, before sending the operation and maintenance observation information, the monitoring statistics in the script execution module can first perform statistical processing on the operation and maintenance observation information, such as clustering, anonymization (removing user privacy data), etc., and send the statistical results and operation and maintenance observation information to the OEM network side device. The statistical results can be used as a reference by the OEM network side device.

[0293] S703: OEM network-side equipment performs information analysis on operation and maintenance observation information.

[0294] In one implementation, information analysis of operation and maintenance observation information includes: performing user interest point analysis based on the operation and maintenance observation information.

[0295] For example, performing user point of interest analysis based on operational observation information includes at least one of the following operations:

[0296] Based on the execution information of the above scripts, we can analyze the user's time period preferences for script execution;

[0297] Script-based resource consumption analysis reveals user preferences for computing task types (whether they have an interest in computationally intensive tasks), data processing scale, data storage and retrieval, and areas of interest in network interaction.

[0298] Analyze user preferences for services associated with standardized interfaces based on the invocation behavior of standardized interfaces during script execution; and,

[0299] Analyze user preferences for services related to business / functions based on statistical information from various service communications during script execution.

[0300] In some solutions, information analysis is performed on the operation and maintenance observation information, including: performance statistics of the scripts executing the operation and maintenance observation information.

[0301] For example, based on the execution time of a script, its performance and efficiency can be evaluated; the execution status and error information of a script can be statistically analyzed for success rate and error type to prioritize the resolution of the error types with the highest error frequency.

[0302] For example, regarding the resource consumption of scripts, statistics based on CPU resources can be used to assess whether the system allocates CPU resources reasonably; statistics based on memory resources can be used to assess whether there are unreasonable memory allocations and memory leaks; statistics based on disk I / O can be used to assess the script's dependence on disk and its impact on script execution speed; and statistics based on network I / O can be used to assess the script's network bandwidth usage and its impact on system network resources.

[0303] For example, regarding the invocation of standardized interfaces during script execution, statistical results based on the number of invocations can be used to assess whether there are abnormally high-frequency or low-frequency invocations; statistical results based on interface response time can be used to assess the overall response speed of standardized interfaces and standardized interfaces with excessively long response times; statistical results based on interface call failure events can be used to determine which interfaces violate or fail to meet functional safety conditions; and statistical results based on interface authentication failure events can be used to determine which standardized interfaces users do not have permission to call.

[0304] For example, based on the statistical information of various service communications during script execution, the script's dependence on services and the distribution of service communications over time can be analyzed based on the number of communications and communication frequency; the communication latency can be assessed based on the communication latency between the script and the service; and the communication success rate can be used to determine the probability of successful communication between the script and the service.

[0305] Furthermore, correlation analysis can be performed on the different statistical indicators mentioned above (such as interface response time and script execution time) to identify key factors affecting script performance. Based on these key factors, performance evaluation indicators, such as script performance scores, can be established to quantitatively evaluate the overall running performance of the script, so as to facilitate performance comparison and optimization effect evaluation between different scripts.

[0306] As illustrated in the embodiment shown in Figure 7, the service orchestration system can provide operational and maintenance observation information for network-side devices, supporting OEMs in performing operations and maintenance to obtain user interests. This allows developers to provide script services that are closer to user habits and preferences. Furthermore, it can determine the direction of system optimization, optimize script performance, and improve system efficiency.

[0307] In some possible implementations, after the script has been running for a period of time, the permissions of some interfaces may need to be narrowed to enhance security; alternatively, OEM manufacturers may want to open more interfaces to a certified third-party developer for a better user experience. In such cases, the interface permissions can be updated using the method shown in Figure 8 below.

[0308] Referring to Figure 8, which is a flowchart of a method for updating interface permissions provided in an embodiment of this application, the method shown in Figure 8 is applied to the OEM network-side device, the script execution module, and the interface management module. Here, please refer to the description of the script execution module and the interface management module in the corresponding content of Figure 1 above; they will not be repeated here.

[0309] The method shown in Figure 8 includes, but is not limited to, the following steps S801-S803.

[0310] S801: The script execution module obtains permission update information from the OEM network-side device.

[0311] In one implementation, to reduce data transmission volume, the permission update information includes at least one mapping relationship to be updated. This mapping relationship records the correspondence between the script provider, the service identifier, the interface identifier, and the user whitelist. Here, updating includes at least one of the operations of adding, modifying, and deleting.

[0312] In some schemes, when network resources are sufficient, permission update information can also include a full set of mapping relationships. One mapping relationship is used to record the mapping relationship between script provider, service identifier, interface identifier, and user whitelist.

[0313] In some possible embodiments, where the permission update information is signed, the script execution module, after obtaining the permission update information, first verifies the signature of the permission update information to ensure the authenticity and integrity of the data.

[0314] S802: The script execution module sends permission update information to the interface management module.

[0315] Correspondingly, the interface management module receives permission update information from the script execution module.

[0316] In some possible embodiments, the script execution module may also send the corresponding relationships in the permission update information to the interface management module one by one.

[0317] S803: The interface management module updates the permission database based on permission update information.

[0318] In one implementation, when the permission update information includes at least one correspondence to be updated, the interface management module updates the permission database according to the permission update information, including: the interface management module updates each correspondence in the permission update information to the permission database.

[0319] Here, updating includes at least one of the operations of adding, deleting, and modifying. Taking a correspondence in the permission update information (e.g., the first correspondence) as an example, updating the first correspondence to the permission database includes: when the update corresponding to the first correspondence is an add operation, writing the first correspondence to the permission database; when the update corresponding to the first correspondence is a delete operation, deleting the first correspondence from the permission database; when the update corresponding to the first correspondence is a modify operation, modifying the user whitelist in the target correspondence corresponding to the first correspondence in the permission database according to the first correspondence.

[0320] For example, assuming the first mapping is "Script Provider (End User) - Service Identifier (EMS_ChargePort) - Interface Identifier (Lock) - User Whitelist (Remote Login Users and Local Login Users)", and the permission database is shown in Table 2, then the interface management module updates the permission database based on the first mapping. This means that the interface management module matches the script provider, service identifier, and interface identifier in the first mapping to the target mapping in the permission database, "Script Provider (End User) - Service Identifier (EMS_ChargePort) - Interface Identifier (Lock) - User Whitelist (Remote Login Users)", thereby updating the user whitelist in the target mapping to the user whitelist in the first mapping (including remote login users and local login users). In this way, the modification of interface permissions is completed.

[0321] For example, if the user whitelist in the first mapping is empty or "null", and the interface management module matches a target mapping in the permission database based on the first mapping, then the interface management module updates the permission database based on the first mapping, including deleting the target mapping from the permission database. This completes the deletion of the interface permission.

[0322] For example, if the interface management module does not find a target correspondence in the permission database based on the first correspondence, the interface management module updates the permission database based on the first correspondence, including adding the first correspondence to the permission database. This completes the addition of new interface permissions.

[0323] In another implementation, when the permission update information includes the full correspondence, the interface management module updates the permission database according to the permission update information, including: the interface management module updates the content in the permission database with the permission update information.

[0324] For example, the interface management module can update the content in the permission database with permission update information by deleting the content in the permission database and storing the permission update information as the permission database.

[0325] In some possible embodiments, after the interface management module updates the permission database based on the permission update information, it also sends the update result to the script execution module, which then returns the update result to the OEM network-side device. Here, the update result indicates whether the permission database update was successful or failed.

[0326] The embodiment shown in Figure 8 supports dynamically updating interface permissions, which not only allows for timely responses to security vulnerabilities and enhances system security, but also increases the flexibility of interface permission control, enabling more granular and precise interface access control.

[0327] In some possible embodiments, as shown in Figure 7, a user's failure to call a certain interface during script execution is due to the atomic service detecting that the call does not meet functional safety conditions. Therefore, the corresponding check script needs to be updated so that the interface is not allowed to be called when it does not meet functional safety conditions, preventing improper operations from being propagated to the atomic service and reducing its load. In this case, the corresponding check script can be updated using the method shown in Figure 9.

[0328] Referring to Figure 9, which is a flowchart of a method for updating an interface check script according to an embodiment of this application, the method shown in Figure 9 is applied to an OEM network-side device, a script execution module, and an interface management module. Here, the script execution module and the interface management module are described in the corresponding content of Figure 1 above, and will not be repeated here.

[0329] The method shown in Figure 9 includes, but is not limited to, the following steps S901-S903.

[0330] S901: The script execution module obtains security update information from the OEM network-side device.

[0331] In one implementation, to reduce data transmission volume, the security update information includes at least one mapping relationship to be updated. This mapping relationship records the mapping relationship between the service identifier, the interface identifier, and the check script. Here, updating includes at least one of the operations of adding, modifying, and deleting.

[0332] In some solutions, when network resources are sufficient, security update information can also include a full set of mappings, where one mapping is used to record the mapping between service identifiers, interface identifiers, and inspection scripts.

[0333] In some possible embodiments, where the security update information is signed, the script execution module, after obtaining the security update information, first verifies the signature of the security update information to ensure the authenticity and integrity of the data.

[0334] S902: The script execution module sends security update information to the interface management module.

[0335] Accordingly, the interface management module receives security update information from the script execution module.

[0336] In some possible embodiments, the script execution module may also send the corresponding relationships in the security update information to the interface management module one by one.

[0337] S903: The interface management module updates and checks the database based on security update information.

[0338] In one implementation, when the security update information includes at least one correspondence to be updated, the interface management module updates the inspection database according to the security update information, including: the interface management module updates each correspondence in the security update information to the inspection database.

[0339] Here, updating includes at least one of the operations of adding, deleting, and modifying. Taking a correspondence (e.g., the second correspondence) in the security update information as an example, updating the second correspondence to the inspection database includes: when the update corresponding to the second correspondence is an add operation, writing the second correspondence to the inspection database; when the update corresponding to the second correspondence is a delete operation, deleting the second correspondence from the inspection database; when the update corresponding to the second correspondence is a modify operation, modifying the inspection script in the target correspondence corresponding to the second correspondence in the inspection database according to the second correspondence.

[0340] For example, assuming the second mapping is "Service Identifier (BCM_Door) - Interface Identifier (Open) - Inspection Script (Parking Inspection.script, Occupant Inspection.script, and Gear Position.script)", and the inspection database is shown in Table 1, then the interface management module updates the inspection database based on the second mapping. This means that the interface management module matches the service identifier and interface identifier in the second mapping to the target mapping "Service Identifier (BCM_Door) - Interface Identifier (Open) - Inspection Script (Parking Inspection.script and Occupant Inspection.script)" in the inspection database, thereby updating the inspection scripts in the target mapping to the inspection scripts in the second mapping (including Parking Inspection.script, Occupant Inspection.script, and Gear Position.script). In this way, the modification of the interface's inspection script is completed.

[0341] For example, if the check script in the second correspondence is empty or "null", and the interface management module matches a target correspondence in the check database that corresponds to the second correspondence, then the interface management module updates the check database based on the second correspondence, including deleting the target correspondence from the check database. This completes the deletion of the interface's check script.

[0342] For example, if the interface management module does not find a target correspondence with the second correspondence in the inspection database, the interface management module updates the inspection database based on the second correspondence, including adding the second correspondence to the inspection database. This completes the addition of the inspection script for the interface.

[0343] In another implementation, when the security update information includes all the corresponding relationships, the interface management module updates the inspection database according to the security update information, including: the interface management module updates the contents of the inspection database with the security update information.

[0344] For example, the interface management module can update the content in the inspection database with security update information by deleting the content in the inspection database and storing the security update information in the inspection database.

[0345] In some possible embodiments, after the interface management module updates the check database according to the permission update information, the interface management module can also send the update result to the script execution module, which then returns the update result to the OEM network-side device. Here, the update result is used to indicate whether the check database update was successful or failed.

[0346] The embodiment shown in Figure 9 supports dynamic updates of the inspection scripts corresponding to the interfaces. This updates the functional safety conditions or rules that the interface calls must meet, effectively addressing emerging security threats and significantly reducing the risks posed to vehicles by the script mechanism. Furthermore, it increases the flexibility of updating the inspection scripts, allowing for adaptability to system updates and hardware configuration changes.

[0347] In some possible embodiments, this solution may also provide an interface for online script debugging before the script leaves the factory, so as to realize the verification of the script. See Figure 10, which is a schematic diagram of script debugging provided by an embodiment of this application.

[0348] In Figure 10, the user sends a control command to the script execution module to download the script via the user command interface. In response to this command, the script engine in the script execution module downloads the target script. Simultaneously, the user sends debugging commands (such as start, pause, single-step commands) to the script engine in the script execution module via the debugging platform and the script interface. In response to these commands, the script engine executes the target script. During the execution of the target script, the script engine feeds back logs or events recorded during script execution to the debugging platform via the script interface. The resource management function in the script execution module feeds back resource consumption during script execution to the debugging platform via the script interface. The monitoring and statistics function in the script execution module feeds back service information during script execution to the debugging platform via the script interface. The data management function in the script execution module feeds back script parameter changes to the debugging platform via the script interface. Based on the received feedback, the debugging platform can create corresponding windows, such as window 1 as the code window, window 2 as the log event window, window 3 as the resource consumption window, window 4 as the service information window, and window 5 as the script parameter change window. Users can then observe and verify the script's execution process through these windows.

[0349] Implementing the example shown in Figure 10, the script is debugged before leaving the factory via a script interface. This allows for verification that the script can achieve its intended functions, timely detection and correction of logical errors within the script, and ensures that the script fully meets business requirements. The script interface can also be used to detect the script's execution efficiency and resource consumption, enabling performance optimization and ensuring stable and efficient operation in actual use. Furthermore, using the script interface for debugging enables automated testing, improving debugging efficiency, reducing the workload and errors of manual script testing, and facilitating the recording and analysis of debugging results, providing strong evidence for subsequent script improvements and optimizations.

[0350] Referring to Figure 11, which is a schematic diagram of a service orchestration device provided in an embodiment of this application, the service orchestration device 30 includes a script execution module 310, an interface management module 312, and a service management module 314. The service orchestration device 30 can be implemented in hardware, software, or a combination of both.

[0351] The script execution module 310 is used to execute a first script, which implements a first service, which is a new service for the vehicle and depends on at least a first sub-service; the interface management module 312 is used to determine whether the call of the first script to the first standardized interface of the first sub-service meets the functional safety conditions corresponding to the first standardized interface, and to convert the first standardized interface into the corresponding first service interface; the service management module 314 is used to communicate with the first sub-service based on the first service interface.

[0352] The service orchestration device 30 can be used to implement the method described in the embodiment of FIG3. In the embodiment of FIG3, the script execution module 310 can be used to execute S301 and S302, the interface management module 312 can be used to execute S303-S305, and the service management module 314 can be used to execute S306. The service orchestration device 30 can also be used to implement the methods described in the embodiments of FIG4, 5, 6, 7, 8, and 9, which will not be described in detail here for the sake of brevity.

[0353] It should be understood that the division of the units in the above service orchestration device 30 is only a logical functional division. In actual implementation, they can be fully or partially integrated into a single physical entity, or they can be physically separated. Furthermore, the units in the device can be implemented by a processor calling software; for example, the device includes a processor connected to a memory containing instructions. The processor calls the instructions stored in the memory to implement any of the above methods or to implement the functions of each unit in the device. The processor can be, for example, a general-purpose processor, such as a central processing unit (CPU) or a microprocessor, and the memory can be internal or external to the device. Alternatively, the units in the device can be implemented as hardware circuits. The functionality of some or all units can be achieved through the design of these hardware circuits, which can be understood as one or more processors. For example, in one implementation, the hardware circuit is an application-specific integrated circuit (ASIC). The functionality of some or all of the above units is achieved through the design of the logical relationships between the components within the circuit. In another implementation, the hardware circuit can be implemented using a programmable logic device (PLD). Taking a field-programmable gate array (FPGA) as an example, it can include a large number of logic gates. The connection relationships between the logic gates are configured through a configuration file, thereby achieving the functionality of some or all of the above units. All units of the above device can be implemented entirely through processor-invoked software, entirely through hardware circuits, or partially through processor-invoked software with the remaining parts implemented through hardware circuits.

[0354] In this application embodiment, a processor is a circuit with signal processing capabilities. In one implementation, the processor can be a circuit with instruction reading and execution capabilities, such as a central processing unit (CPU), a microprocessor, a graphics processing unit (GPU) (which can be understood as a type of microprocessor), or a digital signal processor (DSP). In another implementation, the processor can implement certain functions through the logical relationships of hardware circuits. These logical relationships of hardware circuits are fixed or reconfigurable. For example, the processor is a hardware circuit implemented using an application-specific integrated circuit (ASIC) or a programmable logic device (PLD), such as an FPGA. In a reconfigurable hardware circuit, the process of the processor loading a configuration document and configuring the hardware circuit can be understood as the process of the processor loading instructions to implement the functions of some or all of the above units. Furthermore, it can also be a hardware circuit designed for artificial intelligence, which can be understood as a type of ASIC, such as a neural network processing unit (NPU), a tensor processing unit (TPU), a deep learning processing unit (DPU), etc.

[0355] As can be seen, each unit in the above device can be one or more processors (or processing circuits) configured to implement the above methods, such as: CPU, GPU, NPU, TPU, DPU, microprocessor, DSP, ASIC, FPGA, or a combination of at least two of these processor forms.

[0356] Furthermore, the units in the above devices can be integrated in whole or in part, or they can be implemented independently. In one implementation, these units are integrated together as a system-on-a-chip (SOC). The SOC may include at least one processor for implementing any of the above methods or implementing the functions of the units in the device. The at least one processor may be of different types, such as CPU and FPGA, CPU and artificial intelligence processor, CPU and GPU, etc.

[0357] Referring to Figure 12, which is a schematic diagram of a computing device according to an embodiment of this application, the computing device 40 includes a processor 401, a communication interface 402, a memory 403, and a bus 404. The processor 401, the memory 403, and the communication interface 402 communicate with each other via the bus 404. It should be understood that this application does not limit the number of processors and memories in the computing device 40.

[0358] In one implementation, the computing device 40 may be a server deployed with the aforementioned service orchestration system, which can implement the service orchestration system-side methods provided in the various embodiments above.

[0359] Bus 404 can be a Peripheral Component Interconnect (PCI) bus or an Extended Industry Standard Architecture (EISA) bus, etc. Buses can be categorized as address buses, data buses, control buses, etc. For ease of illustration, only one line is used in Figure 12, but this does not imply that there is only one bus or one type of bus. Bus 404 can include pathways for transmitting information between various components of computing device 40 (e.g., memory 403, processor 401, communication interface 402).

[0360] The processor 401 can be referred to the relevant description of the processor in the above embodiments, and will not be repeated here.

[0361] Memory 403 provides storage space, which can store data such as the operating system and computer programs. Memory 403 can be one or a combination of several of the following: random access memory (RAM), erasable programmable read-only memory (EPROM), read-only memory (ROM), or compact disc read memory (CD-ROM). Memory 403 can exist alone or be integrated into processor 401.

[0362] The communication interface 402 can be used to provide information input or output to the processor 401. Alternatively, the communication interface 402 can be used to receive and / or send data to externally transmitted data, and can be a wired link interface including an Ethernet cable, or a wireless link interface (such as Wi-Fi, Bluetooth, general wireless transmission, etc.). Alternatively, the communication interface 402 may also include a transmitter (such as an RF transmitter, antenna, etc.) or a receiver coupled to the interface.

[0363] The processor 401 in the computing device 40 is used to read the computer program stored in the memory 403 to execute the aforementioned methods, such as the methods described in the embodiments of FIG3, FIG4, FIG5, FIG6, FIG7, FIG8 and FIG9.

[0364] In one possible design, computing device 40 may be one or more modules in an execution body that performs the method shown in FIG3, and processor 401 may be used to read one or more computer programs stored in memory for performing the following operations:

[0365] The first script is executed by the script execution module 310. The first script is used to implement the first service, which is a new service for the vehicle. The first service depends on at least the first sub-service.

[0366] The interface management module 312 determines that the call of the first script to the first standardized interface of the first sub-service meets the functional safety conditions corresponding to the first standardized interface, and converts the first standardized interface into the corresponding first service interface.

[0367] The service management module 314 communicates with the first sub-service based on the first service interface.

[0368] In the embodiments described above, each embodiment has its own emphasis. For parts not described in detail in a particular embodiment, please refer to the relevant descriptions in other embodiments. Furthermore, in the embodiments of this application, unless otherwise specified or logically conflicting, the terminology and / or descriptions between the embodiments are consistent and can be mutually referenced. Technical features from different embodiments can be combined to form new embodiments based on their inherent logical relationships.

[0369] It should be noted that those skilled in the art will recognize that all or part of the steps in the various methods of the above embodiments can be implemented by a program instructing related hardware. This program can be stored in a computer-readable storage medium, including read-only memory (ROM), random access memory (RAM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), one-time programmable read-only memory (OTPROM), electrically-erasable programmable read-only memory (EEPROM), compact disc read-only memory (CD-ROM) or other optical disc storage, disk storage, magnetic tape storage, or any other computer-readable medium capable of carrying or storing data.

[0370] The technical solution of this application, in essence, or the part that makes the contribution, or all or part of the technical solution, can be embodied in the form of a software product. The computer program product is stored in a storage medium and includes several instructions to cause a device (which may be a personal computer, server, network device, robot, microcontroller, chip, robot, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application.

Claims

1. A service orchestration system, characterized in that, The service orchestration system includes a script execution module, an interface management module, and a service management module, wherein... The script execution module is used to execute a first script, wherein the first script is used to implement a first service, the first service is a new service for the vehicle, and the first service depends on at least a first sub-service; The interface management module is used to determine whether the call of the first script to the first standardized interface of the first sub-service satisfies the functional safety conditions corresponding to the first standardized interface, and to convert the first standardized interface into the corresponding first service interface. The service management module is used to communicate with the first sub-service based on the first service interface.

2. The system according to claim 1, characterized in that, The script execution module is specifically used to execute the first script in response to a service request, wherein the service request includes the identifier of the first service and the identifier of the first user, and the first user is associated with the first service; The interface management module is also used to determine whether the first user has permission to call the first standardized interface.

3. The system according to claim 2, characterized in that, The first service is an extension of the second service of the vehicle, wherein the second service is implemented through an OTA software package.

4. The system according to claim 3, characterized in that, The service management module is also used to bind the first service to the communication address of the second service.

5. The system according to claim 3 or 4, characterized in that, During the execution of the first script, the first script is also used to determine, based on the acquired business scenario information, to enable at least one of the first service and the second service.

6. The system according to claim 2, characterized in that, The first service is used to implement the function of the first component, which is a newly added component of the vehicle.

7. The system according to claim 6, characterized in that, The script execution module is further configured to execute a second script, which converts the user's operation on the first component into the service request, wherein the user is the person enjoying the first service.

8. The system according to claim 7, characterized in that, The first script is also used to provide control parameters for the first component; The second script is also used to control the first component based on the acquired control parameters of the first component.

9. The system according to any one of claims 1-8, characterized in that, The script execution module is also used to obtain the first script from the user terminal or network-side device.

10. The system according to any one of claims 2-9, characterized in that, The interface management module is specifically used for: The whitelist of target users corresponding to the provider of the first script, the identifier of the first sub-service, and the identifier of the first standardized interface is retrieved from the permission database. The whitelist of target users is used to indicate users who are allowed to use the first standardized interface. It is determined that the first user belongs to the target user whitelist.

11. The system according to claim 10, characterized in that, The script execution module is also used to receive permission update information from network-side devices; The interface management module is also used to update the permission database based on the permission update information.

12. The system according to any one of claims 1-11, characterized in that, The interface management module is specifically used for: The target inspection script is obtained from the inspection database based on the identifier of the first sub-service and the identifier of the first standardized interface. The target inspection script is used for functional security checks when the first standardized interface is invoked. The target inspection script is executed to determine whether the first script's call to the first standardized interface satisfies the functional safety conditions corresponding to the first standardized interface. The inspection database includes the identifier of the first sub-service, the identifier of the first standardized interface, and the correspondence between the target inspection scripts.

13. The system according to claim 12, characterized in that, The script execution module is also used to obtain security update information and send the security update information to the interface management module; The interface management module is also used to update the inspection database based on the security update information.

14. The method according to any one of claims 1-13, characterized in that, The script execution module is further configured to send operation and maintenance observation information to network-side devices, wherein the operation and maintenance observation information includes at least one of the following: Execution information for each script; The resource consumption of each script; The invocation of standardized interfaces during script execution; and, The script execution process includes statistical information on communication between various services.

15. A service orchestration method, characterized in that, The method includes: Execute the first script, wherein the first script is used to implement the first service, the first service is a new service for the vehicle, and the first service depends on at least the first sub-service; During the execution of the first script, communication is conducted with the first sub-service based on the first service interface; The first service interface is obtained by converting the first standardized interface of the first sub-service, and the first script's call to the first standardized interface satisfies the functional safety conditions corresponding to the first standardized interface.

16. The method according to claim 15, characterized in that, The execution of the first script includes: In response to a service request, the first script is executed, wherein the service request includes an identifier of the first service and an identifier of a first user, and the first user is associated with the first service; Before communicating with the first sub-service based on the first service interface, the method further includes: It is determined that the first user has permission to call the first standardized interface.

17. The method according to claim 16, characterized in that, The first service is an extension of the second service of the vehicle, wherein the second service is implemented through an OTA software package.

18. The method according to claim 17, characterized in that, The method further includes: Bind the first service to the communication address of the second service.

19. The method according to claim 17 or 18, characterized in that, During the execution of the first script, the first script is also used to determine, based on the acquired business scenario information, to enable at least one of the first service and the second service.

20. The method according to claim 16, characterized in that, The first service is used to implement the function of the first component, which is a newly added component of the vehicle.

21. The method according to claim 20, characterized in that, Before executing the first script, the method further includes: Execute a second script, wherein the second script is used to convert the user's operation on the first component into the service request, the user being the person enjoying the first service.

22. The method according to any one of claims 15-21, characterized in that, The method further includes: Obtain the first script from the user terminal or network-side device.

23. The method according to any one of claims 16-22, characterized in that, The step of determining that the first user has permission to call the first standardized interface includes: The whitelist of target users corresponding to the provider of the first script, the identifier of the first sub-service, and the identifier of the first standardized interface is retrieved from the permission database. The whitelist of target users is used to indicate users who are allowed to use the first standardized interface. It is determined that the first user belongs to the target user whitelist.

24. The method according to claim 23, characterized in that, The method further includes: Receive permission update information from network-side devices; The permission database is updated based on the permission update information.

25. The method according to any one of claims 15-24, characterized in that, The process of determining that the call of the first script to the first standardized interface satisfies the functional safety conditions corresponding to the first standardized interface includes: The target inspection script is obtained from the inspection database based on the identifier of the first sub-service and the identifier of the first standardized interface. The target inspection script is used for functional security checks when the first standardized interface is invoked. The target inspection script is executed to determine whether the first script's call to the first standardized interface satisfies the functional safety conditions corresponding to the first standardized interface.

26. The method according to claim 25, characterized in that, The method further includes: Receive security update information from network-side devices; The inspection database is updated based on the security update information.

27. An apparatus for service orchestration, characterized in that, The device includes a memory and a processor, the memory storing computer program instructions, and the processor executing the computer program instructions to cause the device to perform the method as described in any one of claims 15-26.

28. A vehicle, characterized in that, The vehicle includes the system as described in any one of claims 1-14, or the device as described in claim 27.

29. A computer-readable storage medium containing computer instructions, characterized in that, When the computer instructions are executed by the processor, they implement the method as described in any one of claims 15-26.

30. A computer program product containing instructions, characterized in that, When the instructions are executed by the computing device, the computing device performs the method as described in any one of claims 15-26.

Images