Methods and devices for dynamic deployment of vehicle-mounted services

Abstract

This application provides a method and apparatus for dynamic deployment of in-vehicle services, relating to the field of in-vehicle software architecture design technology. The method includes: acquiring an in-vehicle service instance; when the in-vehicle service instance starts, acquiring matching resources in real time from a computing resource entity; binding the matching resources to the in-vehicle service instance; and deploying the in-vehicle service instance using the matching resources. This application dynamically acquires matching resources from the computing resource entity in real time when the in-vehicle service instance starts and deploys the in-vehicle service instance using the matching resources. Therefore, this application offers high flexibility in deploying in-vehicle services, allowing for real-time allocation based on actual computing resources, and is also beneficial for maintenance. Furthermore, this method effectively improves resource utilization and avoids wasting idle resources.

Description

Technical Field

[0001] This application relates to the field of vehicle software architecture design technology, and in particular to a method and apparatus for dynamic deployment of vehicle services. Background Technology

[0002] In order to realize the various functions of the vehicle, different in-vehicle services are designed in the in-vehicle electronic system.

[0003] However, the deployment of in-vehicle services in related technologies suffers from poor flexibility, maintainability, and low resource utilization. Summary of the Invention

[0004] This application provides a method for dynamic deployment of vehicle services to address the shortcomings of existing methods in terms of poor flexibility, maintainability, and low resource utilization, thereby improving the flexibility and resource utilization of dynamic deployment of vehicle services.

[0005] In a first aspect, this application provides a method for dynamically deploying in-vehicle services in a vehicle, wherein the vehicle applies an open automotive system architecture platform, the open automotive system architecture platform including a computing resource entity, the computing resource entity being used to describe the environment for software deployment and execution, and the method comprising: Obtain an in-vehicle service instance; When the vehicle service instance starts, it obtains matching resources from the computing resource entity in real time; Bind the matching resource to the vehicle service instance; The in-vehicle service instance is deployed using the matching resources.

[0006] Optionally, the method further includes: Query available resources from the computing resource entity; Get a list of available resources; Check the available resources in the available resource list and return the resource check results; When the resource check result indicates that the resource is satisfied, obtaining the matching resource from the computing resource entity includes: Retrieve matching resources from the list of available resources.

[0007] Optionally, the real-time acquisition of matching resources from the computing resource entity includes: Obtain the component corresponding to the in-vehicle service instance; The resource corresponding to the component is parsed from the computing resource entity; If the resource corresponding to the component is idle, then the resource corresponding to the component will be used as the matching resource. If the resource corresponding to the element is not idle, then other idle resources are selected from the computing resource entities as the matching resource.

[0008] Optionally, the step of using the resource corresponding to the element as the matching resource if the resource corresponding to the element is idle includes: Obtain the processor utilization and memory utilization of the resources corresponding to the component; If the processor utilization rate is less than or equal to the first threshold and the memory utilization rate is less than or equal to the second threshold, then the resource corresponding to the component is idle, and the component resource is used as the matching resource.

[0009] Optionally, after deploying the in-vehicle service instance using the matching resources, the method further includes: Real-time acquisition of the service response time, processor utilization, and memory utilization of the matched resources; When the service response time exceeds the time threshold N times consecutively, or the processor utilization rate is continuously greater than the first threshold for more than M seconds, or the memory utilization rate is continuously greater than the second threshold for more than L seconds, the matching resource will be unbound from the vehicle service instance. Re-obtain updated matching resources from the computing resource entity, and deploy the in-vehicle service instance using the updated matching resources; Wherein, M, N and L are all positive integers greater than 1.

[0010] Optionally, the method further includes: Obtain the vehicle function requirements, which include the functions in the vehicle service instance; Transform the aforementioned in-vehicle function requirements into in-vehicle services; The core elements of the in-vehicle service are defined using a modeling language and a unique identifier is set. The core elements include at least: service, service provider, service consumer and service port. Define the interface type of the vehicle service, wherein the interface type includes events, methods, and fields; Confirm the service role of the in-vehicle service; Generate service architecture diagrams using visual modeling tools; The service framework code is generated based on the unique identifier, the interface type, the service role, and the service architecture diagram.

[0011] Optionally, deploying the in-vehicle service instance using the matching resources includes: The in-vehicle service instance is deployed using the matching resources based on the service framework code.

[0012] Optionally, the method further includes: Obtain the current service-oriented architecture of the vehicle; The service-oriented architecture is divided into system layering, service layering, and deployment layering to obtain the layered architecture. The system layering includes the vehicle application layer, platform service layer, device abstraction layer, and hardware layer. The service layering includes the hardware abstraction service layer, platform core service layer, domain core service layer, and application service layer. The deployment of the in-vehicle service instance using the matching resources includes: The in-vehicle service instance is deployed using the matching resources based on the layered architecture.

[0013] Secondly, this application also provides a vehicle-mounted service dynamic deployment device, comprising: The first acquisition module is used to acquire in-vehicle service instances; The second acquisition module is used to acquire matching resources from the computing resource entity in real time when the vehicle service instance starts. A binding module is used to bind the matching resource to the vehicle service instance; The deployment module is used to deploy the vehicle service instance using the matching resources.

[0014] Thirdly, this application also provides an electronic device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the method described in the first aspect.

[0015] Fourthly, this application also provides a non-transitory computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the method described in the first aspect.

[0016] Fifthly, this application also provides a computer program product, including a computer program that, when executed by a processor, implements the method described in the first aspect.

[0017] The method and apparatus for dynamic deployment of in-vehicle services provided in this application acquire an in-vehicle service instance. When the in-vehicle service instance starts, it obtains matching resources from the computing resource entity in real time and binds the matching resources to the in-vehicle service instance; then, it deploys the in-vehicle service instance using the matching resources. Compared to the static binding method in related technologies, which presets fixed resources for different services during the development phase, this application dynamically and in real time acquires matching resources from the computing resource entity when the in-vehicle service instance starts and uses the matching resources to deploy the in-vehicle service instance. Therefore, this application offers greater flexibility in deploying in-vehicle services, allowing for real-time allocation based on actual computing resources, and is also beneficial for maintenance. Furthermore, this method effectively improves resource utilization and avoids wasting idle resources. Attached Figure Description

[0018] To more clearly illustrate the technical solutions in this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0019] Figure 1 This is a flowchart illustrating the dynamic deployment method for in-vehicle services provided in an embodiment of this application; Figure 2 This is a flowchart illustrating the standardized modeling method provided in the application embodiments of this application; Figure 3 This is a schematic diagram of the hierarchical structure provided in the application embodiments of this application; Figure 4 This is a schematic diagram of the system layering structure provided in the application embodiments of this application; Figure 5 This is a schematic diagram of the service layering structure provided in the application embodiments of this application; Figure 6 This is a schematic diagram of the dynamic deployment process provided in the application embodiments of this application; Figure 7 This is a diagram of the intelligent cockpit domain service architecture; Figure 8 This is a diagram of the autonomous driving domain service architecture; Figure 9 This is a schematic diagram of the structure of the vehicle-mounted service dynamic deployment device provided in the embodiments of this application; Figure 10 This is a schematic diagram of the structure of the electronic device provided in the embodiments of this application. Detailed Implementation

[0020] To make the objectives, technical solutions, and advantages of this application clearer, the technical solutions of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0021] In traditional in-vehicle electronic systems, different in-vehicle services are designed to realize various vehicle functions. For example, intelligent cockpit services achieve vehicle intelligence by designing features such as air conditioning control, seat adjustment, and ambient lighting control.

[0022] However, related technologies suffer from poor flexibility, maintainability, and low resource utilization in deploying in-vehicle services. The main reason is that these technologies employ static deployment methods, typically establishing a fixed binding mechanism for the in-vehicle service during the development phase. This binding relationship is established and cannot be modified at any subsequent stage. This design results in poor flexibility, maintainability, and low resource utilization. Specifically, the static nature of service deployment leads to an average hardware resource utilization rate of only 40%, which is extremely low and cannot adapt to the heterogeneity of in-vehicle hardware and the demands of dynamic resource adjustments.

[0023] This application relates to the field of in-vehicle software architecture design, specifically a dynamic deployment method for in-vehicle service-oriented architecture (SOA) based on AUTOSAR-AP (Adaptive AUTOSAR). This technology is applicable to the software architecture design of intelligent connected vehicles, aiming to solve the dynamic deployment problem in complex in-vehicle system scenarios. AUTOSAR-AP (Adaptive AUTOSAR) is a platform within the Automotive Open System Architecture (AUTOSAR) framework, specifically designed to meet the needs of modern intelligent vehicles for high-performance computing, dynamic software architecture, and flexible service collaboration. Core Objectives and Design Features: The core objective of AUTOSAR-AP is to support high-performance computing, dynamic software updates, and cross-domain service integration.

[0024] In AUTOSAR Adaptive Platform (AP), Machine is a core concept representing a computing resource entity used to describe the environment in which software is deployed and executed. Essentially, a Machine is a virtualized computing resource; it can be a physical processor (such as a CPU core on an ECU) or a virtual machine.

[0025] In intelligent connected vehicles, Service-Oriented Architecture (SOA) enhances system flexibility and scalability by decomposing vehicle functions into independent service components. In-vehicle SOA systems are a software architecture design methodology for intelligent vehicles that abstracts vehicle hardware resources and functions into independently callable "services." These services are then combined and invoked through standard interfaces and communication protocols to support flexible feature development and iteration.

[0026] SoaML (Service-Oriented Architecture Modeling Language) is an extension of UML specifically designed for modeling service-oriented architectures (SOA). In the automotive industry, it facilitates the reuse and integration of software components by defining services, interfaces, and roles. The core concepts of SoaML include service, service role, and interface definitions.

[0027] To further illustrate the scheme of this application, some terms involved in this application will be explained here.

[0028] The following table is a list of abbreviations in this application.

[0029]

[0030] The following table is a glossary of key terms for this application.

[0031]

[0032] Firstly, this application provides a method for dynamically deploying in-vehicle services in a vehicle. The vehicle utilizes the Automotive Open System Architecture Platform (AUTOSAR-AP), which includes a computing resource entity (Machine) that describes the environment for software deployment and execution. Figure 1 This is a flowchart illustrating the dynamic deployment method for in-vehicle services provided in an embodiment of this application. (Refer to...) Figure 1 This application provides a method for dynamically deploying in-vehicle services. The executing entity can be a control system, which can be located in a terminal or a server. The terminal can include an in-vehicle terminal or a user terminal, and the server can be a server that communicates with the vehicle. No specific limitation is imposed; the following description uses a vehicle control system as the executing entity. The method can include steps 110-140.

[0033] Step 110: Obtain an in-vehicle service instance.

[0034] In-vehicle service examples can be a collection of various control services for vehicles, such as intelligent cockpit domain services, which achieve the effect of an intelligent cockpit by controlling the vehicle's air conditioning, seats, and ambient lighting. They can also be autonomous driving services, which provide services to the vehicle through the integration of environmental perception, path planning, and vehicle control. All of these services require corresponding resource support to execute.

[0035] Step 120: When the vehicle service instance starts, it obtains matching resources from the computing resource entity in real time.

[0036] This application obtains matching resources from computing resource entities in real time when the vehicle service instance starts.

[0037] Step 130: Bind the matching resource to the vehicle service instance.

[0038] Step 140: Deploy the in-vehicle service instance using matching resources.

[0039] The core of this application, based on the "dynamic" nature of AUTOSAR-AP Machine, is to break through the limitations of traditional static binding by using Machine as a logical entity for software deployment, and to achieve adaptive binding and dynamic optimization adjustment at runtime.

[0040] Traditional usage often involves a "fixed binding" pre-set during the development phase, which cannot be changed once fixed. The "dynamic" nature of this invention, however, adds a core mechanism of "real-time adaptation and flexible adjustment" to this foundation, which can be understood from three levels: First, the binding relationship is dynamically established. The mapping between service instances and machines in this application is not fixed during the development phase, but is automatically completed at runtime (corresponding to the startup of the vehicle service instance in step 120). When the service starts, the system will use the service discovery mechanism. In one embodiment of this application, this service discovery mechanism has a latency threshold of ≤50ms. When the service discovery mechanism discovers that a service instance has started, it will automatically match a machine that meets the resource requirements (such as CPU, memory, and supported protocols), without the need for manual pre-configuration of the binding relationship. For example, when the "air conditioning control service" starts, it will automatically identify whether the machine corresponding to the current cabin MCU has idle resources. If it does, the binding will be established in real time; otherwise, other available machines (such as a spare processor) will be matched.

[0041] Second, the dynamic adjustment of the binding relationship corresponds to the real-time acquisition of matching resources from the computing resource entity in step 120. During subsequent service operation, the system monitors the machine's resource utilization in real time. When preset conditions are triggered, it will proactively break the original binding and redeploy the service. This "on-demand adjustment" is a core capability that traditional static binding (which cannot be changed after binding) does not possess. In other words, this adjustment in this application is performed dynamically in real time.

[0042] Third, dynamic adaptation across hardware: As a virtualized ECU concept, a machine can be mapped to different physical processors (MCU, MPU, virtual machine), and "dynamic" supports seamless migration of services between different machines, shielding the differences in hardware heterogeneity. For example, the "environmental perception service" in the autonomous driving domain is initially deployed on the machine corresponding to the AI ​​chip. When a switch is needed through real-time dynamic adjustment, such as when the chip temperature exceeds 85°C, the system will trigger a frequency reduction or migration strategy to dynamically bind the service to other machines that meet the computing power requirements, ensuring hardware safety without interrupting service operation.

[0043] Therefore, this application uses Machine as the "logical carrier" for service deployment and Machine's binding function as the basis for dynamic deployment. The "dynamic" aspect of this application is that, on this carrier, through "real-time resource monitoring, triggered redeployment, and automatic service discovery," the binding between services and Machine changes from "fixed during development" to "adaptive at runtime," ultimately achieving the goals of optimized resource utilization, self-healing of faults, and load balancing.

[0044] The method described in this application allows for real-time allocation of actual computing resources, improving flexibility and facilitating maintenance. It also effectively increases resource utilization, avoids wasting idle resources, and raises resource utilization from 40% to 65%, thus solving the problem of resource waste in static deployment.

[0045] In one embodiment of this application, the method further includes steps 210-230.

[0046] Step 210: Query available resources from the computing resource entity.

[0047] Before proceeding to step 110, this application may first query available resources in the computing resource entity, where available resources may include idle resources.

[0048] Step 220: Obtain a list of available resources.

[0049] After obtaining multiple available resources, a list of available resources can be formed.

[0050] Step 230: Check the available resources in the available resource list and return the resource check results; After obtaining the list of available resources, each available resource is checked, and the resource check results are returned.

[0051] By following the steps above, available resources in the computing resource entity can be acquired and checked first. Therefore, in the subsequent deployment process, efficiency can be effectively improved and deployment failure caused by useless resources can be avoided.

[0052] In one embodiment of this application, when the resource check result in step 230 is that the resource is satisfied, step 120 of this application, obtaining the matching resource from the computing resource entity, includes: obtaining the matching resource from the list of available resources.

[0053] When the available resources check shows that all resources meet the requirements, it means that all available resources in the available resource list have met the check. Then, matching resources can be obtained from the available resource list. This method can effectively improve the efficiency of subsequent deployments and avoid deployment failures. Moreover, by obtaining matching resources from the available resource list in real time, all resources obtained afterward are available resources, without the need for secondary filtering and checking.

[0054] If the resource check result of this application is that the resources are not satisfied, some resources will be discarded. For example, if there are 30 resources in the resource entity, and 5 resources are found to be unsatisfactory, then the remaining 25 resources can be used as the list of available resources, and the other resources will be discarded.

[0055] In one embodiment of this application, in step 120 of this application, a method for obtaining matching resources from a computing resource entity in real time is provided. Alternatively, a selection method can be set for obtaining matching resources from a computing resource entity in real time, such as steps 310-340 below.

[0056] Step 310: Obtain the components corresponding to the vehicle service instance.

[0057] Each in-vehicle service instance includes different in-vehicle services, which correspond to various components of the vehicle. For example, the smart cockpit domain service achieves the smart cockpit effect by controlling the vehicle's air conditioning, seats, and ambient lighting. Therefore, the corresponding components can include air conditioning, seats, and ambient lighting.

[0058] Step 320: Parse the resources corresponding to the components from the computing resource entity.

[0059] Step 320 of this application can parse the corresponding resources of the components from the computing resource entity. For example, the resources of the air conditioner can be the air conditioner controller, the resources of the seat can be the seat controller, and the resources of the ambient light can be the ambient light controller. In some vehicles, these three are controlled by the same controller. Therefore, this application can parse the corresponding resources of the components from the computing resource entity.

[0060] Step 330: If the resource corresponding to the component is idle, then use the resource corresponding to the component as the matching resource.

[0061] By determining the idle status of the resource corresponding to the component, if the resource corresponding to the component is idle, then the resource corresponding to the component can be used as the matching resource.

[0062] In one embodiment of this application, in step 330, if the resource corresponding to the element is idle, then the resource corresponding to the element is used as the matching resource, including: Obtain the processor utilization and memory utilization of the resources corresponding to the component; If the processor utilization is less than or equal to the first threshold and the memory utilization is less than or equal to the second threshold, then the corresponding resource of the component is idle, and the component resource is used as the matching resource.

[0063] For example, this application can be configured to use component resources as matching resources when the processor utilization rate (CPU ≤ 80%) and memory utilization rate (≤ 70%).

[0064] Step 340: If the resource corresponding to the component is not idle, select other idle resources from the computing resource entities as matching resources.

[0065] For example, when configuring a service instance for the autonomous driving domain, the components corresponding to the "environmental perception service" of the autonomous driving domain include AI analysis components. This application can deploy the environmental perception service on the machine corresponding to the AI ​​chip. Through the above steps 310-340, the resources corresponding to the components can be allocated dynamically in real time according to the service instance. Since the control of each component by the resources corresponding to each component is more stable and efficient, the method of this application can further improve stability.

[0066] In one embodiment of this application, if an in-vehicle service instance corresponds to multiple components, the application can select the more idle component for deployment based on its availability. For example, when autonomous driving includes environmental perception and path planning, the corresponding components are an AI chip and a navigation chip, respectively. In this case, the resource corresponding to the more idle component can be deployed based on its availability.

[0067] In one embodiment of this application, if an in-vehicle service instance corresponds to multiple components, the application can select the resource corresponding to the component based on its computing power, choosing the one with higher computing power for deployment. For example, when autonomous driving includes environmental perception and path planning, the corresponding components are an AI chip and a navigation chip, respectively. In this case, the resource corresponding to the AI ​​chip with higher computing power can be selected for deployment based on its computing power.

[0068] The selections made in steps 310-340 are not fixed; the dynamics of this application are dynamically adjusted. Specifically, this application may also include the following steps.

[0069] In one embodiment of this application, after deploying the in-vehicle service instance using matching resources in step 140, this application further includes: Step 150: Obtain the service response time, processor utilization, and memory utilization of the matching resources in real time.

[0070] The binding of matching resources in this application is not fixed. After the binding and deployment are completed in step 140, this application will also monitor and update in real time. Specifically, step 150 of this application can obtain the service response time, processor utilization, and memory utilization of the matching resources in real time.

[0071] Step 160: When the service response time exceeds the time threshold N times consecutively, or the processor utilization rate is continuously greater than the first threshold for more than M seconds, or the memory utilization rate is continuously greater than the second threshold for more than L seconds, the matching resource will be unbound from the vehicle service instance.

[0072] For example, this application can set the matching resource to be unbound from the vehicle service instance when the service response time exceeds the time threshold five times consecutively, or the processor utilization rate is continuously greater than the first threshold for more than 10 seconds, or the memory utilization rate is continuously greater than the second threshold for more than 10 seconds.

[0073] In the event of a hardware failure, the matching resource will be unbound from the in-vehicle service instance. For example, if a component's corresponding resource fails and cannot function, such as a damaged AI chip, the matching resource will be unbound from the in-vehicle service instance.

[0074] Specifically, when a warning occurs for a resource corresponding to a certain component, the matching resource will also be unbound from the vehicle service instance. For example, when the temperature of the chip corresponding to the matching resource exceeds 85°C, the system will trigger a frequency reduction or migration strategy, at which point the matching resource will also be unbound from the vehicle service instance.

[0075] Step 170: Retrieve the updated matching resource from the computing resource entity and deploy the vehicle service instance using the updated matching resource; where M, N and L are all positive integers greater than 1.

[0076] Step 170 of this application can retrieve the updated matching resource from the computing resource entity and then use the updated matching resource to deploy the vehicle service instance.

[0077] In step 170, updated matching resources can be retrieved again from the list of available resources mentioned above.

[0078] This application solves the problems of poor flexibility and resource utilization caused by traditional fixed binding through the above steps. By using real-time dynamic judgment to match resources, if the conditions are not met, timely replacement is made, which effectively improves the efficiency of the entire deployment. At the same time, it also activates some resources, avoids resources being idle for a long time, and improves resource utilization. Through the above method, the resource utilization rate of this application is increased from 40% to 65%, solving the problem of resource waste in static deployment.

[0079] The above steps have solved the deployment problem of this application. The following will continue to improve and optimize other parts of this application.

[0080] Among related technologies, the current automotive SOA architecture still has the following technical shortcomings: Service modeling lacks a unified standard: traditional modeling methods are not tailored to in-vehicle scenarios and cannot effectively describe the real-time and security requirements unique to in-vehicle systems.

[0081] The system is not clearly layered: the functional boundaries of each layer are blurred, and there are serious cross-layer dependencies, resulting in low module reuse rate.

[0082] Therefore, when iterating on functions, the development efficiency of a vehicle system using a traditional architecture is reduced by about 35% due to module coupling, resulting in a significant loss of development efficiency.

[0083] To address the aforementioned issues, this application further discloses the following method. This method adopts OMG's (Object Management Group) SoaML (Service-Oriented Architecture Modeling Language) as the basic modeling language and extends it for the automotive scenario to define a meta-model and visualization modeling method suitable for the automotive environment.

[0084] In one embodiment of this application, the method further includes: Step 410: Obtain vehicle function requirements. Vehicle function requirements include functions in the vehicle service instance, such as requirements for air conditioning control and window adjustment.

[0085] Step 420: Convert vehicle function requirements into vehicle services. This application can abstract function requirements into independent services. For example, convert the above air conditioning control and window adjustment into "air conditioning control service" and "window control service".

[0086] Step 430: Define the core elements of the in-vehicle service using a modeling language and set a unique identifier. The core elements should include at least: service, service provider, service consumer, and service port. For example, this application can use Soa ML to define the core elements of the service and set a unique service ID (such as 0x1001). Taking air conditioning control as an example, its ID could be 0x1006.

[0087] Step 440: Define the interface types for the vehicle service, where each interface type includes events, methods, and fields. Event types include, for example, "Outside Temperature Change Event," with a trigger threshold of a temperature change ≥ 1℃; method types include, for example, "Set Air Conditioning Temperature," with a response time threshold ≤ 100ms; and field types include, for example, "Window Status," with an update frequency threshold ≥ 10Hz.

[0088] Step 450: Confirm the service role of the vehicle service.

[0089] This step is used to identify the service provider; for example, the air conditioner corresponds to the air conditioning ECU, and the consumer corresponds to the central control screen.

[0090] Step 460: Use a visual modeling tool to generate a service architecture diagram.

[0091] This step is the visual modeling phase, where the iDesigner tool can be used to generate service architecture diagrams. iDesigner is a core interface for extending design-time functionality, allowing developers to provide custom behavior for components, thereby enhancing the interactive experience of visual designers (such as the Windows Forms Designer in Visual Studio).

[0092] Step 470: Generate service framework code based on unique identifier, interface type, service role, and service architecture diagram.

[0093] Step 470 of this application can generate service framework code based on unique identifiers, interface types, service roles, and service architecture diagrams, thus completing the modeling process.

[0094] The steps outlined in this application define an in-vehicle service metamodel, including core elements such as Service, Service Provider, Service Consumer, and Service Port. It also extends SoaML to support in-vehicle specific event, method, and field interface types, with events supporting periodic triggering (e.g., vehicle speed update events, triggered when the speed change exceeds 5 km / h). Standardized description methods for service interfaces are established, including parameter types (e.g., sensor data accuracy threshold: temperature sensor error ≤ 0.5℃) and response time requirements (critical control methods response ≤ 50ms).

[0095] Through the above steps, development efficiency is effectively improved: standardized modeling and automatic code generation shorten the development cycle by 40%, increase module reuse rate by 50%, and reduce the amount of repetitive development work.

[0096] In one embodiment of this application, based on the above scheme, a model verification stage may be included before step 470, which checks interface compatibility and the rationality of role allocation.

[0097] In one embodiment of this application, based on the above scheme, step 140 of this application, which involves deploying the in-vehicle service instance using matching resources, includes: Deploy in-vehicle service instances based on service framework code using matching resources.

[0098] Once the modeling is completed, the service framework code of the model can be used to deploy in-vehicle service instances, which can effectively improve deployment efficiency.

[0099] These two sections are interconnected and complementary: the former, "deploying in-vehicle service instances based on service framework code," describes the specific deployment method; the latter supplements the prerequisites for this method (generating service framework code after modeling is completed), and clarifies the core value of this operation (improving deployment efficiency). They are not independent steps, but rather together form a process chain of "modeling completion → generating service framework code → deploying in-vehicle service instances based on this code → achieving improved deployment efficiency." The former is the action executed within this chain, while the latter is the prerequisite and extension of the effect, mutually supporting each other to form a complete logic for improving deployment efficiency.

[0100] In one embodiment of this application, the method further includes: Step 510: Obtain the current service-oriented architecture of the vehicle.

[0101] For example, by acquiring the in-vehicle SOA system.

[0102] Step 520: Divide the service-oriented architecture into system layers, service layers, and deployment layers to obtain the layered architecture; the system layer includes the vehicle application layer, platform service layer, device abstraction layer, and hardware layer; the service layer includes the hardware abstraction service layer, platform core service layer, domain core service layer, and application service layer.

[0103] This application can effectively layer SOA through the above steps, which can reduce maintenance costs: the clear layered architecture reduces module coupling by 35%, shortens fault location time by 60%, and reduces system maintenance costs by 30%.

[0104] In one embodiment of this application, based on the above scheme, step 140 of this application, which involves deploying the vehicle service instance using matching resources, includes: Deploy in-vehicle service instances based on a layered architecture using matching resources.

[0105] The current "matching resources to deploy in-vehicle service instances based on the layered architecture" is driven by the previously outlined architecture layering steps (system, service, and deployment layers), which serve as the prerequisite for this deployment. The dynamic service deployment process (obtaining in-vehicle service instances, binding and matching resources, and utilizing resources to complete deployment) is the concrete implementation of this deployment logic. These two elements form a seamless connection: "pre-existing architecture layering → current layered deployment → supporting device operation," with each stage supporting the others to jointly complete the dynamic deployment of in-vehicle services.

[0106] This application utilizes the aforementioned layered structure for deployment, which can further improve deployment efficiency. Among these steps, modeling, layered deployment, and dynamic deployment are interconnected and form the core components supporting the implementation of SOA. Together, they ensure that vehicle services can be developed efficiently, executed reliably, and flexibly adapted to runtime changes.

[0107] In the embodiments of this application, after generating the aforementioned service framework code, the deployment step utilizes matching resources to deploy the in-vehicle service instance based on this code. After the architecture is layered, the deployment relies on the layered system, service, and deployment layered architecture, combined with matching resources, to complete the deployment. Both serve as prerequisites for deployment, adapting the deployment process from the code foundation and architectural logic levels respectively, ensuring standardized and efficient deployment, and seamless integration with the core deployment steps.

[0108] This application divides the service architecture into three layers: system, service, and deployment. This forms the logical framework for deployment. Deployment, in particular, is based on the service framework code and uses matching resources to deploy in-vehicle service instances. The former is the architecture preparation stage for deployment, while the latter is the code execution stage based on the architecture framework. The two are connected to form the "architecture planning - code implementation" process for the dynamic deployment of in-vehicle services, jointly supporting deployment implementation.

[0109] Modeling is fundamental, defining the structure and interfaces of services. In SOA, modeling abstracts service components using standardized languages ​​(such as SysML) and templates (such as Arc42), encapsulating vehicle functions (such as speed monitoring or lane keeping) as uniquely identified services. This modeling approach not only clarifies service interfaces and dependencies but also supports layered design from basic service layers (such as signal abstraction) to business service layers (such as driving policies), providing a clear blueprint for subsequent deployment.

[0110] Layered deployment organizes service execution in a structured way. It maps service components defined in the modeling phase to hardware and software platforms, such as executing them in layers on domain controllers (e.g., XCUs): the basic service layer runs on the underlying operating system (e.g., POS SIX) and AUTOSAR Adaptive platform, providing general functionality; the business service layer is deployed based on the upper-layer application logic. This layered approach simplifies system integration, enables services to be developed and updated independently, and ensures interoperability through standardized interfaces.

[0111] Dynamic deployment leverages middleware to achieve flexible service management. Service middleware supports service publishing, subscription, and communication, allowing services to automatically discover and connect to each other at runtime based on demand, without modifying the underlying communication matrix. This mechanism means that when microservices are added, removed, or changed, only the subscription relationships of the relevant services need to be adjusted, rather than refactoring the entire system, thereby enhancing the system's adaptability and maintainability.

[0112] These three elements work together to support the full lifecycle management of vehicle services. Modeling provides a structured definition for layered deployment, which ensures the orderly execution of services on hardware resources, while dynamic deployment enables flexible scheduling of services through runtime management. For example, in autonomous driving scenarios, behavior-layer services (such as following strategies) and motion planning-layer services can interact dynamically through middleware. This integration allows vehicle functions to iterate rapidly and adapt to complex traffic environments.

[0113] The specific embodiments of this application have been described above. The application embodiments of this application will be further described below.

[0114] To address the issues of non-standard modeling, high coupling, and poor deployment flexibility in related technologies, this application provides a method for modeling and layered deployment of vehicle-mounted SOA services based on AUTOSAR-AP. Through standardized modeling, clear layering, and dynamic deployment strategies, it achieves improved development efficiency, reduced maintenance costs, and optimized resource utilization for vehicle-mounted systems.

[0115] like Figure 2 As shown, Figure 2 This is a flowchart illustrating the standardized modeling method provided in the application embodiment of this application. The flowchart shows the complete modeling process from requirements analysis to code generation.

[0116] The standardized modeling steps in this application include: Step S201: Requirements analysis phase, identify in-vehicle function requirements, such as air conditioning control, window adjustment, etc.

[0117] Step S202: Service identification stage, abstracting functional requirements into independent services, such as "air conditioning control service" and "window control service".

[0118] Step S203: Metamodel definition phase, use Soa ML to define the core elements of the service and set a unique service ID (e.g., 0x1001).

[0119] Step S204: Interface type definition phase, determine the service interface type: Event type: such as "external temperature change event", the trigger threshold is a temperature change ≥1℃. Method type: such as "set air conditioner temperature", response time threshold ≤ 100ms Field type: such as "window status", update frequency threshold ≥ 10Hz In particular, the interface type definition phase sets event trigger thresholds (such as temperature change ≥1℃) and method response thresholds (critical control ≤50ms) specifically for vehicle scenarios to ensure that the modeling results meet the real-time requirements of vehicle applications.

[0120] Step S205: Service role allocation stage, determine the service provider (such as air conditioning ECU) and the consumer (such as central control screen).

[0121] Step S206: Visual modeling stage, use the iDesigner tool to generate a service architecture diagram.

[0122] Step S207: Model verification stage, check interface compatibility and role allocation rationality.

[0123] Step S208: Code generation stage, automatically generate service framework code.

[0124] Steps S201-S208 correspond to steps 410-470 above. This application improves development efficiency through the standardized modeling process described above: standardized modeling and automatic code generation shorten the development cycle by 40%, increase module reusability by 50%, and reduce repetitive development work.

[0125] like Figure 3 As shown, Figure 3 This is a schematic diagram of the hierarchical structure provided in the application embodiment of this application. This application divides the vehicle SOA system into a three-layer architecture: system layer 301, service layer 302 and deployment layer 303. Each layer follows the principle of high cohesion and low coupling to achieve cross-layer decoupling and service reuse.

[0126] like Figure 4 As shown, Figure 4 This is a schematic diagram of the system layering structure provided in the application embodiment of this application. The system layering 301 of this application includes: Vehicle Application Layer 3011: Contains specific business applications, such as smart cockpit, autonomous driving, and body control, which are implemented through platform service layer interface calls.

[0127] Platform Service Layer 3012: Provides general service capabilities, such as: basic services: logging, diagnostics, resource management, etc.; communication services: encapsulation of communication protocols such as SOME / IP and DDS; security services: encryption, authentication, and access control. The communication service module of the platform service layer encapsulates the SOME / IP protocol and sets a throughput threshold of ≥1000msg / s.

[0128] Device Abstraction Layer 3013: Abstracts hardware and shields hardware differences. For example, sensor abstraction: unifies sensor data interfaces, such as temperature sensor data accuracy being uniformly 0.1℃; actuator abstraction: unifies actuator control interfaces, such as window control speed threshold being 5cm / s; communication interface abstraction: unifies hardware communication interfaces, such as CAN bus baud rate automatic adaptation; among them, the sensor abstraction module of the device abstraction layer unifies data accuracy (such as temperature ≤0.5℃ error) to ensure standardized cross-layer interaction.

[0129] Hardware layer 3014: Contains in-vehicle hardware entities, such as MCUs, sensors, actuators, etc.

[0130] like Figure 5 As shown, Figure 5 This is a schematic diagram of the service layer structure provided in the application embodiment of this application. The service layer 302 of this application includes: Application Service 3021: Specific business scenario services, such as "smart air conditioner scenario service", with a response time threshold of ≤200ms; the scenario service of the application service layer has a response threshold of ≤200ms.

[0131] Domain Core Service 3022: General services for specific domains, such as "Cockpit Domain Display Service", with a refresh rate threshold of ≥30Hz.

[0132] Platform core service 3023: Provides cross-domain general services, such as "SOME / IP communication service", with a throughput threshold of ≥1000msg / s; the communication service of the platform core service layer has a latency threshold of ≤10ms.

[0133] Hardware Abstraction Service 3024: Directly encapsulates hardware functions, such as "temperature sensor reading service," with a sampling frequency threshold of 10Hz; the sensor service in the Hardware Abstraction Service layer also has a sampling frequency threshold of 10Hz. Through this layered structure, a complete quality of service assurance system is formed.

[0134] In this application, a cross-layer decoupling mechanism is implemented at each level: each layer interacts through standardized interfaces, allowing only upper layers to call lower layer interfaces, and lower layers do not depend on upper layers. Cross-layer interface thresholds are defined as follows: inter-layer data transmission latency ≤ 5ms, cross-layer call failure rate ≤ 0.1%, and inter-layer data consistency assurance time ≤ 10ms.

[0135] The aforementioned hierarchical structure is the same as steps 510-520 above.

[0136] Through the layering described above in this application, maintenance costs can be reduced: the clear layered architecture reduces module coupling by 35%, shortens fault location time by 60%, and reduces system maintenance costs by 30%.

[0137] like Figure 6 As shown, Figure 6 This is a flowchart illustrating the dynamic deployment process provided in the application embodiment of this application. The sequence diagram shows the complete service deployment process. When the Machine resource utilization exceeds a threshold, a resource optimization strategy is triggered. Through service migration or dynamic resource allocation, the system resource utilization is ensured to remain within a reasonable range (≤80%). The dynamic deployment strategy of this application can be applied to vehicles. The vehicle system can establish an in-vehicle service-oriented architecture (SOA) based on AUTOSAR-AP (Adaptive AUTOSAR). The vehicle system includes: a service management module, a resource monitoring module, a Machine manager, and a Machine (same as the computing resource entity above). The dynamic deployment steps corresponding to this application include: Step S601: The service management module queries the resource monitoring module for available Machines. This step is the same as step 210 above.

[0138] Step S602: The resource monitoring module retrieves the Machine list from the Machine Manager, the Machine Manager returns the Machine resource status, and the resource monitoring module returns the list of available Machines to the service management module. This step is the same as step 220 above.

[0139] Step S603: The service management module initiates a service deployment request. The service deployment request is in a pending deployment state and has not yet been actually deployed.

[0140] Step S604: The Machine Manager sends a check to the Machine to check resource availability.

[0141] Step S605: Machine returns the resource check results to Machine Manager.

[0142] Steps S604-S605 are the same as step 230 above.

[0143] Step S606: Machine Manager begins deploying service instances. This step is the same as step 110 above, which begins acquiring and deploying in-vehicle service instances.

[0144] Step S607: Machine begins initializing services and deployment completion notification. This step corresponds to steps 120-140 above, that is, the matching resources are obtained through Machine and the corresponding deployment is completed.

[0145] Step S608: After successful deployment, a deployment success response will be sent.

[0146] Step S609: If resources are insufficient, a deployment failure response will be triggered. At this time, the service management module will trigger a resource optimization strategy.

[0147] The deployment strategy thresholds in this application are as follows: Machine resource utilization threshold: CPU ≤ 80%, memory ≤ 70%; Service deployment response time threshold: ≤ 100ms; Service discovery latency threshold: ≤ 50ms. The dynamic adjustment mechanism of this application triggers service redeployment when the following conditions are detected: Machine resource utilization exceeds the threshold for 10 seconds; service response time exceeds the threshold 5 times consecutively; hardware failure causes service unavailability. This step is equivalent to steps 150-170 above.

[0148] In the dynamic deployment of this application, the "dynamic" aspect based on the AUTOSAR-AP Machine is fundamentally about breaking through the limitations of traditional static binding by using the Machine as a logical entity for software deployment. This allows for runtime adaptive binding and dynamic optimization adjustments. While the Machine itself does possess the ability to bind services to hardware, traditional usage often involves "fixed binding" preset during the development phase. The "dynamic" aspect of this invention adds a core mechanism of "real-time adaptation and flexible adjustment" to this foundation. This can be understood from three perspectives: Dynamic establishment of binding relationships: The mapping between service instances and machines is not fixed during development, but is automatically completed at runtime. When a service starts, the system automatically matches a machine that meets the resource requirements (such as CPU, memory, supported protocols) through the service discovery mechanism (latency threshold ≤ 50ms), without the need for manual pre-configuration of binding relationships. For example, when the "Air Conditioning Control Service" starts, it will automatically identify whether the machine corresponding to the current cockpit MCU has idle resources (CPU ≤ 80%, memory ≤ 70%). If so, a binding is established in real time; otherwise, other available machines (such as backup processors) are matched.

[0149] Dynamic adjustment of binding relationships: During operation, the system monitors the resource utilization of the Machine in real time through the resource monitoring unit. When preset conditions are triggered, it will proactively break the original binding and redeploy services. For example, if the CPU utilization of a certain Machine exceeds 80% for 10 seconds, or the service response time exceeds the threshold 5 times consecutively, the system will initiate a redeployment strategy to migrate some services on that Machine to other Machines with sufficient resources, ensuring overall resource balance and service performance meeting standards. This "on-demand adjustment" is a core capability that traditional static binding (which cannot be changed after binding) does not possess.

[0150] Dynamic cross-hardware adaptation: As a virtualized ECU concept, a machine can be mapped to different physical processors (MCU, MPU, virtual machine), and "dynamic" means that services can be seamlessly migrated between different machines, shielding the differences in hardware heterogeneity. For example, the "environmental perception service" in the autonomous driving domain is initially deployed on the machine corresponding to the AI ​​chip. When the chip temperature exceeds 85°C, the system will trigger a frequency reduction or migration strategy to dynamically bind the service to other machines that meet the computing power requirements, ensuring hardware safety without interrupting service operation.

[0151] The Machine in this application is the "logical carrier" for service deployment, and its binding function is the basis for dynamic deployment. The "dynamic" aspect of this invention is that, on this carrier, through "real-time resource monitoring, triggered redeployment, and automatic service discovery," the binding between services and the Machine changes from "fixed during development" to "adaptive at runtime," ultimately achieving the goals of optimized resource utilization, self-healing of faults, and load balancing.

[0152] Through the dynamic deployment of this application, hardware utilization can be increased from 40% to 65%, supporting rapid functional iteration and hardware upgrades.

[0153] The key focus of this application is the machine-based dynamic deployment, which forms the "core of the value loop" of the entire technical solution. The first two parts (Soa ML modeling and three-layer architecture) are the "basic guarantees," while dynamic deployment is the "key to breaking through existing technical bottlenecks and achieving core benefits," and it is also the most fundamental innovation that distinguishes it from traditional automotive SOA architectures. Among the three major pain points of existing technologies addressed in this application, "insufficient service deployment flexibility (static deployment)" is the most critical bottleneck. This shortcoming corresponds to a traditional architecture with a hardware resource utilization rate of only 40%, which cannot adapt to the heterogeneity of automotive hardware (such as MCU / MPU hybrid architecture) and dynamic scenarios (such as high load in autonomous driving and hardware failures).

[0154] Two parts (Soa ML modeling and three-tier architecture) address the "internal standardization issue": Soa ML modeling addresses the "lack of standardized service descriptions and incompatibility with in-vehicle real-time requirements," while the three-tier architecture addresses the "ambiguous layering and high coupling"—essentially, "standardization and decoupling at the software level," belonging to "infrastructure." Dynamic deployment addresses the "practical value issue": through the AUTOSAR-AP Machine concept, a dynamic mapping between services and hardware is established, directly breaking through the limitations of "static deployment," allowing standardized services and a clear layered architecture to truly translate into practical benefits such as "resource optimization, scenario adaptation, and improved stability."

[0155] This application is based on SoaML for customized in-vehicle modeling: it is an "extension of general modeling languages ​​to in-vehicle scenarios" (such as adding event trigger thresholds and response time requirements), which belongs to "optimization innovation" and is essentially "standardization adaptation"; A clear three-tier system architecture is "a clarification and threshold definition of the existing layered thinking" (such as inter-layer latency ≤ 5ms), and also "optimization-oriented innovation," which is essentially "structural decoupling." Machine-based dynamic deployment: It is "using the core concept of AUTOSAR-AP (Machine) to achieve dynamic collaboration between software and hardware", which is a "breakthrough innovation" - for the first time, "virtualized logical entity (Machine)" is bound with "vehicle hardware resources" to establish a dynamic adjustment mechanism (such as resource exceeding threshold triggering redeployment, hardware failure migration service). The technical barrier is higher, and it is a "closed-loop solution" that does not exist in the existing technology.

[0156] The solution described in this application improves hardware resource utilization from 40% to 65% (dynamic scheduling optimizes resource allocation); enhances system flexibility (supports rapid function iteration and hardware upgrade adaptation); maintains 99.9% stability in abnormal scenarios (triggers redeployment / frequency reduction under high temperature and high load); and achieves service deployment response time ≤100ms (meets the real-time requirements of automotive applications). These benefits are the core indicators that customers (automakers) care about most—compared to "improved development efficiency and reduced maintenance costs" (the main benefits of the first two innovations), "resource utilization, flexible adaptation, and stability" are the "core competitiveness" for the implementation of automotive SOA.

[0157] The above describes the application embodiments of this application. The following is a detailed description of the vehicle service.

[0158] Taking intelligent cockpit domain service modeling and deployment as an example: The first step is the service modeling process: Requirements analysis: Identify the requirements for the smart cockpit domain, including air conditioning control, seat adjustment, ambient lighting control, etc.

[0159] Service identification: Abstract the "Air conditioning control service", "seat adjustment service", and "ambient lighting control service".

[0160] SoaML metamodel definition: Service ID setting: Air conditioning control service is 0x1001, Interface definition: Event: "Outside temperature change event", trigger threshold 1℃; Method: "Set air conditioning temperature", response threshold 100ms; Field: "Seat position", update frequency 5Hz.

[0161] Visual modeling: Use the iDesigner tool to generate service architecture diagrams, such as... Figure 7 As shown. Figure 7 This is a diagram of the intelligent cockpit domain service architecture. Visual modeling shows that the intelligent cockpit domain services in this application are divided into air conditioning control service, seat adjustment service, and ambient lighting control service. Specifically, the air conditioning control service includes outside temperature events, temperature setting methods, and air conditioning status fields; the seat adjustment service and ambient lighting control service include seat position events, seat adjustment methods, and seat status fields; and the ambient lighting control service includes ambient lighting color events, color setting methods, and ambient lighting status fields.

[0162] Through the above modeling process, the reuse rate of the intelligent cockpit domain service modeling module can be increased by 50%, reducing the amount of repetitive development work.

[0163] The second step is the layered deployment process: System layered deployment: Application layer: intelligent cockpit scenario applications; Platform service layer: communication services (SOME / IP, latency ≤10ms); Device abstraction layer: air conditioning controller abstraction, seat controller abstraction.

[0164] Service layering mapping: Hardware abstraction service: air conditioning sensor service (sampling frequency 10Hz), platform core service: cockpit communication service (throughput 1000msg / s), domain core service: cockpit control service (response ≤150ms), application service: intelligent cockpit scenario service (response ≤200ms).

[0165] Machine Deployment: Machine Configuration: CPU threshold 80%, memory threshold 70%, Service Instance and Hardware Mapping: Air Conditioning Control Service deployed to Cockpit MCU, Seat Adjustment Service deployed to Body Controller, Dynamic Adjustment: When the Cockpit MCU utilization exceeds 80% for 10 seconds, the service is triggered to migrate to the standby processor.

[0166] Through the above modeling and deployment, the intelligent cockpit domain service offers high deployment flexibility, allowing for real-time allocation based on actual computing resources. It also facilitates maintenance, improves resource utilization, and avoids the waste of idle resources.

[0167] The following example demonstrates the modeling and deployment of autonomous driving domain services: The first step is the service modeling process: Requirements analysis: Identify the requirements for autonomous driving, including environmental perception, path planning, and vehicle control.

[0168] Service identification: Abstract the "environmental perception service", "path planning service", and "vehicle control service".

[0169] Soa ML metamodel definition: Service ID: Environment Awareness Service is 0x2001; Interface definition: Event: "Obstacle Detection Event", trigger threshold distance ≤100m; Method: "Path Planning Calculation", response threshold 50ms; Field: "Vehicle Speed", update frequency 20Hz.

[0170] Visual modeling: Use the iDesigner tool to generate service architecture diagrams, such as... Figure 8 As shown. Figure 8This is an architecture diagram of the autonomous driving domain services. Visual modeling shows that the autonomous driving domain services in this application are divided into environmental perception services, path planning services, and vehicle control services. The environmental perception service includes obstacle detection events, environmental data acquisition methods, and sensor status fields; the path planning service includes path update events, path planning methods, and planning status fields; and the vehicle control service includes control command events, control execution methods, and control status fields.

[0171] The second step is the layered deployment process: System layered deployment: Application layer: autonomous driving scenario applications; Platform service layer: security services (encryption latency ≤5ms); Device abstraction layer: radar sensor abstraction, camera abstraction.

[0172] Service layering mapping: Hardware abstraction service: Radar sampling service (frequency 10Hz); Platform core service: Secure communication service (encryption strength AES-256); Domain core service: Autonomous driving control service (response ≤30ms); Application service: Automatic parking scenario service (response ≤100ms).

[0173] Machine Deployment: Machine Configuration: CPU threshold 75%, memory threshold 65%; Service Instance and Hardware Mapping: Environmental perception service is deployed to the AI ​​chip, and vehicle control service is deployed to the safety MCU; Dynamic Adjustment: When the AI ​​chip temperature exceeds 85℃, a service frequency reduction strategy is triggered to ensure system stability. Through the above modeling and deployment, the deployment of autonomous driving domain services is highly flexible, and can be allocated in real time according to actual computing resources. It is also conducive to maintenance, improves resource utilization, and avoids the waste of idle resources.

[0174] Through the above modeling and deployment, the autonomous driving domain service has high deployment flexibility, can be allocated in real time according to actual computing resources, and is also conducive to maintenance, improving resource utilization and avoiding waste of idle resources.

[0175] In summary, the embodiments of this application improve development efficiency: standardized modeling and automatic code generation shorten the development cycle by 40%, increase module reusability by 50%, and reduce repetitive development workload. Maintenance costs are reduced: a clear layered architecture reduces module coupling by 35%, shortens fault location time by 60%, and lowers system maintenance costs by 30%. System flexibility is enhanced: dynamic deployment strategies support dynamic adjustment of hardware resources, increasing hardware utilization from 40% to 65%, and supporting rapid feature iteration and hardware upgrades. Real-time performance is guaranteed: defining response thresholds for each layer of services improves the response speed of critical control services by 15%, meeting the real-time requirements of automotive applications. Security is improved: the combination of layered architecture and dynamic deployment enables the system to achieve ASIL-D security, meeting the high-safety requirements of scenarios such as autonomous driving.

[0176] The following describes the vehicle-mounted service dynamic deployment device provided in this application. The vehicle-mounted service dynamic deployment device described below and the vehicle-mounted service dynamic deployment method described above can be referred to in correspondence.

[0177] Secondly, this application also provides a vehicle-mounted service dynamic deployment device. Figure 9 This is a structural schematic diagram of the vehicle-mounted service dynamic deployment device provided in an embodiment of this application. (Refer to...) Figure 9 The vehicle-mounted service dynamic deployment device provided in this application embodiment includes: The first acquisition module 910 is used to acquire vehicle service instances; The second acquisition module 920 is used to acquire matching resources from the computing resource entity in real time when the vehicle service instance starts. Binding module 930 is used to bind matching resources to vehicle service instances; Deployment module 940 is used to deploy in-vehicle service instances using matching resources.

[0178] The vehicle service dynamic deployment device provided in this application dynamically and in real time obtains matching resources from the computing resource entity when the vehicle service instance is started, and uses the matching resources to deploy the vehicle service instance. Therefore, this application has strong flexibility in the deployment of vehicle services, can allocate resources in real time according to actual computing resources, and is also conducive to maintenance. At the same time, the method of this application can effectively improve resource utilization and avoid the waste of some idle resources.

[0179] Specifically, the vehicle service dynamic deployment device provided in this application embodiment can implement all the method steps implemented in the above method embodiment and can achieve the same technical effect. Here, the parts that are the same as those in the method embodiment and the beneficial effects will not be described in detail.

[0180] Figure 10 This is a schematic diagram of the structure of the electronic device provided in an embodiment of this application. For example... Figure 10 As shown, the electronic device may include: a processor 1010, a communications interface 1020, a memory 1030, and a communication bus 1040, wherein the processor 1010, the communications interface 1020, and the memory 1030 communicate with each other via the communication bus 1040. The processor 1010 can call logical instructions in the memory 1030 to execute a dynamic deployment method for in-vehicle services, such as including: Obtain an in-vehicle service instance; When the vehicle service instance starts, it obtains matching resources from the computing resource entity in real time; Bind the matching resources to the vehicle service instance; Deploy in-vehicle service instances using matching resources.

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

[0182] On the other hand, this application also provides a non-transitory computer-readable storage medium storing a computer program thereon, which, when executed by a processor, implements the steps of the on-board service dynamic deployment method provided by the above methods, including, for example: Obtain an in-vehicle service instance; When the vehicle service instance starts, it obtains matching resources from the computing resource entity in real time; Bind the matching resources to the vehicle service instance; Deploy in-vehicle service instances using matching resources.

[0183] Furthermore, this application also provides a computer program product, which includes a computer program that can be stored on a non-transitory computer-readable storage medium. When the computer program is executed by a processor, the computer is able to perform the steps of the vehicle service dynamic deployment method provided by the above methods, such as including: Obtain an in-vehicle service instance; When the vehicle service instance starts, it obtains matching resources from the computing resource entity in real time; Bind the matching resources to the vehicle service instance; Deploy in-vehicle service instances using matching resources.

[0184] The device embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs. Those skilled in the art can understand and implement this without any creative effort.

[0185] Through the above description of the embodiments, those skilled in the art can clearly understand that each embodiment can be implemented by means of software plus necessary general-purpose hardware platforms, and of course, it can also be implemented by hardware. Based on this understanding, the above technical solutions, in essence or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product can be stored in a computer-readable storage medium, such as ROM / RAM, magnetic disk, optical disk, etc., and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute the methods described in the various embodiments or some parts of the embodiments.

[0186] It should also be noted that the terms "first," "second," etc., used in the embodiments of this application are used to distinguish similar objects, and are not used to describe a specific order or sequence. It should be understood that such terms can be used interchangeably where appropriate so that embodiments of this application can be implemented in orders other than those illustrated or described herein, and the objects distinguished by "first" and "second" are generally of the same class, and the number of objects is not limited. For example, the first object can be one or more.

[0187] In the embodiments of this application, the term "and / or" describes the relationship between associated objects, indicating that three relationships can exist. For example, A and / or B can represent three cases: A alone, A and B simultaneously, and B alone. The character " / " generally indicates that the preceding and following associated objects have an "or" relationship.

[0188] In this application's embodiments, "determine B based on A" means that factor A must be considered when determining B. It is not limited to "B can be determined based solely on A," but should also include: "determine B based on A and C," "determine B based on A, C, and E," "determine C based on A, and further determine B based on C," etc. Additionally, it can include using A as a condition for determining B, for example, "when A meets the first condition, determine B using the first method"; another example, "when A meets the second condition, determine B," etc.; another example, "when A meets the third condition, determine B based on the first parameter," etc. Of course, it can also be a condition where A is a factor in determining B, for example, "when A meets the first condition, determine C using the first method, and further determine B based on C," etc.

[0189] In the embodiments of this application, the term "multiple" refers to two or more, and other quantifiers are similar.

[0190] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application.

Claims

1. A method for dynamically deploying in-vehicle services, characterized in that, For use in a vehicle, the vehicle employing an automotive open system architecture platform, the automotive open system architecture platform including a computing resource entity, the computing resource entity being used to describe the environment for software deployment and execution, the method comprising: Obtain an in-vehicle service instance; When the vehicle service instance starts, it obtains matching resources from the computing resource entity in real time; Bind the matching resource to the vehicle service instance; The in-vehicle service instance is deployed using the matching resources.

2. The method for dynamic deployment of vehicle-mounted services according to claim 1, characterized in that, The method further includes: Query available resources from the computing resource entity; Get a list of available resources; Check the available resources in the available resource list and return the resource check results; When the resource check result indicates that the resource is satisfied, obtaining the matching resource from the computing resource entity includes: Retrieve matching resources from the list of available resources.

3. The method for dynamic deployment of vehicle-mounted services according to claim 1, characterized in that, The real-time acquisition of matching resources from the computing resource entity includes: Obtain the component corresponding to the in-vehicle service instance; The resource corresponding to the component is parsed from the computing resource entity; If the resource corresponding to the component is idle, then the resource corresponding to the component will be used as the matching resource. If the resource corresponding to the element is not idle, then other idle resources are selected from the computing resource entities as the matching resource.

4. The method for dynamic deployment of vehicle-mounted services according to claim 3, characterized in that, The step of using the resource corresponding to the element as the matching resource if the resource corresponding to the element is idle includes: Obtain the processor utilization and memory utilization of the resources corresponding to the component; If the processor utilization rate is less than or equal to the first threshold and the memory utilization rate is less than or equal to the second threshold, then the resource corresponding to the component is idle, and the component resource is used as the matching resource.

5. The method for dynamic deployment of vehicle-mounted services according to claim 1, characterized in that, After deploying the in-vehicle service instance using the matching resources, the process also includes: Real-time acquisition of the service response time, processor utilization, and memory utilization of the matched resources; When the service response time exceeds the time threshold N times consecutively, or the processor utilization rate is continuously greater than the first threshold for more than M seconds, or the memory utilization rate is continuously greater than the second threshold for more than L seconds, the matching resource will be unbound from the vehicle service instance. Re-obtain updated matching resources from the computing resource entity, and deploy the in-vehicle service instance using the updated matching resources; Wherein, M, N and L are all positive integers greater than 1.

6. The method for dynamic deployment of vehicle-mounted services according to claim 1, characterized in that, The method further includes: Obtain the vehicle function requirements, which include the functions in the vehicle service instance; Transform the aforementioned in-vehicle function requirements into in-vehicle services; The core elements of the in-vehicle service are defined using a modeling language and a unique identifier is set. The core elements include at least: service, service provider, service consumer and service port. Define the interface type of the vehicle service, wherein the interface type includes events, methods, and fields; Confirm the service role of the in-vehicle service; Generate service architecture diagrams using visual modeling tools; The service framework code is generated based on the unique identifier, the interface type, the service role, and the service architecture diagram.

7. The method for dynamic deployment of vehicle-mounted services according to claim 6, characterized in that, The deployment of the in-vehicle service instance using the matching resources includes: The in-vehicle service instance is deployed using the matching resources based on the service framework code.

8. The method for dynamic deployment of vehicle services according to claim 1, characterized in that, The method further includes: Obtain the current service-oriented architecture of the vehicle; The service-oriented architecture is divided into system layering, service layering, and deployment layering to obtain the layered architecture. The system layering includes the vehicle application layer, platform service layer, device abstraction layer, and hardware layer. The service layering includes the hardware abstraction service layer, platform core service layer, domain core service layer, and application service layer. The deployment of the in-vehicle service instance using the matching resources includes: The in-vehicle service instance is deployed using the matching resources based on the layered architecture.

9. A vehicle-mounted service dynamic deployment device, characterized in that, include: The first acquisition module is used to acquire in-vehicle service instances; The second acquisition module is used to acquire matching resources from the computing resource entity in real time when the vehicle service instance starts. A binding module is used to bind the matching resource to the vehicle service instance; The deployment module is used to deploy the vehicle service instance using the matching resources.

10. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the computer program, it implements the in-vehicle service dynamic deployment method as described in any one of claims 1 to 8.

Images