CN115827070A - State management module and method, microcontroller and vehicle-mounted controller - Google Patents

Abstract

The invention provides a state management module and method, a microcontroller and a vehicle-mounted controller. The state management module is used for carrying out unified management on the states of the virtual machines, the virtual machines do not need to be managed by themselves, corresponding software design can be simplified, and development cost is reduced. The main management unit and the auxiliary management unit can be matched with each other and respectively manage the corresponding virtual machines, so that the management among the virtual machines is more flexible, and particularly when the number of the virtual machines is large and the virtual machines are developed by different suppliers, the development granularity of the state management module can be better corresponding to the multiple virtual machines with the relevance. Furthermore, the state management module can also start the associated virtual machine, so that the whole vehicle function matched with a plurality of virtual machines is realized, and meanwhile, the wake-up source design is facilitated to be simplified.

Description

State management module and method, microcontroller and vehicle-mounted controller

Technical Field

The invention relates to the technical field of intelligent automobiles, in particular to a state management module and method, a microcontroller and an on-board controller.

Background

The automobile modernization refers to electromotion, intellectualization, networking and sharing, and is a great revolution direction of the automobile industry at present. With the advancement of new technologies, the functions in the vehicle become increasingly complex, and the traditional distributed Electronic and Electrical Architecture (EEA) cannot adapt to the trend. Thus, the electronic-electrical architecture evolves from the original distributed, step-by-step, towards domain-centralized, central-centralized, to achieve the vision of a "software-defined car".

In a domain-centralized and a central-centralized electronic and electrical architecture, the number of controllers is reduced, and the form and responsibility of the controllers are changed dramatically. The functions of the traditional embedded controller show an integration trend so as to reduce communication overhead and hardware mechanical cost and improve the automation degree of production and manufacturing. In order to meet the demand of Controller integration, virtualization technology is gradually applied to embedded controllers of automobiles, which is an advanced technology and powerful means for integrating functions of a plurality of controllers in a Micro-Controller Unit (MCU). That is, originally, a plurality of controller software may run on the same microcontroller in the form of Virtual Machines (VMs), and coordinate management of each VM through a Virtual Machine monitor (Hypervisor), and configure hardware resources.

However, as the number of virtual machines created in the microcontroller increases and each virtual machine may be provided by a different vendor, the virtual machines may have various status problems during operation, and the virtual machine monitor cannot manage the status of each virtual machine. Moreover, the state management is a complex process, and for the traditional embedded controller of the automobile, the management of the state of the controller needs to be realized by combining external wake-up (such as ignition signal KL15 of the engine, message, charge guiding signal, etc.) and internal wake-up holding requirements, etc. Similarly, after the virtualization technology is applied, a plurality of virtual machines are integrated in one controller, and the state of each virtual machine and the whole system need to be systematically managed so as to ensure the stability of the whole control system.

Therefore, a state management module and a state management method applied to a virtual machine are needed to ensure stable operation of each virtual machine.

Disclosure of Invention

The invention aims to provide a state management module and method, a microcontroller and an on-board controller, which are used for solving the problem of how to manage the state of a virtual machine.

In order to solve the above technical problem, the present invention provides a status management module, which includes a main management unit; the main management unit manages a plurality of virtual machines, and is used for receiving and identifying the awakening source and managing the state of the corresponding virtual machine according to the awakening source identification result;

or, the state management module comprises the main management unit and a plurality of auxiliary management units; the auxiliary management unit manages a plurality of virtual machines and is used for managing the states of the corresponding virtual machines according to the awakening source identification result; wherein, part of the auxiliary management units are further used for receiving and identifying the awakening source; and the main management unit is also used for managing the state of part of the auxiliary management units.

Optionally, in the state management module, the states of the virtual machine and the auxiliary management unit both include: start, shut down, or restart.

Optionally, in the state management module, when the virtual machine is started, the primary management unit and the secondary management unit are further configured to start the virtual machine that needs to be directly started according to the wake-up source identification result, and the associated virtual machine that needs to be started based on the functional link.

Optionally, in the state management module, the primary management unit is further configured to send the wake-up source identification result to the secondary management unit without a wake-up source identification function.

Optionally, in the state management module, the primary management unit and the secondary management unit are further configured to send the wake-up source identification result to the corresponding virtual machine managed by the primary management unit and the secondary management unit.

Optionally, in the state management module, the primary management unit and the secondary management unit are further configured to determine whether the wake-up source identification result exists, if so, the corresponding virtual machine remains in an open state or requests to restart; if not, informing the corresponding virtual machine managed by the virtual machine to prepare for closing.

Optionally, in the state management module, when the time for the virtual machine to be closed exceeds a set time, the primary management unit and the secondary management unit are further configured to directly request to close the corresponding virtual machine, or the virtual machine requests to close by itself.

Optionally, in the state management module, the virtual machine is further configured to determine whether the wake-up source identification result exists; if so, the virtual machine keeps an opening state or requests to restart; if not, the virtual machine automatically requests to close.

Optionally, in the state management module, when the virtual machine is ready to be turned off, the primary management unit or the secondary management unit receives a new wake-up source and needs to start the corresponding virtual machine, and the primary management unit or the secondary management unit requests a restart for the corresponding virtual machine, or the corresponding virtual machine requests a restart for its own time.

Optionally, in the state management module, when all the virtual machines are in a shutdown state and all the auxiliary management units are in a shutdown state, the main management unit is further configured to send a power-off request or a sleep request, so that the microcontroller where the state management module is located is in a power-off state or a sleep state.

Optionally, in the state management module, when all the virtual machines managed by the auxiliary management unit are in a shutdown state, the auxiliary management unit is further configured to request for shutdown by itself, or request for shutdown from the main management unit, or send a power-down request or a sleep request, so that the virtual machines managed by the auxiliary management unit and/or the auxiliary management unit are in a power-down state or a sleep state corresponding to partitions in the microcontroller.

Based on the same inventive concept, the invention also provides a microcontroller, which comprises a plurality of virtual machines and the state management module; the main management unit correspondingly manages the states of part of the auxiliary management units and the states of at least part of the virtual machines, and the rest auxiliary management units respectively manage the states of the rest of the virtual machines.

Optionally, in the microcontroller, the microcontroller further includes a sleep module; when all the virtual machines are in a closed state and all the auxiliary management units are in a closed state, the main management unit is further used for at least sending a sleep request to the sleep module so as to enable the microcontroller to be in a sleep state.

Optionally, in the microcontroller, the number of the sleeping modules is greater than or equal to 2, and when the auxiliary management unit is in the off state, the auxiliary management unit is further configured to send a sleeping request to at least the corresponding sleeping module, so that the virtual machine managed by the auxiliary management unit and/or the auxiliary management unit is in the sleeping state corresponding to the partition in the microcontroller.

Optionally, in the microcontroller, a virtual machine monitor is stored in the microcontroller, where operation of a part of processes in the state management module is executed in the virtual machine monitor, and/or operation of a part of processes in the state management module is executed in the virtual machine managed by the virtual machine monitor.

Optionally, in the microcontroller, the microcontroller further includes a plurality of cores, and the running of part of the processes in the state management module is executed in the cores that are not in the monitoring jurisdiction of the virtual machine.

Based on the same invention concept, the invention also provides a vehicle-mounted controller, which comprises a power management module and a plurality of microcontrollers; wherein, the first and the second end of the pipe are connected with each other,

when all the virtual machines are in a closed state and all the auxiliary management units are in a closed state, the main management unit is further used for at least sending a power-down request to the power management module so as to enable the microcontroller to be in a power-down state.

Optionally, in the vehicle-mounted controller, the number of the power management modules is greater than or equal to 2, and when the auxiliary management unit is in the off state, the auxiliary management unit is further configured to send a power-down request to at least the corresponding power management module, so that the auxiliary management unit and/or the virtual machine managed by the auxiliary management unit is in the power-down state corresponding to the partition in the microcontroller.

Based on the same inventive concept, the invention also provides a state management method, which uses the vehicle-mounted controller and comprises the following steps:

the method comprises the following steps: the main management unit receives and identifies the awakening source, or the main management unit and part of the auxiliary management units receive and identify the awakening source;

step two: the main management unit and/or the auxiliary management unit starts the corresponding virtual machine managed by the auxiliary management unit according to the awakening source identification result;

step three: the main management unit and/or the auxiliary management unit and/or the corresponding virtual machine judge whether the awakening source identification result exists or not, if so, the corresponding virtual machine keeps an open state or requests to restart, and if not, the main management unit and/or the auxiliary management unit inform the corresponding virtual machine managed by the main management unit and/or the auxiliary management unit to prepare to close or the corresponding virtual machine requests to close by itself;

step four: and the main management unit judges whether all the virtual machines are in a closed state or not and all the auxiliary management units are in a closed state or not, if so, the main management unit sends a power-off request or a sleep request so as to enable the microcontroller to be in a power-off state or a sleep state.

Optionally, in the state management method, before the step one is executed, the primary management unit and all the secondary management units are powered on and started; or, the main management unit is powered on and started, and part of the auxiliary management units are started.

Optionally, in the state management method, before the step two is executed and after the step one is executed, the primary management unit sends the wake-up source identification result to the corresponding secondary management unit without a function of identifying a wake-up source.

Optionally, in the state management method, in the second step, the primary management unit and/or the secondary management unit sends the wake-up source identification result to the virtual machine managed by the primary management unit and/or the secondary management unit while starting the corresponding virtual machine.

Optionally, in the state management method, in the third step, when the time for the virtual machine to be turned off exceeds a set time, the primary management unit and/or the secondary management unit directly requests to turn off the corresponding virtual machine, or the virtual machine itself requests to turn off the corresponding virtual machine.

Optionally, in the state management method, in the third step, when the virtual machine is ready to be turned off, the primary management unit or the secondary management unit receives a new wake source that the corresponding virtual machine needs to be started, and the primary management unit or the secondary management unit requests the corresponding virtual machine to be restarted, or the corresponding virtual machine requests the virtual machine to be restarted.

Optionally, in the state management method, before the step four is executed, and after the step three is executed, the auxiliary management unit determines whether the virtual machines managed by the auxiliary management unit are all in a shutdown state, if so, the auxiliary management unit requests to shut down by itself, or requests to shut down the main management unit, or sends a power-down request or a sleep request, so that the virtual machines managed by the auxiliary management unit and/or the auxiliary management unit are in a power-down state or a sleep state corresponding to the partition in the microcontroller.

Based on the same inventive concept, the present invention also provides a computer program comprising instructions for executing the state management method when said computer program is executed on a suitable computer device.

Based on the same inventive concept, the present invention also provides a computer-readable storage medium on which the computer program is encoded.

In summary, the present invention provides a status management module and method, a microcontroller, and a vehicle-mounted controller. The state management module is used for carrying out unified management on the states of the virtual machines, the virtual machines do not need to be managed by themselves, corresponding software design can be simplified, and development cost is reduced. The main management unit and the auxiliary management unit are matched with each other and respectively manage the corresponding virtual machines, so that the management among the virtual machines is more flexible, and particularly when the number of the virtual machines is large and the virtual machines are developed by different suppliers, the development granularity of the state management module and the plurality of virtual machines with the relevance can be better matched. Furthermore, the state management module can also start the associated virtual machine to realize the whole vehicle function matched with a plurality of virtual machines, and meanwhile, the wake-up source design is facilitated to be simplified.

Drawings

Fig. 1 is a schematic structural diagram of a state management module according to an embodiment of the present invention.

Fig. 2 is a schematic structural diagram of a state management module according to an embodiment of the present invention.

Fig. 3 is a schematic structural diagram of a state management module according to an embodiment of the present invention.

Fig. 4 is a flowchart of a state management method in an embodiment of the present invention.

Fig. 5 is a flowchart of a state management method according to an embodiment of the present invention.

Fig. 6 is a flowchart of a state management method according to an embodiment of the present invention.

Fig. 7 is a flowchart of virtual machine startup in the embodiment of the present invention.

FIG. 8 is a flowchart of virtual machine shutdown in an embodiment of the invention.

Wherein the reference numerals are:

101-a master management unit; 102-secondary management unit.

Detailed Description

To further clarify the objects, advantages and features of the present invention, a more particular description of the invention will be rendered by reference to specific embodiments thereof which are illustrated in the appended drawings. It is to be noted that the drawings are in greatly simplified form and are not to scale, but are merely intended to facilitate and clarify the explanation of the embodiments of the present invention. Further, the structures illustrated in the drawings are often part of actual structures. In particular, the drawings may have different emphasis points and may sometimes be scaled differently. It should be further understood that the terms "first," "second," "third," and the like in the description are used for distinguishing between various components, elements, steps, and the like, and are not intended to imply a logical or sequential relationship between various components, elements, steps, or the like, unless otherwise indicated or indicated.

Referring to fig. 1 and 2, the present embodiment provides a system including a master management unit 101; the main management unit 101 manages a plurality of virtual machines, and is used for receiving and identifying a wake-up source and managing the state of the corresponding virtual machine according to the wake-up source identification result; or, the state management module includes the main management unit 101 and a plurality of auxiliary management units 102; the auxiliary management unit 102 manages a plurality of virtual machines, and is configured to manage states of the corresponding virtual machines according to the wake-up source identification result; wherein, part of the secondary management unit 102 is further configured to receive and identify the wake-up source; and the primary management unit 101 is also used for managing the state of part of the secondary management unit 101.

Therefore, the state management module is used for carrying out unified management on the states of the virtual machines, the self-management of each virtual machine is not needed, the corresponding software design can be simplified, and the development cost is reduced. The main management unit 101 and the auxiliary management unit 102 cooperate with each other and respectively manage the corresponding virtual machines, so that management between the virtual machines is more flexible, and especially when the number of the virtual machines is large and the virtual machines are developed by different suppliers, the development granularity of the state management module and the plurality of virtual machines with the association can be better corresponded.

The status management module provided in this embodiment is specifically described below with reference to fig. 1 to 8.

Referring to fig. 1-2, the status management module provided in this embodiment includes a main management unit 101, or includes a main management unit 101 and a plurality of auxiliary management units 102. It is understood that when the state management module only includes the master management unit 101, the states of all the virtual machines are managed by the master management unit 101. When the state management module comprises a main management unit 101 and a plurality of auxiliary management units 102, the main management unit 101 manages states of a part of virtual machines, and each auxiliary management unit manages states of a part of virtual machines; and the main management unit can also manage the states of part of the auxiliary management units.

It should be noted that the states of the primary management unit 101, the secondary management unit 102, and the virtual machine include, but are not limited to: start, shut down, and restart. The start of the main management unit 101 is generally a power-on start. The start of the secondary management unit 102 may be a power-on start, or may be started by the primary management unit 101. The virtual machine is started by the primary management unit 101 or the secondary management unit 102 managed correspondingly according to the wake source identification result.

Further, the restart of the master management unit 101 may be controlled to be performed according to an external signal. The restart of the secondary management unit 102 may be the master management unit 101 or an external signal control execution. The virtual machine may be restarted under the control of the primary management unit 101 or the secondary management unit 102 managed correspondingly, or by requesting to restart itself. For example, when the wake-up source is absent and the virtual machine enters a ready-to-close state, the primary management unit 101 and/or the secondary management unit 102 receive a new wake-up source, and determine that the corresponding virtual machine needs to be turned on according to a new wake-up source identification result, the primary management unit 101 or the secondary management unit 102 may cause the virtual machine to be turned from the ready-to-close state to a restart state, or the virtual machine requests to restart by itself, and does not need to be turned off and then started, so as to provide operation efficiency.

Further, the turning off of the main management unit 101 is to request a power-down or sleep mode from a sleep module or a power management module or another module when all the virtual machines are in the off state and all the auxiliary management units 102 are in the off state, so that the microcontroller corresponding to the state control module is in the power-down or sleep state. The shutdown of the auxiliary management unit 102 may be a request for the main management unit 101 to control shutdown, or the auxiliary management unit 102 may request power down or hibernation by itself, so that the virtual machine managed by the auxiliary management unit and/or the auxiliary management unit 102 is in a power down state or a hibernation state corresponding to the partition in the microcontroller. The virtual machine may be shut down by itself, or shut down by the primary management unit 101 or the secondary management unit 102 managed correspondingly. After the virtual machine receives a closing instruction sent by the primary management unit 101 or the secondary management unit 102, the time for preparing to close exceeds a set time, and the primary management unit 101 or the secondary management unit 102 may directly and forcibly close the virtual machine.

It should be noted that the wake-up source may be provided by hardware, or may be provided by software, for example, a network message specific frame, an ignition signal KL15 of the engine, a message or a charge pilot signal, and the like.

In one embodiment, the state management module only comprises a main management unit 101, and the main management unit 101 is responsible for receiving and identifying a wake source and managing the states of all the virtual machines. For example, the state of each of the n virtual machines (VM 11 to VM1 n) shown in fig. 1 is managed by the master management unit 101. When the main management unit 101 receives the wake-up source, the main management unit 101 identifies the wake-up source, and determines which virtual machines need to be started according to the wake-up source identification result. If the wake source identification result shows that the virtual machine VM11 and the virtual machine VM12 are required to execute the corresponding function instruction, the primary management unit 101 starts the virtual machine VM11 and the virtual machine VM12, and sends the wake source identification result to the virtual machine VM11 and the virtual machine VM12 to execute the corresponding operation. If the virtual machine VM11 is already in the on state, the main management unit 101 only needs to start the virtual machine VM12, and send the wake source identification result to the virtual machine VM11 and the virtual machine VM12.

When the main management unit 101 determines that the wake-up source identification result does not exist, the main management unit 101 sends the determination result to the corresponding virtual machine to notify the virtual machine VM11 and the virtual machine VM12 to prepare for shutdown. Of course, the virtual machine VM11 and the virtual machine VM12 may also request to be turned off by themselves after receiving the determination result. Or the started virtual machine automatically judges whether the awakening source identification result exists or not, and automatically requests to be closed when the awakening source identification result does not exist. If the virtual machine is closed overtime, the master management unit 101 may force the virtual machine to be closed. Further, when the virtual machine VM11 and the virtual machine VM12 enter a shutdown state, the main management unit 101 receives a new related wake-up source, and the main management unit 101 may notify the virtual machine VM11 and the virtual machine VM12 to stop shutdown and request a restart. Or, the virtual machine VM11 and the virtual machine VM12 request restart by themselves. Further, when the main management unit 101 determines that all the virtual machines are in the off state, the main management unit 101 sends a sleep request or a power-off request to the sleep module, the power management module, or another module. The dormancy module is a module which is responsible for dormancy of each module in the microcontroller where the state management module is located. The power management module is a module in charge of power state management in the vehicle-mounted controller, and the other modules may be a System Base Chip (SBC) or other external power supply units.

In summary, the state management module shown in fig. 1 utilizes the main management unit 101 to implement unified management on the states of all the virtual machines, so as to control the corresponding virtual machines to be turned on, restarted or turned off according to the wake-up source identification result, and it is not necessary to perform self-management on each virtual machine, thereby simplifying corresponding software design and reducing development cost.

In other embodiments, referring to fig. 2, when the number of the virtual machines is large, or a plurality of virtual machines are supplied by different developers, separate management of part of the virtual machines is required. The state management module comprises the primary management unit 101 and a plurality of secondary management units 102. The primary management unit 101 and the secondary management unit 102 respectively manage a plurality of virtual machines, and the primary management unit 101 is further responsible for managing states of a part of the secondary management unit 102. Optionally, the main management unit 101 is only responsible for starting, restarting, and closing the virtual machine managed by itself, and each of the auxiliary management units 102 is responsible for starting, restarting, and closing itself, and is responsible for starting, restarting, and closing the virtual machine managed by itself. Or, the primary management unit 101 is responsible for not only the startup, restart, and shutdown of the virtual machine managed by itself, but also the startup, restart, and shutdown of part or all of the secondary management units 102.

Further, in this embodiment, the number of the secondary management units 102 and the number of the virtual machines respectively managed by the primary management unit 101 and the secondary management units 102 are not specifically limited, and may be determined according to design requirements. The state management module, for example, shown in fig. 2, comprises the primary management unit 101 and two secondary management units 102. The main management unit 101 manages n virtual machines (VM 11 to VM1 n), the auxiliary management unit 1 manages m virtual machines (VM 21 to VM2 m), and the auxiliary management unit 2 manages p virtual machines (VM 31 to VM3 p). Wherein n, m and p are positive integers. Of course, the status management module may also be provided with more secondary management units 102.

In the state management module, only the primary management unit 101 may receive and identify the wake-up source, and all the secondary management units 102 do not have a function of identifying the wake-up source; the primary management unit 101 and part or all of the secondary management units 102 may have a function of identifying a wake source. For the secondary management unit 102 without the wake-up source identification function, the primary management unit 101 may send the wake-up source identification result to the corresponding secondary management unit 102. Then, the main management unit 101 and/or the auxiliary management unit 102 determine whether the virtual machine managed by itself needs to be started according to the obtained wake source identification result, if so, start the corresponding virtual machine that is not started, and send the wake source identification result to the corresponding virtual machine.

Furthermore, according to the different categories of the wake-up sources, the wake-up sources can be divided into a common wake-up source for a plurality of virtual machines, a specific wake-up source for a virtual machine, and a wake-up source for an associated virtual machine based on a functional link. The method includes the steps that a plurality of virtual machines share a wake-up source, namely the virtual machines are awakened by the same wake-up source and run together to complete a functional instruction corresponding to the wake-up source. The plurality of virtual machines includes the virtual machine directly required by the corresponding functional instruction and a virtual machine associated with the corresponding functional instruction. For example, the functional instruction corresponding to the wake source requires that the virtual machine VM11 and the virtual machine VM21 directly run, and the virtual machine VM11 and the virtual machine VM21 share the wake source. Wherein, the virtual machine VM31 needs to be used in the running process of the virtual machine VM11, and then the virtual machine VM31 is an associated virtual machine. Therefore, the virtual machine VM31 needs to be started simultaneously with the virtual machine VM11 and the virtual machine VM21. The specific virtual machine awakening source means that the awakening source only awakens the fixed virtual machine. For example, if the wake source X is a specific wake source of the virtual machine VM21, the secondary management unit 102 only starts the virtual machine VM21 when receiving the wake source X. The awakening source of the associated virtual machine based on the functional link refers to the awakening source correspondingly awakens a plurality of associated virtual machines, and each associated virtual machine is applied to a link of a certain vehicle body function. Therefore, in order to realize a certain vehicle body function, the associated virtual machines based on the functional link are all awakened by the awakening source.

It should be noted that the corresponding virtual machine is included in the virtual machines managed by the primary management unit 101 and/or the secondary management unit 102, and the wake source identification result indicates the virtual machine that needs to be directly started and the associated virtual machine that needs to be started based on the functional link. In other words, the wake source identification result corresponds to the virtual machine that needs to be directly started, and the main management unit 101 and/or the auxiliary management unit 102 determine the associated virtual machine that needs to be started according to the functional link corresponding to the wake source identification result. For example, the state management module includes the primary management unit 101 and the secondary management unit 1. The primary management unit 101 and the secondary management unit 1 are both configured to identify a wake-up source. According to the awakening source identification result, the virtual machines needing to be directly started can be determined to be VM11 and VM21, and meanwhile, the main management unit 101 and the auxiliary management unit 1 can also start the virtual machines VM12 and VM22 based on the requirement of a functional link, so that the whole vehicle function matched with a plurality of virtual machines is realized, and the awakening source design is facilitated to be simplified. The primary management unit 101 starts the virtual machines VM11 and VM12 managed by itself, and the secondary management unit 1 starts the virtual machines VM21 and VM22 managed by itself.

Further, in the running process of each virtual machine, the main management unit 101 and/or the auxiliary management unit 102 having the function of identifying the wake-up source may receive and identify a new wake-up source, and if the virtual machine corresponding to the new wake-up source is already started, the main management unit 101 and/or the auxiliary management unit 102 only needs to send the new wake-up source identification result to the corresponding virtual machine. If none or part of the virtual machines corresponding to the new wake-up source identification result are started, the main management unit 101 and/or the auxiliary management unit 102 starts the virtual machine corresponding to the own management, and sends the new wake-up source identification result to all the virtual machines corresponding to the new wake-up source. If the corresponding virtual machine enters a shutdown state, and the primary management unit 101 and/or the secondary management unit 102 receives that a new wake-up source needs to restart the corresponding virtual machine, the virtual machine may request to restart itself, or the primary management unit 101 and/or the secondary management unit 102 notifies it to restart. When the wake source identification result is not available, the virtual machine may request to be turned off by itself, or the corresponding primary management unit 101 or the secondary management unit 102 notifies the corresponding virtual machine to prepare to be turned off. If the shutdown is time-out, the primary management unit 101 and/or the secondary management unit 102 may force the virtual machine to be shut down.

When all the virtual machines managed by the secondary management unit 102 are in a shutdown state, the secondary management unit 102 may request shutdown from the primary management unit 101. And when the software and hardware resource partition corresponding to the auxiliary management unit 102 is managed, the auxiliary management unit 102 may also request to power down or sleep by itself, so that the auxiliary management unit 102 and/or the software and hardware area corresponding to the virtual machine managed by the auxiliary management unit 102 enter a power down state or a sleep state. For example, as shown in fig. 3, the power management module 1 manages the power-on and power-off of the primary management unit 101 and the secondary management unit 1; the power management module 2 manages the power-on and power-off of the auxiliary management unit 2. The dormancy module 1 manages the dormancy of the main management unit 101 and the auxiliary management unit 1; the dormancy module 2 manages the dormancy of the auxiliary management unit 2. Therefore, the secondary management unit 1 may request power-down or hibernation from the power management module 1 or hibernation module 1 alone; the auxiliary management unit 2 may request the power-off or sleep from the power management module 2 or the sleep module 2 separately; or, the auxiliary management unit 1 may also request the main management unit 102 to power down or sleep, so as to enable the partition corresponding to its own virtual machine and the virtual machine managed by the auxiliary management unit to be in a power down or sleep state. In this embodiment, the specific power-off or sleep request manner of the secondary management unit 102 is not limited. Further, when all the auxiliary management units 102 are in an off state and all the virtual machines managed by the main management unit 101 are also in an off state, the main management unit 101 may request to power down or sleep, so that the microcontroller in which the state control module is located is in a power down state or a sleep state.

It can be seen that the primary management unit 101 and the secondary management unit 102 in the state management module shown in fig. 2 to 3 cooperate with each other and respectively manage the corresponding virtual machines, so that management between the virtual machines is more flexible, and especially when the number of the virtual machines is large and the virtual machines are developed by different suppliers, the development granularity of the state management module and the multiple virtual machines with correlation can better correspond to each other. And the state management module can also start the associated virtual machines to realize the whole vehicle function matched with the plurality of virtual machines, thereby being beneficial to simplifying the design of the awakening source.

Based on the same inventive concept, the embodiment also provides a microcontroller, which comprises a plurality of virtual machines and the state management module; the main management unit 101 manages a part of the auxiliary management units 102 and at least a part of the virtual machines correspondingly, and the rest of the auxiliary management units 102 manage the rest of the virtual machines respectively. Optionally, the primary management unit 101 may manage all the virtual machines, and the secondary management unit 102 is not configured. Alternatively, the primary management unit 101 manages part of the virtual machines, and the remaining part of the virtual machines are managed by one or more secondary management units 102.

Further, the microcontroller further comprises a sleep module. When all the virtual machines are in the off state and all the secondary management units 102 are in the off state, the primary management unit 101 may send a sleep request to the sleep module, so that the microcontroller sleeps. If the software and hardware in the microcontroller can be managed by partitions, the number of the sleep modules is greater than or equal to 2, and when the auxiliary management unit 102 is in the off state, the auxiliary management unit 102 may send a sleep request to the corresponding sleep module, so that the auxiliary management unit 102 and/or the partition in the microcontroller corresponding to the virtual machine managed by the auxiliary management unit 102 is in the off state or the sleep state.

Further, the microcontroller further comprises a virtual machine monitor (Hypervisor). The virtual machine monitor may be used to create and run the virtual machine, as well as to configure the resources required by the virtual machine. When the wake-up source corresponds to a higher access right, the state management module may request a virtual machine monitor to be implemented in cooperation. And the running of part of the processes in the state management module is executed in the virtual machine monitor, and/or the running of part of the processes in the state management module is executed in the virtual machine managed by the virtual machine monitor. Or, the microcontroller further includes a plurality of kernels, and the running of part of the processes in the state management module is executed in the kernels which are not in the monitoring jurisdiction of the virtual machine. The present embodiment does not limit the operation and deployment of the state management module.

Based on the same inventive concept, the embodiment also provides a vehicle-mounted controller. The vehicle-mounted controller comprises a power management module and a plurality of microcontrollers. And the power supply management module is used for managing the power supply of all or part of software and hardware in the vehicle-mounted controller. When all the virtual machines are in the off state and all the auxiliary management units 102 are in the off state, the main management unit 101 may send a power-down request to the power management module, so that the microcontroller is in the power-down state. If the on-board controller executes partition management, the number of the power management modules is greater than or equal to 2, and when the auxiliary management unit 102 is in an off state, the auxiliary management unit 102 may send a power-down request to the corresponding power management module, so that the auxiliary management unit 102 and/or the virtual machine managed by the auxiliary management unit 102 is in a power-down state corresponding to a partition in the microcontroller.

Based on the same inventive concept, the present embodiment further provides a state management method, referring to fig. 4, the state management method includes:

step one S11: the main management unit receives and identifies the awakening source, or the main management unit and part of the auxiliary management units receive and identify the awakening source;

step two S12: the main management unit and/or the auxiliary management unit starts the corresponding virtual machine managed by the auxiliary management unit according to the awakening source identification result;

step three S13: the main management unit and/or the auxiliary management unit and/or the corresponding virtual machine judge whether the awakening source identification result exists or not, if so, the corresponding virtual machine keeps an open state or requests to restart, and if not, the main management unit and/or the auxiliary management unit inform the corresponding virtual machine managed by the main management unit and/or the auxiliary management unit to prepare to close or the corresponding virtual machine requests to close by itself;

step four S14: and the main management unit judges whether all the virtual machines are in a closed state or not and all the auxiliary management units are in a closed state or not, if so, the main management unit sends a power-off request or a sleep request so as to enable the microcontroller to be in a power-off state or a sleep state.

In one embodiment, as shown in fig. 1 and 5, only the master management unit 101 is disposed in the state management module, and the master management unit 101 is responsible for managing the states of all the virtual machines. The method comprises the following specific steps:

step one S21: the main management unit 101 receives and identifies the wake-up source.

The master management unit 101 is powered on. When the wake-up source is received, the main management unit 101 identifies and obtains the wake-up source identification result, determines the virtual machine that needs to be directly started according to the wake-up source identification result, and determines the associated virtual machine that needs to be started according to the functional link corresponding to the wake-up source.

Step two S22: the main management unit 101 starts the virtual machine to be started, and sends the wake-up source identification result to the virtual machine corresponding to the wake-up source identification result. And the corresponding virtual machine runs the related instruction according to the awakening source identification result.

After determining the virtual machines corresponding to the wake-up source identification result, the main management unit 101 needs to determine whether the virtual machines are in an on state, if so, only the wake-up source identification result needs to be sent to the corresponding virtual machines, and if not, the corresponding virtual machines need to be started and the wake-up source identification result is sent to the corresponding virtual machines.

Step three, S23: the main management unit 101 or the started virtual machine automatically determines whether the wake-up source exists, if so, the corresponding virtual machine remains in a start state or requests to restart, and if not, the main management unit 101 notifies the corresponding virtual machine to prepare for shutdown, or the corresponding virtual machine automatically requests to shut down.

When the time for the virtual machine to be closed exceeds the set time, the main management unit 101 directly closes the corresponding virtual machine, or the virtual machine requests to close by itself.

Step four S24: when all the virtual machines are in the off state, the main management unit 101 sends a power-down or sleep request, and the microcontroller is in the power-down or sleep state.

As can be seen, the master management unit 101 implements unified management of states of all the virtual machines, so as to control the corresponding virtual machines to be turned on, restarted, or turned off according to the wake-up source identification result, without requiring self-management of each virtual machine, which can simplify corresponding software design and reduce development cost.

In another embodiment, as shown in fig. 2, 3 and 6, when the state management module includes the primary management unit 101 and a number of the secondary management units 102, and part of the secondary management units 102 have a function of identifying a wake source, and part of the secondary management units 102 do not have a function of identifying a wake source; and, the state of part of the secondary management unit 102 is managed by the primary management unit 101, and the state of the rest of the secondary management unit 102 is self-managed.

Step one, S31: the primary management unit 101 and a part of the secondary management unit 102 receive and identify the wake-up source.

Before receiving and identifying the wake-up source, the primary management unit 101 and all the secondary management units 102 are powered on and started, or the primary management unit 101 is powered on and started and some of the secondary management units 102 are started. When the wake-up source is received, the main management unit 101 and the auxiliary management unit 102 having the identification function identify and acquire the wake-up source identification result, determine the virtual machine that needs to be directly started according to the wake-up source identification result, and determine the associated virtual machine that needs to be started according to the functional link corresponding to the wake-up source.

The primary management unit 101 further sends the wake-up source identification result to the corresponding secondary management unit 102 without the wake-up source identification function.

Step two S32: the main management unit 101 and/or the auxiliary management unit 102 start the corresponding virtual machine managed by itself according to the wake-up source identification result.

When the virtual machines corresponding to the awakening source identification result are managed by the main management unit 101, the main management unit 101 judges whether the virtual machines are all started, if not, the virtual machines which are not started are started, and the awakening source identification result is sent to the corresponding virtual machines; and if so, sending the awakening source identification result to the corresponding virtual machine.

When the virtual machines corresponding to the awakening source identification result are managed by the auxiliary management units 102, each auxiliary management unit 102 judges whether the corresponding virtual machines managed by the auxiliary management unit are all started, if not, the virtual machines which are not started are started, and the awakening source identification result is sent to the corresponding virtual machines; and if so, sending the awakening source identification result to the corresponding virtual machine.

When the virtual machine corresponding to the awakening source identification result is partially managed by the main management unit 101 and partially managed by the auxiliary management units 102, the main management unit 101 and each auxiliary management unit 102 judge whether the corresponding virtual machines managed by the main management unit 101 are all started, if not, the virtual machines which are not started are started, and the awakening source identification result is sent to the corresponding virtual machines; and if yes, sending the wake-up source identification result to the corresponding virtual machine.

Step three, S33: the main management unit 101 and/or the auxiliary management unit 102 and/or the corresponding virtual machine determine whether the wake-up source identification result exists, if so, the corresponding virtual machine remains in an open state or requests to restart, and if not, the main management unit 101 and/or the auxiliary management unit 102 notify the corresponding virtual machine managed by itself to prepare for closing, or the corresponding virtual machine requests to close by itself.

It can be understood that, the main management unit 101 and the auxiliary management unit 102 respectively determine whether the wake-up source exists, and correspondingly manage a shutdown state or a restart state of the virtual machine according to the presence or absence of the wake-up source; or the virtual machine judges by itself to request to close or to request to restart by itself. This embodiment is not particularly limited to this.

When the time for the virtual machine to be closed exceeds a set time, the primary management unit 101 and/or the secondary management unit 102 directly close the corresponding virtual machine, or the virtual machine requests to close by itself.

Step four S34: the auxiliary management unit 102 determines whether the virtual machines managed by the auxiliary management unit are all in a closed state, and if so, the auxiliary management unit 102 requests to close itself or requests to close the main management unit 101.

When all the virtual machines managed by the auxiliary management unit 102 are turned off, the auxiliary management unit 102 collectively managed by the main management unit 101 requests the main management unit 101 to turn off, so that the microcontroller is powered off or in a sleep state. The auxiliary management unit 102 that manages itself may send a power-off request or a sleep request to the corresponding power-off or sleep module, so that the auxiliary management unit 102 and/or the software and hardware resources in the partition where the virtual machine managed by the auxiliary management unit 102 is located are in a power-off or sleep state.

Step five S35: the main management unit 101 determines whether all the virtual machines are in an off state and all the auxiliary management units 102 are in an off state, if so, the main management unit 101 sends a power-off request or a sleep request, and the microcontroller is in a power-off state or a sleep state.

It is understood that, in other embodiments, the primary management unit 101 may only manage the state of the virtual machine under its own responsibility, and all the secondary management units 102 may perform state management by themselves. Alternatively, the primary management unit 101 manages not only the state of the virtual machine in its own responsibility but also the states of all the secondary management units 102. The embodiment is not illustrated, and can be personalized according to management requirements.

It can be seen that, under the mutual cooperation between the main management unit 101 and the auxiliary management unit 102, the virtual machines corresponding to each other are managed respectively, so that the management between the virtual machines is more flexible, and especially when the number of the virtual machines is large and the virtual machines are developed by different suppliers, the development granularity of the state management module and the multiple virtual machines with relevance can better correspond to each other. And the state management module can also start the associated virtual machines to realize the whole vehicle function matched with the plurality of virtual machines, thereby being beneficial to simplifying the design of the awakening source.

It should be noted that, when the virtual machine is started, the virtual machine may be started step by step according to the category of the wake source. Referring to fig. 7, when the primary management unit 101 and/or the secondary management unit 102 receives the wake-up, it is first determined whether the wake-up source is a common wake-up source, if so, all the un-started virtual machines associated with the wake-up source are started, and then other related un-started virtual machines are started based on the functional link; and if not, judging whether the awakening source is a specific awakening source, if so, starting an un-started virtual machine corresponding to the specific awakening source, and if not, starting other related un-started virtual machines based on the functional link.

Similarly, when the virtual machine is closed, the virtual machine can be closed step by step according to the category of the wake source. Referring to fig. 8, the main management unit 101 and/or the auxiliary management unit 102 and/or the virtual machines determine whether the shared wake-up source exists, if not, notify all virtual machines related to the shared wake-up source to be turned off, and then determine whether a specific wake-up exists; if yes, judging whether the specific awakening exists, if so, notifying that the virtual machine which does not need to be used is ready to be closed based on the functional link and each virtual running condition, and if not, notifying that the specific virtual machine corresponding to the specific awakening source is ready to be closed. Then, it is determined whether the notified virtual machines are all ready or request a timeout, e.g., the virtual machines ready to close or request a timeout are closed. Further, in the process of closing the virtual machine, the virtual machine can automatically determine whether the wake-up source exists.

Based on the same inventive concept, the present embodiment also provides a computer program comprising instructions for executing the state management method when the computer program is executed on a suitable computer device.

Based on the same inventive concept, the present embodiment also provides a computer-readable storage medium on which the computer program is encoded.

In summary, the present embodiment provides a status management module and method, a microcontroller, and a vehicle-mounted controller. The state management module is used for carrying out unified management on the states of the virtual machines, the virtual machines do not need to be managed by themselves, corresponding software design can be simplified, and development cost is reduced. The main management unit 101 and the auxiliary management unit 102 cooperate with each other and respectively manage the corresponding virtual machines, so that management between the virtual machines is more flexible, and especially when the number of the virtual machines is large and the virtual machines are developed by different suppliers, the development granularity of the state management module and the plurality of virtual machines with the association can be better corresponded. Furthermore, the state management module can also start the associated virtual machine to realize the whole vehicle function matched with a plurality of virtual machines, and meanwhile, the wake-up source design is facilitated to be simplified.

It should be understood, however, that the intention is not to limit the invention to the particular embodiments described. It will be apparent to those skilled in the art that many changes and modifications can be made, or equivalents employed, to the presently disclosed embodiments without departing from the intended scope of the invention. Therefore, any simple modification, equivalent change and modification made to the above embodiments according to the technical essence of the present invention are still within the protection scope of the technical solution of the present invention, unless the content of the technical solution of the present invention is departed from.

Claims (27)

1. A state management module is characterized by comprising a main management unit; the main management unit manages a plurality of virtual machines, and is used for receiving and identifying the awakening source and managing the state of the corresponding virtual machine according to the awakening source identification result;

or, the state management module comprises the main management unit and a plurality of auxiliary management units; the auxiliary management unit manages a plurality of virtual machines and is used for managing the states of the corresponding virtual machines according to the awakening source identification result; wherein, part of the auxiliary management units are further used for receiving and identifying the awakening source; and the main management unit is also used for managing the state of part of the auxiliary management units.

2. The state management module of claim 1, wherein the states of the virtual machine and the secondary management unit each comprise: start, shut down, or restart.

3. The state management module according to claim 2, wherein when the virtual machine is started, the primary management unit and the secondary management unit are further configured to start the virtual machine that needs to be directly started according to the wake source identification result, and the associated virtual machine that needs to be started based on a functional link.

4. The status management module of claim 1, wherein the primary management unit is further configured to send the wake source identification result to the secondary management unit without wake source identification function.

5. The status management module according to claim 1, wherein the primary management unit and the secondary management unit are further configured to send the wake-up source identification result to the corresponding virtual machine managed by the primary management unit and the secondary management unit.

6. The state management module according to claim 1, wherein the primary management unit and the secondary management unit are further configured to determine whether the wake-up source identification result exists, if yes, the corresponding virtual machine remains in an on state or requests a reboot; if not, informing the corresponding virtual machine managed by the virtual machine to prepare for closing.

7. The status management module according to claim 6, wherein when the time for the virtual machine to be turned off exceeds a set time, the primary management unit and the secondary management unit are further configured to directly request to turn off the corresponding virtual machine, or the virtual machine itself requests to turn off the corresponding virtual machine.

8. The state management module of claim 1, wherein the virtual machine is further configured to determine whether the wake-up source identification result exists by itself; if so, the virtual machine keeps the starting state or requests to restart; if not, the virtual machine automatically requests to close.

9. The status management module according to claim 6 or 8, wherein when the virtual machine is ready to be shut down, the primary management unit or the secondary management unit receives a new wake source and needs to start the corresponding virtual machine, and the primary management unit or the secondary management unit requests a restart for the corresponding virtual machine or requests a restart for the corresponding virtual machine itself.

10. The status management module according to claim 1, wherein when all the virtual machines are in an off state and all the secondary management units are in an off state, the primary management unit is further configured to send a power-down request or a sleep request, so that a microcontroller in which the status management module is located is in a power-down state or a sleep state.

11. The state management module according to claim 1, wherein when all the virtual machines managed by the secondary management unit are in a shutdown state, the secondary management unit is further configured to request for shutdown by itself, or request for shutdown from the primary management unit, or send a power-down request or a hibernation request, so that the virtual machines managed by the secondary management unit and/or the secondary management unit are in a power-down state or a hibernation state corresponding to a partition in a microcontroller.

12. A microcontroller, comprising a plurality of virtual machines and a state management module according to any one of claims 1 to 11; the main management unit correspondingly manages the states of part of the auxiliary management units and the states of at least part of the virtual machines, and the rest auxiliary management units respectively manage the states of the rest of the virtual machines.

13. The microcontroller of claim 12, further comprising a sleep module; when all the virtual machines are in a closed state and all the auxiliary management units are in a closed state, the main management unit is further used for at least sending a sleep request to the sleep module so as to enable the microcontroller to be in a sleep state.

14. The microcontroller according to claim 13, wherein the number of the sleeping modules is greater than or equal to 2, and when the secondary management unit is in an off state, the secondary management unit is further configured to send a sleeping request to at least the corresponding sleeping module, so that the virtual machine managed by the secondary management unit and/or the secondary management unit is in a sleeping state corresponding to a partition within the microcontroller.

15. The microcontroller according to claim 12, wherein a virtual machine monitor is stored in the microcontroller, wherein the operation of part of the processes in the state management module is executed in the virtual machine monitor, and/or the operation of part of the processes in the state management module is executed in the virtual machine managed by the virtual machine monitor.

16. The microcontroller of claim 12 wherein the microcontroller further comprises a plurality of cores and wherein the execution of a portion of the flow in the state management module is performed in cores that are not in the virtual machine monitoring jurisdiction.

17. An on-board controller comprising a power management module and a plurality of microcontrollers according to any one of claims 12 to 16; wherein, the first and the second end of the pipe are connected with each other,

when all the virtual machines are in a closed state and all the auxiliary management units are in a closed state, the main management unit is further configured to send a power-down request to at least the power management module, so that the microcontroller is in a power-down state.

18. The vehicle-mounted controller according to claim 17, wherein the number of the power management modules is greater than or equal to 2, and when the secondary management unit is in the off state, the secondary management unit is further configured to send a power-down request at least to the corresponding power management module, so that the secondary management unit and/or the virtual machine managed by the secondary management unit is in a power-down state corresponding to a partition within the microcontroller.

19. A state management method using the on-vehicle controller according to any one of claims 17 to 18, the state management method comprising:

the method comprises the following steps: the main management unit receives and identifies the awakening source, or the main management unit and part of the auxiliary management units receive and identify the awakening source;

step two: the main management unit and/or the auxiliary management unit starts the corresponding virtual machine managed by the auxiliary management unit according to the awakening source identification result;

step three: the main management unit and/or the auxiliary management unit and/or the corresponding virtual machine judge whether the awakening source identification result exists or not, if so, the corresponding virtual machine keeps an open state or requests to restart, and if not, the main management unit and/or the auxiliary management unit inform the corresponding virtual machine managed by the main management unit and/or the auxiliary management unit to prepare to close or the corresponding virtual machine requests to close by itself;

step four: the main management unit judges whether all the virtual machines are in a closed state and all the auxiliary management units are in a closed state, if so, the main management unit sends a power-off request or a sleep request so as to enable the microcontroller to be in a power-off state or a sleep state.

20. The state management method according to claim 19, wherein before performing step one, the primary management unit and all the secondary management units are powered on; or, the main management unit is powered on and started, and part of the auxiliary management units are started.

21. The status management method according to claim 19, wherein before the step two is executed, and after the step one is executed, the primary management unit sends the wake source identification result to the corresponding secondary management unit without wake source identification function.

22. The method according to claim 19, wherein in the second step, the primary management unit and/or the secondary management unit sends the wake source identification result to the corresponding virtual machine managed by itself while starting the corresponding virtual machine.

23. The method according to claim 19, wherein in step three, when the time for the virtual machine to be turned off exceeds a set time, the primary management unit and/or the secondary management unit directly requests to turn off the corresponding virtual machine, or the virtual machine itself requests to turn off the virtual machine.

24. The method according to claim 19, wherein in the third step, when the virtual machine is ready to be shut down, the primary management unit or the secondary management unit receives a new wake-up source that needs to start the corresponding virtual machine, and the primary management unit or the secondary management unit requests a restart for the corresponding virtual machine or requests a restart for the corresponding virtual machine itself.

25. The method according to claim 19, wherein before the step four is executed and after the step three is executed, the secondary management unit determines whether the virtual machines managed by the secondary management unit are all in a shutdown state, and if so, the secondary management unit requests to shutdown by itself, or requests to shutdown the primary management unit, or sends a power-down request or a sleep request, so that the secondary management unit and/or the virtual machines managed by the secondary management unit are in a power-down state or a sleep state corresponding to the partitions in the microcontroller.

26. A computer program comprising instructions for carrying out the method of any one of claims 19 to 26 when said computer program is executed on a suitable computer device.

27. A computer-readable storage medium, on which a computer program according to claim 26 is encoded.

Images