CubeServ Blog
Bleiben Sie auf dem neuesten Stand, rund um das Data Driven Business mit Tools für Analytics von SAP & Co. und verpassen Sie keine

Das Internet der Dinge, Big Data und eine Fischertechnik-Fabrik – Teil 2: Konsequenzen für die Architektur

Im ersten Teil dieses Blogs habe ich die Herausforderungen benannt, die Big Data für ein Data Warehouse darstellt.Für die Big Data-Architektur eines solchen EDW im konkreten Fall eines SAP BW on HANA oder SAP BW/4HANA ergeben sich damit bereits einfache Schlussfolgerungen:
  • Es ist nicht möglich, alle Daten in die SAP HANA zu laden. Die Datenmengen sind einfach zu gross, die HANA-Hardware für diesen Fall unverhältnismässig teuer. Es empfiehlt sich für die Masse an Rohdaten eine entsprechend skalierbare und kostengünstige Lösung zu verwenden, z.B. ein Apache Hadoop-Cluster. Solche Cluster bieten Skalierbarkeit über eine grosse Masse an günstiger Hardware und rechnen bereits in ihrer Architektur mit dem ständigen Ausfall einzelner Teile. So speichert das Hadoop-Filesystem HDFS die Daten immer mehrfach und ist daher betriebsbereit selbst wenn einzelne Server ausfallen. Gleichzeitig muss das System natürlich berücksichtigen, dass es die Mehrfach gespeicherten Daten nicht mehrfach zählt oder liefert. Dazu ist Hadoop entworfen worden. Von diesen grossen Datenmengen auf der Hadoop-Seite können nun kleinere Extrakte oder Aggregate durchaus in die HANA geladen werden, oder schon auf der Hadoop-Seite in-Memory vorgehalten werden, z.B. mit Hilfe des Spark-Adapters, wie sie auch in SAP Vora verwendet werden.
  • Nicht nur Daten, sondern auch Ereignisse müssen orchestriert werden. Das Auftreten bestimmter Ereignisse in den Daten (z.B. Alarmmeldungen) kann sowohl auf der Big Data-Seite, dem Hadoop-Cluster, als auch auf der BW-Seite gewisse Prozesse triggern (Nachladen von Daten, Erstellen von Servicemeldungen, usw.). Diese Ereignisse müssen auf beiden Seiten jeweils orchestriert werden, damit Prozesse technologieübergreifend definiert werden können. Der SAP Data Hub bietet neben der Verwaltung der Datentransfers eben solch auch eine gemeinsame Verwaltung von Ereignissen, Jobs oder Triggern an.
All diese Überlegungen sind doch immer wieder recht abstrakt. CubeServ hat daher eine Fabriksimulation der Firma Fischertechnik erworben, um einmal ganz konkret eine solche Architektur aufzubauen und zu demonstrieren. Die Fabrik besteht aus einem Hochregallager, aus einem zentralen Kran, aus einem Brennofen und einer Sortieranlage. Die Güter der Fabrik sind weisse, rote und blaue Plastikzylinder, die im Hochregal jeweils noch in rechteckigen schwarzen Boxen liegen.
Hier die Fabrik in Aktion:
Die Fischertechnik Fabriksimulation 24V im Einsatz – zur Erzeugung von Big Data-Sensordaten
 
Ein farbiges Gut wird aus der Sortierrutsche für Weiss genommen (wo es fälschlicherweise liegt), vom Kran zum Brennofen gebracht, von dort zum Sortierband und dort dann in die richtige Rutsche einsortiert.

Die einzelnen Bereiche werden separat gesteuert, aber ein kompletter Kreislauf kann so aussehen: ein Gut wird aus dem Hochregal entnommen, der zentrale Kran bringt es zum Brennofen, dort wird es (symbolisch durch blitzende Lichter) bearbeitet. Aus dem Brennofen kommt es zur Sortieranlage, eine Fotozelle erkennt die Farbe und entsprechend wird es in eines von drei Rutschen einsortiert. Von dort wird es wieder vom Kran entnommen und zum Hochregal gebracht, wo es wieder einsortiert wird. Die einzelnen Bereiche verfügen zum Teil über Sensoren wie Lichtschranken oder Fotozelle zur Farberkennung und über Motoren.

Hier der Link zur Produkthomepage dieser Fabrik: https://www.fischertechnik.de/de-de/service/elearning/simulieren/fabrik-simulation-24v .

Die Fabrik wird bereits komplett montiert geliefert, allerdings ohne Steuergeräte und demzufolge auch ohne entsprechende Programmierung. Um die Fabrik zu steuern, wurden acht Siemens Logo 8 Steuergeräte an die entsprechenden Sensoren und Motoren angeschlossen. Die Steuerung in der Logo-Sprache wurde dann von unserem Basis-Experten, Peter Straub, vorgenommen. Diese Programmierung ist recht aufwändig, die zur Verfügung gestellten Bestandteile von Sprache und Fabrik sind sehr einfach gehalten. Es gibt wenige Sensoren. Soll z.B. der zentrale Kran in Grundstellung gedreht werden, so wird er einfach eine bestimmte Zeit in eine bestimmte Richtung gedreht. Da er nicht über einen festmontierten Anschlag hinausdrehen kann, ist er damit in 0-Stellung. Die Bestandteile der LOGO-Sprache sind ebenfalls sehr elementar (UND-Gatter, ODER-Gatter, Zeitverzögerung und ähnliches). Es gibt z.B. keine komfortablen Variablen, die man z.B. für die Lagerhaltung nutzen könnte. Für die Verdrahtung der Geräte und der Programmierung der Fabrik kamen dann doch in etwa vier Wochen Aufwand zusammen.

Im nächsten Teil des Blog geht es dann darum, wie nun Daten aus dieser Fabrik in ein Big Data-Cluster kommen.

Schreibe einen Kommentar

Autor
Expert Team
Benedikt Bleyer
Adrian Bourcevet
Uwe Happel
Christoph Müller
Drazen Pavlovic
Julian Rudack
Thorsten Stossmeister
Jan Wiesemann
Blog abbonieren

Bleiben Sie auf dem neuesten Stand, rund um das Data Driven Business mit Tools für Analytics von SAP & Co. und verpassen Sie keine Neuigkeiten, Downloads & Veranstaltungen.