ROMETSCH FRANK (DE)
WO2007146558A2 | 2007-12-21 |
US20090007078A1 | 2009-01-01 | |||
DE102006046203A1 | 2007-08-30 |
Patentansprüche 1. Verfahren zur Identifikation eines fehlerhaften Algorithmus (A) , umfassend die Schritte: a) Kategorisieren von Daten, welche vom al) zu testenden Algorithmus (A) und/oder a2) einem Referenzalgorithmus (B) ausgegeben werden, b) Bestimmen mit welcher Referenzhäufigkeit (R(A) , R(B) ) Daten zumindest einer Kategorie (Kx) während des Betriebs bei Fall al) des zu testenden Algorithmus (A) oder bei Fall a2) des Referenzalgorithmus (B) auftreten, c) Bestimmen mit welcher Testhäufigkeit (T (A) ) Daten zumindest einer Kategorie (Kx) während des Betriebs des zu testen¬ den Algorithmus (A) auftreten, d) Bestimmen der Abweichung der Testhäufigkeit (T (A) ) zumindest einer Kategorie (Kx) von der Referenzhäufig¬ keit (R(A) , R(B) ) derselben Kategorie (Kx) und e) Ausgabe einer Fehlermeldung wenn die Abweichung einen bestimmten Schwellwert (THR) überschreitet. 2. Verfahren Anspruch 1, d a d u r c h g e k e n n z e i c h n e t , dass in Schritt c) eine Kategorie (Kx) verwendet wird, welche kei¬ ner der in Schritt b) verwendeten Kategorien (Kx) entspricht. 3. Verfahren nach einem der Ansprüche 1 oder 2, d a d u r c h g e k e n n z e i c h n e t , dass in Schritt c) alle Kategorien (Kx) aus Schritt b) verwendet werden . 4. Verfahren nach einem der Ansprüche 1 bis 3, d a d u r c h g e k e n n z e i c h n e t , dass im Schritt b) der Betrieb bei Fall al) des zu testenden Algorithmus (A) oder bei Fall a2) des Referenzalgorithmus (B) überwacht wird. 5. Verfahren nach einem der Ansprüche 1 bis 4, d a d u r c h g e k e n n z e i c h n e t , dass die Referenzhäufigkeit (R(A), R(B)) in Schritt b) mit Hilfe mehrerer Instanzen bei Fall al) des zu testenden Algorithmus (A) oder bei Fall a2) des Referenzalgorithmus (B) bestimmt wird. 6. Verfahren nach einem der Ansprüche 1 bis 5, d a d u r c h g e k e n n z e i c h n e t , dass die Testhäufigkeit (T(A)) in Schritt c) mit Hilfe mehrerer Instanzen des zu testenden Algorithmus (A) bestimmt wird. 7. Verfahren nach Anspruch 5 oder 6, d a d u r c h g e k e n n z e i c h n e t , dass als Referenzhäufigkeit (R(A), R(B)) beziehungsweise Testhäufigkeit (T (A) ) der Durchschnittswert der mehreren Instanzen herangezogen wird. 8. Verfahren nach einem der Ansprüche 1 bis 7, d a d u r c h g e k e n n z e i c h n e t , dass Schritt b) und/oder Schritt c) außerhalb des Betriebs bei Fall al) des zu testenden Algorithmus (A) oder bei Fall a2) des Referenzalgorithmus (B) ausgeführt werden. 9. Verfahren nach einem der Ansprüche 1 bis 8, d a d u r c h g e k e n n z e i c h n e t , dass die Kategorien (Kx) für Schritt a) anhand der empfangenen Daten automatisch ermittelt werden. 10. Vorrichtung zur Identifikation eines fehlerhaften Algorithmus (A), umfassend: a) Mittel zum Kategorisieren von Daten, welche vom al) zu testenden Algorithmus (A) und/oder a2) einem Referenzalgorithmus (B) ausgegeben werden, b) Mittel (H) zum Bestimmen mit welcher Referenzhäufigkeit (R(A), R(B)) Daten zumindest einer Kategorie (Kx) wäh- rend des Betriebs bei Fall al) des zu testenden Algorithmus (A) oder bei Fall a2) des Referenzalgorithmus (B) auftreten, c) Mittel zum Bestimmen mit welcher Testhäufigkeit (T (A) Daten zumindest einer Kategorie (Kx) während des Betriebs des zu testenden Algorithmus (A) auftreten, d) Mittel (D) zum Bestimmen der Abweichung der Testhäufigkeit (T (A) ) einer Kategorie (Kx) von der Referenzhäufigkeit (R(A), R(B)) derselben Kategorie (Kx) und e) Mittel zur Ausgabe einer Fehlermeldung wenn die Abweichung einen bestimmten Schwellwert (THR) überschreitet. |
Verfahren und Vorrichtung zur Identifikation eines fehlerhaften Algorithmus
Die Erfindung betrifft ein Verfahren zur Identifikation eines fehlerhaften Algorithmus. Weiterhin betrifft die Erfindung eine Vorrichtung zur Durchführung des erfindungsgemäßen Verfahrens .
Algorithmen, im Folgenden stellvertretend am Beispiel von Software erläutert, durchdringen viele Bereiche unseres täglichen Lebens. Beispielsweise ist der Beruf vieler Menschen mit Arbeit auf dem PC verbunden. Aber auch in vielen - wenn nicht fast allen - Geräten ist heute Software vorhanden. Die Spanne reicht vom Privatbereich, wo etwa Mobiltelefon, Fernseher, Satelliten-Receiver und dergleichen mit Software ausgestattet sind, über den öffentlichen Bereich, hier beispielsweise Verkehrsleitsysteme bis zum industriellen Be- reich, wo großtechnische Anlagen durch Software gesteuert werden .
Leider zwingen immer kürzer werdenden Entwicklungszyklen die Hersteller von Software, diese für den Markt freizugeben, ob- wohl sie nicht hinreichend getestet wurde. Daher sind wir häufig mit Geräten konfrontiert, die nicht oder nur mangelhaft funktionieren. Aber auch bei umfangreichen Tests lassen sich Fehler in der Software nicht gänzlich ausschließen. Daher wurden eine Reihe von Strategien entwickelt, welche ein effizientes Auffinden von Fehlern in Algorithmen ermöglichen.
Dabei werden Systeme im Betrieb auf ihren Gesundheitszustand und ihre Performance hin überwacht, wobei viele verschiedene Leistungsparameter ausgewertet werden, die grob in die Schichten „Software-Applikation", „Betriebssystem" und „Hardware" unterteilt werden können. Beispielsweise kann die CPU Auslastung, die Netzwerkauslastung, der Speicherverbrauch, die Festplattenaktivität und vieles mehr Aufschluss über den korrekten Ablauf eines Algorithmus geben, für deren Beobachtung die Betriebssysteme oft schon geeignete Werkzeuge mitbringen. Soll eine bestimmte Software-Applikation überwacht werden, so können zum Beispiel die Daten, welche die Applika- tion ausgibt, ausgewertet werden. Oft liegen solche Daten in Form von sogenannten „Log-Files" vor, in denen die Geschehnisse des Betriebs der Applikation protokoliert werden und so eine wertvolle Basis für die Fehlersuche bilden.
Die Log-Files müssen meist händisch durch Software- Spezialisten ausgewertet werden. Dies ist sehr zeit- und kos- tenaufwändig, da diese Log-Files üblicherweise sehr lang und voll von Information sind, die den normalen und auch fehlerfreien Programmfluss dokumentieren, also keine Fehler im ei- gentlichen Sinne darstellen. Zur Unterstützung stehen daher sogenannte „Auswertungsskripte" oder „Post-Prozessoren" zur Verfügung, welche die Menge an Informationen strukturieren. Dazu wird in den Log-Files nach bestimmten Schlüsselwörtern gesucht, an deren Fundstellen potentielle Probleme in der Software vermutet werden. Beispiele dazu wären Begriffe wie
"Warning", "Error", "Abort" oder auch "Exception". Beispielsweise werden Zeilen im Log-File farblich markiert, die bestimmte Schlüsselwörter enthalten. Wie bereits erwähnt, kann ausgelieferte Software häufig nicht einmal Mindestqualitäts- kriterien erfüllen, sodass auch die zur Verfügung stehenden Werkzeuge die Informationsflut nicht so eindämmen können, dass Software-Spezialisten effiziente Fehlersuche betreiben können. In der Regel werden diese nämlich mit einer Menge von sogenannten „False-Positive-Treffern" konfrontiert. Als "FaI- se-Positive" bezeichnet man Testergebnisse, die anzeigen, dass ein Testkriterium erfüllt sei, obwohl es in Wahrheit gar nicht erfüllt ist. In den Log-Files finden sich daher eine Menge an „Fehlermeldungen", die ein erfahrener Software- Experte jedoch als ungefährlich oder uninteressant einstufen würde, da sie während des normalen Programmflusses entstehen.
Selbstverständlich beziehen sich die angesprochenen Probleme nicht ausschließlich auf Algorithmen in Form von Software. Vielmehr kann ein Algorithmus auch in Hardware oder einer Kombination aus Soft- und Hardware abgebildet sein. Das Ge ¬ sagte bezieht sich daher sinngemäß auch auf diese Kategorien.
Die Aufgabe der Erfindung ist es nun, ein verbessertes Ver ¬ fahren und eine verbesserte Vorrichtung zur Identifikation eines fehlerhaften Algorithmus anzugeben.
Erfindungsgemäß wird diese Aufgabe durch ein Verfahren mit den Merkmalen des Patentanspruchs 1 und einer Vorrichtung mit den Merkmalen des Patenanspruchs 10 gelöst.
Demgemäß umfasst ein Verfahren zur Identifikation eines fehlerhaften Algorithmus, die Schritte: a) Kategorisieren von Daten, welche vom al) zu testenden
Algorithmus und/oder a2) einem Referenzalgorithmus ausgegeben werden, b) Bestimmen mit welcher Referenzhäufigkeit Daten zumindest einer Kategorie während des Betriebs bei Fall al) des zu tes- tenden Algorithmus oder bei Fall a2) des Referenzalgorithmus auftreten, c) Bestimmen mit welcher Testhäufigkeit Daten zumindest ei ¬ ner Kategorie während des Betriebs des zu testenden Algorith ¬ mus auftreten, d) Bestimmen der Abweichung der Testhäufigkeit zumindest einer Kategorie von der Referenzhäufigkeit derselben Katego ¬ rie und e) Ausgabe einer Fehlermeldung wenn die Abweichung einen bestimmten Schwellwert überschreitet.
Demgemäß umfasst eine Vorrichtung zur Identifikation eines fehlerhaften Algorithmus: a) Mittel zum Kategorisieren von Daten, welche vom al) zu testenden Algorithmus und/oder a2) einem Referenzalgorithmus ausgegeben werden, b) Mittel zum Bestimmen mit welcher Referenzhäufigkeit Da ¬ ten zumindest einer Kategorie während des Betriebs bei Fall al) des zu testenden Algorithmus oder bei Fall a2) des Referenzalgorithmus auftreten, c) Mittel zum Bestimmen mit welcher Testhäufigkeit Daten zumindest einer Kategorie während des Betriebs des zu testen- den Algorithmus auftreten, d) Mittel zum Bestimmen der Abweichung der Testhäufigkeit einer Kategorie von der Referenzhäufigkeit derselben Kategorie und e) Mittel zur Ausgabe einer Fehlermeldung wenn die Abwei- chung einen bestimmten Schwellwert überschreitet.
Die Erfindung ermöglicht, fehlerhafte Algorithmen besonders effizient zu identifizieren, da die Überprüfung auf einer hohen Abstraktionsebene abläuft. Nicht die einzelne Fehlermel- düng ist hier von Bedeutung sondern die makroskopische Auswirkung des Algorithmus. Dabei wird ein fehlerhafter Algorithmus mit Hilfe statistischer Methoden identifiziert. Besonders vorteilhaft ist, dass dieses Verfahren völlig ohne menschliches Zutun ablaufen kann. Vorteilhaft werden auch „False-Positive-Fehler" unterdrückt, denn auch wenn die Software nicht fehlerfrei funktioniert, so können doch die ungewöhnlichen Fehlereinträge von den üblichen unterschieden werden. Die tatsächliche Menge von verdächtigen Einträgen kann somit verglichen zur deterministischen Methoden nach dem Stand der Technik weiter eingeschränkt werden, was eine schnellere Analyse erlaubt. Weiterhin können Fehler frühzeitig erkannt werden. Läuft der Algorithmus leicht verändert ab, fallen erwartete Daten/Meldungen aus oder kommen neue hinzu, so kann dies ein Indiz für ein sich anbahnendes Prob- lern sein, noch bevor die Software tatsächlich selbst Meldungen wie zum Beispiel „Warning" oder „Error" ausgeben würde. Darüber hinaus ist die statistische Auswertung nicht auf die Einordnung bestimmter Fehlerklassifikationen durch den Entwickler angewiesen. Üblicherweise muss ja der Entwickler der Software und/oder Hardware Fehler vorausahnen und sie durch entsprechenden Aufbau der Soft- und/oder Hardware bearbeiten, d.h. eine Fehlermeldung ausgeben. Es liegt in der Natur der Sache, dass der Entwickler nicht alle Eventualitäten voraus- sehen kann, da Fehler dann ja generell vermieden werden könnten. Passiert aber das Unvorhergesehene, dann wirkt sich dies in aller Regel an den ausgegebenen Daten aus, auch wenn keine dezidierte Fehlermeldung erfolgt. Das heißt, dass auch wenn bestimmte Situationen durch die Logik des Programms nicht als Fehler erkannt werden, können Unregelmäßigkeiten in zum Beispiel einem bestimmten Abschnitt des Log-Files dazu benutzt werden, diesen als bedenklich einzuordnen. Schließlich ist das erfindungsgemäße Verfahren unabhängig von der Anzahl gleichzeitiger Benutzer oder User. Ein Benutzer, der einen bestimmten Vorgang in einem Software-System ausführt produziert damit eine gewisse Menge an Datenausgaben, beziehungsweise Log-File-Einträgen. Die Anzahl der Log-File-Einträge wird natürlich mit der Anzahl der gleichzeitig im System ar- beitenden Benutzer multipliziert. Nach dem Stand der Technik steigt der Aufwand zur Fehlersuche daher mehr oder minder proportional mit der Anzahl der Benutzer im System. Erschwert wird dies noch dadurch, dass die Fehlermeldungen oder Einträge nicht nach Nutzer getrennt sondern chronologisch geordnet erfolgen und somit hinsichtlich einzelner Benutzer bunt gemischt vorliegen. Überdies lässt sich nicht jede Ausgabe einer Applikation auch einem bestimmten Benutzer zuordnen, da es in aller Regel auch allgemein gehaltene Fehlermeldungen gibt. Der Aufwand bei Anwendung des erfindungsgemäßen Verfah- rens steigt dagegen überhaupt nicht oder marginal, da die relative Häufigkeit bestimmter Meldungen ja nicht oder nur wenig von der Anzahl der Benutzer abhängt. Unter der Voraussetzung, dass die Benutzer mehr oder minder gleich agieren, beziehungsweise bei hinreichend langem Beobachtungszeitraum, stellt sich hier eine stabile Verteilung ein. Ändert sich diese stabile Verteilung, so kann dies durch einen Fehler begründet sein. Die Erfindung ermöglicht daher eine signifikante Effizienzsteigerung bei der Identifikation fehlerhafter Software-en .
Vorteilhafte Ausgestaltungen und Weiterbildungen der Erfindung ergeben sich nun aus den Unteransprüchen sowie aus der Beschreibung in Zusammenschau mit den Figuren der Zeichnung. Vorteilhaft ist es, wenn in Schritt c) eine Kategorie verwendet wird, welche keiner der in Schritt b) verwendeten Kategorien entspricht. Bei dieser Variante wird beispielsweise eine „Auffang-Kategorie" vorgesehen, in welche während der Testphase (Schritt c) Daten eingeordnet werden, die in keine der in der Referenzphase (Schritt b) verwendeten Kategorien passen. Auf diese Weise kann das Auftreten unvorhergesehener Fehler besonders gut überwacht werden.
Günstig ist es, wenn in Schritt c) alle Kategorien aus Schritt b) verwendet werden. Bei dieser Variante der Erfindung werden also während der Referenzphase keine unnützen Daten gespeichert.
Günstig ist es auch, wenn im Schritt b) der Betrieb bei Fall al) des zu testenden Algorithmus oder bei Fall a2) des Referenzalgorithmus überwacht wird. Während der Referenzphase wird der Algorithmus hier vorteilhaft mit Hilfe anderer Werk- zeuge oder auch manuell überwacht, um sicherzustellen, dass die Referenzhäufigkeit auch tatsächlich repräsentativ für einen fehlerhaften Betrieb des Algorithmus ist.
In einer vorteilhaften Ausgestaltung der Erfindung wird die Referenzhäufigkeit in Schritt b) mit Hilfe mehrerer Instanzen bei Fall al) des zu testenden Algorithmus oder bei Fall a2) des Referenzalgorithmus bestimmt. Um das Risiko zu minimieren, dass die Referenzhäufigkeit nicht repräsentativ für den fehlerfreien Betrieb des Algorithmus ist, bloß weil zum Bei- spiel ein Benutzer laufend Fehleingaben macht, können auch mehrere Instanzen des Algorithmus herangezogen werden. Arbeiten zum Beispiel mehrere Benutzer an verschiedenen Arbeitsplätzen mit demselben Algorithmus oder Programm, dann können die Daten aller dieser Instanzen zusammengefasst werden und darauf das erfindungsgemäße Verfahren angewandt werden. Fehleingaben einzelner Benutzer wirken sich dann weit weniger aus . In einer weiteren vorteilhaften Ausgestaltung der Erfindung wird die Testhäufigkeit in Schritt c) darüber hinaus mit Hilfe mehrerer Instanzen des zu testenden Algorithmus bestimmt. Hier gilt das für die vorige Variante Gesagte sinngemäß, al- lerdings auf die Testhäufigkeit angewandt.
Vorteilhaft ist es weiterhin, wenn für die Referenzhäufigkeit beziehungsweise Testhäufigkeit der Durchschnittswert der mehreren Instanzen herangezogen wird. Dies ist eine weitere Maß- nähme um das erfindungsgemäße Verfahren robust zu gestalten.
Vorteilhaft ist es auch, wenn Schritt b) und/oder Schritt c) außerhalb des Betriebs bei Fall al) des zu testenden Algorithmus oder bei Fall a2) des Referenzalgorithmus ausgeführt werden. Bei dieser Variante kann das erfindungsgemäße Verfahren „offline" ablaufen, etwa mit Hilfe von Log-Files. Dies ist dann von Vorteil, wenn eine Prüfung vor Ort nicht durchgeführt werden kann und zu Prüfzwecken die erwähnten Log- Files übermittelt werden.
Besonders vorteilhaft ist es schließlich, wenn die Kategorien für Schritt a) anhand der empfangenen Daten automatisch ermittelt werden. Bei dieser Variante der Erfindung werden während eines bestimmten Zeitraumes vor der Referenzphase die Daten daraufhin ausgewertet, welche Arten von Meldungen von einem Algorithmus ausgegeben werden. Diese Kategorien werden dann für die darauf folgenden Referenzphase verwendet. Wird das erfindungsgemäße Verfahren auf Log-Files angewandt, so kann ein und dasselbe Log-File natürlich als Basis für die Kategorien und für die Häufigkeit dienen.
An dieser Stelle wird darauf hingewiesen, dass sich die genannten Variationen des erfindungsgemäßen Verfahrens und die daraus resultierenden Vorteile auch auf die erfindungsgemäße Vorrichtung beziehen und umgekehrt.
Die obigen Ausgestaltungen und Weiterbildungen der Erfindung lassen sich auf beliebige Art und Weise kombinieren. Die vorliegende Erfindung wird nun nachfolgend anhand der in der schematischen Figur der Zeichnung angegebenen Ausführungsbeispiele näher erläutert. Es zeigt dabei die
Fig. 1 funktional den Ablauf des erfindungsgemäßen Verfahrens;
In der Figur sind gleiche und funktionsgleiche Elemente und Merkmale - sofern nichts Anderes ausgeführt ist - mit denselben Bezugszeichen und unterschiedlichen Indizes versehen.
Fig. 1 zeigt funktional eine erfindungsgemäße Vorrichtung und den Ablauf des erfindungsgemäßen Verfahrens. Die in der Fig. 1 dargestellten Elemente stellen nicht zwangsläufig reale Elemente im Sinne eines physikalischen Geräts dar, sondern dienen primär dazu, die Funktion der Erfindung zu illustrieren .
In der Fig. 1 ist ein zu testender Algorithmus A und ein optionaler Referenzalgorithmus B (strichliert) dargestellt. Darüber hinaus zeigt die Fig. 1 einen ersten Schalter Sl, welcher entweder die Daten des zu testenden Algorithmus A oder des Referenzalgorithmus B zu Mitteln H, welche bestimmen mit welcher Häufigkeit Daten einer Kategorie während des Betriebs des zu testenden Algorithmus A oder des Referenzalgorithmus B auftreten. Im vorliegenden Beispiel sind diese Mittel als (Software) Funktion mit dem Namen „Häufigkeitsbestimmung" ausgeführt. Die Funktion bedient sich dazu verschiede- nen Kategorien Kx, die zu prüfen sind und beispielsweise in einem Speicher abgelegt sind. Weiterhin ist ein Schalter S2 dargestellt, welcher die Ergebnisse der Funktion Häufigkeitsverteilung H entweder der Referenzhäufigkeit R(A) oder der Testhäufigkeit T(A) zuführt. Die beiden Zwischenergebnisse bilden den Eingang zu Mitteln D, welche die Abweichung der Testhäufigkeit T (A) einer Kategorie Kx von der Referenzhäufigkeit T(A) derselben Kategorie Kx bestimmt. Diese Mittel sind im vorliegenden Beispiel als (Software) Funktion „Delta" D ausgeführt. Die resultierende Abweichung wird schließlich mit einem Schwellwert THR verglichen und gegebenenfalls eine Fehlermeldung ausgegeben. Dies ist hier mit einer Lampe symbolisiert. Die Ausgabemittel sind hier als (Software) Funkti- on „Fehler" F ausgeführt.
Die Funktion der in der Fig. 1 dargestellten Anordnung ist nun wie folgt:
Für die folgenden Betrachtungen wird von einem Zustand ausgegangen, in dem beide Schalter Sl und S2 geschlossen sind, also die dargestellte Stellung einnehmen. Während der zu testenden Algorithmus A nun abläuft (mit einem Pfeil symbolisiert) , gibt dieser Daten aus. Beim Algorithmus A kann es sich um ein beliebiges Softwareprogramm oder eine in Hardware realisierte Schaltung handeln.
Um die Funktion zu illustrieren wird in diesem Beispiel angenommen, dass der Algorithmus A die Meldungen „Warning", „Er- ror", „Abort" und „Exception" ausgibt. Es werden also vier
Kategorien Kx gebildet. Während einer Referenzphase, in welcher der korrekte Ablauf des Algorithmus A überwacht wird, werden diese Daten von der Funktion Häufigkeit H verarbeitet. Im einfachsten Fall werden für jede Kategorie Zähler vorgese- hen, die beim Empfang einer Meldung entsprechend erhöht werden. Wird also zum Beispiel eine Meldung „Exception" empfangen so wird der Zähler der Kategorie „Exception" um Eins erhöht. Im Laufe der Zeit ergibt sich so eine Verteilung der Referenzhäufigkeit R(A), die repräsentativ für den korrekten Ablauf des zu testenden Algorithmus A ist. In diesem Zusammenhang wird darauf hingewiesen, dass das Auftreten der Meldungen „Error" und „Abort" nicht zwangsläufig zum Absturz des Algorithmus A führt, sondern dieser auch nach Fehlern weiterlaufen kann. Um die Verteilung unabhängig von der Dauer der Referenzphase zu machen, kann die Verteilung auch normalisiert werden. In einem nächsten Schritt wird der Algorithmus A während einer Testphase, also zum Beispiel während des Einsatzes im Feld, getestet. Dazu wird der Schalter S2 umgelegt (strichlierte Position) , der Schalter Sl bleibt in der dargestellten Position.
Wie schon während der Referenzphase produziert der Algorithmus A auch während der Testphase laufend Daten beziehungsweise Meldungen der oben erwähnten Kategorien Kx. Die Funktion Häufigkeit H verarbeitet wiederum die Daten und erzeugt eine Verteilung der Testhäufigkeit T (A) , die wiederum auch normalisiert werden kann. Wird keine Normalisierung vorgesehen, so sollten die Dauer der Referenzphase und der Testphase gleich sein, oder zumindest ein bekanntes Verhältnis aufweisen.
Diese beiden erhaltenen Verteilungen bilden nun den Eingang für die Funktion Delta D, welche die Abweichungen der Testhäufigkeit T(A) von der Referenzhäufigkeit R(A) je Kategorie Kx bestimmt. Das heißt die Häufigkeit der Meldung „Warning" während der Testphase wird von der Häufigkeit dieser Meldung während der Referenzphase abgezogen. Dasselbe geschieht für „Error", „Abort" und „Exception". Ist nun eine der ermittelten Abweichungen größer als ein vorgebbarer Schwellwert THR so wird eine Fehlermeldung ausgegeben. Anstelle der darge- stellten Leuchte kann dies natürlich auch akustisch oder über eine Fehlermeldung auf einem Bildschirm erfolgen. Für die einzelnen Kategorien Kx können auch verschiedene Schwellwerte THX vorgebbar sein. Etwa kann für die Kategorie „Error" ein niedrigerer Schwellwert vorgesehen werden als für die Katego- rie „Warning" . Darüber hinaus kann vorgesehen werden, dass der Absolutwert der Abweichung mit dem Schwellwert THR verglichen wird. In diesem Fall wird auch dann eine Fehlermeldung ausgegeben, wenn z.B. weniger „Warnings" ausgegeben werden als erwartet. Denkbar ist auch das der Mittelwert aller Abweichungen oder der Mittelwert gewichteter Abweichungen mit dem Schwellwert verglichen werden. Die aufgeführten Beispiele stellen dabei nur einen Ausschnitt der denkbaren Möglichkeiten dar. Auf diese Weise kann ein fehlerhafter Algorithmus A relativ einfach und ohne menschliches Zutun identifiziert werden. Dabei werden nicht einzelne Fehler betrachtet, so wie dies tra- ditionell erfolgt, sondern es werden statistische Muster verglichen. Die Fehlerermittlung erfolgt also eher oberflächlich, ist aber trotzdem zuverlässig. Vor allem reagiert das System auch auf unerwartete Fehler. Traditionell wurden eher Fehler überwacht, deren Auftreten man prinzipiell erwartet hat. Vorteilhaft ist es auch, wenn während der Testphase eine weitere Kategorie Kx vorgesehen wird, die keiner der in der Referenzphase verwendeten Kategorien Kx entspricht. Auf diese Weise kann das Auftreten von unerwarteten Fehlern besonders gut überwacht werden.
In einem zweiten Beispiel wird nun gezeigt wie das erfindungsgemäße Verfahren bei Vorhandensein eines Referenzalgorithmus B abläuft. Für dieses Beispiel wird angenommen, dass der Schalter Sl die strichlierte Position einnimmt, der Schalter S2 die dargestellte. Das Verfahren während der Referenzphase läuft analog wie im ersten Beispiel ab, nur dass nun nicht die Daten des Testalgorithmus A sondern des Referenzalgorithmus B ausgewertet werden. In der Testphase wird der Schalter Sl nun umgelegt, sodass die Daten des Algorith- mus A ausgewertet werden. Die Auswertung der Häufigkeiten erfolgt wieder analog zum ersten Beispiel, wobei an die Stelle der Referenzhäufigkeit des Testalgorithmus R(A) die Referenzhäufigkeit des Referenzalgorithmus R(B) tritt. Der wesentliche Unterschied zum ersten Beispiel ist also, dass hier zwei verschiedene Algorithmen A und B vorliegen. Beispielsweise kann der Testalgorithmus A eine neue, unerprobte Weiterentwicklung des bereits stabil laufenden Referenzalgorithmus B sein. Auf diese Weise kann auch das Laufverhalten von Weiterentwicklungen und neuen Algorithmen überwacht werden.
Selbstverständlich muss die Auswertung nicht während des laufenden Betriebs der Algorithmen A und B, also „online" erfolgen. Es ist auch eine Auswertung abseits des Betriebs, also „offline", möglich. Viele Algorithmen legen sogenannte „Log- Files" an, in denen die Geschehnisse des Betriebs protoko- liert werden und so eine wertvolle Basis für die Fehlersuche bilden. Unglücklicherweise sind solche Log-Files zumeist sehr groß. Eine manuelle Fehlersuche ist daher sehr zeitraubend, insbesondere weil ja auch während des Normalbetriebs durchaus Fehlermeldungen und Warnungen produziert werden. Die Erfindung kann hier helfen, Log-Files, in denen ein unerwartetes Verhalten des Algorithmus A aufgezeichnet wurde, zu identifi- zieren. Wenn das erfindungsgemäße Verfahren auf einzelne Abschnitte des Log-Files angewandt wird, kann die betreffende Stelle im Log-File zudem sehr genau lokalisiert werden. Software-Spezialisten können die Fehlersuche dann gezielt manuell in diesem Bereich fortsetzen, um das eigentliche Problem festzustellen. Die Erfindung ermöglicht also eine signifikant effizientere Fehlersuche, als dies bis dato möglich war.
Um das Risiko zu minimieren, dass ein Algorithmus A als fehlerhaft identifiziert wurde, bloß weil zum Beispiel ein Be- nutzer laufend Fehleingaben macht, können auch mehrere Instanzen des Algorithmus A oder B für das erfindungsgemäße Verfahren herangezogen werden. Arbeiten zum Beispiel mehrere Benutzer an verschiedenen Arbeitsplätzen mit demselben Algorithmus oder Programm, dann können die Daten aller dieser In- stanzen zusammengefasst werden und darauf das erfindungsgemäße Verfahren angewandt werden. Fehleingaben einzelner Benutzer wirken sich dann weit weniger aus.
Um die Identifikation eines fehlerhaften Algorithmus A noch einfacher zu gestalten, können auch die Kategorien Kx automatisch bestimmt werden. Dazu werden während eines bestimmten Zeitraumes vor der Referenzphase die Daten daraufhin ausgewertet, welche Arten von Meldungen vom Algorithmus A oder B ausgegeben werden. Diese Kategorien werden dann für die dar- auf folgende Referenzphase verwendet. Wird das erfindungsgemäße Verfahren auf Log-Files angewandt, so kann ein und dasselbe Log-File natürlich als Basis für die Kategorien Kx und für die Häufigkeit dienen. Obwohl das Beispiel zwecks besserer Anschaulichkeit anhand von konkreten Daten der Algorithmen A und B erläutert wurde, so ist es für den Fachmann doch unmittelbar einsichtig, dass die Erfindung auch mit anderen Daten verwirklicht werden kann. Die Erfindung ist keinesfalls auf Fehlermeldungen oder Warnungen beschränkt, sondern auch auf andere Arten von Daten, insbesondere auch Nutzdaten, anwendbar. Beispielsweise kann die Häufigkeit von Zeichen in einer Datei, die das Er- gebnis eines Verschlüsselungs- oder Komprimierungsalgorithmus ist, dazu dienen, einen Fehler in diesem Algorithmus zu identifizieren. Gleichermaßen kann das erfindungsgemäße Verfahren auch Audiodaten oder Videodaten angewandt werden.
Schließlich wird auch nochmals klargestellt, dass sich die
Erfindung - obwohl diese anhand von Software erläutert wurde - nicht ausschließlich auf Software-Algorithmen bezieht. Vielmehr kann die Erfindung auch erfolgreich auf Algorithmen angewandt werden, die in Hardware realisiert oder gemischt aus Soft- und Hardware aufgebaut sind, insbesondere auch weil in modernen Geräten die Grenzen zwischen Hard- und Software ohnehin fließend sind.