Beiträge


Viele IoT-Geschäftsmodelle sind nur mit Hilfe global nutzbarer Konnektivität möglich, wobei aus Gründen der Prozessoptimierung und Kostenminimierung eine intelligente Reduzierung der Datenmenge bereits am Ort ihrer Entstehung stattfinden sollte. Die Lösung dafür sind IoT-Edge-Gateways, welche nahe der Datenquelle – also am Rand („Edge“) des weltweiten Kommunikationsnetzes – positioniert und zu einer intelligenten Datenvorverarbeitung befähigt sind.

Als Hilfestellung bei der Auswahl des richtigen IoT Edge-Gateways vergleichen wir für Euch in einer Video-Serie im Rahmen des SIC! TechTalks die Vor- und Nachteile von aktuell am Markt befindlichen IoT-Edge-Gateway Devices.

Neben den Hardware-Eigenschaften werden insbesondere die nicht sofort so offensichtlich erkennbaren Vor- und Nachteile rund um die Software untersucht, gezeigt und erläutert, wie z.B.

  • welches Betriebssystem kommt zum Einsatz?
  • wie sind die Konzepte zur Verwaltung eigener Software?
  • wie steht es um das Thema Updatebarkeit (a. der eigenen Software / b. des Betriebssystem selbst)?
  • wie sieht es mit der Zukunftssicherheit aus?

 





Der IoT-Edge-Gateway-Vergleich wird fortgesetzt,

Videos zu weiteren IoT Edge Devices sind in Vorbereitung!

 


Edge Computing in der Praxis

Unsere Expertise im Bereich IoT in der Cloud und Embedded Engineering hat bereits zum Erfolg von zahlreichen Innovationen beigetragen.

Einige Beispiele aus der Praxis für den Einsatz von IoT Edge Gateway Devices finden Sie in unseren IoT-Projekt-Referenzen.


Warum Edge Computing?

Erfahren Sie, wie wir den Wert von Daten steigern und die IoT-Cloud-Kosten senken indem wir Sensor-Daten bereits auf den Edge Devices für die Cloud mit AWS Greengrass veredeln:

Vorteile und Funktionen mit Edge Computing


Kostenfreie IoT Projekt-Beratung

Sie haben ein IoT Projekt und benötigen Unterstützung? Profitieren Sie bei unserem „Experten-Feedback“ Angebot von unserem Know-how und der langjährigen Erfahrung aus zahlreichen IoT-Projekten. In einer kostenfreien Online-Beratungsstunde erhalten Sie Feedback für Ihre IoT-Cloud-Projekte von unseren IoT-Spezialisten sowie Best Practice Tipps.

Mehr Info


 


Viele IoT-Geschäftsmodelle sind nur mit Hilfe global nutzbarer Konnektivität möglich, wobei aus Gründen der Prozessoptimierung und Kostenminimierung eine intelligente Reduzierung der Datenmenge bereits am Ort ihrer Entstehung stattfinden sollte. Die Lösung dafür sind IoT-Edge-Gateways, welche nahe der Datenquelle – also am Rand („Edge“) des weltweiten Kommunikationsnetzes – positioniert und zu einer intelligenten Datenvorverarbeitung befähigt sind.

Als Hilfestellung bei der Auswahl eines für Ihr IoT-Projekt passenden IoT Edge-Gateways vergleichen wir für Sie in unserer neuen Video-Serie im Rahmen des SIC! Tech Talks die Vor- und Nachteile von aktuell am Markt befindlichen IoT-Edge-Gateway Devices.

Dabei werden neben den Hardwareeigenschaften insbesondere auch die nicht sofort so offensichtlich erkennbaren Vor- und Nachteile rund um die Software untersucht, gezeigt und erläutert. Beantwortet werden Fragen, wie z.B. …

  • welches Betriebssystem kommt zum Einsatz?
  • wie sind die Konzepte zur Verwaltung eigener Software?
  • wie steht es um das Thema Updatebarkeit (a. der eigenen Software / b. des Betriebssystem selbst)?
  • wie sieht es mit der Zukunftssicherheit aus?

In der ersten Folge stellen wir die HARTING Mica® vor:

zum Video


 


 


In unserer neue Video-Serie „TechTalk“ plaudern unsere Entwickler und Techniker aus dem Nähkästchen und geben nützliche Tipps zu aktuellen technischen Themen. Zum Start zeigt unser CTO Rayko Enz in seinem Video „Flexible IoT Edge Datenverarbeitung mit dem TICK Stack“, wie man mit dem von SIC! Software bereitgestellten Container für die HARTING MICA Box den TICK Stack von InfluxDB deployen und damit sehr einfach Maschinen- bzw. Sensordaten in einer Datenbank auf dem Gateway speichern und auf einem Dashboard ganz einfach visualisieren kann.

Hier geht’s zum Video:

https://youtu.be/Ln5yygAShq0


 

Eine grundlegende Anforderung vieler IoT Projekte ist die Visualisierung der Daten, egal ob Sensor- oder Maschinendaten. Insbesondere steht gerade zu Beginn vieler Projekte eine Visualisierung der Daten direkt am Edge ganz oben auf der Wunschliste von Kunden, aber auch dem Entwickler selbst.

Bei dieser Anforderung geht es in erster Linie darum, schnell und einfach Feintuning an den erhobenen Daten vorzunehmen oder einfach nur zu sehen, ob Sensoren richtig positioniert oder kalibriert sind.

In vielen IoT Projekten und bei Demonstratoren auf Messen sehen wir immer wieder Node-RED als das Mittel der Wahl, um Dashboards auf IoT Edge Geräten zu bauen und diese initiale Visualisierung der Daten zu ermöglichen.

Ohne Frage ist das sicher eine Möglichkeit, vergleichsweise schnell und mit wenigen oder keinen Programmierkenntnissen Datenvisualisierung zu betreiben.

Allerdings hat die Nutzung von Node-RED in der Praxis auch viele Einschränkungen, die uns bewogen haben, hier einen etwas anderen Weg zu gehen. Auch wenn es in Node-RED sehr einfach erscheint, Dashboards zu bauen, so sind diese jedoch trotzdem relativ starr. Sobald sich an den eingehenden Daten etwas verändert – und sei es nur ein neuer Sensorwert – muss sofort wieder am Dashboard Hand angelegt werden. Scripte werden angepasst, neue Widgets werden angelegt und positioniert etc.

Zudem sind die Daten dann meist auch verloren, wenn man sich nicht die Mühe gemacht hat, diese auch in einer Datenbank zwischenzuspeichern.

Um das alles flexibler zu gestalten, bietet sich der Technologistack von Influx, der sogenannte „TICK Stack“ an. TICK steht hier für Telegraf – InfluxDB – Chronograf – Kapacitor. InfluxDB stellt hier den Kern als TimeSeries Datenbank dar. Telegraf ist die universale Waffe, um die Daten von beliebigen Quellen in die Datenbank zu bekommen und Chronograf ist für die Visualisierung zuständig.

Wie sieht das in der Praxis also aus:

 

Die Daten werden vom Sensor oder der Maschine an einen MQTT Broker (z.B. Mosquito) geschickt.

Der Telegraf kann mit Bordmitteln auf den MQTT Broker auf beliebige Topics subscriben und diese Daten dann direkt an die Datenbank weitergeben. Der Vorteil, der diese Konstellation so flexibel macht, ist die Tatsache, dass man nirgends spezifizieren muss, welche Daten erwartet werden. Solange die MQTT Payload aus Key/Value Werten besteht, werden diese alle einfach in die Datenbank übernommen. Wenn einer dazu kommt, muss nichts verändert werden.

Entscheidend ist hier die Konfiguration des MQTT Consumer Plugin:

https://github.com/influxdata/telegraf/tree/master/plugins/inputs/mqtt_consumer

Zum einen muss das Topic spezifiziert werden. In diesem Beispiel würde alles, was unterhalb von Sensor gepublished wird, in die Datenbank übernommen.

topics = [

„sensors/#“,

]

 

Am Ende der Config ist es noch wichtig, das Datenformat zu spezifizieren:

data_format = „json“

 

Ist das gemacht, landen alle Daten vom MQTT Broker automatisch in der Datenbank.

Die Payload des MQTT sollte dieses Format haben:

{

„Druck“: 100,

„Temperatur“: 34.2

}

Damit ist die Arbeit auch schon getan, denn der Chronograf wird diese Daten über den Explore direkt für die Visualisierung zugänglich haben.

Jetzt kann ich ohne weitere Konfiguration mit beliebigen Sensordaten arbeiten und muss mich nicht mehr um die Konfiguration dieser Kette kümmern.

Als weiterer kleiner Nebeneffekt überwacht der Telegraf auch noch den Host und man bekommt ein Systemmonitoring (Speicher/CPU/Festplatte) zusätzlich geschenkt.


Download

Hier können Sie das Beispielprojekt für die HARTING MICA als Datei downloaden:

SIC-TICK-Container_v1.0.tar


Video

Hier finden Sie ein Anleitungsvideo, in dem Schritt für Schritt gezeigt wird, wie man mit dem von SIC! Software bereitgestellten Container für die HARTING MICA den TICK Stack von InfluxDB deployen und damit sehr einfach Maschinen- bzw. Sensordaten in einer Datenbank auf dem Gateway speichern und auf einem Dashboard ganz einfach visualisieren kann.

Video: Flexible IoT Edge Datenverarbeitung mit dem TICK Stack


Stehen Sie aktuell vor einer Edge Computing Herausforderung?

Gerne unterstützen unsere IoT Experten Sie bei Ihren Projekten und helfen Ihnen dabei, möglichst optimale Lösungen zu finden.

Sprechen Sie uns an: Kontakt


 

 

Überall dort wo Cloud-Computing auf die Steuerung und Überwachung im Feld trifft und dies zudem zuverlässig funktionieren muss, wird oft auf Edge-Computing zurückgegriffen.
Dies hilft beispielsweise Unterbrechungen im Betrieb zu vermeiden, da das Gesamtsystem auch ohne eine permanente Online-Verbindung über ein Netzwerk weiter funktioniert.
In der Cloud selbst (und dies gilt auch für jedes vernünftige Rechenzentrum) ist es hier ohne Probleme möglich, eine entsprechende Verfügbarkeit zu gewährleisten.
Wendet man den Blick aber in Richtung Edge, sieht die Welt wieder ganz anders aus: Keine redundante Internetanbindung/-Infrastruktur, Zuständigkeiten verschiedenster Dienstleister/Provider und Netzwerke zwischen Rechenzentrum und Edge-Device.
Hier kann dann schnell mal etwas schiefgehen oder einfach ausfallen – die Fehlerquellen sind sehr vielfältig. Eine Analyse der Probleme ist jedoch unter diesen Umständen relativ zeitraubend und aufwendig.
Aber schieben wir diese sehr kurze Einführung in das Thema Edge-Computing beiseite und betrachten das hieraus resultierende Problem:

Wie verwalte ich die Edge-Devices am besten?

Hat man bereits ein Cloud-Setup für seine IT-Infrastruktur und nutzt hier die Vorteile wie beispielsweise IaC (Infrastrucute-as-Code) und CD (Continuous-Delivery), meldet sich sofort dieses unangenehme Gefühl in der Magengegend, das einem nichts Gutes signalisiert, da solche Tools und Workflows für Edge-Computing – wenn überhaupt – nur sehr schwer umzusetzen sind.
Um genau dieses Thema zu adressieren, haben die großen Cloud Anbieter – und hier allen voran AWS – entsprechende Frameworks für Edge Devices geschaffen. Mit AWS Greengrass steht ein mächtiges Werkzeug zur Verfügung, um Komfortfunktionen, wie man sie aus der Cloud Welt kennt, auch auf einem Edge Device zur Verfügung zu haben.
Zu den wichtigsten Funktionen zählen:

  • Sicherer Remote Zugriff auf die Geräte (Tunnel)
  • Verwaltung von Software, insbesondere die Verteilung von Updates
  • Sicherer Datenkanal in die Cloud mit automatischer Zwischenspeicherung für den Fall, dass die Verbindung nicht möglich ist
  • Eine Laufzeitumgebung, um z.B. Serverless-Anwendungen, wie z.B. Lambda auszuführen

Der Workflow sieht dabei primär vor, die Greengrass Installation in einen Container zu packen und diesen auf dem Edge-Device laufen zu lassen. Da sich tendenziell auch viel häufiger Änderungen an der Anwendung selbst ergeben, als es z.B. nötig ist, eine neue Greengrass Version einzusetzen oder die Firmware des Edge-Devices zu aktualisieren, ist hiermit zumindest schon einmal ein großer Teil der Deployments von Änderungen an der Software sehr einfach möglich.

Firmware und Betriebssystemupdates

Was ist aber mit dem ganzen Rest: Updates von Greengrass selbst, das Betriebssystem, sonstige Systemkomponenten, wie Treiber, Bibliotheken, usw.?
Auch diese Teile des Systems müssen regelmäßig aktualisiert werden!
Um dies zu ermöglichen, ist ein Edge-Device mit einer zuverlässigen Gesamtarchitektur notwendig. Das bedeutet, das es möglich sein muss, die Basis Softwarekomponenten upzudaten, ohne hier im Urschleim der Linux Paketverwaltung herumzuwühlen.
Aus unserer Sicht hat HARTING hier mit der MICA Box ein hervorragendes Gesamtsystem gebaut, welches den Betreiber von diesen Arbeiten großenteils entlastet.
Was bedeutet das in der Praxis?
Bei der HARTING MICA stellt der Hersteller das Basissystem (Linux) sowie diverse Funktionscontainer zur Verfügung. Das Besondere dabei ist der Umstand, dass alle vom Hersteller gelieferten Container mit einer Web-Socket Schnittstelle ausgestattet sind. Damit wird es einem ermöglicht, sehr einfache die Container zu Verwalten und zu Konfigurieren.
Auf diese Weise ist es mit sehr geringem Aufwand möglich, über den von SIC! Software verfügbaren Greengrass Container alle anderen Container auf der MICA und das Betriebssystem selbst über einige wenige API-Aufrufe vollständig zu steuern. Der Greengrass Container ist der Master und somit in der Lage, neue Container zu installieren, bestehende Upzudaten, etc.
Ohne die Bereitstellung dieser Basisfunktionalität von HARTING müsste der geneigte Nutzer das alles selbst in die Hand nehmen. Insbesondere das Update der Basissoftware eines Edge-Device, wie der MICA, ist ohne diese Vorarbeiten nur mit erheblichem Entwicklungsaufwand zu bewerkstelligen.
Um dies zu gewährleisten greift Harting hier auf Container zurück.
Allerdings setzt man hier aufgrund der nur geringen Hardware-Ressourcen, die in der Regel auf einem Edge-Device zur Verfügung stehen, nicht auf Technologien wie Docker oder Podman, sondern verwendet die Basis-Technologie LXC.
Mit Containern kann man alle diese Abhängigkeiten als ein einzelnes Image zur Verfügung stellen, dass mit wenig Handgriffen installiert bzw. aktualisiert werden kann.
Nachdem nun die Application(s) sowie das Image über eine CD-Pipeline ausgerollt werden können, bleibt noch die Aktualisierung des Host-OS bzw. der Firmware selbst.
Hier gilt es ein Edge-Device auszuwählen, das per Netzwerk aktualisiert werden kann.
Integrieren wir nun unseren Management-Dienst mit AWS Greengrass, erhalten wir einen zentralen Management-Hub in der Cloud, der alle Teilbereiche unseres Edge-Devices verwaltet – von Firmware über LXC-Container bis hin zur Greengrass Installation.
Und damit ist dann das Ziel eines jeden Systemadministrators erreicht: Ein transparenter, durchgängiger Prozess, um alle Ebenen der Software eines professionell eingesetzten Edge-Computing-Devices zu verwalten.

Fazit

Unter Verwendung der HARTING MICA und von AWS Greengrass lassen sich grundsätzlich alle Aspekte eines Edge-Devices zentral verwalten. Integrieren wir diese nun in einen Management-Dienst, erhalten wir einen zentralen Management-Hub, der alle Teilbereiche unseres Edge-Devices verwaltet – von Firmware über LXC-Container bis hin zur Greengrass Installation. Außerdem lassen sich so der Status und die Zustände aller Komponenten zentral überwachen, und im Falle von Problemen können diese schnell identifiziert werden oder sogar vor dem Eintreten erkannt und beseitigt werden.


Einige IoT Praxis-Beispiele für den Einsatz der der HARTING MICA mit AWS Greengrass finden Sie bei unseren IoT Case Studies.

Z.B. beim Technologiedemonstrator für vernetzte Ventilatoren, einem Projekt der Firma Rosenberg Ventilatoren:

 


Stehen Sie aktuell vor einer Edge Computing Herausforderung?

Gerne unterstützen unsere IoT Experten Sie bei Ihren Projekten und helfen Ihnen dabei, möglichst optimale Lösungen zu finden.

Sprechen Sie uns an: Kontakt

 


 

Ein seit mehr als 50 Jahren bekanntes Geschäftsmodell erlangt durch die Möglichkeiten der Digitalisierung mit einem Mal ein komplett neues Gewicht und hat weltweit bereits mehr als 50 % aller Fertigungsunternehmen dazu gebracht, ihr Geschäftsmodell zu überdenken und teilweise sogar vollkommen umzukrempeln. Die Rede ist von „Servitization“. Doch was ist das und wem nützt es wirklich?


Was ist Servitization?

„Servitization ist eine Geschäftsmodellinnovation, die für produzierende Unternehmen relevant ist und die Änderung des bisherigen Angebotsportfolios weg von nur Sachgütern und hin zu einer Kombination aus Sachgütern und Dienstleistungen bezeichnet. Damit spiegelt sie den gesamtwirtschaftlichen Trend zur Dienstleistungsgesellschaft auf Unternehmensebene wider.“ – Wikipedia

Anders gesagt: Hersteller ergänzen ihre Produkte durch Services oder tauschen diese sogar komplett damit aus. Dabei sind viele unterschiedliche individuelle Implementierungen möglich und es lassen sich drei grundsätzliche Service-Typen unterscheiden: Base Services, Intermediate Services und Advanced Services. [1]

  • Base Services sind solche Dienstleistungen, die zusätzlich zur Produktbereitstellung kommen. Dies ist in der Regel eine Bereitstellung von zusätzlichen zugehörigen Produkten, wie zum Beispiel Ersatzteile.
  • Intermediate Services dienen dazu, die Funktion eines Produktes und dessen Leistungsfähigkeit zu garantieren, beispielsweise durch Überwachung des Betriebs und präventive Wartungsarbeiten.
  • Advanced Services bedeuten, dass ein Kunde kein physisches Produkt, sondern anstelle dessen eine Leistung erwirbt und pro solch einer erbrachten Leistung bezahlt. Es findet hier vermehrt kein Eigentumswechsel des Produktes statt. Denkbar sind hier viele verschiedene Möglichkeiten.

Ein bekanntes und oft zitiertes Beispiel für die Anwendung eines Advanced Service, bietet der Triebwerkhersteller Bristol Siddeley. Dieser hat mit dem „Power-by-the Hour“-Modell bereits in den 1960er Jahren ein Servitization-Modell eingeführt. Nachdem Bristol Siddeley 1968 von Rolls Royce gekauft wurde, wurde das Konzept aufgegriffen, ausgebaut und seitdem als Service namens TotalCare bis heute angeboten.
Dabei geht es darum, die Triebwerke für Flugzeuge nicht mehr im klassischen Sinne an den Flugzeugbauer zu verkaufen. Der Flugzeugbauer bezahlt lediglich für die tatsächlichen Betriebsstunden des Triebwerks. Das Gerät bleibt dabei vollständig Eigentum von Rolls Royce, die sich dann auch um Wartung und Reparatur kümmern. Rolls-Royce war es so möglich, die Erlösströme zu stabilisieren und höhere Umsätze zu erzielen. Gleichzeitig bietet es dem Kunden wiederum planbare Betriebskosten, reduzierte finanzielle Risiken und ein effizienteres und zuverlässigeres Produkt.

Servitization findet aber auch vereinzelt in anderen Branchen Anwendung. Während Beispiele wie die Betreuung einer Maschine durch den Hersteller relativ naheliegend sind, findet man Servitization auch immer häufiger in zunächst unüblich erscheinenden Bereichen. So hat zum Beispiel das schwedische Bauunternehmen Skanska ein Krankenhaus gebaut und ist nun im Anschluss auch der Betreiber des Krankenhauses.

Ein Servitization Potenzial liegt für einen Hersteller meistens dann vor, wenn die Service-Angebote außerhalb der Kernkompetenz des Kunden liegen. Es entsteht durch sie also zusätzlicher Aufwand und Kosten und somit kein Gewinn für den Kunden.

 

Vorteile durch Servitization

Für Hersteller und Kunden bietet Servitization einen gemeinsamen Fokus auf den reibungslosen Betrieb. Es ergibt sich für Hersteller und Kunde eine Angleichung der Anforderungen an das Produkt. Für Kunden steht in der Regel ein möglichst effizientes und langlebiges Produkt im Vordergrund. Der Hersteller verdient allerdings unter Umständen mehr an seinem Produkt, wenn es gegen Abrechnung repariert wird oder wenn aufgrund eines Defektes ein neues (Austausch-) Produkt verkauft werden kann. Durch Servitization entsteht nun ein Zustand, indem sowohl für den Kunden, als auch den Hersteller, ein wartungsarmes Produkt den größten finanziellen als auch wirtschaftlichen Nutzen bietet.
Da der Hersteller nun auch z.B. für die Wartung zuständig ist, werden für ihn die Bedürfnisse des Kunden deutlich relevanter. Je zuverlässiger und wartungsärmer das Produkt, um so besser für den Hersteller, da jetzt weniger Wartungsarbeiten ausgeführt werden müssen und mehr Betriebsstunden abgerechnet werden können. Überspitzt könnte man sagen, dass theoretisch betrachtet der Hersteller selber die Rolle übernimmt, die bisher sein Kunde eingenommen hatte. Wenn so die Effizienz und Langlebigkeit von Produkten verbessert werden kann, wird im selben Moment der Betrieb automatisch ressourcenschonender und nachhaltiger.

Darüber hinaus kann man Mithilfe eines Servitization-Modells die Beziehung zu Kunden festigen und vertiefen und es ist einem Unternehmen möglich, sich von seinen Mitbewerbern durch mehr als nur die Produktqualität und den Preis zu differenzieren. Ein Lieferant von Sachgütern lässt sich schneller austauschen, als eine enge Zusammenarbeit mit einem Kunden. Außerdem lässt sich so bei einem Kunden der Ausschluss eines Mitbewerbers erzielen.

Natürlich wirkt sich ein Servitization-Modell auch auf den Umsatz aus. So lässt sich durch Service-Angebote beispielsweise ein stetiger Erlösstrom bilden und damit die Erlöse stabilisieren.
Durch die Positionierung als Dienstleister am Markt, kann zusätzlich auch die Wettbewerbsfähigkeit für die Zukunft gesichert werden.

 

Wann ist Servitization für mich lohnenswert?

Als Hersteller ist es zunächst wichtig zu erkennen, ob Servitization Potential vorhanden ist und worin es liegt. Es gilt herauszufinden, welche Aufgaben ein Produkt bei einem Kunden auslöst und welche dieser Aufgaben der Hersteller selbst bewältigen kann. Diese Aufgaben bilden typischerweise immer dann ein geeignetes Servitization Potential, wenn sie außerhalb der Kernkompetenzen des Kunden aber innerhalb der Kernkompetenzen des Herstellers liegen.

Ein typisches Beispiel wäre hier wieder die Wartung von Maschinen. Wer, wenn nicht der Hersteller selber weiß am besten, wie sich seine Maschinen verhalten sollten und wie sie optimal zu warten sind. Darüber hinaus können aber auch andere Bereiche wie der Betrieb, die Installation oder viele weitere individuelle Vorgänge ein Servitization Potential bergen. Wenn erkannt wurde, in welchen Bereichen Servitization Potential vorhanden ist, sollte geprüft werden ob dies einen wirtschaftlichen Nutzen bietet. Hierfür gibt es verschiedene Anhaltspunkte, z.B.
Wie viele bereits in Betrieb befindliche Einheiten gibt es pro neu Verkaufter Einheit? Je mehr Einheiten sich bereits im Betrieb befinden, um so sinnvoller ist es, mit diesen Geschäfte zu machen, statt sich auf die Geschäfte mit neuen Einheiten zu konzentrieren.
Wie ist das Verhältnis der Kosten über die gesamte Produktlebenszeit zu den Anschaffungskosten für den Kunden? Je höher dieses Verhältnis ist, um so lohnenswerter ist das Service-Geschäft.
Weniger Lohnenswert ist eine Dienstleistung zum Beispiel dann, wenn ein Lieferant oder Hersteller im Produktgeschäft zum Beispiel durch Patente oder besondere Technologien sehr stark ist.

So individuell Service Angebote sein können, so unterschiedlich lässt sich auch die Wirtschaftlichkeit eines solchen Service-Angebots ermitteln. Im Endeffekt sollte jeder einzelne Fall separat geprüft werden.

 

Wie gestaltet man einen effizienten Service?

Servitization ist – wie am Rolls Royce Beispiel zu sehen ist – nicht nur durch die fortschreitende Digitalisierung entstanden. Aber die Digitalisierung bietet neue Möglichkeiten, ein Servitization-Modell immer optimaler umzusetzen.

Denn der Servitization Ansatz profitiert von den gleichen oder zumindest von vergleichbaren Technologien, die auch verschiedenen IoT-Anwendungen oder der Industrie 4.0 zugrunde liegen: Sammlung, Übermittlung, Speicherung und Analyse von Daten.

In verschiedenen Bereichen hat die SIC! Software GmbH bereits verschiedenste Sensoren zum Sammeln von Daten eingesetzt und damit ermöglicht, z.B. den Betrieb einer Maschine zu überwachen. Dabei sind verschiedene Möglichkeiten der Analyse denkbar. Ausgelegt auf bloßes Erkennen der Betriebszeit über kleine Änderungen und Abweichungen im Betriebsablauf bis hin zum Erkennen von kompletten Ausfällen.
Bei einer geeigneten Auswertung sind die Daten außerdem dazu geeignet, Wartungsintervalle flexibel auf das tatsächliche Nutzungsverhalten der Maschinen anzupassen. Durch das Überwachen von Verschleißteilen kann ein möglicher Betriebsausfall der Maschine vorhergesagt werden und vorbeugend gehandelt werden („Predictive Maintenance“). So kann die Betriebszeit der Maschine maximiert werden, da unvorhergesehene Ausfälle und Wartungsarbeiten minimiert werden.

Es ist außerdem möglich, das Übermitteln und Visualisieren der Daten in Echtzeit zu realisieren. Über die passende IoT Cloud-Anwendung können die Art der Visualisierung und Alarme individuell konfiguriert und so auf jeden Anwendungsfall abgestimmt werden. Dies ermöglicht in Echtzeit auf Veränderungen im Betriebsablauf zu reagieren, Optimierungen vorzunehmen werden und Daten für weitere Analysen bereitzustellen.

So ist es möglich, eine Abrechnung basierend auf Betriebszeit zu realisieren, vollständig automatisiert Servicetechniker zu Wartungs- und Instandsetzungsarbeiten zu rufen, Verbrauchs- und Verschleißteile automatisch nachzubestellen, eine Rund-um-die-Uhr-Betreuung zu ermöglichen und noch viele weitere denkbare Anwendungsfälle umzusetzen.

Auch über den Einsatz von Servitization-Modellen hinaus birgt die Möglichkeit, Daten über seine Produkte zu sammeln, viele Vorteile. Diese lassen sich unter anderem zur Optimierung der Produkte, Entwicklung von Innovationen und letztendlich auch zur Differenzierung gegenüber Mitbewerbern im Markt einsetzen.

 


[1] [Baines, Tim & Lightfoot, Howard: Made to Serve: How manufacturers can compete through servitization and product service systems. Wiley, 2013, S. 64–68]

Wenn die ersten Konzeptstudien eines IoT-Projektes das Entwicklungslabor verlassen und mit der industriellen Realität konfrontiert werden, geraten die vielfach eingesetzten populären Bastel-Platinen-Rechner wie Raspberry PI oder Beaglebone beim Einsatz als Edge Computing Device schnell an ihre Grenzen. Dann ist eine leistungsfähige, professionelle Hardwareplattform erforderlich.

Hier hat sich in unserem Hause in vielen IoT-Projekten im Industrieumfeld die HARTING MICA® (Modular Industry Computing Architecture) als kleines, leistungsfähiges Edge-Computing System überaus bewährt.

Der gesamte mechanische Aufbau ist sehr robust gestaltet. Egal ob Staub, Öl-Nebel oder feine Eisenspäne aus dem CNC-Bohrwerk – die MICA® Box erfüllt die Schutzklasse IP67 und lässt sich davon nicht beeindrucken. Ebenso genügen die an der MICA® Box verbauten Steckverbinder höchsten Ansprüchen an Lebensdauer und Kontaktsicherheit. Damit ist die MICA® Box ohne Einschränkungen industrietauglich.

HARTING MICA als IoT Edge Computing Device 01

Dem interessierten Leser möchten wir deshalb hier einen Einblick in das Innenleben dieses Edge-Computing Devices geben.

Merkmale der MICA® BOX

Zunächst ist die Harting MICA® BOX eine sehr unscheinbare kleine Box aus Aluminium die nach IP67 geprüft ist. Die Hardware des Systems ist mit einem 1 GHz ARM-Prozessor, 1 GB RAM und 4 GB eMMC Speicher ausgestattet. Zudem kann das System um bis zu weitere 32 GB Flash über eine Micro-SD-Karte nachgerüstet werden.

Als Betriebssystem kommt ein virtualisiertes, auf dem Kernel 3.2.X basierendes, LINUX zum Einsatz. Dies kann mit einer Vielzahl von weiteren Betriebssystem-Komponenten erweitert werden. Zu den Möglichkeiten, die hier auf der Softwareseite beim Einsatz als Edge Computing Device bestehen, folgt in Kürze ein weiterer Blog-Artikel.

Das Gehäuse

Die MICA® Box besitzt ein robustes Alu-Druckgussgehäuse aus einer Aluminum-Slilizium-Magnesium-Legierung (AlSi10Mg). Das gibt dem Gehäuse eine hohe mechanische Stabilität, gute thermische Eigenschaften als passiver Kühlkörper und ein geringes Gewicht.

Das mechanische Konzept der MICA® erlaubt die flexible, modulare Konfiguration mit verschiedenen Schnittstellen. Dabei ist stets die Schutzklasse IP67 erfüllt und die MICA® kann in einem Temperaturbereich von -25 Grad Celsius bis +75 Grad Celsius im Dauerbetrieb eingesetzt werden.

Die Rückwand der MICA® Box ist mit einer Gummidichtung versehen, ebenso alle Bohrungen und Durchlässe für Steckverbinder, LED usw.

Nach dem Entfernen der Schrauben kann die Rückwand abgenommen und der Kühlkörper mit den einzelnen Platinen herausgezogen werden.

Die Module der MICA® Box

Es folgt hier der Blick auf das modulare Platinen-Konzept der MICA® Box. Oben in der Mitte die zentrale Prozessor-Platine mit dem SD-Karten Halter. Links die I/O-Platine – in diesem Falle die Version mit zwei USB 2.0 Schnittstellen. Rechts die Stromversorgungs- und Netzwerkplatine mit LAN-POE-Anschluss und Streckverbindern für eine externe 24V Stromversorgung.

Der Prozessor der MICA® Box ist auf der Unterseite der CPU-Platine montiert. Die Kühlung erfolgt passiv über einen groß dimensionierten Alu-Kühlkörper.

Hier der Blick auf die CPU-Platine mit entfernten Schnittstellenmodulen.

Die Verbindung zwischen CPU Platine und den Schnittstellenmodulen erfolgt über einen Kontaktbügel mit leitfähigem Gummi. Damit ist die Verbindung elektrisch sehr sicher und gegen Vibration geschützt.

So entsteht eine kompakte Einheit von Kühlkörper, Platinen und Steckverbindern die in das Gehäuse eingeschoben wird.

Im Inneren des Gehäuses sorgen dann großzügig dimensionierte Auflageflächen für eine formschlüssige Verankerung der Elektronik im Inneren. Gleichzeitig wird der Kontaktbügel mit definierter Kraft auf die Platinen gedrückt und so eine vibrationssichere elektrische Verbindung der einzelnen Module im Inneren der MICA® Box garantiert.

Es ist dieser intelligente mechanische Aufbau, dem die Harting MICA® Box ihre Widerstandskraft im industriellen Umfeld verdankt.

Hier zum Schluß noch ein Blick auf alle Bauteile einer MICA® Box.

Zusammenfassung

Mit der Harting MICA® Box steht ein Edge-Computing Device mit einer sehr hohen Fertigungsqualität „Made in Germany“ zur Verfügung. Die längerfristige Verfügbarkeit ist durch die Firma HARTING garantiert.


Sie haben eine prototypische IoT Anwendung lauffähig und wollen diese jetzt im Feld erproben?

Sie wollen Sicherheit, dass Ihr wertvolles IoT-Projekt nicht wegen unzulänglicher Edge-Computing Hardware verzögert wird oder gar scheitert?

Dann sprechen Sie uns an.

Gemeinsam mit unseren IoT-Experten finden wir sicherlich einen Weg, Ihr bestehendes IoT-Pilotprojekt von simpler Labor-Hardware wie dem Raspberry Pi auf eine industrietaugliche Edge Computing Plattform wie die HARTING MICA® Box zu heben.

Mit dieser Serie von Blog-Artikeln werden wir einige grundlegende Gedanken zum Themenkomplex des „Internet of Things“ – auch kurz „IoT“ genannt – für Planer und Entscheider in mittelständischen Unternehmen zusammengefasst haben.

Wir wollen damit häufig gestellte Fragen beantworten und unseren Lesern einen Einstieg geben, um erste Gedanken zum Thema IoT für das jeweilige Unternehmen zu formulieren.


In einer kürzlich veröffentlichten Studie des IT-Dienstleisters HCL Technologies nannten 46 Prozent der befragten Projektverantwortlichen die Nutzung der richtigen IoT-Plattform als eine der größten Herausforderungen für das IoT-Projekt des Unternehmens.

Typischer Weise werden dabei die folgenden Anforderungen an die IoT-Plattform gestellt:

  • Quantitative Skalierbarkeit
  • Automatisierbarkeit
  • Offenheit, Schnittstellen
  • Technologische Reife der Plattform

Nun versucht das Unternehmen mit den bekannten Methodiken umfassend zu planen und so durch die Auswahl der „perfekten“ IoT-Plattform sein Projekt zum Erfolg zu führen.
Aber: Eine Digitalisierung nach Fahrplan gibt es nicht. Die Evaluation von IoT-Plattformen ist daher vielfach nur eine unnötige Geld- und Zeitverschwendung!

Warum ist das so? Weil eine Entscheidung pro oder Contra einer Plattform oftmals nur an kleinen technischen Detailfragen festgemacht wird, die zudem immer nur auf Basis des jeweils aktuellen Wissenstandes im Projekt erfolgen kann. Bei IoT-Projekten wird aber fast immer Neuland betreten. Die Anforderungen, Zielsetzungen, Use-Cases und Prioritäten ändern sich sehr schnell. Diese Änderungen sind aber unmöglich vorhersehbar. Alle Versuche, die möglichen Szenarien bei der Planung in Summe zu berücksichtigen, führen entweder zu einem Projekt mit gigantischen Kosten oder aber zu einer sehr langwierigen Planungsphase, die am Ende den Projektfortschritt sehr stark verlangsamt.

Unsere Empfehlung lautet daher:

Wählen Sie eine große, flexible Cloud-Plattform und fangen Sie einfach an. Denn während Ihr Wettbewerber noch überlegt, welche IoT-Plattform er nehmen soll, haben Sie schon den ersten Prof-of-Concept am Start und können echte Erfahrungen im Feld sammeln. Bei Umsetzung von IoT-Projekten lassen sich zwar viele technische Aufgaben im Zweifelsfall durch erhöhten Ressourceneinsatz beschleunigen, nicht aber das Sammeln von Erfahrungen im Feld! Wer hier zuerst kommt, mahlt zuerst und kann sich schnell einen Wettbewerbsvorteil sichern, der von der Konkurrenz nur schwer wieder aufgeholt werden kann.

Was ist wirklich wichtig bei der Plattformauswahl?

Über die Jahre haben sich folgende Parameter als wirklich strategisch relevant erwiesen:

  • Größe des Cloud-Anbieters
  • Flexibilität der Architektur und Ihrer Komponenten
  • schnelle Release-Zyklen der Cloud-Dienste

Warum eine große Plattform? Weil dieser Anbieter vermutlich auch in 24 Monaten noch existiert. Weil nur die großen Anbieter genügend in die kontinuierliche technologische Weiterentwicklung investieren können.

Warum Flexibilität? Weil nur damit die Chance besteht, dass auch Ihre künftigen Anforderungen erfüllt werden – und dies sowohl in technologischer als auch in funktionaler Hinsicht. Gerade der mögliche Einsatz verschiedener Technologien im Rahmen einer Microsystemarchitektur erleichtert und beschleunigt die Integration vorhandener Systeme ganz enorm.

Warum schnelle Release-Zyklen? Weil nur so die Chance besteht, dass in den verwendeten Cloud-Diensten die unvermeidlichen Kinderkrankheiten und Fehler schnell verschwinden, fehlende Funktionen in endlicher Zeit ergänzt werden.

Wenn Ihnen also ein Beratungsunternehmen als Einstieg in Ihr IoT-Projekt eine Studie für den Vergleich von 60 IoT-Plattformen empfiehlt, schicken Sie es nach Hause. Das Geld können Sie sinnvoller einsetzen.


Erwecken Sie Ihre Digitalisierungs-Idee zum Leben und präsentieren Sie sie LIVE vor Management, Kollegen und Kunden: IoT-Showcase-Angebot  


Warum hat sich SIC! Software bei IoT-Projekten auf die Cloud-Dienste von AWS fokussiert?

Die Gründe für AWS sind ganz einfach:

  • Großer internationaler Anbieter, der nicht vom Markt verschwinden wird
  • Transparentes Preismodell
  • Ausgereifte Infrastruktur, rationelle Administrationsmöglichkeiten
  • sehr breites Spektrum unterstützter Programmiersprachen
  • Kein erzwungener Technologischer Lock-In
  • Stabile SDKs und Bibliotheken, umfassende Dokumentation
  • Schnelle Release-Frequenz der Dienste
  • Breites MicroService Portfolio
  • Weltweite Hoch-Verfügbarkeit

Weil es sich bei Technologie-Integratoren wie bei einem 5-Sterne-Restaurant verhält: Wenn die Speisekarte zu groß ist, leidet die Qualität! Viel wichtiger ist die Kenntnis wie man mit den Zutaten das optimale Ergebnis erreicht. Daher gibt es in den Top-Gourment-Restaurants nur ein Menü auf der Speisekarte – genauso wie sich unser Top-Expertenteam auf einen flexiblen, leistungsfähigen und zukunftssicheren Technologiebaukasten fokussiert.


Wenn Sie lernen möchten, mit welchen Methodiken man die für die eigene IoT Anwendung strategisch relevanten Schlüsselkomponenten identifiziert, um die Kontrolle über seine Daten zu behalten, erfahren Sie in Folge 1 unserer Webinar-Reihe „IoT Projekt-Know-how für Planer und Entscheider“ mit dem Titel „Die Cloud als notwendige Basis für IoT-Lösungen – das AWS-Praxisbeispiel „tempmate“.

Infos & Anmeldung


Weitere Teile dieser Blog-Artikel Serie:

IoT Projekt-Know-how für Entscheider – Teil 1: Warum müssen wir in die Cloud?

IoT Projekt-Know-how für Entscheider – Teil 2: Warum sollen wir jetzt IoT Projekte starten?

IoT Projekt-Know-how für Entscheider – Teil 3: Warum sollen wir in eine eigene IoT Anwendung investieren?


Übrigens: Als integrativer Entwicklungsdienstleister für AWS (Amazon Web Services) Cloud-Lösungen bieten wir Ihnen ein fundiertes Know-How in den Themenfeldern Internet of Things (IoT), Smart Products und Industrie 4.0 und unterstützen Sie gerne auch bei Ihrem IoT-Projekt. … mehr 

 


 

Mit dieser Serie von Blog-Artikeln werden wir einige grundlegende Gedanken zum Themenkomplex des „Internet of Things“ – auch kurz „IoT“ genannt – für Planer und Entscheider in mittelständischen Unternehmen zusammengefasst haben.

Wir wollen damit häufig gestellte Fragen beantworten und unseren Lesern einen Einstieg geben, um erste Gedanken zum Thema IoT für das jeweilige Unternehmen zu formulieren.


„Es gibt doch jede Menge „fertiger“ IoT-Lösungen in der Cloud, an die wir ganz einfach unsere Maschinen anschließen können.“

Die Antwort hier ist ganz einfach: Damit klar ist, wem die von Ihren Maschinen und Sensoren erzeugten Daten gehören, ist eine eigene IoT Anwendung die bessere Lösung!

Alle Arten von Daten sind das Gold des 21 Jahrhunderts. Viele „öffentliche“ IoT Dienste vereinnahmen jedoch diese Daten und verkaufen die daraus gewonnenen Erkenntnisse an jedermann – möglicherweise sogar an Ihre direkte Konkurrenz.

„Aber die Vernetzung im IoT Umfeld lebt doch von der Weitergabe von Daten?“

Ja natürlich, eine IoT-Lösung ist ohne die Weitergabe von Daten in der Regel nur von sehr beschränktem Nutzen. Unabhängig davon ist es aber unverzichtbar, dass Sie es selbst kontrollieren können, wer Zugriff auf Ihre Daten erhält und wer nicht, wer die Daten auswerten und daraus lernen kann und wer nicht!

Diese strategisch relevante Kontrolle über Ihre Daten können Sie nur dann sicherstellen, wenn Sie an den Schlüsselstellen in der IoT-Datenschöpfungskette eigene IoT-Anwendungen / -Lösungen/ -Apps implementieren, die zu 100% unter Ihrer Kontrolle stehen.

Nur wenn Sie wissen, an welchen Stellen welche Daten entstehen, was man daraus an Erkenntnisse gewinnen kann ist können Sie „verstehen“ was Ihre Kunden an Daten brauchen. Das wiederum ermöglich es Ihnen, Ihr Produkt mit mehr Kundennutzen zu versehen – und am Ende möglicherweise auch neue Geschäftsmodelle für Ihr Unternehmen zu entwickeln.


Warum wir als Basis für Ihre eigene IoT-Anwendung Amazon Web Services (AWS) Cloud empfehlen, erfahren  Sie hier


Der schnelle Einsatz einer bestehenden IoT-Plattform statt des Aufwands einer eigenen IoT Anwendung ist natürlich sehr verlockend. Für nur ganz wenig Geld können Sie Ihre „intelligenten Maschinen“ auf diese Art und Weise ins Internet bringen. Und für einen ersten Showcase kann dies unter Umständen auch ein sinnvoller Weg sein. Wer aber strategisch und längerfristig denkt, der sollte hier sorgfältig prüfen, welche Konsequenzen solch eine Entscheidung haben kann.

Wenn Sie lernen möchten, mit welchen Methodiken man die für die eigene IoT Anwendung strategisch relevanten Schlüsselkomponenten identifiziert, um die Kontrolle über seine Daten zu behalten, erfahren Sie in Folge 1 unserer Webinar-Reihe „IoT Projekt-Know-how für Planer und Entscheider“ mit dem Titel „Die Cloud als notwendige Basis für IoT-Lösungen – das AWS-Praxisbeispiel „tempmate“.  Infos & Anmeldung


Weitere Teile dieser Blog-Artikel Serie:

IoT Projekt-Know-how für Entscheider – Teil 1: Warum müssen wir in die Cloud?

IoT Projekt-Know-how für Entscheider – Teil 2: Warum sollen wir jetzt IoT Projekte starten?


Übrigens: Als integrativer Entwicklungsdienstleister für AWS (Amazon Web Services) Cloud-Lösungen bieten wir Ihnen ein fundiertes Know-How in den Themenfeldern Internet of Things (IoT), Smart Products und Industrie 4.0 und unterstützen Sie gerne auch bei Ihrem IoT-Projekt. … mehr 

 


 

 

 

 

 

Mit dieser Serie von Blog-Artikeln werden wir einige grundlegende Gedanken zum Themenkomplex des „Internet of Things“ – auch kurz „IoT“ genannt – für Planer und Entscheider in mittelständischen Unternehmen zusammengefasst haben.

Wir wollen damit häufig gestellte Fragen beantworten und unseren Lesern einen Einstieg geben, um erste Gedanken zum Thema IoT für das jeweilige Unternehmen zu formulieren.


„Unsere Kunden haben doch gar keinen Bedarf für IoT!“

Hier wollen wir Ihnen kurz erläutern, warum Sie gerade deshalb jetzt Ihre ersten Schritte im Bereich des Internet of Things gehen und ihre eigenen IoT-Projekte starten müssen.

Wie wir in vielen Projekten erleben konnten, resultiert der fehlende „Bedarf“ auf Kundenseite aus einem Mangel an Vorstellungskraft, welchen neuen Nutzen eine IoT-fähige Maschine oder ein „Smarter Sensor“ bieten können.

„Na dann haben wir ja noch Zeit und können erst mal abwarten bis unsere Kunden soweit sind“

Dieses Denken kann sehr teuer werden, insbesondere dann, wenn Sie typischerweise Maschinen und Anlagen auf Kundenwunsch hin bauen.

Sobald nämlich Ihre Kunden selbst anfangen, die Chancen des Internet of Things zu erkennen und Anforderungen für eine IoT-Lösung selbst formulieren, hat Ihr Unternehmen die Innovationsführerschaft verloren.

Denn in der Regel wird Ihr Kunde nicht nur mit Ihrem Unternehmen sprechen, sondern auch mit Ihren Wettbewerbern, möglicherweise auch mit ganz neuen potentiellen Lieferanten und dabei eigene IoT Projekte starten.


Wenn wir bei SIC! Software Smart Products, Industrie 4.0- und IoT-Projekte starten, setzen wir primär Amazon Web Services (AWS) Cloud ein. Warum, das erfahren Sie hier


Und schneller als Ihnen lieb ist, befinden Sie sich mit Ihrem Angebot in einem Preiskampf. Die Innovationen werden nicht mehr von Ihnen getrieben sondern von Ihrem Kunden – Sie sind nicht mehr ein Partner auf Augenhöhe sondern nur noch ein Erfüllungsgehilfe.

„Wie sollen wir mit unseren Kunden ins Gespräch kommen, wenn diese den Nutzen nicht erkennen?“

Um diese Engpass zu lösen, empfehlen wir in einem ersten Schritt die Umsetzung eines Show-Case (auch Demonstrator genannt). Damit können Sie den Kunden Ihre grundsätzliche IoT Lösung und die daraus resultierenden Chancen anschaulich zeigen. Aber nicht nur das. Weil der Kunde ein konkretes Szenario vor sich liegen hat, können Sie auch die Wünsche und Bedürfnisse des Kunden mit einer ganz anderen Qualität diskutieren.

Im Ergebnis erhalten Sie in vielen Fällen eine völlig andere Sicht der Dinge. Es werden neue Chancen sichtbar, die zuvor niemand erkennen konnte. So wird der Weg geebnet, dass Sie mit IoT Ihren Produkten einen einzigartigen Nutzen geben und Sie auch in Zukunft als innovativer Partner auf Augenhöhe wahrgenommen werden.

Wie Sie IoT-Projekte starten, indem Sie an die Planung und Konzeption eines kundenorientierten IoT-Showcase herangehen und wie Sie die strategisch relevanten Themen identifizieren, erfahren Sie in Folge 1 unserer Webinar-Reihe „IoT Projekt-Know-how für Planer und Entscheider“ mit dem Titel „Die Cloud als notwendige Basis für IoT-Lösungen – das AWS-Praxisbeispiel „tempmate“.  Infos & Anmeldung


Weitere Teile dieser Blog-Artikel Serie:

IoT Projekt-Know-how für Entscheider – Teil 1: Warum müssen wir in die Cloud?


Übrigens: Als integrativer Entwicklungsdienstleister für AWS (Amazon Web Services) Cloud-Lösungen bieten wir Ihnen ein fundiertes Know-How in den Themenfeldern Internet of Things (IoT), Smart Products und Industrie 4.0 und helfen Ihnen gerne auch dabei Ihre IoT-Projekte zu starten. … mehr