METHOD FOR MONITORING AND CONTROLLING SYSTEM RESOURCES OF AN OPERATING SYSTEM

Abstract

The invention relates to a method for monitoring and controlling system resources of an operating system, wherein the method comprises at least the following steps in the order stated: a. by means of the control unit, execution of at least one program on the operating system; b. by means of the monitoring unit, detection of at least one resource consumption claimed by the at least one program; c. by means of the comparison unit, comparison of the resource consumption detected in step b. with a limit value maintained by means of the storage device; and, if the limit value is exceeded as detected in step c.: d. by means of the coordination unit, determination of the criticality of the resource consumption with respect to the system resources of the operating system; e. by means of the coordination unit, setting a maintenance schedule for the program based on the criticality determined in step d.; and f.The invention relates to a method for monitoring and controlling system resources of an operating system, which enables uninterrupted use by a user during maintenance and yet ensures stable operation of the operating system.

Description

The invention relates to a method for monitoring and controlling system resources of an operating system, to an operating system having such a method for controlling components of a motor vehicle, and to a motor vehicle having such an operating system having an operating system.It is known from industrial practice to monitor the system resources of an operating system by means of a monitoring unit. For example, such a monitoring unit monitors how much working memory and what processor power a program is using, which is executed on the operating system. If abnormality is detected, for example, the exceeding of certain limit values, the program is ended and restarted in order to remedy the fault and stabilize the operating system.In particular in motor vehicles, certain programs are indispensable or their failure severely impairs the user.Such a method may result in a program being ended which a user or a usage unit would like to use at the moment or in the near future, so that the program is not available at the desired time.Proceeding from this, the object of the present invention is to overcome at least partially the disadvantages known from the prior art. The features according to the invention are evident from the independent claims, for which advantageous embodiments are shown in the dependent claims. The features of the claims can be combined in any technically expedient manner, wherein the explanations from the following description and features from the figures, which comprise supplementary configurations of the invention, can also be used for this purpose.The invention relates to a method for monitoring and controlling system resources of an operating system, wherein the operating system is executed on a computing device with a monitoring unit, a comparison unit, a coordination unit and a control unit, wherein system resources are provided by the computing device, and the computing device has at least the following components:a processor for executing the operating system; anda storage device for maintaining the operating system, wherein the method comprises at least the following method steps in the order mentioned: a. by means of the control unit, executing at least one program on the operating system; b. by means of the monitoring unit, detecting at least one resource consumption which is occupied by the at least one program; c. by means of the comparison unit, comparing the resource consumption detected in step b. with a limit value which is held by means of the storage device; and if the limit value is exceeded as determined in step c.d. by means of the coordination unit, determining a criticality of the resource consumption with respect to the system resources of the operating system;e. by means of the coordination unit, defining a maintenance timing for the program on the basis of the criticality determined in step d.; andf. by means of the control unit, carrying out the maintenance according to the maintenance timing determined in step e.In the following, reference is made to the mentioned rotational axis if, without explicit reference to the other, the axial direction, radial direction or the circumferential direction and corresponding terms are used. Ordinal numbers used in the preceding and following description, unless expressly stated to the contrary, serve only for the clear distinguishability and do not represent an order or ranking of the designated components. An ordinal number greater than one does not require that a further such component must necessarily be present.A method for monitoring and controlling system resources of an operating system is now proposed here.The operating system comprises a monitoring unit, a comparison unit, a coordination unit and a control unit. The monitoring unit is configured to detect a system resource consumption of a program. For example, the monitoring unit thus detects how much working memory or processor power a specific program consumes. The comparison unit is configured to compare the detected resource consumption with a limit value. The coordination unit is configured to determine a criticality of resource consumption with respect to the system resources of the operating system, and set a maintenance timing based on the criticality. The control unit is configured to perform maintenance, for example to end the program and restart it.The operating system is executed on a computing device that includes at least one processor and a storage device.The method comprises at least the following steps in the order mentioned: a. executing at least one program on the operating system by means of the control unit; b. by means of a monitoring unit, detecting at least one resource consumption which is occupied by the at least one program; c. by means of a comparison unit, comparing the resource consumption detected in step b. with a limit value held by means of the storage device; d. in the event of the limit value being exceeded determined in step c., determining, by means of the coordination unit, a criticality of the resource consumption with respect to the system resources of the operating system; e. by means of the coordination unit, establishing a maintenance timing for the program on the basis of the criticality determined in step d.; and f. by means of the control unit, carrying out the maintenance at the maintenance timing determined in step e.It should be noted that step a. is continuous while step b. and step c. are being performed, preferably while steps b. to e. are being performed.The proposed method thus makes it possible to define a maintenance timing for maintenance of a program. Thus, the maintenance is not necessarily carried out directly when a abnormality, for example, exceeding a limit value, is detected in the resource consumption of the program. Thus, it is possible to wait the program when it is not needed or use by a user or a use unit is unlikely.In step a., a program is executed on the operating system by means of the control unit. Such a program is, for example, a navigation program, a communication program, or a medium playback program. Errors or disturbances may occur during the course of execution of the program. Such disturbances lead, for example, to the memory requirement or the required computing power of the program increasing. These resources may lack other programs running on the operating system, thus causing the operating system to no longer run stably or too slowly. The program itself also runs so slowly, if necessary, that certain functions can no longer be used at all or can only be used very slowly.In a step b, the monitoring unit monitors or records the resource consumption that is being claimed by the at least one program. Step b. is carried out continuously or at certain time intervals.In a step c., the resource consumption determined in step b. by means of the comparison unit is compared with a limit value. The limit value is stored by means of the storage device. If necessary, the comparison unit detects that the limit value has been exceeded.If it is determined in step c. that the resource consumption does not exceed the limit value, preferably no maintenance is provided and step b. is carried out again in order to determine an updated resource consumption for the program.If in step c. the comparison unit establishes that the limit value is exceeded, the criticality of the resource consumption is determined by means of the coordination unit in a step d. The criticality specifies how critical the resource consumption of the at least one program is with respect to the system resources of the operating system. In other words, it is determined whether the increased resource consumption of the at least one program jeopardizes the speed and / or stability of the operating system and / or renders the at least one program unusable (at least in some functions). For example, the criticality is determined only on the basis of the resource consumption, on the basis of the resource consumption and a corresponding total system resource of the operating system and / or on the basis of the still free resource capacities of the operating system. For example, the resource consumption of the at least one program is compared with established comparison values and the criticality is thus established stepwise on the basis of the respectively exceeded comparison values. Alternatively or additionally, the criticality is determined based on a difference or a ratio of the resource consumption of the at least one program and the corresponding total system resource or the remaining resource capacity of the operating system.On the basis of the criticality ascertained in step d., a maintenance timing for the program is established in a step e. Preferably, the maintenance timing includes a time at which the maintenance of the program is executed, a time period after which the maintenance of the program is executed, and / or a trigger event after which the maintenance of the program is executed. For example, the maintenance of the program is carried out immediately, i.e. immediately, if the criticality exceeds a specific comparison value and thus the stability and / or speed of the operating system is influenced too much by the program.In a step f., the maintenance of the program is executed at the maintenance timing set in the step e.As explained, the maintenance in step f. is therefore carried out either directly or at a later point in time. The later point in time is preferably a point in time at which the program is no longer active, particularly preferably when the operating system is in an idle mode, for example because the motor vehicle has been switched off or the IoT device is in a standby mode. If, however, it has been determined in steps b. to d. that the criticality is too high for the operating system and thus, for example, its stability is endangered, the program is immediately maintained, i.e., as long as the program or the operating system is in an active mode, for example, before the program has been ended by a user, the operating system changes to an idle mode, the motor vehicle has been switched off, or the IoT device has been placed in a stand-by mode.A plurality of programs are preferably executed in parallel on the operating system. In steps b. to f., the programs are preferably each checked separately. The method can be executed separately for each program executed on the operating system or managed by the operating system or for each program of a specific class or group of programs. Alternatively or additionally, a plurality of programs, for example of a specific class or group of programs, are combined in order to be checked together according to steps b. to e. and, if appropriate, to be maintained according to step f. Preferably, a separate limit value is provided for each step b. per program or program class. Preferably, different criteria are set for each program or each program class, for example comparison values, for determining the criticality and defining the maintenance timing in step d. and step e.The proposed method offers the advantage that programs are not terminated undesirably or unexpectedly and nevertheless stable and liquid operation of the operating system is made possible.In an advantageous embodiment of the method, it is furthermore proposed that the operating system is an operating system of an Internet of Things device (IOT device) and / or of a motor vehicle.In the case of Internet of Things devices (IOT devices) and motor vehicles, omission of certain programs and / or functionalities at undesired times is particularly critical. Thus, the method proposed here, which enables a timing of the maintenance of the programs, is particularly advantageous.It is furthermore proposed in an advantageous embodiment of the method that the resource consumption comprises at least one from the following list:- memory requirement;computing power;- Memory requirement;ping times; andtime required by the program to process a particular task.The resource consumption indicates, for example, how high the consumption of a particular system resource provided by the computing device by the program is. For example, such resource consumption is a memory requirement, for example on a hard disk, a computing power, for example of the main processor, graphics processor and / or other processors, a memory requirement on the memory of the computing device, a ping time and / or a time required by the program to process a specific task.It is furthermore proposed in an advantageous embodiment of the method that the system resource comprises at least one from the following list:- storage capacity;- capacity of computing power;- working memory;comparison ping times; andcomparison processing times for a task.The system resource is thus, for example, a storage capacity, a capacity of the computing power, a working memory, a comparison ping time and / or a comparison processing time for a task. For example, in step d. the criticality is thus determined by comparing the memory requirement of the program with the memory capacity of the computing device or of the operating system, respectively, the combined computing power of the program with the capacity of the computing power of the processor, the memory requirement of the program with the memory of the computing device, ping times with comparison ping times, and times required by the program for processing a task with comparison processing times for the task, which are held on the memory device, for example.It is furthermore proposed in an advantageous embodiment of the method that in step e. the maintenance timing determines a later inactive time if the criticality falls below a comparison value; and / or in step e. the maintenance timing determines an immediate active time if the criticality exceeds a comparison value.According to this embodiment, it is proposed that in step e. the maintenance timing is set to a later inactive time, i.e. the maintenance is not carried out directly or immediately if the criticality falls below a comparison value. If it is thus established by means of the coordination unit that the program does not influence the stability or speed of the operating system in such a way that immediate maintenance of the program is necessary, the described later inactive time is selected for the maintenance. As already explained, the later inactive point in time preferably lies in a period of time in which the operating system is in an idle mode, the motor vehicle is switched off and / or the IoT device is in a standby mode.Accordingly, for example, an immediate active time for maintenance is established if the criticality exceeds a specific comparison value and the coordination unit recognizes, for example, that too high a load for the stability and / or speed of the operating system arises from the continued operation of the program. In this case, the maintenance is carried out immediately, i.e. for example without waiting for a change in the operating state of the IOT device or motor vehicle, preferably within a few milliseconds, seconds and / or after a user query.It is furthermore proposed in an advantageous embodiment of the method that the later inactive point in time is at least one point in time from the following list:a point in time at which the program is no longer executed on the operating system;a time at which the operating system is in an idle mode;a time at which the ignition of the motor vehicle is switched off;a time at which a user uses the motor vehicle and / or the program rarely or never according to the user profile thereof;a specific time of day point; anda specific time of the week.The later inactive point in time is therefore, for example, a point in time at which the program is no longer executed on the operating system, at which the operating system is in an idle mode, at which the ignition of the motor vehicle is switched off, at which a user, according to the user profile thereof, uses the motor vehicle, the IOT device and / or the program never or rarely, uses a specific time of day and / or a specific time of week.Preferably, the later inactive time is selected or determined based on criticality. For example, in the case of a medium-high criticality, the next time of day is taken. At a higher criticality to the next deactivation of the motor vehicle and at a lower criticality to a week time. Alternatively or additionally, the maintenance timing is preferably defined based on a classification of the program. For example, the programs managed by the operating system are classified according to which consequences the program fails or how important they are to the user in certain situations, preferably the current situation. For example, certain programs are very important or absolutely necessary for driving and may only be ended or restarted if the motor vehicle is not used quite safely. Other programs, for example concerning music reproduction, are less important. Depending on the classification of the program and the current driving situation, different maintenance timings can also be selected. For example, the navigation system can be maintained when the driver is on his daily working path, since he does not require the navigation system in such a driving situation.In the present case, a rare use of the program is to be understood as meaning that the program is used less frequently at specific times than at other times. For example, the program is used rarely at night or on weekend. The underlying usage behavior is, for example, user-specific, preferably stored in a user profile, or part of a larger data set, for example a fleet of vehicles. For example, the setting of the maintenance timing is based on user requests for all programs, specific program classes or individual programs that are set in advance.It is furthermore proposed in an advantageous embodiment of the method that, when the maintenance timing is established in step e., a user query is carried out in which the proposed maintenance timing can be confirmed or rejected by the user or can be selected by the user of one of a plurality of proposed maintenance timings.According to this embodiment, for example, the user is allowed to select one of a plurality of times for maintenance timing. For example, a time interval is determined by means of the coordination unit on the basis of the criticality of the resource consumption of the program. In such a time interval, for example, a plurality of possible times for the maintenance timing can be determined, for example times at which a particularly low probability for the use of the program or motor vehicle is present. A list of the possible times can be displayed to the user, for example, via a user interface and / or a mobile terminal, so that he can select a desired time for the maintenance timing. For example, starting the maintenance can also be indicated or queried by a reminder or an additional query at the user, for example, via a mobile terminal. For example, a confirmation query on the mobile terminal can be displayed to the user that the maintenance is pending at the defined maintenance timing. The user can confirm by means of the mobile terminal that he (still) is in agreement with the maintenance timing, for example because the user no longer schedules the use of the corresponding IOT device or motor vehicle on the day or evening.It is furthermore proposed in an advantageous embodiment of the method that the maintenance in step f. comprises terminating and restarting the program.According to this embodiment, it is now proposed that the maintenance of the program comprises an ending and a restarting of the program. For example, maintenance consists of ending and restarting the program in order to empty the working memory and / or reset program settings.According to a further aspect, an operating system for controlling components of a motor vehicle is proposed, wherein the operating system is designed to carry out a method according to one embodiment as described above and comprises at least the following units:a monitoring unit;a comparison unit;a coordination unit;a control unit.An operating system is now proposed here which is designed to execute the method described above. Such an operating system comprises a monitoring unit, a comparison unit, a coordination unit and a control unit. In this case, the monitoring unit, the comparison unit, the coordination unit and the control unit are not to be understood as apparatuses which are each designed physically, but rather as functional units.The monitoring unit is designed to monitor a resource consumption which is claimed by a program. Step b. of the method is therefore to be carried out.The comparison unit is designed to compare the resource consumption detected by means of the monitoring unit with a limit value which is held on the storage device, for example. Step c. of the method is therefore to be carried out.The coordination unit is designed to determine, by means of the comparison unit, the criticality of the resource consumption with respect to the system resources of the operating system when the limit value is exceeded is established, and to determine a maintenance timing on the basis of this criticality. Step d. and step e. of the method are therefore to be carried out.The control unit is designed to execute the program and to carry out the maintenance of the program, preferably ending and restarting of the program. Step a. and step f. of the method are therefore to be carried out.According to a further aspect, a motor vehicle having an operating system according to one embodiment as described above is proposed, wherein the motor vehicle has at least the following components:a drive unit for providing a drive torque;at least one propulsion wheel in a torque-transmitting connection with the drive unit; anda computing device for executing the operating system.A motor vehicle having the operating system described above is now proposed here.The motor vehicle has at least one drive unit, a propulsion wheel, a storage device and a computing device.The drive unit is, for example, an internal combustion engine and / or an electric drive machine. The drive unit is designed to provide a drive torque for the motor vehicle.The at least one propulsion wheel is in torque-transmitting connection with the drive unit, for example by means of a transmission and / or a clutch. Preferably, at least two or four propulsion wheels are provided.The computing device comprises at least one memory device and a processor. The computing device is configured to execute the operating system and the programs managed by the operating system.The term computing device is used here, for example, equivalently to the term computer known to the person skilled in the art. A computer thus comprises one or more processors, for example general purpose processors (CPU) or microprocessors, RISC processors, GPU and / or DSP. The computer has, for example, additional elements such as memory interfaces or communication interfaces. Such a computing device is capable of executing a provided or incorporated program, preferably with a standardized programming language (for example C++, JavaScript or Python) and / or of controlling and / or accessing data storage devices and / or other devices such as input interfaces and output interfaces. The term computer also refers to a plurality of processors or a plurality of (sub)computers that are interconnected and / or otherwise communicatively connected to one another via physical lines and may possibly share one or more other resources, such as a storage device. A storage device is, for example, a hard disk drive (HDD) or a (non-volatile) solid-state memory, for example a ROM memory or flash memory [flash EEPROM]. The storage device often comprises a plurality of individual physical units or is distributed to a plurality of separate devices such that access thereto takes place via data communication, for example package data service. The latter is a decentralized solution, wherein the storage device and processors of a plurality of separate computers are used instead of a (single) central server or in addition to a central server.The invention described above is explained in detail below in view of the relevant technical background with reference to the associated drawings, which show preferred embodiments. The invention is in no way limited by the purely schematic drawings, it being noted that the drawings are not dimensionally accurate and are not suitable for defining size ratios. It is shown in FIG. 1 : Flow diagram of a method for monitoring and controlling system resources of an operating system; FIG. 2 is a time-chart of the method for monitoring and controlling system resources of an operating system; and FIG. 3 : shows a motor vehicle having a computing device.Referring now to FIG. 1, a flowchart of a method for monitoring and controlling system resources of an operating system is shown. The operating system comprises a monitoring unit, a comparison unit, a coordination unit and a control unit. The monitoring unit is configured to detect a system resource consumption of a program. For example, the monitoring unit thus detects how much working memory or processor power a specific program consumes. The comparison unit is configured to compare the detected resource consumption with a limit value. The coordination unit is configured to determine a criticality of resource consumption with respect to the system resources of the operating system and to set a maintenance timing based on the criticality. The control unit is configured to perform maintenance, for example to end the program and restart it. The operating system is preferably an operating system of a motor vehicle 4 and / or IoT device.Shown symbolically is an idle mode 7 and an active mode 10 of an operating system. In Active mode 10, the operating system is in an active state and at least one program is executed on the operating system. For example, a motor vehicle 4 is started or ignited with the operating system or an IoT device with the operating system is in a switched-on state. In idle mode 7, the operating system in the operating system is not in an active state and preferably no program is executed. For example, the motor vehicle 4 is switched off or the ignition is turned off or the IoT device is in a standby mode.In step a., at least one program is therefore executed on the operating system by means of the control unit. Such a program is, for example, a navigation program, a communication program, or a medium playback program. Errors or disturbances may occur during the course of execution of the program. Such disturbances lead, for example, to the memory requirement or the required computing power of the program increasing. These resources may lack other programs running on the operating system, thus causing the operating system to no longer run stably or too slowly. The program itself also runs so slowly, if necessary, that certain functions can no longer be used at all or can only be used very slowly.According to the illustrated method, it is now checked, preferably continuously, as long as the program is executed, how high the resource consumption of the program is. Based on this, it is determined whether the resource consumption of the program is increased in certain areas and / or whether and / or how much the resource consumption of the program has an effect on the operating system or its performance. If the resource consumption affects the performance of the operating system or if it affects to a critical extent, the program is directly maintained, i.e., it is still waiting in the active mode 10, i.e., it is ended and restarted, for example. If the resource consumption does not affect the performance of the operating system, or does not affect it to a critical extent, the maintenance of the program is shifted to a point in time in idle mode 7. A maintenance timing is therefore defined on the basis of the criticality, which is either in idle mode 7 or in active mode 10.For this purpose, the resource consumption which is claimed by the at least one program is monitored or detected by means of the monitoring unit in a step b. Step b. is carried out continuously or at certain time intervals.In a step c., the resource consumption determined in step b. by means of the comparison unit is compared with a limit value. The limit value is stored by means of the storage device 3. If necessary, the comparison unit detects that the limit value has been exceeded.If it is determined in step c. that the resource consumption does not exceed the limit value, no maintenance is provided and step b. is carried out again in order to determine an updated resource consumption for the program.If in step c. the comparison unit establishes that the limit value is exceeded, the criticality of the resource consumption is determined by means of the coordination unit in a step d. The criticality specifies how critical the resource consumption of the at least one program is with respect to the system resources of the operating system. In other words, it is determined whether the increased resource consumption of the at least one program jeopardizes the speed and / or stability of the operating system and / or renders the at least one program unusable (at least in some functions).On the basis of the criticality ascertained in step d., a maintenance timing for the program is established in a step e. Here, the maintenance timing includes a time point at which the maintenance of the program is executed, a time period after which the maintenance of the program is executed, and / or a trigger event after which the maintenance of the program is executed. For example, the maintenance of the program is executed immediately when the criticality exceeds a specific comparison value and thus the stability and / or speed of the operating system is influenced too much by the program. The maintenance timing is thus placed, as already explained, in the idle mode 7 if the criticality is below a specific comparison value, or in an active mode 10 if the criticality exceeds the specific comparison value. The comparison value is, for example, a predefined, fixed value for the respective resource consumption or, for example, dependent on resource capacities of the operating system for the respective resource.In a step f., the maintenance of the program is executed at the maintenance timing set in the step e. If the criticality is within the determined comparison value, i.e., not so critical that a direct system crash threatens, the maintenance is carried out during idle mode 7, i.e., at a later inactive point in time 6, as represented by step f 2. For example, the idle mode 7 or the later inactive point in time 6 is a state of travel in which the motor vehicle 4 is stationary for a longer period of time.Alternatively, the maintenance is carried out directly, i.e. at an immediate active time 5, as shown in step f 1, if the criticality exceeds the determined comparison value.It should be noted that step a. is continuous while step b. and step c. are being performed, preferably while steps b. to e. are being performed.In FIG. 2, a time-line 13 of the method for monitoring and controlling system resources of an operating system is shown. The time-ray 13 shown here and the following description make reference, without exclusion of generality, to the method which is illustrated in the flow chart in FIG. 1, insofar reference is made to the description there. As shown, maintenance timing is divided into two different modes. On the left, the active mode 10 is shown in unshaded form, i.e. it proceeds first. According to the illustration to the right next to it, as running subsequently in time, the idle mode 7 is shown shaded.According to the illustration, steps a. to e. explained above thus proceed in the active mode 10. During the active mode 10, an exceeding of the limit value for a resource consumption of a program of the operating system is determined at a fault time 14 in step b. or step c. If it is determined in steps d. and e. on the basis of the explained criteria that a resource consumption of a program is critical, for example because the criticality exceeds a specific comparison value, according to step f 1 the maintenance of the program is carried out directly in the active mode 10, at the immediate active time 5.If it is determined that although the resource consumption of the program exceeds a certain limit value, it is not critical, the maintenance is shifted to a later inactive time 6 in idle mode 7.The proposed method thus makes it possible to define a maintenance timing for maintenance of a program. Thus, the maintenance is not necessarily carried out directly when a abnormality, for example, exceeding a limit value, is detected in the resource consumption of the program. Thus, it is possible to wait the program when it is not needed or use by a user or a use unit is unlikely.FIG. 3 shows a motor vehicle 4 with a computing device 1 in a schematic plan view. The computing device 1 comprises a processor 2 and a storage device 3. An operating system can be operated on the computing device 1, which is stored on the computing device 1 and can be executed by means of the processor 2. The computing device 1 is configured to execute the method for monitoring and controlling system resources of the operating system. The motor vehicle 4 additionally comprises purely optionally two electric drive units 8, which are configured to provide a drive torque. The drive torque is transmitted, for example, via a transmission 11 and a differential 12 to propulsion wheels 9, as shown by way of example on the front axle. Of the propulsion wheels 9, a propulsion wheel 9 is provided with a reference sign here (pars-pro-toto).The invention relates to a method for monitoring and controlling system resources of an operating system, wherein the method has at least the following method steps in the order mentioned: a. by means of the control unit, executing at least one program on the operating system; b. by means of the monitoring unit, detecting at least one resource consumption which is claimed by the at least one program; c. by means of the comparison unit, comparing the resource consumption detected in step b. with a limit value which is held by means of the storage device; and if the limit value is exceeded as determined in step c.d. by means of the coordination unit, determining a criticality of the resource consumption with respect to the system resources of the operating system;e. by means of the coordination unit, defining a maintenance timing for the program on the basis of the criticality determined in step d.; andf. by means of the control unit, carrying out the maintenance according to the maintenance timing determined in step e.The invention relates to a method for monitoring and controlling system resources of an operating system which enables use by a user undisturbed by maintenance and nevertheless ensures stable operation of the operating system.List of reference characters1 Computing device 2 Processor 3 Storage device 4 Motor vehicle 5 Immediate active time point 6 Later inactive time point 7 Idle mode 8 Drive unit 9 Propulsion wheel 10 Active mode 11 Transmission 12 Differential 13 Time beam 14 Fault time point

Claims

Method for monitoring and controlling system resources of an operating system, wherein the operating system is executed with a monitoring unit, a comparison unit, a coordination unit and a control unit on a computing device (1), wherein system resources are provided by the computing device (1), and the computing device (1) has at least the following components: - a processor (2) for executing the operating system; and - a storage device (3) for maintaining the operating system, wherein the method has at least the following method steps in the order mentioned: a. by means of the control unit, executing at least one program on the operating system; b. by means of the monitoring unit, detecting at least one resource consumption which is claimed by the at least one program; c. by means of the comparison unit, comparison of the resource consumption detected in step b. with a limit value which is held by means of the storage device (3); and if the limit value is exceeded as determined in step c.: d. by means of the coordination unit, determination of a criticality of the resource consumption with respect to the system resources of the operating system; e. by means of the coordination unit, setting a maintenance timing for the program on the basis of the criticality determined in step d.; and f. by means of the control unit, carrying out the maintenance in accordance with the maintenance timing determined in step e.Method according to Claim 1, wherein the operating system is an operating system of an Internet of Things device (IOT device) and / or of a motor vehicle (4).The method of claim 1 or claim 2, wherein the resource consumption comprises at least one of the following list: - memory requirement; - computing power; - memory requirement; - ping times; and - time required by the program to handle a particular task.The method according to any of the preceding claims, wherein the system resource comprises at least one of the following list: - storage capacity; - capacity of computing power; - working memory; - comparison ping times; and - comparison processing times for a task.Method according to one of the preceding claims, wherein in step e. the maintenance timing determines a later inactive time (6) if the criticality falls below a comparison value; and / or in step e. the maintenance timing determines an immediate active time (5) if the criticality exceeds a comparison value.Method according to one of the preceding claims, wherein the later inactive point in time (6) is at least one point in time from the following list: - a point in time at which the program is no longer executed on the operating system; - a point in time at which the operating system is in an idle mode (7); - a point in time at which the ignition of the motor vehicle (4) is switched off; - a point in time at which a user, according to the user profile thereof, uses the motor vehicle (4) and / or the program rarely or never; - a specific time of day; and - a specific time of week.Method according to one of the preceding claims, wherein, when the maintenance timing is established in step e., a user query is carried out in which the proposed maintenance timing can be confirmed or rejected by the user or one of a plurality of proposed maintenance timings can be selected by the user.Method according to one of the preceding claims, wherein the maintenance in step f. comprises ending and restarting the program.Operating system for controlling components of a motor vehicle (4), wherein the operating system is designed to carry out a method according to one of the preceding claims and comprises at least the following units: - a monitoring unit; - a comparison unit; - a coordination unit; - a control unit.Motor vehicle (4) with an operating system according to Claim 9, wherein the motor vehicle (4) has at least the following components: - a drive unit (8) for providing a drive torque; - at least one propulsion wheel (9) which is in a torque-transmitting connection with the drive unit (8); and - a computing device (1) for executing the operating system.

Images