Cloud-Computing Softwarearchitektur Anwendungssoftware

Internet of Things mit SAP Leonardo

Unterschiedliche Studien sehen erhebliche Wachstumspotenziale für das Internet of Things sowie für IoT-Plattformen. Gerade für die Industrie ist IoT das zentrale Thema im Kontext der digitalen Transformation. So geht eine Studie von Arthur D. Little und dem Verband der Internetwirtschaft davon aus, dass sich der Industrial-IoT-Markt bis 2022 im Vergleich zu 2017 verdoppeln und damit einen Umsatz von etwa 16,8 Milliarden Euro in Deutschland erwirtschaften wird. Im Anlagen- und Maschinenbau beispielsweise, so rechnet die Studie vor, ließen sich durch Remote Monitoring Stillstandzeiten um bis zu 50 Prozent reduzieren (vgl. [Tiß17]). Beim Blick auf Industrial-IoT-Plattformen ist Gartner kürzlich zu dem Ergebnis gekommen, dass der Markt aktuell noch als unreif einzustufen ist – eine Einschätzung, die zugleich auf erhebliche Wachstumspotenziale verweist (vgl. [Gar18]).

Konstantin Bonn

Author

Andreas Kramer

Manager

17.10.2019
Lesezeit: 13 Minuten
103 Views

Das sind Gründe genug, aktuelle Chancen und Möglichkeiten eines industriellen IoT-Szenarios zu erproben und zu bewerten. Aufgesetzt wurde das Szenario unternehmensintern als Proof-of-Concept in einer mit Fischer-Technik® simulierten, vollständig vernetzten Industrie-4.0-„Fabrik“ inklusive Produktion, Lager und Logistik.
Realisiert wurde das Projekt mit SAP Leonardo auf Basis der SAP Cloud Platform. SAP Leonardo bietet Apps und Services rund um das Thema Digitalisierung; zu den bereitgestellten Technologien zählen Machine Learning, Blockchain, Big Data und Analytics. Einen Schwerpunkt des Angebots bilden IoT-Dienste (vgl. Abbildung 1). Dabei eröffnet die SAP Leonardo IoT Foundation die Möglichkeit, IoT-Szenarios selbst zu entwickeln. Im Zentrum steht dabei das „Thing Model“ des IoT Application Enablement Service, das ein logisches Abbild eines physischen Geräts ermöglicht und als Grundlage für die spätere Analyse und Anwendungsentwicklung dient. Die Verbindung von physischen und virtuellen Geräten, Sensoren und Motoren sowie die Ermöglichung der Kommunikation zwischen physischem Gerät und virtueller Repräsentation übernimmt der „IoT Service“ mit einer grafischen Oberfläche. Beide Services lassen sich dabei flexibel einsetzen und künftig in Teilen auch durch andere Bausteine austauschen (vgl. [SAP19]).

Abb. 1: Ansätze des SAP Leonardo Internet of Things: (1) Relevante Services für ein grundlegendes IoT-Szenario, (2) Dezentrale Datenverarbeitung, (3) SaaS-Schnittstelle zu Geschäftsprozessen, (4) Erweiterte Funktionalitäten für verschiedene Anwendungsfälle

Framework für zahlreiche IoT-Szenarien

SAP Leonardo stellt bereits ein vollumfängliches Framework für verschiedene IoT-Szenarios dar, das deutlich mehr Integrationsmöglichkeiten bietet als Plattformen anderer Anbieter, beispielsweise bei der Vernetzung von Diensten oder der Integration von ERP- und CRM-Systemen.
Neben dem Anspruch, das Projekt vollständig mit SAP-Cloud-Technologien zu realisieren, wurden folgende Ziele verfolgt: die Erfassung von Sensordaten zum Maschinenzustand und die Erstellung eines digitalen Zwillings, die Aufnahme von Verbrauchswerten und Geolocation je Sensor und die Visualisierung der Daten, der Aufbau eines Internetshops, mit dem sich die Warenproduktion steuern lässt, sowie die Umsetzung von Berechtigungskonzepten für verschiedene Anwendergruppen. Zudem sollte die Basisarchitektur für ein einheitliches Reporting aufgesetzt werden. Insgesamt ging es darum, die Machbarkeit einer mehrstufigen, cloudbasierten End-to-End-Lösung technisch und fachlich zu prüfen.
Um die IoT-Architektur wie geplant zu realisieren, galt es, Lösungen für eine Reihe von Anforderungen zu finden. Es kamen – abgesehen von einer Ausnahme – Kerntechnologien von SAP zum Einsatz. Hier eine Übersicht der einzelnen Schritte:

Prototyping und Feedback

Schnelles Prototyping und einfaches Feedback wurden mit SAP Build realisiert. Dieser Service gehört genau genommen nicht zum SAP-Leonardo-Portfolio und erlaubt das Erstellen interaktiver Prototypen. SAP Build stellt integrierte Controls zur Verfügung, die sich per Drag&Drop zu einem Wireframe, das heißt zu einem konzeptionellen Layout, zusammenfügen lassen. Die Erfahrung hat jedoch gezeigt, dass eine schnelle Prototyperstellung besser über die Importfunktion für eigene Fotos zu realisieren ist, die zunächst von Flipchart, Whiteboard oder dergleichen aufgenommen wurden. Anschließend können diese mit Navigationspfaden versehen werden, um ein erstes Gefühl für die Lösung zu vermitteln. Präferiert man dennoch bereitgestellte Baukästen, ist man in den meisten Fällen besser beraten, das Prototyping direkt in der SAP WebIDE durchzuführen, da dieser Weg deutlich mehr Gestaltungsfreiheit bietet, aber nicht zwingend mehr Zeit kostet. Mit einem Zusatzmodul in der WebIDE, der Entwicklungsumgebung von SAP, lassen sich die beiden Tools allerdings auch kombinieren, sodass der Build-Prototyp importiert und der dazugehörige UI5-Code automatisch erstellt werden kann.

Layer in der Cloud

Um die Daten aus der Fabrik zu sammeln und einen Workflow für den automatischen Versand im Edge-Layer in die Cloud zu gestalten, wurde Node- Red von IBM als Flow-based-Programming-Tool eingesetzt. Der Edge-Layer ermöglicht die lokale Anbindung der Geräte, sodass Daten bereits auf dem Gerät oder innerhalb einer Fabrik verarbeitet und gespeichert werden können. Diese Flexibilität ist in einem IoT-Szenario sehr nützlich, da auf diesem Wege schnellere Reaktionszeiten sowie eine Absicherung gegen Netzwerkausfälle gewährleistet werden können. Mit Node-Red lässt sich unter anderem das Format der Sensor-Nachrichten anpassen, sodass diese vom IoT Service der SAP Cloud Platform korrekt erkannt und zugeordnet werden können (vgl. Abbildung 2). Aus dem Hause SAP stellt der Data Hub eine mögliche Alternative dar, allerdings entfaltet dieser erst bei größeren, heterogenen Datenlandschaften seine volle Wirkung und hätte somit nur für einen Bruchteil seines Funktionsumfangs genutzt werden können. Eine direkte Verbindung der Geräte wäre jedoch ebenso möglich gewesen.

Abb. 2: Konfiguration der Nachricht eines Klimasensors: Der Payload wird als JSON verpackt

Schnittstelle

Das SAP IoT Service Cockpit markiert die Schnittstelle zwischen On-Premise System und SAP Cloud Platform und ist die erste Instanz der SAP Leonardo IoT Foundation, die in dieser IoT-Architektur Verwendung fand. Zum einen werden mit dem SAP Service Cockpit die Gateway-Server verwaltet. Als Übertragungsprotokoll wurde MQTT genutzt, das aufgrund seiner schlanken Natur für IoT-Szenarien generell gut geeignet ist und mit einem Publish/Subscribe-Ansatz dem Prinzip eines Twitters für IoT ähnelt.
Zum zweiten gewährleistet das SAP IoT Service Cockpit das Remote Device Management. Damit lassen sich einerseits Zertifikate generieren, die die sichere Kommunikation zwischen Edge- und Cloud-Netzwerk garantieren und damit grundlegende Security-Erfordernisse in einem IoT-Szenario erfüllen. Vor allem aber werden im SAP IoT Service Cockpit alle Sensoren verwaltet und es werden ihre jeweiligen Capabilities, also Datentypen, Einheiten etc. definiert. Damit entsteht im SAP IoT Service Cockpit eine digitale Repräsentanz aller eingesetzten IoT-Geräte.

Digitaler Zwiling

Die Erstellung eines digitalen Zwillings der Fabrik erfolgte mit SAP IoT Application Enablement, einer umfassenden Sammlung von Apps, Services und UI-Themes. Mit diesem Toolkit ist es möglich, unterschiedliche IoT-Szenarios zu kreieren. Deshalb kann das SAP IoT Application Enablement verstanden werden als Bindeglied zwischen den Gateway- und der IoT-Applikation bzw. den Frontend-Tools. So können beispielsweise Dashboard-Tools oder selbstgebaute SAPUI5-Apps auf das SAP IoT Application Enablement zugreifen und sich dort selbstständig die benötigten Daten ziehen. Genauso haben Applikationen über REST Zugriff auf die Daten des „Thing Model“: Wird zunächst für jedes Gerät und jeden Sensor ein korrespondierendes „Thing“ angelegt und anschließend mit dem SAP IoT Application Enablement eine Verbindung hergestellt, kann das „Thing Model“ als digitaler Zwilling beispielsweise in einer SAPUI5-App visualisiert werden.
Darüber hinaus lässt sich das SAP IoT Application Enablement für zahlreiche weitere Aufgaben nutzen. So können dort KPIs hinterlegt werden (beispielsweise produzierte Stückzahlen) oder es lassen sich unter Verwendung von bereitgestellten APIs bestimmte Events definieren, zum Beispiel dass bei einem definierten Schwellenwert eine Aktion ausgelöst wird. Sodann können via REST oder OData Daten versendet werden. OData ist ein von Plattformen, Technologien und Programmiersprachen unabhängiges Protokoll, das sich als wesentlicher Standard von Webschnittstellen durchgesetzt hat.
Zudem verfügt das SAP IoT Application Enablement über ein eigenes Berechtigungsmanagement, mit dem Benutzer verwaltet und Zugriffsrechte geregelt werden. Eine weitere wichtige Möglichkeit ist, im SAP IoT Application Enablement über das API-Management eine Speicherverwaltung einzurichten, die sich nach den jeweiligen Anforderungen richtet. So lassen sich beispielsweise aggregierte Zeitreihendaten in einem Hot Storage ablegen und individuelle Datenpunkte in einem Warm Storage, während ein Cold Storage als kosteneffizienter Langzeitspeicher dient.

Visualisierung

Für das Visualisieren der Sensordaten wurde die Entwicklungsumgebung SAP WebIDE verwendet. Sie ermöglicht den Bau einer SAPUI5-App, wobei zwei Varianten zu unterscheiden sind. Zum einen lässt sich eine solche App von Grund auf selbst bauen, was allerdings entsprechende Entwicklerkenntnisse voraussetzt. Zum anderen werden durch IoT Application Enablement IoT-Templates bereitgestellt, um SAPUI5-Apps für Things und Messwerte zu erstellen. Grundsätzlich gibt es eine weitere Option, nämlich die SAP Analytics Cloud zum Visualisieren von Sensordaten einzusetzen. Dafür muss ein OData Stream mit Open Authorization eingebunden werden. Zum Projektzeitpunkt hatte SAP die Anbindungsoption jedoch noch nicht fertig entwickelt.

Internetshop

Die SAP WebIDE wurde auch für den Aufbau eines kleinen Internetshops eingesetzt. Weil SAP WebIDE über eine eigene Importfunktion verfügt, können Prototypen aus SAP Build importiert werden, womit der Zugriff auf den UI5-Code möglich ist. Mit entsprechenden Anpassungen lässt sich in SAP Build das Grundgerüst für eine solche App schaffen.

Informationsportal

Den Schlusspunkt bildete der Aufbau eines Informationsportals mit dem Portal-Service der SAP Cloud Platform. Damit lässt sich eine Freestyle-Seite bauen, was wiederum Kenntnisse im UI5-Programmieren voraussetzt. Zudem steht in dem Portal bereits ein kachelbasiertes Fiori-Launchpad zur Verfügung, das entsprechend angepasst werden kann, beispielsweise an das Corporate Design. Hierzu wurde ein auf die Rolle eines Fabrikleiters zugeschnittenes Portal mit eingebundenen UI5-Apps bereitgestellt.

Gesamtarchitektur

Ein Blick auf die Gesamtarchitektur zeigt, dass eine vollständig cloudbasierte Lösung von IoT-Szenarien mit SAP Leonardo gut zu realisieren ist und die vorab definierten Anforderungen erfüllt (vgl. Abbildung 3). In dieser Architektur wurden die Messwerte direkt an das Frontend durchgeleitet, eine langfristige Datenspeicherung ist aber problemlos möglich, beispielsweise durch das aktive Verwalten des SAP Big Data Storage oder durch das Anbinden einer separaten HANA-Datenbank. Und schließlich lässt sich auf verschiedenen Ebenen – SAP Cloud Platform, SAP Application Enablement oder auch im Portal – eine differenzierte Benutzerverwaltung aufbauen, die mit dem SAP ID Service applikationsübergreifend betrieben werden kann.

Abb. 3: Die Gesamtarchitektur der getesteten SAP-Services

Fazit: Plattform mit großem Potenzial

Die einzelnen Produkte und Lösungen aus dem SAP-Leonardo-Portfolio bzw. dem Umfeld weisen einen unterschiedlichen Reifegrad auf. So ist die grafische Oberfläche von SAP Build noch nicht so ausgereift, dass sich bereitgestellte Controls per Drag&Drop gänzlich nach eigenen Vorstellungen zusammenbauen lassen. Die SAP WebIDE ist eine vielfältig nutzbare Entwicklungsumgebung, weist jedoch stellenweise einige Bugs auf. So kann es vorkommen, dass man seine Projekte öffnen möchte, aber einen leeren Workspace vorfindet. Hier handelt es sich um einen bekannten Anzeigefehler, der aber in manchen Fällen nur durch ein Support-Ticket gelöst werden kann. Weitere Anzeigefehler wurden in den UI5-Apps beobachtet, die verstärkt auftraten, wenn mehrere Entwickler an einem Projekt beteiligt waren. Dagegen funktionierte der SAP Portal Service zuverlässig und stellte eine benutzerfreundliche Möglichkeit dar, Anwendungen zu zentralisieren. Die nahtlose Verzahnung der Applikationen erlaubt es, bereits in kurzer Zeit eine gut integrierte Lösung zu erstellen. Gezeigt hat sich aber auch der Fokus auf die Applikationsentwicklung, weniger auf das Management der IoT-Geräte. Hier konnten wir in vorherigen Projekten umfangreichere Funktionen bei anderen Cloud-Dienstleistern einsetzen. Das ist vermutlich auch ein Grund, warum SAP die strategische Partnerschaft mit Microsoft Azure bekannt gegeben hat, um gerade die Stärken der IoT-Edge-Lösung sowie des IoT-Hubs von Microsoft mit den Stärken der Anwendungsentwicklung und Prozessintegration von SAP zu verbinden.
Auch andere große Hersteller wie Amazon mit AWS IoT, IBM mit IBM Watson IoT oder Google Cloud IoT bieten umfangreiche Lösungen, um den wachsenden Bedarf zu befriedigen. Auch wenn erst ein ausführlicher Technologievergleich, der jedoch den Rahmen unseres Projekts gesprengt hätte, genaueren Aufschluss über Stärken und Schwächen der einzelnen Lösungen geben würde, wird ein Abtausch zwischen Funktionsumfang und Benutzerfreundlichkeit sowie Funktionsumfang und Kostentransparenz deutlich. So hebt sich AWS aktuell mit dem größten Produktportfolio vom Wettbewerb ab, ist aber in der Implementierung und im Betrieb stärker auf ausgebildetes Fachpersonal angewiesen (vgl. [Cri18]). Es gibt beispielsweise vier primäre Identitätsmethoden, die wiederum auf eine Vielzahl von Services verteilt sind, für die Authentifizierung auf Geräten, in mobilen Anwendungen sowie Web- und Desktop-Anwendungen (vgl. [AWS19a]). Diese in einer IT-Infrastruktur feingranular und sicher zu verknüpfen, kann nicht zuletzt aufgrund substanzieller Supportgebühren eine Herausforderung darstellen (vgl.[AWS19b]). Dazu kommt die Rechnungsstellung, die aufgrund ihrer komplizierten Zusammenstellung bereits einen Markt der Kostenberatung für AWS-Dienste eröffnet hat.
In diesem Kontext bietet SAP bisher einen guten Kompromiss zwischen Funktionsumfang und benutzerfreundlichem Set-up durch vorkonfigurierte Verknüpfungen der Dienste. Das Preismodell variiert zwar zwischen Pay-per-Use und Flatrate, wurde aber mittlerweile so transparent und nachvollziehbar gestaltet, dass den Nutzer softwareseitig keine bösen Überraschungen erwarten. Insgesamt besitzt die SAP Cloud Platform das Potenzial, eine intuitive und funktionale All-in-One-Entwicklungsumgebung zu werden, die es erlaubt, neben IoT-Szenarios auch andere Zukunftstechnologien der Digitalisierung zu nutzen.

Zahlreiche Erweiterungsmöglichkeiten

Bereits im Projekt wurden diverse Erweiterungsmöglichkeiten andiskutiert und ausprobiert. Dabei sind insbesondere die Integrationsmöglichkeiten in bestehende SAP-Systeme über die zahlreichen Integrationsservices in der SAP Cloud Platform, beispielsweise die Cloud Platform Integration Services, von besonderem Interesse. Das gilt aus unserer Sicht ebenso für die Einbindung des SAP Data Hub, weil sich damit die Möglichkeit eröffnet, die Daten zu orchestrieren und bereits „auf dem Weg“ mit Advanced-Analytics-Diensten zu verarbeiten. Für die endgültige Darstellung und Analyse der Werte sehen wir künftig die SAP Analytics Cloud als Zielsystem vor.
In einem Produktionsszenario besteht ferner die Möglichkeit, Predictive-Maintenance-Techniken einzubinden: Mit Hilfe von Machine-Learning-Services können Echtzeitdaten der Fabrik so aufbereitet werden, dass beispielsweise Muster in Messund Statuswerten erkannt werden, die Störungen der Gerätschaften vorhersagen können. Hierfür wird eine weitere SAPUI5-App mit einem Status-Dashboard erstellt, die wiederum in das Portal eingebunden wird.
Von ähnlich hohem Interesse ist eine Erweiterungsmöglichkeit im Bereich der Qualitätskontrolle: Wird jedes Produkt pro Fertigungsstation mit einem Zeitstempel versehen, lassen sich Qualitätsabweichungen der Produkte wiederum zurückführen auf Daten der einzelnen Produktionsmaschinen. Wenngleich das einen höheren initialen Aufwand erfordert und zusätzliche Daten generiert – für die Qualitätssicherung steckt hierin großes Potenzial.