Jahr: 2018

TDWI Schweiz 2018 – Von Small Data, Data Vaults und Cloud DWHs – Ein kurzer Rückblick

Data Analytics ist in der BI Welt angekommen – Big Data dagegen ist zumindest als Schlagwort out. Small Data scheint jetzt die Expertenmassen anzuziehen, auch wenn sich mir die Tragweite dieses Begriffs trotz Keynote und Wikipedia verschlossen bleibt.

Wenn das Data Analytics Thema in den letzten Schweizer TDWI Kongressen noch eher akademisch angegangen wurde, so hat es spätestens dieses Jahr seinen festen Platz erhalten. Doch Data Analytics steckt in der Schweiz weiterhin in den Kinderschuhen, das zeigen die Beiträge. Der amerikanische und asiatische Kontinent ist uns leider in der Umsetzung meilenweit voraus. Da nützt es auch wenig, wenn gesammelt gegen Google zum Thema «Persönlicher Datenschutz» in der Fragerunde geschossen wird.

Bemerkenswert ist: Konventionelles Data Warehousing erfährt eine Renaissance über die Themen Data Vault/DWH Automation. Ich, der in den letzten Jahren neben Big Data Technologien den Kimball Ansatz vertreten hat (da für KMU’s meistens ausreichend, agiler und einfacher umsetzbar), sehe zugegeben etwas verspätet den Data Vault Ansatz für DWH’s grösserer Firmen nutzbar. Der Data Vault Builder hilft hier, ein DWH agil aufzubauen, nur der Data Vault Layer wird persistent abgespeichert.

Aber auch das Thema DWH in der Cloud setzt sich durch: Eindrücklich ist, wie Scout 24 ganz Abstand vom herkömmlichen DWH nimmt, da hier die Strukturen immer komplexer und aufwändiger wurden. Neu wird ein reiner Cloud Ansatz gefahren. Daten werden in der AWS S3 (Blob Storage) abgespeichert und von Analysten über Hive Metastore zugänglich gemacht. Über den Data Catalogue (Alation) werden die Daten dann auch gefunden. Das ist ein einfacher Big Data Ansatz (ohne Hadoop) und hoch skalierbar. Die User sollen im Self Service Prinzip Ihr Ad Hoc Reporting ausführen. Damit das möglich ist, gibt es eine Gruppe von Data Engineers, Data Analysten und Data Scientists, die die Vorbereitungsaufgaben ausführen. Das bisherige relationale DWH soll wirklich abgestellt werden (kleine Einschränkung: reines finanzielles und Sales Reporting werden weiterhin separat geführt). Macht dieser Ansatz nicht mehr Sinn, als komplexe Big Data Strukturen aufzubauen, um dann über einen automatisierten kommerziellen Plattformansatz wiederum zu umsetzbaren Lösungen zu kommen?

Auf der SAP Seite wird über S/4Hana/SAP Analytics Cloud und die «embedded» Planing und BW Komponenten die analytische Welt einfacher, hurra! Solange die Legacy Systeme dann auch abgestellt werden können. Hierzu gab es in mehreren Vorträgen positiven Input.

Als Fazit der Konferenz besteht bei mir weiterhin das Gefühl, das Experten sich stark spezialisieren müssen, um die allgemeine Komplexitätszunahme in der Datenwelt zu verkraften.

Und zu einer Sache möchte ich noch etwas schreiben: Für Nicht-Experten wird die Begriffswelt in der Welt der Daten wirklich immer unübersichtlicher. Da brauchen wir nicht auch noch Small Data, Smart Data kann ich gerade noch akzeptieren. Denn schliesslich brauchen wir Daten nur, um darauf aufbauend die Welt smarter zu machen und smartere Entscheidungen zu treffen.

Die Entscheidung, an diese Konferenz gegangen zu sein, war für mich eine smarte Entscheidung, danke an das TDWI für die Datengrundlage zu diesem kurzen Rückblick.

Partnerschaft mit Controlling Hub AG

Controlling Hub AG und LeanBI AG gehen eine Partnerschaft ein im Bereich Digitalisierung und Controlling.

CONTROLLING HUB hilft Unternehmen bei der Digitalisierung im Controlling in fachlicher Sicht und auf der Datenebene.

Dabei stehen Themen wie Echtzeitsteuerung des Unternehmens, Prognoseverfahren unterstützt durch künstliche Intelligenz, Integration breiter auch externer und unstrukturierter Datenbestände, dynamische Planung und interaktive Business Excellence im Vordergrund.

Der Ansatz von CONTROLLING HUB ist ganzheitlich, unter Einbezug organisatorischer Aspekte, der verfügbaren Ressourcen, Kenntnisse der Mitarbeiter, Geschäftsprozesse und der bestehenden Infrastruktur. Die Dienstleistungen umfassen Standortbestimmung, Beratung, Evaluation von Potentialen, Erarbeitung von Lösungen und Projektleitung.

LeanBI holt sich damit die fachliche Kompetenz in die Projekte und unterstützt CONTROLLING HUB bei der technischen Umsetzung. Für Planung- und Business Intelligence ergänzen wir unsere technische Beratungs- und Umsetzungsexpertise durch die wichtige fachliche Ebene. Auch sind wir überzeugt, dass unsere Data Science Expertise immer stärker im Controlling Einzug finden wird. Mit Data Science lassen sich Marktzusammenhänge nicht nur besser, sondern auch schneller erkennen und in den Controlling-Prozess integrieren. Ein Controller muss kein Data Scientist sein, aber er muss mit Datenanalytik Zusammenhänge feststellen und prognostizieren können. Und das in immer kürzeren Zeitzyklen.

Gemeinsam mit unserem neuen Partner CONTROLLING HUB helfen wir dem Controlling noch stärker der zentrale Business Partner der Geschäftsleitung zu werden. Damit unsere Schweizer Unternehmen noch stärker zu datengetriebenen Organisationen werden.

Wir freuen uns sehr auf eine fruchtbare Partnerschaft.

FFHS-Business Breakfast: Data Science als Schlüssel zur digitalen Innovation


Einmal bereits am Morgen mit spannenden Gästen aus der Unternehmenspraxis aktuelle Themen diskutieren! In lockerem Rahmen und an zentraler Lage bei Kaffee und Gipfeli Anregungen sammeln, Ideen austauschen und Kontakte zu knüpfen, bevor es weiter zur Arbeit geht…

FFHS-Business Breakfast: Data Science als Schlüssel zur digitalen Innovation

Marc Tesch, LeanBI AG spricht zum Thema «Der Nutzen von AI in Industrie und Logistik

Innovationsweltmeister zu sein und zu bleiben, braucht ein Gespür für Trends, es braucht Talent und Know-how und heutzutage auch Daten. Nichts funktioniert mehr ohne den Rohstoff der Digitalisierung. Das Problem liegt im Management der Daten und deren effiziente Nutzung, Analyse und Interpretation für neue Produkte, Lösungen und Entscheide. Data Science und Innovationsmanagement gehen Hand in Hand. Während das Eine der Treiber ist, ist das Andere der Umsetzer für erfolgreiches Wirtschaften.

Die Ziele der Data Science sind vordergründig eine bessere Entscheidungsgrundlage für das Business bereitzustellen, Prozesse zu optimieren, Störungen mittels Predictive Analytics vorherzusehen und so die Wettbewerbsfähigkeit des Unternehmens stetig zu erhöhen. Sie stellt aber auch die Grundlage für neue Produkte und Serviceleistungen dar, die wiederum neue Geschäftsmodelle definieren und damit der Ausgangspunkt für ein komplett neues Business sein können.

Doch die Hürde zum ersten Data-Science-Projekt scheint hoch: Zu schwammig sind die einzelnen Schritte, zu undurchschaubar wirkt der Aufwand. Wie ist der Ablauf eines typischen Data-Science-Projekts? Was ist bei der Durchführung wichtig? Und wie lässt sich ein Data-Science-Projekt in die Innovationsphase und damit in die wirtschaftliche Umsetzung führen?

Ein gutes Data-Science-Projekt umfasst vier Phasen. Es beginnt mit der Vorbereitung und endet nach vielen iterativen Prozessschritten, die primär die Anpassung des zielführenden Algorithmus darstellen, mit der Inbetriebnahme. In der Iteration liegt die Kunst, denn um das Ergebnis zu optimieren, wird immer wieder an den Parametern geschraubt, bis das Ergebnis stimmt. Kreativität und Flexibilität eines interdisziplinären Teams sind essentielle Faktoren, um auch das Potenzial eines Data-Science-Projekts auszuschöpfen.

Hier finden Sie das vollständige Programm www.ffhs.ch/fuer-unternehmen/seminare-workshops/18-business-breakfast

Peakboard und LeanBI gehen eine Partnerschaft ein

Wir freuen uns, Ihnen unsere Partnerschaft mit Peakboard, dem innovativen Visualisierer von Daten bekannt zu geben. Peakboard passt optimal zur LeanBI und zum LeanBI Slogan „agil-schnell-einfach“.

  • Agil: Kommt mit minimalen IT Infrastrukturen aus
  • Schnell: In wenigen Stunden produktionsbereit
  • Einfach: Dashboards können durch Fachpersonen erstellt werden

Damit ist Peakbaord ist nicht nur für Grossbetriebe sondern auch für KMUs unkompliziert einsetzbar.


Ob Andon Boards, Corporate Digital Signage oder Dashboarding. Mit Peakboard ist die Visualisierung von Prozessen, Daten und Kennzahlen auf Displays im Unternehmen in kürzester Zeit erstellt.

Peakboard ist eine intelligente und wartungsarme Industrielösung, um operative Daten aus unterschiedlichen Quellen auf Displays in Echtzeit zu visualisieren. Diese Daten werden dem Werker in Produktion und Logistik als Dashboards zur Verfügung gestellt. Peakboard besteht aus einer Hardware-Komponente, die das Echtzeitdashboard speist und im lokalen Netzwerk kommuniziert und einer Design-Komponente, mit der die Dashboards vom PC aus erstellt und auf die Peakboard Box geladen werden.

Abb 1: Vernetzung von Peakboard mit Maschinen und Ihren IT Systemen (ERP, CRM, Planung, usw.)

Jede Peakboard-Box kommuniziert mit den verbundenen Systemen im lokalen Netz oder im Internet ausschließlich dann, wenn der User dies so wünscht und so konzipiert hat. Das bedeutet, dass weder Peakboard noch Drittfirmen Nutzerdaten sammeln. Die Daten bleiben damit immer im sicheren Firmennetzwerk.

Anwendungen finden sich über die gesamte Wertschöpfungskette der Industrie: Von der Logistik über die Sales Abteilung hin zur Produktion (Shopfloor Management) sowie Administration und IT.

Abb 2: Anwendungsbeispiele von Peakboard

Wie Sie wissen, hat sich die LeanBI der Prozess- und Service-Optimierung im industriellen Umfeld verschrieben. Peakboard integriert sich nahtlos in unsere Dienstleistungen. BI (Business Intelligence), AI (Artificial Intelligence) und ML (Machine Learning) werden erst mit Front Ends wie Peakboard zum Leben erweckt. So wird mit Peakboard z.B. unser Predictive Maintenance Lösung visualisiert. Hier ein Beispiel aus den Peakboard Referenzen:

Mit Peakboard konnten wir unseren Reparaturprozess nun auch ‚auf dem letzten Meter‘ – der Visualisierung – digitalisieren und damit einen weiteren Schritt in Richtung ‚Industrie 4.0‘ gehen“

.Oliver Herz, Leiter der Anwendungsentwicklung, MUNSCH-Unternehmensgruppe

Wollen Sie mehr zu Peakboard wissen oder wünschen Sie eine Demo, wir kommen gerne bei Ihnen vorbei.

Hier finden Sie auch mehr Informationen zu unserem Partner: https://peakboard.com/

Wir freuen uns und schauen der neuen Partnerschaft mit Peakboard mit Spannung und Enthusiasmus entgegen.

Konferenz Perspektiven mit Industrie 4.0 – Von smarten Produkten zu neuen Service-Modellen: Neues Business mit neuen Ansätzen

Konferenz Perspektiven mit Industrie 4.0

Am Mittwoch, 5. September 2018 findet wie letztes Jahr die Konferenz Perspektiven mit Industrie 4.0 statt, welche von der ZHAW, Industrie 2025 und Swiss Alliance for Data-Intensive Services organisiert wird. Letztes Jahr war ein voller Erfolg und dieses Jahr werden noch mehr Besucher erwartet.

 

Digitalisierung und Industrie 4.0 sind eine Herausforderung für Schweizer KMUs – gleichzeitig liegen hier riesige Chancen. Smarte Produkte eröffnen neue Märkte und ermöglichen neue und innovative Geschäftsmodelle, oft in Form von neuen Services.

 

Speziell im Fokus der Konferenz steht die Frage, wie man in einer digitalisierten Welt neue Produkte und Services entwickeln kann. Es werden die Erfolgsfaktoren wie Produktentwicklung von smarten Produkten und deren Produktion Service-Design Geschäftsmodell-Entwicklung, Technologie-Einsatz und Organisation erläutert.

 

Das ist genau das Thema von LeanBI und darum treten wir hier als Gold Sponsor der Veranstaltung auf. Besuchen Sie diese spannende Konferenz. Gerne begrüssen wir Sie auch bei uns am Stand.

 

Hier geht es zur Anmeldung:

https://www.xing.com/events/konferenz-perspektiven-industrie-4-0-1875036

 

und hier zu weiteren Informationen der Veranstaltung:

https://www.zhaw.ch/de/engineering/ueber-uns/veranstaltungen/perspektiven-mit-industrie-40/

 

 

 

 

41. Face to Face Meeting | Industrie 4.0 – Risiken und Massnahmen bei einer Vernetzung der Produktion der Berner Fachhochschule Burgdorf

Face to Face Meeting - Industry 4.0

Die Berner Fachhochschule in Burgdorf hatte am Freitag, 29.6.2018 zum Industrie 4.0 Face to Face eingeladen. Zu einem sehr wichtigen Thema.

 

Stellen Sie sich vor, ein Kryptovirus wird in die Produktion eingeschleust und verschlüsselt ihre gesamte Produktionssoftware. Ein riesen Schaden, wenn Ihre Anlagen plötzlich nicht mehr verfügbar sind! Ist Ihre Produktionssoftware dagegen gut genug geschützt? Im Impulsvortrag von Prof. Felser wurde sehr schön aufgezeigt, wo die heutigen grössten Risiken bei der Vernetzung der Produktion liegen.

 

Top 10 Bedrohungen und Gegenmassnahmen 2016

Diese Tabelle zeigt, wie die Bedrohungsszenarien aussehen. An erster Stelle stehen Social Engineering, Pishing und Einschleusen von Malware über Wechselträger (Nr. 1 und Nr. 2). Hier ist Ausbildung der Mitarbeiter zu genau diesem Thema angesagt, und behalten Sie Ihre Software immer auf dem neuesten Stand. Verhindern Sie auch, dass fremde Computer oder USB-Sticks in Ihr Produktionsnetzwerk gelangen (wie bspw. bei externen Wartungszwecken). Auch bei Einbindung von Mobile Phones ist absolute Vorsicht geboten.

 

Dass die Infektion über das Internet „erst“ an dritter Stelle folgt, ist nachvollziehbar. Wir gehen davon aus, dass dies sogar noch nach hinten rutschen wird. Sehr hohe Sicherheit erhalten Sie hier, wenn der Datentransfer eine Einbahnstrasse nach aussen ist. Auch können Sie via VPN (Virtual Private Network) und Entkopplung via Gateways Ihr Netzwerk ganz abschotten. Dann kann auch ein Fernwartungsthema umgesetzt werden.

 

Die Normen wie IEC 62443 (Industrial Communication Networks- Network und System Security) helfen Ihnen bei Sicherheitsfragen. Nur sind diese Normen zwischenzeitlich sehr umfangreich und immer im Fluss. Auch hilft das BSI Lars Handbuch.

 

Die Vernetzung der Produktion ist ein unabdingbarer Schritt der Modernisierung und Digitalisierung. Es gibt wohl keine Produktion, wo dies nicht schon im vollen Gang ist. Das Bedrohungs-Risiko steigt, wenn diesen möglichen Bedrohungen nicht genügend Stellenwert beigemessen wird.

 

Nun zu einem ganz anderen Thema: Begeistert war ich auch von den Bachelor Abschlussarbeiten, die uns nach dem Essen während einer Poster-Ausstellung von den Studenten direkt gezeigt wurden: Besonders beeindruckt haben mich natürlich die Digitalisierungsthemen: Intelligent gesteuerte Strassenlampen (Nathanael Josua Berger und Nicola Damien Vaucher) und eine nachgelagerte Verkehrsanalytik. Dies mit Bluetooth 5.0 zu machen ist neu und macht Sinn. Im Gegensatz zu LORA Netzwerken, kann hier mit viel höheren Datenraten gearbeitet werden. Auch bei vernünftigen Preisen. Eine tolle Arbeit!  Predictive Maintenance für einen Trocknungsturm (Christian Morf). Ein Thema, dass uns natürlich besonders interessiert. Ausgeführt für die Firma Küffer AG und Naturex AG. Die Machbarkeit konnte konzeptionell und mit einem kleinen Piloten bewiesen werden. Predictive Maintenance ist und bleibt ein grosses Thema. Und zu guter Letzt der IoT Parkplatzsensor (Loris Kerim Leroy Knutti und Marc Philipp Saegesser). Eine Thematik mit der die BFH ja schon länger unterwegs ist. Neu ist hier der wireless aufladbare Akku. Ein Öffnen der Apparatur zum Batteriewechsel wird damit obsolet.

 

Natürlich gab es noch viele weitere tolle Arbeiten, dies würde den Blograhmen aber leider sprengen. Ich bin begeistert, was Studenten heute in wenigen Wochen nicht nur konzeptionell sondern hemdsärmelig erarbeiten können! Danke herzlichst für diesen spannenden Nachmittag in Burgdorf.

 

Predictive Maintenance im Schweizer Post-Verteilzentrum mit LeanPredict

Unser Innosuisse Projekt LeanPredict, bei welchem LeanBI Hauptumsetzungspartner ist, macht Fortschritte. Die Hochschule für Technik Rapperswil HSR, unser Hochschulpartner gemeinsam mit der FHS St. Gallen, hat dazu einen Artikel verfasst, den wir Ihnen in diesem Blog gerne zur Verfügung stellen. Wir setzen im Projekt mit unserem Anwendungspartner der Schweizerischen Post und drei weiteren Partner (Neratec AG, Küffer AG, acs AG) eine modulare Predictive Maintenance Lösung um, die im intralogistischen Bereich Verbreitung finden wird.

 

Hier kommen Sie   https://issuu.com/hsrpublishing/docs/hsr_magazin_1.2018/34 auf den Zeitschriftenartikel

 

Hier können Sie den Bericht herunterladen: LeanPredict bei der Post

Halle Kippschalen

Predictive Maintenance: Wie starten?

Uns fragen regelmässig Maschinen-, Anlagenbauer und Hersteller wie ein Predictive Maintenance Projekt zu starten ist. Leider gibt es hierfür kein allumfassendes Rezept, aber eine Richtschnur sehr wohl.

Warum is Predictive Maintenance wichtig

  1. Machen Sie einen Plan

Ein rein technischer Ansatz sollte vermieden werden: Zuerst einmal alle möglichen Daten der Maschinen oder Anlagen in eine Datenbank oder Filesystem zu schreiben ist nicht unbedingt der beste Weg. Einen solchen Big Data Ansatz sehen wir als überholt an, und glücklicherweise stimmen zwischenzeitlich auch viele Beratungshäuser dem zu. Smart Data ist angesagt.

Machen Sie zuerst einen Plan. Sitzen Sie in einem interdisziplinären Team (Technologie, Produkt Management, Produktion, F&E) zusammen und besprechen, was Ziele, Nutzen und Anforderungen an ein Predictive Maintenance sind. Vergessen Sie dabei nicht die zentralen kommerziellen Ziele und betrachten Sie die Machbarkeit. Häufig dreht eine vermeintlich unmachbare Situation (z.B. der Kunde wird seine Daten nicht herausgeben) in eine Relativierung und dann sogar in eine positive Stimmung um. Aber beginnen Sie mit Bedacht und mit der Philosophie der kleinen Schritte.

  1. Nutzen Sie die Erfahrungen und Daten Ihrer Firma

Fangen Sie damit an, Störungs- und Servicedatenbanken auszuwerten. Häufig sind Informationen aus diesen Datenbanken unstrukturierte Texte, aber mit heutigen Textmining Tools lassen sich diese trotzdem recht einfach analysieren. Ideal ist, wenn Sie hier Daten von 3 bis 5 Jahren Datenhistorie aufweisen können. Werden Komponenten nicht aufgrund von Verschleiss- sondern wegen Vorgaben des Wartungsplans ausgewechselt, dann sind Informationen zum Zustand dieser Komponenten nützlich. Oft ergeben sich aus dieser Auswertung sehr aufschlussreiche Informationen, wo bereits Projektpotential vorliegt.

Priorisieren Sie die Wichtigkeit der Störungen. Einflussfaktoren sind dabei Anlagenverfügbarkeit, Komponenten- und Wartungskosten.

LeanBI Vorgehensmethodik Einführung von Predictive Maintenance

Betrachten Sie dann zuerst nur die wichtigen Störungsfälle und eruieren Sie die Anlagendaten, die einen solchen Störungsfall messen oder prognostizieren können. Auch das ist ein Workshop-Thema, wo Ihr und unser Expertenwissen miteinfliesst: Kann voraussichtlich mit der kombinierten Auswertung bestehenden Analagendaten bereits ein Störungsfall gemessen oder auch prognostiziert werden? Wie schnell muss in den Prozess eingegriffen werden, damit ein Störungsfall vermieden werden kann? Was ist die Taktfrequenz der Messdatenerfassung, damit eine Anomalie erkannt wird? Solche Fragen können häufig bereits aufgrund Erfahrung und physikalischem Wissen abgeschätzt werden und benötigen keine Testläufe.

  1. Condition Monitoring kann ein Zwischenschritt sein

Condition Monitoring misst den aktuellen Zustand Ihrer Anlage. Das ist Bedingung für eine zustandsorientierte Instandhaltung. Condition Monitoring ist im eigentlichen Sinn noch keine prädiktive Überwachung. Spontane und zukünftige Ausfälle können damit nicht ermittelt werden. Condition Monitoring ist kein zwingender, aber ein möglicher Zwischenschritt zu einer vorausschauenden Wartung (Predictive Maintenance). Er macht Sinn, wenn die prädiktive Wartung einen hohen Komplexitätsgrad aufweist und die Machbarkeit als schwierig eingestuft wird.

  1. Make or Buy?

Sehr wichtig ist die «Make or Buy» Frage. Es gibt bereits eine grössere Anzahl von Predictive Maintenance Anbieter auf dem Markt. Das sind in den weitaus meisten Fällen Cloud Angebote, die mit IoT Dienstleistungen kombiniert werden (teilweise über 2 bis 3 Hersteller hinweg). Gerade aber in der Maschinenindustrie sind solche Angebote nicht optimal. Diese werden häufig auf das «Make» zurückgreifen. Wir können auch hier gute Ratschläge geben, wann der Einsatz kommerzieller Lösungen Sinn macht.

  1. Halten Sie den Business Case kurz und bündig

Rechnen Sie den Business Case grob durch. Berücksichtigen Sie auch qualitative Schlüsselfaktoren. Zum Beispiel kann ein «Predictive Maintenance Service» ein verkaufsunterstützender Aspekt einer Maschine sein, auch wenn dieser Service anfänglich nicht vom Kunden gekauft wird. Auch hier gilt wieder, dass ein solcher Business Case kurz und bündig sein sollte.

  1. Gehen Sie schnell in einen Proof of Concept

All diese obengenannten Punkte sollten in wenigen Tagen machbar sein. Machen Sie daraus keine Doktorarbeit. Gehen Sie lieber früher als später in einen Proof of Concept. Nehmen Sie dabei die dringlichen, machbaren und nützlichen Maintenance Use Cases zuerst. Für den Prototyp muss noch keine Online Anbindung vorhanden sein. Für die käuflichen Predictive Mainenance Produkte mag dies aber Sinn machen. Meistens reicht es aus, wenn die Daten Offline auf einer Data Science Plattform ausgewertet werden. Der Prototyp klärt die Frage, ob sich auf der Datenbasis ein statistisches Modell (Artificial Intelligence (AI) & Machine Learning Modell) aufbauen und sich damit die Anomalie gut erkennen lässt. Kann die Anomalie eine Maschinenkomponente zugeordnet werden? Wie früh trifft die Anomalie auf? Kann ein Schaden damit verhindert werden?

Nicht überall muss das Rad neu erfunden werden. Bei einer Reihe von Standardkomponenten bestehen dazu Erfahrungen oder in den käuflichen Tools bereits Modelle. Der Reifegrad der Lösungen auf dem Markt ist sehr unterschiedlich. Besonders günstige Lösungen leisten häufig nicht, was sie versprechen. Achten Sie darauf, dass Sie ein offenes System beziehen, dass sie die Daten über eine Schnittstelle automatisiert auslesen können. Die Daten gehören Ihnen und müssen in allen Transformationszuständen einfach exportierbar sein. Dazu mehr in einem späteren Blog.

  1. Optimieren Sie in Richtung Decision Support System

Ist der Prototyp erfolgreich, gehen Sie in eine Testproduktion. Das kann ein Testkunde sein oder ein spezifischer Case in der Produktionsanlage. Sammeln Sie Erfahrung, optimieren sie das Modell und erweitern Sie die Vorhersage in Richtung Entscheidungshilfe und Wartungsplaneinbindung. Dann kann ein solcher Service innerhalb der Firma und/oder an Ihre Kunden verkauft werden. Ein präventive Wartungsplan wird so nicht über den Haufen geworfen, sondern geht stetig, mit Bedacht, aber unabdingbar in eine zustandsorientierte und vorausschauende Wartung über.

Diese Blog ist der erste Teil unserer neuen LeanBI Reihe zum Thema Predictive Maintenance. Weitere Blogs der nächsten Wochen besprechen folgende Themen:

  • Predictive Maintenance: Was gibt es auf dem Markt?
  • Predictive Maintenance für Motoren und Lager
  • Predictive Maintenance: Quo Vadis?
  • Predictive Maintenance: Die Algorithmen

IoT für die Lagerlogistik: Stöcklin DMA, Data Monitoring und Alerting

Auch in der Intralogistik wird IoT und Predictive Maintenance zu einem signifikanten Wettbewerbsvorteil. Die Schweizer Firma Stöcklin Logistik AG spielt eine Vorreiterrolle auf dem Gebiet Industrie 4.0. In Zusammenarbeit mit stemys.io durften wir für die Stöcklin Logistik AG in einem Zeitraum von 4 Monaten ein sehr erfolgreiches Data Monitoring und Alerting Projekt umsetzen.

Ausgangssituation

Als Anbieter von Intralogistiksystemen und logistischen Gesamtlösungen ist Stöcklin Logistik AG entlang der ganzen Wertschöpfungskette Logistik am Markt präsent und verbindet Mechanik, Steuerung und Informatik.

Stöcklin möchte seine Kunden mit neuen datengetriebenen und analytischen Services bei der Produktivitätssteigerung unterstützen. Dafür wird eine DMA-Data Monitoring und Alerting Plattform aufgebaut. Die Plattform ist Grundlage neuer, innovativer Dienstleistungen der Stöcklin Logistik AG auf Basis von Big Data und Machine-Learning.

Projektziele

  • Aufbau einer Big Data-In Memory Infrastruktur
  • Jeder Kunde sieht nur seine Daten
  • Die Lösung kann auch beim Kunden laufen
  • Hoch skalierbare Infrastruktur
  • Die Datensicherheit muss stets gewährleistet sein
  • Moderne Alarmierung und Dashboard Services auch auf mobilen Endgeräten

Ausgangssituation

  • Frühzeitige Stillstandprognose mit vorausschauender Wartung (Predictive Maintenance)
  • Rollenbasierte Information mit Hilfe kontinuierlicher Prozessvisualisierung und -optimierung
  • Erhöhung der Anlagenverfügbarkeiten über proaktives Event-Monitoring
  • Optimierung des Energie- Managements der logistischen Anlagen

Lösungsweg

  • Erarbeitung der IoT-Architektur und Definition der Dashboards in gemeinsamen Workshops
  • Erstellung und Freigabe eines Umsetzungskonzeptes
  • Gemeinsame Umsetzung der Lösung auf auf der stemys.io Entwicklungsumgebung und Produktivsetzung in der Stöcklin Cloud

Die Sucess Story kann hier heruntergeladen werden: Success Story with Stöcklin (PDF download)

IoT und Predictive Analytics: Fog und Edge Computing für Industrien versus Cloud (19.1.2018)

Bild: ESG Research 2016

Warum nicht immer Cloud?

Von unseren industriellen Kunden wird immer wieder angezweifelt, ob die Cloud der richtige Weg sei, um IoT und Predictive Analytics in Industrieprozessen, Produktionsanlagen und Maschinenparks zu implementieren. Einige Gründe sprechen dafür, einige aber auch dagegen:

IoT und Predictive Analytics in der Cloud: Was spricht dafür?

  • Aus der Cloud können Prozesse zentral überwacht werden. Mit den Daten lassen sich die Prozesse optimieren und besser betreiben. Die Informationen aus den Prozessen können zudem in die Produktentwicklung einfliessen.
  • In der Cloud sind die Daten zentral in einer Datenbank abgelegt und können für zukünftige aktuell noch unbekannte Analysen umfassend eingesetzt werden (Data Pool, Single Source of Truth).
  • Komplexe Algorithmen mit grossen Datenmengen können auf schweren Big Data Infrastrukturen ausgeführt werden (z.B. auf Hadoop oder MPP-Massive Parallel Processing Infrastrukturen). Es bestehen keine Limiten bezüglich CPU und RAM.
  • Die Daten können über eine zentrale Einheit zwischen den „Things“ ausgetauscht werden. Das bringt strukturierten Informationsaustausch mit sich (im Gegensatz zur sog. Spagetti-Vernetzung).
  • Das Thema Datensicherheit kann zentral angegangen werden und muss nicht dezentral für jede Einheit separat gelöst werden.

IoT und Predictive Analytics in der Cloud: Was spricht dagegen?

  • Die Daten verlassen das Netzwerk des Industrieprozesses (zum Beispiel des Herstellprozesses), was nicht von allen Kunden akzeptiert wird. Es besteht das potentielle Risiko, dass Prozess Know-How abgesaugt wird.
  • Über die Cloud kann ein Angriff auf die Daten der Firma oder sogar auf die Anlagen selbst erfolgen (Cyber Security). Ein zentrales Element wie z.B. die IoT Plattform eines grossen Providers ist grösser und bekannter; somit ist das Interesse und die Gefahr, dass ein solcher Punkt angegriffen und gehackt wird, viel grösser.
  • Die Latenzzeit zwischen Maschine und Cloud beeinträchtigt den Eingriff im Millisekunden-Bereich (Real Time oder Near Real Time Applikationen). Viele Use Cases im Machine Learning und im datenanalytischen Bereich können so nicht oder nur eingeschränkt funktionieren.
  • Die Bandbreite des Netzwerkes ist oft nicht ausreichend, um die grossen Datenmengen zu übertragen.
  • Das Netzwerk kann ausfallen, die Verfügbarkeit der Applikation ist dann nicht sichergestellt. Im schlimmsten Fall kann sich das auf die Anlagenverfügbarkeit auswirken.
  • Bei grossen Datenmengen kann eine Cloud wie z.B. MS Azure IoT, Predix, Mindsphere, Amazon AWS, Google Cloud, usw. sehr teuer werden, da die Lizenzmodelle mengenspezifisch aufgesetzt sind.

Was ist Edge und wann wird es verwendet?

Ziel neuer Konzepte ist es, die Geräte und Sensoren in der Edge (im Deutschen am besten mit Rand übersetzt, in unserem Fall mit Industrieanlagen) oder in der Fog (d.h. im Industrienetzwerk) intelligenter zu machen, so dass die Kommunikation nicht nur von und zu der Cloud, sondern – wo sinnvoll – wieder zwischen den Geräten selbst stattfindet.

Warum also nicht Applikationen wie Predictive Maintenance direkt auf der Maschine ausführen? Dabei lassen sich Micro-Controllers einsetzten, die aber bezüglich Speicher und RAM beschränkt sind. Solche kleinen Prozessoreinheiten kommen dann auf Raspberry Pi’s, Onion Omega 3 oder ähnlichen Fabrikaten zum Einsatz, die kleine und kostengünstige IoT Umgebungen zur Verfügung stellen. Diese Einheiten weisen wichtige Schnittstellen wie WiFi, Bluetooth und USB auf, die Leistungen sind aber rechtgering, ein Raspberry Pi Zero W verfügt über z.B. 1 GHz CPU und 512 MB Storage bei einem Preis von 10$ pro Einheit.


Bild 1: Micro Controllers und Raspberry Pi‘s

Damit auf diesen Systemen Algorithmen laufen können, müssen die Algorithmen sehr «leicht» gemacht sein, was häufig nicht möglich ist.

Was ist also die nächst grössere Einheit an Compute Technologie? Heute lassen sich auch sogenannte SoC (System on a Chip) Bauelemente einsetzen. Diese besitzen sehr viel höhere Leistungsdichten bei gleichzeitig geringem Platzbedarf. Diese sind bezüglich Hardwarekosten recht günstig, müssen aber speziell für den Einsatz entwickelt werden, was dann wiederum mit Entwicklungskosten verbunden ist.

Bild 2: Beispiel einer SoC Technologie

Einsatz finden solche Systeme angefangen bei mobilen Telefongeräten bis hin zu Recheneinheiten in Cloud Centern. Die Leistungen gehen entsprechend bis 54 Cores hoch, 3 GHz, 512 GB RAM, 1 TB Storage und 100 Gbps Bandbreite, sind aber mit einigen 100 $ auch einiges teurer als die Micro Controllers und Raspberry Pi‘s.

Warum braucht es Fog Computing?

Natürlich könnten wir auch einen Server an eine Maschine stellen, welcher bis zu 176 Cores, 2 TB RAM und 460 TB Storage ausweist. Die Hardware Kosten würden dann aber dramatisch zunehmen und wir müssten uns die Frage stellen, wie teuer eine maschinennahe analytische Einheit sein darf. Dies ist natürlich abhängig von dem Preis der Maschine selber, aber in vielen Fällen lohnt sich dies vermutlich nicht.

Fog arbeitet mit der Cloud, während der Edge durch den Ausschluss der Cloud definiert wird. Fog arbeitet hierarchisch, wogegen Edge auf eine kleine Anzahl von Schichten beschränkt ist. Fog befasst sich neben der Berechnung auch mit Vernetzung, Speicherung, Steuerung und Beschleunigung. Mit Fog Computing kann daher eine interessante und preisgünstige Zwischenlösung zur Cloud geschaffen werden. Mit Fog wird die Rechenleistung an die Peripherie der Netzwerke gedrückt und damit für eine Gruppe von „Dingen“ zwischen Edge und Cloud ausgeführt.

Bild 3: Darstellung der Fog Architektur

Fog: Ein Architekturkonzept

Fog ist zuerst einmal ein Architekturansatz, zweitens eine Software und Drittens eine Hardwarekomponente. Der Ansatz ist noch recht neu, stammt aus den Jahren 2014, im 2015 wurde von einigen wichtigen Exponenten wie Cisco, Intel, Dell, Microsoft und Princeton University das Open Fog Konsortium gegründet. Im Februar 2017 ist dann das erste Architekturkonzept publiziert worden, welches hier eingesehen werden kann:
https://www.openfogconsortium.org/wp-content/uploads/OpenFog_Reference_Architecture_2_09_17-FINAL.pdf

Die Publikation ist noch nicht sehr konkret und man muss sich durch 162 Seiten Paper kämpfen. Trotzdem lohnt sich eine Sichtung des Dokuments, und ohne hier genauer darauf einzugehen, ist für uns folgende Zusammenarbeit von Edge, Fog und Cloud essentiell.

Das Machine Learning (ML) Modell wird auf einer Data Science Plattform entwickelt. Das kann Offline oder in der Cloud geschehen. LeanBI setzt dafür als Plattform Dataiku ein. Das ML Modell wird dann auf eine produktive Plattform exportiert. Je nach den Anforderungen läuft dann das ML Modell auf der Edge, in der Fog oder direkt in der Cloud. Der Trainings-Task zur Modell-Optimierung wird in der Regel an die Cloud abgegeben, da dieser Task rechenintensiv ist und eine breite Datenbasis benötigt. Das Modell wir damit periodisch in der Cloud mit neuen Daten optimiert, um dieses verbesserte Modell dann auf die Fog oder Edge periodisch anzuwenden. Prinzipiell lässt sich dieser Trainings-Task auch offline ausführen, je nachdem, wie häufig dieser stattfinden muss.

Fog: Ein Stück Software

Die Softwarelandschaft rund um Edge und Fog Computing ist momentan noch recht übersichtlich. Dabei ist der Funktionsumfang teilweise sehr unterschiedlich. Cloud Anbieter wie MS Azure IoT, Predix, AWS oder IBM Watson haben im 2016/2017 Edge/Fog Komponenten lanciert (meistens als Open Source), um besonders als Bindeglied zwischen der Edge und der Cloud zu wirken. Dabei werden Funktionalitäten bereitgestellt, die das Machine Learning Modell auf der Edge laufen lassen. Hier drei Beispiele dafür:

AWS Greengrass: https://aws.amazon.com/de/greengrass/

Azure IoT Edge: https://azure.microsoft.com/de-de/services/iot-edge/

IBM Edge Analytics: https://console.bluemix.net/docs/services/IoT/edge_analytics.html#edge_analytics

Was Data Preparation, Data Cleansing und Data Processing auf der Edge/Fog anbelangt, sind diese Lösungen noch sehr programmieraufwändig. Die Lösungen sind nicht unabhängig von der Cloud Lösung einsetzbar. Dann gibt es jene Software Lösungen, die unabhängig vom Cloud Provider Edge und Fog Computing möglich macht. Foghorn, ein Silicon Valley Start Up Unternehmen, ist ein Beispiel dafür.

Foghorn: https://www.foghorn.io/technology/

Foghorn bietet die Möglichkeit der Datenaufbereitung und einer sehr schnellen Ausführungs- Engine, der sogenannten CEP Engine. CEP bedeutet Complex Event Processing und beinhaltet verschiedene Methoden, um Logik möglichst in Real Time abzuhandeln. CEP kann innerhalb von Docker betrieben werden und läuft damit auch direkt auf der Edge. Meistens läuft die Software nicht auf den Endpunkten der Anlagen, sondern auf den physischen Gateways.

Fog: Ein Stück Hardware

Die physischen Gateways bringen den Vorteil mit sich, dass Software immer noch Nahe der Anlage läuft, gleichzeitig aber ein ganzes Bündel an Maschinen und Anlagenpunkten bedient werden können. Netzwerkmässig läuft die Software damit noch im Automatisierungsnetzwerk, also abgekoppelt von der Cloud, der Datenaustausch findet über die Standard-Konnektoren der Gateways statt. Wichtige Daten können aber von diesem Punkt einfach der Cloud zur Verfügung gestellt werden.

Um einen Eindruck über die Leistungsfähigkeit heutiger Gateways zu erhalten, hier einige Beispiele:

Hilscher Gateway „On Premise“ https://www.hilscher.com/fileadmin/cms_upload/en-US/Resources/pdf/netIOT_Edge_DS_Datenblatt_10-2015_DE.pdf

Weist zu den Maschinen hin die wichtigen Feld- und IoT Protokolle auf: Profibus, Profinet, Modbus, MQTT, OPC-UA und andere. Leistungsmässig bis 2 GHz, 4 GB DDR3 RAM und 128 GB SSD. Physische Trennung von Automatisierungs- und Cloud Netzwerk aus Gründen der Security.

Dell Edge Gateway der 5000 Series

http://www.dell.com/ch/unternehmen/p/dell-edge-gateway-5000/pd
Als Vergleich dieses Dell Edge Gateway, welches etwas schwächere Leistungsdaten 1.33 GHz, 2 GB DDR3 RAM und 32 GB SSD in der gleichen Preisklasse von ca. 1000 $.

HP stellt sowohl Mittelklasse als auch High End Gateways her. Hier eine Mittelklasse Ausführung

HP Gateway: HPE GL20 IoT Gateway

https://www.hpe.com/us/en/product-catalog/servers/edgeline-systems/pip.hpe-edgeline-el20-intelligent-gateway.1008670391.html

Intel® i5 CPU, 8 GB RAM, 64 GB SDD Storage
Aber auch eine High End Ausführung wie folgendes System zu haben:


HPE Edgeline EL1000 Converged Edge System

https://www.hpe.com/us/en/product-catalog/servers/edgeline-systems/pip.hpe-edgeline-el1000-converged-edge-system.1008670396.html

Mit bis zu 16 Cores und 4 TB Disc Storage lassen sich hier schon sehr schöne analytische Lösungen betreiben.

Zusammenfassung und Fazit

Zukünftige analytische Lösungen werden weder nur auf der Maschine noch nur in der Cloud betrieben werden. Immer häufiger werden stattdessen Fog Architekturen die passende Lösung sein.

Hier kommen Kombinationseinsätze von physischen Gateways und Cloud Plattformen zum Einsatz, eine kostengünstige Form zur Umsetzung analytischer Lösungen nahe der Maschine oder Anlage bei gleichzeitiger optimaler Nutzung von Compute Ressourcen in der Cloud.

Welche Herausforderungen verbleiben?

  • Die IoT/Edge & Fog Lösungen sind neuem Datums und zur Zeit einer starken Entwicklung unterworfen.
  • Es ist immer zu definieren, welche Daten in die Cloud gegeben und welche Daten in der Edge und Fog verbleiben.
  • Storage, CPU und Kostengrenzen in der Edge/Fog.
  • Modellbildung an einem Ort – Ausführung und Verteilung an mehreren Orten.
  • Standards für Peer to Peer Lösungen sind noch nicht genügend vorhanden.