Sleep / Wake-up Methods, Systems, and Devices

Abstract

The present application relates to sleep / wake-up methods, systems, and apparatus. The method includes the steps of converting at least one first sleep / wake-up signal into at least one second sleep / wake-up signal, where the first sleep / wake-up signal represents a sleep / wake-up signal generated in an in-vehicle network of a first vehicle model and the second sleep / wake-up signal represents a unified sleep / wake-up signal into which a sleep / wake-up signal generated in an in-vehicle network of a different vehicle model and having the same function is converted; determining at least one static control target based on the at least one second sleep / wake-up signal, where the static control target indicates a function of the first sleep / wake-up signal; determining at least one sleep / wake-up operation based on the at least one static control target, where the sleep / wake-up operation is used to wake up at least one in-vehicle object in the at least one vehicle integration unit or to control at least one in-vehicle object in the at least one vehicle integration unit to enter a sleep state; and performing the at least one sleep / wake-up operation. The sleep / wake-up method, system and apparatus provided in the embodiments of the present application can implement sleep / wake-up control based on communication and computing architecture.

Description

Technical Field

[0001] This application claims priority to Chinese Patent Application No. 202210125226.9, titled "Sleep / Wake-up Method, System, and Device", filed with the China National Intellectual Property Administration on February 10, 2022, which is incorporated herein by reference in its entirety.

[0002] This application relates to the field of intelligent vehicles, and particularly to sleep / wake-up methods, systems, and devices.

Background Art

[0003] With the rapid development of intelligent connected vehicles, the rapid increase in the amount of vehicle information and the requirements for vehicle intelligence have jointly promoted the upgrade and evolution of the vehicle's electrical / electronic architecture. From the perspective of the Electronic Control Unit (ECU), the vehicle's electrical and electronic (E / E) architecture has undergone three generations of evolution.

[0004] The first generation is a distributed electrical / electronic architecture. In this architecture, one function corresponds to one ECU. The second generation is a centralized electrical / electronic architecture. In this architecture, the original single-function ECUs are integrated into controllers based on function types. For example, the ECUs are integrated into the powertrain domain, chassis domain, body domain, driving domain, and cockpit domain. The third generation is a central centralized electrical / electronic architecture. In this architecture, the function domains are further centralized to form one or more central computing units. In addition, the function domains of the second generation are further centralized to form zone controllers. The central centralized electrical / electronic architecture may also be referred to as the Communication&Computation Architecture (CCA).

[0005] Conventional sleep / wake solutions used in distributed electrical / electronic architectures are as follows: In vehicle sleep mode, the vehicle network needs to be woken up when certain functions are activated. The vehicle network can only enter sleep mode after all network nodes have met the sleep conditions. This sleep / wake solution affects the vehicle's power consumption and shortens the vehicle's static storage period. In addition, in this sleep / wake solution, network nodes influence each other. If a network node fails to enter sleep mode properly due to anomalies such as software vulnerabilities or hardware failures, it becomes difficult to locate the faulty network node.

[0006] In conventional technologies, sleep / wake-up solutions used in centralized electrical / electronic architectures are as follows: The sleep / wake-up requirements of ECUs in different network segments connected to a central gateway (CGW) are used as criteria to allow different network segments to enter sleep mode or wake up independently. Figure 1 is a diagram of an exemplary network topology of a centralized electrical / electronic architecture. As shown in Figure 1, the CGW of the centralized electrical / electronic architecture is connected to three Controller Area Networks (CANs): CAN 1, CAN 2, and CAN 3. Three ECUs, ECU 1, ECU 2, and ECU 3, are connected to CAN 1. Three ECUs, ECU 4, ECU 5, and ECU 6, are connected to CAN 2. Three ECUs, ECU 7, ECU 8, and ECU 9, are connected to CAN 3. When the vehicle is in sleep mode, if the CGW detects that ECU 1 on CAN 1 has been woken up, it determines whether there are any related ECUs on CAN 2 that have functional interactions with ECU 1. If there are related ECUs, the CGW wakes up CAN 2 and the related ECUs on CAN 2. If the CGW determines that all ECUs in CAN 1 have sent sleep requests, and all related ECUs that have functional interactions with all ECUs in CAN 1 have also sent sleep requests, it controls CAN 1 to enter sleep mode. Sleep / wake-up scenarios with multiple CGWs, and the interaction between CGWs in the sleep / wake-up process are not considered in this sleep / wake-up solution. In addition, sleep / wake-up methods based on Ethernet buses, Local Interconnect Network (LIN) buses, hardwiring, etc., are not considered in this sleep / wake-up solution.

[0007] In communication and computing architectures, ECUs implement the interaction of multiple networks using multiple Vehicle Integrated / Integration Units (VIUs). Therefore, none of the aforementioned sleep / wake-up solutions are applicable to communication and computing architectures. Given that a large number of automotive electrical / electronic architectures are already shifting from distributed and centralized electrical / electronic architectures to communication and computing architectures, how to implement sleep / wake-up control in communication and computing architectures has become an urgent issue that needs to be addressed. [Overview of the project] [Means for solving the problem]

[0008] In view of this, sleep / wake methods, systems, and apparatus are provided for implementing sleep / wake control based on communication and computing architectures.

[0009] According to a first aspect, one embodiment of the present application provides a sleep / wake-up method. This method is A step of converting at least one first sleep / wake-up signal to at least one second sleep / wake-up signal, wherein the first sleep / wake-up signal represents a sleep / wake-up signal generated within the in-vehicle network of a first vehicle model, and the second sleep / wake-up signal represents a unified sleep / wake-up signal obtained by converting sleep / wake-up signals generated within the in-vehicle networks of different vehicle models that have the same function, A step of determining at least one static control target based on at least one second sleep / wake-up signal, wherein the static control target exhibits the function of a first sleep / wake-up signal; A step of determining at least one sleep / wake-up operation based on at least one static control objective, wherein the sleep / wake-up operation is used to wake up at least one onboard object in at least one vehicle integration unit, or to control at least one onboard object in at least one vehicle integration unit to enter a sleep state; A step that performs at least one sleep / wake operation, Includes.

[0010] In possible implementations, the step of converting at least one first sleep / wake-up signal to at least one second sleep / wake-up signal is: A step of determining a second sleep / wake signal corresponding to at least one of the first sleep / wake signals based on a first mapping relationship, wherein the first mapping relationship represents a mapping relationship between a sleep / wake signal generated in the in-vehicle network of a first vehicle model and a unified sleep / wake signal. Includes.

[0011] In possible implementations, the step of determining at least one static control target based on at least one second sleep / wake-up signal is: A step of determining a static control target corresponding to at least one of two second sleep / wake-up signals based on a second mapping relationship, wherein the second mapping relationship represents a mapping relationship between a unified sleep / wake-up signal and an in-vehicle object, To obtain at least one static control goal, the steps include merging the static control goals corresponding to each second sleep / wake-up signal, Includes.

[0012] In possible implementations, the step of determining at least one sleep / wake-up operation based on at least one static control objective is: A step of determining, based on a third mapping relationship, at least one vehicle integration unit corresponding to any one of at least one static control target, and an in-vehicle object located within each determined vehicle integration unit that requires sleep / wake-up control, wherein the third mapping relationship represents a mapping relationship between the static control target, the vehicle integration unit, and the in-vehicle object that requires sleep / wake-up control; A step of determining at least one sleep / wake operation based on whether the in-vehicle object on which sleep / wake control needs to be performed is currently in an awake state or a sleep state, Includes.

[0013] In possible implementations, the first sleep / wake-up signal includes a first signal used to wake up the in-vehicle object and / or a second signal used to control the in-vehicle object to enter a sleep state, and the method is A step in which it is determined that a first signal has been acquired when a network management packet or service packet is received, or when a first level change is detected, or The step of determining that a second signal has been acquired when neither network management packets nor service packets are received within a predetermined time, or when a second level change is detected. It also includes.

[0014] According to a second aspect, one embodiment of the present application provides a sleep / wake-up system. The sleep / wake-up system includes a wake-up source parser, a wake-up policy controller, and a wake-up execution unit.

[0015] The wake-up source parser is configured to convert at least one first sleep / wake-up signal into at least one second sleep / wake-up signal, send at least one second sleep / wake-up signal to the wake-up policy controller, convert at least one first sleep / wake-up signal into at least one second sleep / wake-up signal, wherein the first sleep / wake-up signal represents a sleep / wake-up signal generated within the in-vehicle network of a first vehicle model, and the second sleep / wake-up signal represents a unified sleep / wake-up signal obtained by converting sleep / wake-up signals generated within the in-vehicle networks of different vehicle models that have the same function.

[0016] The wake-up policy controller is configured to determine at least one static control target based on at least one second sleep / wake-up signal, transmit at least one static control target to the wake-up execution unit, and have the static control target indicate the function of the first sleep / wake-up signal.

[0017] The wake-up execution unit is configured to determine at least one sleep / wake-up operation based on at least one static control objective, execute at least one sleep / wake-up operation, and the sleep / wake-up operation is used to wake up at least one onboard object in at least one vehicle integration unit, or to control at least one onboard object within at least one vehicle integration unit to enter a sleep state.

[0018] In possible implementations, the wake-up source parser and wake-up execution unit are deployed within the vehicle integration unit, while the wake-up policy controller is deployed within the domain controller.

[0019] In a possible implementation form, the wake-up source parser, the wake-up policy controller, and the wake-up execution unit are arranged within the vehicle integration unit.

[0020] In a possible implementation form, the wake-up policy controller includes a distributed wake-up policy controller and a centralized wake-up policy controller. The wake-up source parser, the wake-up execution unit, and the distributed wake-up policy controller are arranged within the vehicle integration unit, and the centralized wake-up policy controller is arranged within the domain controller.

[0021] In a possible implementation form, the wake-up source parser determines a second sleep / wake-up signal corresponding to any one of at least one first sleep / wake-up signal based on a first mapping relationship, and the first mapping relationship represents a mapping relationship between the sleep / wake-up signal generated in the in-vehicle network of the first vehicle model and the unified sleep / wake-up signal, and is further configured as such.

[0022] In a possible implementation form, the wake-up policy controller determines a static control target corresponding to any one of at least one second sleep / wake-up signal based on a second mapping relationship, and the second mapping relationship represents a mapping relationship between the unified sleep / wake-up signal and the in-vehicle object, and merges the static control targets corresponding to each second sleep / wake-up signal to obtain at least one static control target. and is further configured as such.

[0023] In a possible implementation form, the wake-up execution unit Based on the third mapping relationship, it is determined that at least one vehicle integration unit corresponds to at least one of the static control targets, and that sleep / wake-up control must be performed on the in-vehicle objects located within each determined vehicle integration unit, with the third mapping relationship representing the mapping relationship between the static control targets, the vehicle integration units, and the in-vehicle objects on which sleep / wake-up control must be performed. Determine at least one sleep / wake operation based on whether the in-vehicle object requiring sleep / wake control is currently in an awake state or a sleep state. It is further configured in this way.

[0024] In possible implementations, the first sleep / wake-up signal includes a first signal used to wake up the in-vehicle object and / or a second signal used to control the in-vehicle object to enter a sleep state, and the sleep / wake-up system further includes a wake-up source.

[0025] The wake-up source is configured to determine that a first signal has been acquired when a network management packet or service packet is received, or when a first level change is detected, or to determine that a second signal has been acquired when neither a network management packet nor a service packet is received within a predetermined time, or when a second level change is detected.

[0026] According to a third aspect, one embodiment of the present application provides a sleep / wake-up device. The device is A conversion module configured to convert at least one first sleep / wake signal into at least one second sleep / wake signal, wherein the first sleep / wake signal represents a sleep / wake signal generated within the in-vehicle network of a first vehicle model, and the second sleep / wake signal represents a unified sleep / wake signal obtained by converting sleep / wake signals generated within the in-vehicle networks of different vehicle models that have the same function, A first determination module is configured to determine at least one static control target based on at least one second sleep / wake-up signal, such that the static control target indicates the function of a first sleep / wake-up signal. A second determination module is configured to determine at least one sleep / wake-up operation based on at least one static control objective, and the sleep / wake-up operation is used to wake up at least one onboard object in at least one vehicle integration unit or to control at least one onboard object in at least one vehicle integration unit to enter a sleep state, An executable module configured to perform at least one sleep / wake operation, Includes.

[0027] In possible implementations, the conversion module is: Based on the first mapping relationship, a second sleep / wake signal is determined that corresponds to at least one of the first sleep / wake signals, and the first mapping relationship represents the mapping relationship between a sleep / wake signal generated within the in-vehicle network of a first vehicle model and a unified sleep / wake signal. It is further configured in this way.

[0028] In possible implementations, the first decision module is: Based on the second mapping relationship, a static control target corresponding to at least one of the second sleep / wake-up signals is determined, and the second mapping relationship represents the mapping relationship between the unified sleep / wake-up signal and the in-vehicle object. To obtain at least one static control objective, merge the static control objectives corresponding to each second sleep / wake-up signal. It is further configured in this way.

[0029] In possible implementations, the second decision module is: Based on the third mapping relationship, it is determined that at least one vehicle integration unit corresponds to at least one of the static control targets, and that sleep / wake-up control must be performed on the in-vehicle objects located within each determined vehicle integration unit, with the third mapping relationship representing the mapping relationship between the static control targets, the vehicle integration units, and the in-vehicle objects on which sleep / wake-up control must be performed. Determine at least one sleep / wake operation based on whether the in-vehicle object requiring sleep / wake control is currently in an awake state or a sleep state. It is further configured in this way.

[0030] In possible implementations, the first sleep / wake-up signal includes a first signal used to wake up the in-vehicle object and / or a second signal used to control the in-vehicle object to enter a sleep state, and the device A third determination module configured to determine that a first signal has been acquired when a network management packet or service packet is received, or when a first level change is detected, or A fourth determination module configured to determine that a second signal has been acquired when neither network management packets nor service packets are received within a predetermined time, or when a second level change is detected. It also includes.

[0031] According to a fourth aspect, one embodiment of the present application provides a sleep / wake device. The sleep / wake device may perform a sleep / wake method according to the first aspect or one or more possible implementations of the first aspect.

[0032] According to a fifth aspect, one embodiment of the present application provides a computer program product. The computer program product includes computer-readable code or a non-volatile computer-readable storage medium that carries the computer-readable code. When the computer-readable code is executed on an electronic device, a processor in the electronic device performs a sleep / wake-up method according to the first aspect or one or more possible implementations of the first aspect.

[0033] In embodiments of this application, sleep / wake-up signals generated within an in-vehicle network of different vehicle models may be converted into a unified sleep / wake-up signal, and a unified static control target is obtained to wake up an in-vehicle object within a vehicle integration unit, or to allow an in-vehicle object within a vehicle integration unit to enter a sleep state. Accordingly, sleep / wake-up control in the communication and computing architecture is implemented using software.

[0034] These and other embodiments of this application are described in more concise and easier to understand in the following description of the embodiments.

[0035] The accompanying drawings included herein and this specification, which constitute part of this specification, are intended to illustrate exemplary embodiments, features, and aspects of this application and to explain the principles of this application. [Brief explanation of the drawing]

[0036] [Figure 1] This is a diagram illustrating an exemplary network topology of a centralized electrical / electronic architecture. [Figure 2]This is a diagram illustrating an exemplary network topology of a ring network for communication and computing architectures. [Figure 3] This is a diagram illustrating an exemplary network topology of a ring network for communication and computing architectures. [Figure 4] This is a diagram illustrating an exemplary network topology of a ring network for communication and computing architectures. [Figure 5] This is a diagram illustrating an exemplary network topology of a star network in a communications and computing architecture. [Figure 6] This is a diagram illustrating an exemplary network topology of a star network in a communications and computing architecture. [Figure 7] This is a schematic diagram of the architecture of a sleep / wake-up system according to one embodiment of this application. [Figure 8] This is a flowchart of a sleep / wake-up method according to one embodiment of this application. [Figure 9] This is a schematic diagram of an exemplary network topology for communication and computing architectures. [Figure 10A] This is a flowchart illustrating the interaction of a sleep / wake-up method according to one embodiment of this application. [Figure 10B] This is a flowchart illustrating the interaction of a sleep / wake-up method according to one embodiment of this application. [Figure 11] This is a schematic diagram of the deployment of a wake-up / sleep system according to one embodiment of the present application. [Figure 12A] This is a flowchart illustrating the interaction of a sleep / wake-up method according to one embodiment of this application. [Figure 12B] This is a flowchart illustrating the interaction of a sleep / wake-up method according to one embodiment of this application. [Figure 13] This is a schematic diagram of the deployment of a wake-up / sleep system according to one embodiment of the present application. [Figure 14A] This is a flowchart illustrating the interaction of a sleep / wake-up method according to one embodiment of this application. [Figure 14B] This is a flowchart illustrating the interaction of a sleep / wake-up method according to one embodiment of this application. [Figure 15] This is a schematic diagram of the deployment of a wake-up / sleep system according to one embodiment of the present application. [Figure 16A] This is a flowchart illustrating the interaction of a sleep / wake-up method according to one embodiment of this application. [Figure 16B] This is a flowchart illustrating the interaction of a sleep / wake-up method according to one embodiment of this application. [Figure 16C] This is a flowchart illustrating the interaction of a sleep / wake-up method according to one embodiment of this application. [Figure 17] This is a schematic diagram of the structure of a sleep / wake-up device according to one embodiment of the present application. [Figure 18] This is a schematic diagram of the structure of a sleep / wake-up device according to one embodiment of the present application. [Modes for carrying out the invention]

[0037] The following describes in detail various exemplary embodiments, features, and aspects of this application with reference to the accompanying drawings. The same reference numerals in the accompanying drawings indicate elements having the same or similar function. While various aspects of the embodiments are shown in the accompanying drawings, the drawings are not necessarily drawn proportionally unless otherwise specified.

[0038] In this specification, the specific term “example” means “used as an example, embodiment, or illustration.” Embodiments described as “example” are not necessarily described as superior to or better than other embodiments.

[0039] In addition, to better illustrate this application, many specific details are given in the following specific embodiments. Those skilled in the art should understand that this application can be carried out without some of the specific details. In some cases, methods, means, elements and circuits well known to those skilled in the art are not described in detail so as to emphasize the subject matter of this application.

[0040] In the communication and computing architecture, the vehicle's ECUs are distributed across multiple zones, and one VIU is deployed in each zone to manage the ECUs within that zone. The VIUs are interconnected via high-speed Ethernet to implement high-speed communication for the vehicle. In embodiments of this application, the VIU may have one or more of the following functions: electronic control functions, specifically, the VIU is configured to implement electronic control functions provided by some or all of the ECUs in the aforementioned vehicle components; functions identical to those of a gateway, specifically, the VIU may further have some or all of the functions identical to those of a gateway, such as protocol conversion functions, protocol encapsulation and transmission functions, and data format conversion functions; and functions for processing data across vehicle components and parts, specifically, functions for processing, calculating, etc., data obtained from the execution units of multiple vehicle components. It should be noted that the above are merely examples of the functions of a VIU and are not intended to limit the VIU. The VIU may have more or fewer functions than those indicated above.

[0041] In communication and computing architectures, each functional domain of a vehicle has its own independent Domain Controller (DC). For example, a DC within a vehicle may include an Autonomous Driving Domain Controller (ADAS / AD Domain Controller, ADC), a Cockpit Domain Controller (CCDC), and a Vehicle Domain Controller (VDC).

[0042] The ADC may be configured to serve vehicle components that implement autonomous driving functions. These vehicle components include monocular cameras, binocular cameras, millimeter-wave radar, lidar, and ultrasonic radar. Note that the ADC's functionality may be implemented by a Mobile Data Center (MDC). The CDC may be configured to serve vehicle components within the cockpit domain. These components include head-up displays (HUDs), instrument displays, radios, navigation systems, and cameras. The VDC may be configured to serve vehicle components within the body domain and the chassis domain. These components include door and window controllers, power rearview mirrors, air conditioning systems, and central door locks. These components include components within the braking system, steering system, and acceleration system, such as the accelerator.

[0043] In embodiments of this application, the VDC, MDC, and CDC may be integrated with respect to logical functions based on requirements. In one example, the VDC and MDC are integrated; that is, the vehicle control services and autonomous driving services are integrated, and the CDC is maintained. In another example, the MDC and CDC are integrated; that is, the autonomous driving and entertainment control modules are integrated, and the VDC is maintained. In yet another example, the VDC and CDC are integrated; that is, the vehicle control services and entertainment control modules are integrated, and the MDC is maintained. In yet another example, the VDC, MDC, and CDC are integrated; that is, the vehicle control services and autonomous driving services are integrated. In this case, the VDC, MDC, and CDC are integrated into a central computer in the architecture. There is no longer a correspondence between functions and components, and the VIU is directed by the central computer as needed. In embodiments of this application, for the sake of explanation and understanding, xDC may be used to replace components obtained by integrating the VDC, MDC, or CDC, or two or three of the VDC, MDC, and CDC.

[0044] Considering the requirements of different vehicle models, the communication and computing architecture may support different network configurations of VIUs and xDCs, such as ring networks and star networks. Figures 2 through 4 are illustrative network topologies of a ring network for the communication and computing architecture, respectively. Figures 5 and 6 are illustrative network topologies of a star network for the communication and computing architecture, respectively. VIU 1, VIU 2, VIU 3, and VIU 4 in Figures 2 through 6 are VIUs. The functions of VIUs, VDCs, MDCs, and CDCs have been described above. Further details are not provided here. It should be understood that the communication and computing architectures shown in Figures 2 through 6 are merely examples of communication and computing architectures and are not intended to limit the scope of communication and computing architectures. The communication and computing architecture may further include more or fewer VIUs or have different network configurations. Further details are not provided here.

[0045] Signal-oriented communication is the conventional method of interaction in vehicles. Point-to-point data transmission is performed between ECUs via CAN and LIN buses. The communication method is determined before the vehicle is delivered. As vehicle architecture evolves into communication and computing architecture, most computing power is concentrated in xDC. Interaction between software and hardware within the vehicle is no longer point-to-point, and there is a great deal of collaboration between hardware. Any adjustments affect the entire network and cause update inconveniences. Signal-oriented communication is no longer suitable for communication and computing architectures.

[0046] Service-Oriented Architecture (SOA) is a software architecture that effectively solves the combination problem between software and hardware and is suited to the centralized evolution of electrical / electronic architectures. Under the SOA concept, when a vehicle needs to implement a function, related service A "subscribes" to the service from service B. After receiving the subscription information, service A "pushes" its service to service B, and the related service then implements the function. SOA makes software service-oriented. Service upgrades and adjustments do not affect the entire network, thereby improving the scalability of vehicle functions. Different services can call different software combinations, and different service combinations can implement different functions. This greatly enhances the reusability of the software.

[0047] In the communication and computing architecture, the VIU and xDC form the core network of the in-vehicle network, while CAN access, Ethernet access, LIN access, and General-Purpose Input / Output (GPIO) access connected to the VIU form the access network of the in-vehicle network. In embodiments of this application, sleep / wake methods such as CAN or LIN from the prior art are still used for the access network in order to maintain compatibility with existing ECUs. To ensure the flexibility of the sleep / wake solution, the sleep / wake method provided in embodiments of this application is used for the core network. The sleep / wake solution provided in embodiments of this application can simplify development for vehicle manufacturers and maximize the platformization of the sleep / wake solution. The sleep / wake solution provided in embodiments of this application may be loaded into in-vehicle devices in software form (early or later) and sold.

[0048] Figure 7 is a schematic diagram of the architecture of a sleep / wake-up system according to one embodiment of the present application. As shown in Figure 7, the sleep / wake-up system includes a wake-up source parser 11, a wake-up policy controller 12, and a wake-up execution unit 13.

[0049] The wake-up source parser 11 may be configured to convert at least one first sleep / wake-up signal into at least one second sleep / wake-up signal. The first sleep / wake-up signal may represent a sleep / wake-up signal generated within the in-vehicle network of a first vehicle model, and the first vehicle model may represent any vehicle model. It should be understood that sleep / wake-up signals generated within the in-vehicle networks of different vehicle models and having the same function will be different. For example, the in-vehicle network of vehicle model A (i.e., the first vehicle model) may implement a function to wake up all low-voltage power supplies of the vehicle by inputting a high level (i.e., a sleep / wake-up signal generated within the in-vehicle network of vehicle model A) using a PIN, while the in-vehicle network of vehicle model B (i.e., the first vehicle model) may implement a function to wake up all low-voltage power supplies of the vehicle using a CAN packet with KeyON=1 (i.e., a sleep / wake-up signal generated within the in-vehicle network of vehicle model B). The second sleep / wake-up signal may represent a unified sleep / wake-up signal obtained by converting sleep / wake-up signals that have the same function and are generated within the in-vehicle network of different vehicle models. For example, the wake-up source parser 11 may convert a high-level input using a PIN to "KL15=1", or a CAN packet with KeyON=1 to "KL15=1". It can be seen that the first sleep / wake-up signals that have the same function and are generated within the in-vehicle network of different vehicle models can be converted into a unified sleep / wake-up signal after being analyzed by the wake-up source parser 11.

[0050] In one example, the first sleep / wake-up signal may include, but is not limited to, CAN packets, Ethernet packets, LIN interface packets, or General-Purpose Input / Output (GPIO) packets. The packets may include, but are not limited to, network management packets or service packets. The type of packet is not limited to the embodiments of this application.

[0051] In possible implementations, the first sleep / wake-up signal includes a first signal used to wake up an in-vehicle object and / or a second signal used to control the in-vehicle object to enter a sleep state. The wake-up source parser 11 may determine that the first signal has been acquired when it receives a network management packet or service packet or detects a first level change, or the wake-up source parser 11 may determine that the second signal has been acquired when it does not receive a network management packet or service packet within a preset time or detects a second level change. The preset time may be set on a requirement basis, for example, 30 seconds or 1 minute, but is not limited to this application.

[0052] A first level change may indicate a level change used to wake up an in-vehicle object, and a second level change may indicate a level change used to control an in-vehicle object to enter a sleep state. The first level change may be a change from a low level to a high level, or a change from a high level to a low level. The second level change may be a change from a low level to a high level, or a change from a high level to a low level. In embodiments of this application, it is possible to pre-configure interfaces or lines in which a detected change from a low level to a high level is the first level change, interfaces or lines in which a detected change from a high level to a low level is the first level change, and interfaces or lines in which a detected change from a high level to a low level is the second level change. In this way, when the wake-up source parser 11 detects that the level on the interface or line has changed (from a low level to a high level, or from a high level to a low level), it may determine, based on the current content, whether the level change is a first level change or a second level change in order to determine whether the first signal or the second signal has been acquired.

[0053] As shown in Figure 7, when an external wake-up source (e.g., CAN, LIN, Ethernet interface, or GPIO) begins or stops transmitting network management or service packets, the wake-up source parser 11 receives N collected first sleep / wake signals. The wake-up source parser 11 converts the N first sleep / wake signals separately to obtain N second sleep / wake signals. N is an integer greater than or equal to 1, where N represents the number of first sleep / wake signals.

[0054] The wake-up source parser 11 may transmit at least one second sleep / wake-up signal to the wake-up policy controller 12. The transmission methods herein may be CANNM packets, CAN application packets, UDPNM packets, or user-defined IP protocol stack-based packets, or combinations thereof. In this embodiment of the application, the method by which the wake-up source parser 11 transmits the second sleep / wake-up signal to the wake-up policy controller 12 is not limited.

[0055] The wake-up policy controller 12 may be configured to determine at least one static control target (or referred to as a sleep / wake-up mode, wake-up mode, sleep mode, etc.) based on at least one second sleep / wake-up signal. The static control target may represent a function of the first sleep / wake-up signal. The static control targets described herein include static wake-up targets that wake up and / or static sleep targets that enter a sleep state. For example, a static control target may be a combination of CAN network segments, LIN network segments, Ethernet segments, or ECUs required for DC charging, unlocking with a Bluetooth key, or vehicle wake-up, or a combination of CAN network segments, LIN network segments, Ethernet segments, or ECUs required to enter a sleep state.

[0056] As shown in Figure 7, after receiving N second sleep / wake-up signals, wake up policy Controller 12 outputs M static control targets. M is an integer greater than or equal to 1, and M indicates the number of static control targets. Each second sleep / wake-up signal corresponds to each static control target, but considering that some static control targets may be merged, the wake-up signal... policyIt should be understood that the number of static control targets output by controller 12 may differ from the number of second sleep / wake-up signals received. For example, if second sleep / wake-up signal A corresponds to static control target A, then second sleep / wake-up signal B corresponds to static control target B, and second sleep / wake-up signal C corresponds to static control target C, and wake up policy The static control target last output by the controller 12 is the union of static control target A, static control target B, and static control target C. If static control target A, static control target B, and static control target C can be merged, the wake-up execution unit 13 will perform a wake-up to prevent it from executing unnecessary processing. policy The final output results of controller 12 need to be merged. For example, if static control objective A is CAN 1 wake-up, static control objective B is CAN 2 wake-up, and static control objective C is vehicle wake-up, then wake-up policy The controller 12 only needs to output a vehicle wake-up signal; it does not need to output CAN 1 wake-up, CAN 2 wake-up, or vehicle wake-up signals.

[0057] Wake up policy The controller 12 may transmit at least one static control target to the wake-up execution unit 13. The transmission method herein may be a CANNM packet, a CAN application packet, a UDPNM packet, or a user-defined IP protocol stack-based packet, or a combination thereof. In this embodiment of the application, wake-up policy The method by which the controller 12 transmits the static control target to the wake-up execution unit 13 is not limited. In possible implementations, wake-up policy The controller 12 may transmit static control targets to the wake-up execution unit 13 using a unicast or broadcast method.

[0058] The wake-up execution unit 13 may be configured to determine at least one sleep / wake-up operation based on at least one static control objective. The sleep / wake-up operation may be used to wake up at least one on-board object (e.g., CAN, LIN, or ECU) in at least one vehicle integration unit (VIU), or to control at least one on-board object in at least one vehicle integration unit to enter a sleep state. When the first sleep / wake-up signal is a first signal, the sleep / wake-up operation acquired based on the first sleep / wake-up signal may be used to wake up at least one on-board object in at least one vehicle integration unit. When the first sleep / wake-up signal is a second signal, the sleep / wake-up operation acquired based on the first sleep / wake-up signal may be used to control at least one on-board object in at least one vehicle integration unit to enter a sleep state.

[0059] The wake-up execution unit 13 may perform at least one determined sleep / wake-up operation. For example, performing a sleep / wake-up operation may include, but is not limited to, sending a CANNM to the ECU or waking up the ECU through a specific interface.

[0060] The sleep / wake-up system provided in this embodiment of the present application may be used in intelligent vehicles, new energy vehicles, conventional vehicles, etc. New energy vehicles include extended-range electric vehicles, fuel cell vehicles, and other new energy vehicles. Conventional vehicles include gasoline vehicles, diesel vehicles, etc.

[0061] According to the sleep / wake system provided in this embodiment of the present application, sleep / wake signals generated within an in-vehicle network of different vehicle models may be converted into a unified sleep / wake signal, and a unified static control target is obtained to wake up an in-vehicle object in a vehicle integration unit or to allow an in-vehicle object in a vehicle integration unit to enter a sleep state. Thus, sleep / wake control in the communication and computing architecture is implemented using software.

[0062] Figure 8 is a flowchart of a sleep / wake-up method according to one embodiment of the present application. This method may be applied to a sleep / wake-up system, for example, the sleep / wake-up system shown in Figure 7. As shown in Figure 8, this method may include the following steps.

[0063] Step S201: Convert at least one first sleep / wake signal to at least one second sleep / wake signal.

[0064] The first sleep / wake-up signal represents a sleep / wake-up signal generated within the in-vehicle network of the first vehicle model. The second sleep / wake-up signal represents a unified sleep / wake-up signal obtained by converting sleep / wake-up signals that have the same function and are generated within the in-vehicle networks of different vehicle models.

[0065] In one example, the first sleep / wake-up signal may include a first signal used to wake up an in-vehicle object. The sleep / wake-up system may determine that the first signal has been acquired when a network management packet or service packet is received, or when a first level change is detected. When the sleep / wake-up system determines that the first signal has been acquired, this indicates that one or more in-vehicle objects in one or more vehicle integration units need to be woken up.

[0066] In another example, the first sleep / wake-up signal may include a second signal used to control an in-vehicle object to enter a sleep state. If no network management or service packets are received within a pre-set time, or if a second level change is detected, the sleep / wake-up system determines that the second signal has been acquired. When the sleep / wake-up system determines that the second signal has been acquired, this indicates that one or more in-vehicle objects within one or more vehicle integration units need to be controlled to enter a sleep state.

[0067] For the sake of clarity, the network topology structure shown in Figure 9 is used as an example for the explanation of this embodiment of the present application. Figure 9 is a schematic diagram of an exemplary network topology of the communications and computing architecture. As shown in Figure 9, the communications and computing architecture includes four VIUs (VIU 1, VIU 2, VIU 3, and VIU 4), ​​a VDC, an MDC, and a CDC. As shown in Figure 9, VIU 1 includes CAN 11 and CAN 12, with ECUs 11, 12, and 13 connected to CAN 11, and ECUs 14, 15, and 16 connected to CAN 12. VIU 2 includes CAN 21 and LIN 21, with ECUs 21, 22, and 23 connected to CAN 21, and ECUs 24, 25, and 26 connected to LIN 21. VIU 3 includes CAN 31, CAN 32, and CAN 33, with ECU 31, ECU 32, and ECU 33 connected to CAN 31, ECU 34 and ECU 35 connected to CAN 33, and ECU 36 connected to CAN 32. VIU 4 includes CAN 41 and LIN 41, with ECU 41, ECU 42, and ECU 43 connected to LIN 41, and ECU 44, ECU 45 and ECU 46 are connected to CAN 41. VIU 1, VIU 2, VIU 3, and VIU 4 are vehicle integration units. CAN 11, CAN 12, LIN 21, etc., are on-board objects. ECU 11, ECU 12, ECU 13, etc., are also on-board objects. The first signal may be used to wake up one or more on-board objects in one or more vehicle integration units. For example, the first signal may be used to wake up CAN 11 in VIU 1, or to wake up ECU 14 and ECU 15 connected to CAN 12 in VIU 1. The second signal may be used to control one or more on-board objects in one or more vehicle integration units to enter a sleep state. For example, the second signal may be used to control the CAN 41 and LIN 41 within the VIU 4 to enter a sleep state, or it may be used to control the ECU 44 connected to the CAN 41 to enter a sleep state.

[0068] In a possible implementation, step S201 may include determining a second sleep / wake signal corresponding to any one of at least one first sleep / wake signal based on a first mapping relationship, wherein the first mapping relationship represents a mapping relationship between sleep / wake signals generated within the in-vehicle network of a first vehicle model and a unified sleep / wake signal.

[0069] Table 1 shows an example of the first mapping relationship. As shown in Table 1, based on Figure 9, when J4-35 of VIU 3 detects a high level, the sleep / wake-up system may determine that the first sleep / wake-up signal has been acquired. In this case, based on the first mapping relationship, the sleep / wake-up system may convert the first sleep / wake-up signal to the second sleep / wake-up signal "A + DC charge". When CAN 21 does not have a network management packet, the sleep / wake-up system may determine that the first sleep / wake-up signal has been acquired. In this case, based on the first mapping relationship, the sleep / wake-up system may convert the first sleep / wake-up signal to the second sleep / wake-up signal "CAN 21 requests to enter sleep state". In possible implementations, the name of the second sleep / wake-up signal may indicate the function of the second sleep / wake-up signal. Considering that the first sleep / wake-up signal before conversion corresponds to the second sleep / wake-up signal obtained through conversion, and that the implemented functions are the same, the name of the second sleep / wake-up signal further indicates the function of the first sleep / wake-up signal.

[0070] [Table 1]

[0071] As shown in Table 1, in this embodiment of the present application, a unique identifier may be assigned to each second sleep / wake-up signal. In this way, the identifier of the second sleep / wake-up signal is transferred instead of the name of the second sleep / wake-up signal to improve efficiency.

[0072] A sleep / wake-up system shown in Figure 7 is used as an example. The wake-up source parser 11 converts the first sleep / wake-up signal into a second sleep / wake-up signal and sends the second sleep / wake-up signal to the wake-up policy controller 12 for subsequent processing. In this embodiment of the present application, Interface 1 represents the interface between the wake-up source parser 11 and the wake-up policy controller 12, and the wake-up source parser 11 may send the second sleep / wake-up signal to the wake-up policy controller 12 through Interface 1.

[0073] Table 2 shows an example of interface 1. As shown in Table 2, the name corresponding to the second sleep / wake-up signal with identifier 2 is defined as "unlock using Bluetooth key" in interface 1. Therefore, when the wake-up source parser 11 transmits identifier 2 through interface 1, the wake-up policy controller 12 can learn that the name of the second sleep / wake-up signal is "unlock using Bluetooth key".

[0074] [Table 2]

[0075] In this embodiment of the present application, the first mapping relationship and interface 1 may be configured based on requirements and past experience.

[0076] Step S202: Determine at least one static control target based on at least one second sleep / wake-up signal.

[0077] The static control objective indicates the function of the first sleep / wake-up signal.

[0078] In a possible implementation, step S202 may include: determining a static control target corresponding to any one of at least one second sleep / wake-up signal based on a second mapping relationship, wherein the second mapping relationship represents a mapping relationship between a unified sleep / wake-up signal and an in-vehicle object; and merging the static control targets corresponding to each second sleep / wake-up signal in order to obtain at least one static control target.

[0079] Table 3 shows an example of the second mapping relationship. As shown in Table 3, when the sleep / wake system receives a second sleep / wake-up signal with identifier 1 based on Figure 9, a static control target with identifier 1, name "DC charging", and content "CAN 41" may be obtained based on the second mapping relationship. The static control target indicates the function "A+ DC charging". When the sleep / wake-up system receives a second sleep / wake-up signal with identifier 2, a static control target with identifier 2, name "Wake-up for unlocking using Bluetooth key", and content "CAN 11, CAN 12, and CAN 31" may be obtained based on the second mapping relationship. The static control target indicates the function "Unlocking using Bluetooth key".

[0080] [Table 3]

[0081] As shown in Table 3, in this embodiment of the present application, a unique identifier may be assigned to each static control target based on the function represented by each static control target, or a unique identifier may be assigned to each static control target based on requirements. In this way, the identifiers of the static control targets are used to improve efficiency, static control Your eyes This will be forwarded in place of the name and content of the tag.

[0082] The sleep / wake-up system shown in Figure 7 is used as an example. The wake-up policy controller 12 determines the static control target based on the second sleep / wake-up signal and transmits the static control target to the wake-up execution unit 13 for subsequent processing. In this embodiment of the present application, Interface 2 represents the interface between the wake-up policy controller 12 and the wake-up execution unit 13, and the wake-up Pupo The RISE controller 12 can transmit static control targets to the wake-up execution unit 13 via interface 2.

[0083] Table 4 shows an example of interface 2. As shown in Table 4, the content corresponding to a static control target with identifier 1 is defined as "CAN 41" in interface 2. Therefore, when the wake-up policy controller 12 transmits identifier 1 through interface 2, the wake-up execution unit 13 can learn that the name of the static control target is "DC charging" and the content of the static control target is "CAN 41".

[0084] [Table 4]

[0085] In this embodiment of the present application, the second mapping relationship and interface 2 may be configured based on requirements and past experience.

[0086] Step S203: Determine at least one sleep / wake-up operation based on at least one static control objective.

[0087] Sleep / wake-up operations are used to wake up at least one onboard object within at least one vehicle integration unit, or to control at least one onboard object within at least one vehicle integration unit to enter a sleep state. When the first sleep / wake-up signal is a first signal, the corresponding sleep / wake-up operation is used to wake up at least one onboard object within at least one vehicle integration unit. When the first sleep / wake-up signal is a second signal, the corresponding sleep / wake-up operation is used to control at least one onboard object within at least one vehicle integration unit to enter a sleep state.

[0088] In a possible implementation, step S203 may include, based on a third mapping relationship, determining at least one vehicle integration unit corresponding to any one of at least one static control target and an in-vehicle object located within each determined vehicle integration unit that requires sleep / wake-up control, wherein the third mapping relationship represents a mapping relationship between a static control target, a vehicle integration unit, and an in-vehicle object that requires sleep / wake-up control; and determining at least one sleep / wake-up operation based on whether the in-vehicle object that requires sleep / wake-up control is currently in an awake state or a sleep state.

[0089] Table 5 shows an example of a third mapping relationship. As shown in Table 5, when the sleep / wake-up system acquires a static control target with identifier 1 based on Figure 9, a sleep / wake-up operation can be acquired based on the third mapping relationship, where identifier 1, vehicle integration unit is "VIU 4", and onboard objects are ECUs 44 and 45 connected to "CAN 41". The sleep / wake-up operation is used to wake up ECUs 44 and 45, which are connected to "CAN 41" and located within the vehicle integration unit "VIU 4".

[0090] [Table 5]

[0091] In this embodiment of the present application, the third mapping relationship may be established based on requirements and past experience.

[0092] Step S204: Perform at least one sleep / wake operation.

[0093] The sleep / wake-up system may perform each sleep / wake-up operation to wake up at least one onboard object in at least one vehicle integration unit, or to control at least one onboard object in at least one vehicle integration unit to enter a sleep state.

[0094] According to the sleep / wake system provided in this embodiment of the present application, sleep / wake signals generated within an in-vehicle network of different vehicle models may be converted into a unified sleep / wake signal, and a unified static control target is obtained to wake up an in-vehicle object in a vehicle integration unit or to allow an in-vehicle object in a vehicle integration unit to enter a sleep state. Thus, sleep / wake control in the communication and computing architecture is implemented using software.

[0095] Figures 10A and 10B are flowcharts of the interaction of a sleep / wake-up method according to one embodiment of the present application. The method shown in Figures 10A and 10B may be applied to the system shown in Figure 7. As shown in Figures 10A and 10B, the method may include the following steps.

[0096] Step S401: The external wake-up source sends at least one first sleep / wake signal to the wake-up source parser.

[0097] Step S402: The wake-up source parser converts at least one first sleep / wake-up signal into at least one second sleep / wake-up signal.

[0098] Step S403: The wake-up source parser sends at least one second sleep / wake-up signal to the wake-up policy controller.

[0099] Step S404: The wake-up policy controller determines at least one static control target based on at least one second sleep / wake-up signal.

[0100] Step S405: The wake-up policy controller sends at least one static control target to the wake-up execution unit.

[0101] Step S406: The wake-up execution unit determines at least one sleep / wake-up operation based on at least one static control objective.

[0102] Step S407: The wake-up execution unit performs at least one sleep / wake operation to wake up at least one onboard object in at least one vehicle integration unit, or to enable at least one onboard object in at least one vehicle integration unit to enter a sleep state.

[0103] For steps S401 to S407, please refer to steps S201 to S204. Further details will not be explained here.

[0104] According to the sleep / wake-up method provided in this embodiment of the present application, sleep / wake-up signals generated within an in-vehicle network of different vehicle models may be converted into a unified sleep / wake-up signal, and a unified static control target is obtained to wake up an in-vehicle object in a vehicle integration unit or to allow an in-vehicle object in a vehicle integration unit to enter a sleep state. Thus, sleep / wake-up control in the communication and computing architecture is implemented using software.

[0105] In possible implementations, the wake-up source parser and wake-up execution unit within the sleep / wake-up system are located within the vehicle integration unit, while the wake-up policy controller is located within the domain controller.

[0106] Figure 11 is a schematic diagram of the deployment of a wake-up / sleep system according to one embodiment of the present application. As shown in Figure 11, based on the communication and computing architecture shown in Figure 9, the wake-up source parser and wake-up execution unit are deployed within each VIU (including VIU 1, VIU 2, VIU 3, and VIU 4), ​​and the wake-up policy controller is deployed within the xDC.

[0107] Figures 12A and 12B are flowcharts of the interaction of a sleep / wake-up method according to one embodiment of the present application. The method may be applied to the system shown in Figure 11. As shown in Figures 12A and 12B, the method includes the following steps:

[0108] Step S501: The external wake-up source sends a first sleep / wake-up signal to the wake-up source parser in the VIU.

[0109] An external signal source may transmit a first sleep / wake signal to a wake-up parser within each VIU. As shown in Figure 11, the external wake-up source transmits the first sleep / wake signal 11 and the first sleep / wake signal 12 to the wake-up source parser in VIU 1. The external wake-up source transmits the first sleep / wake signal 21 and the first sleep / wake signal 22 to the wake-up source parser in VIU 2. The external wake-up source transmits the first sleep / wake signal 31 and the first sleep / wake signal 32 (not shown) to the wake-up source parser in VIU 3. The external wake-up source transmits the first sleep / wake signal 41 and the first sleep / wake signal 42 to the wake-up source parser in VIU 4. It should be understood that an external wake-up source may send more or fewer first sleep / wake signals to the wake-up source parser within the VIU than those shown in Figure 11.

[0110] For example, an external wake-up source, "Passive Entry & Passive Start (PEPS)," may send a first sleep / wake signal, a "CANNM packet," to VIU 1.

[0111] Step S502: The wake-up source parser in the VIU converts the first sleep / wake-up signal into a second sleep / wake-up signal.

[0112] The wake-up source parser within each VIU can convert the received first sleep / wake signal into a second sleep / wake signal. As shown in Figure 11, the wake-up source parser in VIU 1 can convert the first sleep / wake signal 11 into the second sleep / wake signal 11 and the first sleep / wake signal 12 into the second sleep / wake signal 12. The wake-up source parser in VIU 2 can convert the first sleep / wake signal 21 into the second sleep / wake signal 21 and the first sleep / wake signal 22 into the second sleep / wake signal 22. The wake-up source parser in VIU 3 can convert the first sleep / wake signal 31 into the second sleep / wake signal 31 and the first sleep / wake signal 32 into the second sleep / wake signal 32 (not shown). The wake-up source parser within VIU 4 can convert the first sleep / wake-up signal 41 to the second sleep / wake-up signal 41, and the first sleep / wake-up signal 42 to the second sleep / wake-up signal 42. Note that the above is merely an example of the first and second sleep / wake-up signals. Actual implementations may include more or fewer first and second sleep / wake-up signals.

[0113] For example, a first sleep / wake signal, a "CANNM packet," can be converted into a second sleep / wake signal whose identifier is "2" and whose name is "unlock using Bluetooth key."

[0114] Step S503: The wake-up source parser in the VIU sends a second sleep / wake-up signal to the wake-up policy controller in the xDC.

[0115] A wake-up source parser within a VIU may send the acquired second sleep / wake-up signal to a wake-up policy controller within the xDC for processing. As shown in Figure 11, the wake-up source parser within VIU 1 may send the second sleep / wake-up signal 11 and the second sleep / wake-up signal 12 to the wake-up policy controller within the xDC. The wake-up source parser within VIU 2 may send the second sleep / wake-up signal 21 and the second sleep / wake-up signal 22 to the wake-up policy controller within the xDC. The wake-up source parser within VIU 4 may send the second sleep / wake-up signal 41 and the second sleep / wake-up signal 42 to the wake-up policy controller within the xDC.

[0116] In one example, the wake-up source parser in VIU 1 sends a second sleep / wake signal to the wake-up policy controller in xDC, where "identifier is 2 and name is unlock using Bluetooth key".

[0117] Step S504: The wake-up policy controller in xDC determines the static control target based on the second sleep / wake-up signal from the wake-up source parser in each VIU.

[0118] The wake-up policy controller within the xDC can determine a static control target based on each received second sleep / wake-up signal and obtain the final static control target by taking the union of the static control targets. As shown in Figure 11, the wake-up policy controller within the xDC ultimately obtains static control target 1.

[0119] In one example, the wake-up policy controller within the xDC acquires a static control objective, "Wake-up with Bluetooth Key Unlock," based on a second sleep / wake-up signal, "Identifier 2, Name: Unlock with Bluetooth Key" (as shown in Table 3).

[0120] Step S505: Wake up in xDC policy The controller sends static control targets to the wake-up execution unit within each VIU.

[0121] As shown in Figure 11, wake-up in xDC policy The controller sets static wake-up target 1 to VIU 1 The wake-up execution unit is sent separately to the wake-up execution unit in VIU 2, the wake-up execution unit in VIU 3 (not shown), and the wake-up execution unit in VIU 4.

[0122] For example, the wake-up policy controller in xDC sends a static control goal to the wake-up execution unit in all VIUs, where "identifier is 2 and name is Wake-up Unlock Using Bluetooth Key".

[0123] Step S506: The wake-up execution unit in the VIU determines which in-vehicle objects in the current VIU need to be woken up and / or enter sleep mode, based on the received static control target and the current state of each in-vehicle object in the VIU.

[0124] As shown in Figure 11, the wake-up execution unit in VIU 1 determines, based on static control target 1 and the state of each in-vehicle object in VIU 1, that sleep / wake-up operation 11 (e.g., wake up in-vehicle object 1) and sleep / wake-up operation 12 (e.g., control in-vehicle object 2 to enter sleep mode) needs to be executed. The wake-up execution unit in VIU 2 determines, based on static control target 1 and the state of each in-vehicle object in VIU 2, that sleep / wake-up operation 21 and sleep / wake-up operation 22 needs to be executed. The wake-up execution unit in VIU 3 determines, based on static control target 1 and the state of each in-vehicle object in VIU 3, that sleep / wake-up operation 31 and sleep / wake-up operation 32 (not shown) need to be executed. The wake-up execution unit within VIU 4 determines whether sleep / wake operations 41 and 42 need to be performed based on the static control target 1 and the state of each in-vehicle object within VIU 4. Please note that the above is only one example of sleep / wake operations. In actual execution, more or fewer sleep / wake operations may be determined.

[0125] For example, the wake-up execution unit in VIU 1 wakes up ECUs 11 and 12 connected to CAN 11, and wakes up ECUs 14, 15, and 16 connected to CAN 12. The wake-up execution unit in VIU 2 wakes up ECU 21 connected to CAN 21. The wake-up execution unit in VIU 3 does not have a corresponding sleep / wake operation. The wake-up execution unit in VIU 4 does not have a sleep / wake operation.

[0126] Step S507: The wake-up execution unit within the VIU needs to wake up and / or enter sleep mode, and controls the in-vehicle objects within the VIU to enter sleep mode.

[0127] In one example, VIU 1 and VIU 2 perform the sleep / wake operation described above, while VIU 3 and VIU 4 It does not need to perform sleep / wake-up operations.

[0128] According to the sleep / wake-up method provided in this embodiment of the present application, sleep / wake-up signals generated within an in-vehicle network of different vehicle models may be converted into a unified sleep / wake-up signal, and a unified static control target is obtained to wake up an in-vehicle object in a vehicle integration unit or to allow an in-vehicle object in a vehicle integration unit to enter a sleep state. Thus, sleep / wake-up control in the communication and computing architecture is implemented using software.

[0129] Considering that the vehicle has specific wake-up period requirements, for example, when the owner approaches the vehicle within a certain distance (e.g., 5 meters), the vehicle detects the vehicle key. In this case, the vehicle wakes up the VIU and xDC. If the user approaches the vehicle further, the vehicle may automatically unlock to provide the owner with a good user experience. If the vehicle wake-up time is long (e.g., more than 1 second), the doors may not be unlocked when the owner needs to open them. This impacts the customer experience. In Figure 11, the wake-up policy controller is deployed within the xDC, and all sleep / wake-up operations must go through a process from the "VIU" to the "xDC" and then back to the "VIU". Therefore, the vehicle's sleep / wake-up period is extended, which can affect the user experience.

[0130] In possible implementations, the wake-up source parser, wake-up policy controller, and wake-up execution unit within the sleep / wake-up system can all be located within the vehicle's integrated unit.

[0131] Figure 13 is a schematic diagram of the deployment of a wake-up / sleep system according to one embodiment of the present application. As shown in Figure 13, based on the communication and computing architecture shown in Figure 9, the wake-up source parser, wake-up execution unit, and wake-up policy controller are deployed within each VIU (including VIU 1, VIU 2, VIU 3, and VIU 4).

[0132] Considering that an external wake-up source on one VIU affects an in-vehicle object connected to another VIU, the static control target output by the wake-up policy controller on the VIU needs to be sent to the wake-up execution unit on each VIU for processing. For the sake of design simplification, we assume that the wake-up policy (i.e., the second mapping relationship) carried by all wake-up policy controllers is the same. In this case, only the wake-up source parser on one VIU needs to send the static control target to the wake-up execution unit on each VIU, and it is not necessary to send the second sleep / wake-up signal to the wake-up policy controller on another VIU for processing. In addition, we assume that the in-vehicle network is properly planned. When the wake-up policy controller on one VIU supports only external wake-up sources on the VIU (i.e., when the wake-up policy controller can only convert the first sleep / wake-up signal generated on the VIU), the objectives of waking up the vehicle and controlling the vehicle to enter a sleep state can still be implemented. As a general rule, one wake-up policy controller is deployed for each VIU. If, during the in-vehicle network design process, it is determined that an external wake-up source is not directly received within a particular VIU, then it is not necessary to deploy a wake-up policy controller for that VIU.

[0133] Figures 14A and 14B are flowcharts of the interaction of a sleep / wake-up method according to one embodiment of the present application. The method may be applied to the system shown in Figure 13. As shown in Figures 14A and 14B, the method includes the following steps:

[0134] Step S601: The external wake-up source sends a first sleep / wake-up signal to the wake-up source parser in the VIU.

[0135] Step S602: The wake-up source parser in the VIU converts the first sleep / wake-up signal into a second sleep / wake-up signal.

[0136] For steps S601 and S602, please refer to steps S501 and S502. Further details will not be explained here.

[0137] Step S603: The wake-up source parser in the VIU sends a second sleep / wake-up signal to the wake-up policy controller in the current VIU.

[0138] In one example, the wake-up source parser in VIU 1 sends a second sleep / wake signal to the wake-up policy controller in VIU 1, with the identifier being "2" and the name "unlock using Bluetooth key".

[0139] Step S604: The wake-up policy controller within the VIU determines the static control target based on a second sleep / wake-up signal from the wake-up source parser within the current VIU.

[0140] In one example, the wake-up policy controller within VIU 1 acquires a static control objective, "Wake-up with Bluetooth Key Unlock," based on a second sleep / wake-up signal, "Identifier 2, Name: Unlock with Bluetooth Key" (as shown in Table 3).

[0141] Step S605: Wake-up in VIU policy The controller sends the static control target to the wake-up execution unit within the VIU.

[0142] In possible implementations, wake-up within the VIU policyThe controller may transmit static control targets to the wake-up execution units in all VIUs. The wake-up execution unit in each VIU may then perform steps S606 and S607 to control the in-vehicle object. For example, as shown in Figure 9, the wake-up policy controller in VIU 1 transmits a static control target, "identifier is 2 and name is Bluetooth key unlock wake-up," separately to the wake-up execution units in VIU 1, VIU 2, VIU 3, and VIU 4.

[0143] In possible implementations, wake-up within the VIU policy The controller may transmit a static control objective to the wake-up execution unit within the VIU associated with the static control objective. For example, as shown in Table 3, the content of the static control objective "identifier is 2 and name is Wake-up for unlocking using Bluetooth key" includes CAN 11, CAN 12, and CAN 31. As shown in Figure 9, CAN 11 and CAN 12 are connected to VIU 1, and CAN 31 is connected to VIU 3. That is, the VIUs associated with the static control objective "identifier is 2 and name is Wake-up for unlocking using Bluetooth key" are VIU 1 and VIU 3. Therefore, the wake-up in VIU 1 policy The controller may separately transmit static control targets to the wake-up execution units in VIU 1 and VIU 3.

[0144] Step S606: The wake-up execution unit in the VIU determines which in-vehicle objects in the current VIU need to be woken up and / or enter sleep mode, based on the received static control target and the current state of each in-vehicle object in the VIU.

[0145] Step S607: The wake-up execution unit within the VIU needs to wake up and / or enter sleep mode, and controls the in-vehicle objects within the VIU to enter sleep mode.

[0146] For steps S606 and S607, please refer to steps S506 and S507. Further details will not be explained here.

[0147] In this embodiment of the present application, a wake-up policy controller deployed within the xDC is moved to each VIU so that the sleep / wake-up rate is accelerated when the local in-vehicle object of the VIU needs to enter sleep mode or be woken up.

[0148] In the wake-up policy controller mentioned in Figure 13, a conflict occurs when static control goals corresponding to wake-up sources received by different VIUs conflict, for example, if VIU 1 triggers CAN 21 to wake up and VIU 2 triggers CAN 21 to enter sleep mode.

[0149] In possible implementations, the wake-up policy controller is divided into a distributed wake-up policy controller and a centralized wake-up policy controller. The wake-up source parser, wake-up execution unit, and distributed wake-up policy controller within the sleep / wake-up system are deployed within the vehicle integration unit, while the centralized wake-up policy controller is deployed within the domain controller.

[0150] Figure 15 is a schematic diagram of the deployment of a wake-up / sleep system according to one embodiment of the present application. As shown in Figure 15, based on the communication and computing architecture shown in Figure 9, the wake-up source parser, wake-up execution unit, and distributed wake-up policy controller are deployed within each VIU (including VIU 1, VIU 2, VIU 3, and VIU 4), ​​and the centralized wake-up policy controller is deployed within the xDC.

[0151] Based on the principle of "fast wake-up and slow sleep," in order to ensure that a local wake-up source can quickly wake up an in-vehicle object and to avoid conflicts between the wake-up and sleep behaviors of different in-vehicle objects caused by different wake-up sources, this embodiment of the present application requires that the work for wake-up operations be divided between a distributed wake-up policy controller and a centralized wake-up policy controller. The distributed wake-up policy controller can determine wake-up only for in-vehicle objects within the local VIU. The centralized wake-up policy controller can determine wake-up only for in-vehicle objects across VIUs.

[0152] To ensure that the centralized policy controller can determine the wake-up source from a different VIU, wake-up source interface 1 needs to be modified to add a definition for the source VIU. The modified interface 1 (which may be called interface 3) is shown in Table 6.

[0153] [Table 6]

[0154] In sleep mode, in this embodiment of the present application, the policy related to entering the sleep state needs to be moved to a centralized wake-up policy controller based on Figures 14A and 14B. Figures 16A to 16C are flowcharts of the interaction of a sleep / wake-up method according to one embodiment of the present application. The method may be applied to the system shown in Figure 15. As shown in Figures 16A to 16C, the method includes the following steps:

[0155] Step S701: The external wake-up source sends a first sleep / wake-up signal to the wake-up source parser in the first VIU.

[0156] The first VIU represents the VUI in communication and computing architectures.

[0157] Step S702: The wake-up source parser in the first VIU converts the first sleep / wake-up signal into the second sleep / wake-up signal.

[0158] For steps S701 and S702, please refer to steps S501 and S502. Further details will not be explained here.

[0159] Step S7031: The wake-up parser in the first VIU sends a second sleep / wake-up signal to the distributed wake-up policy controller in the first VIU.

[0160] In one example, the wake-up source parser in VIU 1 sends a second sleep / wake-up signal to the distributed wake-up policy controller in VIU 1, where "identifier is 2 and name is unlock using Bluetooth key".

[0161] Step S7032: The wake-up parser in the first VIU sends a second sleep / wake-up signal to the centralized wake-up policy controller in the xDC.

[0162] In one example, the wake-up source parser in VIU 1 sends a second sleep / wake signal to the centralized wake-up policy controller in xDC, where "identifier is 2 and name is unlock using Bluetooth key".

[0163] Step S7041: The distributed wake-up policy controller in the first VIU determines the static control target based on the second sleep / wake-up signal from the wake-up source parser in the first VIU.

[0164] In one example, the distributed wake-up policy controller within VIU 1 determines a static control target "Wake-up for unlocking with Bluetooth key" based on a second sleep / wake-up signal from VIU 1 "with identifier 2 and name "Unlocking with Bluetooth key".

[0165] Step S7042: The centralized wake-up policy controller in xDC determines the static control target based on a second sleep / wake-up signal from the wake-up source parser in the first VIU.

[0166] For example, a centralized wake-up policy controller within xDC determines a static control target "Wake-up for unlocking with Bluetooth key" based on a second sleep / wake-up signal from VIU 1 "with identifier 2 and name "Unlock with Bluetooth key".

[0167] Step S7051: The distributed wake-up policy controller in the first VIU sends the determined static wake-up target to the wake-up execution unit in the first VIU.

[0168] In one example, the wake-up policy controller within VIU 1 sends a static control goal to all wake-up execution units within VIU 1, where "identifier is 2 and name is Bluetooth key unlock wake-up".

[0169] Step S7052: The centralized wake-up policy controller in the xDC sends the determined static wake-up target to the wake-up execution unit in the second VIU.

[0170] The second VIU represents VUIs other than the first VUI in the communication and computing architecture.

[0171] In one example, the wake-up policy controller in xDC sends a static control goal to the wake-up execution unit in a VIU other than VIU 1, where the identifier is "2" and the name is "Wake-up for unlocking using Bluetooth key".

[0172] Step S7061: The wake-up execution unit in the first VIU determines which in-vehicle objects in the first VIU need to be woken up and / or which need to enter sleep mode, based on the received static control target and the current state of each in-vehicle object in the VIU.

[0173] In one example, the wake-up execution unit in VIU 1 wakes up ECUs 11 and 12 connected to CAN 11, and then wakes up ECUs 14, 15, and 16 connected to CAN 12.

[0174] Step S7062: The wake-up execution unit in the second VIU determines which in-vehicle objects in the second VIU need to be woken up and / or which in-vehicle objects in the second VIU need to enter a sleep state, based on the received static control target and the current state of each in-vehicle object in the VIU.

[0175] For example, the wake-up execution unit in VIU 2 wakes up ECU 21, which is connected to CAN 21. The wake-up execution unit in VIU 3 does not have a corresponding sleep / wake operation. The wake-up execution unit in VIU 4 does not have a sleep / wake operation.

[0176] Step S7071: The wake-up execution unit in the first VIU needs to wake up, wakes up the in-vehicle object in the first VIU and / or enters sleep mode, and controls the in-vehicle object in the first VIU to enter sleep mode.

[0177] Step S7072: The wake-up execution unit in the second VIU needs to wake up and / or enter sleep mode, and controls the in-vehicle object in the second VIU to enter sleep mode.

[0178] In this embodiment of the present application, the distributed wake-up policy controller is deployed locally on the VIU, so that the wake-up speed can be increased when the VIU's wake-up source needs to wake up local in-vehicle objects. In addition, since the centralized wake-up policy controller is still maintained within the xDC, sleep / wake-up contention issues are resolved and reliability is improved.

[0179] In this embodiment of the present application, it should be noted that a wake-up policy controller deployed within a VIU may be referred to as a distributed wake-up policy controller, and a wake-up policy controller deployed within an xDC may be referred to as a centralized wake-up policy controller or a global wake-up policy controller.

[0180] Figure 17 is a schematic diagram of the structure of a sleep / wake-up device according to one embodiment of the present application. As shown in Figure 17, the device 1700 is A conversion module 1701 is configured to convert at least one first sleep / wake signal into at least one second sleep / wake signal, wherein the first sleep / wake signal represents a sleep / wake signal generated within the in-vehicle network of a first vehicle model, and the second sleep / wake signal represents a unified sleep / wake signal obtained by converting sleep / wake signals generated within the in-vehicle networks of different vehicle models that have the same function. A first determination module 1702 is configured to determine at least one static control target based on at least one second sleep / wake-up signal, such that the static control target indicates the function of the first sleep / wake-up signal, A second determination module 1703 is configured to determine at least one sleep / wake-up operation based on at least one static control objective, and the sleep / wake-up operation is used to wake up at least one onboard object in at least one vehicle integration unit or to control at least one onboard object in at least one vehicle integration unit to enter a sleep state, An executable module 1704 configured to perform at least one sleep / wake operation, It may include.

[0181] In possible implementations, the conversion module is: Based on the first mapping relationship, a second sleep / wake signal is determined that corresponds to at least one of the first sleep / wake signals, and the first mapping relationship represents the mapping relationship between a sleep / wake signal generated within the in-vehicle network of a first vehicle model and a unified sleep / wake signal. It is further configured in this way.

[0182] In possible implementations, the first decision module is: Based on the second mapping relationship, a static control target corresponding to at least one of the second sleep / wake-up signals is determined, and the second mapping relationship represents the mapping relationship between the unified sleep / wake-up signal and the in-vehicle object. To obtain at least one static control objective, merge the static control objectives corresponding to each second sleep / wake-up signal. It is further configured in this way.

[0183] In possible implementations, the second decision module is: Based on the third mapping relationship, it is determined that at least one vehicle integration unit corresponds to at least one of the static control targets, and that sleep / wake-up control must be performed on the in-vehicle objects located within each determined vehicle integration unit, with the third mapping relationship representing the mapping relationship between the static control targets, the vehicle integration units, and the in-vehicle objects on which sleep / wake-up control must be performed. Determine at least one sleep / wake operation based on whether the in-vehicle object requiring sleep / wake control is currently in an awake state or a sleep state. It is further configured in this way.

[0184] In possible implementations, the first sleep / wake-up signal includes a first signal used to wake up the vehicle-mounted object and / or a second signal used to control the vehicle-mounted object to enter a sleep state. Figure 18 is a schematic diagram of the structure of a sleep / wake-up device according to one embodiment of the present application. As shown in Figure 18, based on Figure 17, the device 1700 is: A third determination module 1705 is configured to determine that a first signal has been acquired when a network management packet or service packet is received, or when a first level change is detected, or A fourth determination module 1706 is configured to determine that a second signal has been acquired when neither network management packets nor service packets are received within a predetermined time, or when a second level change is detected. This may further include:

[0185] One embodiment of this application provides a sleep / wake device including a processor and a memory configured to store instructions that can be executed by the processor. The processor is configured to implement the aforementioned method when executing instructions.

[0186] One embodiment of this application provides a non-volatile computer-readable storage medium. The non-volatile computer-readable storage medium stores computer program instructions. When the computer program instructions are executed by a processor, the aforementioned method is implemented.

[0187] One embodiment of this application provides a computer program product including computer-readable code, or a non-volatile computer-readable storage medium carrying computer-readable code. When the computer-readable code is executed by a processor in an electronic device, the processor in the electronic device performs the method described above.

[0188] A computer-readable storage medium may be a tangible device capable of holding and storing instructions for use by an instruction execution device. A computer-readable storage medium may be, for example, an electronic storage device, a magnetic storage device, an optical storage device, an electromagnetic storage device, a semiconductor storage device, or any suitable combination thereof (but not limited to these). More specific examples (a non-exhaustive list) of computer-readable storage media include portable computer disks, hard disk drives, random access memory (RAM), and read-only memory (Read -This includes Memory Only (ROM), Electrically Programmable Read-Only Memory (EPROM, or Flash Memory), Static Random-Access Memory (SRAM), Compact Disc Read-Only Memory (CD-ROM), Digital Video Disc (DVD), Memory Stick, Floppy Disk, Mechanical coding devices such as punched cards or grooved protrusion structures for storing instructions, and any suitable combination thereof.

[0189] The computer-readable program instructions or code described herein may be downloaded from a computer-readable storage medium or via a network, such as the Internet, a local area network, a wide area network, and / or a wireless network, to an external computer or external storage device to the respective computing / processing device. The network may include copper transmission cables, optical fiber transmission, wireless transmission, routers, firewalls, switches, gateway computers, and / or edge servers. A network adapter card or network interface within each computing / processing device receives computer-readable program instructions from the network and transfers the computer-readable program instructions for storage in a computer-readable storage medium within each computing / processing device.

[0190] The computer program instructions used to perform the operations in this application may be assembly instructions, Instruction Set Architecture (ISA) instructions, machine instructions, machine-related instructions, microcode, firmware instructions, status setting data, or source code or object code written in any combination of one or more programming languages. Programming languages ​​include object-oriented programming languages ​​such as Smalltalk and C++, or traditional procedural programming languages ​​such as "C" or similar programming languages. Computer-readable program instructions may be executed entirely on a user computer, partially on a user computer, as a standalone software package, partially on a user computer, partially on a remote computer, or entirely on a remote computer or server. If a remote computer is involved, the remote computer may be connected to the user computer via any type of network, including a Local Area Network (LAN) or Wide Area Network (WAN), or it may be connected to an external computer (for example, via the Internet using an Internet Service Provider). In some embodiments, electronic circuits, such as programmable logic circuits, field-programmable gate arrays (FPGAs), or programmable logic arrays (PLAs), are customized by using status information of computer-readable program instructions. The electronic circuits may execute computer-readable program instructions to implement various embodiments of this application.

[0191] Various aspects of this application are described herein with reference to flowcharts and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this application. It should be understood that each block in a flowchart and / or block diagram, as well as any combination of blocks in a flowchart and / or block diagram, may be implemented by computer-readable program instructions.

[0192] These computer-readable program instructions may be provided to the processor of a general-purpose computer, a dedicated computer, or another programmable data processing device for manufacturing a machine, and as a result, when the instructions are executed by the computer's processor or another programmable data processing device, they create a device for performing the functions / operations specified in one or more blocks of a flowchart and / or block diagram. Alternatively, these computer-readable program instructions may be stored on a computer-readable storage medium. These instructions enable a computer, a programmable data processing device, and / or another device to operate in a particular way. Therefore, a computer-readable medium storing instructions contains artifacts containing instructions for implementing various aspects of the functions / operations specified in one or more blocks of a flowchart and / or block diagram.

[0193] Alternatively, computer-readable program instructions may be loaded into a computer, another programmable data processing device, or another device, resulting in a series of actions and steps being performed on the computer, another programmable data processing device, or another device to generate a computer implementation process. Thus, instructions executed on the computer, another programmable data processing device, or another device implement the functions / actions specified in one or more blocks of a flowchart and / or block diagram.

[0194] The flowcharts and block diagrams in the accompanying drawings illustrate possible implementations of system architectures, device functions and operations, systems, methods, and computer program products according to several embodiments of this application. In this regard, each block in a flowchart or block diagram may represent a module, program segment, or part of an instruction, and a module, program segment, or part of an instruction contains one or more executable instructions for implementing a specified logical function. In some alternative embodiments, the functions marked in a block may also be performed in a different order than those marked in the accompanying drawings. For example, two consecutive blocks may actually be executed substantially in parallel, or in reverse order depending on the functions they contain.

[0195] It should also be noted that each block in a block diagram and / or flowchart, as well as any combination of blocks in a block diagram and / or flowchart, may be implemented by hardware (e.g., a circuit or an ASIC (Application Specific Integrated Circuit)) that performs the corresponding function or operation, or by a combination of hardware and software, such as firmware.

[0196] While the present invention is described with reference to embodiments, a person skilled in the art can understand and implement other variations of the disclosed embodiments by referring to the accompanying drawings, the disclosed content, and the accompanying claims in the process of implementing the invention for which protection is claimed. In the claims, “comprising” does not exclude another component or another step, and “one” or “one” does not exclude multiple cases. A single processor or another unit may perform some of the functions enumerated in the claims. Although some means are described in different dependent claims, this does not mean that these means cannot be combined to produce a better effect.

[0197] The foregoing has described embodiments of the present application. The foregoing description is illustrative and not exhaustive, and is not limited to the embodiments disclosed. Many modifications and changes will be apparent to those skilled in the art without departing from the scope of the embodiments described. The choice of terms used herein is intended to best describe the principles of the embodiments, their practical applications, or improvements in the technology of the market, or to enable another person skilled in the art to understand the embodiments disclosed herein. [Explanation of symbols]

[0198] 1. Wake-up source interface, identifier, static wake-up target, static control target, in-vehicle object 2. In-vehicle objects, identifiers, and interfaces 3 Interfaces 11. Wake-up source parser, first sleep / wake-up signal, second sleep / wake-up signal, sleep / wake-up operation 12. Wake-up source policy controller, wake-up decision controller, first sleep / wake-up signal, second sleep / wake-up signal, sleep / wake-up operation 13 Wake-up Execution Unit 21 First sleep / wake-up signal, second sleep / wake-up signal, sleep / wake-up operation 22 First sleep / wake-up signal, second sleep / wake-up signal, sleep / wake-up operation 31. First sleep / wake-up signal, second sleep / wake-up signal, sleep / wake-up operation 32 First sleep / wake-up signal, second sleep / wake-up signal, sleep / wake-up operation 41. First sleep / wake-up signal, second sleep / wake-up signal, sleep / wake-up operation 42 First sleep / wake-up signal, second sleep / wake-up signal, sleep / wake-up operation 1700 equipment 1701 Conversion Module 1702 First determination module 1703 Second determination module 1704 Executable Module 1705 Third Determination Module 1706 Fourth Decision Module

Claims

1. A sleep / wake-up method performed by at least one processor, A step of converting at least one first sleep / wake-up signal to at least one second sleep / wake-up signal, wherein the first sleep / wake-up signal represents a sleep / wake-up signal generated within the in-vehicle network of a first vehicle model, and the second sleep / wake-up signal represents a unified sleep / wake-up signal obtained by converting sleep / wake-up signals generated within the in-vehicle networks of different vehicle models that have the same function; A step of determining at least one static control target based on the at least one second sleep / wake-up signal, wherein the static control target is determined based on an identifier included in the at least one second sleep / wake-up signal, and the static control target represents the function of the first sleep / wake-up signal. A step of determining at least one sleep / wake-up operation based on the at least one static control objective, wherein the sleep / wake-up operation is used to wake up at least one in-vehicle object in at least one vehicle integration unit, or to control at least one in-vehicle object in at least one vehicle integration unit to enter a sleep state; The steps include performing at least one sleep / wake operation, A method that includes this.

2. The step of converting at least one first sleep / wake-up signal to at least one second sleep / wake-up signal is: A step of determining a second sleep / wake signal corresponding to any one of the at least one first sleep / wake signal based on a first mapping relationship, wherein the first mapping relationship represents a mapping relationship between the sleep / wake signal generated in the in-vehicle network of the first vehicle model and the unified sleep / wake signal. The method according to claim 1, including the method described in claim 1.

3. The step of determining at least one static control target based on the at least one second sleep / wake-up signal is: A step of determining a static control target corresponding to any one of the at least one second sleep / wake-up signals based on a second mapping relationship, wherein the second mapping relationship represents a mapping relationship between the unified sleep / wake-up signal and the in-vehicle object, To obtain the aforementioned at least one static control target, the steps include merging the static control targets corresponding to each second sleep / wake-up signal, The method according to claim 1, including the method described in claim 1.

4. The step of determining at least one sleep / wake-up operation based on the at least one static control objective is: A step of determining, based on a third mapping relationship, at least one vehicle integration unit corresponding to any one of the at least one static control target and an in-vehicle object located within each determined vehicle integration unit that requires sleep / wake-up control, wherein the third mapping relationship represents a mapping relationship between the static control target, the vehicle integration unit, and the in-vehicle object that requires sleep / wake-up control; The steps include determining at least one sleep / wake operation based on whether the in-vehicle object on which sleep / wake control is to be performed is currently in an awake state or a sleep state, The method according to claim 1, including the method described in claim 1.

5. The first sleep / wake-up signal includes a first signal used to wake up the in-vehicle object and / or a second signal used to control the in-vehicle object to enter a sleep state, and the method is The step of determining that the first signal has been acquired when a network management packet or service packet is received, or when a first level change is detected, or The step of determining that the second signal has been acquired when neither network management packets nor service packets are received within a predetermined time, or when a second level change is detected. The method according to claim 1, further comprising:

6. A sleep / wake-up system comprising a wake-up source parser, a wake-up policy controller, and a wake-up execution unit, The wake-up source parser is configured to convert at least one first sleep / wake-up signal into at least one second sleep / wake-up signal, transmit the at least one second sleep / wake-up signal to the wake-up policy controller, convert the at least one first sleep / wake-up signal into the at least one second sleep / wake-up signal, wherein the first sleep / wake-up signal represents a sleep / wake-up signal generated within the in-vehicle network of a first vehicle model, and the second sleep / wake-up signal represents a unified sleep / wake-up signal obtained by converting sleep / wake-up signals generated within the in-vehicle networks of different vehicle models that have the same function. The wake-up policy controller is configured to determine at least one static control target based on the at least one second sleep / wake-up signal, the at least one static control target being determined based on an identifier included in the at least one second sleep / wake-up signal, and to transmit the at least one static control target to the wake-up execution unit, such that the static control target indicates the function of the first sleep / wake-up signal. The wake-up execution unit is configured to determine at least one sleep / wake-up operation based on the at least one static control objective, to execute the at least one sleep / wake-up operation, and the sleep / wake-up operation is used to wake up at least one in-vehicle object in at least one vehicle integration unit, or to control at least one in-vehicle object in at least one vehicle integration unit to enter a sleep state. system.

7. The system according to claim 6, wherein the wake-up source parser and the wake-up execution unit are located within a vehicle integration unit, and the wake-up policy controller is located within a domain controller.

8. The system according to claim 6, wherein the wake-up source parser, the wake-up policy controller, and the wake-up execution unit are located within a vehicle integration unit.

9. The system according to claim 6, wherein the wake-up policy controller comprises a distributed wake-up policy controller and a centralized wake-up policy controller, the wake-up source parser, the wake-up execution unit, and the distributed wake-up policy controller are deployed within a vehicle integration unit, and the centralized wake-up policy controller is deployed within a domain controller.

10. A sleep / wake-up device, wherein the device is A conversion module configured to convert at least one first sleep / wake signal into at least one second sleep / wake signal, wherein the first sleep / wake signal represents a sleep / wake signal generated within the in-vehicle network of a first vehicle model, and the second sleep / wake signal represents a unified sleep / wake signal obtained by converting sleep / wake signals generated within the in-vehicle networks of different vehicle models that have the same function, A first decision module configured to determine at least one static control target based on at least one second sleep / wake-up signal, wherein the static control target represents the function of the first sleep / wake-up signal, the first decision module being determined based on an identifier included in the at least one second sleep / wake-up signal, A second decision module is configured to determine at least one sleep / wake-up operation based on the at least one static control objective, wherein the sleep / wake-up operation is used to wake up at least one in-vehicle object in at least one vehicle integration unit or to control at least one in-vehicle object in at least one vehicle integration unit to enter a sleep state, An executable module configured to perform at least one of the sleep / wake operations, A device equipped with the following features.

11. The aforementioned conversion module is Based on the first mapping relationship, a second sleep / wake signal is determined that corresponds to any one of the at least one first sleep / wake signal, wherein the first mapping relationship represents the mapping relationship between the sleep / wake signal generated within the in-vehicle network of the first vehicle model and the unified sleep / wake signal. The apparatus according to claim 10, further configured as follows.

12. The first decision module described above is: Based on the second mapping relationship, a static control target corresponding to any one of the at least one second sleep / wake-up signals is determined, and the second mapping relationship represents the mapping relationship between the unified sleep / wake-up signal and the in-vehicle object. To obtain the aforementioned at least one static control objective, the static control objectives corresponding to each second sleep / wake-up signal are merged. The apparatus according to claim 10, further configured as follows.

13. The aforementioned second decision module is, Based on the third mapping relationship, at least one vehicle integration unit corresponding to any one of the at least one static control target and the in-vehicle objects within each determined vehicle integration unit that require sleep / wake-up control are determined, wherein the third mapping relationship represents the mapping relationship between the static control target, the vehicle integration unit, and the in-vehicle objects that require sleep / wake-up control. The system determines the at least one sleep / wake operation based on whether the in-vehicle object on which sleep / wake control is to be performed is currently in an awake state or a sleep state. The apparatus according to claim 10, further configured as follows.

14. The first sleep / wake-up signal comprises a first signal used to wake up the in-vehicle object and / or a second signal used to control the in-vehicle object to enter a sleep state, and the device A third decision module configured to determine that the first signal has been acquired when a network management packet or service packet is received, or when a first level change is detected, or A fourth decision module configured to determine that the second signal has been acquired when neither network management packets nor service packets are received within a predetermined time, or when a second level change is detected. The apparatus according to claim 10, further comprising:

15. A non-volatile computer-readable storage medium, wherein the non-volatile computer-readable storage medium stores computer program instructions, and when the computer program instructions are executed by a processor, the method according to claim 1 is implemented.

Images