A vehicle service control method and device, vehicle, equipment and storage medium
By acquiring and processing the control attribute information of the target control request and rationally arranging the service call order, the problem of chaotic service call order in the automotive industry is solved, the security and reliability of the system are improved, and the rational and orderly calling and maximization of service functions are realized.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- Filing Date
- 2020-09-25
- Publication Date
- 2026-04-14
AI Technical Summary
In existing technologies, the order of car service calls is chaotic, leading to security risks and the inability to maximize resource utilization. This is especially true when multiple applications call the same service simultaneously, as the service call order cannot be handled reasonably and orderly.
By obtaining the control attribute information of the target control request, the status information of the target service is determined, and the permission information of the target application is extracted. The service call order is arranged reasonably, and the permission information of competing applications is processed by the unified resource management layer. When the preset priority service conditions are met, the service status is updated and the control request is forwarded.
This enables the rational and orderly invocation of vehicle services, improves the security and reliability of the system, avoids the chaos and security risks when multiple programs call the same service function at the same time, and maximizes the utilization of the service functions provided by the vehicle.
Smart Images

Figure CN116034574B_ABST
Abstract
Description
Technical Field
[0001] This application relates to the fields of automotive electronic architecture and vehicle network technology, specifically to a vehicle service control method, device, vehicle, equipment, and storage medium. Background Technology
[0002] With the rapid development of automotive Ethernet communication technology in recent years, applications such as intelligent driving, OTA (Over-The-Air), and entertainment are becoming increasingly diverse. Service-Oriented Architecture (SOA) is gaining popularity. SOA transforms automotive resources (various sensors and controllers) into services, which can then be accessed by different applications, maximizing resource utilization and diversifying applications to provide users with a richer experience. After being transformed into services, automotive resources are not fixed to a single application; instead, different applications can access the services provided by the vehicle based on their specific functionalities. As the number of applications increases, multiple applications may access the same automotive service (for example, two applications may need to access sunroof control).
[0003] Existing technologies primarily utilize the SOME / IP protocol to implement function-to-service conversion, which is complex and requires serialization and deserialization. When different applications call the same service, later services directly overwrite earlier ones, and the caller of the earlier service is unaware that its execution result has been overwritten by other applications. This chaotic and unreasonable service call order may lead to security risks and fails to maximize the utilization of the services provided by the vehicle. Therefore, a more efficient solution is needed. Summary of the Invention
[0004] To address the problems of the prior art, this application provides a vehicle service control method, apparatus, vehicle, equipment, and storage medium. The technical solution is as follows:
[0005] This application provides a vehicle service control method, the method comprising:
[0006] Obtain the target control request, wherein the target control request carries control attribute information of the target service;
[0007] The status information of the target service is determined based on the control attribute information;
[0008] When it is determined that the status information of the target service includes being occupied, the permission information of the target application is extracted from the control attribute information, and the target application includes the application corresponding to the target control request;
[0009] The permission information of competing applications is determined based on the aforementioned control attribute information;
[0010] When the permission information of the target application and the permission information of the competing application meet the preset priority service conditions, the status information of the target service is updated based on the control attribute information, and the target control request is forwarded to the corresponding controller to realize the corresponding vehicle function control.
[0011] Another aspect of this application provides a vehicle service control device, the device comprising:
[0012] The target control request acquisition module is used to acquire the target control request, which carries the control attribute information of the target service;
[0013] The status information acquisition module is used to determine the status information of the target service based on the control attribute information;
[0014] The first permission information determination module is used to extract permission information of the target application from the control attribute information when it is determined that the status information of the target service includes being occupied. The target application includes the application corresponding to the target control request.
[0015] The second permission information determination module is used to determine the permission information of competing applications based on the control attribute information;
[0016] The service preemption module is used to update the status information of the target service based on the control attribute information and forward the target control request to the corresponding controller to realize the corresponding vehicle function control when the permission information of the target application and the permission information of the competing application meet the preset priority service conditions.
[0017] This application also provides a vehicle, characterized in that the vehicle includes the aforementioned vehicle service control device.
[0018] In another aspect, this application provides an apparatus comprising a processor and a memory, wherein the memory stores at least one instruction or at least one program, the at least one instruction or the at least one program being loaded and executed by the processor to implement the vehicle service control method.
[0019] In another aspect, this application provides a computer-readable storage medium storing at least one instruction or at least one program segment, which is loaded and executed by a processor to implement the vehicle service control method.
[0020] The vehicle service control method, device, vehicle, equipment, and storage medium provided in this application have the following technical advantages:
[0021] This application determines the status information of a target service by utilizing the control attribute information carried in the target control request. When the status information of the target service indicates that it is occupied, the permission information of the target application is extracted from the control attribute information. That is, when it is determined that there is service competition and it is necessary to call a service that is being used by another application, the permission information of the target application is further determined, and the permission information of the competing application is determined based on the control attribute information. This is reasonable and orderly, which helps to improve reliability. When the permission information of the target application and the permission information of the competing application meet the preset priority service conditions, the status information of the target service is updated based on the control attribute information, and the target control request is forwarded to the corresponding controller to realize the corresponding vehicle function control. This helps to maximize the utilization of the service functions provided by the vehicle and can avoid the chaos and security risks caused by multiple programs calling the same service function at the same time. This is reasonable and orderly, which improves security and reliability.
[0022] Additional aspects and advantages of this application will be set forth in part in the description which follows, and in part will be obvious from the description, or may be learned by practice of this application. Attached Figure Description
[0023] To more clearly illustrate the technical solutions and advantages in the embodiments of 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 only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.
[0024] Figure 1 This is a schematic diagram of an application environment for the vehicle service control method provided in the embodiments of this application;
[0025] Figure 2 This is a schematic diagram of a hardware structure for implementing a vehicle service control method according to an embodiment of this application.
[0026] Figure 3 This is a flowchart of a vehicle service control method provided in an embodiment of this application;
[0027] Figure 4 This is a flowchart of another vehicle service control method provided in the embodiments of this application;
[0028] Figure 5 This is a flowchart of another vehicle service control method provided in the embodiments of this application;
[0029] Figure 6 This is a flowchart of another vehicle service control method provided in the embodiments of this application;
[0030] Figure 7 This is a flowchart of another vehicle service control method provided in the embodiments of this application;
[0031] Figure 8 This is a flowchart of another vehicle service control method provided in the embodiments of this application;
[0032] Figure 9 This is a flowchart of another vehicle service control method provided in the embodiments of this application;
[0033] Figure 10 This is a flowchart of another vehicle service control method provided in the embodiments of this application;
[0034] Figure 11 This is a schematic diagram of a vehicle service control device provided in an embodiment of this application;
[0035] Figure 12 This is a hardware structure block diagram of a server for implementing a vehicle service control method provided in an embodiment of this application. Detailed Implementation
[0036] The technical solutions of the embodiments 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, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the scope of protection of this application. Examples of the embodiments are shown in the accompanying drawings, wherein the same or similar reference numerals denote the same or similar elements or elements having the same or similar functions throughout.
[0037] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of this application described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or server that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or devices.
[0038] Please see Figure 1 , Figure 1 This is a schematic diagram of an application environment for the vehicle service control method provided in this application embodiment, such as... Figure 1As shown, the application environment for vehicle service control in this application may include on-board sensors and on-board controller 100, data transfer unit 200 and data processing unit 300.
[0039] In the embodiments of this specification, the vehicle-mounted sensors and the vehicle-mounted controller 100 can be electrically connected to the data transfer unit 200 via different types of buses. The vehicle-mounted sensors can acquire corresponding sensor data, and the vehicle-mounted controller can implement corresponding vehicle function control based on target control requests, as well as generate corresponding control data. In practical applications, the vehicle-mounted sensors may include, but are not limited to, rain sensors for monitoring rainfall, smoke sensors for monitoring smoke concentration, cameras for monitoring video, images, and distance information, millimeter-wave radar, lidar, and ultrasonic radar. In some embodiments, the vehicle-mounted sensors may also include light sensors, motion sensors, and other sensors capable of acquiring vehicle speed, acceleration, deceleration, and seatbelt status. In practical applications, the vehicle-mounted sensors may also include gyroscopes, temperature and humidity sensors, and infrared sensors, etc., which will not be elaborated further here. In practical applications, the vehicle-mounted controller may include, but is not limited to, window controllers (including window controllers on the left and right sides of the vehicle and sunroof controllers), door controllers, volume controllers, air conditioning controllers, and air purification system controllers.
[0040] In the embodiments of this specification, the data transfer unit 200 can be electrically connected to the vehicle sensors and vehicle controller 100 via different types of buses, thereby communicating with the vehicle sensors and vehicle controller 100. The data transfer unit 200 can be used to acquire data from the vehicle sensors and vehicle controller 100, perform data parsing and data format conversion, and send the converted data to the data processing unit 300. The data transfer unit 200 can also be used to receive target control requests sent by the data processing unit 300 and forward them to the corresponding vehicle sensors and vehicle controller 100 to achieve corresponding vehicle function control, etc. In the embodiments of this specification, the data transfer unit 200 may include an eth (Ethereum) communication interface, a CAN communication interface, a LIN communication interface, and corresponding communication interface drivers. In practical applications, the data transfer unit 200 may include, but is not limited to, an MCU (Microcontroller Unit). The data processing unit 300 may include, but is not limited to, an ARM (Advanced RISC Machines) controller. For specific embodiments, please refer to... Figure 2 , Figure 2This is a schematic diagram of a hardware structure for implementing a vehicle service control method according to an embodiment of this application. The on-board sensors and the on-board controller 100 can be electrically connected to the MCU via corresponding data channels 101, such as multiple CAN (Controller Area Network) channels, multiple LIN (Local Interconnect Network) channels, 100Mbps Ethernet channels, and 1Gbps Ethernet channels. Specifically, when the on-board sensors and the on-board controller 100 are electrically connected to the MCU via 100Mbps Ethernet channels and 1Gbps Ethernet channels, they can also be electrically connected to the MCU via an Ethernet switch and PHY (Physical Interface Transceiver) 102. The ARM controller can also be electrically connected to the Ethernet switch and PHY 102 to complete related data transmission.
[0041] In the embodiments of this specification, the data processing unit 300 may include at least one application 301, a service interface 302, and a unified resource management layer 303. Specifically, the application 301 may be used to respond to a function start command by sending permission acquisition requests, control requests, and receiving service call failure information, service occupation feedback information, and vehicle component operation data from the unified resource management layer 303, based on the corresponding service interface 302. In practical applications, the application 301 may include, but is not limited to, features such as: smoking mode, Bluetooth comfort call, window and sunroof external circulation linkage, automatic sunshade in high temperatures, automatic sunroof and window control in rainy weather, warm mode, no music playback, and vehicle navigation. In practical applications, by encapsulating the data and status of the vehicle sensors and the vehicle controller 100, as well as the executable actions of the vehicle controller, into a unified service interface 302, the application 301 only needs to call the corresponding service interface 302 to complete the corresponding operation during runtime, shielding the details of the vehicle network and data interaction, allowing the application to focus on its own logical functions and improving the development efficiency of the application. In the embodiments of this specification, the unified resource management layer 303 can be used to acquire a target control request, which carries control attribute information of a target service; determine the status information of the target service based on the control attribute information; when the status information of the target service includes being occupied, extract the permission information of the target application from the control attribute information, the target application including the application corresponding to the target control request; determine the permission information of competing applications based on the control attribute information; when the permission information of the target application and the permission information of competing applications meet preset priority service conditions, update the status information of the target service based on the control attribute information, and forward the target control request to the corresponding controller to realize the corresponding vehicle function control. Furthermore, the unified resource management layer 303 can also be used to monitor the operating data of vehicle components; upload the operating data of vehicle components to the corresponding shared memory domain; respond to a data read request sent by the target application 301, determine the operating data of the corresponding vehicle component from the shared memory domain corresponding to the data read request; and send the corresponding operating data of the vehicle component to the target application 301. Figure 1 As shown, the data transfer unit 200 and data processing unit 300 mentioned above can be installed on the central gateway 400.
[0042] In the embodiments described in this specification, Figure 2The hardware structure may further include a power supply module 500 and a memory 600. The power supply module 500 is used to supply power to the data transfer unit 200 and the data processing unit 300, and the memory 600 is used to provide the storage space required for the operation of the data processing unit 300. The power supply module 500 is electrically connected to the data transfer unit 200 and the data processing unit 300 respectively, and the memory 600 is electrically connected to the data processing unit 300.
[0043] In addition, it should be noted that, Figure 1 This is merely one embodiment of the application environment for the vehicle service control method provided in this specification. Figure 2 This is merely one embodiment of the hardware structure for implementing the vehicle service control method provided in this specification, and this application is not limited thereto.
[0044] Figure 3 This is a flowchart of a vehicle service control method provided in an embodiment of this application. Please refer to it. Figure 3 The vehicle service control method provided in the embodiments of this specification includes the following steps:
[0045] S301: The unified resource management layer obtains a target control request.
[0046] Specifically, the target control request carries control attribute information of the target service.
[0047] In the embodiments described in this specification, the target control request includes a control request sent by the corresponding target application to the unified resource management layer based on the corresponding service interface; the target service may include actions that the vehicle controller can perform, and in practical applications, the target service may include, but is not limited to, opening the sunroof, opening the door, turning on the air purification system, and turning on the vehicle air conditioning. The control attribute information of the target service may include the permission information of the target application, whether the target service needs to be locked, the duration of locking the target service, and the identification code of the target service.
[0048] like Figure 4 As shown, before the unified resource management layer obtains the target control request, the method may further include:
[0049] S401: At least one application sends a control request to the unified resource management layer based on the corresponding service interface.
[0050] In practical applications, this application may include, but is not limited to, features such as: smoking mode, Bluetooth comfort calling, window / sunroof external circulation linkage, automatic sunshade in high temperatures, automatic sunroof / window control in rainy weather, and a cozy mode. In the embodiments described in this specification, the data, status, and executable actions of the vehicle sensors and controllers are encapsulated as classes to generate a unified service interface. This unified service interface layer provides services to the application layer, thereby converting the functions or resources of all vehicle sensors and controllers into services. When developing the application, only class instantiation is required, resulting in good compatibility. This reduces the development difficulty of vehicle applications, improves development efficiency, and shortens the development cycle. During runtime, the application only needs to call the corresponding service interface to send control requests, shielding the details of the vehicle network and data interaction. This allows the application to focus on its own logical functions, improving the reliability of vehicle service control.
[0051] S403: The unified resource management layer sorts the control requests based on the time when they are received, and generates a control request queue.
[0052] In practical applications, control requests received earlier (correspondingly, those sent to the unified resource management layer earlier by the application) will be placed at the front of the control request queue. This means that the unified resource management layer can process the earlier-placed control requests first, which helps the unified resource management layer to process control requests in a reasonable and orderly manner and avoids confusion caused by multiple programs calling the same service function at the same time, thus avoiding a reduction in system performance.
[0053] like Figure 5 As shown in the embodiments of this specification, the acquisition of the target control request may include:
[0054] S501: The unified resource management layer obtains the control request queue.
[0055] S503: The unified resource management layer determines the first unprocessed control request in the control request queue, arranged in chronological order of control request reception time.
[0056] In the embodiments described in this specification, the first unprocessed control request is the control request that is ranked first in the control request queue (the control request with the earliest sending time / receiving time).
[0057] S505: The unified resource management layer uses the first unprocessed control request as the target control request.
[0058] By acquiring the control request queue through a unified resource management layer and processing the control requests in the queue sequentially according to time, it ensures that data written first is read first by the unified resource management layer. This guarantees that the execution order of control requests sent by multiple applications strictly follows the chronological order. This helps avoid confusion and performance degradation caused by multiple programs simultaneously calling the same service function, thus improving the reliability of vehicle service control.
[0059] S303: The unified resource management layer determines the status information of the target service based on the control attribute information.
[0060] Specifically, the control attribute information of the target service may include the identification code of the target service, and the identification code may be, but is not limited to, a string composed of at least one of letters, numbers, and special characters; the identification code can be used to distinguish different services; in the embodiments of this specification, the unified resource management layer can obtain the functions or executable actions of the vehicle controller and generate the status information of the target service. The status information of the target service may include the identification code of the target service, the value of the target service, the identification code of the application currently locking the target service (which can be used later to query which application is currently occupying the target service), the maximum lock time of the target service (how long the target service can be locked, the lock time of the target application must be less than the maximum lock time of the target service), and the remaining release time of the target service calculated using a timer. In practical applications, the identification code of the target service included in the control attribute information of the target service can be used to determine the status information of the corresponding target service.
[0061] S305: When the unified resource management layer determines that the status information of the target service includes being occupied, it extracts the permission information of the target application from the control attribute information.
[0062] Specifically, the target application includes the application corresponding to the target control request.
[0063] In the embodiments of this specification, when the unified resource management layer determines that the remaining release time of the target service is not 0, it indicates that the target service is currently occupied, that is, the status information of the target service includes being occupied. The unified resource management layer extracts the permission information of the target application from the control attribute information. Furthermore, in the embodiments of this specification, the permission information of the target application is pre-generated by the unified resource management layer based on the permission acquisition request sent by the target application. In a specific embodiment, the permission information of the target application may include a permission identifier code of the target application, and the permission identifier code may be, but is not limited to, a string composed of at least one of letters, numbers, and special characters. This permission identifier code can be used to distinguish different applications, and it contains information that indicates the application's permissions. For example, the permission information of a security-related application may include a permission identifier code with the highest bit set to 1, while the permission information of a non-security-related application may include a permission identifier code with the highest bit set to 0.
[0064] like Figure 6 As shown, before the unified resource management layer obtains the target control request, the method may further include:
[0065] S601: In response to a feature start command, the target application sends a permission request to the unified resource management layer.
[0066] Specifically, the permission request carries the attribute information of the target application and the initial permission identifier.
[0067] In the embodiments of this specification, the attribute information of the target application may include the name of the target application and the identification code of the target application, and the initial permission identifier may include a temporary identification code generated by the target application based on the file path.
[0068] S603: The unified resource management layer generates a permission request identifier for the target application based on the attribute information of the target application, and sends the permission request identifier to the target application.
[0069] In the embodiments described in this specification, the Unified Resource Management layer can parse the attribute information of the target application to determine whether the target application is a security-related application or a non-security-related application. When the Unified Resource Management layer determines that the target application is a security-related application, it can generate a permission identifier code with the highest bit set to 1 as the permission request identifier for the target application; when the Unified Resource Management layer determines that the target application is a non-security-related application, it can generate a permission identifier code with the highest bit set to 0 as the permission request identifier for the target application. In practical applications, the aforementioned security-related applications may include, but are not limited to, applications involving door control and driving control (e.g., one-touch door opening, automatic emergency braking, etc.); the aforementioned non-security-related applications may include, but are not limited to, applications related to the in-vehicle entertainment system (e.g., smoking mode, Bluetooth comfort calling, etc.).
[0070] S605: The target application modifies the initial permission identifier to the requested permission identifier, and uses the requested permission identifier as the permission information of the target application.
[0071] In the embodiments described in this specification, after receiving the request permission identifier sent by the unified resource management layer, the target application can modify its initial permission identifier to the request permission identifier and use it as the permission information of the target application. This facilitates the unified resource management layer in determining whether it can preempt the service in the event of subsequent competition. By having the unified resource management layer generate the request permission identifier of the target application based on its attribute information, and the target application use this request permission identifier as its permission information, it is beneficial to set different permissions according to the type of application (e.g., functional safety related or non-functional safety related), avoiding potential security risks when multiple applications need to call the same service, improving the security and reliability of vehicle service control, and making vehicle service control more orderly and reasonable.
[0072] S307: The unified resource management layer determines the permission information of competing applications based on the control attribute information.
[0073] Accordingly, the permission information of the competing application may include a permission identifier code for the competing application. This permission identifier code may be, but is not limited to, a string composed of at least one of letters, numbers, and special characters. This permission identifier code can be used to distinguish different applications, and it contains information indicating the application's permissions. For example, the permission information of a security-related application may include a permission identifier code with the highest bit set to 1, while the permission information of a non-security-related application may include a permission identifier code with the highest bit set to 0. The permission information of the competing application is also pre-generated by the unified resource management layer based on the permission request sent by the competing application. The generation method is similar to S601-S605, and the specific process can be found in the relevant descriptions of S601-S605, which will not be repeated here.
[0074] S309: When the permission information of the target application and the permission information of the competing application meet the preset priority service conditions, the unified resource management layer updates the status information of the target service based on the control attribute information and forwards the target control request to the corresponding controller to realize the corresponding vehicle function control.
[0075] In a specific embodiment, the permission information of the target application and the permission information of the competing application satisfying the preset priority service condition may include: the highest bit of the permission identifier code of the target application is 1, and the highest bit of the permission identifier code of the competing application is 0 (i.e., the target application is a security function-related application, and the competing application is a non-security function-related application). In this case, the preset priority service condition is met (the target application can be served preferentially). The unified resource management layer can update the status information of the target service based on the control attribute information and forward the target control request to the corresponding controller to implement the corresponding vehicle function control. The unified resource management layer updating the status information of the target service based on the control attribute information may include, but is not limited to: updating the identifier code of the application currently locking the target service based on the identifier code of the target application; and updating the remaining release time of the target service based on the duration the target application has locked the target service when the target application needs to lock the target service. In practical applications, some target applications do not need to lock the target service (e.g., only need to execute the action once). In this case, the target service can be left unlocked, i.e., the remaining release time of the target service can be set to 0, so that subsequent applications can directly call the service if needed.
[0076] By determining the permission information of the target application and the competing application through the unified resource management layer, and when the permission information meets the preset priority service conditions, the target application is granted access to the target service. When the target service is locked by non-functional safety-related applications, functional safety-related applications can directly call the target service without being restricted by the lock. Unified scheduling by the unified resource management layer facilitates reasonable service calls based on application permissions, avoiding potential security risks when multiple applications need to call the same service, improving the security and reliability of vehicle service control. Furthermore, applications can lock the services they need, with the lock time specified when calling the service; the lock is released after the time expires, offering great flexibility and ensuring that the application's execution result is not modified by other applications within the required timeframe.
[0077] like Figure 7 As shown in the embodiments of this specification, when the permission information of the target application and the permission information of the competing application meet the preset priority service conditions, after the unified resource management layer updates the status information of the target service based on the control attribute information and forwards the target control request to the corresponding controller to realize the corresponding vehicle function control, the method may further include:
[0078] S701: The unified resource management layer generates feedback information on the occupied service and sends the feedback information on the occupied service to the competing application.
[0079] In the embodiments described in this specification, the feedback information regarding service occupancy may include the identifier of the application currently occupying the service (the target application) and the remaining release time of the target service. This allows competing applications to promptly obtain information about service preemption and subsequently schedule appropriate times to request service re-invocation, thereby improving the reliability of vehicle service control.
[0080] like Figure 8 As shown in the embodiments of this specification, the method may further include:
[0081] S801: When the permission information of the target application and the permission information of the competing application do not meet the preset priority service conditions, the unified resource management layer generates service call failure information and sends the service call failure information to the target application.
[0082] In the embodiments described in this specification, the fact that the permission information of the target application and the permission information of the competing application do not meet the preset priority service conditions may include:
[0083] (1) The highest bit of the permission identifier of the target application is 1, and the highest bit of the permission identifier of the competing application is also 1 (that is, both the target application and the competing application are security function related applications).
[0084] (2) The highest bit of the permission identifier of the target application is 0, and the highest bit of the permission identifier of the competing application is also 0 (that is, both the target application and the competing application are applications that are not related to security functions).
[0085] (3) The highest bit of the permission identifier of the target application is 0, and the highest bit of the permission identifier of the competing application is 1 (i.e., the target application is an application not related to security functions, and the competing application is an application related to security functions).
[0086] If the preset priority service conditions are not met (the target application cannot be served first), the unified resource management layer can generate service call failure information and send it to the target application. This service call failure information may include the identifier of the application currently occupying the service (the competing application) and the remaining release time of the target service. This allows the target application to obtain service call failure information promptly, enabling it to rationally schedule subsequent service requests and improve the reliability of vehicle service control. Non-functional safety-related applications cannot preempt services locked by functional safety-related applications, ensuring that actions of functional safety-related applications are executed promptly, thus improving the overall safety and reliability of the vehicle system.
[0087] like Figure 9 As shown in the embodiments of this specification, the method may further include:
[0088] S901: When the unified resource management layer determines that the status information of the target service includes idle, it updates the status information of the target service based on the control attribute information and forwards the target control request to the corresponding controller to realize the corresponding vehicle function control.
[0089] In the embodiments of this specification, the unified resource management layer determines the status information of the target service, including idle, which may include: the unified resource management layer determines that the remaining release time of the target service is 0 (no application is using the target service, or the application using the target service has not locked the target service). At this time, the unified resource management layer can directly update the status information of the target service based on the control attribute information and forward the target control request to the corresponding controller to realize the corresponding vehicle function control.
[0090] like Figure 10As shown in the embodiments of this specification, the method may further include:
[0091] S1001: The unified resource management layer monitors the operational data of vehicle components.
[0092] In the embodiments described in this specification, vehicle components may include on-board sensors and on-board controllers. The operating data of the vehicle components may include, but is not limited to, relevant data acquired using on-board sensors and status information of the on-board controllers. For example, rainfall information acquired using a rain sensor, PM2.5 values acquired using a smoke sensor, door status, and the status of the air purification system controller, etc.
[0093] S1003: The unified resource management layer uploads the operating data of the vehicle components to the corresponding shared memory domain.
[0094] In the embodiments of this specification, the aforementioned shared memory domain may include, but is not limited to, entertainment domain, body domain, hybrid domain, chassis domain, and power domain. By dividing the shared memory domain into different types according to function, it is beneficial for the unified resource management layer to classify and store the operating data of vehicle components. Subsequently, the operating data of the corresponding vehicle components can be easily and quickly determined based on the data reading requests sent by the application, which is more flexible and improves the efficiency of application reading data.
[0095] S1005: The target application sends a data read request to the unified resource management layer.
[0096] In the embodiments of this specification, the target application can send a data read request to the unified resource management layer based on the corresponding service interface. The data read request may include the identification information of the vehicle component's operating data that the target application needs to read, so that the unified resource management layer can conveniently and quickly determine the required vehicle component's operating data from the corresponding shared memory domain.
[0097] S1007: The unified resource management layer determines the operating data of the corresponding vehicle component from the shared memory domain corresponding to the data read request.
[0098] S1009: The unified resource management layer sends the operating data of the corresponding vehicle component to the target application.
[0099] By creating different types of shared memory domains and having a unified resource management layer monitor the uploading of operational data from vehicle components to the corresponding shared memory domains, multiple applications can simultaneously read relevant data from onboard sensors and onboard controllers. This flexibly and conveniently resolves the competition for data reading by multiple applications simultaneously, which is beneficial for improving vehicle system performance.
[0100] In the embodiments of this specification, the status information of the target service is determined by utilizing the control attribute information carried in the target control request. When the status information of the target service includes being occupied, the permission information of the target application is extracted from the control attribute information. That is, when it is determined that there is service competition and it is necessary to call a service that is being used by another application, the permission information of the target application is further determined, and the permission information of the competing application is determined based on the control attribute information. This is reasonable and orderly, which helps to improve reliability. When the permission information of the target application and the permission information of the competing application meet the preset priority service conditions, the status information of the target service is updated based on the control attribute information, and the target control request is forwarded to the corresponding controller to realize the corresponding vehicle function control. This helps to maximize the utilization of the service functions provided by the vehicle, and can avoid the chaos and security risks caused by multiple programs calling the same service function at the same time. This is reasonable and orderly, which improves security and reliability. By encapsulating the data, status, and executable actions of vehicle sensors and controllers into classes, a unified service interface is generated. When developing applications, only the classes need to be instantiated, which has good compatibility. This helps reduce the development difficulty of vehicle applications and improves the development efficiency. When the application runs, it only needs to call the corresponding service interface to send control requests, shielding the details of the vehicle network and data interaction. This allows the application to focus on its own logical functions and improves the reliability of vehicle service control.
[0101] By acquiring the control request queue through a unified resource management layer and processing the control requests in the queue sequentially according to time, it ensures that data written first is read first by the unified resource management layer. This guarantees that the execution order of control requests sent by multiple applications strictly follows the chronological order. This helps avoid confusion and performance degradation caused by multiple programs simultaneously calling the same service function, thus improving the reliability of vehicle service control. By creating different types of shared memory domains, and having the unified resource management layer monitor the uploading of vehicle component operating data to the corresponding shared memory domain, multiple applications can simultaneously read relevant data from onboard sensors and onboard controllers. This flexibly and conveniently resolves the contention for data reads by multiple applications simultaneously, further improving vehicle system performance.
[0102] This application also provides an embodiment of a vehicle service control device, such as... Figure 11 As shown, the device may include:
[0103] The target control request acquisition module 1110 is used to acquire a target control request, wherein the target control request carries control attribute information of the target service;
[0104] The status information acquisition module 1120 is used to determine the status information of the target service based on the control attribute information;
[0105] The first permission information determination module 1130 is used to extract permission information of the target application from the control attribute information when it is determined that the status information of the target service includes being occupied. The target application includes the application corresponding to the target control request.
[0106] The second permission information determination module 1140 is used to determine the permission information of the competing application based on the control attribute information;
[0107] The service preemption module 1150 is used to update the status information of the target service based on the control attribute information and forward the target control request to the corresponding controller to realize the corresponding vehicle function control when the permission information of the target application and the permission information of the competing application meet the preset priority service conditions.
[0108] In embodiments described in this specification, the apparatus may further include:
[0109] The failure information feedback module is used to generate service call failure information and send the service call failure information to the target application when the permission information of the target application and the permission information of the competing application do not meet the preset priority service conditions.
[0110] In embodiments described in this specification, the apparatus may further include:
[0111] The permission acquisition request receiving module is used to receive a permission acquisition request sent by the target application in response to the function start command before acquiring the target control request. The permission acquisition request carries the attribute information and initial permission identifier of the target application.
[0112] The permission identifier allocation module is used to determine the permission request identifier of the target application based on the attribute information of the target application, and send the permission request identifier to the target application, so that the target application modifies the initial permission identifier to the permission request identifier and uses the permission request identifier as the permission information of the target application.
[0113] In embodiments described in this specification, the apparatus may further include:
[0114] The control request receiving module is used to receive at least one control request sent by an application based on the corresponding service interface before obtaining the target control request.
[0115] The control request queue generation module is used to sort the control requests based on the time when the control requests are received, and generate a control request queue.
[0116] Specifically, the target control request acquisition module 1110 may include:
[0117] A control request queue acquisition unit is used to acquire the control request queue;
[0118] An unprocessed request determination unit is used to determine the first unprocessed control request in the control request queue arranged in the order of control request reception time.
[0119] The target control request determination unit is used to determine the first unprocessed control request as the target control request.
[0120] In one embodiment, the apparatus may further include:
[0121] The service idle call module is used to update the status information of the target service based on the control attribute information when it is determined that the status information of the target service includes idle, and forward the target control request to the corresponding controller to realize the corresponding vehicle function control.
[0122] In one embodiment, the apparatus may further include:
[0123] The occupancy feedback information generation module is used to update the status information of the target service based on the control attribute information and forward the target control request to the corresponding controller to realize the corresponding vehicle function control when the permission information of the target application and the permission information of the competing application meet the preset priority service conditions. Then, it generates occupancy service feedback information and sends the occupancy service feedback information to the competing application.
[0124] In embodiments described in this specification, the apparatus may further include:
[0125] The operation data monitoring module is used to monitor the operation data of vehicle components;
[0126] The operation data upload module is used to upload the operation data of the vehicle components to the corresponding shared memory domain;
[0127] The running data determination module is used to determine the running data of the corresponding vehicle component from the shared memory domain corresponding to the data reading request in response to a data reading request sent by the target application.
[0128] The data transmission module is used to send the operational data of the corresponding vehicle components to the target application.
[0129] This application provides a vehicle that includes the vehicle service control device described above.
[0130] This application provides a computer device including a processor and a memory. The memory stores at least one instruction or at least one program, which is loaded and executed by the processor to implement the vehicle service control method provided in the above method embodiments.
[0131] Memory can be used to store software programs and modules. The processor executes various functional applications and data processing by running the software programs and modules stored in the memory. Memory can primarily include a program storage area and a data storage area. The program storage area can store the operating system, application programs required for the functions, etc.; the data storage area can store data created based on the use of the device, etc. Furthermore, memory can include high-speed random access memory, and can also include non-volatile memory, such as at least one disk storage device, flash memory device, or other volatile solid-state storage device. Accordingly, memory can also include a memory controller to provide the processor with access to the memory.
[0132] The methods and embodiments provided in this application can be executed in a mobile terminal, computer terminal, server, or similar computing device; that is, the aforementioned computer device may include a mobile terminal, computer terminal, server, or similar computing device. Taking running on a server as an example... Figure 12 This is a hardware structure block diagram of a server implementing a vehicle service control method provided in an embodiment of this application. For example... Figure 12As shown, the server 1200 can vary significantly due to different configurations or performance. It may include one or more central processing units (CPUs) 1210 (CPUs 1210 may include, but are not limited to, microprocessors (MCUs) or programmable logic devices (FPGAs), a memory 1230 for storing data, and one or more storage media 1220 (e.g., one or more mass storage devices) for storing application programs 1223 or data 1222. The memory 1230 and storage media 1220 may be temporary or persistent storage. The program stored in the storage media 1220 may include one or more modules, each module including a series of instruction operations on the server. Furthermore, the CPU 1210 may be configured to communicate with the storage media 1220 and execute the series of instruction operations stored in the storage media 1220 on the server 1200. Server 1200 may also include one or more power supplies 1260, one or more wired or wireless network interfaces 1250, one or more input / output interfaces 1240, and / or one or more operating systems 1221, such as Windows Server. TM Mac OSX TM Unix TM Linux TM FreeBSD TM etc.
[0133] Those skilled in the art will understand that Figure 12 The structure shown is for illustrative purposes only and does not limit the structure of the aforementioned electronic device. For example, server 1200 may also include... Figure 12 The more or fewer components shown, or having the same Figure 12 The different configurations shown.
[0134] Embodiments of this application also provide a computer-readable storage medium, which can be disposed in a server to store at least one instruction or at least one program related to implementing a vehicle service control method in the method embodiments. The at least one instruction or the at least one program is loaded and executed by the processor to implement the vehicle service control method provided in the above method embodiments.
[0135] Optionally, in this embodiment, the storage medium may be located at at least one of the multiple network servers in a computer network. Optionally, in this embodiment, the storage medium may include, but is not limited to, various media capable of storing program code, such as USB flash drives, read-only memory (ROM), random access memory (RAM), portable hard drives, magnetic disks, or optical disks.
[0136] As can be seen from the embodiments of the vehicle service control method, device, vehicle, computer equipment, or storage medium provided in this application, this application determines the status information of the target service by utilizing the control attribute information carried in the target control request. When the status information of the target service is determined to include being occupied, the permission information of the target application is extracted from the control attribute information. That is, when it is determined that there is service competition and it is necessary to call a service that is being occupied by other applications, the permission information of the target application is further determined, and the permission information of the competing application is determined based on the control attribute information. This is reasonable and orderly, which is conducive to improving reliability. When the permission information of the target application and the permission information of the competing application meet the preset priority service conditions, the status information of the target service is updated based on the control attribute information, and the target control request is forwarded to the corresponding controller to realize the corresponding vehicle function control. This is conducive to maximizing the utilization of the service functions provided by the vehicle, and can avoid the chaos and security risks caused by multiple programs calling the same service function at the same time. This is reasonable and orderly, which improves security and reliability. By encapsulating the data, status, and executable actions of vehicle sensors and controllers into classes, a unified service interface is generated. When developing applications, only the classes need to be instantiated, which has good compatibility. This helps reduce the development difficulty of vehicle applications and improves the development efficiency. When the application runs, it only needs to call the corresponding service interface to send control requests, shielding the details of the vehicle network and data interaction. This allows the application to focus on its own logical functions and improves the reliability of vehicle service control.
[0137] By acquiring the control request queue through a unified resource management layer and processing the control requests in the queue sequentially according to time, it ensures that data written first is read first by the unified resource management layer. This guarantees that the execution order of control requests sent by multiple applications strictly follows the chronological order. This helps avoid confusion and performance degradation caused by multiple programs simultaneously calling the same service function, thus improving the reliability of vehicle service control. By creating different types of shared memory domains, and having the unified resource management layer monitor the uploading of vehicle component operating data to the corresponding shared memory domain, multiple applications can simultaneously read relevant data from onboard sensors and onboard controllers. This flexibly and conveniently resolves the contention for data reads by multiple applications simultaneously, further improving vehicle system performance.
[0138] It should be noted that the order of the embodiments described above is merely for descriptive purposes and does not represent the superiority or inferiority of the embodiments. Furthermore, specific embodiments have been described above. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps described in the claims can be performed in a different order than that shown in the embodiments and still achieve the desired result. Additionally, the processes depicted in the drawings do not necessarily require a specific or sequential order to achieve the desired result. In some embodiments, multitasking and parallel processing are also possible or may be advantageous.
[0139] The various embodiments in this specification are described in a progressive manner. Similar or identical parts between embodiments can be referred to mutually. Each embodiment focuses on describing the differences from other embodiments. In particular, the embodiments of apparatus, devices, and storage media are basically similar to the method embodiments, so the descriptions are relatively simple; relevant parts can be referred to the descriptions of the method embodiments.
[0140] Those skilled in the art will understand that all or part of the steps of the above embodiments can be implemented by hardware or by a program instructing related hardware. The program can be stored in a computer-readable storage medium, such as a read-only memory, a disk, or an optical disk.
[0141] The above description is only a preferred embodiment of this application and is not intended to limit this application. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the protection scope of this application.
Claims
1. A vehicle service control method, characterized in that, The method includes: Obtain a target control request, the target control request carrying control attribute information of a target service; determine the status information of the target service based on the control attribute information; When it is determined that the status information of the target service includes being occupied, the permission information of the target application is extracted from the control attribute information, and the target application includes the application corresponding to the target control request; The permission information of competing applications is determined based on the aforementioned control attribute information; When the permission information of the target application and the permission information of the competing application meet the preset priority service conditions, the status information of the target service is updated based on the control attribute information, and the target control request is forwarded to the corresponding controller to realize the corresponding vehicle function control. Wherein, the highest bit of the permission identifier code of the target application is 1, and the highest bit of the permission identifier code of the competing application is 0, and the identifier code of the application currently locking the target service is updated based on the identifier code of the target application.
2. The method according to claim 1, characterized in that, The method further includes: When the permission information of the target application and the permission information of the competing application do not meet the preset priority service conditions, a service call failure message is generated and sent to the target application.
3. The method according to claim 1, characterized in that, Before obtaining the target control request, the method further includes: Receive a permission acquisition request sent by the target application in response to a function launch command, the permission acquisition request carrying the target application's attribute information and initial permission identifier; Based on the attribute information of the target application, a permission request identifier for the target application is generated and sent to the target application, so that the target application modifies the initial permission identifier to the permission request identifier and uses the permission request identifier as the permission information of the target application.
4. The method according to claim 1, characterized in that, Before obtaining the target control request, the method further includes: Receive at least one control request sent by an application based on the corresponding service interface; The control requests are sorted according to the time they are received, and a control request queue is generated.
5. The method according to claim 4, characterized in that, The process of obtaining the target control request includes: obtaining the control request queue; Determine the first unprocessed control request in the control request queue, arranged in chronological order of control request reception time. The first unprocessed control request is taken as the target control request.
6. The method according to claim 1, characterized in that, The method further includes: When the status information of the target service is determined to include idle, the status information of the target service is updated based on the control attribute information, and the target control request is forwarded to the corresponding controller to realize the corresponding vehicle function control.
7. The method according to claim 1, characterized in that, After the permission information of the target application and the permission information of the competing application meet the preset priority service conditions, the method further includes updating the status information of the target service based on the control attribute information and forwarding the target control request to the corresponding controller to realize the corresponding vehicle function control. Generate feedback information about the occupied service and send the feedback information about the occupied service to the competing application.
8. The method according to claim 1, characterized in that, The method also includes: monitoring the operational data of vehicle components; The operational data of the vehicle components is uploaded to the corresponding shared memory domain; In response to a data read request sent by the target application, the operating data of the corresponding vehicle component is determined from the shared memory domain corresponding to the data read request; The operating data of the corresponding vehicle components are sent to the target application.
9. A vehicle service control device, characterized in that, The device includes: The target control request acquisition module is used to acquire the target control request, which carries the control attribute information of the target service; The status information acquisition module is used to determine the status information of the target service based on the control attribute information; The first permission information determination module is used to extract permission information of the target application from the control attribute information when it is determined that the status information of the target service includes being occupied. The target application includes the application corresponding to the target control request. The second permission information determination module is used to determine the permission information of competing applications based on the control attribute information; The service preemption module is used to update the status information of the target service based on the control attribute information and forward the target control request to the corresponding controller to realize the corresponding vehicle function control when the permission information of the target application and the permission information of the competing application meet the preset priority service conditions. Wherein, the highest bit of the permission identifier code of the target application is 1, and the highest bit of the permission identifier code of the competing application is 0, and the identifier code of the application currently locking the target service is updated based on the identifier code of the target application.
10. The vehicle service control device according to claim 9, characterized in that, The device further includes: The failure information feedback module is used to generate service call failure information and send the service call failure information to the target application when the permission information of the target application and the permission information of the competing application do not meet the preset priority service conditions.
11. The vehicle service control device according to claim 9, characterized in that, The device further includes: The permission acquisition request receiving module is used to receive a permission acquisition request sent by the target application in response to the function start command before acquiring the target control request. The permission acquisition request carries the attribute information and initial permission identifier of the target application. The permission identifier allocation module is used to generate a request permission identifier for the target application based on the attribute information of the target application, and send the request permission identifier to the target application, so that the target application modifies the initial permission identifier to the request permission identifier and uses the request permission identifier as the permission information of the target application.
12. The vehicle service control device according to claim 9, characterized in that, The device further includes: The control request receiving module is used to receive at least one control request sent by an application based on the corresponding service interface before obtaining the target control request. The control request queue generation module is used to sort the control requests based on the time when the control requests are received, and generate a control request queue.
13. The vehicle service control device according to claim 12, characterized in that, The target control request acquisition module includes: A control request queue acquisition unit is used to acquire the control request queue; An unprocessed request determination unit is used to determine the first unprocessed control request in the control request queue arranged in the order of control request reception time. The target control request determination unit is used to determine the first unprocessed control request as the target control request.
14. The vehicle service control device according to claim 9, characterized in that, The device further includes: The service idle call module is used to update the status information of the target service based on the control attribute information when it is determined that the status information of the target service includes idle, and forward the target control request to the corresponding controller to realize the corresponding vehicle function control.
15. The vehicle service control device according to claim 9, characterized in that, The device further includes: The occupancy feedback information generation module is used to update the status information of the target service based on the control attribute information and forward the target control request to the corresponding controller to realize the corresponding vehicle function control when the permission information of the target application and the permission information of the competing application meet the preset priority service conditions. Then, it generates occupancy service feedback information and sends the occupancy service feedback information to the competing application.
16. The vehicle service control device according to claim 9, characterized in that, The device further includes: The operation data monitoring module is used to monitor the operation data of vehicle components; The operation data upload module is used to upload the operation data of the vehicle components to the corresponding shared memory domain; The running data determination module is used to determine the running data of the corresponding vehicle component from the shared memory domain corresponding to the data reading request in response to a data reading request sent by the target application. The data transmission module is used to send the operational data of the corresponding vehicle components to the target application.
17. A vehicle, characterized in that, The vehicle includes the vehicle service control device as described in any one of claims 9 to 16.
18. A vehicle service control device, characterized in that, The device includes a processor and a memory, the memory storing at least one instruction or at least one program, the at least one instruction or the at least one program being loaded and executed by the processor to implement the vehicle service control method as described in any one of claims 1 to 8.
19. A computer-readable storage medium, characterized in that, The storage medium stores at least one instruction or at least one program segment, which is loaded and executed by a processor to implement the vehicle service control method as described in any one of claims 1 to 8.
Citation Information
Patent Citations
Information interaction method and system
CN108749820A
Vehicle service response method and system
CN111064772A