Network wake-up maintenance control method and apparatus, vehicle, and storage medium

Abstract

Embodiments of the present application provide a network wake-up maintenance control method and device, a vehicle and a storage medium, and relate to the technical field of vehicle electronic and electrical architecture. The present application can receive a network wake-up maintenance request carrying a general interface parameter initiated by an application component through a general interface; based on the general interface parameter, detect whether the network wake-up maintenance request meets a functional correlation requirement; when the network wake-up maintenance request meets the functional correlation requirement, respond to the network wake-up maintenance request; when the network wake-up maintenance request does not meet the functional correlation requirement, refuse to respond to the network wake-up maintenance request. The present application can arbitrate the functional correlation of the network wake-up maintenance request of each application component, respond to the network wake-up maintenance request on the premise that the network wake-up maintenance request meets the functional correlation requirement, which can effectively prevent the vehicle from running out of power, provide protection for the stability of the vehicle system, improve the overall vehicle quality, and optimize the user experience.

Description

Technical Field

[0001] This application relates to the field of vehicle electronic and electrical architecture technology, and more specifically, to a method, apparatus, vehicle, and storage medium for network wake-up sustain control. Background Technology

[0002] With the continuous development of intelligent vehicles and the increasing improvement of people's living standards, vehicle functions are becoming increasingly diverse. On the one hand, to meet different usage needs, more and more functions (such as silent upgrades, plug-in charging, and remote vehicle control) are enabled when the vehicle is in standby mode, requiring the wake-up and maintenance of the entire vehicle network. This results in high power consumption, and in standby mode powered only by the vehicle battery, it is very easy to cause the vehicle to run out of power. On the other hand, with the popularization of the Electrical / Electronic Architecture (EEA) 3.0, more and more modules and functions are integrated into the Central Computing Unit (CCU), which has complex network wake-up and maintenance requirements.

[0003] Because traditional electronic and electrical architectures involve distributed deployment of various vehicle components, the wake-up and maintenance of the entire vehicle's network are regulated by a unified Controller Area Network (CAN) communication protocol. There is no unified module for management, and the risk of power loss can only be avoided by extensive testing, reproduction, and optimization. However, there are still occasional reports of power loss issues in the market.

[0004] Due to the integration of multiple modules, the domain control architecture requires the addition of a Wake-on-LAN (WCC) module for management. Because the network request standards of functional modules differ, the current management approach primarily involves the WCC module prioritizing the fulfillment of WCC requests from functional modules, making it difficult to incorporate measures to prevent power loss. For example, when the vehicle is in standby mode, the Vehicle Control Unit (VCU) needs to initiate plug-in charging, requesting a WCC request (NmAwakeReq_VCU) from the charging network (Net_Charge) for 30 minutes. Simultaneously, if the user operates in-vehicle functions via the remote control module, the Remote Control (RC) module requests a WCC request (NmAwakeReq_RC) from the vehicle network (Net_Global) for 20 minutes. Ultimately, the WCC module will first maintain the vehicle network for 20 minutes, then maintain the charging network for 10 minutes, before entering network sleep mode. This method delegates control of network maintenance to functional modules, which can easily lead to network wake-up requests from functional modules persisting due to imperfect functional design or software defects, preventing the vehicle from going into sleep mode and ultimately causing power loss.

[0005] Based on the above analysis, the technical problem to be solved by this application is how to efficiently and simply manage the various network requirements in the central computing unit and reduce and eliminate the risk of power shortage. Summary of the Invention

[0006] This application provides a method, apparatus, vehicle, and storage medium for maintaining network wake-up control to solve the above-mentioned problems.

[0007] In a first aspect, embodiments of this application provide a method for controlling wake-up call maintenance (WCOP). The method includes: receiving a WCOP request initiated by an application component through a general interface, the WCOP request carrying general interface parameters provided by the application component; detecting whether the WCOP request meets functional associativity requirements based on the general interface parameters; responding to the WCOP request when the WCOP request meets the functional associativity requirements; and refusing to respond to the WCOP request when the WCOP request does not meet the functional associativity requirements.

[0008] Secondly, embodiments of this application provide a Wake-on-LAN (WLAN) maintenance control device, comprising: a request receiving module, configured to receive a WLAN maintenance request initiated by an application component through a general interface, the WLAN maintenance request carrying general interface parameters provided by the application component; a functional associativity arbitration module, configured to detect whether the WLAN maintenance request meets functional associativity requirements based on the general interface parameters; an active response module, configured to respond to the WLAN maintenance request when the WLAN maintenance request meets the functional associativity requirements; and a passive response module, configured to refuse to respond to the WLAN maintenance request when the WLAN maintenance request does not meet the functional associativity requirements.

[0009] Thirdly, embodiments of this application provide a vehicle, which includes a memory and a processor. The memory stores an application program that, when invoked by the processor, causes the processor to execute the method provided in embodiments of this application.

[0010] Fourthly, embodiments of this application provide a computer-readable storage medium storing program code, which, when invoked by a processor, causes the processor to execute the method provided in embodiments of this application.

[0011] The network wake-up maintenance control method provided in this application has the following technical effects: This application can arbitrate the functional correlation of network wake-up maintenance requests of various application components based on a general interface. It responds to network wake-up maintenance requests when the functional correlation requirements are met, and refuses to respond to network wake-up maintenance requests when the functional correlation requirements are not met. This can effectively prevent the vehicle from experiencing power loss, provide a guarantee for the stability of the whole vehicle system, improve the overall vehicle quality, and optimize the user experience. Attached Figure Description

[0012] To more clearly illustrate the technical solutions in the embodiments of this application, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments and drawings obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0013] Figure 1 A schematic diagram of the structure of the central processing unit provided in an embodiment of this application is shown;

[0014] Figure 2 A schematic flowchart of a network wake-up sustaining control method provided in an embodiment of this application is shown;

[0015] Figure 3A flowchart illustrating step S120 provided in an embodiment of this application is shown;

[0016] Figure 4 This illustration shows a schematic diagram of the functional relationships between multiple application components provided in an exemplary embodiment of this application;

[0017] Figure 5 A flowchart illustrating a network wake-up sustaining control method according to another embodiment of this application is shown;

[0018] Figure 6 A flowchart illustrating a network wake-up sustaining control method according to another embodiment of this application is shown;

[0019] Figure 7 A schematic diagram of the structure of the Wake-up Network Maintenance Control Device provided in an embodiment of this application is shown;

[0020] Figure 8 A schematic diagram of the vehicle structure provided in an embodiment of this application is shown. Detailed Implementation

[0021] To enable those skilled in the art to better understand the present application, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings.

[0022] Please see Figure 1 , Figure 1 A schematic diagram of the central processing unit (CCU) provided in an embodiment of this application is shown. The CCU 100 can be deployed in a vehicle. Figure 1 As shown, the central processing unit 100 may include a wake-up call control module (WCC) 110, a general interface 120, and multiple control modules 130. The multiple control modules 130 are used to implement different vehicle control functions. For example, ... Figure 1 As shown, the multiple control modules 130 may include a vehicle control module 131, a remote control module 132, an air conditioning control module (Heating Ventilation and Air Conditioning, HVAC) 133, and a thermal management system (TMS) 134, etc. It is understandable that... Figure 1 This is merely an example and not a limitation on the number of control modules. In practical applications, multiple control modules 130 can be deployed according to the actual functions of the vehicle, and may include... Figure 1 The control modules shown may not be all included. Figure 1 The complete set of control modules shown may also include Figure 1 Other control modules besides all the control modules shown.

[0023] like Figure 1 As shown, the central processing unit in this application provides a unified general interface 120. Each functional module (e.g., vehicle control module, remote control module, air conditioning control module) interacts with the network wake-up maintenance control module 110 through this general interface 120, for example, requesting a network wake-up maintenance request, thereby requesting network wake-up maintenance. The network wake-up maintenance control module 110 can perform multi-dimensional arbitration on the network wake-up maintenance request (see the method description section for details) to determine whether to respond to the network wake-up maintenance request, that is, whether to wake up the network, and issue the network status of each control module.

[0024] For example, the interface functions of the general interface 120 of this application can be shown in Table 1. The application (APP) in Table 1 can represent the control module mentioned above and the application component mentioned below. The ID (identification) in Table 1 refers to identification information; for example, APPID represents the identification information of the APP, used to uniquely identify the APP. APPID, NetType, AwakeTime, AwakeLevel, and SourceAPPID in Table 1 are general interface parameters. Each control module (i.e., application component) needs to provide these general interface parameters when initiating a network wake-up sustain request through the general interface. Specifically, the specific values ​​of each general interface parameter need to be provided.

[0025] Table 1

[0026]

[0027]

[0028] The wake-up call sustaining control method provided in this application can be applied to a vehicle or a wake-up call sustaining control device. Specifically, the wake-up call sustaining control method can be applied to the wake-up call sustaining control module in the central processing unit of a vehicle. The wake-up call sustaining control device can be deployed in the wake-up call sustaining control module in the central processing unit of a vehicle. The wake-up call sustaining control method of this application will now be described using the wake-up call sustaining control module as the executing entity.

[0029] Please see Figure 2 , Figure 2 A schematic flowchart of a network wake-up sustaining control method according to an embodiment of this application is shown. Figure 2 As shown, the Wake-up on the network maintenance method may include steps S110 to S140.

[0030] Step S110: Receive a Wake-up Request initiated by the application component through a general interface, wherein the Wake-up Request carries general interface parameters provided by the application component.

[0031] During the product design phase, the Wake-on-LAN (WLAN) maintenance control module can collect all WLAN maintenance requirements and related information for the vehicle. During software initialization, the WLAN maintenance control module can register application components (i.e., functional modules) with WLAN maintenance requirements. Specifically, application components can register with the WLAN maintenance control module based on their identification information (i.e., APPID). After registration, the WLAN maintenance control module can query the identification information (i.e., APPID) of the registered application components.

[0032] When an application component requires Wake-on-LAN maintenance, it can request a Wake-on-LAN maintenance request from the Wake-on-LAN maintenance control module via a generic interface, and fill in the relevant generic interface parameters in the Wake-on-LAN maintenance request according to the generic interface parameter specification (as shown in Table 1). The Wake-on-LAN maintenance control module can receive Wake-on-LAN maintenance requests initiated by application components through the generic interface.

[0033] Each Wake-on-LAN sustain request carries common interface parameters provided by the corresponding application component. As shown in Table 1, the common interface parameters may include the application component's identification information (i.e., APPID), the network type requested by the application component (i.e., NetType), the duration of the Wake-on-LAN sustain request (i.e., AwakeTime), the application component's functional level (i.e., AwakeLevel), and the source application component associated with the application component's function (i.e., SourceAPPID), etc.

[0034] In some embodiments, after receiving a Wake-on-LAN (WLAN) sustain request initiated by an application component through a generic interface, wherein the WLAN sustain request carries generic interface parameters provided by the application component, it can be detected whether the generic interface parameters meet the interface parameter specification of the generic interface. If the generic interface parameters meet the interface parameter specification, proceed to step S120: based on the generic interface parameters, detect whether the WLAN sustain request meets the functional associativity requirements. If the generic interface parameters do not meet the interface parameter specification, refuse to respond to the WLAN sustain request.

[0035] As shown in Table 1, the interface parameter specifications of a general interface can be determined based on the interface function specifications of the general interface. If the general interface parameters provided by the application component include all the input parameters of the general interface, then the general interface parameters satisfy the interface parameter specifications of the general interface. If the general interface parameters provided by the application component are missing one of the input parameters of the general interface, then the general interface parameters do not satisfy the interface parameter specifications of the general interface.

[0036] The network wake-up maintenance control module will only actively respond to the network wake-up maintenance request of the application component if the general interface parameters provided by the application component meet the interface parameter specification of the general interface and satisfy at least one of the three requirements: legality, time rationality, and functional relevance (see steps S110 to S140, S210 to S250, and S310 to S360). Otherwise, the network wake-up maintenance control module will refuse to respond (i.e., respond negatively) to the network wake-up maintenance request of the application component.

[0037] In this embodiment of the application, by verifying the general interface parameters provided by the application components, the efficiency and accuracy of subsequent multi-dimensional arbitration (at least one of legality requirements, time reasonableness requirements, and functional relevance) can be improved, ensuring the stability and robustness of Wake-up Network (WRN) maintenance.

[0038] Step S120: Based on the general interface parameters, detect whether the Wake-up Persistence Request meets the functional relevance requirements.

[0039] Please see Figure 3 , Figure 3 A flowchart illustrating step S120 provided in an embodiment of this application is shown. Figure 3 As shown, step S120 may include steps S121 to S123.

[0040] Step S121: Based on the general interface parameters, determine the functional level (i.e., AwakeLevel) of the application component.

[0041] If an application component has associated application components, the application component of this application can request a Wake-on-LAN (WLAN) sustaining function at different levels. Considering that when an application component has associated application components, the WLAN sustaining request initiated by the application component may involve those associated application components, this application defines the function levels as a first level (i.e., Level 1) and a second level (i.e., Level 2). This application defines an application component that requests WLAN sustaining due to its own functional requirements as a first-level application component, and the request issued by a first-level application component is a first-level WLAN sustaining request. This application defines an application component that requests WLAN sustaining to cooperate with other application components as a second-level application component, and the request issued by a second-level application component is a second-level WLAN sustaining request.

[0042] When an application component's functional level is Level 2, its source application component is indicated by its identifier (SourceAPPID). When an application component's functional level is Level 1, the position of the source application component in the general interface parameters can be filled with 0, indicating that the application component has no source application component.

[0043] As an example, please refer to Figure 4 , Figure 4 This diagram illustrates the functional relationships between multiple application components provided in an exemplary embodiment of this application. Assume the scenario is a user remotely operating the air conditioning for heating via a mobile phone during winter. The remote control module (RC) responds to the user's remote operation, executes control, and maintains wake-up; the RC request is a first-level wake-up maintenance request. The vehicle control module (VCU) responds to the RC request, powers on the vehicle's high voltage, and maintains wake-up; the VCU request is a second-level wake-up maintenance request. The air conditioning control module (HVAC) responds to the RC request, heats the vehicle interior, and maintains wake-up; the HVAC request is a second-level wake-up maintenance request. The HVAC module responds to the VCU request, heats the battery, and maintains wake-up; the HVAC request is a second-level wake-up maintenance request. That is, in this example, the functional hierarchy of each application component and the source application component are shown in Table 2.

[0044] Table 2

[0045] Application Components Functional hierarchy of application components Source of application components RC AwakeLevel = Level1 SourceAPPID = 0 (None) VCU AwakeLevel = Level2 SourceAPPID=RC HVAC AwakeLevel = Level2 SourceAPPID=RC HVAC AwakeLevel = Level2 SourceAPPID=VCU

[0046] In some embodiments, when the source application component has a Wake-on-LAN (WLAN) sustain request, it is determined that the WLAN sustain request of the application component meets the functional associativity requirement; when the source application component does not have a WLAN sustain request, it is determined that the WLAN sustain request of the application component does not meet the functional associativity requirement. That is, as... Figure 4As shown, a Level 2 wake-up sustain request can only be effective if there is a wake-up sustain request in the associated Level 1.

[0047] Step S122: If it is determined that the application component has an associated application based on the functional classification of the application component, determine the source application component (i.e., SourceAPPID) that is functionally associated with the application component.

[0048] After determining the functional level (i.e., AwakeLevel) of the application component based on the general interface parameters, it can be determined whether the application component has an associated application. If the functional level of the application component is Level 1, it can be determined that the application component has no associated application; if the functional level of the application component is Level 2, it can be determined that the application component has an associated application. As shown in Table 2, RC's AwakeLevel = Level 1, RC's SourceAPPID = 0, RC has no associated application. VCU's AwakeLevel = Level 2, VCU's SourceAPPID = RC, VCU has an associated application RC, and the source application component associated with the VCU's function is RC.

[0049] Step S123: Based on the source application component, detect whether the Wake-on-LAN maintenance request meets the functional relevance requirements.

[0050] It can determine whether the source application component has a Wake-on-LAN maintenance request; if the source application component has a Wake-on-LAN maintenance request, it can determine that the application component's Wake-on-LAN maintenance request meets the functional relevance requirements; if the source application component does not have a Wake-on-LAN maintenance request, it can determine that the application component's Wake-on-LAN maintenance request does not meet the functional relevance requirements.

[0051] In some embodiments, when the Wake-on-LAN (WLAN) sustain request of the source application component stops, WLAN sustain requests from all application components associated with the function of the source application component are refused; the WLAN sustain state of all application components associated with the function of the source application component is terminated, that is, the network state of all application components associated with the function of the source application component is switched to a dormant state. In other words, as... Figure 4 As shown, if the Level 1 wake-up maintenance request stops (no new request is made when the request time arrives), then all Level 2 wake-up maintenance requests associated with it will be negatively responded to by the wake-up maintenance control module (Result = 6: Negative Response by SourceAPPID). At this time, the wake-up maintenance control module will end the wake-up maintenance state of all Level 2 requests currently associated with the Level 1 wake-up maintenance request.

[0052] like Figure 4 As shown, the "functional correlation" arbitration logic of this application, through a tree-structured management method, can effectively control the network wake-up maintenance requests of each functional level, thereby effectively preventing network problems caused by design defects or other reasons.

[0053] Step S130: When the Wake-on-LAN sustain request meets the functional associativity requirements, respond to the Wake-on-LAN sustain request.

[0054] When the Wake-on-LAN maintenance request meets the functional associativity requirements, the Wake-on-LAN maintenance control module can respond to the Wake-on-LAN maintenance request and maintain the network requested by the Wake-on-LAN maintenance request.

[0055] Step S140: If the Wake-on-LAN sustain request does not meet the functional associativity requirements, refuse to respond to the Wake-on-LAN sustain request.

[0056] When the Wake-on-LAN maintenance request does not meet the functional associativity requirements, the Wake-on-LAN maintenance control module may refuse to respond to the Wake-on-LAN maintenance request and control the network requested by the Wake-on-LAN maintenance request to remain in sleep mode.

[0057] In some embodiments, wake-up maintenance between different networks operates in a union manner. For example, assuming that there are wake-up maintenance requests from both the charging network and the vehicle network responding simultaneously, the wake-up maintenance control module can ultimately process the request to wake up the vehicle network.

[0058] Steps S110 to S120 have the following technical effects: Based on the general interface, the network wake-up maintenance requests of each application component are arbitrated for functional correlation. The network wake-up maintenance request is responded to when the functional correlation requirements are met, and the network wake-up maintenance request is rejected when the functional correlation requirements are not met. This can effectively prevent the vehicle from running out of power, provide a guarantee for the stability of the whole vehicle system, improve the overall vehicle quality, and optimize the user experience.

[0059] Please see Figure 5 , Figure 5 A flowchart illustrating a network wake-up sustaining control method according to another embodiment of this application is shown. Figure 5 As shown, the Wake-up on the network maintenance method may include steps S210 to S250.

[0060] Step S210: Receive a Wake-on-LAN sustain request initiated by the application component through a general interface, wherein the Wake-on-LAN sustain request carries general interface parameters provided by the application component.

[0061] Step S220: Based on the general interface parameters, detect whether the Wake-up Persistence Request meets the functional associativity requirements (functional associativity arbitration).

[0062] Step S230: Based on the general interface parameters, detect whether the network wake-up sustain request meets the time reasonableness requirements (time reasonableness arbitration).

[0063] In some embodiments, the Wake-on-LAN (WLAN) maintenance control module can determine the WLAN maintenance duration (i.e., AwakeTime) requested by the application component based on the general interface parameters; if the WLAN maintenance duration is greater than or equal to a first duration and less than or equal to a second duration, the WLAN maintenance request is determined to meet the time reasonableness requirements. If the WLAN maintenance duration is less than the first duration or greater than the second duration, the WLAN maintenance request is determined to not meet the time reasonableness requirements.

[0064] The first and second durations can be preset based on the developer's experience and the actual needs of the scenario. For example, the first duration can be set to 1 second and the second duration to 10 minutes, meaning that the minimum duration for each application component to request a Wake-on-LAN maintenance is 1 second, and the maximum duration is 10 minutes. If the requested Wake-on-LAN maintenance duration is less than 1 second or more than 10 minutes, the Wake-on-LAN maintenance control module can determine that the request is invalid and respond negatively (Result = 3: Negative Response by AwakeTime).

[0065] The Wake-on-LAN maintenance control module can acquire information such as the vehicle's current operating mode, battery status, engine status, and network status of each application component. Based on this information, it can adjust the wake-up / sleep state of each network. For example, when the Wake-on-LAN maintenance time reaches its maximum limit (e.g., 40 minutes), the Wake-on-LAN maintenance control module can switch all networks to sleep mode.

[0066] In some embodiments, the Wake-on-LAN sustain control module can obtain the vehicle's current operating mode and battery status; when the vehicle is in standby mode and the battery is independently powered, it determines the total number of times the application component requests Wake-on-LAN; when the total number of requests reaches a threshold, it determines that the Wake-on-LAN sustain request does not meet the time reasonableness requirement; when the total number of requests does not reach the threshold, it determines that the Wake-on-LAN sustain request meets the time reasonableness requirement.

[0067] The number of requests can be preset based on the developer's experience and the actual needs of the scenario. For example, the number of requests can be set to 3, meaning that each application component can only request network wake-up maintenance a maximum of 3 times when the vehicle is in standby mode and the battery is independently powered (i.e., each application component can only request wake-up maintenance for a maximum of 30 minutes). If more than 3 requests are made, the network wake-up maintenance control module will respond negatively (Result = 4: Negative Response by RequestFrequently).

[0068] In some embodiments, when the vehicle is in standby mode and the battery is independently powered, the Wake-on Maintenance control module can determine the total duration of all application components of the vehicle requesting Wake-on Maintenance; when the total duration reaches the maximum limit, it refuses to respond to all current Wake-on Maintenance requests of the vehicle.

[0069] The maximum time limit can be preset based on the developer's actual experience and the actual needs of the scenario. For example, the maximum time limit can be set to 40 minutes. When the vehicle is in standby mode and the battery is independently powered, if the total duration of all application components requesting network wake-up maintenance reaches 40 minutes, the network wake-up maintenance control module can passively respond to all network wake-up maintenance requests (Result = 5: Negative Response by System Limit) and end all current network wake-up maintenance states, that is, switch all current network states to sleep state.

[0070] In some embodiments, when the vehicle is in non-standby mode, the number of times application components request network wake-up sustain is not limited, nor is the total duration of network wake-up sustain requests from all application components limited.

[0071] In some embodiments, when the vehicle is in standby mode and the current power battery is continuously charging the battery (i.e., the battery is in a charging state, such as when a new energy vehicle is plugged in for charging), the number of network wake-up maintenance requests of the application components is not limited, nor is the total duration of network wake-up maintenance requests from all application components limited.

[0072] In some embodiments, when the vehicle is in standby mode and the current engine is continuously running (such as remote engine ignition in a gasoline vehicle), the number of times the application component makes a network wake-up maintenance request is not limited, nor is the total duration of all application components requesting network wake-up maintenance.

[0073] It is understandable that time-reasonableness arbitration and functional relevance arbitration can be performed in parallel or sequentially. Since a positive response will only be given to a Wake-up Maintenance request if both time-reasonableness and functional relevance requirements are met, it is preferable to use a sequential execution of time-reasonableness arbitration and functional relevance arbitration for multi-dimensional arbitration.

[0074] Step S240: When the Wake-up Request meets the functional relevance requirement and the time reasonableness requirement, respond to the Wake-up Request.

[0075] Step S250: If the Wake-up sustain request does not meet the functional relevance requirement or the time reasonableness requirement, refuse to respond to the Wake-up sustain request.

[0076] Steps S210 to S250 have the following technical effects: Based on the general interface, the network wake-up maintenance requests of each application component are arbitrated for functional correlation and time reasonableness. The network wake-up maintenance request is responded to if it meets the functional correlation and time reasonableness requirements. The network wake-up maintenance request is rejected if it does not meet the functional correlation or time reasonableness requirements. This can effectively prevent the vehicle from running out of power, ensure the stability of the whole vehicle system, improve the overall vehicle quality, and optimize the user experience.

[0077] Please see Figure 6 , Figure 6 A flowchart illustrating a network wake-up sustaining control method according to another embodiment of this application is shown. Figure 6 As shown, the Wake-up on the network maintenance method may include steps S310 to S360.

[0078] Step S310: Receive a Wake-on-LAN sustain request initiated by the application component through a general interface, wherein the Wake-on-LAN sustain request carries general interface parameters provided by the application component.

[0079] Step S320: Based on the general interface parameters, detect whether the Wake-up Persistence Request meets the functional correlation requirements (functional correlation arbitration).

[0080] Step S330: Based on the general interface parameters, detect whether the network wake-up sustain request meets the time reasonableness requirements (time reasonableness arbitration).

[0081] Step S340: Based on the general interface parameters, detect whether the Wake-up Persistence Request meets the legality requirements (legality arbitration).

[0082] In some embodiments, the Wake-on-LAN sustain control module can determine the identification information (i.e., APPID) of the application component and the network type (i.e., NetType) requested by the application component based on the general interface parameters; and detect whether the Wake-on-LAN sustain request meets the legality requirements based on the identification information and the network type.

[0083] In some embodiments, the Wake-on-LAN maintenance control module can detect whether the identification information (i.e., APPID) of the application component is registered; detect whether the network type matches the functional requirements of the application component; when the identification information is registered and the network type matches the functional requirements of the application component, determine that the Wake-on-LAN maintenance request meets the legality requirements; when the identification information is unregistered or the network type does not match the functional requirements of the application component, determine that the Wake-on-LAN maintenance request does not meet the legality requirements.

[0084] Specifically, the Wake-on-LAN maintenance control module can detect whether the application component's identification information (i.e., APPID) is registered. If the application component's identification information (i.e., APPID) is registered, the application component is determined to be a legitimate application component; if the application component's identification information (i.e., APPID) is not registered, the application component is determined to be an illegitimate application component. Only application components that have registered with the Wake-on-LAN maintenance control module can initiate Wake-on-LAN maintenance requests using the general interface. Application components that have not registered with the Wake-on-LAN maintenance control module will have their requests treated as illegitimate by the Wake-on-LAN maintenance control module and will receive a negative response (Result = 1:).

[0085] P1CN-GQJT240216, 2024P0447CN1Negative Response by APPID).

[0086] Application components can request wake-up from corresponding networks (e.g., charging networks or vehicle networks) according to their functional requirements. The network types corresponding to all network wake-up maintenance requests for the vehicle are pre-written into the storage area of ​​the network wake-up maintenance control module; that is, the network types corresponding to all network wake-up maintenance requests for the vehicle are defined values. In some embodiments, the network wake-up maintenance control module can detect whether the parameter (i.e., the NetType value) corresponding to the network type requested by the application component is a defined value. If the parameter is a defined value, it detects whether the network type (i.e., NetType) requested by the application component matches the functional requirements of the application component. If the parameter is an undefined value, it determines that the application component's network wake-up maintenance request is an illegal request and responds negatively (Result = 2: Negative Response by NetType).

[0087] In some embodiments, the Wake-on-LAN maintenance control module can directly detect whether the network type (i.e., NetType) requested by the application component matches the functional requirements of the application component (i.e., the application component's requirement information collected during the product design phase); when the network type requested by the application component matches the functional requirements of the application component, it is determined that the Wake-on-LAN maintenance request meets the legality requirements; when the network type requested by the application component does not match the functional requirements of the application component, it is determined that the Wake-on-LAN maintenance request does not meet the legality requirements, and the application component's Wake-on-LAN maintenance request is determined to be an illegal request and a negative response is given (Result = 2: Negative Response by NetType).

[0088] It is understandable that the three arbitration operations—legality arbitration, time reasonableness arbitration, and functional relevance arbitration—can be performed in parallel or sequentially. Since a positive response will only be given to a Wake-up Maintenance request if it simultaneously meets the requirements of legitimacy, time reasonableness, and functional relevance, it is preferable to adopt a multi-dimensional arbitration approach by sequentially executing the three arbitration operations.

[0089] Step S350: When the Wake-up sustain request meets the legality requirement, the time reasonableness requirement, and the functional relevance requirement, respond to the Wake-up sustain request.

[0090] Step S360: If the Wake-up sustain request does not meet the functional relevance requirement, the time reasonableness requirement, or the legality requirement, refuse to respond to the Wake-up sustain request.

[0091] Steps S310 to S360 have the following technical effects: They provide a general interface to obtain network wake-up maintenance requests from various application components (i.e., functional modules), and uniformly arbitrate and manage the network wake-up maintenance requirements of each application component (i.e., functional module) in the central computing unit from multiple dimensions (e.g., request legality, timing rationality, and functional relevance). Under the premise of satisfying the network wake-up maintenance requirements of each application component, they can effectively solve the problem of the vehicle network not sleeping due to imperfect module functional design or software defects in the central computing unit itself. This can effectively prevent vehicle battery drain, ensure the stability of the entire vehicle system, improve overall vehicle quality, and optimize user experience. Specifically, this application changes the current practice where the network wake-up maintenance control module prioritizes satisfying the functional modules (the control of network maintenance rests with the functional modules) to allowing the network wake-up maintenance control module to determine the control of network wake-up maintenance, giving it greater discretion in maintaining network stability.

[0092] Please see Figure 7 , Figure 7 A schematic diagram of the structure of the Wake-on-LAN (WLAN) maintenance control device provided in an embodiment of this application is shown. The WLAN maintenance control device 200 can be applied to a vehicle; specifically, it can be deployed in the WLAN maintenance control module of the vehicle's central processing unit. The WLAN maintenance control device 200 includes a request receiving module 210, a functional affinity arbitration module 220, an active response module 230, and a passive response module 240. Specifically: the request receiving module 210 receives WLAN maintenance requests initiated by application components through a general interface, the WLAN maintenance request carrying general interface parameters provided by the application component. The functional affinity arbitration module 220 detects whether the WLAN maintenance request meets functional affinity requirements based on the general interface parameters. The active response module 230 responds to the WLAN maintenance request when it meets the functional affinity requirements. The passive response module 240 refuses to respond to the WLAN maintenance request when it does not meet the functional affinity requirements.

[0093] In some embodiments, the functional association arbitration module 220 is further configured to: determine the functional level of the application component based on the general interface parameters; if it is determined that the application component has an associated application based on the functional level of the application component, determine the source application component that is functionally associated with the application component; and detect whether the Wake-on-LAN maintenance request meets the functional association requirements based on the source application component.

[0094] In some embodiments, the functional association arbitration module 220 is further configured to: determine that the Wake-on-LAN maintenance request of the application component satisfies the functional association requirement when the source application component has a Wake-on-LAN maintenance request; and determine that the Wake-on-LAN maintenance request of the application component does not satisfy the functional association requirement when the source application component does not have a Wake-on-LAN maintenance request.

[0095] In some embodiments, the functional association arbitration module 220 is further configured to: refuse to respond to the network wake-up maintenance requests of all application components functionally associated with the source application component when the network wake-up maintenance request of the source application component stops; and terminate the network wake-up maintenance state of all application components functionally associated with the source application component.

[0096] In some embodiments, the Wake-on-LAN maintenance control device 200 further includes a time reasonableness arbitration module. The time reasonableness arbitration module is used to detect whether the Wake-on-LAN maintenance request meets the time reasonableness requirements based on the general interface parameters. The positive response module 230 is further used to respond to the Wake-on-LAN maintenance request when the Wake-on-LAN maintenance request meets both the functional associativity requirements and the time reasonableness requirements. The negative response module 240 is further used to refuse to respond to the Wake-on-LAN maintenance request when the Wake-on-LAN maintenance request does not meet the time reasonableness requirements.

[0097] In some embodiments, the time rationality arbitration module is further configured to: determine the network wake-up duration requested by the application component based on the general interface parameters; determine that the network wake-up duration meets the time rationality requirements when the network wake-up duration is greater than or equal to a first duration and less than or equal to a second duration; and determine that the network wake-up duration does not meet the time rationality requirements when the network wake-up duration is less than the first duration or greater than the second duration.

[0098] In some embodiments, the time rationality arbitration module is further configured to: obtain the vehicle's current operating mode and battery status; when the vehicle is in standby mode and the battery is independently powered, determine the total number of times the application component requests network wake-up; and when the total number reaches a threshold, determine that the network wake-up maintenance request does not meet the time rationality requirements.

[0099] In some embodiments, the time rationality arbitration module is further configured to: determine the total duration for all application components of the vehicle to request wake-up maintenance when the vehicle is in standby mode and the battery is independently powered. The negative response module 240 is further configured to: refuse to respond to all current wake-up maintenance requests of the vehicle when the total duration reaches a maximum limit.

[0100] In some embodiments, the Wake-on-LAN maintenance control device 200 further includes a legitimacy arbitration module. The legitimacy arbitration module is used to detect whether the Wake-on-LAN maintenance request meets the legitimacy requirements based on the general interface parameters. The positive response module 230 is further used to respond to the Wake-on-LAN maintenance request when it meets the legitimacy requirements, the time reasonableness requirements, and the functional relevance requirements. The negative response module 240 is further used to refuse to respond to the Wake-on-LAN maintenance request when it does not meet the legitimacy requirements.

[0101] In some embodiments, the legitimacy arbitration module is further configured to: determine the identification information of the application component and the network type requested by the application component based on the general interface parameters; and detect whether the network wake-up sustain request meets the legitimacy requirements based on the identification information and the network type.

[0102] In some embodiments, the legitimacy arbitration module is further configured to: detect whether the identification information is registered identification information; detect whether the network type matches the functional requirements of the application component; when the identification information is registered identification information and the network type matches the functional requirements of the application component, determine that the Wake-up Maintenance request meets the legitimacy requirements; when the identification information is unregistered identification information or when the network type does not match the functional requirements of the application component, determine that the Wake-up Maintenance request does not meet the legitimacy requirements.

[0103] In some embodiments, the request receiving module 210 is further configured to detect whether the general interface parameters meet the interface parameter specification of the general interface. The functional assimilation arbitration module 220 is further configured to, when the general interface parameters meet the interface parameter specification, detect whether the Wake-on-LAN sustain request meets the functional assimilation requirements based on the general interface parameters. The negative response module 240 is further configured to refuse to respond to the Wake-on-LAN sustain request when the general interface parameters do not meet the interface parameter specification.

[0104] Those skilled in the art will clearly understand that the apparatus provided in the embodiments of this application can implement the methods provided in the embodiments of this application. The specific working process of the described apparatus and modules can be found in the corresponding processes of the methods in the embodiments of this application, and will not be repeated here.

[0105] In the embodiments provided in this application, the coupling, direct coupling, or communication connection between the modules shown or discussed may be indirect coupling or communication coupling through some interfaces, devices, or modules, and may be electrical, mechanical, or other forms. The embodiments of this application do not impose specific limitations on this.

[0106] Furthermore, the functional modules in the embodiments of this application can be integrated into one processing module, or each module can exist physically separately, or two or more modules can be integrated into one module. The integrated modules described above can be implemented in hardware or as software functional modules.

[0107] Please see Figure 8 , Figure 8 A schematic diagram of the structure of a vehicle provided in an embodiment of this application is shown. The vehicle 300 may include a memory 310 and a processor 320. The memory 310 stores an application program that is configured to cause the processor 320 to execute the method provided in the embodiment of this application when invoked by the processor 320.

[0108] The processor 320 may include one or more processing cores. The processor 320 uses various interfaces and lines to connect to various parts of the vehicle 300, and is used to run or execute instructions, programs, code sets or instruction sets stored in the memory 310, as well as to call and run or execute data stored in the memory 310, and perform various functions and process data of the vehicle 300.

[0109] The processor 320 can be implemented using at least one of the following hardware forms: Digital Signal Processing (DSP), Field-Programmable Gate Array (FPGA), and Programmable Logic Array (PLA). The processor 320 can integrate one or a combination of several of the following: Central Processing Unit (CPU), Graphics Processing Unit (GPU), and modem. The CPU primarily handles the operating system, user interface, and applications; the GPU is responsible for rendering and drawing the displayed content; and the modem handles wireless communication. It is understood that the modem can also be implemented separately as a communication chip, without being integrated into the processor 320.

[0110] The memory 310 may include random access memory (RAM) or read-only memory (ROM). The memory 310 can be used to store instructions, programs, code, code sets, or instruction sets. The memory 310 may include a program storage area and a data storage area. The program storage area may store instructions for implementing an operating system, instructions for implementing at least one function, instructions for implementing the various method embodiments described above, etc. The data storage area may store data created by the vehicle 300 during use.

[0111] This application also provides a computer-readable storage medium. The computer-readable storage medium stores program code configured to cause the processor to execute the method provided in this application embodiment when invoked by a processor. The computer-readable storage medium may be an electronic storage device such as flash memory, electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), hard disk, or ROM.

[0112] In some embodiments, the computer-readable storage medium includes a non-volatile computer-readable storage medium (Non-TCRSM). The computer-readable storage medium has storage space for program code that performs any of the method steps described above. This program code can be read from or written to one or more computer program products. The program code may be compressed in an appropriate form.

[0113] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application.

Claims

1. A method for maintaining network wake-up control, characterized in that, include: Receive a Wake-up sustain request initiated by an application component through a general interface, wherein the Wake-up sustain request carries general interface parameters provided by the application component; Based on the general interface parameters, it is determined whether the network wake-up sustain request meets the functional correlation requirements; The network wake-up sustain request is responded to when the functional associativity requirement is met; If the Wake-on-LAN sustain request does not meet the functional associativity requirements, the Wake-on-LAN sustain request will not be responded to.

2. The method according to claim 1, characterized in that, The step of detecting whether the Wake-up Persistence Request meets the functional relevance requirements based on the general interface parameters includes: Based on the general interface parameters, the functional hierarchy of the application components is determined; If it is determined that the application component has associated applications based on the functional classification of the application component, the source application component associated with the function of the application component is determined. Based on the source application component, it is determined whether the Wake-on-LAN maintenance request meets the functional relevance requirements.

3. The method according to claim 2, characterized in that, The step of detecting whether the Wake-on-LAN sustain request meets the functional relevance requirements based on the source application component includes: When the source application component has a Wake-on-LAN sustain request, it is determined that the Wake-on-LAN sustain request of the application component meets the functional associativity requirements; When the source application component does not have a Wake-on-LAN maintenance request, it is determined that the application component's Wake-on-LAN maintenance request does not meet the functional associativity requirements.

4. The method according to claim 2, characterized in that, The method further includes: When the Wake-on sustain request of the source application component stops, Wake-on sustain requests of all application components associated with the function of the source application component are refused. End the wake-up maintenance state of all application components associated with the source application component's functionality.

5. The method according to any one of claims 1-4, characterized in that, The method further includes: Based on the general interface parameters, it is detected whether the network wake-up sustain request meets the time reasonableness requirements; The network wake-up sustain request is responded to when it meets both the functional relevance requirement and the time reasonableness requirement. If the Wake-up sustain request does not meet the time reasonableness requirement, the Wake-up sustain request will not be responded to.

6. The method according to claim 5, characterized in that, The step of detecting whether the Wake-up Network (WRN) sustain request meets the time reasonableness requirements based on the general interface parameters includes: Based on the general interface parameters, determine the network wake-up duration requested by the application component; When the duration of the Wake-on-LAN maintenance is greater than or equal to the first duration and less than or equal to the second duration, it is determined that the Wake-on-LAN maintenance request meets the time reasonableness requirement; If the duration of the Wake-on-LAN request is less than the first duration or greater than the second duration, it is determined that the Wake-on-LAN request does not meet the time reasonableness requirements.

7. The method according to claim 5, characterized in that, The step of detecting whether the network wake-up sustain request meets the time reasonableness requirements based on the general interface parameters further includes: Obtain the vehicle's current operating mode and battery status; When the vehicle is in standby mode and the battery is independently powered, determine the total number of times the application component requests network wake-up; When the total number of attempts reaches the threshold, it is determined that the network wake-up maintenance request does not meet the time reasonableness requirement.

8. The method according to claim 7, characterized in that, The method further includes: When the vehicle is in standby mode and the battery is independently powered, determine the total duration for all application components of the vehicle to request wake-up from the network. When the total duration reaches the maximum time limit, refuse to respond to all current network wake-up maintenance requests of the vehicle.

9. The method according to claim 5, characterized in that, The method further includes: Based on the general interface parameters, it is detected whether the Wake-up Persistence Request meets the legality requirements; The network wake-up sustain request is responded to when it meets the legality requirements, the time reasonableness requirements, and the functional relevance requirements. If the Wake-up sustain request does not meet the validity requirements, the Wake-up sustain request will not be responded to.

10. The method according to claim 9, characterized in that, The step of detecting whether the Wake-up Persistence Request meets the legality requirements based on the general interface parameters includes: Based on the general interface parameters, the identification information of the application component and the network type requested by the application component are determined; Based on the identification information and the network type, it is determined whether the Wake-up Keeping Request meets the legality requirements.

11. The method according to claim 10, characterized in that, The step of detecting whether the Wake-up Keeping Request meets the legality requirements based on the identification information and the network type includes: Detect whether the identification information is registered identification information; Detect whether the network type matches the functional requirements of the application component; When the identification information is registered identification information and the network type matches the functional requirements of the application component, it is determined that the network wake-up maintenance request meets the legality requirements. If the identification information is unregistered or if the network type does not match the functional requirements of the application component, the Wake-Up Call request is determined to be invalid.

12. The method according to claim 1, characterized in that, After receiving a Wake-on-LAN sustain request initiated by an application component through a generic interface, wherein the Wake-on-LAN sustain request carries generic interface parameters provided by the application component, the method further includes: Check whether the general interface parameters meet the interface parameter specifications of the general interface; When the general interface parameters meet the interface parameter specification, based on the general interface parameters, it is detected whether the network wake-up sustain request meets the functional correlation requirements; If the general interface parameters do not meet the interface parameter specifications, the network wake-up sustain request will not be responded to.

13. A network wake-up sustaining control device, characterized in that, include: The request receiving module is used to receive a Wake-on-LAN sustain request initiated by the application component through a general interface, wherein the Wake-on-LAN sustain request carries the general interface parameters provided by the application component. The functional correlation arbitration module is used to detect whether the network wake-up sustain request meets the functional correlation requirements based on the general interface parameters. An active response module is used to respond to the Wake-up Maintenance request when the Wake-up Maintenance request meets the functional associativity requirements; The negative response module is used to refuse to respond to the Wake-Up Maintenance Request when the Wake-Up Maintenance Request does not meet the functional associativity requirements.

14. A vehicle, characterized in that, include: A memory and a processor, wherein an application program is stored in the memory, the application program being invoked by the processor to cause the processor to perform the method as described in any one of claims 1-12.

15. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores program code that, when invoked by a processor, causes the processor to perform the method as described in any one of claims 1-12.

Images