EP1917595A2 - Method for diagnosing technical systems - Google Patents

Method for diagnosing technical systems

Info

Publication number
EP1917595A2
EP1917595A2 EP06792815A EP06792815A EP1917595A2 EP 1917595 A2 EP1917595 A2 EP 1917595A2 EP 06792815 A EP06792815 A EP 06792815A EP 06792815 A EP06792815 A EP 06792815A EP 1917595 A2 EP1917595 A2 EP 1917595A2
Authority
EP
European Patent Office
Prior art keywords
diagnostic
data
oracle
diagnoseorakel
system components
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Withdrawn
Application number
EP06792815A
Other languages
German (de)
French (fr)
Inventor
Detlef Kendelbacher
Holger Schilling
Fabrice Stein
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Siemens AG
Original Assignee
Siemens AG
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Siemens AG filed Critical Siemens AG
Publication of EP1917595A2 publication Critical patent/EP1917595A2/en
Withdrawn legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/0703—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation
    • G06F11/079—Root cause analysis, i.e. error or fault diagnosis
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/0703—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation
    • G06F11/0706—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation the processing taking place on a specific hardware platform or in a specific software environment
    • G06F11/0748—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation the processing taking place on a specific hardware platform or in a specific software environment in a remote unit communicating with a single-box computer node experiencing an error/fault
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/30—Monitoring
    • G06F11/3003—Monitoring arrangements specially adapted to the computing system or computing system component being monitored
    • G06F11/3006—Monitoring arrangements specially adapted to the computing system or computing system component being monitored where the computing system is distributed, e.g. networked systems, clusters, multiprocessor systems
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/30—Monitoring
    • G06F11/3065—Monitoring arrangements determined by the means or processing involved in reporting the monitored data
    • G06F11/3072—Monitoring arrangements determined by the means or processing involved in reporting the monitored data where the reporting involves data filtering, e.g. pattern matching, time or event triggered, adaptive or policy-based reporting

Definitions

  • the invention relates to a method for system diagnosis in technical systems with several system components
  • Such complex systems often consist of several computational ⁇ technical system components, ie processing units that interact with each other by exchanging data.
  • the respective processing units have a more or less large amount of self-running functions as well as a number of interfaces to the environment.
  • Two or more processing units are coupled to one another via interfaces and are thereby decoupled in their function from one another.
  • sensors and actuators can also be integrated.
  • the distribution of the processing units is based on the fact that they are mobile units that communicate with each other and / or with stationary system components, mostly below Use of radio technology.
  • the radio connection is a system-determining interface, which often serves not only for the exchange of process data, but at the same time also for system diagnostics.
  • Safety-related systems such as railway Siche ⁇ insurance systems, often have multiple interacting proces ⁇ processing units of differentxtonan horrsstu- fen - Safety Integrity Level - SIL. Since the Ecksauf ⁇ wall rises for safety-related requirements with increasing SIL, is for these systems, the economic interest, functions of different safety requirements approximately stepped in separate processing units to order.
  • the coupling of the processing units of distributed systems can be synchronous or asynchronous.
  • data is exchanged cyclically by adjusting internal process states.
  • asynchronous coupling data is exchanged in an event-oriented manner, which reduces the amount of data.
  • Asynchronous interfaces, via which event-oriented data are exchanged, can lead to problems in the overall system if a processing unit has fallen out of ⁇ . Since in this case no more events arrive at the interface partner, special mechanisms for the failure disclosure must be used. This problem is solved implicitly in synchronous interfaces, as a failure is automatically revealed by the lack of data.
  • Distributed complex systems require system-internal diagnostic functions ⁇ to be economically maintainable.
  • system diagnostics are subject to considerably higher requirements than, for example, only the user's information about failed components. With an increasing share of software and increasingly complex structures based on increasingly slightest ⁇ processing performance hardware system diagnostics is given a new significance.
  • System developers require internal process statuses and process histories for the analysis and elimination of complex fault patterns.
  • Customers require information about failures and the operating status of the system.
  • Dispatching services require filtered and prepared data from system interfaces for operation monitoring, which can be used to log and control system performance parameters and utilization. For maintenance and In istset ⁇ Zung services information is necessary to maintenance, spare parts and system test.
  • ⁇ In addition to the content of various diagnostic information, the type of communication, and appropriate to ⁇ play of the diagnostic data preparation an essential role. Often be ⁇ is the request to the processing units to transmit diagnostic data on a network to a central location or several specialized sites such that up consuming, manual data logistics is avoided. As a rule, the existing transmission facilities should be shared. In most cases, the data must also be appropriately filtered, condensed and processed in order firstly to limit the data volume in the transmission network or to regulate it by means of priority control and secondly to enable a time-saving evaluation.
  • the diagnosis is an integral part of the system at least in terms of data acquisition.
  • Software modules generate diagnostic data for specified events or for specific regimes, for example time-based, in order to make condition-related diagnostic information available in addition to their system function.
  • the scope of the diagnostic messages can be set by configuration or configuration in order to be able to obtain more or more detailed diagnostic data in phases of system stabilization or troubleshooting, for example, than in normal operation of a system.
  • diagnosis data obtained in modular plane are then transferred to a specially designed for diagnostic purposes diagnosis processing unit and further processed there and stores ge ⁇ .
  • One or more diagnostic processing units may be located in the system. Diagnose engineerss ⁇ units in addition to the interfaces to the software modules more interfaces to external devices, eg.
  • diagnostic processing units As sensors, or to humans - MMI - have. As a rule, they also have storage facilities for diagnostic data. For the evaluation and interpretation of the data, other separate devices and programs are often used. A common method is the computer-aided access to the data of diagnostic processing units, for example, to retrieve the collected diagnostic data, evaluate and archive.
  • Typical of complex distributed systems is a hierarchical structure in which diagnostic primary information is obtained decentrally at the level of software modules or hardware components and transferred to special diagnostic processing units and further processed.
  • the type and extent of diagnostic data generation is either permanently coded in software modules or can be set via parameters.
  • a common problem with the system diagnostics, particularly in the To ⁇ connexion with complex software errors is within the scope of the diagnostic data. If too few diagnostic data are logged, the available data may not be sufficient to analyze or reproduce errors in detail.
  • the massive production and Spei leads ⁇ assurance of diagnostic data, eg. For example, tracing often leads to considerable amounts of data requiring a great deal of storage, logistics, and evaluation, thereby increasing system costs.
  • the massive increase of the diagnostic data volume can lead to performance problems and a changed time behavior of the system, which undesirably influences the system usage.
  • the invention has for its object to overcome these disadvantages and to provide a method of the generic type, are optimized in the nature and extent of the diagnostic data to be transmitted, the data volume should be reduced as much as possible.
  • the object is achieved in that a central system diagnosis, ie a Diagnoseorakel, is provided, wherein the Diagnoseorakel type and extent of the sys ⁇ temkomponenten to be transmitted to the Diagnoseorakel diagnostic sedata depending on already passed diagnostic data and stored in the diagnostic oracle rules controls.
  • a diagnostic functionality is introduced in the system, which provides an automatic adaptive tive control of the diagnostic data in dependence on defined rules, in particular with respect to events or thresholds allowed.
  • the diagnostic functionality contains rules for interpreting the current diagnostic data and uses these rules to control the type and scope of future diagnostic data.
  • the diagnostic functionality In addition to the adaptive control of the diagnostic data volume, the diagnostic functionality also takes over the control of further processing, storage, transmission and output of diagnostic messages as required. It thus forms a so-called diagnostic oracle.
  • the method according to the invention covers different diagnostic requirements with a uniform concept - developer diagnosis, customer diagnosis, system maintenance.
  • the Systement ⁇ development will be better modularized by the consistent separation of system and diagnostic functions.
  • the design of the system components is simplified. Through the process-related components, the design testability of the Sys tems ⁇ improved.
  • the separation of diagnostics and system function avoids undesirable repercussions on the system with increased diagnostic activity.
  • System function can be done separately if the interface between system and diagnostic oracle is specified
  • the diagnostic oracle can be used as a test tool. Use is possible during system development as well as during operation of the system.
  • the diagnostic functions can be carried out in separate hardware, whereby the diagnostic capability of the system is maintained even if the system components fail .
  • the adaptive method automatically retrieves data in sufficient quantity and depth of information necessary for later analysis of system errors.
  • the procedure ensures that the scope of the resulting diagnostic data is reduced to a minimum.
  • storage and logistics costs are optimized.
  • performance problems can be avoided by offloading diagnostic functions and keeping the system load deterministic even with high volumes of trace data.
  • the central diagnostic function of the diagnostic oracle enables easy connection to central services, eg. B. pei ⁇ cher, and system interfaces, such as a cent ⁇ cal maintenance interface.
  • the adaptive diagnostic method has high functional flexibility and scalability.
  • a simple expandability of existing diagnostic oracle by changing existing analysis algorithms without retroactivity to the system is possible.
  • Figure 1 system components in conjunction with a Diagnoseorakel and Figure 2 shows the structure of a Diagnoseorakels. The principle of the diagnostic oracle is shown in FIG.
  • Diagnostic data is transferred to a diagnostic oracle via interfaces to system components.
  • the initiative for the over ⁇ reproducing diagnostic data to the diagnostic oracle can either come from the diagnostic oracle - Hole duty - or temkomponenten from the Sys ⁇ - Bring duty.
  • the incoming data is evaluated on the basis of stored rules. The rules allow an assessment of the system status. If required, several diagnostic data from different system components can be linked and evaluated to assess the system status. Additional processing steps such as filtering and extrapolation are possible in order to be able to make a prognosis in the diagnostic oracle about possible fault conditions of the system.
  • the diagnostic oracle If indications of an error condition in the system can be derived on the basis of the incoming data, the diagnostic oracle outputs control instructions to the components of the system which lead to an increased diagnostic data flow from the system components to the diagnostic oracle. It is thus by the diagnostic oracle a direct influence on the out ⁇ reproducing behavior agnose of system components with respect to Systemdi-.
  • the diagnostic oracle specifically Dieje ⁇ Nigen system components in enhanced diagnostic output mode in which indicia have been identified for faulty system conditions or which can provide for fault analysis, relevant In ⁇ formations. These components then produce a correspondingly larger data output and provide the diagnostic oracle with detailed data that allows later accurate analysis of the faulty system behavior.
  • the nose schemes the diagnostic oracle based diagnostic rules and Diag ⁇ controlled activities in case of error events may include in addition to the activation of additional diagnostic output of the system components further action. For example, the long-term storage of the data associated with the error event is activated, or messages are issued to higher level entities.
  • the Diagnoseorakel is responsible for the occurrence of diagnostic or Feh ⁇ lerereignissen that suitable diagnostic data in sufficient quantity and depth of information obtained, aufbe ⁇ rides and filed. In addition, it provides for further ⁇ reproducing messages and data to system interfaces, such as system maintenance to se on certain event ⁇ in the system to inform.
  • the diagnostic oracle can also provide information limiting and suppression functions which ensure that parallel and repeated messages about the same event - informational show - are omitted.
  • the accuracy of the error events detected by the diagnostic oracle depends on the complexity of the system and the rules stored in the diagnostic oracle. According to the accuracy and complexity of the stored rules, the diagnostic oracle will be able to perform more or less exact analyzes and appropriate actions. For example, setting a threshold value depends on how quickly the diagnostic oracle responds to data that may indicate a departure from normal operation.
  • the inventive method requires the interaction of system components and Diagnoseorakel on special Thomas ⁇ places.
  • the interface between the diagnostic oracle and the system is specific to each system component. Diagnostic data flows from the system component to the diagnostic oracle via the interface .
  • the type and scope of the transmitted diagnostic data depend on the system component and the required output scope - trace level.
  • the diagnostic data is used in the diagnostic oracle to infer the behavior and possible errors in the system.
  • the functions of the diagnosis which analyze the state of the system and are no longer implemented in the system components, but in the diagnostic oracle.
  • the system components supply diagnostic data resulting from their specific function in the system to the diagnostic oracle.
  • the scope of the data supplied to the diagnostic oracle is the diagnostic ⁇ oracle according to the results of condition analysis regu ⁇ lines.
  • the diagnostic data supplied by the system components to the diagnostic oracle are raw data that does not require analysis in the system components for diagnostic purposes. As a result, the structure of the system components can be made easier.
  • the system components must be able to generate the data output to the diagnostic oracle according to the required trace level.
  • the performance of a system component can be modeled and checked under the boundary condition of the maximum data output to the diagnostic oracle. If, in this case, a component works as required and the diagnostic oracle has separate system resources, it can be assumed that system diagnostics will not cause any undue repercussion on system performance.
  • the system design defines the diagnostic functions for each system component.
  • the definition is about data and rules that a system component for the diagnosis ⁇ oracle exported.
  • the regulations contain rules for the processing and interpretation of the diagnostic data supplied by the system component. They also define diagnostic events that occur when certain diagnostic data or analysis results occur.
  • the regulations contain instructions for activities of the diagnostic oracle to be performed after the occurrence of diagnostic events. For example, these activities may involve switching trace level for different system components or output data to external interfaces.
  • the accuracy and precision depends the function of the di ⁇ agnoseorakels from decisive. This means that when designing the system components with the definition of the interface to the diagnostic oracle also its function and quality are determined.
  • the diagnostics data of several system components can be received and further processed by the diagnostic oracle become. This offers the possibility of diagnosing ⁇ data of various system components combine together in order to draw conclusions about error conditions in the system. This forecasts are possible diagnostic oracle on much broader basis and Beurtei ⁇ lung parent and complex system states.
  • FIG. 2 An example of the realization of a diagnosis oracle shows Figure 2.
  • the information from the system ready make ⁇ can be obtained in a form suitable for the diagnostic oracle.
  • interface-specific adapters can be used.
  • the interface adapters can also handle the switching of the trace level in the system components.
  • the diagnostic oracle can perform any number of plausibility checks - as a plausibility oracle.
  • the plausibility oracle can link all ready rack ⁇ th primary diagnostic data in any desired manner and process to conclude on the diagnostic state of the Sys tems ⁇ .
  • a radar system In a vehicle, a radar system is used to measure the distance.
  • the radar system is connected via a diagnostic interface to the diagnostic oracle and continuously provides the current data for travel and speed.
  • the Diagnostics ⁇ oracle the output data of the radar system are analyzed. Path and speed, for example, are checked for continuous progress within given tolerances. As long as the data of the radar system indicates that the device is functioning correctly, no action is taken by the diagnostic oracle. If, for example, sudden changes in the output speed appear, this is considered by the oracle as an indicator of faulty behavior.
  • the diagnostic oracle increases the trace level for the radar output in this case.

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Quality & Reliability (AREA)
  • Computing Systems (AREA)
  • Health & Medical Sciences (AREA)
  • Biomedical Technology (AREA)
  • Mathematical Physics (AREA)
  • Computer Vision & Pattern Recognition (AREA)
  • Computer Hardware Design (AREA)
  • Test And Diagnosis Of Digital Computers (AREA)
  • Testing And Monitoring For Control Systems (AREA)

Abstract

The invention relates to a method for diagnosing technical systems comprising several system components. In order to reduce the volume of diagnostic data to be transmitted, central system diagnostics, i.e. a diagnostic oracle, are provided. Said diagnostic oracle controls the type and the amount of diagnostic data to be transmitted to the diagnostic oracle by the system components in accordance with previously transmitted diagnostic data and rules filed in the diagnostic oracle.

Description

Beschreibungdescription
Verfahren zur Systemdiagnose in technischen SystemenMethod for system diagnostics in technical systems
Die Erfindung betrifft ein Verfahren zur Systemdiagnose in technischen Systemen mit mehreren SystemkomponentenThe invention relates to a method for system diagnosis in technical systems with several system components
Derartige komplexe Systeme bestehen oft aus mehreren rechen¬ technischen Systemkomponenten, d. h. Verarbeitungseinheiten, die miteinander durch Austausch von Daten in Wechselwirkung stehen. Die jeweiligen Verarbeitungseinheiten besitzen einen mehr oder weniger großen Umfang an eigenständig ablaufenden Funktionen sowie eine Anzahl von Schnittstellen zur Umwelt. Über Schnittstellen werden zwei oder mehr Verarbeitungsein- heiten miteinander gekoppelt und dadurch in ihrer Funktion voneinander entkoppelt . In derart aufgebauten Architekturen können neben Prozessoren beispielsweise auch Sensoren und Aktoren eingebunden sein.Such complex systems often consist of several computational ¬ technical system components, ie processing units that interact with each other by exchanging data. The respective processing units have a more or less large amount of self-running functions as well as a number of interfaces to the environment. Two or more processing units are coupled to one another via interfaces and are thereby decoupled in their function from one another. In architectures constructed in this way, in addition to processors, for example, sensors and actuators can also be integrated.
Bei verteilten Echtzeitsystemen werden meist sehr kurze Reaktionszeiten auf Zustandsänderungen im System auch über die Grenzen der Schnittstellen verschiedener Verarbeitungseinheiten benötigt. In diesen Systemen ist neben einem ausreichend schnellen Datenaustausch meistens die Kapazität der Datenver- arbeitung in der Verarbeitungseinheit eine knappe Ressource. Durch geeignete Dekomposition der Systemanforderungen auf Verarbeitungseinheiten - funktionale Kohärenz - und Minimierung der Anforderungen an die Datenübertragung - Kapselung - werden Performanceprobleme minimiert .In distributed real-time systems, very short reaction times to changes in the state of the system are usually required across the boundaries of the interfaces of different processing units. In these systems, in addition to a sufficiently fast data exchange, the capacity of the data processing in the processing unit is usually a scarce resource. By properly decomposing the system requirements onto processing units - functional coherence - and minimizing the data transfer requirements - encapsulation - performance problems are minimized.
Bei einer Reihe von komplexen Systemen liegt die Verteilung der Verarbeitungseinheiten darin begründet, dass es sich um mobile Einheiten handelt, die untereinander und/oder mit ortsfesten Systemkomponenten kommunizieren, meistens unter Verwendung von Funktechnik. Die Funkanbindung ist eine systembestimmende Schnittstelle, die oft nicht nur dem Austausch von Prozessdaten dient, sondern zugleich auch der Systemdiagnose .In a number of complex systems, the distribution of the processing units is based on the fact that they are mobile units that communicate with each other and / or with stationary system components, mostly below Use of radio technology. The radio connection is a system-determining interface, which often serves not only for the exchange of process data, but at the same time also for system diagnostics.
Weiterhin ist die räumliche Anordnung von Systemzugängen ein wichtiger Grund für deren Verteilung, wie beispielsweise bei Kommunikationsnetzen .Furthermore, the spatial arrangement of system accesses is an important reason for their distribution, such as in communication networks.
Sicherheitsrelevante Systeme, beispielsweise Eisenbahnsiche¬ rungssysteme, besitzen oft mehrere interagierende Verarbei¬ tungseinheiten unterschiedlicher Sicherheitsanforderungsstu- fen - Safety Integrity Level - SIL. Da der Entwicklungsauf¬ wand für sicherheitsrelevante Anforderungen mit zunehmendem SIL ansteigt, besteht für diese Systeme das wirtschaftliche Interesse, Funktionen unterschiedlicher Sicherheitsanforde- rungsstufen in separaten Verarbeitungseinheiten anzuordnen.Safety-related systems, such as railway Siche ¬ insurance systems, often have multiple interacting proces ¬ processing units of different Sicherheitsanforderungsstu- fen - Safety Integrity Level - SIL. Since the Entwicklungsauf ¬ wall rises for safety-related requirements with increasing SIL, is for these systems, the economic interest, functions of different safety requirements approximately stepped in separate processing units to order.
Die Kopplung der Verarbeitungseinheiten verteilter Systeme kann synchron oder asynchron erfolgen. Bei synchroner Kopplung erfolgt der Datenaustausch zyklisch durch Abgleich interner Prozesszustände . Bei asynchroner Kopplung werden Daten ereignisorientiert ausgetauscht, wodurch das Datenaufkommen geringer ist. Asynchrone Schnittstellen, über die ereignis- orientiert Daten ausgetauscht werden, können im Gesamtsystem dann zu Problemen führen, wenn eine Verarbeitungseinheit aus¬ gefallen ist. Da in diesem Fall keine Ereignisse mehr beim Schnittstellenpartner eintreffen, müssen spezielle Mechanismen für die Ausfalloffenbarung eingesetzt werden. Dieses Problem wird bei synchronen Schnittstellen implizit gelöst, da ein Ausfall automatisch durch Ausbleiben der Daten offenbart wird. Verteilte komplexe Systeme benötigen systeminterne Diagnose¬ funktionen, um wirtschaftlich wartbar zu sein. An die Systemdiagnose werden erheblich höhere Anforderungen gestellt, als beispielsweise nur die Information des Nutzers über ausgefal- lene Komponenten. Durch einen steigenden Anteil von Software und immer komplexere Strukturen auf der Basis zunehmend leis¬ tungsfähiger Hardware erhält die Systemdiagnose einen neuen Stellenwert. Systementwickler benötigen interne Prozesszu- stände und Prozesshistorie für die Analyse und Beseitigung komplexer Fehlerbilder. Kunden benötigen Informationen über Ausfälle und den Betriebszustand der Anlage. Dispatching- Dienste benötigen für die Betriebsüberwachung gefilterte und aufbereitete Daten von Systemschnittstellen, anhand derer Leistungsparameter und Auslastung der Anlage protokolliert und gesteuert werden können. Für Wartungs- und Inbetriebset¬ zungsdienste sind Informationen zu Wartungsmaßnahmen, Ersatzteilen und Prüfung der Anlage notwendig.The coupling of the processing units of distributed systems can be synchronous or asynchronous. In the case of synchronous coupling, data is exchanged cyclically by adjusting internal process states. With asynchronous coupling, data is exchanged in an event-oriented manner, which reduces the amount of data. Asynchronous interfaces, via which event-oriented data are exchanged, can lead to problems in the overall system if a processing unit has fallen out of ¬ . Since in this case no more events arrive at the interface partner, special mechanisms for the failure disclosure must be used. This problem is solved implicitly in synchronous interfaces, as a failure is automatically revealed by the lack of data. Distributed complex systems require system-internal diagnostic functions ¬ to be economically maintainable. The system diagnostics are subject to considerably higher requirements than, for example, only the user's information about failed components. With an increasing share of software and increasingly complex structures based on increasingly slightest ¬ processing performance hardware system diagnostics is given a new significance. System developers require internal process statuses and process histories for the analysis and elimination of complex fault patterns. Customers require information about failures and the operating status of the system. Dispatching services require filtered and prepared data from system interfaces for operation monitoring, which can be used to log and control system performance parameters and utilization. For maintenance and Inbetriebset ¬ Zung services information is necessary to maintenance, spare parts and system test.
Neben den inhaltlich verschiedenen Diagnoseinformationen spielen auch die Art der Übermittlung und die geeignete Auf¬ bereitung der Diagnosedaten eine wesentliche Rolle. Oft be¬ steht die Anforderung an die Verarbeitungseinheiten, die Diagnosedaten in einem Netzwerk an eine zentrale Stelle oder an mehrere spezialisierte Stellen zu übermitteln, so dass auf- wendige manuelle Datenlogistik vermieden wird. In der Regel sollen dafür die bestehenden Übertragungseinrichtungen mitbenutzt werden. Meistens müssen die Daten außerdem entsprechend gefiltert, verdichtet und aufbereitet werden, um erstens das Datenaufkommen im Übertragungsnetz zu begrenzen bzw. mittels Prioritätensteuerung zu regulieren und zweitens eine zeitsparende Auswertung zu ermöglichen.In addition to the content of various diagnostic information, the type of communication, and appropriate to ¬ play of the diagnostic data preparation an essential role. Often be ¬ is the request to the processing units to transmit diagnostic data on a network to a central location or several specialized sites such that up consuming, manual data logistics is avoided. As a rule, the existing transmission facilities should be shared. In most cases, the data must also be appropriately filtered, condensed and processed in order firstly to limit the data volume in the transmission network or to regulate it by means of priority control and secondly to enable a time-saving evaluation.
Die hohen Anforderungen an die Diagnosefähigkeit in verteil¬ ten komplexen Systemen müssen bereits bei den Architekturent- Scheidungen berücksichtigt werden. Ein nachträgliches Einbau¬ en von Diagnoseeinrichtungen in ein bestehendes System ist technisch und wirtschaftlich nicht effektiv.The high demands on the diagnostic capability in distribution ¬ th complex systems have already been in the Architekturent- Divorces are considered. A subsequent installation ¬ s of diagnostic facilities in an existing system is not technically and economically effective.
Komplexe softwarebasierte Systeme sind modular strukturiert. Die Diagnose ist mindestens bezüglich der Datengewinnung integraler Bestandteil des Systems. Software-Module erzeugen bei festgelegten Ereignissen oder nach bestimmten Regimen, beispielsweise zeitbasiert, Diagnosedaten, um neben ihrer Systemfunktion zustandsbezogene Diagnoseinformationen verfügbar zu machen. Oft kann der Umfang der Diagnosemeldungen durch Projektierung oder Konfiguration eingestellt werden, um beispielsweise in Phasen der Systemstabilisierung oder Fehlersuche mehr oder detailliertere Diagnosedaten erhalten zu können als im Regelbetrieb eines Systems. Vielfach werden die auf modularer Ebene gewonnenen Diagnosedaten anschließend zu einer speziell für Diagnosezwecke konzipierten Diagnoseverarbeitungseinheit übertragen und dort weiterverarbeitet und ge¬ speichert. Es können eine oder mehrere Diagnoseverarbeitungs- einheiten im System angeordnet sein. Diagnoseverarbeitungs¬ einheiten können neben den Schnittstellen zu den Softwaremodulen weitere Schnittstellen zu externen Geräten, z. B. Sensoren, oder zum Menschen - MMI - aufweisen. In der Regel besitzen sie auch Speichermöglichkeiten für Diagnosedaten. Für die Auswertung und Interpretation der Daten werden oft weitere separate Vorrichtungen und Programme benutzt. Eine übliche Methode ist der rechnergestützte Zugriff auf die Daten von Diagnoseverarbeitungseinheiten, um die gesammelten Diagnosedaten beispielsweise abzurufen, auszuwerten und zu archivie- ren .Complex software-based systems are modular in structure. The diagnosis is an integral part of the system at least in terms of data acquisition. Software modules generate diagnostic data for specified events or for specific regimes, for example time-based, in order to make condition-related diagnostic information available in addition to their system function. Often, the scope of the diagnostic messages can be set by configuration or configuration in order to be able to obtain more or more detailed diagnostic data in phases of system stabilization or troubleshooting, for example, than in normal operation of a system. In many cases the diagnosis data obtained in modular plane are then transferred to a specially designed for diagnostic purposes diagnosis processing unit and further processed there and stores ge ¬. One or more diagnostic processing units may be located in the system. Diagnoseverarbeitungs ¬ units in addition to the interfaces to the software modules more interfaces to external devices, eg. As sensors, or to humans - MMI - have. As a rule, they also have storage facilities for diagnostic data. For the evaluation and interpretation of the data, other separate devices and programs are often used. A common method is the computer-aided access to the data of diagnostic processing units, for example, to retrieve the collected diagnostic data, evaluate and archive.
Typisch für komplexe verteilte Systeme ist eine hierarchische Struktur, bei der Diagnose-Primär-Informationen dezentral auf Ebene von Softwaremodulen oder Hardwarekomponenten gewonnen werden und zu speziellen Diagnoseverarbeitungseinheiten ü- bertragen und weiterverarbeitet werden. Art und Umfang der Diagnosedatenerzeugung ist in Softwaremodulen entweder fest codiert oder über Parameter einstellbar.Typical of complex distributed systems is a hierarchical structure in which diagnostic primary information is obtained decentrally at the level of software modules or hardware components and transferred to special diagnostic processing units and further processed. The type and extent of diagnostic data generation is either permanently coded in software modules or can be set via parameters.
Ein häufiges Problem bei der Systemdiagnose besonders im Zu¬ sammenhang mit komplexen Softwarefehlern liegt im Umfang der Diagnosedaten. Werden zu wenige Diagnosedaten protokolliert, reichen die verfügbaren Daten gegebenenfalls nicht aus, um auftretende Fehler detailliert analysieren oder reproduzieren zu können. Andererseits führt die massive Erzeugung und Spei¬ cherung von Diagnosedaten, z. B. Tracing, oft zu erheblichen Datenmengen, die einen hohen Aufwand für Speicherung, Logistik, und Auswertung erfordern und damit die Systemkosten er- höhen. Weiterhin kann die massive Erhöhung des Diagnosedatenaufkommens zu Performanceproblemen und einem veränderten Zeitverhalten des Systems führen, was die Systemnutzung unerwünscht beeinflusst.A common problem with the system diagnostics, particularly in the To ¬ connexion with complex software errors is within the scope of the diagnostic data. If too few diagnostic data are logged, the available data may not be sufficient to analyze or reproduce errors in detail. On the other hand, the massive production and Spei leads ¬ assurance of diagnostic data, eg. For example, tracing often leads to considerable amounts of data requiring a great deal of storage, logistics, and evaluation, thereby increasing system costs. Furthermore, the massive increase of the diagnostic data volume can lead to performance problems and a changed time behavior of the system, which undesirably influences the system usage.
Der Erfindung liegt die Aufgabe zugrunde, diese Nachteile zu beseitigen und ein Verfahren der gattungsgemäßen Art anzugeben, bei dem Art und Umfang der zu übertragenden Diagnosedaten optimiert sind, wobei das Datenvolumen so weit wie möglich reduziert werden soll.The invention has for its object to overcome these disadvantages and to provide a method of the generic type, are optimized in the nature and extent of the diagnostic data to be transmitted, the data volume should be reduced as much as possible.
Erfindungsgemäß wird die Aufgabe dadurch gelöst, dass eine zentrale Systemdiagnose, d. h. ein Diagnoseorakel, vorgesehen ist, wobei das Diagnoseorakel Art und Umfang der von den Sys¬ temkomponenten an das Diagnoseorakel zu übertragenden Diagno- sedaten in Abhängigkeit von bereits übergebenen Diagnosedaten und im Diagnoseorakel hinterlegten Regeln steuert.According to the invention the object is achieved in that a central system diagnosis, ie a Diagnoseorakel, is provided, wherein the Diagnoseorakel type and extent of the sys ¬ temkomponenten to be transmitted to the Diagnoseorakel diagnostic sedata depending on already passed diagnostic data and stored in the diagnostic oracle rules controls.
Mit dem erfindungsgemäßen Verfahren wird eine Diagnosefunktionalität im System eingeführt, welche eine automatische adap- tive Regelung des Diagnosedatenaufkommens in Abhängigkeit von festgelegten Regeln, insbesondere bezüglich Ereignissen oder Schwellwerten, erlaubt. Die Diagnosefunktionalität beinhaltet Regeln für die Interpretation der aktuellen Diagnosedaten und steuert anhand dieser Regeln Art und Umfang der zukünftig zu generierenden Diagnosedaten.With the method according to the invention, a diagnostic functionality is introduced in the system, which provides an automatic adaptive tive control of the diagnostic data in dependence on defined rules, in particular with respect to events or thresholds allowed. The diagnostic functionality contains rules for interpreting the current diagnostic data and uses these rules to control the type and scope of future diagnostic data.
Weiterhin übernimmt die Diagnosefunktionalität neben der a- daptiven Steuerung des Diagnosedatenaufkommens bei Bedarf die Steuerung der Weiterverarbeitung, Speicherung, Übertragung und Ausgabe von Diagnosemeldungen. Sie bildet damit ein so genanntes Diagnoseorakel.In addition to the adaptive control of the diagnostic data volume, the diagnostic functionality also takes over the control of further processing, storage, transmission and output of diagnostic messages as required. It thus forms a so-called diagnostic oracle.
Das erfindungsgemäße Verfahren deckt unterschiedliche Diagno- seanforderungen mit einem einheitlichen Konzept ab - Entwicklerdiagnose, Kundendiagnose, Systemwartung. Die Systement¬ wicklung wird durch die konsequente Trennung von System- und Diagnosefunktionen besser modularisiert . Das Design der Systemkomponenten vereinfacht sich. Durch das verfahrensbedingte Komponentendesign verbessert sich die Testbarkeit des Sys¬ tems. Die Trennung von Diagnose und Systemfunktion vermeidet unerwünschte Rückwirkungen auf das System bei erhöhten Diagnoseaktivitäten .The method according to the invention covers different diagnostic requirements with a uniform concept - developer diagnosis, customer diagnosis, system maintenance. The Systement ¬ development will be better modularized by the consistent separation of system and diagnostic functions. The design of the system components is simplified. Through the process-related components, the design testability of the Sys tems ¬ improved. The separation of diagnostics and system function avoids undesirable repercussions on the system with increased diagnostic activity.
Die Entwicklung von Diagnosefunktion - Diagnoseorakel - undThe development of diagnostic function - diagnostic oracle - and
Systemfunktion kann getrennt erfolgen, wenn die Schnittstelle zwischen System und Diagnoseorakel spezifiziert istSystem function can be done separately if the interface between system and diagnostic oracle is specified
Das Diagnoseorakel kann als Testwerkzeug verwendet werden. Die Verwendung ist sowohl während der Systementwicklung, als auch während des Betriebes des Systems möglich. Die Diagnosefunktionen können in separater Hardware ablaufen, wobei die Diagnosefähigkeit des Systems auch bei ausgefalle¬ nen Systemkomponenten erhalten bleibt .The diagnostic oracle can be used as a test tool. Use is possible during system development as well as during operation of the system. The diagnostic functions can be carried out in separate hardware, whereby the diagnostic capability of the system is maintained even if the system components fail .
Durch das adaptive Verfahren werden automatisch Daten in ausreichender Menge und Informationstiefe gewonnen, die für eine spätere Analyse der Systemfehler notwendig sind. Dabei sorgt das Verfahren dafür, dass der Umfang der entstehenden Diagnosedaten auf ein Minimum reduziert wird. Mit dem Wegfall über- flüssiger nicht benötigter Diagnosedaten werden Speicher- und Logistikaufwand optimiert. In Echtzeitsystemen können Performanceprobleme vermieden werden, indem Diagnosefunktionen ausgelagert werden und die Systemlast auch bei hohem Tracedaten- aufkommen deterministisch bleibt.The adaptive method automatically retrieves data in sufficient quantity and depth of information necessary for later analysis of system errors. The procedure ensures that the scope of the resulting diagnostic data is reduced to a minimum. With the elimination of superfluous unneeded diagnostic data, storage and logistics costs are optimized. In real-time systems, performance problems can be avoided by offloading diagnostic functions and keeping the system load deterministic even with high volumes of trace data.
Die zentrale Diagnosefunktion des Diagnoseorakels ermöglicht die einfache Ankopplung an zentrale Dienste, z. B. Datenspei¬ cher, und Systemschnittstellen, wie beispielsweise eine zent¬ rale Wartungsschnittstelle.The central diagnostic function of the diagnostic oracle enables easy connection to central services, eg. B. Datenpei ¬ cher, and system interfaces, such as a cent ¬ cal maintenance interface.
Wegen der variablen Definition von Daten und Verarbeitungsvorschriften im Diagnoseorakel und zu den Schnittstellen von Systemkomponenten besitzt das adaptive Diagnoseverfahren eine hohe funktionale Flexibilität und Skalierbarkeit. Damit ist beispielsweise auch eine einfache Erweiterungsfähigkeit be¬ stehender Diagnoseorakel durch Veränderung bestehender Analysealgorithmen ohne Rückwirkung auf das System möglich.Because of the variable definition of data and processing rules in the diagnostic oracle and to the interfaces of system components, the adaptive diagnostic method has high functional flexibility and scalability. Thus, for example, a simple expandability of existing diagnostic oracle by changing existing analysis algorithms without retroactivity to the system is possible.
Vorteilhafte Weiterbildungen sind in den Unteransprüchen ge- kennzeichnet und werden nachfolgend anhand figürlicher Dar¬ stellungen näher erläutert. Es zeigen:Advantageous further developments are characterized in the dependent claims and are explained in more detail below with reference to figurative Dar ¬ positions. Show it:
Figur 1 Systemkomponenten im Zusammenwirken mit einem Diagnoseorakel und Figur 2 den Aufbau eines Diagnoseorakels. Das Prinzip des Diagnoseorakels ist in Figur 1 gezeigt.Figure 1 system components in conjunction with a Diagnoseorakel and Figure 2 shows the structure of a Diagnoseorakels. The principle of the diagnostic oracle is shown in FIG.
Über Schnittstellen zu Systemkomponenten werden Diagnosedaten an ein Diagnoseorakel übergeben. Die Initiative für die Über¬ gabe von Diagnosedaten an das Diagnoseorakel kann entweder vom Diagnoseorakel ausgehen - Holepflicht - oder von den Sys¬ temkomponenten - Bringepflicht. Im Diagnoseorakel werden die eintreffenden Daten anhand von hinterlegten Regeln bewertet. Die Regeln erlauben eine Beurteilung des Systemzustandes. Für die Beurteilung des Systemzustandes können bei Bedarf mehrere Diagnosedaten unterschiedlicher Systemkomponenten verknüpft und ausgewertet werden. Zusätzliche Verarbeitungsschritte wie beispielsweise Filterung und Extrapolation sind möglich, um im Diagnoseorakel eine Prognose über mögliche Fehlerzustände des Systems treffen zu können.Diagnostic data is transferred to a diagnostic oracle via interfaces to system components. The initiative for the over ¬ reproducing diagnostic data to the diagnostic oracle can either come from the diagnostic oracle - Hole duty - or temkomponenten from the Sys ¬ - Bring duty. In the diagnostic oracle, the incoming data is evaluated on the basis of stored rules. The rules allow an assessment of the system status. If required, several diagnostic data from different system components can be linked and evaluated to assess the system status. Additional processing steps such as filtering and extrapolation are possible in order to be able to make a prognosis in the diagnostic oracle about possible fault conditions of the system.
Lassen sich anhand der eintreffenden Daten Indizien für einen Fehlerzustand im System ableiten, werden durch das Diagnose- orakel Steueranweisungen an die Komponenten des Systems ausgegeben, die zu einem erhöhten Diagnosedatenfluss von den Systemkomponenten zum Diagnoseorakel führen. Es erfolgt also durch das Diagnoseorakel eine direkte Beeinflussung des Aus¬ gabeverhaltens von Systemkomponenten bezüglich der Systemdi- agnose. Dabei werden durch das Diagnoseorakel gezielt dieje¬ nigen Systemkomponenten in erhöhten Diagnoseausgabemodus geschaltet, in denen Indizien für fehlerhafte Systemzustände ermittelt wurden oder die für die Fehleranalyse relevante In¬ formationen liefern können. Diese Komponenten produzieren daraufhin einen entsprechend umfangreicheren Daten-Output und versorgen das Diagnoseorakel mit detaillierten Daten, die eine spätere genaue Analyse des fehlerhaften Systemverhaltens ermöglichen . Die vom Diagnoseorakel auf Basis von Diagnoseregeln und Diag¬ nosedaten gesteuerten Aktivitäten im Falle von Fehlerereignissen können neben der Aktivierung von zusätzlichem Diagnose-Output der Systemkomponenten weitere Maßnahmen umfassen. Beispielsweise wird die Langzeitspeicherung der Daten, die mit dem Fehlerereignis in Zusammenhang stehen aktiviert, oder es werden Meldungen an übergeordnete Einrichtungen ausgegeben .If indications of an error condition in the system can be derived on the basis of the incoming data, the diagnostic oracle outputs control instructions to the components of the system which lead to an increased diagnostic data flow from the system components to the diagnostic oracle. It is thus by the diagnostic oracle a direct influence on the out ¬ reproducing behavior agnose of system components with respect to Systemdi-. Here are switched by the diagnostic oracle specifically Dieje ¬ Nigen system components in enhanced diagnostic output mode in which indicia have been identified for faulty system conditions or which can provide for fault analysis, relevant In ¬ formations. These components then produce a correspondingly larger data output and provide the diagnostic oracle with detailed data that allows later accurate analysis of the faulty system behavior. The nosedaten the diagnostic oracle based diagnostic rules and Diag ¬ controlled activities in case of error events may include in addition to the activation of additional diagnostic output of the system components further action. For example, the long-term storage of the data associated with the error event is activated, or messages are issued to higher level entities.
Das Diagnoseorakel ist bei Eintritt von Diagnose- oder Feh¬ lerereignissen dafür zuständig, dass geeignete Diagnosedaten in ausreichender Menge und Informationstiefe gewonnen, aufbe¬ reitet und abgelegt werden. Daneben sorgt es für die Weiter¬ gabe von Meldungen und Daten an Systemschnittstellen, wie beispielsweise die Systemwartung, um über bestimmte Ereignis¬ se im System zu informieren. In diesem Zusammenhang können vom Diagnoseorakel auch Funktionen zur Informationsbegrenzung und -Unterdrückung bereitgestellt werden, die dafür sorgen, dass parallele und wiederholte Meldungen zum selben Ereignis - Informationsschauer - unterbleiben.The Diagnoseorakel is responsible for the occurrence of diagnostic or Feh ¬ lerereignissen that suitable diagnostic data in sufficient quantity and depth of information obtained, aufbe ¬ rides and filed. In addition, it provides for further ¬ reproducing messages and data to system interfaces, such as system maintenance to se on certain event ¬ in the system to inform. In this context, the diagnostic oracle can also provide information limiting and suppression functions which ensure that parallel and repeated messages about the same event - informational show - are omitted.
Die Treffsicherheit der durch das Diagnoseorakel erkannten Fehlerereignisse hängt von der Komplexität des Systems und der im Diagnoseorakel hinterlegten Regeln ab. Entsprechend der Genauigkeit und Komplexität der hinterlegten Regeln wird das Diagnoseorakel mehr oder weniger exakte Analysen und dazu passende Aktionen durchführen können. Beispielsweise hängt von der Einstellung eines Schwellwertes ab, wie schnell das Diagnoseorakel auf Daten, die ein Abweichen vom Normalbetrieb bedeuten können, reagiert.The accuracy of the error events detected by the diagnostic oracle depends on the complexity of the system and the rules stored in the diagnostic oracle. According to the accuracy and complexity of the stored rules, the diagnostic oracle will be able to perform more or less exact analyzes and appropriate actions. For example, setting a threshold value depends on how quickly the diagnostic oracle responds to data that may indicate a departure from normal operation.
In einem komplexen System können oft nicht alle Fehlermöglichkeiten vorausschauend analysiert und Kriterien für ihren Eintritt abgeleitet werden. Aus diesem Grund kann es Fehler- ereignisse im System geben, die keine Reaktion im Diagnose¬ orakel bewirken. Andererseits kann es dazu kommen, dass vom Diagnoseorakel Daten als fehlerhaft interpretiert werden, de¬ nen kein fehlerhaftes Systemverhalten zugrunde liegt und die im Diagnoseorakel dennoch entsprechende Aktionen und Steuer¬ flüsse auslösen. Die korrekte Reaktion des Diagnoseorakels hängt somit von der Genauigkeit der auf den hinterlegten Re¬ geln basierenden Datenanalyse ab und wird durch den Entwurf des Diagnoseorakels und seiner Schnittstellen zu den System- komponenten bestimmt.In a complex system, often not all possibilities of error can be analyzed in advance and criteria for their occurrence can be derived. For this reason, it can be error- events in the system provide that no reaction in the diagnostic ¬ oracle effect. On the other hand, it can happen that are interpreted by the diagnostic oracle as defective, de ¬ nen no faulty system behavior underlies and trigger the corresponding still in the diagnostic oracle actions and control ¬ rivers. The correct reaction of the diagnostic oracle thus depends on the accuracy of the rules on the stored Re ¬-based data analysis and components through the design of the diagnostic oracle and its interfaces to the system determined.
Das erfindungsgemäße Verfahren bedingt das Zusammenwirken von Systemkomponenten und Diagnoseorakel über spezielle Schnitt¬ stellen. Die Schnittstelle zwischen Diagnoseorakel und System ist spezifisch für jede Systemkomponente. Über die Schnitt¬ stelle fließen Diagnosedaten von der Systemkomponente in Richtung Diagnoseorakel. Art und Umfang der übertragenen Diagnosedaten hängen von der Systemkomponente und dem geforderten Ausgabeumfang - Tracelevel - ab. Die Diagnosedaten werden im Diagnoseorakel benutzt, um auf das Verhalten und mögliche Fehler im System zu schlussfolgern . Weiterhin fließen über die Schnittstelle Steueranweisungen aus dem Diagnoseorakel in Richtung Systemkomponente, womit die Systemkomponente bezüg¬ lich ihrer Datenausgabe angewiesen wird, mehr oder weniger Diagnosedaten an das Diagnoseorakel zu liefern - Steuerung Tracelevel. Dabei ist bereits bei der Schnittstellendefini¬ tion festgelegt, um welche Art von Diagnosedaten es sich handelt und in welchen Schritten die Ausgabe erhöht oder vermindert werden kann.The inventive method requires the interaction of system components and Diagnoseorakel on special Schnitt ¬ places. The interface between the diagnostic oracle and the system is specific to each system component. Diagnostic data flows from the system component to the diagnostic oracle via the interface . The type and scope of the transmitted diagnostic data depend on the system component and the required output scope - trace level. The diagnostic data is used in the diagnostic oracle to infer the behavior and possible errors in the system. Continue to flow through the interface control instructions from the diagnostic oracle toward the system component with which the system component bezüg ¬ Lich its data output is commanded to provide more or less diagnostic data to the diagnostic oracle - control trace level. It is already established in the Schnittstellendefini ¬ tion to the type of diagnostic data is and can be the steps in which increases the output or reduced.
Mit der Einführung der Schnittstellen zwischen Systemkomponenten und dem Diagnoseorakel sind qualitativ neue Designanforderungen an die Systemkomponenten verbunden. Die Funktionen der Diagnose, die den Zustand des Systems analysieren und bewerten, werden nicht mehr in den Systemkomponenten implementiert, sondern im Diagnoseorakel. Die Systemkomponenten liefern Diagnosedaten, die aus ihrer spezifischen Funktion im System resultieren, an das Diagnoseorakel. Der Umfang der an das Diagnoseorakel gelieferten Daten wird durch das Diagnose¬ orakel entsprechend den Ergebnissen der Zustandsanalyse regu¬ liert. Bei den von den Systemkomponenten an das Diagnoseorakel gelieferten Diagnosedaten handelt es sich um Rohdaten, die in den Systemkomponenten keiner Analyse zwecks Diagnose bedürfen. Dadurch kann der Aufbau der Systemkomponenten einfacher erfolgen.With the introduction of the interfaces between system components and the diagnostic oracle, qualitatively new design requirements for the system components are associated. The functions of the diagnosis, which analyze the state of the system and are no longer implemented in the system components, but in the diagnostic oracle. The system components supply diagnostic data resulting from their specific function in the system to the diagnostic oracle. The scope of the data supplied to the diagnostic oracle is the diagnostic ¬ oracle according to the results of condition analysis regu ¬ lines. The diagnostic data supplied by the system components to the diagnostic oracle are raw data that does not require analysis in the system components for diagnostic purposes. As a result, the structure of the system components can be made easier.
Die Systemkomponenten müssen in der Lage sein, die Datenausgabe an das Diagnoseorakel entsprechend des geforderten Tra- celevels zu generieren. Die Performance einer Systemkomponente kann unter der Randbedingung der maximalen Datenausgabe an das Diagnoseorakel modelliert und geprüft werden. Sofern eine Komponente in diesem Fall anforderungsgemäß arbeitet und das Diagnoseorakel über separate Systemressourcen verfügt, kann davon ausgegangen werden, dass durch die Systemdiagnose keine unzulässige Rückwirkung auf die Systemperformance erfolgt.The system components must be able to generate the data output to the diagnostic oracle according to the required trace level. The performance of a system component can be modeled and checked under the boundary condition of the maximum data output to the diagnostic oracle. If, in this case, a component works as required and the diagnostic oracle has separate system resources, it can be assumed that system diagnostics will not cause any undue repercussion on system performance.
Beim Systemdesign werden die Diagnosefunktionen für jede Systemkomponente definiert. Die Definition erfolgt über Daten und Vorschriften, die eine Systemkomponente für das Diagnose¬ orakel exportiert. Die Vorschriften beinhalten Regeln für die Verarbeitung und Interpretation der von der Systemkomponente gelieferten Diagnosedaten. Sie definieren weiterhin Diagnoseereignisse, die beim Auftreten bestimmter Diagnosedaten oder Analyseergebnisse entstehen. Außerdem enthalten die Vorschriften Anweisungen für Aktivitäten des Diagnoseorakels, die nach dem Eintritt von Diagnoseereignissen durchzuführen sind. Zu diesen Aktivitäten kann beispielsweise die Umschal- tung des Tracelevels für verschiedene Systemkomponenten oder die Ausgabe von Daten an externe Schnittstellen gehören.The system design defines the diagnostic functions for each system component. The definition is about data and rules that a system component for the diagnosis ¬ oracle exported. The regulations contain rules for the processing and interpretation of the diagnostic data supplied by the system component. They also define diagnostic events that occur when certain diagnostic data or analysis results occur. In addition, the regulations contain instructions for activities of the diagnostic oracle to be performed after the occurrence of diagnostic events. For example, these activities may involve switching trace level for different system components or output data to external interfaces.
Von den im Rahmen des Designs der Systemkomponenten festge- legten Diagnosedaten und Vorschriften für die Systemdiagnose hängt die Treffsicherheit und Präzision der Funktion des Di¬ agnoseorakels entscheidend ab. Das bedeutet, dass beim Design der Systemkomponenten mit der Definition der Schnittstelle zum Diagnoseorakel auch dessen Funktion und Qualität bestimmt werden.Of the system components designed fixed as part of the design diagnostic data and rules for system diagnosis, the accuracy and precision depends the function of the di ¬ agnoseorakels from decisive. This means that when designing the system components with the definition of the interface to the diagnostic oracle also its function and quality are determined.
Im Rahmen des Komponentendesigns müssen folgende Festlegungen für die komponentenspezifischen Schnittstellen zum Diagnoseorakel getroffen werden:As part of the component design, the following definitions must be made for the component-specific interfaces to the diagnostic oracle:
1. vorgesehene Tracelevel und Kriterien für deren Wechsel1. intended tracelevel and criteria for their change
2. Spezifikation der Diagnosedaten für die Ausgabe an das Diagnoseorakel, abhängig vom Tracelevel2. Specification of the diagnostic data for output to the diagnostic oracle, depending on the trace level
3. Spezifikation der Steuerflüsse für die Umschaltung der Tracelevel3. Specification of the control flows for switching the trace levels
4. Vorschriften für die Verarbeitung der an das Diagnoseora- kel übertragenen Diagnosedaten, z. B. Filtern, Speichern4. Rules for the processing of the diagnostic data transmitted to the diagnostic B. Filter, Save
5. Diagnoseereignisse und Kriterien für deren Auftreten, z. B. Schwellwerte5. Diagnostic events and criteria for their occurrence, eg. B. Thresholds
6. durchzuführende Aktivitäten infolge von Diagnoseereignis¬ sen .6. activities to be carried out as a result of diagnostic events .
Vom Diagnoseorakel können bei Bedarf die Diagnosedaten mehrerer Systemkomponenten entgegengenommen und weiterverarbeitet werden. Damit bietet sich auch die Möglichkeit, die Diagnose¬ daten verschiedener Systemkomponenten miteinander zu verknüpfen, um daraus Schlussfolgerungen über Fehlerzustände im System zu ziehen. Dadurch werden Prognosen des Diagnoseorakels auf wesentlich breiterer Grundlage möglich sowie die Beurtei¬ lung übergeordneter und komplexer Systemzustände.If necessary, the diagnostics data of several system components can be received and further processed by the diagnostic oracle become. This offers the possibility of diagnosing ¬ data of various system components combine together in order to draw conclusions about error conditions in the system. This forecasts are possible diagnostic oracle on much broader basis and Beurtei ¬ lung parent and complex system states.
Ein Beispiel für die Realisierung eines Diagnoseorakels zeigt Figur 2. In einem System gibt es eine Anzahl verschiedener Diagnose-Interfaces, die Informationen aus dem System bereit¬ stellen. Um die Diagnosedaten in einer für das Diagnoseorakel geeigneten Form zu erhalten, können interfacespezifische A- dapter eingesetzt werden. Die Interfaceadapter können auch die Umschaltung des Tracelevels in den Systemkomponenten ü- bernehmen. Die von den Diagnose-Interfaces gelieferten primä¬ ren Diagnoseinformationen werden durch das Diagnoseorakel anhand von hinterlegten Bewertungsalgorithmen verarbeitet. Dazu kann das Diagnoseorakel eine beliebige Anzahl von Plausibili- tätsprüfungen durchführen - als Plausibilitäts-Orakel darge- stellt. Die Plausibilitäts-Orakel können alle bereitgestell¬ ten primären Diagnosedaten in beliebiger Art und Weise verknüpfen und verarbeiten, um auf den Diagnosezustand des Sys¬ tems zu schlussfolgern . Werden anhand von Indizien Fehlerzu¬ stände neu oder als nicht mehr bestehend erkannt, erfolgt durch die Plausibilitäts-Orakel die Ausgabe von Steuerbefeh¬ len an einen oder mehrere der Interface-Adapter, um die Tra- celevel der zugeordneten Systemkomponenten zu erhöhen oder zu erniedrigen. Weiterhin werden von den Plausibilitäts-Orakeln Anweisungen an einen zentralen Massendaten-Manager ausgege- ben, um dessen Protokollierungsfunktion ein- oder auszuschalten. Der Massendaten-Manager speichert selektiv diejenigen primären Diagnosedaten, die für den aktuellen Fehlerzustand relevant sind. Zusätzlich können weitere Daten der Plausibi¬ litäts-Orakel als Kontextinformation für eine spätere Auswer- tung abgespeichert werden. Über eingetretene Diagnoseereig¬ nisse können sowohl durch die Plausibilitäts-Orakel, als auch durch den Massendaten-Manager Informationen an übergeordnete Subsysteme oder an externe Schnittstellen ausgegeben werden.An example of the realization of a diagnosis oracle shows Figure 2. In a system there are a number of different diagnostic interfaces, the information from the system ready make ¬. To obtain the diagnostic data in a form suitable for the diagnostic oracle, interface-specific adapters can be used. The interface adapters can also handle the switching of the trace level in the system components. The products delivered by the diagnostic interfaces Primae ¬ ren diagnostic information by the diagnostic oracle based on the stored evaluation algorithms processed. For this, the diagnostic oracle can perform any number of plausibility checks - as a plausibility oracle. The plausibility oracle can link all ready rack ¬ th primary diagnostic data in any desired manner and process to conclude on the diagnostic state of the Sys tems ¬. Be based on evidence Fehlerzu ¬ stands new or recognized as no longer composed, performed by the plausibility oracle issuing operation command ¬ len to one or more of the interface adapter to the ordered celevel the associated system components to increase or decrease. Furthermore, the plausibility oracles issue instructions to a central mass data manager in order to switch its logging function on or off. The mass data manager selectively stores those primary diagnostic data relevant to the current error condition. In addition, other data of reasonableness can ¬ litäts Oracle as context information for later evaluation be stored. About incurred Diagnoseereig ¬ nisse, both by the plausibility oracle, and by the mass data manager information to higher-level subsystems or external interfaces are issued.
Die Wirkungsweise des erfindungsgemäßen Verfahrnes wird nach¬ folgend anhand eines einfachen Beispiels erläutert:The operation of the invention is to Verfahrnes ¬ following explained using a simple example:
In einem Fahrzeug wird zur Wegmessung ein Radarsystem einge- setzt. Das Radarsystem ist über eine Diagnoseschnittstelle mit dem Diagnoseorakel verbunden und liefert kontinuierlich die aktuellen Daten für Weg und Geschwindigkeit. Im Diagnose¬ orakel werden die Ausgabedaten des Radarsystems analysiert. Weg und Geschwindigkeit werden beispielsweise auf kontinuier- liehen Verlauf innerhalb gegebener Toleranzen geprüft. Solange die Daten des Radarsystems auf eine korrekte Funktion des Gerätes schließen lassen, werden durch das Diagnoseorakel keine Aktivitäten vorgenommen. Treten beispielsweise sprunghafte Veränderungen der ausgegebenen Geschwindigkeit auf, wird dieses vom Orakel als Indiz für fehlerhaftes Verhalten gewertet. Durch das Diagnoseorakel wird in diesem Fall der Tracelevel für die Radarausgabe erhöht. Dieses bewirkt, dass nun neben Berechnungsergebnissen des Radarsystems nämlich Ort und Geschwindigkeit auch die Radar-Primärdaten vor Filterung und Verarbeitung, wie beispielsweise die Feldstärke des Emp¬ fangssignals, an die Diagnoseschnittstelle ausgegeben werden. Mit Hilfe dieser Primärdaten kann bei späterer Auswertung die Ursache für die Fehlfunktion analysiert werden. Durch das Diagnoseorakel wird die Speicherung aller vom Radarsystem ge- lieferten Daten veranlasst. Außerdem wird die aktuelle Sys¬ temzeit protokolliert. An den zentralen Diagnosedatenspeicher des Fahrzeuges wird eine Diagnosemeldung abgesetzt, die den fehlerhaften Systemzustand des Radarsystems meldet. Die Spei¬ cherung der Radardaten erfolgt über einen vorgegebenen Zeit- räum oder bis das zugrunde liegende Diagnoseereignis nicht mehr besteht. Mit dem Beenden der Protokollierung wird der Tracelevel an der Schnittstelle des Radarsystems zum Diagno¬ seorakel wieder auf den ursprünglichen Wert herabgesetzt. In a vehicle, a radar system is used to measure the distance. The radar system is connected via a diagnostic interface to the diagnostic oracle and continuously provides the current data for travel and speed. In the Diagnostics ¬ oracle the output data of the radar system are analyzed. Path and speed, for example, are checked for continuous progress within given tolerances. As long as the data of the radar system indicates that the device is functioning correctly, no action is taken by the diagnostic oracle. If, for example, sudden changes in the output speed appear, this is considered by the oracle as an indicator of faulty behavior. The diagnostic oracle increases the trace level for the radar output in this case. This causes now in addition to calculation results of the radar system namely place and speed and the radar primary data before filtering and processing, such as the field strength of Emp ¬ catch signal, are output to the diagnostic interface. With the help of this primary data, the cause of the malfunction can be analyzed in a later evaluation. The diagnosis oracle causes the storage of all data supplied by the radar system. In addition, the current Sys ¬ is temzeit logged. At the central diagnostic data memory of the vehicle, a diagnostic message is issued, which reports the faulty system state of the radar system. The SpeI ¬ assurance of the radar data is carried out over a predetermined time or until the underlying diagnostic event no longer exists. With the completion of the logging of the trace level at the interface of the radar system to Diagno ¬ seorakel is reduced again to the original value.

Claims

Patentansprüche claims
1. Verfahren zur Systemdiagnose in technischen Systemen mit mehreren Systemkomponenten, dadurch gekennzeichnet, dass eine zentrale Systemdiagnose, d. h. ein Diagnoseorakel, vorgesehen ist, wobei das Diagnoseorakel Art und Umfang der von den Systemkomponenten an das Diagnoseorakel zu übertra¬ genden Diagnosedaten in Abhängigkeit von übergebenen Prozess- daten und im Diagnoseorakel hinterlegten Regeln steuert.1. Method for system diagnosis in technical systems having a plurality of system components, characterized in that a central system diagnosis, ie a Diagnoseorakel is provided, wherein the Diagnoseorakel type and extent of the system components to the Diagnoseorakel transmis ¬ ing diagnostic data in dependence on passed process - Controls data and rules stored in the diagnostic oracle.
2. Verfahren nach Anspruch 1, dadurch gekennzeichnet, dass das Diagnoseorakel ereignisgesteuerte Diagnosefunktio- nen, insbesondere hinsichtlich Datenverarbeitung, -speicherung und -ausgäbe, ausführt.2. The method according to claim 1, characterized in that the Diagnoseorakel event-driven Diagnosefunktio- nen, in particular with regard to data processing, storage and -ausgäbe executed.
3. Verfahren nach einem der vorangehenden Ansprüche, dadurch gekennzeichnet, dass das Diagnoseorakel die regelbasierte Auswertung der Di¬ agnosedaten hinsichtlich des Systemzustandes und möglicher Systemfehler, Generierung von Diagnoseereignissen infolge aufgetretener Systemfehler, Bestimmung des Ausgabeverhaltens von Systemkomponenten - Tracelevel - und Durchführung weite- rer an Diagnoseereignisse gebundener Aktivitäten, insbesonde¬ re die Generierung von Diagnosemeldungen, ausführt.3. The method according to any one of the preceding claims, characterized in that the Diagnoseorakel the rule-based evaluation of Di ¬ agnosedaten with regard to the system state and possible system errors, generation of diagnostic events due to system errors occurred, determination of the output behavior of system components - Tracelevel - and implementation further Diagnosis events bound activities, in particular ¬ re the generation of diagnostic messages executes.
4. Verfahren nach einem der vorangehenden Ansprüche, dadurch gekennzeichnet, dass zwischen jeder Systemkomponente und dem Diagnoseorakel eine komponentenspezifische Schnittstelle definiert wird, die neben der Definition der möglichen Tracelevel und der trace- levelspezifischen, an das Diagnoseorakel zu übergebenden Diagnosedaten auch die Festlegung der Steuerflüsse vom Diagno- seorakel zu den Systemkomponenten, mit denen das Ausgabeverhalten der Systemkomponente gesteuert wird, beinhaltet.4. The method according to any one of the preceding claims, characterized in that between each system component and the Diagnoseorakel a component-specific interface is defined, in addition to the definition of the possible Tracelevel and the trace level specific, to be passed to the Diagnoseorakel diagnostic data and the definition of the control flows from diagnosis Seccelerates to the system components that control the output behavior of the system component includes.
5. Verfahren nach einem der vorangehenden Ansprüche, dadurch gekennzeichnet, dass das Design der Systemkomponenten verändert wird, indem Diagnosefunktionen in das Diagnoseorakel verlagert werden.5. The method according to any one of the preceding claims, characterized in that the design of the system components is changed by diagnostic functions are moved to the Diagnoseorakel.
6. Verfahren nach einem der vorangehenden Ansprüche, dadurch gekennzeichnet, dass von den Systemkomponenten Regeln für die Systemdiagnose definiert werden, die die Auswertung der Diagnosedaten, Kriterien für die Bewertung des Systemzustandes und Aktivitäten für systemspezifische Fehlerzustände beinhalten und im Diag- noseorakel umgesetzt werden.6. The method according to any one of the preceding claims, characterized in that are defined by the system components rules for system diagnostics, which include the evaluation of the diagnostic data, criteria for assessing the system state and activities for system-specific error conditions and are implemented in the diagnostic oracle.
7. Verfahren nach einem der vorangehenden Ansprüche, dadurch gekennzeichnet, dass im Diagnoseorakel die Diagnosedaten verschiedener Sys- temkomponenten derart miteinander verknüpft werden, dass Diagnoseinformationen über komplexe Systemzustände gewonnen werden .7. The method according to any one of the preceding claims, characterized in that in the diagnostic oracle, the diagnostic data of various system components are linked together such that diagnostic information about complex system states are obtained.
8. Verfahren nach einem der vorangehenden Ansprüche, dadurch gekennzeichnet, dass mittels adaptiver Steuerung des Datenflusses von den Systemkomponenten zum Diagnoseorakel Umfang und Informations¬ tiefe der Diagnosedaten automatisch systemzustandsabhängig derart reguliert werden, dass einerseits die anfallende Diag- nosedatenmenge reduziert und andererseits ein Mangel an rele¬ vanten Diagnosedaten zur Fehleranalyse vermieden wird. 8. The method according to any one of the preceding claims, characterized in that by means of adaptive control of the data flow from the system components to Diagnoseorakel extent and information ¬ depth of the diagnostic data automatically system state dependent so regulated that on the one hand reduces the resulting diagnostic nosedatenmenge and on the other hand, a lack of rele ¬ major diagnostic data for error analysis is avoided.
EP06792815A 2005-08-24 2006-08-15 Method for diagnosing technical systems Withdrawn EP1917595A2 (en)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
DE200510040822 DE102005040822A1 (en) 2005-08-24 2005-08-24 Method for system diagnostics in technical systems
PCT/EP2006/065309 WO2007023106A2 (en) 2005-08-24 2006-08-15 Method for diagnosing technical systems

Publications (1)

Publication Number Publication Date
EP1917595A2 true EP1917595A2 (en) 2008-05-07

Family

ID=37671346

Family Applications (1)

Application Number Title Priority Date Filing Date
EP06792815A Withdrawn EP1917595A2 (en) 2005-08-24 2006-08-15 Method for diagnosing technical systems

Country Status (3)

Country Link
EP (1) EP1917595A2 (en)
DE (1) DE102005040822A1 (en)
WO (1) WO2007023106A2 (en)

Families Citing this family (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE102008043094A1 (en) 2008-10-22 2010-04-29 Endress + Hauser Process Solutions Ag Method for dynamic adaptation of a diagnostic system
DE102010044184B4 (en) * 2010-11-19 2018-05-09 Endress + Hauser Process Solutions Ag Method and communication unit for creating a diagnosis of a field device
DE102010044186A1 (en) * 2010-11-19 2012-05-24 Endress + Hauser Process Solutions Ag Method for providing a field device type-comprehensive diagnostic message
DE102013217324A1 (en) * 2013-08-30 2015-03-05 Siemens Aktiengesellschaft Method and system configuration for system diagnostics in a safety-related system

Family Cites Families (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH03134760A (en) 1989-10-20 1991-06-07 Nec Corp Performance adjuster for computer system
JP2804125B2 (en) 1989-11-08 1998-09-24 株式会社日立製作所 Fault monitoring device and control method for information processing system
JPH06214820A (en) 1992-11-24 1994-08-05 Xerox Corp Interactive diagnostic-data transmission system for remote diagnosis
EP1337905A4 (en) * 2000-11-15 2006-11-08 Dmo Inc Online diagnosing of computer hardware and software
DE10140519B4 (en) * 2001-08-17 2004-07-22 Daimlerchrysler Ag Communication method and communication module
DE10207222A1 (en) * 2002-02-21 2003-10-02 Daimler Chrysler Ag Method for recording a time-related data record assembled from sub-data records from multiple control devices, records the record in a system operating with a distributed configuration
DE10307342B4 (en) * 2003-02-21 2005-08-11 Volkswagen Ag Device and method for model-based on-board diagnostics

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See references of WO2007023106A2 *

Also Published As

Publication number Publication date
WO2007023106A3 (en) 2007-05-24
WO2007023106A2 (en) 2007-03-01
DE102005040822A1 (en) 2007-03-15

Similar Documents

Publication Publication Date Title
DE102009042368B4 (en) Control system for controlling safety-critical processes
DE10307342B4 (en) Device and method for model-based on-board diagnostics
DE10152235B4 (en) Method for detecting errors during data transmission within a CAN controller and a CAN controller for carrying out this method
WO2008040641A2 (en) Method and device for error management
EP2707999B1 (en) Signal processing system and method for processing signals in a bus node
EP3098673B1 (en) Method and device for automated validation of security features on a modular security system
DE19919504A1 (en) Engine controller, engine and method for controlling an engine
DE102011081640B4 (en) control system
EP3414632B1 (en) Method and device for monitoring data processing and transmission in a security chain of a security system
EP1672446B1 (en) Secure Input/Ouput assembly for a controller
EP1917595A2 (en) Method for diagnosing technical systems
EP3400452B1 (en) Transport unit having at least one installation
DE102005046373A1 (en) Communication system, e.g. for motor vehicle, has functional systems, in which one system is designed to detect malfunction and/or functional deficiency of other systems, and to take on parts of functionality of deficient systems
EP3470939B1 (en) Method and system for monitoring the security integrity of a security function provided by a security system
EP3470937B1 (en) Method and devices for monitoring the response time of a security function provided by a security system
EP2418580B1 (en) Method for operating a network and network
EP2239752A1 (en) Secure switching device and modular error-proof control system
WO2005001692A2 (en) Method and device for monitoring a distributed system
EP1997007B1 (en) Method and management system for configuring an information system
DE102008008449A1 (en) Electric press
EP1819551B1 (en) Method for the structured storage of error entries
EP0425897B1 (en) Method for operating a control system
DE102006004619A1 (en) Intelligent actuator topology
DE10137671A1 (en) Method and device for monitoring, in particular, a programmable logic controller
DE102012213228A1 (en) Method for operating vehicle, particularly spacecraft, involves storing models in vehicle computer, evaluating system response of vehicle when new event occurs, generating event value, and transferring parameters to external evaluator

Legal Events

Date Code Title Description
PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

17P Request for examination filed

Effective date: 20080121

AK Designated contracting states

Kind code of ref document: A2

Designated state(s): AT CH DE LI

17Q First examination report despatched

Effective date: 20080826

RBV Designated contracting states (corrected)

Designated state(s): AT CH DE LI

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE APPLICATION IS DEEMED TO BE WITHDRAWN

18D Application deemed to be withdrawn

Effective date: 20110301