Ein Reifegradmodell zur Einstufung eines DWH Deployments

Es gibt eine Vielzahl von Reifegradmodellen, die diverse Aspekte in der Entwicklung in Reifegrade unterteilen. Zum jetzigen Zeitpunkt exisitiert, jedoch kein Reifegradmodell, dass die Reife eines DWH Deployments bestimmt. Innerhalb meiner Bachelorthesis habe ich mich diesem Thema gewidmet und das Deployment eines DWH in Reifegrade unterteilt. Dabei habe ich mich ausschließlich auf ein agiles Deployment durch die Umsetzung von Continuous Delivery (CD) fokussiert.

Neue Anforderungen schneller dem Kunden zur Verfügung zu stellen, wird im Zuge der Digitalisierung wichtiger. Um dies zu erreichen, lassen sich agile Methoden im Umfeld der Entwicklung eines DWH adaptieren. Dabei liegt der Fokus des Modells darauf, wie bei steigenden Reifegrad die Umsetzung von CD voranschreitet. Es wird darauf eingegangen, warum man Continuous Delivery auf eine datengetriebene Entwicklung anwenden kann.

Das Modell basiert zum Teil auf existierenden Modellen und bündelt weitere Aspekte, um die Anforderungen beim Deployment eines neuen Releases zu berücksichtigen. Der Aufbau des Modells orientiert sich an dem Capability Maturity Model. Das CMM ist ein Reifegradmodell zur Beurteilung der Qualität von Softwareprozessen, welches bereits in den verschiedensten Varianten existiert.

Das Reifegradmodell stellt einen umfassenden Blick auf diese Problematik dar. Neben den technischen Voraussetzungen werden auch die Prozesse und der Mindset der Organisation betrachtet. Insbesondere die Zusammenarbeit zwischen den Fachbereich, den Entwicklern und der IT während des gesamten Entwicklungszyklus wird akzentuiert. Des Weiteren wird das Konzept des BICC in dem Modell berücksichtigt. Im ersten Reifegrad wird eine Organisation skizziert, dessen Deployment fehleranfällig und unzuverlässig ist, wohingegen eine Organisation im fünften Reifegrad durch die Umsetzung von CD und DevOps   das Deployment verbessert.

Veröffentlicht unter Analytics & BigData | Kommentar hinterlassen

Alexa, frag Opitz! Entwicklung eines Alexa Skills

Auf der InspireIT sprachen Besucher bereits mit der ersten Version unseres Alexa Skills. Dieser Chatbot erklärt dem interessierten Nutzer das OC Wimmelbild. Doch beginnen wir von vorne.

Echo_Dot

Weiterlesen

Veröffentlicht unter IoT & Industry 4.0, Software Engineering, OC Inside | Verschlagwortet mit , , , , | Kommentar hinterlassen

MQTT – Eine Einführung in weniger als 345 Worten

MQTT[1] (Message Queue Telemetry Transport) hat sich in den letzten Jahren zu einem wichtigen Nachrichtenprotokoll im Bereich IoT durchgesetzt. Mit ihm werden Informationen leichtgewichtig nach dem Publish-Subscribe Pattern übermittelt. Gerade bei einem hohen Nachrichtenaufkommen kann eine Broker-Architektur von Nutzen sein. Mit ihr werden periodische Abfragen von Nachrichten nach dem „Request-Reply“ Muster vermieden.
Das ist einer der Gründe, warum die IoT-Plattformen der großen Anbieter Oracle, Microsoft und Amazon dieses Protokoll unterstützen. Auch mit den Ansätzen im IoT-Umfeld passt es gut zusammen, Zustandsänderungen und damit Events/Ereignisse zu kommunizieren.

MQTT

Abbildung 1: Architektur

Im Zentrum der Kommunikation steht ein Server („Broker“), der Nachrichten sammelt und verteilt. Mit ihm verbinden sich „Clients“ und veröffentlichen Nachrichten bzw. abonnieren sie zu einem bestimmten Thema („Topic“). Der Broker nimmt die Nachrichten entgegen und verschickt sie automatisch („push“) an die Clients, die das Topic abonniert haben.

Topics werden hierarchisch aufgebaut und mit einem „/“ getrennt.
Beispiel: /Wohnung/Wohnzimmer/Heizung/Temperatur. Um mehrere Topics zu einer Ebene zu abonnieren, gibt es Wildcards. Mittels „+“ wird eine Ebene abonniert, über „#“ können mehrere Ebenen abonniert werden.  /Wohnung/+/Heizung/Temperatur abonniert beispielsweise die Heizungstemperatur in allen Zimmern, /Wohnung/Badezimmer/# alle Badezimmerdaten.

Über die Quality of Service kann jeder Client festlegen, in welchem Umfang die Nachrichtenübertragung garantiert werden soll. Das reicht von maximal ein Mal (Level 0) über mindestens ein Mal (Level 1) zu genau ein Mal (Level 2). Je höher der Level ist, desto mehr Daten müssen für die Sicherstellung des Levels gesendet werden.

Die Verfügbarkeit IoT-fähiger Geräte kann stark schwanken. Beispielsweise können Straßenbahnen die Verbindung zur Zentrale verlieren, wenn sie in einen Tunnel fahren. In diesem Fall kann der Client beim Broker eine Nachricht hinterlegen, die bei einem Verbindungsabbruch gesendet wird. Dies wird als „Last Will and Testament“ bezeichnet. Im Fall der Straßenbahn könnte das die letzte ermittelte Position sein.

Damit Clients bei einem neu abonnierten Topic  nicht darauf warten müssen, bis ein neuer Wert gepusht wird, kann die zuletzt gesendete Nachricht standardmäßig an den neuen Abonnenten verschickt werden.  Nachrichten, die vom Client dafür markiert wurden, werden „Retained Messages“ genannt.

[1] http://mqtt.org/

Veröffentlicht unter IoT & Industry 4.0 | Kommentar hinterlassen

„Digital Transformation – Behind the Scenes“ – Das war die inspire|IT 2017

Unter dem Motto „Digital Transformation  – Behind the Scenes“ fand vom 03. bis 04. April 2017 die 4. Ausgabe unserer Best-Practices-Konferenz inspire|IT in Frankfurt statt. Jetzt können wir wirklich schon von einer Tradition sprechen. Zwei Tage mit unterschiedlichen Tracks und Hands-on waren voll gepackt mit Informationen, Vorträgen und Demonstrationen und ganz vielen informativen Gesprächen. Zur Eröffnung gab es eine spannenden Keynote von Tom Gansor über digitalen Pragmatismus (einfach mal machen!).  Die einzelnen Thementracks am ersten Tag beschäftigten sich mit Development & Mensch Maschine Interaktion sowie Business Insights und Big Data. Nach einem spannenden ersten Tag, stand dem ersten Bier nur noch eine weitere Keynote im Weg. Die Abstinenz hat sich nach einhelliger Meinung mehr als gelohnt: Robert Schröder, Check Pilot und Mitglied der Flugunfalluntersuchungskommission der Lufthansa, referierte zur Entwicklung der Fehlerkultur in der Luftfahrt und zeigte, was wir für unseren Berufsalltag daraus lernen können. In einer sehr unterhaltsamen, kurzweiligen und authentischen Art berichtetet Schröder aus mehr als 25 Jahren Erfahrung und regte diverse Male zum Nachdenken an.

Mehr als 90 Teilnehmer blieben zum anschließenden Networking Dinner, wo bei exzellenter Küche und gutem Wein oder gepflegtem Bier noch lebhaft weiter diskutiert wurde. Der intensive und inzwischen informelle Austausch wurde danach an der Hotelbar ausgiebig weitergeführt.
inspireIT
Der zweite Tag startete mit den zwei Workshops Multi-Cloud-Strategie und Design Thinking. Trotz des aktiven Networking am Vorabend, wurde hier schon wieder sehr intensiv diskutiert. Nach den Workshops ging es in den Tracks Infrastruktur & Cloud sowie IoT & Integration of Everything weiter. Die Veranstaltung endete mit einem Denkanstoß von Rolf Scheuch in seiner Keynote „Die Digitalisierung frisst Ihre Kinder“. Das Programm war insgesamt sehr praxisbezogen und hatte viele spannende Highlights mit konkreten Beiträgen unter anderem von ista, Mercedes Benz Vans, innogy, F.A.Z, Securitas, TH Mittelhessen, Duale Hochschule BaWü und einigen mehr. In einem parallelen Side-Track boten wir zusätzlich an beiden Tagen einen Hands-On-Cloud-Workshop mit Oracle an.

Auch das OC|Lab war in einer Abordnung vertreten und  hat in den Pausenzeiten spannende Use Cases vorgestellt. Neben der Demonstration von Chat Bot Möglichkeiten auf Basis von Amazon Alexa und oder einem Augmented Reality Projekt auf Basis von Google Tango war die Microsoft HoloLens ein echtes Highlight. Hiermit lies sich die über Q-loud ins Internet eingebundene Industriemaschine steuern.

Wir freuen uns, dass wir von allen Seiten sehr viel positives Feedback zum Programm und zur Organisation der inspire|IT bekommen haben. Im vierten Jahr hat sich die Veranstaltung zu einer festen Größe im jährlichen Eventkalender etabliert, mit rund 140 Teilnehmern war es der bislang erfolgreichste Event und eine gute Basis für die Zukunft. 2018 kann kommen.

Veröffentlicht unter Analytics & BigData, BPM & System Integration, Cloud & Infrastructure, IoT & Industry 4.0, News, OC Inside | Verschlagwortet mit , , , , | Kommentar hinterlassen

Apache Lucene Basics

Wollten Sie nicht immer schon mal wissen, was im Hintergrund einer Suchmaschine abläuft. Warum sind Search Engines so schnell? Wie lautet der Such-Algorithmus von Google?

Vielleicht können wir wenigstens eine dieser beiden Fragen klären. Google hütet sein Geheimnis gut, aber wer z. B. auch alternative Suchmaschinen wie DuckDuckGo kennt, der kann hier einmal hinter die Kulissen schauen. Denn DuckDuckGo funktioniert mit der Suchmaschinen-API Lucene.

Apache Lucene ist eine hochperformante Suchmaschinen-Bibliothek, die komplett in Java geschrieben ist. Wer direkt in die Tiefen der API eintauchen will, kann sich das Projekt von der Homepage runterladen und in den Quellcode reinschnuppern: Apache Lucene.

Wer aber nur ein grobes Verständnis über die Technologie dahinter erhalten möchte, kann sich den Einstieg auch mit diesem Artikel erleichtern:

Abgrenzung zu Solr und Elastic Search

Bekannte Suchmaschinen im Bereich Big Data oder Software Engineering sind Elastic Search und Solr. Wie passt hier Lucene rein? Nun, Lucene ist einfach formuliert die Basis für das, was unter der Haube passiert. Sowohl Elastic Search als auch Solr bauen auf Lucene auf und bieten dem Anwender einen einfachen Zugang zu einer Bibliothek, in Form von Webschnittstellen und fertigen Implementierungen verschiedener Anwendungsfälle.

Lucene wird für das Erstellen und Verwalten des Such-Indexes verwendet, der erst einmal nicht mehr ist als ein Dokumentenspeicher. Für eine erfolgreiche Volltextsuche braucht es aber doch noch etwas mehr. Schauen wir uns dazu einmal die grundlegenden Probleme bei einer Volltextsuche anhand von relationalen Datenbanken an:

Was ist ein Index?

Jeder hat vermutlich schon einmal den Satz gehört: „Die Datenbank ist etwas langsam, wir sollten Indizes verwenden“. Was steckt denn eigentlich hinter diesen Indizes?

Die Antwort ist einfach: Sie machen die Suche auf der Datenbank schneller. Interessant ist aber das Warum.

Werfen wir einen Blick in eine ganz normale Datenbanktabelle einer relationalen Datenbank wie der Oracle DB:

ID SURNAME NAME ADDRESS TEL_NUMBER
1 Smith John Groove Street 5551
2 Gardner Hellen Any Town 5552
3 Lambert Zachariah First Street 5553

Hier sehen wir erst einmal nichts Besonderes. Wir führen ein klassisches Select-Statement aus: SELECT * FROM TABLE WHERE NAME=’John‘. Was jetzt intern passiert, ist, dass die Datenbank die Spalte NAME durchsucht und uns alle Treffer in einem Result Set zurückgibt. Da die Datenbank selbst aber nicht weiß, wie viele Johns es in der Tabelle gibt, muss sie wohl oder übel alle Einträge überprüfen. Denn selbst wenn sie, wie in unserem Fall, direkt im ersten Eintrag schon einen Treffer hat, gibt es keine Garantie, dass es nicht weiter unten noch einen John gibt. Versteht sich von selbst, dass dieses Vorgehen nicht besonders performant sein kann. Vor allem dann nicht, wenn wir 1.000.000 Einträge durchsuchen müssten. Wir legen nun einen Index über die Spalte NAME, was zur Folge hat, dass die Datenbank eine zweite Tabelle anlegt:

NAME RECORD_POINTER
Hellen 0 … 0xffffffff
John 0 … 0xffffffff
John 0 … 0xffffffff
Zachariah 0 … 0xffffffff

In dieser Tabelle sind die Einträge anhand des Namens sortiert. Die zweite Spalte RECORD_POINTER ist ein Pointer auf den Eintrag in der Haupttabelle. Wenn wir jetzt wieder nach dem Namen John suchen, durchsucht die Datenbank diese Tabelle, findet den Eintrag John, fügt den Eintrag in das Result Set (über den Pointer kann der echte Eintrag in der Haupttabelle referenziert werden) und schaut in der nächsten Reihe nach. Bei einem weiteren Treffer kommt auch dieser Eintrag in das Result Set, bis es keine weiteren Treffer mehr gibt. Das passiert, wenn der nächste Eintrag Zachariah lautet. Diesmal steht aber fest, dass es keine weiteren Johns mehr in der Tabelle gibt und es muss nicht weiter gesucht werden.

Der Vollständigkeit halber sollte noch erwähnt werden, dass die Einträge in einer Tabelle standardmäßig anhand des Primary Keys sortiert werden und dieser somit automatisch einen Index hat.

Für alle weiteren Indizes wird eine neue kleine Tabelle angelegt. Man kann sich natürlich ausmalen, wie sinnvoll das Ganze für eine Volltextsuche ist, nämlich gar nicht. Wenn man in einem Feld nun nicht einfach einen Namen, sondern ein ganzes Textdokument ablegt und möchte dann herausfinden ob Schlagwort „X“ darin vorkommt, dann helfen die Indizes der Datenbank nicht weiter. Ihr bleibt dann nichts anderes übrig, als einen Full Table Scan durchzuführen.

Was macht Lucene anders?

Lucene ist eine NoSQL-Datenbank bzw. ein Dokumentenspeicher. Es nutzt keine relationalen Tabellen, aber trotzdem existiert auch in Lucene ein Index, der einer Datenbanktabelle recht nah kommt. In diesem Index werden aber nicht ganze Texte gespeichert mit dem Verweis zu welchem Dokument sie gehören, sondern sogenannte Tokens. Ein Token kann ein einzelnes Wort sein, eine E-Mail-Adresse oder eine Telefonnummer. Im Prinzip besteht ein Text aus mehreren Tokens. Damit man einen größeren Text effizient durchsuchen kann, muss er vorher in Tokens zerlegt werden. Bei Lucene heißt dieser Prozess Analyze. Folgendes Schaubild soll den Prozess verdeutlichen:

LuceneAnalyzeProzess

Hangeln wir uns einmal kurz durch die drei Schritte:

Tokenizer

Der Tokenizer zerlegt den Text in einzelne Wörter. In der Praxis gibt es natürlich verschiedene Implementierungen für den Tokenizer. Manche werden von Lucene mitgeliefert, man kann sie aber auch selbst implementieren. Solr und Elastic Search bieten selbst noch ein paar weitere Implementierungen an. Sollte man also nicht vorhaben das „nackte“ Lucene direkt zu verwenden, braucht man sich um diesen Schritt, in einfachen Anwendungsfällen, eigentlich keine großen Sorgen machen. Wichtig ist nur zu wissen, dass der Tokenizer den Text in kleine Einheiten zerlegt, die in der Regel ein Wort beinhalten.

Stemmer

Der Stemmer bringt Wörter in seine Grundform. Dass heißt aus Wörtern wie „ging“, „Hauses“, „Bäume“ wird „gehen“, „Haus“, „Baum“. Das ist wichtig, weil man bei einer Suche nach dem Wort „Baum“ vielleicht auch Treffer haben möchte in denen das Wort Bäume vorkommt.

Filter

Der Filter entfernt unbrauchbare Wörter wie Konjunktionen, Präpositionen, Artikel etc. Wer bei einer Suchmaschine einfach das Wort „und“ sucht, sollte sich sowieso nicht auf zutreffende Ergebnisse freuen, warum das ganze also speichern. Der Filter kann natürlich auch angepasst werden. Z.B. könnte es ja eventuell doch Sinn haben, bei einer Filmdatenbank das Wort „der“ nicht rauszufiltern, um Treffer wie „Der Fluch der Karibik“ trotzdem zu bekommen.

Wir veranschaulichen das ganze noch einmal:

LuceneAnalyzeExample

Der Text wurde nun in 6 Tokens zerlegt. Diese Tokens werden in Lucene in einem sogenannten Inverted Index gespeichert.

Inverted Index

Der Begriff Inverted Index sorgt manchmal für ein wenig Verwirrung, weil er oft ohne den Kontext dahinter verwendet wird. Grundsätzlich unterscheidet man im Kontext von Suchmaschinen einfach zwei Arten von Indizes. Einmal den Forwarded Index und zum anderen den Inverted Index. Der Forwarded Index ist eine Tabelle, in der alle Dokumente in der linken Spalte stehen und in der rechten Spalte die zugehörigen Tokens. Bei einem Inverted Index stehen in der linken Spalte die Tokens und in der rechten Spalte alle Dokumente, in denen diese Tokens vorkommen.

Eine einfache Darstellung haben wir hier:

ForwardedVSInvertedIndex

Der Vorteil entsteht dadurch, dass die Tokens eigentlich genau den Schlagworten in einer Suche entsprechen. Wenn wir jetzt nach dem Wort [brown] suchen, bekommen wir direkt alle Dokumente geliefert, die das Wort [brown] enthalten. Dadurch, dass der Index anhand der Tokens sortiert ist, muss nicht der gesamte Index durchsucht werden, was sich positiv auf die Performance auswirkt.

Halt, war Lucene nicht ein Dokumentenspeicher?

Ja, richtig. Wie am Anfang dieses Artikels erwähnt, handelt es sich bei dem Index auch um einen Dokumentenspeicher. Insgesamt besteht der Index aus mehreren Dateien, die direkt auf der Platte oder gar in einem Hadoop HDFS abgelegt werden. In diesen Dateien finden sich vielerlei Informationen, neben dem Inverted Index liegen hier aber auch die Dokumente. Ein Dokument in Lucene besteht aus mehreren Feldern, die wiederum aus Keys und Values bestehen. Zur Veranschaulichung hier ein Dokument im JSON Format:

{
„title“:“buying a house“,
„author“:“james gumberfield“,
„price“:“15$“
„text“:“some content“

}

Die Values in diesem Dokument werden beim Indexieren durch den Analyze-Prozess in Tokens zerlegt. Lucene merkt sich aber natürlich, zu welchem Feld diese Tokens gehören. Über den Inverted Index können diese dann nach potenziellen Treffern durchsucht werden und die Dokumente, die diese Tokens enthalten, werden als Ergebnis zurückgeliefert.

Suchen auf dem Lucene Index

Lucene bietet eine eigene Query-Struktur an, mit der man Suchanfragen ausführen kann. Die Suche erfolgt immer in den Werten der Felder, also z. B. im Feld Title wird nach dem Wort Buying gesucht. Die Query dazu würde so aussehen:

title:buying

Also Feldname gefolgt von einem : und anschließend der Suchterm buying. Gibt man keinen Feldname an, wird im Default-Feld gesucht. Das Default-Feld ist implementierungsabhängig.

Gehen wir in unserem Beispiel davon aus, dass wir die Felder title und text haben. Eine Suche mit einem einzelnen Wort haben wir bereits gesehen, doch wie sieht es mit einer Wortphrase aus?

Dabei muss man lediglich daran denken, die Phrase in Anführungszeichen zu setzen:

title:"buying a house"

Würde man folgende Suche ausführen …

title:buying a house

… würde Lucene nach dem Wort buying im Feld title suchen und anschließend nach den Wörtern a und house im Default-Feld. Die Suchen können mithilfe von Booleschen Operatoren verknüpft werden:

OR

Der OR Operator ist der Default-Wert. Das heißt, wenn kein Operator zwischen zwei Termen steht, dann wird automatisch OR genutzt:

Finde alle Dokumente mit "buying" im Feld title oder "house" im Default-Feld.

title:buying OR house

AND

Finde alle Dokumente mit den Wörtern "buying" und "house" im Feld title.

title:buying AND title:house

NOT

Finde alle Dokumente mit den Wörtern "new house" und nicht "new home" im Feld title.

title:"new house" NOT title:"new home"

Beim NOT Operator müssen mindestens zwei Suchterme eingegeben werden, sonst bleibt das Ergebnis leer.

+

Der „+“ Operator setzt den darauffolgenden Term auf required.

+house

Findet Dokumente die das Wort „house“ enthalten.

Der + Operator kann auch als Äquivalent zu AND verwendet werden, wenn man Folgendes schreibt:

+house +home

„-“ ist der Gegenpart von „+“ (welch eine Überraschung ;-)) und verbietet den folgenden Term in der Ergebnismenge:

+house -home

Das Ergebnis ist identisch mit dem NOT Operator, allerdings kann „-“ auch mit nur einem Suchterm verwendet werden.

Wildcards

Wildcards werden ebenfalls unterstützt mit den Operatoren „?“ und „*“. Der Unterschied ist, das „?“ für einzelne Zeichen und „*“ für mehrere gilt.

te?t

Findet z.B. test und text.

Wohn*

Findet wohnen, wohnung, wohnheim etc.

Fuzzy search

Lucene unterstützt auch eine unscharfe Suche mit dem „~“ Operator.

house~

… findet ähnliche Wörter wie „house“. Optional kann man über eine Zahl zwischen 0 und 1 einen Faktor bestimmen, der den Grad der Ähnlichkeit der Wörter angibt.

house~0.8

Standardmäßig wird der Faktor 0.5 verwendet.

Boosting

man kann einzelnen Suchtermen unterschiedliche Prioritäten einräumen. Der Operator „^“, gefolgt von einer positiven Zahl, beeinflusst die Reihenfolge der Ergebnisliste. Die Zahl kann auch kleiner als 1 sein (0.8 z.B.).

house^4 home 

… findet alle Dokumente, die die Wörter „house“ und „home“ beinhalten. Die Treffer mit „house“ erhalten eine höhere Priorität und werden am Anfang der Ergebnismenge zurückgegeben.

Grouping

Mit Klammern kann man einzelne Suchkommandos zusammenfassen

(house OR home) AND new

Range search

Eine Bereichssuche kann mit den Operatoren „[ ]“ und „{ }“ erfolgen, wobei die Suche mit „[]“ die Randwerte mit einschließt, „{ }“ schließt diese hingegen aus.

date:[01012017 TO 01052017]

… findet alle Einträge zwischen und inklusive dem 01.01.2017 und dem 01.05.2017.

title:{A TO Z}

… findet alle Einträge zwischen A – Z wobei A und Z nicht in der Ergebnismenge enthalten sind.

Dies waren die wichtigsten Operatoren im Überblick. Die gesamte Doku dazu, befindet sich hier.

Fazit

Lucene ist ausgereift und robust. Man kann es ohne schlechtes Gewissen in der Produktion einsetzen. In der Praxis werden aber meist Elastic Search und Solr genutzt. Beide Technologien haben Lucene auf den nächsten Level gehoben. Viele Standardprobleme sind damit bereits gelöst und man muss sich nicht so viel mit der Implementierungen herumschlagen, sondern bekommt gleich das All-Around-Paket. In der Praxis kommt es natürlich oft vor, dass viel Feintuning erforderlich ist. Der Grund ist, dass die Suche immer anhand sehr spezifischer Anforderungen implementiert wird, trotzdem spart man sich viel Initialaufwand.

Wer mehr über wissen will, sollte sich einmal die jeweilige Homepage anschauen:

http://lucene.apache.org/solr/

https://www.elastic.co/de/

Wer trotzdem mit Lucene starten möchte kann sich hier die Doku dazu anschauen. Derzeit ist die Version 6.5.0 aktuell.

Veröffentlicht unter Software Engineering | Verschlagwortet mit , , , , , | Kommentar hinterlassen

Oracle Code Berlin – Personal impressions from a surprisingly different conference

You want to learn about my impressions about the Oracle Code conference in Berlin? Then read my blog 🙂

Understanding IT, software architectures and technologies

Monday the 24th of April, 3:15 a.m.: My alarm clocks rings me up – yes, this is of course brutally early! But it was necessary to catch my train from Cologne to Berlin, where the newly invented conference format „Oracle Code“ opens the doors. With respect to these early hours, knowing that this will be a long day and not sure what to expect, I made my way to Berlin – and this was a very good invest!

The facts of Oracle Code 2017 in Berlin:

  • 350 attendees
  • More than 20 sessions covering relevant topics like
    • Micorservices
    • API Management
    • Chatbots
    • Docker
    • DevOps
    • Kafka
  • 2 Hands-On-Labs (Docker introduction and Oracle Bare Metal Cloud)
  • Experienced, international speakers

The focussed audience of this conference were developers and architects, so the focus of the conference presentation was on technology, real-world problems and solutions – no marketing, which was very welcomed! If you want…

Ursprünglichen Post anzeigen 281 weitere Wörter

Veröffentlicht unter Cloud & Infrastructure, News | Verschlagwortet mit , , , , | Kommentar hinterlassen

Realisierung der IoT Steuerung mit Hilfe der Microsoft HoloLens und Cloud Computing

Die Industriemaschine ist per Retrofitting smart gemacht, also IoT-enabled. Dies ermöglicht die SPS-Steuerung der Maschine in der Cloud zu exponieren, womit neue Steuerungsmöglichkeiten entstehen wie das untere Bild es veranschaulicht.

Technical_holo-qloud

Die Steuerung der Industriemaschine erfolgt mit den zwei Grundkonzepten GAZE und GESTURE der HoloLens. Mit Gaze wird die Blickrichtung erfasst, womit das Fokussieren der modellierten 3D Objekte möglich ist. Nach dem Fokussieren eines Objektes, erfolgt die Interaktion mit Gesture. Das Gesture Konzept erkennt das Tippen mit dem Zeigefinger als eine Geste und führt in einem C#- Script hinterlegten Programmcode aus. Im Bild unten ist ein virtuell modelliertes Objekt mit einem C#-Script dargestellt, welches die Interaktion ermöglicht.

unity-cube1.png

Das C#-Script enthält die Methode onSelect(), welche nach der „Air Tap“ -Geste ausgeführt wird.

void OnSelect()
  {
    changeS7300SetUp(RestfulServices.sessionInformationCredintials);
    playAudio();
  }

Diese Methode ändert die Produktion der Maschine und gibt akustisch einen Signal zurück, dieses bestätig, dass das Produktion -Setup der Maschine geändert worden ist. Das Ändern des Produktion -Setups erfolgt in drei Schritten:

  1. IoT Cloud Authentifizierung
  2. Abonnieren der Events der Maschine
  3. Einen POST des neuen Produktions-Setups ausführen

Die Authentifizierung und das Abonnieren der Events ist  hier dokumentiert. Die Änderung des Setups ist weiter im Text beschrieben.

Das Setup der Maschine also die Steuerung, kann wie folgt in der IoT Cloud hinterlegt sein:

    "0cgh2eb10-dfasd-11e5-a699-0asdf73fd04":{
         "type": "xobject",
         "owner": "ccasdfd90-da25-13e5-9fbb-0025wer342ac08",
         "time": 1456241720,
         "description": "0,2,1",
         "tag": ["ccasdfd90-da25-13e5-9fbb-0025wer342ac08"]
      }

Der Key „description“ enthält die Werte, die bestimmte Funktionen der Maschine repräsentieren. Nachdem ein POST mit den neuen Werten durch die Geste „AirTap“ mit der HoloLens ausgeführt wird, ändert sich der Key in der IoT -Cloud und die smarte Industriemaschine bekommt ein Befehl das Produktion -Setup zu ändern.

Das ändern des Produktions -Setups in C#, erfolgt in dieser Methode:

void changeS7300SetUp(SessionInformationModel sessionCredintials)
 {
   string jsonBody = ("{\"description\":\"0,1,0\"}");

   Dictionary<string, string> headers = new Dictionary<string, string>();
   headers.Add("Content-Type", "application/json");
   headers.Add("Authorization ", "Bearer " + sessionCredintials.sid);

   byte[] body = System.Text.Encoding.UTF8.GetBytes(jsonBody);

   //POST
    WWW www = new WWW(sessionCredintials.server + "/api/xobject/0c02eb10-da43-asd-a699-00259073fd04?sid="+sessionCredintials.sid, body, headers);
    StartCoroutine(WaitForChangeS7300SetUp(www, sessionCredintials));
 }

Hier wird ein JSON-String mit den Produktionswerten erzeugt, der dann an die Maschine über die IoT Cloud, im Body per POST gesendet wird.

Diese Art der Steuerung einer Industriemaschine bietet in vielerlei Hinsicht einen Mehrwert. Die Originalsteuerungs-UI der Industriemaschinen unterscheiden sich je nach Hersteller und sind selten intuitiv. Die Steuerungs-UI der HoloLens kann jedoch personalisiert und auch mit Zugriffsrechten versehen werden. Durch die Augmented Reality werden den Mitarbeiter die Informationen geboten, die zu diesem Zeitpunkt und abhängig vom Ort gerade benötigt werden. Des Weiteren bietet die virtuelle Steuerung höhere Sicherheit da die Interaktivität nicht direkt an der Maschine stattfindet.

 

Veröffentlicht unter Cloud & Infrastructure, IoT & Industry 4.0, Uncategorized | Verschlagwortet mit , , , , , | 2 Kommentare