DE60207070T2

DE60207070T2 - Überwachung von tasks

Info

Publication number: DE60207070T2
Application number: DE60207070T
Authority: DE
Inventors: Stefan Noll; Alexander Wassew
Original assignee: Telefonaktiebolaget LM Ericsson AB
Current assignee: Telefonaktiebolaget LM Ericsson AB
Priority date: 2001-05-14
Filing date: 2002-05-14
Publication date: 2006-07-27
Anticipated expiration: 2022-05-15
Also published as: ATE308780T1; US8191071B2; AU2002310820A1; DE20221531U1; ES2252462T3; WO2002093374A3; DE60207070D1; EP1390848A2; US7451446B2; US20040216110A1; US20090044060A1; EP1390848B1; WO2002093374A2

Description

Die Erfindung befasst sich mit dem Gebiet der Datenverarbeitung. Sie betrifft ein Verfahren, eine Vorrichtung sowie ein Computerprogramm für die Überwachung von Tasks, insbesondere zur Verwendung in einem Echtzeit-Telekommunikationssystem.
Hintergrund der Erfindung
Es sind Computerbetriebssysteme, insbesondere Echtzeitbetriebssysteme (real time operation systems – RTOS), bekannt, die für eine task-basierte Datenverarbeitung sorgen. Bei einem Task handelt es sich um ein Arbeitselement eines Computerverarbeitungsjobs. Ein Task kann eine einzige von einem Prozessor eines Computers oder Computersystems zu verarbeitende Aktivität darstellen, oder er kann ein Prozess mit einer Vielzahl von Unterprozessen sein, die in dem Computer oder Computersystem verarbeitet werden sollen. Ein Task kann deshalb auch als ein Thread oder ein Prozess bezeichnet werden.
Zu ihrer Verarbeitung werden Tasks von dem Betriebssystem geplant. Der Ausdruck „Taskplanung", wie er im folgenden verwendet wird, umfasst die Bedeutung von „Aufrufen einer Direktverarbeitung" sowie „Einplanen eines Tasks zur Verarbeitung", z.B. mittels einer Warteschlangen- oder Taskliste. Im letzteren Fall kann es vorkommen, dass der Task auf die Verarbeitung warten muss, bis andere Tasks verarbeitet sind, die für eine frühere Verarbeitung geplant waren, z.B. aufgrund ihrer höheren Priorität. Im letzteren Fall ist es ferner möglich, einen Task einer Umplanung zu unterwerfen, d.h. einen bereits geplanten Task für eine frühere oder spätere Verarbeitung vorzusehen.
Insbesondere Echtzeitsysteme sehen eine Tasküberwachung vor, d.h. eine Überwachung der geplanten Tasks, um Fehler zu erkennen. Eine bekannte Tasküberwachung in existierenden Systemen erfolgt mittels eines höher priorisierten Überwachungstasks. Als Überwachungsmeldungen bezeichnete Meldungen werden von überwachten Tasks an den überwachenden Task gesendet. Der überwachende Task überwacht dedizierte Zeitüberschreitungen für erwartete Überwachungsmeldungen. Im Falle einer Zeitüberschreitung weiß der Überwachungstask, dass etwas falsch lief, und kann geeignete Maßnahmen treffen.
Übliche Überwachungshierarchien sind in den 1 und 2 dargestellt. 1 zeigt einen zentralen Supervisor SV 100, der die Tasks „Task 1" 110, „Task 2" 120 bis „Task n" 130 überwacht. 2 zeigt einen Überwachungsbaum, welcher an seiner Wurzel einen Supervisor SV 200 umfasst, der mit mittelschichtigen Supervisors SV1 210, SV2 220 und SV3 230 verbunden ist. Die Tasks „Task 1" 240, Task 2" 250 und Task 3" 260 senden ihre Überwachungsmeldungen an den Supervisor SV1 210. Der Supervisor SV2 220 empfängt Überwachungsmeldungen vom „Task 4" 270 und „Task 5", während der Supervisor SV3 230 Überwachungsmeldungen vom „Task 6" 290 bis zum „Task n" 296 erhält. Jeder mittelschichtig angeordnete Supervisor 210, 220, 230 sendet Überwachungsmeldungen an den an der Wurzel angeordneten Supervisor SV 200.
Tasks können unterschiedliche Prioritäten aufweisen. Häufig erfolgt die Planung in Echtzeitsystemen nur gemäß Prioritäten, um den Echtzeiterfordernissen zu genügen.
Gewöhnlich ist eine Überwachung der Taskplanung erforderlich, da mehrere Probleme auftreten können: Ein Task kann dem System nicht zur Verfügung gestellt werden aufgrund eines Absturzes dieses Tasks. Ein Task kann dem System nicht zur Verfügung gestellt werden aufgrund einer sich in ihm befindlichen Endlosschleife. Ein Task kann dem System nicht zur Verfügung gestellt werden aufgrund einer gegenseitigen Blockierung, d.h. einer Prozessblockade, die beispielsweise während eines Konkurrenzkampfes von Tasks mit Blick auf begrenzte Systemressourcen auftreten kann. Tasks können dem System nicht zur Verfügung gestellt werden aufgrund eines „Life Locks". Ein „Life Lock" ist entweder einer Endlosschleife eines Tasks oder eine Kommunikation zwischen zwei oder mehreren Tasks auf fehlerhafte, unendliche Weise. Hierdurch können andere Tasks nicht vom Prozessor (CPU) verarbeitet werden. Oder aber die fehlerhaften Tasks versäumen es, weitere Tasks auszulösen, so dass diese weiteren Tasks nicht mehr ausgeführt werden.
Tasks mit niedrigerer Priorität können dem System aufgrund einer Überlastung nicht zur Verfügung stehen, die von einem oder mehreren mit einer besseren Priorität verursacht wird. Dies kann aufgrund von Mängeln im Aufbau des Taskverarbeitungssystems vorkommen, denn bei einer korrekten Ausführungsform wird ein Task keine anderen wichtigen Tasks, die jedoch eine niedrigere Priorität aufweisen, an deren Ausführung hindern, selbst in Überlastungssituationen.
Gewöhnlich sind nicht alle Tasks in einem System Teil der Anwendung. Stattdessen bilden einige Teil einer Systemplattform. Normalerweise kann der Quellencode derartiger Plattformtasks nicht geändert werden.
Bei Überwachungsmeldungen ist es schwierig herauszufinden, was genau im Falle einer Störung falsch lief, d.h. welcher Task bzw. welche Tasks versagten. Stehen Tasks aufgrund eines „Life Locks" oder einer Überlastung – wie beschrieben – nicht zur Verfügung, so kann ein Supervisor, der die Taskplanung mittels Überwachungsmeldungen überwacht, lediglich feststellen, dass einer der Tasks mit einer schlechteren Priorität keine Funktion mehr hat, kann jedoch nicht bestimmen, dass es ein „Life Lock" oder eine Überlastung gibt, obgleich es für den Supervisor wichtig ist herauszufinden, was falsch lief, um entsprechende Maßnahmen zur Lösung des Problems zu ergreifen.
Ein weiterer Nachteil besteht darin, dass es unmöglich ist, Plattformtasks in eine Überwachungshierarchie, wie mit Bezug auf die 1 und 2 beschrieben, einzubringen, es sei denn, die Plattform bietet bestimmte Schnittstellen an, die einen zusätzlichen Kostenaufwand verursachen können oder insbesondere in sicherheitsbezogenen Systemen nicht erwünscht sind.
Takashi u.a. („Trace visualization and analysis, tool for supervisory control systems", Systems, Man and Cybernetics, 2000 IEEE International Conference, ISBN 0-7803-6583-6, Seiten 1198–1203) beziehen sich auf ein task-basiertes Visualisierungs- und Analyse-Tool für Überwachungssteuersysteme. Es werden Ereignismuster identifiziert, die spurenweise wiederholt auftreten, wie z.B. periodische Ereignisse. Statt der Vielzahl von Ereignissen, die das Muster bilden, wird ein identifiziertes Ereignismuster in einem visualisierten Verkehrsverlaufsdiagramm mittels einer zugeordneten Phrase dargestellt. Eine entsprechende Visualisierung von Spuren sorgt für eine verminderte Informationsmenge, die dem überwachenden Benutzer gegenüber angezeigt wird.
Deshalb ist es eine Aufgabe der Erfindung, ein Verfahren, eine Vorrichtung sowie ein Computerprogramm für eine verbesserte Tasküberwachung in einem task-basierten Datenverarbeitungssystem bereitzustellen.
Zusammenfassung der Erfindung
Diese Aufgabe wird durch die Lehre der unabhängigen Ansprüche gelöst.
Die Erfindung betrifft ein Verfahren zur Überwachung einer task-basierten Datenverarbeitung, wobei bei einer Vielzahl von Tasks für jeden Task die folgenden Schritte durchgeführt werden: Planung des Tasks für die Verarbeitung und Protokollieren der Planung des Tasks durch Speichern einer Taskkennung in einem Protokollspeicher, wobei die Taskkennung den geplanten Task identifiziert und dem geplanten Task zugeordnet ist. Die in dem Protokollspeicher gespeicherten Taskkennungen bilden ein Taskverlaufsmuster der geplanten Tasks. Mittels des Taskverlaufsmusters wird bewertet, ob in der taskbasierten Datenverarbeitung eine Störung auftritt. Mindestens eine Sicherheitsmaßnahme wird ergriffen, wenn die Bewertung eine Störung anzeigt.
Gemäß einem weiteren Aspekt betrifft die Erfindung ein Netzelement eines Kommunikationsnetzes, das zur Durchführung des beschriebenen Verfahrens zum Überwachen einer task-basierten Datenverarbeitung ausgestaltet ist.
Gemäß einem weiteren Aspekt betrifft die Erfindung ein Kommunikationsnetz umfassend mindestens einen Netzknoten, der zur Durchführung des beschriebenen Verfahrens zum Überwachen einer task-basierten Datenverarbeitung ausgestaltet ist.
Gemäß einem weiteren Aspekt betrifft die Erfindung ein Computerprogramm, insbesondere ein Computerbetriebssystem, umfassend Softwarecodeteile, die in einen internen Speicher einer digitalen Verarbeitungseinheit ladbar sind und zum Steuern der Schritte des beschriebenen Verfahrens zum Überwachen einer taskbasierten Datenverarbeitung ausgestaltet sind, wenn das Computerprogramm auf der digitalen Verarbeitungseinheit ausgeführt wird.
Die Erfindung ermöglicht vorteilhafterweise eine Erkennung von „Life Locks" und überlasteten Tasks. Ferner erlaubt die Erfindung die Feststellung, ob sich ein einziger Task in einer Endlosschleife befindet.
Ferner ist es ein Vorteil, dass der Aufbau einfach und deshalb zuverlässig ist, da die Überwachung von einem einzigen Überwachungstask gehandhabt werden kann. Hinzu kommt, dass nur ein Task-Scheduler Informationen über geplante Tasks bereitstellen muss. Hohe Zeichengabeverkehrsmengen, die z.B. von Überwachungsmeldungen verursacht werden, werden vermieden. Zusätzlich müssen die überwachten Tasks für die Anwendung der Erfindung nicht geändert werden.
Weitere bevorzugte Ausführungsformen der Erfindung sind in den Unteransprüchen beschrieben.
Gemäß einer bevorzugten Ausführungsform umfasst die Taskkennung mindestens einen dedizierten Parameter des geplanten Tasks. Der Scheduler kann vorteilhafterweise jegliche verfügbare Information, die für die Tasküberwachung von Bedeutung ist, in den Parameter einfügen. Das Tasküberwachungssystem kann deshalb zur Verfügung stehende Informationen über Tasks in effizienter Weise nutzen.
In einer weiteren Ausführungsform ist der mindestens eine dedizierte Parameter einer aus einer Gruppe umfassend eine Taskpriorität, eine erforderliche Verarbeitungszeit, eine verbrauchte Verarbeitungszeit, eine Verarbeitungsfrist, einen Tasktypindikator. Die aufgeführten Parameter erlauben in vorteilhafter Weise eine differenzierte und ausführliche Tasküberwachung, insbesondere für Echtzeitsysteme, da sie zeitliche Constraints wiedergeben, die während der Taskverarbeitung kritisch sein können.
Gemäß einer weiteren Ausführungsform umfasst der Schritt des Bewertens den Schritt des Vergleichens des Taskverlaufsmusters mit mindestens einem vordefinierten Kriterium. In vorteilhafter Weise erlaubt die Verwendung vordefinierter Kriterien eine Anpassung der Tasküberwachung an individuelle Anwendungsbedürfnisse.
Gemäß einer weiteren Ausführungsform stammt das mindestens eine vordefinierte Kriterium aus einer Gruppe von Kriterien, diese Gruppe umfassend:
das Kriterium, dass in dem Taskverlauf eine dedizierte Taskkennung nicht vorkommt,
das Kriterium, dass in dem Taskverlauf eine Vielzahl von dedizierten Taskkennungen nicht vorkommt,
das Kriterium, dass eine Anzahl von geplanten Tasks geringer ist als eine erste Schwelle,
das Kriterium, dass eine Anzahl von geplanten Tasks größer ist als eine zweite Schwelle,
das Kriterium, dass die Anzahl von Planungen eines dedizierten Tasks größer ist als eine dritte Schwelle,
das Kriterium dass die Anzahl von Planungen eines dedizierten Tasks größer ist als eine vierte Schwelle,
das Kriterium dass die Anzahl von Planungen einer Vielzahl von dedizierten Tasks größer ist als eine fünfte Schwelle, und
jede Kombination von Kriterien aus der Gruppe der Kriterien.
Vorteilhafterweise geben die Kriterien aus der Gruppe Störungsszenarien wieder, deren Erkennung durch die Tasküberwachung von Nutzen ist.
Gemäß einer weiteren Ausführungsform der Erfindung stellt ein vordefiniertes Kriterium ein Referenzmuster dar, wobei eine Störung bestimmt wird, wenn das Taskverlaufsmuster und das Referenzmuster übereinstimmen.
Als ein Referenzmuster wird eine Gruppe von Bedingungen verstanden, die gegenüber dem Taskverlaufsmuster geprüft werden. Gemäß einer alternativen Ausführungsform sind das Taskverlaufsmuster und das Referenzmuster von Bitmustern dargestellt, die einfach, schnell und effektiv von entsprechenden Bit-Operationen, z.B. mittels einer XOR-Funktion, verglichen und bewertet werden können.
Die Störungserkennung im Falle übereinstimmender Muster sorgt für eine effektive Tasküberwachung, wenn das Referenzmuster aus kritischen Bedingungen besteht, und wenn die Anzahl verfügbarer kritischer Szenarien, d.h. solcher, die eine Störung anzeigen, niedriger ist als die Anzahl gesunder Szenarien, d.h. solcher, die keine Störung anzeigen.
Gemäß einer weiteren Ausführungsform stellt ein vordefiniertes Kriterium ein Referenzmuster dar, wobei eine Störung bestimmt wird, wenn das Taskverlaufsmuster und das Referenzmuster nicht übereinstimmen.
Die Störungserkennung im Falle nicht übereinstimmender Muster sorgt für eine effektive Tasküberwachung, wenn das Referenzmuster aus unkritischen Bedingungen besteht, und wenn die Anzahl verfügbarer kritischer Szenarien, d.h. solcher, die eine Störung anzeigen, höher ist als die Anzahl gesunder Szenarien, d.h. solcher, die keine Störung anzeigen.
Gemäß einer weiteren Ausführungsform umfasst das Referenzmuster mindestens eines aus der Gruppe
mindestens eine Taskkennung eines zu überwachenden Tasks,
mindestens eine Prioritätsinformation über mindestens einen zu überwachenden Task,
mindestens ein Leerlaufmuster,
mindestens ein gesundes Auslastungsmuster.
Gemäß einer weiteren Ausführungsform umfasst die Sicherheitsmaßnahme das Auslösen eines Alarms.
Gemäß einer weiteren Ausführungsform ist mindestens eine Referenzmaßnahme dem mindestens einen vordefinierten Kriterium zugeordnet, und die mindestens eine ergriffene Sicherheitsmaßnahme entspricht der mindestens einen Referenzmaßnahme, die dem vordefinierten Kriterium zugeordnet ist, das die Erkennung der Störung bewirkte. Eine sofortige Maßnahme gegen eine Störung wird durch ein Verknüpfen der Störungsbedingung mit der Gegenmaßnahme unterstützt.
Gemäß einer weiteren Ausführungsform wird der Schritt des Erkennens wiederholt durchgeführt, wobei der Protokollspeicher zumindest nach einem durchgeführten Erkennungsschritt geleert wird. Hierdurch wird ermöglicht, dass der erforderliche Speicherplatz in vernünftigen Schranken gehalten wird.
Gemäß einer weiteren Ausführungsform wird die Planung des Tasks mittels einer Rückruffunktion durchgeführt. Dies ermöglicht eine einfache und zuverlässige Übergabe der Taskkennung sowie relevanter Taskparameter zum Zwecke des Protokollierens im Protokollspeicher.
Gemäß einer weiteren Ausführungsform betriff die Erfindung ein Computerprogramm, das auf einem computerlesbaren Medium gespeichert ist.
Im folgenden werden Ausführungsformen der Erfindung unter Bezugnahme auf die Figuren ausführlich beschreiben. Es zeigen.
1 eine bekannte Supervisor-Hierarchie,
2 eine weitere bekannte Supervisor-Hierarchie,
3 eine Darstellung der Tasküberwachung,
4 ein Taskverlaufsmuster, das ein fehlerhaftes Szenario anzeigt,
5 ein Taskverlaufsmuster, das ein gesundes Szenario anzeigt.
Ausführliche Beschreibung der erfindungsgemäßen Ausführungsformen
Erfindungsgemäß protokolliert ein Scheduler eines task-basierten Softwaresystems die zu aktivierenden Tasks, d.h. die geplanten Tasks, in einem Protokollspeicher. Alternativ oder ergänzend kann der Scheduler auch deaktivierte Tasks bzw. umgeplante Tasks protokollieren. Ein hoch priorisierter Supervisortask bewertet das in diesem Protokoll gespeicherte Muster regelmäßig. Bewertung bedeutet der Vergleich des Musters gegenüber vordefinierter Kritierien, die einen bestimmten Fehler angeben.
Kriterien sind:

– ein oder mehrere Tasks tauchen im Muster nicht auf,
– die Anzahl der Planungen ist viel niedriger als erwartet; dies kann mittels einer bestimmten Schwelle gemessen werden,
– die Anzahl der Planungen ist viel höher als erwartet; dies kann mittels einer weiteren bestimmten Schwelle gemessen werden,
– ein oder mehrere Tasks werden häufiger als erwartet geplant; dies kann mittels einer oder mehrerer weiteren Schwellen gemessen werden.

Die aufgeführten Kriterien können zum Definieren der Bedingungen, unter welchen die Tasküberwachung eine Störung anzeigen soll, beliebig kombiniert werden.
Echtzeitbetriebssysteme RTOS stellen eine „Rückruf"-Funktion bereit, die vom Scheduler durchgeführt wird. Hierdurch ist es möglich, dass eine Anwendungsfunktion während jedes Planungszyklus vom Scheduler aufgerufen wird. Erfindungsgemäß kann diese Funktion zum Übermitteln von Parametern wie Taskkennungen oder Tasknamen von vom Scheduler geplanten Tasks als Parameter an eine Anwendungsfunktion verwendet werden. Die aufgerufene Anwendungsfunktion protokolliert die übermittelte Taskscheduling-Information in einer Speicherposition. Deshalb kann ein Taskverlauf, der auch als Taskverlaufsmuster bezeichnet wird, vom Supervisor aus diesem Speicher gelesen werden.
Diese Schritte der Tasküberwachung sind in der 3 gezeigt.
Der Supervisor kann nach dem Taskverlauf die folgenden Maßnahmen ergreifen:

– Lesen und Bewerten desselben;
– Protokollieren und/oder Ausdrucken dessen, wenn etwas durch die Bewertung als fehlerhaft oder verdächtig erkannt wird,
– Löschen des Ablaufes, vorzugsweise nach jedem Überwachungscheck, um eine effektive Nutzung des Speichers zu unterstützen.

Im beschriebenen Beispiel ist folgendes dem Supervisor-Task bekannt: die zu überwachenden Tasks sowie deren entsprechende Taskkennungen, die Prioritäten der Tasks, ein Leerlaufmuster, das durch eine Anzahl von Planungen und durch die Kennungen der im Leerlaufmodus involvierten Tasks definiert ist, sowie ein gesundes Auslastungsmuster, das durch eine Anzahl von Planungen und durch die Kennungen der im unkritischen, gesunden Modus involvierten Tasks definiert ist.
Mit Blick auf die 4 und 5 wird ein Beispiel beschrieben, wie der Supervisor-Task einen Task in einer Endlosschleife feststellt. Das Beispiel basiert auf den folgenden Annahmen: 4 Tasks sollen überwacht werden. Der erste Task hat die Taskkennung „1", der zweite Task die Taskkennung „2" etc. Der Task 1 hat die höchste Priorität, gefolgt von Task 2. Task 3 hat eine schlechtere Priorität als Task 2, und Task 4 hat die schlechteste Priorität. Es gibt ein Leerlaufszenario, bei dem nur der Task 3 und der Task 4 mit ungefähr 200 erwarteten Planungen/Sek. ablaufen. Ein gesundes Auslastungsszenario sorgt für ca. 1000 erwartete Planungen/Sek. Alle 4 Tasks werden in einem gesunden Auslastungsszenario geplant.
4 zeigt ein fehlerhaftes Szenario. Der Supervisor stellt lediglich durch Bewerten der Anzahl von Tasks, die geplant und im Taskverlaufsmuster protokolliert sind (d.h. 150 Einträge im Verlauf), fest, dass etwas fehl läuft. Er kann sogar anzeigen, was passiert, da Task 3 und Task 4 vollständig fehlen. Dies gibt an, dass sich Task 2 in einer Endlosschleife befindet und lediglich von dem höher priorisierten Task 1 unterbrochen wird. Alternativ kann es vorkommen, dass Task 1 und Task 2 in ein Life Lock geraten sind. Der Supervisor kann deshalb eine Sicherheitsmaßnahme auslösen, um die fehlerhafte Taskverarbeitung zu überwinden, z.B. durch einen Neustart des Task 2.
Ein entsprechendes gesundes Szenario ist in der 5 gezeigt, wobei das Taskverlaufsmuster eine Zufallsverteilung umfasst, mit anderen Worten, eine chaotische Ansammlung der Taskkennungen „1" bis „4". Protokolliert werden 897 Planungen. Ein Vergleich mit den für ein gesundes Muster umschriebenen Kriterien bestätigt einen regelmäßigen Betrieb der task-basierten Datenverarbeitung.
Gemäß einer Ausführungsform wird die Erfindung durch Software realisiert. Gemäß einer weiteren bevorzugten Ausführungsform ist das Computerprogramm auf einem computerlesbaren Medium gespeichert, z.B. einer CD-ROM, einer Diskette, einer Bildplatte oder einer Magnetplatte. Deshalb wird für eine gute physikalische Portabilität der Steuerungssoftware Sorge getragen, d.h. Aktualisierungen können auf einfache Weise durchgeführt werden.
Gemäß einer weiteren Ausführungsform wird das erfindungsgemäße Verfahren von einem Netzelement eines Kommunikationssystems durchgeführt, z.B. einer Mobilfunkvermittlungsstelle MSC, einer Paket-MSC, einem SGSN oder einer Heimatdatei.
In einer Ausführungsform bezieht sich die Erfindung auf ein Datenverarbeitungsverfahren umfassend die Schritte des Protokollierens von zu aktivierenden oder zu deaktivierenden Tasks durch einen Scheduler, des Bewertens des Musters im Taskprotokoll durch Vergleichen des protokollierten Musters mit vordefinierten Kriterien, die einen Fehler angeben, falls die Bewertung in einer Nichtübereinstimmung der Muster resultiert.
Ohne Beschränkung darauf kann die Erfindung vorzugsweise in sämtlichen Kommunikationssystemen Anwendung finden, die durch 3GPP im Release 99 sowie in sämtlichen künftigen Ausgaben hiervon definiert sind. Insbesondere umfasst dies PDC- und PPDC- sowie UMTS-Netze, Kernnetze, GSM-Netze und die entsprechender Benutzergeräte.

Claims

Verfahren zur Überwachung von Tasks, wobei bei einer Vielzahl von Tasks für jeden Task der folgende Schritt durchgeführt wird: – Planung des Tasks für die Verarbeitung, dadurch gekennzeichnet, dass bei der Vielzahl von Tasks für jeden Task der folgende Schritt durchgeführt wird: – Protokollieren der Planung des Tasks durch Speichern einer Taskkennung in einem Protokollspeicher, wobei die Taskkennung den geplanten Task identifiziert und dem geplanten Task zugeordnet ist, wobei die in dem Protokollspeicher gespeicherten Taskkennungen ein Taskverlaufsmuster der geplanten Tasks bilden, und wobei von einem Überwachungstask mittels des Taskverlaufsmusters bewertet wird, ob in der taskbasierten Datenverarbeitung eine Störung auftritt, und wobei mindestens eine Sicherheitsmaßnahme ergriffen wird, wenn die Bewertung eine Störung anzeigt.
Verfahren nach Anspruch 1, wobei die Taskkennung mindestens einen dedizierten Parameter des geplanten Tasks umfasst.
Verfahren nach Anspruch 2, wobei der mindestens eine dedizierte Parameter einer aus einer Gruppe umfassend eine Taskpriorität, eine erforderliche Verarbeitungszeit, eine verbrauchte Verarbeitungszeit, eine Verarbeitungsfrist, einen Tasktypindikator ist.
Verfahren nach einem der vorstehenden Ansprüche, wobei der Schritt des Bewertens den Schritt des Vergleichens des Taskverlaufsmusters mit mindestens einem vordefinierten Kriterium umfasst.
Verfahren nach Anspruch 4, wobei das mindestens eine vordefinierte Kriterium aus einer Gruppe von Kriterien stammt, diese Gruppe umfassend: – das Kriterium, dass in dem Taskverlauf eine dedizierte Taskkennung nicht vorkommt, – das Kriterium, dass in dem Taskverlauf eine Vielzahl von dedizierten Taskkennungen nicht vorkommt, – das Kriterium, dass eine Anzahl von geplanten Tasks geringer ist als eine erste Schwelle, – das Kriterium, dass eine Anzahl von geplanten Tasks größer ist als eine zweite Schwelle, – das Kriterium, dass die Anzahl von Planungen eines dedizierten Tasks größer ist als eine dritte Schwelle, – das Kriterium dass die Anzahl von Planungen eines dedizierten Tasks größer ist als eine vierte Schwelle, – das Kriterium dass die Anzahl von Planungen einer Vielzahl von dedizierten Tasks größer ist als eine fünfte Schwelle, – jede Kombination von Kriterien aus der Gruppe der Kriterien.
Verfahren nach Anspruch 4 oder 5, wobei ein vordefiniertes Kriterium ein Referenzmuster darstellt, und wobei eine Störung bestimmt wird, wenn das Taskverlaufsmuster und das Referenzmuster übereinstimmen.
Verfahren nach Anspruch 4 oder 5, wobei ein vordefiniertes Kriterium ein Referenzmuster darstellt, und wobei eine Störung bestimmt wird, wenn das Taskverlaufsmuster und das Referenzmuster nicht übereinstimmen.
Verfahren nach Anspruch 6 oder 7, wobei das Referenzmuster mindestens eines aus der Gruppe – mindestens eine Taskkennung eines zu überwachenden Tasks, – mindestens eine Prioritätsinformation über mindestens einen zu überwachenden Task, – mindestens ein Leerlaufmuster, – mindestens ein gesundes Auslastungsmuster umfasst.
Verfahren nach einem der vorstehenden Ansprüche, wobei die Sicherheitsmaßnahme das Auslösen eines Alarms umfasst.
Verfahren nach einem der Ansprüche 4 bis 9, wobei mindestens eine Referenzmaßnahme dem mindestens einen vordefinierten Kriterium zugeordnet ist, und wobei die mindestens eine ergriffene Sicherheitsmaßnahme der mindestens einen Referenzmaßnahme entspricht, die dem vordefinierten Kriterium zugeordnet ist, das die Erkennung der Störung bewirkte.
Verfahren nach einem der vorstehenden Ansprüche, wobei der Schritt des Erkennens wiederholt durchgeführt wird, und wobei der Protokollspeicher zumindest nach einem durchgeführten Erkennungsschritt gelöscht wird.
Verfahren nach einem der vorstehenden Ansprüche, wobei die Planung des Tasks mittels einer Rückruffunktion durchgeführt wird.
Netzelement eines Kommunikationsnetzes, das ausgestaltet ist, um das Verfahren nach einem der Ansprüche 1 bis 12 durchzuführen.
Kommunikationsnetz umfassend mindestens einen Netzknoten nach Anspruch 13.
Computerprogramm, insbesondere ein Computerbetriebssystem, umfassend Softwarecodeteile, die in einen internen Speicher einer digitalen Verarbeitungseinheit ladbar sind und für die Schritte nach einem der Ansprüche 1 bis 12 ausgestaltet sind, wenn das Computerprogramm auf der digitalen Verarbeitungseinheit ausgeführt wird.
Computerprogramm nach Anspruch 15, wobei das Computerprogramm auf einem computerlesbaren Medium gespeichert ist.