MONITORING OF A PROCESSING SYSTEM

Abstract

A processing system is configured to dynamically carry out processes. A method for monitoring the processing system includes steps of determining a number of processes running on the processing system; of determining a maximum expected number of processes; of determining that more processes than expected are running; and of deactivating the processing system.

Claims

1. A method for monitoring a processing system which is configured to dynamically carry out processes, the method comprising: determining a number of processes running on the processing system; determining a maximum expected number of processes; determining that more processes than expected are running; and deactivating the processing system.

2. The method as recited in claim 1, further comprising: determining system rights of the running processes; comparing the determined system rights with predetermined system rights; determining that one of the running processes has obtained extended system rights; and deactivating processing system.

3. The method as recited in claim 1, wherein the deactivation includes the resetting of the processing system.

4. The method as recited in claim 3, wherein the resetting includes carrying out a software resetting request.

5. The method as recited in claim 3, wherein the processing system includes a processing unit and a monitoring circuit, and the deactivation is controlled by the monitoring circuit.

6. The method as recited in claim 1, wherein the method is carried out periodically.

7. The method as recited in claim 5, wherein the monitoring circuit includes a watchdog timer, which, when running, deactivates the processing system, the timer being set to a predetermined value if the processing system is not to be deactivated.

8. The method as recited in claim 1, wherein the processing system includes a communication interface, and the deactivation includes a switching-off of the communication interface.

9. The method as recited in claim 1, wherein one of the processes is assigned multiple lightweight processes and the processing system is deactivated if a number of lightweight processes exceeds an expected maximum number of lightweight processes.

10. A non-transitory computer readable storage medium on which is stored program code for monitoring a processing system which is configured to dynamically carry out processes, the program code, when executed by a processing unit, causing the processing unit to perform: determining a number of processes running on the processing system; determining a maximum expected number of processes; determining that more processes than expected are running; and deactivating the processing system.

11. A processing system configured to carry out dynamic processes, the processing system configured to monitor the processes and to determine a number of processes running on the processing system, determine a maximum expected number of processes, determine that more processes than expected are running, and deactivate the processing system.

Description

BRIEF DESCRIPTION OF THE DRAWINGS

[0023] The present invention is described in greater detail below with reference to the figures.

[0024] FIG. 1 shows a processing system, in particular, for use on board a motor vehicle.

[0025] FIG. 2 schematically shows a representation of a process, which runs on a processing system in an operating system.

[0026] FIG. 3 schematically shows a representation of a processing system including an external watchdog timer.

[0027] FIG. 4 shows a flow chart of a method for controlling a processing system.

DETAILED DESCRIPTION OF EXAMPLE EMBODIMENTS

[0028] FIG. 1 shows a processing system 100, in particular, for application on board a motor vehicle. Processing system 100 is configured to carry out a control task on board the motor vehicle. Processing system 100 preferably includes a control unit 105, which is preferably connected to one or multiple sensors 110, and further preferably includes a communication interface 115 for communication with another unit, such as an additional control unit 105 or with a user interface. The communication with communication interface 115 and/or sensors 110 may take place, for example, with the aid of a network 120. As the implementing unit, control unit 105 includes one or multiple processing units 125, each of which may be implemented by a programmable microcomputer or a CPU having one or multiple cores. An operating system 130 preferably runs on each processing unit 125, whereby one operating system 130 may also span multiple processing units 125.

[0029] Processing system 100 is configured to dynamically carry out processes 135. Processes 135 may be dynamically started and terminated, whereby the starting may take place through the operating system 130, through another process 135 or on the basis of, for example, a chronological event. Each process 135 may include one or multiple lightweight processes (threads) 140. In this case, all threads 140 of a process 135 normally run as user threads in the same environment and with the same operating means that are assigned to higher-level process 135.

[0030] A process 135 may carry out, in particular, a control task, whereby a surroundings variable may be scanned with the aid of a sensor 110, the result may be processed and an actuator, which normally directly or indirectly retroacts on sensor 110, may be actuated with the aid of communication interface 115.

[0031] In order to enable processes 135 to be carried out on processing system 100, which were not yet known at a point in time of the conception of processing system 100, have changed since the conception (refined) or were only later installed on processing system 100, it is provided not only to use an operating system 130, which allows dynamic processes 135 to be carried out, but also to ensure that an excessive number of processes 135 does not run on processing system 100.

[0032] FIG. 2 schematically shows a representation of a process 135, which runs on a processing system 100 such as that of FIG. 1 in an operating system 130. Operating system 130 provides a monitoring function 205, which is configured to supply information about processes 135, which run or are ready to run on processing system 100. In a Unix-like operating system 130, monitoring function 205 may include, for example, the system program ps, which may query the desired information from a file system 210 of operating system 130. Under Unix, a process 135 exhibits properties of a file, which may be managed via file system 210. Another mechanism may be used in other operating systems 130.

[0033] It is provided to use monitoring function 205 to obtain and to analyze information about running processes 135 or threads 140 with the aid of a method 215. If an anomaly is detected in the process, a measure may be initiated, which may include sending a signal 220, which ensures that preferably all processes 135 running on processing system 100 are preferably immediately terminated, inhibited or their communication, in particular, to an actuator, is disrupted.

[0034] FIG. 3 schematically shows a representation of a processing system 100 including a watchdog timer (“watchdog”) 305. If it is determined by method 215 that an irregularity is present in one of processes 135 or in one of threads 140, an internal action may then be carried out, which is purely software-based, or an external action, which requires watchdog timer 305. Both actions may include the output of a signal 220, in order to either reset processing system 100, or, with the aid of communication interface 115, to cause a disruption of a communication. If watchdog timer 305 is not used, then the resetting or blocking of communication interface 115 may be triggered via method 215 itself or via operating system 130.

[0035] On the other hand, both functionalities may also be effectuated independently of one another via watchdog timer 305. In this case, it is of particular advantage that watchdog timer 305 may be activated to initiate the described measure if a complementary signal 220, which indicates that no anomaly was detected, is absent for longer than a predetermined period. Method 215 is carried out preferably periodically, and whenever no anomaly has been determined, watchdog timer 305 is set to a time which corresponds to or exceeds the period duration of the implementation of method 215. Method 215 may be carried out every second, for example, and watchdog timer 305 may be set to a runtime of 1 second whenever no anomaly has been detected. If method 215 cannot be carried out, for example, because its implementation takes longer than one second, or important system resources of processing system 100 are not available, watchdog timer 305 then runs and causes the disruption of communication via communication interface 115 or a resetting of processing system 100 or of control unit 105 or even of just one of processing units 125.

[0036] FIG. 4 shows a flow chart of a method 400 for controlling a processing system 100, such as that of one of the preceding figures. Method 400 may, in particular, correspond to method 215 of FIG. 2. In the following description, a number of processes 135 is assumed, method 400 in this case is also correspondingly suitable for threads 140. Method 400 is carried out preferably periodically, for example, controlled by a timer.

[0037] In a first step 405, a maximum number of processes 135 is determined, of which it is expected that they run (simultaneously) on processing system 100. This maximum number may be permanently predefined and, for example, changed only if a new process 135 is installed or upgraded on processing system 100. In another specific embodiment, by sending a corresponding message to operating system 130 before the start of a process 135, the maximum number of processes 135 may also be dynamic in order to adapt the maximum number of processes 135 accordingly.

[0038] In a step 410, the instantaneous number of processes 135 is determined. For this purpose, monitoring function 205, in particular, may be used. In another specific embodiment, additional information may also be queried via processes 135, in particular, the present system authorizations of running processes 135.

[0039] In a step 415, the information obtained is then examined as to whether an irregularity is present. It may be checked, in particular, whether the instantaneous number of processes 135 exceeds the determined maximum number of processes 135. If this is the case, method 400 may continue with a step 435, which is described below in greater detail.

[0040] Otherwise, predetermined system rights of one or multiple processes 135 may be determined in a step 420. In a step 425, information about system rights of processes 135 on processing system 100 may then be determined, similar to step 410. In a step 430, the predetermined and the actual system rights are compared with one another and step 435 may be activated if the actual system rights of a process 135 exceed the predetermined system rights. Otherwise, method 400 may return to and undergo step 405 again.

[0041] In step 435, a communication with the aid of communication interface 115 is optionally prevented. For this purpose, communication interface 115 may be switched off or a part of operating system 130 required for using communication interface 115 may refuse access.

[0042] In addition or alternatively, a resetting of processing system 100 may be prompted in a step 440. Steps 435 and 440 may be prompted, independently of one another, in each case via software or via hardware, in particular, with the aid of watchdog timer 305, as explained above.