AWS Germany – Amazon Web Services in Deutschland

Industrieprotokoll an AWS-Cloud: Maschinendatenerfassung für AWS Dienste

von Arie Leeuwesteijn übersetzt durch Marco Strauss

Industriedaten sind eine wertvolle Ressource. Sie bieten Einblicke in Maschinenleistung, Prozesse und Produkte und Erlauben sogar Rückschlüsse auf zukünftige Ereignisse wie Defekte. Durch das Sammeln und Analysieren solcher Daten können Unternehmen die Produktqualität verbessern, die Effizienz optimieren, Lieferketten verwalten und vorbeugende Wartung effektiv planen.

Die Daten aus den industriellen Geräten auszulesen kann jedoch ein komplexer Prozess sein. Typischerweise werden diese Geräte von verschiedenen Herstellern produziert, die jeweils ihre eigenen proprietären Datenformate, Adressierungsschemata und Zugangsprotokolle verwenden. Auch Netzwerkbeschränkungen und Plattformanforderungen können den Betrieb und die Bereitstellung der erforderlichen Software in Produktionsumgebungen weiter erschweren.

Shop Floor Connectivity (SFC) ist ein Datenerfassungswerkzeug, welches schnell anpassbare Greenfield- und Brownfield-Konnektivitätslösungen liefern kann. SFC adressiert die Einschränkungen bestehender IoT-Datenerfassungsdienste und vereinheitlicht die Datenerfassung, sodass Kunden Daten von Geräten verschiedener Hersteller auf einheitliche Weise für die Verwendung mit verschiedenen AWS-Diensten sammeln können.

SFC-Komponenten

SFC besteht aus Komponenten die sich in drei Haupttypen unterteilen lassen.

  • Protokolladapter (Protocol Adapter)
  • SFC-Core
  • Zieladapter (Target Adapter)
 
Überblick über die SFC-Komponenten

Protokolladapter

Protokolladapter werden verwendet, um Daten von einem oder mehreren industriellen Geräten zu lesen. Diese Adapterschnittstelle abstrahiert das verwendete Protokoll von den Geräten und liefert die Daten mit zusätzlichen Metadaten in einem gemeinsamen Format an den SFC-Core. Die Schnittstelle ist so konzipiert, dass SFC einfach um neue Protokolladapter erweitert werden kann, ohne dass Änderungen am Rest des Frameworks erforderlich sind.

Zum Zeitpunkt dieses Artikels verfügt SFC über Adapter für Modbus TCP, MQTT, OPCUA, Ethernet/IP PCCC, ADS, SNMP, SLMP, S7 sowie SQL und REST.

SFC-Core

Der SFC-Core ist der Controller des SFC-Frameworks. Er verwaltet die Konfiguration und Planung der Datenerfassung durch die Protokolladapter. Optional kann er jeden empfangenen Datenwert mithilfe einer Kombination aus einer oder mehreren der über 60 verfügbaren Transformationsfunktionen umwandeln. Der Core verfügt über eine durchgängige Datentypentreue, was bedeutet, dass die Daten in dem Datenformat an die Ziele gesendet werden können, in dem sie von der Quelle gelesen wurden, einschließlich komplexer strukturierter Datentypen und mehrdimensionaler Arrays.

Optional können die Daten auf dem Edge-Gateway gepuffert und aggregiert werden, um den Netzwerkverkehr zu reduzieren, indem eine oder mehrere der 12 verfügbaren Aggregationsfunktionen verwendet werden.

AWS Secrets Manager integriert ebenfalls mit SFC-Core. Platzhalter in der Konfiguration ermöglichen die Speicherung von in AWS Secrets Manager gespeicherten Geheimnissen.

Zieladapter

Zieladapter sind Komponenten, die die Daten vom SFC-Core empfangen und an ihre spezifischen AWS- oder lokalen Dienste senden. Komponenten können optional Datentransformationen unter Verwendung einer Apache Velocity-Vorlage anwenden, um die Daten im erforderlichen Format für den empfangenden Dienst zu liefern. Verfügbar sind z.B. AWS IoT Core, Amazon Kinesis Data Streams, Amazon Firehose, AWS Lambda, Amazon Managed Streaming for Apache Kafka (MSK), Amazon Simple Storage Service (S3), AWS IoT SiteWise, Amazon Timestream, Amazon Simple Notification Service (SNS) oder Amazon Simple Queue Service (SQS). Zusätzliche Ziele für das lokale Dateisystem, die Terminalausgabe, MQTT-Clients sind ebenfalls verfügbar. Daneben besteht die Möglichkeit gesammelte Daten als OPC UA Model zu exponieren.

Datenerfassung

Die Datenerfassung wird durch Konfiguration eingerichtet und erfordert keine zusätzliche Codierung. Die erforderlichen Konfigurationsdateien sind als JSON Dokumente verfasst, was im operativen Betrieb einen hohen Automatisierungsgrad erlaubt. Kern der Konfiguration sind eine oder mehrere Zeitpläne (Schedules), die vom SFC-Core ausgeführt werden. Jeder Zeitplan definiert das Intervall und die Quellen (Sources), die von unterschiedlichen Typen sein können, aus denen Daten verschiedener Typen gelesen werden müssen. Eine Quelle definiert den verwendeten Protokolladapter und die Werte, die mit diesem Adapter ausgelesen werden müssen. Optional können Transformationen und Aggregationen definiert und auf die gesammelten Daten angewendet werden. Ein Zeitplan gibt auch einen oder mehrere Zieladapter an, an die die gesammelten und verarbeiteten Daten gesendet werden sollen.

Bereitstellung

Der SFC-Core kann als einzelner Prozess bereitgestellt werden, der die konfigurierten Konnektoren und Zieladapter lädt, die vom Benutzer konfiguriert wurden. Alternativ können Protokolladapter, Zieladapter und der SFC-Core als einzelne Dienste bereitgestellt werden, die über einen TCP/IP-Stream kommunizieren, um die gesammelten Daten auszutauschen.

Diese Dienste können sich auf derselben physischen Maschine oder auf separater externer Hardware befinden. Diese Flexibilität ermöglicht Lastausgleich für die Datenerfassung und -verarbeitung und erlaubt die Bereitstellung über Netzwerksegmente mit unterschiedlichen Konnektivitätsanforderungen und -beschränkungen hinweg. Das Diagramm unten zeigt einige Beispielbereitstellunge

SFC-Bereitstellungsbeispiele

SFC-Komponenten benötigen eine Java Virtual Machine zur Ausführung. Komponenten können als eigenständige Anwendung, Container oder als AWS IoT Greengrass-Komponente ausgeführt werden.

Erweiterung von SFC

SFC kann durch die Implementierung neuer Protokolle und Zieladapter in einem unkomplizierten Prozess erweitert werden. Um eine Komponente für einen neuen Adapter zu erstellen, müssen Entwickler die Schnittstelle für den Adapter implementieren, die vom SFC-Core zur Kommunikation mit dem Adapter verwendet wird. SFC ist so konzipiert, dass sich Entwickler auf Protokoll- und Zielimplementierungen konzentrieren können, indem sie den Code von SFC nutzen, ohne dass eine Änderung am Code von SFC erforderlich ist.

SFC ermöglicht auch die Konfiguration angepasster Konfigurationsanbieter, wodurch die Konfiguration aus bestehenden Konfigurationsdatenspeichern ermöglicht wird. Von SFC-Komponenten generierte Metriken können an Amazon CloudWatch-Metriken oder an andere Metrikdatenspeicher unter Verwendung eines konfigurierbaren benutzerdefinierten Metrik-Schreibers gesendet werden.

Protokollausgabedaten können auch in einen benutzerdefinierten Speicher geschrieben werden. Dazu muss ein benutzerdefinierter Protokollschreiber konfiguriert werden.

Beispielkonfiguration OPC UA zu Amazon S3 und AWS IoT Core

Dies ist eine einfache Beispielkonfiguration, die Daten von einem OPC UA-Server liest und sie direkt an ein MQTT-Thema in AWS IoT Core und Objekte in einem Amazon S3-Bucket sendet, ohne weitere Verarbeitung oder Aggregation. Zusätzlich enthält es ein Debug-Ziel, das in der Abbildung unten nicht gezeigt wird. Hier werden die Daten zu Debugging-Zwecken an die Konsole sendet.

SFC-Konfigurationsdatei

{
  "AWSVersion": "2022-04-02",
  "Name": "OPCUA to S3, IoT Core and console",
  "Schedules": [
    {
      "Name": "OPCUA-DATA",
      "Interval": 1000,
      "Sources": {
        "OPCUA-SOURCE": ["*"]
      },
      "Targets": ["IoTCoreTarget", "S3Target", "DebugTarget"]
    }
  ],
  "Sources": {
    "OPCUA-SOURCE": {
      "Name": "OPCUA-SOURCE",
      "ProtocolAdapter": "OPC-UA",
      "AdapterOpcuaServer": "OPCUA-SERVER",
      "SourceReadingMode": "Subscription",
      "Channels": {
        "ServerStatus": {
          "NodeId": "ns=0;i=2256"
        },
        "SimulationCounter": {
          "NodeId": "ns=3;i=1001"
        },
        "SimulationRandom": {
          "NodeId": "ns=3;i=1002"
        },
        "LevelAlarm": {
          "NodeId": "ns=6;s=MyLevel.Alarm",
          "EventType": "ExclusiveLevelAlarmType"
        }
      }
    }
  },
  "ProtocolAdapters": {
    "OPC-UA": {
      "AdapterType": "OPCUA",
      "OpcuaServers": {
        "OPCUA-SERVER": {
          "Address": "opc.tcp://sfc-server",
          "Path": "OPCUA/SimulationServer"
        }
      }
    }
  },
 
  "Targets": {
    "IoTCoreTarget": {
      "TargetType": "AWS-IOT-HTTP",
      "TopicName": "sfc-data-topic",
      "Region": "eu-west-1",
      "CredentialProviderClient": "AwsIotClient"
    },
    "S3Target": {
      "TargetType": "AWS-S3",
      "Region": "eu-west-1",
      "BucketName": "sfc-data-bucket",
      "Interval": 60,
      "BufferSize": 1,
      "CredentialProviderClient": "AwsIotClient",
      "Compression": "Zip"
    },
    "DebugTarget": {
      "TargetType": "DEBUG-TARGET"
    }
  },

  "AdapterTypes": {
    "OPCUA": {
      "JarFiles": ["/sfc/opcua/lib"],
      "FactoryClassName": "com.amazonaws.sfc.opcua.OpcuaAdapter"
    }
  },
 
  "TargetTypes": {
    "AWS-IOT-HTTP": {
      "JarFiles": ["/sfc/aws-iot-http-target/lib"],
      "FactoryClassName": "com.amazonaws.sfc.awsiot.http.AwsIotHttpTargetWriter"
    },
    "AWS-S3": {
      "JarFiles": ["/sfc/aws-s3-target/lib"],
      "FactoryClassName": "com.amazonaws.sfc.awss3.AwsS3TargetWriter"
    },
    "DEBUG-TARGET": {
      "JarFiles": ["/sfc/debug-target/lib"],
      "FactoryClassName": "com.amazonaws.sfc.debugtarget.DebugTargetWriter"
    }
  },
 
  "AwsIotCredentialProviderClients": {
    "AwsIotClient": {
      "IotCredentialEndpoint": "1234567890abcd.credentials.iot.eu-west-1.amazonaws.com",
      "RoleAlias": "TokenExchangeRoleAlias",
      "ThingName": "MyThingName",
      "Certificate": "/sfc/cert/certificate.crt",
      "PrivateKey": "/sfc/cert/private.key",
      "RootCa": "/sfc/cert/root.pem"
    }
  }
}

Schlüsselelemente der Konfiguration

Schedules: Die Konfiguration dreht sich um Zeitpläne (Schedules), in diesem Fall beispielhaft durch ‚OPCUA-DATA‘ dargestellt. Dieser Zeitplan umrfasst die Quellen für die Datenabfrage, legt das Erfassungsintervall in Millisekunden fest und bestimmt die Zielorte für die Datenübermittlung.

Sources: Dieser Abschnitt beschreibt die Quellen (Sources) für die Datenextraktion. In diesem Beispiel wird eine einzelne OPC UA-Quelle definiert. Innerhalb dieser Quelle sind Details wie der Adaptername und der spezifische Server innerhalb dieses Adapters, von dem die Daten bezogen werden, enthalten. Die Kanäle verkörpern konkrete Datenelemente, die auf verschiedene Arten von Quelladaptern zugeschnitten sind. Im Kontext des OPC UA-Adapters in diesem Beispiel repräsentieren diese Kanäle Datenelemente wie Datenknoten, Ereignisse oder Alarme – jedes durch seine eindeutige Knoten-ID identifiziert.

ProtocolAdapters: Die verwendeten Protokolladapter (Protocol adapters)werden in diesem Abschnitt definiert. Jeder Protokolladaptertyp hat seine eigenen spezifischen Elemente. Im Fall des verwendeten OPC UA-Adapters gibt es eine Definition des tatsächlichen OPC UA-Servers, von dem die Daten für eine Quelle gelesen werden.

Targets: In diesem Abschnitt werden die Ziele (Targets) definiert, an die Daten geliefert werden können. Jeder Zieltyp hat seine spezifischen Elemente, wie den Namen des Amazon S3-Buckets für das Amazon S3-Ziel oder den Topicnamen für den AWS IoT Core-Adapter.

AdapterTypes und TargetTypes: Jede Adapter- und Zieldefinition bezieht sich auf ihre Adapter- oder Zieltypen, die im Abschnitt AdapterTypes oder TargetTypes konfiguriert werden müssen. Jeder Typ definiert, von wo die JAR-Dateien, die den Adapter oder das Ziel implementieren, geladen werden können und den Namen der Fabrikklasse, um Instanzen davon zu erstellen. SFC-Core wird diese Informationen verwenden, um Instanzen der erforderlichen Adapter und Ziele zu erstellen. (Hinweis: Diese Abschnitte sind nur erforderlich, wenn der Adapter oder das Ziel im gleichen Prozess wie der SFC-Kern läuft. Wenn ein Adapter oder Ziel als IPC-Dienst ausgeführt wird, verweist der Adapter auf einen Protokoll- oder Zielserver, der die Adresse und den Port definiert, unter dem er erreichbar ist.)

AWS IoT Credential Provider Clients: Dieser Abschnitt definiert die Clients, die von Zielen verwendet werden, die Zugriff auf AWS-Dienste benötigen. Jeder Client verwendet einen Satz von X.509-Zertifikaten und Schlüsseldateien, um temporäre Anmeldeinformationen zu erhalten. Der Rollenalias verweist auf eine Rolle, die Zugriff auf AWS-Dienste gewährt. Weitere detaillierte Informationen finden Sie im AWS Security Blog-Beitrag „How to Eliminate the Need for Hardcoded AWS Credentials in Devices by Using the AWS IoT Credentials Provider“.

Erste Schritte mit SFC

SFC wird als Quellcode bereitgestellt und kann von https://github.com/aws-samples/shopfloor-connectivity bezogen werden. Das SFC-Repository auf GitHub enthält umfangreiche Dokumentation, einschließlich detaillierter Beispiele zur Konfiguration von SFC und zur Erstellung benutzerdefinierter Komponenten. Vorgefertigte SFC-Pakete können von https://github.com/aws-samples/shopfloor-connectivity/releases heruntergeladen werden.

Das SFC-Repository enthält auch einen umfassenden Schnellstartleitfaden, der die erforderlichen Schritte zur Bereitstellung und Konfiguration von SFC für das in diesem Artikel verwendete Beispiel beschreibt.

Fazit

SFC ist eine freie, leistungsstarke Technologie, die es ermöglicht, Daten aus einer Vielzahl von gängigen, industriellen Datenquellen auszulesen und an AWS-Dienste für die weitere Analyse zu senden oder lokal verfügbar zu machen. Die Konfigurierbarkeit via JSON-Dateien ermöglicht einen hohen Automatisierungsgrad, da JSON-Dateien prinzipiell maschinell aus bestehenden Informationen erzeugt werden können. Außerdem bietet sie viele weitere Funktionen wie z.B. Datentransformation oder Filter, die weitere wichtige Aspekte der industriellen Datenverarbeitung adressieren.

Über die Autoren

Arie Leeuwesteijn, Principal Solutions Builder bei Amazon Web Services (AWS), ist spezialisiert auf die Entwicklung von Cloud-Lösungen, die auf industrielle und fertigende Kunden zugeschnitten sind. Mit seiner Expertise in der Beratung von Großkunden ermöglicht er die praktische Anwendung von Cloud-Diensten zur Optimierung von Betriebsabläufen und zur Steigerung des Geschäftswerts.