Method and device for controlling a vehicle tonneau cover

Abstract

The application provides a control method and device for a vehicle box cover, and relates to the technical field of vehicle control. The control request is analyzed and the target application scene is matched through a scene service layer, the execution mechanism set is determined based on the arrangement rule, the control signal is sent to the corresponding execution mechanism through a transmission abstraction layer, and the box cover is controlled. The control logic is independent of the hardware driver in the arrangement rule. The requests from different sources can be flexibly mapped to the corresponding application scene through the scene service layer. The execution mechanism can be flexibly combined and sequenced according to the corresponding scene. When the hardware configuration is changed, the adaptation can be realized by adjusting the arrangement rule under the corresponding scene. The transmission abstraction layer establishes isolation between the software and the hardware. The upper control logic does not need to pay attention to the specific model and the driving mode of the bottom executioner. The upper code is not affected when the hardware is replaced. In summary, the application can effectively improve the flexibility of control and the hardware adaptability.

Description

Technical Field

[0001] This invention relates to the field of vehicle control technology, and in particular to a method and device for controlling a vehicle's cargo cover. Background Technology

[0002] The opening and closing control of vehicle storage compartments (such as the front trunk) usually involves the coordinated action of multiple actuators (such as electric latches, strut motors, etc.). The type, number, and drive method of actuators may vary between different vehicle models or different configuration versions of the same vehicle model.

[0003] In existing technologies, the control logic of the glove compartment is often directly bound to the hardware configuration of a specific vehicle model. On the one hand, the control software is developed directly for specific actuator drive interfaces, and the software needs to be modified synchronously when the hardware changes, resulting in long development cycles and high adaptation costs. On the other hand, as users' demands for intelligent vehicle functions increase, the glove compartment control needs to be integrated with more scenarios (such as remote control, voice control, near-field sensing, navigation linkage, etc.). However, in existing solutions, the control logic for different scenarios is independent of each other. When adding or adjusting scenario functions, the underlying control program needs to be modified, which lacks flexibility and limits the rapid iteration and diversified expansion of the glove compartment control function. Summary of the Invention

[0004] The purpose of this invention is to provide a control method and device for a vehicle hatch cover, which can effectively improve the flexibility of control and hardware adaptability while realizing basic control functions.

[0005] In a first aspect, the present invention provides a control method for a vehicle lid, wherein the method is applied to a vehicle controller, and the method includes: responding to a control request for the vehicle lid, parsing the control request through a preset scene service layer and determining the target application scenario corresponding to the control request; wherein the scene service layer is configured with application scenarios corresponding to various functions of the lid; determining a target set of actuators and the execution order of each actuator in the target set of actuators according to the arrangement rules corresponding to the target application scenario in a preset service processing layer; wherein the service processing layer connects the scene service layer and the transmission abstraction layer; and sending control signals to the actuators in the target set of actuators according to the execution order through a software interface set in the transmission abstraction layer to drive the lid to perform corresponding actions.

[0006] In an optional implementation, the steps of parsing the control request through a preset scene service layer and determining the target application scenario corresponding to the control request include: parsing the request source identifier and execution action carried in the control request through the scene service layer; determining the application scenario type to which the control request belongs based on the request source identifier; the application scenario type includes user-initiated operation scenarios and vehicle-triggered scenarios; and determining the target application scenario corresponding to the control request based on the application scenario type and execution action.

[0007] In an optional implementation, the aforementioned service processing layer includes an enhanced service layer and an atomic service layer. The steps of determining the target execution mechanism set and the execution order of each execution mechanism in the target execution mechanism set according to the preset orchestration rules corresponding to the target application scenario in the service processing layer include: determining the control requirements corresponding to the target application scenario through the enhanced service layer, determining multiple atomic operations corresponding to the control requirements according to the preset orchestration rules, and the execution order between each atomic operation; determining the execution mechanism corresponding to each atomic operation through the atomic service layer; forming the target execution mechanism set from all the execution mechanisms, and determining the execution order between each execution mechanism according to the execution order between each atomic operation.

[0008] In an optional implementation, the above-mentioned determination of the control requirements corresponding to the target application scenario through the enhanced service layer includes: parsing the target application scenario through the enhanced service layer to determine the control requirements corresponding to the target application scenario; wherein, the control requirements include at least one of the following: enable requirement, disable requirement, obstacle detection and fallback requirement, reminder requirement, speed limit requirement or anti-play restriction requirement.

[0009] In an optional implementation, the multiple atomic operations corresponding to the control requirement determined according to the preset programming rules include: when the control requirement is an opening requirement, the atomic operations corresponding to the opening requirement determined according to the preset programming rules include a lifting operation of the strut motor for driving the lid to move and an unlocking operation of the electric latch for unlocking the lid; when the control requirement is a closing requirement, the atomic operations corresponding to the closing requirement determined according to the preset programming rules include a lowering operation of the strut motor for driving the lid to move and a locking operation of the electric latch for locking the lid.

[0010] In an optional implementation, the above-mentioned determination of multiple atomic operations corresponding to the control requirement according to the preset orchestration rules includes: when the control requirement is an anti-play restriction requirement, the atomic operation corresponding to the anti-play restriction requirement is determined to be a prohibit response operation according to the preset orchestration rules; the determination of the execution mechanism corresponding to each atomic operation through the atomic service layer includes: if the atomic operation is a prohibit response operation, the prohibit response operation is determined to not correspond to an execution mechanism through the atomic service layer, and the current state of the lid is maintained.

[0011] In an optional implementation, the above-mentioned determination of the control requirements corresponding to the target application scenario through the enhanced service layer further includes: obtaining the vehicle's current gear signal and current vehicle speed signal through the enhanced service layer; when the current gear signal is park and the current vehicle speed signal is zero, determining that the control requirement corresponding to the target application scenario is a drive requirement; when the current vehicle speed signal is not zero, determining that the control requirement corresponding to the target application scenario is a speed limit requirement; the atomic operation corresponding to the speed limit requirement is a drive prohibition operation; determining the actuator corresponding to each atomic operation through the atomic service layer includes: if the atomic operation is a drive prohibition operation, determining through the atomic service layer that the drive prohibition operation does not correspond to an actuator, and continuing to maintain the current state of the lid.

[0012] In an optional implementation, after sending control signals to the actuators in the target actuator set according to the execution sequence, the method further includes: collecting the operating parameters of the actuators during the movement process through the transmission abstraction layer, and determining whether the lid is obstructed based on the operating parameters; when the lid is obstructed, generating an obstruction signal through the transmission abstraction layer and reporting it to the service processing layer, so that the service processing layer determines the control requirement of the lid as an obstruction backoff requirement based on the obstruction signal.

[0013] In an optional implementation, the software interface set through the transmission abstraction layer sends control signals to the actuators in the target actuator set according to the execution order, including: in the transmission abstraction layer, converting the control request into the target control signal of the corresponding actuator according to the drive interface type and signal format of each actuator in the target actuator set; and sending the target control signals to the corresponding actuators in sequence according to the execution order.

[0014] Secondly, embodiments of the present invention also provide a control device for a vehicle trunk lid, wherein the device is applied to a vehicle controller, and the device includes: an application scenario determination module, used to respond to a control request for the vehicle trunk lid, parse the control request through a preset scenario service layer, and determine the target application scenario corresponding to the control request; wherein the scenario service layer is configured with application scenarios corresponding to various functions of the trunk lid; an execution mechanism determination module, used to determine a target set of execution mechanisms and the execution order of each execution mechanism in the target set of execution mechanisms according to the arrangement rules corresponding to the target application scenario in a preset service processing layer; wherein the service processing layer connects the scenario service layer and the transmission abstraction layer; and an execution module, used to send control signals to the execution mechanisms in the target set of execution mechanisms according to the execution order through a software interface set in the transmission abstraction layer, so as to drive the trunk lid to perform corresponding actions.

[0015] The embodiments of this invention bring the following beneficial effects: This invention provides a control method and device for a vehicle trunk lid. By parsing control requests and determining the corresponding target application scenarios through a scene service layer, it can identify diverse triggering sources and application requirements based on different control requests. This allows the same execution action to match different scene services under different request sources. When adding or adjusting scenarios, only the mapping configuration needs to be modified in the scene service layer, without changing the underlying control logic. This improves the scene flexibility and functional diversity of the trunk lid control function and reduces development and maintenance costs caused by changes in requirements. Furthermore, by determining the set of execution mechanisms and the execution order between them through the orchestration rules corresponding to the target application scenario in the service processing layer, scene requirements can be transformed into specific execution schemes. This allows the control logic to exist independently of the hardware driver in the form of orchestration rules. The same scenario can be adapted to different hardware configurations by adjusting the orchestration rules without redeveloping the control program. This achieves standardization and configurability of the control logic, thereby reducing adaptation costs caused by hardware changes or vehicle model expansion. Furthermore, by using a unified software interface set in the transmission abstraction layer, control signals are sent to each actuator in the execution order. This standardizes and encapsulates the hardware differences such as drive interface types and signal formats of different actuators, making the issuance of control signals independent of the hardware characteristics of specific actuators. When the hardware of an actuator changes, only interface adaptation needs to be completed in the transmission abstraction layer. The logic of the upper-layer scene service layer and service processing layer remains completely unaffected. This decouples the control logic from the underlying hardware, allowing the same set of upper-layer control logic to flexibly adapt to the hardware differences of different vehicle models or different configuration versions, thereby improving the scalability and maintainability of the system.

[0016] Other features and advantages of the invention will be set forth in the following description, or some features and advantages may be inferred from the description or determined without doubt, or may be learned by practicing the techniques described above.

[0017] To make the above-mentioned objects, features and advantages of the present invention more apparent and understandable, preferred embodiments are described below in detail with reference to the accompanying drawings. Attached Figure Description

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

[0019] Figure 1 A flowchart illustrating a method for controlling a vehicle cargo cover according to an embodiment of the present invention; Figure 2 A flowchart of another vehicle cover control method provided in an embodiment of the present invention; Figure 3 A schematic diagram of a hierarchical architecture for a control system provided in an embodiment of the present invention; Figure 4 This is a schematic diagram illustrating the division and positional status of the movement area of ​​a box lid, provided in an embodiment of the present invention. Figure 5 This is a schematic diagram of the structure of a vehicle hatch control device provided in an embodiment of the present invention; Figure 6 This is a schematic diagram of the structure of an electronic device provided in an embodiment of the present invention. Detailed Implementation

[0020] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, the technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. The components of the embodiments of the present invention described and shown in the accompanying drawings can generally be arranged and designed in various different configurations.

[0021] Therefore, the following detailed description of the embodiments of the invention provided in the accompanying drawings is not intended to limit the scope of the claimed invention, but merely to illustrate selected embodiments of the invention. All other embodiments obtained by those skilled in the art based on the embodiments of the invention without inventive effort are within the scope of protection of the invention.

[0022] To facilitate understanding, a method for controlling a vehicle trunk lid according to an embodiment of the present invention will first be described, wherein the method is applied to a vehicle controller, referring to... Figure 1 The method includes the following steps: Step S102: In response to the control request for the vehicle's lid, the control request is parsed through a preset scene service layer, and the target application scene corresponding to the control request is determined.

[0023] A vehicle's cargo cover is a storage space cover that can be opened and closed electronically via a control system. Examples include the front or rear trunk lid, the specific type of which depends on the vehicle model. A control request represents the instruction that triggers the lid's action and can be obtained through the vehicle's human-machine interface or sensors. For example, a control request can be generated when a user presses a physical button inside the vehicle, sends a command remotely via a mobile app, a proximity sensor detects a legitimate key approaching, or the voice recognition system receives a voice command.

[0024] The scenario service layer is the logical layer in the system architecture used for control request parsing and application scenario identification. Within this layer, corresponding application scenarios are set for each function of the lid. These functions include, but are not limited to, opening and closing. Each function can correspond to different application scenarios under different triggering conditions. For example, for the opening function, remote opening, local opening, near-field sensing opening, and voice opening scenarios can be configured; for the closing function, remote closing, local closing, and voice closing scenarios can be configured. After receiving a control request, the controller first parses the request. Based on the request's source and functional requirements, it determines the matching target application scenario from the configured application scenarios. Subsequent processes are then scheduled based on this scenario identifier. Compared to existing technologies that directly bind control requests to specific triggering conditions, resulting in independent control flows from different triggering sources and difficulty in unified management, this invention adds an independent scenario identification step between the request source and the actual execution. This allows for the addition or adjustment of application scenarios only by modifying the scenario configuration in the scenario service layer, without altering the execution logic.

[0025] Step S104: Determine the target execution mechanism set and the execution order of each execution mechanism in the target execution mechanism set according to the orchestration rules corresponding to the target application scenario in the preset service processing layer; The service processing layer is the logical layer in the system architecture used to transform application scenarios into specific execution plans, connecting the scenario service layer and the transport abstraction layer. The service processing layer pre-stores orchestration rules corresponding to multiple application scenarios. These orchestration rules define the execution mechanisms required to execute a specific application scenario, as well as the timing and logical dependencies between these mechanisms. For example, it can be stipulated that the electric suction lock should perform the unlocking action before the strut motor, and only after successful unlocking can the strut motor perform the lifting action, thus avoiding mechanical jamming or component damage due to timing errors.

[0026] After determining the target application scenario in the above steps, the controller can call the corresponding orchestration rules from the service processing layer according to the target application scenario, parse the orchestration rules to determine the set of target execution mechanisms to be called for this execution, and the execution order of each execution mechanism in the set. The set of target execution mechanisms is a list of physical actuators to be called to execute the current scenario. The types and number of actuators included can be predefined by the orchestration rules according to the scenario requirements and hardware configuration. For example, it can include an electric latch and a strut motor, or an electric latch, a left strut motor, and a right strut motor, etc. The execution order is the order in which each execution mechanism in the set starts. Compared with the prior art, which directly binds the control logic to specific hardware, resulting in the need to redevelop the control program for different hardware configurations, the embodiments of the present invention describe the control logic of each scenario independently of the hardware driver in the form of orchestration rules. This allows the same scenario to be adapted to different hardware configurations by only adjusting the set of execution mechanisms or action parameters in the corresponding orchestration rules, without the need to redevelop the control program. In specific implementation, the orchestration rules can be implemented in any data format or configuration file form known in the art, and the present invention does not limit this.

[0027] In step S106, control signals are sent to the actuators in the target actuator set according to the execution order through the software interface set by the transmission abstraction layer, so as to drive the box cover to perform the corresponding actions.

[0028] The transport abstraction layer is a logical layer in the system architecture used to implement bidirectional conversion and transmission between control commands and physical drive signals. It connects the service processing layer and each physical actuator. Hardware adaptation information for each actuator at the physical layer can be configured in the transport abstraction layer, enabling the service processing layer and the actuators to interact through standardized control commands and status feedback, without needing to concern themselves with the specific implementation details of the underlying hardware.

[0029] In practical implementation, the controller can call the corresponding software interface in the transmission abstraction layer according to the type of each actuator in the target actuator set, and issue control commands to each actuator in the execution order determined by the above steps. After receiving the control commands, the transmission abstraction layer can convert the control commands into corresponding drive signals according to the hardware characteristics of the target actuator, and transmit them to the target actuator through the physical bus to drive the cover to perform the corresponding action. Compared with the prior art where the control code directly manipulates hardware registers or bus messages, which requires extensive software modifications when hardware changes, this embodiment of the invention sets up a transmission abstraction layer, so that the service processing layer only transmits control commands and receives status feedback in a standardized way, without needing to care about the specific driving method and signal format of the underlying hardware. When the actuator hardware changes, only the corresponding hardware adaptation configuration needs to be adjusted in the transmission abstraction layer, and the upper scene service layer and service processing layer are not affected.

[0030] Furthermore, based on the above embodiments, this invention also provides another vehicle hatch control method, referring to... Figure 2 The method includes the following steps: Step S202: In response to the control request for the vehicle's lid, the request source identifier and execution action carried in the control request are parsed through the scene service layer.

[0031] The request source identifier indicates how or what application triggered the control request, such as remote call, near-field call, in-vehicle screen, voice command, or hard switch. The execution action indicates the specific operation that the request expects the lid to perform, such as opening, closing, or opening to a certain angle.

[0032] In actual operation, different types of control requests will be generated under different usage scenarios. For example, when a user sends a command remotely through a mobile app, the request source identifier is "remote call," and the execution action is "open" or "close." When a user sends a command to "open to 50%" through a mobile app, the execution action carries a quantitative parameter of "open to 50%." When a user clicks a control button on the in-vehicle central control screen, the request source identifier is "screen call." When a user issues a voice command to "open the front trunk," the request source identifier is "voice call." When a user presses an in-vehicle physical switch, the request source identifier is "physical switch call." When a near-field sensor detects a legitimate key approaching, the request source identifier is "near-field call." The controller can obtain the above request source identifiers and execution actions by parsing the corresponding fields in the control request to determine the triggering method and operation intent corresponding to the current control request.

[0033] Step S204: Determine the application scenario type to which the control request belongs based on the request source identifier.

[0034] Application scenario types are used to characterize the scenario category to which a control request belongs, and to classify different triggering methods into scenario categories with common business characteristics. In one implementation, control requests can be classified into user-initiated operation scenarios or vehicle-triggered scenarios based on the request source identifier. User-initiated operation scenarios are applicable to control requests consciously and actively initiated by the user, including requests from human-computer interaction methods such as mobile apps, in-vehicle screens, voice commands, and hard switches. Their business characteristic is that the user explicitly expresses their operational intent through some interactive means. Vehicle-triggered scenarios are applicable to control requests spontaneously triggered by the vehicle system based on environmental perception or state judgment, including requests from system self-perception methods such as near-field sensing and navigation linkage. Their business characteristic is that the vehicle automatically determines whether to perform a lid operation based on sensor information or navigation information. It should be understood that the above classification is only illustrative. In actual applications, more scenario types can be flexibly expanded according to vehicle function definitions and system requirements, such as safety-priority scenarios and convenience-priority scenarios classified by safety level, and mandatory scenarios and non-mandatory scenarios classified by execution priority. Those skilled in the art can define these according to actual needs, and this embodiment of the invention does not limit them.

[0035] After obtaining the above request source identifier, the scenario service layer can classify the request into the corresponding application scenario type according to the preset classification rules. For example, if the request source identifier is a remote call, large screen call, voice call, or hard switch call, it is classified into the user active operation scenario; if the request source identifier is a near field call or navigation linkage system trigger, it is classified into the vehicle automatic trigger scenario.

[0036] Step S206: Determine the target application scenario corresponding to the control request based on the application scenario type and the execution action.

[0037] The scenario service layer is configured with multiple application scenarios as options. Some scenarios are directly related to the basic control actions of the lid, such as opening and closing scenarios. Other scenarios can be triggered based on the vehicle's current operating status. For example, when the vehicle speed is not zero, the system can determine that the opening conditions are not met, thus triggering a speed limit scenario. When opening requests are received frequently within a certain period of time, an anti-pinch scenario can be triggered. Furthermore, when the rate of change of motor current exceeds a threshold, an anti-pinch scenario can be triggered. In addition, self-learning scenarios and reminder scenarios can also be included. Each application scenario corresponds to a complete set of control strategies.

[0038] After determining the application scenario type, the scenario service layer can match the target application scenario uniquely corresponding to the current request from the above candidate scenarios by combining the execution action (opening, closing, or opening at a certain angle). For scenarios directly related to the basic control actions of the lid, the target application scenario can be determined based on the combination of application scenario type and execution action; for scenarios triggered by vehicle status, a comprehensive judgment can be made by combining status information such as vehicle speed signal, operation frequency, and current feedback during matching.

[0039] Step S208: Determine the control requirements corresponding to the target application scenario by enhancing the service layer, and determine multiple atomic operations corresponding to the control requirements and the execution order between each atomic operation according to the preset orchestration rules.

[0040] Step S210: Determine the execution mechanism corresponding to each atomic operation through the atomic service layer.

[0041] Step S212: The target execution mechanism set is composed of all the execution mechanisms, and the execution order between each execution mechanism is determined according to the execution order between each atomic operation.

[0042] In conjunction with the above embodiments, the service processing layer includes an enhanced service layer and an atomic service layer. (Refer to...) Figure 3 This diagram illustrates the layered architecture of the control system corresponding to an embodiment of the present invention. The architecture, from top to bottom, includes an APP layer, a scene service layer, an enhancement service layer, an atomic service layer, and an I / O abstraction layer. It adopts a service-oriented architecture (SOA) design, and the layers can communicate with each other through standardized service interfaces. Figure 3 In this architecture, the APP layer corresponds to the source of the control requests mentioned above, the scenario service layer corresponds to the scenario service layer mentioned in the previous steps, the service processing layer, composed of the enhancement service layer and the atomic service layer, can be used to determine the set of target execution mechanisms and their execution order, and the I / O abstraction layer, also known as the transport abstraction layer, can be used for the conversion, transmission, and distribution of control signals. The service processing layer includes the enhancement service layer and the atomic service layer. The enhancement service layer, as the center of service orchestration and composition, is responsible for receiving the target application scenarios distributed by the scenario service layer and flexibly orchestrating and combining multiple atomic services provided by the atomic service layer. The atomic service layer isolates the enhancement service layer from the I / O abstraction layer, and each atomic service module can provide standardized service interfaces for the enhancement service layer to call. Through this SOA architecture, the control logic required by different application scenarios can be implemented through different orchestrations and combinations of atomic services by the enhancement service layer. When adding or adjusting scenarios, only the scenario configuration in the scenario service layer or the orchestration rules in the enhancement service layer need to be modified; the atomic service layer and the I / O abstraction layer do not need to be changed.

[0043] Control requirements are the control objectives that need to be achieved in the target application scenario, such as the requirement to open or close a vehicle's cargo cover. Additionally, control requirements can be determined based on vehicle status or feedback during execution, such as obstacle detection and reversal requirements, warning requirements, speed limit requirements, or anti-trolling restrictions. The orchestration rules are preset logical flows used to decompose control requirements into multiple atomic operations and define their execution order. An atomic operation is the smallest execution unit in this embodiment of the invention, with each atomic operation corresponding to a specific execution mechanism or a no-operation.

[0044] In practical implementation, the enhanced service layer can analyze the target application scenario to determine the corresponding control requirements. For example, the business meaning of "user-initiated opening scenario" is that the user consciously initiates the operation of opening the lid, so the enhanced service layer determines the control requirement as an opening requirement; the business meaning of "speed control scenario" is that the current vehicle speed does not meet the safe opening conditions, so the enhanced service layer determines the control requirement as a speed limit requirement; the business meaning of "anti-pinch scenario" is that an obstacle is detected during execution, so the enhanced service layer determines the control requirement as an obstacle avoidance requirement. After determining the control requirements, the enhanced service layer calls the corresponding orchestration rules to decompose the control requirements into multiple atomic operations and clarifies the execution order between each atomic operation. Taking the opening request as an example, the orchestration rules determine that its corresponding atomic operations include the unlocking operation of the electric latch and the lifting operation of the strut motor. The execution order is to execute the unlocking operation first and then the lifting operation to ensure that the lid is unlocked before the lifting action is performed, avoiding mechanical jamming. Taking the closing request as an example, the orchestration rules determine that its corresponding atomic operations include the lowering operation of the strut motor and the locking operation of the electric latch. The execution order is to execute the lowering operation first and then the locking operation to ensure that the lid is closed in place before locking. Furthermore, the enhanced service layer can distribute the orchestrated atomic operation sequence to the atomic service layer, which can determine the specific execution mechanism corresponding to each atomic operation according to the preset mapping relationship. For example, the unlocking and locking operations correspond to the electric latch, and the lifting, lowering, and reverse / backward operations correspond to the strut motor. For operations that prohibit drive or prohibit response, no execution mechanism is corresponding, and the system continues to maintain the current state of the lid.

[0045] Furthermore, determining the control requirements corresponding to the target application scenario through the enhanced service layer also includes: obtaining the vehicle's current gear signal and current speed signal through the enhanced service layer; when the current gear signal is park and the current speed signal is zero, determining the control requirement corresponding to the target application scenario as a drive requirement; when the current speed signal is not zero, determining the control requirement corresponding to the target application scenario as a speed limit requirement; the atomic operation corresponding to the speed limit requirement is a drive-disable operation; determining the actuator corresponding to each atomic operation through the atomic service layer includes: if the atomic operation is a drive-disable operation, determining through the atomic service layer that the drive-disable operation does not correspond to an actuator, and continuing to maintain the current state of the cover.

[0046] For example, while the vehicle is in motion, a user might accidentally trigger a trunk opening request via the in-vehicle central control screen, or the near-field sensing module might misinterpret a legitimate key approaching due to signal interference and automatically trigger an opening request. Since the vehicle is in motion and the speed signal is not zero, when the enhanced service layer receives such a request, it will determine based on the current speed signal that the safe opening conditions are not met, classifying the control request as a speed limit requirement, prohibiting driving operation, and maintaining the trunk lid's current state to prevent the safety risks caused by accidental opening of the trunk lid while the vehicle is in motion. Furthermore, in practical applications, there may also be intelligent scenarios that automatically identify trunk openings. For example, the enhanced service layer can monitor navigation service events. When the navigation destination is the owner's residence and the current vehicle distance to the destination is less than a set threshold (e.g., 500 meters), the system can predict that the owner is about to arrive and may use the front trunk, intelligently calling the opening interface to provide a pre-opening reminder. In this scenario, if the vehicle speed signal is not zero, the enhanced service layer will also determine that the control requirement is a vehicle speed limit requirement and will not execute the opening action for the time being. The pre-opening action will be executed after the vehicle speed drops to zero and the gear is switched to parking gear, thereby achieving both safety and user experience.

[0047] Furthermore, determining multiple atomic operations corresponding to control requirements according to preset orchestration rules also includes: when the control requirement is an anti-play restriction requirement, determining the atomic operation corresponding to the anti-play restriction requirement as a prohibition response operation according to preset orchestration rules; determining the execution mechanism corresponding to each atomic operation through the atomic service layer includes: if the atomic operation is a prohibition response operation, determining through the atomic service layer that the prohibition response operation does not correspond to an execution mechanism, and continuing to maintain the current state of the lid.

[0048] For example, a child playing inside the car might repeatedly press physical buttons, or the owner might accidentally activate the remote key from outside the car, sending numerous on / off commands. This causes the controller to receive multiple invalid open or close requests within a short period (e.g., within one minute). In this case, the enhanced service layer determines this as an anti-play restriction requirement, classifies the atomic operation as a prohibited response operation, and prohibits responding to subsequent operation requests to prevent the actuator from overheating or being damaged due to frequent start-stop cycles. Simultaneously, the atomic service layer determines that the prohibited response operation does not correspond to an actuator, and the system maintains the current state of the door cover until the set anti-play timer period (e.g., no new requests within two consecutive minutes) is exceeded, after which it automatically resumes response. Since the prohibited response operation corresponding to the anti-play restriction requirement does not involve the driving of a specific actuator, the atomic service layer does not send any control signals to the I / O abstraction layer.

[0049] In addition, the scenario service layer can be configured with a self-learning scenario service to receive diagnostic command requests and detect the current scenario conditions. When the current scenario conditions meet the requirements, it can send a service request for diagnostic self-learning commands to the enhancement service layer. For example, after a vehicle rolls off the production line or after-sales maintenance replaces the strut motor, the newly installed strut motor needs to learn the opening and closing limit positions of the trunk lid to ensure control accuracy. At this time, the diagnostic device sends a self-learning request through the vehicle diagnostic interface. The scenario service layer parses this request into a self-learning scenario, the enhancement service layer determines the control requirement as a self-learning requirement, orchestrates the corresponding atomic operations as self-learning operations, and the self-learning atomic service in the atomic service layer receives the diagnostic command request, calls the I / O abstraction layer to control the front trunk strut for learning, generates corresponding learning status notifications (such as learning in progress, learning completed, learning interrupted, etc.), and sends them to the enhancement service layer and the atomic service layer so that the upper layer can know the learning progress and results. The self-learning operation corresponds to the strut motor. The atomic service layer maps it to the strut motor, drives the box cover from the mechanical closed position to the mechanical stop position, records and stores the corresponding Hall count value as a reference calibration parameter for the soft stop position and the extreme position.

[0050] The scenario service layer can also be configured with reminder scenario services. For example, when a user locks the car using the remote key, the vehicle simultaneously receives an arming notification. If the front trunk lid is open at this time, the arming operation will fail, and the system can issue a warning sound to alert the user. In this scenario, the scenario service layer parses the locking signal into a reminder scenario, the enhancement service layer determines the control requirement as a reminder requirement, and orchestrates the corresponding atomic operations as reminder operations. When the reminder atomic service in the atomic service layer receives the arming notification and detects that the front trunk lid is open, it generates a reminder arming failure notification and reminds the user to close the lid through an in-vehicle buzzer or flashing headlights. The actuator corresponding to the reminder operation can be determined according to the specific implementation method; for example, it can call the speaker or lighting module to output the reminder signal through the body domain controller.

[0051] Furthermore, based on the above embodiments, after determining the corresponding actuator and sending control signals to the actuators in the target actuator set according to the execution sequence through the transmission abstraction layer, this embodiment of the invention can also collect the operating parameters of the actuator during the movement process through the transmission abstraction layer, and determine whether the lid is obstructed based on the operating parameters; when the lid is obstructed, the transmission abstraction layer generates an obstruction signal and reports it to the service processing layer, so that the service processing layer determines the control requirement of the lid as an obstruction retreat requirement based on the obstruction signal. For example, if an object is accidentally trapped between the lid and the vehicle body during the closing process, the I / O abstraction layer collects the current signal of the strut motor in real time. When it detects an abnormal increase in the current value and exceeds a preset threshold, it determines that an obstruction has occurred, immediately generates an obstruction signal and reports it to the enhancement service layer. The enhancement service layer determines the control requirement as an obstruction retreat requirement based on this signal, and programs the corresponding atomic operation as a reverse retreat operation of the strut motor to drive the lid to move in the opposite direction to a safe position (such as retreating to a half-open position), thereby achieving anti-pinch safety protection.

[0052] like Figure 4 The diagram illustrates the division of the trunk lid's movement zones and its positional states. The mechanical closed position, full lock, half lock, soft stop position, and mechanical stop position are labeled to indicate the trunk lid's positional states at different stages of movement. Zones 1 to 5 represent the travel range traversed by the trunk lid during different movement stages. Considering the large load and high safety requirements of the front trunk, a current detection algorithm can be set for the transmission abstraction layer. When the trunk reaches different zones (zones 2, 3, and 4), different detection algorithms are triggered to determine the corresponding control signals. Specifically, different zones correspond to different trunk lid movement states: Zones 2, 3, and 4 are areas with smaller gaps between the trunk lid and the vehicle body and higher anti-pinch safety requirements. Therefore, different current change rate thresholds are used in these zones for anti-pinch detection to improve the sensitivity of anti-pinch detection and prevent current fluctuations during normal movement from being mistakenly interpreted as obstruction. When the trunk lid is about to reach the mechanical closed or full lock position, the electric locking mechanism performs a locking action. At this time, a dedicated current monitoring strategy for locking is used to ensure proper locking while preventing misjudgment. Furthermore, when the transmission abstraction layer detects an abnormal increase in current exceeding the threshold corresponding to that area, it immediately determines it as obstruction, generates an obstruction signal, and reports it to the atomic service layer. This causes the atomic service layer to trigger the corresponding safety policy (such as immediately stopping and reverting to the initial position). This current change rate algorithm is adaptable to different front trunks, struts, and door locks. When the sensor or actuator changes, only the relevant parameters of the current change rate need to be adjusted according to the calibration parameters. This function is encapsulated in a standard interface, which can be called for different scenarios. Thus, the anti-pinch function under different hardware configurations can be implemented through the unified interface of the transmission abstraction layer, and the upper service processing layer does not need to be aware of the underlying hardware differences.

[0053] In step S214, control signals are sent to the actuators in the target actuator set according to the execution order through the software interface set by the transmission abstraction layer, so as to drive the box cover to perform the corresponding actions.

[0054] Reference Figure 3 The transport abstraction layer (I / O abstraction layer), located below the atomic service layer, is a logical layer in the system architecture used to receive calls from the atomic service layer and create a unified software interface to shield the differences in hardware between different actuators. Control signals are instructions used to drive the actuators to perform physical actions. They are issued through standardized interfaces provided by the transport abstraction layer and do not depend on the specific hardware characteristics of the actuators. Standardized software interfaces for different actuator types can be configured in the transport abstraction layer, specifying hardware adaptation information such as the drive interface type, communication protocol, and signal format for each actuator. This allows the atomic service layer and the actuators to interact through standardized control instructions and status feedback without needing to concern themselves with the specific implementation details of the underlying hardware. When a standard instruction such as "open" or "close" is received from the upper layer, the transport abstraction layer translates the standard instruction into control signals that drive the hardware (such as PWM waves for driving motors and current for controlling locks). The controller, based on the type of each actuator in the target actuator set, calls the corresponding standardized software interface in the transport abstraction layer and issues control signals to each actuator according to the above execution order.

[0055] In the transmission abstraction layer, standardized control commands are converted into drive signals adapted to the hardware characteristics of each actuator based on the drive interface type and signal format of each actuator in the target actuator set. For example, the "unlock" command is converted into a drive signal that the electric latch can recognize (such as a PWM wave with a specific duty cycle or a CAN message with a specific ID), and the "lift" command is converted into a drive signal that the strut motor can recognize. The drive signals are then sent sequentially to the corresponding actuators according to the execution order. The transmission abstraction layer transmits the drive signals to the target actuators through the corresponding physical bus to drive the cover to perform the corresponding actions.

[0056] Furthermore, based on the above embodiments, after determining the corresponding actuator and sending control signals to the actuators in the target actuator set according to the execution sequence through the transmission abstraction layer, this embodiment of the invention can also collect the operating parameters of the actuator during the movement process through the transmission abstraction layer, and determine whether the lid is obstructed based on the operating parameters; when the lid is obstructed, the transmission abstraction layer generates an obstruction signal and reports it to the service processing layer, so that the service processing layer determines the control requirement of the lid as an obstruction retreat requirement based on the obstruction signal. For example, if an object is accidentally trapped between the lid and the vehicle body during the closing process, the I / O abstraction layer collects the current signal of the strut motor in real time. When it detects an abnormal increase in the current value and exceeds a preset threshold, it determines that an obstruction has occurred, immediately generates an obstruction signal and reports it to the enhancement service layer. The enhancement service layer determines the control requirement as an obstruction retreat requirement based on this signal, and programs the corresponding atomic operation as a reverse retreat operation of the strut motor to drive the lid to move in the opposite direction to a safe position (such as retreating to a half-open position), thereby achieving anti-pinch safety protection.

[0057] like Figure 4 The diagram illustrates the division of the trunk lid's movement areas and its positional states. The mechanical closed position, full lock, half lock, soft stop position, and mechanical stop position are labeled to indicate the trunk lid's positional states at different stages of movement. Areas 1 to 5 represent the travel range traversed by the trunk lid at different stages of movement. Considering the large load and high safety requirements of the front trunk, a current detection algorithm can be set for the transmission abstraction layer. When the trunk reaches different areas (area 2, area 3, area 4), different detection algorithms will be triggered to determine the corresponding control signals. Specifically, different areas correspond to different trunk lid movement states: areas 2, 3, and 4 are areas with small gaps between the trunk lid and the vehicle body and high anti-pinch safety requirements. In this embodiment, different current change rate thresholds are used in these areas for anti-pinch judgment to improve the sensitivity of anti-pinch detection and prevent current fluctuations during normal movement from being mistakenly interpreted as obstruction. When the trunk lid is about to reach the mechanical closed position or the full lock position, the electric locking mechanism performs a locking action. At this time, a dedicated current monitoring strategy for locking is used to ensure proper locking while preventing misjudgment. Furthermore, when the transmission abstraction layer detects an abnormal increase in current exceeding the threshold corresponding to that area, it immediately determines it as obstruction, generates an obstruction signal, and reports it to the atomic service layer. This causes the atomic service layer to trigger the corresponding safety policy (such as immediately stopping and reverting to the initial position). This current change rate algorithm is adaptable to different front trunks, struts, and door locks. When the sensor or actuator changes, only the relevant parameters of the current change rate need to be adjusted according to the calibration parameters. This function is encapsulated in a standard interface, which can be called for different scenarios. Thus, the anti-pinch function under different hardware configurations can be implemented through the unified interface of the transmission abstraction layer, and the upper service processing layer does not need to be aware of the underlying hardware differences.

[0058] In step S214, control signals are sent to the actuators in the target actuator set according to the execution order through the software interface set by the transmission abstraction layer, so as to drive the box cover to perform the corresponding actions.

[0059] Reference Figure 3 The transport abstraction layer (I / O abstraction layer), located below the atomic service layer, is a logical layer in the system architecture used to receive calls from the atomic service layer and create a unified software interface to shield the differences in hardware between different actuators. Control signals are instructions used to drive the actuators to perform physical actions. They are issued through standardized interfaces provided by the transport abstraction layer and do not depend on the specific hardware characteristics of the actuators. Standardized software interfaces for different actuator types can be configured in the transport abstraction layer, specifying hardware adaptation information such as the drive interface type, communication protocol, and signal format for each actuator. This allows the atomic service layer and the actuators to interact through standardized control instructions and status feedback without needing to concern themselves with the specific implementation details of the underlying hardware. When a standard instruction such as "open" or "close" is received from the upper layer, the transport abstraction layer translates the standard instruction into control signals that drive the hardware (such as PWM waves for driving motors and current for controlling locks). The controller, based on the type of each actuator in the target actuator set, calls the corresponding standardized software interface in the transport abstraction layer and issues control signals to each actuator according to the above execution order.

[0060] In the transmission abstraction layer, standardized control commands are converted into drive signals adapted to the hardware characteristics of each actuator based on the drive interface type and signal format of each actuator in the target actuator set. For example, the "unlock" command is converted into a drive signal that the electric latch can recognize (such as a PWM wave with a specific duty cycle or a CAN message with a specific ID), and the "lift" command is converted into a drive signal that the strut motor can recognize. The drive signals are then sent sequentially to the corresponding actuators according to the execution order. The transmission abstraction layer transmits the drive signals to the target actuators through the corresponding physical bus to drive the cover to perform the corresponding actions.

[0061] Furthermore, in conjunction with the above embodiments, the transmission abstraction layer can also collect and abstract the hardware status (such as latch status, motor current, motor Hall effect input, etc.), converting it into unified status signals (such as locked, opening, subjected to external force, etc.) and reporting them to the atomic service layer. By collecting and abstracting the hardware status, the operation of the actuator can be monitored in real time, and the underlying hardware status can be converted into unified status signals that the upper layer can recognize, providing a data foundation for the status management and security policies of the atomic service layer. Figure 4As shown, considering the high load and high safety characteristics of the front trunk, the I / O abstraction layer includes a current detection algorithm. This algorithm can be configured on the transmission abstraction layer, triggering different detection algorithms when the trunk moves to different areas (area 2, area 3, area 4) to determine the corresponding control signal. Specifically, the transmission abstraction layer can monitor the current in real time and establish a current-position model. When an abnormal increase in current exceeding a threshold is detected, it is immediately identified as obstruction, triggering a backoff. This current change rate algorithm is adaptable to different front trunks, struts, and door locks. When sensors or actuators change, only the relevant parameters of the current change rate need to be adjusted according to the calibration parameters. This function is encapsulated in a standard interface for use in different scenarios. Therefore, the anti-pinch function under different hardware configurations can be implemented through the unified interface of the transmission abstraction layer, without the upper service processing layer needing to be aware of the underlying hardware differences. Furthermore, when sensors or actuators change, only the relevant parameters of the current change rate need to be adjusted appropriately according to the calibration parameters, and this function is encapsulated in a standard interface for use in different scenarios, shortening the development cycle.

[0062] Compared to existing technologies where control code directly manipulates hardware registers or bus messages, requiring extensive software modifications when hardware changes occur, this invention, through the establishment of a transmission abstraction layer, enables the atomic service layer to transmit control commands and receive status feedback only in a standardized manner, without needing to concern itself with the specific driver methods and signal formats of the underlying hardware. When the actuator hardware changes, only the corresponding hardware adaptation configuration needs to be adjusted in the transmission abstraction layer; the upper-layer scene service layer, enhancement service layer, and atomic service layer remain unaffected.

[0063] Based on the above embodiments, this invention also provides a control device for a vehicle trunk lid, which is applied to a vehicle controller, as described above. Figure 5 The device includes: an application scenario determination module 10, used to respond to a control request for the vehicle's lid, parse the control request through a preset scenario service layer, and determine the target application scenario corresponding to the control request; wherein, the scenario service layer sets application scenarios corresponding to each function of the lid; an actuator determination module 20, used to determine a set of target actuators and the execution order of each actuator in the set of target actuators according to the arrangement rules corresponding to the target application scenario in the preset service processing layer; wherein, the service processing layer connects the scenario service layer and the transmission abstraction layer; and an execution module 30, used to send control signals to the actuators in the set of target actuators according to the execution order through the software interface set in the transmission abstraction layer, so as to drive the lid to perform corresponding actions.

[0064] The vehicle hatch control device provided in this embodiment of the invention has the same implementation principle and technical effect as the aforementioned method embodiment. For the sake of brevity, any parts not mentioned in the device embodiment can be referred to the corresponding content in the aforementioned method embodiment.

[0065] This invention also provides an electronic device, including a memory, a processor, and a computer program stored in the memory and executable on the processor. When the processor executes the computer program, it implements the above-described... Figures 1-2 The steps of any of the methods shown. Embodiments of the present invention also provide a computer-readable storage medium storing a computer program, which, when executed by a processor, performs the above-described steps. Figures 1-2 The steps of any of the methods shown. Embodiments of the present invention also provide a structural schematic diagram of an electronic device, such as... Figure 6 The diagram shows the structure of the electronic device, which includes a processor 101 and a memory 100. The memory 100 stores computer-executable instructions that can be executed by the processor 101. The processor 101 executes the computer-executable instructions to implement the above-mentioned... Figures 1-2 Any of the methods shown.

[0066] exist Figure 6In the illustrated embodiment, the electronic device further includes a bus 102 and a communication interface 103, wherein the processor 101, the communication interface 103, and the memory 100 are connected via the bus 102. The memory 100 may include high-speed random access memory (RAM) or non-volatile memory, such as at least one disk drive. Communication between this system network element and at least one other network element is achieved through at least one communication interface 103 (which can be wired or wireless), using the Internet, wide area network, local area network, metropolitan area network, etc. Bus 102 can be an ISA (Industry Standard Architecture) bus, a PCI (Peripheral Component Interconnect) bus, or an EISA (Extended Industry Standard Architecture) bus, or an AMBA (Advanced Microcontroller Bus Architecture) bus. AMBA defines three types of buses: APB (Advanced Peripheral Bus), AHB (Advanced High-performance Bus), and AXI (Advanced eXtensible Interface). Bus 102 can be divided into address bus, data bus, control bus, etc. For ease of representation, Figure 6The diagram uses only a single double-headed arrow, but this does not imply a single bus or a single type of bus. Processor 101 may be an integrated circuit chip with signal processing capabilities. In implementation, each step of the above method can be completed by the integrated logic circuitry in the hardware of processor 101 or by instructions in software form. Processor 101 can be a general-purpose processor, including a Central Processing Unit (CPU), a Network Processor (NP), etc.; it can also be a Digital Signal Processor (DSP), an Application Specific Integrated Circuit (ASIC), a Field-Programmable Gate Array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components. The general-purpose processor can be a microprocessor or any conventional processor. The steps of the method disclosed in the embodiments of this application can be directly manifested as execution by a hardware decoding processor, or execution by a combination of hardware and software modules in the decoding processor. The software module can reside in a mature storage medium in the field, such as random access memory, flash memory, read-only memory, programmable read-only memory, electrically erasable programmable memory, or registers. This storage medium is located in memory, and the processor 101 reads information from the memory and, in conjunction with its hardware, completes the aforementioned tasks. Figures 1-2 Any of the methods shown.

[0067] The computer program product of the vehicle hatch control method and device provided in this embodiment of the invention includes a computer-readable storage medium storing program code. The instructions included in the program code can be used to execute the methods described in the preceding method embodiments. For specific implementation, please refer to the method embodiments, which will not be repeated here. Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working process of the system described above can be referred to the corresponding process in the preceding method embodiments, which will not be repeated here. If the function is implemented in the form of 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 the present invention, or the part that contributes to the prior art, 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, a server, or a network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of the present invention. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, mobile hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0068] In the description of this invention, it should be noted that the terms "first," "second," and "third" are used for descriptive purposes only and should not be construed as indicating or implying relative importance. Finally, it should be noted that the above embodiments are merely specific implementations of this invention, used to illustrate the technical solutions of this invention, and not to limit it. The scope of protection of this invention is not limited thereto. Although this invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that any person skilled in the art can still modify or easily conceive of changes to the technical solutions described in the foregoing embodiments within the technical scope disclosed in this invention, or make equivalent substitutions for some of the technical features; and these modifications, changes, or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this invention, and should all be covered within the scope of protection of this invention. Therefore, the scope of protection of this invention should be determined by the scope of the claims.

Claims

1. A method for controlling a vehicle cargo cover, characterized in that, The method is applied to the controller of the vehicle, and the method includes: In response to a control request for the vehicle's cargo cover, the control request is parsed through a preset scenario service layer, and the target application scenario corresponding to the control request is determined; wherein, the scenario service layer is configured with application scenarios corresponding to each function of the cargo cover; The set of target execution mechanisms and the execution order of each execution mechanism in the set of target execution mechanisms are determined according to the orchestration rules corresponding to the target application scenario in the preset service processing layer; wherein, the service processing layer connects the scenario service layer and the transport abstraction layer; Through the software interface set by the transmission abstraction layer, control signals are sent to the actuators in the target actuator set according to the execution order to drive the box cover to perform the corresponding actions.

2. The method according to claim 1, characterized in that, The steps of parsing the control request through a preset scenario service layer and determining the target application scenario corresponding to the control request include: The scene service layer parses the request source identifier and execution action carried in the control request. The application scenario type to which the control request belongs is determined based on the request source identifier; the application scenario type includes user-initiated operation scenarios and vehicle-triggered scenarios. Based on the application scenario type and the execution action, the target application scenario corresponding to the control request is determined.

3. The method according to claim 1, characterized in that, The service processing layer includes an enhanced service layer and an atomic service layer; the steps of determining the target execution mechanism set and the execution order of each execution mechanism in the target execution mechanism set according to the orchestration rules corresponding to the target application scenario in the preset service processing layer include: The enhanced service layer determines the control requirements corresponding to the target application scenario, and determines multiple atomic operations corresponding to the control requirements according to preset orchestration rules, as well as the execution order between each atomic operation. The execution mechanism corresponding to each atomic operation is determined through the atomic service layer. The target execution mechanism set is composed of all the aforementioned execution mechanisms, and the execution order among the execution mechanisms is determined according to the execution order among each of the atomic operations.

4. The method according to claim 3, characterized in that, The control requirements corresponding to the target application scenario are determined through the enhanced service layer, including: The enhanced service layer parses the target application scenario to determine the control requirements corresponding to the target application scenario; wherein, the control requirements include at least one of the following: enable requirement, disable requirement, obstacle detection and fallback requirement, reminder requirement, speed limit requirement, or anti-play restriction requirement.

5. The method according to claim 4, characterized in that, The multiple atomic operations corresponding to the control requirements, determined according to preset arrangement rules, include: When the control requirement is an opening requirement, the atomic operations corresponding to the opening requirement are determined according to the preset programming rules, including the lifting operation of the strut motor for driving the movement of the box cover and the unlocking operation of the electric suction lock for unlocking the box cover. When the control requirement is a closing requirement, the atomic operations corresponding to the closing requirement are determined according to the preset programming rules, including the lowering operation of the strut motor used to drive the movement of the lid and the locking operation of the electric locking device used to lock the lid.

6. The method according to claim 4, characterized in that, The multiple atomic operations corresponding to the control requirement are determined according to the preset orchestration rules, including: when the control requirement is an anti-play restriction requirement, the atomic operation corresponding to the anti-play restriction requirement is determined to be a prohibit response operation according to the preset orchestration rules; Determining the actuator corresponding to each atomic operation through the atomic service layer includes: if the atomic operation is a prohibited response operation, the atomic service layer determines that the prohibited response operation does not correspond to an actuator, and continues to maintain the current state of the lid.

7. The method according to claim 3, characterized in that, Determining the control requirements corresponding to the target application scenario through the enhanced service layer further includes: obtaining the vehicle's current gear signal and current speed signal through the enhanced service layer; when the current gear signal is in park and the current speed signal is zero, determining the control requirement corresponding to the target application scenario as a drive requirement; when the current speed signal is not zero, determining the control requirement corresponding to the target application scenario as a speed limit requirement; the atomic operation corresponding to the speed limit requirement is a drive-disable operation; The atomic service layer determines the actuator corresponding to each atomic operation as follows: if the atomic operation is a prohibited response operation, the atomic service layer determines that the prohibited drive operation does not correspond to an actuator, and continues to maintain the current state of the lid.

8. The method according to claim 3, characterized in that, After issuing control signals to the actuators in the target actuator set according to the execution order, the method further includes: The transmission abstraction layer collects the operating parameters of the actuator during its movement and determines whether the lid encounters an obstruction based on the operating parameters. When the lid encounters an obstruction, an obstruction signal is generated through the transmission abstraction layer and reported to the service processing layer, so that the service processing layer determines the control requirement of the lid as an obstruction back-off requirement based on the obstruction signal.

9. The method according to claim 1, characterized in that, Through the software interface set by the transmission abstraction layer, control signals are sent to the actuators in the target actuator set according to the execution order, including: In the transmission abstraction layer, the control request is converted into the target control signal of the corresponding actuator according to the drive interface type and signal format of each actuator in the target actuator set; The target control signals are sent sequentially to the corresponding actuators according to the execution order.

10. A control device for a vehicle cargo cover, characterized in that, The device is applied to the controller of the vehicle, and the device includes: The application scenario determination module is used to respond to a control request for the vehicle's lid by parsing the control request through a preset scenario service layer and determining the target application scenario corresponding to the control request; wherein, the scenario service layer is configured with application scenarios corresponding to each function of the lid. An execution mechanism determination module is used to determine a set of target execution mechanisms and the execution order of each execution mechanism in the set of target execution mechanisms according to the orchestration rules corresponding to the target application scenario in the preset service processing layer; wherein, the service processing layer connects the scenario service layer and the transport abstraction layer; The execution module is used to send control signals to the actuators in the target actuator set according to the execution order through the software interface set by the transmission abstraction layer, so as to drive the box cover to perform the corresponding action.

Images