Vehicle interface calling method and vehicle

Abstract

The embodiment of the invention provides a vehicle interface calling method and a vehicle, and relates to the technical field of vehicle technology and electric vehicle communication. The method comprises the steps that a function execution request is obtained, and the function execution request is used for indicating a vehicle to execute a target function; a service unit calling list is determined based on the function execution request, the service unit calling list is used for indicating to-be-called target service units, and signal information, performance indexes and attribute information of target controllers in the vehicle and a calling sequence among the target controllers are packaged in the target service units; analyzing the service unit calling list to obtain a target controller and a target interface corresponding to the target controller; and controlling the target controller to call the target interface based on the call sequence to execute the target function. According to the method and the device, the technical problem that signals are complicated and redundant due to the fact that signal interfaces are defined on the basis of functions and platform requirements for generalization cannot be met in the prior art is solved.

Description

Vehicle interface call methods and vehicles Technical Field

[0001] This application relates to vehicle technology and electric vehicle communication technology, specifically to a vehicle interface calling method and a vehicle. Background Technology

[0002] With the popularization of intelligent connected vehicles, electric vehicle communication technology is facing a transformation from the traditional function-defined model to a capability-driven architecture. Early signal interface designs focused on specific function implementation, resulting in serious signal redundancy in the vehicle's electronic and electrical architecture, high system redundancy, which not only increased network load but also complicated the compatibility challenges during software version iterations.

[0003] Currently, multi-vehicle platforms generally adopt a function-defined signal interface design, especially in the body control domain, where the signal redundancy rate is as high as 15%-20%. However, the function-defined signal interface design cannot meet the requirements of a universal platform, resulting in complex and redundant signals.

[0004] There is currently no good solution to the above problems. Summary of the Invention

[0005] This application provides a method for calling an interface for a vehicle and a vehicle, so as to at least solve the technical problem in the related art that the function-defined signal interface cannot meet the general platform requirements, resulting in complex and redundant signals.

[0006] According to one aspect of the embodiments of this application, a method for invoking an interface of a vehicle is provided, comprising: obtaining a function execution request, wherein the function execution request is used to instruct the vehicle to execute a target function; determining a service unit invocation list based on the function execution request, wherein the service unit invocation list is used to indicate a target service unit to be invoked, the target service unit encapsulating signal information, performance indicators, attribute information of a target controller in the vehicle, and the invocation order among target controllers; parsing the service unit invocation list to obtain a target controller and a target interface corresponding to the target controller; and controlling the target controller to invoke the target interface based on the invocation order to execute the target function.

[0007] Furthermore, the method also includes: obtaining a capability description document for a device in the vehicle, wherein the capability description document describes the signal capabilities and attributes provided by the device; generating an atomic signal library based on the capability description document; determining an atomic signal combination based on a preset target function and the atomic signal library, wherein the atomic signal combination is a set of atomic signals in the atomic signal library that perform the target function; and generating a service unit call list based on the atomic signal combination.

[0008] Furthermore, generating an atomic signal library based on a capability description document includes: extracting signals from the capability description document to obtain signal extraction results, wherein the signal extraction results are used to represent the signal capabilities and attributes of the device; standardizing the signal extraction results based on a preset template to obtain standardized signals, wherein the preset template is used to provide definition rules and formats for signal interfaces, and the standardized signals have the same signal format and communication protocol; establishing a device abstraction matrix table based on the standardized signals, wherein the device abstraction matrix table is used to convert the standardized signals of the device into abstract functional signals; and establishing a mapping relationship between the abstract functional signals and the physical interfaces of the device based on electronic control unit software to generate an atomic signal library.

[0009] Furthermore, establishing a device abstraction matrix table based on standardized signals includes: establishing a device abstraction matrix table based on signal abstraction principles and standardized signals, wherein the signal abstraction principles include at least one of the following: standardization principle, used to abstract devices of the same type into a unified interface; minimization principle, used to abstract the core signals that realize the function of the device; atomicity principle, used to ensure that the abstracted functional signals are the smallest indivisible functional units.

[0010] Furthermore, determining the atomic signal combination based on the preset target function and atomic signal library includes: selecting target atomic signals from the atomic signal library based on the target function; encapsulating and combining the target atomic signals based on the signal group of the communication composite object model layer to obtain a first atomic signal combination; performing controller local area network signal packaging processing on the first atomic signal combination using a data exchange format file to obtain a second atomic signal combination; and updating the version number of the second atomic signal combination to obtain the atomic signal combination.

[0011] Furthermore, generating a service unit call list based on atomic signal combinations includes: analyzing the atomic signal combinations to obtain the call requirements of the target controller, wherein the call requirements are used to represent the call order, frequency, and conditions of the target controller; and mapping the signals in the atomic signal combinations to the corresponding service units based on the call requirements to generate a service unit call list.

[0012] Furthermore, the method also includes: verifying the service unit call list using a preset verification strategy, wherein the preset verification strategy includes at least one of the following: performing model-in-the-loop testing on the service unit call list; performing hardware-in-the-loop testing on the service unit call list; and performing regression testing on the service unit call list.

[0013] Furthermore, determining the service unit call list based on the function execution request includes: parsing the function execution request to determine the target function; and determining the service unit call list based on a preset mapping table and the target function, wherein the preset mapping table is used to record the mapping relationship between vehicle functions and the service unit call list.

[0014] Furthermore, the method also includes: managing the versions of atomic signal combinations using semantic versioning specifications, and establishing a change impact assessment template, wherein the change impact assessment template is used to reflect the impact of signal modifications on the target function and the impact on the target controller version.

[0015] According to another aspect of the embodiments of this application, a vehicle interface invocation device is also provided, comprising: an acquisition module, configured to acquire a function execution request, wherein the function execution request is used to instruct the vehicle to execute a target function; a determination module, configured to determine a service unit invocation list based on the function execution request, wherein the service unit invocation list is used to indicate a target service unit to be invoked, the target service unit encapsulating signal information, performance indicators, attribute information, and invocation order of a target controller in the vehicle; a parsing module, configured to parse the service unit invocation list to obtain a target controller and a target interface corresponding to the target controller; and an invocation module, configured to control the target controller to invoke the target interface based on the invocation order to execute the target function.

[0016] According to another aspect of the embodiments of this application, a vehicle is also provided, including: a memory storing an executable program; and a processor for running the program, wherein the program executes the methods in various embodiments of this application when it runs.

[0017] According to another aspect of the embodiments of this application, a computer-readable storage medium is also provided, the computer-readable storage medium including a stored executable program, wherein, when the executable program is running, it controls the device where the computer-readable storage medium is located to perform the methods of various embodiments of this application.

[0018] According to another aspect of the embodiments of this application, a computer program product is also provided, including a computer program that, when executed by a processor, implements the methods of various embodiments of this application.

[0019] In this embodiment, a function execution request is obtained, which instructs the vehicle to perform a target function. A service unit call list is determined based on the function execution request. This list indicates the target service unit to be called, and each target service unit encapsulates the signal information, performance indicators, attribute information, and calling order of the target controllers in the vehicle. The service unit call list is parsed to obtain the target controller and its corresponding target interface. Based on the calling order, the target controller is controlled to call the target interface to execute the target function. This achieves unified signal management and optimized resource allocation, thereby simplifying the signal system, accelerating function iteration, and enhancing system versatility. It also solves the technical problem in related technologies where function-defined signal interfaces cannot meet the requirements of a universal platform, resulting in complex and redundant signals. Attached Figure Description

[0020] The accompanying drawings, which are included to provide a further understanding of this application and form part of this application, illustrate exemplary embodiments and are used to explain this application, but do not constitute an undue limitation of this application. In the drawings:

[0021] Figure 1 is a flowchart of a vehicle interface calling method according to one embodiment of this application;

[0022] Figure 2 is a flowchart of an in-vehicle service interface design according to one embodiment of this application;

[0023] Figure 3 is an interactive flowchart of the components in a vehicle automatic high beam control system according to one embodiment of the present application;

[0024] Figure 4 is a structural block diagram of a vehicle interface calling device according to one embodiment of the present application. Detailed Implementation

[0025] To enable those skilled in the art to better understand the present application, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present application, and not all embodiments. Based on the embodiments in the present application, all other embodiments obtained by those of ordinary skill in the art without creative effort should fall within the scope of protection of the present application.

[0026] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of this application described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0027] With the rapid development of intelligent connected vehicle technology, the traditional function-defined signal interface design pattern has shown significant limitations. This interface definition approach, driven by specific functional requirements, often results in a large number of redundantly defined signals in the vehicle's electronic and electrical architecture, causing a continuous increase in system redundancy. Statistics show that in vehicle platforms using the function-defined pattern, the signal redundancy rate in the body control domain alone is as high as 15%-20%. This not only increases network load but also presents complex compatibility challenges during software version iterations.

[0028] Currently, the main problems with function-defined signal interfaces include the following:

[0029] (1) High signal redundancy and uncontrolled system complexity.

[0030] Problem Description: Different functional modules repeatedly define the same physical quantities (such as vehicle speed signals being independently defined in multiple electronic control units (ECUs) such as Advanced Driver Assistance Systems (ADAS), instrument clusters, and body control).

[0031] Root cause analysis: Function-oriented design leads each module to focus only on its own needs, lacking overall optimization.

[0032] Challenges: In a distributed architecture, cross-domain signal coordination requires manual matching, and the impact of changes is difficult to assess.

[0033] (2) Poor scalability, unable to adapt to platform requirements.

[0034] Problem Description: Adding new features (such as L3 autonomous driving) requires reconstructing the communication matrix, triggering a chain of modifications.

[0035] Cause analysis: The functions and interfaces are strongly coupled, and the software needs to be adapted synchronously when the hardware capabilities are upgraded.

[0036] Challenges: In the traditional Automotive Open System Architecture (AutoSAR) architecture, signals are bound to specific ECUs, resulting in high migration costs.

[0037] (3) The development efficiency is low and the verification cycle is long.

[0038] Problem: Multiple definitions of the same signal lead to an exponential increase in test cases (if N modules use the vehicle speed signal, N×(N-1) interaction scenarios need to be verified).

[0039] Root cause analysis: Lack of a unified signal semantic library, with each team developing independently.

[0040] The pain points that existing technologies cannot solve are shown in Table 1 below.

[0041] Table 1

[0042]

[0043] In contrast, the signal interface methodology based on controller capability definition represents a fundamental transformation. This approach restructures the signal system through the following three key innovations.

[0044] (1) Atomization capability modeling.

[0045] The physical capabilities of the controller are abstracted into standardized service units. For example, a drive motor controller declares that it can provide basic capabilities such as speed control accuracy of ±5 revolutions per minute (rpm) and torque response delay of <50 milliseconds (ms).

[0046] The autonomous driving domain controller has defined performance indicators such as a target recognition refresh rate of 30 Hz and a positioning accuracy of 0.1 m.

[0047] (2) Dynamic service combination mechanism.

[0048] Functionality implementation = Where n represents the total number of capabilities and interfaces involved in the implementation of the function, and n is a positive integer. This represents the i-th capability or service. This represents the interface weight for the i-th capability.

[0049] By linearly combining the capability matrix, the same set of basic signals can generate a variety of functional scenarios. For example, the automatic parking function only needs to call 0.7×ultrasonic ranging + 0.3×steering angle output.

[0050] (3) Two-way contract verification system.

[0051] A three-dimensional interface contract library is established, including timing constraints, numerical boundaries, and Failure Modes and Effects Analysis (FMEA), to achieve the following technical effects:

[0052] The signal definition repetition rate dropped below 8%;

[0053] OTA upgrades involve 72% fewer interface changes;

[0054] The development cycle for new features has been shortened by 40%.

[0055] This paradigm shift not only solves the signal redundancy problem but also builds a service-oriented, resilient architecture. When adding Level 3 autonomous driving functions, only the semantic understanding layer needs to be extended on the existing environmental perception capability interface, without reconstructing the underlying communication matrix. The software defect (bug) density of vehicle platforms adopting the capability-defined model will be significantly reduced.

[0056] The aforementioned functional definition of the signal interface cannot meet the general platform requirements, leading to technical problems of complex and redundant signals. This application defines the signal interface according to the controller's capabilities, which can solidify the general smallest signal unit, meet the calling requirements of different functions, reduce the repeated definition of signals, simplify software development content, improve software development efficiency, and increase signal scalability.

[0057] According to an embodiment of this application, a method embodiment for a vehicle interface invocation method is provided. It should be noted that the steps shown in the flowchart in the accompanying drawings can be executed in a computer system such as a set of computer-executable instructions. Furthermore, although a logical order is shown in the flowchart, in some cases, the steps shown or described may be executed in a different order than that shown here.

[0058] This embodiment provides a method for invoking a vehicle's interface. Figure 1 is a flowchart of a method for invoking a vehicle's interface according to one embodiment of this application. As shown in Figure 1, the process includes the following steps:

[0059] Step S11: Obtain a function execution request, wherein the function execution request is used to instruct the vehicle to perform a target function.

[0060] In this embodiment, the function execution request can be an instruction triggered by the user through voice commands or touch screen gestures, or it can be a signal or instruction issued by a certain part of the vehicle (such as the Human-Machine Interface (HMI), automatic system, vehicle network, etc.) that requires the vehicle to perform a specific function.

[0061] A function execution request can be a simple on / off command (such as turning on automatic high beams) or a complex sequence of operations (such as performing an automatic parking process). For example, a function execution request may include information such as the identifier (ID) of the target function, execution parameters, and priority, which are not limited here.

[0062] The function execution request is used to instruct the vehicle to perform a target function, such as automatic parking or emergency hazard lights, which is determined according to the requirements and is not limited here.

[0063] For example, the vehicle's central control unit or related subsystems receive a function execution request from the HMI or other systems. This request may be triggered by user operation or by a condition automatically detected by the system. This ensures the vehicle can respond to function requests promptly, improving user experience and system efficiency. Furthermore, the function execution request provides clear execution goals and parameters for subsequent steps, simplifying the complexity of function implementation.

[0064] Step S12: Determine the service unit call list based on the function execution request. The service unit call list is used to indicate the target service unit to be called. The target service unit encapsulates the signal information, performance indicators, attribute information and calling order between the target controllers in the vehicle.

[0065] In this embodiment, the service unit call list is a list containing a series of service units generated based on the received function execution request. This application abstracts the physical capabilities of the controller into standardized service units. The service unit call list is used to indicate the target service unit to be called. The service unit is the smallest independently callable functional unit provided by the controller. Each service unit encapsulates signal information (e.g., what signals the controller can receive and send), performance indicators (e.g., response time, accuracy), attribute information (e.g., signal format, unit, exception handling method), and calling order (i.e., the order in which service units should be called when multiple controllers cooperate), etc., to clarify the specific services and calling process required during function execution.

[0066] Signal information refers to signals contained in the service unit, such as control signals, status signals, and fault signals, used for communication between controllers or between the controller and the application layer.

[0067] Performance metrics include the service unit's response time, accuracy, and data refresh rate, ensuring that the performance requirements for function execution are met.

[0068] Attribute information is inherent information about a service unit or controller, such as type, location, and operating conditions.

[0069] The call order is the time sequence in which the service units are called, ensuring the sequential and temporal execution of functions.

[0070] For example, the system can parse the function execution request and, based on the parsing result, convert the abstract functional requirements into a specific service unit call list by querying the capability description file or database, thus clarifying the specific service units, controllers, signal information, performance indicators, attribute information, and the calling order between controllers required for function execution.

[0071] Therefore, the abstraction and standardization of service units makes the implementation of the same or similar functions more consistent across different vehicle models or platforms, reducing redundant development work. Furthermore, the generation and maintenance of the service unit call list are relatively independent of the specific function implementation, reducing the difficulty of software development and subsequent maintenance. In addition, through the predefined call list, the system can quickly locate the target service unit and controller during function execution, reducing unnecessary signal transmission and processing delays.

[0072] Step S13: Parse the service unit call list to obtain the target controller and the target interface corresponding to the target controller.

[0073] In this embodiment of the application, the process of parsing the service unit call list involves reading the information in the service unit call list, identifying which controllers will be involved in the specific function execution, and the interface (signal group or atomic signal) that each controller should call.

[0074] The target controller is the controller in the vehicle responsible for performing the target function. It can be the body controller, powertrain controller, ADAS controller, etc., and is determined according to the requested target function.

[0075] The target interface is the interface provided by the target controller, used to receive instructions, report status, or process data. It is the direct object called by the service unit.

[0076] For example, the system controller (such as a central gateway) parses the service unit call list, maps each service unit to a specific vehicle controller, and identifies the target interface corresponding to each controller, in preparation for the next step of signal invocation and execution.

[0077] Therefore, the parsing process transforms abstract service unit calls into concrete hardware and software operations, enabling automated control. Furthermore, it ensures that each controller calls the correct interface during function execution, preventing functional failures caused by incorrect interface calls. In addition, when controllers or interfaces are updated, the parsing process can automatically adapt based on the latest capability description files, reducing the workload of system maintenance and functional expansion.

[0078] Step S14: Based on the call sequence, the target controller calls the target interface to execute the target function.

[0079] In this embodiment of the application, the call order control means that according to the call order defined in the service unit call list, the system controller will send signals to each target controller, requesting them to call the target interface in order to execute the assigned service unit.

[0080] For example, based on the parsed service unit call list and its calling order, the system controller directly issues instructions to the target controller, requesting it to call the corresponding target interface and execute the functions defined in the service unit, thereby realizing the execution of the entire function. Thus, execution according to the predefined calling order avoids signal out-of-order issues and conflicts, ensuring the timing and correctness of the function. Furthermore, directly controlling the target controller to call the target interface reduces intermediate steps, speeds up signal transmission and processing, and improves execution efficiency. In addition, adding new functions or updating existing functions only requires modifying the service unit call list, without requiring major adjustments to the entire system architecture, improving the system's flexibility and adaptability.

[0081] In summary, this application establishes a top-down execution path, from abstract function execution requests to the invocation of specific service units, and finally to the direct control of the target controller. This significantly improves the flexibility, efficiency, and reliability of intelligent connected vehicles in implementing complex functions. Compared to the traditional function-driven model, this capability-driven interface design reduces signal redundancy and development cycles, supports platform-based hardware and software requirements, facilitates over-the-air (OTA) technology upgrades and new feature development, reduces software bug density, and improves development and verification efficiency.

[0082] Therefore, this application effectively addresses the challenges of complex and redundant signals in general-purpose platforms based on function-defined signal interfaces by introducing a capability-driven design approach and multi-level signal abstraction. First, it unifies and abstracts controller capabilities to form standardized service units, achieving signal deduplication and reuse. Second, it dynamically combines signals to construct function-independent signal groups, improving the interface's versatility. Finally, it controls according to the calling sequence to ensure efficient signal invocation and reduce invalid communication. The overall process simplifies the signal system, enhances the system's adaptability to new functions, and significantly improves development efficiency and resource utilization.

[0083] The above steps of this application involve obtaining a function execution request, which instructs the vehicle to perform a target function; determining a service unit call list based on the function execution request, whereby the service unit call list indicates the target service unit to be called, and the target service unit encapsulates the signal information, performance indicators, attribute information, and calling order among the target controllers in the vehicle; parsing the service unit call list to obtain the target controller and its corresponding target interface; and controlling the target controller to call the target interface based on the calling order to execute the target function. This achieves the goal of unified signal management and optimized resource allocation, thereby realizing the technical effects of simplifying the signal system, accelerating function iteration, and enhancing system versatility. Furthermore, it solves the technical problem in related technologies where function-defined signal interfaces cannot meet the requirements of a generalized platform, resulting in complex and redundant signals.

[0084] Optionally, the method may further include the following execution steps:

[0085] Step S101: Obtain the capability description document of the device in the vehicle, wherein the capability description document is used to describe the signal capabilities and attributes provided by the device.

[0086] Step S102: Generate an atomic signal library based on the capability description document.

[0087] Step S103: Determine the atomic signal combination based on the preset target function and atomic signal library, wherein the atomic signal combination is a set of atomic signals in the atomic signal library that perform the target function.

[0088] Step S104: Generate a service unit call list based on the combination of atomic signals.

[0089] In this embodiment of the application, when the service unit call list is generated, the capability description documents of the devices in the vehicle are first obtained. Here, "devices in the vehicle" refers to hardware components inside the vehicle used to perform specific tasks, such as the engine control unit (ECU), body control module (BCM), and motor control unit (MCU).

[0090] Capability description documents are used to describe the signal capabilities and attributes provided by a device. These documents detail the signal services the device can provide and their attributes, such as signal name, physical quantity unit, data type, value range, update frequency, and delay time. For example, capability description documents are typically written in standardized formats, such as YAML or JSON, for easy machine reading and processing.

[0091] As can be seen, this application collects and organizes detailed signal capability information of various devices inside the vehicle. By systematically analyzing and recording the signal service capabilities of each device, it lays the foundation for subsequent signal abstraction and combination. This ensures the transparency and traceability of signal services, facilitating precise management and flexible combination of signals in subsequent steps.

[0092] Then, an atomic signal library is generated based on the capability description document.

[0093] An atomic signal library is a collection of the smallest indivisible signal units, each representing an independent physical or logical function of a device. The atomic signal library aims to provide standardized signal interfaces and eliminate redundancy in signal definitions.

[0094] For example, the system will sort out the capabilities of the vehicle's basic components and abstract them into basic signals. That is, it will decompose the signal capabilities of each component into the finest-grained atomic signals and store the atomic signals in a unified database, namely the atomic signal library.

[0095] Thus, the creation of the atomic signal library greatly simplifies signal interface management, facilitates service calls across controllers and platforms, and provides rich and standardized basic signal resources for subsequent function combinations.

[0096] Next, based on the preset target function and the atomic signal library, the atomic signal combination is determined. Here, the atomic signal combination is a set of atomic signals in the atomic signal library that perform the target function. That is, an atomic signal combination is a specific group of atomic signals, and the atomic signals in the combination work together to achieve a certain target function. For example, a combination of "vehicle speed signal," "distance sensor signal," and "braking signal" can be used to implement the "Automatic Emergency Braking system (AEB) function."

[0097] For example, based on the requirements of the target function, the system selects the necessary signal units from the atomic signal library and combines them to achieve the target function. For example, the most efficient signal combination method in the function implementation process can be identified through algorithms or expert experience. Thus, through precise signal combination, efficient matching of functional requirements and signal services is achieved, unnecessary signal transmission is reduced, network load and energy consumption are lowered, and the scalability and interoperability of the system are enhanced.

[0098] Finally, a service unit call list is generated based on the combination of atomic signals.

[0099] For example, after determining the combination of atomic signals, the system will generate a detailed service unit call list. The service unit call list clarifies the calling time, parameter requirements and expected effects of each service unit, providing clear guidance for controller programming and network communication.

[0100] Therefore, the service unit call list ensures the orderliness and coordination of communication between devices, avoids signal conflicts, optimizes signal transmission paths and timing, improves the reliability and real-time performance of function execution, and also facilitates function testing and verification.

[0101] Optionally, in step S102, generating the atomic signal library based on the capability description document may include the following steps:

[0102] Step S1021: Perform signal extraction on the capability description document to obtain signal extraction results, wherein the signal extraction results are used to represent the signal capabilities and attributes of the device.

[0103] Step S1022: Standardize the signal extraction results based on the preset template to obtain standardized signals. The preset template is used to provide the definition rules and format of the signal interface. The standardized signals have the same signal format and communication protocol.

[0104] Step S1023: Establish a device abstract matrix table based on the standardized signal, wherein the device abstract matrix table is used to convert the standardized signal of the device into an abstract functional signal.

[0105] Step S1024: Based on the electronic control unit software, a mapping relationship is established between the abstract functional signals and the physical interface of the device to generate an atomic signal library.

[0106] In this embodiment of the application, when generating an atomic signal library based on a capability description document, signal extraction can be performed on the capability description document to obtain signal extraction results.

[0107] The signal extraction results are used to represent the signal capabilities and attributes of the device. For example, the signal extraction results include a set of device signal capabilities (e.g., switching commands, brightness commands, speed commands, etc.) and attributes (e.g., signal format, communication protocol, physical quantity units of the signal, etc.), providing basic data for subsequent standardization processing.

[0108] As can be seen, by analyzing the capability description document, we can identify the signal capabilities and attribute information that the device can provide, laying the foundation for establishing standardized signals. Therefore, through signal extraction, we can clearly understand the signal capabilities of each device, helping to avoid redundant signal definitions and meaningless redundancy, reducing complexity in the initial stages and improving subsequent processing efficiency.

[0109] Then, the signal extraction results are standardized based on the preset template to obtain a standardized signal.

[0110] The preset template provides the definition rules and format for signal interfaces. In other words, the template defines the standardized format and communication protocol of the signal interfaces to guide standardized signal processing and ensure that all signals conform to a unified standard. For example, the preset template can be an Adaptive Software Component (SWC) for the Automotive Open System Architecture (AUTOSAR).

[0111] Standardized signals have the same signal format and communication protocol. In other words, standardized signals are signals processed according to a preset template, and have a unified format and communication protocol, which facilitates cross-module calling and management.

[0112] As can be seen, the signal capabilities in the extracted signal results are processed according to the rules of the preset template to unify the format and protocol, generating standardized signals. This standardization process ensures signal consistency, facilitates signal management and combination, reduces compatibility issues caused by inconsistent signal formats and protocols, and improves signal reusability.

[0113] Then, a device abstract matrix table is established based on the standardized signals.

[0114] The Device Abstraction Matrix (DAM) is used to convert the standardized signals of a device into abstract functional signals. In other words, the DAM maps various standardized signals of a device to abstract functional signals, forming a matrix table for subsequent logic design of signal combinations.

[0115] As can be seen, further abstracting the standardized signals to form a device abstraction matrix table is used to manage and display the logical relationships of device signal capabilities, facilitating rapid identification and retrieval during subsequent logic design. Therefore, the device abstraction matrix table makes signal capabilities clearer, enabling rapid signal location and combination, reducing design complexity, and improving design efficiency.

[0116] Finally, an atomic signal library is generated by establishing a mapping relationship between abstract functional signals and the physical interface of devices based on the electronic control unit software.

[0117] Electronic control unit software (ECU software) is the software layer responsible for managing the internal logic of the ECU and communicating with other ECUs. It enables signal conversion and coordination of communication protocols.

[0118] As can be seen, the ECU software establishes a mapping relationship between atomic signals and specific physical interfaces based on the device abstraction matrix table, generating an atomic signal library. Therefore, the establishment of the atomic signal library facilitates unified management and flexible signal retrieval, contributing to the construction of a modular and scalable vehicle electronic architecture and reducing the signal design difficulty when developing new functions.

[0119] Optionally, in step S1023, establishing the device abstract matrix table based on the standardized signal may include the following steps:

[0120] Step S10231: Establish a device abstraction matrix table based on signal abstraction principles and standardized signals, wherein the signal abstraction principles include at least one of the following:

[0121] Standardization principles are used to abstract devices of the same type into a unified interface;

[0122] The principle of minimization is used to abstract the core signals that implement the functions of a device.

[0123] The principle of atomicity is used to ensure that abstract functional signals are the smallest indivisible functional units.

[0124] In this embodiment, the signal abstraction principle is a fundamental guideline for signal abstraction processing, aiming to simplify the signal architecture and improve the versatility and reusability of signals. The signal abstraction principle includes at least one of the following:

[0125] Standardization principles are used to abstract devices of the same type into a unified interface. In other words, standardization principles are used to abstract the functional signals of similar devices into a unified interface description, ignoring differences in their physical location or model, thereby achieving signal standardization.

[0126] The principle of minimization is used to abstract the core signals that implement the functions of a device. In other words, the principle of minimization is used to select the most core signals for abstraction while meeting functional requirements, avoiding the definition of too many signals and reducing unnecessary signal redundancy.

[0127] The atomicity principle is used to ensure that abstracted functional signals are the smallest indivisible functional units. In other words, the atomicity principle ensures that each abstracted signal represents an indivisible functional unit, so as to facilitate the combination and invocation of signals.

[0128] As can be seen, based on the principle of signal abstraction, standardized signals are further processed to create a device abstraction matrix table. Here, standardized signals are categorized into a unified framework according to type, core function, and atomicity, forming a matrix table that intuitively displays the device's signal capabilities and calling logic.

[0129] Therefore, the application of standardization principles enhances the interoperability of signals between different devices, reduces signal definition redundancy caused by device differences, and improves the overall system compatibility. The application of the minimization principle simplifies the signal architecture, reduces the complexity of signal processing, and improves system operating efficiency. The application of the atomicity principle ensures the accuracy of signal definitions, helps to build stable and reliable signal interaction models, and also creates conditions for subsequent functional expansion and flexible signal combination.

[0130] Optionally, in step S103, determining the combination of atomic signals based on the preset target function and the atomic signal library may include the following execution steps:

[0131] Step S1031: Select target atomic signals from the atomic signal library based on the target function.

[0132] Step S1032: The target atomic signal is encapsulated and combined based on the signal group of the communication composite object model layer to obtain the first atomic signal combination.

[0133] Step S1033: The first atomic signal combination is processed by controller local area network signal packaging using a data exchange format file to obtain the second atomic signal combination.

[0134] Step S1034: Update the version number of the second atomic signal combination to obtain the atomic signal combination.

[0135] In this embodiment of the application, when determining the combination of atomic signals based on the preset target function and the atomic signal library, the target atomic signal can be selected from the atomic signal library based on the target function first.

[0136] The target atomic signal is the signal selected from the atomic signal library according to the target functional requirements. These target atomic signals are the smallest units necessary to achieve the target function.

[0137] As can be seen, based on the target functions that the vehicle needs to achieve, a set of atomic signals, namely the target atomic signals, is selected from the atomic signal library. These target atomic signals are the foundation for realizing the function. Therefore, by accurately selecting the target atomic signals, unnecessary signal interactions can be reduced, system design can be simplified, and the targeting and efficiency of signal combinations can be improved.

[0138] Then, the target atomic signals are encapsulated and combined based on the signal group of the communication composite object model layer to obtain the first atomic signal combination.

[0139] In the AUTOSAR architecture, the Communication Component Object Model Layer (COM layer) Signal Group is used to encapsulate and manage signals. The COM layer Signal Group can combine multiple target atomic signals into a single logical unit for system calls.

[0140] The first atomic signal combination is a logic unit encapsulated by multiple target atomic signals through a COM layer signal group. The first atomic signal combination represents a set of signals that achieve a specific target function.

[0141] As can be seen, using the signal group in the communication composite object model layer encapsulates the selected target atomic signals, forming a logically tighter combination of first atomic signals, which facilitates subsequent invocation and management. Thus, signal group encapsulation simplifies the complexity of signal management and invocation, improves the efficiency of signal processing, and also facilitates tracking signal usage and version control.

[0142] Subsequently, the first atomic signal combination is processed into a controller area network signal package using a data exchange format file to obtain the second atomic signal combination.

[0143] A Data Exchange Format File (DBC file) is a file used to describe the signal communication format in a network, specifying parameters such as the signal name, ID, length, and transmission period.

[0144] Controller Area Network (CAN) signal packetization refers to converting the signals in the first atomic signal combination into a format suitable for transmission on the CAN network to ensure the correct transmission of signals in the vehicle network.

[0145] The second atomic signal combination is the signal combination after CAN signal packaging. The second atomic signal combination is the specific implementation of the first atomic signal combination at the network communication layer.

[0146] As can be seen, by using the DBC file, the signal format in the first atomic signal combination is converted into a communication format compatible with the CAN network, forming the second atomic signal combination, ensuring that the signal can be effectively transmitted in the vehicle network environment. Thus, signal packetization ensures the standardization of signal transmission and the compatibility of network communication, reduces errors during signal transmission, and improves the stability and efficiency of system communication.

[0147] Finally, update the version number of the second atomic signal combination to obtain the atomic signal combination.

[0148] Version numbers are used to identify the iteration history of signal combinations. Each version number represents a specific state of the signal combination, making it easy to track and manage the change history of the signal combination.

[0149] As can be seen, based on the second atomic signal combination, the version number is updated according to changes in the signal combination to reflect the latest state of the signal combination, facilitating version control and rollback. Therefore, the version control mechanism can clearly record the change history of the signal combination, making it easier to identify and resolve potential compatibility issues, while ensuring that the latest version of the signal combination can be correctly identified and applied during OTA upgrades.

[0150] Optionally, in step S104, generating the service unit call list based on the atomic signal combination may include the following execution steps:

[0151] Step S1041: Analyze the atomic signal combination to obtain the calling requirements of the target controller, wherein the calling requirements are used to represent the calling order, frequency and conditions of the target controller.

[0152] Step S1042: Based on the call requirements, map the signals in the atomic signal combination to the corresponding service units and generate a service unit call list.

[0153] In this embodiment of the application, when generating a service unit call list based on atomic signal combinations, the atomic signal combinations can be analyzed to obtain the call requirements of the target controller.

[0154] The invocation requirement is used to represent the invocation order, frequency, and conditions of the target controller. In other words, the invocation requirement describes the sequence, frequency, and condition requirements of the target controller when using combinations of atomic signals, and is an important component of the functional logic.

[0155] It can be seen that by conducting in-depth analysis of the aforementioned generated second atomic signal combination (i.e., after network signal packaging), the call requirements of the target controller for each signal when executing the target function can be determined. The call requirements include the order of signal usage, the frequency of call, and the conditions for call, ensuring that the signal calls can be executed correctly according to the predetermined functional logic.

[0156] Therefore, the call requirements provide a clear guide for signal invocation, ensuring that signal invocation on the target controller meets the functional requirements. Furthermore, by analyzing the call frequency and conditions, the use of signal resources can be rationally planned, avoiding waste or excessive network bandwidth consumption.

[0157] Then, based on the call requirements, the signals in the atomic signal combination are mapped to the corresponding service units, generating a service unit call list.

[0158] As can be seen, based on the call requirements derived from the preceding analysis, atomic signals are mapped to corresponding service units. That is, each atomic signal is associated with one or more service units responsible for specific functions, and a service unit call list is generated according to the call requirements. The service unit call list details the call order, frequency, and conditions of each service unit, providing a basis for subsequent software programming and system testing.

[0159] Therefore, the service unit call list makes the system architecture more modular, easier to understand and maintain, and also facilitates feature expansion and iteration. Based on the service unit call list, software developers can focus more on programming the service units themselves, rather than the low-level signal details, thus accelerating development. Furthermore, by defining the service units and their calling logic in advance, the system integration phase can directly use this list for testing and verification, reducing integration time.

[0160] Optionally, the method may further include the following execution steps:

[0161] Step S105: Verify the service unit call list using a preset verification strategy, wherein the preset verification strategy includes at least one of the following:

[0162] Perform model-in-the-loop testing on the service unit call list;

[0163] Perform hardware-in-the-loop testing on the service unit call list;

[0164] Perform regression testing on the service unit call list.

[0165] In this embodiment of the application, a preset verification strategy will also be used to verify the service unit call list, such as performing model-in-the-loop testing on the service unit call list.

[0166] Model-in-the-loop (MIL) testing refers to using a software model (such as a Simulink model) to simulate the operating environment of a service unit in the early stages of development, in order to test the logical correctness of the service unit's call list and whether the functional implementation meets the requirements.

[0167] As can be seen, software simulation verifies whether the signal call logic in the service unit call list meets design expectations and whether the functionality can be correctly implemented. Model-in-the-loop testing is typically performed without hardware support, focusing primarily on software-level signal processing and functional logic.

[0168] Another example is performing hardware-in-the-loop testing on the service unit call list.

[0169] Hardware-in-the-loop (HIL) testing refers to placing the software under development in a simulated hardware environment for testing to verify its functional performance and performance indicators under actual hardware conditions, ensuring software and hardware compatibility and overall system stability.

[0170] As can be seen, on the hardware prototype or simulator, the service units are actually called according to the defined order and conditions in the service unit call list to verify the real-time performance and accuracy of the signals in the hardware environment, and to ensure that the signal calling logic can correctly and errorlessly achieve the functional requirements.

[0171] Another example is performing regression testing on the service unit call list.

[0172] Regression testing refers to rerunning all previous test cases after software or system has been modified or upgraded to ensure that the added or modified parts have not introduced new errors, while the original functions can still operate normally.

[0173] As can be seen, when the service unit call list or related software is modified, regression testing is performed to verify whether the modification affects the original functions and the correctness of service unit calls.

[0174] Therefore, a pre-defined verification strategy employing model-in-the-loop (MIL) testing, hardware-in-the-loop (HIL) testing, and regression testing is used to verify the service unit call list, ensuring quality control throughout the entire process from software logic design to hardware interaction and version iteration. This pre-defined verification strategy not only identifies and fixes logical errors in software design early on but also verifies the performance of signals in a real hardware environment, ensuring software-hardware compatibility and system stability. Regression testing further ensures that existing functions and service unit call logic remain unaffected during system upgrades or feature expansions, maintaining the system's continuous and reliable operation.

[0175] Optionally, in step S12, determining the service unit call list based on the function execution request may include the following execution steps:

[0176] Step S121: Parse the function execution request and determine the target function.

[0177] Step S122: Determine the service unit call list based on the preset mapping table and the target function, wherein the preset mapping table is used to record the mapping relationship between vehicle functions and the service unit call list.

[0178] In this embodiment of the application, when determining the service unit call list based on the function execution request, the function execution request can be parsed to determine the target function.

[0179] As can be seen, when the system receives a function execution request, it first parses it to identify the specific function indicated in the request, that is, transforming the abstract request information into an actionable and clearly defined target function. This parsing process ensures that the system can accurately understand and locate the function to be executed, avoiding function execution errors caused by misunderstandings.

[0180] Then, the service unit call list is determined based on the preset mapping table and the target function.

[0181] The preset mapping table is used to record the mapping relationship between vehicle functions and service unit call lists. That is, the preset mapping table records the relationship between each vehicle function and the service unit to be called, as well as the calling order, frequency and conditions.

[0182] As can be seen, by using the pre-defined mapping table, the system can quickly find the service unit call list corresponding to the target function from the previously defined and verified service unit call logic. Therefore, once the function execution request is parsed and the target function is determined, the relevant service units can be called according to the table to begin executing the function.

[0183] Therefore, the existence of the pre-defined mapping table automates and speeds up the conversion between functions and service units, eliminating the need to recalculate the service unit call logic every time a function is executed, thus greatly improving the efficiency of function execution. Furthermore, since the service unit call list is formed based on detailed design and rigorous verification in the early stages, it ensures that all signal interactions follow the correct logic during the execution of the target function, avoiding errors in function execution.

[0184] Optionally, the method may further include the following execution steps:

[0185] Semantic version control is used to manage the versions of atomic signal combinations, and a change impact assessment template is established. The change impact assessment template is used to reflect the impact of signal modifications on the target function and the target controller version.

[0186] In this embodiment, Semantic Versioning (SemVer) is a method for version marking and release, designed to provide users and developers with clear information about software changes. SemVer uses three numbers (major version, minor version, and revision version) to identify versions, such as 1.0.0, and specifies the meaning of changes to these numbers.

[0187] It can be seen that each time the atomic signal combination is modified or optimized, its version number is updated according to the semantic versioning specification. That is to say:

[0188] If modifications introduce incompatible Application Programming Interface (API) changes (such as adding required signals or changing signal formats), the major version number is incremented by one.

[0189] If a modification adds new functionality without breaking existing functionality (such as adding optional attributes to a signal), the minor version number is incremented by one.

[0190] If the revision only fixes bugs without adding new features or API changes, the revision number is incremented by one.

[0191] Therefore, the SemVer specification clearly communicates the content and impact of version changes, helping downstream system and software developers understand whether updates affect currently used functionalities. Furthermore, through standardized version control, the impact of signal combination changes on existing functionality can be effectively assessed and managed, avoiding system failures caused by version incompatibility.

[0192] A change impact assessment template is a tool used to systematically assess the impact of signal modifications on target functions and target controller versions. A change impact assessment template typically includes a change description, a list of affected functions, compatibility analysis, and other content.

[0193] As can be seen, for each version change of atomic signal combination, a change impact assessment template must be filled out, detailing the changes, analyzing the list of affected functions, and the potential impact on the target controller version. This requires a detailed description of the changes, an assessment of the functions in the system that call these signals, determining which functions may need to be updated to accommodate the new signal combination version, and also taking into account the compatibility issues of the controller software.

[0194] Therefore, by using a template-based approach, the impact of signal changes on functionality can be systematically assessed, avoiding the omission of important information. The assessment template provides stakeholders with a basis for evaluating signal changes, promoting transparency in the decision-making process and smoother communication.

[0195] In summary, this application first needs to identify the capabilities of the vehicle's basic components and abstract them into basic signals. For example, the capabilities of a light signal are set as follows:

[0196] Output the execution command;

[0197] Report the output current;

[0198] Report the output status.

[0199] All lamp modules with the same abstraction capabilities are abstracted into the above interface signals, without distinguishing the lamp's location or name. The upper-level logic then determines which module is calling the signal.

[0200] The above constitutes the first layer of signal processing. If certain combinations of signals in the first layer are frequently invoked by the upper layer, these combinations of signals are packaged and processed to form standardized signal groups to facilitate processing by upper-layer applications.

[0201] The logic judgments and design should refer to the overall vehicle functional requirements definition:

[0202] Refer to the functional requirements description document, which includes functional behavior and requirements, usage scenarios, user examples, detailed descriptions of functions, application scenarios, and implementation steps.

[0203] The functional implementation method includes the collaboration between different subsystems to achieve the function, which systems participate and the system responsibilities are clearly defined (how to implement the function), the interaction scenarios for function implementation, and the interaction implementation requirements between different subsystems. It is based on the functional requirements description and the detailed system design, and includes the interaction sequence and functional block diagram.

[0204] Subsystem requirements description, subsystem functional implementation logic, including input requirements, system design, logic allocation, logical requirements for components corresponding to the system logic, network signal requirements, etc.

[0205] It can be seen that this application realizes a paradigm shift from function-driven to capability-driven, the core of which lies in transforming the traditional "demand-oriented" signal definition model into a "resource-oriented" capability management model. The essence of this shift is to establish a standardized controller capability description system, enabling system design to shift its focus from "what signals the function needs" to clearly defining "what services the controller can provide".

[0206] Specifically, this application has the following key technological advantages.

[0207] 1. Improved hardware compatibility. When iterating on hardware (such as upgrading LiDAR), only the corresponding capability description file (YAML format) needs to be updated at the software layer. There is no need to refactor the underlying communication protocol, thus maintaining the stability of the original system architecture.

[0208] 2. Heterogeneous Platform Integration. Supports hybrid deployment across different computing platforms. Enables cross-platform service calls through a unified capability interface abstraction layer.

[0209] This application can achieve the engineering value shown in Table 2.

[0210] Table 2

[0211]

[0212] It can be seen that by establishing a standardized capability description system, not only has development efficiency been greatly improved, but a solid foundation has also been laid for the continuous evolution of intelligent connected vehicles in the future.

[0213] Figure 2 is a flowchart of an in-vehicle service interface design according to one embodiment of this application. As shown in Figure 2, Figure 2 describes the core workflow of an in-vehicle service interface design method based on a generalized capability definition interface. Starting from the capability identification of vehicle components, standardized service interfaces are gradually built up, ultimately achieving efficient and flexible system interaction between the application program (APP) and the user level. The following is a detailed description of the workflow in Figure 2:

[0214] Vehicle component capability statistics: This is the starting point of the entire process, involving the collection and organization of capability information for all vehicle components. Vehicle component capability statistics include analyzing the actual physical capabilities of each ECU or sensor, such as the torque output capability of the drive motor and the target recognition capability of the LiDAR. This step aims to comprehensively understand the performance parameters and functional characteristics of each component in the vehicle's electronic architecture.

[0215] Defining basic interface capabilities: After statistically analyzing the capabilities of all vehicle components, the next task is to convert these complex capabilities into standardized interface signals, i.e., basic interface capabilities. This process requires abstracting the physical functions of the controller into simple, unified signal descriptions. For example, the atomic signals of a "lamp module" include "on / off commands" and "brightness commands." Through this abstraction, similar devices in different locations and with different names can share a single set of signal interfaces, greatly reducing the redundancy of signal definitions.

[0216] Basic Capability Combination Definition: After defining the basic interface capabilities, these atomic signals need to be further combined into higher-level signal groups to adapt to the needs of specific functions or scenarios. For example, multiple "lamp module" signals can be combined into a "turn signal group" signal, or the "light sensor" and "high beam switch" signals can be combined into a signal group for automatic high beam function. This combination process follows the principles of call frequency, functional relevance, and timing constraints, ensuring that the signal group not only meets functional requirements but also has good reusability and timeliness.

[0217] App Applications and Users: After defining the signal groups, they will be encapsulated into service interfaces usable by the app, allowing users to operate and experience various in-vehicle functions through the in-vehicle interactive system (such as the central control screen). For example, users can trigger functions such as automatic parking and emergency hazard lights through voice commands or touchscreen gestures, and these commands will be parsed into corresponding signals to interact with the underlying hardware.

[0218] Cross-domain invocation: Figure 2 also illustrates the signal invocation process between different functional domains (such as the body control domain, powertrain domain, and infotainment system domain), i.e., "cross-domain invocation". When a function involves controllers in multiple domains, signal groups based on capability definitions can be efficiently invoked across these domains without needing to define duplicate signals separately in each domain. In this way, functions such as "automatic parking" can seamlessly invoke signals from the "powertrain system" and "body control system" to achieve multi-domain collaboration.

[0219] Specifically, when a function (such as automatic parking) needs to call basic signals from different domains, the standardized basic interface capabilities can ensure signal consistency and interoperability, enabling ECUs in different domains to understand and respond to signal requests.

[0220] For more complex functions, it may be necessary to invoke signal groups defined by combining multiple basic capabilities. In this case, the standardization of signal groups makes cross-domain communication simpler and more efficient, reducing problems caused by signal incompatibility.

[0221] The signal processed through cross-domain calls eventually reaches the user interface. Whether through the HMI display or changes in vehicle behavior, users can intuitively feel the enhanced intelligent experience brought about by the controller capability definition interface.

[0222] Furthermore, the implementation scheme for abstracting the capabilities of basic vehicle components and implementing signal processing includes the following steps.

[0223] 1. Basic component signal abstraction (first-level signal processing).

[0224] 1) Signal abstraction principle.

[0225] Standardization: Similar devices are abstracted into a unified interface, ignoring differences in physical location (e.g., front, rear, left, and right lights are unified as "light modules");

[0226] Minimize: Expose only the necessary control / status signals (3-5 core signals);

[0227] Atomicity: Each signal represents the smallest indivisible functional unit.

[0228] 2) Typical component abstract examples, see Table 3.

[0229] Table 3

[0230]

[0231] 3) Implementation method.

[0232] Define atomic-level signal interfaces using AUTOSAR SWC templates;

[0233] Establish a device abstract matrix table;

[0234] Unified signal mapping is achieved through the ECU basic software layer.

[0235] 2. Signal combination and standardization (second-level signal processing).

[0236] 1) Signal group identification standard.

[0237] Call frequency: Signal combinations that are called by 3 or more upper-level functions;

[0238] Functional relevance: The set of signals that complete a specific sub-function (e.g., "turn signal group" = front left + front right + rear left + rear right);

[0239] Timing constraints: Signal groups that require synchronous control.

[0240] 2) Typical signal group example.

[0241] For example, a structure named `Lighting_Output` can be defined to represent the integrated lighting cluster. This structure contains the on / off state of the emergency flashers (`emergency_flash`) and the signal states of the turn signals, subdivided into Boolean values ​​for left turn (`turn_signal_left`) and right turn (`turn_signal_right`). Additionally, it includes an ambient light level group, which quantifies the ambient light intensity using an 8-bit unsigned integer for automatically adjusting the interior lighting.

[0242] 3) Combination method.

[0243] Use COM layer signal group encapsulation;

[0244] Use DBC files to package CAN signals;

[0245] Define the signal group version number (e.g., Lighting_Ctrl_v2.1).

[0246] 3. Demand-driven logical design process.

[0247] 1) Demand decomposition matrix, see Table 4.

[0248] Table 4

[0249]

[0250] 2) Logical judgment design template.

[0251] For example, a core logic function `auto_high_beam` for an automatic high beam control system is defined. Its main responsibility is to determine whether to turn on the vehicle's high beams based on data fused from visual sensors. The function accepts a dictionary parameter named `fusion_data`, which contains fused data from the vehicle's vision system, such as whether there is an oncoming vehicle ahead and the road illuminance (in lux).

[0252] The logical flow is as follows: First, the `oncoming_vehicle` key value in `fusion_data` is checked. If an oncoming vehicle is detected, the high beam status `Lighting_Output.high_beam` is set to `False`, meaning the high beams are turned off to avoid glare for other drivers. Next, if the road light intensity is below 15 lux, the high beam status is set to `True`, automatically turning on the high beams to enhance visibility at night. Finally, if none of the above conditions are triggered, the function calls `maintain_current_state()` to keep the current high beam status unchanged, ensuring the system does not change the brightness of the lights without reason.

[0253] 3) Subsystem collaboration mechanism.

[0254] Refer to Figure 3 for the definition of the interaction contract. Figure 3 is an interaction flowchart of the components in the vehicle automatic high beam control system according to one embodiment of this application. The flowchart of Figure 3 describes in detail the interaction process of the components in the vehicle automatic high beam control system, especially the information transmission and technical implementation details between the HMI, the camera electronic control unit (Camera ECU), the lighting controller (Lighting_Controller), and the lighting output (Lighting_Output).

[0255] First, user actions on the HMI (such as pressing the automatic high beam button or activating the automatic high beam function via voice command) generate a function request. This request carries instructions regarding the control of the automatic high beams. Subsequently, this request is sent to the Lighting Controller, which is responsible for handling all logic and control related to the vehicle's lighting system.

[0256] Meanwhile, the camera electronic control unit (Camera ECU) periodically (e.g., every 100 milliseconds) provides the lighting controller with information about the status of vehicles ahead. This information may include, but is not limited to, whether oncoming vehicles are detected, whether there are pedestrians ahead, and the current road lighting level. The Camera ECU uses visual recognition algorithms to analyze the image data captured by the camera, extract environmental features, and convert them into signals that can be used for control, such as the presence of oncoming vehicles.

[0257] After receiving the function request from the HMI and the environmental data provided by the Camera ECU, the Lighting Controller begins to determine whether the high beams should be turned on or off based on preset logic. Factors considered in this logic may include whether the system is currently in automatic high beam mode, whether there are vehicles ahead, and whether the road lighting is sufficient. Once a decision is made, the Lighting Controller generates a "high beam control command," which is then passed to the Lighting Output system to actually control the headlight's illumination mode.

[0258] Inside the Lighting_Controller, high beam control commands might be a simple Boolean value (on or off) or more complex signals, such as adjusting the brightness or angle of the high beams. The Lighting_Output then executes specific operations based on the received control commands, such as adjusting the high beam brightness or switching to low beam mode, to ensure that the vehicle's lighting system responds safely and appropriately under different driving conditions.

[0259] 4. Implementation steps.

[0260] 1) Implementation steps for each phase are shown in Table 5.

[0261] Table 5

[0262]

[0263] 2) Verification method.

[0264] Model-in-the-Loop (MIL) testing: Simulink model-in-the-loop verification of signal combinational logic;

[0265] Hardware-in-the-Loop (HIL) testing: Hardware-in-the-loop testing signal timing constraints;

[0266] Regression testing: Establish a signal call relationship matrix to verify the influence domain.

[0267] 5. Change the management mechanism.

[0268] 1) Signal version control.

[0269] Use the SemVer versioning specification: major version.minor version.revision number;

[0270] Change Impact Assessment Template:

[0271] Signal modification request, list of affected functions:

[0272] ① F-210 automatic parking (light interaction);

[0273] ② F-305 welcome light show.

[0274] Compatibility analysis, for example, the need to synchronously update Body_Controller to v3.2+.

[0275] The proposed solution recommends using the Automotive Software Process Improvement and Capability Assessment (ASPICE) process for process control. It also suggests establishing a Signal Abstraction Layer (SAL) as a standard middleware for the vehicle's Electronic Electrical Architecture (EE architecture), which can reduce the workload of signal interaction modification by more than 30% during subsequent function iterations.

[0276] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, data stored, data displayed, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties. Furthermore, the collection, use and processing of the relevant data must comply with the relevant laws, regulations and standards of the relevant countries and regions, and corresponding operation entry points are provided for users to choose to authorize or refuse.

[0277] According to an embodiment of this application, a vehicle interface calling device is provided. It should be noted that the device can be used to execute the above-described vehicle interface calling method.

[0278] Figure 4 is a structural block diagram of a vehicle interface invocation device according to one embodiment of this application. As shown in Figure 4, taking the vehicle interface invocation device 400 as an example, the device includes: an acquisition module 401, used to acquire a function execution request, wherein the function execution request is used to instruct the vehicle to execute a target function; a determination module 402, used to determine a service unit invocation list based on the function execution request, wherein the service unit invocation list is used to indicate the target service unit to be invoked, and the target service unit encapsulates the signal information, performance indicators, attribute information, and invocation order of the target controller in the vehicle; a parsing module 403, used to parse the service unit invocation list to obtain the target controller and the target interface corresponding to the target controller; and an invocation module 404, used to control the target controller to invoke the target interface based on the invocation order to execute the target function.

[0279] Embodiments of this application also provide a vehicle, including: a memory storing an executable program; and a processor for running the program, wherein the program executes the methods described in various embodiments of this application when it runs.

[0280] Embodiments of this application also provide a computer-readable storage medium including a stored executable program, wherein, when the executable program is running, it controls the device where the computer-readable storage medium is located to perform the methods of various embodiments of this application.

[0281] Embodiments of this application also provide a computer program product, including a computer program that, when executed by a processor, implements the methods of various embodiments of this application.

[0282] In the above embodiments of this application, the descriptions of each embodiment have different focuses. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions of other embodiments.

[0283] In the several embodiments provided in this application, it should be understood that the disclosed technical content can be implemented in other ways. The device embodiments described above are merely illustrative; for example, the division of units can be a logical functional division, and in actual implementation, there may be other division methods. For instance, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the displayed or discussed mutual coupling, direct coupling, or communication connection may be through some interfaces; the indirect coupling or communication connection between units or modules may be electrical or other forms.

[0284] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0285] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

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

[0287] The above description is only a preferred embodiment of this application. It should be noted that for those skilled in the art, several improvements and modifications can be made without departing from the principle of this application, and these improvements and modifications should also be considered within the scope of protection of this application.

Claims

1. A method for invoking a vehicle's interface, characterized in that, The method includes: obtaining a function execution request, wherein the function execution request is used to instruct a vehicle to execute a target function; determining a service unit call list based on the function execution request, wherein the service unit call list is used to indicate target service units to be called, the target service units encapsulating signal information, performance indicators, attribute information of target controllers in the vehicle, and the calling order among the target controllers; parsing the service unit call list to obtain the target controller and the target interface corresponding to the target controller; and controlling the target controller to call the target interface based on the calling order to execute the target function.

2. The method according to claim 1, characterized in that, The method further includes: obtaining a capability description document for a device in the vehicle, wherein the capability description document describes the signal capabilities and attributes provided by the device; generating an atomic signal library based on the capability description document; determining an atomic signal combination based on the preset target function and the atomic signal library, wherein the atomic signal combination is a set of atomic signals in the atomic signal library that execute the target function; and generating the service unit call list based on the atomic signal combination.

3. The method according to claim 2, characterized in that, The process of generating an atomic signal library based on the capability description document includes: extracting signals from the capability description document to obtain signal extraction results, wherein the signal extraction results are used to represent the signal capabilities and attributes of the device; standardizing the signal extraction results based on a preset template to obtain standardized signals, wherein the preset template is used to provide definition rules and formats for signal interfaces, and the standardized signals have the same signal format and communication protocol; establishing a device abstraction matrix table based on the standardized signals, wherein the device abstraction matrix table is used to convert the standardized signals of the device into abstract functional signals; and establishing a mapping relationship between the abstract functional signals and the physical interfaces of the device based on electronic control unit software to generate the atomic signal library.

4. The method according to claim 3, characterized in that, The establishment of the device abstraction matrix table based on the standardized signals includes: establishing the device abstraction matrix table based on signal abstraction principles and the standardized signals, wherein the signal abstraction principles include at least one of the following: standardization principle, used to abstract devices of the same type into a unified interface; minimization principle, used to abstract the core signals that realize the functions of the device; atomicity principle, used to ensure that the abstracted functional signals are the smallest indivisible functional units.

5. The method according to claim 2, characterized in that, The step of determining the atomic signal combination based on the preset target function and the atomic signal library includes: selecting a target atomic signal from the atomic signal library based on the target function; encapsulating and combining the target atomic signal based on the signal group of the communication composite object model layer to obtain a first atomic signal combination; performing controller local area network signal packaging processing on the first atomic signal combination using a data exchange format file to obtain a second atomic signal combination; and updating the version number of the second atomic signal combination to obtain the atomic signal combination.

6. The method according to claim 2, characterized in that, The step of generating the service unit call list based on the atomic signal combination includes: analyzing the atomic signal combination to obtain the call requirements of the target controller, wherein the call requirements are used to represent the call order, frequency and conditions of the target controller; and mapping the signals in the atomic signal combination to the corresponding service units based on the call requirements to generate the service unit call list.

7. The method according to claim 2, characterized in that, The method further includes: verifying the service unit call list using a preset verification strategy, wherein the preset verification strategy includes at least one of the following: performing model-in-the-loop testing on the service unit call list; performing hardware-in-the-loop testing on the service unit call list; and performing regression testing on the service unit call list.

8. The method according to any one of claims 1-7, characterized in that, The step of determining the service unit call list based on the function execution request includes: parsing the function execution request to determine the target function; and determining the service unit call list based on a preset mapping table and the target function, wherein the preset mapping table is used to record the mapping relationship between vehicle functions and the service unit call list.

9. The method according to any one of claims 2-7, characterized in that, The method further includes: managing the versions of the atomic signal combinations using a semantic version control specification, and establishing a change impact assessment template, wherein the change impact assessment template is used to reflect the impact of signal modifications on the target function and on the target controller version.

10. A vehicle, characterized in that, include: Memory, which stores executable programs; A processor for running the program, wherein the program, when running, executes the interface invocation method for the vehicle as described in any one of claims 1 to 9.

Images