1. Einleitung Die Forschung im Bereich Echtzeitdatenbanken hat sich in den letzten Jahren zu einem wichtigen Forschungsfeld moderner Datenbanken entwickelt und erfährt große Beachtung. Als Schlüsseltechnologie in der industriellen Steuerungssoftware spielen Echtzeitdatenbanken eine entscheidende Rolle in Systemen mit hohen Echtzeitanforderungen. Sie eignen sich für die Verarbeitung ständig aktualisierter und sich schnell ändernder Daten sowie für zeitkritische Transaktionen. Beispielsweise müssen in Stromnetzüberwachungssystemen Tausende oder sogar Zehntausende von Echtzeitgrößen und Statusvariablen innerhalb von Sekunden aktualisiert werden. Gleichzeitig muss die entsprechende Überwachungsanzeige aktualisiert werden, um die Konsistenz zwischen Anzeige und Realität zu gewährleisten. Dies stellt hohe Anforderungen an die Abrufeffizienz von Echtzeitdatenbanken. 2. Faktoren, die die Abrufeffizienz beeinflussen Die Datenzugriffsgeschwindigkeit ist einer der Hauptengpässe, die die Abrufeffizienz von Echtzeitdatenbanken beeinträchtigen. Analysen der Computerhardware-Leistung zeigen, dass die Festplattenzugriffsgeschwindigkeit bei etwa 100 MB/s liegt. Häufige Zugriffe auf externe Speichermedien beeinträchtigen die Systemeffizienz erheblich. Zweitens spielt auch die durchschnittliche Suchlänge der Nachschlagetabelle eine Rolle. Bei großen Datenmengen kann eine lange durchschnittliche Suchlänge ebenfalls zu einem Systemengpass führen. Da die Datenverarbeitung unvorhersehbar ist, kann es zudem passieren, dass Daten in der Echtzeitdatenbank ungültig werden oder wichtige Daten und Ereignisse verloren gehen, wenn die Verarbeitung bestimmter Daten nicht innerhalb der vorgegebenen Zeit abgeschlossen werden kann. Dies führt zu Verzögerungen oder sogar Konflikten bei der Datenverarbeitung. Dank der Entwicklung der Mikroelektronik ist Speicher mit hoher Kapazität heute Realität. Durch die Erweiterung des Speichers können alle in Echtzeit benötigten Daten im Arbeitsspeicher abgelegt werden, während historische Datensätze für die Entscheidungsunterstützung und andere abgeleitete Daten (z. B. Alarm- und Unfallberichte) in der Echtzeitdatenbank in einer relationalen Datenbank auf einem externen Speicher abgelegt werden können. Dies kann die Anforderungen an die Geschwindigkeit bis zu einem gewissen Grad reduzieren. Da der Speicher jedoch nicht unbegrenzt erweiterbar ist, müssen Softwaremethoden untersucht werden. 3 Vektorbasierte Datenabfrage 3.1 Datenstruktur Im Stromnetzüberwachungssystem muss die Echtzeitdatenbank Daten verschiedener Mess- und Steuergeräte für die Echtzeitüberwachung und Feldsteuerung speichern sowie den Zustand der Überwachungspunkte im Hinblick auf Alarme und Störungen beurteilen und analysieren. Die Speicherstruktur dieser Daten hat einen wesentlichen Einfluss auf die durchschnittliche Suchlänge der Nachschlagetabelle. Aufgrund der hohen Effizienz der Vektorabfrage werden in diesem Beitrag Vektoren zur Organisation dieser Daten verwendet. Die Speicherstruktur der resultierenden Echtzeitdatenbank ist in Abbildung 1 dargestellt. Jeder Überwachungspunkt vor Ort wird eindeutig durch seinen Anlagennamen, den Überwachungspunkttyp und den Überwachungspunktnamen identifiziert. Der Status jedes Überwachungspunkts wird durch mehrere Parameter beschrieben, typischerweise bestehend aus Vor-Ort-Werten, Alarmflags, oberen und unteren Alarmgrenzen, Alarmtotzonen, Betriebszustand und einigen Statistiken. 3.2 Algorithmusimplementierung Um die durchschnittliche Suchlänge zu reduzieren, kann das Sortieren und Abrufen dieser Echtzeitdatenbank mithilfe des folgenden Algorithmus implementiert werden: 1. Sortieren und Abrufen der Anlagennamen. Angesichts der im Allgemeinen relativ geringen Anzahl an Pflanzen wird folgende Zuordnung zwischen Mengen erstellt: map: {Pflanzenname} {Vektorindex}. Dabei ist der Pflanzenname der Schlüssel und der Vektorindex der Wert. Somit kann der Index des Vektorelements direkt aus dem Pflanzennamen abgeleitet und die Pflanze gefunden werden. 2. Sortieren und Abrufen von Überwachungspunkttypen und -namen. Aufgrund der relativ großen Anzahl an Überwachungspunkttypen und -namen wird eine Hashtabelle zum Sortieren verwendet. Um die Effizienz der Adressberechnung zu verbessern, wird eine direkte Adressierungsmethode zur Erstellung der Hashfunktion verwendet, und Kollisionen werden durch Verkettung behandelt. Zunächst wird die Länge der Hashtabelle anhand der Anfangsdaten bestimmt. Um Kollisionen zu reduzieren, wird üblicherweise ein leerer Vektor generiert, dessen Länge größer als die Länge der Anfangsdaten ist. Anschließend ordnen eine gegebene Hashfunktion und eine Funktion zur Kollisionsbehandlung den entsprechenden Überwachungspunkttyp bzw. -namen den Elementen des Vektors zu. Ist die Vektortabelle voll, wird einfach ein Element am Ende des Vektors angehängt, um ihn mit den neuen Daten zu füllen. Anschließend wird der Index des Elements in die verkettete Adresstabelle eingetragen. 3. Sortieren und Abrufen von Überwachungspunktparametern. In einem Stromnetzüberwachungssystem entspricht jeder Überwachungspunkt einem Gerät im Feld. Daher benötigt jeder Überwachungspunkt Parameter, die den Gerätestatus widerspiegeln. Im Allgemeinen ist die Anzahl der Parameter pro Überwachungspunkt nicht sehr groß. Aufgrund der hohen Effizienz der sequenziellen Speicherung und des sequenziellen Abrufs bei geringem Datenvolumen werden diese Methoden angewendet. Darüber hinaus wird die Position der Parameter dynamisch entsprechend ihrer Abrufhäufigkeit angepasst, wobei Parameter mit hoher Abrufhäufigkeit am Anfang und Parameter mit niedriger Abrufhäufigkeit am Ende des Vektors platziert werden. 4. Die Einführung von Multithreading-Technologie in Stromnetzüberwachungssystemen erfordert Echtzeit-Datenbankaktualisierungen der Felddaten. Dies ermöglicht die Sicherheitsüberwachung und Feldsimulation auf Basis der Felddaten, das Speichern der Felddaten in benutzerdefinierten Zeitintervallen sowie die Wiedergabe von Vorfällen an den Überwachungspunkten. Würden all diese Funktionen von einem einzigen Thread ausgeführt, würden Ressourcenkonflikte und andere Probleme die Verarbeitungseffizienz negativ beeinflussen. Daher haben wir die in Abbildung 2 dargestellte Multithread-Struktur gewählt. Das Gesamtsystem besteht aus einem Kommunikationsthread, einem Alarmverarbeitungsthread, einem Thread zum Schreiben der Historiendatenbank, einem Thread zum Schreiben auf die Festplatte, einem Thread zur Anzeigeüberwachung und einem Hauptschnittstellenthread. Der Kommunikationsthread ist primär für die Kommunikation zwischen der Echtzeitdatenbank und dem Feld zuständig. Verschiedene Mess- und Steuergeräte senden die erfassten Daten an ihre jeweiligen Ports. Der Kommunikationsthread scannt jeden Port in Echtzeit und wandelt die vom Feld erfassten Rohdaten durch verschiedene Protokollkonvertierungen in für das System oder den Benutzer verständliche Daten um, bevor er sie an die Echtzeitdatenbank sendet. Bei Bedarf werden auch Rohdaten an die Echtzeitdatenbank gesendet. Gleichzeitig empfängt der Kommunikationsthread verschiedene Steuerungs- und Einstellbefehle vom Displayüberwachungsthread, wandelt diese über entsprechende Kommunikationsprotokolle in für die Mess- und Steuergeräte lesbare Daten um und sendet sie zur Ausführung an die zugrundeliegenden Geräte. Der Kommunikationsthread ist außerdem dafür zuständig, die zu speichernden Rohdaten, Systeminformationen des Kommunikationsmoduls und Fehlerinformationen in eine Pufferwarteschlange zur Verarbeitung durch einen anderen Thread zu schreiben. Der Alarmverarbeitungsthread ist primär für das Scannen der Echtzeitdatenbank sowie die Erkennung und Behandlung von Alarmen und Vorfällen verantwortlich. Dieser Thread wird vom Kommunikationsthread gestartet, und der Verarbeitungsablauf ist in Abbildung 3 (Flussdiagramm der Alarmverarbeitung) dargestellt. Der Thread wird gestartet, sobald Daten in die Echtzeitdatenbank geschrieben werden. Um zu verhindern, dass Alarme und Vorfälle übersehen werden, wird die globale Variable `NoProccessCount` verwendet, um die Anzahl der Punkte zu erfassen, deren Feldwerte sich geändert haben, die aber innerhalb eines Echtzeitdatenbank-Scanzyklus noch nicht verarbeitet wurden. `bNew` gibt an, ob sich der Feldwert eines Punktes innerhalb dieses Scanzyklus geändert hat. Wenn der Kommunikationsthread in die Echtzeitdatenbank schreibt, setzt er das Flag `bNew` des entsprechenden Datenpunkts auf den geänderten Zustand und erhöht `NoProccessCount` um 1. Wird der Alarmverarbeitungsthread ausgelöst, sucht er zunächst den Datenpunkt in der Echtzeitdatenbank, verringert `NoProccessCount` um 1, setzt `bNew` auf den unveränderten Zustand und führt eine Alarm- und Ereigniserkennung durch. Tritt ein Alarm oder ein Ereignis auf, verarbeitet er die entsprechenden Daten und schreibt die Alarminformationen bzw. den Ereignis-Rückrufwert zur Weiterverarbeitung durch einen anderen Thread in die entsprechende Pufferwarteschlange. Anschließend prüft er, ob `NoProccessCount` gleich 0 ist. Ist dies der Fall, befinden sich keine zu verarbeitenden Datenpunkte in der Echtzeitdatenbank, und der Thread wartet auf die erneute Auslösung. Andernfalls scannt er den nächsten Überwachungspunkt und prüft, ob sich `bNew` in einem geänderten Zustand befindet. Ist dies der Fall, setzt er `bNew` auf den unveränderten Zustand, verringert `NoProccessCount` um 1 und führt eine Alarm- bzw. Ereignisprüfung durch. Tritt ein Alarm oder ein Unfall auf, wird die entsprechende Verarbeitung durchgeführt und anschließend der Wert von NoProccessCount überprüft. Diese Schritte werden wiederholt, bis ein Beendigungsereignis ausgelöst wird. Der Thread wird dann beendet. Der Thread zum Schreiben der Verlaufsdatenbank ist hauptsächlich für das periodische Speichern von Daten aus der Echtzeitdatenbank in der externen Speicherdatenbank zuständig. Im Stromnetzüberwachungssystem können Benutzer die Daten der Verlaufsdatenbank anpassen, d. h. sie können die zu speichernden Zustandsänderungen und Messwerte sowie das Speicherintervall definieren. Zur Effizienzsteigerung wird eine verkettete Liste aller Überwachungspunktinformationen erstellt, für die Verlaufsdaten gespeichert werden sollen. Die Struktur des Verlaufsdatenbankknotens in dieser verketteten Liste ist wie folgt: struct HistoryNode{ string stationName; string typeName; string pointName; time_t startTime; double intervalTime; struct HistoryNode *next; } ; Dabei ist stationName der Stationsname, typeName der Punkttyp, pointName der Punktname, startTime der Zeitpunkt der letzten Speicherung in der Verlaufsdatenbank und intervalTime das Speicherintervall für die Verlaufsdatenbank. Der Thread zum Schreiben der Verlaufsdatenbank durchsucht die verkettete Liste in Echtzeit. Die Vorgehensweise ist wie folgt: Für jeden Punkt in der Liste wird zunächst die Systemzeit mit `startTime` verglichen. Ist die Differenz zwischen Systemzeit und `startTime` größer als `intervalTime`, ist der Schreibzyklus für diesen Punkt in der Verlaufsdatenbank abgelaufen. In diesem Fall werden die Indizes `stationName`, `typeName` und `pointName` verwendet, um den Wert des Punktes aus der Echtzeitdatenbank abzurufen und in die entsprechende Pufferwarteschlange zu schreiben. Anschließend schreibt der Thread zum Schreiben auf die Festplatte den Wert in die externe Speicherdatenbank. Andernfalls wird der nächste Knoten durchsucht. Der Thread zur Anzeigeüberwachung ist hauptsächlich für die Echtzeitsimulation und die Vor-Ort-Steuerung zuständig. Jedem Punkt im Feld ist ein entsprechendes Bild im Simulationsbildschirm zugeordnet. Dieser Thread durchsucht periodisch jeden Bildpunkt im Bildschirm, sucht anhand des Anlagennamens, des Überwachungspunkttyps und des Überwachungspunktnamens des Bildpunkts in der Echtzeitdatenbank nach dem Wert des simulierten Punktes und ändert den Zustand des simulierten Punktes im Bildschirm oder zeigt diesen Wert entsprechend an. Der Hauptschnittstellen-Thread ist hauptsächlich für die Online-Einstellungen des Benutzers zuständig. Dieser Thread schreibt benutzerdefinierte Informationen wie Definitionen von Verlaufsdatenbankdaten, Alarmberechtigungen und Alarmgrenzwerten in die Echtzeitdatenbank. Er ist außerdem für die Verwaltung verschiedener Threads verantwortlich. Der Festplattenschreib-Thread schreibt Daten aus der Pufferwarteschlange auf den externen Speicher. Für das Lesen und Schreiben in die Pufferwarteschlange wird ein Produzent-Konsument-Modell verwendet (siehe Abbildung 4). Dieses Modell verfügt über zwei Pufferpools: einen Produzenten (RP) und einen Konsumenten (WP). Der Kommunikationsprozess, der Alarmbehandlungs-Thread und der Verlaufsdatenbank-Schreib-Thread fungieren als Produzenten, während der Festplattenschreib-Thread als Konsument agiert. Produzenten und Konsumenten, die gleichzeitig auf denselben Pufferpool zugreifen, müssen dies exklusiv tun. Anfangs füllt einer der Produzenten (Kommunikationsprozess, Alarmbehandlungs-Thread oder Verlaufsdatenbank-Schreib-Thread) beide Pufferpools. Sobald beide Pufferpools voll sind und neue Daten im System generiert werden, wird der zweite Pufferpool erweitert. Der erste Pufferpool wird an den Festplatten-Schreibthread übergeben, der benachrichtigt wird, dass er Daten lesen kann. Der Festplatten-Schreibthread beginnt dann, Daten aus dem ersten Pufferpool auf den externen Speicher zu schreiben. Nachdem der Festplatten-Schreibthread das Lesen aus einem Pufferpool abgeschlossen hat, übergibt er diesen Pufferpool an den Produzenten-Thread zurück und benachrichtigt ihn, dass der Pufferpool leer ist und weitere Daten empfangen kann. Anschließend wartet er, bis der zweite Pufferpool verfügbar ist, bevor er die Daten aus diesem Pufferpool auf den externen Speicher schreibt. Dieser abwechselnde Lese- und Schreibprozess stellt sicher, dass der Kommunikationsprozess, der Alarmbehandlungs-Thread und der Thread zum Schreiben der historischen Datenbank alle mit Daten im Arbeitsspeicher arbeiten, was die Verarbeitungseffizienz deutlich verbessert. Das gesamte System arbeitet durch die Koordination zwischen den Threads, wobei Ereignisse sich gegenseitig auslösen und so eine Verschwendung von Systemeffizienz durch Schleifenerkennung vermieden wird. 4. Fazit: Im Vergleich zu bestehenden Echtzeit-Datenbankabfragemethoden haben die beiden in diesem Beitrag vorgestellten Methoden bessere Ergebnisse hinsichtlich der Reduzierung der durchschnittlichen Suchlänge von Tabellen und der Verbesserung der Datenverarbeitungsgeschwindigkeit erzielt. Beispielsweise verwenden die Referenzen [15] und [16] für die Speicherung der Echtzeitdatenbank eine B-Baum-Struktur bzw. eine sequentielle Struktur. Unter der Annahme, dass die Echtzeitdatenbank n Datenelemente enthält, beträgt die durchschnittliche Suchlänge ASL. Bei Verwendung der sequenziellen Suchmethode ergibt sich ASL = (n+1)/2; dies entspricht der durchschnittlichen Suchlänge der B-Baum-Struktur, wobei m die Ordnung des B-Baums ist. Bei Verwendung der in diesem Beitrag vorgestellten Abrufmethode gilt jedoch für den Abruf von Anlagennamen ASL = 1; für den Abruf von Überwachungspunkttypen und -namen gilt ASL = 1 + α/2 ≤ 1,5 (α ≤ 1). Im vom Autor entwickelten Stromnetzüberwachungssystem wurden die oben genannten Methoden umfassend angewendet. Nach erfolgreichen Tests wurde die Echtzeitdatenbank auf einem IBM APTIVA-Server (Pentium III 550, 128 MB RAM, Windows 2000 Server) betrieben. Bei mehr als 5.000 Überwachungspunkten vor Ort konnten die Daten mit einer Datenrate von 9600 Bit über die serielle Schnittstelle an die Echtzeitdatenbank übertragen werden. Die Leistungsindikatoren können mit denen der Echtzeitdatenbank der dreidimensionalen Kraftregelung aus Referenz [17] verglichen werden (siehe Tabelle 1). Referenzen: 1 Wang Quan, Jin Haidong, Li Fuzhong. Design and implementation of real-time database system for industrial control configuration software. Computer Application 2000, 1, 6. 2 Liu Yunsheng, Yi Lan, Yu Liping. A real-time data model. Small and micro computer systems 2000, 5. 3 Tang Ziying, Zhe Fengping, Tang Xiaodan. Computer operating system. Xi'an University of Electronic Science and Technology Press 2001, 8, 1. 4 Yan Weimin, Wu Weimin. Data structure. 5 Stanley Lippman et al., C++ Primer, translate by Pan Aimin. Tsinghua University Press, 1999, 7. 6 DLG107-92, Technische Spezifikationen für den Entwurf eines Mikrocomputer-Überwachungssystems für ein 500-kV-Umspannwerk, China Electric Power Press, 1992. 7 DLG 5002-91, Technische Spezifikationen für den Entwurf der regionalen Netzleitstellenautomatisierung, China Electric Power Press, 1991. 8 DLG5002-92, Technische Spezifikationen für den Entwurf der Netzleitstellenautomatisierung, China Electric Power Press, 1992. 9 DL476-92 Anwendungsschichtprotokoll für die Echtzeit-Datenkommunikation in Energiesystemen, China Electric Power Press, 1992. 10 Yang Ling. Überblick über Echtzeitdatenbanken, Metallurgical Automation, 1996, 3. 11 Tan Zhukui. Zusammensetzung einer Echtzeitdatenbank für ein Fernsteuerungssystem, Electric Power Automation Equipment, 2002, 1. 12 Zhou Buxiang, Yu Xiaowen. Integrationsstrategien für Echtzeit-Datenbankmanagement-Software, Computer Engineering, 1995, 3 13 JR Haritsa und K. Ramamritham. Echtzeitdatenbanken im neuen Jahrtausend, Echtzeitsysteme, 2000 14 A. Datta, S. Mukherjee, P. Konana, I. Viguier, A. Bajaj. „Multiclass Transaction Scheduling and Overload Management in Firm Real-Time Database Systems“, Information Systems, Bd. 21, Nr. 1, 1996, S. 29–54. 15 Haritsa J. und S. Seshadri. „Real-Time Index Concurrency Control“, IEEE Transactions on Knowledge and Data Engineering, 2000. 16 Tao Zhixiang, Huang Wei. Anwendung von Echtzeit-Datenbanktechnologie im Autobahn-Ereignismanagement, Journal of Civil Engineering, 2001, 3 17 He Penghui. Anwendung der FIX-Software in Energiesystemen, World Instrumentation and Automation 2002, 18, Ma Guohua. Überwachungskonfigurationssoftware und ihre Anwendung, Tsinghua University Press 2001, 8. Autorenbiografien: Yin Baokun (geb. 1975), männlich, aus Jinxiang, Provinz Shandong, Master-Abschluss, Forschungsschwerpunkte: Echtzeitüberwachung, Multimedia-Übertragung. Niu Lianqiang (geb. 1965), männlich, aus Gaixian, Provinz Liaoning, Professor, Forschungsschwerpunkte: wissenschaftliche Datenvisualisierung, Computersimulation. Zhang Shengnan (geb. 1968), weiblich, außerordentliche Professorin, Forschungsschwerpunkte: Datenbanktheorie. Wang Xiaodong (geb. 1979), männlich, aus Nanyang, Provinz Henan, Master-Abschluss, Forschungsschwerpunkte: Energieüberwachungssysteme, digitale Wasserzeichen.