Supply Chain – Wie die Blockchain Lieferketten in der Corona Pandemie absichert

2020 hat uns gezeigt, wie eine Pandemie eingespielte Prozesse und sichergeglaubte Annahmen erschüttern kann. Damit meine ich nicht den Blick in die leeren Klopapier-Regale deutscher Supermarktketten, sondern die Anfälligkeit vernetzter Lieferketten: Gerade in der ersten Welle der Corona-Pandemie standen ganze Industriezweige zeitweise still, weil einzelne Stationen komplexer globaler Lieferantennetzwerke unterbrochen waren.

Im Bestreben Lagerkosten zu reduzieren und Lieferzeiten zu verkürzen, hat die Abhängigkeiten moderner just-in-time Produktionen von reibungslos funktionierenden Supply Chain-Prozessen in den letzten Jahren immer weiter zugenommen. Das gilt umso mehr, wenn es sich um sensible Lieferketten mit spezifischen Anforderungen an Sicherheits-, Feuchtigkeits- oder Temperaturbedingungen handelt. Schon 2017 habe ich einen Beitrag über die Lufthansa Cargo gesehen, die Rosen aus Afrika nach Frankfurt transportiert. Zur Sicherung der Qualität ist es in diesem Fall sehr wichtig, die Kühlkette einzuhalten und ggf. auch deren Einhaltung nachweisen zu können, da dies eine Gewährleistungsrelevanz hat. Diese Einhaltung wird regelmäßig entlang der gesamten Lieferkette stichprobenartig manuell geprüft.

Aktuell gewinnt diese Thematik im Zuge der Corona-Impfstoff-Transporte erneut Relevanz. Denn je nach Präparat müssen bei Transport und Lagerung Temperaturen von -70°C eingehalten werden. Heute kommen bereits Datenlogger zum Einsatz, die nach der Lieferung ausgelesen werden können. Nur dann ist es oft zu spät, wenn die Kühlkette unterbrochen war. In diesem Beitrag möchte ich deshalb die Einsatzmöglichkeiten von IoT und Blockchain-Technologie im Kontext von Lieferketten aufzeigen und anhand eines kleinen Prototyps die Funktionsweise erläutern.

Lieferkettentransparenz bedeutet Gesundheitsschutz

Epidemien und Pandemien gab es schon vor CORONA. 2011 infizierten sich 3.800 Menschen mit den Enterohämorrhagische Escherichia Coli (EHEC) Bakterien, 53 Personen verstarben. Auslöser waren vermutlich Sprossen, die aus Bockshornkleesamen gezogen wurden und aus Ägypten stammten. Ein eindeutiger Beweis konnte aufgrund nicht sicher reproduzierbarer Lieferketten nie erbracht werden. Allein in der EU erkranken laut WHO mehr als 23 Mio. Menschen jährlich am Verzehr verunreinigter Lebensmittel, ca. 4.700 Erkrankte sterben pro Jahr an den Folgen solcher Infektionen.
An diesen Zahlen lässt sich der Zusammenhang zwischen transparenten, nachvollziehbaren Lieferketten und einem effektiven Infektionsschutz ablesen. In der Praxis weisen diese heute jedoch noch immer einige Schwächen auf:

• Kein zentraler Zugriff auf alle Daten in der Lieferkette (Informationsteile liegen oft nur bei den für den Lieferabschnitt Zuständigen)
• Viele manuelle Verarbeitungsschritte in der Prozesskette (z.B. Lieferscheine/ Frachtpapiere)
• Daraus ergibt sich, dass eine schnelle und lückenlose Nachverfolgung ein sehr aufwändiger Prozess ist

Die Blockchain- bzw. Distributed-Ledger-Technologie hat das Potenzial, einige der angesprochenen Probleme zu überwinden. Um zu zeigen, wie eine solche Lösung technisch umgesetzt werden kann, habe ich einen Blockchain-basierten Prototypen entwickelt, der im Folgenden beschrieben werden soll. Wer noch einmal in die technologischen Grundlagen einsteigen möchte, dem empfehle ich die Artikelreihe „Wie funktioniert eigentlich die Blockchain?“.

Nachverfolgung von Lieferketten inkl. Sensordaten

Zur Lösung der angesprochenen Probleme intransparenter Lieferketten ist eine Kombination unterschiedlicher Technologien erforderlich. Das betrifft auf der einen Seite Sensorik, die, wie im Fall der Rosen, die Temperatur misst. Auf der anderen Seite sollen die Informationen allen Beteiligten der Lieferkette unverfälscht und sicher zur Verfügung gestellt werden, aber auch an Transitionspunkten automatisiert Aktionen ausführen (z.B. Rechnungsstellungen veranlassen).

Im vorliegenden Prototyp verwende ich dafür das IOTA Protokoll. IOTA versteht sich als sicheres Kommunikations- und Zahlungsmedium für das Internet of Things (IoT). Ein Grund für die Wahl von IOTA ist die intensive Beschäftigung damit (s. "Was kommt nach der Blockchain?"). Grundsätzlich kann aber auch jede andere Distributed-Ledger-Technologie eingesetzt werden. Der zweite Teil der Auswahl begründet sich mit dem verfügbaren Masked Authenticated Messaging (MAM) Protokoll. Dabei handelt es sich um ein Second Layer Datenübertragungsprotokoll, das es Sensoren ermöglicht, ganze Datenströme zu verschlüsseln und im IOTA Tangle (Details zum Tangle s. "Was kommt nach der Blockchain?") zu verankern. Damit stehen Funktionen für das Senden und den Zugriff auf diesen verschlüsselten Datenstrom zur Verfügung. Mittlerweile ist die Weiterentwicklung des MAM Protokolls unter dem Begriff IOTA Streams zu finden.

Als IoT Gerät dient ein Aufbau, der verschiede Sensoren vereint, die über einen raspberry pi3+ angebunden sind. Dies ist eine einfache und schnelle Möglichkeit für die prototypische Umsetzung der Sensorik. Die verwendeten Sensoren (siehe Abbildung 1) stellen eine mögliche Konfiguration dar, die natürlich in Abhängigkeit des jeweiligen Use Cases spezifiziert werden kann.

Abbildung 1: Platine mit Sensoren

Die Messdaten der Sensoren werden mittels MAM-Protokoll an das IOTA Tangle übertragen. Die Visualisierung der Daten erfolgt über eine Web-Anwendung, die die Daten aus dem Tangle abrufen und visualisieren kann.

Abbildung 2: Prototyp Gesamtaufbau

Im vorliegenden Prototyp erfolgt die Messung und das Übertragen des Datensatzes an das Tangle durch einen Trigger, der über den RFID Leser ausgelöst wird. Dies ermöglicht es, über die RFID Tags eine konkrete Zuordnung in der beispielhaften Supply Chain abzubilden.

Abbildung 3: Beispiel Supply Chain

In dem konkreten Beispiel ist jedem RFID Tag ein konkreter Ein- und Ausgangspunkt der Supply Chain (s. Abbildung 3) zugeordnet. So kann für jeden Transitionspunkt die Messung und der Transfer der Sensordaten getriggert und eindeutig dem Transitionspunkt zugeordnet werden. In der praktischen Umsetzung hängt dies natürlich vom konkreten Use Case ab. Bei der Einhaltung von Kühlketten ist beispielsweise eine kontinuierliche Messung der Temperatur auf den Transportwegen sinnvoll. In anderen Fällen ist eine Übertragung von Messwerten evtl. ausreichend bei der Überschreitung von Grenzwerten.

Dadurch entsteht ein extrem breites Spektrum an Einsatzmöglichkeiten, die sich auch auf reine Transportketten fokussieren können. In solchen Fällen ist es oft interessant, die Gefahrenübergänge zwischen den einzelnen Logistikpartnern zurückzuverfolgen.

Abbildung 4: Beispiel Nachverfolgung einer Lieferkette

Über die fälschungssichere Dokumentation der jeweiligen Transitionspunkte, lassen sich eindeutig und transparent Zuständigkeiten und damit Verantwortlichkeiten für die Transportabschnitte abbilden. Das kann etwa eingesetzt werden, um Ansprüche, z.B. bei Lieferverzögerungen, geltend zu machen.

Funktionsweise

Wie im vorherigen Kapitel kurz angesprochen, basiert die Umsetzung des Prototyps auf dem IOTA MAM Protokoll bzw. Streams. Streams ist als kryptographisches Framework zu verstehen, welches es ermöglicht, ganze Datenströme zu verschlüsseln und im IOTA Tangle zu speichern und auf diese Nachrichten auch wieder zuzugreifen.

MAM steht dabei für:

Mask: Die Nachrichten sind verschlüsselt

Authenticated: Die Nachrichten lassen sich einem definierten Absender zuordnen

Messaging: Es wird ein kontinuierlicher Stream von Nachrichten durch den Sender erzeugt, der im Tangle gespeichert wird.

Abbildung 5: Beispiel Nachverfolgung einer Logistikkette

Wie in der Abbildung 5 ersichtlich ist, verschickt das IoT-Gerät als Publisher Nachrichten, die im IOTA Tangle gespeichert werden. Der Empfänger kann diese Nachrichten lesen, wenn er die entsprechende (Root-) Adresse der Nachricht kennt. Diese Root-Adresse wird auch als Channel-ID bezeichnet. An diesem Channel „lauscht“ der Subscriber, um Nachrichten vom Publisher zu empfangen.

Dabei enthält jede empfangende Nachricht eine Referenz auf seine nachfolgende Nachricht. Damit kann der Subscriber alle Folgenachrichten für die Channel-ID empfangen. Dies zeigt das folgende Bild:

Abbildung 6: Detailansicht Nachverfolgung einer Logistikkette

Der Stream verläuft dabei ausschließlich in eine Richtung. Wer die Channel-ID der Message 3 (s. Abbildung 6) besitzt, kann nicht auf die Messages 1 und 2 zugreifen, nur auf alle folgenden. Wer hingegen über die Channel-ID der Message1 verfügt, kann auf alle Messages ab Message 1 zugreifen.
In dem Beispiel der SupplyChain (s. Abbildung 3) könnte z.B. dem Kunden nur die Information ab „Produktion“ sichtbar gemacht werden.

Jede versendete Nachricht ist dabei Teil eines Bundles, welches aus einer Signature Section und einer MAM Section besteht. Die Daten der Nachricht werden in der MAM Section übertragen. Konkret im signatureMessageFragment einer Zero-Value-Transaktion. Die Message der Transaktion setzt sich im Kern aus dem Payload und der nächsten Root-Adresse zusammen, wie es in der Abbildung 6 zu sehen ist. Diese Message wird verschlüsselt.

• Public Mode
• Private Mode
• Restricted Mode.

Der Public Mode verwendet als Adresse zum Speichern der Transaktion die Rootadresse. Dieser Root ist gleichzeitig der Schlüssel zum Ver- und Entschlüsseln der Nachricht. Jeder, der auf eine solche Nachricht stößt (z.B. im Tangle-Explorer), kann sie dann unter Verwendung der Adresse lesen. Dies ist vergleichbar mit dem Empfang eines Radiosenders. Wenn ich den Kanal kenne, kann ich den Sender hören. Mit diesem Modus kann jeder Partei der Zugriff auf die Nachricht gewährt werden. Die folgenden beiden Abbildungen zeigen sowohl die verschlüsselte als auch die entschlüsselte Nachricht, auf die man direkt über den Tangle-Explorer zugreifen kann.

Abbildung 7: Verschlüsselte Beispielnachricht

In der entschlüsselten Nachricht kann man auch die Adresse (nextRoot) sehen, unter der die nächste Nachricht im Tangle gespeichert wird. Damit erhält man auch Zugriff auf die folgende Nachricht:

Abbildung 8: Entschlüsselte Beispielnachricht

Im Private Mode wird der Hash des Root als Adresse zum Speichern der Transaktion verwendet (address = hash(root)). Dadurch wird verhindert, dass ein zufälliger Finder der Nachricht diese lesen kann. Die Verschlüsselung erfolgt weiterhin mit der Adresse des Root. Eine Entschlüsselung ist nur mit dem Root möglich, der aber nicht aus der Adresse abzuleiten ist. Dies macht einen MAM-Stream nur für diejenigen lesbar, die den Root besitzen.

Der Restricted Mode fügt dem Private Mode einen Berechtigungsschlüssel (side key) hinzu. Mit diesem Berechtigungsschlüssel wird die Nachricht dann ver- und entschlüsselt. Dies ermöglicht eine Art Entzug der Leseberechtigung für Daten – unter Beibehaltung der Channel-ID.

Fazit

Dieser kleine Prototyp zeigt, dass MAM bzw. Streams in Kombination mit IoT einen interessanten Ansatz bieten, die klassische IoT Landschaft mit der Sicherheit, Transparenz und Dezentralität der Blockchain bzw. der Distributed-Ledger-Technologie (DLT) zu vereinen. Die Umsetzung von Supply Chain Use Cases ist aber auch mit anderen DLTs möglich. Der Fokus bei der Betrachtung liegt aber wie immer zunächst auf dem Use Case und erst dann auf der Betrachtung der Technologie. Die aktuelle Pandemie zeigt uns aber auch, wie wichtig die Umsetzung transparenter und nachverfolgbarer Lieferketten ist – und eben auch, dass es hier durchaus Nachhol- und Optimierungsbedarf gibt.

Noch Fragen?

Wie können Sie Chancen und mögliche Einsatzfelder von Blockchain-Lösungen identifizieren und diese in Ihrer Organisation umsetzen? Erfahren Sie, wie wir Sie beim Thema Blockchain unterstützen können:

Nico Heinze - ist Projektmanager bei der iteratec GmbH in München. In den vergangenen Jahren setzten sein Team und er immer wieder völlig neuartige Anwendungen um.