Freigeben über



August 2019

Band 34, Nummer 8

[Blockchain]

Schutz Ihrer Lieferkette mit Azure IoT und der Blockchaincloud

Von Stefano Tempesta | August 2019

Der Einsatz von Blockchain- und IoT-Technologien hat das Potenzial, die Fertigungsindustrie dabei zu unterstützen, Lieferketten sicherer und die damit verbundenen Prozesse transparenter zu gestalten. Wahrscheinlich haben Sie von Blockchain nur im Zusammenhang mit Kryptowährungen gehört. Wie also ist Blockchain für Lieferketten relevant?

Ein Beispiel für eine Verteilungslieferkette

Die traditionelle Lieferkettenverwaltungsstruktur weist Einschränkungen bezüglich der Zuverlässigkeit und Genauigkeit der Messungen sowie der Transparenz der Prozesse zwischen allen beteiligten Parteien auf. IoT- und Blockchaintechnologien stellen eine mögliche Lösung dar, um diesen Herausforderungen zu begegnen, indem sie Geräte zur Automatisierung der Erfassung von Metriken in jeder Phase der Lieferkette sowie einen verteilten digitalen Ledger zur unveränderlichen Speicherung von Transaktionsprotokollen einführen. Darüber hinaus können Smart Contracts in Blockchain regelbasierte Intelligenz nutzen, um die Validierung dieser Daten durchzuführen und den Zustand jeder Stufe der Lieferkette für alle Beteiligten absolut vertrauenswürdig und transparent zu aktualisieren. So können beispielsweise Bestimmungen, Bedingungen und jede beliebige andere Programmlogik in einem Smart Contract codiert werden, um die ordnungsgemäße Durchführung einer Transaktion von Waren zwischen zwei Stufen der Lieferkette zu überprüfen.

Abbildung 1 vereinfacht eine Verteilungslieferkette, in der ein Lebensmittelhersteller Waren zur Verpackung und zum Versand an einen Lebensmittelverarbeiter übergibt. Die Waren werden bei einer bestimmten Temperatur und Luftfeuchtigkeit versiegelt, und diese oder ähnliche Bedingungen müssen während des Transports zum Lager und Einzelhandel eingehalten werden.

Eine Verteilungslieferkette mit einem Smart Contract
Abbildung 1: Eine Verteilungslieferkette mit einem Smart Contract

Diese Bedingungen werden in einem Blockchain Smart Contract codiert, wie später in diesem Artikel gezeigt wird. In den Containern und Transportmitteln, in denen Waren gelagert und transportiert werden, sind IoT-Geräte mit Sensoren zur Messung von Temperatur und Luftfeuchtigkeit installiert. Telemetriedaten werden in regelmäßigen Intervallen während der Lagerungs- und Verteilungsphase erfasst und die tatsächlichen Metriken mit den im Smart Contract festgelegten Werten verglichen. Wenn die Werte für Temperatur oder Luftfeuchtigkeit diese Werte überschreiten, ändert sich der Zustand des Transports der Waren in „out of compliance“ (nicht vorschriftsgemäß), und dieser Zustand spiegelt sich im Transaktionsprotokoll wider, das im digitalen Blockchain-Ledger gespeichert ist. Alle Beteiligten in der Lieferkette können den Zustand und die Details des Vertrags zu jedem Zeitpunkt einsehen. Die für die Lagerung oder den Transport von Waren verantwortliche Gegenpartei gibt die nächste Gegenpartei, die mit den Paketen befasst ist, als nächste Stufe an, und die registrierten IoT-Geräte leiten Telemetriedaten an einen zentralen IoT-Hub weiter. Auf diese Weise können der Initiator der Lieferkette und alle ihre Beteiligten feststellen, welche Gegenpartei die Compliancevorschriften nicht erfüllt hat, wenn zu irgendeinem Zeitpunkt im Prozess entweder die Temperatur- oder die Luftfeuchtigkeitsanforderungen nicht eingehalten wurden.  

Eine Lieferkette erfordert ein Zustandsübergangsdiagramm, um die möglichen Flows und die verschiedenen Übergangsfunktionen in jedem Zustand anzugeben. Jede Partei in der Lieferkette darf nur bestimmte Maßnahmen ergreifen, die von ihrer Rolle und dem Zustand der zu transportierenden Produkte abhängen. Zustände, Workflows und Beteiligte werden in einem Smart Contract beschrieben und in Azure Blockchain Workbench bereitgestellt, wie später in diesem Artikel beschrieben wird. Das hier vorgestellte Beispiel implementiert die vier in Abbildung 2 dargestellten Zustände.

Abbildung 2: Die vier Zustände der Beispiellieferkette

Bundesstaat Beschreibung
Erstellt Gibt an, dass der Vertrag initiiert wurde und die Nachverfolgung läuft.
InTransit Gibt an, dass eine andere Partei derzeit Güter besitzt und für deren Transport verantwortlich ist.
Abgeschlossen Gibt an, dass das Produkt sein beabsichtigtes Ziel erreicht hat.
OutOfCompliance Gibt an, dass die vereinbarten Bestimmungen für die Temperatur und Luftfeuchtigkeit der Umgebung nicht eingehalten wurden.

Azure IoT Central

Das Beispiel in diesem Artikel verwendet Azure IoT Central (bit.ly/2X6Jlwe), um die IoT-Geräte zu verbinden. IoT Central ist eine vollständig verwaltete SaaS-Lösung (Software-as-a-Service), die es einfach macht, Geräte im richtigen Maßstab zu verbinden, zu überwachen und zu verwalten. Die Erstkonfiguration von Geräten wird durch die Verwendung von Gerätevorlagen für verschiedene Plattformen vereinfacht, und die Projektimplementierung der IoT-Komponente der Lieferkettenlösung kann zu Testzwecken von der Gerätesimulation profitieren.

Die für die Verteilungslieferkette im aktuellen Beispiel implementierte IoT-Lösung besteht aus einem cloudbasierten Gateway, das Telemetriedaten von Gerätesensoren und den mit IoT Central verbundenen Geräten selbst empfängt. Bevor IoT-Geräte Daten streamen dürfen, werden sie bei der Cloudplattform registriert, und ihnen wird eine Identität zugewiesen. Beim Herstellen einer Verbindung mit IoT Central sendet ein Gerät seine Identitätsinformationen zusammen mit Sensordaten. Wenn das Gerät diese Identitätsinformationen nicht sendet, schlägt die Verbindung fehl. Sobald eine erfolgreiche Verbindung zwischen den Geräten und dem Cloudgateway hergestellt wurde, werden in festgelegten Intervallen Daten erfasst. Azure IoT Central erleichtert diesen Prozess durch die Bereitstellung von Funktionen zur Geräteregistrierung und Datenerfassung sowie zur Visualisierung von Telemetriepunkten auf einem Dashboard, wie in Abbildung 3 dargestellt.

Das Dashboard von Azure IoT Central
Abbildung 3: Das Dashboard von Azure IoT Central

Abbildung 3 zeigt Messwerte, die von einem simulierten Gerät erzeugt wurden. In Azure IoT Central können Sie eine Gerätevorlage für die Geräte definieren, die eine Verbindung mit Ihrer Anwendung herstellen, eine Art Blaupause, die die Eigenschaften und das Verhalten eines Gerätetyps definiert. Eine Vorlage kann für die Verbindung eines physischen Geräts oder für die Simulation des Streamings von Daten innerhalb bestimmter Grenzen verwendet werden. Zu den simulierten Daten gehören:

  • Geräteeigenschaften, die von einem Gerät festgelegt werden und in der Anwendung schreibgeschützt sind.
  • Der Status, der das Verhalten des Geräts festlegt.
  • Spezifische Messungen für die installierten Sensoren.

Die Einrichtung einer Anwendung in IoT Central beginnt damit, dass mindestens eine Gerätevorlage definiert und dann ein Gerät hinzugefügt wird, entweder ein echtes oder ein simuliertes Gerät. Sie können auf das IoT Central Dashboard unter bit.ly/2RBtWD6 zugreifen und dann zur Seite „Application Manager“ (Anwendungs-Manager) von Azure IoT Central navigieren, um mit der Erstellung einer neuen Azure IoT Central-Anwendung zu beginnen. Sobald Sie eine Anwendung erstellt haben, greifen Sie auf den Abschnitt „Device Explorer“ (Geräte-Explorer) zu, um ein echtes oder simuliertes Gerät hinzuzufügen, das jeder Gerätevorlage in der Anwendung zugeordnet ist. Wenn Sie eine Gerätevorlage erstellen, generiert Azure IoT Central aus der Vorlage ein simuliertes Gerät. Das simulierte Gerät generiert Telemetrie, mit der Sie das Verhalten Ihrer Anwendung testen können, bevor Sie ein echtes Gerät verbinden. Auf der Registerkarte „Measurements“ (Messwerte) können Sie die vom Gerät gesendeten Messwerte wie Telemetrie, Ereignis und Zustand angeben und die dem Gerät zugeordneten Regeln definieren.

Nachdem Sie ein Gerät und seine Messwerte eingerichtet haben, können Sie mithilfe von Ereignissen Zeitpunktdaten definieren, die das Gerät senden soll, wenn ein Ereignis wie ein Fehler oder ein Komponentenausfall eintritt. Azure IoT Central kann Geräteereignisse simulieren, damit Sie das Verhalten Ihrer Anwendung testen können, bevor Sie ein echtes Gerät verbinden. Nach kurzer Zeit wird auf der Registerkarte „Measurements“ (Messwerte) ein Diagramm der zufällig von Ihrem simulierten verbundenen Gerät generierten Ereignisse angezeigt.

Schließlich erstellen Sie eine Regel, die eine benutzerdefinierte Aktion ausführt, wenn die gemessene Temperatur oder Luftfeuchtigkeit die angegebenen Bedingungen überschreitet. In diesem Fall habe ich eine Microsoft Flow-Aktion konfiguriert (wie in Abbildung 4 gezeigt), die ausgeführt werden soll, wenn die Luftfeuchtigkeit größer als 60 und die Temperatur höher als 8 ist.

Konfigurieren einer Microsoft Flow-Aktion
Abbildung 4 Konfigurieren einer Microsoft Flow-Aktion

Microsoft Flow

Warum Flow? Blockchainnetzwerke sind von der Außenwelt isoliert, sodass keine Daten eingebracht werden können, die „außerhalb der Kette“ generiert wurden. Smart Contracts arbeiten mit Daten, die in der Blockchain selbst gespeichert sind. Das Azure Blockchain Development Kit (bit.ly/2TkG23Z) ist eine Erweiterung der Möglichkeiten von Azure Blockchain Workbench (gleich mehr dazu). Das Blockchain Development Kit integriert Azure-Dienste für Schlüsselverwaltung, Off-Chain-Identität und -Daten, Überwachung und Messaging-APIs in eine Referenzarchitektur, die zum schnellen Erstellen von blockchainbasierten Anwendungen verwendet werden kann, die sich in jedes beliebige externe System integrieren lassen. Mit Flow ist es möglich, eine Nachricht an Azure Service Bus zu senden, der als Teil von Azure Blockchain Workbench bereitgestellt wird, und Daten sicher an einen digitalen Blockchain-Ledger zu übertragen. Abbildung 5 zeigt den Trigger des Flows, wenn eine Regel in IoT Central ausgelöst wird.

Auslösen eines Flows in IoT Central
Abbildung 5: Auslösen eines Flows in IoT Central

Anschließend wird eine Nachricht vorbereitet und schließlich in Service Bus von Azure Blockchain Workbench gemäß dem auf der REST-API basierenden Integrationsmuster platziert, das unter bit.ly/31WqmIs beschrieben wird. Bei der Vorbereitung der Nachricht zum Senden an Service Bus werden die folgenden Parameter als Teil des Flows selbst erstellt:

  • requestId: Ein eindeutiger Wert zum Identifizieren einer Anforderung. In Flow kann dies durch eine Variable mit der GUID des Ausdrucks implementiert werden.
  • timestamp: Das Datum und die Uhrzeit der Anforderung. In Flow kann dies durch Extrahieren der Ticks für den aktuellen zeitlichen Moment abgerufen werden. Da eine Sekunde jedoch 10 Millionen Ticks aufweist, würde dies zu einer extrem großen Zahl führen. Ich berechne daher normalerweise die aktuelle Unix-Zeit (Epoch), also die Anzahl von verstrichenen Sekunden seit dem 1. Januar 1970 (Mitternacht UTC).

In Flow kann ein Zeitstempel einfach mit dem Subtraktionsausdruck berechnet werden:

sub(variables('TicksNow'), variables('TicksUnixEpoch'))

Hier ist TicksNow eine Integervariable, die als ticks(utcNow()) definiert ist, und TicksUnixEpoch ist eine weitere Variable, die als ticks('1970-01-01-01') definiert ist.

Für die Service Bus-Nachricht ist außerdem Folgendes erforderlich:

  • userChainIdentifier: Die Blockchainadresse des Benutzers oder Geräts, der bzw. das im Blockchainnetzwerk erstellt wurde.
  • contractLedgerIdentifier: Die Blockchainadresse des Vertrags im Ledger.
  • workflowFunctionName: Der Name der aufzurufenden Funktion des Smart Contracts.
  • Parameter: Ein Array von Objekten, die Telemetriedaten identifizieren.

Das JSON-Format dieser Nachricht ist wie folgt:

{
  "requestId": "",
  "userChainIdentifier": "",
  "contractLedgerIdentifier": "",
  "workflowFunctionName": "ReadTelemetry",
  "Parameters": [
    { "name": "humidity", "value": "" },
    { "name": "temperature", "value": "" }
    { "name": "timestamp", "value": "" }
  ]
}

Azure Blockchain Workbench

Das ursprüngliche Ziel der Blockchaintechnologie war es, vertrauenswürdige Fiskaltransaktionen zwischen zwei Parteien zu ermöglichen, ohne dass ein Dritter (beispielsweise eine Bank) involviert sein musste. Da eine Blockchain auf einem dezentralen, vernetzten System basiert, ist es schwieriger, sie zu beschädigen. Wenn die Informationen für einen der Blöcke bearbeitet werden, können alle anderen, die diesen Block anzeigen, die vorgenommenen Änderungen sehen. Die Einführung der Blockchaintechnologie in Lieferketten kann dazu beitragen, Probleme wie Betrug und Fälschung zu verhindern. Transaktionen für die Blockchain werden gespeichert und auf mehrere Knoten im Netzwerk verteilt. Diese Transaktionen oder Datensätze sind aufgrund der Funktionsweise der Blockchain sehr sicher (weitere Informationen zur Cybersicherheit mit Blockchain finden Sie in meinem Artikel unter bit.ly/2ZQcm16), was diese Technologie zur perfekten Methode für die transparente und sichere Aufzeichnung von Transaktionen in einem unabhängigen und unveränderlichen Protokoll werden lässt. Im Rahmen einer Lieferkette überprüfen und erzwingen Blockchain Smart Contracts neben einem Transaktionsprotokoll auch eine Vereinbarung zwischen mindestens zwei an einer Transaktion beteiligten Parteien. Smart Contracts ermöglichen es, dass glaubwürdige Transaktionen ohne Autorisierung und Überprüfung durch eine zentrale Instanz durchgeführt werden können. Außerdem sind diese Transaktionen nachverfolgbar und unwiderruflich.

Der Blockchain-Ledger in dieser Lösung wird in Azure gehostet. Es handelt sich um eine Ethereum-Installation, die als Teil von Azure Blockchain Workbench bereitgestellt wird. Mit Azure Blockchain Workbench (bit.ly/2XBhWqw) können Sie ein Konsortiumnetzwerk in nur wenigen Minuten konfigurieren und bereitstellen, dank automatischer Ledgerbereitstellung, Netzwerkerstellung und vordefinierten Blockchainbefehlen, die die Bereitstellungszeit für die Infrastruktur erheblich verkürzen. Sobald die erforderliche Infrastruktur bereitgestellt wurde, können Sie Ihre Smart Contracts codieren und anschließend in Blockchain Workbench zur Ausführung bereitstellen. Blockchain Workbench erstellt nach dem Workflow Ihres Smart Contracts automatisch und ohne Programmierung eine Webbenutzeroberfläche und ermöglicht es Ihnen, jede Statusänderung nachzuverfolgen. So sendet beispielsweise die von IoT Central über Flow gesendete Nachricht die Messwerte für Temperatur und Luftfeuchtigkeit. Ein Smart Contract validiert diese Werte, und wenn sie nicht den im Smart Contract selbst codierten Bedingungen entsprechen, legt er den Status dieser Transaktion auf „Out of Compliance“ (Nicht vorschriftsgemäß) fest. Diese Stufe der Lieferkette ist dann ungültig, und der Prozess wird (oder sollte) nicht zur nächsten Stufe übergehen. Abbildung 6 zeigt die erste Stufe der Ausführung des Smart Contract „Telemetry“, der in dieser Lieferkettenlösung verwendet wird: Zwischen zwei Parteien wird ein neuer Vertrag abgeschlossen, ein Gerät zur Erfassung von Telemetriedaten wird registriert, und die Ausgangsbedingungen für Luftfeuchtigkeit und Temperatur werden festgelegt.

Die erste Stufe der Ausführung des Smart Contract „Telemetry“
Abbildung 6: Die erste Stufe der Ausführung des Smart Contract „Telemetry“

Der Smart Contract „Telemetry“ in Abbildung 7, der in der Solidity-Programmiersprache (solidity.readthedocs.io) für die Ethereum-Plattform implementiert ist, definiert Parteien, Eigenschaften und Zustände, die zusammengenommen eine Darstellung des Status des Vertrags zu einem bestimmten Zeitpunkt sind. Lieferkettenparteien werden durch eine Blockchainadresse identifiziert. In Azure Blockchain Workbench ist dies die Benutzer- oder Geräteadresse, die auf der Plattform registriert ist. Um auf Blockchain Workbench zugreifen zu können, müssen die Parteien in Azure Active Directory registriert sein. Zustände stellen eine Enumeration von Stufen im Prozess der Lieferkette dar (Vertrag erstellt, Waren im Übergang, Transaktion abgeschlossen oder als nicht vorschriftsgemäß erfasst) sowie die beiden verschiedenen Arten von Sensoren, die in diesem Beispiel verwendet werden (Luftfeuchtigkeit und Temperatur). Die Enumeration ermöglicht es, weitere Einträge einfach hinzuzufügen, wenn der Lieferkettenprozess zusätzliche Stufen erfordert oder andere Sensortypen eingeführt werden.

Abbildung 7: Der Smart Contract „Telemetry“

contract Telemetry
{
  // States
  enum StateType { Created, InTransit, Completed, OutOfCompliance }
  enum SensorType { None, Humidity, Temperature }
  // Parties
  address public Owner;
  address public InitiatingCounterparty;
  address public Counterparty;
  address public PreviousCounterparty;
  address public Device;
  address public SupplyChainOwner;
  address public SupplyChainObserver;
  // Properties
  StateType public State;
  SensorType public ComplianceSensorType;
  int public MinHumidity;
  int public MaxHumidity;
  int public MinTemperature;
  int public MaxTemperature;
  int public ComplianceSensorReading;
  bool public ComplianceStatus;
  string public ComplianceDetail;
  int public LastSensorUpdateTimestamp;

Die Benutzeroberfläche für die Eingabe eines neuen Vertrags in Blockchain Workbench wird automatisch basierend auf dem Konstruktor des Smart Contract „Telemetry“ in Abbildung 8 generiert. Dieser Konstruktor legt die Ausgangsbedingungen für den Transportprozess fest, die von allen an der Lieferkette beteiligten Parteien erfüllt werden müssen. Es legt außerdem den Anfangszustand auf StateType.Created fest.

Abbildung 8: Der Konstruktor des Smart Contract „Telemetry“

constructor(address device, address supplyChainOwner, address supplyChainObserver,
  int minHumidity, int maxHumidity, int minTemperature, int maxTemperature) public
{
  ComplianceStatus = true;
  ComplianceSensorReading = -1;
  InitiatingCounterparty = msg.sender;
  Owner = InitiatingCounterparty;
  Counterparty = InitiatingCounterparty;
  Device = device;
  SupplyChainOwner = supplyChainOwner;
  SupplyChainObserver = supplyChainObserver;
  MinHumidity = minHumidity;
  MaxHumidity = maxHumidity;
  MinTemperature = minTemperature;
  MaxTemperature = maxTemperature;
  State = StateType.Created;
  ComplianceDetail = "N/A";
}

Wenn schließlich Telemetriedaten gestreamt werden und eine Regelausnahme in IoT Central auftritt, wird der zuvor beschriebene Flow ausgeführt, der wiederum eine Nachricht an Blockchain Workbench sendet, um die ReadTelemetry-Funktion in Abbildung 9 aufzurufen. Diese Funktion validiert die vom IoT-Gerät aufgezeichneten Eingabewerte für Luftfeuchtigkeit oder Temperatur und löst einen Zustand „Out-of-Compliance“ (Nicht vorschriftsmäßig) aus, wenn die in der ersten Stufe festgelegten Bedingungen nicht erfüllt sind.

Abbildung 9: Die ReadTelemetry-Funktion

function ReadTelemetry(int humidity, int temperature, int timestamp) public
{
  if (Device != msg.sender)
  {
    revert();
  }
  if (State == StateType.Completed || State == StateType.OutOfCompliance)
  {
    revert();
  }
  LastSensorUpdateTimestamp = timestamp;
  if (humidity < MinHumidity || humidity > MaxHumidity)
  {
    ComplianceSensorType = SensorType.Humidity;
    ComplianceSensorReading = humidity;
    ComplianceDetail = "Humidity value out of range.";
    ComplianceStatus = false;
  }
  else if (temperature < MinTemperature || temperature > MaxTemperature)
  {
    ComplianceSensorType = SensorType.Temperature;
    ComplianceSensorReading = temperature;
    ComplianceDetail = "Temperature value out of range.";
    ComplianceStatus = false;
  }
  if (ComplianceStatus == false)
  {
    State = StateType.OutOfCompliance;
  }
}

Aus Sicht der Benutzeroberfläche zeichnet Blockchain Workbench automatisch jede Zustandsänderung auf und aktualisiert den Gesamtstatus des Smart Contract „Telemetry“ entsprechend, wie in Abbildung 10 gezeigt wird.

Der aktualisierte Smart Contract „Telemetry“
Abbildung 10: Der aktualisierte Smart Contract „Telemetry“

Zusammenfassung

Die Azure-Plattform bietet eine Reihe von Diensten zum Erstellen von vollständig integrierten Lösungen für die Anforderungen von Industry 4.0. Dies schließt die IoT-Plattform und verwaltete Blockchaindienste ein. In diesem Artikel habe ich ein allgemeines Blockchainmuster für die IoT-fähige Überwachung von Waren beschrieben, während sie sich entlang einer Lieferkette mit mehreren Parteien bewegen. Während des gesamten Transportprozesses müssen spezifische Complianceregeln eingehalten werden. In diesem Szenario legt eine initiierende Partei vertragliche Bedingungen fest, z.B. einen erforderlichen Luftfeuchtigkeits- und Temperaturbereich, an den sich ein Transportunternehmen in der Lieferkette halten muss. Wenn das Gerät eine Temperatur- oder Luftfeuchtigkeitsmessung durchführt, die außerhalb des gültigen Bereichs liegt, wird der Status des Smart Contract aktualisiert, um anzuzeigen, dass er nicht konform ist. Es wird eine Transaktion für die Blockchain aufgezeichnet, und es werden in der Folge Korrekturmaßnahmen ausgelöst.

Für diejenigen unter Ihnen, die mehr darüber erfahren möchten, ist die Azure Referenzarchitektur für die Lieferkette ein guter Ausgangspunkt, die Sie unter bit.ly/2X7NIr7 finden.


Stefano Tempestaist Microsoft Regional Director, MVP für Azure, KI und Business Applications und Mitglied des Blockchain Councils. Tempesta ist regelmäßiger Referent auf internationalen IT-Konferenzen, darunter Microsoft Ignite and Tech Summit, und interessiert sich für blockchain- und KI-bezogene Technologien. Er hat Blogchain Space (blogchain.space) ins Leben gerufen, einen Blog über Blockchaintechnologien, schreibt für MSDN Magazine und MS Dynamics World und veröffentlicht Machine Learning-Experimente im Azure KI-Katalog (gallery.azure.ai).

Unser Dank gilt dem folgenden technischen Experten bei Microsoft für die Durchsicht dieses Artikels: Danilo Diaz


Diesen Artikel im MSDN Magazine-Forum diskutieren