EP1917595A2 - Procede pour realiser des diagnostics dans des systemes techniques - Google Patents

Procede pour realiser des diagnostics dans des systemes techniques

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)
English (en)
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/fr
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)
  • Computer Vision & Pattern Recognition (AREA)
  • Computer Hardware Design (AREA)
  • Mathematical Physics (AREA)
  • Testing And Monitoring For Control Systems (AREA)
  • Test And Diagnosis Of Digital Computers (AREA)

Abstract

La présente invention concerne un procédé pour réaliser des diagnostics dans des systèmes techniques comprenant plusieurs composantes système. Afin de réduire le volume de données diagnostiques à transmettre, un diagnostic système central, c.-à-d. un oracle diagnostique est utilisé, l'oracle diagnostique commandant le type et la taille des données diagnostiques à transmettre par les composantes système à l'oracle diagnostique, en fonction de données diagnostiques déjà transmises et de règles en mémoire dans l'oracle diagnostique.
EP06792815A 2005-08-24 2006-08-15 Procede pour realiser des diagnostics dans des systemes techniques Withdrawn EP1917595A2 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
DE200510040822 DE102005040822A1 (de) 2005-08-24 2005-08-24 Verfahren zur Systemdiagnose in technischen Systemen
PCT/EP2006/065309 WO2007023106A2 (fr) 2005-08-24 2006-08-15 Procede pour realiser des diagnostics dans des systemes techniques

Publications (1)

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

Family

ID=37671346

Family Applications (1)

Application Number Title Priority Date Filing Date
EP06792815A Withdrawn EP1917595A2 (fr) 2005-08-24 2006-08-15 Procede pour realiser des diagnostics dans des systemes techniques

Country Status (3)

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

Families Citing this family (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE102008043094A1 (de) 2008-10-22 2010-04-29 Endress + Hauser Process Solutions Ag Verfahren zur dynamischen Anpassung eines Diagnosesystems
DE102010044184B4 (de) * 2010-11-19 2018-05-09 Endress + Hauser Process Solutions Ag Verfahren und Kommunikationseinheit zum Erstellen einer Diagnose eines Feldgerätes
DE102010044186A1 (de) * 2010-11-19 2012-05-24 Endress + Hauser Process Solutions Ag Verfahren zum Bereitstellen einer Feldgerätetyp-übergreifenden Diagnosemeldung
DE102013217324A1 (de) * 2013-08-30 2015-03-05 Siemens Aktiengesellschaft Verfahren und Systemkonfiguration zur Systemdiagnose in einem sicherheitstechnischen System

Family Cites Families (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH03134760A (ja) * 1989-10-20 1991-06-07 Nec Corp コンピュータシステムの性能調整装置
JP2804125B2 (ja) * 1989-11-08 1998-09-24 株式会社日立製作所 情報処理システムの障害監視装置と制御方法
JPH06214820A (ja) * 1992-11-24 1994-08-05 Xerox Corp 遠隔診断のための会話形診断データ伝送システム
MXPA03004289A (es) * 2000-11-15 2004-09-10 Dmo Inc Diagnostico en linea de hardware y software de computadora.
DE10140519B4 (de) * 2001-08-17 2004-07-22 Daimlerchrysler Ag Kommunikationsverfahren und Kommunikationsmodul
DE10207222A1 (de) * 2002-02-21 2003-10-02 Daimler Chrysler Ag Verfahren und Vorrichtung zum Prozessdatenerfassen
DE10307342B4 (de) * 2003-02-21 2005-08-11 Volkswagen Ag Vorrichtung und Verfahren zur modellbasierten On-Board-Diagnose

Non-Patent Citations (1)

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

Also Published As

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

Similar Documents

Publication Publication Date Title
DE102009042368B4 (de) Steuerungssystem zum Steuern von sicherheitskritischen Prozessen
DE10307342B4 (de) Vorrichtung und Verfahren zur modellbasierten On-Board-Diagnose
DE10152235B4 (de) Verfahren zum Erkennen von Fehlern bei der Datenübertragung innerhalb eines CAN-Controllers und ein CAN-Controller zur Durchführung dieses Verfahrens
EP2078253A2 (fr) Procédé et dispositif de gestion des pannes
EP2707999B1 (fr) Système de traitement de signaux et procédé de traitement de signaux dans un n ud de bus
EP3098673B1 (fr) Procede et dispositif de validation automatique de fonctions de securite sur un systeme de securite construit de façon modulaire
DE19919504A1 (de) Triebwerksregler, Triebwerk und Verfahren zum Regeln eines Triebwerks
EP3414632B1 (fr) Procédé et dispositif pour contrôler un traitement et une transmission de données dans une chaîne de sécurité d'un système de sécurité
DE102011081640B4 (de) Steuersystem
EP1672446B1 (fr) Module d'entrée/sortie sécurisé pour un controleur
EP1917595A2 (fr) Procede pour realiser des diagnostics dans des systemes techniques
EP3400452B1 (fr) Unité de transport comprenant au moins une installation
DE102005046373A1 (de) Kommunikationssystem für ein technisches Gerät, insbesondere für ein Kraftfahrzeug
EP3470939B1 (fr) Procédé et système de surveillance de l'intégrité de sécurité d'une fonction de sécurité fournie par un système de sécurité
EP3470937B1 (fr) Procédé et dispositifs de surveillance du temps réactionnel d'une fonction de sécurité fournie par un système de sécurité
EP2418580B1 (fr) Procédé destiné au fonctionnement d'un réseau et réseau
EP2239752A1 (fr) Dispositif de couplage sécurisé et système de commande modulaire protégé contre les erreurs
EP1649373A2 (fr) Procede et dispositif pour la surveillance d'un systeme reparti
EP1997007B1 (fr) Procédé et système de gestion conçus pour configurer un système d'information
DE102008008449A1 (de) Elektrische Presse
EP1819551B1 (fr) Procédé de mise en mémoire structurée d'enregistrements de défaillances
EP0425897B1 (fr) Procédé de fonctionnement d'un dispositif de commande
DE102006004619A1 (de) Intelligente Stellgliedtopologie
DE102012213228A1 (de) Verfahren und Vorrichtung zum Betrieb eines Fahrzeugs
WO2013044963A1 (fr) Procédé de détermination de paramètres relatifs à des composants et dispositif associé

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