Einleitung

Ignition ist ein Entwicklungs-Toolkit mit einem unbegrenzten Lizenzmodell und verschiedenen Modulen, es ermöglicht Ihnen Lösungen umzusetzen. Ein Ignition-Projekt kann so klein sein wie ein Datensammler für wenige Tags oder so groß wie eine Unternehmenslösung mit Hunderten von Geräten, Hunderttausenden von Tags und Hunderten von Visualisierungsclients. Es ist äußerst wichtig, die richtige Architektur und die richtige Dimensionierung der Server für Ihr Ignition-Projekt zu finden, damit das Projekt wie beabsichtigt funktioniert und Raum für zukünftiges Wachstum hat.

Die Leistung und Dimensionierung von Ignition basiert auf verschiedenen Faktoren:

• Anzahl der Geräteanschlüsse
• Arten von PLCs (Treiber)
• Anzahl der Datenpunkte (Tags)
• Häufigkeit der Tagabfrage (1 Sekunde, 5 Sekunden, 1 Minute, usw.)
• Anzahl der Tag-Wertänderungen pro Sekunde (% der Änderung)
• Anzahl der gleichzeitigen Visualisierungsclients
• SQL-Datenbankdurchsatz (Historian, Alarmjournal usw.)
• Bereitstellung (physische Maschine, VM usw.)
• Netzwerk und Latenzzeit
• Und mehr…

Die Funktionen, die Sie in Ignition verwenden, spielen ebenfalls eine große Rolle für die Leistung. Funktionen wie die folgenden benötigen Verarbeitungszeit und Speicher:

• Gerätekommunikation
• OPC-UA (Client und Server)
• Tags (OPC, Expression, SQL-Abfrage, usw.)
• Historian (Speicherung und Abruf)
• Alarmierung (Status, Journal, Benachrichtigungspipelines)
• Transaktionsgruppen (insbesondere bei großen Zahlen)
• Geplante PDF-Berichte (Reports)
• Ablaufdiagramme (SFC)
• Skripterstellung
• Skripte für Tag-Änderungen
• Skripte, die auf dem Server laufen (Timer, Message Handler, etc.)
• Visualisierungs-Clients
• Anzahl der Tag-Abonnements auf einem Bildschirm
• Polling-Abfragen (Tag-Historian, Alarmierung, benutzerdefinierte Abfragen, usw.)
• Anzahl der Gateway-Anfragen
• Gateway-Netzwerk (remote Dienste, EAM)
• MES-Funktionalität
• MQTT oder Cloud-Injektion
• Und mehr…

Ignition ist stark multithreading-fähig und kann Konfigurationen mit allen oben genannten Funktionen in effizient verarbeiten. Einige der oben genannten Funktionen, wie z.B. die Gerätekommunikation und Tags, benötigen eine vorhersehbare Leistung. Andere Funktionen, wie z.B. Visualisierungsclients, haben einen weniger vorhersehbaren Leistungsbedarf. Sie basieren darauf, wie der Benutzer mit dem System interagiert und wie das Projekt konfiguriert ist. So können wir beispielsweise einem Benutzer erlauben, ein Jahr historischer Daten zu einem Trend abzurufen und diese im Sekundentakt abzufragen. Es kann sein, dass dieser Bildschirm stunden- oder tagelang von niemandem genutzt wird, aber dann kann es vorkommen, dass 10 Personen gleichzeitig darauf zugreifen, was zu einer erhöhten Belastung des Servers führt. In den meisten Fällen reicht ein einziger Server aus, um alles zu bewältigen. Wenn die Projekte jedoch größer werden oder wir an die Grenzen von Ignition stoßen, müssen wir mehrere Server verwenden. Glücklicherweise ist Ignition modular aufgebaut und kann durch Aufteilung verschiedener Module und Funktionen auf dedizierte Server erweitert werden. Letztendlich arbeiten diese separaten Server als eine Ignition-Einheit und sind für den Benutzer völlig transparent, dank des Gateway-Netzwerks von Ignition und Standards wie OPC-UA, SQL, MQTT und mehr.

Der Zweck dieses Leitfadens ist es, Sie durch Projekte unterschiedlicher Größe zu führen, um deren Hardwareanforderungen und Architektur zu verstehen. Da Ignition über viele verschiedene Funktionen verfügt, wird sich dieser Leitfaden auf die Anzahl der Geräte, Tags und Clients konzentrieren.

SQL-Datenbank

Die SQL-Datenbank (MySQL, Microsoft SQL-Server usw.) sollte in allen unten genannten Szenarien auf einem eigenen Server liegen. Wenn Sie die Datenbank und Ignition auf demselben Server installieren möchten, benötigen Sie mehr Rechenleistung und Speicher. Im Folgenden finden Sie einige grundlegende Tipps zur Dimensionierung von Datenbanken:

Kleiner Historian

2 Kerne (2 GHz+), 2 GB Speicher, SSD

• 0-100 Wertänderungen pro Sekunde
• Benötigt ca. 300 GB Festplattenspeicher/Jahr, wenn sich 100 % der Werte dauerhaft jede Sekunde ändern (ca. 6 GB bei 2 %-igen Änderungen, kleiner bei langsameren Raten)

2 Kerne (2 GHz+), 4 GB Arbeitsspeicher, SSD

• 100 – 500 Wertänderungen pro Sekunde
• Benötigt ca. 3 TB Festplattenspeicher/Jahr, wenn sich 100 % der Werte dauerhaft jede Sekunde ändern (ca. 60 GB bei einer Änderung von 2 %, bei langsameren Raten weniger)

Mittlerer Historian

4 Kerne (4 GHz+), 8 GB Speicher, SSD

• 500 – 2.500 Wertänderungen pro Sekunde
• Benötigt ca. 7 TB Festplattenspeicher/Jahr, wenn sich 100 % der Werte dauerhaft jede Sekunde ändern (ca. 150 GB bei einer Änderung von 2 %, bei langsameren Raten weniger)

4 Kerne (4 GHz+), 16 GB Speicher, SSD

• 500 – 5.000 Wertänderungen pro Sekunde
• Benötigt ca. 15 TB Festplattenspeicher/Jahr, wenn sich 100 % der Werte dauerhaft jede Sekunde ändern (ca. 300 GB bei 2 % Änderung, bei langsameren Raten kleiner)

Großer Historian

8 Kerne (4 GHz+), 16 GB Speicher, SSD

• 5000 – 10.000 Wertänderungen pro Sekunde
• Benötigt ca. 30 TB/Jahr, wenn sich 100 % der Werte dauerhaft jede Sekunde ändern (ca. 60 GB bei einer Änderungsrate von 2 %, bei langsameren Raten weniger)

Hinweis: Einige Datenbanken auf einem ordnungsgemäß eingestellten Server erreichen ihr Limit bei 10.000 Wertänderungen pro Sekunde. Bei MySQL beispielsweise ist bei 10.000 Wertänderungen pro Sekunde limitiert, so dass es ratsam ist, unter 5.000 zu bleiben. Microsoft SQL-Server kann in der neuesten Version bis zu 20.000-30.000 Wertänderungen pro Sekunde verarbeiten. Der Durchsatz und die Abfragegeschwindigkeit hängen jedoch von der Hardware und der Konfiguration der Datenbank ab. Die Geschwindigkeit des Datenabrufs in Ignition kann auch durch einen höheren Speicherdurchsatz beeinträchtigt werden. Sie können einen höheren Durchsatz erreichen, indem Sie eine weitere Ignition-Instanz auf demselben Server wie die Datenbank installieren und die Ignition-Funktion „Remote Tag History“ über das Gateway-Netzwerk verwenden. Dadurch wird vermieden, dass eine große Menge an Rohdaten (SQL-Inserts) über das Netzwerk gesendet wird, und stattdessen werden komprimierte Daten über das Netzwerk gesendet, was letztendlich zu denselben Inserts führt, die jedoch lokal ausgeführt werden.

Ignition-Speicher

Die Grösse des zugewiesenen Speichers, welcher in der Konfigurationsdatei ignition.conf zugewiesen wird, kann angepasst werden. Es ist wichtig die richtige Menge an Speicher für jedes der unten aufgeführten Szenarien einzustellen. In der Regel genügen 1-2 GB Arbeitsspeicher für das  Betriebssystem, den Rest kann für Ignition verwendet werden. In unserer Dokumentation finden Sie weitere Einzelheiten zur Einstellung des Speichers von Ignition: https://docs.inductiveautomation.com/display/DOC81/Gateway+Configuration+File+Reference#GatewayConfigurationFileReference-GatewayMemoryAllocation

Standard Architektur (Single Server)

Die gebräuchlichste Architektur von Ignition besteht aus einem einzigen Ignition-Server vor Ort, der mit einer SQL-Datenbank, SPSen und Clients verbunden ist. In diesem Fall wird die gesamte Funktionalität auf demselben Ignition-Server konfiguriert. Die Lizenzierung von Ignition ist unbegrenzt. Allerdings ist Ignition durch die Leistungsfähigkeit der Hardware begrenzt. Bei performanterer Hardware kann Ignition mehr Geräteverbindungen, Tags und Clients verarbeiten.

Kleines Ignition-Projekt

Perfekt für Edge Panel, Edge IIoT, HMI, kleine SCADA, Datenerfassung, Alarmierung.

ARM, 1GB Speicher, SSD

• 1-2 Geräte
• 500 Tags
• 2 gleichzeitige Clients †

2 Kerne (2 GHz+), 2GB Speicher, SSD

• 1-10 Geräte
• 2’500 Tags
• 5 gleichzeitige Clients †

2 Kerne (3 GHz+), 4 GB Arbeitsspeicher, SSD

• 1-10 Geräte
• 5’000 Markierungen
• 10 gleichzeitige Clients †

Mittelgroßes Ignition-Projekt

Mittlere vollständige SCADA-Systeme oder MES-Systeme.

4 Kerne (3 GHz+), 4GB Speicher, SSD

• 1-25 Geräte
• 10’000 Tags
• 20 gleichzeitige Clients †

4 Kerne (4 GHz+), 8 GB Arbeitsspeicher, SSD

• 1-50 Geräte
• 25’000 Tags (max. 40% Tag-Verlaufsänderung)
• 25 gleichzeitige Clients †

4 Kerne (4 GHz+), 16GB Speicher, SSD

• 1-100 Geräte
• 50’000 Tags (max. 20% Tag-Verlaufsänderung)
• 50 gleichzeitige Clients †

Großes Ignition-Projekt

Große vollständige SCADA-Systeme oder MES-Systeme.

8 Kerne (4 GHz+), 8GB Speicher, SSD

• 1-100 Geräte
• 000 Tags (max. 10% Tag-Verlaufsänderung)
• 50 gleichzeitige Clients †

8 Kerne (4 GHz+), 16GB Speicher, SSD

• 1-100 Geräte
• 100’000 Tags (max. 10% Tag-Verlaufsänderung)
• 75 gleichzeitige Clients †

16 Kerne (4 GHz+), 32GB Speicher, SSD

• 1-100 Geräte
• 150’000 Tags (max. 6% Tag-Verlaufsänderung)
• 100 gleichzeitige Clients †

† Die Ergebnisse können je nach Designauswahl variieren. Die Beispiele basieren auf einer typischen Nutzung. Schnellere Abfrageraten, häufigere Wertänderungen und die Verwendung anderer Ignition-Funktionen wie Skripte, Transaktionsgruppen, SFCs usw. können die Gesamtleistung erheblich beeinträchtigen.

Scale-Out-Architektur

In größeren Systemen ist es oft einfacher, mehrere Ignition-Installationen zu haben, um die Last zwischen Front- und Backend-Aufgaben zu verteilen. Dies ist ideal für einzelne große Systeme, die nicht in verschiedene Standorte aufgeteilt sind. In Fällen, in denen Systeme in verschiedene Standorte aufgeteilt sind, ist die Hub-and-Spoke-Architektur in der Regel besser geeignet.

In der Scale-Out-Architektur gibt es mindestens ein Gateway, welches die Backend-Kommunikation übernimmt. Das Backend-Gateway ist für die gesamte SPS- und Gerätekommunikation zuständig. Das Frontend-Gateway verwaltet alle Clients und stellt die vom Backend-Gateway abgerufenen Daten bereit. Ermöglicht wird dies durch das Gateway-Netzwerk, das die Gateways miteinander verbindet und die gemeinsame Nutzung von Tags durch Remote-Tag-Anbieter ermöglicht.

Gateway-Netzwerk

Das Gateway-Netzwerk ermöglicht es Ihnen, mehrere Gateways über ein LAN (LocalAreaNetwork) oder WAN (WideAreaNetwork) miteinander zu verbinden, und eröffnet viele verteilte Funktionen zwischen Gateways.

Das Gateway-Netzwerk bietet die folgenden Funktionen:

• Einen dedizierten HTTP-Datenkanal, der mehrere Nachrichtenströme verarbeiten kann.
• Die Möglichkeit, einen Knoten so einzurichten, dass er als Proxy für einen anderen Knoten fungiert.
• Sicherheitseinstellungen, die eingehende Verbindungen auf der Grundlage einer Whitelist oder der manuellen Genehmigung der Verbindung einschränken. Eingehende Verbindungen können auch vollständig deaktiviert werden.
• Ein verfügbarer SSL-Modus. Wenn dieser Modus aktiviert ist, müssen Verbindungen SSL-Zertifikate senden, um ihre Identität nachzuweisen. Eine Verbindung wird erst dann angenommen, wenn ihr SSL-Zertifikat genehmigt wurde. Optional können sowohl Client-Zertifikate als auch Server-Zertifikate als erforderlich konfiguriert werden.

Funktionen des Gateway-Netzwerks

Das Gateway-Netzwerk stellt bestimmte Dienste zur Verfügung, die die Verwaltung mehrerer Gateways und die effektive Kommunikation mit jedem der Gateways erleichtern. Außerdem verfügt es über spezielle Sicherheitsfunktionen, die die Nutzung bestimmter Dienste in bestimmten Zonen des Gateway-Netzwerks einschränken können.

Enterprise Administration Modul

Das Enterprise Administration Module (EAM) nutzt das Gateway-Netzwerk für den Nachrichten- und Dateitransfer und kann Netzwerkverbindungen auf ihre Verfügbarkeit hin überwachen. Das EAM meldet über Alarmereignisse und System-Tags, wenn die Kommunikation unterbrochen ist.

Verteilte Dienste

Zu den verteilten Diensten gehört folgendes:

• Remote Realtime Tag Providers: Bietet die Möglichkeit, Tags von einem entfernten Ignition-Server zu lesen/schreiben. Ideal für Frontend-Server, welche die Tags im Backend sehen müssen. Dazu gehören das Lesen und Schreiben von Tags, das anzeigen von Alarmen und sogar die Abfrage historischer Daten.
• Remote Historical Tag Providers: Bietet die Möglichkeit, historische Daten an einen anderen Ignition-Server zu senden um diese in einer SQL-Datenbank zu speichern. Ermöglicht auch die Remoteabfrage historischer Daten, wenn keine Verbindung zur SQL-Datenbank verfügbar ist.
• Remote Alarmierung: Bietet die Möglichkeit, Alarmbenachrichtigungen an einen anderen Ignition-Server zu senden. Ideal, wenn E-Mail, Sprache oder SMS nur auf einem zentralen Ignition-Server verfügbar sind.
• Remote-Alarmjournal: Bietet die Möglichkeit, den Alarmverlauf an einen anderen Ignition-Server zur Speicherung in einer SQL-Datenbank zu senden.
• Remote Audit-Protokolle: Bietet die Möglichkeit, Audit-Protokolle an einen anderen Ignition-Server zur Speicherung in einer SQL-Datenbank zu senden.

Sicherheitszonen und Servicesicherheit

Sicherheitszonen können eingerichtet werden, um den Zugang zu bestimmten Teilen der Gateways innerhalb des Gateway-Netzwerks zu sperren oder zu verhindern. Sie können die Sicherheit auf Dienstebene auf jedem System konfigurieren, um festzulegen, was von entfernten Ignition-Servern aus erlaubt ist.

Ein I/O / ein Frontend

Bei dieser Architektur gibt es einen Ignition-Server, der mit den SPS kommuniziert und Backend-Aufgaben wie die Abfrage von Live-Werten, Historien und Alarmen durchführt. Der Backend-Server ist auch für die Protokollierung der Daten in der SQL-Datenbank zuständig. Der Frontend-Server verwaltet alle Visualisierungsclients (Vision und Perspective) und sollte auch mit der SQL-Datenbank kommunizieren, um historische Daten abzufragen.

Mit dieser Architektur können Sie mehr Geräteverbindungen, Tags und Clients verwalten, da Sie zwei Server haben. Mit zunehmender Projektgröße können Sie problemlos auf mehrere I/O-Server und Frontend-Server erweitern, was eine einfache Skalierbarkeit ermöglicht.

Ein OPC-UA Server / ein I/O / ein Frontend

Mit dieser Architektur wurde ein dedizierter OPC-UA Server eingeführt, der die gesamte SPS-Kommunikation übernimmt. Im Wesentlichen wird OPC-UA von einem einzigen Server getrennt. Mit dieser Architektur kann man eine größere Anzahl von Geräten verwalten. Der I/O-Server verarbeitet lediglich die Tag-Wertänderungen. Mit zusätzlichen OPC-UA-Servern für verschiedene SPS-Sets können Sie problemlos eine größere Anzahl von Tags in Bezug auf die Historie und Alarmierung verwalten.

Zwei I/O / ein Frontend

Bei dieser Architektur haben Sie zwei Ignition-Server, die mit verschiedenen SPS-Sets kommunizieren, was die Kommunikation mit einer größeren Anzahl von Geräten und Tags ermöglicht. So ist es zum Beispiel möglich, etwa 250.000 Tags von 200 Geräten zu verarbeiten. Bei Bedarf können Sie problemlos weitere I/O-Server hinzufügen.

Best Practice für Tag Provider

Bei der Scale-Out-Architektur ist es wichtig, dass Sie Ihren Tag-Providern die richtigen Namen geben, und die Namen sollten im I/O und im Frontend konsistent sein. Sie sollten nicht den Standardprovider verwenden, der in einer Standardinstallation enthalten ist. Es ist üblich, auf dem I/O-Server einen neuen Echtzeit-Tag-Anbieter mit einem Namen zu erstellen, der diesen I/O-Server beschreibt und sich von anderen I/O-Servern unterscheidet. Auf dem Frontend-Server sollten Sie einen Remote-Tag-Provider mit demselben Namen wie der I/O-Server anlegen, damit beide konsistent sind.

Tag-Pfade

Es wird empfohlen, in Ihren Projekten vollqualifizierte Tag-Pfade zu verwenden, insbesondere bei Visualisierungsvorlagen und Bildschirmen. Anhand eines vollqualifizierten Pfads kann Ignition genau erkennen, wo sich der Tag befindet, einschließlich des Tag-Anbieternamens.

Ein nicht vollständig qualifizierter Tag-Pfad sieht zum Beispiel wie folgt aus:

Pfad/zu/meinem/tag

Bei diesem Pfad wissen Sie nicht, von welchem Tag-Anbieter das Tag stammt. Ein Ignition-Projekt verwendet den Standard-Tag-Provider des Projekts, der nur ein Provider ist.

Ein vollqualifizierter Tag-Pfad sieht wie folgt aus:

[TagProviderName]Pfad/zu/meinem/tag

Beachten Sie, dass der Pfad den Tag-Anbieter enthält. Sie können in einer Visualisierungsvorlage problemlos einen Parameter angeben, der den Tag-Anbieter und den Tag-Pfad ändern kann, so dass wir auf ein beliebiges Tag von einem beliebigen Anbieter verweisen können.

Vollständiges Scale-Out mit Load Balancer

Das Beste an der Scale-Out-Architektur ist, dass sich Ignition leicht skalieren lässt, wenn Ihr System wächst. In der obigen Abbildung wurden weitere Frontend-Gateways hinzugefügt, um die steigende Anzahl von Clients zu bewältigen, und ein Load Balancer, um die Clients automatisch zwischen ihnen zu verteilen. Bei der Verwendung eines Load Balancers ist es wichtig, „sticky“ Sessions zu aktivieren, um sicherzustellen, dass die Verbindung mindestens eine Stunde lang konstant bleibt. Der Frontend-Server muss völlig zustandslos sein. Er erhält seine Daten von den I/O-Servern und der SQL-Datenbank. Mit dieser Architektur und einer angemessenen Anzahl von Frontend-Servern können Sie Tausende von gleichzeitigen Clients sowie eine große Anzahl von Geräten und Tags verarbeiten.

Beispiele für Load Balancer:

• F5 LoadBalancer
• HAProxy
• AWS / Azure LB

Wertänderungen sind der Schlüssel

Wenn es um Tags geht, sind Wertänderungen die wichtigste Metrik, die es zu beachten gilt. Dies ist definiert als eine Wertänderung, die über dem konfigurierten Deadband liegt. Deadbands können absolut oder prozentual sein. Ein Beispiel: Sie haben einen analogen Wert mit einer Deadband von 0,1. Eine Änderung von 7,89 auf 7,88 würde nicht als Änderung angesehen werden. Eine Änderung von 7,89 auf 7,9 würde jedoch als Änderung gelten. Normalerweise wird jede Änderung mit diskreten Werten als Änderung betrachtet, da es sich um einen Zustand handelt. Deadbands sind pro Tag konfigurierbar.

Der Grund, warum Wertänderungen so wichtig sind, liegt in der Tatsache, dass wir die Wertänderung für Alarme, den Historian usw. verarbeiten müssen. Diese Verarbeitung erfordert Speicher und Rechenzeit. Je mehr Tags sich pro Sekunde ändern, desto höher ist der Verarbeitungsaufwand. Ein Ignition-Server der oberen Leistungsklasse kann etwa 50.000 Wertänderungen pro Sekunde verarbeiten, und zwar durch das Tag-System, die Alarmierung, den Historian und die Clients. Wie bereits erwähnt, haben einige SQL-Datenbanken jedoch eine Grenze von 10.000 Wertänderungen pro Sekunde auf einer dedizierten Instanz. Ihre Aufgabe ist es also, die Anzahl der Wertänderungen pro Sekunde zu reduzieren. Ignition kann durch Optimierung und Reduzierung der Wertänderungen mehr Geräte, Tags und Clients verarbeiten.

Schauen wir uns einige verschiedene Szenarien an, die helfen zu verstehen, was ein Server bewältigen kann. Jedes Szenario steht für eine Anzahl von Tags, welche die Leistung eines Servers ausreizen.

• 10’000 Tags bei einer Rate von 1 Sekunde und 100 % Änderung = 10’000 Werte/Sek.
• 50’000 Tags bei einer Rate von 5 Sekunden und einer Änderungsrate von 100 % = 10’000 Werte/Sek.
• 100’000 Tags bei einer Rate von 1 Sekunde und einer Änderungsrate von 10 % = 10’000 Werte/Sek.
• 500’000 Tags bei einer Rate von 5 Sekunden und einer Änderung von 10 % = 10’000 Werte/Sek.
• 500 Geräte mit je 100 Tags = 50.000 Tags bei einer Rate von 5 Sekunden und einer Änderungsrate von 100% = 10’000 Werte/Sek.

Wie Sie sehen, können durch Optimierung der Abfrageraten und Deadband mehr Tags verarbeitet werden. Es ist möglich, eine grössere Anzahl von Geräteverbindungen und Tags durch Optimierung zu erreichen.

Optimierungen

Sie können Ihr System optimieren, indem Sie genau auf die Anzahl der Wertänderungen pro Sekunde achten. Je besser Sie das System optimieren, desto mehr können Sie bewältigen und desto besser ist die Leistung. Hier sind einige Dinge zu beachten:

Abfrageraten

Tag-Gruppen (oder Scan-Klassen) bestimmen, wie oft Ignition Daten von SPSen abruft. Stellen Sie sicher, dass Sie die richtigen Abfrageraten verwenden. Nicht alles muss mit einer Rate von 1 Sekunde erfolgen. Einige Werte können langsamer abgefragt werden als andere, da sie sich nicht sehr oft ändern. Versuchen Sie, alle möglichen Abfrageraten zu ermitteln, die Sie benötigen. So kann es beispielsweise sein, dass Sie eine Reihe von Tags mit einer Abfragerate von 1 Sekunde für die Alarmierung oder den Verlauf benötigen, während der Rest der Tags in Intervallen von 5 Sekunden oder Minuten abgefragt werden kann.

Deadbands

Deadbands protokollieren weniger Datenpunkte, insbesondere wenn die Wertänderungen zu gering sind, um signifikant zu sein. Sie sind besonders nützlich bei Prozessen, welche Werte mit hoher Frequenz prüfen, vor allem aber die Erfassung von Wertänderungen relevant sind, die einen bestimmten Betrag oder Prozentsatz überschreiten. Deadbands können entweder absolut oder prozentual sein. Absolute Deadbands basieren auf einer absoluten Änderung des Wertes, während prozentuale Deadbands bedeuten, dass sich der Wert um einen bestimmten Prozentsatz ändern muss. Außerdem gibt es zwei Deadband-Modi: digital und analog. Digitales Deadband wird gespeichert, wenn ein neuer Wert um +/- den Deadbandwert vom zuvor gespeicherten Wert abweicht. Die Werte des analogen Modus werden mit einem modifizierten „Sliding Window“-Algorithmus ausgewertet, der versucht, die geringste Anzahl von Punkten zu protokollieren, die zum korrekten Zeichnen eines Graphen erforderlich ist.

Sowohl für Echtzeit- als auch für historische Werte gibt es Deadbands auf Tags. Echtzeit-Deadband bedeuten, dass Ignition den neuen Wert überhaupt nicht verarbeitet, es sei denn, er ändert sich entsprechend der Konfiguration. Historische Deadbands gelten danach und legen fest, wann ein Wert in den Historian aufgenommen wird. Auf diese Weise können auf Echtzeitbildschirmen detailliertere Daten angezeigt, aber weniger Punkte protokolliert werden.

Ohne geeignete Deadbands protokollieren Systeme „Rauschen“ bei analogen Signalen. Es ist nie sinnvoll, eine höhere Empfindlichkeit für die Aufzeichnung zu haben als die Nenngenauigkeit eines Sensors.

Je besser Sie Ihre Deadbands abstimmen, desto weniger Wertänderungen werden Sie im System haben. Sie können ein Flattern der Analogwerte und eine kostspielige historische Speicherung vermeiden.

Tag-Gruppen

Tag-Gruppen geben Ignition vor, wie oft die SPS gelesen (abgefragt) werden soll. Tag-Gruppen diktieren die Ausführung von Tags, was besonders für große und leistungsstarke Systeme wichtig ist. Es wird empfohlen, Tag-Gruppen nach Abfragestrategien zu organisieren. Für einen bestimmten Tag ist es üblich, eine schnelle Tag-Gruppe für Status und Steuerung und eine langsamere Tag-Gruppe für den historischen Verlauf zu verwenden.

So genannte «Drive-Tag-Groups» sind eine gute Option für die Historie, wenn eine schnellere Protokollierung bedingt erforderlich ist. Tag-Gruppen legen nicht die historische Aufzeichnungsrate fest, sondern beeinflussen die Häufigkeit, mit der Ignition die Datenänderung sieht.

So genannte «Leased-Tag-Groups» sind eine gute Option, wenn Sie Tags nur dann abfragen wollen, wenn sie auf einem Bildschirm benötigt werden. Es gibt viele Werte einer SPS, die nicht für die Historie oder Alarmierung verwendet werden, sondern nur zur Anzeige auf einem Bildschirm. Wir müssen diese Werte nicht ständig abfragen.

Es ist wichtig zu beachten, dass «leased» und «driven»-Tag-Gruppen einen Einfluss auf die Verwendung des OPC-UA-Servers und den Treiber von Ignition haben, da sich die Abonnements recht häufig ändern. Eine Änderung in der Anmeldung erfordert, dass der Gerätetreiber von Ignition jede Geräteverbindung neu optimiert, was jeden auf dieser Verbindung konfigurierten Tag in dem Moment neu einliest, in dem ein leased oder driven Tag zwischen der schnellen und der langsamen Rate wechselt. Aus diesem Grund wird bei der Verwendung des OPC-UA-Servers von Ignition und von Treibern mit leased oder driven Tag-Gruppen empfohlen, falls möglich zwei Geräteverbindungen zur SPS zu erstellen. Eine Verbindung für die direkten Tag-Gruppen und eine Verbindung für leased und driven Tag-Gruppen. Auf diese Weise wirken sich Änderungen der Abonnements nicht auf die direkten Tag-Gruppen aus und vermeiden kostspielige Re-Optimierungen und veraltete Overlays.

Ereignisgesteuertes Verhalten

Es ist äußerst wichtig, Logik nur bei Änderungen auszuführen, insbesondere bei Expressions und SQL-Abfragen. Dadurch werden zusätzliche Berechnungen vermieden, wenn sich die Werte nicht geändert haben. Ignition bietet dafür verschiedene Tag-Modi wie z.B. „Event-Driven“. Bei der ereignisgesteuerten Ausführung wird die Expression oder die SQL-Abfrage nur dann ausgelöst, wenn sich eine Abhängigkeit ändert (d. h. ein Tag-Wert-Ereignis oder ein Alarm-Ereignis), anstatt ständig mit einer bestimmten Rate ausgeführt zu werden. Stellen Sie sich vor, Sie haben ein Expression-Tag in einem UDT, welcher eine Switch-Anweisung für einen Integer-Wert ausführt, um einen für den Menschen lesbaren Status bereitzustellen. Der Zustand ändert sich nicht sehr oft. Nehmen wir an, Sie haben 2.000 UDT-Instanzen, die zu 2.000 Ausdrücken führen. Bei ereignisgesteuerten Ausdrücken wird der Ausdruck immer nur dann ausgelöst, wenn sich der Zustand ändert, was sehr selten vorkommt. Bei festen Raten könnten dagegen 2.000 Ausdrücke jede Sekunde ausgelöst werden, was eine Menge unnötiger Berechnungen bedeuten würde.

Es wird empfohlen, ereignisgesteuerte Ausdrücke, abgeleitete Tags und SQL-Abfrage-Tags zu verwenden. Es wird auch empfohlen, den Verlaufsmodus eines Tags auf „Bei Änderung“ zu setzen.

Skripte

Sie können an verschiedenen Stellen in Ignition Skripte schreiben. Es ist sehr wichtig zu verstehen, wo und wann diese Skripte ausgeführt werden. Vermeiden Sie runScript-Expressions, wenn es nicht unbedingt notwendig ist. Vermeiden Sie eine Vielzahl von Timer-Skripten auf dem Gateway oder im Client. Vermeiden Sie viele Tag-Change-Skripte. Letztendlich sollten Sie versuchen, die Anzahl der Skripte auf dem Server und den Clients zu reduzieren. Auf der Gateway-Statusseite von Ignition finden Sie weitere Informationen zu laufenden Skripten. Expressions laufen viel schneller als Skripte, daher sollten Sie, wo immer möglich, Expressions anstelle von Skripten verwenden. Verwenden Sie Skripte, wo es sinnvoll ist, denn Skripte sind sehr leistungsfähig und nützlich, aber achten Sie auf die Rechenleistung, die die von Ihnen geschriebenen Skripte benötigen.

Vermeiden Sie Polling-Abfragen und verwenden Sie Caching

Es ist sehr einfach, Polling-Abfragen an den Historian, das Alarmjournal, die Audit-Logs oder benutzerdefinierte SQL-Abfragen in einem Client einzurichten. Es wird jedoch empfohlen, Polling-Abfragen zu vermeiden, da dies den Ignition-Server zusätzlich belastet, insbesondere wenn viele Clients geöffnet sind. Wenn Sie zum Beispiel zwei Polling-Abfragen pro Sekunde in einem Client laufen lassen und 25 Clients geöffnet haben, werden pro Sekunde 50 Abfragen laufen. Versuchen Sie, die Anzahl der Abfragen zu reduzieren oder sie ganz abzuschalten. Sie können auf der Benutzeroberfläche (UI) eine Aktualisierungsschaltfläche einrichten, mit der die Abfrage bei Bedarf ausgeführt werden kann. Sowohl Vision als auch Perspective verfügen über eine einfach zu bedienende Funktion zum Aktualisieren der Bindings.

Bei den sogenannten «named queries» kann das Caching für die Ergebnisse im Gateway aktiviert werden. Das bedeutet, dass das Gateway bei einer weiteren Anfrage für dieselbe named query das zwischengespeicherte Ergebnis zurückgeben kann, anstatt die Datenbank die Abfrage erneut ausführen zu lassen. Dadurch wird zwar mehr Speicherplatz auf dem Gateway benötigt (um die Ergebnisse zwischen zu speichern), aber es müssen weniger Abfragen an die Datenbank ausgeführt werden. Wenn polling-Abfragen notwendig sind oder wenn Sie viele Clients geöffnet haben, sollten Sie named queries mit Caching verwenden, um eine bessere Leistung zu erzielen.

Tag Historian, veraltete Daten erkennen

Wenn diese Ignition-Funktion aktiviert ist, wird die Ausführung von Tag-Gruppen verfolgt, um den Unterschied zwischen unveränderten Werten und Werten zu ermitteln, die sich nicht verändern, weil das System nicht läuft. Im Wesentlichen wird verfolgt, wann das System nicht läuft, was in der Regel auf Probleme wie Clock-drift zurückzuführen ist. Standardmäßig ist das Erkennen veralteter Daten (Stale Data Detection) aktiviert. Auch wenn dies nützlich sein kann, haben viele Systeme, bei denen diese Funktion aktiviert ist, viele Einträge in der Tabelle sqlth_sce der Datenbank, was unbeabsichtigt zu Leistungsproblemen bei der Abfrage historischer Daten führt. Die Leistungsprobleme werden dadurch verursacht, dass Ignition mehr SQL-Abfragen mit einer höheren Anzahl von Zeilen durchführt.

Wenn es nicht unbedingt notwendig ist, empfehlen wir, diese Funktion zu deaktivieren und das System einfach die Werte verfolgen zu lassen, während sie sich ändern. Falls es zu Clock-Drift oder zu Systemproblemen kommt, sollten diese als separate Probleme behandelt werden. Um die Funktion zu deaktivieren, deaktivieren Sie zunächst die Einstellung: «Stale Data Detection» für Ihre History Providers auf der Konfigurationsseite von Ignition Gateway unter Tags → History. Die Einstellung befindet sich unter «Advanced Settings», «Enable Stale Data Detection». Als Nächstes setzen Sie den History-Modus für alle history-Tags auf «On Change». Überprüfen Sie schließlich Ihre SQL-Datenbank mit der folgenden Abfrage, um festzustellen, ob Sie eine hohe Anzahl von Zeilen in der Tabelle sqlth_sce haben:

SELECT COUNT(*) FROM sqlth_sce

Wenn Sie Hunderte von Zeilen oder mehr haben, sollten Sie in Erwägung ziehen, die Zeilen zu einer Zeile pro Scanklasse und Rate zusammenzufassen. Sie können diese Abfrage verwenden, um die ideale Mindestanzahl von Zeilen zu finden:

SELECT scid, MIN(start_time) start_time, MAX(end_time) end_time, rate FROM sqlth_sce GROUP BY scid, rate.

Vision Client Tag Poll Rate

Vision-Clients und der Ignition Designer müssen mit dem Ignition Gateway kommunizieren, um Tag-Werte zu erhalten. Natürlich müssen Sie nur die Daten abrufen, die Sie auf dem Bildschirm sehen möchten. In diesem Fall erstellen die Vision-Clients und der Designer ein Abonnement für die Tags, die sie benötigen. Allerdings kann das Gateway den Client/Designer nicht benachrichtigen, wenn sich ein Tag ändert, so dass der Client/Designer das Gateway abfragen muss. Die Client-Abfragerate (Client Poll Rate) ist die Rate, mit der ein Vision-Client oder Ignition-Designer das Gateway nach Aktualisierungen für seine abonnierten Tags abfragt. Standardmäßig ist die Einstellung auf 250 ms festgelegt. Das bedeutet, dass jeder Vision-Client und Designer das Gateway alle 250 ms abfragt, um zu sehen, ob sich ein Tag, geändert hat. Wenn sich nichts geändert hat, erhalten wir ein leeres Ergebnis. Die Rate ist recht hoch, aber normalerweise kein Problem. Wenn Sie jedoch eine große Anzahl von Vision-Clients haben, kann dies zu einer zusätzlichen Belastung des Servers führen. Sie können diese Belastung leicht verringern, indem Sie die Einstellung auf 1 Sekunde ändern. Wenn Sie also 100 Clients geöffnet haben, erhalten Sie standardmäßig 400 Anfragen pro Sekunde für Tagänderungen. Wenn Sie die Einstellung auf 1 Sekunde ändern, erhalten Sie nur noch 100 pro Sekunde. Die Einstellung hierfür finden Sie im Designer unter Project → Properties on the Project → General tab.

Optimierungen des Gateway-Netzwerks

Das Gateway-Netzwerk ist großartig, aber es kann leicht passieren, dass ungewollt viele Daten gesendet werden. Es ist wichtig zu wissen, welche und wie viele Daten durch das Netzwerk gehen. Ignition bietet im Statusbereich des Gateways eine Diagnoseseite, auf der der ein- und ausgehende Datenverkehr des Gateway-Netzwerkdienstes angezeigt wird. Es wird empfohlen, die Kommunikation zu optimieren, um den Zustand des Gateway-Netzwerks sicherzustellen.

Alarmabonnement für remote Tag-Provider

Der Remote-Tag-Provider hat die Möglichkeit, Alarme über das Gateway-Netzwerk zur Verwendung in Alarmstatus abzufragen. Sie können die Alarmierung entweder ausschalten oder den Modus für die Abfrage von Alarmen festlegen. Es wird empfohlen, für eine optimale Kommunikation den Modus «Subscribed» zu verwenden. Bei «Subscribed» wird der Status abonniert, und Aktualisierungen werden asynchron gesendet. «Subscribed» bietet eine bessere Performance, verbraucht aber mehr Speicher. Dies ist besonders wichtig bei vielen Gateway-Netzwerkverbindungen und einer hohen Anzahl von Alarmen.

History-Modus des Remote-Tag-Providers

Der Remote-Tag-Provider hat die Möglichkeit, die History über das Gateway-Netzwerk abzufragen. Es wird empfohlen, ein Frontend-Gateway direkt mit der SQL-Datenbank zu verbinden und History-Tag-Pfade zur Abfrage der Daten zu verwenden. Wenn Sie jedoch Echtzeit-Tag-Pfade zur Abfrage der History verwenden, empfiehlt es sich, den Remote-Tag-Provider so einzustellen, dass er den Modus «Database» für den Zugriff auf die History verwendet. Auf diese Weise können Sie vermeiden, den I/O-Server nach History Daten zu fragen. Stattdessen können Sie sich abkürzen und die Datenbank direkt abfragen, was jedoch eine direkte Verbindung zur SQL-Datenbank erfordert. Wenn eine Verbindung zur SQL-Datenbank nicht verfügbar ist, sollten Sie versuchen, die Anzahl der History-Abfragen zu reduzieren und recourcenintensive Abfragen mit großen Zeitbereichen und Daten zu vermeiden.

Ignition auf virtuellen Maschinen ausführen

Zusammenfassung

Eine der wichtigsten Einsatzumgebungen für Ignition sind heute virtuelle Maschinen (VMs). Ein großer Prozentsatz der Unternehmenskunden verwendet Ignition auf VMs und nicht Bare-Metal auf physischen Servern. Obwohl VMs von Haus aus langsamer sind als Bare-Metal, sollte Ignition in diesen Umgebungen gut laufen, solange die richtige VM-Konfiguration angewendet wird.

Software

Ignition läuft auf jedem Hypervisor, der Hardware und ein Betriebssystem ordnungsgemäß emuliert. Die meissten virtualisierten Ignition Installationen basieren auf VMWare jedoch nicht auf Grund von speziellen Vorteilen, sondern hauptsächlich aufgrund des grossen Marktanteils von WMWare. Inductive Automation empfiehlt VMWare nicht vor anderen Hypervisoren und hat, solange die Ressourcenzuweisung angemessen ist, keine hypervisor-spezifischen Probleme bei neuerer Virtualisierungssoftware festgestellt.

Ressourcenzuweisung

Die CPU- und Speicherzuweisung sollte von den Ingenieuren festgelegt werden, welche auch die Ignition-Projekte erstellen. Kleine Systeme können aus 4 vCPUs mit 8 GB RAM bestehen. Sehr große Systeme können 32 vCPUs oder mehr mit 64+GB RAM umfassen.

Wenn Ignition auf kleinen Systemen mit nur einer Handvoll Clients und Tags läuft, ist die normale Ressourcenzuweisung oft akzeptabel. Wenn kritische Anwendungen oder irgendeine Art von erheblicher Last ausgeführt wird, werden dedizierte Ressourcen benötigt, damit das System leistungsfähig bleibt.

Zugewiesene Ressourcen

Bei der ersten Spezifizierung der Anforderungen eines Ignition Gateway sollten Sie immer den Bedarf an dedizierten vCPUs und Speicher ansprechen. Wenn ein Ignition Projekt klein anfängt, wird dies anfangs vielleicht nicht benötigt, aber wenn es wächst, werden dedizierte Ressourcen benötigt, um Probleme zu vermeiden. Wenn dedizierte Ressourcen anfangs nicht konfiguriert werden, kann es später zu erheblichem Widerstand seitens der IT-Abteilungen kommen, die diesen Bedarf nicht vorausgesehen haben.

VMWare-spezifische Einstellungen

In VMWare wird in der Regel die Einstellung der Latenzempfindlichkeit auf Hoch konfiguriert.

Überprüfen Sie nach der Konfiguration, ob die vCPU-Zuweisung zu 100 % für die Ignition-VM bestimmt ist. Wenn dies nicht der Fall ist, bedeutet dies, dass der VM-Host überdimensioniert wird, was behoben werden sollte.

Allgemeine Fragen

F: Meine CPU-Auslastung ist nicht al zu hoch. Brauche ich trotzdem Dedicated Resources?

A: Ja, wahrscheinlich. Wenn Sie nicht gerade ein System betreiben, das nicht viel tut, verarbeitet Ihr Ignition Gateway wahrscheinlich eine Menge Burst-Prozesse. Das bedeutet, dass Datenverkehr über das Netzwerk läuft, Threads asynchron aufgeweckt werden oder andere Dinge passieren, bei denen Ignition sofort CPU-Zyklen verwenden möchte. Ohne dedizierte Ressourcen kann dies bis zu 50-500 uS dauern. Wenn 1000 solcher Vorgänge pro Sekunde stattfinden, was auf einem stark belasteten Ignition-System nicht unüblich ist, kann die Aufwachverzögerung bis zu 5%-50% einer vCPU betragen.

F: Wie kann ich wissen, ob ich dedizierte Ressourcen benötige?

A: Inductive Automation empfiehlt normalerweise, von Anfang an dedizierten Ressourcen bereit zu stellen. Wenn man bedenkt, wie wichtig Ignition für die meisten Unternehmen ist, welchen Wert es hat und wie hoch die Investition für den Kauf war, macht es keinen Sinn, bei den Ressourcen zu sparen.

Wenn Sie bereits mit gemeinsam genutzten Ressourcen begonnen haben, gibt es ein Hauptanzeichen dafür, dass dedizierte Ressourcen notwendig werden.

Clock-Drift. Dies ist eine Kennzahl auf der Ignition Statusseite und ein Maß dafür, wann das Betriebssystem eine geplante Aufgabe ausführt. Angenommen Ignition plant eine Aufgabe für die Ausführung in 1s. Unter den meisten Umständen wird diese Aufgabe genau in 1000 ms ausgeführt. Wenn dies nicht der Fall ist, erhält das Betriebssystem nicht die CPU-Zyklen, die es für die Ausführung dieser Aufgabe benötigt. Es handelt sich entweder um ein CPU-Zuordnungsproblem, ein sehr stark belastetes System, andere Software, welche das Betriebssystem beeinträchtigt, oder der Hypervisor stellt nicht oder nicht schnell genug Ressourcen zur Verfügung. Mit dedizierten Ressourcen lässt sich Clock Drift fast immer beheben. Beachten Sie, dass eine zu geringe Anzahl zugewiesener vCPUs ebenfalls zu Clock Drift beitragen kann.

Verzögerungen bei allgemeinen Aufgaben, langsame Verarbeitung, History Probleme (wenn die Datenbank und die Geräte nicht überlastet sind), und anderes träges Verhalten können ebenfalls Anzeichen dafür sein, dass dedizierte Ressourcen benötigt werden.

F: Ich habe bereits dedizierte Ressourcen und habe eine große Anzahl von vCPUs zugewiesen, aber mein Ignition-System ist immer noch überlastet. Was kann ich tun?

A: Irgendwann stößt ein einzelner Ignition-Server, unabhängig von CPU- und Speicherzuweisungen an seine Grenzen. Die Scale-Out-Architektur von Inductive Automation ist die allgemeine Empfehlung, um die Grenzen eines einzelnen Systems zu überschreiten.