Ein statisches Modell einer verteilten Architektur. Speicherschicht mit verwalteter verteilter Architektur

basierend auf einer rekonfigurierbaren Multi-Pipeline-Computing-Umgebung von L-Net

Eine der dringendsten Aufgaben im Bereich Leitsysteme ist die Entwicklung von Software für verteilte fehlertolerante Leitsysteme. Die heute in diesem Bereich existierenden Lösungen sind proprietär, daher teuer und nicht immer effektiv.

Diese Lösungen bieten keine effiziente Nutzung der Ressourcen redundanter Basen, Technik und Software, was sowohl die Fehlertoleranz als auch die Skalierbarkeit solcher Lösungen negativ beeinflusst. Bei Verletzung der Netzwerkarchitektur besteht keine Möglichkeit der dynamischen Rekonfiguration sowohl der Ials auch der Übertragung von Datenströmen (sowohl Kontrolle als auch Information). Der Einsatz spezifischer Mikrocontroller, der Einsatz von DCS / SCADA erschwert die Entwicklung und Betreuung von Systemen, die Erweiterung ihrer Funktionalität.

Architektur des verteilten Steuerungssystems

Die verallgemeinerte typische Architektur eines verteilten Leitsystems (PLS) umfasst drei hierarchisch zusammenhängende Ebenen: Bedienerebene, Steuerungsebene und I/O-Ebene (siehe Abb. 1).

Die Hauptaufgabe der Bedienerebene besteht darin, eine Mensch-Maschine-Schnittstelle (HMI) bereitzustellen, um die Konfiguration und die Kontrolle der Funktionsfähigkeit des Gesamtsystems sicherzustellen. Die Steuerungsebene ist dafür verantwortlich, Daten von Sensoren zu empfangen und zu verarbeiten, Daten an die Bedienerebene zu übermitteln und Steueraktionen an den Aktoren zu entwickeln. Die I/O-Ebene repräsentiert Sensoren und Aktoren, die direkt mit dem gesteuerten Objekt verbunden sind.

Aufgabe der Software im Rahmen der generalisierten Architektur des DCS ist es, die Funktionsfähigkeit der Betreiberebene und deren Anbindung an die Leitebene der Anlage sicherzustellen. Folglich ist die grundlegende Ebene bei der Softwareentwicklung und der Lösung von Problemen ihrer Interaktion mit der Hardware die des Betreibers. Die Software sollte die verfügbaren Hardwareressourcen des Systems optimal nutzen und dabei möglichst unabhängig von der internen Architektur der Hardware sein.

Hardware stellt Rechenressourcen, Speicher und Kommunikationsmedien zwischen Knoten in einem System bereit. Beim Entwurf der allgemeinen Architektur des Systems werden die spezifischen Knoten der I / O-Ebene, die in einer bestimmten Implementierung damit verbunden werden, nicht berücksichtigt, daher werden in der verallgemeinerten Architektur die Bedienerebene und die Steuerungsebene berücksichtigt. Hardware muss weit verbreitet sein, modernen Standards entsprechen und über alle Eigenschaften und Fähigkeiten verfügen, die zur Implementierung der Architektur erforderlich sind.

DCS-Anforderungen

Die Anforderungen an das DCS gelten nicht nur für das Gesamtsystem, sondern auch für dessen Hard- und Softwarekomponenten getrennt, da die konkreten Ansätze zur Erfüllung dieser Anforderungen für diese Komponenten grundsätzlich unterschiedlich sein können. Das DCS sollte vor allem fehlertolerant sein. Die einfachste Methode zur Erhöhung der Fehlertoleranz ist die Redundanz (Duplizierung) von Funktionseinheiten oder deren Aggregat. Die zweite wichtige Eigenschaft ist die Skalierbarkeit. Die Skalierbarkeit basiert auf der Implementierung spezieller Algorithmen in Software und der Fähigkeit der Hardware, neue Knoten oder deren Bestandteile zu ersetzen und hinzuzufügen. Gleichzeitig soll das System in seiner Bedienung, der Entwicklung neuer Knoten oder Module und der Modifikation seiner Architektur einfach bleiben.

Übersicht über DCS-Architekturen

Für die Überprüfung der DCS-Architekturen wurde Siemens SIMATIC PCS 7 DCS als eines der gefragtesten auf dem Markt und RTS S3 als auf Basis von QNX RTOS implementiertes DCS ausgewählt.

Siemens SIMATIC PCS 7

Die Systemarchitektur weist alle Eigenschaften einer generischen DCS-Architektur auf. Die Operator Stationen sind Computer auf Basis einer x86-Prozessorarchitektur mit Windows OS und Siemens WinCC Paket, das ein HMI bereitstellt. Es gibt Server mit Datenbanken. Operator Stationen, Engineering Stationen und Server sind über ein Ethernet-basiertes lokales Netzwerk verbunden. Die Bedienebene ist mit der Steuerungsebene des redundanten Industrial Ethernet-Netzwerks verbunden. Auf der Steuerungsebene gibt es speicherprogrammierbare Steuerungen (SPS) mit der Möglichkeit der Redundanz durch Doppelfunktionalität. Es ist möglich, sich mit externen Systemen und Netzwerken zu verbinden und den Fernzugriff auf das System zu organisieren.

RTS S3

Diese Architektur besteht ebenfalls aus den Schichten der verallgemeinerten Struktur des DCS. Die Operator Stationen basieren auf der gleichen Hardwareplattform wie im SIMATIC DCS, sind jedoch sowohl unter Windows- als auch unter Linux-Betriebssystemen lauffähig. Engineering-Stationen werden mit Operator-Stationen kombiniert. Das System bietet eine einheitliche Anwendungsentwicklungsumgebung. Ein Ethernet-Netzwerk verbindet Knoten innerhalb der Trägerschicht und die Betreiberebene selbst mit der Steuerungsebene unter Verwendung des TCP/IP-Protokollstapels. Auf der Steuerungsebene gibt es Industriecomputer mit QNX OS mit eigener Datenbank und der Möglichkeit der Redundanz durch Duplizieren der Funktionalität des Knotens.

Nachteile der beschriebenen Systeme

Die oben beschriebenen Systeme verwenden eine unterschiedliche Hardware-/Softwareplattform für die Bedienerebene und die Steuerungsebene. Innerhalb der Operator-Ebene kann nur eine Prozessorarchitektur verwendet werden und für die Projektierung und Entwicklung der Leitebene ist eine spezielle Engineering-Station erforderlich. Diese DCSs bieten nur Hardwareredundanz mit Duplizierung der Funktionalität des redundanten Knotens, um die Fehlertoleranz zu erhöhen, was eine irrationale Verwendung redundanter Hardware ist.

Eigenschaften und Funktionsmerkmale des L-Net Systems

Bei der Entwicklung des L-Net-Systems bestand die Aufgabe darin, ein Steuerungssystem zu schaffen, das folgende Eigenschaften aufweisen sollte:

• Dynamische Neukonfiguration mit vollständiger Wiederherstellung mit minimalem Verlust im Falle eines Hostausfalls oder einer Unterbrechung der Netzwerktopologie.
• Effiziente Aufgabenverteilung auf die verfügbaren effizienten Netzwerkknoten.
• Duplizierung von Kommunikationskanälen zwischen Knoten mit dynamischer Neukonfiguration der Datenübertragungsströme.
• Benutzerfreundlichkeit und Skalierbarkeit des Systems.
• Portabilität und Leistung des Systems auf jeder Hardwareplattform, die für Gebäudeleitsysteme und eingebettete Systeme entwickelt wurde.

Um ein System mit den oben genannten Eigenschaften aufzubauen, wird ein Betriebssystem benötigt, das in erster Linie für die Erstellung von Leitsystemen und eingebetteten Systemen gedacht ist. Die Analyse bestehender Betriebssysteme zeigte, dass QNX 6 (Neutrino) das am besten geeignete Betriebssystem ist, das über eine sehr effiziente Ressourcenzuweisung und Netzwerkfähigkeiten verfügt. Das Qnet-Netzwerkprotokoll bietet umfassende Netzwerkfähigkeiten. Es löst das Problem der Zuverlässigkeit und des dynamischen Lastausgleichs von Kommunikationskanälen, aber es löst nicht das Problem der Fehlertoleranz des Systems als Ganzes. Als Ergebnis wurde ein innovatives Steuerungssystem entwickelt, das auf einer verteilten rekonfigurierbaren Multi-Pipeline-Computing-Umgebung basiert. Das entwickelte System weist eine Peer-to-Peer-Architektur auf, die drei logische Blöcke umfasst: einen Eingabe-Ausgabe-Block, einen Allzweck-Switch-Block und einen Block einer rekonfigurierbaren Rechenumgebung (RCS) (siehe Fig. 2).

Die Hauptvorteile dieser Architektur sind:

• Peer-to-Peer-Typ
• Dezentralisierung
• Skalierbarkeit
• Räumliche Aufteilung

Funktionsmerkmale dieser Architektur:

• Pipeline-Datenverarbeitung
• Hardware-Redundanz
• Lastverteilung
• On-the-fly-Rekonfiguration

Auf der ersten Ebene der Architektur befindet sich eine Eingabe-Ausgabe-(I/O)-Einheit, die Folgendes umfasst: Eingabe-Ausgabe-Knoten, einen Schalter von Eingabe-Ausgabe-Knoten, eine Eingabe-Ausgabe-Schnittstelle, Sensoren und Aktoren. Die Einheit ist verantwortlich für die grundlegenden Mechanismen zur Generierung von Steueraktionen basierend auf Daten von lokalen Sensoren und Daten, die von anderen Ebenen des Steuersystems empfangen werden. Die zugewiesenen Aufgaben werden auf die gesunden I/O-Knoten basierend auf ihrer aktuellen relativen Leistung oder manuell durch den Bediener verteilt. Sensoren und Aktoren sind über einen Bus mit allen I/O-Knoten im Block verbunden, wodurch jeder Knoten jeden Sensor abfragen oder einen Effekt auf jeden Aktor erzeugen kann. Der E/A-Knotenschalter stellt die Kommunikation zwischen allen E/A-Knoten her, um Daten zwischen ihnen und anderen Ebenen der Systemarchitektur auszutauschen, um Steuer- und Informationsdaten zu erhalten. Mit den entsprechenden Hardware-Fähigkeiten kommunizieren die Nodes untereinander und mit Nodes und Switches auf anderen Ebenen des Systems direkt, was die Reaktionszeit im Netzwerk reduziert. Die direkte Kommunikation zwischen Knoten und einer bestimmten Last von Knoten im aktuellen Betriebsmodus der I / O-Einheit ermöglicht die Organisation von Pipeline-Berechnungen in der Einheit, die für den Betrieb dieser Einheit erforderlich sind, ohne auf externe Rechenleistung der Steuerung zurückgreifen zu müssen ( DCS), die es ermöglicht, im Ausfallzeitpunkt bereitgestellte freie Ressourcen für Redundanzknoten der I/O-Einheit effektiv zu nutzen.

Der Block von Allzweck-Switches, der sich auf der zweiten Ebene der Architektur befindet, organisiert Kommunikationsleitungen zwischen den Input-Output-Blöcken und dem DCS und externen Systemen. Jeder Schalter kann verschiedene Verbindungen und Schalter im gesamten Steuerungssystem miteinander verbinden. Die Anzahl der Kommunikationsleitungen wird durch die Hardwarefähigkeiten der Knoten und Schalter bestimmt, die in den Blöcken enthalten sind. Da Sie mit dem Qnet-Netzwerk Datenströme dynamisch verteilen können, erfolgt die Skalierung dieses Blocks durch einfaches Anschließen neuer Geräte und erfordert keine Konfiguration, und wenn einer der Switches ausfällt, wird die Datenübertragung zwischen den Knoten nicht unterbrochen, wenn die ein anderer Switch stellt eine ähnliche Verbindung zwischen den Knoten her oder sie stehen in direktem Zusammenhang. Gleichzeitig muss für ausreichende Netzwerkbandbreite gesorgt werden, um einen ausgefallenen Switch zu sichern.

Der Block des rekonfigurierbaren Computernetzwerks (RCN), der sich auf der dritten Ebene der Architektur befindet, bietet ein Managementsystem mit hoher Rechenleistung zur Lösung komplexer Probleme der Informationsverarbeitung, Entscheidungsfindung, Erkennung usw. Der Block ist verantwortlich für die Initialisierung des gesamten Steuerungssystems: Überprüfung der Funktionsfähigkeit von Switches und Knoten, Netzwerkintegrität, Erstellen von Netzwerkgraphen des gesamten Systems, Einstellen der Startparameter für den Betrieb von Input-Output-Blöcken. Die Knoten dieses Bausteins ermöglichen die Archivierung sowohl eigener Daten als auch Daten von I/O-Bausteinen. Jeder Knoten dieses Blocks kann die Rolle einer Bedienermaschine spielen, die dazu bestimmt ist, den Betrieb des Systems zu überwachen und Anpassungen an den Arbeitsprogrammen sowohl dieses Knotens als auch aller Knoten des Systems vorzunehmen und auf Anfrage eine Neukonfiguration durchzuführen.

Lastverteilung

Eine der Hauptaufgaben des L-Net Systems ist die Verteilung der Rechenlast auf die Netzknoten. Die Lösung dieses Problems basiert auf der Konstruktion von Rechenpipelines. Um eine Rechenpipeline aufzubauen, wird vorläufig ein Aufgabengraph konstruiert – ein Schema zum Austauschen von Datenströmen von einer Quelle zu einem Empfänger. Sensoren fungieren als Quelle und Aktoren als Empfänger. Die Rechenpipeline selbst ist eine Abbildung des Aufgabengraphen (siehe Fig. 3) auf den Computernetzwerkgraphen (siehe Fig. 4) unter Berücksichtigung der Anforderungen der Aufgabe an die Rechenressourcen des Systems und seines aktuellen Zustands.

Die Lösung besteht darin, einen Dienst zu verwenden, der dem Empfänger umfassende Informationen über die aktuelle Hardware, deren Zustand und verfügbare Datenquellen bereitstellt, der mit Netzwerkgraphen und -aufgaben arbeitet. Als Ergebnis wird die Leistungsfähigkeit durch das Pipelining von Berechnungen erhöht und die rationelle Nutzung aller dem System zur Verfügung stehenden Rechenressourcen organisiert.

Fehlertoleranz

Das Hauptproblem des Funktionierens eines solchen Systems ist eine vollständige Unterbrechung der Rechenpipelines im Falle eines Ausfalls eines Knotens dieses Förderers oder einer Verletzung der Datenübertragung zwischen ihnen. Die grundlegenden Mittel des Qnet-Protokolls erreichen die Wiederherstellung von Verbindungen zwischen Knoten im Falle einer teilweisen Verletzung aufgrund der von der Architektur bereitgestellten Backup-Leitungen. Das L-Net-System löst das Problem der Wiederherstellung der Betriebsfähigkeit im Falle eines vollständigen Ausfalls des Hosts des Computersystems durch dynamisches Rekonfigurieren der Computerpipeline, d.h. Verwenden von Arbeitsressourcen, um den fehlerhaften Block zu ersetzen. Das System bietet drei Wiederherstellungsszenarien (Neukonfiguration), die sich in der Reaktionszeit auf einen Ausfall, der Wiederherstellungszeit und den verwendeten Hardwareressourcen unterscheiden: bei Ausfall, mit passiver Bereitschaft und aktiver Bereitschaft.

• Neukonfiguration bei Ausfall- Nachdem ein Fehler erkannt wurde, wird die Suche nach verfügbarer Hardware durchgeführt und deren Aufnahme in den Task-Graph.
• Rekonfiguration mit passiver Bereitschaft- Redundante Hardware wird im Voraus bestimmt, ein Prozess wird gestartet, der die Implementierung des Vertex des Task-Graphen auf dem Knoten sicherstellt, Verbindungen werden hergestellt, aber der Prozess verarbeitet die Daten nicht, es sei denn, der Hauptknoten fällt aus.
• Rekonfiguration mit aktiver Bereitschaft- der obere Teil des Aufgabengraphen ist auf mehreren Knoten implementiert, die parallel die Datenverarbeitung durchführen und das Ergebnis übertragen.

Als Ergebnis bietet das System flexible Ausfallsicherheit sowohl auf Software- als auch auf Hardwareebene, die Möglichkeit, die Konfiguration von Knoten ohne Arbeitsunterbrechung und Leistungsverlust unabhängig von der Implementierung des Netzwerks, der Rechenpipeline und des Knotens zu ändern.

Fazit

Das entwickelte L-Net-System setzt im Gegensatz zu den bestehenden Analoga die Nutzung verschiedenster Hardware-Eigenschaften von DCS-Knoten mit ihrer vollen Software-Kompatibilität voraus. Wenn Nodes unter der Kontrolle eines Betriebssystems (QNX Neutrino) arbeiten, ist es möglich, diese auf verschiedenen Prozessorarchitekturen (x86, ARM, MIPS usw.) mit einer Vielzahl von Schnittstellen und Peripheriegeräten aufzubauen. Die Implementierung der Knoten ist in Form von Desktop, Industrie-PCs, Wearable-PCs und Single-Board-Computern möglich. Alle Komponenten des Softwarepakets des entwickelten DCS können auf jedem seiner Nodes mit dem QNX OS gestartet werden, während es weiterhin möglich ist, Nodes mit einem anderen Betriebssystem zu verwenden. Dieser Ansatz ermöglicht es, dass jeder Knoten verwendet werden kann, um Aufgaben sowohl auf Bedienerebene als auch auf Steuerungsebene zu lösen. Folglich gibt es ein flexibles Interaktionssystem zwischen Peers ohne eine starre Hierarchie von Ebenen, die der generalisierten DCS-Architektur und Systemen, die diese Architektur als Basis verwenden, innewohnen. Peer-to-Peer-Netzwerke vereinfachen die Prozesse der Bereitstellung, des Betriebs, der Skalierung und des Debuggens eines Systems.

Um das Rechenpotential der redundanten Hardware im entwickelten System zu realisieren, werden dynamische Konfigurations- und Rekonfigurationsalgorithmen basierend auf dem Qnet Netzwerkprotokoll und der L-Net Netzwerksoftware vorgeschlagen. Der dynamische Konfigurationsalgorithmus basiert auf der Verteilung der Rechenlast auf alle Knoten durch Pipelining und Parallelisierung von Aufgaben und den dynamischen Lastausgleich auf den Datenübertragungskanälen zwischen den Knoten. Der Sgeht davon aus, dass drei Szenarien zur Wiederherstellung der Funktionsfähigkeit im Fehlerfall vorliegen, abhängig von der verfügbaren Hardware, den Prioritäten und den dem System zugewiesenen Aufgaben: bei Ausfall, mit passiver Bereitschaft (Ressourcenzuweisung) und mit aktiver Bereitschaft (Ressourcennutzung) . Dynamische Konfigurations- und Rekonfigurationsalgorithmen verbessern die Leistung und Zuverlässigkeit unter Nutzung der Hardwarereserven im System.

Ein wichtiger Vorteil des Systems ist die maximale Transparenz der darin verwendeten Hard- und Softwaretechnologien, die es ermöglicht, die technische Betreuung des Systems und die Entwicklung neuer Module dafür erheblich zu vereinfachen.

Ausgabe

Die entwickelten Architekturlösungen ermöglichen es, Indikatoren von verteilten Steuerungssystemen wie Zuverlässigkeit, Leistung, Kosten, Skalierbarkeit und Einfachheit durch die Möglichkeit der Verwendung einer breiten Palette von Hardware, die Implementierung dynamischer Konfigurationsalgorithmen und die rationelle Nutzung von Systemressourcen zu verbessern.

1. http://kazanets.narod.ru/DCSIntro.htm.
2. http://kazanets.narod.ru/PCS7Overview.htm.
3. http://www.rts.ua/rus/news/678/0/409.
4. Zyl S. QNX Momentics: Anwendungsgrundlagen. - SPb: BHV-Petersburg, 2005.
5. Krten R. Einführung in QNX Neutrino. Ein Leitfaden für die Entwicklung von Echtzeitanwendungen. - SPb: BHV-Petersburg, 2011.

Stichworte: verteiltes Steuerungssystem, Informationsunterstützung für Steuerungssysteme, verteilte rekonfigurierbare Systeme.

Architektur eines verteilten Steuerungssystems basierend auf einer rekonfigurierbaren Multi-Pipeline-Computing-Umgebung L-Net

Sergej Yu. Potomskiy, Assistenzprofessor der Nationalen Forschungsuniversität "Higher School of Economics".

Nikita A. Poloyko, Studentin im fünften Jahr der National Research University "Higher School of Economics". Studienassistentin. Programmierer. Ausbildungsbereich: "Steuerung und Informatik in den technischen Systemen".

Abstrakt. Der Artikel ist einem verteilten Steuersystem gewidmet, das auf einer rekonfigurierbaren Multi-Pipeline-Computing-Umgebung basiert. Die Architektur des Systems ist vorgegeben. Außerdem werden die grundlegenden Eigenschaften und Funktionseigenschaften des Systems angegeben. Der Artikel präsentiert eine Begründung für die Wahl des Betriebssystems. Die grundsätzlichen Vorteile des Systems im Vergleich zu bestehenden ähnlichen Entwicklungen werden im Artikel aufgezeigt.

Schlüsselwörter: verteiltes Steuerungssystem, Systemsoftwareunterstützung, verteilt rekonfigurierbar.

In Kontakt mit

Laut E. Tanenbaum, einem ausgewiesenen Informatiker, gibt es keine allgemein akzeptierte und zugleich strikte Definition eines verteilten Systems. Einige Witze argumentieren, dass verteilt so ist Computersystem, bei dem eine Fehlfunktion eines Computers, von deren Existenz die Benutzer zuvor nicht einmal ahnten, zur Beendigung ihrer gesamten Arbeit führt. Ein erheblicher Teil der verteilten Computersysteme erfüllt leider diese Definition, aber formal bezieht sie sich nur auf Systeme mit einer einzigartigen Schwachstelle ( der Punkt des Versagens).

Häufig liegt der Fokus bei der Definition eines verteilten Systems auf der Aufteilung seiner Funktionen auf mehrere Rechner. Bei diesem Ansatz ist any verteilt Computersystem wo die Datenverarbeitung auf zwei oder mehr Computer aufgeteilt wird. Basierend auf der Definition von E. Tanenbaum kann ein etwas enger verteiltes System als eine Menge unabhängiger Computer definiert werden, die durch Kommunikationskanäle verbunden sind, die aus der Sicht eines Benutzers einer Software wie ein einziges Ganzes aussehen.

Dieser Ansatz zum Definieren eines verteilten Systems hat seine Nachteile. Zum Beispiel alles, was in einem so verteilten System verwendet wird Software auf einem einzelnen Computer funktionieren könnte, aber aus der Sicht der obigen Definition wird ein solches System nicht mehr verteilt. Daher sollte das Konzept eines verteilten Systems wahrscheinlich auf der Analyse der Software basieren, die ein solches System bildet.

Als Grundlage für die Beschreibung der Interaktion zweier Entitäten sei das allgemeine Modell der Client-Server-Interaktion betrachtet, bei dem eine der Parteien (der Client) den Datenaustausch initiiert, indem sie eine Anfrage an die andere Partei (den Server) sendet. Der Server bearbeitet die Anfrage und sendet ggf. eine Antwort an den Client (Abb. 1.1).

Feige. 1.1.

Die Interaktion im Rahmen des Client-Server-Modells kann entweder synchron sein, wenn der Client darauf wartet, dass der Server seine Anfrage verarbeitet, oder asynchron, bei dem der Client eine Anfrage an den Server sendet und seine Ausführung fortsetzt, ohne auf die Server-Anfrage zu warten Antwort. Das Client- und Servermodell kann als Grundlage für die Beschreibung verschiedener Interaktionen verwendet werden. Für diesen Kurs ist das Zusammenspiel der Bestandteile der Software wichtig, die ein verteiltes System bildet.

Feige. 1.2.

Betrachten Sie eine bestimmte typische Anwendung, die nach modernen Konzepten in die folgenden logischen Ebenen unterteilt werden kann (Abb.1.2): Benutzeroberfläche(PI), Anwendungslogik (LP) und Datenzugriff (DD), Arbeiten mit der Datenbank (DB). Der Systembenutzer interagiert mit ihm über die Benutzeroberfläche, die Datenbank speichert Daten, die die Anwendungsdomäne beschreiben, und die Anwendungslogikschicht implementiert alle Algorithmen in Bezug auf Fachrichtung.

Da in der Praxis in der Regel verschiedene Benutzer des Systems daran interessiert sind, auf dieselben Daten zuzugreifen, wird die einfachste Trennung der Funktionen eines solchen Systems zwischen mehreren Computern die Trennung der logischen Schichten der Anwendung zwischen einem Serverteil der Anwendung sein Verantwortlich für den Zugriff auf Daten und die Client-Teile, die sich auf mehreren Computern befinden, Implementieren der Benutzeroberfläche. Die Anwendungslogik kann dem Server, den Clients zugewiesen oder zwischen ihnen geteilt werden (Abbildung 1.3).

Feige. 1.3.

Die Architektur von Anwendungen, die auf diesem Prinzip aufgebaut sind, wird Client-Server oder zweischichtig genannt. In der Praxis werden solche Systeme oft nicht als verteilt klassifiziert, können aber formal als einfachste Vertreter verteilter Systeme angesehen werden.

Die Entwicklung der Client-Server-Architektur ist eine dreischichtige Architektur, bei der Benutzeroberfläche, Anwendungslogik und Datenzugriff in unabhängige Komponenten des Systems aufgeteilt sind, die auf unabhängigen Computern arbeiten können (Abb. 1.4).

Feige. 1.4.

Die Anforderung des Benutzers wird in solchen Systemen sequentiell vom Client-Teil des Systems, dem Anwendungslogikserver und dem Datenbankserver verarbeitet. Unter einem verteilten System wird jedoch in der Regel ein System mit einer komplexeren Architektur verstanden als ein dreischichtiges.

Verteiltes AIS ist zur täglichen Realität geworden. Zahlreiche Unternehmens-AIS verwenden verteilte Datenbanken. Ausgearbeitet wurden Methoden der Datenverteilung und des Managements verteilter Daten, Architekturansätze, die die Skalierbarkeit von Systemen sicherstellen, die Umsetzung der Prinzipien der mehrschichtigen Client-Server-Architektur sowie die Architektur der Mittelschicht.

Mobile Architekturen werden in der Praxis eingesetzt. Dies gilt sowohl für Datenbanksysteme als auch für Webanwendungen.

Ein Ansatz zum Aufbau verteilter Systeme auf Basis einer Peer-to-Peer-Architektur wird wiederbelebt, bei dem im Gegensatz zur heute in verteilten Systemen dominierenden Client-Server-Architektur die Rollen der interagierenden Parteien im Netzwerk nicht festgelegt sind. Sie werden je nach Situation im Netzwerk, je nach Auslastung seiner Knoten zugewiesen.

Im Zusammenhang mit der intensiven Entwicklung von Kommunikationstechnologien entwickelt sich mobile AIS aktiv weiter. Die technischen Mittel und die Software für ihre Erstellung sind entwickelt. Dies hat zur Entwicklung mobiler Datenbanksysteme geführt. Viele Forschungsteams forschen an den spezifischen Eigenschaften solcher Systeme und erstellen ihre verschiedenen Prototypen. Java-Technologien sind zu einem wichtigen Werkzeug für die mobile Softwareentwicklung geworden.

Ein Wireless Application Protocol (WAP)-Standard wurde geschaffen und wird bereits von einigen Handymodellen unterstützt. Basierend auf WAP und XML hat das W3C eine Auszeichnungssprache für die drahtlose Kommunikation entwickelt, WML (Wireless Markup Language).

Bei der Entwicklung von AIS wurde den Metadaten mehr Aufmerksamkeit geschenkt. Dabei werden Schritte in zwei Richtungen unternommen - die Darstellung von Metadaten zu standardisieren und deren Unterstützung im System sicherzustellen.

AIS verwendet verschiedene Möglichkeiten und Mittel zur Präsentation von Metadaten (verschiedene Arten von Metadaten-Repositories). Die fehlende Vereinheitlichung in diesem Bereich erschwert die Lösung der Probleme der Anwendungsmobilität, der Wiederverwendung und Integration von Informationsressourcen und Informationstechnologien sowie des AIS-Reengineering erheblich.

Um diese Schwierigkeiten zu überwinden, wird die Entwicklung von Metadatenstandards mit Fokus auf verschiedene Informationstechnologien aktiv vorangetrieben. In diesem Bereich gibt es bereits eine Reihe von internationalen, nationalen und Industriestandards, die die Darstellung von Metadaten und den Austausch von Metadaten in AIS definieren. Einige von ihnen haben bereits den Status von De-facto-Standards erlangt. Wir beschränken uns hier darauf, nur die wichtigsten davon zu erwähnen.

Der wahrscheinlich erste De-facto-Standard in dieser Kategorie war die Datenbeschreibungssprache CODASYL für vernetzte Datenbanken. Spätere Standards umfassen: den Standard der SQL-Abfragesprache für relationale Datenbanken, der die Definition des sogenannten Informationsschemas enthält – ein Satz von Darstellungen relationaler Datenbankschemas; die ODMG-Objektdatenbank-Standardkomponente, die die Objektschema-Repository-Schnittstellen beschreibt; Internationaler Standard IRDS (Information Resource Dictionary Systems), der Systeme zum Erstellen und Verwalten von Verzeichnissen von Informationsressourcen einer Organisation beschreibt.

Als nächstes ist der vom OMG-Konsortium entwickelte CWM-Standard (Common Warehouse Metamodel) zur Darstellung von Data-Warehouse-Metadaten zu nennen, der auf dem zuvor erstellten OIM-Standard (Open Information Model) des MDC (Meta Data Coalition)-Konsortiums basiert.

Das neue XML für die Web-Technologieplattform enthält auch Standards für die Darstellung von Metadaten. Die Unterstützung von Metadaten ist eine der wichtigsten Neuerungen des Webs und verändert die Technologie zur Verwaltung seiner Informationsressourcen radikal. Während Metadatenunterstützung ursprünglich in Datenbanktechnologien erforderlich war, wurden Metadaten im Web der ersten Generation nicht unterstützt.

Web-Metadatenstandards enthalten eine Untermenge der XML-Sprache, die verwendet wird, um die logische Struktur eines XML-Dokumenttyps zu beschreiben. Diese Beschreibung wird als DTD (Document Type Definition) bezeichnet. Darüber hinaus enthält die XML-Plattform den XML-Schema-Standard, der erweiterte Funktionen zum Beschreiben von XML-Dokumenten bietet. Der Standard Resource Definition Framework (RDF) definiert eine einfache Wissensrepräsentationssprache zum Beschreiben des Inhalts von XML-Dokumenten. Schließlich definiert der aufkommende OWL-Standard (Ontology Web Language) eine formale Ontologie-Beschreibungssprache für das Semantic Web.

Der Standard Unified Modeling Language (UML), der Metadatendarstellung für visuelle CASE-Objektanalyse- und Designtools bereitstellt, wurde vom OMG-Konsortium entwickelt. Diese Sprache wird von vielen CASE-Softwareprodukten unterstützt. Die OMG hat auch den XML Metadata Interchange (XMI)-Standard für den Austausch von Metadaten zwischen CASE-Tools unter Verwendung der UML erstellt.

Erwähnenswert ist auch der Dublin Core (DC) Standard, ein Satz von Metadatenelementen zur Beschreibung des Inhalts von Dokumenten unterschiedlicher Art. Dieser Standard gewann schnell an Popularität und fand insbesondere im Web-Umfeld breite Anwendung (siehe Abschnitt 3.3).

Die Arbeit an der Entwicklung bestehender und Schaffung neuer Standards für die Präsentation von Metadaten für AIS wird fortgesetzt. Nähere Informationen zu den jeweiligen Standards finden Sie in der Enzyklopädie.

AggreGate ist eine der wenigen IoT-Plattformen weltweit, die eine verteilte Architektur wirklich unterstützt. Dies bietet unbegrenzte Skalierbarkeit, um alle AggreGate-Servervorgänge auf verschiedenen Ebenen auszugleichen und zu trennen. Eine solche Architektur kann die Grundlage sowohl für aktuelle Herausforderungen als auch für zukünftige Anforderungen sein.

Im Gegensatz zu einem Failover-Cluster sind AggreGate-Server in einer verteilten Architektur völlig unabhängig. Jeder Server verfügt über eine eigene Datenbank, lokale Benutzerkonten und zugehörige Berechtigungen.

Die verteilte Architektur von AggreGate ist äußerst flexibel. Technisch basiert es auf der Bildung von Peer-to-Peer-Verbindungen zwischen Servern und dem Anhängen von Teilen eines einzigen Datenmodells einiger Server ("Lieferanten") an andere ("Verbraucher").

Ziele des verteilten Betriebs

Die Hauptziele einer verteilten Architektur sind:

• Skalierbarkeit... Untergeordnete Server können stark belastet werden, sammeln Daten und verwalten eine große Anzahl von Geräten nahezu in Echtzeit. In der Praxis ist die Anzahl der Geräte, die von einem Server bedient werden können, jedoch auf mehrere Tausend begrenzt. Wenn Sie das System skalieren, um eine große Anzahl von Geräten zu verwalten, ist es ratsam, mehrere Server einzurichten und in einer verteilten Installation zu kombinieren.
• Lastverteilung... Jeder Server in einer verteilten Installation löst ein anderes Problem. Netzwerkmanagementserver prüfen die Verfügbarkeit und Leistung der Netzwerkinfrastruktur, während Zutrittskontrollserver Anfragen von Türcontrollern und Drehkreuzen verarbeiten. Kontrolloperationen wie das Erstellen von Berichten und das Versenden per Mail können auf einem zentralen Server durchgeführt werden.
• Einbruchschutz... Sekundäre Probe-Server können an entfernten Standorten installiert und mit einem zentralen Server verbunden werden. Systembetreiber verbinden sich nur mit dem zentralen Server, wodurch die Konfiguration von VPN und Portweiterleitung zu diesen Servern entfällt.
• Zentralisierung... Sekundärserver können im vollautomatischen Modus betrieben werden, während ihre Konfiguration und Überwachung über den Hauptserver erfolgt, der in der zentralen Leitwarte installiert ist.

Serverrollenverteilung

In diesem einfachen Szenario werden zwei Server zu einer verteilten Infrastruktur kombiniert. Systembetreiber sind ständig mit dem Überwachungsserver verbunden und erfüllen ihre täglichen Aufgaben. Das Management des Unternehmens verbindet sich mit dem Berichts- und Analyseserver, wenn es einen Datenausschnitt benötigt. Unabhängig von der Datenmenge und der Last auf dem Server hat dieser Vorgang keinen Einfluss auf die Arbeit der Bediener.

Große Cloud-IoT-Plattform

Telekommunikations- und Cloud-Dienstleister bieten IoT-Dienste in IaaS- / PaaS- / SaaS-Modellen an. In diesen Fällen sprechen wir von Millionen von Geräten, die Tausenden von Benutzern gehören. Um eine so riesige Infrastruktur aufrechtzuerhalten, sind Hunderte von AggreGate-Servern erforderlich, von denen die meisten in zwei Gruppen gruppiert werden können:

• Server, die das Register von Benutzern und ihren Geräten speichern, Verbindungen von Betreibern und Geräten zu Servern niedrigerer Ebene umleiten sowie Daten für die anschließende Analyse von Informationen unter Beteiligung von Servern niedrigerer Ebene aggregieren
• Server, die Geräte überwachen und verwalten sowie Daten empfangen, speichern und verarbeiten

Die Benutzer- und Geräteverwaltungsserver sind auch für die Interaktion mit dem Cloud-Verwaltungssystem verantwortlich, das für die Bereitstellung und Überwachung neuer Speicher- und Analyseserver verantwortlich ist.

Datenspeicher- und -verarbeitungsserver verwenden Ressourcen (Alarme, Modelle, Workflows, Dashboards usw.), die von Vorlagenservern empfangen werden, die wiederum Masterkopien dieser Ressourcen speichern.

Mehrschichtige IoT-Infrastruktur

Dank der verteilten Infrastruktur von AggreGate kann jede Lösung viele Server unterschiedlicher Ebenen umfassen. Einige von ihnen können an IoT-Gateways arbeiten und Daten sammeln, andere - um Informationen zu speichern und zu verarbeiten und der Rest - um Aggregation auf hoher Ebene und verteiltes Computing durchzuführen.

Feldgeräte wie Sensoren und Aktoren können direkt, über Agenten, über Gateways oder eine Kombination aus beidem mit Servern verbunden werden.

Intelligentes Stadtmanagement

Dies ist ein Beispiel für eine AggreGate-basierte Schichtarchitektur für die komplexe Automatisierung einer großen Gruppe von Gebäuden:

• Level 1: physische Ausrüstung (Netzwerkrouter, Controller, Industrieausrüstung usw.)
• Level 2: Managementserver (Netzwerküberwachungsserver, Zugangskontrollserver, Gebäudeautomatisierungsserver und andere)
• Stufe 3: Gebäude-Server-Kontrollzentren (ein Server pro Gebäude, der Informationen von allen Servern der zweiten Ebene sammelt)
• Level 4: Stadtbezirksserver (Endziel für die Eskalation von Warnungen auf niedrigerer Ebene, Echtzeitüberwachung, Integration mit Service Desk-Systemen)
• Level 5: Server der Zentrale (Kontrolle der Bezirksserver, Sammlung und Synthese von Berichten, Benachrichtigungen)

Jeder der oben genannten Server kann ein Failovercluster mit mehreren Knoten sein.

Multi-Segment-Netzwerkmanagement

AggreGate Network Manager basiert auf der AggreGate-Plattform und ist ein typischer Anwendungsfall für eine verteilte Architektur. Große segmentierte Netzwerke von Unternehmen und Telekommunikationsbetreibern können aufgrund von Routingbeschränkungen, Sicherheitsrichtlinien oder Bandbreitenbeschränkungen für Verbindungen zu entfernten Netzwerksegmenten nicht von einem einzigen Zentrum aus überwacht werden.

So besteht ein verteiltes Monitoring-System in der Regel aus folgenden Komponenten:

• Primär oder zentral ein Server, der Informationen aus allen Netzwerksegmenten sammelt
• Sekundär Server oder Probe-Server Abfragegeräte in isolierten Segmenten
• Spezialisiert Server wie Verkehrsanalyseserver, die täglich Milliarden von NetFlow-Ereignissen verarbeiten

Sekundäre und spezialisierte Server sind Informationslieferanten für den Primärserver und geben einen Teil ihres Datenmodells an das Kontrollzentrum weiter. Das kann sein:

• Alle Inhalte des Kontextbaums des Probe-Servers, der die vollständige Kontrolle der Konfiguration von einem zentralen Server aus ermöglicht. In diesem Fall wird der Probe-Server einfach als Proxy verwendet, um das Netzwerksegmentierungsproblem zu überwinden.
• Vom Probe-Server generierte Warnungen. In diesem Fall können 99% der Arbeitsplätze entfernt sein und der Betreiber des zentralen Servers erhält sofort Benachrichtigungen von den sekundären Servern.
• Benutzerdefinierte Datensätze von Probe-Servern, wie Echtzeit-Statusinformationen für kritische Geräte oder zusammengefasste Berichte. Alle damit verbundenen Arbeiten werden auf dem sekundären Server ausgeführt, wodurch ein Lastausgleich ermöglicht wird.

Hochleistungs-Eventmanagement

Einige Anwendungsfälle für die AggreGate-Plattform, wie z. B. das zentralisierte Vorfallmanagement, erfordern, dass eine erhebliche Anzahl von Ereignissen empfangen, verarbeitet und dauerhaft in einem strukturierten Format gespeichert wird. Manchmal können Streams ein Volumen von Millionen von Ereignissen pro Sekunde erreichen und von verschiedenen Quellen empfangen werden.

In solchen Fällen wird ein AggreGate-Server nicht den gesamten Ereignisfluss bewältigen. Eine verteilte Architektur hilft bei der Organisation der Ereignisbehandlung:

• Auf den ereigniserzeugenden Objekten sind mehrere lokale Server installiert, die diese Ereignisse verarbeiten. Mehrere Quellen (Probes) können sich mit einem Verarbeitungsserver verbinden.
• An jeden lokalen Verarbeitungsserver ist ein dedizierter Speicherserver oder ein Big-Data-Speichercluster mit mehreren Servern gebunden. Die Anzahl der Clusterknoten kann je nach der Rate variieren, mit der Ereignisse generiert werden.
• Alle lokalen Speicherserver führen Vorfilterung, Deduplizierung, Korrelation (unter Verwendung von Regeln für lokal angeschlossene Probes), Anreicherung und Ereignisspeicherung durch.
• Lokale Speicherserver verbinden sich mit einem zentralen Aggregationsserver. Der Aggregationsserver ist für die Korrelation wichtiger Ereignisse im gesamten System verantwortlich.
• Zentrale Serverbetreiber können die gesamte Ereignisdatenbank durchsuchen, während die Aufgaben zum Auffinden von Live-Daten auf die Speicherserver verteilt werden. Somit ist es möglich, zentralisierte Berichte und Warnungen basierend auf einer Datenbank für alle Ereignisse zu erstellen.

Digitales Unternehmen

AggreGate kann als koordinierende Plattform für das digitale Unternehmen fungieren. Jeder der AggreGate-Server kann verschiedene Funktionen ausführen, die von der Überwachung und Verwaltung von Remote-Objekten bis hin zu High-Level-Services wie Business Intelligence oder beispielsweise Incident Management reichen.

Alle Server in einem digitalen Unternehmen sind über eine verteilte Infrastruktur miteinander verbunden. Untergeordnete Server bieten den übergeordneten Servern Zugriff auf einige der Kontexte eines einzelnen Datenmodells, sodass Sie ein situatives Zentrum für das gesamte Unternehmen erstellen können.

Gegenwärtig haben alle für kommerzielle Zwecke entwickelten ICs eine verteilte Architektur, was die Verwendung globaler und/oder lokaler Netzwerke impliziert.

Historisch gesehen war die Fileserver-Architektur die erste, die sich durchgesetzt hat, da ihre Logik einfach ist und es am einfachsten ist, die bereits verwendeten ISs auf eine solche Architektur zu übertragen. Dann wurde es in eine Server-Client-Architektur umgewandelt, die als logische Fortsetzung interpretiert werden kann. Moderne Systeme, die im globalen Netzwerk INTERNET verwendet werden, beziehen sich hauptsächlich auf die Architektur verteilter Objekte (siehe Abb. III‑15 )

IS kann man sich bestehend aus folgenden Komponenten vorstellen (Abb. III-16)

III.03.2. a Dateiserveranwendungen.

Es ist historisch die erste verteilte Architektur (Abb. III-17). Es ist sehr einfach organisiert: Der Server enthält nur Daten und alles andere gehört zum Client-Rechner. Da lokale Netzwerke recht günstig sind und die Anwendungssoftware bei einer solchen Architektur autonom ist, wird eine solche Architektur heute häufig verwendet. Wir können sagen, dass dies eine Variante der Client-Server-Architektur ist, bei der sich nur Datendateien auf dem Server befinden. Verschiedene Personalcomputer interagieren nur mittels eines gemeinsamen Datenspeichers, so dass für einen Computer geschriebene Programme am einfachsten an eine solche Architektur angepasst werden können.

Vorteile:

Vorteile der Dateiserverarchitektur:

Einfache Organisation;

Widerspricht nicht den notwendigen Anforderungen an die Datenbank zur Aufrechterhaltung der Integrität und Zuverlässigkeit.

Netzüberlastung;

Unvorhersehbare Reaktion auf eine Anfrage.

Diese Nachteile werden dadurch erklärt, dass jede Anfrage an die Datenbank zur Übertragung erheblicher Informationsmengen über das Netzwerk führt. Um beispielsweise eine oder mehrere Zeilen aus Tabellen auszuwählen, wird die gesamte Tabelle auf den Client-Rechner heruntergeladen und das DBMS wählt dort bereits aus. Erheblicher Netzwerkverkehr ist insbesondere mit der Organisation des Fernzugriffs auf die Datenbank verbunden.

III.03.2. b Client-Server-Anwendungen.

In diesem Fall gibt es eine Verteilung der Verantwortlichkeiten zwischen dem Server und dem Client. Je nachdem, wie sie getrennt sind, unterscheiden Fett und Dünner Kunde.

Im Thin-Client-Modell erfolgt die gesamte Anwendungsarbeit und das Datenmanagement auf dem Server. Die Benutzerschnittstelle in diesen Systemen "migriert" zu einem Personalcomputer, und die Softwareanwendung selbst führt die Funktionen eines Servers aus, d.h. führt alle Anwendungsprozesse aus und verwaltet die Daten. Das Thin-Client-Modell kann auch dort implementiert werden, wo Clients Computer oder Workstations sind. Die Netzwerkgeräte führen den Internetbrowser und die im System implementierte Benutzeroberfläche aus.

Main Nachteil Thin-Client-Modelle - hohe Server- und Netzwerklast. Alle Berechnungen werden auf dem Server durchgeführt, was zu erheblichem Netzwerkverkehr zwischen Client und Server führen kann. In modernen Computern ist genügend Rechenleistung vorhanden, wird aber im Modell / Thin Client der Bank praktisch nicht genutzt

Im Gegensatz dazu nutzt das Thick-Client-Modell die Rechenleistung lokaler Maschinen: Die Anwendung selbst wird auf dem Client-Computer platziert. Ein Beispiel für diese Art von Architektur sind ATM-Systeme, bei denen der ATM der Client ist und der Server der zentrale Computer ist, der die Kundenkontendatenbank bedient.

III.03.2. c Zwei- und dreischichtige Client-Server-Architektur.

Alle oben diskutierten Architekturen sind zweistufig. Sie unterscheiden zwischen der Client-Ebene und der Server-Ebene. Genau genommen besteht der IC aus drei logischen Ebenen:

· Benutzerlevel;

Anwendungsebene:

· Datenschicht.

Daher gibt es in einem zweistufigen Modell, bei dem nur zwei Schichten beteiligt sind, Skalierbarkeits- und Leistungsprobleme, wenn das Thin-Client-Modell gewählt wird, oder Systemverwaltungsprobleme, wenn das Thick-Client-Modell gewählt wird. Diese Probleme können vermieden werden, wenn wir ein Modell anwenden, das aus drei Ebenen besteht, von denen zwei Server sind (Abb. III-21).

Datenserver

Tatsächlich können sich der Anwendungsserver und der Datenserver auf demselben Computer befinden, aber sie können nicht die Funktionen des anderen ausführen. Das Gute am dreistufigen Modell ist, dass es die Anwendungsausführung und das Datenmanagement logisch trennt.

Tabelle III-5 Anwendung verschiedener Architekturtypen

Die Architektur	Anwendung
Zweischichtiger Thin Client	1 Altsysteme, bei denen es nicht ratsam ist, Anwendungsausführung und Datenverwaltung zu trennen. 2 Computing-intensive Anwendungen mit wenig Datenmanagement. 3 Anwendungen mit großen Datenmengen, aber wenig Rechenaufwand.
Zweistufiger Dicker Client	1 Anwendungen, bei denen der Benutzer eine intensive Datenverarbeitung, d. h. Datenvisualisierung, benötigt. 2 Anwendungen mit einem relativ konstanten Satz von Benutzerfunktionen, die auf eine gut verwaltete Systemumgebung angewendet werden.
Dreistufiger Server-Client	1 Große Anwendungen mit Zellen und Tausenden von Clients 2 Anwendungen, bei denen sich sowohl Daten als auch Verarbeitungsmethoden häufig ändern. 3 Anwendungen, die Daten aus mehreren Quellen integrieren.

Dieses Modell eignet sich für viele Arten von Anwendungen, schränkt jedoch die IS-Entwickler ein, die entscheiden müssen, wo sie Dienste bereitstellen, Skalierbarkeit unterstützen und Tools entwickeln müssen, um neue Kunden zu verbinden.

III.03.2. d Verteilte Objektarchitektur.

Einen allgemeineren Ansatz bietet eine verteilte Objektarchitektur, deren Hauptkomponenten Objekte sind. Sie stellen über ihre Schnittstellen eine Reihe von Diensten bereit. Andere Objekte senden Anfragen, ohne zwischen Client und Server zu unterscheiden. Objekte können sich auf verschiedenen Computern im Netzwerk befinden und über Middleware interagieren, ähnlich dem Systembus, der es Ihnen ermöglicht, verschiedene Geräte zu verbinden und die Kommunikation zwischen Hardwaregeräten aufrechtzuerhalten.

…

ODBC-Treibermanager

Fahrer 1

Fahrer K

DB 1

DB K

Arbeiten mit SQL

…

Die ODBC-Architektur umfasst Komponenten:

1. Bewerbung (zB IS). Es führt Aufgaben aus: fordert eine Verbindung zur Datenquelle an, sendet SQL-Abfragen an die Datenquelle, beschreibt den Speicherbereich und das Format für SQL-Abfragen, behandelt Fehler und benachrichtigt den Benutzer darüber, schreibt Transaktionen fest oder rollt zurück, fordert eine Verbindung zum Datenquelle.

2. Geräte-Manager. Es lädt Treiber bei Bedarf von Anwendungen, bietet eine einzige Schnittstelle für alle Anwendungen, und die ODBC-Administratorschnittstelle ist dieselbe und unabhängig davon, mit welchem ​​DBMS die Anwendung interagiert. Der von Microsoft gelieferte Treiber-Manager ist eine dynamisch ladbare DLL.

3. Der Treiber ist vom DBMS abhängig. Ein ODBC-Treiber ist eine Dynamic Link Library (DLL), die ODBC-Funktionen implementiert und mit einer Datenquelle interagiert. Ein Treiber ist ein Programm, das eine Anforderung für eine DBMS-spezifische Funktion verarbeitet (es kann Anforderungen gemäß dem DBMS ändern) und das Ergebnis an die Anwendung zurückgibt. Jedes DBMS, das die ODBC-Technologie unterstützt, muss Anwendungsentwicklern einen Treiber für dieses DBMS bereitstellen.

4. Die Datenquelle enthält die vom Benutzer angegebenen Steuerinformationen, Informationen zur Datenquelle und wird verwendet, um auf ein bestimmtes DBMS zuzugreifen. In diesem Fall werden die Mittel des Betriebssystems und der Netzwerkplattform verwendet.

Dynamisches Modell

Dieses Modell geht von vielen Aspekten aus, die in der UML-Sprache mit mindestens 5 Diagrammen dargestellt werden, siehe S. 2.04.2- 2.04.5.

Betrachten wir den Aspekt des Managements. Das Governance-Modell ergänzt die Strukturmodelle.

Egal wie die Struktur des Systems beschrieben wird, es besteht aus einer Menge von Struktureinheiten (Funktionen oder Objekten). Damit sie als Ganzes funktionieren, müssen sie verwaltet werden, und in den statischen Diagrammen gibt es keine Kontrollinformationen. Steuerungsmodelle gestalten den Steuerungsfluss zwischen Systemen.

Es gibt zwei Hauptarten der Steuerung in Softwaresystemen.

1. Zentralisierte Verwaltung.

2. Ereignisbasiertes Management.

Zentralisierte Verwaltung kann sein:

· Hierarchisch- nach dem "Call-Return"-Prinzip (so funktionieren Bildungsprogramme am häufigsten)

· Disponentenmodell die für parallele Systeme verwendet wird.

IM Dispatcher-Modelle Es wird davon ausgegangen, dass eine der Komponenten des Systems ein Dispatcher ist. Es verwaltet sowohl das Hoch- und Herunterfahren von Systemen als auch die Koordination der restlichen Prozesse im System. Prozesse können parallel laufen. Ein Prozess bezieht sich auf ein Programm, ein Subsystem oder eine Prozedur, die derzeit ausgeführt werden. Dieses Modell kann auch in sequentiellen Systemen angewendet werden, bei denen das Steuerungsprogramm in Abhängigkeit von einigen Zustandsvariablen (über den Operator Fall).

Veranstaltungsmanagement geht davon aus, dass keine Unterroutine vorhanden ist, die für die Verwaltung zuständig ist. Die Steuerung erfolgt durch externe Ereignisse: Drücken einer Maustaste, Drücken einer Tastatur, Ändern von Sensorwerten, Ändern von Timer-Messwerten usw. Jedes externe Ereignis wird codiert und in die Ereigniswarteschlange gestellt. Ist eine Reaktion auf ein Ereignis in der Warteschlange vorgesehen, wird die Prozedur (Unterprogramm) aufgerufen, die die Reaktion auf dieses Ereignis durchführt. Die Ereignisse, auf die das System reagiert, können entweder in anderen Subsystemen oder in der externen Umgebung des Systems auftreten.

Ein Beispiel für eine solche Verwaltung ist die Organisation von Anwendungen in Windows.

Alle zuvor beschriebenen Strukturmodelle können über eine zentrale Verwaltung oder eine ereignisbasierte Verwaltung implementiert werden.

Benutzeroberfläche

Bei der Entwicklung eines Schnittstellenmodells sollte man nicht nur die Aufgaben der entworfenen Software berücksichtigen, sondern auch die mit der Informationswahrnehmung verbundenen Eigenschaften des Gehirns.

III.03.4. a Psychophysische Merkmale einer Person im Zusammenhang mit der Wahrnehmung und Verarbeitung von Informationen.

Der Teil des Gehirns, der konventionell als Wahrnehmungsprozessor bezeichnet werden kann, verarbeitet ständig ohne Beteiligung des Bewusstseins eingehende Informationen, vergleicht sie mit früheren Erfahrungen und speichert sie.

Wenn ein visuelles Bild unsere Aufmerksamkeit auf sich zieht, gelangen die für uns interessanten Informationen ins Kurzzeitgedächtnis. Wenn unsere Aufmerksamkeit nicht erregt wurde, verschwinden die Informationen im Speicher und werden durch die folgenden Teile ersetzt.

Der Fokus der Aufmerksamkeit kann zu jedem Zeitpunkt auf einen Punkt fixiert werden. Wenn also mehrere Situationen gleichzeitig verfolgt werden müssen, verschiebt sich der Fokus von einem verfolgten Objekt zum anderen. Gleichzeitig wird die Aufmerksamkeit gestreut und einige Details können übersehen werden. Bemerkenswert ist auch, dass die Wahrnehmung weitgehend auf Motivation beruht.

Beim Wechseln eines Bildes ist das Gehirn für eine Weile blockiert: Es meistert ein neues Bild und hebt die wichtigsten Details hervor. Das heißt, wenn Sie eine schnelle Antwort vom Benutzer benötigen, sollten Sie die Bilder nicht abrupt ändern.

Das Kurzzeitgedächtnis ist der Flaschenhals im Informationsverarbeitungssystem einer Person. Seine Kapazität beträgt 7 ± 2 nicht verbundene Objekte. Nicht beanspruchte Informationen werden darin nicht länger als 30 Sekunden gespeichert. Um keine für uns wichtigen Informationen zu vergessen, wiederholen wir sie in der Regel für uns selbst und aktualisieren die Informationen im Kurzzeitgedächtnis. So ist bei der Gestaltung von Oberflächen zu berücksichtigen, dass es für die allermeisten zum Beispiel schwierig ist, sich Zahlen mit mehr als fünf Ziffern zu merken und auf einem anderen Bildschirm einzugeben.

Obwohl die Kapazität und Speicherdauer des Langzeitgedächtnisses unbegrenzt ist, ist der Zugang zu Informationen nicht einfach. Der Mechanismus zum Extrahieren von Informationen aus dem Langzeitgedächtnis ist assoziativer Natur. Um die Speicherung von Informationen zu verbessern, werden sie an die Daten gebunden, die der Speicher bereits speichert, und macht sie leicht zu erhalten. Da der Zugriff auf das Langzeitgedächtnis schwierig ist, ist es ratsam, vom Benutzer nicht zu erwarten, dass er sich an die Informationen erinnert, sondern dass der Benutzer sie erkennt.

III.03.4. b Grundkriterien für die Bewertung von Schnittstellen

Zahlreiche Umfragen und Umfragen führender Software-Entwicklungsfirmen haben gezeigt, dass Benutzer Wert auf eine Oberfläche legen:

1) Leichtigkeit des Masterings und des Auswendiglernens - schätzen Sie insbesondere die Zeit des Masterings und die Dauer der Bewahrung von Informationen und Gedächtnis;

2) die Geschwindigkeit, mit der Ergebnisse bei der Verwendung des Systems erzielt werden, die durch die Anzahl der Befehle und Einstellungen bestimmt wird, die mit der Maus eingegeben oder ausgewählt werden;

3) subjektive Zufriedenheit mit dem Betrieb des Systems (Benutzerfreundlichkeit, Ermüdung usw.).

Darüber hinaus stehen für professionelle Benutzer, die ständig mit demselben Paket arbeiten, das zweite und dritte Kriterium schnell an erster Stelle, und für nicht professionelle Benutzer, die regelmäßig mit Software arbeiten und relativ einfache Aufgaben ausführen - das erste und dritte.

Unter diesem Gesichtspunkt haben Schnittstellen mit freier Navigation heute die besten Eigenschaften für professionelle Anwender und direkte Manipulationsschnittstellen für nicht-professionelle Anwender. Es ist seit langem aufgefallen, dass die meisten Profis beim Kopieren von Dateien unter sonst gleichen Bedingungen Shells wie Far verwenden, während Nicht-Profis Windows Drag & Drop verwenden.

III.03.4. c Arten von Benutzeroberflächen

Es werden folgende Arten von Benutzeroberflächen unterschieden:

Primitive

Kostenlose Navigation

Direkte Manipulation.

Die Schnittstelle ist primitiv

Primitive wird die Schnittstelle genannt, die die Interaktion mit dem Benutzer organisiert und im Konsolenmodus verwendet wird. Die einzige Abweichung vom sequentiellen Prozess, den die Daten bieten, ist das Durchlaufen mehrerer Datensätze.

Menüoberfläche.

Im Gegensatz zur primitiven Schnittstelle ermöglicht es dem Benutzer, eine Operation aus einer speziellen Liste auszuwählen, die vom Programm angezeigt wird. Diese Schnittstellen beinhalten die Umsetzung vieler Arbeitsszenarien, deren Aktionsfolge von den Benutzern bestimmt wird. Die baumartige Anordnung der Menüs lässt vermuten, dass es schwierig ist, einen Eintrag in mehr als zweistufigen Menüs zu finden.