Industrial DevOps

Ein Messe-Demonstrator für eine Low-Code IoT Plattform

Laukar Tofik — Fri, 10 Sep 2021 12:02:41 +0000

Für ein Softwareprodukt zur Automatisierung und Integration von Maschinen und Systemen eignet sich ein Demonstrator, der die Funktionalitäten präsentiert. Ein solcher Demonstrator stellt eine besondere Herausforderung dar. Ich stelle deshalb hier die Ergebnisse meiner Bachelorarbeit zum Thema Aufbau und Entwicklung eines Messe-Demonstrators für eine Low-Code IoT Plattform für Systemintegration.

Der erste Kontakt

Kurz vor dem Abschluss meines Wirtschaftsinformatik-Studiums lernte ich die wobe-systems GmbH als Unternehmen bei einem Gastvortrag an meiner Universität kennen. Mein Interesse war geweckt und ich bewarb mich initiativ bei der wobe-systems GmbH, in der Hoffnung vielleicht ein Bewerbungsgespräch zu ergattern. Das bekam ich auch. Der Geschäftsführer Maik Wojcieszak stellte mir Irene, ein Mitglied des Titan Teams, vor. Irene hat mir dann von der titan Plattform erzählt. Ich erkannte das Potenzial der titan Plattform und war von der Idee begeistert. Gesagt getan, habe ich die Stelle angenommen und so begann dann mein erster Tag.

Ein Messedemonstrator für eine No-Code-Plattform

Die titan No-Code Plattform war einsatzbereit. Nun sollte das Marketing beginnen. Bestandteil des Marketings ist es, das Produkt geeignet zu demonstrieren und Interesse bei potenziellen Kunden zu wecken. Eine Kaufendscheidung für eine Software treffen interessierte Kunde nur dann, wenn das Softwareprodukt einen erkennbaren Nutzen aufweist.

Ein persönliches Beispiel: Momentan benutze ich beim Sport gerne einen Fitnesstracker mit einigen Statistiken. Damals bin ich nicht regelmäßig zum Sport gegangen. Deswegen habe ich nicht wirklich den Sinn darin gesehen, mir dieses Gerät anzuschaffen. Der Preis war mir für eine kleine Spielerei zu hoch. Die Kosten überstiegen aus meiner Sicht den potenziellen Nutzen. Als ich nun anfing, regelmäßig zum Sport zu gehen, wurden die Informationen für mich interessanter. Der Nutzen der Informationen stieg. Anschließend habe ich mir einen Fitnesstracker zugelegt, weil der Nutzen für mich nun den Kauf legitimierte.

Nun zur Leitfrage meiner Arbeit. Wie schaffe ich es, potenzielle Kund*innen für die titan Plattform zu interessieren? Diese Frage sollte meine Bachelorarbeit Aufbau und Entwicklung eines Messe-Demonstrators für eine Low-Code IoT Plattform für Systemintegration klären. Meine Aufgabe war es, einen Demonstrator für die titan Plattform für Messen und Kundenpräsentationen zu entwickeln. Kund*innen sollten so die Möglichkeiten und das Potenzial der titan Plattform erleben können.

Ich bin in meiner Arbeit wie folgt vorgegangen. Der erste Schritt war eine Wettbewerbsanalyse. Ich verglich die titan Plattform mit anderen Plattformen oder Frameworks auf dem Markt. Danach definierte ich die Zielgruppe der titan Plattform anhand von Daten, die mir die wobe-systems GmbH zur Verfügung stellte. Die Wettbewerbsanalyse hilft dabei die Eigenschaften des Produkts zu finden, die sich als besonders Einzigartig vermarkten lassen (USP). Die Zielgruppenanalyse hilft die potenziell interessanten Merkmale der titan Plattform zielgruppengerecht darzustellen. Meine Erfahrung und Beobachtung der titan Plattform als Anwender flossen darüber hinaus auch in die Betrachtungen ein und halfen die wichtigen Produktmerkmale der Plattform auszuwählen.

Die besonderen Merkmale der titan Plattform

Ich definierte zehn Produktmerkmale der titan Plattform, die interessant sein könnten für potenzielle Kund*innen.

Die zehn Produktmerkmale lauten wie folgt:

Low-Code (bzw. No-Code)
Prozesssteuerung
Wiederverwendbarkeit
Offene Schnittstellen
Datenverarbeitung
Portmatching (bzw. Portmapping)
Monitoring
Skalierung
Kollaborationsmodell
Geschäftsmodell

Low Code (bzw. NoCode)

Die titan Plattform ermöglicht Low-Code-Programmierung (LCP). Mittels LCP sollen Bricks einfacher miteinander zu Flows verknüpft werden. So können Facharbeiter Prozesse aufbauen oder verändern, ohne fundierte Programmierkenntnisse zu besitzen. Die LCP sticht heraus, da nicht alle Wettbewerber LCP angeboten habe.

Prozesssteuerung

Ein Flow kann mit wenig Aufwand durch die LCP gesteuert und geändert werden. Neue Anforderungen können mit wenig Aufwand in den Flow aufgenommen werden. Es gibt keine Grenzen beim Ausbau eines Geschäftsprozesses.

Wiederverwendbarkeit

Die Integration von IoT-Geräten und Software ist ein wichtiger Aspekt für Softwareplattformen dieser Art. Wiederverwendbarkeit bedeutet, dass Komponenten oder Prozesse für ähnlich geartete Anwendungen nicht neu entwickelt werden müssen, sondern durch Konfiguration angepasst und somit wieder verwendet werden können.

Offene Schnittstellen

Offene Schnittstellen zeigen ihren Vorteil, wenn viele verschiedene Objekte integriert werden. Objekte können dabei andere Softwaresysteme oder IoT-Geräte sein. Die titan Plattform besitzt offene und erweiterbare Schnittstellen. Es kann jedes Protokoll zur Kommunikation verwendet werden, was in Python möglich ist. Für die Zielgruppe ist die Verwendung einer Softwareplattform auch eine Entscheidung für die Zukunft, weshalb Freiheit und Flexibilität wichtig sind.

Datenverarbeitung

Verschiedene Daten können in die titan Plattform eingepflegt werden. Sie werden verarbeitet, korreliert und aufbereitet, um neue Informationen zu gewinnen. Dann können sie weitergereicht und verwendet werden.

Portmatching (bzw. Portmapping)

Das Portmatching ist ein einzigartiges Produktmerkmal innerhalb der Wettbewerber. Es verhindert die Verknüpfung von inkompatiblen Bricks. Zudem hilft es dem/der Entwickler*in dabei, immer anzunehmen, dass die Daten in einem Flow Paket konsistent sind. Dies verkürzt die Entwicklungszeit von neuen Bricks.

Portmatching war damals nur eine Kontrollfunktion bei neuen Verbindungen. Es wurde darauf geachtet, nur korrekte Verbindungen zuzulassen. Dieses Merkmal wurde mit der Zeit weiter ausgebaut und hat an Bedeutung gewonnen. Eine Verbindung ist nun konkretisierter. Weitere Informationen findest du hier.

Monitoring

Das Monitoring wird oft für Plattformen dieser Art angeboten. Auch die titan Plattform besitzt ein Monitoring-System. Es können die Geschäftsprozesse innerhalb der Unternehmung analysiert und überwacht werden.

Skalierung

Die titan Plattform bietet als einziger innerhalb der Wettbewerber Merkmale für eine Skalierung der Plattform. Ein Geschäftsprozess kann durch neuen Anforderung oder Verwendung von verschiedenen Komponenten komplexer werden. Das kann zu einer stärkeren Auslastung der Plattform führen. Die titan Plattform ist imstande durch seine Skalierungsmerkmale anspruchsvollere Prozesse auszuführen.

Kollaborationsmodell

Das Kollaborationsmodell, wie das Rollenmodell oder Industrial DevOps, sind nicht Prinzipien, die lediglich für die titan Plattform exklusiv sind. Die titan Plattform wurde in anbetracht dieser Modelle entwickelt und angepasst. Es ermöglicht eine einfache Integration der Prinzipien in die Unternehmung.

Geschäftsmodell

Das Open Source Entwicklungsmodell (OSE) ist bekannt in der Softwarebranche. Vendor-LockIn ist die Anbindung des Kunden an den Anbieter. Die Trennung vom Anbieter wird erschwert, um eine Bindung zu halten. Durch OSE sind Unternehmen frei bei der Nutzung der titan Plattform. Die wobe-systems GmbH bietet für die titan Plattform einen Software as a Service Ansatz an. Unternehmen, ohne die Möglichkeit einen Server zu warten, können die titan Plattform verwendet, indem Sie über das Internet auf ihre Instanz von der titan Plattform zugreifen.

Diese definierten Produktmerkmale halfen mir bei der Entwicklung des Demonstrators. So konnte ich mich darauf fokussieren, was über dem Demonstrator präsentiert werden soll. Die nächste Aufgabe bestand also darin, den Demonstrator zu entwickeln, der die definierten Produktmerkmale gut und deutlich darstellt.

Demonstrator

Im nächsten Schritt folgte der Aufbau des Demonstrators. Mir war es wichtig, dass der Demonstrator eine Interaktion mit Messerbesucher*innen ermöglicht. Messebesucher*innen sollten ein persönliches und positives Erlebnis mit Demonstrator haben. Dadurch steigt die Wahrscheinlichkeit, dass sie sich an die titan Plattform positiv erinnern. Der Demonstrator sollte eine Lösung in einem vertrauten Szenario der Zielgruppe abbilden, um den Nutzen durch die titan Plattform nachvollziehbar zu machen.

Zurück zum Fitnesstracker. Ich habe die Vorteile eines Fitnesstracker erst verstanden und nachvollziehen können, als ich regelmäßig zum Sport gegangen bin. Die Informationen des Trackers boten mir nützliche Informationen, deren Wert ich jedoch nicht direkt erkannte.

Die Zielgruppenanalyse ergab, dass sich die Zielgruppe im industriellen Umfeld befand. Das Szenario des Demonstrator sollte deshalb die Überwachung einer Produktionsstätte sein. Dafür werden verschiedene Daten einer Maschine im Produktionsbetrieb überwacht. Dabei handelt es sich um Temperaturdaten, Energiedaten, Produktionsdaten und Störungsdaten. Der Demonstrator imitiert dabei die Produktionsstätte und erzeugt die Daten.

Szenario

Der Demonstrator besteht sowohl aus Hardware-Komponenten als auch aus Software-Komponenten. Aus dem Szenarium und den Produktmerkmalen entwickelte ich den folgende Demonstrator.

Hardware

Demonstrator

Der Demonstrator basierte auf einer älteren Version eines Demonstrators der wobe-systems GmbH. Ein Temperatursensor (lila) maß konstant die Temperatur. Zusätzlich hat der Demonstrator noch eine LED-Lampe (grün) und einen Ventilator (blau). Angeschlossen sind die Geräte an zwei Raspberry Pis (rot), die sie steuern können.

Software

Die titan Plattform übernimmt die Verbindung von Hardware und Software. Zwei Flows dienen als Schnittstellen und übernehme die Verarbeitung der Daten. Als Beispiele entwickelte ich einen kleinen und einen großen Flow, die sich nur durch die jeweils überwachten Daten unterscheiden.

Der kleine Flow

kleiner Flow

Der kleine Flow überwachte nur die Temperaturdaten der Produktionsstätte. Diese werden durch den Temperatursensor produziert. Ab einem kritischen Punkt, der frei konfigurierbar ist durch das titan UI, schaltet sich der Ventilator und die LED-Lampe an. Es wird zudem eine SMS zur Benachrichtigung versendet.

Der große Flow

großer Flow

Der große Flow hingegen überwachte die Temperaturdaten, die Energiedaten, die Produktionsdaten und prüft auf Störungen der Produktionsstätte. Die Temperaturdaten sind live. Sie stammen direkt vom Sensor. Die übrigen Daten werden simuliert. Alle Daten werden vom Flow in einer Datenbank gesammelt und in Echtzeit in einem Dashboard dargestellt.

Die Produktmerkmale flossen in die Entwicklung des Demonstrators ein. Sie ließen sich jedoch nicht durch die alleinige Darstellung der Flows repräsentieren. Dafür habe ich eine strukturierte Präsentation des Demonstrators entwickelt. Die Präsentation beginnt mit dem kleinen Flow, der die Hauptfunktionalität der Hardware darstellt. Der kleine Flow wird während der Präsentation ausgebaut und entwickelt sich zum großen Flow. So können Messebesucher*Innen erleben wie eine Lösung vor ihren Augen entsteht.

Evaluierung meiner Arbeit

Die Evaluierung des Demonstrators konnte leider nicht live stattfinden, da COVID-19 mir einen Strich durch die Rechnung gemacht hat. Stattdessen produzierte ich verschiedene Youtube-Videos, um die Produktmerkmale mit dem Demonstrator zu präsentieren. Nach jedem Video ermittelte ich in einer Online-Umfrage die Eindrücke der Testpersonen. Ziel der Umfrage war es festzustellen, ob die gewählten Produktmerkmale ansprechend für Messebesucher*innen sein werden.

Die Eindrücke der Befragten analysierte ich anhand des KANO-Modells. Das KANO-Modell klassifiziert die Produktmerkmale in vier unterschiedlichen Kategorien, die einen unterschiedlichen Einfluss auf die Kundenzufriedenheit haben. Der Einfluss hängt davon ab, ob das Produktmerkmal fehlt oder vorhanden ist. Ich konnte die oben genannten Produktmerkmale durch die Umfrage den Kategorien des KANO-Modells zuordnen. Das Ergebnis sah folgendermaßen aus:

Die Befragten wurden nach ihrem Hintergrund aufgeteilt. Es waren Studierende der Christian-Albrechts-Universität zu Kiel, Kollegen aus der wobe-systems GmbH, assoziierte Partner des Titan Projekts oder sonstigen Personen. Die Umfrage zeigte, dass insgesamt acht der zehn Produktmerkmale als Leistungsmerkmal angesehen werden. Als Leistungsmerkmal dienen sie der titan Plattform als Identifizierungskriterium im Vergleich zum Mitbewerb. Die Präsentation des Geschäftsmodells wurde bei den befragten Personen indifferent aufgenommen. Es schaffte keine Kundenzufriedenheit. Die Prozesssteuerung wurde als Basis-Merkmal klassifiziert. Sie schaffen keine Kundenzufriedenheit, sollte aber nicht fehlen, da sie sonst starke Kundenunzufriedenheit verursachte. Bemerkenswert war noch, dass die assoziierten Partner das Kollaborationsmodell als Begeisterungsmerkmal wahrnahmen. Es schaffte eine starke Kundenzufriedenheit.

Ich rechnete den Kundenzufriedenheit Koeffizienten auch aus den Ergebnissen der Befragung heraus. Der Koeffizient zeigt, wie sehr das Vorhandensein oder nicht Vorhandensein eines Produktmerkmals der titan Plattform die Befragten zufrieden oder unzufrieden stellt. Dies bedeutet in der Grafik, je höher ein Punkt ist, desto stärker ist der Einfluss auf die Zufriedenheit der Kund*innen, wenn dieses Merkmal auf der titan Plattform vorhanden ist. Je weiter rechts ein Punkt ist, desto stärker ist der Einfluss auf die Unzufriedenheit von Kund*innen, wenn dieses Merkmal auf der titan Plattform nicht vorhanden ist.

Kundenzufriedenheits Koeffizient

Der Kundenzufriedenheit Koeffizienten zeigte, dass die Produktmerkmale unterschiedlich wahrgenommen werden. Die Wichtigkeit variiert. Portmachting ist das Merkmal mit der höchsten Kundenzufriedenheit beim Vorhandensein. Es wurde von den Befragten als wichtigstes Merkmal angesehen. Skalierung und Monitoring waren die Merkmale, die die größte Unzufriedenheit beim Nichtvorhandensein schaffen.

Natürlich kann die Umfrage nicht als repräsentativ angesehen werden, da die Menge der befragten Personen sehr gering ist. Sie gibt aber einen Hinweis zur Wahrnehmung der Produktmerkmale bei den befragten Personen.

Fazit

Die titan Plattform ist ein Produkt mit viel Potenzial für Unternehmen. Es ermöglicht die Einbindung verschiedener Informationsquellen, Maschinen und Sensoren auf einer Plattform. Die Daten können gesammelt und aggregiert werden, um neue wichtige Informationen zu gewinnen. Das Potenzial zeigte sich auch in der Wettbewerbsanalyse oder durch das Interesse von verschiedenen Unternehmen an dem Thema No-Code in der Industrie. In meiner Umfrage wurden acht der zehn Produktmerkmale als ein Leistungsmerkmal und eins von zehn als ein Basismerkmal klassifiziert. Das zeigt, dass die gewählten Produktmerkmale gut Resonanz erzeugen. Der Demonstrator zeigt Messebesucher*innen die Produktmerkmale und vermittelt einen Eindruck des Potenzials.

Natürlich war ich stolz, als ich die Arbeit dann schlussendlich beim Prüfungsamt abgegeben habe. Es war der immerhin der Abschluss meines dreijähriges Studiums und das Ende eines Kapitels in meinem Leben.

Der Beitrag Ein Messe-Demonstrator für eine Low-Code IoT Plattform erschien zuerst auf Industrial DevOps.

Mobile App für das Smart Home mit No-Code entwickeln

Laukar Tofik — Mon, 12 Apr 2021 11:26:04 +0000

Mit No-Code Programmierung kann jeder ohne Programmierkenntnisse eine App entwickeln. In einem Beispiel zeige ich, wie eine Mobile App mit den No-Code Werkzeugen FIGMA, Bravo Studio und der titan Plattform, zur Fernbedienung meiner smarten Lampe gewissermaßen über Nacht entsteht.

Not macht erfinderisch

Es ist Schlafenszeit. Zähne putzen, Gesicht waschen und endlich ins Bett. Eins habe ich wieder mal vergessen. Während ich auf Wolke 7 schwebe, schaue ich mir meine Lampe an. Mein Erzfeind… Mein Gehirn versucht mit der letzten Energie eine Lösung zu finden, die Lampe auszuschalten, ohne aufzustehen. Wenn ich doch nur die Macht hätte, wie in Star Wars, um die Lampe auszuschalten. Meine Ideen verlieren langsam an Realität. Kurz bevor ich die Hoffnung schon fast aufgegeben hatte, fällt mir dann die sinnvollste Idee von allen ein. Wir leben in einem Zeitalter der Digitalisierung. Es gibt beispielsweise autonom fahrende Autos, Staubsaugroboter, intelligente Lichtsensoren und so weiter. Alle genannten Geräte können heutzutage schon über das Handy gesteuert werden. Meine Lampe gehört sogar zu den Intelligenten. Also, wieso rappel ich mich nicht auf und baue mir eine mobile App, um meine smarte Lampe mit meinem Handy zu steuern.

Was benötige ich?

Ich stehe von meinem Bett auf und bewege mich voller Energie an den Schreibtisch. Nun zur Arbeit. Was benötige ich eigentlich?

Der Aufbau besteht aus:

Smartes Leuchtmittel z.B.: Müller Licht – tint White & Color oder IKEA Trådfri
RasperryPi
RaspBee II

Weitere Informationen findest du im Blog „titan mit der IoT Welt verbinden“ von Björn Latte unter dem Abschnitt „Schlauer werden“.

No-Code für die mobile App

Eine mobile App zu entwickeln, ist normalerweise eine Herausforderung. Ich müsste mehrere Stunden Arbeit investieren, um das Grundgerüst einer App für iOS oder Android zu verstehen. Dafür fehlt mir aber die Zeit so spät am Abend. Titan ermöglicht es, mittels No-Code die Backend-Integration für Unternehmen zu vereinfachen. Vielleicht gibt es solche Werkzeuge auch für die Entwicklung von Apps? Nach einer Online-Recherche entscheide ich mich für FIGMA und Bravo Studio.

Figma ist ein Online-Tool zum Designen von Prototypen. Damit ist es möglich, das Design meiner App zu erstellen.

Mit Bravo Studio wird aus einem FIGMA Projekt eine native Mobile-App erzeugt und die Logik mit dem Design verbunden.

Mit beiden Tools zusammen wird das Frontend, also die App selbst, entwickelt. Das Backend realisiere ich mit der titan Plattform. Die Hardware, beide Tools und titan sind alles, was ich brauche. Nun geht’s an den Spaß.

Realisierung der Lampensteuerung

Aufbau meines Systems:

Als allererstes beginne ich mit dem Design meiner App mit FIGMA. Die Elemente werden per Drag&Drop, wie in titan, in die Zeichenfläche gezogen. Ich beginne mit dem Aufbau eines ersten Frames. Das soll mein Homescreen werden, wenn ich die App öffne. Dort werden die Farbe der Lampe und drei Buttons angezeigt. Ein Button öffnet immer ein Pop-up-Fenster zum Steuern. Zwei Buttons sind zum Ein- bzw. Ausschalten der Lampe. Ein weiterer Button ermöglicht mir, die Farbe zu wechseln.

So, das Design steht. Bevor ich mit der App weitermache, fange ich erst mal an das Backend aufzubauen. Also ab zu titan.

Beim Thema Backend kräuseln sich meine Haare am Arm. Lange harte Arbeit und viel Planung ist nötig, bevor ich die erste Zeile Code schreibe. Zum Glück muss ich bei titan keinen Code schreiben, um die gleiche Funktionalität zu bekommen. Also rein da!

Die titan-Webseite aufrufen, einloggen und los geht’s. Schnell einen neuen Flow erstellt und rein in den Flow-Editor. Alle nötigen Bricks sind vorhanden.

Ich benötige für meine Steuerung drei Funktionen:

Typ	URL	Daten	Bedeutung
`GET`	../state	keine	Status der Lampe
`POST`	../state	`{"color": }`	Farbe Wechseln
`POST`	../light	`{"on": }`	Licht an-/ausschalten

Aus den drei Schnittstellen ergibt sich der folgende Flow:

Die Bricks state und light sind Request-Bricks. Sie sind unter einer bestimmten URL erreichbar und bieten der App die oberen Dienste an. Dabei ist die Struktur die folgende:

https://{Titan-Service-URL}/endpoint/{Username}/{Flowname}/{Request-Brickname}

Der Flow lässt sich auf die zwei wesentliche URLs aufteilen.

Status der Lampe ermitteln und verändern: ../state

Die ../state-URL lässt jeweils eine GET oder POST Anfrage zu. Je nach Anfrage, wird ein Ausgangsport gewählt. Bei einer GET-Anfrage wird der HttpClientGeneral1-Brick getriggert. Eine GET-Anfrage vom HttpClientGeneral1 aus wird an die Lampe gestellt, um die aktuelle Farbe zu erhalten. Anschließend werden die folgenden Daten an den HueToHex-Brick gesendet.

{
  "hue": 2000,
  "sat": 120,
  "bri": 120
}

Aus den Daten wird dann der RGB-Farbwert errechnet. Der Farbwert wird benötigt, um ein Image für unsere App zu erstellen, das genau diese Farbe enthält. Dafür gibt es eine offene API, die uns ein Image generiert. Der Wert ${color} wird durch den errechneten Farbwert ausgetauscht.

https://singlecolorimage.com/get/${color}/320x270

Der Response1-Brick antwortet meiner App dann mit der oberen URL. Nun, was passiert, wenn ich einen POST-Anfrage stelle? Ich muss auf die gesendeten Daten der App zugreifen. Dafür nutze ich das Portmapping.

Die Daten vom Handy werden über den state-Brick weitergeleitet an den HexToHue-Brick. Dieser berechnet den Hsl-Farbwert für die Lampe. Anschließend kann der LampWriter den Wert an die Lampe senden, um die Farbe zu wechseln. Der Response2-Brick antwortet der App, dass die Anfrage angekommen ist und erfolgreich war.

Lampe Ein- und Ausschalten: ../light

Jetzt noch kurz den Ein- und Ausschalter einrichten. Sonst muss ich heute Abend dennoch im hellen Schlafen. Die andere Schnittstelle ist ../light. Diese nutze ich nur um das Licht ein- und auszuschalten. Ich kann sie daher direkt mit dem LampWriter verbinden. Genau wie oben muss ich das Port-Mapping entsprechend anpassen.

Mein Flow steht und ist funktionsbereit. Nun ab zu Bravo Studio. Mein Gehirn macht schon langsam schlapp, aber nur noch ein wenig und die Steuerung steht.

In Bravo Studio muss ich zuallererst mein FIGMA-Projekt importieren. Das klappt zum Glück ganz einfach über einen Log-In mit meinen FIGMA-Benutzerdaten. Jetzt muss ich eine Data Library anlegen. Eine Data Library beschreibt eine Sammlung an REST-Anfragen. Ich erzeuge vier REST-Anfragen an meinen existierenden Flow.

Die Abbildung zeigt die REST-Anfrage, um die Lampenfarbe zu wechseln. Über ${} können Variablen definiert werden, die dann mit Daten aus der App gefüllt werden. Jetzt zum Data-Binding. Man beginnt mit der Wahl der App-Seite. Pro Seite kann man (momentan) nur eine REST-Anfrage verbinden.

Um die Daten zu verbinden, wählt man zuerst die Anfrage als Quelle und anschließend das visuelle Element als Senke der Daten aus. Bravo Studio übernimmt dann automatisch die Verbindung der Elemente und der Daten.

Geschafft, nur noch installieren

Endlich alles geschafft. Es fehlt der letzte Schritt. Die App muss nun auf mein Handy. Dafür nutze ich lediglich die eigene Bravo-Studio-App. Damit kann ich auf alle erstellten Projekt meines Bravo-Studio Accounts zugreifen.

Oh, schon 1:00 Uhr morgens. Also ab ins Bett und schnell einschlafen. Ich starre die Decke an mit einem breiten Lächeln. Dieses Mal gewinnt die Lampe nicht gegen mich. Also Handy in die Hand, App öffnen und die Lampe ausschalten. Die Lampe ist aus und ich habe den erholsamsten Schlaf seit Langem.

Der Beitrag Mobile App für das Smart Home mit No-Code entwickeln erschien zuerst auf Industrial DevOps.

Die Smarte Fabrik und das Internet der Dinge – Ein Industrie 4.0 Fallbeispiel

Uwe Glockmann — Mon, 08 Feb 2021 09:59:42 +0000

An einem verschneiten Dezembermorgen im Jahr 2019 befinde ich mich im mittelhessischen Haiger vor den Toren der neuen Smart Factory von Rittal. Der weltweit führende Systemanbieter für Schaltschränke, Stromverteilung, Klimatisierung, IT-Infrastruktur sowie Software & Service lässt in seinem neuen Werk eine smarte Fabrik entstehen – die weltweit modernste Fertigung von Kompakt-Schaltschränken und Kleingehäusen. Ich gehöre heute zu einer der ersten kleinen Besuchergruppen, die die Möglichkeit hat, diese einzigartige digitale Fertigung zu besichtigen.

Das vollständig nach hocheffizienten Industrie-4.0-Strukturen ausgerichtete Werk ist noch nicht zu 100% in Produktion. Big Data – eine Vielzahl an Daten aus Maschinen, von Aktoren und Sensoren werden noch ins Monitoring eingebunden, Daten- und Systemintegrationen finden parallel statt und ein Expertenteam von Entwicklungsingenieuren und Service-Technikern analysiert, clustert jede Menge Daten für das große Industrie 4.0-Format der Visualisierung. Der Kontext macht dann aus den Daten die unmittelbare bereitgestellte Information. Das Ziel ist, in den neuen Fabrikhallen auf 24.000 Quadratmetern mit mehr als 100 neuen Hightech-Maschinen, Anlagenkomponenten und IoT-Plattformen rund 9.000 Kompaktschaltschränke und Kleingehäuse pro Tag hochautomatisiert zu fertigen.

Die smarte Fabrik mit der Anbindung vieler Drittsysteme an den zentralen Geschäftsprozess hat sich in den vergangenen Jahren zu einer werksnahen Datendrehscheibe weiterentwickelt. (Bild: gemeinfrei / Pixabay)

Was ist Industrie 4.0 eigentlich (für uns)?

Der Begriff Industrie 4.0 wurde erstmals 2011, also genau vor 10 Jahren zur Hannover Messe in die Öffentlichkeit getragen. Aus einer Arbeitsgruppe entstand letztlich die Plattform Industrie 4.0, einem Zusammenschluss der Branchenverbände Bitkom, VDMA und ZVEI. Die Plattform Industrie 4.0 wurde seitdem weiter ausgebaut und das Ziel ist die Weiterentwicklung der mit dem Begriff Industrie 4.0 verbundenen Inhalte im Dialog mit Gewerkschaften, Wirtschaftsverbänden, Unternehmen, Wissenschaft und Politik.

Industrie 4.0 – relevante Informationen verfügbar machen

Für uns ist Industrie 4.0 eine neue Stufe der Organisation und Steuerung der gesamten Wertschöpfungskette über den Lebenszyklus von Produkten – von der Idee bis hin zum Recycling. Individuelle Kundenwünsche entstehen in der diskreten Fertigung und eine Studie von der International Data Corporation (IDC) aus 2019 belegt, dass 42% der Industrial IoT-Projekte in der deutschen Industrie genau dort umgesetzt werden, wo in der Industrieproduktion eine starke Anpassung der Produkte (bis zur Losgröße 1) erforderlich ist.

Basis ist die Verfügbarkeit aller relevanten Informationen in Echtzeit durch Vernetzung aller beteiligten Instanzen. Die Herausforderung dabei ist die Fähigkeit, aus den Daten den optimalen Wertschöpfungsfluss abzuleiten – und das zu jedem Zeitpunkt. Durch die Konnektivität von Menschen, Objekten und Systemen entstehen Wertschöpfungsnetzwerke. Sie sind dynamisch, echtzeitoptimiert, selbstorganisierend und unternehmensübergreifend.

Eine entscheidende Aufgabe ist dabei, sinnvolle Informationen aus der Vielzahl an Daten produzieren zu können. (Bild: gemeinfrei / Pixabay)

Was sind die großen Herausforderungen beim Industrial Internet of Things (IIoT)?

Im Gegensatz zum Internet of Things (IoT) stehen beim industriellen Internet der Dinge nicht die Verbraucher und Anwender im Mittelpunkt der Konzepte, sondern industrielle Prozesse und Abläufe. Ziele des Industrial IoT sind die Verbesserung der betrieblichen Effizienz, Kostensenkungen in der Produktion, schnellere Prozesse und die Realisierung neuer Geschäftsmodelle.

Zurück in der neuen digitalen Fabrik von Rittal. Fahrerlose Transportsysteme kommen mir entgegen, fahren sensorgesteuert an mir vorbei und übernehmen automatisiert die Transporte im Werk. Ich fühle mich wie ein Statist aus einem Star Wars Film. Ich komme mit einem Ingenieur aus der Prozessautomatisierung ins Gespräch. Er ist total begeistert, irgendwie auch stolz auf dieser 24.000 Quadratmeter großen digitalen Bühne zu arbeiten.

Früher analog, heute digital

„Früher hatten wir eine Vielzahl an Insellösungen von Systemen, Maschinen und Anlagen. Es fehlte uns die Transparenz über Aufträge, Prozesse und Produktionsstatus durch mangelnde Datenverfügbarkeit. Und dann unglaublich viel Papier, papierbasierte Prozessschritte und zwangsläufige Medienbrüche,“ so der Ingenieur. „Es gab viel Ad hoc-Planung und -Kommunikation anstelle von strukturierter Planung. Und zuletzt geht es um eine genauere Kontrolle, wie viel elektr. Strom, Wasser und andere Ressourcen verbraucht werden, wann die Maschinen laufen und wie viel diese produzieren.“

Konnektivität – Menschen und Maschinen verbinden

Ich stimme ihm zu und wo früher die einzelnen Fertigungsprozesse Zuschneiden, Kanten, Schweißen sowie Lackieren transaktional, sequenziell und unabhängig voneinander abgearbeitet wurden, werden in der Smart Factory alle Menschen und Maschinen immer enger in das Manufacturing Execution System (MES) eingebunden. Die Einzelbaugruppen werden am Ende automatisch zum fertigen Produkt zusammengeführt. Dabei kommunizieren die Maschinen und Handling-Systeme, die fahrerlosen Transportsysteme untereinander und mit den übergeordneten Prozesseitsystemen. So stellt sich der Maschinenpark im Produktionsprozess automatisiert auf die zu produzierenden Werkstücke und Baugruppen ein.

Menschen, Objekte und Systeme tauschen permanent Informationen aus. (Bild: gemeinfrei / Pixabay)

5G, Edge Computing und KI/ML – neue Technologien in der Industrie 4.0

Ich treffe auf einen jungen Mann aus der IT. Er erzählt mir viel über Big Data und neue Technologien, die in Zukunft zum Einsatz kommen. Der gesamte Maschinenpark liefert permanent Daten über die Steuerung und die aktuellen Betriebszustände. Diese Daten werden zukünftig in einem Edge Data Center am Werk gesammelt und mit Anwendungen eines Schwesterunternehmens ausgewertet. So wird die Basis für Industrial Analytics gelegt. Mithilfe wissensbasierter Systeme auf Basis von Künstlicher Intelligenz (KI), die kontinuierlich dazulernen – Machine learning (ML) – werden Ausfallzeiten verringert, Wartungen vorausschauend (Predictive Maintenance) geplant und damit Störungen des ausgeklügelten Produktionsprozesses minimiert.

Diese neuen Technologien wie 5G, Edge Computing und KI/ML sollten nach IDC Einschätzungen genutzt und eingesetzt werden, um langfristig einen Grundstein für neue Geschäftsmodelle und Services zu legen, die entweder selbstständig erbracht oder in Ökosysteme integriert werden können. Diese Ökosysteme zu entwickeln, entsprechende Partnerschaften aufzubauen und allgemein akzeptierte Standards zu bestimmen, sollte und wird eine der zentralen Aufgaben für industrielle und industrienahe Unternehmen in den kommenden Jahren in Deutschland sein, um wettbewerbsfähig zu bleiben.

5G – Datenverarbeitung mit 10 Gigabit pro Sekunde

Mittlerweile hat der Schaltschrank-Spezialist Rittal als eines der ersten Industrieunternehmen in Deutschland eine 5G Frequenzzuteilung erhalten. Bereits in 2020 wurde ein privates 5G Mobilfunknetz im neuen Werk in Haiger installiert. Erste Pilotprojekte, etwa in der Produktionsüberwachung und -analyse, sind bereits in Planung.

Rittal will das 5G-Mobilfunknetz in seiner Smart Factory in Haiger in einer realen Produktionsumgebung schnellstmöglich installieren und in Betrieb nehmen. Die neue 5G-Funktechnologie soll den Datenverkehr deutlich beschleunigen und vereinfachen – etwa beim videobasierten Abgleich von Stückzahlen mit hinterlegten Auftragsdaten und bei der schrittweisen Implementierung von Data Analytics für eine präventive Instandhaltung. Mit dem neuen 5G Mobilfunkstandard lassen sich Daten mit einer Geschwindigkeit von 10 Gigabit pro Sekunde verarbeiten. 5G gilt als die Zukunftstechnologie, mit der sich industrielle Fertigungsprozesse noch besser vernetzen und steuern lassen – und somit die Potenziale von Industrie 4.0 weiter auszuschöpfen.

Edge Computing im industriellen IoT

Aktuelle Cloud-Computing-Trends stellen das Edge-Computing als ein Konzept vor, das den Industriebetrieb revolutionieren kann. Dies ist auf seine Fähigkeit zurückzuführen, nicht angeschlossene Geräte, Fertigungswerkzeuge, IIoT-Geräte und Arbeitsplätze in die Lage zu versetzen, Daten zu erfassen und zu verarbeiten, ohne mit einem zentralen Datenbanksystem zusammenarbeiten zu müssen. Mit Industrie 4.0 und den Millionen von Sensoren und IIoT-Geräten, die es antreiben, wird das Edge-Computing für das industrielle IoT neue Höhen erreichen.

Edge-Computing kann als die Bereitstellung von Daten-Handling-Aktivitäten und Vorgängen an der Quelle, ohne durch zentralisierte Netzwerksegmente gehen zu müssen, definiert werden. Dieser Rechenprozess optimiert Geräte, IoT-Geräte und Anwendungen, indem er das Rechnen näher an den Netzwerkrand dieser datenproduzierenden Geräte bringt. Je nach Gerät oder Anlage kann sich der Netzwerkrand auf den Bereich beziehen, in dem das Gerät mit dem Internet kommuniziert.

So ist das auch bei Rittal. Zukünftig können Daten, die an Sensoren, Bauteilen, Maschinen oder Robotern entstehen und benötigt werden, schneller als bisher in einem Edge- oder Cloud-Rechenzentrum erfasst und ausgewertet werden. Die notwendigen IT-Voraussetzungen sind im neuen Werk in Haiger bereits vorhanden.

Neue Technologien wie 5G, Edge Computing und KI/ML sind auf dem Vormarsch. (Bild: gemeinfrei / Pixabay)

Wo liegt der Unterschied zwischen Künstlicher Intelligenz (KI) und Machine learning (ML)

In der Smart Factory von Rittal fallen Daten von über 100 Maschinen an. Das sind bis zu 18 Terabyte am Tag. Eine Auswertung der Daten kann nur erfolgen, wenn diese Daten nach der Erfassung per Künstlicher Intelligenz (KI) analysiert werden. Und der Mensch spielt dabei eine entscheidende Rolle: Erst mit den Menschen als systematische Ausbilder werden aus den Anlagen zunächst lernende Systeme – Maschinelles Lernen (ML) – und später intelligente Systeme.

Computerprogramme, die Dame spielten

Sie sind eines der frühesten Beispiele für Künstliche Intelligenz. Auf der Dartmouth Konferenz im Sommer 1956 war es die Idee der KI-Pioniere eine komplexe Maschine zu konstruieren, die mit Hilfe der neu entstehenden Computer die gleiche Intelligenz wie ein Mensch besitzt. Bei diesem Konzept spricht man von der «General Artificial Intelligence (AI)»: Maschinen, die all unsere Sinne haben, unsere Vernunft und so denken wie wir.

Was heute schon davon umgesetzt werden kann, ist ein Konzept der «begrenzten KI». Technologien, die in der Lage sind, spezifische Aufgaben genauso gut oder besser als Menschen zu lösen. Ein Beispiel dafür ist die Gesichtserkennung von Facebook oder die Bildklassifizierung bei Pinterest. Die Technologien zeigen Aspekte von menschlicher Intelligenz. Doch wie funktioniert das und woher kommt die Intelligenz? Hier kommt das Machine Learning (ML) ins Spiel.

«Maschinelles Lernen» (Machine Learning) bezeichnet eine Querschnittsdisziplin aus Statistik, Informatik und Mathematik, die das Ziel hat, Softwaresysteme zu konstruieren, die automatisch aus Daten lernen können. Eine Vielzahl generischer Lernalgorithmen wurde entwickelt, um eine Vielzahl von Lernaufgaben zu lösen oder neue Erkenntnisse aus Daten zu gewinnen. Maschinen lernen also komplexe Zusammenhänge, wozu Menschen in puncto Schnelligkeit und Genauigkeit nicht mehr in der Lage sind.

Maschinelles Lernen kombiniert Methoden der Statistik, Informatik und Mathematik mit dem Ziel, Softwaresysteme zu konstruieren, die automatisch aus Daten lernen können. (Bild: Pixabay / CC0 )

Damit die wachsende Datenflut in der industriellen Produktion beherrschbar wird, hilft maschinelles Lernen, aus einer immensen Menge von Sensoren- und Prozessdaten komplexe Zusammenhänge zu entschlüsseln, Muster zu erkennen und neues Wissen zu generieren.

Source Code oder doch lieber Low-Code / No-Code?

Meine Werksbesichtigung in der Smart Factory bei Rittal nähert sich dem Ende. Fast am Ausgang angekommen, schaue ich einem Techniker über die Schulter, der an einem Prozessrechner noch einige Programmierungsanpassungen im Source Code vornimmt. Was früher eingeweihten IT-Professionals ein Begriff war, ist heute im Bereich der Software- und Applikationsentwicklung nicht mehr wegzudenken. Von der Automotive-Industrie bis zum Pharma-Unternehmen – vom Mittelständler bis hin zum Global Player. Sie alle nutzen es und die Einsatzmöglichkeiten sind nahezu grenzenlos.

Die Rede ist von Low-Code / No-Code

Schneller, leistungsfähiger, effektiver und kostengünstiger müssen sie sein, die digitalen Prozesse und Anwendungen. Die Prämisse der Digitalisierung gilt für alle Unternehmen, denn in Zeiten steigender Anforderungsprofile, eines zunehmenden Fachkräftemangels und überlasteter IT-Teams ist eine Low-Code oder No-Code-Automatisierungsplattform oftmals ein probates Mittel, um Entwicklungszeit einzusparen, Kosten zu senken und die eigenen Applikationen stets auf dem neuesten Stand zu halten. Gerade für IT- und Fachabteilungen bietet sich damit die Möglichkeit, dem hohen Bedarf an Anwendungen und anderen Tätigkeiten gerecht zu werden.

Wohin geht sie nun, die künftige Reise für Low-Code / No-Code?

Der IT-Analyst Gartner prognostiziert, dass die Erstellung von Low-Code-Anwendungen, die auch No-Code enthalten, bis zum Jahr 2024 mehr als 65% aller App-Entwicklungsfunktionen ausmachen wird. Bis 2024 werden 75% aller Großkonzerne mindestens vier Low-Code-Entwicklungstools für Aktivitäten sowohl in der IT-Anwendungsentwicklung als auch im Citizen Development einsetzen. Forrester Research prognostiziert, dass sich der Marktanteil von Low-Code bei Business-Anwendungen innerhalb der nächsten Jahre von derzeit elf auf über 30 Prozent vervielfacht. IDC sieht in einem Whitepaper zum Thema Low-Code stark verkürzte Entwicklungszyklen und Vorteile durch Produktivitätssteigerungen von bis zu 25 Prozent.

Das teils mühsame Coding einzelner Programmierzeilen gehört mit dem modularen Low-Code-Ansatz der Vergangenheit an. (Bild: gemeinfrei / Pixabay )

Individuelle Softwarelösungen sind gefragt

In nur wenigen Jahren hat sich die Entwicklungstechnologie Low-Code und No-Code zum Gütesiegel für Entwicklungseffizienz und zu einem klaren Wettbewerbsvorteil für Unternehmen gemausert. Statt mühsamen Codings einzelner Programmierzeilen wird bei Low-Code mit Hilfe eines modularen Prinzips gearbeitet. Vorgefertigte Bausteine ersetzen textbasiertes Coding. Dies spart Unternehmen viel Zeit und Geld – und entlastet die knapp bemessenen Ressourcen hauseigener IT-Teams. Beim modularen Baukastenprinzip des Low-Code-Development wird mit Hilfe von Applikationsdesignern, grafischen Methoden und Bibliotheken gearbeitet, um individuelle Softwarelösungen und Geschäftsprozessanwendungen zu erstellen. So können neue Funktionen mit immer komplexeren Anforderungsprofilen in kurzer Zeit umgesetzt werden.

COVID-19 und Industrie 4.0

Heute denke ich noch oft an dieses imposante Industrial IoT Erlebnis in der Smart Factory von Rittal zurück. Rittal ist ein Musterbeispiel für gelebte Industrie 4.0. Und auch heute in COVID-19 Zeiten ist das industrielle Internet der Dinge mehr als präsent. Aktuell sehen viele Unternehmen zentrale Vorteile im Industrial IoT zur Bewältigung kurzfristiger Herausforderungen. Laut einer aktuellen IDC-Studie planen 59 Prozent der Befragten neue IIoT-Projekte. COVID-19 bremst aktuell sicherlich einige Unternehmen aus, für andere ist es hingegen der Moment, in denen sich ihre Investitionen in neue Technologien und vor allem auch im Industrial IoT auszahlen. Wie Studienergebnisse zeigen, ist die Krise für viele gleichzeitig ein Weckruf, längst notwendige Modernisierungen durchzuführen.

Denn eins ist klar. Die Bedeutung von Industrie 4.0 für Deutschland kann nicht hoch genug eingeschätzt werden. Industrie 4.0 ist die Voraussetzung für den Erhalt der Wettbewerbsfähigkeit der deutschen Industrie und damit die Sicherung von Arbeitsplätzen.

Die Chancen sind riesig und dem an Ressourcen armen und Know-how reichen Standort Deutschland kann nichts Besseres passieren als die Digitalisierung in der Industrie.

Links

https://www.rittal.com/ch-de/content/de/unternehmen/presse/pressemeldungen/pressemeldung_detail_57152.jsp

https://de.wikipedia.org/wiki/Industrie_4.0

https://www.rittal.com/at-de/content/de/unternehmen/presse/pressemeldungen/pressemeldung_detail_96576.jsp

https://www.bitkom.org/Themen/Digitale-Transformation-Branchen/Industrie-40/Was-ist-Industrie-40-2.html

https://automationspraxis.industrie.de/industrie-4-0/rittal-smart-factory-fertigt-schaltschraenke/

https://automationspraxis.industrie.de/news/rittal-pionier-beim-5g-mobilfunk-in-der-produktion/

https://www.industry-of-things.de/iot-basics-machine-learning-in-der-smart-factory-a-698047/

https://www.twt.de/news/detail/wo-liegt-der-unterschied-zwischen-artificial-intelligence-machine-learning-und-deep-learning.html

https://www.industry-of-things.de/low-code-ist-integrativ-automatisiert-und-smart-a-960267/

https://www.mendix.com/de/resources/gartner-magic-quadrant-for-low-code-application-platforms/

https://www.idc.com/getdoc.jsp?containerId=prEUR147017420

https://www.bitkom.org/Themen/Digitale-Transformation-Branchen/Industrie-40/Vision-Industrie-40-2.html

Der Beitrag Die Smarte Fabrik und das Internet der Dinge – Ein Industrie 4.0 Fallbeispiel erschien zuerst auf Industrial DevOps.

titan mit der IoT Welt verbinden

Björn Latte — Mon, 28 Dec 2020 11:34:34 +0000

Im Winter, in der Dunkelheit, morgens am Auto und alle Scheiben zugefroren. Das warme Smart Home, in dem das sich mit meiner Bewegung durch die Räume einschaltende Licht gerade wieder erlischt, hat das nicht gekümmert. Mich aber jetzt umso mehr, während ich mit kalten Händen die Scheiben vom Eis befreie.

Wäre das Licht, welches mich beim Aufstehen im Flur begrüßt nicht nur von morgenfreundlicher Helligkeit gewesen, sondern in einer Farbe, die der Außentemperatur angepasst ist, die Warnung wäre angekommen. Dass es heut‘ mal wieder etwas länger dauert und die Handschuhe besser dabei sind, wäre mir „einleuchtender Weise“ übermittelt worden. Aber dafür reicht es nicht mit der „Intelligenz“ des Smart Home.

Die Daten sind vorhanden. Die Interfaces sie abzufragen und sie entgegenzunehmen auch. Nur wie finden diese beiden Enden zusammen?

Digitalisierung überall

In immer mehr Häusern findet man jetzt Smart Home Installationen, die auf Basis eines ZigBee Funknetzwerks arbeiten. Auch von IKEA ist inzwischen mit Trådfri eine kostengünstige Lösung zu bekommen. Wenig anders sieht es in vielen Betrieben aus, in denen die Zahl der Sensoren und Aktoren ständig steigt und doch die Hürde der Digitalisierung nicht kleiner wird.

Wie eine für die Digitalisierung von KMUs gedachte Plattform uns bei diesem Problem aus der Heimautomatisierung helfen kann und warum auch solch scheinbar kleine Problemstellungen aufzeigen wie Digitalisierung in der Industrie vor sich gehen kann, macht unser kleines Maker Projekt deutlich.

Schlauer werden

Um das Licht jetzt schlauer zu machen, lässt sich hier mit einem Rasperry Pi einem ZigBee Gateway und einer No-Code Plattform nachhelfen. Ein experimenteller Aufbau aus einem Dataflow in der titan Platform , einem Gateway zur Lichtsteuerung und einer Lampe soll exemplarisch dabei einmal zeigen, was mit Daten alles machbar ist. Also machen mein Kollege und ich uns ans Werk.

ZigBee Gateway

Zutaten Hardware:

RasperryPi
RaspBee II
Smartes Leuchtmittel z.B.: Müller Licht – tint White & Color oder IKEA Trådfri

RasBee II auf einem Pi3 Board

Beim Aufbau des Smart Homes ist es genauso wie in der Industrie bei der Wahl der Steuerung. Man kann sich an einen Hersteller wie z.B. Philips Hue oder Osram Lightify binden. Damit ist man dann aber ebenso an die Launen eben dieses Herstellers gebunden. So fiel die Wahl hier auf das offenere Gateway von Dresden Elektronik. Nicht zuletzt, da es eine gut dokumentierte, Open Source REST API anbietet (https://github.com/dresden-elektronik/deconz-rest-plugin).

Zutaten Software:

deCONZ
deCONZ REST Plugin

Der Aufbau des Gateways und auch die Installation der nötigen Software gestalten sich dankbar einfach. Es gilt an dieser Stelle der detaillierten Dokumentation auf der Website des Herstellers zu folgen. In der deCONZ GUI oder über die Phoscon APP kann danach das erste Leuchtmittel angelernt werden. Wer nicht immer die GUI geöffnet haben möchte, damit das REST Interface zur Verfügung steht, betreibt dieses im headless Modus, kann danach jedoch auch nicht mehr die deCONZ GUI nutzen. Für Debugging und ähnliche Zwecke muss man dann etwas hin und her wechseln. Auf der Kommandozeile ist dazu der entsprechende Dienst auf enablezu setzen und zu starten.

				
					sudo systemctl enable deconz 
sudo systemctl start deconz

Ohne große Mühe haben wir jetzt dank Dresden Elektronik schon eine mit etlichen nützlichen Features wie Lichtgruppen, Zeit Steuerung, Szenen und weiterem ausgestattet Steuerung. Für sich schon smart, aber nicht smart genug, um mit im Web leicht verfügbaren Informationen mehr aus der Sache zu machen.

Bring Farbe in Dein Leben

Zutaten:

titan Plattform
Datenfluss basierte Programmierung

Die Temperaturdaten für die farbliche Steuerung der Lampe gibt es aus dem Web. Wir nutzen hier die nach einer Anmeldung frei verfügbare Variante der REST API von OpenWeatherMap (https://openweathermap.org/api), mit der auch für deinen Ort auf dem Globus Wetterdaten verfügbar sein sollten. Das Abfragekontingent ist großzügig, wenn man es benötigt. Für echte Bastler lässt sich unser Beispiel natürlich auch mit der eigenen Wetterstation realisieren.

Um jetzt auf der einen Seite die Daten abzuholen und auf der anderen Seite als Steuerinformationen an das Gateway zu übergeben, benötigen wir „Glue Code“, der die Arbeit für uns verrichtet. Damit dieser wartbar und veränderbar bleibt, schreiben wir erst gar keinen Code, sondern nutzen die Möglichkeiten der titan Plattform per Datafluss Programmierung eben diese Daten zu holen, zu transformieren und an das Gateway zu senden. Die Elemente der Programmierung werden Bricks genannt und es stehen uns eine Reihe generischer Bricks zur Verfügung, mit denen schon eine Vielzahl an Aufgaben erledigt werden können.

Am Anfang des Flows steht ein HTTP Request an die REST API von Open Weather. Dafür nutzen wir in titan den HTTPClient Brick mit dem wir die Daten aus dem WWW abfragen können.

Eine Anfrage zusammen mit dem zuvor bei OpenWeather generierten API Schlüssel für z.B.:

				
					https://api.openweathermap.org/data/2.5/weather?q=Kiel&units=metric&appid=15a3102429698031a2aacb41b8598bc0

liefert dann neben weiteren Informationen zum aktuellen Wetter die begehrte derzeitige Temperatur am abgefragten Ort:

				
					{
	"name": "Kiel",
    ...
	"main": {
		"temp": 6.39,
         ...
	},
}

Flow zur Verbindung einer offenen REST API mit einer über ZigBee angebundenen smarten Lampe.

Den Startpunkt haben wir, muss nur noch eine Farbe daraus werden, mit der die Lampe gefüttert werden kann. Der HTTPClient liefert den gesamten Body zurück, aus dem wir dann nur die benötigten Daten extrahieren. Der JSONParser wandelt uns zuerst das universelle textuelle Ergebnis in eine Key-Value Map, welche die titan Plattform besser versteht. Den Inhalt der Map, oder besser der Teil der uns interessiert legen wir am Portmapping des Ausgangsports fest. Das von OpenWeather erhaltene JSON enthält den Schlüssel main und darin die begehrte Temperatur. Dazu fügen wir der resultmap ein Element main von Typ map und darunter das Element temp vom Typ float32 hinzu. Das Port Mapping erledigt den Rest für uns, wenn wir das Feld temp auf das Feld celsius des nächsten Bricks zuweisen.

Mit Hilfe von Portmapping werden Daten aus und in den Datenstrom gelenkt.

Aus der Temperatur werde Farbe. Dies ist eine speziellere Rechenaufgabe für die wir in titan noch keinen generischen Brick gefunden haben mit dem sich dies erledigen ließ. Also doch ein wenig Programmierung. Ein neues Brick Paket muss her, in dem der TemperatureToHUE Brick implementiert wird. Die Anleitung „How To Write a Brick“ und das Template für Brick Pakete helfen bei der Erstellung. Das neue Paket stellen wir dann, dem Open Source Gedanken der Plattform folgend, auch gleich als Repository zur Verfügung. Die Nächsten, die sich einer ähnlichen Aufgabe wie wir stellen, haben den Brick dann gleich zur Verfügung oder müssen zumindest nur noch das entsprechende Paket in Ihrer Instanz hochladen.

Damit es, wenn es im Winter draußen schön kalt ist, tiefblau leuchtet und im Sommer rot, erstellen wir zuerst einen linearen Gradienten aus dem HLS Farbkreis. Mit der aktuellen Temperatur ermitteln wir dann später den anzuzeigenden Farbton aus diesem Gradienten. Sobald unser neuer Brick in der Plattform hochgeladen ist, erledigt das Port Mapping am Input und Output des Bricks.

				
					from ujotypes import UjoUInt16

import titanfe.log
from titanfe.brick import BrickBase


log = titanfe.log.getLogger(__name__)

HUE_MAX = 65535  # 360°
HUE_COLD = int(HUE_MAX / 360 * 250)  # deep blue at 250°
HUE_HOT = 0  # red at 0°

TEMP_MIN = -20.0
TEMP_MAX = 40.0


def make_gradient(hue_min, hue_max, temp_min, temp_max):
    """ create evenly spaced gradient from low to high"""
    temp_range = range(int(temp_min * 10), int(temp_max * 10) + 1)
    return {
        temp: int(hue_min + step * (hue_max - hue_min) / (len(temp_range) - 1))
        for step, temp in enumerate(temp_range)
    }


class Brick(BrickBase):
    temp_color_gradient = make_gradient(HUE_COLD, HUE_HOT, TEMP_MIN, TEMP_MAX)

    def process(self, input, port):
        try:
            temperature = float(input.value)
        except (ValueError, TypeError) as error:
            log.error("Temperature is not a numeric value: %s", error)
            log.debug("Failed to floatify: %s", input.value, exc_info=True)
            return

        temp = max(min(float(temperature), TEMP_MAX), TEMP_MIN)  # fix temp between -20 to 40°
        temp = round(temp, 1) * 10

        return UjoUInt16(self.temp_color_gradient[temp])

Damit der Farbton bei der Anzeige auch passt, muss dem Kommando an die Lampe auch noch die Sättigung und die Helligkeit mit übermittelt werden. Wer weiß, welche Lichtstimmung zuletzt im Flur angesagt war. Für die Aufgabe Festwerte in den Datenstrom des Flows zu injizieren gibt es die Konstanten im Portmapping, die mit den passenden Werten belegt und in das Payload Feld des HTTPWriter gemappt werden.

Das Kommando an das ZigBee Gateway geht dann per HTTPWriter im Body des Request raus. Dazu muss am Brick nur die aufzurufende URL parametrisiert und per Port Mapping die einzelnen Felder aus dem Datenstrom an das PayloadFeld des Bricks übergeben werden. Den Aufbau der Map für den Payload wird im Portmapping Dialog der Verbindung zum HTTPWriter angelegt. Die nötigen Infos über die Parameter des Kommandos finden sich in der deCONZ API Dokumentation beim Set State Kommando für Lampen. Die Umwandlung des UJO Objekts aus dem Flow in JSON übernimmt das Port Mapping und der Brick.

				
					{ 
  "bri": 10,
  "hue": 15170,
  "sat": 255
}

Bereit für die nächste Stufe

Für den nächsten kalten Tag, an dem ich jetzt rechtzeitig gewarnt werde, dass Eiskratzen angesagt ist, sorgt die Natur. Mehr Ideen, was man noch alles mit Daten aus dem Netz und Datenfluss Programmierung machen kann, kommen bestimmt auch noch. Wie einfach sich Digitalisierung erreichen lässt und dass es uns mit der Plattform, den Bricks und Flows möglich sein wird, diese in iterativer und einfach Form anzugehen, hat der Ausflug in die Heimautomation gezeigt. Die meisten Aufgaben waren mit allgemeinen Bausteinen lösbar. Nur dort, wo wirklich spezielle Dinge benötigt werden, muss noch Hand angelegt werden.

Übertragbar ist dies in den industriellen Bereich. Auch dort gibt es einen Reichtum an Daten, die nur darauf warten, in die passende Form gebracht und den ebenfalls schon bereitstehenden Endpunkten übergeben zu werden . Klein anzufangen und einen Datenfluss dann fortlaufend zu erweitern und an die Gegebenheiten anzupassen, anstelle einer großen Lösung auf einmal, erscheint dabei völlig natürlich.

Der Beitrag titan mit der IoT Welt verbinden erschien zuerst auf Industrial DevOps.

Digitale Transformation in der Produktion

Maik Wojcieszak — Thu, 12 Nov 2020 09:59:14 +0000

Die Digitale Transformation ist kein Hype, der vorübergeht, sondern die konsequente Anpassung an eine veränderte Situation. Selbst in Märkten, die bisher als unangreifbar galten, müssen sich die etablierten Unternehmen neuen Mitbewerbern stellen, die scheinbar aus dem Nichts auftauchen.

Die von Unternehmen gesteuerte Werbung ist nicht mehr die einzige Informationsquelle, die Kunden zur Verfügung steht. Selbstbewusst werden im Netz Bewertungen geteilt und Foren genutzt, um sich eine Meinung vom Wert und der Qualität eines Produkts oder einer Dienstleistung zu bilden.

Was heute für Kunden noch interessant ist, kann morgen bereits Schnee von gestern sein.

Startups sind in der Lage, Digitale Geschäftsmodelle mit einem Bruchteil der Ressourcen umzusetzen, die noch vor wenigen Jahren erforderlich waren.

Unternehmen mit digitalen Dienstleistungen wie Amazon, Netflix, Otto.de und viele andere haben gelernt, mit der neuen Welt umzugehen und sie als Chance zu nutzen. DevOps steht dabei als Oberbegriff für Technologien, Methoden, Werte und Prinzipien, die diesen Unternehmen helfen schnell und zielsicher auf Veränderung zu reagieren.

Wie können diese Erfahrungen der Digitalunternehmen übertragen werden auf Unternehmen, die für ihre Wertschöpfung physikalische Maschinen und Produktionsanlagen nutzen?

Das Ziel

„Never touch a running system!” – Wenn es erstmal läuft möglichst nichts mehr verändern, ist ein Credo, das wir besser zurück ins 20. Jahrhundert schicken und vergessen. Schnelle Reaktionen auf neue Anforderungen sind nur möglich, wenn die Veränderung zur Norm wird.

Wie produzierte und eingelagerte, unfertige Teile sind neue Systemfunktionen, die zwar entwickelt sind, aber nicht genutzt werden, gebundenes Kapital, das keinen Gewinn bringt oder einen anderen Mehrwert schafft. Kurzfristige Markchancen werden möglicherweise nicht genutzt.

Das Ziel von DevOps ist deshalb die kontinuierliche Auslieferung neuer Softwareversionen (continuous delivery = CD) in die Produktion. Dabei sind mehrere Aktualisierungen täglich denkbar und machbar. Sogar Aktualisierungen in der laufenden Produktion sind heute technisch umsetzbar, sicher und nutzenbringend.

CALMS: Das Fundament für den Erfolg

Bei all der Flexibilität von Software, stellt die ständige Veränderung eines komplexen Systems hohe Anforderungen an die Qualität der Umsetzung. Damit das gelingt prägte die DevOps Community das Akronym CALMS (Abbildung 1) und beschreibt damit die Grundpfeiler für den Erfolg.

Abb. 1: Das Fundament von DevOps

In vielen Artikeln und Veröffentlichungen zum Thema Digitale Transformation wird deutlich, wie wichtig die Unternehmenskultur ist. Digitale Unternehmen stellten bereits fest, dass ohne eine passende Kultur DevOps nur Theater ohne Effekt ist. Die Gründe hierfür sind vielfältig.

Standardisierung und Automatisierung komplexer Arbeitsabläufe sind für eine reproduzierbare Qualität unerlässlich. Manuelle Arbeitsschritte sind langsam und fehleranfällig. Während Industrie 4.0 die Automatisierung und Flexibilisierung durch Maschinen in der Produktion adressierte steht bei Industrial DevOps die wachsende Integration digitaler Systeme über Abteilungs- und Unternehmensgrenzen hinweg im Mittelpunkt.

Komplexe Softwareprojekte sind teuer. Digitale Unternehmen haben jedoch lange Entscheidungswege und teilweise unnötigen administrativen Aufwand als mögliche Ursachen dafür identifiziert.

So wurde das L eingefügt, um die Rolle der Lean Prinzipien und Methoden in DevOps zu unterstreichen. Lean stammt aus dem Toyota Production System (TPS) und soll unter anderem erreichen, wertschöpfende Arbeitsschritte zu stärken und Arbeiten, die keinen Wert liefern (Waste) zu reduzieren. Hier schließt sich interessanterweise der Kreis, denn Lean ist in der Industrie seit langem bekannt und wird erfolgreich angewendet.

Metriken, Messen und Monitoren

Das M für Messungen oder auch alternativ für Monitoring bildet die Grundlage der Analyse, Optimierung und Validierung des Gesamtsystems. Je besser die Messungen, desto schneller können Engstellen, Probleme aber auch Chancen und Potentiale erkannt werden.

In digitalen Unternehmen zeigen Dashboards zu jeder Zeit den aktuellen Zustand des Systems. Wird ein System zum Beispiel durch ein Softwareupdate verändert oder Server, Netzwerk und andere IT-Infrastruktur funktioniert nicht mehr korrekt, so kann das Problem schnell erkannt, analysiert und (vielleicht sogar automatisch) behoben werden.

In produzierenden Unternehmen helfen Maschinendaten zusätzlich nötige Wartung zu erkennen und so Ausfälle zu vermeiden (Predictive Maintenance).

Messungen helfen Fehler schnell zu erkennen und zu beheben. So werden die Auswirkungen von Fehlern reduziert und gleichartige Fehler zukünftig vermeidbar.

Informationen teilen

Zentral erfasste Daten stehen allen Beteiligten in Echtzeit zur Verfügung. Das stellt die Grundlage für das S, dem Sharing, dar. Technische Systeme verändern sich in der Regel nicht von allein (zumindest nicht zum Besseren). Dazu bedarf es der Kreativität und der Erfahrung von Menschen, die mit dem System arbeiten und ihr Fachwissen einbringen. Teamarbeit und ein gemeinsames Verständnis für die aktuelle Situation, sowie für die Anforderungen erfordert Transparenz und niedrige Hürden, die benötigten Informationen zu erhalten und zu verstehen.

Industrial DevOps

Abbildung 2: Industrial DevOps

Viele der bereits erprobten DevOps Werkzeuge und Methoden helfen Softwareaktualisierungen routinemäßig in die Produktion zu bringen. Die enge Verflechtung von Software und physikalischen Maschinen bringt jedoch neue Herausforderung mit sich.

Wenn Maschinen, Sensoren und Aktoren durch Software verbunden werden, entstehen Cyber-Physikalische Systeme.

Abbildung 2 zeigt, wie Geschäftsfunktionen, Softwareentwicklung, Softwarebetrieb und Produktion im Unternehmen kontinuierlich und transparent zusammenarbeiten.

Digitale Unternehmen haben gelernt, Herausforderungen ganzheitlich anzugehen. Die Erweiterung BizDevOps, also die Einbeziehung der Geschäftsfunktionen (Biz) oder DevOpsSec die unterstreicht wie wichtig IT-Security ist, sind logische Weiterentwicklungen. Industrial DevOps schließt nun die Lücke zwischen der virtuellen Welt der Software und der physikalischen Welt der Maschinen, Sensoren und Aktoren.

Unter anderem werden dafür Wissensbereiche wie das Internet of Things (IoT), Fog Computing, Smart Manufactoring sowie Entwicklung und Test von Embedded Software unter dem Oberbegriff Industrial DevOps in einem neuen Licht betrachtet. Auch für die Konstruktion von Produktionsanlagen und Maschinen ergeben sich interessante Aspekte. DevOps bringt zusätzlich unter anderem Themen wie Lean, Agile, Systems Thinking und natürlich auch Künstliche Intelligenz als wichtiges Werkzeug mit.

Hardware auf „Vorrat“

Bei Neuinvestitionen sind die Kosten für Maschinen und Sensoren im Verhältnis zur Softwareentwicklung gesunken. Die rein physikalische Vernetzung von z.B. Sensoren ist heute ohne großen Aufwand machbar. Wieso also nicht mehr einbauen als aktuell nötig und mit Hilfe von Software nach und nach das System verbessern, erweitern und an neue Herausforderungen anpassen?

Auch Maschinenhersteller können bei der Entwicklung darauf verzichten jede nur denkbare Funktion in ihrer Firmware umzusetzen und stattdessen Hardware auf Vorrat einbauen und die Software je nach Bedarf anpassen.

So können Kunden neue Funktionen erhalten, wenn sie benötigt werden. Für die Auslieferung ist dann lediglich ein Softwareupdate nötig. Auch Telemetriedaten können so verfeinert werden und helfen die Maschine immer weiter zu verbessern. Die Auswertung der Telemetrie ist ein zusätzlicher möglicher Vorteil für Kunden.

Es gibt zu wenig Programmierer

Müssen jetzt alle Unternehmen Softwareabteilungen aufbauen, die ein Heer von Programmierern beschäftigen? Große Unternehmen gehen genau diesen Weg und entwickeln individuelle Software für das Kerngeschäft selbst. Auch Startups erarbeiten sich mit eigenen Softwarelösungen ihren Platz im Markt.

Wenn jedoch alle Unternehmen beginnen Softwareabteilungen aufzubauen, werden geeignete Bewerberinnen und Bewerber knapp und damit teuer. Die Auswirkungen sind bereits jetzt deutlich zu erkennen. Es ist zu erwarten, dass die Kosten für qualifiziertes Personal in den nächsten Jahren weiter steigen. Besonders kleine und mittelständische Unternehmen können dann möglicherweise bei der Digitalisierung abgehängt werden.

Analysten wie Gartner sehen in LowCode und No-Code Programmierung eine Möglichkeit, diesem Trend zu begegnen. Fachkräfte ohne Programmierkenntnisse sind damit in der Lage, einen großen Teil der täglichen Anforderungen selbst umzusetzen. Besonders die Übersetzung von Datenformaten und die Verbindung von Systemkomponenten sollte im täglichen Geschäft routinemäßig zu leisten sein.

Die nötigen Softwarekomponenten werden von Herstellern der Hardware geliefert oder von Dienstleistern entwickelt. Eine Plattform liefert Lösungen für Standardaufgaben. Die Entwicklung von Komponenten wird damit vereinfacht und so schneller und günstiger.

Digitale Souveränität

Bei der Auswahl einer geeigneten Plattform oder Anwendung sollte die eigene Digitale Souveränität an erster Stelle stehen. Es ist schließlich das Kerngeschäft, um das es geht. Mit der Zeit entstehen umfangreiche Systeme. Die Low-Code/No-Code Anwendung ist dabei der „Leim“ der die Komponenten des Systems miteinander verbindet. Hier entsteht leicht eine Abhängigkeit vom Softwareanbieter, die zum Problem werden kann, wenn sich zum Beispiel Firmenpolitik oder Lizenzbedingungen ändern.

Besonders mittelständische Unternehmen stoßen möglicherweise bei großen Herstellern auf Schwierigkeiten, die eigenen Anforderungen durchzusetzen. Quelloffene Lizenzmodelle bieten eine gute Alternative zum „Do It Yourself“ (DIY). Der Kontakt zur Community und die aktive Beteiligung hilft das Projekt im eigenen Sinn zu beeinflussen. Das erfordert Aufwand und Einsatz, der sich jedoch schnell auszahlt.

Digitale Transformation? Ja, bitte!

Wie DevOps ist auch Industrial DevOps nicht das Ziel, sondern der Weg. Unternehmen sind gefordert, sich dem Tempo der Marktveränderung anzupassen. Kontrolliert Fehler machen und daraus lernen, gehört ebenso dazu wie eine schonungslos realistische Wahrnehmung der inneren und äußeren Situation des eigenen Unternehmens. In einer komplexer werdenden Welt sind richtige Antworten schwer zu finden. Was für den einen richtig ist, kann für den anderen falsch sein.

Software liefert die nötigen Freiheitsgrade, schafft Verbindungen wo Verbindungen nötig sind und lässt sich schnell an neue Herausforderungen anpassen.

Für Entscheider ist es wichtig langfristige Ziele zu haben und diese nicht aus den Augen zu verlieren. Der Weg zum Ziel ist dabei keine gut durchgeplante Autobahn, sondern gleicht eher einer Expedition in unbekanntes Gebiet. Hier gibt es Überraschungen und Umwege aber auch Chancen, die erst offensichtlich werden, wenn bereits ein Stück des Weges zurückgelegt ist.

Digitale Unternehmen haben bereits gelernt mit komplexen Systemen und Herausforderungen umzugehen und ihnen mit Software zu begegnen.

Industrial DevOps soll dazu inspirieren über den Tellerrand zu schauen und die Leistungsfähigkeit moderner, verteilter IT-Systeme in produzierenden Unternehmen zu nutzen, Mehrwerte durch Software zu schaffen und Veränderung als Chance zu sehen.

Links

Digital transformation: online guide to digital business transformation; https://www.i-scoop.eu/digital-transformation/

Russell L. Ackoff; https://en.wikipedia.org/wiki/Russell_L._Ackoff

If Russ Ackoff had given a TED Talk…; https://youtu.be/OqEeIG8aPPk

What is BizDevOps?; https://enterprisersproject.com/article/2019/9/devops-what-is-bizdevops

Applying DevOps and Continuous Delivery to Significant Cyber-Physical Systems; https://itrevolution.com/book/industrial-devops/

Industrial DevOps; https://www.researchgate.net/publication/333062727_Industrial_DevOps

Was ist Embedded Software?; https://www.dev-insider.de/was-ist-embedded-software-a-579399/

Fog computing: decentralized approach for IoT clouds; https://www.ionos.com/digitalguide/server/know-how/fog-computing/

Why Smart Manufacturing?; https://spectrum.ieee.org/consumer-electronics/standards/why-smart-manufacturing

Weitere Referenzen

Erfolgreiches Management von Instabilität; Peter Kruse; GABAL Verlag GmbH

Lean Enterprise; Humble, Molesky, O’Reilly; 2014 O’Reilly Media, Inc.

Der Beitrag Digitale Transformation in der Produktion erschien zuerst auf Industrial DevOps.

Datenstrukturen dokumentieren

Maik Wojcieszak — Thu, 02 Jul 2020 12:00:01 +0000

Die titan Datenbeschreibungssprache UJO Schema erlaubt nicht nur die Beschreibung der eigentlichen Datenstruktur, sondern bietet auch Möglichkeiten umfangreich zu dokumentieren. So kann an einer Stelle die technische Beschreibung und die Dokumentation gepflegt werden, was es wesentlich erleichtert, beide auf einem aktuellen Stand zu halten.

Selbst wenn zu Beginn eines Projekts Datenstrukturen gut dokumentiert sind, wird dieser Aspekt mit der Zeit oft vernachlässigt. Wenn das passiert, passen die realen Daten mit der Zeit immer weniger zur Dokumentation. Um diese Lücken wieder zu schließen, sind aufwendige Analysen erforderlich. Was sich jemand beim Erstellen der Datenstruktur gedacht hat, ist so allerdings nicht mehr zu ermitteln und für immer verloren.

In den drei vorangegangenen Blogs Es sind die Daten, Dummchen, Typen gibt’s und Grenzen setzen wurde erklärt wie mit UJO Schema Datenstrukturen beschrieben werden. Auch wenn die dort gezeigten Beispiele relativ leicht verständlich sind, ist es sinnvoll Informationen hinzuzufügen, die zwar technisch keine Rolle spielen, aber für das Verständnis der Daten wichtig sind.

Das Folgende Beispiel zeigt einen Datentyp, der einen bestimmten Status als Zahlenwert darstellt.

status = int32
    : in (0 ,1, 2, 3 ,4);

Was die einzelnen Werte aussagen, oder wofür der Status verwendet wird ist nicht ersichtlich. Fügt man jedoch mit dem Schlüsselwort doc entsprechende Beschreibungen ein, wird klar, worum es dabei geht.

status = int32
    : in (
        0 : doc "offline",
        1 : doc "warten",
        2 : doc "daten empfangen",
        3 : doc "drucken",
        4 : doc "Fehler"
    )
: doc "Aktuelle Aktivität eines Druckers";

Jeder mit der Einschränkung in definierte Wert ist dokumentiert. Die Dokumentation des Datentyps status steht am Ende. So wird deutlich, wie die Werte interpretiert werden und welchen Zweck sie erfüllen.

So kann aus der rein technischen Beschreibung auch eine Online-Dokumentation generiert werden:

status

Aktuelle Aktivität eines Druckers

Identifier	Type	Constraints
status	int32	in Values

status in Values

Value	Description
0	offline
1	warten
2	daten empfangen
3	drucken
4	Fehler

Damit auch ausführlichere Texte gut lesbar zu formatieren sind, wird mit dreifachen Anführungszeichen """...""" über mehrere Zeilen dokumentiert. Dabei werden Markdown Formatierungen verwendet.

number = (int32, int64, float32, float64)
: doc """Zahlenwert im [__JSON__](https://www.json.org) Stil.  
Eine Aufstellung der verwendeten _Datentypen_ ist
[hier](https://www.geeksforgeeks.org/json-data-types/) zu finden.

__folgende Typen sind möglich:__

- string
- number
- boolean
- null
- object
- array
""";

Das Beispiel zeigt, wie einfach eine gut lesbare Dokumentation mit zusätzlichen Links angereichert wird. Übersetzt in eine Online-Dokumentation sieht es dann wie folgt aus:

number

Zahlenwert im JSON Stil. Eine Aufstellung der verwendeten Datentypen ist hier zu finden.

folgende Typen sind möglich:

string
number
boolean
null
object
array

Identifier	Type	Constraints
number	[int32, int64, float32, float64]

Records und Objekte dokumentieren

drucker = [
    drucker_id      =   string   : not null : doc "Eindeutige Bezeichnung der Maschine",
    drucker_status  =   status   : not null : doc "Maschinenstatus",
    drucker_online  =   int64               : doc "Sekunden online"
] : doc "Aktuelle Informationen des Druckers";

In diesem Beispiel wird der oben deklarierte Datentyp status verwendet. Beim Erzeugen der Dokumentation wird automatisch ein entsprechender Link erzeugt.

drucker

Aktuelle Informationen des Druckers.

Items:

Name	Type	Doc	Constraints
drucker_id	string	Eindeutige Bezeichnung der Maschine	[not null]
drucker_status	status	Maschinenstatus	[not null]
drucker_online	int64	Sekunden online

In gleicher Weise können die Druckerinformationen auch als Objekt beschrieben werden.

drucker = {
    "drucker_id"      ->   string   : not null : doc "Eindeutige Bezeichnung der Maschine",
    "drucker_status"  ->   status   : not null : doc "Maschinenstatus",
    "drucker_online"  ->   int64               : doc "Sekunden online"
 } : doc "Aktuelle Informationen des Druckers";

Fazit

So entsteht quasi nebenbei eine Dokumentation der Datenstrukturen zusammen mit der technischen Beschreibung für die automatische Prüfung von Daten. Die navigierbare, verlinkte HTML Version der Dokumentation lässt sich automatisch generieren und aktualisieren.

Interesse geweckt? – Bald gibt es mehr Infos zu titan. Folge uns auf Twitter @InDevOps_Titan

Hier findest Du das Projekt ujoschema-py

Titel Photo by Andrea Piacquadio from Pexels

Der Beitrag Datenstrukturen dokumentieren erschien zuerst auf Industrial DevOps.

Grenzen setzen

Maik Wojcieszak — Sat, 06 Jun 2020 11:57:08 +0000

Bei der Kommunikation zwischen Systemen und Systemkomponeten kommt es zu Fehlern. Häufig sind mehrdeutige oder falsche Daten die Ursache für diese Fehler. Die titan Datenbeschreibungssprache UJO Schema wurde bereits in den Blog-Beiträgen Es sind die Daten, Dummchen! und Typen gibt’s! vorgestellt. Dieser Beitrag erläutert wie man Daten mit UJO Schema eingrenzt, damit Fehler frühzeitig und automatisch erkannt werden.

Es lässt sich nicht ausschließen, dass Fehler in komplexen Systemen auftreten. Unser Ziel ist es also nicht Fehler grundsätzlich zu verhindern. Vielmehr wollen wir mit der strikten Typisierung in UJO Schema

Fehler so früh wie möglich erkennen.
die negativen Auswirkungen von Fehlern minimieren.
Die Fehleranalyse und Behebung erheblich vereinfachen und so die mittlere Zeit bis zur Behebung eines Fehlers (MTR – Mean Time to Repair) reduzieren.

In der Programmiersprache ADA wird die strikte Typisierung eingesetzt, um Mehrdeutigkeiten und Fehler durch unreflektierte Datenstrukturen zu minimieren. Da ADA für den Einsatz in militärischen Systemen entwickelt wurde ist die Notwendigkeit dafür sicher leicht nachvollziehbar.

A type is used to reason about the objects a program manipulates (an object is a variable or a constant). The aim is to classify objects by what you can accomplish with them (i.e., the operations that are permitted), and this way you can reason about the correctness of the objects’ values.
https://learn.adacore.com/courses/intro-to-ada/chapters/strongly_typed_language.html

Daten einschränken

Damit das gelingt werden Daten auf auschließlich gültige Werte eingeschränkt. Das titan-System kann so falsche Daten identifizieren, melden und die weitere Verarbeitung stoppen. Eine umständliche Fehlersuche entfällt. Werden Daten für die Steuerung von Aktoren wie zum Beispiel Motoren genutzt, hilft die Überprüfung sogar dabei Schäden durch falsche Daten zu verhindern.

mytype = int
    : 
    : 
    : <...>
    : ;

Das obere Beispiel zeigt, wie Einschränkungen einer Typdefinition angefügt werden.

Zahlen und Wertebereiche

Die wohl häufigste Einschränkung bezieht sich auf die möglichen Werte, die ein Datenfeld annehmen kann. Dabei werden entweder die Werte konkret angegeben oder Bereiche definiert. Das verwendete Schlüsselwort für diese Einschränkung ist in.

Definiert man in (1, 2, 3, 4) sind nur die angegeben Werte gültig. Die Festlegung in (1 .. 4) ist gleichwertig und legt fest, dass alle Werte von 1 bis 4 gültig sind. Manchmal möchte man nur den maximal oder minimal möglichen Wert angeben. Zum Beispiel legt in (.. 20) den maximal möglichen Wert auf 20 fest. Kleinere Werte sind uneigeschränkt erlaubt. Die Einschränkung in (-18 ..) legt den kleinsten möglichen Wert auf -18 fest.

Kombiniet man diese Möglichkeiten können in einer einzigen Einschränkung verschiedene gültige Wertebereiche und Werte festgelegt werden.

mytype = int32
    : in (.. -18, 1, 2, 3, 4, 10..15, 20..25, 50 ..);

Das Beispiel erlaubt Werte kleiner als -18 oder größer als 50, die festen Werte 1,2,3 und 4, Werte zwischen 10 und 15 sowie 20 und 25. Alle anderen Werte sind nicht erlaubt und führen zu Fehlern bei der Prüfung.

Natürlich können Werte und Wertebereiche auch für Fließkommazahlen (float) festgelegt werden.

constants = float32
    : in (2.71, 3.14, 9.81);

Das Beispiel erlaubt nur einige Konstanten aus Mathematik und Physik.

Auch wenn die Einschränkung in bereits eine sehr genaue Festlegung des Wertebereichs erlaubt ist es manchmal einfacher zu definieren was nicht enthalten sein soll. Um das zu erreichen die Einschränkung not in verwendet.

Zum Beispiel können für die Festlegung von Grad Celsius folgende Beschreibungen verwendet werden.

gradCelsiusA = float32
    : in (-273.15 ..);

gradCelsiusB = float32
    : not in (.. -273.15);

Worte, nichts als Worte

Mit der Einschränkung in werden auch für Texte gültige Wortlisten definiert. Für die Farbnamen in einem Kartenspiel würde zum Beispiel ein eingeschränkter Datentyp wie folgt beschrieben.

kartenFarben = string
    : in ("Herz", "Kreuz", "Pik", "Karo");

Für die Festlegung der Textlänge wird die Einschränkung length verwendet. Die Länge kann entweder als feste Anzahl Zeichen sein, variabel mit maximalen und minimalen Werten eingeschränkt werden. Die einschränkung length (.. 50) definiert eine maximale Länge von 50 Zeichen. Gibt man length ( 10 ..) an, müssen mindestend 10 Zeichen vorhanden sein. Mit length (10..50) sind mindestend 10 Zeichen erforderlich, aber maximal 50 möglich.

Listen einschränken

Wenden wir in und length auf Listen an, wirken sich die Einschränkungen auf alle Elemente der Liste aus. Es können sogar Texte und Zahlen kombiniert werden.

mixListe = (int32, string)*
    : in (1..20)
    : in ("Karo", "Herz", "Pik", "Kreuz")
    : length ( ..10 );

In dem Beispiel dürfen maximal 10 Elemente in einer Liste vorhanden sein. Die enthaltenen Texte werden auf die Kartenfarben festgelegt. Als Zahlenwerte sind nur 1 bis 20 zulässig.

Es ist zu beachten, dass die Einschränkung length sich hier nicht auf die Länge der Texte, sondern auf die Länge der Liste bezieht. Die Textlänge kann mit Hilfe eines weiteren eigenen Datentyps eingeschränkt werden, wie folgendes Beispiel zeigt.

shortText = string
    : length (..100);

mixListe = (int32, shortText)*
    : in (1..20)
    : in ("Herz", "Kreuz", "Pik", "Karo")
    : length ( ..10 );

Weniger als nichts

Grundsätzlich können Datenfelder beliebiger Typen undefiniert sein. Um diesen Zustand der Abwesenheit von Daten zu kennzeichnen wird das Schlüsselwort nullverwendet, damit der Unterschied zum Wert 0 klar erkennbar ist. Falls es erforderlich ist auf jeden Fall gültige Daten zu erzwingen, weil sonst ein unklarer Systemzustand entsteht, wird dies mit der Einschränkung not null erreicht.

Manchmal reicht es auch aus einen speziellen Wert zu setzen, wenn keine echten Daten vorhanden sind. Mit dem optionalen Schlüsselwort default kann dieser für die Einschränkung not null gesetzt werden. Das System kann dann automatisch nicht vorhandene Daten durch Defaultwerte ersetzen.

noNull = int32
    : not null default 0;

Das Beispiel zeigt einen Datentyp der immer Daten enthalten muss. Sollten keine Daten vorhanden sein wird der Wert 0 angenommen.

Fazit

Im titan Projekt prüfen wir die Anwendung von UJO Schema. Es hat sich bereits gezeigt, dass zukünftig noch weitere Einschränkungen den Umgang mit Daten erleichern könnten.

Reguläre Ausdrücke für Prüfungen, ob Textfelder korrekt formatiert sind und zum Beispiel eine E-Mail Adresse enthalten könnten, helfen die Korrektheit von Daten weiter zu verbessern.

Eine ebenfalls bereits diskutierte Idee ist die Verwendung von Einheiten für technische Werte. Besonders im Internet of Things (IoT) könnten klar definierte Einheiten ein System in die Lage versetzen automatische Konvertierungen und Umrechnungen vorzunehmen.

In meinem nächsten Blog geht es um die Verwendung von UJO Schema als Werzeug für die Dokumentation von Daten.

Interesse geweckt? – Bald gibt es mehr Infos zu titan. Folge uns auf Twitter @InDevOps_Titan

Hier findest Du das Projekt ujoschema-py

Der Beitrag Grenzen setzen erschien zuerst auf Industrial DevOps.

Typen gibt’s!

Maik Wojcieszak — Thu, 21 May 2020 11:53:38 +0000

In meinem letzten Blog Es sind die Daten, Dummchen habe ich die titan Datenbeschreibungssprache UJO Schema vorgestellt. Datenschema sind nicht nur für Datenbankexperten und Systemspezialisten wichtig. Jede Person, die direkt oder indirekt mit dem System arbeitet, sollte die Möglichkeit haben, sich ohne großen Aufwand über die verwendeten Datenstrukturen zu informieren. Nur durch das gemeinsame Verstehen kann ein System konsistent – über einen längeren Zeitraum, mit wechselnden Verantwortlichkeiten und verschiedenen Teams weiterentwickelt werden. Der Aufbau technischer Schuld durch Workarounds wird reduziert oder komplett vermieden und die Stabilität des Systems nicht gefährdet.

Für die Programmierung von Software gibt es statisch und dynamisch typisierte Sprachen. Letztere erlauben, zur Laufzeit beliebige Daten zu erzeugen, ohne ihre Struktur vorher festgelegt und beschrieben zu haben. So ist eine hohe Flexibilität möglich, die jedoch auch Probleme mit sich bringt.

Die Struktur der Daten wird oft nicht oder nicht ausreichend dokumentiert. Um aktuelle Datenstrukturen zu ermitteln, kommen dann reverse Engineering Methoden zum Einsatz. Diese reichen vom Betrachten der Daten selbst bis zur Analyse des Software Quellcodes. Heute werden dafür auch KI-basierte, automatische Analysen diskutiert. Diese Verfahren sind jedoch aufwendig und bei umfangreichen Daten potentiell lückenhaft.

Für titan haben wir uns daher entschieden, die Beschreibungssprache zu typisieren. Es gibt verschiedene Kategorien von Datentypen. Eine davon sind die grundlegenden, unteilbaren Typen. Diese atomaren Typen sind zum Beispiel Zahlenwerte, Texte oder binäre Daten wie Bilder. Eine vollständige Liste atomarer Typenist in der Dokumentation zu finden.

Die einfachste Form eines Schemas ist das Umbenennen eines atomaren Typen.

new_type = int64;

Daten stukturieren

Eine weitere Kategorie sind die zusammengesetzten Typen, die verschiedene unterschiedlichen Typen enthalten können und ihnen Struktur geben. Diese Containerkönnen kombiniert und verschachtelt werden. Komplexe Datenstrukturen lassen sich so als wiederverwendbare Module beschreiben.

Die Liste ist die einfachste Form eines Containers. Sie lässt sich leicht erzeugen, indem hinter den gewünschten Datentype ein * angegeben wird.

number_list = int64*;

Auf Elemente einer Liste wird über ihre Position oder ihren Index zugegriffen. Manchmal ist es jedoch besser, mit einem festgelegten Wert, einem Schlüssel, auf die Elemente zuzugreifen. Dafür kann ein so genanntes assoziatives Array verwendet werden. Das Schema für ein assoziatives Array erfordert die Festlegung des Schlüsseltyps und des Werttyps.

ages =  int32>;

Das Beispiel definiert ein assoziatives Array, das genutzt werden kann, um Namen von Personen mit deren Alter zu kombinieren.

Ein Modell der Welt

Listen und assoziativen Arrays reichen nicht aus, um reale Daten verständlich zu strukturieren. Wie kann man zum Beispiel eine Adresse beschreiben? Damit das funktioniert bietet UJO Schema Records und Objekte.

Records beschreiben eine feste Anzahl Elemente, die in einer bestimmten Reihenfolge strukturiert sind.

address = [
    Street      = string,
    No          = int32,
    ZIPCode     = string,
    City        = string
];

Ein Objekt definiert festgelegte Schlüssel für die einzelnen Elemente. So spielt die Reihenfolge keine Rolle und Elemente können weggelassen oder hinzugefügt werden. Die Schlüssel müssen jedoch bei der Datenübertragung und Speicherung berücksichtigt werden, was die Datenmenge vergrößert. Das spielt heute auf Servern vielleicht keine große Rolle, kann aber ein limitierender Faktor bei Anwendungen im Internet der Dinge (IoT) sein.

Das Adressbeispiel wird als Objekt wie folgt definiert:

address = {
    "Street"    -> string,
    "No"        -> int32,
    "ZIPCode"   -> string,
    "City"      -> string
];

Mehr Dynamik

Klar definierte Datentypen sorgen für Sicherheit und Planbarkeit, gehen jedoch auf Kosten der Flexibilität. Soll dynamisch auf Daten, die sich nicht klar definieren lassen, reagiert werden, bietet sich der Datentyp variant an. In einem als variant deklarierten Element sind alle unterstützten Datentypen erlaubt.

all_data = variant;

Der variante Typ sollte sparsam genutzt werden, damit keine Mehrdeutigkeiten entstehen wo sie vermieden werden sollten.

Atomare Typen schränken die möglichen Daten stark ein. Damit nicht immer, wenn diese Einschränkung zu streng ist, auf den Typ variant zurückgegriffen werden muss, können alternative Datentypen angegeben werden. Ist beispielsweise bekannt, dass die Daten in jedem Fall ein Zahl sind, kann dies wie folgt beschrieben werden:

number = (int32, int64, uint32, uint42, float32, float64);

Kombinieren und verschachteln

Beim Erstellen von Datenmodellen ist jetzt Kreativität gefragt. Wirklich mächtig wird ein Schema durch die Kombination von Elementen, Containern und die Wiederverwendung von Strukturen.

Zum Beispiel können Kundendaten durch die Wiederverwendung der bereits oben beschriebenen Adresse strukturiert werden:

person = [
    family_name     = string,
    given_names     = string,
    address         = address
];

company = [
    name            = string,
    address         = address,
    contacts        = person*
];

Für die Firmenadresse in company wird der gleiche address Typ benutzt wie für die person. Da in einer Firma verschiedene Personen arbeiten wird das Feld contactsmit einer Liste von Personen gefüllt.

Damit sind die Möglichkeiten, Datenstrukturen zu definieren, beschrieben. Im nächsten Blog erkläre ich, wie die Einschränkung von Datentypen funktioniert, damit automatisch auf Abweichungen reagiert werden kann.

Interesse geweckt? – Bald gibt es mehr Infos zu titan. Folge uns auf Twitter @InDevOps_Titan

Hier findest Du das Projekt ujoschema-py

Der Beitrag Typen gibt’s! erschien zuerst auf Industrial DevOps.

Daten als Schlüssel zur No-Code Programmierung

Maik Wojcieszak — Tue, 12 May 2020 10:40:35 +0000

Daten sind der Schlüssel zu No-Code Programmierung. Wenn Menschen ohne Programmierkenntnisse komplexe IT Probleme lösen, müssen sie die Daten im Griff haben.

Mit dem Slogan “It’s the economy, stupid!” (“Es ist die Wirtschaft, Dummerchen”), der von dem Wahlkampf Strategen James Carville geprägt wurde, gewann Bill Clinton 1992 die US-Präsidentschaftswahl. Platziert auf einem Schild im Hauptquartier in Little Rock hatten die Mitarbeiter diese Botschaft ständig vor Augen und konnten all die vielen, kleinen Entscheidungen, die notwendig waren, die Wahl zu gewinnen, daran ausrichten und messen.

“It’s the data, stupid!” (“Es sind die Daten, Dummerchen!“) ist der Leitsatz für das titan-Projekt. Vor allem anderen sind es die Daten, die wir im Griff haben müssen, damit wir eine kohärente Plattform für eine iterative Systemintegration schaffen.

Die Welt verändert sich

Im Zuge der Digitalisierung verändert sich die Systemlandschaft in Unternehmen. Spezialisierte Software-Werkzeuge, Maschinen und Systeme wurden bisher miteinander vernetzt, um z.B. Planungs- und Konstruktionsdaten oder statistische Daten auszutauschen. Diese geringfügige Vernetzung hat den Vorteil, dass Abhängigkeiten kein Problem darstellen, wenn ein Werkzeug durch ein anderes ersetzt wird oder eine Aktualisierung einer Software benötigt wird.

Heute steigt der Grad der Vernetzung der Systeme in Unternehmen und über Unternehmensgrenzen hinaus exponentiell. Abhängigkeiten sind auf einen Blick nicht mehr leicht erkennbar. So ein komplexes System kann nicht mehr einfach ausgetauscht werden. Wissen, das in die Automatisierung von Prozessen geflossen ist, ginge verloren.

Eine moderne Integrationsplattform wie titan muss daher in der Lage sein Komplexität beherrschbar zu machen und dabei gleichzeitig feste Abhängigkeiten zu spezialisierten Werkzeugen vermeiden. Offene Schnittstellen, leichte Anpassbarkeit und lose Kopplung sind dabei ebenso wichtig wie eine verständliche Darstellung der Daten.

Die einzige Quelle der Wahrheit

Es gibt eine Reihe von Möglichkeiten, Daten in einem System zu beschreiben. Dabei geht es sowohl um die Dokumentation, die leicht verständlich und aktuell sein muss, als auch um die technische Evaluierung und Anwendung der Datenbeschreibung.

Datenschema und automatisierte Generierung von Dokumentation gibt es für verschiedene technische Aspekte. Schnittstellen für Microservices werden mit RAML oder Swagger beschrieben, für XML gibt es XML Schema und DTD, für Datenbanken SQL und so weiter.

Da die titan-Plattform jedoch das Ziel hat unabhängig von bestimmten Technologien zu sein, war das keine Option. Wir benötigten eine Technologie-unabhängige Beschreibung der Daten, die leicht verständlich ist und trotzdem detailliert genug, damit technische Aspekte wie Datenmodelle automatisiert abgeleitet werden können. Schnittstellen und Datenmodelle in Datenbanken sollen mit den gleichen Begriffen definiert werden. Die Beschreibung der Daten dient sowohl den Menschen als Dokumentation, als auch dem System als einzige Quelle der Wahrheit. Nur so ist unserer Meinung nach über einen langen Zeitraum die Pflege des Systems möglich, ohne dabei mit jeder Änderung technische Schuld aufzubauen.

Die Abwärtsspirale

Technische Schuld entsteht leicht, wenn Systeme komplexer werden und nicht mehr leicht zu überblicken sind. Änderungen werden eingeführt, ohne vorhandene Abhängigkeiten und Konventionen zu beachten. Wird technische Schuld nicht erkannt und regelmäßig behoben, kommt es irgendwann zu immer häufigeren Störungen bis hin zum Systemversagen.

Vernetzte Systeme müssen jedoch sowohl regelmäßig angepasst werden als auch wachsen. Nur so können neue Anforderungen und Herausforderungen bewältigt werden. Die immer umfassendere Vernetzung von IT-Systemen führt zukünftig dazu, dass Managemententscheidungen immer häufiger Änderungen in IT-Systemen erfordern.

Divide et impera

Das Prinzip Teile und Herrsche wird auch auf die Methode, ein großes, übermächtiges und schwer beherrschbares Problem in viele kleine und übersichtliche zu zerlegen, angewendet.

Abb.1: Flow mit Bricks und Ports

In der titan-Plattform werden basierend darauf Prozesse mithilfe von Flows als Ablaufdiagramm dargestellt. Flows sind sowohl die technische Umsetzung eines Prozesses als auch dessen Dokumentation. Sie dienen dazu, Wissen über den Kontext zu transportieren, damit Menschen ohne IT-Hintergrund an Aspekten des Systems, die sie betreffen, konstruktiv mitarbeiten können. Flows wiederum bestehen aus Bricks, die miteinander verbunden werden. Ein Brick löst einen relativ kleinen Teilaspekt, auf den sich ein Programmierer bei der Konzeption konzentrieren kann. Der Teilaspekt sollte so klein sein, dass er leicht zu kommunizieren und zu verifizieren ist.

Daten, Daten, Daten

Abb.2: Schema und Umwandlungen

Zwischen den Bricks werden Datenpakete ausgetauscht. Diese Flow-Packets stellen ebenfalls einen Teilaspekt des Systems dar. Sie fließen durch das System und hinterlassen ihre Spuren, indem sie Aktionen, wie das Versenden von E-Mails oder das Einschalten eines Alarmsignals, steuern. Natürlich werden sie auch genutzt, um permanente Datenbestände aufzubauen oder zu verändern.

Für die Beschreibung der Daten wurde für die titan-Plattform eine eigene Schema-Sprache entwickelt, die speziell dafür optimiert und angepasst werden kann. Sie dient als Dokumentation der Daten wie auch als technische Implementierung.

Abb.2 zeigt, wie Module helfen Daten zu strukturieren und technische Teilaspekte abgeleitet werden.

Die titan-Plattform kümmert sich um die Details

Als Menschen sind wir nicht gut dafür gerüstet, alle Details eines komplexen Systems im Blick zu haben. Dafür nutzen wir heute Informationstechnologie und Software.

Damit die titan-Plattform optimal dabei unterstützen kann, sich um Details einer Änderung zu kümmern, werden Schemata eingesetzt. Zum Beispiel wird beim Verbinden von Bricks automatisch geprüft, ob die Ausgangsdaten des einen kompatibel mit den Eingangsdaten des anderen sind. Der Nutzer wird informiert, wenn es Konflikte gibt.

Bricks werden in verschiedenen Zusammenhängen in unterschiedlichen Flows eingesetzt. Durch die Beschreibung der Daten ist die titan-Plattform in der Lage, den Nutzer vor einem produktiven Einsatz zu informieren, wenn Änderungen Probleme verursachen würden.

Simulation und Test

Natürlich müssen Änderungen im System getestet werden. Integrierte Systeme zu testen ist ein Herausforderung, weil Daten systemspezifisch sind. Testdaten zu erzeugen und zu pflegen ist aufwendig. Das Schema hilft dabei, Testdaten automatisch zu erzeugen und neue Flows zu testen.

Wiederverwendbare Daten

Wie die Bricks werden auch Daten in Teilaspekten dargestellt. Es ist relativ leicht, eine Adresse zu definieren.

anschrift = [
    Strasse = string,
    Postleitzahl = number,
    Ort = string
] : doc "Globale Definition einer Adresse;

Wie die Adresse können Teilaspekte der Daten im System leicht beschrieben und wiederverwendet werden. Die Defintion einer Person mit einer Adresse könnte so aussehen:

person = [
    Vorname = string,
    Nachname = string,
    Alter = number,
    Adresse = anschrift
] : doc "Person mit Adresse";

Möchte ich einen Firmenkontakt beschreiben, der eine Liste von Personen und die Adresse des Unternehmens enthält, kombiniere ich wieder die entsprechenden Teilaspekte:

firma = [
    Firmenname = string,
    Firmenadresse = anschrift,
    Ansprechpartner = person*
] : doc "Firma mit Adresse und Ansprechpartnern";

Der * hinter person zeigt an, dass es sich um eine Liste handelt.

Jeder Teilaspekt, der beschrieben wird, ist für sich genommen keine große Herausforderung. Der Vorteil der Wiederverwendbarkeit ermöglicht es, dass Änderungen sich durch alle Teilaspekte propagieren. Die titan-Plattform kümmert sich dabei um die Details und zeigt an, wenn potentielle Probleme auftreten. Notwendige Änderungen werden durchgeführt, ohne Probleme im Betrieb befürchten zu müssen. Das System bleibt auf dem neuesten Stand.

Die Quelle der Wahrheit für alle

Für die Dokumentation kann ein Nutzer das Schlüsselwort doc verwenden, um zusätzliche Informationen anzufügen. Wird das Schema geändert, wird automatisch die Online-Dokumentation aktualisiert.

Das Schema kann in verschiedene technische Teilaspekte konvertiert werden. In der titan-Plattform wird beispielsweise eine binäre, kompakte Darstellung generiert, damit Schemata untereinander oder mit Daten in Echtzeit verglichen werden können (Abb.2). Zukünftig sollen auch andere Formate wie SQL Datenmodelle, XML Schema, JSON Schema und weitere erzeugt werden.

Die Abbildung zeigt, wie globale Datentypen in Teilaspekten der Daten eingesetzt werden. Aus diesem kompletten Datenmodell werden Teilaspekte in andere Darstellungen für unterschiedliche Zwecke konvertiert.

So entsteht eine unabhängige Beschreibung, die sowohl für die beteiligten Menschen wie auch für die titan-Plattform als Referenz und alleinige Quelle der Wahrheit dient.

Interesse geweckt? – Bald gibt es mehr Infos zu titan. Folge uns auf Twitter @InDevOps_Titan

Hier findest Du das Projekt ujoschema-py

Titel Photo by Markus Spiske from Pexels

Der Beitrag Daten als Schlüssel zur No-Code Programmierung erschien zuerst auf Industrial DevOps.

No-Code Process Mining

Manuel Wetzel — Tue, 18 Feb 2020 08:02:14 +0000

Eine heutige Fertigung und die damit verbundenen Prozesse unterliegen einem ständigen Wandel. Seien es neue Produkte, der Austausch einer Maschine oder lediglich die Umgestaltung der Produktion – viele Ursachen führen dazu, dass eine Fertigung immer wieder neu gestaltet werden muss.

Gleichzeitig ist es aber aus wirtschaftlichen Gesichtspunkten wichtig, die Prozesse zu kennen und Schwachstellen aufzudecken, um effizient zu arbeiten und Qualität sicherzustellen.

Was ist Process Mining und wo liegen seine Herausforderungen?

Diesem Thema widmet sich das immer populärer werdende Gebiet des Process Minings. Das Ziel ist es, aus den Daten, die ein Produktionssystem generiert, automatisch das zugehörige Geschäftsprozessmodell zu generieren. So werden ähnlich zum verwandten Data Mining aus den großen Datenströmen prozessbasierte Informationen abgeleitet. Die Vorteile liegen auf der Hand: man entdeckt die wahren Prozesse im Unternehmen und nicht nur diejenigen, die der Prozessmanager in einem Meeting modelliert hat. Außerdem können die Prozesse mit diesen Informationen und weiteren Indikatoren zur Prozessgüte auf Schwachstellen analysiert werden.

Hierfür muss natürlich die Datengrundlage (das sogenannte Event-Log) gewissen Standards genügen und zumindest die folgenden Punkte enthalten:

Was wurde gemacht?
Wann wurde es gemacht?
Für welchen Auftrag wurde es gemacht?

Zeit	Aufgabe	Auftrag	Bearbeiter
12-02-2020-11-37-56	Beginn Endmontage	IS-2193	Monteur1
12-02-2020-11-51-44	Ende Endmontage	IS-2193	Monteur1

So sieht der Event Log aus. Er beinhaltet Zeitstempel, Bezug zu Auftrag und die durchgeführte Tätigkeit. Diese Informationen können um beliebilge Spalten erweitert werden, je nachdem welche Frage analysiert werden soll. Der Event Log bildet den Input und die Grundlage für jeden Process Mining Algorithmus.

Quelle: titan Projekt Creative Commons CCBY-SA4.0

Genau hier liegt die größte Herausforderung von Process Mining. Die Daten, die ein Produktionssystem generiert, sind nicht standardisiert, nicht alle Arbeitsschritte werden technisch erfasst und nicht alle Informationsquellen können einbezogen werden. Die Folge ist massive manuelle Nacharbeit und die damit einhergehende Unschärfe der Ergebnisse. So muss zum Beispiel bei einem fehlenden Zeitstempel ein chronologisch korrekter Zeitpunkt geraten werden, eine spätere zeitliche Analyse wird damit aber unbrauchbar. Außerdem wird Process Mining hauptsächlich rückwirkend für vergangene Zeiträume durchgeführt. Das Potential von der Prozessinformationen wird so nicht ausgeschöpft.

Unser Ziel: ein automatisch generiertes Prozessmodell, das den realen Prozess abbildet.

Process Mining ohne Prgrammieren

An dieser Stelle kommt nun titan ins Spiel. Mit einem Flow können verschiedene Informationsquellen integriert und miteinander verbunden werden. Dies könnte beispielsweise ein MES (Manufacturing Execution System) oder ein ERP (Enterprise Resource Planning) System sein. Es können aber auch individuell integrierte Sensoren einbezogen werden. Ein Arbeitsplatz, dessen Tätigkeiten bisher nicht erfasst wurden, kann somit modular mit einem Barcode-Scanner oder RFID Sensor ausgestattet werden. Durch unseren No-Code-Ansatz ist die konkrete Umsetzung schnell austauschbar und erweiterbar. Man würde lediglich vorhandene Bricks mit neuer Adresse in den Flow einbinden. Die starken Änderungen, denen eine Fertigung zwangsläufig unterliegt, können also mit geringem Änderungsaufwand auch in den Flow einbezogen werden. Das Ergebnis ist also eine perfekt aufgearbeitete Ereignis-Datenbank (sogenanntes Event-Log), die es Process Mining ermöglicht, automatisch ein Prozessmodell zu generieren.

Neben der Datenaufarbeitung für eine spätere Analyse und dem Finden von Verbesserungsmöglichkeiten bietet Process Mining aber auch noch einen weiteren praktischen Nutzen. Wenn einmal ein Prozessmodell vorliegt, kann nun für einen neu abgeschlossenen Auftrag überprüft werden, inwiefern dieser dem Standard-Ablauf entspricht oder wo besonders große Abweichungen auftreten (sogenanntes Conformance Checking).

Auch hier kann die leichte Anpassungsfähigkeit und Individualisierbarkeit von titan helfen. Man kann sich vorstellen, dass einzelne Verantwortliche benachrichtigt werden möchten, wenn sich rausstellt, dass zu viele Aufträge abweichend von der Norm bearbeitet werden. Diese Alarme, Benachrichtigungen und Fragestellungen sind aber eben auch sehr firmenindividuell. Je nach Schwellwerten, Parametern oder Aktionen müssen für die Weiterverarbeitung der Auswertung die Bricks nur angepasst und neu verbunden werden.

Schlussendlich adressiert titan auch ein gravierendes Problem der personenbezogenen Daten. Grundsätzlich ist bei der Prozessanalyse interessant, wie lange welche Arbeitsstelle an welchem Auftrag gearbeitet hat. Aus diesen Daten lassen sich aber schnell Rückschlüsse auf die Produktivität einzelner Mitarbeiter ziehen. In manchen Fällen mag dies erwünscht sein, z.B. um in Echtzeit Überlastungen festzustellen und schnell entgegenwirken zu können. Diese Daten sollten allerdings nicht zur späteren Performance-Bewertung zweckentfremdet werden. Hier kann titan durch einzelne Anonymisierungs-Bricks an genau den richtigen Stellen dafür sorgen, dass personenbezogene Daten abgeschnitten werden und gar nicht erst weitergeleitet und gespeichert werden. Auch hier sind die Anforderungen sehr individuell je Firma und Prozess. Titan ermöglicht es, in den Dialog mit Betriebsrat und Datenschützern zu gehen und deren Anforderungen selbst mit dem No-Code Ansatz gerecht zu werden.

Anpassbare Datenauswertung in Echtzeit

Eine Fertigung und die damit verbundenen Prozess unterliegen ständigem Wandel. Gleichzeitig ist es aber wichtig, die Prozesse zu kennen und zu verbessern. Die Werkzeuge des Process Mining können verschiedenste Fragen rund um Prozesse beantworten, brauchen dafür aber eine gute Datenbasis.

Titan bietet mit seinem No-Code-Ansatz die Möglichkeit individuell und vor allem anpassbar die Daten zu sammeln und bereitzustellen. Die Wiederverwendbarkeit von Bricks ermöglicht es, dies sehr wirtschaftlich und effizient zu tun. Die Datenzusammenstellung wird sich immer ändern, seien es neue Zusammenhänge, die analysiert werden sollen oder einfach neue manuelle Arbeitsplätze, die eingebunden werden sollen. Der Schlüssel zum Erfolg mit Process Mining ist ein anpassbares Auswerten der Daten in Echtzeit.

In diesem Sinne möchte ich mit einem Zitat vom Process Mining Papst Will Van der Aalst schließen:

“It is the Process and the Data, Stupid!”

Weitere Informationen zu Process Mining

Der Beitrag No-Code Process Mining erschien zuerst auf Industrial DevOps.