IOT USE CASE PODCAST

Podcastfolge

Share on linkedin
Share on facebook
Share on whatsapp
Share on email
Share on xing
Zurück zur Folgenübersicht

FOLGENTITEL

Service-Strategie setzt neue Maßstäbe für die Kundenkommunikation

„Wir als Komponentenlieferant sind in der Vergangenheit eher mit klassischer Softwareentwicklung und Anwenderentwicklung konfrontiert gewesen – weniger mit Cloud Computing. Da ist es immer gut, wenn man sich externe Kompetenzen ins Unternehmen holt und mit denen das Projekt initial aufsetzt.“ – Maximilian Stadlbauer, Frauscher Sensortechnik

 

In dieser Podcastfolge sind der IoT-Anbieter All for One bzw. die Tochterfirma CDE Engineering und der IoT-Anwender Frauscher Sensortechnik zu Gast. Der Podcast dreht sich um die Optimierung der Leistungsfähigkeit und Ausfallsicherheit von Bahnstrecken mithilfe eines IoT-Diagnosesystems, das Sensordaten sammelt, analysiert und auswertbar bereitstellt.

 

Folge 57 auf einen Blick (und Klick):

 

[09:49] Herausforderungen, Potenziale und Status quo – So sieht der Use Case in der Praxis aus 

[15:06] Lösungen, Angebote und Services – Ein Blick auf die eingesetzten Technologien 

[26:59] Ergebnisse, Geschäftsmodelle und Best Practices – So wird der Erfolg gemessen

[30:10] Übertragbarkeit, Skalierung und Nächste Schritte – So könnt ihr diesen Use Case nutzen

 

Zusammenfassung der Podcastfolge

Dass uns der Zug, in den wir einsteigen, sicher ans Ziel bringt, ist für uns selbstverständlich. Doch hinter dieser scheinbaren Selbstverständlichkeit steckt komplexe Technik – wie die Signalkomponenten von Frauscher Sensortechnik. Frauscher ist Spezialist auf dem Gebiet des Bahnbetriebs, und hier insbesondere für die sogenannten Achszähler und Radsensoren. 

Die All for One Group ist einer der führenden Digitalisierungspartner im deutschsprachigen Mittelstand. In dieser Podcastfolge spricht Madeleine Mickeleit mit All for One beziehungsweise der Tochter CDE Engineering über die Zusammenarbeit mit Frauscher. CDE ist Experte für smarte Produkte, SAP-nahe, MES-light-, Smart-Factory-Produkte, aber auch Predictive Maintenance. Frauscher Sensortechnik ist einer ihrer 2.500 Kunden aus dem DACH-Raum. Die beiden Partner zeigen in dieser Folge, wie Sensordaten und Komponenten von Frauscher mit der Cloud verbunden werden und sich die digitale Vernetzung intelligent und reibungslos in bestehende Geschäftsprozesse integriert. Wie genau dadurch auch Wartungsarbeiten optimiert werden, die Züge pünktlicher werden und welche Mehrwerte die All for One Group außerdem für Frauscher auf die Schiene bringt, darum geht es in Folge Nummer 57 des IoT Use Case Podcasts.

 

 

Die Podcastgäste:

 

Podcast Interview

Andreas, magst du dich ganz kurz vorstellen und was ihr bei All for One genau macht? Beziehungsweise du bist ja bei der Tochterfirma CDE. 

Andreas

Ich bin Andreas Lehner. Ich bin in der All-for-One-Tochter CDE für den Bereich Web App und Data Science verantwortlich. Wir entwickeln Software- und IoT-Lösungen, um die Produkte unserer Kunden verbessern zu können. Das sind im Normalfall alles Individual-Entwicklungen. Wir begleiten den Kunden von der Idee, über die Umsetzung bis zum Betrieb ihrer Lösung. Da ist bei uns besonders wichtig, da geht es um den gesamtheitlichen Ansatz. Das bedeutet, von der Sensoranbindung, über die Edge bis hin zur Schnittstelle zur Connectivity in die Cloud oder andere Server, inklusive dem User Interface oder der entsprechenden Applikation.

 
Wer sind hier klassischerweise eure Kunden und Partner?
Andreas
Unsere Kunden sind im Normalfall mittelständische Kunden aus dem Industrieumfeld. Sie sind meistens Produkthersteller – Beispiele dafür sind STABILO, ekey, Plasser & Theurer –, aber auch im Medizinprodukteumfeld tätig, wo entsprechend hohe Qualität gefordert ist.
 
Maximilian, magst du dich auch kurz vorstellen?
Maximilian
Mein Name ist Maximilian Stadlbauer. Ich bin seit fünf Jahren bei Frauscher und für den Bereich Softwareprodukte mit Schwerpunkt Diagnose zuständig. Frauscher ist jetzt seit über 30 Jahren im Achszählgeschäft, so ungefähr 600 Mitarbeiter, ein mittelständisches Unternehmen in Oberösterreich an der Grenze zu Bayern. Wir sind Komponentenlieferant für die Bahnindustrie, für den sicheren Bahnbetrieb.
 
Achszählgeschäft – Achszähler: Wo kommen die genau zum Einsatz? Direkt an der Schiene?
Maximilian
Ganz genau. Ein Achszähler ist im Prinzip ein Sensor, der die Überfahrt eines Zuges, oder eines Rades, erkennt. Die werden auf den Gleisen montiert. Es ist ja nicht so wie bei der klassischen Autofahrt, man fährt auf Sicht und sieht alles vor sich. Sondern ein Lokführer muss sich auf die Signaltechnik verlassen können, das heißt auf Ampelsignale et cetera, ob er in diesen nächsten Streckenabschnitt einfahren darf. Diese Gleise sind in sogenannte Freimeldeabschnitte, oder Streckenabschnitte, unterteilt. Die Grenzen dieser Abschnitte werden durch unsere Radsensoren überwacht, das heißt, dadurch ergibt sich dann eine sogenannte Freimeldung. Das heißt, der Betreiber beziehungsweise Lokführer weiß dann, in diesem Abschnitt befindet sich kein Zug und der nächste Zug darf in diesen Abschnitt einfahren und kann die nächste Passage durchfahren.
 
Jetzt geht es darum, eure Sensorik beziehungsweise das Gleis und hier Daten zu nutzen. Was ist hier eure Vision in diese Richtung? Was bewegt den Schienenverkehr beziehungsweise die Industrie, in der ihr seid?
Maximilian
Großes Thema, ganz genau. Industrie 4.0, oder IoT, ist ja sowieso in aller Munde. Wir haben uns ebenfalls Gedanken dazu gemacht, wie können wir unseren Betreibern beziehungsweise unsere Kunden dabei unterstützen? Die Systeme werden kontinuierlich komplexer, das heißt, man braucht sehr viel Know-how, um ein System zu warten und zu verstehen, was das System macht et cetera. Da haben wir gesagt, da könnten wir einhaken – wer versteht das Produkt besser als wir? Wie können wir dem Kunden Transparenz schaffen, das System transparenter machen? Da geht es in diese Richtung, die Diagnose, speziell bei der Wartung den Kunden zu unterstützen. Ihm zu helfen, Probleme früher festzustellen.
 
Man muss sich vorstellen, der Bahnbetreiber will erstens einen sicheren Verkehr auf den Gleisen und auch eine hohe Verfügbarkeit. Das heißt, die Wartungsintervalle werden immer kürzer; die Wartungsfenster werden immer kürzer. Das heißt, er muss versuchen, schneller seine Tasks durchzubringen – meistens in Nachtschichten et cetera. Dahingehend können wir mit entsprechender Diagnose, oder ein bisschen in Richtung Predictive Maintenance, den Kunden unterstützen, seine Punkte, seine To-Do’s auszuarbeiten, BEVOR Probleme entstehen. Bis jetzt ist das eher klassisch mit Wartungsintervallen und manueller Arbeit. Hier könnten wir mit IoT, oder IIoT in diesem Fall, den Kunden unterstützen.
 
Im Endeffekt geht es auch um die Verspätungen, die wir alle kennen, und auch um das Thema Sicherheit. Man muss sicherstellen, dass keiner auf dem Gleis ist. Und diese Verfügbarkeit – dass man diese Zeitfenster so gering wie möglich hält, um Verspätungen im besten Fall aus dem Weg zu räumen, oder?
Maximilian
Genau. Hohe Durchsatzraten zu erzielen. Speziell im städtischen Bereich, wenn man an die Rushhour denkt, U-Bahnen et cetera, da wollen sehr viele Leute in einem kleinen Zeitfenster schnell von A nach B kommen. Speziell in diesen Bereichen ist es erforderlich, dass dann keine Störung auftritt oder der Bahnbetrieb gestört ist. Sicherheit steht natürlich ganz groß im Vordergrund: Es will jeder gut am Ziel ankommen.
 
Um das Ganze ein bisschen abzugrenzen – wer sind eure Kunden, das heißt, neben der Bahn auch die U-Bahnen?
Maximilian
Wir haben zwei Arten von Kunden. Das eine sind die Bahnbetreiber, wie zum Beispiel in der Industrie, Bergbau et cetera. Die haben auch entsprechende Gleise. Da ist dieser Sicherheitsaspekt nicht GANZ so im Vordergrund. Natürlich AUCH, aber nicht ganz so wie in einem städtischen Betreib, wo ich einen U-Bahn-Betrieb habe. Und die andere Klientel sind die sogenannten Integratoren, wie zum Beispiel Siemens – es gibt da mehrere große Player –, die für Bahnbetreiber die Signaltechnik installieren, also im Prinzip ein Projekt ausarbeiten. Da sind wir eine kleine, aber nicht sehr unwesentliche Komponente, um diese Signaltechnik sicherzustellen und den Bahnbetrieb zu gewährleisten.
 

Herausforderungen, Potenziale und Status quo – So sieht der Use Case in der Praxis aus [09:49]

Wenn ich mir einen Wartungstechniker vorstelle und auch den täglichen Job: Wie sieht es vor Ort aus und was hat der so für Aufgaben? Ist das klassisch, dass er sich die Signaltechnik anschaut und die Wartungen manuell durchführt?

Maximilian

Schwierige Frage. Die Betreiber haben ja sehr viele Komponenten; wir sind nur eine davon. Da geht es auch um Lichtsignale, Weichen et cetera. Die Bahnbetrieb-Oberleitungen, Stromversorgung. Es gibt sehr, sehr viele Komponenten, die der Bahnbetreiber begutachten und instand halten muss. Wir haben hier auch unsere Vorgaben, wie unsere Komponenten zu warten sind. Da geht es um monatliche oder jährliche Inspektionen, da kommt es ein bisschen drauf an.

 

Unsere Kunden takten diese Wartungen in ihren Wartungsintervallen ein, und dann wird in den Wartungsfenstern der Radsensor begutachtet. Auch auf irgendwelche Defekte, mechanische Defekte; ob der Radsensor noch montiert ist. Wir sind ja in einer relativ rauen Umgebung. Wir sind weltweit aufgestellt, das heißt, wir haben sehr heiße wie auch sehr kalte Temperaturen. Feuchte ist ein Thema, Überschwemmungen. Oder auch Vibrationen. Speziell auf dem Gleis, man kennt das: Wenn ein Zug irgendwo vorbeifährt, hört man hin und wieder so ein Rattern, je nach Wartung der Gleisanlagen. Das wirkt sich natürlich auch auf unsere Sensoren aus. Dementsprechend muss der Sensor gelegentlich gewartet werden, und das wird in diesen Wartungsfenstern gemacht.

 
Das heißt, ich habe irgendwo Störungen, die an so einem Gleisabschnitt auftreten, vielleicht auch durch externe Faktoren. Es kommen Zeiten zustande – du hast gesagt, der Techniker muss das in bestimmten Wartungszyklen machen, hat wenig Zeit. Wie werden denn diese Wartungsarbeiten heute gemacht? Meldet dieser Sensor das schon selber? Wie funktioniert das heute, also ohne die digitale Lösung, die ihr zusammen aufgebaut habt; das heißt, das klassische Wartungsgeschäft in der Praxis.
Maximilian
Derzeit sieht die Wartung so aus: Es gibt ja schon vor Ort ein historisches Diagnosesystem, das Daten aufzeichnet. Wo man die Daten abrufen kann, um zu sehen, was ist – zum Beispiel bei einer Störung oder einem Fehlverhalten – passiert? Was war der ausschlaggebende Grund, wie es zu dieser Störung gekommen ist? Da kann man nachvollziehen, was passiert ist. Dafür braucht man natürlich trotzdem entsprechendes Fachwissen. Es ist ein sehr Achszähler-spezifisches Thema. Dazu muss man sich auch etwas mit der Materie beschäftigen.
 
Das wäre dann der Punkt, bei dem wir einhaken möchten. Dass wir hier den Kunden unterstützen, dass er dieses ganze Expertenwissen nicht mehr im Detail braucht, sondern wir ihm hier unter die Arme greifen können mit einem System und ihm die entsprechenden Schritte, die zu tun sind, etwas besser darstellen können.
 
Das heißt, man muss sich das so vorstellen, dass euer Sensor bei einem bestimmten Schwellwert – sei es eine Vibration oder welcher Auslöser auch immer – in einem Diagnosesystem diese Daten meldet. Und der nächste Schritt ist dann, diese Daten noch weiter zur Verfügung zu stellen, und das Ganze auch verstärkt proaktiv?
Maximilian
Proaktiv, genau. Man muss sich das so vorstellen: es gibt zwei Stufen. Das eine ist eine sogenannte Warnung, das heißt, der Sensor hat ein Problem, es ist aber noch nicht der Betrieb gefährdet. Das andere ist die Störung, das ist sozusagen der Worst Case für den Betreiber, denn das heißt, es muss jemand sofort raus und irgendwie diese Störung beheben. Der Bahnbetrieb ist dadurch eingeschränkt, weil er den Abschnitt dann nicht zur Gänze nutzen kann. Das führt dann im Prinzip dazu, dass man sich die Diagnosedaten anschauen muss, sich mit dem Thema beschäftigen muss – und das Ganze dann meistens auch schon unter Zeitdruck. Man will ja schnell wieder in den Regelbetrieb kommen, und wir sind auch im Sicheren Bereich. Sicherheit heißt teilweise, man muss sogenannte Freifahrten machen, das heißt, es muss ein Zug mit verminderter Geschwindigkeit durchfahren et cetera. Da hat jeder Betreiber seine eigenen Regelwerke, wie er seinen Bahnbetrieb sicher gestaltet. Das ist natürlich mit erheblichem Aufwand verbunden.
 
Sinn wäre es jetzt, diese Warnungen, die der Kunde aktuell manuell prüfen oder suchen muss, aktiv zu prüfen und mit proaktiven Meldungen et cetera dem Kunden transparent zu machen, mitzuteilen, damit er das Thema oder die Störung oder Warnung kennt und das entsprechend in den Wartungsfenstern eintakten kann.
 

Lösungen, Angebote und Services – Ein Blick auf die eingesetzten Technologien [15:06]

Wenn ich richtig verstehe, das ist genau das Projekt, wo ihr sagt, bislang waren es die Warnungen, die im Diagnosesystem aufgekommen sind – und der nächste Schritt ist, dieses Thema mit All for One proaktiv anzugehen und das ins Next Level zu heben. Wie arbeitet ihr hier genau zusammen? Wer macht was in dieser Lösung?

Maximilian

Bei dieser Lösung haben wir eine gemeinsame Schnittstelle, also ein Protokoll, wo wir die Daten von unserem Bestandsdiagnosesystem an ein übergeordnetes System weiterleiten. Das derzeitige Diagnosesystem ist dezentral und über mehrere Abschnitte verteilt. Alle diese Komponenten sollen in ein zentrales System, über diese Schnittstelle in das übergeordnete System die Daten liefern und dort zur Auswertung bringen.

 
Das heißt, man hat euren Sensor, dann dieses zwischengeschaltete System und dann diesen übergeordneten Layer. Andreas, ich würde das gern genauer verstehen. Wie kommt dieses Manuelle – also diese Prozesse, die wir proaktiv angehen wollen – genau ins Digitale?
Andreas
Wie Max bereits gesagt hat, ist das Diagnosesystem, wie es jetzt existiert, ein dezentrales System. Das bedeutet, man braucht für ein entsprechend großes Projekt im Bahnbereich auch mehrere solcher Diagnosegeräte. Das Ziel der Softwarelösung, die wir entwickelt haben, bringt genau diese Informationen von all den verschiedenen Diagnosegeräten auf EIN übergeordnetes Diagnosegerät. Das heißt, ab diesem Moment kann das gesamte Projekt von einem System aus überwacht werden. Das ist mal die Basis für unsere Entwicklung, wo wir dann diese Daten, die übermittelt werden, im Verbund analysieren und auswerten können, um dem Kunden auch gezielt Informationen bereitzustellen.
 
Noch eine Stufe tiefer in die Architektur, wie muss ich mir das vorstellen? Ich habe verschiedene Diagnosesystem, die einzeln irgendwo da draußen bei Kunden laufen – bei U-Bahn-Betreibern, anderen Bahnbetreibern. Die sollen alle zentral in ein übergeordnetes System gehoben werden, um das Thema proaktiv anzugehen? Kannst du uns ein bisschen abholen, wie die Architektur dazu aussieht?
Andreas
Wir haben uns zu Beginn des Projektes Gedanken gemacht, wie die Architektur im Detail aussehen soll und haben uns relativ schnell dazu entschieden, dass wir in diesem Fall eine Microservice-Architektur instanziieren wollen. Das bedeutet, man entwickelt verschiedene Services, die alle eine bestimmte Aufgabe in diesem System erledigen. Da geht es zum einen damit los, dass man einen Service hat, bei dem man diese Daten von den Diagnosegeräten abgreifen kann. Das bedeutet, diese Schnittstelle ist eine Netzwerkschnittstelle und da gibt es ein bestimmtes Protokoll. Wir haben einen Service, das dieses Protokoll versteht und dieses abarbeiten und so die Diagnosedaten in den Geräten abholen kann.
 
Da das Projekt schon von Anfang an so aufgesetzt wurde, dass man damit vielleicht später auch mal in die Cloud gehen kann – aktuell läuft das auf einem Server lokal bei den Kunden –, haben wir uns deshalb für diese Microservice-Architektur entschieden, sodass wir in Zukunft mehrere solcher Services parallel instanziieren kann, um so theoretisch auch weltweit von diesen Diagnosegeräten die Daten abgreifen zu können.
 
Von diesem Punkt aus haben wir eine Datenbank, in der wir diese Daten abspeichern. Im Detail verwenden wir im Hintergrund auch noch Caching-Datenbanken, um den Druck auf die eigentliche Datenbank zu verringern. Das heißt, das ist ein mehrstufiges System, wo wir die Daten in unsere Hauptdatenbank bringen können. Von dort werden die Daten mit einem eigenen Datenanalyse-Service analysiert. Hier geht es um diese proaktiven Informationen, die wir den Kunden bieten. Das bedeutet, welche Warnungen, welche Fehler sind im System? Welche Wartungsarbeiten stehen auch an? Alles, was wir in dem Kontext hier schon gehört haben.
 
Wir bereiten dann diese Informationen über eine API entsprechend auf und haben zusätzlich auch noch ein Frontend entwickelt, ein Web-basiertes User Interface, wo man sich diese Informationen anschauen kann. Dazu gehört dann Benutzerverwaltung, Einstellungen; bestimmte Seiten, wo man spezielle Aspekte zum System, wie etwa dessen Gesundheitszustand, sich anschauen kann.
 
Maximilian, kannst du das noch ein bisschen aus der Praxis erklären? Andreas sagt, man hat eine API, verschiedene Datenbanken. Welche Daten, Sensordaten kommen denn da an? Und was ist der Output? Habt ihr ein Dashboard, wo man sich einloggen kann, was für eure Kunden da ist?
Maximilian
Es gibt verschiedenste Daten. Vom gesamten Achszählsystem generell, da gibt es Redundanzinformationen et cetera. Ein wichtiger Wert ist zum Beispiel der Radsensorstrom, der für unsere Sensoren wichtig ist, den wir damit auch monitoren können, der auch ein Indiz dafür ist, ob mal wieder eine Wartung ansteht. Oder ein Sensorabgleich. Unsere Sensoren muss man abgleichen. Nicht kalibrieren, aber einen Abgleich machen. Das wäre zum Beispiel eine Information, die wir dem Kunden zur Verfügung stellen können, mit dem Diagnose-Dashboard.
 
Es gibt dann eine Art Landing Page, wo sich der Anwender anmelden kann, um die Daten einzusehen. Diese werden graphisch aufbereitet, also man muss sich nicht mehr durch die historischen Daten durchackern, sondern man hat im Dashboard die aufbereiteten Informationen und kann über das gesamte System alle Daten abrufen.
 
Das heißt, ich muss mir das so vorstellen, ich habe ein Dashboard vor mir, da habe ich ein paar bunte Graphen und kann da zum Beispiel die Diagnose zum Radsensorstrom einsehen – da gibt es bestimmte Schwellwerte, die ihr irgendwo hinterlegt habt, und wenn die überschritten werden, wird der Output dort angezeigt. Das heißt, ich muss nicht durch die Daten durchgehen, sondern sehe im Dashboard auf einen Schlag, was war der Fehler?
Maximilian
Ganz genau.
 
Andreas, du sagtest ja, ihr kommt aus dem Bereich Web App, Data Science, ihr seid da die Experten. Aber für jemanden, der das zum ersten Mal hört, klingt das nach einem riesengroße Feld. Maximilian, was für Kenntnisse brauchtet ihr dafür? Hattet ihr das alles schon? Du kommst ja aus dem Bereich, aber was braucht man, um mit so einem Thema zu starten?
Maximilian
Speziell für diese Microservices, oder die Vorbereitung für Cloud oder Verschiebung der Anwendung in die Cloud, braucht man natürlich entsprechende Kenntnisse. Die hatten wir inhouse zu dem Zeitpunkt nicht. Das war auch der Grund, warum wir uns dann umgeschaut haben und auf CDE gestoßen sind. Da hat dann eigentlich die Partnerschaft angefangen.
 
Wie habt ihr da zusammengearbeitet? Vielleicht auch mal rückblickend; ihr seid ja jetzt schon länger in dem Projekt.
Andreas
Genau. Das Projekt hat so begonnen, dass wir einen gemeinsamen Workshop in dem Zusammenhang gemacht haben, um das System auch einmal zu verstehen. Das war in diesem Fall ein dreitägiger Workshop, wo wir teilweise auch wirklich die Spezialitäten der Achszählsysteme kennengelernt haben. Also wirklich auch, wie funktionieren die Achszähler technisch? Damit wir ein entsprechendes System aufsetzen können und das Hintergrundverständnis dafür haben.
 
Anhand dessen haben wir einen SCRUM-basierten Ansatz gewählt, den Backlog in diesem Workshop gefüllt und die ersten Aufgaben beschrieben, wo wir unser erstes Ziel definiert haben. Das Minimum Viable Product. Wo wir gesagt haben, damit können wir quasi zu unserem ersten Kunden gehen. Das haben wir dann einmal zum Laufen gebracht. Diese Schnittstelle implementieren, dass wir überhaupt mal Daten zur Verfügung haben, und diese dann zumindest mal in einer Liste anzeigen zu lassen. Einfach mal zu beginnen, komplett ohne Dashboard. Um zu schauen, dass dieses übergeordnete Diagnosesystem entsprechend funktionsfähig ist.
 
Also den Kunden überhaupt erst mal fragen, brauchst du das so oder anders? So ein bisschen mit ihm ins Gespräch zu kommen, wie das genau aussehen soll, nicht?
Andreas
Genau, und auch in dem Zusammenhang die User Storys definiert, um aus den User-Sichten zu definieren, was braucht der User für seine Arbeiten? Wie kann er dieses System richtig nutzen? Natürlich mit ganz starker Unterstützung von Frauscher, die natürlich wissen, wer ihre User in dem System überhaupt sind.
 
Klar, das ist dann zum Beispiel so ein Wartungstechniker; der hat einen Login und sieht dann nur die Themen, die für ihn relevant sind, oder?
Andreas
Richtig, genau, zum Beispiel.
 
Maximilian, zur Praxis. Viele da draußen arbeiten vielleicht an ähnlichen Projekten. Zusammenfassend, was für Komponenten habt ihr von All for One gebraucht? Kannst du da sagen, ich brauche eins, zwei, drei … kann man das so einfach zusammenfassen?
Maximilian
In diesem konkreten Fall haben wir die Software-Dienstleistung gebraucht. Also das Know-how, wie man Cloud Computing, oder eine Applikation, die Cloud-ready sein soll, erstellt. Wie man die Architektur aufsetzt. Welche Themen es zu berücksichtigen gibt – sei es jetzt Bandbreiten et cetera. Da braucht man auf alle Fälle Know-how, und da ist es nicht schlecht, wenn man jemanden hat, der sich damit gut auskennt und einen da unterstützen kann. Denn wir als Komponentenlieferant sind eher Klassische Softwareentwicklung und Anwenderentwicklung, und wenig mit Cloud Computing konfrontiert gewesen in der Vergangenheit. Da ist es immer gut, wenn man sich externe Kompetenzen ins Unternehmen holt und mit denen das Projekt initial aufsetzt – was nun bei uns auch so der Fall war.
 
Andreas hat auch schon angeführt, dahinter stecken verschiedenste Datenbankstrukturen, wo ihr eure Kompetenzen zusammengebracht habt. Dann braucht es wahrscheinlich nur noch einen PC vom Kunden, wo das Ganze läuft – beziehungsweise das ist ja jetzt nicht in der Public Cloud sondern gehostet von den Kunden –, und eure Komponenten natürlich, die dort zum Einsatz kommen, wo die Daten überhaupt generiert werden. Das ist so zusammengefasst; könnte man das so sagen?
Andreas
Genau.

Ergebnisse, Geschäftsmodelle und Best Practices – So wird der Erfolg gemessen [26:59]

Best Practices – viele fragen mich immer, »Madeleine, können deine Partner so ein paar Best Practices und Fallstricke aus der Praxis mitgeben?« Und das andere ist, am Ende geht es ja auch wirklich um einen Business Case. Also ihr seitens Frauscher geht ja auch einen Weg, wo ihr sagt, bislang waren die Komponenten irgendwo verbaut … jetzt bringen wir neue Intelligenz rein – ihr seid der Hersteller und kennt eure Komponenten natürlich und könnte diese Daten nutzbar machen, auch für andere. Das ist ja auch irgendwo ein neues Geschäftsmodell vielleicht, oder auch ein Business Case, den ihr aufgesetzt habt. Maximilian, wie sieht der Business Case für euch aus? Wo wollt ihr damit vielleicht noch hin?

Maximilian

Zum einen ist ein Thema, dass wir wieder zu unserem Kunden den Kontakt herstellen können. Es ist ja auch so: Wenn man Komponentenlieferant ist, liefert man die Komponenten, und »das war’s« letztendlich. Man unterstützt vielleicht während der Projektphase oder im Lifecycle Management mit Support, wo man kann. Und mit diesem System wäre der Wunsch, dass man näher zusammenarbeitet und wieder näher beim Kunden ist. Auch die Bedürfnisse des Kunden besser gewinnen und ihn in seiner täglichen Arbeit unterstützen kann. Das wäre theoretisch eine Basis für ein neues Geschäftsmodell, ja.

 

Wo die Reise tatsächlich hingeht, muss man sich noch anschauen. Wie eingangs schon besprochen, die Systeme laufen ja jetzt beim Betreiber – also sie sind noch nicht in der Cloud. Das wäre der nächste denkbare Schritt. Allerdings muss man hier sehr vorsichtig sein. Wir leben ja in einer Zeit, wo Cybersecurity eine riesige Rolle spielt. Gerade bei Bahnbetreibern, wo es um Personenverkehr, Güterverkehr und Verfügbarkeitsthemen geht, ist Cybersecurity ein ganz großes Thema; dem müssen wir uns auf alle Fälle widmen und Maßnahmen treffen kann, damit nichts passieren kann, was irgendwie den Bahnbetrieb gefährdet. Da sind wir in Vorbereitung.

 
Ja, klar, Security, Riesenthema. Und das andere ist natürlich, die Geschäftspotenziale kommen dann auch noch in der Zukunft. Wenn man anschaut, das Thema Lichtsignale, Oberleitungen, das sind dann Externe – auch noch ANDERE Player, die mit reinspielen. Wenn man das ins nächste Level hebt, zu sagen, man geht vielleicht auch in Richtung Cloud, dann kann man in Zukunft – Schlagwort Smart City – verschiedenste Gewerke zusammenbringen und auch noch ganz andere Potenziale heben. Dadurch dass die Gewerke miteinander sprechen. Das ist wahrscheinlich auch noch etwas, was vielleicht Chance des Ganzen ist?
Maximilian
Da gibt es mit Sicherheit sehr viele Bereiche, wo man das Ganze noch forcieren kann, ja. Ganz spannendes Thema, auf alle Fälle. Gerade die Vernetzung verschiedenster Komponenten; Anreicherung mit anderen Daten et cetera. Da gäbe es noch sehr viele Anwendungsgebiete

Übertragbarkeit, Skalierung und Nächste Schritte – So könnt ihr diesen Use Case nutzen [30:10]

Andreas, ihr habt ja verschiedenste Kunden, mit denen ihr arbeitet. Siehst du auch ähnliche Use Cases, Projekte auch bei anderen, die vielleicht auch schon so weit in die Zukunft denken?

Andreas

Ich muss sagen, dass IoT-Projekte meist unterschiedlich sind. Wir haben aber schon Erfahrung und Wissen, wie man solche Projekte in verschiedenen Bereichen umsetzen kann. Grundsätzlich ist es so, dass dieses Handwerkszeug, das man für solche Umsetzungen benötigt, immer ähnlich aussieht. Wir wollen mit diesen Kunden-Workshops, die wir in dem Bereich haben, den Kunden zeigen, was ist alles möglich, also was gibt es? Und wie kann das beim Kunden konkret aussehen? Also es sind sehr individualisierte Lösungen, aber es gibt eine gemeinsame Basis, von der man ausgehen kann und von der man das auf jeden beliebigen anderen Use Case im IoT-Bereich ummünzen kann.

 
Wie geht die Zusammenarbeit mit Frauscher weiter? Was habt ihr noch geplant?
Andreas
Das Projekt an sich, für das Higher-Ranking-Diagnosesystem haben wir inzwischen erfolgreich abgeschlossen. Da haben wir den Kunden nun enablen können, dass er selber bei dieser Lösung weitermacht. Das heißt, in diesem Bereich passiert jetzt unmittelbar kein weiteres Projekt mehr. Allerdings besteht nach wie vor Zusammenarbeit im Bereich Smart Factory und auch S/4HANA, SAP-Einführung.
 
Das ist ja im Endeffekt genau das Ziel: Ihr enablet den Kunden. Maximilian, ihr habt ja die Kompetenzen mit der Zeit weiter ausgebaut. Das ist ja auch ein Prozess, den man durchläuft und bis zu einem gewissen Punkt gemeinsam geht, und schließlich selber ausbaut mit weiteren Kompetenzen, die ihr inhouse habt.
 
Wenn ich Kontakt zu euch aufnehmen will, das heißt alles, was spezifische Komponenten angeht – wie ist der nächste Schritt mit euch? Kann man da einfach mal anrufen und nachfragen?
Maximilian
Gibt es viele Möglichkeiten. Wir sind auf Social-Media-Plattformen. Wir haben eine Web Page, wo man Kontakt aufnehmen kann. Sind auch auf Messen vertreten. Es gibt verschiedene Kanäle, wie man mit uns Kontakt aufnehmen kann. Also, es sind keine Grenzen gesetzt, und wir freuen uns über jede Anfrage.
 
Kann man sich einfach mal so einen Radsensor oder auch eure Komponenten mal im Detail anschauen?
Maximilian
Genau. Da würde ich empfehlen, mal auf einen Messestand zu gehen. Es gibt eigens spezielle Bahnmessen, wo wir immer vertreten sind. Es gibt natürlich auch Onlinevorführungen. Wir machen mittlerweile auch Onlinetrainings. Coronabedingt bieten wir Trainings an. Oder auch in den Telefonaten mit dem Kunden, dass man mal so ein System zeigt, von Trainingscenter heraus, mit Webcams et cetera. Also da finden sich IMMER irgendwelche Möglichkeiten, das System dem Kunden näherzubringen und etwas transparenter zu machen. Denn Achszählung ist natürlich ein sehr eigenes Thema, sage ich jetzt mal.
 
Andreas, wenn ich auch Komponentenbauer bin oder ein ähnliches Projekt am Laufen habe. Wie erreiche ich dich beziehungsweise euch von All for One oder CDE?
Andreas
Am besten erreicht man uns eigentlich über die Web Page. Wir haben also auch eine Homepage. Wir nutzen auch Social-Media-Kanäle. Und grundsätzlich gern auch direkt per E-Mail.
 
Sehr gut. Ich würde in den Shownotes eure Kontakte bei LinkedIn hinterlegen, und die anderen auch. Dann kann man den Kontakt aufnehmen und das ein oder andere Projekt diskutieren.
Andreas
Vielleicht noch ein kleiner Rat, den man noch mit auf den Weg geben kann: Wenn man so ein IIoT-Projekt geplant hat oder es vorhat – nicht lange planen, was man mit welchen Daten machen kann. Sondern einfach mal loslegen mit einem Prototypen und Erkenntnisse gewinnen. Man wird merken, dass die Reise vielleicht ETWAS anders als geplant verläuft und man sehr viele Erkenntnisse gewinnt, die man sonst vielleicht nicht gewonnen hätte und an die man möglicherweise nicht gedacht hätte. Das kann man nur jedem empfehlen.
 
Viel lernt man wahrscheinlich auch auf dem Weg, oder?
Andreas
Keine Angst vor den Daten, sondern einfach immer rein damit und analysieren.
 
Vielen Dank!

TEILNEHMER

in dieser Folge

Andreas Lehner

Maximilian Stadlbauer

Fragen?

Für Rückfragen stehe ich Ihnen gern zur Verfügung.

Ing. Madeleine Mickeleit

Ing. Madeleine Mickeleit

Host & Geschäftsführerin
IoT Use Case Podcast