Method and device for executing vehicle business logic, vehicle and storage medium

Abstract

The invention provides a method and device for executing vehicle business logic, a vehicle and a storage medium, the method is applied to the field of vehicle control, and the method comprises the following steps: in response to a target business demand, determining a target business configuration file corresponding to a target vehicle type from a plurality of preset business configuration files according to the target vehicle type corresponding to the vehicle; determining a target service execution sequence corresponding to the target service demand from the target service configuration file according to the target service demand; and executing the target service demand according to the target service execution sequence. According to the method, business logic can be separated from codes, and business rules are independently configured for each vehicle type in the form of business configuration files. When the business demand changes, the business demand can be quickly realized only by modifying the business configuration file, and the codes do not need to be modified and recompiled on a large scale, so that the risk of frequently modifying the codes is reduced, the configuration and change flexibility is enhanced, and the workload of workers is reduced.

Description

Technical Field

[0001] This application relates to the field of vehicle control, and more specifically, to a method, apparatus, vehicle, and storage medium for executing vehicle business logic in the field of vehicle control. Background Technology

[0002] In the automotive field, vehicle business logic refers to a series of rules, processes, and algorithms involved in achieving various functions and meeting user needs. These rules coordinate the work between various hardware devices and software modules of the vehicle to realize its various functions.

[0003] During the implementation of business logic, the Hardware Abstraction Layer (HAL) provides basic support for business logic configuration. Specifically, the HAL configures a unified hardware access interface for in-vehicle business logic. The business logic will call the interface provided by the HAL to control hardware devices according to its own needs and configuration information.

[0004] In related technologies, for the same business requirement, different vehicles may need to perform different operations depending on the vehicle model. The relevant business logic code for these different operations, as well as the vehicle model determination code, are all in one code file. The drawback of writing business logic in this way is that as the number of vehicle models increases, it is necessary to continuously add different vehicle model judgment logic to the code, making the code increasingly complex and significantly reducing readability and maintainability. Summary of the Invention

[0005] This application provides a method, apparatus, vehicle, and storage medium for executing vehicle business logic. The method separates business logic from code, using business configuration files to configure business rules individually for each vehicle model. When business requirements change, they can be quickly implemented simply by modifying the business configuration file, without requiring large-scale code modifications and recompilation. This reduces the risk of frequent code changes, enhances the flexibility of configuration and changes, and reduces the workload of staff.

[0006] Firstly, a method for executing vehicle business logic is provided. The method includes: responding to a target business requirement, determining a target business configuration file corresponding to the target vehicle model from multiple preset business configuration files, wherein the multiple preset business configuration files are business configuration files corresponding to multiple different vehicle models, and the target business configuration file includes a mapping relationship between the target business requirement and the target business execution sequence corresponding to the target business requirement; determining the target business execution sequence corresponding to the target business requirement from the target business configuration file according to the target business requirement; and executing the target business requirement according to the target business execution sequence.

[0007] In the above technical solution, this application provides a method for executing vehicle business logic. Specifically, a corresponding business configuration file is first configured for each vehicle model. When a user's target business requirement is received, the target business configuration file corresponding to the current target vehicle model is determined from the preset business configuration files of multiple vehicle models. The business configuration file provided by this application contains multiple business requirements and the corresponding business execution sequences. Based on this, the vehicle can determine the target business execution sequence corresponding to the current target business requirement based on the business configuration file, and then execute the target business requirement according to the target business execution sequence. The above process can separate business logic from the code and configure business rules separately for each vehicle model in the form of a business configuration file. When business requirements change, they can be quickly implemented by simply modifying the business configuration file, without the need for large-scale code modifications and recompilation, reducing the risk of frequent code modifications, enhancing the flexibility of configuration and changes, and reducing the workload of staff.

[0008] In conjunction with the first aspect, in some possible implementations, determining the target business execution sequence corresponding to the target business requirement from the target business configuration file based on the target business requirement includes: parsing the target business configuration file and extracting multiple key-value pairs consisting of multiple business requirements under the target vehicle model and the business execution sequences corresponding to the multiple business requirements; and determining the target business execution sequence based on the target business requirement and the multiple key-value pairs.

[0009] In the above technical solution, when determining the target business execution sequence corresponding to the current target business requirement, the target business configuration file is first parsed. This automatically extracts multiple business requirements and their corresponding execution sequences. This automated parsing process reduces manual intervention and improves parsing efficiency. By parsing the configuration file, redundant information can be removed, reducing interference from useless information in the data, making the search and matching process for the target business execution sequence more efficient.

[0010] In combination with the first aspect and the above implementation methods, in some possible implementation methods, executing the target business requirement according to the target business execution sequence includes: determining at least one code file corresponding to the target business requirement from multiple preset code files according to the target business execution sequence; and executing the target business requirement according to the at least one code file and the target business execution sequence.

[0011] In the above technical solution, after obtaining the target business execution sequence, the vehicle in this application directly locates the code file related to the target business requirement through the target business execution sequence. This ensures that the code file called during execution is highly matched with the business requirement, reducing execution deviations caused by incorrect calls to irrelevant code. When business requirements change, the above steps enable this application to dynamically select the appropriate code file to call based on the business requirements, increasing the robustness of the method.

[0012] In combination with the first aspect and the above implementation methods, in some possible implementation methods, executing the target business requirement based on the at least one code file and the target business execution sequence includes: for any one of the at least one code file, determining the implementation code of the target method in the code file used to execute the target business execution sequence based on the target business execution sequence; and calling the implementation code of the target method to execute the target business requirement.

[0013] In the above technical solution, during the execution of target business requirements, the implementation code of the target method required to implement the current sequence is accurately located through the target business execution sequence. This makes the code structure more modular, avoids unnecessary execution of the entire code file, improves the efficiency of business requirement execution, and reduces unnecessary computing resources. Furthermore, by only selecting the implementation code of methods related to the current business execution sequence, the method of this application can flexibly adapt to different business requirements without changing the overall code architecture. This allows the same code to be called multiple times in different business requirements, improving code reusability and reducing development costs.

[0014] Combining the first aspect and the above implementation methods, in some possible implementation methods, the execution of the target business requirement by calling the implementation code of the target method includes: obtaining the type of the target method, which is used to represent the running process of the implementation code of the target method; if the type of the target method is an acquisition type, calling the implementation code of the target method to obtain the current parameters of the target method; if the type of the target method is a condition judgment type, calling the implementation code of the target method to obtain the current parameters and the target parameters of the target method; and determining the comparison result between the current parameters and the target parameters of the target method.

[0015] In combination with the first aspect and the above implementation methods, in some possible implementation methods, the method further includes: when the type of the target method is a setting type, calling the implementation code of the target method to obtain the target parameters of the target method; generating a target control instruction based on the target parameters of the target method; and sending the target control instruction to the hardware device driver corresponding to the target control instruction through the target method, so that the hardware device driver controls the target hardware device corresponding to the hardware device driver to run with the target parameters of the target method based on the target control instruction.

[0016] In the above technical solution, based on the differences in the method types involved in the target business execution sequence, this application proposes specific execution operations when implementing target business requirements through different types of methods. The vehicle can automatically adjust its operation process according to the type of the target method, executing different business operations, enabling the vehicle to adapt to various types of business requirements. Since the implementation logic of the same method is fixed, the above process eliminates the need to rewrite execution logic for each method when different business requirements involve the same method, improving code versatility.

[0017] Combining the first aspect and the above implementation methods, in some possible implementation methods, the step of obtaining the target parameter of the target method includes: performing semantic recognition on the target business requirement to obtain multiple keywords included in the target business requirement; determining whether the multiple keywords include parameter keywords; if the multiple keywords include the parameter keyword, determining the parameter corresponding to the parameter keyword as the target parameter of the target method; if the multiple keywords do not include the parameter keyword, determining whether the target business execution sequence includes the preset parameter of the target method; if the target business execution sequence includes the preset parameter, determining the preset parameter as the target parameter of the target method; if the target business execution sequence does not include the preset parameter, determining the previous parameter in the previous call process of the target method as the target parameter of the target method.

[0018] In the above technical solution, when determining the target parameters of the target method, if the target business requirement includes parameter keywords, the parameters corresponding to the parameter keywords are directly used as the target parameters. This allows for adherence to the user's subjective adjustment needs, improving the user experience, especially when the user has a clear intention to adjust the parameters. When the user does not specify any adjustment parameters, the preset parameters in the target business execution sequence are used first, ensuring consistency of the target method across different calling scenarios. When there are no preset parameters in the target business execution sequence, the previous parameter is used as the target parameter. This preserves the user's historical adjustment habits and avoids adjustment interruptions caused by missing parameters.

[0019] Secondly, an apparatus for executing vehicle business logic is provided. The apparatus includes: a configuration file determination module, configured to, in response to a target business requirement, determine a target business configuration file corresponding to the target vehicle model from a plurality of preset business configuration files, wherein the plurality of preset business configuration files are business configuration files corresponding to multiple different vehicle models, and the target business configuration file includes a mapping relationship between the target business requirement and the target business execution sequence corresponding to the target business requirement; an execution sequence determination module, configured to determine the target business execution sequence corresponding to the target business requirement from the target business configuration file based on the target business requirement; and a business requirement execution module, configured to execute the target business requirement according to the target business execution sequence.

[0020] In conjunction with the second aspect, in some possible implementations, the execution sequence determination module is specifically used to: parse the target business configuration file, extract multiple key-value pairs consisting of multiple business requirements under the target vehicle model and the business execution sequences corresponding to the multiple business requirements; and determine the target business execution sequence based on the target business requirements and the multiple key-value pairs.

[0021] In combination with the second aspect and the above implementation methods, in some possible implementation methods, the business requirement execution module is specifically used to: determine at least one code file corresponding to the target business requirement from multiple preset code files according to the target business execution sequence; and execute the target business requirement according to the at least one code file and the target business execution sequence.

[0022] In conjunction with the second aspect and the above implementation methods, in some possible implementation methods, the business requirement execution module is further configured to: for any one of the at least one code file, determine the implementation code of the target method in the code file used to execute the target business execution sequence according to the target business execution sequence; and call the implementation code of the target method to execute the target business requirement.

[0023] In conjunction with the second aspect and the above implementation methods, in some possible implementation methods, the business requirement execution module is further used to: obtain the type of the target method, which represents the execution process of the implementation code of the target method; if the type of the target method is an acquisition type, call the implementation code of the target method to obtain the current parameters of the target method; if the type of the target method is a condition judgment type, call the implementation code of the target method to obtain the current parameters and the target parameters of the target method; and determine the comparison result between the current parameters and the target parameters of the target method.

[0024] In conjunction with the second aspect and the above implementation methods, in some possible implementation methods, the business requirement execution module is further configured to: when the type of the target method is a setting type, call the implementation code of the target method to obtain the target parameters of the target method; generate target control instructions based on the target parameters of the target method; and send the target control instructions to the hardware device driver corresponding to the target control instructions through the target method, so that the hardware device driver controls the target hardware device corresponding to the hardware device driver to run with the target parameters of the target method based on the target control instructions.

[0025] In conjunction with the second aspect and the above implementation methods, in some possible implementation methods, the business requirement execution module is further configured to: perform semantic recognition on the target business requirement to obtain multiple keywords included in the target business requirement; determine whether the multiple keywords include parameter keywords; if the multiple keywords include the parameter keywords, determine the parameter corresponding to the parameter keywords as the target parameter of the target method; if the multiple keywords do not include the parameter keywords, determine whether the target business execution sequence includes the preset parameters of the target method; if the target business execution sequence includes the preset parameters, determine the preset parameters as the target parameters of the target method; if the target business execution sequence does not include the preset parameters, determine the previous parameter in the previous call process of the target method as the target parameter of the target method.

[0026] Thirdly, a vehicle is provided, including a memory and a processor. The memory is used to store executable program code, and the processor is used to call and run the executable program code from the memory, causing the vehicle to perform the methods described in the first aspect or any possible implementation thereof.

[0027] Fourthly, a computer program product is provided, comprising: computer program code, which, when run on a computer, causes the computer to perform the methods described in the first aspect or any possible implementation thereof.

[0028] Fifthly, a computer-readable storage medium is provided that stores computer program code, which, when executed on a computer, causes the computer to perform the methods described in the first aspect or any possible implementation thereof. Attached Figure Description

[0029] Figure 1 This is a schematic diagram of the structure of a HAL layer provided in an embodiment of this application;

[0030] Figure 2This is a schematic flowchart illustrating a method for executing vehicle business logic provided in an embodiment of this application;

[0031] Figure 3 This is a schematic flowchart illustrating another method for executing vehicle business logic provided in an embodiment of this application;

[0032] Figure 4 This is an interactive flowchart of a vehicle business logic execution process provided in an embodiment of this application;

[0033] Figure 5 This is a schematic diagram of the structure of a device for executing vehicle business logic provided in an embodiment of this application;

[0034] Figure 6 This is a schematic diagram of the structure of a vehicle provided in an embodiment of this application. Detailed Implementation

[0035] The technical solutions in this application will be clearly and thoroughly described below with reference to the accompanying drawings. In the description of the embodiments of this application, unless otherwise stated, " / " means "or," for example, A / B can mean A or B. "And / or" in the text is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, and B existing alone. Furthermore, in the description of the embodiments of this application, "multiple" refers to two or more than two.

[0036] Hereinafter, the terms "first" and "second" are used for descriptive purposes only and should not be construed as implying or suggesting relative importance or implicitly indicating the number of technical features indicated. Thus, a feature defined as "first" or "second" may explicitly or implicitly include one or more of that feature.

[0037] Before introducing the solutions of the embodiments of this application, the technical terms that may be involved in the embodiments of this application will be explained first.

[0038] HAL Layer: A software abstraction layer located between the operating system kernel and hardware devices. The HAL layer provides the operating system with a hardware-independent interface, encapsulating the specific details of the underlying hardware. This allows the operating system kernel and upper-layer applications to access and control hardware devices in a unified way, without needing to understand the specific implementation and differences of the hardware.

[0039] Business logic: In the vehicle field, business logic refers to a series of rules, processes, and algorithms designed to achieve specific functions and meet business needs. It covers all aspects from basic vehicle operation to the implementation of complex intelligent functions.

[0040] Cyclomatic Complexity (CC) is a metric for measuring code complexity. Based on graph theory, cyclomatic complexity measures code complexity by analyzing the number of linear independent paths in the program's control flow graph. Higher cyclomatic complexity indicates more control structures such as branches and loops in the code, resulting in more complex logic.

[0041] After introducing the technical terms that may be involved in the embodiments of this application, the application scenarios of the embodiments of this application will be introduced below.

[0042] Currently, in the automotive field, the HAL layer plays a crucial role in the implementation of vehicle business logic. Specifically, the HAL layer provides abstract interfaces that isolate the vehicle's software system from the underlying hardware. Through the HAL layer, upper-layer software of the in-vehicle infotainment system (such as navigation software, multimedia software, or applications) can interact with different types and models of hardware devices in a unified manner.

[0043] The user's business needs (i.e., user requests) and the corresponding operations constitute a crucial part of the business logic. Due to the diversity of vehicle models, the business logic also varies. Specifically, for the same business need, different vehicle models may correspond to different operations. Therefore, when a vehicle receives a business need, it first needs to determine which vehicle model it belongs to, and then control the vehicle's hardware to execute the corresponding instructions according to the operation required for that business need under that vehicle model.

[0044] The current approach in related technologies involves writing both the vehicle model determination logic and the corresponding business requirement operation logic into a single code file, without clear separation or distinction between the vehicle model determination code and the corresponding operation code. For example, for the same business requirement, depending on the vehicle model, the code file might first determine the vehicle model in one function, then directly write the control operation code for that model based on the determination result, and then perform the same vehicle model determination in another location, writing the control operation code for another vehicle model. This coding style results in redundant and cumbersome code files with high cyclomatic complexity, leading to poor code quality and increased maintenance costs for code engineers. Furthermore, when a new vehicle model is added or the operation of a business requirement changes, code engineers must modify and compile the code to update it, increasing their workload.

[0045] To address the aforementioned technical issues, this application provides a method for executing vehicle business logic. This method separates business logic from the code and uses business configuration files to configure business rules individually for each vehicle model. When business requirements change, they can be quickly implemented simply by modifying the business configuration file, without requiring large-scale code modifications and recompilation. This reduces the risk of frequent code modifications, enhances the flexibility of configuration and changes, and reduces the workload of staff.

[0046] After introducing the application scenarios of the embodiments of this application, and before introducing a method for executing vehicle business logic provided by the embodiments of this application, we will first introduce the HAL architecture and overall implementation process for executing vehicle business logic provided by the embodiments of this application.

[0047] It should be understood that in vehicles, different HAL layers exist for different business processing domains, depending on the specific hardware and business requirements. For example, in the audio processing domain, engineers can design an audio HAL, enabling upper-layer software to interact with audio hardware through these interfaces. In the video processing domain, engineers can design and implement a video HAL, allowing upper-layer software to interact with video hardware through these interfaces. In the sensor processing domain, engineers can design and implement a sensor HAL, enabling upper-layer software to interact with sensor hardware through these interfaces. The following embodiments of this application will use the AudioHAL as an example in describing the HAL architecture and the provided method for executing vehicle business logic.

[0048] Figure 1 This is a schematic diagram of the structure of a HAL layer provided in an embodiment of this application.

[0049] For example, such as Figure 1 As shown in the illustration, this application's embodiments define an interface at the HAL layer. This interface contains a series of methods that define standard methods for interaction between upper-layer software and hardware. Specifically, this interface is... Figure 1 The HAL business configurable framework interface is specifically mHalBusinessConfigurableFrameworks. This interface includes the following methods: write(), read(), setParameters(), setAudioMute(), setAudioPortConfig(), and setEffect().

[0050] The HAL layer business configurable framework implementation class, HalBusinessConfigurableFrameworks, implements the methods in the aforementioned HAL business configurable framework interface. This implementation class contains multiple business logic processors for handling different business logic. These business logic processors process specific business logic by calling methods of the underlying, different business processors.

[0051] Optional, such as Figure 1 As shown, the business logic processors included in the configurable framework implementation classes for multiple HAL layer services can be: volume business logic processor -mVolumeHandler, mute business logic processor -mMuteHandler, connection business logic processor -mConnectionHandler, effect business logic processor -mEffectHandler, power business logic processor -mPowerHandler, memory cache business logic processor -mMemoryCacheHandler, and judgment business logic processor -mJudgementsHandler.

[0052] In addition, the HAL business configurable framework implementation class also includes the initialization configuration method - init() and the execution function method - execFeature(), which are used to execute specific business logic.

[0053] In this embodiment, the HAL layer architecture further includes a configuration parser class, ConfigParser, which includes a parsing method, parse(), and a configuration table, ConfigTable. During business logic execution, the HAL business configurable framework implementation class can call the parsing method of the configuration parser class to parse the configuration file and store the parsed configuration information in the configuration table. When configuration information is needed, the HAL business configurable framework implementation class can query and retrieve the corresponding configuration items from the configuration table.

[0054] When specific business logic needs to be processed, after the corresponding business logic processor is determined, the business logic processor can call the methods in the underlying business processor to process the specific business logic.

[0055] like Figure 1As shown, each service processor includes VolumeHandler, MuteHandler, ConnectionHandler, EffectHandler, PowerHandler, MemoryCacheHandler, and JudgementsHandler.

[0056] The volume handler includes methods for setting and getting the volume (setVolume()). The mute handler includes methods for setting and getting the mute state (setMute()). The connection handler includes methods for connecting and disconnecting (connect()). The effects handler includes methods for setting and getting the effects (setEffect()). The power handler includes methods for registering power callbacks (registerPowerCallback()) and onPowerChanged(). The memory handler includes methods for setting and getting the memory state (setState()). The conditional handler includes methods for checking if the memory is greater than (isGreater()), less than (isLess()), equal to (isEqual()), and contained within (isContained()).

[0057] Based on the HAL layer architecture described above, the specific implementation process for executing business requirements is as follows:

[0058] Upper-layer software or applications call methods in the HAL business configurable framework interface provided by the HAL layer. When a method in the interface is called, the corresponding method in the HAL business configurable framework implementation class is also called. In the initial stage, the HAL business configurable framework implementation class can also call the parsing method in the configuration parser class to parse the configuration file corresponding to the current business requirement and store the parsed configuration information in the configuration table.

[0059] The execution function methods in the HAL business configurable framework implementation class will call the corresponding business processor methods to process the data based on the configuration information and business requirements.

[0060] Specifically, when the execution function method determines that it needs to call the set volume method in the volume business processor, the execution function method will call the set volume method in the volume business processor pointed to by the volume business logic processor class to handle the business logic related to volume setting.

[0061] After introducing the overall structure of the HAL layer in the embodiments of this application, the following describes a method for executing vehicle business logic provided by the embodiments of this application.

[0062] Figure 2 This is a schematic flowchart illustrating a method for executing vehicle business logic according to an embodiment of this application. It should be understood that this method can be applied to vehicles, specifically to applications or upper-layer software installed on the vehicle's infotainment system that are related to the current business logic. For example, in the field of audio processing, if the audio playback device in the vehicle is playing navigation voice from a navigation system, then the corresponding application is the navigation system; or, if the audio playback device in the vehicle is playing music from a music app, then the corresponding application is that music app.

[0063] For example, such as Figure 2 As shown, the method 200 includes the following steps 201 to 203.

[0064] 201. In response to the target business requirements, based on the target vehicle model, the target business configuration file corresponding to the target vehicle model is determined from multiple preset business configuration files. The multiple preset business configuration files are business configuration files corresponding to multiple different vehicle models. The target business configuration file includes the mapping relationship between the target business requirements and the target business execution sequence corresponding to the target business requirements.

[0065] It should be understood that the method for executing vehicle business logic provided in this application addresses the drawbacks of related technologies where all vehicle model determination logic and business logic execution operations are written in code. In this application, technicians pre-configure all business logic execution operations for each vehicle model in the form of a business configuration file. Therefore, when business requirements change, they can be quickly implemented simply by modifying the business configuration file, without requiring code modification, thus improving the flexibility of configuration and changes.

[0066] The improved HAL layer code structure provided in the embodiments of this application is given below.

[0067] HAL layer code structure:

[0068] Parser directory;

[0069] Parser code file;

[0070] Configuration file directory;

[0071] Model 0

[0072] Business sequence configuration file for vehicle model 0;

[0073] Model 1

[0074] Business sequence configuration file for vehicle model 1;

[0075] Model 2

[0076] Business sequence configuration file for vehicle type 2;

[0077] Business configurable framework directory;

[0078] Business-configurable framework code files;

[0079] Implement a directory;

[0080] action:

[0081] Connect the business processor code file;

[0082] Focus business processor code files;

[0083] Memory cache business processor code files;

[0084] Silent service processor code file;

[0085] Power business processor code file;

[0086] Volume service processor code file;

[0087] Audio effects processing code file;

[0088] judge:

[0089] Determine the business processor code file.

[0090] As can be seen from the exemplary HAL layer code structure provided in the above embodiments of this application, the HAL layer code is organized into several main parts, namely, a parser directory, a configuration file directory, a business configurable framework directory, and an implementation directory. The parser directory includes the parser code file - ConfigParser.cpp, used to parse the business sequence configuration file (or, the business configuration file). The configuration file directory includes the business sequence configuration files for each vehicle model. Optionally, the business sequence configuration file has the extension .JavaScript Object Notation (JSON). The business configurable framework directory includes the business configurable framework code file - HalBusinessConfigurableFrameworks.cpp, used to execute the core framework code of the HAL layer. The implementation directory includes the specific implementation code for different operations. According to the different operation types, the code files in the implementation directory include action type code files and judgment type code files.

[0091] The business sequence configuration file for each vehicle model includes the business requirements and the corresponding execution order of the business logic involved in that vehicle model. Below is an illustrative example of a business sequence configuration file for a vehicle model provided in this application embodiment.

[0092]

[0093] In the illustrative example of the business sequence configuration file mentioned above, the business logic table contains a business logic, which includes a business requirement and the corresponding operation sequence. For example, the business requirement in the business logic of the example above is "adjust volume," and the corresponding operation sequence is: get volume → not equal to target volume → set to target volume. Specifically, when adjusting the volume, first, the volume is obtained, and then compared with the target volume. If the current volume is not equal to the target volume, the current volume is set to the target volume. The current volume can also be understood as the initial volume before adjustment during this process.

[0094] It should be understood that due to differences in vehicle models, the operation sequence for the same business requirement may differ. For example, both vehicle model 0 and vehicle model 1 might have a business requirement including "adjusting volume." The operation sequence for vehicle model 0 might be: set the volume to the target volume, thus adjusting the current volume to the target volume regardless of whether the initial volume equals the target volume. The operation sequence for vehicle model 1 might be: get volume → not equal to target volume → set to target volume. In this sequence, if the current volume equals the target volume, the current volume will not be set.

[0095] In addition to the different operation sequences corresponding to the same business needs under different vehicle models, the number of business needs corresponding to different vehicle models may also be different, depending on the actual needs during vehicle operation.

[0096] Based on the HAL layer architecture provided in this application embodiment, when a user has a need to adjust in-vehicle audio, they can initiate the target service request in the vehicle through voice commands or click operations.

[0097] For example, users can output target business requirements through voice commands, such as "turn up the volume in the car," or users can generate target business requirements by clicking the volume adjustment button on the car's volume control interface, and then the target business requirements can be captured by the upper-level software or application.

[0098] Specifically, if the target business requirement is triggered by a voice command, the voice command can be captured by the in-vehicle voice assistant or the voice recognition system within the application, thereby allowing the application to obtain the target business requirement.

[0099] If the target business request is triggered by a click operation, the event listener in the application will listen for the click event and thus obtain the target business requirement.

[0100] As can be seen from the foregoing description, this application embodiment pre-configures multiple business configuration files corresponding to different vehicle models (i.e., the business sequence configuration files mentioned above). When the application receives a target business request, it can find the target vehicle model corresponding to the current vehicle based on the vehicle's basic configuration information and the vehicle model's storage path.

[0101] Once the target vehicle model is determined, the application can search for the target business configuration file that matches the current target vehicle model in the configuration file directory of the HAL code structure.

[0102] For example, such as Figure 1As shown, the configuration parser class -ConfigParser corresponds to the parser code file -ConfigParser.cpp in the previous example, which can read and parse configuration files.

[0103] As shown in the example above, the multiple preset business configuration files include the business sequence configuration file for vehicle model 0, the business sequence configuration file for vehicle model 1, and the business sequence configuration file for vehicle model 2. Each preset business configuration file corresponds to a unique vehicle model. For any given preset business configuration file, it includes multiple business requirements for the vehicle corresponding to the current vehicle model and the business execution sequence (i.e., the operation sequence of the business requirements) corresponding to each business requirement.

[0104] During the process of obtaining the target business configuration file for the target vehicle model, the application can read the target business configuration file for the current target vehicle model from the configuration directory by running the parser code file -ConfigParser.cpp in the ConfigParser of the HAL layer and using the parsing method -parse() in the parser code file.

[0105] Through the above process, the application can obtain the target business configuration file for the target vehicle model.

[0106] 202. Based on the target business requirements, determine the target business execution sequence corresponding to the target business requirements from the target business configuration file.

[0107] After obtaining the target business configuration file corresponding to the target vehicle model, the application can determine the target business execution sequence corresponding to the current target business requirement based on the target business configuration file.

[0108] Specifically, the application can first parse the target business configuration file through the parser class in the HAL layer, and then obtain the target business execution sequence corresponding to the target business requirements based on the parsing result.

[0109] In one possible implementation, the target business execution sequence corresponding to the target business requirement is determined from the target business configuration file, including:

[0110] Parse the target business configuration file and extract multiple key-value pairs consisting of multiple business requirements under the target vehicle model and the business execution sequences corresponding to the multiple business requirements;

[0111] Based on the target business requirements and multiple sets of key-value pairs, determine the target business execution sequence.

[0112] For example, the target business configuration file before parsing is in JSON format. JSON is a structured data exchange format, existing as a string, which is difficult to manipulate directly. Therefore, it is necessary to parse the target business configuration file first, so that the JSON text can be directly converted into a data structure that can be manipulated in the program.

[0113] Specifically, the application can parse the target business configuration file by calling the parsing method -parse() in the ConfigParser of the HAL layer.

[0114] Taking the aforementioned example, the parsed configuration file might look like this: "Adjust volume", "Get volume → Not equal to target volume → Set as target volume". Compared to the original target business configuration file, redundant information has been removed, resulting in each business requirement and its corresponding execution sequence forming a set of key-value pairs. Therefore, after parsing, the target business configuration file contains multiple sets of key-value pairs consisting of multiple business requirements and their corresponding execution sequences.

[0115] After obtaining the parsed key-value pairs, since the current target business requirement is essentially a key in the key-value pairs, the application can further search for the value corresponding to the key in the key-value pairs using the key corresponding to the current target business requirement.

[0116] For example, such as Figure 1 As shown, the HAL business configurable framework implementation class - HalBusinessConfigurableFrameworks class corresponds to the business configurable framework directory file - HalBusinessConfigurableFrameworks.cpp in the aforementioned example.

[0117] After obtaining multiple sets of parsed key-value pairs, ConfigParser stores the collection of these pairs in a configuration table. When the application needs to query the execution sequence corresponding to the current business requirement, it can call the HAL business configurable framework implementation class – HalBusinessConfigurableFrameworks – to control the execution of the configurable framework directory file – HalBusinessConfigurableFrameworks.cpp. When the application needs to determine the target business execution sequence corresponding to the target business requirement, it can access the configuration table in the parser class – ConfigParser – through the HalBusinessConfigurableFrameworks class.

[0118] Furthermore, the application can call the execution function method - execFeature() in the HalBusinessConfigurableFrameworks class, passing in the key corresponding to the current target business requirement. execFeature() accesses the configuration table to find the value corresponding to the key of the current target business requirement, that is, the target business execution sequence.

[0119] In the above technical solution, when determining the target business execution sequence corresponding to the current target business requirement, the target business configuration file is first parsed. This automatically extracts multiple business requirements and their corresponding execution sequences. This automated parsing process reduces manual intervention and improves parsing efficiency. By parsing the configuration file, redundant information can be removed, reducing interference from useless information in the data, making the search and matching process for the target business execution sequence more efficient.

[0120] Through the above process, the application can obtain the target business execution sequence corresponding to the target business requirements.

[0121] 203. Execute the target business requirements according to the target business execution sequence.

[0122] After determining the target business execution sequence, the application can further call methods in various business processors within the HAL layer to execute the aforementioned target business requirements. Specifically, executing the target business requirements involves sequentially calling the methods in the corresponding business processors according to the order of the operation sequence corresponding to the target business requirements.

[0123] In one possible implementation, controlling the operation of at least one vehicle component corresponding to the target business requirement, based on the target business execution sequence, includes:

[0124] Based on the target business execution sequence, determine at least one code file corresponding to the target business requirement from multiple preset code files;

[0125] Execute the target business requirements based on at least one code file and the target business execution sequence.

[0126] Specifically, combining the aforementioned examples and Figure 1 As can be seen, in this embodiment of the application, the specific logic of business processing is configured in the HAL layer in the form of code files. For example... Figure 1The volume service processor, mute service processor, connection service processor, effect service processor, power service processor, memory service processor, and judgment service processor in the example correspond to the volume service processor code file, mute service processor code file, connection service processor code file, sound effect service processor code file, power service processor code file, memory cache service processor code file, and judgment service processor code file in the example above, respectively.

[0127] After determining the target business execution sequence, the application can select at least one code file corresponding to the current target business requirement (or the target business execution sequence) from the above-mentioned multiple preset code files according to the operation order corresponding to the target business execution sequence.

[0128] Specifically, the application can call the execution function method - execFeature() in the HalBusinessConfigurableFrameworks class to parse the target business execution sequence and determine the corresponding business processor and the order in which the business processors are called.

[0129] For example, if the target business requirement is to increase the volume, the corresponding target business execution sequence is: "get volume → not equal to target volume → set to target volume". The `execFeature()` method, through parsing, can determine that the business processors involved in this target business execution sequence include a volume business processor and a judgment business processor. The order in which these two business processors are called is: first the volume business processor, then the judgment business processor.

[0130] Each of the above business processors corresponds to one (or one) code file. The execFeature() method will extract the "volume business processor code file" and the "judgment business processor code file" from the implementation directory.

[0131] After obtaining at least one code file, the application can execute the current target business requirement based on at least one code file and the current target business execution sequence.

[0132] In the above technical solution, after obtaining the target business execution sequence, the vehicle in this application directly locates the code file related to the target business requirement through the target business execution sequence. This ensures that the code file called during execution is highly matched with the business requirement, reducing execution deviations caused by incorrect calls to irrelevant code. When business requirements change, the above steps enable the embodiments of this application to dynamically select the appropriate code file to call according to the business requirements, increasing the robustness of the method.

[0133] It should be understood that, in the embodiments of this application, a single code file may contain multiple methods (or functions) for implementing different functionalities. For example Figure 1 The volume service handler's corresponding volume service processing code file includes "setVolume()" and "getVolume()". Similarly, the mute service handler's corresponding mute service processing code file includes "setMute()" and "getMute()".

[0134] Therefore, after obtaining at least one code file, the application first needs to call the HAL layer to determine the target method for executing the current target business execution sequence from the multiple methods included in the code file.

[0135] In one possible implementation, the target business requirement is executed based on at least one code file and the target business execution sequence, including:

[0136] For any one of the at least one code file, determine the implementation code of the target method in the code file used to execute the target business execution sequence, based on the target business execution sequence;

[0137] The implementation code of the target method is invoked to execute the target business requirement.

[0138] It should be understood that a business execution sequence is generally a sequence of method identifiers, and it is not the code itself used to execute the methods. For example, in the previous example, the business execution sequence is "get volume → not equal to target volume → set to target volume", which is identified by the corresponding method identifiers as "getVolume(currentVolume) → isNotEqual(currentVolume,TargetVolume) → setVolume(TargetVolume)". The method identifiers involved are... Figure 1 The methods for "get volume", "equal to", and "set volume" are listed in the table.

[0139] These methods are implemented through code. Therefore, after obtaining at least one code file corresponding to the current target business execution sequence, the application needs to use the HAL layer to determine the implementation code of the target methods contained in the aforementioned target business execution sequence from at least one code file.

[0140] For example, for any one of the at least one code file, the application can call the control configurable framework directory file - HalBusinessConfigurableFrameworks.cpp file in the HAL layer to run. During the execution of this code file, the code block of the target method in the target business execution sequence included in the current code file can be determined from the code file based on the current target business execution sequence.

[0141] For any given code file, there is a mapping relationship between multiple sets of methods and the corresponding implementation code of each set of methods. During the execution of the HalBusinessConfigurableFrameworks.cpp file, the implementation code of the target method can be determined by matching the method name in the target business execution sequence in the current code file.

[0142] like Figure 1 As shown, during the execution of the HalBusinessConfigurableFrameworks.cpp file, HAL first determines the business logic processor corresponding to the current method name for any method name in the target business execution sequence, then determines the corresponding business processor (i.e., code file) based on the business logic processor, and determines the implementation code corresponding to the current method from the mapping relationship between multiple methods and implementation code of the business processor based on the current method name.

[0143] Thus, by performing similar operations on each of the at least one code file, the application can determine the implementation code of all methods in the current target business execution sequence, and execute the current target business requirement by running or calling the implementation code of all methods.

[0144] In the above technical solution, during the execution of target business requirements, the implementation code of the target method required to implement the current sequence is accurately located through the target business execution sequence. This makes the code structure more modular, avoids unnecessary execution of the entire code file, improves the efficiency of business requirement execution, and reduces unnecessary computing resources. Furthermore, by only selecting the implementation code of methods related to the current business execution sequence, the method of this application can flexibly adapt to different business requirements without changing the overall code architecture. This allows the same code to be called multiple times in different business requirements, improving code reusability and reducing development costs.

[0145] Specifically, in the process of executing target business requirements based on the implementation code of the target method, the process of the application calling the implementation code of the target method and executing the target business requirements varies depending on the type of method.

[0146] In one possible implementation, the implementation code that calls the target method executes the target business requirement, including:

[0147] Get the type of the target method. The type of the target method is used to represent the execution process of the implementation code of the target method.

[0148] If the target method is of type gettable, call the implementation code of the target method to get the current parameters of the target method;

[0149] If the target method is a conditional judgment type, call the implementation code of the target method to obtain the current parameter and the target parameter of the target method; determine the comparison result between the current parameter and the target parameter of the target method.

[0150] The type of the target method is used to represent the execution process of the implementation code of the target method.

[0151] Optionally, this application provides three different method types: acquisition type, condition judgment type, and setting type.

[0152] Methods for retrieving types refer to methods used to retrieve or obtain specific attributes, states, or data from an object or system.

[0153] Conditional statements are used to check whether a certain condition is met, and they usually return a boolean value.

[0154] Setting types are methods used to set or modify specific properties, states, or data of an object or system.

[0155] In this context, the implementation code for methods that retrieve the type and those that conditionally check the type typically does not change the object's state during runtime. However, the implementation code for methods that set the type may involve changing the object's state during runtime. For example, methods that retrieve the type include `getVolume()` (as mentioned above), methods that conditionally check the type include `isEqual()` (as mentioned above), and methods that set the type include `setVolume()` (as mentioned above).

[0156] In this embodiment, a corresponding type can be pre-defined and stored for each method. Based on this, once the application determines any target method in the target business execution sequence, the type of the current target method can be determined.

[0157] When the target method is of type getter, the application, in the process of calling the implementation code of the target method through the HAL layer to execute the target business requirement, is essentially obtaining the current parameters of the target method. Here, the parameters of the target method refer to the input values ​​of that method.

[0158] For example, when the target method is getVolume(), it typically retrieves the current volume value in the application by default. Therefore, the implementation code corresponding to the target method will directly obtain the current volume value in the current application during runtime and use the current volume value as the current parameter of getVolume(), thereby achieving the operation related to the target method for obtaining the type in the target business requirement.

[0159] When the target method is a conditional judgment type, when the application calls the implementation code of the target method through the HAL layer to execute the target business requirement, it is essentially comparing the current parameter and the target parameter of the method and returning the comparison result.

[0160] Regarding the current parameter, during the execution of the target method's implementation code, the application can obtain the current parameter of the target method of the current conditional judgment type through the type-getting method in the HAL layer. The target parameter of the target method can be carried in the user's target business requirement or a parameter pre-set in the method. The process of obtaining the target parameter will be described below. After obtaining the current parameter and target parameter of the target method, during the execution of the target method's implementation code, by comparing the current parameter and target parameter, the comparison result can be obtained, thereby achieving the operation of the target method related to the conditional judgment type in the target business requirement.

[0161] For example, when the target method is isEqual(currentValue, TargetValue), if the target business requirement is to increase the volume, then currentValue refers to currentVolume, and TargetValue refers to TargetVolume. Therefore, during runtime, the implementation code corresponding to the target method will directly obtain the current volume value and the target volume value in the current application, compare whether the current volume value and the target volume value are equal, and return the comparison result.

[0162] In another scenario, when the target method is of type setter, the implementation code of this type of target method involves the control of hardware devices during runtime.

[0163] One possible implementation method also includes:

[0164] If the target method is of type setter, call the implementation code of the target method to obtain the target parameter of the target method;

[0165] Generate target control instructions based on the target parameters of the target method;

[0166] The target method sends target control instructions to the hardware device driver corresponding to the target control instructions, so that the hardware device driver controls the target hardware device corresponding to the hardware device driver to run with the target parameters of the target method based on the target control instructions.

[0167] When the target method is of type set, when the application calls the implementation code of the target method through the HAL layer to execute the target business requirement, it is essentially equivalent to setting the running parameters of the hardware device related to the current business requirement to the target parameters of the target method.

[0168] For example, when the target method is `setVolume(TargetVolume)`, the application, after obtaining the target parameter (e.g., the target volume value) of the target method, can use a specific method function to convert the target parameter into a target control instruction that the hardware device can understand, and then send the target control instruction to the hardware device driver that communicates with the hardware device. After receiving the target control instruction, the hardware device driver can adjust the state of the hardware device (e.g., a power amplifier or audio playback device) according to the content of the target control instruction to make its volume reach the target volume.

[0169] Therefore, the above process is the specific implementation process of different types of methods in the execution of target business requirements.

[0170] In the above technical solution, based on the differences in the method types involved in the target business execution sequence, this application proposes specific execution operations when implementing target business requirements through different types of methods. The vehicle can automatically adjust its operation process according to the type of the target method, executing different business operations, enabling the vehicle to adapt to various types of business requirements. Since the implementation logic of the same method is fixed, the above process eliminates the need to rewrite execution logic for each method when different business requirements involve the same method, improving code versatility.

[0171] The process of obtaining the target parameters mentioned above is described below.

[0172] In one possible implementation, the steps for obtaining the target parameter of the target method include:

[0173] Semantic recognition is performed on the target business requirements to obtain multiple keywords included in the target business requirements;

[0174] Determine whether multiple keywords include parameter keywords;

[0175] When multiple keywords include parameter keywords, the parameters corresponding to the parameter keywords are determined as the target parameters of the target method;

[0176] In cases where multiple keywords do not include parameter keywords, determine whether the target business execution sequence includes the preset parameters of the target method;

[0177] If the target business execution sequence includes preset parameters, the preset parameters will be determined as the target parameters of the target method.

[0178] If the target business execution sequence does not include preset parameters, the previous parameter in the previous call process of the target method will be determined as the target parameter of the target method.

[0179] Specifically, the process of obtaining the target parameters of the target method in the embodiments of this application can be roughly divided into three ways: obtaining the target parameters from the target business requirements, determining the preset parameters as the target parameters, or determining the previous parameters as the target parameters.

[0180] After receiving the target business requirement, the application can use natural language processing (NLP) technology to perform semantic recognition on the requirement and identify multiple keywords. For example, if the target business requirement is "turn the volume up to 70%", then after recognizing the target business requirement, the keywords obtained will include "volume" and "70%".

[0181] When a target business requirement is received, the corresponding method can also be determined simultaneously. Therefore, the application only needs to determine whether the aforementioned keywords include parameter keywords related to the target method's parameters. Specifically, parameter keywords refer to keywords that directly correspond to the parameters required by the target method. For example, 70% in the example above is a parameter keyword.

[0182] When multiple keywords are identified, including parameter keywords, the application can directly determine the parameters corresponding to the parameter keywords as the target parameters of the target method and pass them to the target method in the HAL layer.

[0183] In situations where multiple keywords do not include parameter keywords, technical personnel may pre-set preset parameters in the target method when configuring the business execution sequence corresponding to business requirements. For example, when the target method is `setVolume(TargetVolume)`, if the target business requirement does not contain `TargetVolume`, the application can, after obtaining the target business execution sequence corresponding to the target business requirement, directly check whether the parameters of methods of the conditional or setter type in the target business execution sequence are empty to determine whether the target business execution sequence contains the preset parameters of the current method.

[0184] If the parameter of this method is not empty, then the parameter of the current method is determined to be the preset parameter (i.e., the target parameter). If the parameter of this method is empty, in order to retain the user's driving habits in the historical adjustment process, the application can call... Figure 1 The memory service handler, MemoryCacheHandler, retrieves the previous parameter from the previous method call and determines it as the target parameter of the current method. Here, "previous parameter" can be understood as the previous target parameter from the previous call.

[0185] It should be understood that when the target parameter is the same as the previous parameter, the previous parameter is either the initial parameter or the current parameter before adjustment during this execution. When the current parameter equals the target parameter, there may be two business execution sequences during the execution of business requirements: one is to not adjust when the current parameter is determined to be equal to the target parameter; the other is to forcibly adjust to the target parameter regardless of whether the current parameter is equal to the target parameter. The specific execution can be set according to the actual situation, and this application embodiment does not limit this.

[0186] In the above technical solution, when determining the target parameters of the target method, if the target business requirement includes parameter keywords, the parameters corresponding to the parameter keywords are directly used as the target parameters. This allows for adherence to the user's subjective adjustment needs, improving the user experience, especially when the user has a clear intention to adjust the parameters. When the user does not specify any adjustment parameters, the preset parameters in the target business execution sequence are used first, ensuring consistency of the target method across different calling scenarios. When there are no preset parameters in the target business execution sequence, the previous parameter is used as the target parameter. This preserves the user's historical adjustment habits and avoids adjustment interruptions caused by missing parameters.

[0187] In summary, this application provides a method for executing vehicle business logic. Specifically, a corresponding business configuration file is first configured for each vehicle model. When a user's target business requirement is received, the target business configuration file corresponding to the current target vehicle model is determined from the preset business configuration files of multiple vehicle models. The business configuration file provided in this application contains multiple business requirements and the corresponding business execution sequences. Based on this, the vehicle can determine the target business execution sequence corresponding to the current target business requirement based on the business configuration file, and then execute the target business requirement according to the target business execution sequence. The above process can separate business logic from the code and configure business rules separately for each vehicle model in the form of a business configuration file. When business requirements change, they can be quickly implemented by simply modifying the business configuration file, without the need for large-scale code modifications and recompilation, reducing the risk of frequent code modifications, enhancing the flexibility of configuration and changes, and reducing the workload of staff.

[0188] To understand the overall implementation process of the embodiments of this application, the following will be used... Figure 3 The overall implementation process of the embodiments of this application will be described.

[0189] Figure 3 This is a schematic flowchart illustrating another method for executing vehicle business logic provided in an embodiment of this application.

[0190] For example, such as Figure 3 As shown, the method 300 includes the following steps 301 to 312.

[0191] 301. In response to the target business requirements, based on the target vehicle model, the target business configuration file corresponding to the target vehicle model is determined from multiple preset business configuration files. The multiple preset business configuration files are business configuration files corresponding to multiple different vehicle models. The target business configuration file includes the mapping relationship between the target business requirements and the target business execution sequence corresponding to the target business requirements.

[0192] 302. Parse the target business configuration file and extract multiple key-value pairs consisting of multiple business requirements under the target vehicle model and the business execution sequences corresponding to the multiple business requirements.

[0193] 303. Based on the target business requirements and multiple sets of key-value pairs, determine the target business execution sequence.

[0194] 304. Based on the target business execution sequence, determine at least one code file corresponding to the target business requirement from multiple preset code files.

[0195] 305. For any one of the at least one code file, determine the implementation code of the target method in the code file used to execute the target business execution sequence, based on the target business execution sequence.

[0196] 306. Get the type of the target method. The type of the target method is used to represent the execution process of the implementation code of the target method.

[0197] Depending on the type of target method, the process of executing business requirements corresponds to three situations: the execution process corresponding to step 307, the execution process corresponding to steps 308 to 309, and the execution process corresponding to steps 310 to 312.

[0198] 307. If the target method is of type gettable, call the implementation code of the target method to get the current parameters of the target method.

[0199] 308. If the target method is a conditional judgment type, call the implementation code of the target method to obtain the current parameters and target parameters of the target method.

[0200] 309. Determine the comparison result between the current parameters of the target method and the target parameters of the target method.

[0201] 310. If the target method is of type setter, call the implementation code of the target method to obtain the target parameter of the target method.

[0202] 311. Generate target control instructions based on the target parameters of the target method.

[0203] 312. Through the target method, the target control instruction is sent to the hardware device driver corresponding to the target control instruction, so that the hardware device driver controls the target hardware device corresponding to the hardware device driver to run with the target parameters of the target method based on the target control instruction.

[0204] The specific processes of steps 301 to 312 in the above method 300 have the same inventive concept as steps 201 to 203 in the aforementioned method 200, and will not be repeated here.

[0205] The implementation process of the embodiments of this application will be further described below based on the HAL layer architecture.

[0206] Figure 4 This is an interactive flowchart of the vehicle business logic execution process provided in an embodiment of this application.

[0207] For example, such as Figure 4 As shown, Figure 4 This describes the implementation process for a possible volume control requirement in an audio system. The entire process is described below, and can be broadly divided into the following stages:

[0208] Phase 1: Initialization

[0209] First, upon receiving the current volume control request, the AudioFlinger initializes by calling the HAL's open() method. HAL then calls the init() method in HalBusinessConfigurableFrameworks for further initialization.

[0210] Phase Two: Configuration Resolution Phase

[0211] After initialization, HAL calls the parse() method of ConfigParser to obtain the business configuration file for the current vehicle model, and parses the business configuration file to obtain multiple business requirements in the business configuration file and the business execution sequence corresponding to each business requirement.

[0212] Phase 3: Business Requirement Processing Phase

[0213] For example, such as Figure 4 As shown, this embodiment of the application takes "volume setting request" as an example to illustrate the business requirement.

[0214] When the volume needs to be set, AudioFlinger sends a request to HAL by calling setAudioPortConfig().

[0215] After receiving the request, HAL calls the `execFeature(FEATURE_VOLUME, requestingVolume)` method to execute the volume-related business logic. Here, `requestingVolume` is the same as the `TargetVolume` mentioned earlier.

[0216] Specifically, HAL obtains volume-related business configurations from HalBusinessConfigurableFrameworks by calling the getFeatureBusinessConfig() method. That is, it determines the business execution sequence corresponding to the volume setting request from the business requirements and the corresponding business execution sequences obtained from the above parsing.

[0217] For example, in this embodiment of the application, it is assumed that the business execution sequence corresponding to the volume setting request is "getVolume()→isEqual()→setVolume()→isEqual(0)→setMute()".

[0218] Based on the current business execution sequence, HAL first obtains the current volume value from VolumeHandler through the getVolume() method, and VolumeHandler returns currentVolume.

[0219] HAL compares the requested volume value with the current volume value using the `isEqual(currentVolume, requestingVolume)` method. If the two values ​​are not equal, the volume setting logic continues; if they are equal, no further action is needed. If the requested volume value is not equal to the current volume value, HAL calls the `setVolume(requestingVolume)` method to set the new volume value to the requested volume value.

[0220] After the settings are complete, HAL uses the `isEqual()` method to check if the requested volume is muted. If the requested volume value is 0, it means that muting is required, and HAL calls the `setMute()` method to set the device to mute. Once the above business execution sequence is completed, HAL returns the result to AudioFlinger, completing the entire volume control business process.

[0221] Optionally, the configuration parsing stage in the second stage described above can also be an operation triggered after receiving the business requirements; this embodiment of the application does not limit this.

[0222] Figure 5 This is a schematic diagram of the structure of a device for executing vehicle business logic provided in an embodiment of this application.

[0223] For example, such as Figure 5 As shown, the device 500 includes:

[0224] The configuration file determination module 501 is used to respond to the target business requirements and determine the target business configuration file corresponding to the target vehicle model from multiple preset business configuration files according to the target vehicle model. The multiple preset business configuration files are business configuration files corresponding to multiple different vehicle models. The target business configuration file includes the mapping relationship between the target business requirements and the target business execution sequence corresponding to the target business requirements.

[0225] The execution sequence determination module 502 is used to determine the target business execution sequence corresponding to the target business requirement from the target business configuration file based on the target business requirement;

[0226] The business requirement execution module 503 is used to execute the target business requirement according to the target business execution sequence.

[0227] In one possible implementation, the execution sequence determination module 502 is specifically used to: parse the target business configuration file, extract multiple key-value pairs consisting of multiple business requirements under the target vehicle model and the business execution sequences corresponding to the multiple business requirements; and determine the target business execution sequence based on the target business requirements and the multiple key-value pairs.

[0228] In one possible implementation, the business requirement execution module 503 is specifically used to: determine at least one code file corresponding to the target business requirement from multiple preset code files according to the target business execution sequence; and execute the target business requirement according to the at least one code file and the target business execution sequence.

[0229] In one possible implementation, the business requirement execution module 503 is further configured to: for any one of the at least one code file, determine the implementation code of the target method in the code file used to execute the target business execution sequence according to the target business execution sequence; and call the implementation code of the target method to execute the target business requirement.

[0230] In one possible implementation, the business requirement execution module 503 is further configured to: obtain the type of the target method, the type of the target method being used to represent the execution process of the implementation code of the target method; if the type of the target method is an acquisition type, call the implementation code of the target method to obtain the current parameters of the target method; if the type of the target method is a condition judgment type, call the implementation code of the target method to obtain the current parameters and the target parameters of the target method; and determine the comparison result between the current parameters and the target parameters of the target method.

[0231] In one possible implementation, the business requirement execution module 503 is further configured to: when the type of the target method is a setting type, call the implementation code of the target method to obtain the target parameters of the target method; generate a target control instruction based on the target parameters of the target method; and send the target control instruction to the hardware device driver corresponding to the target control instruction through the target method, so that the hardware device driver controls the target hardware device corresponding to the hardware device driver to run with the target parameters of the target method based on the target control instruction.

[0232] In one possible implementation, the business requirement execution module 503 is further configured to: perform semantic recognition on the target business requirement to obtain multiple keywords included in the target business requirement; determine whether the multiple keywords include parameter keywords; if the multiple keywords include the parameter keywords, determine the parameter corresponding to the parameter keywords as the target parameter of the target method; if the multiple keywords do not include the parameter keywords, determine whether the target business execution sequence includes a preset parameter of the target method; if the target business execution sequence includes the preset parameter, determine the preset parameter as the target parameter of the target method; if the target business execution sequence does not include the preset parameter, determine the previous parameter in the previous call process of the target method as the target parameter of the target method.

[0233] Figure 6 This is a schematic diagram of the structure of a vehicle provided in an embodiment of this application.

[0234] For example, such as Figure 6 As shown, the vehicle 600 includes a memory 601 and a processor 602. The memory 601 stores executable program code 6011, and the processor 602 is used to call and execute the executable program code 6011 to perform a method for executing vehicle business logic.

[0235] Furthermore, embodiments of this application also protect an apparatus that may include a memory and a processor, wherein the memory stores executable program code, and the processor is used to call and execute the executable program code to execute a method for executing vehicle business logic provided in embodiments of this application.

[0236] This embodiment can divide the device into functional modules based on the above method example. For example, each module can correspond to a separate function, or two or more functions can be integrated into one processing module. The integrated module can be implemented in hardware. It should be noted that the module division in this embodiment is illustrative and only represents one logical functional division. In actual implementation, there may be other division methods.

[0237] When each functional module is divided according to its corresponding function, the device may further include a configuration file determination module, an execution sequence determination module, and a business requirement execution module. It should be noted that all relevant content regarding the steps involved in the above method embodiments can be referenced in the functional descriptions of the corresponding functional modules, and will not be repeated here.

[0238] It should be understood that the apparatus provided in this embodiment is used to execute the above-described method for executing vehicle business logic, and therefore can achieve the same effect as the above-described implementation method.

[0239] When using an integrated unit, the device may include a processing module and a storage module. When the device is applied to a vehicle, the processing module can be used to control and manage the vehicle's movements. The storage module can be used to support the vehicle in executing relevant program code.

[0240] The processing module may be a processor or a controller, which can implement or execute various exemplary logic blocks, modules, and circuits shown in conjunction with the disclosure of this application. The processor may also be a combination of functions that implement computing capabilities, such as a combination of one or more microprocessors, a combination of digital signal processing (DSP) and microprocessors, etc., and the storage module may be a memory.

[0241] In addition, the apparatus provided in the embodiments of this application may specifically be a chip, component or module. The chip may include a connected processor and a memory. The memory is used to store instructions. When the processor calls and executes the instructions, the chip can execute a method for executing vehicle business logic provided in the above embodiments.

[0242] This embodiment also provides a computer-readable storage medium storing computer program code. When the computer program code is run on a computer, the computer executes the above-described related method steps to implement a method for executing vehicle business logic provided in the above embodiment.

[0243] This embodiment also provides a computer program product that, when run on a computer, causes the computer to perform the aforementioned related steps to implement a method for executing vehicle business logic provided in the above embodiment.

[0244] In this embodiment, the device, computer-readable storage medium, computer program product, or chip are all used to execute the corresponding methods provided above. Therefore, the beneficial effects they can achieve can be referred to the beneficial effects in the corresponding methods provided above, and will not be repeated here.

[0245] Through the above description of the embodiments, those skilled in the art will understand that, for the sake of convenience and brevity, only the division of the above functional modules is used as an example. In actual applications, the above functions can be assigned to different functional modules as needed, that is, the internal structure of the device can be divided into different functional modules to complete all or part of the functions described above.

[0246] In the embodiments provided in this application, it should be understood that the disclosed devices and methods can be implemented in other ways. For example, the device embodiments described above are merely schematic. For example, the division of modules or units is only a logical function division. In actual implementation, there may be other division methods, such as multiple units or components can be combined or integrated into another device, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be through some interfaces, indirect coupling or communication connection of devices or units, which can be electrical, mechanical or other forms.

[0247] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A method for executing vehicle business logic, characterized in that, The method includes: In response to target business requirements, based on the target vehicle model, a target business configuration file corresponding to the target vehicle model is determined from multiple preset business configuration files. The multiple preset business configuration files are business configuration files corresponding to multiple different vehicle models. The target business configuration file includes a mapping relationship between the target business requirements and the target business execution sequence corresponding to the target business requirements. Based on the target business requirements, determine the target business execution sequence corresponding to the target business requirements from the target business configuration file; Execute the target business requirements according to the target business execution sequence.

2. The method according to claim 1, characterized in that, The step of determining the target business execution sequence corresponding to the target business requirement from the target business configuration file based on the target business requirement includes: The target business configuration file is parsed to extract multiple key-value pairs consisting of multiple business requirements under the target vehicle model and the business execution sequences corresponding to the multiple business requirements; Based on the target business requirements and the multiple sets of key-value pairs, the target business execution sequence is determined.

3. The method according to claim 1, characterized in that, The step of executing the target business requirement according to the target business execution sequence includes: Based on the target business execution sequence, at least one code file corresponding to the target business requirement is determined from multiple preset code files; The target business requirement is executed based on the at least one code file and the target business execution sequence.

4. The method according to claim 3, characterized in that, The step of executing the target business requirement based on the at least one code file and the target business execution sequence includes: For any one of the at least one code file, the implementation code of the target method in the code file for executing the target business execution sequence is determined according to the target business execution sequence; The implementation code of the target method is invoked to execute the target business requirement.

5. The method according to claim 4, characterized in that, The execution of the target business requirement by calling the implementation code of the target method includes: Obtain the type of the target method, whereby the type of the target method represents the execution process of the implementation code of the target method; If the type of the target method is a getter type, the implementation code of the target method is called to obtain the current parameters of the target method; If the target method is a conditional judgment type, the implementation code of the target method is called to obtain the current parameters and target parameters of the target method; the comparison result between the current parameters and target parameters of the target method is determined.

6. The method according to claim 5, characterized in that, The method further includes: If the type of the target method is a setting type, the implementation code of the target method is called to obtain the target parameters of the target method; Based on the target parameters of the target method, generate target control instructions; The target method sends the target control instruction to the hardware device driver corresponding to the target control instruction, so that the hardware device driver controls the target hardware device corresponding to the hardware device driver to run with the target parameters of the target method based on the target control instruction.

7. The method according to claim 6, characterized in that, The steps for obtaining the target parameters of the target method include: Semantic recognition is performed on the target business requirement to obtain multiple keywords included in the target business requirement; Determine whether the plurality of keywords includes parameter keywords; When the plurality of keywords include the parameter keyword, the parameter corresponding to the parameter keyword is determined as the target parameter of the target method; If the multiple keywords do not include the parameter keyword, determine whether the target business execution sequence includes the preset parameters of the target method; If the target service execution sequence includes the preset parameters, the preset parameters are determined as the target parameters of the target method; If the target business execution sequence does not include the preset parameters, the previous parameter in the previous call process of the target method is determined as the target parameter of the target method.

8. An apparatus for executing vehicle business logic, characterized in that, The device includes: The configuration file determination module is used to respond to target business requirements and determine the target business configuration file corresponding to the target vehicle model from multiple preset business configuration files based on the target vehicle model. The multiple preset business configuration files are business configuration files corresponding to multiple different vehicle models. The target business configuration file includes the mapping relationship between the target business requirements and the target business execution sequence corresponding to the target business requirements. An execution sequence determination module is used to determine the target business execution sequence corresponding to the target business requirement from the target business configuration file based on the target business requirement; The business requirement execution module is used to execute the target business requirement according to the target business execution sequence.

9. A vehicle, characterized in that, The vehicles include: Memory, used to store executable program code; A processor for calling and running the executable program code from the memory, causing the vehicle to perform the method as described in any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when executed, implements the method as described in any one of claims 1 to 7.

Images