“Flexibel durch Modularität” – Tag Historian Modul

Überblick

Das Tag Historian Modul für Ignition ist ein Set an Funktionen, welche die Erfassung, Speicherung, Abfrage und Visualisierung von Daten ermöglichen.

Wie alles andere in Ignition ist auch die Historian-Funktionalität modular aufgebaut. Oft werden mehrere Module zusammen verwendet, um ein vollständiges System zu erhalten. Häufig kombinieren Anwender die Historian-Funktionalität von Ignition mit SCADA-, HMI-, IIoT- oder MES-Funktionalität.

Obwohl viele Benutzer das Tag-Historian-Modul von Ignition als „Ignition-Historian“ betrachten, wird eine vollständige Datenhistoriefunktion oft dadurch beschrieben, dass nicht nur Tag-Daten, sondern auch ereignisbasierte Daten gespeichert werden und eine Visualisierung geboten wird. Daher werden in diesem Dokument die Module für diese Funktionen beschrieben.

Module

Die modulare Architektur von Ignition ermöglicht die Wahl zwischen der Verwendung eines einzigen oder mehrerer Module für eine bestimmte Installation. Die Mindestanforderung für die Verwendung von Ignition als Tag-Historian ist das Tag-Historian-Modul. Viele Unternehmen verwenden aber mehrere Module, insbesondere wenn eine ereignisbasierte Speicherung erforderlich ist oder eine direkte Gerätekommunikation verwendet wird. Die Module, die in einem typischen System verwendet werden, sind unten aufgeführt.

Tag Historian Module

Dies ermöglicht die Speicherung und den Abruf historischer Daten über das Tag-System von Ignition. Eingehende Tag-Änderungen können an den Datenspeicher weitergeleitet werden, und der Tag-Verlauf kann über das Modul abgerufen werden.

Speicherung

Die Speicherung von Daten durch das Tag-Historian-Modul kann an verschiedenen Orten erfolgen. Ein interner Speicher ist verfügbar, um kleine Datenmengen in Ignition selbst zu speichern. Die SQL-basierte Speicherung ist die normale Empfehlung für die meisten Systeme und leitet die Daten an eine angeschlossene SQL-Datenbank weiter. Weitere Speicher-Engines sind von Drittentwicklern erhältlich, von denen einige im Modul-Showcase zu finden sind. Unabhängig von der Speicher-Engine bietet das Tag Historian-Modul Werkzeuge für Datenspeicherraten, Komprimierung, Deadbands und eine Reihe anderer Funktionen.

Abruf

Das Tag Historian Modul kann verwendet werden, um historische Daten abzurufen und Berechnungen und Aggregationen auf historischen Daten durchzuführen. Abhängig von der verwendeten Speicher-Engine führt das Tag Historian Modul entweder den Abruf und entsprechenden Aggregationen direkt durch, oder im Falle der Verwendung von Speicher-Engines von Drittanbietern leitet das Tag Historian Modul die Anfrage an die Speicher-Engine weiter.

Datenspeicherung

Die Datenspeicherung von ereignisbasierten Daten über SQL-Bridge erfolgt in SQL-Datenbanken. SQL-Bridge ermöglicht es den Benutzern, Tabellennamen und Spalten zu definieren und auszuwählen, was gespeichert werden soll und mit welchen Triggern. Historische Transaktionsgruppen sind eine gute Wahl für die meisten ereignisbasierten Protokollierungen.

Daten Speicherung von Tag-basierten Daten durch Tag-Historian kann an verschiedenen Orten erfolgen. Die meisten Benutzer zielen auf eine SQL-Datenbank ab. Andere Möglichkeiten sind ein kleines internes Speichersystem und Speicher-Engines von Drittanbietern, von denen viele im Modul-Showcase zu finden sind.

Datenabruf

Verwendung der Visualisierungswerkzeuge von Ignition.

Bei der Verwendung von Perspective oder Vision bietet Ignition eine Reihe von eingebauten Werkzeugen für den Datenabruf. Für die Tag-Historie beinhaltet dies Tag-Historie-Binding, einen Datenquellentyp für das Reporting-Modul, automatische Integration mit einigen Diagrammkomponenten und einige Drag-and-Drop-Konfigurationen in den Design-Tools. Für Ereignisdaten, die in einer SQL-Datenbank gespeichert sind, können in Ignition sogenannte Named Queries definiert werden, die den Abruf von Bedingungen, Datums- und Qualitätsbeschränkungen und alles andere, was die SQL-Syntax zulässt, unterstützen.

Für die Verwendung mit externen Tools

Für Ereignisdaten können externe Tools die Datenbank direkt abfragen, so dass alle Daten für Personen mit entsprechenden Sicherheitsberechtigungen zugänglich sind.

Für Tag-Historian daten wird empfohlen, dass externe Tools Daten von den Ignition-APIs abfragen. Dies ist nützlich, damit jeder Datenabruf die Logik von Ignition durchläuft, die Interpolation, Aggregation, Partitionsüberbrückung und jede andere für den Abruf von Tag-Daten erforderliche Logik bereitstellt. Die API-Funktion zum Abrufen dieser Daten ist system.tag.queryTagHistory(), und das Einrichten eines REST-Endpunkts für diese Funktion ist mit dem WebDev-Modul einfach.

Architekturen

Diese Architekturdiagramme zeigen Ignition mit dem Tag Historian-Modul in Kombination mit einer SQL-Datenbank. Beachten Sie, dass Architekturen, die andere Tag-History-Speicher verwenden, deutlich anders aussehen können. (Der quelloffene, kostenlose Azure ADX-Connector von Microsoft hat beispielsweise einen sehr hohen Durchsatz und speichert in der Cloud, so dass keine SQL-Datenbank verwendet wird).

Wenn Sie eine SQL-Datenbank für die Speicherung verwenden, können diese Architekturen einen Eindruck von möglichen Konfigurationen vermitteln. Im Abschnitt „Benchmarks“ weiter unten erhalten Sie einen Eindruck von den möglichen Durchsatzraten für verschiedene Datenbanktechnologien.

Geringe Ausfallsicherheit Einfache Architektur

Server 1: Ignition
Server 2: SQL-Datenbank

Hohe Leistung Einfache Architektur

Server 1: Ignition
Server 2: Ignition nur mit Tag Historian-Modul und SQL-Datenbank auf demselben Server

Vorteil: Hochgeschwindigkeits-Gateway-Netzwerkkommunikation zwischen den Servern. Auch Kommunikationsschwierigkeiten, Latenzzeiten und Paketverluste besser gehandhabt.

Leistungsstarke Multi-Datenbank Architektur

Server 1: Ignition
Server 2 und 3: Ignition nur mit Tag Historian-Modul und SQL-Datenbank auf demselben Server

Vorteil: Ermöglicht Skalierung über die Durchsatzgrenzen einer einzelnen Datenbank hinaus.

Datensammler-Architektur

PLCs oder andere Geräte kommunizieren mit Datensammlern im Feld. Diese Datensammler können Ignition, Ignition Edge oder andere Systeme, welche MQTT Sparkplug B nativ beherrschen sein. Darüber hinaus sprechen einige Geräte nativ MQTT Sparkplug B und unterstützen History-Transfer und Store and Forward. Diese Geräte können oft direkt ohne einen separaten Kollektor kommunizieren.

Kollektoren sind optional. Je nach Branche können sie aus Sicht der Bandbreite, Netzwerksegmentierung und Sicherheit sinnvoll sein.

Benchmarking

Sowohl ereignisbasierte Daten als auch Tag-basierte Daten benötigen eine geeignete Hard- und Software, um die Anforderungen des Designs zu erfüllen. Ein angemessen konzipiertes System hat jedoch in der Regel tausendmal mehr Tag-basierte Daten als Ereignisdaten. Daher konzentrieren sich die Benchmarks hier auf Tag-basierte Daten und Durchsatzraten.

Verstehen der Benchmarks

Die Benchmarks basieren auf Durchsatzraten.

Ein Beispiel:

Bei einer Rate von 10s, bei der sich 10 % der Tags ändern.

Verstehen von Raten und Änderungsprozentsätzen

Beachten Sie die oben angegebene Rate und den Prozentsatz der Tag-Änderungen. Die Leistung der Tag-Historiker von Ignition lässt sich am besten in Tag-Änderungen pro Sekunde bewerten.

Bei einer Änderungsrate von 10 Sekunden und 10 % der Tags erzeugen 100 Tags 1 Tag-Änderung pro Sekunde.

Angenommen, eine Datenbank kann 10.000 Tag-Änderungen pro Sekunde verarbeiten. In dieser Tabelle ist angegeben, wie viele Tags sie verarbeiten kann:

Storage Rate	10s	60s	1s	1s
Change Rate	10%	10%	10%	100%
Number of Tags	1 Million	6 Million	100k	10k

Wie viele Tags kann eine einzelne Datenbank verarbeiten?

Wie Sie in der obigen Tabelle sehen können, hängt dies stark von der Speicherrate und der Änderungsrate Rate der Tags ab. Ignition-Systeme sind standardmässig so konfiguriert, dass sie 10s-Speicherraten für Tags verwenden. Einige Benutzer wünschen jedoch 1s oder schnellere Raten für einige oder alle Tags. Der Wechsel zu schnelleren Raten wird unterstützt und je nach Anforderung empfohlen. Beachten Sie jedoch, dass schnellere Raten gleichbedeutend sind mit mehr Änderungen pro Sekunde welche an die Datenbank übertragen werden.

SSD oder HDD?

Inductive Automation empfiehlt dringend die Verwendung einer SSD sowohl für die Ignition-Installation als auch für den Datenbankspeicher. Wenn nur ein geringer Durchsatz erwartet wird, kann jedoch auch eine HDD ausreichend sein. Wenn Sie sich für eine HDD entscheiden, sollten Sie den Durchsatz der Datenbank testen, um sicherzustellen, dass die Festplatte die erforderlichen Speichergeschwindigkeiten erreicht.

Interner Historie Speicher

Der interne Historian ist ein festplattenbasierter Historian, der direkt in Ignition verfügbar ist. Dies kann eine eine gute Möglichkeit sein, kleine Datenmengen an entfernten Standorten oder an Orten zu speichern, an denen eine SQL-Datenbank nicht verfügbar ist. Die Daten sind standardmässig auf 1 Woche begrenzt. Diese Begrenzung kann jedoch erweitert werden, Inductive Automation empfiehlt nicht, jahrelange Daten im internen Historian zu speichern, da er nur für kleine Mengen lokaler Daten gedacht ist. Wenn Sie Ihre benötigte Zeitspanne für die Protokollierung, Ihre Raten und Ihren Änderungsprozentsatz berechnen, empfehlen wir, ein maximum von 10 Millionen Einträgen. Da der interne Historian nicht über einige der erweiterten Funktionen des SQL-Datenbankspeichers, wie z. B. automatische Partitionierung Verfügt, sollten Sie einen SQL-Datenspeicher verwenden falls Sie mehr als 10 Millionen Einträge benötigen.

Tag Änderungen pro Sekunde

Um aussagekräftige Benchmarks zu erhalten werden diese in Tag Änderungen pro Sekunde bemessen. Um die Tag Änderungen pro Sekunde zu berechnen können Sie folgende Formel anwenden.

Anz.Tags * Änderungsrate in % / Speicherrate in Sekunden

Beispiel: 100,000 Tags * 20% Änderung / 5s Speicherrate = 100’000 * 0.2 / 5 = 4,000

SQL Database Benchmarks

Test System:

Platform	Windows
CPU	Intel Core i7-4790K (4/8 core, 4GHz)
RAM	16GB
Drive	Samsung SSD 860 EVO 2TB

Anmerkungen:

• Diese Benchmarks sind nur Schätzungen. Hardwareunterschiede und viele andere Faktoren können sich erheblich auf die Durchsätze auswirken.
• Diese Schätzungen beruhen auf Durchsätzen im eingeschwungenen Zustand. Eine vernünftige Tag-Historian-Partitionsgrösse hilft die meissten Datenbank vor Degradation zu bewahren. Timescale ist eine Ausnahme da sie keine Degradation erfährt mit der Zeit.
• Oracle ist in dieser Liste nicht enthalten, da Inductive Automation keine Oracle Enterprise-Lizenz besitzt. Das leichtgewichtige Oracle Express wurde getestet und hatte eine ähnliche Leistung wie MySQL, aber es wird erwartet, dass eine Vollversion von Oracle eine deutlich bessere Leistung zeigt.

Diese anfänglichen Schreib-Benchmarks sind nur als Referenz angegeben. Die meisten Datenbanken haben eine hohe Leistung beim anfänglichen Durchsatz und die Geschwindigkeit nimmt dann ab, bis sie einen stabilen Zustand erreichen. Das erste Bild zeigt diesen stabilen Zustand. Wenn Sie Ihre eigenen Tests durchführen und die ersten Ergebnisse einen höheren Durchsatz zeigen, sollten Sie das System einige Stunden oder Tage laufen lassen damit sich die Raten ausgleichen können.

Speicherplatzbedarf

Der unkomprimierte, nicht optimierte Speicherplatzbedarf in SQL-Datenbanken beträgt etwa 100 Byte pro Tag-Änderung, unabhängig von der gewählten Datenbank. Anhand dieser Zahl lässt sich der Speicherbedarf recht einfach berechnen.

Tag Änderungen Pro Sekunde * 100 * Zeitraum in Sekunden

Wenn Sie z.B. 1.000 Tags haben, von denen sich 10 % ändern, dann sind das 10 Änderungen pro Sekunde. Multiplizieren Sie das mit 100 Byte und 86.400 Sekunden pro Tag, dann erhalten Sie rund 86,4 MB pro Tag.

Beachten Sie, dass viele Datenbanken über Komprimierungsoptionen verfügen, die den Gesamtspeicherbedarf um 30-50 % oder mehr reduzieren können, was in der Regel auf Kosten der CPU/Durchsatzleistung geht. Timescale, insbesondere, verfügt über eine Option, die den Speicherbedarf unter bestimmten Umständen um bis zu 90 % reduzieren kann. Wenn Speicherplatz ein wichtiger Faktor ist, kann es sich lohnen, diese Optionen zu prüfen.

Durchsatz vs. Netzwerkqualität

Die Durchsatztests für die Netzwerkqualität wurden mit Microsoft SQL Server durchgeführt. Es wird angenommen, dass andere Datenbanken ähnliche Leistungsmerkmale aufweisen, was die Netzwerklatenz betrifft.

Szenario 1:

		Latenz (Server 1 zu Server 2)
		0ms	1ms	5ms	10ms	20ms	50ms	100ms	150ms	200ms
Packet Verlust   (Server 1 zu Server 2)	0%	30	19	17	15	12	9	6	4	3
	2%	22	4	3	3	2	2	–	–	–
	5%	10	1	1	1	1	–	–	–	–
	10%	1	–	–	–	–	—	–	–	–
	15%	–	–	–	–	–	–	–	–	–
	20%	–	–	–	–	–	–	–	–	–

Szenario 2:

		Latenz (Server 1 zu Server 2)
		0ms	1ms	5ms	10ms	20ms	50ms	100ms	150ms	200ms
Packet Verlust   (Server 1 zu Server 2)	0%	30	30	30	30	30	30	30	26	20
	2%	30	30	30	30	30	30	19	14	12
	5%	30	30	30	30	30	19	11	9	7
	10%	30	22	21	20	17	10	9	7	5
	15%	20	14	13	12	11	7	6	5	3
	20%	5	–	–	–	6	–	–	–	–

Alle Ergebnisse sind in Tausender Tag-Änderungen pro Sekunde angegeben.

Wie aus den Zahlen hervorgeht, ist Ignition in Szenario 2 wesentlich widerstandsfähiger, da eine Leistungsverschlechterung erst bei einem signifikanten Prozentsatz an verworfenen Paketen oder einer Latenzzeit von über 100ms. Diese Tests wurden mit einer grossen Anzahl von Tag-Änderungen mit einer Rate von einer Sekunde durchgeführt.

Optimierung

SQL-Bridge

• Konfigurieren Sie die Datenbereinigung in Tabellen so dass der Verlauf nicht ewig gespeichert werden muss
• Stellen Sie sicher, dass Trigger verwendet werden, um Ereignisse richtig zu speichern
• Speichern Sie keine Daten, die nicht benötigt werden. Wenn das Speichern von Time Series erforderlich ist, sollten Sie stattdessen Tag-Historian verwenden und nur Ereignisse über Transaktionsgruppen abspeichern.
• Wenn Sie Abfragen für die von SQL-Bridge gespeicherten Daten schreiben, achten Sie auf die WHERE Klausel der Abfragen und erstellen Sie entsprechende Indizes in den Datenbanktabellen.
• Überwachen Sie die Leistung des Systems, um sicherzustellen, dass Sie nicht vergessen haben, einen Index hinzuzufügen, und um sicherzustellen, dass die Grösse der Datenbanktabellen nicht zu gross für das Projekt und die Hardware auf der es läuft ist.

Tag Historian mit SQL-Datenbanken

• Legen Sie angemessene Deadbands für Tags fest. Deadbands stellen sicher, dass Junk-Daten nicht protokolliert werden. Wenn ein Sensor eine Genauigkeit von 0,2 hat, gibt es keinen Grund, jemals eine Änderung von 0,02 zu protokollieren, da diese Änderung nur Rauschen darstellt und wertlos ist. Die Einstellung vernünftiger Deadbands kann eine erhebliche Menge an Speicherplatz und Durchsatz einsparen.
• Legen Sie die Zeitgrenzen („Min Time Between Samples“) so fest, wie es sinnvoll ist, damit Tags nicht schneller als bestimmte Raten protokolliert werden.
• Stellen Sie die Tag-Raten vernünftig ein. Legen Sie Tags nur bei Bedarf so fest, dass sie mit 1s-Raten aufzeichnen.
• Wenn es für Ihr System sinnvoll ist, empfehlen wir, die Erkennung veralteter Daten zu deaktivieren. Wenn das System langsamer läuft, als es eigentlich sein sollte, überprüfen Sie die Tabelle sqlth_sce. Wenn dort mehr als ein paar hundert Zeilen vorhanden sind, haben Sie möglicherweise versehentlich das System überlastet. Das Ausschalten der «Stale Data Detection» ist normalerweise kein Problem (unter den erweiterten Eigenschaften der Datenbankverbindung), aber lesen Sie das aber lesen Sie zuerst das Benutzerhandbuch, um sicher zu sein, dass Sie die Einstellung verstehen. Diese Einstellung verhindert, dass die Tabelle sqlth_sce anwächst, wenn das System Langsamer wird.
• Wenn Sie MySQL verwenden, fügen Sie einen zusätzlichen Verbindungsparameter zur Datenbankverbindung hinzu. Dies erhöht den Durchsatz von etwa 1.000 Tag-Änderungen pro Sekunde auf etwa 10.000-20.000. (rewriteBatchedStatements=true)
• Stellen Sie sicher, dass keine anderen Anwendungen oder Dienste auf den Systemen laufen, auf dem Ignition und die Datenbank(en) gehostet sind.
• Richten Sie vorverarbeitete Partitionen ein, wenn Abfragen über längere Zeiträume zu erwarten sind. Beachten Sie, dass dies einen gewissen zusätzlichen Speicher- und Verarbeitungsaufwand erfordert, der Speicherdurchsatz geringfügig beeinflusst.

Hoher Durchsatz

Diese Optimierungen gelten, wenn Sie ein System spezifiziert oder in Produktion haben, bei dem Sie erwarten einen hohen Durchsatz in Form von Tag-Änderungen pro Sekunde zu haben.

• Option 1 – Verringern Sie den Durchsatz entsprechend der obigen Anleitung.
• Option 2 – Hinzufügen einer weiteren Datenbank/Schema zur SQL-Datenbank DBMS auf demselben Speicher. Mehrere Datenbanken können dazu beitragen, die Last zu verteilen und den Durchsatz zu erhöhen. Verteilen Sie die Tags auf die Datenbanken.
• Option 3 – Wenn der Durchsatz immer noch nicht erreicht werden kann, können Sie mehrere Datenbanken auf demselben DBMS, die aber auf unterschiedliche Speicherplätze verweisen, anlegen. Dies kann den Durchsatz ebenfalls erhöhen. Einige Datenbanken sind stark durch Laufwerks-IO begrenzt, und die Aufteilung von Datenbanken auf verschiedene Speicher kann erhebliche Auswirkungen haben.
• Option 4 – Ignition auf mehrere Datenbankserver zu verweisen ermöglicht einen separaten Durchsatz zu jedem Server, wodurch sich der mögliche Durchsatz gegenüber eines einzelnen Datenbankservers verdoppelt.
• Option 5 – Erwägen Sie eine verteilte Architektur. Wenn es mehrere Standorte und ein zentrales System gibt, sollten Sie erwägen, die Standortdaten an jedem Standort zu lassen und die zusammengefassten Daten an die Zentrale zu senden. Keine Sorge: Wenn Sie das Gateway-Netzwerk verwenden, können Sie jederzeit vom Zentralsystem aus auf die historischen Daten der Standortkennzeichen zugreifen. Zentrale Berichte, Dashboards und andere visuelle Darstellungen können Daten von den Standorten streamen, um sie zentral anzuzeigen, solange der Standort online ist.
• Option 6 – Wenn ein sehr hoher Durchsatz erforderlich ist, beispielsweise im Bereich von 500.000 bis 1.000.000 Tag-Änderungen pro Sekunde, kann dies die Möglichkeiten einer SQL-Datenbank übersteigen. Andere Speicher-Engines sind für Tag-Historian über das Modul Showcase und andere Bereiche, die einen extrem hohen Durchsatz haben. Diese Optionen können erwägenswert sein, wenn ein sehr hoher Durchsatz benötigt wird.

Anforderungen um Datenmengen zu reduzieren

• Datenbankkomprimierung (30-50%)
  • Viele Datenbanken verfügen über Optionen zur Komprimierung der Daten für Tabellen.
• Vollständige Laufwerkskomprimierung
  • Die Laufwerkskomprimierung für Speicherlaufwerke kann ebenfalls Vorteile bringen.
  • Wird normalerweise nicht zusammen mit der Datenbankkomprimierung verwendet.
• Bei Verwendung von Timescale
  • Timescale’s Chunking & Compression kann noch deutlichere Einsparungen bringen. Die Komprimierung erfolgt nach einer konfigurierbaren Zeitspanne. Einsparung von Speicherplatz erfolgen nach Ablauf dieses Zeitraums und lösen die Komprimierung aus. Die Einsparungen werden mit bis zu 90% oder mehr angegeben. Inductive Automation hat keine Benchmarks durchgeführt, daher sind die genauen Einsparungen im Vergleich zu den Tag Historian-Tabellendaten zum jetzigen Zeitpunkt nicht bekannt.
• Verwendung anderer Speicher-Engines
  • Einige Speicher-Engines bieten erhebliche Platzeinsparungen.
  • Beispiele:
    • Influx von Module Showcase hat einen geringeren Speicherbedarf pro Datensatz.
    • Azure ADX’s unterstützt einen sehr hohen Durchsatz und soll eine effiziente Speicherung gewährleisten. Microsoft hat ein kostenloses, quelloffenes Modul als Connector veröffentlicht, das auf github zu finden ist. Der Azure ADX-Dienst ist ein kostenpflichtiger Dienst von Microsoft.
  • Obwohl Inductive Automation von Zeit zu Zeit Anleitungen für Modulautoren bereitstellet, unterstützt oder befürwortet Inductive Automation keine Showcase Module. Wir verweisen unsere Kunden an die Modulautoren und die Moduldokumentation zu studieren, bevor sie sich für die Verwendung eines dieser Module entscheiden.

Security

Leitfaden zur Security Hardening

Inductive Automation legt grossen Wert auf Sicherheit und bietet einen Leitfaden zur Sicherung einzelner Ignition Gateways. Inductive Automation empfiehlt die Lektüre der neuesten Security Härtungsrichtlinien für den neuesten Stand der Sicherung eines einzelnen Ignition Gateways, welche Sie hier finden: https://inductiveautomation.com/resources/article/ignition-security-hardening-guide

Verschlüsselung der Kommunikation

Die Verschlüsselung kann für alle historischen Daten einen wichtigen Aspekt sein. Ignition kann über gesicherte Netzwerke laufen, und die gesamte Datenübertragung kann über VPN oder andere verschlüsselte Tunnel laufen, welche normalen IP-Verkehr unterstützen. Ausserdem kann die Ignition-Kommunikation von Client zu Server wie auch die Gateway-zu-Gateway-Kommunikation verschlüsselt werden.Der Gateway-zu-Datenbank-Verkehr kann bei allen gängigen Datenbanken verschlüsselt werden. Einige Geräte unterstützen selbst keine Verschlüsselung. Daher ist es wichtig zu überlegen, wie die Gerätekommunikation gesichert werden kann. Manchmal besteht die Lösung darin, ein kleines Datenerfassungsgerät neben die unsichere Hardware zu stellen, auf dem Ignition Edge oder eine andere Software läuft, um die unverschlüsselte Kommunikation der Netzwerke sicher zu stellen. Andere Lösungen umfassen die VLAN-Verschlüsselung und die Sicherung von Netzwerken für unverschlüsselten Verkehr durch Firewall-Regeln, IDSs und andere Sicherheitsmassnahmen. Inductive Automation empfiehlt die Zusammenarbeit mit Sicherheitsexperten, wenn Fragen zur Sicherheit der Gerätekommunikation auftauchen.

Verschlüsselung der Datenträger

Die Verschlüsselung at-rest kann durch Verschlüsselung der Laufwerke oder der Verschlüsselung von Datenbanktabellen erfolgen. Diese Verschlüsselungswerkzeuge sind Teil der Datenbank-Verwaltungstools. Die Verschlüsselung des Laufwerk auf dem Ignition läuft, ist in den meissten Fällen nicht notwendig, da Ignition nicht als Hauptspeichermedium fungiert. Je nach Datenverkehr, Leistung und Einstellungen in Ignition besteht die Möglichkeit, dass zwischengespeicherte Daten im Store & Forward-System vorübergehend von Ignition auf die Festplatte geschrieben werden. Wenn diese Daten im Ruhezustand verschlüsselt werden müssen, auch wenn sie vorübergehend auf der Festplatte gepuffert werden, dann wäre es in diesem Fall angebracht, auch das Laufwerk, auf dem Ignition läuft, zu verschlüsseln.

Client Security

Für die Sicherheit der Clients wird normalerweise die TLS 1.2/1.3-Verschlüsselung verwendet, die den selben Verschlüsselungsgrad wie eine typische Banken-Website erreicht. Es werden standardmässige PKI-Zertifikate verwendet, und die Schritte für die Konfiguration sind in der Ignition-Dokumentation beschrieben. Eine Anleitung zur Aktivierung von TLS finden Sie in der Anleitung für die Aktivierung von TLS in Ignition.