Hypervisor system operation system domain fault status monitor device

Abstract

The present invention relates to a fault state monitor for an operating system domain of a hypervisor system. The present invention includes a hardware physical layer, an operating system layer consisting of a plurality of different operating systems and control / application software, a hypervisor that allocates basic resources for using the system resources of the hardware physical layer so that the plurality of operating systems operate in a virtual machine environment, and has a function of notifying dependent fault states for a plurality of operating system domains corresponding to the plurality of operating systems constituting the operating system layer, so that the plurality of operating systems operate in a virtual machine environment, and includes a fault state monitor manager having a fault state monitoring function, and the hypervisor collects fault states for each of the plurality of operating system domains via an interface and shares them with the plurality of operating system domains. According to the present invention, a situation occurs in which some operating system domains running on a hypervisor cause a failure, resulting in a cascaded failure phenomenon in which each operating system on the hypervisor cannot operate according to its original specifications, and the remaining operating system domains, especially operating systems with a higher ASIL rating, are unable to operate while satisfying functional safety requirements. This has the effect of solving the problem.

Description

[Technical Field]

[0001] The present invention relates to an operating system domain fault monitoring device for a hypervisor system, and more particularly, to an operating system domain fault monitoring device for a hypervisor system that can prevent a problem in which a physical or logical fault occurs in some operating system domains running on a hypervisor, causing a cascaded failure in the remaining operating system domains running in conjunction with the corresponding operating system domain on the hypervisor, resulting in the failure of the operating system domain to meet system requirements. [Background technology]

[0002] Generally, hypervisor software is software that turns one computer hardware into multiple virtual computer hardware, and designing / developing hypervisor software requires a high level of technology comparable to that used to create general-purpose operating system software such as Windows (registered trademark) and Linux (registered trademark).

[0003] Traditionally, hypervisors have been used to manage computing resources in cloud data centers to streamline hardware and ensure uninterrupted banking services even during operational upgrades.

[0004] It is predicted that the application of hypervisors will expand to cutting-edge devices such as future automobiles, drones, and robots. While the operating system that runs on a conventional hypervisor was a general-purpose operating system like Linux, it is predicted that the operating system that runs on a hypervisor in the future will include a real-time operating system and an operating system that guarantees functional safety, as the fields in which it will be used are real-time systems such as automobiles, drones, and robots. In addition, control / application software that guarantees functional safety will run on an operating system that guarantees functional safety. When such a hypervisor efficiently uses computer hardware to operate multiple operating systems simultaneously, the hypervisor allocates hardware resources for each operating system according to given specifications.

[0005] On the other hand, among hardware resources, input / output devices such as networks, touchscreens, and mice that are commonly used by multiple operating systems on the hypervisor may malfunction and consume more resources than the hardware resources allocated according to the specifications. For example, in such a situation where hardware resources are being used excessively, the hardware resources allocated according to the original specifications for each operating system on the hypervisor may become insufficient, which may cause the operating system to malfunction.

[0006] Future devices such as automobiles, drones, and robots will use real-time operating systems, so if a shortage of hardware resources occurs, the real-time operating system will be unable to provide normal services, which could lead to malfunctions in automobiles, drones, robots, and other systems.

[0007] This problem will be described in more detail with reference to FIGS. 1 and 2.

[0008] FIG. 1 is a diagram illustrating a structure in which control / application software (e.g., AutoSAR) operates on a general-purpose operating system (e.g., Linux®) according to conventional technology, and FIG. 2 is a diagram illustrating an example of a structure in which the control / application software (e.g., AutoSAR) of FIG. 1 is separated and configured on a hypervisor according to the ISO26262 functional safety level ASIL (Automotive Safety Integrity Level) decomposition methodology. Referring to Figure 1, previously, the system in Figure 1 could not be defined at a higher ASIL level (e.g., ASIL-B, ASIL-D, etc.) due to the high complexity of a general-purpose operating system (e.g., Linux). Referring to Figure 2, the ASIL decomposition methodology is applied to the control / application software (e.g., AutoSAR) in Figure 1, and the system is structurally divided into AutoSAR(QM: Quality Management), which does not require an ASIL level, and AutoSAR(ASIL), which does require an ASIL level. In this case, AutoSAR(ASIL) runs on an operating system (e.g., Safety OS) that applies a higher ASIL level, and AutoSAR(QM) runs on a general-purpose operating system.

[0009] In the structure of Figure 2, there was previously no device in the hypervisor to prevent dependent failures between AutoSAR(QM) and AutoSAR(ASIL), which caused problems in applying the ASIL decomposition methodology. [Prior art documents] [Patent documents]

[0010] [Patent Document 1] Korean Patent Publication No. 10-2021-0127427 (Publication date: October 22, 2021, Title: CPU virtualization method and device in multi-core embedded system) [Patent Document 2] Korean Patent Publication No. 10-2021-0154769 (Publication Date: December 21, 2021, Title: Microkernel-Based Extensible Hypervisor) [Patent Document 3] Korean Patent Publication No. 10-2019-0029977 (Publication Date: March 21, 2019, Title: Equipment Control System and Driving Method) [Patent Document 4] Korean Patent Publication No. 10-2015-0090439 (Publication date: August 6, 2015, Title: Scheduling method in a hypervisor of a many-core system) Summary of the Invention [Problem to be solved by the invention]

[0011] The technical objective of the present invention is to prevent a problem that occurs when implementing ASIL decomposition running on a hypervisor, in which a physical or logical failure occurs in some operating system domains, causing a cascaded failure in the remaining operating system domains that were operating in conjunction with the corresponding operating system domain on the hypervisor, resulting in the system being unable to operate while satisfying system requirements.

[0012] In addition, the technical objective of the present invention is to solve the problem that a situation occurs in which some operating system domains running on a hypervisor cause a failure, resulting in a dependent failure phenomenon in which the operating system on the hypervisor cannot operate according to its original specifications, and the remaining operating system domains, especially the operating system with a higher ASIL rating and the control / application software with a higher ASIL rating, do not satisfy the functional safety requirements and cannot operate.

[0013] Various communication channels (e.g., back-end device drivers, front-end device drivers, and logical bus channels) exist between operating system domains on a hypervisor, enabling interdependent operation between the operating systems. A more specific technical object of the present invention is to fundamentally prevent the problem that when a dependent failure occurs between operating system domains, the entire related operating system domain is affected by the failure. [Means for solving the problem]

[0014] In order to solve these technical problems, an operating system domain fault status monitoring device according to an embodiment of the present invention includes a hardware physical layer, an operating system layer consisting of a plurality of different operating systems and control / application software, a hypervisor that allocates basic resources for using system resources of the hardware physical layer so that the plurality of operating systems operate in a virtual machine environment, has a function of notifying dependent fault statuses for a plurality of operating system domains corresponding to the plurality of operating systems constituting the operating system layer, so that the plurality of operating systems operate in a virtual machine environment, and includes a fault status monitor manager having a fault status monitoring function, and the hypervisor collects fault statuses for each of the plurality of operating system domains via an interface and shares them with the plurality of operating system domains.

[0015] In the fault state monitoring device for an operating system domain of a hypervisor system according to the present invention, the system resources include one or more of a CPU (central processing unit) resource, an MCU (microcontroller unit) resource, and a memory resource.

[0016] In the fault status monitoring device for an operating system domain of a hypervisor system according to the present invention, a fault status monitor manager constituting the hypervisor continuously tracks the fault status of an operating system domain through an interface through which the hypervisor collects status information of a specific operating system domain, shares the operating / malfunction status of the associated operating system domain through a hypervisor interface so that the operating / malfunction status can be known, and when a malfunction occurs in an operating system domain of the hypervisor system, notifies the entire system of an event signal, and this notified event signal is transmitted to a user.

[0017] In the fault state monitoring device for an operating system domain of a hypervisor system according to the present invention, the operating system layer includes an operating system having one or more ASIL grades, control / application software having one or more ASIL grades, and one or more general-purpose operating systems. In the fault status monitor device for an operating system domain of a hypervisor system according to the present invention, the fault status monitor manager is characterized in that it registers operating system domains that operate in conjunction with each other via an identification ID assigned to the operating system domain on the hypervisor, and manages the cooperative operation. [Effects of the Invention]

[0018] According to the present invention, a situation occurs in which some operating system domains operating on a hypervisor cause a failure, resulting in a dependent failure phenomenon in which each operating system domain on the hypervisor cannot operate according to its original specifications, and the remaining operating system domains, especially operating systems with a higher ASIL rating, cannot operate while satisfying functional safety requirements. This has the effect of solving the problem. In addition, the fault status information shared by the hypervisor with the operating system domain allows the fault status of individual operating systems in the ASIL decomposition software structure to be known, which has the effect of fundamentally preventing the problem of dependent faults in operating system domains running on the hypervisor. In addition, it has the effect of solving the problem that a situation occurs in which some operating system domains running on the hypervisor cause a failure, resulting in a dependent failure phenomenon in which the operating system on the hypervisor cannot operate according to its original specifications, and the remaining operating system domains, especially the operating system with a higher ASIL rating and the control / application software with a higher ASIL rating, do not meet the functional safety requirements and cannot operate. [Brief explanation of the drawings]

[0019] [Figure 1]1 is a structural diagram of a conventional control / application software (e.g., AutoSAR) running on a general-purpose operating system (e.g., Linux). [Figure 2] 1 is a diagram illustrating an example of a structure in which the control / application software (e.g., AutoSAR) of FIG. 1 is separated and configured on a hypervisor according to the ISO26262 functional safety level ASIL decomposition methodology. [Figure 3] FIG. 2 illustrates a fault status monitor device for an operating system domain of a hypervisor system according to an embodiment of the present invention. [Figure 4] FIG. 2 is a diagram illustrating an example of a hypervisor configuration in an embodiment of the present invention. [Figure 5] FIG. 1 illustrates an example system architecture in which the device driver domain is isolated from the operating system domain in one embodiment of the present invention. [Figure 6] FIG. 1 illustrates an example system architecture in which a device driver domain is merged into an operating system domain in accordance with one embodiment of the present invention. DETAILED DESCRIPTION OF THE INVENTION

[0020] Specific structural or functional descriptions of embodiments according to the inventive concepts disclosed herein are merely illustrative for purposes of describing embodiments according to the inventive concepts, and embodiments according to the inventive concepts may be embodied in a variety of forms and are not limited to the embodiments described herein. Because the embodiments of the inventive concept may be variously modified and may have various forms, the embodiments are illustrated in the drawings and described in detail herein, but it is not intended to limit the embodiments of the inventive concept to the particular disclosed forms, and all modifications, equivalents, or alternatives falling within the spirit and scope of the present invention are included. Unless otherwise defined, all terms, including technical or scientific terms, used herein have the same meaning as commonly understood by a person of ordinary skill in the art to which this invention pertains. Terms defined in commonly used dictionaries should be interpreted to have a meaning consistent with the meaning they have in the context of the relevant art, and should not be interpreted in an idealized or overly formal sense unless expressly defined herein.

[0021] The basic principles of the present invention will be explained first, and then embodiments of the present invention will be explained in detail.

[0022] When the hypervisor 30 efficiently uses computer hardware to simultaneously operate a plurality of operating systems, the hypervisor 30 operates according to the specifications given to each operating system. If a specific operating system domain among multiple operating system domains malfunctions, other operating systems that operate in conjunction with the specific operating system domain will be unable to operate as specified due to a dependent failure according to the specifications, which is a problem that arises.

[0023] On the other hand, devices that will be applied in the future, such as automobiles, drones, and robots, will use a real-time operating system, so if a dependent failure occurs, the real-time operating system will be unable to provide normal services, which could cause systems such as automobiles, drones, and robots to malfunction.

[0024] To solve such dependent failures, the method of applying ASIL decomposition to the hypervisor is as follows.

[0025] The conventional technology lacks a function and interface for sharing state information between multiple operating systems running on the hypervisor 30, and therefore has no way to prevent dependent failures. In other words, with conventional technology, if a malfunction occurs in one of the multiple operating systems on the hypervisor, the other operating systems remain unaware of it. If this problem is linked to software that requires ASIL classification, the problem can become even more severe.

[0026] The present invention solves these problems in the following manner. In other words, in response to the proliferation of autonomous devices such as future automobiles, drones, and robots, future hypervisors 30 will need to support ASIL-level operating systems, so they will need to operate according to predetermined specifications for multiple operating systems on the hypervisor 30. To this end, the present invention provides a mechanism for managing dependent failures by providing a hypervisor function and interface that allows the hypervisor 30 to understand whether the status of multiple operating systems is transmitted and share status information such as normal operation or malfunction with multiple operating systems, and sharing a failure status monitor.

[0027] DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS Hereinafter, preferred embodiments of the present invention will be described in detail with reference to the accompanying drawings.

[0028] FIG. 3 is a diagram showing a fault state monitor device for an operating system domain of a hypervisor system according to an embodiment of the present invention, and FIG. 4 is a diagram showing an example of the configuration of a hypervisor in an embodiment of the present invention.

[0029] 3 and 4, the fault state monitor device for an operating system domain of a hypervisor system according to an embodiment of the present invention includes a hardware physical layer 10, an operating system layer 20, and a hypervisor 30.

[0030] The hardware physical layer 10 is an element constituting a physical device in which a fault state monitor device for an operating system domain of a hypervisor system according to an embodiment of the present invention is implemented. For example, the physical devices constituting the hardware physical layer 10 include a CPU or MCU, memories including dynamic random access memory (DRAM), and input / output devices, and the input / output devices include, but are not limited to, storage, network devices, information output devices including a touch screen, information input devices including a keyboard, a mouse, and serial input / output devices.

[0031] The operating system layer 20 is composed of a plurality of different operating systems and control / application software. For example, the plurality of operating systems constituting the operating system layer 20 may be configured to include one or more ASIL-rated operating systems and one or more general-purpose operating systems such as UNIX, Windows, etc., and the control / application software may be configured to include one or more ASIL-rated software.

[0032] The hypervisor 30 is a component that allocates basic resources for using the system resources of the hardware physical layer 10 for each of the multiple operating system domains corresponding to the multiple operating systems that make up the operating system layer 20, thereby enabling the multiple operating systems to operate in a virtual machine environment.

[0033] In addition, the hypervisor 30 has a function of notifying dependent fault conditions for each of a plurality of operating system domains corresponding to a plurality of operating systems that constitute the operating system hierarchy 20, allowing a plurality of operating systems to operate in a virtual machine environment, and has a fault condition monitoring function.

[0034] In addition, the hypervisor 30 collects fault conditions for each of the operating system domains through an interface and shares the collected fault conditions with the operating system domains. For example, the hypervisor 30 may collect fault conditions by monitoring using a watchdog or by communicating with the operating system layer 20 through an interface, examples of which include shared memory, device driver software, and hypercalls.

[0035] For example, the system resources allocated by the hypervisor 30 to each of the multiple operating system domains may include one or more of CPU resources, MCU resources, and memory resources.

[0036] Referring to the example of FIG. 4, the hypervisor 30 may be configured to include a resource allocator 32, a domain manager 34, an access controller 36, and a failure status monitoring manager 38.

[0037] The resource allocator 32 allocates the amount of system hardware resources such as CPU, memory, etc. for each domain.

[0038] The domain manager 34 schedules the domains in a time-sharing manner according to the amount of resources allocated by the resource allocator 32, and manages context switching during scheduling.

[0039] The access controller 36 controls access between objects such as domains, hardware system resources, data, and the like.

[0040] The fault status monitor manager 38 monitors the status information of each domain, device driver and control / application software, and shares it with all operating systems.

[0041] For example, the fault condition monitor manager 38 can be configured to register the operating system domains that operate in cooperation with each other by using an identification ID given to the operating system domain on the hypervisor 30, and manage the cooperation.

[0042] For example, if the hardware system resource is a CPU resource, one embodiment of the present invention uses a fault condition monitor manager 38 constituting the hypervisor 30 to accurately grasp and manage the status of each operating system domain (e.g., whether or not there is a malfunction), and by sharing the status with the operating system, the operating system domains operating in conjunction with each other can decide whether to continue or discontinue their cooperation. As a result, since it is guaranteed that the operating system domains operate according to specifications when they run on the hypervisor 30, stable ASIL-grade operating system services can be guaranteed.

[0043] Figure 5 is a diagram showing an example of a system architecture in which a device driver domain is isolated from an operating system domain, and Figure 6 is a diagram showing an example of a system architecture in which a device driver domain is merged into an operating system domain.One embodiment of the present invention can be applied in common to the system architectures illustrated in Figures 5 and 6.

[0044] As described above in detail, according to the present invention, a situation occurs in which some operating system domains operating on a hypervisor cause a failure, resulting in a dependent failure phenomenon in which each operating system on the hypervisor cannot operate according to its original specifications, and the remaining operating system domains, especially operating systems with a higher ASIL rating, cannot operate while satisfying functional safety requirements. This has the effect of solving the problem.

[0045] In addition, the fault status information shared by the hypervisor with the operating system domain allows the fault status of individual operating systems in the ASIL decomposition software structure to be known, which has the effect of fundamentally preventing the problem of dependent faults in operating system domains running on the hypervisor.

[0046] In addition, it has the effect of solving the problem that a situation occurs in which some operating system domains running on the hypervisor cause a failure, resulting in a dependent failure phenomenon in which the operating system on the hypervisor cannot operate according to its original specifications, and the remaining operating system domains, especially the operating system with a higher ASIL rating and the control / application software with a higher ASIL rating, do not meet the functional safety requirements and cannot operate. [Explanation of symbols]

[0047] 10: Hardware physical layer 20: Management hierarchy 30: Hypervisor 32:Resource Allocator 34: Domain Manager 36: Access Controller 38: Failure Status Monitoring Manager

Claims

1. A fault state monitor device for an operating system domain of a hypervisor system, comprising: a hardware physical layer; An operating system hierarchy consisting of multiple different types of operating systems and control / application software; a hypervisor that allocates basic resources for using system resources of the hardware physical layer so that the plurality of operating systems operate in a virtual machine environment, and has a function of notifying dependent fault states for each of a plurality of operating system domains corresponding to the plurality of operating systems constituting the operating system layer, and that operates the plurality of operating systems in a virtual machine environment and includes a fault state monitor manager having a fault state monitoring function; The hypervisor collects fault conditions for each of the plurality of operating system domains via an interface and shares the collected fault conditions with the plurality of operating system domains.

2. 2. The fault state monitor device for an operating system domain of a hypervisor system according to claim 1, wherein the system resources include at least one of a central processing unit (CPU) resource, a microcontroller unit (MCU) resource, and a memory resource.

3. A fault condition monitor manager constituting the hypervisor includes:

2. The fault status monitor device for an operating system domain of a hypervisor system according to claim 1, characterized in that it continuously tracks the fault status of an operating system domain through an interface through which the hypervisor collects status information of a specific operating system domain, shares the operating / malfunction status of associated operating system domains through the hypervisor interface so that the operating / malfunction status of the associated operating system domains can be known, and when a malfunction occurs in an operating system domain of the hypervisor system, it notifies the entire system with an event signal, and transmits this notified event signal to a user.

4. 2. The fault state monitor device for an operating system domain of a hypervisor system according to claim 1, wherein the operating system layer includes an operating system having one or more ASIL grades, control / application software having one or more ASIL grades, and one or more general-purpose operating systems.

5. The fault condition monitor manager 2. The fault status monitor device for an operating system domain of a hypervisor system according to claim 1, characterized in that it registers operating system domains that operate in cooperation with each other via an identification ID given to the operating system domain on the hypervisor and manages the cooperation operation.

Images