DE19614748C2 - Fehlerdiagnose-Verfahren - Google Patents

Description

Die Erfindung betrifft ein rechnergestütztes Verfahren zur Fehlerdiagnose und/oder -Analyse eines oder mehrerer technisch-physikalischer Prozesse, insbesondere elektrischer An­ triebsvorgänge, die unter der Steuerung, Regelung und/oder Überwachung durch einen oder mehrere, Prozeßrechnerknoten ablaufen, gemäß Oberbegriff des Anspruchs 1.

Aufgrund des inzwischen erreichten Entwicklungsstandes in der technischen In­ formatik sind schnelle Mikroprozessorsysteme in der Lage, das Management der Steuerungs- und Regelungstechnik sowie der Informationsübertragung zu über­ nehmen. Dieser bereits vorhandene Automatisierungsgrad bringt eine Komplexität der Produktionsanlagen und -stätten mit sich, die zur Wartung und Reparatur Spezialisten erfordert, denen als Werkzeuge entsprechend komplexe Fehler­ suchmittel zur Verfügung stehen müssen. Denn mit hochgradig automatisierten Produktionsanlagen werden inzwischen Bahngeschwindigkeiten von 10 Meter pro Sekunde erreicht, wobei mehr als tausend Informationsdaten innerhalb weniger Millisekunden anfallen und verarbeitet werden müssen. Dazu sind spezielle Meßeinrichtungen mit extrem hohen Auflösungen einzusetzen. Diese ist erforder­ lich, um bei den sehr hohen Geschwindigkeiten noch die geforderte Genauigkeit einzelner Antriebskomponenten zueinander (die Antriebe wirken beispielsweise auf das gleiche bahnartige Medium, ohne miteinander mechanisch verbunden zu sein) zu erreichen. Ebenso wichtig wie die dynamischen Signale sind die Informa­ tionen der Überwachungseinrichtungen, von denen es sehr viele an einer Produk­ tionsanlage geben kann. Sie haben die Aufgabe, Mensch und Maschine weitest­ gehend vor Gefahren zu schützen sowie gefährliche oder wartungsbedürftige Zu­ stände an Anlagen bzw. Anlagenteilen anzuzeigen und gegebenenfalls die Pro­ duktion zu unterbrechen.

Ein etwa gattungsgemäßes Diagnosekonzept ergibt sich aus Industrieanzeiger 34 (1989), Seiten 27, 28, 31, 32. Im dortigen Bild 1 ist die entsprechende Integration von Diagnoseaufgaben für die automatische Fertigung aufgezeigt, wobei ein Rechnerknoten zur Stördatenerfassung und Diagnose an einen speziellen Diagnosebus angeschaltet ist, an dem ferner weitere Rechnerknoten, beispielsweise für eine Lagersystem-, Roboter-, Transportsteuerung usw. parallel angeschaltet sind. Zu jeder Maschinensteuerung ist ein Diagnosebus installiert, der bei einer eingeschränkten Kommunikation mit der Steuerung die Online- Prozeß- und Maschinendatenerfassung erlaubt. Aufgrund dieser Daten können einerseits Maschinenstillstände dokumentiert, konstruktive Schwachstellen aufgezeigt und Instandsetzungshinweise verwaltet werden, um die Fehlerursachensuche für eine Wiederholungsstörung zu verkürzen. Zur Datenverwaltung wird ein Datenbanksystem vorgeschlagen, das um eine automatische Datenerfassung erweitert ist. Die Fehler und Statusmeldungen sind auf dem zentralen Diagnoserechner Grundlage für ein zweiteiliges Diagnoseprogramm. Einerseits können bei Bedarf zu sogenannten "bekannten Fehlern" Statistiken zur Störungsbeseitigung aufgerufen werden (Datenbankmanager). Andererseits kann über das Kontrollmodul des Diagnosemanagers die entsprechende Wissensbasis einer Expertensystemshell geladen werden, um mit Hilfe des hier abgelegten anlagen- und problemspezifischen Wissens die Störungsursache zu finden.

Aus der DE-Zeitschrift "Engineering & Automation", Jahrgang 17 (1995), Heft 5, Seiten 12 und 13 gehen hierarchische Rechnerorganisationen hervor, wie sie in der Steuerungstechnik üblich sind.

Aus der DE-Zeitschrift "atp - Automatisierungtechnische Praxis", Jahrgang 36 (1994), Seiten 16-18, 20-26, 29-31, 34 und 35 ist ein Echtzeitrechner entnehmbar, der sowohl mit Steuergeräten einer Feldebene als auch mit Leitrechnern verbunden ist. Zur Kommunikation mit den Leitrechnern ist ein Prozeßbus, zur Kommunikation mit der Feldebene ein Feldbus vorgesehen. Beide Busse laufen am Echtzeitrechner sternartig zusammen.

Aus DE 42 21 841 A1 ist ein zentralisiertes Überwachungs-/Kontrollsystem für die zentrale Überwachung mehrerer überwachter Geräte bekannt. Sie weist insbesondere eine Abweichungsdatenerzeugungseinrichtung auf, um dann, wenn die Beurteilungseinrichtung denselben Datenblock feststellt, die vorher gespeicherten Statusdaten mit den neu empfangenen Statusdaten in demselben Block zu vergleichen. Dadurch soll ermittelt werden, ob die neu empfangenen Statusdaten irgendeine Abweichung aufweisen, und um dann, wenn eine derartige Abweichung existiert, Abweichungsdaten zu erzeugen, die aus dem Inhalt der Abweichung und einer Tageszeitanzeige bestehen, die der Abweichung zugeordnet werden kann.

In der DE-Zeitschrift "industrieelektrik + elektronik" Jahrgang 32 (1987), Nummer 8, Seiten 16 und 17, ist eine automatische Diagnose beschrieben. Dabei wird im Fehlerfall ein aktueller Schritt auf fehlende Weiterschaltbedingungen untersucht. Diese werden auch angezeigt. Bei Programmänderungen erfolgt dazu die automatische Anpassung. Als Zusatznutzen ergibt sich die Unterstützung bei der Inbetriebnahme durch Statusanzeige aller Eingänge, Ausgänge, Merker, Zeiten, Zähler und programmierten Datenbausteininhalte. Die Erfassung, Auswertung und Darstellung von Produktionsabläufen und Betriebsdaten bekommt man in tabellarischer oder graphischer Form. Es gibt auch Bedienungs- und Führungshinweise beim Anfahren und Betrieb der Maschine.

Der Erfindung liegt die Aufgabe zugrunde, bei einem eingangs genannten Fehlerdiagnoseverfahren die Konfigurationsflexibilität zu erhöhen, wenn Baugruppenwechsel in der Rechner-, Regelungs- oder Steuerungsanlage notwendig sind. Zur Lösung wird das in Patentanspruch 1 gekennzeichnete Verfahren vorgeschlagen. Weitere vorteilhafte Ausgestaltungen ergeben sich aus den Unteransprüchen und der nachfolgenden Beschreibung sowie den Zeichnungen.

Bei mikroprozessorgesteuerten Systemen ist es anzustreben, wesentliche inter­ nationale Vorschriften und Richtlinien einzuhalten. Dies trifft insbesondere auf die Kommunikation unterschiedlicher autonomer Systeme zu. Darin sind entspre­ chende Nachrichten, Übermittlungsprotokolle und Feldbussysteme integriert. Im Antriebsbereich sind schnelle Feldbussysteme mit Bus-Topologien leistungsfähi­ ger Rechnernetze zu verbinden. Insbesondere mit an sich bekannter Direktan­ triebstechnik hat sich ein hochdynamisches Antriebskonzept durchgesetzt. Dazu ist die Ankopplung des erfindungsgemäßen Diagnoserechners ohne weiteres möglich. Mit diesem können relevante analoge und digitale Daten auch direkt aus dem technischen Prozeß beispielsweise über Analog-Digitalwandler selbstständig aufgezeichnet werden. Es können Strategien und Algorithmen implementiert sein, die ein sicheres Erkennen von Störungen gewährleisten. Die Prozeßrechnerkno­ ten sind aufgrund der Bus-Kompatibilität vom Diagnoserechnerknoten ansprech­ bar. Bei notwendigem Baugruppenwechsel in einem Prozeßrechnerknoten lassen sich die aktuellen Softwareparameter mittels Download auch dem Diagnoserech­ ner eingeben. Mittels grafischer Bedienoberfläche ist eine einfache Bedienung des Diagnoserechners gewährleistet. Darin können Userbereiche mit Passwort­ schutz konfigurierbar sein.

Im Rahmen der Erfindung ist ein Nachrichterservermodul vorgesehen, das über auf den Diagnose- und Prozeßrechnerknoten implementierte Nachrichtenproto­ kolltreiber Prozeßdaten aus dem Prozeßrechnerknoten wiederholt ausliest. Ferner ist ein Datenbankmodul vorgesehen das die vom Nachrichtenserver­ modul erhaltenen Daten für den späteren Zugriff durch das Nachrichtenservermo­ dul speichert und/oder archiviert, wobei das Bedienmodul mit dem Nachrichten­ servermodul und dem Datenbankmodul zumindest teilweise unter der Kontrolle des Betriebssystems im Diagnoserechnerknoten kommuniziert. Mit dem Zusam­ menspiel des Nachrichtenservermoduls und des Datenbankmoduls ist eine Mög­ lichkeit geschaffen, prozeßrelevante Daten insbesondere in Echtzeit mitzuproto­ kollieren. Daraus läßt sich im Nachhinein die Ursache für etwaige Störungen und Ausfälle und Schadensfälle objektiv ermitteln. Aufgrund der Nachrichtenproto­ kolltreiber auf Diagnose- und Prozeßrechnerknoten, die gegebenenfalls durch Echtzeit-Datenkanäle ergänzt sein können, ergibt sich für das Nachrichtenserver­ modul ein ständiges Überwachungsauge in jedem Prozeßrechnerknoten.

Um die Steuerung und Administration für die Archivierung von Prozeßdaten in dem Datenbankmodul zu gewährleisten, ist erfindungsgemäß ein mit dem Datenbankmodul und/oder dem Nachrichtenservermodul zusammenwirkendes Parametriermodul vorgesehen, das zur Identifikation und/oder Interpretation der vom Nachrichtenservermodul aus den Prozeßrechnerknoten gelesenen Prozeßda­ ten und/oder zur Steuerung von deren Ablage und/oder Verwaltung und/oder Ausgabe im/aus dem Datenbankmodul ausgelegt ist. Dieses Parametriermodul kann gleichsam das Steuerwerk für die Datenbank und/oder auch für den Nach­ richtenserver bilden. Vorzugsweise ist es ausschließlich über das Betriebssystem konfigurierbar, so daß Kundenbenutzer nicht darauf ohne weiteres zugreifen kön­ nen. Gleichzeitig ergibt sich eine übersichtliche Aufteilung der anfallenden Infor­ mationen derart, daß im Datenbankmodul ausschließlich Prozeßdaten und im Parametriermodul ausschließlich Steuerparameter für die Behandlung der Prozeßda­ ten abgelegt sind. Mit dem Parametriermodul lassen sich insbesondere das Nachrichtenservermodul, das Datenbankmodul und/oder die Prozeßrechnerkno­ ten für verschiedenste Zwecke konfigurieren und nutzen. Selbst die Art und Weise der Meldung von Ausfällen, Störungen oder Änderungen im technischen Prozeß läßt sich über den Parametriermodul einstellen (Meldungsparametrierung).

Grundsätzlich ist es ausreichend, wenn Nachrichtenservermodul und Datenbank­ modul direkt miteinander kommunizieren, und das Parametriermodul direkt nur auf das Datenbankmodul einwirkt. Alternativ ist es denkbar, daß der Nachrichten­ server auch direkt Steuersignale und Informationen vom Parametriermodul emp­ fängt. Nach einer weiteren Alternative ist das Datenbankmodul lediglich mit dem Parametriermodul verbunden, das seinerseits dann auch direkt mit dem Nachrich­ tenserver kommuniziert.

Damit bei technischen Prozessen mit hoher Dynamik, insbesondere bei hochdy­ namischen Antriebsvorgängen, die Diagnose von Fehlern und die Ursachenermitt­ lung korrekt erfolgen kann, ist es von Vorteil, wenn das Betriebssystem für Multi­ tasking ablaufen kann (beispielsweise durch Verwendung von WINDOWS NT). Für Anwendungen des Diagnosesystems, bei denen keine Direktantriebstechnik zu diagnostizieren ist, kann gleichwertig das Betriebssystem WINDOWS 3.1 ohne Multitasking eingesetzt werden.

Damit über das Nachrichtenservermodul in Verbindung mit dem Datenbank- und Parametriermodul Störungen erkannt werden, ist es zweckmäßig, mit diesen Mo­ dulen gekoppelte Tabellen zum Vergleich von alten und neuen Prozeßdaten glei­ chen Typs anzulegen. Wird eine Störung erkannt, kann vom Parametriermodul aus die Zuweisung eines Echtzeit-Datenkanals (Real-Time Pipe) an den von der Störung betroffenen Prozeßrechnerknoten erfolgen. Über das Nachrichtenserver­ modul läßt sich dann das Auslesen dieses Echtzeit-Datenkanals anstoßen, und die ausgelesenen Prozeßdaten werden in der Datenbank für die spätere Auswer­ tung und Ursachenermittlung abgespeichert.

Der Realisierung der Echtzeit-Datenkanäle können an sich bekannte Pufferspei­ cher oder Warteschlangen dienen, die im Diagnose- und/oder Prozeßrechner­ knoten physikalisch abgelegt sind.

Auf der Basis der Erfindung ist es möglich daß das Nachrichtenservermodul wie­ derholt von dem Prozeßrechnerknoten Kennwerte und sonstige Daten, welche die technisch-physikallischen Prozesse und/oder Verarbeitungsprozesse charakteri­ sieren, anfordert und einliest und diese neuen Prozeßdaten mit dem auf voraus­ gegangene Prozeßdaten gleichen Typs basierenden Prozeßabbild aus dem Da­ tenbankmodul vergleicht, und im Falle von Änderungen und/oder Störungen ein aktualisiertes Prozeßabbild generiert und in das Datenbankmodul eingetragen wird, sowie ein Anzeigeprogramm in Verbindung insbesondere mit dem Bedien­ modul und/oder einem bedienerorientierten Prozeßrechnerknoten, beispielsweise Leitstandsrechner, parametrisiert wird. Jede Änderung, jedenfalls wenn sie nicht vorab spezifiziert ist, löst also eine Aufzeichnung von Daten entsprechend den Prozeß- bzw. Verarbeitungsprozeßsignalen in die Datenbank aus. Die Änderung oder auch Störung wird durch ständigen, vorzugsweise zyklischen Alt- /Neuvergleich gleichartiger Prozeßdaten erkannt, die zu unterschiedlichen Zeit­ punkten vom Nachrichtenserver angefordert wurden. Bei diesem Konzept wird der Vorteil erzielt, daß die Speicherkapazität des Diagnose-Systems nur dann außer­ ordentlich belastet wird, wenn ungewollte Änderungen oder Störungen, die nicht dem spezifizierten Normalverlauf des Prozesses entsprechen, auftreteten. Alle nacheinander anfallenden Prozeßdaten brauchen jedenfalls nicht abgespeichert zu werden; eine die Historie bildende Serie von Prozeßdaten wird nur dann ge­ speichert beibehalten, wenn sie zur Ermittlung der Ursache von Störungen benö­ tigt wird, die bei oder unmittelbar nach dieser Serie aufgetreten sind.

Aufgrund der hohen Anforderungen an die Schnelligkeit der Datenübetragung ist es zweckmäßig, die Prozeßdaten zwischenzuspeichern, sei es in einer Pipe, Warteschlange, Tabelle oder dergleichen. Vor allem ein Tabellenmodul eignet sich dazu, den genannten Alt-/Neuvergleich zwischen frisch angeforderten und älteren, in der Datenbank archivierten Prozeßdaten durchzuführen.

Nach einer besonderen Ausbildung des erfindungsgemäßen Verfahrens wird das Pa­ rametriermodul des Diagnose-Systems dazu verwendet, die Bus-Adressen, Typ, Identifikationsangaben, interne Bezeichnungen, Überwachungsflag und derglei­ chen jeweils spezifisch für die Prozeßrechnerknoten bereitzuhalten für den Zugriff durch das Datenbank- und/oder Nachrichtenservermodul. Insbesondere kann das Parametriermodul dazu verwendet werden, dem Datenbank- und/oder Nachrich­ tenservermodul die Angaben zu machen bzw. die Parameterwerte zu liefern, die für die Änderungs- und/oder Störungserkennung der neu eingelesenen Prozeß­ daten mit den historischen Prozeßdaten notwendig sind. Dies kann beispielsweise über Zeiger- oder indirekte Adressierung erfolgen: Wird beispielsweise aus einem Prozeßrechnerknoten, der direkten Zugriff auf die Drehzahl eines Elektroantriebs hat, ein Prozeßdatum für die aktuelle Drehzahl angefordert, können vom Nach­ richtenservermodul gleichzeitig über Zeiger-Adressierung oder relative Adressie­ rung indirekt auf Informationen bzw. Parameterwerte für zulässige Grenzwerte der Drehzahlhysterese zugegriffen werden. Von diesen Parameterwerten kann das Datenbankmodul und/oder der Parametriermodul selbst dann entlastet sein, was deren Speicherkapazität förderlich ist.

Der nachträglichen, objektiven Erforschung von Ursachen für aufgetretene Stö­ rungen dient es, wenn nach einer Ausbildung des erfindungsgemäßen Verfahrens unter Verwendung eines Diagnose-Systems mit Echtzeit-Datenkanälen bei Er­ kennung von Änderungen oder Störungen durch das Nachrichtenserver- und/oder Parametriermodul dem oder den betroffenen Prozeßrechnerknoten je ein Echtzeit- Datenkanal zugewiesen wird, der in das Datenbankmodul für die spätere, nach­ trägliche Auswertung einmündet. Dabei ist es von Vorteil, wenn in einem solchen Störungsfall der Echtzeit-Datenkanal Priorität gegenüber sonstigen Datenübertra­ gungsprozessen auf der Basis von Warteschlangen oder Pufferspeichern besitzt.

Die Prozeßrechnerknoten sind über wenig­ stens einem gemeinsamen Bus die Prozeßrechnerknoten mit wenigstens einem Diagnoserechnerknoten verbunden, in dem eine oder mehrere Diagnose­ dienste und/oder Funktionen implementiert sind, die dem oder den Prozessen und/oder dem oder den Prozeßrechnerknoten und/oder den darin ablaufenden Verarbeitungsprozessen zugeordnet sind. Die Prozeßrechnerknoten sind, wenn sie parallel und/oder gleichzeitig ablaufende technische Prozesse zu begleiten und/oder zu kontrollieren haben, in der Regel mit einem gemeinsamen Bus- System verbunden. An diesen läßt sich leicht noch ein zusätzlicher Rechnerkno­ ten ankoppeln, der dann die Diagnosedienste und/oder -funktionen vollziehen kann. Beispielsweise können dann die Prozeßrechnerknoten bei Bedarf Diagno­ sedienste vom Diagnoserechner in Anspruch nehmen. Da bei der digitalen rech­ nergestützten Begleitung und Kontrolle technischer Prozesse die Verarbeitung der Daten für die Steuerung, Regelung und Visualisierung weitestgehenst digital er­ folgt, können diese ohnehin vorhandenen digitalen Prozeßdaten mit der Erfindung effizient zur Analyse und Fehlerdiagnose ausgenutzt werden. In dem Diagnose­ rechner können, ähnlich eines "Werkzeugkoffers", die Module zumindest teilweise enthalten sein, die das Analysieren der Zustände der Produktionsanlagen, ange­ paßt an den jeweiligen Automatisierungsgrad, ermöglichen. Ferner ist mit der An­ schaltung des Diagnoserechners als in sich autarkes System nur eine minimale Belastung der bereits arbeitenden Rechnerarchitekturen vor allem hinsichtlich Ih­ res Arbeitsspeichers verbunden. Zweckmäßig können die Diagnosedienste und - funktionen auch auf Diagnoserechner- und Prozeßrechnerknoten verteilt ablaufen, so daß sich die volle Rechenleistung aller angeschlossenen Rechnerknoten nut­ zen läßt.

Weitere Einzelheiten, Merkmale und Vorteile auf der Basis der Erfindung ergeben sich aus der nachfolgenden Beschreibung bevorzugter Ausführungen der Erfin­ dung sowie anhand der Zeichnungen. Diese zeigen in:

Fig. 1 in schematisch-grafischer Darstellung die Grobstruktur einer frei konfigurierbaren Diagnoseanordnung nach der Erfindung,

Fig. 2 in schematischer Darstellung ein Software-Strukturbild für das frei konfigurierbare Diagnosesystem nach der Erfindung, und

Fig. 3 ein vereinfachtes Flußdiagramm des Diagnoseverfahrens nach der Erfindung.

Gemäß Fig. 1 sind an einem ersten Bus 1 zwei gegebenenfalls zueinander redun­ dante Leitstand-Prozeßrechner 2a, 2b, zwei gegebenenfalls auch zueinander red- undante Steuerprozeßrechner 3a, 3b sowie eine Mehrzahl Feldprozeßrechner 4a, 4b, 4c, 4d, 4e parallel angeschaltet. Die Steuerprozeßrechner 3a, 3b sind vor­ zugsweise frei programmierbar ausgelegt. Die Feldprozeßrechner 4a-4e zeich­ nen sich durch direkte Zugriffsmöglichkeiten auf technisch-physikalisch Prozesse aus beispielsweise auf die Antriebsvorgänge von Elektromotoren 5 mit vorge­ schalteten Umrichtergeräten 6. Die Feldprozeßrechner 4a-4e sind den Steuer­ prozeßrechnern 3a, 3b, welche die globalen Steuerungs- und Regelstrategien liefern, sowie den Leitstand-Prozeßrechnern 2a, 2b hierarchisch untergeordnet. Ein Diagnoserechner 7 ist über einen zweiten Bus 8 unmittelbar mit den Leitstand- Prozeßrechnern 2a, 2b verbunden. Über diese kann der Diagnoserechner 7 mit­ telbar auch mit den Steuerprozeßrechnern 3a, 3b kommunizieren. Alternativ ist es denkbar, daß der Diagnoserechner über ein an sich bekanntes Dual-Port-RAM mit dem oder den Steuerprozeßrechnern 3a, 3b kommuniziert. Zweckmäßig arbeitet der zweite Bus 8, an dem die Leitstand-Prozeßrechner 2a, 2b und der Diagnose­ rechner 7 parallel angeschaltet sind, nach dem an sich bekannten Standardproto­ koll TCP/IP (Transport Control Protocol/Interface Program). Zu dem zweiten Bus 8 sternartig angeordnet ist noch ein dritter Bus 9, der beispielsweise als serieller Feldbus nach dem Standard RS 485 ausgeführt sein kann. Daran parallel ange­ schaltet sind die Feldprozeßrechner 4a-4e. Über den zweiten und dritten Bus 8, 9, die in dem Diagnoserechner 7 sternartig zusammenlaufen, ist dieser den son­ stigen Prozeßrechnern 2a-4e in einem Hierarchieverhältnis nach dem Ma­ ster/Slave-Prinzip übergeordnet. Ferner ist der Diagnoserechner 7 mit einem ISDN (Intergrated Service Digital Network)-Anschluß 10 versehen, wodurch die Möglichkeit einer Ferndiagnose gegeben ist.

Grundsätzlich ist das frei konfigurierbare Diagnosesystem gemäß Fig. 2 zur Erfül­ lung folgender Anforderungen ausgelegt:

• - selbstständiges Aufzeichnen relevanter, digitaler Prozeßdaten sowie auch analoger Meßwerte über Analog-Digitalwandler unmittelbar von den technischen Prozessen
• - sicheres Erkennen von Störungen nicht nur in den technischen Prozessen, sondern auch in den Verarbeitungsprozessen der zugeordneten Prozeßrechnerknoten
• - Abholung aller relevanten Prozeßdaten der angeschlossenen Prozeßrechnerknoten über den oben angesprochenen Echtzeit- Datenkanal, wenn Anlagenstörungen vorliegen
• - Ansprechbarkeit aller Prozeßrechnerknoten innerhalb der Systemanordnung (Fig. 1) insbesondere über das Master/Slave- Verhältnis zwischen Diagnoserechner und Prozeßrechnerknoten
• - bei notwendigem Baugruppenwechsel im System Übergabe der aktuellen Softwareparameter mittels Download
• - Anbindung des Diagnosesystems gemäß Fig. 2 an das öffentliche Telefonnetz beispielsweise mittels Modem oder dem ISDN-Anschluß 10 gemäß Fig. 1
• - einfache Bedienung des Diagnosesystems mittels grafischer Bedieneroberfläche
• - Konfigurierbarkeit von User-Bereichen mit Passwordschutz
• - konfigurierbare Client/Server-Struktur
• - Bereitstellung konfigurierbarer Datenlisten.

Zur Erfüllung dieses Anforderungsprofils dienen die in Fig. 2 gezeigten Software­ module, dargestellt in einer vereinfachten Übersicht. Dabei gliedern sich die we­ sentlichen Module in das Betriebssystem 11 mit modular aufgebauten Proto­ kolltreibern 12, dem Message bzw. Nachrichten-Server 13, dem Bedienmodul 14 und der relationalen Datenbank 15. Der mit dem seriellen Bus 9 verbundene Pro­ tokolltreiber 12a stellt eine universelle serielle Schnittstelle (USS) dar, wie es Standard ist. Der weitere Protokolltreiber 12b, der einem Fernservice bzw. einer Ferndiagnose 16 dient, ist ein Submodul des Betriebssystems "WINDOWS NT 3.51", bekannt unter der Bezeichnung "RAS" (Remote Access Service). Der dritte Protokolltreiber 12c, der der Nachrichtenübermittlung mit dem Fremdsystem 17 über dem zweiten BUS 8 (vgl. Fig. 1) dient, ist bereits oben anhand von Fig. 1 er­ läutert. Der zweite Protokolltreiber 12b (RAS) arbeitet, wie an sich bekannt, mit einem Modem. Als Netzwerk-Verknüpfung oder -erstreckung für das Diagnosesy­ stem 18 zum Fremdsystem 17 (beispielsweise die Prozeßrechner 2a-4e gemäß Fig. 1) kann das an sich bekannte Ethernet dienen. Als Kommunikationsverbin­ dung 19 zwischen dem Betriebssystem 11 und dem Nachrichtenserver 13 wird zweckmäßig eine an sich bekannte Laufzeitbibliothek (DLL - Dynamic Library Link) verwendet. Als Kommunikationsverbindung 20 zwischen dem Nachrichten­ server 13 und dem Bedienmodul 14 dient eine dynamische Programmkommuni­ kation zwischen Anwendungen (DDE - Dynamic Date Exchange). Dem Informati­ onsaustausch zwischen der Datenbank 15 einerseits und dem Nachrichtenserver 13 bzw. Bedienmodul 14 andererseits dienen je eine Kommunikationsverbindung 21 bzw. 22, die mit einer Datenmanipulationssprache für das Wiederauffinden und für den Änderungsdienst einer relationalen Datenbank (SQL) arbeiten. Mit beson­ derem Vorteil ist noch ein Parametrierungsmodul 23 vorgesehen, das mit der Da­ tenbank 15 in einer Kommunikationsverbindung 24 steht, die ebenfalls nach SQL arbeitet. Alternativ oder zusätzlich kann das Parametriermodul 23 über eine (gestrichelt angedeutete) Kommunikationsverbindung 25 direkt an den Nachrich­ tenserver 13 angekoppelt sein.

Zur Funktionsweise des Diagnose-Systems 18 in Fig. 2 wird folgendes ausgeführt:

Durch den Nachrichtenserver 13 ergibt sich die Verbindung zwischen den Prozeß­ rechnerknoten 2a-4e (Fig. 1) bzw. den zugehörigen technischphysikalischen Prozessen einerseits und dem Prozeß-Abbild bzw. der Datenbank 15 sowie des Bedienmoduls 14 andererseits. Über den USS-Protokolltreiber 12a wird nach dem Master/Slaveprinzip gearbeitet, wobei das Diagnosesystem 18 den Master, und die Prozeßrechnerknoten 2a-4e die Slaves darstellen. Das Diagnosesystem 18 bzw. der entsprechende Diagnoserechner 7 (Fig. 1) stellt zyklisch Anforderungen an die Prozeßrechnerknoten 2a-4e und wartet auf die entsprechende Antwort. Insbesondere entsprechend der Vorgabe des Parametriermoduls 23 werden Pro­ zeßwerte repräsentierende Prozeßdaten zyklisch von den Prozeßrechnerknoten 2a-4e abgefragt. Ergeben sich durch Alt-/Neuvergleich (vgl. Fig. 3) Änderungen, werden diese im Hauptspeicher-Prozeßabbild aktualisiert. Sind aufgrund des - kundenspezifisch - programmierten Parametriermoduls 23 weitere Überprüfungen oder Aktionen notwendig, werden diese veranlaßt, insbesondere Schreiben in die Datenbank 15. Bei einer derartigen Weiterverarbeitung der Prozeßdaten ist si­ cherzustellen, daß der Nachrichtenserver 13 in seiner zyklischen Verarbeitung nicht behindert wird. Deshalb sind, falls notwendig, weitere Prozesse über Warte­ schlangen-Funktionen zu aktivieren, um die Verarbeitung vom Telegramm/Daten- Verkehr zeitlich zu entkoppeln. Wird eine Änderung als Störung erkannt, dann kann dieser Störung insbesondere aufgrund des Parametriermoduls 23 ein Echt­ zeit-Datenkanal zugeordnet sein. Dessen Auslesen wird angestoßen, und die zur Störung gehörigen Prozeßdaten in dem Datenbank für die spätere Auswertung der Historie abgespeichert.

Das Bedienmodul 14 umfaßt folgende Funktionen:

• - Grafische Darstellung von Prozeßwerten, insbesondere deren zeit­ licher Verlauf, wobei zwischen Echtzeit oder historischer Darstellung der in der Datenbank 15 archivierten Prozeßdaten gewählt werden kann
• - Logbuchfunktionen über die erfaßten Störungen ("Störmeldelogbuch" über die Historie)
• - Sichern/Laden von Parametersätzen im Download-Verfahren insbe­ sondere in das Parameteriermodul 23 und/oder in die über den seriellen Bus 9 angekoppelten Prozeßrechnerknoten 2a-4e
• - Bearbeiten von in der Datenbank 15 archivierten Parametersätzen
• - Online-Änderungen einzelner Parameter der angeschlossenen Prozeßrechnerknoten 2a-4e
• - Auswerte- und Analysefunktionen insbesondere im Zusammenhang mit dem oben genannten "Störmeldelogbuch"
• - Bereitstellen von Daten für Systeme außerhalb des frei konfigurier­ baren Diagnosesystems 18 beispielsweise durch Modem- und/oder ISDN-Anschluß
• - Ein-/Ausschalten der Erfassung/Archivierung in der Datenbank 15

Alle diese Funktionen und Dienste können entweder direkt vor Ort am Diagnose­ rechner 7 oder über Remote Access Service (Modem) zur Ferndiagnose betätigt werden.

Im Parametriermodul werden für jeden angeschlossenen Prozeßrechnerknoten 2a -4e folgende Angaben hinterlegt:

• - Adresse im maschinen- bzw. prozeßnahen RS 485-Feldbus
• - Typ des Knotens bzw. der Komponente (z. B. firmenspezifisch, Steuerungssystem, digitaler Signalprozessor usw.)
• - Bezeichnung zum Einsatz als Variable
• - Ein-/Ausschalten oder Ein-/Ausblenden der Überwachung des betreffenden Prozeßrechnerknotens

Für die Parameter und Werte der einzelnen Prozeßrechnerknoten werden folgen­ de Angaben benötigt:

• - Parameternummer, welche die Adressierung des Parameters inner­ halb eines Prozeßrechnerknotens beschreibt;
• - Parametergruppe, in der verschiedene Parameter vor allem unter­ schiedlicher Prozeßrechnerknoten (z. B. digitaler Signalprozessor und Umrichter) komponentenübergreifend zu logischen Gruppen zusammengefaßt werden
• - Beschreibung des Parameters durch Hinterlegung eines beschrei­ benden Klartextes
• - Parameter-Format, wobei folgende Darstellungsformate unterschie­ den werden:
• - Wort: ganzzahliger Wert 16 Bit-Integer
• - Doppelwort: ganzzahliger Wert 32 Bit-Integer
• - Gleitkomma: 32 Bit-Gleitkommawert nach IEEE
• - Parameter-Typ zur Angabe, wie der Inhalt eines Parameters zu in­ terpretieren ist (prinzipiell wird unterschieden zwischen Status- /Steuerworten (Bitfelder), die bestimmte Zustände bzw. Zustands­ vorgaben widerspiegeln, und Wertanzeigen bzw. Wertangaben; Beispiele für Statusworte sind Zustände wie "ein/aus", "frei/gesperrt", für Wertanzeigen "Drehzahl-Istwert", "Regeldifferenz")
• - Angaben für Grenzwerte, wobei obere und untere Grenzwerte direkt oder indirekt angegeben sein können (bei der direkten Angabe wer­ den hier die Werte festgelegt; indirekte Grenzwerte verweisen auf Parameter in einer beliebigen, angeschlossenen Prozeßrechner­ komponente)
• - Überwachung (Erfassung) einzelner Parameter kann ein- oder aus geschaltet werden
• - Die Grenzwertüberwachung für einzelne Parameter kann ein- oder ausgeschaltet werden
• - Parametrierung der Meldung, die beschreibt, wie bestimmte Ereig­ nisse an übergeordnete Systeme weiterzumelden sind, z. B. Grenz­ wertverletzungen, Auftreten von bestimmten Zuständen oder Störungen
• - Echtzeit-Datenkanal (Real-Time-Pipe - RTP), der für zeitkritische Werte in einem angeschlossenen Prozeßrechnerknoten (z. B. digita­ ler Signalprozessor) geführt wird, wobei in einer Art Ringpuffer die Werte in Echtzeit mitprotokolliert, sozusagen "mitgefilmt" werden (tritt eine Störung auf und ist dieser Störung eine RTP zugeordnet, wird diese RTP vom frei konfigurierbaren Diagnosesystem 18 ausgele­ sen, so daß der zeitliche Verlauf dieses Wertes vor Auftreten der Störung insbesondere für die objektive Ursachenermittlung auswert­ bar ist)

Gemäß Fig. 2 ist im Zusammenhang vor allem mit dem Bedienmodul 14 ein Onli­ ne-Anbindungsmodul 26 implementiert. Zusätzlich kann dieses auch mit anderen Software-Modulen in Verbindung treten (gestrichelt angedeutet). Das Online- Anbindungsmodul 26 ermöglicht beispielsweise in Verbindung mit dem Bedien­ modul 14 das Ansprechen aller Daten und/oder Parameter der Prozeßrechnerkno­ ten 2a-4e in Echtzeit (während des laufenden Prozesses). Dies könnte direkt vom Diagnoserechner 7 oder über Modemanbindung erfolgen. Damit ist die Mög­ lichkeit einer Optimierung von Daten und Parametern geschaffen (z. B. Anpassung der Reglerparameter an Verschleiß von Maschinenelementen im technisch­ physikalischen Prozeß). Ein Spezialist braucht bei Modemanbindung oder Einsatz sonstiger Mittel zur Datenfernübertragung nicht vor Ort zu sein. Zudem können die (wichtigen) Unterprogramme beispielsweise des Bedienmoduls 14 über das Onli­ ne-Anbindungsmodul 26 auf Ferndiagnose umgeschaltet werden.

Zur Ferndiagnose und Anbindung an Netztopologien können vom Betriebssystem 11 folgende Funktionen zur Verfügung gestellt werden:

• - Remote Access Service (RAS - Ferndiagnose über Modem)
• - Netzwerk-Anbindung (lokale Netze, Fremdsysteme 17) über TCP/IP und Ethernet (Novell)

Das Nachrichtenservermodul 13 stellt die Echtzeit-Kommunikation zwischen den technischen Prozessen und den darauf in Echtzeit zugreifenden Prozeßrechner­ knoten 2a-4e sowie den sonstigen Prozeßrechnerknoten 2a, 2b, 3a, 3b und dem Bedienmodul 14 her. Diese Funktion ist vorzugsweise in der Programmiersprache C/C++, um eine schnelle Bearbeitungsgeschwindigkeit zu erreichen. Gemäß Fig. 3 wird durch das Programm-Teilmodul 27 über das USS-Protokoll bzw. den entsprechenden Protokolltreiber 12a das Prozeßdatum bzw. die Prozeßdaten von den unterlagerten Systemen mit technischen Prozessen und Prozeßrechnerkno­ ten 2a-4e angefordert und in beispielsweise einer internen Tabelle gespeichert. Die Speicherung erfolgt aufgrund einer Interpretation des eingelesenen Prozeßda­ tums gemäß Teilmodul 28 insbesondere in Kombination mit dem Parametriermo­ dul 23. Daraufhin erfolgt gemäß Verzweigungsmodul 29 eine Abfrage, ob zwi­ schen der letzten Speicherung von Prozeßdaten und den aktuellen Prozeßdaten eine Änderung festzustellen ist. Wenn ja, wird über den Zweig 30 in das Teilmodul 31 verzweigt, mit dem eine Aktualisierung des vom Nachrichtenserver 13 generier­ ten Prozeßabbilds erfolgt. Sodann wird gemäß Teilmodul 32 das aktualisierte Pro­ zeßabbild in der Datenbank 15 archiviert. Zur Vermeidung von Datenverlust kann das Abspeichern in die Datenbank 15 über ein oder mehrere Warteschlangen oder sonstige Zwischenpuffer erfolgen. Zweckmäßig wirkt auf dem Datenbankein­ trag das Parametriermodul 23 steuernd und/oder administrativ ein. Nachfolgend kann gemäß Teilmodul 33 optional noch eine Ausgabe an den Bediener oder Be­ nutzer erfolgen, sei es über den Diagnoserechner 7 oder über einen der Leitstand- Prozeßrechnerknoten 2a, 2b. Sodann kann die in Fig. 3 dargestellte Programm­ schleife von vorne beginnen. Wird beim Alt-/Neu-Vergleich gemäß Verzwei­ gungsmodul 29 keine Änderung festgestellt, wird über den zweiten Programm­ zweig 34 ebenfalls an den Anfang der Programmschleife zurückgekehrt.

Claims (8)

1. Verfahren zur Fehler-Diagnose und/oder -Analyse eines oder mehrerer technisch-physikalischer Prozesse (5, 6), insbesondere elektrischer An­ triebsvorgänge, die unter der Steuerung, Regelung und/oder Überwachung durch einen oder mehrere Prozeßrechnerknoten (2a-4e) ablaufen, unter Verwendung eines Fehlerdiagnose-Programmsystems (18), bei dem wenig­ stens ein Diagnoserechnerknoten (7) mit dem einen oder mehreren Prozeß­ rechnerknoten (2a-4e) kommuniziert, und mittels eines Bedien- Softwaremoduls (14) Daten, Befehle und/oder Parameter ein- und/oder ausgegeben werden, unter Verwendung eines Nachrichtenserver- Softwaremoduls (13), das Prozeßdaten aus den Prozeßrechnerknoten (2a- 4e) wiederholt anfordert und einliest (27, 28), und unter Verwendung eines Datenbankmoduls (15), das die vom Nachrichtenserver-Softwaremodul (13) erhaltenen Daten für den späteren Zugriff durch das Nachrichtenserver- Softwaremodul (13) speichert und/oder archiviert, wobei das Bedien- Softwaremodul (14) mit dem Nachrichtenserver-Softwaremodul (13) und dem Datenbankmodul (15) zumindest teilweise unter der Kontrolle eines Betriebssystems (11) im Diagnoserechnerknoten (7) kommuniziert, und wo­ bei das Nachrichtenserver-Softwaremodul (13) die wiederholt eingelesenen, neuen Prozeßdaten mit dem auf vorausgegangene ältere Prozeßdaten gleichen Typs basierenden Prozeßabbild aus dem Datenbankmodul (15) vergleicht (29), und bei Änderung und/oder Störung ein aktualisiertes Pro­ zeßabbild generiert (31) und in das Datenbankmodul (15) eingetragen (32) werden, dadurch gekennzeichnet, daß der Diagnoserechnerknoten (7) mittels eines in ihm implementierten Parametrier-Softwaremoduls (23), das mit dem Datenbankmodul (15) und/oder dem Nachrichtenserver- Softwaremodul (13) zusammenwirkt, zum Parametrieren der Prozeßrech­ nerknoten (2a-4e) verwendet wird.

2. Verfahren nach Anspruch 1, dadurch gekennzeichnet, daß das Bedien- Softwaremodul (14) zur Analyse und/oder grafischen Aufbereitung und Ausgabe der Prozeßdaten an einen externen Bus (35), als Störmeldelog­ buch, zum Laden und Sichern von Parametern in die Prozeßrechnerknoten (2a-4e) auch im Echtzeitbetrieb, zum Bearbeiten archivierter Daten und Pa­ rameter in der Datenbank (15), zum Ein- und Ausschalten des Betriebs der Prozeßdatenerfassung in Verbindung mit dem Nachrichtenserver- Softwaremodul (13) und/oder des Betriebs der Archivierung in Verbindung mit dem Datenbankmodul (15) verwendet wird.

3. Verfahren nach einem der vorangehenden Ansprüche, dadurch gekenn­ zeichnet, daß im Parametrier-Softwaremodul (23) die Bus-Adressen, Typ- Identifikationsangaben, interne Bezeichnung und Überwachungsflags der Prozeßrechnerknoten (2a-4e) hinterlegt werden.

4. Verfahren nach einem der vorangehenden Ansprüche, dadurch gekenn­ zeichnet, daß im Parametrier-Softwaremodul (23) die Werte beziehungs­ weise Parameter des oder der Prozeßrechnerknoten (2a-4e) aufgegliedert werden nach Nummer beziehungsweise Adresse im betreffenden Prozeßrechnerknoten (2a-4e), nach logischer Zugehörigkeit zu einer Gruppe, Kombination oder zu einem Typ von Parametern, nach Art der Meldung und/oder Verfügbar­ keit eines etwaigen Echtzeit-Datenkanals.

5. Verfahren nach einem der vorangehenden Ansprüche, gekennzeichnet durch einen oder mehrere Echtzeit-Datenkanäle für Prozeßdaten zwischen dem Nachrichtenserver-Softwaremodul (13) und einem oder mehreren Pro­ zeßrechnerknoten (2a-4e), wobei bei Erkennung einer Änderung oder Stö­ rung durch das Nachrichtenserver- und/oder Parametrier-Softwaremodul (13, 14) dem oder den betroffenen Prozeßrechnerknoten (2a-4e) durch das Parametrier-Softwaremodul (23) je ein Echtzeit-Datenkanal zugewiesen wird, über den die zur Änderung oder Strömung gehörigen Prozeßdaten in das Datenbankmodul (15) für die spätere Auswertung eingele­ sen werden.

6. Verfahren nach einem der vorangehenden Ansprüche, gekennzeichnet durch ein Echtzeit-Anbindungs-Softwaremodul (26), das wenigstens mit dem Bedien-Softwaremodul (14) gekoppelt ist und auf dieses derart einwir­ ken kann, daß über das Bedien-Softwaremodul (14) und das Nachrichten­ server-Softwaremodul (13) und gegebenenfalls den oder die Echtzeit- Datenkanäle Befehle, Parameter und/oder sonstige Daten zu den Prozeß­ rechnerknoten (2a-4e) übermittelt werden und/oder das Bedien- Softwaremodul (14) mit einer Schnittstelle (10) des Diagnoserrechnerkno­ tens (7) für Datenfernübertragung gekoppelt wird, wobei dieses zur Echt­ zeit-Veränderung und/oder -Optimierung von Daten und Parametern im Pa­ rametrierungs-Softwaremodul (23) und/oder in dem oder den Prozeßrech­ nerknoten (2a-4e) verwendet wird.

7. Verfahren nach einem der vorangehenden Ansprüche, dadurch gekenn­ zeichnet, daß das Parametrier- und/oder Nachrichtenserver-Softwaremodul (23, 13) auf Parameterwerte, insbesondere wenn sie in den Prozeßrechner­ knoten (2a-4e) abgelegt sind, mittels Zeiger- und/oder indirekter Adressie­ rung zugreifen.

8. Verfahren nach einem der vorangehenden Ansprüche, dadurch gekenn­ zeichnet, daß bei der Änderung oder Störung in Verbindung mit den Prozeßdaten von den Prozeßrechnerknoten (2a-4e) ein An­ zeigeprogramm (33) in Verbindung mit dem Bedien-Softwaremodul (14) und/oder einem bedienerorientierten Prozeßrechnerknoten (2a, 2b) para­ metrisiert wird.