Dormancy awakening method, system and device

Abstract

The invention relates to a sleep wake-up method, system and device. The method comprises the following steps: converting a first sleep wake-up signal generated in a vehicle-mounted network of a first vehicle model into a unified second sleep wake-up signal which is generated in vehicle-mounted networks of different vehicle models and is converted into sleep wake-up signals with the same function; determining a static control target for representing the function of the first sleep wake-up signal based on a second sleep wake-up signal; based on the static control target, determining a dormancy awakening action for awakening at least one vehicle-mounted object in the at least one vehicle integrated unit or controlling the at least one vehicle-mounted object in the at least one vehicle integrated unit to perform dormancy; at least one sleep wake-up action is performed. According to the sleep wake-up method, system and device provided by the embodiment of the invention, sleep wake-up control based on a communication computing architecture can be realized.

Description

[0001] This application is a divisional application. The original application has the application number 202210125226.9 and the original application date is February 10, 2022. The entire contents of the original application are incorporated herein by reference. Technical Field

[0002] This application relates to the field of intelligent vehicles, and in particular to a sleep / wake-up method, system, and device. Background Technology

[0003] With the rapid development of intelligent connected vehicles, the significant increase in vehicle information and the demand for vehicle intelligence have jointly driven the upgrade and evolution of automotive electronic and electrical architecture. From the perspective of electronic control unit (ECU), automotive electronic and electronic (E / E) architecture has undergone three generations of evolution.

[0004] The first generation is a distributed electrical and electronic architecture, where one function corresponds to one ECU. The second generation is a centralized electrical and electronic architecture, where the original single-function ECUs are integrated into a single controller according to their function category, such as integrating ECUs into the powertrain domain, chassis domain, body domain, driver domain, and cockpit domain. The third generation is a centrally centralized electrical and electronic architecture, which further centralizes the functional domains to form one or more central computing units, and further centralizes the functional domains from the second generation to form area controllers. The centrally centralized electrical and electronic architecture can also be called a Communication & Computation Architecture (CCA).

[0005] In related technologies, the sleep-wake scheme used in distributed electronic and electrical architectures works as follows: when the vehicle is in sleep mode, the vehicle network needs to be woken up when a certain function is activated; the vehicle network can only enter sleep mode after all network nodes meet the sleep conditions. This sleep-wake scheme affects the vehicle's daily power consumption and reduces the vehicle's static storage period. Furthermore, in this sleep-wake scheme, the network nodes influence each other, and if an anomaly such as a software vulnerability or hardware failure causes a network node to fail to enter sleep mode normally, it is difficult to pinpoint the cause.

[0006] In related technologies, the sleep / wake-up scheme adopted in centralized electronic and electrical architecture is as follows: the sleep / wake-up requirements of each ECU in different network segments in the central gateway (CGW) are used as the judgment condition, and different network segments are put into sleep or woken up independently. Figure 1 An exemplary network topology diagram of a centralized electrical and electronic architecture is shown. For example... Figure 1As shown, the centralized electronic and electrical architecture's CGW connects to three Controller Area Networks (CANs): CAN1, CAN2, and CAN3. CAN1 has three ECUs connected to it: ECU1, ECU2, and ECU3; CAN2 has three ECUs connected to it: ECU4, ECU5, and ECU6; and CAN3 has three ECUs connected to it: ECU7, ECU8, and ECU9. When the vehicle is in sleep mode, if the CGW detects that ECU1 on CAN1 has been woken up, it determines whether there is an associated ECU on CAN2 that interacts functionally with ECU1. If an associated ECU exists, the CGW wakes up CAN2 and its associated ECUs. When the CGW determines that all ECUs in CAN1 have issued sleep requests, and all associated ECUs that interact functionally with all ECUs in CAN1 have also issued sleep requests, it controls CAN1 to go into sleep mode. This sleep / wake-up scheme does not consider multiple CGW sleep / wake-up scenarios, nor the mutual influence between CGWs during the sleep / wake-up process. Furthermore, this sleep / wake-up scheme does not consider Ethernet, Local Interconnect Network (LIN), or hardwired sleep / wake-up methods.

[0007] Because the ECU interacts with multiple networks through multiple Vehicle Integrated Units (VIUs) in the communication computing architecture, the above-mentioned sleep / wake-up solutions are not suitable for this architecture. Considering that many in-vehicle electronic and electrical architectures have transitioned from distributed and centralized architectures to communication computing architectures, how to implement sleep / wake-up control within these architectures has become a pressing issue. Summary of the Invention

[0008] In view of this, a hibernation wake-up method, system and device are proposed, which can realize hibernation wake-up control based on communication computing architecture.

[0009] In a first aspect, embodiments of this application provide a sleep-wake method, the method comprising: At least one first sleep wake-up signal is converted into at least one second sleep wake-up signal, wherein the first sleep wake-up signal is used to characterize the sleep wake-up signal generated in the vehicle network of the first vehicle model, and the second sleep wake-up signal is used to characterize the unified sleep wake-up signal converted from the sleep wake-up signals with the same function generated in the vehicle networks of different vehicle models. Based on the at least one second sleep-wake signal, at least one static control target is determined, wherein the static control target is used to represent the function of the first sleep-wake signal; Based on the at least one static control objective, at least one sleep / wake-up action is determined. The sleep / wake-up action is used to wake up at least one in-vehicle object in at least one vehicle integration unit or to control at least one in-vehicle object in at least one vehicle integration unit to go into sleep mode. Perform at least one sleep / wake action.

[0010] In one possible implementation, converting at least one first sleep wake-up signal into at least one second sleep wake-up signal includes: For any one of the at least one first sleep wake-up signals, a second sleep wake-up signal corresponding to the first sleep wake-up signal is determined based on a first mapping relationship. The first mapping relationship is used to characterize the mapping relationship between the sleep wake-up signal generated in the vehicle network of the first vehicle model and the unified sleep wake-up signal.

[0011] In one possible implementation, determining at least one static control target based on the at least one second sleep / wake-up signal includes: For any one of the at least one second sleep wake-up signals, a static control target corresponding to the second sleep wake-up signal is determined based on a second mapping relationship. The second mapping relationship is used to characterize the mapping relationship between the unified sleep wake-up signal and the vehicle object. The static control targets corresponding to each second sleep wake-up signal are merged to obtain at least one static control target.

[0012] In one possible implementation, determining at least one sleep / wake-up action based on the at least one static control target includes: For any one of the at least one static control targets, based on a third mapping relationship, at least one vehicle integration unit corresponding to the static control target is determined, as well as the vehicle-mounted object in each determined vehicle integration unit that needs to be controlled for sleep and wake-up. The third mapping relationship is used to characterize the mapping relationship between the static control target, the vehicle integration unit, and the vehicle-mounted object that needs to be controlled for sleep and wake-up. Determine whether the vehicle-mounted object requiring sleep / wake control is currently in a wake-up state or a sleep state, and determine the at least one sleep / wake action.

[0013] In one possible implementation, the first sleep / wake signal includes a first signal for waking up the vehicle-mounted object, and / or a second signal for controlling the vehicle-mounted object to enter sleep mode, and the method further includes: Upon receiving a network management message, a service message, or detecting a change in the first level, it is determined that the first signal has been obtained; If no network management message or service message is received within a preset time, or if a change in the second level is detected, it is determined that the second signal has been obtained.

[0014] Secondly, embodiments of this application provide a sleep-wake system, the sleep-wake system comprising: a wake-up source resolver, a wake-up policy controller, and a wake-up executor; The wake-up source parser is used to convert at least one first sleep wake-up signal into at least one second sleep wake-up signal, and send the at least one second sleep wake-up signal to the wake-up policy controller. The first sleep wake-up signal is used to characterize the sleep wake-up signal generated in the vehicle network of the first vehicle model, and the second sleep wake-up signal is used to characterize the unified sleep wake-up signal converted from the sleep wake-up signals with the same function generated in the vehicle networks of different vehicle models. The wake-up policy controller is configured to determine at least one static control target based on the at least one second sleep wake-up signal, and send the at least one static control target to the wake-up actuator, wherein the static control target represents the function of the first sleep wake-up signal; The wake-up actuator is used to determine at least one sleep wake-up action based on the at least one static control target, and to execute the at least one sleep wake-up action. The sleep wake-up action is used to wake up at least one in-vehicle object in at least one vehicle integration unit or to control at least one in-vehicle object in at least one vehicle integration unit to go into sleep mode.

[0015] In one possible implementation, the wake-up source resolver and the wake-up executor are deployed in the vehicle integration unit, and the wake-up policy controller is deployed in the domain controller.

[0016] In one possible implementation, the wake-up source resolver, the wake-up policy controller, and the wake-up executor are deployed in the vehicle integration unit.

[0017] In one possible implementation, the wake-up policy controller includes a distributed wake-up policy controller and a centralized wake-up policy controller. The wake-up source resolver, the wake-up executor, and the distributed wake-up policy controller are deployed in the vehicle integration unit, while the centralized wake-up policy controller is deployed in the domain controller.

[0018] In one possible implementation, the wake-up source resolver is further used for: For any one of the at least one first sleep wake-up signals, a second sleep wake-up signal corresponding to the first sleep wake-up signal is determined based on a first mapping relationship. The first mapping relationship is used to characterize the mapping relationship between the sleep wake-up signal generated in the vehicle network of the first vehicle model and the unified sleep wake-up signal.

[0019] In one possible implementation, the wake-up policy controller is further configured to: For any one of the at least one second sleep wake-up signals, a static control target corresponding to the second sleep wake-up signal is determined based on a second mapping relationship. The second mapping relationship is used to characterize the mapping relationship between the unified sleep wake-up signal and the vehicle object. The static control targets corresponding to each second sleep wake-up signal are merged to obtain at least one static control target.

[0020] In one possible implementation, the wake-up executor is further used for: For any one of the at least one static control targets, based on a third mapping relationship, at least one vehicle integration unit corresponding to the static control target is determined, as well as the vehicle-mounted object in each determined vehicle integration unit that needs to be controlled for sleep and wake-up. The third mapping relationship is used to characterize the mapping relationship between the static control target, the vehicle integration unit, and the vehicle-mounted object that needs to be controlled for sleep and wake-up. Determine whether the vehicle-mounted object requiring sleep / wake control is currently in a wake-up state or a sleep state, and determine the at least one sleep / wake action.

[0021] In one possible implementation, the first sleep-wake signal includes a first signal for waking up the vehicle-mounted object, and / or a second signal for controlling the vehicle-mounted object to go into sleep mode, and the sleep-wake system further includes a wake-up source; The wake-up source is used to determine that it has obtained the first signal when it receives a network management message, or a service message, or detects a first level change; and to determine that it has obtained the second signal when it does not receive a network management message, or a service message, or detects a second level change within a preset time.

[0022] Thirdly, embodiments of this application provide a sleep / wake-up device, the device comprising: A conversion module is used 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 is used to characterize the sleep wake-up signal generated in the vehicle network of the first vehicle model, and the second sleep wake-up signal is used to characterize a unified sleep wake-up signal converted from sleep wake-up signals with the same function generated in the vehicle networks of different vehicle models. A first determining module is configured to determine at least one static control target based on the at least one second sleep / wake-up signal, wherein the static control target represents the function of the first sleep / wake-up signal; The second determining module is used to determine at least one sleep-wake action based on the at least one static control target. The sleep-wake action is used to wake up at least one vehicle object in at least one vehicle integration unit or to control at least one vehicle object in at least one vehicle integration unit to go into sleep mode. An execution module is used to execute the at least one sleep / wake-up action.

[0023] In one possible implementation, the conversion module is further configured to: For any one of the at least one first sleep wake-up signals, a second sleep wake-up signal corresponding to the first sleep wake-up signal is determined based on a first mapping relationship. The first mapping relationship is used to characterize the mapping relationship between the sleep wake-up signal generated in the vehicle network of the first vehicle model and the unified sleep wake-up signal.

[0024] In one possible implementation, the first determining module is further configured to: For any one of the at least one second sleep wake-up signals, a static control target corresponding to the second sleep wake-up signal is determined based on a second mapping relationship. The second mapping relationship is used to characterize the mapping relationship between the unified sleep wake-up signal and the vehicle object. The static control targets corresponding to each second sleep wake-up signal are merged to obtain at least one static control target.

[0025] In one possible implementation, the second determining module is further configured to: For any one of the at least one static control targets, based on a third mapping relationship, at least one vehicle integration unit corresponding to the static control target is determined, as well as the vehicle-mounted object in each determined vehicle integration unit that needs to be controlled for sleep and wake-up. The third mapping relationship is used to characterize the mapping relationship between the static control target, the vehicle integration unit, and the vehicle-mounted object that needs to be controlled for sleep and wake-up. Determine whether the vehicle-mounted object requiring sleep / wake control is currently in a wake-up state or a sleep state, and determine the at least one sleep / wake action.

[0026] In one possible implementation, the first sleep / wake signal includes a first signal for waking up the vehicle-mounted object, and / or a second signal for controlling the vehicle-mounted object to enter sleep mode, and the device further includes: The third determining module is used to determine that the first signal has been obtained when a network management message is received, a service message is received, or a change in the first level is detected. The fourth determining module is used to determine that the second signal has been obtained if no network management message or service message is received within a preset time, or if a change in the second level is detected.

[0027] Fourthly, embodiments of this application provide a sleep-wake device that can execute one or more of the sleep-wake methods described in the first aspect or in various possible implementations of the first aspect.

[0028] Fifthly, embodiments of this application provide a computer program product including computer-readable code, or a non-volatile computer-readable storage medium carrying computer-readable code, wherein when the computer-readable code is executed in an electronic device, the processor in the electronic device executes one or more of the sleep-wake methods described in the first aspect or various possible implementations of the first aspect.

[0029] In this embodiment, the sleep / wake-up signals generated by the vehicle networks of different vehicle models can be converted into a unified sleep / wake-up signal, and a unified static control target can be obtained. This allows the vehicle objects in the vehicle integration unit to be woken up or put into sleep mode, and the sleep / wake-up control in the communication computing architecture is realized through software.

[0030] These and other aspects of this application will become more apparent in the description of the following embodiments(s). Attached Figure Description

[0031] The accompanying drawings, which are included in and form part of this specification, illustrate exemplary embodiments, features, and aspects of this application together with the specification and serve to explain the principles of this application.

[0032] Figure 1 An exemplary network topology diagram of a centralized electronic and electrical architecture is shown; Figures 2 to 4 The diagrams show exemplary network topologies of ring networks in a communication computing architecture. Figure 5 and Figure 6 Exemplary network topologies for star-shaped communication computing architectures are shown below; Figure 7This diagram illustrates the architecture of the sleep / wake-up system provided in an embodiment of this application. Figure 8 This document illustrates a flowchart of the sleep / wake-up method provided in an embodiment of this application. Figure 9 An exemplary schematic diagram of the network topology of the communication computing architecture is shown; Figure 10 The interactive flowchart of the sleep-wake method provided in the embodiments of this application is shown; Figure 11 A deployment diagram of the wake-up and hibernation system provided in an embodiment of this application is shown; Figure 12 The interactive flowchart of the sleep-wake method provided in the embodiments of this application is shown; Figure 13 A deployment diagram of the wake-up and hibernation system provided in an embodiment of this application is shown; Figure 14 The interactive flowchart of the sleep-wake method provided in the embodiments of this application is shown; Figure 15 A schematic diagram of the deployment of the wake-up and hibernation system provided in an embodiment of this application is shown; Figure 16 The interactive flowchart of the sleep-wake method provided in the embodiments of this application is shown; Figure 17 This diagram illustrates the structure of the sleep / wake-up device provided in an embodiment of this application. Figure 18 This diagram illustrates the structure of the sleep / wake-up device provided in an embodiment of this application. Detailed Implementation

[0033] Various exemplary embodiments, features, and aspects of this application will now be described in detail with reference to the accompanying drawings. The same reference numerals in the drawings denote elements that have the same or similar functions. Although various aspects of the embodiments are shown in the drawings, they are not necessarily drawn to scale unless specifically indicated otherwise.

[0034] The term “exemplary” as used herein means “serving as an example, embodiment, or illustration.” Any embodiment illustrated herein as “exemplary” is not necessarily to be construed as superior to or better than other embodiments.

[0035] Furthermore, to better illustrate this application, numerous specific details are provided in the following detailed embodiments. Those skilled in the art should understand that this application can be implemented without certain specific details. In some instances, methods, means, components, and circuits well-known to those skilled in the art have not been described in detail in order to highlight the main points of this application.

[0036] In the communication computing architecture, the vehicle's ECUs are distributed across multiple regions, with a VIU deployed in each region to manage the ECUs within that region. The VIUs are interconnected via high-speed Ethernet to achieve high-speed communication across the entire vehicle. In this embodiment, the VIU may have one or more of the following functions: electronic control functions, meaning the VIU implements some or all of the electronic control functions provided by the ECUs within the aforementioned vehicle components; functions similar to a gateway, meaning the VIU may also have some or all of the same functions as a gateway, such as protocol conversion, protocol encapsulation and forwarding, and data format conversion; and data processing functions across vehicle components, meaning it processes and calculates data obtained from actuators of multiple vehicle components. It should be noted that the above are merely exemplary examples of VIU functions and are not intended to limit the VIU; a VIU may have more or fewer functions than those listed above.

[0037] In a communication computing architecture, each functional domain of a vehicle has an independent domain controller (DC). For example, the DC in a vehicle may include an autonomous driving domain controller (ADAS / AD Domain Controller, ADC), a cockpit domain controller (CDC), and a vehicle domain controller (VDC).

[0038] The ADC (Analog-to-Digital Converter) can provide services to vehicle components that enable autonomous driving functions. These components include monocular cameras, binocular cameras, millimeter-wave radar, lidar, and ultrasonic radar. It's worth noting that the ADC's functionality can be implemented by a Mobile Data Center (MDC). The CDC (Digital-to-Digital Converter) can provide services to vehicle components in the cockpit domain. These components include head-up displays (HUDs), instrument cluster displays, radios, navigation systems, and cameras. The VDC (Vehicle Data Center) can provide services to vehicle components in both the body and chassis domains. Body domain components include window and door controllers, power mirrors, air conditioning, and central locking systems. Chassis domain components include those in the braking system, steering system, and acceleration system, such as the accelerator pedal.

[0039] In this embodiment, VDC, MDC, and CDC can be logically integrated as needed. In one example, VDC and MDC are integrated, that is, vehicle control services and autonomous driving services are integrated, while CDC is retained. In another example, MDC and CDC are integrated, that is, autonomous driving and entertainment control modules are integrated, while VDC is retained. In yet another example, VDC and CDC are integrated, that is, vehicle control services and entertainment control modules are integrated, while MDC is retained. In yet another example, VDC, MDC, and CDC are integrated, that is, vehicle control services and autonomous driving services are integrated. In this case, the architecture integrates VDC, MDC, and CDC into a central computer. The correspondence between functions and components no longer exists, and the central computer commands the VIU on demand. In this embodiment, for the sake of simplification and ease of understanding, xDC can be used to replace VDC, MDC, CDC, or a component obtained by integrating two or three of VDC, MDC, and CDC.

[0040] To meet the needs of different vehicle models, the communication computing architecture can support different networking forms of VIU and xDC, such as ring networking and star networking. Figures 2 to 4 The diagrams show exemplary network topologies of ring networks in a communication computing architecture. Figure 5 and Figure 6 Exemplary network topologies for star-shaped communication computing architectures are shown. Figures 2 to 6 The VIU1, VIU2, VIU3, and VIU4 mentioned herein are VIUs. The functions of VIU, VDC, MDC, and CDC are as described above and will not be repeated here. It is understandable that... Figures 2 to 6 The communication computing architecture shown is merely an example and is not intended to limit the communication computing architecture. The communication computing architecture may include more or fewer VIUs and may have other networking forms, which will not be elaborated here.

[0041] Signal-oriented communication is the traditional interaction method for vehicles. ECUs transmit data point-to-point via CAN or LIN buses, and this communication method is determined at the factory. However, as vehicle architecture evolves to a communication-computing architecture, most computing power is concentrated in xDC (xDistributed Control Center). The interaction between software and hardware in the vehicle is no longer point-to-point; there is extensive coordination between hardware components. Any adjustment will affect the entire network, causing inconvenience for updates. Signal-oriented communication is no longer adequate for a communication-computing architecture.

[0042] Service-Oriented Architecture (SOA) effectively solves the coupling problem between hardware and software, and is a software architecture that adapts to the centralized evolution of electronic and electrical architectures. Under the SOA concept, when a vehicle needs to perform a certain function, relevant service A "subscribes" to service B. After receiving the subscription information, service A "pushes" the service to service B, which then executes the function. SOA service-oriented architecture means that service upgrades and adjustments will not affect the entire network, thereby improving the vehicle's functional scalability. Different services can call different software combinations, and different service combinations can also execute different functions, greatly enhancing software reusability.

[0043] In the communication computing architecture, the VIU and xDC constitute the core network of the vehicle network, while the CAN, Ethernet, LIN, and General-Purpose Input / Output (GPIO) connections under the VIU constitute the access network of the vehicle network. In this embodiment, to maintain compatibility with existing ECUs, the access network still adopts sleep / wake-up methods such as CAN and LIN from related technologies; however, to ensure the flexibility of the sleep / wake-up scheme, the core network uses the wake-up / sleep method provided in this embodiment. The sleep / wake-up scheme provided in this embodiment can simplify the development for vehicle manufacturers and maximize the platformization of the sleep / wake-up scheme. The sleep / wake-up scheme provided in this embodiment can be loaded into the vehicle equipment in software form (early or later) and sold.

[0044] Figure 7 This diagram illustrates the architecture of a sleep / wake-up system provided in an embodiment of this application. Figure 7 As shown, the sleep-wake system includes a wake-up source resolver 11, a wake-up policy controller 12, and a wake-up executor 13.

[0045] The wake-up source resolver 11 can be used 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 can represent a sleep wake-up signal generated in the vehicle network of a first vehicle model, where "first vehicle model" can represent any vehicle model. It is understood that functionally identical sleep wake-up signals generated in the vehicle networks of different vehicle models are different. For example, the vehicle network of vehicle model A (i.e., the first vehicle model) achieves full wake-up of the vehicle's low-voltage power supply through a high-level PIN input (i.e., a sleep wake-up signal generated in the vehicle network of vehicle model A); the vehicle network of vehicle model B (i.e., the first vehicle model) achieves full wake-up of the vehicle's low-voltage power supply through a CAN message with KeyON=1 (i.e., a sleep wake-up signal generated in the vehicle network of vehicle model B). The second sleep wake-up signal can be used to represent a unified sleep wake-up signal converted from functionally identical sleep wake-up signals generated in the vehicle networks of different vehicle models. For example, the wake-up source resolver 11 can convert the aforementioned high-level PIN input into "KL15=1", and can also convert the aforementioned CAN message with KeyON=1 into "KL15=1". Therefore, the first sleep / wake-up signals generated by the in-vehicle networks of different vehicle models, which have the same function, can be converted into a unified sleep / wake-up signal after being parsed by the wake-up source parser 11.

[0046] In one example, the first sleep wake-up signal includes, but is not limited to, CAN messages, Ethernet interface messages, LIN interface messages, and General-Purpose Input / Output (GPIO) messages. These messages include, but are not limited to, network management messages and service messages; the types of these messages are not limited in this embodiment.

[0047] In one possible implementation, the first sleep / wake-up signal includes a first signal for waking up the vehicle-mounted object, and / or a second signal for controlling the vehicle-mounted object to enter sleep mode. The wake-up source parser 11 can determine that it has obtained the first signal if it receives a network management message, a service message, or detects a first level change; and can determine that it has obtained the second signal if it does not receive a network management message, a service message, or detects a second level change within a preset time. The preset time can be set as needed, for example, it can be set to 30 seconds or 1 minute, and this application does not limit this.

[0048] The first level change can represent a level change used to wake up the in-vehicle object, and the second level change can represent a level change used to control the in-vehicle object to enter sleep mode. The first level change may be a change from low to high or a change from high to low; the second level change may be a change from low to high or a change from high to low. In this embodiment, it is possible to pre-set which interfaces or lines detect a change from low to high as a first level change, which interfaces or lines detect a change from low to high as a second level change, and which interfaces or lines detect a change from high to low as a first level change and which interfaces or lines detect a change from high to low as a second level change. In this way, when the wake-up source parser 11 detects a level change (from low to high or from high to low) on a certain interface or line, it can determine whether the level change belongs to the first level change or the second level change according to the pre-set content, and thus determine whether the first signal or the second signal has been obtained.

[0049] like Figure 7 As shown, when an external wake-up source (e.g., CAN, LIN, Ethernet interface, GPIO, etc.) starts sending network management messages or service messages, or stops sending network management messages or service messages, the wake-up source parser 11 receives N collected first sleep wake-up signals. The wake-up source parser 11 converts each of the N first sleep wake-up signals to obtain N second sleep wake-up signals. Here, N is an integer greater than or equal to 1, and N represents the number of first sleep wake-up signals.

[0050] The wake-up source resolver 11 can send at least one second sleep wake-up signal to the wake-up policy controller 12. The sending method can be CANNM message, CAN application message, UDPNM message, or a custom message based on the IP protocol stack and a combination thereof. In this embodiment, there is no restriction on the way the wake-up source resolver 11 sends the second sleep wake-up signal to the wake-up policy controller 12.

[0051] The wake-up strategy controller 12 can be used to determine at least one static control target (or sleep-wake mode, wake-up mode, sleep mode, etc.) based on at least one second sleep-wake signal. The static control target can represent the function of the first sleep-wake signal. Here, the static control target includes a static wake-up target to be woken up, and / or a static sleep target to be put into sleep mode. For example, the static control target can be a CAN network segment, LIN network segment, Ethernet segment, or ECU combination required for DC charging, Bluetooth key unlocking wake-up, or vehicle wake-up, or a sleep mode for a specific CAN network segment, LIN network segment, Ethernet segment, or ECU combination.

[0052] like Figure 7 As shown, after receiving N second sleep wake-up signals, the wake-up decision controller 12 outputs M static control targets. Here, M is an integer greater than or equal to 1, representing the number of static control targets. It is understandable that although each second sleep wake-up signal corresponds to one static control target, considering that some static control targets can be merged, the number of static control targets output by the wake-up decision controller 12 may differ from the number of received second sleep wake-up signals. For example, if second sleep wake-up signal A corresponds to static control target A, second sleep wake-up signal B corresponds to static control target B, and second sleep wake-up signal C corresponds to static control target C, then the final static control target output by the wake-up decision controller 12 is the union of static control targets A, B, and C. If static control targets A, B, and C can be merged, the final output of the wake-up decision controller 12 needs to be merged to avoid unnecessary processing by the wake-up actuator 13. For example, if static control target A is CAN1 wake-up, static control target B is CAN2 wake-up, and static control target C is vehicle wake-up, then the wake-up decision controller 12 only needs to output vehicle wake-up, and does not need to output CAN1 wake-up, CAN2 wake-up and vehicle wake-up.

[0053] The wake-up decision controller 12 can send at least one static control target to the wake-up actuator 13. The sending method can be CANNM messages, CAN application messages, UDPNM messages, or custom messages based on the IP protocol stack, or combinations thereof. This embodiment does not limit the method by which the wake-up decision controller 12 sends the static control target to the wake-up actuator 13. In one possible implementation, the wake-up decision controller 12 can send the static control target to the wake-up actuator 13 via unicast or broadcast.

[0054] The wake-up actuator 13 can be used to determine at least one sleep wake-up action based on at least one static control target. The sleep wake-up action can be used to wake up at least one on-board object (e.g., CAN, LIN, ECU, etc.) in at least one vehicle integration unit (VIU), or to control at least one on-board object in at least one VUI to enter sleep mode. Specifically, 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 can be used to wake up at least one on-board object in at least one VUI; 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 can be used to control at least one on-board object in at least one VUI to enter sleep mode.

[0055] The wake-up actuator 13 can perform at least one defined sleep wake-up action. In one example, performing a sleep wake-up action includes, but is not limited to, sending a CAN NM to the ECU to wake up the ECU via a specific interface.

[0056] The hibernation / wake-up system provided in this application can be applied to intelligent vehicles, new energy vehicles, or traditional vehicles. New energy vehicles include pure electric vehicles, range-extended electric vehicles, hybrid vehicles, fuel cell vehicles, and other new energy vehicles. Traditional vehicles include gasoline vehicles and diesel vehicles.

[0057] The sleep / wake-up system provided in this application embodiment can convert sleep / wake-up signals generated by vehicle networks of different vehicle models into a unified sleep / wake-up signal and obtain a unified static control target, thereby waking up or putting the vehicle objects in the vehicle integration unit into sleep mode. The sleep / wake-up control in the communication computing architecture is realized through software.

[0058] Figure 8 A flowchart illustrating a sleep / wake-up method provided in an embodiment of this application is shown. The method can be applied to a sleep / wake-up system, for example... Figure 7 The sleep / wake-up system shown. (As illustrated) Figure 8 As shown, the method may include: Step S201: Convert at least one first sleep wake-up signal into at least one second sleep wake-up signal.

[0059] Wherein, the first sleep wake-up signal is used to characterize the sleep wake-up signal generated in the vehicle network of the first vehicle model, and the second sleep wake-up signal is used to characterize the unified sleep wake-up signal converted from sleep wake-up signals with the same function generated in the vehicle networks of different vehicle models.

[0060] In one example, the first sleep wake-up signal may include a first signal for waking up an in-vehicle object. The sleep wake-up system can determine that the first signal has been received upon receiving a network management message, a service message, or detecting a first level change. When the sleep wake-up system determines that the first signal has been received, it indicates that one or more in-vehicle objects in one or more vehicle integration units need to be woken up.

[0061] In another example, the first sleep / wake signal may include a second signal for controlling an in-vehicle object to enter sleep mode. The sleep / wake system determines that it has received the second signal if no network management message or service message is received within a preset time, or if a second level change is detected. When the sleep / wake system determines that it has received the second signal, it indicates that it needs to control one or more in-vehicle objects in one or more vehicle integration units to enter sleep mode.

[0062] For ease of description, the embodiments of this application use... Figure 9 The network topology shown is used as an example for illustration. Figure 9 An exemplary schematic diagram of a network topology for a communication computing architecture is shown. Figure 9 As shown, this communication computing architecture includes four VIUs (VIU1, VIU2, VIU3, and VIU4) as well as VDC, MDC, and CDC. Figure 9 As shown, VIU1 includes CAN11 and CAN12; CAN11 connects to ECU11, ECU12, and ECU13; CAN12 connects to ECU14, ECU15, and ECU16. VIU2 includes CAN21 and LIN21; CAN21 connects to ECU21, ECU22, and ECU23; LIN21 connects to ECU24, ECU25, and ECU26. VIU3 includes CAN31, CAN32, and CAN33; CAN31 connects to ECU31, ECU32, and ECU33; CAN33 connects to ECU34 and ECU35; CAN32 connects to ECU36. VIU4 includes CAN41 and LIN41; LIN41 connects to ECU41, ECU42, and ECU43; CAN41 connects to ECU44, ECU45, and ECU46. VIU1, VIU2, VIU3, and VIU4 are vehicle integration units; CAN11, CAN12, and LIN21 are vehicle-mounted objects; and ECU11, ECU12, and ECU13 are also vehicle-mounted objects. The first signal can be used to wake up one or more vehicle-mounted objects within one or more vehicle integration units. For example, the first signal can be used to wake up CAN11 of VIU1, or to wake up ECU14 and ECU15 connected to CAN12 of VIU1. The second signal can be used to control one or more vehicle-mounted objects within one or more vehicle integration units to enter sleep mode. For example, the second signal can be used to control CAN41 and LIN41 of VIU4 to enter sleep mode, or to control ECU44 connected to CAN41 to enter sleep mode, etc.

[0063] In one possible implementation, step S201 may include: for any one of the at least one first sleep wake-up signals, determining a second sleep wake-up signal corresponding to the first sleep wake-up signal based on a first mapping relationship, wherein the first mapping relationship is used to characterize the mapping relationship between sleep wake-up signals generated in the vehicle network of the first vehicle model and a unified sleep wake-up signal.

[0064] Table 1 shows an example of the first mapping relationship. As shown in Table 1, based on Figure 9When the VIU3 J4-35 detects a high level, the sleep / wake-up system can determine that it has acquired the first sleep / wake-up signal. At this time, the sleep / wake-up system can convert the first sleep / wake-up signal into the second sleep / wake-up signal "A+DC charging" according to the first mapping relationship. When there is no network management message on CAN21, the sleep / wake-up system can determine that it has acquired the first sleep / wake-up signal. At this time, the sleep / wake-up system can convert the first sleep / wake-up signal into the second sleep / wake-up signal "CAN21 requesting sleep" according to the first mapping relationship. In one possible implementation, the name of the second sleep / wake-up signal can be used to characterize its function. Considering that the first sleep / wake-up signal before conversion and the second sleep / wake-up signal after conversion correspond and perform the same function, the name of the second sleep / wake-up signal also characterizes the function of the first sleep / wake-up signal.

[0065] Table 1

[0066] As shown in Table 1, in the embodiments of this application, a unique identifier can be set for each second sleep wake-up signal. In this way, by using the identifier of the second sleep wake-up signal instead of the name of the second sleep wake-up signal, efficiency can be improved.

[0067] by Figure 7 Taking the sleep-wake system shown as an example, the wake-up source resolver 11 converts the first sleep-wake signal into a second sleep-wake signal and sends the second sleep-wake signal to the wake-up policy controller 12 for further processing. In this embodiment, interface 1 is used to represent the interface between the wake-up source resolver 11 and the wake-up policy controller 12. The wake-up source resolver 11 can send the second sleep-wake signal to the wake-up policy controller 12 through interface 1.

[0068] Table 2 shows an example of Interface 1. As shown in Table 2, Interface 1 defines the name corresponding to the second sleep wake-up signal with identifier 2 as "Bluetooth key unlock". Therefore, when the wake-up source resolver 11 transmits identifier 2 through Interface 1, the wake-up policy controller 12 can obtain the name of the second sleep wake-up signal as "Bluetooth key unlock".

[0069] Table 2

[0070] In this embodiment of the application, the first mapping relationship and interface 1 can be set as needed and based on historical experience.

[0071] Step S202: Based on the at least one second sleep wake-up signal, determine at least one static control target.

[0072] The static control target is used to represent the function of the first sleep-wake signal.

[0073] In one possible implementation, step S202 may include: for any one of the at least one second sleep wake-up signals, determining a static control target corresponding to the second sleep wake-up signal based on a second mapping relationship, wherein the second mapping relationship is used to characterize the mapping relationship between a 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.

[0074] Table 3 shows an example of the second mapping relationship. As shown in Table 3, based on Figure 9 When the sleep / wake system receives a second sleep / wake signal identified as 1, a static control target identified as 1, named "DC charging," and containing "CAN41" can be obtained according to the second mapping relationship. This static control target represents the "A+ DC charging" function. When the sleep / wake system receives a second sleep / wake signal identified as 2, a static control target identified as 2, named "Bluetooth key unlock wake-up," and containing "CAN11, CAN12, and CAN31" can be obtained according to the second mapping relationship. This static control target represents the "Bluetooth key unlock" function.

[0075] Table 3

[0076] As shown in Table 3, in the embodiments of this application, each static control target can be assigned a unique identifier based on its function, or a unique identifier can be assigned to each static control target as needed. This improves efficiency by transmitting the identifier of the static control target instead of the name and content of the static controllable target.

[0077] by Figure 7 The illustrated sleep-wake system involves the wake-up strategy controller 12 determining a static control target based on a second sleep-wake signal and sending the static control target to the wake-up actuator 13 for further processing. In this embodiment, interface 2 represents the interface between the wake-up strategy controller 12 and the wake-up actuator 13. The wake-up source strategy controller 12 can send the static control target to the wake-up actuator 13 through interface 2.

[0078] Table 4 shows an example of interface 2. As shown in Table 4, interface 2 defines the content corresponding to the static control target with identifier 1 as "CAN41". Therefore, when the wake-up strategy controller 12 transmits identifier 1 through interface 2, the wake-up actuator 13 can obtain the name of the static control target as "DC charging" and the content as "CAN41".

[0079] Table 4

[0080] In this embodiment of the application, the second mapping relationship and interface 2 can be set as needed and based on historical experience.

[0081] Step S203: Based on the at least one static control target, determine at least one sleep / wake-up action.

[0082] The sleep / wake-up action is used to wake up at least one in-vehicle object in at least one vehicle integration unit or to control at least one in-vehicle object in at least one vehicle integration unit to enter sleep mode. It can be understood that when the first sleep / wake-up signal is a first signal, the corresponding sleep / wake-up action is used to wake up at least one in-vehicle object in at least one vehicle integration unit. When the first sleep / wake-up signal is a second signal, the corresponding sleep / wake-up action is used to control at least one in-vehicle object in at least one vehicle integration unit to enter sleep mode.

[0083] In one possible implementation, step S203 may include: for any one of the at least one static control targets, based on a third mapping relationship, determining at least one vehicle integration unit corresponding to the static control target, and the vehicle-mounted object in each determined vehicle integration unit that needs to be subject to sleep / wake-up control, wherein the third mapping relationship is used to characterize the mapping relationship between the static control target, the vehicle integration unit, and the vehicle-mounted object that needs to be subject to sleep / wake-up control; and determining the at least one sleep / wake-up action based on whether the vehicle-mounted object subject to sleep / wake-up control is currently in a wake-up state or a sleep state.

[0084] Table 5 shows an example of the third mapping relationship. As shown in Table 5, based on Figure 9 When the hibernation wake-up system obtains a static control target identified as 1, according to the third mapping relationship, the hibernation wake-up actions of ECU44 and ECU45, which are identified as 1, have the vehicle integration unit as "VIU4", and have the vehicle object as "CAN41", can be obtained. This hibernation wake-up action is used to wake up ECU44 and ECU45, which are connected to "CAN41" of the vehicle integration unit "VIU4".

[0085] Table 5

[0086] In this embodiment of the application, the third mapping relationship can be set as needed and based on historical experience.

[0087] Step S204: Execute the at least one sleep-wake action.

[0088] The sleep-wake system can execute various sleep-wake actions to wake up at least one in-vehicle object in at least one vehicle integration unit or control at least one in-vehicle object in at least one vehicle integration unit to go into sleep mode.

[0089] The sleep / wake-up system provided in this application embodiment can convert sleep / wake-up signals generated by vehicle networks of different vehicle models into a unified sleep / wake-up signal and obtain a unified static control target, thereby waking up or putting the vehicle objects in the vehicle integration unit into sleep mode. The sleep / wake-up control in the communication computing architecture is realized through software.

[0090] Figure 10 The interactive flowchart of the sleep-wake method provided in the embodiments of this application is shown. Figure 10 The method shown can be applied to Figure 7 The system shown. (As shown in the image) Figure 10 As shown, the method may include: Step S401: The external wake-up source sends at least one first sleep wake-up signal to the wake-up source resolver.

[0091] In step S402, the wake-up source resolver converts at least one first sleep wake-up signal into at least one second sleep wake-up signal.

[0092] In step S403, the wake-up source resolver sends at least one second sleep wake-up signal to the wake-up policy controller.

[0093] In step S404, the wake-up policy controller determines at least one static control target based on at least one second sleep wake-up signal.

[0094] In step S405, the wake-up policy controller sends at least one static control target to the wake-up actuator.

[0095] Step S406: The wake-up actuator determines at least one sleep wake-up action based on at least one static control target.

[0096] Step S407: The wake-up actuator performs at least one sleep wake-up action to wake up or put into sleep mode at least one on-board object in at least one vehicle integration unit.

[0097] Steps S401 to S407 can be referred to steps S201 to S204, and will not be repeated here.

[0098] The sleep / wake-up method provided in this application can convert sleep / wake-up signals generated by vehicle networks of different vehicle models into a unified sleep / wake-up signal and obtain a unified static control target, thereby waking up or putting the vehicle objects in the vehicle integration unit into sleep mode. The sleep / wake-up control in the communication computing architecture is realized in software.

[0099] In one possible implementation, the wake-up source resolver and wake-up executor in the sleep-wake system can be deployed in the vehicle integration unit, while the wake-up policy controller is deployed in the domain controller.

[0100] Figure 11 A deployment diagram of the wake-up and hibernation system provided in an embodiment of this application is shown. Figure 11 As shown, in Figure 9 Based on the communication computing architecture shown, a wake-up source resolver and a wake-up executor are deployed in each VIU (including VIU1, VIU2, VIU3 and VIU4), and a wake-up policy controller is deployed in xDC.

[0101] Figure 12 The diagram illustrates the interactive flowchart of the sleep-wake method provided in an embodiment of this application. The method can be applied to... Figure 11 The system shown. (As shown in the image) Figure 12 As shown, the method includes: Step S501: The external wake-up source sends a first sleep wake-up signal to the wake-up source resolver in the VIU.

[0102] An external signal source can send the first sleep / wake-up signal to the wake-up resolver in each VIU. For example... Figure 11 As shown, the external wake-up source sends the first sleep wake-up signal 11 and the first sleep wake-up signal 12 to the wake-up source resolver in VIU1; the external wake-up source sends the first sleep wake-up signal 21 and the first sleep wake-up signal 22 to the wake-up source resolver in VIU2; the external wake-up source sends the first sleep wake-up signal 31 and the first sleep wake-up signal 32 (not shown) to the wake-up source resolver in VIU3; and the external wake-up source sends the first sleep wake-up signal 41 and the first sleep wake-up signal 42 to the wake-up source resolver in VIU4. It can be understood that the external wake-up source can send more than... Figure 11 The number of first sleep wake-up signals shown.

[0103] In one example, the external wake-up source "Passive Entry & Passive Start (PEPS)" can send the first sleep wake-up signal "CAN NM message" to VIU1.

[0104] In step S502, the wake-up source resolver in the VIU converts the first sleep wake-up signal into a second sleep wake-up signal.

[0105] The wake-up source resolver in each VIU can convert the received first sleep wake-up signal into a second sleep wake-up signal. For example... Figure 11 As shown, the wake-up source resolver in VIU1 can convert the first sleep wake-up signal 11 into the second sleep wake-up signal 11, and the first sleep wake-up signal 12 into the second sleep wake-up signal 12; the wake-up source resolver in VIU2 can convert the first sleep wake-up signal 21 into the second sleep wake-up signal 21, and the first sleep wake-up signal 22 into the second sleep wake-up signal 22; the wake-up source resolver in VIU3 can convert the first sleep wake-up signal 31 into the second sleep wake-up signal 31, and the first sleep wake-up signal 32 into the second sleep wake-up signal 32 (not shown); the wake-up source resolver in VIU4 can convert the first sleep wake-up signal 41 into the second sleep wake-up signal 41, and the first sleep wake-up signal 42 into the second sleep wake-up signal 42. It should be noted that the above are only examples of the first and second sleep wake-up signals; in actual execution, there may be more or fewer first and second sleep wake-up signals.

[0106] In one example, the first sleep wake-up signal, “CAN NM message”, can be converted into a second sleep wake-up signal, “identified as 2 and named Bluetooth Key Unlock”.

[0107] In step S503, the wake-up source resolver in the VIU sends the second sleep wake-up signal to the wake-up policy controller in the xDC.

[0108] The wake-up source resolver in each VIU can send the obtained second sleep wake-up signal to the wake-up policy controller in the xDC for processing. For example... Figure 11 As shown, the wake-up source resolver in VIU1 can send the second sleep wake-up signal 11 and the second sleep wake-up signal 12 to the wake-up policy controller in xDC. The wake-up source resolver in VIU2 can send the second sleep wake-up signal 21 and the second sleep wake-up signal 22 to the wake-up policy controller in xDC. The wake-up source resolver in VIU4 can send the second sleep wake-up signal 41 and the second sleep wake-up signal 42 to the wake-up policy controller in xDC.

[0109] In one example, the wake-up source resolver in the VIU1 sends a second sleep wake-up signal, identified as "2 and named Bluetooth Key Unlock", to the wake-up policy controller in the xDC.

[0110] In step S504, the wake-up policy controller in xDC determines the static control target based on the second sleep wake-up signal from the wake-up source resolver in each VIU.

[0111] The wake-up policy controller in xDC can determine a static control target based on each received second sleep wake-up signal, and take the union of all static control targets to obtain the final static control target. As shown in Figure 11, the xDC wake-up policy controller finally obtains static control target 1.

[0112] In one example, the wake-up policy controller in xDC obtains a static control target of "identified as 2 and named Bluetooth key unlock wake-up" based on the second sleep wake-up signal "identified as 2 and named Bluetooth key unlock wake-up" (as shown in Table 3).

[0113] In step S505, the wake-up decision controller in xDC sends the static control target to the wake-up actuator in each VIU.

[0114] like Figure 11 As shown, the wake-up decision controller in xDC sends the static wake-up target 1 to the wake-up executor in VIU2, the wake-up executor in VIU3 (not shown), and the wake-up executor in VIU4, respectively.

[0115] In one example, the wake-up policy controller in the xDC sends a static control target, identified as 2 and named Bluetooth Key Unlock Wake-up, to the wake-up actuators in all VIUs.

[0116] In step S506, the wake-up actuator in the VIU determines the vehicle objects that need to be woken up and / or the vehicle objects that need to be put into hibernation in the current VIU based on the received static control target and the status of each vehicle object in the current VIU.

[0117] like Figure 11As shown, the wake-up actuator in VIU1 determines, based on static control target 1 and the state of each vehicle-mounted object in VIU1, that sleep wake-up action 11 (e.g., waking up vehicle-mounted object 1) and sleep wake-up action 12 (e.g., controlling vehicle-mounted object 2 to sleep) need to be executed; the wake-up actuator in VIU2 determines, based on static control target 1 and the state of each vehicle-mounted object in VIU2, that sleep wake-up action 21 and sleep wake-up action 22 need to be executed; the wake-up actuator in VIU3 determines, based on static control target 1 and the state of each vehicle-mounted object in VIU3, that sleep wake-up action 31 and sleep wake-up action 32 (not shown) need to be executed; and the wake-up actuator in VIU4 determines, based on static control target 1 and the state of each vehicle-mounted object in VIU4, that sleep wake-up action 41 and sleep wake-up action 42 need to be executed. It should be noted that the above are only examples of sleep wake-up actions; in actual execution, more or fewer actions may be determined than those described above.

[0118] In one example, the wake-up actuator in VIU1 wakes up ECU11 and ECU12 connected to CAN11, and ECU14, ECU15 and ECU16 connected to CAN12. The wake-up actuator in VIU2 wakes up ECU21 connected to CAN21. The wake-up actuator in VIU3 has no corresponding sleep / wake-up action, and the wake-up actuator in VIU4 has no sleep / wake-up action.

[0119] In step S507, the wake-up actuator in the VIU wakes up the vehicle objects in the current VIU that need to be woken up, and / or controls the vehicle objects in the current VIU that need to be hibernated to hibernate.

[0120] In one example, VIU1 and VIU2 perform the above sleep-wake actions, while VIU3 and VIU4 do not need to perform sleep-wake actions.

[0121] The sleep / wake-up method provided in this application can convert sleep / wake-up signals generated by vehicle networks of different vehicle models into a unified sleep / wake-up signal and obtain a unified static control target, thereby waking up or putting the vehicle objects in the vehicle integration unit into sleep mode. The sleep / wake-up control in the communication computing architecture is realized in software.

[0122] Considering that vehicles have specific wake-up time requirements. For example, when the owner approaches the vehicle within a certain distance (e.g., 5 meters), the vehicle will detect the car key. At this time, the vehicle will wake up the VIU and xDC. If the user moves further closer to the vehicle, it can automatically unlock, thus providing a good user experience. If the vehicle wake-up time is too long (e.g., >1 second), the door may not be unlocked when the owner needs to open it, which will affect the customer experience. Figure 11The wake-up strategy controller is deployed in xDC. All sleep-wake actions need to go through the process of "VIU" to "xDC" and back to "VIU". Therefore, the sleep-wake time of the vehicle is extended, which may affect the user experience.

[0123] In one possible implementation, the wake-up source resolver, wake-up policy controller, and wake-up executor in the sleep-wake system can all be deployed in the vehicle integration unit.

[0124] Figure 13 A deployment diagram of the wake-up and hibernation system provided in an embodiment of this application is shown. Figure 13 As shown, in Figure 9 Based on the communication computing architecture shown, each VIU (including VIU1, VIU2, VIU3 and VIU4) deploys a wake-up source resolver, a wake-up executor, and a wake-up policy controller.

[0125] Considering that an external wake-up source on one VIU can affect the connected vehicle objects of other VIUs, the static control target output by the wake-up policy controller on one VIU needs to be sent to the wake-up actuators on each VIU for processing. To simplify the design, it is assumed that each wake-up policy controller carries the same wake-up policy (i.e., the second mapping relationship). Therefore, the wake-up source resolver on one VIU only needs to send the static control target to the wake-up actuators on each VIU, without needing to send the second sleep wake-up signal to the wake-up policy controllers on other VIUs for processing. Furthermore, assuming a reasonable vehicle network plan, even if the wake-up policy controller on one VIU only supports the external wake-up source on that VIU (i.e., can only convert the first sleep wake-up signal generated on that VIU), it is still possible to achieve the goals of waking up the entire vehicle and controlling the vehicle to enter sleep mode. In principle, one wake-up policy controller will be deployed for each VIU. If, during the vehicle network design process, it is found that a certain VIU does not directly receive external wake-up sources, then that VIU does not need to deploy a wake-up policy controller.

[0126] Figure 14 The diagram illustrates the interactive flowchart of the sleep-wake method provided in an embodiment of this application. The method can be applied to... Figure 13 The system shown. (As shown in the image) Figure 14 As shown, the method includes: Step S601: The external wake-up source sends a first sleep wake-up signal to the wake-up source resolver in the VIU.

[0127] In step S602, the wake-up source resolver in the VIU converts the first sleep wake-up signal into a second sleep wake-up signal.

[0128] Steps S601 and S602 can be referred to as steps S501 and S502, and will not be repeated here.

[0129] In step S603, the wake-up source resolver in the VIU sends the second sleep wake-up signal to the wake-up policy controller in the current VIU.

[0130] In one example, the wake-up source resolver in the VIU1 sends a second sleep wake-up signal, identified as "2, named Bluetooth Key Unlock", to the wake-up policy controller in the VIU1.

[0131] In step S604, the wake-up policy controller in the VIU determines the static control target based on the second sleep wake-up signal from the wake-up source resolver in the current VIU.

[0132] In one example, the wake-up policy controller in VIU1 obtains a static control target of "identified as 2 and named Bluetooth key unlock wake-up" based on the second sleep wake-up signal "identified as 2 and named Bluetooth key unlock wake-up" (as shown in Table 3).

[0133] In step S605, the wake-up decision controller in the VIU sends the static control target to the wake-up actuator in the VIU.

[0134] In one possible implementation, the wake-up decision controller in the VIU can send static control targets to the wake-up actuators in all VIUs. Then, the wake-up actuators in each VIU can execute steps S606 and S607 to control the onboard object. For example, such as... Figure 9 The wake-up policy controller in VIU1 sends a static control target "identified as 2 and named Bluetooth key unlock wake-up" to the wake-up actuators in VIU1, VIU2, VIU3 and VIU4 respectively.

[0135] In one possible implementation, the wake-up decision controller in the VIU can send static control targets to the wake-up actuators in the VIU associated with the static control targets. For example, as shown in Table 3, since the static control target "identified as 2, named Bluetooth key unlock wake-up" involves CAN11, CAN12, and CAN31, such as... Figure 9 As shown, CAN11 and CAN12 are connected to VIU1, and CAN31 is connected to VIU3. That is to say, the VIUs associated with the static control target "identified as 2 and named Bluetooth key unlock wake-up" are VIU1 and VIU3. Therefore, the wake-up decision controller in VIU1 can send the static control target to the wake-up actuators in VIU1 and VIU3 respectively.

[0136] In step S606, the wake-up actuator in the VIU determines the vehicle objects that need to be woken up and / or the vehicle objects that need to be put into hibernation in the current VIU based on the received static control target and the current state of each vehicle object in the VIU.

[0137] In step S607, the wake-up actuator in the VIU wakes up the vehicle objects that need to be woken up in the current VIU, and / or controls the vehicle objects that need to be hibernated in the current VIU to hibernate.

[0138] Steps S606 and S607 can be referred to steps S506 and S507, and will not be repeated here.

[0139] In this embodiment, the wake-up policy controller deployed in xDC is moved down to each VIU, which speeds up the wake-up speed when it is necessary to wake up the local vehicle objects of the VIU from sleep.

[0140] for Figure 13 Regarding the wake-up strategy controller mentioned above, if the static control targets corresponding to the wake-up sources received by different VIUs conflict, for example, VIU1 will trigger CAN21 wake-up while VIU2 will trigger CAN21 sleep, a conflict will occur.

[0141] In one possible implementation, the wake-up policy controller is divided into a distributed wake-up policy controller and a centralized wake-up policy controller. The wake-up source resolver, wake-up executor, and distributed wake-up policy controller in the sleep wake-up system are deployed in the vehicle integration unit, while the centralized wake-up policy controller is deployed in the domain controller.

[0142] Figure 15 A deployment diagram of the wake-up and hibernation system provided in an embodiment of this application is shown. Figure 15 As shown, in Figure 9 Based on the communication computing architecture shown, each VIU (including VIU1, VIU2, VIU3 and VIU4) deploys a wake-up source resolver, a wake-up executor, and a distributed wake-up policy controller, while xDC deploys a centralized wake-up policy controller.

[0143] To ensure that the local wake-up source can quickly wake up the in-vehicle objects, while avoiding conflicts in wake-up and sleep behaviors of different in-vehicle objects caused by different wake-up sources, based on the principle of "fast wake-up, slow sleep," the distributed wake-up strategy controller and the centralized wake-up strategy controller need to divide their work for the wake-up action in this embodiment. Specifically, the distributed wake-up strategy controller can only decide on the wake-up of in-vehicle objects within its own VIU; the centralized wake-up strategy controller can only decide on the wake-up of in-vehicle objects across VIUs.

[0144] To ensure that the centralized policy controller makes decisions from wake-up sources of different VIUs, it is necessary to modify wake-up source interface 1 and add the definition of the source VIU. The modified interface 1 (which can be called interface 3) is shown in Table 6.

[0145] Table 6

[0146] Regarding hibernation, in this embodiment of the application, it is necessary to... Figure 14 Based on this, the strategies involved in hibernation will be moved up to the centralized wake-up strategy controller. Figure 16 The diagram illustrates the interactive flowchart of the sleep-wake method provided in an embodiment of this application. The method can be applied to... Figure 15 The system shown. (As shown in the image) Figure 16 As shown, the method includes: Step S701: The external wake-up source sends a first sleep wake-up signal to the wake-up source resolver in the first VIU.

[0147] Here, the first VIU represents any VIU in the communication computing architecture.

[0148] In step S702, the wake-up source parser in the first VIU converts the first sleep wake-up signal into a second sleep wake-up signal.

[0149] Steps S701 and S702 can be referred to as steps S501 and S502, and will not be repeated here.

[0150] In step S7031, the wake-up resolver in the first VIU sends the second sleep wake-up signal to the distributed wake-up policy controller in the first VIU.

[0151] In one example, the wake-up source resolver in the VIU1 sends a second sleep wake-up signal, identified as "2 and named Bluetooth Key Unlock", to the distributed wake-up policy controller in the VIU1.

[0152] In step S7032, the wake-up resolver in the first VIU sends the second sleep wake-up signal to the centralized wake-up strategy controller in the xDC.

[0153] In one example, the wake-up source resolver in the VIU1 sends a second sleep wake-up signal, identified as "2 and named Bluetooth Key Unlock", to the centralized wake-up policy controller in the xDC.

[0154] In step S7041, the distributed wake-up policy controller in the first VIU determines the static control target based on the second sleep wake-up signal from the wake-up source resolver in the first VIU.

[0155] In one example, the distributed wake-up policy controller in the VIU1 determines the static control target "Identified as 2, named Bluetooth Key Unlock Wake-up" based on the second sleep wake-up signal "identified as 2, named Bluetooth Key Unlock" from the VIU1.

[0156] In step S7042, the centralized wake-up policy controller in xDC determines the static control target based on the second sleep wake-up signal from the wake-up source resolver in the first VIU.

[0157] In one example, the centralized wake-up policy controller in xDC determines the static control target "Identified as 2, named Bluetooth Key Unlock Wake-up" based on the second sleep wake-up signal "identified as 2, named Bluetooth Key Unlock" from VIU1.

[0158] In step S7051, the distributed wake-up policy controller in the first VIU sends a defined static wake-up target to the wake-up executor in the first VIU.

[0159] In one example, the wake-up policy controller in the VIU1 sends a static control target, identified as 2 and named "Bluetooth Key Unlock Wake-up", to the wake-up actuator in the VIU1.

[0160] In step S7052, the centralized wake-up policy controller in xDC sends a defined static wake-up target to the wake-up executor in the second VIU.

[0161] The second VIU refers to the VIU other than the first VIU in the communication computing architecture.

[0162] In one example, the wake-up policy controller in xDC sends a static control target, identified as 2 and named Bluetooth Key Unlock Wake-up, to the wake-up actuator in VIU other than VIU1.

[0163] In step S7061, the wake-up actuator in the first VIU determines the vehicle objects that need to be woken up and / or the vehicle objects that need to be put into hibernation in the first VIU based on the received static control target and the current state of each vehicle object in the VIU.

[0164] In one example, the wake-up actuator in VIU1 wakes up ECU11 and ECU12 connected to CAN11, and wakes up ECU14, ECU15 and ECU16 connected to CAN12.

[0165] In step S7062, the wake-up actuator in the second VIU determines the vehicle objects in the second VIU that need to be woken up and / or the vehicle objects that need to be put into hibernation, based on the received static control target and the status of each vehicle object in the current VIU.

[0166] In one example, the wake-up actuator in VIU2 wakes up ECU21 connected to CAN21. The wake-up actuator in VIU3 has no corresponding sleep wake-up action, and the wake-up actuator in VIU4 has no sleep wake-up action.

[0167] In step S7071, the wake-up actuator in the first VIU wakes up the vehicle-mounted object in the first VIU that needs to be woken up, and / or controls the vehicle-mounted object in the first VIU that needs to be put into sleep mode to go into sleep mode.

[0168] In step S7072, the wake-up actuator in the second VIU wakes up the vehicle-mounted object in the second VIU that needs to be woken up, and / or controls the vehicle-mounted object in the second VIU that needs to be put into sleep mode to go into sleep mode.

[0169] In this embodiment, because a distributed wake-up policy controller is deployed locally in the VIU, the wake-up speed can be accelerated when the wake-up source of the VIU needs to wake up the local in-vehicle object. Meanwhile, since a centralized wake-up policy controller is still retained in the xDC, the sleep-wake conflict problem is resolved, and reliability is improved.

[0170] It should be noted that, in the embodiments of this application, the wake-up policy controller deployed in the VIU can be referred to as the distributed wake-up policy controller, and the wake-up policy controller deployed in the xDC can be referred to as the centralized wake-up policy controller or the global wake-up policy controller.

[0171] Figure 17 This diagram illustrates the structure of the sleep / wake-up device provided in an embodiment of this application. Figure 17 As shown, device 1700 may include: The conversion module 1701 is used 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 is used to characterize the sleep wake-up signal generated in the vehicle network of the first vehicle model, and the second sleep wake-up signal is used to characterize the unified sleep wake-up signal converted from the sleep wake-up signals with the same function generated in the vehicle networks of different vehicle models. The first determining module 1702 is used to determine at least one static control target based on the at least one second sleep-wake signal, wherein the static control target is used to represent the function of the first sleep-wake signal; The second determining module 1703 is used to determine at least one sleep-wake action based on the at least one static control target. The sleep-wake action is used to wake up at least one vehicle object in at least one vehicle integration unit or to control at least one vehicle object in at least one vehicle integration unit to go into sleep mode. The execution module 1704 is used to execute the at least one sleep-wake action.

[0172] In one possible implementation, the conversion module is further configured to: For any one of the at least one first sleep wake-up signals, a second sleep wake-up signal corresponding to the first sleep wake-up signal is determined based on a first mapping relationship. The first mapping relationship is used to characterize the mapping relationship between the sleep wake-up signal generated in the vehicle network of the first vehicle model and the unified sleep wake-up signal.

[0173] In one possible implementation, the first determining module is further configured to: For any one of the at least one second sleep wake-up signals, a static control target corresponding to the second sleep wake-up signal is determined based on a second mapping relationship. The second mapping relationship is used to characterize the mapping relationship between the unified sleep wake-up signal and the vehicle object. The static control targets corresponding to each second sleep wake-up signal are merged to obtain at least one static control target.

[0174] In one possible implementation, the second determining module is further configured to: For any one of the at least one static control targets, based on a third mapping relationship, at least one vehicle integration unit corresponding to the static control target is determined, as well as the vehicle-mounted object in each determined vehicle integration unit that needs to be controlled for sleep and wake-up. The third mapping relationship is used to characterize the mapping relationship between the static control target, the vehicle integration unit, and the vehicle-mounted object that needs to be controlled for sleep and wake-up. Determine whether the vehicle-mounted object requiring sleep / wake control is currently in a wake-up state or a sleep state, and determine the at least one sleep / wake action.

[0175] In one possible implementation, the first sleep-wake signal includes a first signal for waking up the vehicle-mounted object, and / or a second signal for controlling the vehicle-mounted object to enter sleep mode. Figure 18 This diagram illustrates the structure of the sleep / wake-up device provided in an embodiment of this application. Figure 18 As shown, in Figure 17 Based on this, the device 1700 may further include: The third determining module 1705 is used to determine that the first signal has been obtained when a network management message is received, a service message is received, or a change in the first level is detected. The fourth determining module 1706 is used to determine that the second signal has been obtained if no network management message or service message is received within a preset time, or if a change in the second level is detected.

[0176] Embodiments of this application provide a sleep-wake device, including: a processor and a memory for storing processor-executable instructions; wherein the processor is configured to implement the above method when executing the instructions.

[0177] Embodiments of this application provide a non-volatile computer-readable storage medium storing computer program instructions thereon, which, when executed by a processor, implement the above-described method.

[0178] Embodiments of this application provide a computer program product including computer-readable code, or a non-volatile computer-readable storage medium carrying computer-readable code, wherein when the computer-readable code is run in a processor of an electronic device, the processor in the electronic device performs the above-described method.

[0179] Computer-readable storage media can be tangible devices capable of holding and storing instructions for use by an instruction execution device. Computer-readable storage media can be, for example, (but not limited to) electrical storage devices, magnetic storage devices, optical storage devices, electromagnetic storage devices, semiconductor storage devices, or any suitable combination of the foregoing. More specific examples (a non-exhaustive list) of computer-readable storage media include: portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), electrically programmable read-only memory (EPROM or flash memory), static random-access memory (SRAM), compact disc read-only memory (CD-ROM), digital video disc (DVD), memory sticks, floppy disks, mechanical encoding devices, such as punch cards or recessed protrusions storing instructions thereon, and any suitable combination of the foregoing.

[0180] The computer-readable program instructions or code described herein can be downloaded from computer-readable storage media to various computing / processing devices, or downloaded via a network, such as the Internet, local area network, wide area network, and / or wireless network, to an external computer or external storage device. The network may include copper transmission cables, fiber optic transmission, wireless transmission, 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 them to the computer-readable storage media in the respective computing / processing device.

[0181] The computer program instructions used to perform the operations of this application may be assembly instructions, instruction set architecture (ISA) instructions, machine instructions, machine-dependent instructions, microcode, firmware instructions, status setting data, or source code or object code written in any combination of one or more programming languages, including object-oriented programming languages ​​such as Smalltalk, C++, etc., and conventional procedural programming languages ​​such as the "C" language or similar programming languages. The computer-readable program instructions may be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer may be connected to the user's 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 personalized by utilizing state information from computer-readable program instructions. These electronic circuits can execute computer-readable program instructions to implement various aspects of this application.

[0182] Various aspects of this application are described herein with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this application. It should be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer-readable program instructions.

[0183] These computer-readable program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing apparatus to produce a machine such that, when executed by the processor of the computer or other programmable data processing apparatus, they create means for implementing the functions / actions specified in one or more blocks of the flowchart and / or block diagram. These computer-readable program instructions can also be stored in a computer-readable storage medium that causes a computer, programmable data processing apparatus, and / or other device to operate in a particular manner; thus, the computer-readable medium storing the instructions comprises an article of manufacture that includes instructions for implementing aspects of the functions / actions specified in one or more blocks of the flowchart and / or block diagram.

[0184] Computer-readable program instructions may also be loaded onto a computer, other programmable data processing apparatus, or other device to cause a series of operational steps to be performed on the computer, other programmable data processing apparatus, or other device to produce a computer-implemented process, thereby causing the instructions executed on the computer, other programmable data processing apparatus, or other device to perform the functions / actions specified in one or more boxes of a flowchart and / or block diagram.

[0185] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of apparatus, systems, methods, and computer program products according to various embodiments of this application. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of an instruction containing one or more executable instructions for implementing a specified logical function. In some alternative implementations, the functions marked in the blocks may occur in a different order than those shown in the drawings. For example, two consecutive blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved.

[0186] It should also be noted that each block in the block diagram and / or flowchart, as well as combinations of blocks in the block diagram and / or flowchart, can be implemented using hardware (such as circuits or ASICs (Application Specific Integrated Circuits)) that performs the corresponding function or action, or using a combination of hardware and software, such as firmware.

[0187] Although the invention has been described herein in conjunction with various embodiments, those skilled in the art will understand and implement other variations of the disclosed embodiments by reviewing the accompanying drawings, disclosure, and appended claims in carrying out the claimed invention. In the claims, the word "comprising" does not exclude other components or steps, and "a" or "an" does not exclude a plurality. A single processor or other unit can implement several functions listed in the claims. While different dependent claims may recite certain measures, this does not mean that these measures cannot be combined to produce good results.

[0188] The various embodiments of this application have been described above. These descriptions are exemplary and not exhaustive, nor are they limited to the disclosed embodiments. Many modifications and variations will be apparent to those skilled in the art without departing from the scope of the described embodiments. The terminology used herein is chosen to best explain the principles, practical application, or improvement of the technology in the market, or to enable others skilled in the art to understand the embodiments disclosed herein.

Claims

1. A method for waking up from hibernation, characterized in that, The method includes: At least one first sleep wake-up signal is converted into at least one second sleep wake-up signal, wherein the first sleep wake-up signal is used to characterize the sleep wake-up signal generated in the vehicle network of the first vehicle model, and the second sleep wake-up signal is used to characterize the unified sleep wake-up signal converted from the sleep wake-up signals with the same function generated in the vehicle networks of different vehicle models. Based on the at least one second sleep-wake signal, at least one static control target is determined, wherein the static control target is used to represent the function of the first sleep-wake signal; Based on the at least one static control objective, at least one sleep / wake-up action is determined; Perform at least one sleep / wake action.

2. The method according to claim 1, characterized in that, The step of converting at least one first sleep wake-up signal into at least one second sleep wake-up signal includes: For any one of the at least one first sleep wake-up signals, a second sleep wake-up signal corresponding to the first sleep wake-up signal is determined based on a first mapping relationship. The first mapping relationship is used to characterize the mapping relationship between the sleep wake-up signal generated in the vehicle network of the first vehicle model and the unified sleep wake-up signal.

3. The method according to claim 1 or 2, characterized in that, The determination of at least one static control target based on the at least one second sleep wake-up signal includes: For any one of the at least one second sleep wake-up signals, a static control target corresponding to the second sleep wake-up signal is determined based on a second mapping relationship. The second mapping relationship is used to characterize the mapping relationship between the unified sleep wake-up signal and the vehicle object. The static control targets corresponding to each second sleep wake-up signal are merged to obtain at least one static control target.

4. The method according to any one of claims 1 to 3, characterized in that, The determination of at least one sleep / wake-up action based on the at least one static control objective includes: For any one of the at least one static control targets, based on a third mapping relationship, at least one vehicle integration unit corresponding to the static control target is determined, as well as the vehicle-mounted object in each determined vehicle integration unit that needs to be controlled for sleep and wake-up. The third mapping relationship is used to characterize the mapping relationship between the static control target, the vehicle integration unit, and the vehicle-mounted object that needs to be controlled for sleep and wake-up. Determine whether the vehicle-mounted object requiring sleep / wake control is currently in a wake-up state or a sleep state, and determine the at least one sleep / wake action.

5. The method according to any one of claims 1 to 4, characterized in that, The first sleep / wake-up signal includes a first signal for waking up the vehicle-mounted object, and / or a second signal for controlling the vehicle-mounted object to enter sleep mode. The method further includes: Upon receiving a network management message, a service message, or detecting a change in the first level, it is determined that the first signal has been obtained; If no network management message or service message is received within a preset time, or if a change in the second level is detected, it is determined that the second signal has been obtained.

6. A sleep / wake-up system, characterized in that, The sleep-wake system includes: a wake-up source resolver, a wake-up policy controller, and a wake-up executor; The wake-up source parser is used to convert at least one first sleep wake-up signal into at least one second sleep wake-up signal, and send the at least one second sleep wake-up signal to the wake-up policy controller. The first sleep wake-up signal is used to characterize the sleep wake-up signal generated in the vehicle network of the first vehicle model, and the second sleep wake-up signal is used to characterize the unified sleep wake-up signal converted from the sleep wake-up signals with the same function generated in the vehicle networks of different vehicle models. The wake-up policy controller is configured to determine at least one static control target based on the at least one second sleep wake-up signal, and send the at least one static control target to the wake-up actuator, wherein the static control target represents the function of the first sleep wake-up signal; The wake-up actuator is used to determine at least one sleep wake-up action based on the at least one static control target, and to execute the at least one sleep wake-up action.

7. The system according to claim 6, characterized in that, The wake-up source resolver and the wake-up executor are deployed in the vehicle integration unit, and the wake-up policy controller is deployed in the domain controller.

8. The system according to claim 6, characterized in that, The wake-up source parser, the wake-up policy controller, and the wake-up executor are deployed in the vehicle integration unit.

9. The system according to claim 6, characterized in that, The wake-up policy controller includes a distributed wake-up policy controller and a centralized wake-up policy controller. The wake-up source resolver, the wake-up executor, and the distributed wake-up policy controller are deployed in the vehicle integration unit, while the centralized wake-up policy controller is deployed in the domain controller.

10. The system according to any one of claims 6 to 9, characterized in that, The wake-up source parser is also used for: For any one of the at least one first sleep wake-up signals, a second sleep wake-up signal corresponding to the first sleep wake-up signal is determined based on a first mapping relationship. The first mapping relationship is used to characterize the mapping relationship between the sleep wake-up signal generated in the vehicle network of the first vehicle model and the unified sleep wake-up signal.

11. The system according to any one of claims 6 to 10, characterized in that, The wake-up policy controller is also used for: For any one of the at least one second sleep wake-up signals, a static control target corresponding to the second sleep wake-up signal is determined based on a second mapping relationship. The second mapping relationship is used to characterize the mapping relationship between the unified sleep wake-up signal and the vehicle object. The static control targets corresponding to each second sleep wake-up signal are merged to obtain at least one static control target.

12. The system according to any one of claims 6 to 11, characterized in that, The wake-up actuator is also used for: For any one of the at least one static control targets, based on a third mapping relationship, at least one vehicle integration unit corresponding to the static control target is determined, as well as the vehicle-mounted object in each determined vehicle integration unit that needs to be controlled for sleep and wake-up. The third mapping relationship is used to characterize the mapping relationship between the static control target, the vehicle integration unit, and the vehicle-mounted object that needs to be controlled for sleep and wake-up. Determine whether the vehicle-mounted object requiring sleep / wake control is currently in a wake-up state or a sleep state, and determine the at least one sleep / wake action.

13. The system according to any one of claims 6 to 12, characterized in that, The first sleep-wake signal includes a first signal for waking up the vehicle-mounted object, and / or a second signal for controlling the vehicle-mounted object to go into sleep mode. The sleep-wake system also includes a wake-up source. The wake-up source is used to determine that the first signal has been obtained when a network management message is received, a service message is received, or a first level change is detected. If no network management message or service message is received within a preset time, or if a change in the second level is detected, it is determined that the second signal has been obtained.

14. A sleep / wake-up device, characterized in that, The device includes: A conversion module is used 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 is used to characterize the sleep wake-up signal generated in the vehicle network of the first vehicle model, and the second sleep wake-up signal is used to characterize a unified sleep wake-up signal converted from sleep wake-up signals with the same function generated in the vehicle networks of different vehicle models. A first determining module is configured to determine at least one static control target based on the at least one second sleep / wake-up signal, wherein the static control target represents the function of the first sleep / wake-up signal; The second determining module is used to determine at least one sleep / wake-up action based on the at least one static control target; An execution module is used to execute the at least one sleep / wake-up action.

15. The apparatus according to claim 14, characterized in that, The conversion module is also used for: For any one of the at least one first sleep wake-up signals, a second sleep wake-up signal corresponding to the first sleep wake-up signal is determined based on a first mapping relationship. The first mapping relationship is used to characterize the mapping relationship between the sleep wake-up signal generated in the vehicle network of the first vehicle model and the unified sleep wake-up signal.

16. The apparatus according to claim 14 or 15, characterized in that, The first determining module is further configured to: For any one of the at least one second sleep wake-up signals, a static control target corresponding to the second sleep wake-up signal is determined based on a second mapping relationship. The second mapping relationship is used to characterize the mapping relationship between the unified sleep wake-up signal and the vehicle object. The static control targets corresponding to each second sleep wake-up signal are merged to obtain at least one static control target.

17. The apparatus according to any one of claims 14 to 16, characterized in that, The second determining module is also used for: For any one of the at least one static control targets, based on a third mapping relationship, at least one vehicle integration unit corresponding to the static control target is determined, as well as the vehicle-mounted object in each determined vehicle integration unit that needs to be controlled for sleep and wake-up. The third mapping relationship is used to characterize the mapping relationship between the static control target, the vehicle integration unit, and the vehicle-mounted object that needs to be controlled for sleep and wake-up. Determine whether the vehicle-mounted object requiring sleep / wake control is currently in a wake-up state or a sleep state, and determine the at least one sleep / wake action.

18. The apparatus according to any one of claims 14 to 17, characterized in that, The first sleep / wake-up signal includes a first signal for waking up the vehicle-mounted object, and / or a second signal for controlling the vehicle-mounted object to enter sleep mode. The device further includes: The third determining module is used to determine that the first signal has been obtained when a network management message is received, a service message is received, or a change in the first level is detected. The fourth determining module is used to determine that the second signal has been obtained if no network management message or service message is received within a preset time, or if a change in the second level is detected.

19. A sleep / wake-up device, characterized in that, include: processor; Memory used to store processor-executable instructions; 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 thereon, characterized in that, When the computer program instructions are executed by the processor, they implement the method described in any one of claims 1 to 5.

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

Images