Instrument state management method and device, computer equipment and storage medium

Abstract

The invention relates to the technical field of vehicle machine systems, and discloses an instrument state management method and device, computer equipment and a storage medium, and the instrument state management method comprises the steps: responding to a registration request of vehicle instrument middleware, and registering the instrument middleware in an instrument system; analyzing based on the state data of the vehicle to obtain the driving state of the vehicle; determining a target operation state matched with the driving state according to the state condition; and in response to a switching request received by the instrument middleware, controlling the instrument system to be switched to the target running state. According to the invention, a registration mechanism is introduced, and the instrument middleware can be registered in the instrument system, so that the operation state of the instrument system can be managed through the instrument middleware, the complexity of an instrument project is reduced, the potential safety hazard is reduced, and the use experience of a user is improved.

Description

Technical Field

[0001] The present invention relates to the technical field of vehicle computer systems, and in particular to an instrument status management method, device, computer equipment and storage medium. Background Art

[0002] With the development of new energy vehicles, various models are iterating one after another, and there are usually large differences between the architectural designs of vehicle instruments. This has led to rapid iterations of instrument power management solutions based on various SOC (System on Chip) solutions, and there are large differences between each management solution.

[0003] However, with the iteration of vehicle models and the increase in projects, this instrument power management without a unified architecture will greatly increase the complexity of each instrument project, bring extremely huge costs for the subsequent maintenance of the project and the development of new vehicle model instruments, and will also lead to further reduction in project stability. For example, it will cause the instrument's sleep wake-up signal to be lost and unable to wake up the instrument, thereby causing safety hazards, reduced user experience and shortened battery life. Summary of the invention

[0004] In view of this, the present invention provides an instrument status management method, apparatus, computer equipment and storage medium to solve the problem that instrument power management schemes of SOC schemes are quite different.

[0005] In a first aspect, the present invention provides an instrument status management method, the method comprising:

[0006] In response to a registration request of the vehicle instrument middleware, registering the instrument middleware in the instrument system;

[0007] Analyze the vehicle's status data to obtain the vehicle's driving status;

[0008] Determine a target operating state that matches the driving state according to the state condition;

[0009] In response to the switching request received by the instrument middleware, the instrument system is controlled to switch to the target operating state.

[0010] In an optional implementation, in response to a registration request of the vehicle instrument middleware, registering the instrument middleware in the instrument system includes:

[0011] After the vehicle is started, the instrument middleware is started;

[0012] Generate a registration request based on the identification information of the middleware;

[0013] A registration request is sent to a power management unit of the instrument system to register the instrument middleware in the instrument system according to the registration request.

[0014] In the embodiment of the present invention, considering that with the iteration of the vehicle system, the instrument system and the SOC are not static, and new business modules may be added or replaced, the instrument middleware can be registered after each vehicle start. At the same time, module reuse is achieved without changing the power management module, which solves the problem of power management reuse between different SOC solutions, greatly reduces the amount of code, improves the reuse rate, and realizes the platformization of power management.

[0015] In an optional embodiment, the method further includes:

[0016] Acquire operation status information corresponding to the instrument system, wherein the operation status information includes at least one operation status;

[0017] At least one preset operating state matching the operating state information is determined in the preset operating states to obtain an operating state collection.

[0018] In the embodiment of the present invention, the operation status information corresponding to the instrument system can be obtained, and each operation status in the operation status information can be classified to achieve abstract unification of the operation status, thereby facilitating the management of the operation status of the instrument system.

[0019] In an optional implementation, the operating state collection includes at least one preset operating state of: initialization state, standby state, startup animation playing state, working state, shutdown animation playing state, and sleep state.

[0020] In the embodiment of the present invention, the operation status information corresponding to the instrument system can be obtained, and each operation status in the operation status information can be classified to achieve abstract unification of the operation status, thereby facilitating the management of the operation status of the instrument system.

[0021] In an optional implementation, determining a target operating state that matches the driving state according to the state condition includes:

[0022] Obtaining a control signal fed back by a microcontroller unit of the vehicle, wherein the control signal is used to control the driving state of the vehicle;

[0023] Based on the state condition, a target operating state corresponding to the control signal in the operating state collection is determined.

[0024] In the embodiment of the present invention, on the basis of abstracting and unifying the operating state of the instrument system, the operating state of the instrument can be switched based on the control signal indication of the vehicle, thereby ensuring the independence of the power management logic of the instrument state and the SOC chip solution, reducing the coupling degree between the instrument power management core module and the instrument middleware, reducing the differences in power management modules of different SOC solutions, and greatly reducing the probability of the vehicle computer having a black screen and being unable to start, and the vehicle being unable to ignite due to dark current feeding.

[0025] In an optional implementation, the target operating state includes: a wake-up state;

[0026] In response to the switching request received by the instrument middleware, controlling the instrument system to switch to the target operating state includes:

[0027] After receiving a switching request sent by a microcontroller unit of the vehicle, waking up a driving unit of the vehicle;

[0028] Based on the drive unit, a switching request is sent to the instrument system;

[0029] When the instrument middleware meets the wake-up condition, the instrument middleware is switched to the wake-up state.

[0030] In an embodiment of the present invention, a switching request can be sent by the vehicle's microcontroller unit so that the power management unit can respond to the switching request and switch the operating state of the instrument system, thereby ensuring that the power management logic of the instrument sleep and wake-up is independent of the SOC chip solution, reducing the coupling degree between the instrument power management core module and the instrument middleware, reducing the differences in power management modules of different SOC solutions, and greatly reducing the probability of the vehicle computer having a black screen and being unable to start, and the vehicle being unable to ignite due to dark current feeding.

[0031] In an optional implementation, the target operating state includes: a dormant state;

[0032] In response to the switching request received by the instrument middleware, controlling the instrument system to switch to the target operating state includes:

[0033] When the meter middleware meets the sleep condition, in response to a switching request sent by the micro control unit of the vehicle, the meter middleware is switched to the sleep state, and the system-on-chip (SOC) of the vehicle is switched to the sleep state.

[0034] In an embodiment of the present invention, a switching request can be sent by the vehicle's microcontroller unit so that the power management unit can respond to the switching request and switch the operating state of the instrument system, thereby ensuring that the power management logic of the instrument sleep and wake-up is independent of the SOC chip solution, reducing the coupling degree between the instrument power management core module and the instrument middleware, reducing the differences in power management modules of different SOC solutions, and greatly reducing the probability of the vehicle computer having a black screen and being unable to start, and the vehicle being unable to ignite due to dark current feeding.

[0035] In a second aspect, the present invention provides an instrument status management device, the device comprising:

[0036] A registration module, for registering the instrument middleware in the instrument system in response to a registration request of the vehicle instrument middleware;

[0037] An analysis module, used to analyze based on the vehicle status data to obtain the driving status of the vehicle;

[0038] A determination module, used to determine a target operating state matching the driving state according to the state condition;

[0039] The control module is used to control the instrument system to switch to a target operating state in response to a switching request received by the instrument middleware.

[0040] In a third aspect, the present invention provides a computer device, comprising: a memory and a processor, the memory and the processor are communicatively connected to each other, the memory stores computer instructions, and the processor executes the instrument status management method of the first aspect or any corresponding embodiment thereof by executing the computer instructions.

[0041] In a fourth aspect, the present invention provides a computer-readable storage medium having computer instructions stored thereon, the computer instructions being used to enable a computer to execute the instrument status management method of the first aspect or any corresponding embodiment thereof.

[0042] In a fifth aspect, the present invention provides a computer program product, comprising computer instructions, wherein the computer instructions are used to enable a computer to execute the instrument status management method of the first aspect or any corresponding embodiment thereof. BRIEF DESCRIPTION OF THE DRAWINGS

[0043] In order to more clearly illustrate the specific implementation methods of the present invention or the technical solutions in the prior art, the drawings required for use in the specific implementation methods or the description of the prior art will be briefly introduced below. Obviously, the drawings described below are some implementation methods of the present invention. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying creative work.

[0044] Figure 1 is a flow chart of an instrument status management method according to an embodiment of the present invention;

[0045] Figure 2 is a flow chart of another instrument status management method according to an embodiment of the present invention;

[0046] Figure 3 It is a schematic diagram of registering the instrument middleware in the power management unit;

[0047] Figure 4 is a flow chart of another instrument status management method according to an embodiment of the present invention;

[0048] Figure 5 It is a schematic diagram for switching the operating state of the instrument system;

[0049] Figure 6 It is a flowchart of putting the instrument system to sleep or wake up;

[0050] Figure 7 is an architecture diagram of an instrument status management system according to an embodiment of the present invention;

[0051] Figure 8 is a structural block diagram of an instrument status management device according to an embodiment of the present invention;

[0052] Fig. 9 It is a schematic diagram of the hardware structure of a computer device according to an embodiment of the present invention. DETAILED DESCRIPTION

[0053] In order to make the purpose, technical solution and advantages of the embodiments of the present invention clearer, the technical solution in the embodiments of the present invention will be clearly and completely described below in conjunction with the drawings in the embodiments of the present invention. Obviously, the described embodiments are part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative work are within the scope of protection of the present invention.

[0054] In conjunction with the application scenarios on which the execution of the instrument status management method depends, the application scenarios are described here.

[0055] With the development of new energy vehicles, various models are iterating one after another, and there are usually large differences between the architectural designs of vehicle instruments. This has led to rapid iterations of instrument power management solutions based on various SOC (System on Chip) solutions, and there are large differences between each management solution.

[0056] However, with the iteration of vehicle models and the increase in projects, this instrument power management without a unified architecture will greatly increase the complexity of each instrument project, bring extremely huge costs for the subsequent maintenance of the project and the development of new vehicle instrumentation, and will also lead to further reduction in project stability. For example, it will cause the instrument's sleep wake-up signal to be lost and unable to wake up the instrument, thereby causing safety hazards and reduced user experience.

[0057] Based on this, an embodiment of the present invention provides an instrument status management method, which includes: first, responding to a registration request of a vehicle instrument middleware, registering the instrument middleware in the instrument system, then analyzing the vehicle status data to obtain the vehicle's driving status, and determining a target operating status that matches the driving status according to the status conditions. Then, responding to a switching request received by the instrument middleware, the instrument system can be controlled to switch to the target operating status, thereby introducing a registration mechanism, registering the instrument middleware in the instrument system, so that the operating status of the instrument system can be managed through the instrument middleware, reducing the complexity of the instrument project, thereby reducing safety hazards, and improving the user experience.

[0058] According to an embodiment of the present invention, an embodiment of an instrument status management method is provided. It should be noted that the steps shown in the flowchart of the accompanying drawings can be executed in a computer system such as a set of computer executable instructions, and although a logical order is shown in the flowchart, in some cases, the steps shown or described can be executed in an order different from that shown here.

[0059] In this embodiment, a method for managing instrument status is provided, which can be used for the above-mentioned new energy vehicle. Figure 1 is a flow chart of an instrument status management method according to an embodiment of the present invention. Figure 1 As shown, the process includes the following steps:

[0060] Step S101 : registering the instrument middleware in the instrument system in response to a registration request of the vehicle instrument middleware.

[0061] In the embodiment of the present invention, the vehicle instrument middleware may be a component in the instrument system, and the instrument middleware may include communication middleware, system service middleware, and related support tools, etc. Specifically, the communication middleware may be used to efficiently and stably transmit multi-source heterogeneous data between different sensors and computing units of the vehicle, the system service middleware is used to provide an abstraction of the operating system so that upper-layer applications can run across platforms, and the related support tools may be used to improve development efficiency and simplify common development and debugging tasks.

[0062] It should be understood that the vehicle's SOC can manage the operating status of the instrument system by managing the instrument middleware. Therefore, the instrument middleware can be registered in the power management unit of the instrument system, so that the SOC can achieve status management of the entire instrument system by controlling the power management unit.

[0063] Step S102, analyzing the vehicle status data to obtain the vehicle driving status.

[0064] Step S103, determining a target operating state that matches the driving state according to the state condition.

[0065] In the embodiment of the present invention, the vehicle driving state may include a normal driving state, a non-driving state, an ignition-off state, etc. It should be understood that the state of the instrument system may be different when the vehicle is in different driving states. For example, when the vehicle is not in a driving state, the target operating state of the instrument system may be a dormant state, and when the vehicle is started and in a normal driving state, the target operating state of the instrument system may be an awake state.

[0066] Step S104 , in response to the switching request received by the instrument middleware, controlling the instrument system to switch to the target operating state.

[0067] In the embodiment of the present invention, a target operating state matching the above-mentioned driving state may be determined by a microcontroller unit (MCU) in the vehicle, and a switching request for the instrument system may be initiated.

[0068] Specifically, after receiving the switching request, the power management unit registered by the instrument middleware can detect the operating state of the instrument system in response to the switching request, and if the operating state does not match the target operating state indicated by the switching request, the instrument system can be controlled to switch to the target operating state. Here, the middleware and UI display module in the instrument system can be switched to the target operating state.

[0069] For example, if the above-mentioned target operating state is a sleep state, after receiving the switching request, if the power management unit monitors that the operating state of the instrument system is a normal operating state, the middleware and UI display module in the instrument system can be switched to a sleep state, so that the instrument system can enter a low power consumption state to save energy.

[0070] It can be seen from the above description that in the embodiment of the present invention, first, the instrument middleware can be registered in the instrument system in response to the registration request of the vehicle instrument middleware. Next, the vehicle's driving state is analyzed based on the vehicle's state data, and the target operating state that matches the driving state is determined according to the state conditions. Then, in response to the switching request received by the instrument middleware, the instrument system can be controlled to switch to the target operating state, thereby introducing a registration mechanism to register the instrument middleware in the instrument system, so that the operating state of the instrument system can be managed through the instrument middleware, reducing the complexity of the instrument project, thereby reducing safety hazards and improving the user experience.

[0071] In this embodiment, another instrument status management method is provided, which can be used for the above-mentioned new energy vehicle. Figure 2 is a flow chart of another instrument status management method according to an embodiment of the present invention. Figure 2 As shown, the process includes the following steps:

[0072] Step S201 : registering the instrument middleware in the instrument system in response to a registration request of the vehicle instrument middleware.

[0073] Specifically, the above step S201 includes:

[0074] Step S2011, after the vehicle is started, start the instrument middleware.

[0075] Step S2012: Generate a registration request based on the identification information of the middleware.

[0076] Step S2013: Send a registration request to the power management unit of the instrument system to register the instrument middleware in the instrument system according to the registration request.

[0077] In the embodiment of the present invention, after the vehicle is started, the vehicle control system can be powered on, and then the MCU is used to power the SOC, so that the SOC performs the boot process from the kernel and starts the instrument Linux system to run the power management system logic. Next, the instrument middleware can be started, and at this time, other applications of the instrument Linux system can also be started at the same time. The specific content of other applications is not expanded in this invention.

[0078] It should be understood that, considering that with the iteration of the vehicle system, the instrument system and SOC are not static, and new business modules may be added or replaced, etc. Therefore, the instrument middleware can be registered after each vehicle start.

[0079] When implementing it, Figure 3The diagram shown is a schematic diagram of registering an instrument middleware in a power management unit, wherein the instrument middleware 1-n can respectively send a registration request containing its own identification information to the power management unit, for example, the identification information can be a middleware ID.

[0080] Step S202: Analyze the vehicle status data to obtain the vehicle driving status. Figure 1 Step S102 of the illustrated embodiment will not be described in detail here.

[0081] Step S203: Determine the target running state that matches the driving state according to the state condition. Figure 1 Step S103 of the illustrated embodiment will not be described in detail here.

[0082] Step S204: In response to the switching request received by the instrument middleware, the instrument system is controlled to switch to the target operating state. Figure 1 Step S104 of the illustrated embodiment will not be described in detail here.

[0083] In the embodiment of the present invention, considering that with the iteration of the vehicle system, the instrument system and the SOC are not static, and new business modules may be added or replaced, the instrument middleware can be registered after each vehicle start. At the same time, module reuse is achieved without changing the power management module, which solves the problem of power management reuse between different SOC solutions, greatly reduces the amount of code, improves the reuse rate, and realizes the platformization of power management.

[0084] In some optional embodiments, the above Figure 1 The corresponding embodiments also include:

[0085] Step S11, obtaining operation status information corresponding to the instrument system, wherein the operation status information includes at least one operation status.

[0086] Step S12: determining at least one preset operating state that matches the operating state information in the preset operating states, and obtaining an operating state collection.

[0087] In the embodiment of the present invention, it is considered that different models of vehicles may use different instrument system models, and even the same model of instrument system may change the operating status included in the operating status information during subsequent use due to system updates, for example, increasing or decreasing the operating status.

[0088] Therefore, the operation status information corresponding to the instrument system can be obtained, and each operation status in the operation status information can be classified to achieve abstract unification of the operation status. Here, several preset operation statuses can be pre-set, and the operation status information can be classified into these preset operation statuses.

[0089] Specifically, the preset operating states may include: initialization state (init), standby state (standby), boot animation playing state (welcom), operation state (operation), shutdown animation playing state (goodbye), sleep state (sleep), etc. Among them, the initialization state is the startup state of the device, which can usually be entered immediately after the instrument system is awakened. After entering the initialization state, if there is no user operation or instruction, the instrument system can enter the standby state. Some devices will enter a special welcome or startup animation state after receiving a specific signal or user operation in the standby state. For example, in a car audio system, when the user turns on the radio, a short boot animation may be displayed or a welcome sound effect may be played, indicating that the system has been activated and is ready to accept further operation commands. The operating state is the main working state of the device, which is entered after all initialization and settings are completed. In this state, the device performs its designed main functions, such as the car dashboard displays information such as speed, fuel level, engine status, etc.; the audio system plays music, etc. In the operating state, the device runs at full power and provides complete functions and performance. When the device receives a shutdown signal or the user attempts to shut down the device, it may enter the shutdown animation playing state. Similar to the boot animation playing state, this is a transition state used to display a shutdown animation or farewell message to indicate that the device is in the process of shutting down. For example, in a car audio system, when the user turns off the radio, a shutdown animation may be displayed or a farewell sound effect may be played. The sleep state is usually entered when the device has not been used for a long time and does not need to be on standby. In this state, the device may almost completely shut down all functions to save energy.

[0090] It should be understood that not all preset operating states can be included in the operating state collection obtained after abstracting and unifying the operating state information of all instrument systems. For example, if the status information of the instrument system includes initialization state, standby state, welcome animation playing state, working state and sleep state, then after abstracting and unifying the operating state information, the preset operating states that can be included in the operating state collection include: initialization state, standby state, boot animation playing state, working state and sleep state.

[0091] In the embodiment of the present invention, the operation status information corresponding to the instrument system can be obtained, and each operation status in the operation status information can be classified to achieve abstract unification of the operation status, thereby facilitating the management of the operation status of the instrument system.

[0092] In this embodiment, another instrument status management method is provided, which can be used for the above-mentioned new energy vehicle. Figure 4 is a flow chart of another instrument status management method according to an embodiment of the present invention. Figure 4 As shown, the process includes the following steps:

[0093] Step S401, in response to a registration request from the vehicle instrument middleware, register the instrument middleware in the instrument system. Figure 1 Step S101 of the illustrated embodiment will not be described in detail here.

[0094] Step S402: Analyze the vehicle status data to obtain the vehicle driving status. Figure 1 Step S102 of the illustrated embodiment will not be described in detail here.

[0095] Step S403: determining a target operating state that matches the driving state according to the state condition.

[0096] Specifically, the above step S403 includes:

[0097] Step S4031, obtaining a control signal fed back by a micro control unit of the vehicle, wherein the control signal is used to control the driving state of the vehicle.

[0098] Step S4032: Based on the state condition, determine the target operating state corresponding to the control signal in the operating state collection.

[0099] In an embodiment of the present invention, the MCU can monitor the control signal of the vehicle body in real time. For example, the control signal may include the communication signal sent by the key, the sensor signal returned by the sensor of the main driver's door, the IGN (Ignition) status signal, the CAN (Controller Area Network) bus signal, the 4G remote wake-up signal, etc.

[0100] Next, the MCU can determine the target operating state corresponding to the control signal in the operating state collection based on the state conditions. Specifically, the control signal corresponding to each state condition can be pre-set so that after receiving the control signal, the operating state indicated by the state condition corresponding to the control signal can be determined as the target operating state.

[0101] For example, the control signal corresponding to the boot animation playback state can be preset as a radio startup signal. When the user turns on the radio, the CAN bus signal received by the MCU includes the radio startup signal. At this time, the boot animation playback state can be determined as the target operating state.

[0102] Here, if Figure 5 The figure shows a schematic diagram of switching the operating state of the instrument system, wherein the operating state collection corresponding to the instrument system includes the above-mentioned initialization state (init), standby state (standby), boot animation playback state (welcom), working state (operation), shutdown animation playback state (goodbye) and sleep state (sleep). After determining the target operating state of the vehicle according to the control signal, the operating state of the instrument system can be switched by controlling GPIO8 and / or GPIO9 (General Purpose Input Output, i.e., input and output port, referred to as GPIO).

[0103] For example, when the instrument system is in sleep or initialization state, GPIO8 and GPIO9 can be pulled high (i.e. GPIO8||GPIO9 is pulled high) to switch the instrument system to standby state. Alternatively, when the instrument system is in standby state, GPIO8 can be pulled high to switch the instrument system to the boot animation playback state, and the instrument system will automatically switch to the working state after the animation is played. In addition, the operating state switching method of the remaining instrument systems is similar to the above embodiment, as shown in the following example. Figure 5 As shown, no further description is given here.

[0104] Step S404: In response to the switching request received by the instrument middleware, the instrument system is controlled to switch to the target operating state. Figure 1 Step S104 of the illustrated embodiment will not be described in detail here.

[0105] In the embodiment of the present invention, on the basis of abstracting and unifying the operating state of the instrument system, the operating state of the instrument can be switched based on the control signal indication of the vehicle, thereby ensuring the independence of the power management logic of the instrument state and the SOC chip solution, reducing the coupling degree between the instrument power management core module and the instrument middleware, reducing the differences in power management modules of different SOC solutions, and greatly reducing the probability of the vehicle computer having a black screen and being unable to start, and the vehicle being unable to ignite due to dark current feeding.

[0106] In some optional implementations, the target operating state includes: a wake-up state, and the step S104 includes:

[0107] Step S21: After receiving the switching request sent by the micro control unit of the vehicle, wake up the driving unit of the vehicle.

[0108] Step S22: Based on the drive unit, a switching request is sent to the instrument system.

[0109] Step S23: When the meter middleware meets the wake-up condition, the meter middleware is switched to the wake-up state.

[0110] In the embodiment of the present invention, Figure 6 The figure shows a process diagram of putting the instrument system into sleep or wake-up mode, in which the underlying MCU chip is responsible for sending a switching request, and the Linux instrument power management module in the SOC (i.e., the above-mentioned driver unit) is responsible for managing the sleep and wake-up of the Linux system of the entire instrument system, and communicates with the MCU through the relevant drivers of the kernel to obtain the switching request from the MCU to control the sleep and wake-up logic of the instrument middleware and the instrument UI display module.

[0111] Specifically, when waking up the instrument system, the target operating state indicated by the above switching request can be the awakened state. When the MCU receives the control signal and determines that the instrument system meets the awakening condition according to the control signal, it can generate a switching request and send the switching request to the Linux instrument power management module in the SOC. Next, when it is determined that the instrument system is in a dormant state, it is determined that the instrument middleware meets the awakening condition, and the instrument middleware and the instrument UI display module are switched to the awakened state.

[0112] Here, when waking up the instrument middleware, the running status of the instrument middleware can be monitored in real time. If the running status of the instrument middleware is still in the sleep state, the instrument power management module can continue to be notified to continue waking up the instrument middleware and the UI display module; if the running status of the instrument middleware is in the initialization state, it is determined that the wake-up is completed.

[0113] In addition, when the control instrument system is in sleep mode, the target operating state indicated by the switching request may be a sleep state, and the step S104 further includes:

[0114] When the meter middleware meets the sleep condition, in response to a switching request sent by the micro control unit of the vehicle, the meter middleware is switched to the sleep state, and the system-on-chip (SOC) of the vehicle is switched to the sleep state.

[0115] In the embodiment of the present invention, when the MCU receives the control signal and determines that the instrument system meets the sleep condition according to the control signal, it can generate a switching request and send the switching request to the Linux instrument power management module in the SOC. Next, when it is determined that the instrument system is in a non-sleep state, it is determined that the instrument middleware meets the sleep condition, and the instrument middleware and the instrument UI display module are switched to the sleep state.

[0116] Specifically, it is possible to monitor in real time whether the running state of the instrument middleware is in a dormant state. If so, the SOC kernel is notified to sleep so that the SOC switches to a dormant state. If not, the running state of the instrument middleware is continuously monitored until the instrument middleware is in a dormant state. It should be understood that when the instrument middleware is in a dormant state, the instrument UI display module can also be switched to a dormant state at the same time.

[0117] In an embodiment of the present invention, a switching request can be sent by the vehicle's microcontroller unit so that the power management unit can respond to the switching request and switch the operating state of the instrument system, thereby ensuring that the power management logic of the instrument sleep and wake-up is independent of the SOC chip solution, reducing the coupling degree between the instrument power management core module and the instrument middleware, reducing the differences in power management modules of different SOC solutions, and greatly reducing the probability of the vehicle computer having a black screen and being unable to start, and the vehicle being unable to ignite due to dark current feeding.

[0118] In this embodiment, an instrument status management system is also provided, which is used to implement the above embodiments and preferred implementations, and the descriptions that have been made will not be repeated. Although the system described in the following embodiments is preferably implemented in software, the implementation in hardware, or a combination of software and hardware, is also possible and conceivable.

[0119] This embodiment provides an instrument status management system, such as Figure 7 The diagram shows the architecture of the instrument status management system, which includes: SOC and MUC, wherein the SOC includes UI (ie, the instrument UI display module mentioned above), registered instrument middleware and kernel.

[0120] The MUC is used to analyze the vehicle's state data to obtain the vehicle's driving state, and determine a target operating state that matches the driving state according to the state conditions, so as to initiate a switching request according to the target operating state.

[0121] In the embodiment of the present invention, the specific implementation method of determining the target running state and initiating the switching request is as described above. Figure 1 The corresponding embodiments are described in detail and will not be repeated here.

[0122] SOC is used to obtain the switching request sent by the MCU based on the driving unit in the kernel, and send the switching request to the power management unit so that the power management unit manages the running status of the instrument middleware, wherein the instrument middleware may include ivs (In-Vehicle Server), rpcmanager (remote procedure call manager), etc.

[0123] In the embodiment of the present invention, the specific implementation method of the running state switching is as described above. Figure 1 The corresponding embodiments are described and will not be described here. In addition, the user can communicate with the ivs in the instrument middleware through the HMI unit (Human-Machine Interface) in the instrument UI display module to control the running state of the vehicle.

[0124] In summary, in the embodiment of the present invention, first, the instrument middleware can be registered in the instrument system in response to the registration request of the vehicle instrument middleware. Next, the vehicle's driving state is analyzed based on the vehicle's state data, and the target operating state that matches the driving state is determined according to the state conditions. Then, in response to the switching request received by the instrument middleware, the instrument system can be controlled to switch to the target operating state, thereby introducing a registration mechanism to register the instrument middleware in the instrument system, so that the operating state of the instrument system can be managed through the instrument middleware, reducing the complexity of the instrument project, thereby reducing safety hazards and improving the user experience.

[0125] In this embodiment, an instrument status management device is also provided, which is used to implement the above embodiments and preferred implementations, and the descriptions that have been made will not be repeated. As used below, the term "module" can be a combination of software and / or hardware that implements a predetermined function. Although the devices described in the following embodiments are preferably implemented in software, the implementation of hardware, or a combination of software and hardware, is also possible and conceivable.

[0126] This embodiment provides an instrument status management device, such as Figure 8 As shown, including:

[0127] A registration module 801, for registering the vehicle instrument middleware in the instrument system in response to a registration request of the vehicle instrument middleware;

[0128] An analysis module 802 is used to analyze the vehicle status data to obtain the driving status of the vehicle;

[0129] A determination module 803, configured to determine a target operating state matching the driving state according to a state condition;

[0130] The control module 804 is used to control the instrument system to switch to the target operating state in response to the switching request received by the instrument middleware.

[0131] In some optional implementations, the registration module 801 is used to:

[0132] After the vehicle is started, starting the instrument middleware;

[0133] Generate a registration request based on the identification information of the middleware;

[0134] The registration request is sent to a power management unit of the meter system, so as to register the meter middleware in the meter system according to the registration request.

[0135] In some optional embodiments, the device is also used for:

[0136] Acquiring operation status information corresponding to the instrument system, wherein the operation status information includes at least one operation status;

[0137] At least one preset operating state matching the operating state information is determined in the preset operating states to obtain an operating state collection.

[0138] In some optional implementations, the operating state collection includes at least one preset operating state of: initialization state, standby state, startup animation playing state, working state, shutdown animation playing state, and sleep state.

[0139] In some optional implementations, the determination module 803 is used to:

[0140] Acquire a control signal fed back by a microcontroller unit of the vehicle, wherein the control signal is used to control the driving state of the vehicle;

[0141] Based on the state condition, a target operating state corresponding to the control signal in the operating state collection is determined.

[0142] In some optional implementations, the target operating state includes: a wake-up state; the control module 804 is further configured to:

[0143] After receiving a switching request sent by the micro control unit of the vehicle, waking up the driving unit of the vehicle;

[0144] Based on the drive unit, sending a switching request to the instrument system;

[0145] When the meter middleware meets the wake-up condition, the meter middleware is switched to the wake-up state.

[0146] In some optional implementations, the target operating state includes: a dormant state; the control module 804 is further configured to:

[0147] When the meter middleware meets the sleep condition, in response to a switching request sent by the micro control unit of the vehicle, the meter middleware is switched to the sleep state, and the system-on-chip (SOC) of the vehicle is switched to the sleep state.

[0148] The further functional description of each of the above modules and units is the same as that of the above corresponding embodiments and will not be repeated here.

[0149] The instrument status management device in this embodiment is presented in the form of a functional unit, where the unit refers to an ASIC (Application Specific Integrated Circuit) circuit, a processor and memory that executes one or more software or fixed programs, and / or other devices that can provide the above functions.

[0150] The embodiment of the present invention also provides a computer device having the above Figure 8 The instrument status management device shown.

[0151] See also Fig. 9 , Fig. 9 is a schematic diagram of the structure of a computer device provided by an optional embodiment of the present invention, such as Fig. 9 As shown, the computer device includes: one or more processors 10, a memory 20, and interfaces for connecting various components, including high-speed interfaces and low-speed interfaces. Various components are connected to each other using different buses for communication, and can be installed on a common mainboard or installed in other ways as needed. The processor can process the instructions executed in the computer device, including instructions stored in or on the memory to display the graphical information of the GUI on an external input / output device (such as, a display device coupled to the interface). In some optional embodiments, if necessary, multiple processors and / or multiple buses can be used together with multiple memories and multiple memories. Similarly, multiple computer devices can be connected, and each device provides some necessary operations (for example, as a server array, a group of blade servers, or a multi-processor system). Fig. 9 A processor 10 is taken as an example.

[0152] The processor 10 may be a central processing unit, a network processor or a combination thereof. The processor 10 may further include a hardware chip. The hardware chip may be a dedicated integrated circuit, a programmable logic device or a combination thereof. The programmable logic device may be a complex programmable logic device, a field programmable gate array, a general purpose array logic or any combination thereof.

[0153] The memory 20 stores instructions executable by at least one processor 10, so that the at least one processor 10 executes the method shown in the above embodiment.

[0154] The memory 20 may include a program storage area and a data storage area, wherein the program storage area may store an operating system, an application required for at least one function; the data storage area may store data created according to the use of the computer device, etc. In addition, the memory 20 may include a high-speed random access memory, and may also include a non-transient memory, such as at least one disk storage device, a flash memory device, or other non-transient solid-state storage device. In some optional embodiments, the memory 20 may optionally include a memory remotely arranged relative to the processor 10, and these remote memories may be connected to the computer device via a network. Examples of the above-mentioned network include, but are not limited to, the Internet, an intranet, a local area network, a mobile communication network, and combinations thereof.

[0155] The memory 20 may include a volatile memory, such as a random access memory; the memory may also include a non-volatile memory, such as a flash memory, a hard disk or a solid state drive; the memory 20 may also include a combination of the above types of memory.

[0156] The computer device also includes an input device 30 and an output device 40. The processor 10, the memory 20, the input device 30 and the output device 40 may be connected via a bus or other means. Fig. 9 The example of connecting through bus is taken in the following.

[0157] The input device 30 can receive input digital or character information, and generate key signal input related to the user settings and function control of the computer device, such as a touch screen, a keypad, a mouse, a track pad, a touch pad, an indicator bar, one or more mouse buttons, a trackball, a joystick, etc. The output device 40 may include a display device, an auxiliary lighting device (e.g., an LED) and a tactile feedback device (e.g., a vibration motor), etc. The above-mentioned display device includes but is not limited to a liquid crystal display, a light emitting diode, a display and a plasma display. In some optional embodiments, the display device can be a touch screen.

[0158] The embodiment of the present invention also provides a computer-readable storage medium. The method according to the embodiment of the present invention can be implemented in hardware, firmware, or can be implemented as a computer code that can be recorded in a storage medium, or can be implemented as a computer code that is originally stored in a remote storage medium or a non-temporary machine-readable storage medium and will be stored in a local storage medium through a network download, so that the method described herein can be stored in such software processing on a storage medium using a general-purpose computer, a dedicated processor, or programmable or dedicated hardware. Among them, the storage medium can be a magnetic disk, an optical disk, a read-only storage memory, a random access memory, a flash memory, a hard disk or a solid-state hard disk, etc.; further, the storage medium can also include a combination of the above types of memories. It can be understood that a computer, a processor, a microprocessor controller, or programmable hardware includes a storage component that can store or receive software or computer code. When the software or computer code is accessed and executed by a computer, a processor, or hardware, the method shown in the above embodiment is implemented.

[0159] A part of the present invention may be applied as a computer program product, such as a computer program instruction, which, when executed by a computer, can call or provide the method and / or technical solution according to the present invention through the operation of the computer. Those skilled in the art should understand that the existence of the computer program instruction in a computer-readable medium includes, but is not limited to, a source file, an executable file, an installation package file, etc., and accordingly, the way in which the computer program instruction is executed by the computer includes, but is not limited to: the computer directly executes the instruction, or the computer compiles the instruction and then executes the corresponding compiled program, or the computer reads and executes the instruction, or the computer reads and installs the instruction and then executes the corresponding installed program. Here, the computer-readable medium may be any available computer-readable storage medium or communication medium accessible to the computer.

[0160] Although the embodiments of the present invention have been described in conjunction with the accompanying drawings, those skilled in the art may make various modifications and variations without departing from the spirit and scope of the present invention, and such modifications and variations are all within the scope defined by the accompanying description.

Claims

1. A method for managing instrument status, characterized in that: The method comprises: In response to a registration request of the vehicle instrument middleware, registering the instrument middleware in the instrument system; Analyze the vehicle status data to obtain the driving status of the vehicle; determining a target operating state matching the driving state according to the state condition; In response to the switching request received by the meter middleware, the meter system is controlled to switch to the target operating state.

2. The method according to claim 1, characterized in that The step of registering the instrument middleware in the instrument system in response to the registration request of the vehicle instrument middleware includes: After the vehicle is started, starting the instrument middleware; Generate a registration request based on the identification information of the middleware; The registration request is sent to a power management unit of the meter system, so as to register the meter middleware in the meter system according to the registration request.

3. The method according to claim 1, characterized in that The method further comprises: Acquiring operation status information corresponding to the instrument system, wherein the operation status information includes at least one operation status; At least one preset operating state matching the operating state information is determined in the preset operating states to obtain an operating state collection.

4. The method according to claim 3, characterized in that: The operating state collection includes: at least one preset operating state of initialization state, standby state, startup animation playing state, working state, shutdown animation playing state, and sleep state.

5. The method according to claim 3, characterized in that: The step of determining a target operating state matching the driving state according to the state condition includes: Acquire a control signal fed back by a microcontroller unit of the vehicle, wherein the control signal is used to control the driving state of the vehicle; Based on the state condition, a target operating state corresponding to the control signal in the operating state collection is determined.

6. The method according to claim 1, characterized in that The target operating state includes: a wake-up state; The step of controlling the instrument system to switch to the target operating state in response to the switching request received by the instrument middleware includes: After receiving a switching request sent by the micro control unit of the vehicle, waking up the driving unit of the vehicle; Based on the drive unit, sending a switching request to the instrument system; When the meter middleware meets the wake-up condition, the meter middleware is switched to the wake-up state.

7. The method according to claim 1, characterized in that The target operating state includes: a dormant state; The step of controlling the instrument system to switch to the target operating state in response to the switching request received by the instrument middleware includes: When the meter middleware meets the sleep condition, in response to a switching request sent by the micro control unit of the vehicle, the meter middleware is switched to the sleep state, and the system-on-chip (SOC) of the vehicle is switched to the sleep state.

8. An instrument status management device, characterized in that: The device comprises: A registration module, for registering the vehicle instrument middleware in the instrument system in response to a registration request of the vehicle instrument middleware; An analysis module, used for analyzing based on the vehicle status data to obtain the driving status of the vehicle; a determination module, configured to determine a target operating state matching the driving state according to a state condition; The control module is used to control the instrument system to switch to the target operating state in response to the switching request received by the instrument middleware.

9. A computer device, characterized in that: include: A memory and a processor, wherein the memory and the processor are communicatively connected to each other, the memory stores computer instructions, and the processor executes the instrument status management method according to any one of claims 1 to 7 by executing the computer instructions.

10. A computer-readable storage medium, characterized in that: The computer-readable storage medium stores computer instructions, and the computer instructions are used to enable a computer to execute the instrument status management method according to any one of claims 1 to 7.

11. A computer program product, characterized in that The method comprises computer instructions, wherein the computer instructions are used to cause a computer to execute the instrument status management method according to any one of claims 1 to 7.

Images