SLEEP / WAKE UP METHOD, SYSTEM, AND APPARATUS

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, entitled "SLEEP / WAKE-UP METHOD, SYSTEM, AND APPARATUS," filed with the China State Intellectual Property Office on February 10, 2022, which is incorporated herein by reference in its entirety.

[0002] The present application relates to the field of intelligent vehicles, and in particular to sleep / wake-up methods, systems, and apparatus. [Background technology]

[0003] With the rapid development of intelligent connected vehicles, the exponential increase in the amount of vehicle information and the requirements for vehicle intelligence both promote the upgrade and evolution of the vehicle's electrical / electronic architecture. From the perspective of the electronic control unit (ECU), the vehicle's electrical / electronic (E / E) architecture has undergone three generations of evolution.

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

[0005] In the prior art, the sleep / wake-up solution used in the distributed electrical / electronic architecture is as follows: In the vehicle sleep state, the vehicle network needs to be woken up when a certain function is activated. The vehicle network can enter the sleep state only after all network nodes meet the sleep conditions. This sleep / wake-up solution affects the power consumption of the vehicle and shortens the stationary storage period of the vehicle. In addition, in this sleep / wake-up solution, the network nodes affect each other. When an abnormal factor such as software vulnerability or hardware failure prevents a network node from entering a sleep state normally, it is difficult to locate the abnormal network node.

[0006] In the prior art, the sleep / wake-up solution used in the centralized electric / electronic architecture is as follows: the sleep / wake-up requirements of ECUs in different network segments connected to a central gateway (CGW) are used as the criterion to independently enable different network segments to enter a sleep state or wake up different network segments. FIG. 1 is a diagram of an exemplary network topology of the centralized electric / electronic architecture. As shown in FIG. 1, the CGW of the centralized electric / 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. In vehicle sleep state, when detecting that ECU 1 on CAN 1 is woken up, the CGW determines whether there is an associated ECU on CAN 2 that has functional interaction with ECU 1. If there is an associated ECU, the CGW wakes up CAN 2 and the associated ECU on CAN 2. When it determines that all ECUs in CAN 1 send sleep requests and all associated ECUs that have functional interaction with all ECUs in CAN 1 also send sleep requests, the CGW controls CAN 1 to enter sleep state. Sleep / wake-up scenarios with multiple CGWs and mutual influence 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 bus, Local Interconnect Network (LIN) bus, hardwiring, etc. are not considered in this sleep / wake-up solution.

[0007] In the communication and computing architecture, the ECU uses multiple Vehicle Integrated / Integration Units (VIUs) to implement the interaction of multiple networks. Therefore, none of the aforementioned sleep / wake-up solutions are applicable to the communication and computing architecture. Considering that currently, a large amount of in-vehicle electric / electronic architectures have already changed from distributed electric / electronic architectures and centralized electric / electronic architectures to communication and computing architectures, how to implement sleep / wake-up control in the communication and computing architecture has become an urgent problem to be solved now. Summary of the Invention [Means for solving the problem]

[0008] In view of this, a sleep / wake-up method, system, and apparatus are provided for implementing sleep / wake-up control based on a communication and computing architecture.

[0009] According to a first aspect, an embodiment of the present application provides a sleep / wake-up method, the method comprising: converting at least one first sleep / wake-up signal into at least one second sleep / wake-up signal, the first sleep / wake-up signal representing a sleep / wake-up signal generated in an in-vehicle network of a first vehicle model, and the second sleep / wake-up signal representing a unified sleep / wake-up signal into which a sleep / wake-up signal having the same function generated in an in-vehicle network of a different vehicle model is converted; determining at least one static control objective based on the at least one second sleep / wake-up signal, the static control objective indicating a function of the first sleep / wake-up signal; determining at least one sleep / wake-up action based on at least one static control objective, the sleep / wake-up action being used to wake up at least one vehicle object in the at least one vehicle integration unit or to control at least one vehicle object in the at least one vehicle integration unit to enter a sleep state; performing at least one sleep / wake-up operation; Includes.

[0010] In a possible implementation, the step of converting the at least one first sleep / wake-up signal into the at least one second sleep / wake-up signal includes: determining a second sleep / wake-up signal corresponding to any one of the at least one first sleep / wake-up signal based on a first mapping relationship, the first mapping relationship representing a mapping relationship between a sleep / wake-up signal generated in an in-vehicle network of a first vehicle model and a unified sleep / wake-up signal; Includes.

[0011] In a possible implementation, the step of determining at least one static control objective based on the at least one second sleep / wake-up signal includes: determining a static control target corresponding to any one of the at least one second sleep / wake-up signal based on a second mapping relationship, the second mapping relationship representing a mapping relationship between the unified sleep / wake-up signal and an in-vehicle object; merging the static control targets corresponding to each second sleep / wake-up signal to obtain at least one static control target; Includes.

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

[0013] In a possible implementation, 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, and the method includes: determining that a first signal is acquired when a network management packet or a service packet is received or when a first level change is detected; or determining that a second signal has been acquired when no network management packet or no service packet is received within a predetermined time or when a second level change is detected; Further includes:

[0014] According to a second aspect, an embodiment of the present application provides a sleep / wake-up system, the sleep / wake-up system including a wake-up source parser, a wake-up policy controller, and a wake-up executor.

[0015] The wakeup source parser is configured to convert the at least one first sleep / wake-up signal into at least one second sleep / wake-up signal, send the at least one second sleep / wake-up signal to the wakeup policy controller, convert the at least one first sleep / wake-up signal into the at least one second sleep / wake-up signal, where the first sleep / wake-up signal represents a sleep / wake-up signal generated in the 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 the in-vehicle network of a different vehicle model and having the same function is converted.

[0016] The wake-up policy controller is configured to determine at least one static control objective based on the at least one second sleep / wake-up signal and send the at least one static control objective to the wake-up execution unit, the static control objective indicating a 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 the at least one static control target, execute the at least one sleep / wake-up operation, and the sleep / wake-up operation is used to wake up at least one vehicle-mounted object of the at least one vehicle integration unit or to control the at least one vehicle-mounted object in the at least one vehicle integration unit to enter a sleep state.

[0018] In a possible implementation, the wakeup source parser and the wakeup executor are deployed in the vehicle integration unit, and the wakeup policy controller is deployed in the domain controller.

[0019] In a possible implementation, the wakeup source parser, the wakeup policy controller, and the wakeup executor are located in a vehicle integration unit.

[0020] In a possible implementation, the wake-up policy controller includes a distributed wake-up policy controller and a centralized wake-up policy controller, where the wake-up source parser, the wake-up executor, and the distributed wake-up policy controller are deployed in the vehicle integration unit, and the centralized wake-up policy controller is deployed in the domain controller.

[0021] In a possible implementation, the wakeup source parser: Determine a second sleep / wake-up signal corresponding to any one of the at least one first sleep / wake-up signal based on a first mapping relationship, the first mapping relationship representing 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; The method is further configured as follows.

[0022] In a possible implementation, the wake-up policy controller: Determine a static control objective corresponding to any one of the at least one second sleep / wake-up signal based on a second mapping relationship, the second mapping relationship representing a mapping relationship between the unified sleep / wake-up signal and the vehicle-mounted object; merging the static control targets corresponding to each second sleep / wake-up signal to obtain at least one static control target; The method is further configured as follows.

[0023] In a possible implementation, the wakeup executor comprises: Determine at least one vehicle integrated unit corresponding to any one of the at least one static control target and an on-vehicle object for which the sleep / wake-up control needs to be performed and located within each determined vehicle integrated unit based on a third mapping relationship, the third mapping relationship representing a mapping relationship between the static control target, the vehicle integrated unit, and the on-vehicle object for which the sleep / wake-up control needs to be performed; determining at least one sleep / wake-up operation based on whether an in-vehicle object for which sleep / wake-up control needs to be performed is currently in an awake state or a sleep state; The method is further configured as follows.

[0024] In a possible implementation, 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, 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 a service packet is received or when a first level change is detected, or to determine that a second signal has been acquired when no network management packet or service packet is received within a predetermined time or when a second level change is detected.

[0026] According to a third aspect, an embodiment of the present application provides a sleep / wake-up device, comprising: a conversion module 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 representing a sleep / wake-up signal generated in an in-vehicle network of a first vehicle model, and the second sleep / wake-up signal representing a unified sleep / wake-up signal into which a sleep / wake-up signal having the same functionality generated in an in-vehicle network of a different vehicle model is converted; a first determination module configured to determine at least one static control objective based on the at least one second sleep / wake-up signal, the static control objective indicating a function of the first sleep / wake-up signal; a second determination module configured to determine at least one sleep / wake-up action based on the at least one static control objective, the sleep / wake-up action being used to wake up the at least one on-vehicle object in the at least one vehicle integration unit or to control the at least one on-vehicle object in the at least one vehicle integration unit to enter a sleep state; an execution module configured to perform at least one sleep / wake-up operation; Includes.

[0027] In a possible implementation, the conversion module includes: Determine a second sleep / wake-up signal corresponding to any one of the at least one first sleep / wake-up signal based on a first mapping relationship, the first mapping relationship representing 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; The method is further configured as follows.

[0028] In a possible implementation, the first determination module comprises: Determine a static control objective corresponding to any one of the at least one second sleep / wake-up signal based on a second mapping relationship, the second mapping relationship representing a mapping relationship between the unified sleep / wake-up signal and the vehicle-mounted object; merging the static control targets corresponding to each second sleep / wake-up signal to obtain at least one static control target; The method is further configured as follows.

[0029] In a possible implementation, the second determination module comprises: Determine at least one vehicle integrated unit corresponding to any one of the at least one static control target and an on-vehicle object for which the sleep / wake-up control needs to be performed and located within each determined vehicle integrated unit based on a third mapping relationship, the third mapping relationship representing a mapping relationship between the static control target, the vehicle integrated unit, and the on-vehicle object for which the sleep / wake-up control needs to be performed; determining at least one sleep / wake-up operation based on whether an in-vehicle object for which sleep / wake-up control needs to be performed is currently in an awake state or a sleep state; The method is further configured as follows.

[0030] In a possible implementation, 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, and the device: a third determination module configured to determine that the first signal is acquired when a network management packet or a service packet is received or when a first level change is detected; or a fourth determining module configured to determine that the second signal is acquired when no network management packet or no service packet is received within a predetermined time or when a second level change is detected; Further includes:

[0031] According to a fourth aspect, an embodiment of the present application provides a sleep / wake-up device, which may perform the sleep / wake-up method according to the first aspect or one or more of a plurality of possible implementation forms of the first aspect.

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

[0033] In an embodiment of the present application, the sleep / wake-up signals generated in the in-vehicle networks of different vehicle models may be converted into a unified sleep / wake-up signal, and a unified static control objective is obtained to wake up the in-vehicle objects in the vehicle integration unit or to enable the in-vehicle objects in the vehicle integration unit to enter a sleep state. Thus, the sleep / wake-up control in the communication and computation architecture is implemented using software.

[0034] These and other aspects of the present application will be more concise and easier to understand in the description of the embodiment(s) that follows.

[0035] The accompanying drawings and this specification, which are incorporated in and constitute a part of this specification, illustrate exemplary embodiments, features, and aspects of the present application and are intended to explain the principles of the present application. [Brief description of the drawings]

[0036] [Figure 1] FIG. 1 is a diagram of an example network topology of a centralized electrical / electronic architecture. [Diagram 2]FIG. 1 is a diagram of an example network topology of a ring network of a communications and computing architecture. [Diagram 3] FIG. 1 is a diagram of an example network topology of a ring network of a communications and computing architecture. [Figure 4] FIG. 1 is a diagram of an example network topology of a ring network of a communications and computing architecture. [Diagram 5] FIG. 1 is a diagram of an example network topology of a star network of a communications and computing architecture. [Figure 6] FIG. 1 is a diagram of an example network topology of a star network of a communications and computing architecture. [Figure 7] FIG. 1 is a schematic diagram of an architecture of a sleep / wake-up system according to an embodiment of the present application. [Figure 8] 2 is a flowchart of a sleep / wake-up method according to an embodiment of the present application. [Figure 9] FIG. 1 is a schematic diagram of an exemplary network topology of a communication and computing architecture. [Figure 10A] 1 is a flowchart of a sleep / wake-up method interaction according to an embodiment of the present application. [Figure 10B] 1 is a flowchart of a sleep / wake-up method interaction according to an embodiment of the present application. [Figure 11] FIG. 1 is a schematic diagram of a deployment of a wake-up / sleep system according to an embodiment of the present application. [Figure 12A] 1 is a flowchart of a sleep / wake-up method interaction according to an embodiment of the present application. [Figure 12B] 1 is a flowchart of a sleep / wake-up method interaction according to an embodiment of the present application. [Figure 13] FIG. 1 is a schematic diagram of a deployment of a wake-up / sleep system according to an embodiment of the present application. [Figure 14A] 1 is a flowchart of a sleep / wake-up method interaction according to an embodiment of the present application. [Figure 14B] 1 is a flowchart of a sleep / wake-up method interaction according to an embodiment of the present application. [Figure 15] FIG. 1 is a schematic diagram of a deployment of a wake-up / sleep system according to an embodiment of the present application. [Figure 16A] 1 is a flowchart of a sleep / wake-up method interaction according to an embodiment of the present application. [Figure 16B] 1 is a flowchart of a sleep / wake-up method interaction according to an embodiment of the present application. [Figure 16C] 1 is a flowchart of a sleep / wake-up method interaction according to an embodiment of the present application. [Figure 17] FIG. 2 is a schematic diagram of the structure of a sleep / wake-up device according to an embodiment of the present application; [Figure 18] FIG. 2 is a schematic diagram of the structure of a sleep / wake-up device according to an embodiment of the present application; DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0037] Various exemplary embodiments, features, and aspects of the present application are described in detail below with reference to the accompanying drawings, in which identical reference numbers indicate elements having the same or similar functions. While various aspects of the embodiments are illustrated in the accompanying drawings, the accompanying drawings are not necessarily drawn to scale unless otherwise specified.

[0038] The specific term "exemplary" herein means "serving as an example, embodiment, or illustration." An embodiment described as an "exemplary" is not necessarily described as being superior or better than other embodiments.

[0039] In addition, in order to better explain the present application, many specific details are given in the following specific embodiments. It should be understood by those skilled in the art that the present application can be practiced without some of the specific details. In some instances, 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 the present application.

[0040] In the communication and computation architecture, the ECUs of a vehicle are distributed into multiple zones, and one VIU is deployed in each zone to manage the ECUs in the zone. The VIUs are interconnected through high-speed Ethernet to implement high-speed communication of the vehicle. In an embodiment of the present application, the VIU may have one or more of the following functions: electronic control function, specifically, the VIU is configured to implement the electronic control function provided by some or all of the ECUs in the aforementioned vehicle components; functions the same as the functions of a gateway, specifically, the VIU may further have some or all of the functions the same as the functions of a gateway, such as a protocol conversion function, a protocol encapsulation and forwarding function, and a data format conversion function; functions to process data across vehicle components and parts, specifically, functions to process, calculate, etc., data obtained from the execution units of multiple vehicle components. It should be noted that the above is only an example of the functions of the VIU, and is not intended to limit the VIU. The VIU may have more or less functions than those shown above.

[0041] In the communication and computation architecture, there is an independent Domain Controller (DC) for each functional domain in the vehicle. For example, DCs in a vehicle may include an autonomous driving domain controller (ADAS\AD Domain Controller, ADC), a cockpit domain controller (CDC), a vehicle domain controller (VDC), etc.

[0042] The ADC may be configured to provide services to vehicle components that implement the autonomous driving function. The vehicle components that implement the autonomous driving function include monocular cameras, binocular cameras, millimeter wave radars, lidars, ultrasonic radars, etc. It should be noted that the functions of the ADC may be implemented by a Mobile Data Center (MDC). The CDC may be configured to provide services to vehicle components in the cockpit domain. The vehicle components in the cockpit domain include a Head-Up Display (HUD), an instrument display, a radio, navigation, cameras, etc. The VDC may be configured to provide services to vehicle components in the body domain and vehicle components in the chassis domain. The vehicle components in the body domain include door and window lift controllers, electric rearview mirrors, air conditioning, central door locks, etc. The vehicle components in the chassis domain include vehicle components in the braking system, vehicle components in the steering system, and vehicle components in the acceleration system, such as the accelerator.

[0043] In the embodiment of the present application, the VDC, MDC, and CDC may be integrated in terms of logical functions based on requirements. In one example, the VDC and MDC are integrated, i.e., the vehicle control service and the automated driving service are integrated, and the CDC is maintained. In another example, the MDC and CDC are integrated, i.e., the automated driving and entertainment control modules are integrated, and the VDC is maintained. In yet another example, the VDC and CDC are integrated, i.e., the vehicle control service and the entertainment control module are integrated, and the MDC is maintained. In yet another example, the VDC, MDC, and CDC are integrated, i.e., the vehicle control service and the automated driving service 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 the function and the component, and the VIU is instructed by the central computer as necessary. In the embodiment of the present application, for ease of explanation and understanding, in the embodiment of the present application, the xDC may be used to replace the component 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 forms of VIU and xDC, for example, ring network and star network. Figures 2 to 4 are diagrams of an exemplary network topology of a ring network of the communication and computing architecture, respectively. Figures 5 and 6 are diagrams of an exemplary network topology of a star network of the communication and computing architecture, respectively. VIU 1, VIU 2, VIU 3, and VIU 4 in Figures 2 to 6 are VIUs. The functions of VIU, VDC, MDC, and CDC have been described above. The details will not be described again here. It should be understood that the communication and computing architecture shown in Figures 2 to 6 is only one example of the communication and computing architecture, and is not intended to limit the communication and computing architecture. The communication and computing architecture may further include more or less VIUs, or have another network form. The details will not be described again here.

[0045] The signal-oriented communication method is the traditional interaction method of vehicles. Point-to-point data transmission is performed between ECUs through CAN buses and LIN buses. The communication method is decided before the vehicle is delivered. As the vehicle architecture evolves into a communication and computing architecture, most of the computing power is concentrated in the xDC. The interaction between software and hardware in the vehicle is no longer point-to-point, and there is a large amount of collaboration between hardware. Any adjustment will affect the entire network and cause the inconvenience of updates. The signal-oriented communication method is no longer suitable for the communication and computing architecture.

[0046] Service-Oriented Architecture (SOA) is a software architecture that effectively solves the combination problem between software and hardware and fits the centralized evolution of electrical / electronic architecture. Under the SOA concept, when a vehicle needs to implement a function, related service A "subscribes" to a service from service B. After receiving the subscription information, service A "pushes" its service to service B, and then the related service implements the function. SOA makes software service-oriented. The upgrade and adjustment of the service does not affect the whole network, which improves 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 software.

[0047] In the communication and computing architecture, the VIU and xDC form the core network of the in-vehicle network, and the 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 the embodiment of the present application, in order to maintain compatibility with existing ECUs, the sleep / wake-up method such as CAN or LIN in the conventional technology is still used for the access network. In order to ensure the flexibility of the sleep / wake-up solution, the sleep / wake-up method provided in the embodiment of the present application is used for the core network. The sleep / wake-up solution provided in the embodiment of the present application can simplify the development of vehicle manufacturers and maximize the platformization of the sleep / wake-up solution. The sleep / wake-up solution provided in the embodiment of the present application may be loaded into an in-vehicle device in the form of software (early or later) and sold.

[0048] 7 is a schematic diagram of the architecture of a sleep / wake-up system according to an embodiment of the present application. As shown in FIG. 7, the sleep / wake-up system includes a wake-up source parser 11, a wake-up policy controller 12, and a wake-up executor 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 in the in-vehicle network of a first vehicle model, and the first vehicle model may represent any vehicle model. It should be understood that the sleep / wake-up signals generated in the in-vehicle networks of different vehicle models and having the same function are different. For example, the in-vehicle network of vehicle model A (i.e., the first vehicle model) implements a function of waking up all low-voltage power supplies of the vehicle by inputting a high level using a PIN (i.e., the sleep / wake-up signal generated in the in-vehicle network of vehicle model A), and the in-vehicle network of vehicle model B (i.e., the first vehicle model) implements a function of waking up all low-voltage power supplies of the vehicle using a CAN packet with KeyON=1 (i.e., the sleep / wake-up signal generated in the in-vehicle network of vehicle model B). The second sleep / wake-up signal may represent a unified sleep / wake-up signal into which the sleep / wake-up signals generated in the in-vehicle networks of different vehicle models and having the same function are converted. For example, the wake-up source parser 11 may convert a high-level input using a PIN into "KL15=1", or convert a CAN packet of KeyON=1 into "KL15=1". It can be seen that the first sleep / wake-up signals generated in the in-vehicle networks of different vehicle models and having the same function can be converted into a unified sleep / wake-up signal after being parsed by the wake-up source parser 11.

[0050] In one example, the first sleep / wake-up signal includes, but is not limited to, a CAN packet, an Ethernet packet, a LIN interface packet, a General-Purpose Input / Output (GPIO) packet, etc. The packets include, but are not limited to, a network management packet, a service packet, etc. The type of the packet is not limited in the embodiment of the present application.

[0051] In a possible implementation, 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. The first signal may be determined to be acquired when the wake-up source parser 11 receives a network management packet or a service packet or detects a first level change, or the second signal may be determined to be acquired when the wake-up source parser 11 does not receive a network management packet or a service packet within a preset time or detects a second level change. The preset time may be set based on requirements, for example, 30 seconds or 1 minute. This is not limited in the present application.

[0052] The first level change can indicate a level change used to wake up the vehicle object, and the second level change can indicate a level change used to control the vehicle object to enter a sleep state. The first level change can 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 can be a change from a low level to a high level, or a change from a high level to a low level. In an embodiment of the present application, it is possible to pre-set an interface or line for which a detected change from a low level to a high level is a first level change, an interface or line for which a detected change from a low level to a high level is a second level change, an interface or line for which a detected change from a high level to a low level is a first level change, and an interface or line for which a detected change from a high level to a low level is a second level change. In this way, upon detecting a change in level on an interface or line (from low to high or from high to low), the wakeup source parser 11 may determine whether the level change is a first level change or a second level change based on the current content to determine whether a first signal or a second signal has been acquired.

[0053] 7, when an external wakeup source (e.g., a CAN, a LIN, an Ethernet interface, or a GPIO) starts to send a network management packet or a service packet or stops sending a network management packet or a service packet, the wakeup source parser 11 receives the collected N first sleep / wakeup signals. The wakeup source parser 11 converts the N first sleep / wakeup signals separately to obtain N second sleep / wakeup signals, where N is an integer equal to or greater than 1, and N indicates the number of first sleep / wakeup signals.

[0054] The wakeup source parser 11 can send at least one second sleep / wakeup signal to the wakeup policy controller 12. The sending manner in this specification can be a CANNM packet, a CAN application packet, a UDPNM packet, or a user-defined IP protocol stack-based packet, and combinations thereof. In this embodiment of the present application, the manner in which the wakeup source parser 11 sends the second sleep / wakeup signal to the wakeup 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, a wake-up mode, a sleep mode, etc.) based on the at least one second sleep / wake-up signal. The static control target may indicate a function of the first sleep / wake-up signal. The static control target herein includes a static wake-up target to be woken up and / or a static sleep target to enter a sleep state. For example, the static control target may be a combination of a CAN network segment, a LIN network segment, an Ethernet segment, or an ECU required for DC charging, a wake-up for unlocking using a Bluetooth key, or a vehicle wake-up, or a combination of a CAN network segment, a LIN network segment, an Ethernet segment, or an ECU required for entering a sleep state, etc.

[0056] As shown in FIG. 7, after receiving N second sleep / wake-up signals, the wake-up decision controller 12 outputs M static control targets, where M is an integer equal to or greater than 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, it should be understood that the number of static control targets output by the wake-up decision controller 12 may be different from the number of received second sleep / wake-up signals. For example, if the second sleep / wake-up signal A corresponds to static control target A, the second sleep / wake-up signal B corresponds to static control target B, and the second sleep / wake-up signal C corresponds to static control target C, the static control target finally output by the wake-up decision controller 12 is the union of the static control target A, the static control target B, and the static control target C. When static control objective A, static control objective B, and static control objective C can be merged, the final output result of wake-up decision controller 12 needs to be merged to prevent wake-up execution unit 13 from performing unnecessary processing. 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, wake-up decision controller 12 only needs to output vehicle wake-up, and does not need to output CAN 1 wake-up, CAN 2 wake-up, and vehicle wake-up.

[0057] The wake-up decision controller 12 may transmit at least one static control target to the wake-up execution unit 13. The transmission manner in this specification may be a CANNM packet, a CAN application packet, a UDPNM packet, or a user-defined IP protocol stack-based packet, and a combination thereof. In this embodiment of the present application, the manner in which the wake-up decision controller 12 transmits the static control target to the wake-up execution unit 13 is not limited. In a possible implementation form, the wake-up decision controller 12 may transmit the static control target to the wake-up execution unit 13 in a unicast or broadcast manner.

[0058] The wake-up execution unit 13 may be configured to determine at least one sleep / wake-up action based on at least one static control target. The sleep / wake-up action may be used to wake up at least one vehicle object (e.g., CAN, LIN, or ECU) in at least one vehicle integration unit (VIU) or to control at least one vehicle object in the 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 action obtained based on the first sleep / wake-up signal may be used to wake up at least one vehicle object in the at least one vehicle integration unit. When the first sleep / wake-up signal is a second signal, the sleep / wake-up action obtained based on the first sleep / wake-up signal may be used to control at least one vehicle object in the at least one vehicle integration unit to enter a sleep state.

[0059] The wake-up execution unit 13 may execute at least one of the determined sleep / wake-up operations. In one example, executing the sleep / wake-up operation includes, but is not limited to, sending a CANNM to the ECU and waking up the ECU through a specific interface.

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

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

[0062] 8 is a flowchart of a sleep / wake-up method according to an embodiment of the present application. The method can be applied to a sleep / wake-up system, such as the sleep / wake-up system shown in FIG 7. As shown in FIG 8, the method can include the following steps:

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

[0064] 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 converted from a sleep / wake-up signal having the same function generated in an in-vehicle network of a different vehicle model.

[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 a 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 the on-board objects to enter a sleep state. When no network management packet or service packet is received within a preset time or 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 on-board objects in one or more vehicle integration units need to be controlled to enter a sleep state.

[0067] For ease of explanation, the network topology structure shown in FIG. 9 is used as an example for explanation in this embodiment of the present application. FIG. 9 is a schematic diagram of an exemplary network topology of a communication and computing architecture. As shown in FIG. 9, the communication 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 FIG. 9, VIU 1 includes a CAN 11 and a CAN 12, ECU 11, ECU 12, and ECU 13 are connected to the CAN 11, and ECU 14, ECU 15, and ECU 16 are connected to the CAN 12. VIU 2 includes a CAN 21 and a LIN 21, ECU 21, ECU 22, and ECU 23 are connected to the CAN 21, and ECU 24, ECU 25, and ECU 26 are connected to the LIN 21. VIU 3 includes CAN 31, CAN 32, and CAN 33, ECU 31, ECU 32, and ECU 33 are connected to CAN 31, ECU 34 and ECU 35 are connected to CAN 33, and ECU 36 is connected to CAN 32. VIU 4 includes CAN 41 and LIN 41, ECU 41, ECU 42, and ECU 43 are connected to LIN 41, and ECU 44, CU 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 in-vehicle objects. ECU 11, ECU 12, ECU 13, etc. are also in-vehicle 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 may be used 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 in the VIU 4 to enter a sleep state, or may be used to control the ECU 44 connected to the CAN 41 to enter a sleep state.

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

[0069] Table 1 shows an example of the first mapping relationship. As shown in Table 1, based on FIG. 9, when J4-35 of VIU 3 detects a high level, the sleep / wake-up system may determine that a first sleep / wake-up signal is acquired. In this case, the sleep / wake-up system may convert the first sleep / wake-up signal to a second sleep / wake-up signal "A+ DC charging" based on the first mapping relationship. When CAN 21 does not have a network management packet, the sleep / wake-up system may determine that a first sleep / wake-up signal is acquired. In this case, the sleep / wake-up system may convert the first sleep / wake-up signal to a second sleep / wake-up signal "request CAN 21 to enter sleep state" based on the first mapping relationship. In a possible implementation, 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 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] In this embodiment of the present application, a unique identifier may be set for each second sleep / wake-up signal, as shown in Table 1. In this way, the identifier of the second sleep / wake-up signal is transmitted instead of the name of the second sleep / wake-up signal to improve efficiency.

[0072] The 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 an interface between the wake-up source parser 11 and the wake-up policy controller 12, and the wake-up source parser 11 can 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 with Bluetooth key" in interface 1. Therefore, when wakeup source parser 11 forwards identifier 2 through interface 1, wakeup policy controller 12 may learn that the name of the second sleep / wake-up signal is "unlock with Bluetooth key".

[0074] [Table 2]

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

[0076] Step S202: Determine at least one static control objective based on the 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 form, step S202 may include a step of determining a static control target corresponding to any one of the at least one second sleep / wake-up signal based on a second mapping relationship, where the second mapping relationship represents a mapping relationship between a unified sleep / wake-up signal and an on-vehicle object, and a step of merging the static control targets corresponding to each second sleep / wake-up signal to obtain at least one static control target.

[0079] Table 3 shows an example of the second mapping relationship. As shown in Table 3, based on FIG. 9, when the sleep / wake-up system acquires a second sleep / wake-up signal with an identifier of 1, a static control target with an identifier of 1, a name of “DC charging”, and a content of “CAN 41” can be acquired based on the second mapping relationship. The static control target indicates the function “A+DC charging”. When the sleep / wake-up system acquires a second sleep / wake-up signal with an identifier of 2, a static control target with an identifier of 2, a name of “wake-up unlocking with Bluetooth key”, and a content of “CAN 11, CAN 12, and CAN 31” can be acquired based on the second mapping relationship. The static control target indicates the function “unlocking with Bluetooth key”.

[0080] [Table 3]

[0081] As shown in Table 3, in this embodiment of the present application, a unique identifier may be set for each static control target based on the function indicated by each static control target, or a unique identifier may be set for each static control target based on requirements. In this way, the identifier of the static control target is transferred instead of the name and content of the static controllable target to improve efficiency.

[0082] The sleep / wake-up system shown in Fig. 7 is used as an example. The wake-up policy controller 12 determines a static control target based on the second sleep / wake-up signal, and sends the static control target to the wake-up executor 13 for subsequent processing. In this embodiment of the present application, Interface 2 represents an interface between the wake-up policy controller 12 and the wake-up executor 13, and the wake-up source policy controller 12 can send the static control target to the wake-up executor 13 through Interface 2.

[0083] Table 4 shows an example of interface 2. As shown in Table 4, the content corresponding to the static control target with identifier 1 is defined as "CAN 41" in interface 2. Therefore, when the wake-up policy controller 12 transfers identifier 1 through interface 2, the wake-up executor 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 the interface 2 may be set based on requirements and past experiences.

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

[0087] The sleep / wake-up operation is used to wake up at least one vehicle-mounted object in the at least one vehicle integration unit or to control at least one vehicle-mounted object in the at least one vehicle integration unit to enter a sleep state. It should be understood that when the first sleep / wake-up signal is a first signal, the correspondingly obtained sleep / wake-up operation is used to wake up at least one vehicle-mounted object in the at least one vehicle integration unit. When the first sleep / wake-up signal is a second signal, the correspondingly obtained sleep / wake-up operation is used to control at least one vehicle-mounted object in the at least one vehicle integration unit to enter a sleep state.

[0088] In a possible implementation form, step S203 may include a step of determining at least one vehicle integrated unit corresponding to any one of the at least one static control target and an on-vehicle object within each determined vehicle integrated unit for which sleep / wake-up control needs to be performed based on a third mapping relationship, where the third mapping relationship represents a mapping relationship between the static control target, the vehicle integrated unit, and the on-vehicle object for which sleep / wake-up control needs to be performed, and a step of determining at least one sleep / wake-up operation based on whether the on-vehicle object for which sleep / wake-up control needs to be performed is currently in an awake state or a sleep state.

[0089] Table 5 shows an example of the third mapping relationship. As shown in Table 5, based on FIG. 9, when the sleep / wake-up system obtains a static control target whose identifier is 1, a sleep / wake-up action whose identifier is 1, the vehicle integration unit is "VIU 4", and the in-vehicle object is ECU 44 and ECU 45 connected to "CAN 41" can be obtained based on the third mapping relationship. The sleep / wake-up action is used to wake up ECU 44 and ECU 45 connected to "CAN 41" and located in the vehicle integration unit "VIU 4".

[0090] [Table 5]

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

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

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

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

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

[0096] Step S401: An external wakeup source sends at least one first sleep / wakeup signal to the wakeup source parser.

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

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

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

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

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

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

[0103] For steps S401 to S407, please refer to steps S201 to S204, and the details will not be described again here.

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

[0105] In a possible implementation, the wakeup source parser and wakeup executor in the sleep / wakeup system are deployed in the vehicle integration unit, and the wakeup policy controller is deployed in the domain controller.

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

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

[0108] Step S501: An external wakeup source sends a first sleep / wakeup signal to a wakeup source parser in the VIU.

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

[0110] In one example, an external wake-up source “Passive Entry & Passive Start (PEPS)” may send a first sleep / wake-up signal “CANNM Packet” to VIU 1.

[0111] Step S502: A wakeup source parser in the VIU converts the first sleep / wakeup signal into a second sleep / wakeup signal.

[0112] The wakeup source parser in each VIU may convert the received first sleep / wake-up signal to a second sleep / wake-up signal. As shown in FIG. 11, the wakeup source parser in VIU 1 may convert the first sleep / wake-up signal 11 to the second sleep / wake-up signal 11 and convert the first sleep / wake-up signal 12 to the second sleep / wake-up signal 12. The wakeup source parser in VIU 2 may convert the first sleep / wake-up signal 21 to the second sleep / wake-up signal 21 and convert the first sleep / wake-up signal 22 to the second sleep / wake-up signal 22. The wakeup source parser in VIU 3 may convert the first sleep / wake-up signal 31 to the second sleep / wake-up signal 31 and convert the first sleep / wake-up signal 32 to the second sleep / wake-up signal 32 (not shown). The wakeup source parser in the VIU 4 can convert the first sleep / wakeup signal 41 to the second sleep / wakeup signal 41 and convert the first sleep / wakeup signal 42 to the second sleep / wakeup signal 42. Note that the above is just one example of the first sleep / wakeup signal and the second sleep / wakeup signal. In actual implementation, more or fewer first sleep / wakeup signals and second sleep / wakeup signals may be included.

[0113] In one example, a first sleep / wake signal "CANNM packet" may be converted into a second sleep / wake signal "with identifier 2 and name Unlock with Bluetooth Key."

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

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

[0116] In one example, the wakeup source parser in VIU 1 sends a second sleep / wakeup signal with identifier 2 and name Unlock with Bluetooth Key to the wakeup policy controller in xDC.

[0117] Step S504: The wake-up policy controller in the xDC determines a 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 in the xDC can determine a static control target based on each received second sleep / wake-up signal, and obtain a final static control target by obtaining a union of the static control targets. As shown in FIG. 11, the wake-up policy controller in the xDC finally obtains static control target 1.

[0119] In one example, the wake-up policy controller in the xDC obtains a static control objective "having an identifier of 2 and a name of wake-up to unlock with Bluetooth key" based on a second sleep / wake-up signal "having an identifier of 2 and a name of wake-up to unlock with Bluetooth key" (as shown in Table 3).

[0120] Step S505: The wakeup decision controller in the xDC sends the static control objective to the wakeup executor in each VIU.

[0121] As shown in FIG. 11, the wakeup decision controller in the xDC sends static wakeup target 1 separately to the wakeup executor in VIU 2, the wakeup executor in VIU 2, the wakeup executor in VIU 3 (not shown), and the wakeup executor in VIU 4.

[0122] In one example, the wake-up policy controller in the xDC sends a static control objective "with identifier 2 and name Wake-up to unlock using Bluetooth key" to the wake-up executors in all VIUs.

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

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

[0125] In one example, the wakeup executor in VIU 1 wakes up ECU 11 and ECU 12 connected to CAN 11, and wakes up ECU 14, ECU 15, and ECU 16 connected to CAN 12. The wakeup executor in VIU 2 wakes up ECU 21 connected to CAN 21. The wakeup executor in VIU 3 does not have a corresponding sleep / wakeup operation. The wakeup executor in VIU 4 does not have a sleep / wakeup operation.

[0126] Step S507: The wake-up execution unit in the VIU wakes up vehicle-mounted objects in the current VIU that need to be woken up, and / or controls vehicle-mounted objects in the current VIU that need to enter a sleep state to enter a sleep state.

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

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

[0129] Considering that a vehicle has a specific wake-up period requirement, 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 will wake up the VIU and xDC. When the user approaches the vehicle further, the vehicle may be automatically unlocked to provide a good user experience to the owner. If the vehicle wake-up time is long (e.g., more than 1 second), the door is not unlocked when the owner needs to open it. This will affect the customer experience. In FIG. 11, the wake-up policy controller is deployed in the xDC, and all sleep / wake-up operations need to go through the process from "VIU" to "xDC" and then back to "VIU". Therefore, the vehicle sleep / wake-up period is extended and the user experience may be affected.

[0130] In a possible implementation, the wakeup source parser, wakeup policy controller, and wakeup executor in the sleep / wakeup system may all be located in the vehicle integration unit.

[0131] Figure 13 is a schematic diagram of the deployment of a wake-up / sleep system according to an embodiment of the present application. As shown in Figure 13, based on the communication and computation architecture shown in Figure 9, a wake-up source parser, a wake-up executor, and a wake-up policy controller are deployed in 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 objective 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. To simplify the design, it is assumed that the wake-up policies (i.e., the second mapping relationship) carried by all the wake-up policy controllers are the same. In this case, only the wake-up source parser on one VIU needs to send the static control objective to the wake-up execution unit on each VIU, and there is no need to send the second sleep / wake-up signal to the wake-up policy controller on another VIU for processing. In addition, it is assumed that the in-vehicle network is properly planned. When the wake-up policy controller on one VIU only supports the external wake-up source 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 objective of waking up the vehicle and the objective of controlling the vehicle to enter a sleep state can still be implemented. In principle, one wake-up policy controller is deployed for each VIU. If it is found during the design process of the in-vehicle network that the external wake-up source is not directly received within a particular VIU, there is no need to deploy a wake-up policy controller for the VIU.

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

[0134] Step S601: An external wakeup source sends a first sleep / wakeup signal to a wakeup source parser in the VIU.

[0135] Step S602: A wakeup source parser in the VIU converts the first sleep / wakeup signal into a second sleep / wakeup signal.

[0136] For step S601 and step S602, please refer to step S501 and step S502, and the details will not be described again here.

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

[0138] In one example, the wakeup source parser in VIU 1 sends a second sleep / wakeup signal with an identifier of 2 and a name of Unlock with Bluetooth Key to the wakeup policy controller in VIU 1.

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

[0140] In one example, the wake-up policy controller in VIU 1 obtains a static control objective "whose identifier is 2 and whose name is Wake-up to unlock with Bluetooth key" based on a second sleep / wake-up signal "whose identifier is 2 and whose name is Unlock with Bluetooth key" (as shown in Table 3).

[0141] Step S605: The wakeup decision controller in the VIU sends the static control objective to the wakeup execution unit in the VIU.

[0142] In a possible implementation, the wake-up decision controller in the VIU may send the static control objective to the wake-up executors in all VIUs. The wake-up executors in each VIU may then execute steps S606 and S607 to control the in-vehicle object. For example, as shown in FIG. 9, the wake-up policy controller in VIU 1 sends a static control objective "identifier is 2 and name is wake-up to unlock using Bluetooth key" to the wake-up executors in VIU 1, VIU 2, VIU 3, and VIU 4 separately.

[0143] In a possible implementation, the wake-up decision controller in the VIU may send the static control target to the wake-up executor in the VIU associated with the static control target. For example, as shown in Table 3, the content of the static control target "identifier is 2 and name is wake-up to unlock using Bluetooth key" includes CAN 11, CAN 12, and CAN 31. As shown in FIG. 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 target "identifier is 2 and name is wake-up to unlock using Bluetooth key" are VIU 1 and VIU 3. Therefore, the wake-up decision controller in VIU 1 may send the static control target to the wake-up executor in VIU 1 and VIU 3 separately.

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

[0145] Step S607: The wake-up execution unit in the VIU wakes up vehicle-mounted objects in the current VIU that need to be woken up, and / or controls vehicle-mounted objects in the current VIU that need to enter a sleep state to enter a sleep state.

[0146] For step S606 and step S607, please refer to step S506 and step S507, and the details will not be described again here.

[0147] In this embodiment of the present application, the wake-up policy controller deployed in the xDC is moved to each VIU so that the sleep / wake-up speed is accelerated when the VIU's local in-vehicle objects need to go into sleep state or be woken up.

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

[0149] In a possible implementation, the wake-up policy controller is split into a distributed wake-up policy controller and a centralized wake-up policy controller, and the wake-up source parser, wake-up executor, and distributed wake-up policy controller in the sleep / wake-up system are deployed in the vehicle integration unit, and the centralized wake-up policy controller is deployed in the domain controller.

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

[0151] Based on the principle of "fast wakeup and slow sleep", in order to ensure that the local wakeup source can quickly wake up the vehicle-mounted object and to avoid the conflict between the wakeup behavior and the sleep behavior of different vehicle-mounted objects caused by different wakeup sources, this embodiment of the present application needs to divide the work between the distributed wakeup policy controller and the centralized wakeup policy controller for the wakeup operation. The distributed wakeup policy controller can only determine the wakeup of the vehicle-mounted object in the local VIU. The centralized wakeup policy controller can only determine the wakeup of the vehicle-mounted object across the VIU.

[0152] To ensure that the centralized policy controller determines the wakeup source from different VIUs, the wakeup source interface 1 needs to be modified and a definition of the source VIU needs to be added. The modified interface 1 (which may be called interface 3) is shown in Table 6.

[0153] [Table 6]

[0154] In sleep, in this embodiment of the present application, the policy related to entering the sleep state needs to be moved to the 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. This method can be applied to the system shown in Figure 15. As shown in Figures 16A to 16C, this method includes the following steps:

[0155] Step S701: An external wakeup source sends a first sleep / wakeup signal to a wakeup source parser in a first VIU.

[0156] The first VIU represents a VIU in a communications and computing architecture.

[0157] Step S702: A wakeup source parser in the first VIU converts the first sleep / wakeup signal into a second sleep / wakeup signal.

[0158] For step S701 and step S702, please refer to step S501 and step S502, and the details will not be described again 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 wakeup source parser in VIU 1 sends a second sleep / wakeup signal with identifier 2 and name Unlock with Bluetooth Key to the distributed wakeup policy controller in VIU 1.

[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 wakeup source parser in VIU 1 sends a second sleep / wakeup signal with identifier 2 and name Unlock with Bluetooth Key to the centralized wakeup policy controller in xDC.

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

[0164] In one example, the distributed wake-up policy controller in VIU 1 determines a static control target whose identifier is 2 and whose name is wake-up to unlock with Bluetooth key based on a second sleep / wake-up signal from VIU 1 whose identifier is 2 and whose name is unlock with Bluetooth key.

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

[0166] In one example, the centralized wake-up policy controller in the xDC determines a static control target whose "identifier is 2 and whose name is wake-up to unlock with Bluetooth key" based on a second sleep / wake-up signal whose "identifier is 2 and whose name is unlock with Bluetooth key" from VIU 1.

[0167] Step S7051: The distributed wakeup policy controller in the first VIU sends the determined static wakeup goal to the wakeup executor in the first VIU.

[0168] In one example, the wake-up policy controller in VIU 1 sends a static control objective with an identifier of 2 and a name of wake-up to unlock using Bluetooth key to all wake-up executors in VIU 1.

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

[0170] The second VIU represents a VIU other than the first VIU in the communications and computing architecture.

[0171] In one example, the wake-up policy controller in the xDC sends a static control objective "with identifier 2 and name Wake-up to unlock using Bluetooth key" to a wake-up executor in a VIU other than VIU 1.

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

[0173] In one example, the wakeup executor in VIU 1 wakes up ECU 11 and ECU 12 connected to CAN 11, and wakes up ECU 14, ECU 15, and ECU 16 connected to CAN 12.

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

[0175] In one example, the wakeup executor in VIU 2 wakes up the ECU 21 connected to the CAN 21. The wakeup executor in VIU 3 does not have a corresponding sleep / wakeup operation. The wakeup executor in VIU 4 does not have a sleep / wakeup operation.

[0176] Step S7071: A wake-up execution unit in the first VIU wakes up an in-vehicle object in the first VIU that needs to be woken up, and / or controls an in-vehicle object in the first VIU that needs to go into a sleep state to go into a sleep state.

[0177] Step S7072: The wake-up execution unit in the second VIU wakes up an in-vehicle object in the second VIU that needs to be woken up, and / or controls an in-vehicle object in the second VIU that needs to go into a sleep state to go into a sleep state.

[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 wake-up source of the VIU needs to wake up the local in-vehicle object, and the centralized wake-up policy controller is still maintained in the xDC, so that the sleep / wake-up contention problem is solved and the reliability is improved.

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

[0180] 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 FIG. 17, the device 1700 includes: a conversion module 1701 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 representing a sleep / wake-up signal generated in an in-vehicle network of a first vehicle model, and the second sleep / wake-up signal representing a unified sleep / wake-up signal into which a sleep / wake-up signal having the same function generated in an in-vehicle network of a different vehicle model is converted; a first determination module 1702 configured to determine at least one static control objective based on the at least one second sleep / wake-up signal, the static control objective indicating a function of the first sleep / wake-up signal; a second determination module 1703 configured to determine at least one sleep / wake-up action based on the at least one static control objective, the sleep / wake-up action being used to wake up at least one vehicle-mounted object in the at least one vehicle integration unit or to control at least one vehicle-mounted object in the at least one vehicle integration unit to enter a sleep state; an execution module 1704 configured to execute at least one sleep / wake-up operation; may include.

[0181] In a possible implementation, the conversion module includes: Determine a second sleep / wake-up signal corresponding to any one of the at least one first sleep / wake-up signal based on a first mapping relationship, the first mapping relationship representing 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; The method is further configured as follows.

[0182] In a possible implementation, the first determination module comprises: Determine a static control objective corresponding to any one of the at least one second sleep / wake-up signal based on a second mapping relationship, the second mapping relationship representing a mapping relationship between the unified sleep / wake-up signal and the vehicle-mounted object; merging the static control targets corresponding to each second sleep / wake-up signal to obtain at least one static control target; The method is further configured as follows.

[0183] In a possible implementation, the second determination module comprises: Determine at least one vehicle integrated unit corresponding to any one of the at least one static control target and an on-vehicle object for which the sleep / wake-up control needs to be performed and located within each determined vehicle integrated unit based on a third mapping relationship, the third mapping relationship representing a mapping relationship between the static control target, the vehicle integrated unit, and the on-vehicle object for which the sleep / wake-up control needs to be performed; determining at least one sleep / wake-up operation based on whether an in-vehicle object for which sleep / wake-up control needs to be performed is currently in an awake state or a sleep state; The method is further configured as follows.

[0184] In a possible implementation, 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 an embodiment of the present application. As shown in Figure 18, based on Figure 17, the device 1700: a third determining module 1705 configured to determine that the first signal is acquired when a network management packet or a service packet is received or when a first level change is detected; or a fourth determining module 1706 configured to determine that a second signal is acquired when no network management packet or no service packet is received within a predetermined time or when a second level change is detected; It may further include.

[0185] An embodiment of the present application provides a sleep / wake-up device, comprising a processor and a memory configured to store instructions executable by the processor, the processor being configured to implement the aforementioned method when executing the instructions.

[0186] An embodiment of the present application provides a non-volatile computer readable storage medium, which stores computer program instructions, which, when executed by a processor, implement the aforementioned method.

[0187] One embodiment of the present application provides a computer program product including computer readable code, or a non-volatile computer readable storage medium carrying the computer readable code, which when executed by a processor of an electronic device causes the processor in the electronic device to perform the aforementioned method.

[0188] A computer-readable storage medium may be a tangible device that can hold and store instructions for use by an instruction execution device. A computer-readable storage medium may be, for example, but not limited to, 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. More specific examples (non-exhaustive list) of computer-readable storage media include portable computer disks, hard disk drives, Random Access Memory (RAM), Read Only Memory (ROM), Electrically Programmable Read-Only Memory (EPROM, or Flash memory), Static Random-Access Memory (SRAM), portable Compact Disc Read-Only Memory (CD-ROM), Digital Video Disc (DVD), memory sticks, floppy disks, mechanical coding devices such as punched cards or slotted structures that store instructions, and any suitable combination thereof.

[0189] The computer-readable program instructions or codes described herein can be downloaded to each computing / processing device from a computer-readable storage medium or via an external computer or external storage device over a network, such as the Internet, a local area network, a wide area network, and / or a wireless network. The network may include copper transmission cables, optical fiber transmissions, wireless transmissions, routers, firewalls, switches, gateway computers, and / or edge servers. A network adapter card or network interface in each computing / processing device receives the computer-readable program instructions from the network and forwards the computer-readable program instructions for storage in a computer-readable storage medium in 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 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. The computer readable program instructions may be executed entirely on the user computer, partially on the user computer, as a standalone software package, partially on the user computer, partially on a remote computer, or entirely on a remote computer or server. When a remote computer is included, the remote computer may be connected to the user computer via any type of network, including a Local Area Network (LAN) or a Wide Area Network (WAN), or may be connected to an external computer (e.g., 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 aspects of the present application.

[0191] Various aspects of the present application are described herein with reference to flowcharts and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the present application. It will be understood that each block of the flowcharts and / or block diagrams, and combinations of blocks in the flowcharts and / or block diagrams, may be implemented by computer readable program instructions.

[0192] These computer-readable program instructions may be provided to a processor of a general-purpose computer, a special-purpose computer, or another programmable data processing device to manufacture a machine, such that the instructions, when executed by the processor of the computer or another programmable data processing device, create an apparatus for performing the functions / operations specified in one or more blocks of the flowcharts and / or block diagrams. 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 manner. Thus, a computer-readable medium storing instructions includes an artifact including instructions for implementing various aspects of the functions / operations specified in one or more blocks of the flowcharts and / or block diagrams.

[0193] Alternatively, the computer readable program instructions may be loaded into a computer, another programmable data processing apparatus, or another device, such that a sequence of operations and steps are performed by the computer, another programmable data processing apparatus, or another device to produce a computer-implemented process. Thus, the instructions executing on the computer, another programmable data processing apparatus, or another device implement the functions / operations specified in one or more blocks of the flowcharts and / or block diagrams.

[0194] The flowcharts and block diagrams in the accompanying drawings illustrate possible implementations of the system architecture, the functions and operation of the apparatus, the system, the method, and the computer program product according to the embodiments of the present application. In this regard, each block in the flowchart or block diagram may represent a module, a program segment, or a portion of an instruction, which includes one or more executable instructions for implementing the specified logical function. In some alternative implementations, the functions marked in the blocks may also be performed in a different order than that marked in the accompanying drawings. For example, two consecutive blocks may in fact be executed substantially in parallel or may be executed in a reverse order depending on the functions involved.

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

[0196] Although the present invention has been described with reference to the embodiments, in the process of implementing the claimed invention, those skilled in the art may understand and implement other variations of the disclosed embodiments by referring to the attached drawings, the disclosed content, and the appended claims. In the claims, "comprising" does not exclude other components or steps, and "a" or "a" does not exclude a plurality of cases. A single processor or other unit may implement several functions recited in the claims. Although some means are recited in mutually different dependent claims, this does not mean that these means cannot be combined to produce a better effect.

[0197] The above has described the embodiments of the present application. The foregoing description is exemplary, not exhaustive, and is not limited to the disclosed embodiments. Many modifications and changes will be apparent to those skilled in the art without departing from the scope of the described embodiments. The choice of terms used herein is intended to best explain the principles, practical applications, or improvements of market technology of the embodiments, 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. Vehicle-mounted objects, identifiers, and interfaces 3. Interface 11 Wakeup source parser, first sleep / wakeup signal, second sleep / wakeup signal, sleep / wakeup action 12 Wake-up source policy controller, wake-up decision controller, first sleep / wake-up signal, second sleep / wake-up signal, sleep / wake-up action 13 Wake-up Execution Department 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 Judgment Module 1703 Second Judgment Module 1704 Execution Module 1705 Third Judgment Module 1706 Fourth Judgment Module

Claims

1. 1. A sleep / wake-up method, comprising: converting at least one first sleep / wake-up signal into at least one second sleep / wake-up signal, the first sleep / wake-up signal representing a sleep / wake-up signal generated in an in-vehicle network of a first vehicle model, and the second sleep / wake-up signal representing a unified sleep / wake-up signal into which a sleep / wake-up signal having the same functionality generated in an in-vehicle network of a different vehicle model is converted; determining at least one static control objective based on the at least one second sleep / wake-up signal, the static control objective indicative of a function of the first sleep / wake-up signal; determining at least one sleep / wake-up action based on the at least one static control objective, the sleep / wake-up action being used to wake up at least one vehicle object in the at least one vehicle integration unit or to control at least one vehicle object in the at least one vehicle integration unit to enter a sleep state; performing said at least one sleep / wake-up operation; The method includes:

2. The step of converting at least one first sleep / wake-up signal into at least one second sleep / wake-up signal comprises: determining a second sleep / wake-up signal corresponding to any one of the at least one first sleep / wake-up signal based on a first mapping relationship, the first mapping relationship representing 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; 2. The method of claim 1, comprising:

3. The step of determining at least one static control objective based on the at least one second sleep / wake-up signal further comprises: determining a static control target corresponding to any one of the at least one second sleep / wake-up signal based on a second mapping relationship, the second mapping relationship representing a mapping relationship between the unified sleep / wake-up signal and an in-vehicle object; merging static control targets corresponding to each second sleep / wake-up signal to obtain the at least one static control target; 3. The method of claim 1 or 2, comprising:

4. The step of determining at least one sleep / wake-up action based on the at least one static control objective comprises: determining at least one vehicle integrated unit corresponding to any one of the at least one static control target and an on-vehicle object for which sleep / wake-up control needs to be performed and located within each determined vehicle integrated unit based on a third mapping relationship, wherein the third mapping relationship represents a mapping relationship between the static control target, the vehicle integrated unit, and the on-vehicle object for which sleep / wake-up control needs to be performed; determining the at least one sleep / wake-up operation based on whether the vehicle object for which a sleep / wake-up control needs to be performed is currently in an awake state or a sleep state; The method according to any one of claims 1 to 3, comprising:

5. The first sleep / wake-up signal includes a first signal used to wake up an on-vehicle object and / or a second signal used to control an on-vehicle object to enter a sleep state, and the method further comprises: determining that the first signal is acquired when a network management packet or a service packet is received or when a first level change is detected; or determining that the second signal has been acquired when no network management packet or service packet is received within a predetermined time or when a second level change is detected; 5. The method of 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 executor; 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 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, the first sleep / wake-up signal representing a sleep / wake-up signal generated in an in-vehicle network of a first vehicle model, and the second sleep / wake-up signal representing a unified sleep / wake-up signal into which a sleep / wake-up signal having the same function generated in an in-vehicle network of a different vehicle model is converted; The wake-up policy controller is configured to determine at least one static control objective based on the at least one second sleep / wake-up signal, and to send the at least one static control objective to the wake-up executor, the static control objective indicating a function of the first sleep / wake-up signal; the wake-up execution unit is configured to determine at least one sleep / wake-up action based on the at least one static control target, execute the at least one sleep / wake-up action, and the sleep / wake-up action is used to wake up at least one vehicle object in the at least one vehicle integration unit or to control at least one vehicle object in the at least one vehicle integration unit to enter a sleep state. system.

7. The system of claim 6 , wherein the wakeup source parser and the wakeup executor are deployed in a vehicle integration unit and the wakeup policy controller is deployed in a domain controller.

8. The system of claim 6 , wherein the wakeup source parser, the wakeup policy controller, and the wakeup executor are deployed in a vehicle integration unit.

9. 7. The system of 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 executor, and the distributed wake-up policy controller being deployed in a vehicle integration unit, and the centralized wake-up policy controller being deployed in a domain controller.

10. The wakeup source parser comprises: determining a second sleep / wake-up signal corresponding to any one of the at least one first sleep / wake-up signal based on a first mapping relationship, the first mapping relationship representing 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; 10. The system of claim 6, further configured to:

11. The wake-up policy controller, Determine a static control objective corresponding to any one of the at least one second sleep / wake-up signal based on a second mapping relationship, the second mapping relationship representing a mapping relationship between the unified sleep / wake-up signal and an in-vehicle object; merging the static control targets corresponding to each second sleep / wake-up signal to obtain the at least one static control target; The system of any one of claims 6 to 10, further configured to:

12. The wake-up execution unit is Determine at least one vehicle integrated unit corresponding to any one of the at least one static control target and an on-vehicle object for which sleep / wake-up control needs to be executed and located within each determined vehicle integrated unit based on a third mapping relationship, the third mapping relationship representing a mapping relationship between the static control target, the vehicle integrated unit, and the on-vehicle object for which sleep / wake-up control needs to be executed; determining the at least one sleep / wake-up operation based on whether the vehicle object for which the sleep / wake-up control needs to be performed is currently in an awake state or a sleep state; 12. The system of claim 6, further configured to:

13. The first sleep / wake-up signal comprises a first signal used to wake up an on-vehicle object and / or a second signal used to control an on-vehicle object to enter a sleep state, the sleep / wake-up system further comprising a wake-up source; 13. The system of claim 6, wherein the wake-up source is configured to determine that the first signal has been acquired when a network management packet or a service packet is received or when a first level change is detected, or to determine that the second signal has been acquired when no network management packet or service packet is received within a predetermined time or when a second level change is detected.

14. 1. A sleep / wake-up device, comprising: a conversion module 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 representing a sleep / wake-up signal generated in an in-vehicle network of a first vehicle model, and the second sleep / wake-up signal representing a unified sleep / wake-up signal into which a sleep / wake-up signal having the same functionality generated in an in-vehicle network of a different vehicle model is converted; a first determination module configured to determine at least one static control objective based on the at least one second sleep / wake-up signal, the static control objective indicating a function of the first sleep / wake-up signal; a second determination module configured to determine at least one sleep / wake-up action based on the at least one static control objective, the sleep / wake-up action being used to wake up at least one vehicle object in the at least one vehicle integration unit or to control at least one vehicle object in the at least one vehicle integration unit to enter a sleep state; an execution module configured to execute the at least one sleep / wake-up operation; An apparatus comprising:

15. The conversion module includes: determining a second sleep / wake-up signal corresponding to any one of the at least one first sleep / wake-up signal based on a first mapping relationship, the first mapping relationship representing 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; The apparatus of claim 14, further configured to:

16. The first determination module includes: Determine a static control objective corresponding to any one of the at least one second sleep / wake-up signal based on a second mapping relationship, the second mapping relationship representing a mapping relationship between the unified sleep / wake-up signal and an in-vehicle object; merging the static control targets corresponding to each second sleep / wake-up signal to obtain the at least one static control target; 16. The apparatus of claim 14 or 15, further configured to:

17. The second determination module includes: Determine at least one vehicle integrated unit corresponding to any one of the at least one static control target and an on-vehicle object for which sleep / wake-up control needs to be executed and located within each determined vehicle integrated unit based on a third mapping relationship, the third mapping relationship representing a mapping relationship between the static control target, the vehicle integrated unit, and the on-vehicle object for which sleep / wake-up control needs to be executed; determining the at least one sleep / wake-up operation based on whether the vehicle object for which the sleep / wake-up control needs to be performed is currently in an awake state or a sleep state; 17. The apparatus of claim 14, further configured to:

18. The first sleep / wake-up signal comprises a first signal used to wake up an on-board object and / or a second signal used to control an on-board object to enter a sleep state, and the device further comprises: a third determination module configured to determine that the first signal is acquired when a network management packet or a service packet is received or when a first level change is detected; or a fourth determining module configured to determine that the second signal is acquired when no network management packet or no service packet is received within a predetermined time or when a second level change is detected; 18. The apparatus of claim 14, further comprising:

19. A processor; a memory configured to store instructions executable by the processor; A sleep / wake-up device comprising: A sleep / wake-up device, wherein the processor is configured to implement the method of any one of claims 1 to 5 when executing the instructions.

20. A non-volatile computer readable storage medium storing computer program instructions which, when executed by a processor, implement the method of any one of claims 1 to 5.

21. 6. A computer program product comprising computer readable code or a non-volatile computer readable storage medium carrying computer readable code, the computer program product comprising, when executed on an electronic device, a processor of the electronic device which performs the method of any one of claims 1 to 5.

Images