Analyzing Wikipedia using Apache Storm

Veröffentlicht am 21. Juni 2017 von

Apache Storm is one of the dinosaurs within the large set of big data technologies – especially in the stream processing area. This article will introduce you to Apache Storm by demonstrating how to create a small project. Many tutorials about streaming technologies use the Twitter API to demonstrate their framework. In this tutorial we will use the public available wiki data stream that continuously sends data whenever an article in one of Wikimedia’s wikis has been changed.

Apache Storm Basics

The most important concepts in Storm are the spouts, the bolts and the topology:

  • Spouts: Are responsible to get data from outside into the Storm Cluster
  • Bolts: Are responsible to do something with the data and potentially send them to the next bolt
  • Topology: Defines how spouts and bolts interact and determines the parallelism

Another important concept is the groupings. Groupings are defined in the topology and tell Storm which data tuple must be distributed to which of the bolt’s tasks. The most important grouping types are:

  • Shuffle Grouping: Tuples are distributed randomly to the bolts‘ task
  • Fields Grouping: Tuples having the same value in a field defined in the topology are sent to the same task
  • All Grouping: All data tuples go to all tasks. Typically used to send configuration data
  • Global Grouping: All tuples go to exactly one task

There are some other groupings that can be found here.

Our Task

That’s enough technical stuff! Let’s get into the problem! Which data is sent to us?

Everytime there is a change in a wiki, the stream sends us JSON data in real time in the following structure:

wiki

So we have a comment, we have the information in which wiki the change was made, and we know if the change was made by a bot. Furthermore we have some other information we don’t care about here.

Let’s define our goals!

We want to know which wikis are the most active ones! And we don’t care about changes made by bots. To make the objectives as clear as a test in school:

Write a Storm application using Java which regulary writes a new .txt file which contains the name of the wikis and the number of changes that happened there. Ignore all bot changes! The text file shall have this format:

https://ms.wikipedia.org 1

https://fr.wikipedia.org 49

https://nl.wikipedia.org 8

https://sv.wikipedia.org 3

https://bs.wikinews.org 1

https://te.wikipedia.org 1

https://zh.wikipedia.org 29

In each line we want to have the name of the wiki and the number of changes.

The Concept

We learned about the topology, spouts and bolts before.

At first we need a spout which receives data from the wiki stream and brings the data in our topology. Let’s call it WikiSpout.

The WikiSpout sends the data tuples to a bolt called RemoveBotsBolt which removes all tuples from the data stream which contain the attribute bot:true.

In the last step the data must be sent to the ServerCounterBolt which finally tracks the number of changes in the wikis. So our topology looks like this:

topology

Let’s start!

The POM

First of all we create a project using this pom.xml

<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 	xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
	<modelVersion>4.0.0</modelVersion>
	<groupId>de.opitz.bigdata</groupId>
	<artifactId>wikireader</artifactId>
	<version>0.0.1-SNAPSHOT</version>

	<build>
		<plugins>
			<plugin>
				<groupId>org.apache.maven.plugins</groupId>
				<artifactId>maven-compiler-plugin</artifactId>
				<version>3.1</version>
				<configuration>
					<compilerVersion>1.7</compilerVersion>
					<source>1.7</source>
					<target>1.7</target>
				</configuration>
			</plugin>
		</plugins>
	</build>
	<dependencies>
		<dependency>
			<groupId>org.apache.storm</groupId>
			<artifactId>storm-core</artifactId>
			<version>1.0.2</version>
			<scope>provided</scope>
		</dependency>
		<dependency>
			<groupId>org.apache.commons</groupId>
			<artifactId>commons-io</artifactId>
			<version>1.3.2</version>
		</dependency>
	</dependencies>
</project>

The Main

Let’s start with our main class:

public class Main {
public static void main(String[] args) throws Exception {
	Config conf = new Config();
	conf.setDebug(false);
	conf.setNumWorkers(2); // We want to use 2 Worker processes
	LocalCluster cluster = new LocalCluster(); // We define a LocalCluster which is perfect for developing puposes
	TopologyBuilder topologyBuilder = new Topology().build();
	cluster.submitTopology("WikiTopology", conf, topologyBuilder.createTopology());
}

}

This class seems to be more or less self-explanatory: We get a configuration, define the number of worker processes we want to use, tell Storm that we are just using a LocalCluster for testing and finally submit our topology.

The Topology

It’s becoming interesting: We define our topology! So let’s go to the class Topology:

public class Topology {
public TopologyBuilder build() {
	TopologyBuilder topologyBuilder = new TopologyBuilder();
	topologyBuilder.setSpout("WikiSpout", new WikiSpout(), 1);
	topologyBuilder.setBolt("RemoveBotsBolt", new RemoveBotsBolt(), 3).shuffleGrouping("WikiSpout");
	topologyBuilder.setBolt("ServerCounterBolt", new ServerCounterBolt(), 1).globalGrouping("RemoveBotsBolt");
	return topologyBuilder;
}
}

At first we tell Storm that we want to have a spout called „WikiSpout“ which implementation is in WikiSpout.java and that we only want one task that executes this spout. That should be enough since the spout just receives data and sends them to the bolt.

In the next line we define our first bolt, the RemoveBotsBolt. We define a parallelism of 3, because we assume that the complexity of this process needs 3 tasks. (Of course that’s not realistic and just for demonstration purposes)

Finally we define a global grouping from the RemoveBotsBolt to ServerCounterBolt. Why a global grouping? If we would use a shuffle grouping and define a parallelism > 1, the data tuples sometimes go to task1 and sometimes to task2 and so on. We cannot seriously count our data tuples since both tasks have their „own“ counter and we have also no database to synchronize the counters in this example.

Additional Question:

What would you do, if there is so much data that one task of ServerCounterBolt cannot deal with this? —-> We have to increase the parallelism, and we have to think about using field-grouping in order to achieve correct results. Try it!

Some Helper Classes

Before we continue we create two small classes which will help us later:

public class Util {

	public static final String SERVER = "server";
	public static final String USER = "user";
	public static final String TITLE = "title";
	public static final String BOT = "bot";

}

and

public class Change {
	private String serverName;
	private String title;
	private String user;
	private boolean bot;

+ Getters & Setters!

}

Our Wiki-Spout

At first we need a library that is able to read the wiki stream. We decided to use this socket.io-java-client from Github and compiled it and imported it to the build path.

Now let’s create a class called WikiSpout extending BaseRichSpout.

Before writing any methods we start with defining following variables:

private SpoutOutputCollector collector;
private List changes;
final Lock lock = new ReentrantLock();

First of all we need to overwrite the method nexTuple(). This method is invoked continuously by Storm (imagine a while loop invoking this method over and over). The goal of this method is to send all data we have in our list „changes“ to the next bolt:

lock.lock();
for (Change change : changes) {
	collector.emit(new Values(change.getServerName(), change.getUser(),           change.getTitle(), change.isBot()));
}
changes = new ArrayList();
lock.unlock();

We needed a lock here, since it is possible that while invoking nextTuple() the List „changes“ is used by another method.

This is the method open(Map arg0, TopologyContext context, SpoutOutputCollector collector):

It is invoked only when the task gets started. At first we create some variables:

this.collector = collector;
SocketIO socket = null;
changes = new ArrayList();

And then we try to invoke the wiki stream:

try {
	socket = new SocketIO("http://stream.wikimedia.org/rc");
} catch (MalformedURLException e1) {
	throw new RuntimeException(e1);
}

After we start listening to this socket:

socket.connect(new IOCallback() {
public void onMessage(JSONObject json, IOAcknowledge ack) {
}

public void onMessage(String data, IOAcknowledge ack) {
}

public void onError(SocketIOException socketIOException) {
	System.out.println("an Error occured");
	socketIOException.printStackTrace();
}

public void onDisconnect() {
	System.out.println("Connection terminated.");
}

public void onConnect() {
	System.out.println("Connection established");
}

public void on(String event, IOAcknowledge ack, Object... args) {
	System.out.println("Server triggered event '" + event + "'");
	if (args[0] instanceof JSONObject) {
		JSONObject changeJson = (JSONObject) args[0];
		try {
			Change change = new Change();
			change.setUser(changeJson.get("user").toString());
			change.setTitle(changeJson.get("title").toString());
			change.setServerName(changeJson.get("server_url").toString());
			change.setBot(Boolean.valueOf(changeJson.get("bot").toString()));
			lock.lock();
			changes.add(change);
			lock.unlock();
		} catch (JSONException e) {
			e.printStackTrace();
		}
	}
}
});

The most interesting thing here is the on(…) method. It is invoked whenever a change in a wiki was done. Then we get a JSON Object according to the example described in the text above. Now we extract the data we want from the JSON, create a „Change“ object and add it to the list.

Finally we tell the socket to subscribe to each tuple that is sent by the stream:

socket.emit("subscribe", "*");

The last thing we have to do is to tell Storm what the names of the fields we send to the next bolts are:

public void declareOutputFields(OutputFieldsDeclarer declarer) {
	declarer.declare(new Fields(Util.SERVER, Util.USER, Util.TITLE, Util.BOT));
}

So what did we do? The method on() is continuously invoked when a change in wiki happened and adds a „Change“ object to a list.

Method nextTuple() is continuously invoked by Storm. If the list mentioned above contains elements they get emitted, which finally means that they will be sent to the next bolt(s).

Remove Bots Bolt

The task of the RemoveBotsBolt is to eliminate all tuples that have a flag „true“ for the attribute bots.

So we create a new class, RemoveBotsBolt.java extending from BaseRichBolt.

Before writing a method we define the collector:

private OutputCollector collector;

In the prepare method, we set it:

public void prepare(Map stormConf, TopologyContext context, OutputCollector collector) {
	this.collector = collector;
}

The execute method should look like the following:

public void execute(Tuple input) {
	Boolean bot = input.getBooleanByField(Util.BOT);
	String server = input.getStringByField(Util.SERVER);
	if (!bot) {
		collector.emit(new Values(server));
	}
}

The method execute(…) is invoked by Storm when a new data tuple comes in. We extract the data from this tuple, and if we get a bot, we do nothing; otherwise we emit the name of the server.

This time we know the next bolt is just interested in the name of the server (for example ‚de.wikipedia.org‘). So we tell Storm the name of our single output field:

public void declareOutputFields(OutputFieldsDeclarer declarer) {
	declarer.declare(new Fields(Util.SERVER));
}

Finally: The Server Counter Bolt

The last class we are writing is called ServerCounterBolt extending from BaseRichBolt.

This time the methodes prepare and declareOutputFields can be left empty.

But we need two variables at the beginning of the class:

	private HashMap counts = new HashMap();
	private int totalCount = 0;
  • counts: contains the name of the server and the number of occurences
  • totalCount: contains the total number of tuples that came in

So let’s write a helper method that writes a file having the current date and time in its name:

private void writeFile() {
	DateFormat df = new SimpleDateFormat("MMdd-HH-mm-ss");
	String dateTime = df.format(new Date());
	File file = new File(dateTime + ".txt");
	List lines = new ArrayList();
	for (String key : counts.keySet()) {
		lines.add(key + " " + counts.getOrDefault(key, 0));
	}

	try {
		FileUtils.writeLines(file, lines);
	} catch (IOException e) {
		throw new RuntimeException(e);
	}
}

This method iterates through our „counts“ map and writes its contents to a file.

Finally we have to overwrite the execute-Method:

public void execute(Tuple input) {
	totalCount++;
	String server = input.getStringByField(Util.SERVER);
	Integer count = counts.getOrDefault(server, 0);
	count++;
	counts.put(server, count);
	if (totalCount % 200 == 0) {
		writeFile();
	}
}

That’s it!

Now we can start the main class and need to wait a few seconds to get the first file with results.

This article just describes the absolute basics of Storm. Many things, for example acknowledgments are not dealt with here. So have fun to dive deeper into Storm’s technology!

I hope you got a first idea how Storm works.

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

Oracle API Platform Cloud Service – The Next-Gen API Management Platform

Veröffentlicht am 15. Juni 2017 von

Curious to know how to build Next-gen APIs using a API First Desing approach? Go on reading….

Understanding IT, software architectures and technologies

Nowadays APIs are omnipresent. In a world of intelligent Virtual assistants (a.k.a. Chatbots), like Google’s Alexa, and a „Connect everything“-mentality this is not surprising. In addition, APIs are essential building blocks of modern software applications build on top of new architectural patterns like Microservices. That’s the technical side.

From a corporate perspective, APIs provide the chance to create new digital business models and economies by exposing services and data to business partners and customers. The challenge: How to ensure Usability, Security, Transparency and Discoverability for the exposed APIs?

Design-Driven API Management

With API Platform Cloud Service (APIP CS), Oracle launched the next big thing today making their Platform as a Service (PaaS) offering even more complete.

APIP CS is a lightweight, cloud-native platform that is capable for covering the complete API Lifecycle from Planning to Retirement.

API_LIfecycle

Having an integration with Apiary.io, which was acquired by Oracle in the…

Ursprünglichen Post anzeigen 686 weitere Wörter

Veröffentlicht unter Uncategorized | Kommentar hinterlassen

OPITZ CONSULTING berichtet vom AWS Summit Berlin – Teil 2

Veröffentlicht am 22. Mai 2017 von

Im ersten Teil unseres Berichts über den AWS Summit 2017 in Berlin ging es hauptsächlich um das Thema Cloud Adoption. Im zweiten Teil möchten wir weitere besuchte Sessions, hauptsächlich aus dem Track „Next Generation Applications“ vorstellen:

Amazon Polly: Voice Your App

In dieser Session zeigten Rafal Kuklinski und Remus Mois Amazons Text to Speach Engine Polly. Die Session zeigte an verschiedenen Beispielen, welche Möglichkeiten die Engine bietet. Erfreulich war die Tatsache, dass die Beispiele für den deutschen Sprachraum erstellt wurden. Gestartet wurde mit einem Goethe Zitat (gesprochen von der neuen Stimme Vicky)

Ein Highlight war aber sicherlich das Beispiel für die neue „Flüstern“ Funktionalität.

IMG_0965 (1)

7 Things You Must Know to Build Better Alexa Skills

Da wir bei Opitz Consulting auch einen eigenen Alexa Skill und sprachbasierte Interfaces sich immer mehr verbreiten, konnte es nicht schaden, sich Tips eines Alexa Entwicklers zu holen. Memo Doring zeigte sieben Punkte, die seiner Meinung nach für einen guten Alexa Skill wichtig sind.

  1. Design for the ear
  2. Use the skill builder
  3. Be mindful of your training data
  4. Leverage States
  5. Persistence
  6. Voice requires cognitive processing
  7. Listen to how people actually talk

Einige der aufgeführten Punkte sind auch im Artikel von Christian Ochsenkühn zu finden.

Real-time Streaming Applications on AWS, Patterns and Use Cases

Hier wurde von Dr.Steffen Hausmann aufgezeigt, welche Möglichkeiten AWS mit Kinesis für die Verarbeitung von Streaming Daten bietet. Christian Deger untermalte die erwähnten Möglichkeiten im Anschluss mit greifbaren Anwendungen von Kinesis Streams, Analysis und Firehose am Beispiel von Autoscout24.

Analyzing Streaming Data in Real-time with Amazon Kinesis Analytics

Aufbauend auf der vorherigen Session ging Dr. Steffen Hausmann nunmehr ins Detail von Kinesis Analytics. Er wählte als Beispiel die Analyse eines Twitter Streams. Er zeigte live die Filterung der eintreffenden Daten nach Fussballclubs und die anschließende Auswertung, welche fünf Clubs in der letzten Stunde am meisten Erwähnung fanden. Ganz nebenbei wurden diese Ergebnisse noch in Elastic Search gespeichert. Beeindruckend, was alles mit ein wenig Konfiguration und wenigen Zeilen SQL Möglich ist.

DevOps at Amazon: A Look at Our Tools and Processes

Hier war es beruhigend zu sehen, dass Amazon auch nur mit Wasser kocht. Alle vorgestellten Tools und Vorgehensweisen waren einem DevOps Praktizierenden bereits bekannt. Relativ unbekannt ist allerdings der AWS Service CodeStar. Dieser Service beinhaltet alles, um eine komplette Delivery Pipeline mit wenigen Clicks bereit stellen zu können. Angefangen beim Code Repository bis zum automatischen Deploy der Anwendung in EC2.

Fazit

Der AWS Summit 2017 war ein tolles Event. Viele interessante Talks, und jede Menge neue Möglichkeiten wurden aufgezeigt. Die Liste mit Dingen, die ausprobiert werden müssen, ist um viele viele Punkte angewachsen.

 

 

 

Veröffentlicht unter Cloud & Infrastructure, Uncategorized | 2 Kommentare

OPITZ CONSULTING berichtet vom AWS Summit Berlin – Teil 1 mit Fokus „Cloud Adoption“

Veröffentlicht am 19. Mai 2017 von

Am 18. Mai 2017 fand in Berlin eine weitere Auflage des AWS Summit statt. Mit über 3000 Teilnehmern, mehr als 70 Ausstellern, über 60 Breakout Sessions, einem Innovation Lab und mehreren technischen Demos befindet sich das Event weiter auf Wachstumskurs. OPITZ CONSULTING war ebenfalls mit einem Team vor Ort und teilt in diesem Post die Eindrücke.

AWS-Summit

Den Auftakt lieferte eine inspirierende Keynote von Glenn Gore (Chief Architect AWS). Neben der Evolution der AWS Cloud bildeten die Themen Alexa, DevOps, Microservices, Datenbank-Migration und Machine Learning auf Basis des AWS Stacks den Kern der Session. Interessant waren dabei die verschiedenen Anwendungsbeispiele aus der Praxis, die demonstrierten, wie es Kunden geschafft haben mit AWS ihr Geschäft zu digitalisieren und zu optimieren. Besonders zu erwähnen ist hierbei der hybride Cloud-Ansatz der Deutschen Bahn (vorgetragen von Oliver Krülle, CIO, DB Vertrieb GmbH) zum Ausgleich von Lastspitzen sowie die Lösung zur Warnung von Wasserschäden von der GROHE AG (vorgetragen von Bert Depiere, Director Digital Innovations). Übrigens wem dieser Text hier zu lang ist, der sollte sich genauer mit Sprachassistenten und der Kombination aus AWS Polly, Lex und Rekognition auseinandersetzen. Für die neue deutsche Stimme Vicki stellen nun auch Anglizismen kein Problem mehr dar. Aufgrund des fortgeschrittenen Reifegrades eignet sich die Sprachausgabe sogar zum Erlernen von Fremdsprachen, wie von Dr. Ralf Herbrich (Director of Machine Learning) am Beispiel von duolingo erwähnt wurde.

Datei 19.05.17, 10 30 21

Takeaways aus den Sessions

The Digital Innovation Program by AWS

Diese Session lieferte einen Überblick zum AWS Digital Innovation Program und dem „working backwards“ Ansatz. Dabei starten Kunden zunächst mit einem Press Release und schärfen darin die Vision und das Ziel Ihrer geplanten Innovationsprojekte. Ein interessanter Ansatz, um sich von Anfang an auf den tatsächlich angestrebten Mehrwert zu konzentrieren, ohne sich in technischen Details zu verlieren. Danach folgt i.d.R. ein MVP, der in cross-functional Teams erstellt wird. Das Programm bietet hilfreiche Ansätze, welche – angereichert mit unseren Erfahrungen und Methoden – auch im Rahmen unseres Zukunftsworkshops zur Cloud Strategie näher erläutert werden.

The future is already here! How new technologies are changing the game at Deutsche Bahn Kommunikationstechnik GmbH

In diesem Vortrag wurde auf die digitale Transformation typischer Anwendungsfälle bei der Deutschen Bahn eingegangen. Anhand von Cloud und dem österreichischen ivii.assist zeigte der Vortrag, wie die Digitalisierung die gemeinsame Bearbeitung komplizierter Probleme geographisch getrennten Teams verbessert bzw. überhaupt erst ermöglicht. Ganz konkret wurden hier folgende Anwendungsfälle genannt:

  • Remote Support
  • Qualitätssicherung
  • Ausbildung
  • Unterstützung planbarer Aktivitäten.

Fazit: Anregende Session mit vielerlei Parallelen zu unseren Schwerpunktthemen im Competence Center IoT (Mit Retrofitting und Cloud in die Digitalisierung; IoT Steuerung mit HoloLens & Cloud).

Building Apps in the Cloud to Reduce Costs up to 90%

Hier lieferte Christian Petters (AWS Solutions Architect) vielerlei nützliche Informationen, wie sich mit Hilfe sogenannter EC2 Spot Instances deutliche Kosteneinsparungen erzielen lassen. Der Ansatz ist insbesondere für Dev- und Test Umgebungen spannend. Die größten Einsparungen lassen sich erzielen, wenn die Architektur Rücksicht auf bewährte Best Practices wie Stateless, Fault Tolerance, Multi-Availability Zones und lose Kopplung nimmt. Besonders hilfreich war die Diskussion zu typischen Vorurteilen bzw. Fragestellungen, die kurze Vorstellung des Spot Bid Advisors sowie die Auflistung geeigneter UseCases. Insgesamt eine sehr gute Session, deren Inhalte in das OPITZ Angebot zur Cloud Kostenoptimierung und zum Lizenzmanagement einfließen werden.

AWS Cloud Adaption Framework 2017 – Starting a Structured Cloud Initiative

In dieser Session wurde das AWS Cloud Adoption Framework (AWS CAF) vorgestellt. Zweck des Frameworks ist es, Organisationen dabei zu helfen einen effizienten und effektiven Plan für den Weg in die Cloud zu entwickeln. Der Planungsvorgang ist in sieben Perspektiven gegliedert: Business, Plattform, Reife, Mitarbeiter, Prozesse, Betriebsablauf und Sicherheit. Guter Hinweis von Referent Marcus Fritsche (IT Transformation Consultant), dass mind. 50% einer erfolgreichen Cloud Initiative von der Organisation, den Menschen sowie der Governance abhängen – das entspricht ganz klar auch unseren Erfahrungen. Das Framework umfasst eine Vielzahl an Inhalten, welche auch Ihren Platz in unseren Cloud Workshop-Angeboten besitzen.

10 Best Practices for your Cloud Migration

In der knappen Zeit von 30 Minuten wies Jeremias Reith (Senior Consultant) in seinem gut gegliederten Vortrag auf folgende Best Practices hin:

  1. Do create a Cloud Center of Excellence (CCoE)
  2. Do a pre-migration migration
  3. Do build a minimal landing zone and iterate (!)
  4. Be agile
  5. Do leverage specialiced migration factories
  6. Do track and communicate Progress
  7. Apply lessons learned to existing organization
  8. Do let the CCoE build re-usable building blocks
  9. Do a post-migration migration
  10. Do engage partners or AWS Professional Services

Getting Started with AWS Database Migration Service

Gelungener Vortrag mit vielen relevanten Praxisinhalten, um Datenbanken mit minimaler Downtime zu migrieren. Das dies jedoch nicht zwangsläufig mit einer Ablösung der bestehenden Datenbank einhergehen muss, wurde anhand vieler verschiedener Einsatzgebiete dargestellt. Diese können im Rahmen einer Modernisierung, Migration und/oder der Replikation angesiedelt sein. Weitere Use Cases können dem nachfolgenden Foto entnommen werden.

Datei 19.05.17, 14 23 16

Die Session vermittelte einen guten Einblick in die Werkzeuge (DMS & SCT) und die Herausforderungen, die im Rahmen einer Datenbankmigration bestehen (z.B. Kostenbetrachtung, technische Hürden). Trotz der ausgereiften Werkzeuge wurde deutlich, dass eine Datenbankmigration keine „One-Button-Click“ Aufgabe ist. Eine Erkenntnis, die wir in unserer langen Historie als Datenbankspezialist und Managed Service Provider vollends bestätigen können.

In Teil 2 berichten wir vom AWS Summit mit dem Fokus auf Next Generation Applications.

 

Veröffentlicht unter Cloud & Infrastructure | 1 Kommentar

BuildingIoT2017 – Our Impressions and Learnings from this year’s Conference

Veröffentlicht am 11. Mai 2017 von

Starting from the Star Wars Day (04/05/2017, probably a good sign;-) to the 05/05/2017 the BuildingIoT 2017 took place in Heidelberg. Otto Fitz and Dominik Bial went there to represent OC at our booth (we were gold sponsors) and with the talk “IoT als zentraler Treiber der Digitalisierung (IoT as Enabler for Digitisation)”.  The talk was given by Dominik and Christian Pereira from Q-loud.

Networking and meeting people were a lot of fun. Besides that, we had great discussions at our booth. Security, integration and projects were the key topics this year.  Moreover, a lesson we already learned at the Hannover Messe 2017, analytics is becoming more important as a key skill and, therefore, it is interesting for partnerships. As soon as there is the data, concepts and knowledge are needed to come to insights. Luckily, OC has already a strong background in analytics, so that we can look forward to new, interesting projects.

Our favorite three talks were:

  • Sicherheit & IoT – Stand der Gefährdung 2017 (Security and IoT – State of Threats 2017) by Stefan Strobel: A talk about new approaches for hacking
  • Praxisbericht: Eine Big-Data- und Microservices-Landschaft für IoT-Daten (A report about a big data and microservice acrchitecture) by Marc Jäckle, Sebastian Wöhrl: Great justification of our architectures)
  • Auf dem Weg zu einer offenen IoT-Cloud-Plattform (On the way to an open IoT cloud platform) by Steffen Evers, Kai Zimmerman: Great insights about designing own IoT Clouds.

The Q-loud sorter showcase in combination with the Hololens was definitely an eye catcher which attracted people and resulted in a lot of discussions.  If you are interested, Otto published a video on youtube.

Overall, the conference was a great success and brought together developers, innovators and managers. We are looking forward to next year.

Veröffentlicht unter IoT & Industry 4.0 | Kommentar hinterlassen

Augmented Reality im Unternehmen – Eine Analyse der Möglichkeiten aktuell verfügbarer Hardware

Veröffentlicht am 11. Mai 2017 von

Spätestens seit Microsoft mit der HoloLens im Jahr 2015 eine AR-Brille der Öffentlichkeit präsentiert hat, ist das Thema „Augmented Reality“ (AR) in aller Munde. Im Internet finden sich zu Hauf Videos und Bildmaterial, welche mögliche Einsatzszenarien in beeindruckender Weise veranschaulichen. Dabei stehen nicht nur Unterhaltungszwecke im Vordergrund, sondern vor allem auch die Erleichterung und Effizienzsteigerung der alltäglichen Arbeit. Goldman Sachs prognostiziert bereits ein Marktvolumen von $80 Milliarden für VR und AR bis zum Jahr 2025, Digi Capital sieht gar ein Potenzial von $150 Milliarden bis 2020. So haben auch wir bei OPITZ CONSULTING begonnen, uns mit dem Thema Augmented Reality zu beschäftigen. Doch bei aller Euphorie, die aktuell herrscht, gilt es zunächst zu klären, welche Möglichkeiten die aktuelle Hardware bietet und welche Brillen neben der alles überstrahlenden HoloLens existieren.

Da sich die Anwendung von Augmented Reality nicht auf Brillen beschränkt, möchten wir zunächst einen Überblick darüber gewinnen, welche weiteren Devices verwendet werden können. Die Devices werden im Kapitel zu den Nutzungsszenarien wieder aufgegriffen. Dort kann ein Eindruck vom Einsatz von Augmented Reality in Unternehmen gewonnen werden. Trotz der Erwähnung von Smartphones und VR-Brillen, liegt der Fokus auf AR-Brillen. Hierzu vergleichen wir im letzten großen Kapitel exemplarisch die AR-Brillen HoloLens, Epson Moverio BT-300 und Vuzix m100 und arbeiten die Herausforderungen für den Einsatz in der Praxis heraus.

Augemented Reality – Immer das Gleiche?

Die HoloLens wird aktuell ohne Zweifel von der Öffentlichkeit wahrgenommen. Es ist nach der Google Glass das zweite Mal, dass eine AR-Brille diese weitreichende Aufmerksamkeit erfährt. Beide Brillen stehen für zwei unterschiedliche Ansätze im Bereich der erweiterten Realität. Zwar wurde die Google Glass mittlerweile eingestellt, doch steht sie auch heute noch sinnbildlich für eine Gruppe von AR-Brillen, die aktuell und vermutlich zukünftig weiterentwickelt werden.

Google Glass visualisiert Informationen für lediglich ein Auge und in 2-D, während die HoloLens dazu in der Lage ist, 3-D Objekte im Raum darzustellen und mit ihnen zu interagieren. Microsoft selbst spricht daher von Mixed Reality (MR). Für Brillen, die funktional dem Lager der Google Glass zuzuordnen sind, wird teilweise das Wort „Datenbrille“ verwendet. Sowohl MR-Brillen, als auch Datenbrillen haben gemein, dass die reale Welt trotz virtueller Anreicherung durch Informationen, unmittelbar wahrnehmbar ist. In diesem Punkt unterscheiden sie sich eindeutig von Virtual-Reality-Brillen (VR-Brillen) wie der Oculus Rift, welche den Nutzer, abgekapselt von der realen Welt, komplett in virtuelle Welten eintauchen lassen.

Zusätzlich zu den Brillen gibt es noch weitere Devices, die AR unterstützen. So gibt es bereits Smartphones, die mit ToF-Kameras ausgestattet sind. In Kombination mit der Technologie-Plattform Google Tango, können diese Smartphones ebenfalls ihre Umgebung erfassen und vermessen. Sie bieten sich somit für den Einsatz im AR-Umfeld an. Doch selbst herkömmliche Smartphones werden bereits für AR-Anwendungen genutzt. Diese nutzen real existierende Referenzobjekte im Raum, um die virtuellen Objekte auf die richtige Größe und die richtige Perspektive zu skalieren.

Realistische und utopische Nutzungsszenarien

Auf YouTube finden sich viele Videos, die AR visualisieren. Es ist jedoch nicht immer klar, ob es sich um tatsächlich realisierte Projekte handelt, oder um den geschickten Einsatz von Adobe Premiere. Hier seien zunächst zwei Videos genannt, zu denen sich keine tiefergehenden Informationen über praktische Umsetzungen finden ließen:

Im weiteren Verlauf dieses Artikels werden wir auf große Hürden zur Umsetzung der beiden oben verlinkten Videos stoßen. Ob ein Produktiveinsatz möglich wäre, ist fraglich. Doch die Sinnhaftigkeit eines Einsatzes von AR korreliert nicht mit seiner Spektakularität. Im Folgenden liegt daher der Fokus auf der Darstellung der Identifizierten tatsächlich umgesetzten AR-Pilotprojekte. Die verwendeten Technologien bestehen hauptsächlich aus AR-Brillen. Dennoch beschreiben wir bewusst auch Szenarien mit VR-Brillen und Smartphones, um die Möglichkeiten, die sich durch die virtuelle Anreicherung bzw. Überdeckung der Realität ergeben, anzudeuten.

Remote Support für Onsite-Service-Techniker

Die meisten identifizierten Projekte beschäftigen sich mit dem Remote Support. Alle Projekte haben gemein, dass der im Einsatz befindliche Techniker bei komplexen Problemen Unterstützung durch Fachexperten erhalten kann. Diese müssen nicht mehr vor Ort sein und können so Support für viele, an unterschiedlichen Stellen arbeitenden Techniker, bieten.

Lee Company

Zweifelsohne spielt Lee Company seit der Inbetriebnahme von sage und schreibe 500 Vuzix M100 Smart Glasses im Jahr 2016 im vorderen Feld der AR-Pioniere mit. In Zusammenarbeit mit dem auf den professionellen Einsatz von Wearables im klassischen Arbeiterumfeld spezialisierten Unternehmen XOEye Technologies, feilt Lee Company daran, seine Arbeitsprozesse durch den Einsatz von AR effizienter zu gestalten.

Lee Company hat sich auf Dienstleistungen im Bereich „Home Services“ spezialisiert. Dazu gehören u.a. die Installation und Wartung von Wärme- und Kältetechnik, Sanitäranlagen, Elektrotechnik und Sicherheitssystemen. Die Datenbrillen ermöglichen den Remote-Support in Echtzeit durch erfahrene Fachexperten. Dabei wird das Sichtfeld des am Einsatzort befindlichen Technikers live per Videostream an den Experten übertragen, was die Qualität des Supports erheblich steigert. Der Experte wiederum kann unmittelbar Hilfestellung geben und auf etwaige Folgeereignisse reagieren. Ist gerade kein Fachexperte verfügbar oder wird weitere Hilfe benötigt, so können Videos ohne weitere Umwege an elektronische Service Tickets angehängt werden. Geeignete Videos werden außerdem archiviert und im internen Schulungssystem bereitgestellt. So können neue Mitarbeiter deutlich effizienter eingearbeitet werden.

Was technisch gesehen weit von den eingangs vorgestellten visionären Konzepten entfernt ist, hat sich bei Lee Company im Einsatz als äußerst förderlich herausgestellt. Woche für Woche werden etliche Arbeitsstunden gespart und die Tätigkeiten beim Kunden schneller erledigt. Somit sinken nicht nur unmittelbar die Arbeitskosten, sondern der Kunde ist auch zufriedener mit der Leistung des Unternehmens.

Quellen / Weiterführende Informationen:

Caterpillar Remote Assistance

Caterpillar geht konzeptionell gesehen zusammen mit der auf AR spezialisierten Softwareschmiede Scope AR einen ähnlichen Weg. Ein großer Unterschied besteht jedoch in der Vermarktung: die Software soll auch anderen Unternehmen zur Verfügung gestellt werden. Durch das auf viele Bereiche übertragbare Konzept, scheinen Skaleneffekte durchaus für möglich.

Die „Remote AR“ genannte Software liefert eine Lösung, die komplett auf die Unterstützung von Technikern durch weitere Experten abzielt. Dabei kann der am Einsatzortbefindliche Techniker wahlweise ein Tablet, ein Smartphone oder eine Datenbrille einsetzen. Ruft er den Experten an, so wird das Kamerabild des gewählten Devices übertragen. Der Experte wiederum kann ein Tablet, ein Smartphone, einen Laptop oder einen Desktop benutzen. Beide Parteien können das Video annotieren. So können beispielsweise reale Objekte markiert werden. Die Markierungen bleiben bei der Bewegung des Kamerabildes am realen Objekt haften. Die Verantwortlichen weisen darauf hin, dass die Einsatzorte von Technikern oft keine breitbandige Internetverbindung hergeben. Daher ist ein wichtiger Gesichtspunkt von „Remote AR“, trotz niedriger Bandbreite ein akzeptables Bild zu übertragen. Bei zu schlechter Verbindung kann zusätzlich auf die Funktion der Annotation eines hochauflösenderen Standbildes zurückgegriffen werden.

Das Prinzip der App bietet eine Reihe von Einsatzmöglichkeit, die sich nicht zuletzt auf Grund der flexiblen technischen Gestaltung ergeben. Es ließen sich jedoch leider keine Zahlen darüber finden, wie groß der Benefit für Caterpillar oder andere „Remote AR“-benutzende Unternehmen sind.

Quellen / Weiterführende Informationen:

Boeing

In der Produktion von Flugzeugen werden äußerst komplexe Kabelbäume konstruiert. Die damit betrauten Techniker benutzen in aller Regel tragbare Computer, auf denen PDFs mit Schaltplänen geöffnet sind. Sie sind ständig auf der Suche nach bestimmten Stecker- und Anschlussbelegungen. Dafür wird der übliche STRG+F Shortcut benutzt. Techniker müssen also sehr häufig neben ihrer eigentlichen Arbeit ihre Hände benutzen, um den Computer zu bedienen. Boeing hat bereits vor mehr als 20 Jahren in diesem Bereich einen Optimierungsbedarf erkannt. Im Jahre 1995 starteten Experimente mit damals noch äußerst teuren und unergonomischen AR-Brillen. Diese Experimente wurden ungleich vielversprechender, als Google Glass veröffentlicht wurde. Die mit der Entwicklung einer Softwarelösung betraute Firma APX Labs entwickelt seitdem an einer vielversprechenden Softwarelösung, die aktuell den Namen Skylight App trägt.

Die Daten, welche dem Techniker zur Verfügung gestellt werden, werden durch das System nach dem Einscannen von QR-Codes ermittelt. So muss sich der Techniker zunächst über einen am Computer generierten QR-Code authentifizieren. Danach scannt er den QR-Code auf der Box mit den Bauteilen ein. Auf seinem Head-Mounted Display erscheinen daraufhin Status Updates, weitere Notizen und die Informationen über seine nächste Aufgabe. Die Skylight App kann sowohl mit Gesten als auch mit Sprachbefehlen gesteuert werden. Für die Suche bestimmter Stecker- und Anschlussbelegungen müssen die Hände somit nicht mehr benutzt werden. Diese bleiben stattdessen frei für die eigentliche Arbeit. Auch die Skylight App unterstützt das Hinzuziehen eines Experten per Videostream für Probleme, die der Techniker von sich aus nicht lösen kann. Außerdem hat er die Möglichkeit auf ein Videoarchiv zuzugreifen, in dem Möglicherweise bereits Lösungen für das Problem beschrieben sind.

Nach der Beendigung der Pilotphase Mitte des Jahres 2016 wurde festgestellt, dass die Montagezeiten der äußerst komplexen Kabelbäume um 25% reduziert werden konnten. Gleichzeitig sind bei der Montage nur noch halb so viele Fehler aufgetreten. Als die beiden größten Herausforderungen in der bisher 5-jährigen Entwicklungszeit, bezeichnen die Entwickler den verlässlichen Datenbezug aus den verschiedenen Legacy Systemen und den Umgang mit sensible Geschäftsdaten.

Quellen / Weiterführende Informationen:

Thyssen Krupp Fahrstuhl Reparatur

Thyssen Krupp geht in mindestens einem Punkt einen anderen Weg als die zuvor beschriebenen Firmen. Die Partnerschaft mit Microsoft und der Einsatz der HoloLens ermöglichen die Interaktion mit 3D-Visualisierungen im realen Raum. So kann bei Auftragseingang bereits ein 3D-Modell des betroffenen Aufzugs angezeigt werden. Für die Ausreizung der Mächtigkeit dieser Funktionalität ist es erforderlich, dass der zu wartende Aufzug mit dem internen IoT-System MAX ausgestattet ist. In diesem Fall wird dem Techniker das betroffene Bauteil im 3D-Modell visualisiert. Auch für Schulungszwecke können die 3D-Modelle herhalten. Per Gestensteuerung kann der Aufzug in seine Einzelteile zerlegt werden, was für ein besseres Verständnis insbesondere beim unerfahrenen Techniker führt. Einen vergleichbaren Ansatz verfolgt Japan Airlines.

Ansonsten ist das Einsatzszenario Thyssen Krupps vergleichbar mit den zuvor beschriebenen Fällen. Auch Thyssen Krupp stellt die Hinzuziehung eines Experten über einen Videostream und bidirektionalen Audiokanal zur Verfügung. Ist der Techniker am Einsatzort angekommen, können relevante Informationen über die Reparaturhistorie angezeigt werden.

Thyssen Krupp geht davon aus, dass die Arbeit durch den Einsatz der HoloLens nicht nur schneller, sondern auch sicherer verrichtet werden kann. Von dem im letzten Jahr gestarteten Pilotprojekt wurden diesbezüglich jedoch noch keine Zahlen veröffentlicht.

Quellen / Weiterführende Informationen:

Vision Picking im Warenlager

DHL hat bereits im Jahr 2014 ein groß angelegtes Pilotprojekt in Zusammenarbeit mit Vuzix in einem niederländischen Warenlager begonnen. Die Ergebnisse waren so überzeugend, dass die Erprobungsphase verlängert und auf weitere Warenlager in den Vereinigten Staaten, Großbritannien und dem europäischen Festland ausgeweitet wurde. Im ersten Pilotprojekt in Bergen op Zoom bei der Firma Ricoh wird die Kommissionierung durch den Einsatz einer Datenbrille unterstützt. Die Datenbrille hat sowohl den bisher verwendeten Handscanner als auch die Kommissionierungsliste abgelöst. Die Lageristen haben somit zu jeder Zeit freie Hände.

Das betroffene Lager zeichnet sich durch eine hohe Standardisierung aus. Die Lageristen haben haben Trolleys mit Packstücken zu befüllen, deren Lagerort im System mit einer eindeutigen Bezeichnung versehen ist. Beginnt der Lagerist seine Schicht, so scannt er zunächst mit der Datenbrille seinen Dienstausweis ein und begibt sich zum nächsten verfügbaren Trolley. Das Scannen des am Trolley befindlichen Strichcodes sorgt dann für die Einblendung der Aufgabenbeschreibungen mit Informationen zum Standort (Gang- und Regalnummer) des nächsten Packstücks und der benötigten Menge. Außerdem wird der Trolley grafisch dargestellt und diejenigen Boxen visuell hervorgehoben, in die das Packstück einsortiert werden soll. Nachdem alle benötigten Exemplare des ersten Packstücks im Trolley untergebracht sind, werden die entsprechenden Informationen zum nächsten Packstück eingeblendet.

DHL und Ricoh stellten als Ergebnis der ersten Tests eine deutliche Steigerung der Produktivität, gesunkene Fehlerraten und eine Steigerung der Zufriedenheit der Mitarbeiter fest. Der positive Einfluss, den Augmented Reality auf die Realität haben kann, war hiermit unter Beweis gestellt. Die Steigerung der Effizienz um 25% war Grund genug, die Erprobungsphase auf viele weitere Warenlager auszuweiten.

Quellen / Weiterführende Informationen:

Die Menschliche Komponente im Online Shopping

GoInStore bietet mit seiner Softwarelösung eine Möglichkeit für Händler mit Kunden stärker in Kontakt zu treten. So soll beispielsweise in einem Onlineshop für interessierte Kunden mittels eines Buttons die Möglichkeit bestehen, mit einem Kundenberater in Kontakt zu treten. Auf Grund von Variablen wie der Nähe zum Kunden oder der Expertise des Kundenberaters soll dann automatisch der Kontakt zum bestgeeigneten Berater hergestellt werden.

Der Verkäufer trägt die Datenbrille Epson Moverio. Sein Bild wird direkt an den Kunden übertragen. Zeitgleich besteht eine beidseitige Audioverbindung. So soll der Kunde einen besseren Eindruck von vor allem höherwertigen Produkten bekommen. GoInStore verspricht, durch Beratung und emotionale Komponenten eine höhere Conversionrate.

Ein aktuelles Pilotprojekt findet gerade in Hotels des Marriott European Convention Networks statt. Es ist zu erwähnen, dass diese Technik bisher nicht im großen Stil umgesetzt wurde. Verlässliche Zahlen darüber, in wie weit Kunden den Service tatsächlich honorieren, ist nicht herauszufinden.

Quellen / Weiterführende Informationen:

Jaguars Auto Neuvorstellung mit einer VR-Brille

Doch nicht nur AR, sondern auch VR, könnte nutzenstiftend sein. So hat beispielsweise Jaguar im letzten Jahr vor der Los Angeles Auto Show sein in der Entwicklung befindliches Modell I-PACE rein virtuell vorgestellt. Hier dürfte vor Allem der Showeffekt im Mittelpunkt stehen. Gleichzeitig entfällt die Aufwändige Erstellung eines realen Prototyps.

Quellen / Weiterführende Informationen:

Platzierung virtueller Möbel im eigenen Zuhause

Es gibt eine Reihe von Apps die auf handelsüblichen Smartphones funktionieren und den Benutzern bereits heute Augmented Reality ins Wohnzimmer liefern. Hier seien Beispielhaft Apps von vier verschiedenen Firmen genannt:

Während Converse eine virtuelle Schuhanprobe ermöglicht, soll die Lego App für eine bessere Vorstellung von den angebotenen Produkten sorgen. Sowohl die Ikea App als auch ViewAR bieten die Möglichkeit, virtuelle Möbel in real existierenden Räumen zu platzieren. Die Apps benötigen ein Referenzobjekt, welches im Falle von Lego und Ikea die jeweiligen Produktkataloge sind. Die virtuellen Objekte werden daraufhin anhand der im Raum liegenden Produktkataloge ausgerichtet.

Augmented-Reality-Brillen

Die beschriebenen Nutzungsszenarien lassen die Vermutung zu, dass AR-Brillen insbesondere in internen Geschäftsprozessen ihre Stärke ausspielen. Während die Benutzung von VR-Brillen und AR-Technologien auf Smartphones das Endkundenerlebnis steigern soll, werden AR-Brillen dazu eingesetzt, Geschäftsprozesse effektiver und effizienter zu gestalten. Zwar finden wir all diese Technologien äußerst interessant, beschränken uns jedoch in diesem Artikel auf die beschriebenen Geschäftsprozesse und somit auf AR-Brillen.

Im Internet finden sich Informationen zu zahlreichen verschiedenen Brillen. Dabei übersteigt das Angebot deutlich die in den Nutzungsszenarien des vorherigen Kapitels eingesetzten Geräte. Eine Bewertung der Ausgereiftheit der einzelnen Produkte würde rein spekulativen Charakter haben. Wir beschränken uns im Folgenden daher auf die in den beschriebenen Projekten eingesetzten Brillen. Wir lassen die Google Glass außen vor, da ihr Vertrieb eingestellt wurde. Somit bleiben drei Brillen für die nähere Untersuchung übrig: Vuzix m100, Epson Moverio BT-300 und Microsoft HoloLens.

Spezifikationen

Wir betrachten zunächst die technischen Spezifikationen der Brillen und stellen diese einander gegenüber.

Vuzix m100 Epson Moverio BT-300 Microsoft HoloLens
Preis 1,079.99 € 849,00 € 3.299,00 €
Display-Art Undurchsichtiges LCD-Display Halbtransparentes OLED-Display Prisma-Projektor (Durchsichtig)
Bildschirm-auflösung 432 x 240 2 * (1.280 x 720) 2 * (1.268 x 720)
Sichtfeld 15° 23° 30°
Prozessor Dual Core 1,2 GHz Intel® Atom™ x5, 1.44GHz Quad Core 1.04Ghz Intel Atom x5-Z8100
RAM 1 GB 2 GB 2 GB
Interner Speicher 4 GB 16 GB 64 GB
Externer Speicher 32 GB (Micro SD) microSD (max. 2 GB), microSDHC (max. 32 GB) –
Sound Ja Ja Ja
Mikrofon Ja Ja Ja
Kamera 1080p Video + 5 MP Foto 5 MP 2 MP (Auch Hologramme aufnehmbar) + Tiefenkamera
GPS Ja Ja –
Konnektivität WLAN, Bluetooth, Micro-USB WLAN, Bluetooth, Micro-USB WLAN, Bluetooth, Micro-USB
Steuerung 4 control buttons, Remote control app (iOS & Android), Stimme, Gesten Touchpad an externer Steuereinheit Stimme und Handgesten
Betriebssystem Android 4.04 Android 5.1 Windows 10
Akkulaufzeit 2 h 6 h 2 h
Autarker Betrieb Ja, kann aber auch mit Smartphone gekoppelt werden Nein, verbunden mit externer Steuereinheit Ja

Der große Unterschied zwischen der HoloLens und den anderen Geräten wurde bereits in der Einleitung durch die Art der Anreicherung der Umwelt durch virtuelle Objekte beschrieben. Im Folgenden beschreiben wir ergänzend weitere Aspekte, die bei der Planung eines praktischen Einsatzes von AR-Brillen unserer Meinung nach berücksichtigt werden sollten.

Displays

Die Vuzix m100 verfügt lediglich über ein einseitiges Display. Zwar ist die Seite wählbar, jedoch kann immer nur ein Auge das Display sehen. Sie ist außerdem mit einem herkömmlichen Display ausgestattet, das im äußeren Sichtbereich eines Auges platziert wird und somit das Sichtfeld auf die Realität einschränkt, selbst wenn keine Informationen präsentiert werden. Anders bei Epson Moverio BT-300 und der HoloLens, bei denen das transparente Display vor beiden Augen platziert ist. Die Anreicherung der Realität mit weiteren Daten ist somit optional. Die Realität kann bei ausgeschaltetem Display uneingeschränkt wahrgenommen werden.

Interaktion mit der Brille

Ein weiterer großer Unterschied zwischen den Geräten besteht in der Interaktion. So ist es bei der Brille von Epson zwingend erforderlich, eine externe Steuereinheit in der Größe eines Smartphones mitzutragen. Dieses ist über ein Kabel mit der Brille verbunden und stellt ein Touchpad bereit. Sowohl HoloLens als auch Vuzix m100 ermöglichen die Steuerung per Stimme und Gesten. Außerdem stellt die Vuzix m100 darüber hinaus Bedienelemente an der Brille selbst bereit.

Akkulaufzeit

Für den Einsatz von AR-Brillen im Unternehmensalltag ist die Akkulaufzeit von essenzieller Bedeutung. Gerade in diesem Punkt gibt es großen Nachholbedarf. Vuzix m100 und HoloLens machen bereits nach 2 Stunden schlapp. Die Epson Moverio BT-300 profitiert hier vom Platzangebot der externen Steuereinheit in der der verhältnismäßig große Akku untergebracht ist. Dennoch hält sie ohne Pitstop an der Steckdose keinen 8-stündigen Arbeitstag durch. Hier verspricht die Vuzix m300 deutliche Verbesserungen. Externe Akkus sorgen je nach Größe für eine 2 – 12 stündige Laufzeit und können auf Grund der im Brillenrahmen verbauten internen Batterie zur Laufzeit ausgewechselt werden. Die Vuzix m300 ist jedoch aktuell nur für Premium Partner von Vuzix verfügbar.

Entwicklungsumgebung und verfügbare Apps

Die HoloLens arbeitet mit Windows 10. Die Entwicklung findet in C# und Unity statt. Es gibt einen Emulator, so dass die HoloLens bei der Entwicklung nicht verfügbar sein muss. Die beiden anderen vorgestellten Brillen setzen auf Android. Somit haben Entwickler, die sich bereits mit der Entwicklung von nativen Android Apps auseinandergesetzt haben, einen leichteren Einstieg.

Neben der Eigenentwicklung von Apps steht Standardsoftware zur Verfügung. Das Angebot der App Stores ist über folgende Links einzusehen:

Verschiedene Entwickler stellen die Apps entweder kostenlos oder gegen ein Entgelt bereit. So ist beispielsweise für die Vuzix m100 eine „Collaboration App“ von Atheer erhältlich, welche die Möglichkeit bietet, mit Experten per Livevideo Kontakt aufzunehmen und mit ihnen zu telefonieren. Außerdem können Videos annotiert werden. Es ist somit möglich, mit dieser App bereits einige der obigen Testszenarien zu realisieren. Atheer, der Hersteller der App, hat bereits Partnerschaften mit weiteren Herstellern von AR-Brillen wie recon, Epson und ODG geschlossen. Zum Zeitpunkt des Verfassens des vorliegenden Artikels haben wir die App jedoch nicht im Store von Epson gefunden.

Outdoor Nutzung

Für die Outdoor Nutzung bestehen zwei Anforderungen: eine hohe Bildschirmhelligkeit und eine hohe Robustheit gegenüber äußeren Einflüssen wie Regen, Staub und Stößen. Von den zu betrachtenden Geräten ist keines für seine Wasserdichtigkeit zertifiziert. Es gibt jedoch Geräte auf dem Markt, bei denen dies der Fall ist. Als Beispiel sei die ODG R-7 genannt, welche wir jedoch auf Grund fehlender größerer Pilotprojekte nicht näher betrachten.

Dennoch sind sowohl die Vuzix m100 als auch die Epson Moverio BT-300 laut Hersteller Outdoor tauglich. Anders sieht es bei der HoloLens aus. Microsoft hat die HoloLens explizit für den Gebrauch im Innenraum konzipiert. So ist auch der vergleichsweise dunkle Bildschirm zu erklären. Epson löst das Problem der möglicherweise schwierigen Lichtverhältnisse im Außenbereich durch die Bereitstellung von getönten Brillengläsern. Mit ihnen soll es dem Träger möglich sein, das Display selbst bei starker Sonneneinstrahlung abzulesen.

Navigation

Die Navigation ist ein vielversprechender Ansatzpunkt für den Einsatz von AR-Brillen. Dabei kommt es jedoch zu besonderen Herausforderungen. Zur näheren Erläuterung unterscheiden wir die Indoor von der Outdoor Navigation.

Die Indoor Navigation ist theoretisch möglich durch:

  • Beacons (1-3m)
  • WiFi (5-15m)
  • UWB (10-30cm, aber zusätzlicher „Locator Tag“ auf Seiten des Nutzers nötig)

Die in Klammern angegebenen Messgenauigkeiten wurden durch eine Internetrecherche auf Seiten von spezialisierten Unternehmen gewonnen. Wir halten diese Zahlen für optimistisch. Bei eigenen Tests der Navigation mit der Beacontechnologie und WiFi kamen wir unter realistischen Bedingungen stellenweise auf eine 100% höhere Abweichung. UWB weist im Gegensatz zur Navigation mit Beacons und WiFi eine ausreichende Genauigkeit auf, ist jedoch durch seine hohen Anschaffungskosten und die zusätzliche Belastung des Nutzers durch den „Locator Tag“ nur unter speziellen Bedingungen wirtschaftlich bzw. komfortabel. Die betrachteten AR-Brillen unterstützen allesamt die Navigation mit den drei genannten Techniken. Microsoft bietet mit der HoloLens noch eine weitere Technik. Durch ihre Tiefenkamera ist sie in der Lage, die Umgebung zu erfassen und ein virtuelles 3D-Modell zu erstellen. Ebenso können bereits vorhandene 3D-Modelle in der HoloLens geladen werden. Sie ist in der Lage in diesem Modell punktgenau zu navigieren. Gaze Tracking führt dazu, dass sogar die Lage des Kopfes ermittelt werden kann.

Die Genauigkeit der Outdoor Navigation über GNSS für die zivile Nutzung hängt stark von den Empfangsbedingungen ab. Dabei können unter guten Bedingungen die Abweichungen von der realen Position durchaus auf bis zu 3m sinken. In der Regel ist die Abweichung jedoch weitaus größer. In der Praxis ist GNSS hauptsächlich für die Navigation auf Straßen sinnvoll. Anders sieht es aus, wenn kleinere Wege relevant werden, welche dicht beieinander liegen. Dann stoßen selbst softwareseitige Korrekturmaßnahmen an ihre Grenzen. Auf Grund des vorhanden GPS Sensors sind sowohl Vuzix m100 als auch Epson Moverio für die Outdoor Navigation somit eingeschränkt geeignet. Die Navigation mit Hilfe eines 3D-Modells wie oben beschrieben ist grundsätzlich auch im Außenbereich möglich, im Falle der HoloLens jedoch nicht vom Hersteller empfohlen.

Zusammenfassung und Ausblick

Die Nutzungsszenarien der AR-Brillen sind sehr vielversprechend. Die bisher durchgeführten Pilotprojekte zeigen, dass das Potenzial zur Steigerung der Effizienz der Geschäftsprozesse groß ist. Nichtsdestotrotz sollte beachtet werden, dass die Technik noch am Beginn ihrer Entwicklung ist. Viele der zu Promotionszwecken erstellten Videos der Hersteller der AR-Brillen scheinen noch Zukunftsmusik zu sein. Dabei konnten im vorliegenden Artikel vor allem die fehlende Robustheit, die limitierte Akkulaufzeit und die nur eingeschränkt mögliche Navigation als Hemmnisse identifiziert werden. Ergonomie und Optik dürften hingegen insbesondere bei den reinen Datenbrillen keine großen Hürden mehr für einen praktischen Einsatz darstellen. Die Entwicklungen bei den Geräten gehen in eine vielversprechende Richtung. Aktuell sind sie zwar noch nicht uneingeschränkt für den professionellen Einsatz zu empfehlen, jedoch scheinen sie in die richtige Richtung zu gehen. Dennoch kann eine Beschäftigung mit dem Thema AR im Unternehmen und der Einsatz noch nicht ausgereifter AR-Brillen bereits jetzt wertvolle Erkenntnisse liefern. Gesammelte Erfahrungen können sich bereits in einigen Jahren auszahlen.

Gerade der Remote Support scheint ein dankbares Einsatzszenario von AR-Technik zu sein. Es ist absehbar, dass bereits in naher Zukunft AR-Brillen soweit sein werden, dass sie komfortabel über einen kompletten Arbeitstag eingesetzt werden können. Bereits jetzt steht Standardsoftware zur Verfügung, die Funktionen für den Remote Support bereitstellt. Sollen Daten aus Legacy Systemen wie im Fall von Boeing bereitgestellt werden, so scheint dennoch eine Individuallösung die einzig mögliche Wahl. Auch das Vision Picking im Warenlager kann bereits in naher Zukunft durch AR-Brillen gut unterstützt werden, sofern die organisatorischen Rahmenbedingungen im Warenlager hierzu geeignet sind. Als realistisches Szenario kann hier das oben beschriebene Pilotprojekt der DHL dienen. Ein Szenario wie es SAP in Zusammenarbeit mit Vuzix visualisiert hat, scheint hingegen noch in weiter Ferne.

Darüber hinaus lohnt ein Blick über den Tellerrand. Der Einsatz anderer Devices wie Smartphones oder VR-Brillen kann je nach Szenario die bessere Wahl sein. Zusammenfassend bietet die AR-Technologie vielversprechende Möglichkeiten, die aller Voraussicht nach bereits in naher Zukunft Geschäftsprozesse in Unternehmen sinnvoll unterstützen können. Dennoch sollte eine allzu euphorische Heransgehensweise, die leicht unter dem Einfluss von beeindruckendem Marketingmaterial der Brillenhersteller entstehen kann, vermieden werden. Durch die in diesem Artikel genannten kritischen Aspekte, wollen wir einen Beitrag zum besonnenen Einstieg in das Thema Augmented Reality liefern.

Quellen / Weiterführende Informationen:
  • Van Krevelen & Poelman (2010): A Survey of Augmented Reality Technologies, Applications and Limitations
Veröffentlicht unter Strategy & Methods | Verschlagwortet mit , | Kommentar hinterlassen

Design Thinking: 6-Hüte-Methode

Veröffentlicht am 11. Mai 2017 von

Design Thinking wird oft als Methodik im Zusammenhang mit Prozessoptimierung oder Innovation genannt. Der Design Thinking-Prozess besteht aus mehreren Abschnitten wobei jedem Abschnitt mehrere einschlägige Methoden zugeordnet werden. Diese können je nach Problemstellung verwendet werden. Antworten auf Fragen „Wie könnten wir…?“ lassen sich am besten mit Hilfe von Brainstorming evaluieren, um mehrere Optionen möglichst objektiv und aus unterschiedlichen Blickrichtungen zu bewerten empfehlen sich Methoden wie die 6-Hüte-Methode oder die Walt-Disney-Methode. Wir fokussieren uns auf die 6-Hüte-Methode von De Bono.

Diese Methode wurde von OC in unterschiedlichen Projektkontexten erfolgreich verwendet. Die Methode ist denkbar einfach. Und in der IT-Welt kennt man sowas ähnliches aus dem Aufwandsschätzungsverfahren, wo in drei Schätzungsiterationen die Arbeitspakete pessimistisch, normal und optimistisch geschätzt werden, anschließend wird der Aufwand normiert. So ähnlich funktioniert auch die 6-Hüte-Methode. Innerhalb einer ausgewählten Stakeholdergruppe geben die Personen jeweils ein Statement aus unterschiedlicher Denkrichtung ab. Die Denkrichtung wird je nach dem „aufgesetztem Hut“ bestimmt.

6hats.png

  • Weißer Hut: analytisches Denken: Konzentration auf Tatsachen, Anforderungen und wie sie erreicht werden können (objektiv)
  • Roter Hut: emotionales Denken, Empfinden: Konzentration auf Gefühle und Meinungen (subjektiv)
  • Schwarzer Hut: kritisches Denken: Risikobetrachtung, Probleme, Skepsis, Kritik und Ängste mitteilen (kritisch)
  • Gelber Hut: optimistisches Denken: was ist das Best-Case Szenario (spekulativ)
  • Grüner Hut: kreatives, assoziatives Denken: neue Ideen, Kreativität (konstruktiv)
  • Blauer Hut: ordnendes, moderierendes Denken: Überblick über die Prozesse

Nachfolgend wird erklärt, wie die Bewertung stattgefunden hat. Dies soll exemplarisch die Funktionsweise der Methode zeigen.

Als Diskussions-/Bewertungsgrundlage wurden 3 zuvor ausgearbeitete Optionen genommen, diese werden hier nicht näher beleuchtet. Zu jeder Option wurden von jedem Stakeholder jeweils ein Vor- und ein Nachteil aus jeder der 5 Denkrichtungen erhoben. 5 Denkrichtungen, weil die 6 Denkrichtung dem Blauen Hut zugeordnet wird und entspricht der Rolle des Moderators.

Fazit

Wurden alle Vor und Nachteile erhoben findet eine Sortierung dieser statt, um Doppelungen zu vermeiden. Anschließend wird gezählt und bewertet. So einfach kommt man mit dieser Methode zum Ziel und die Beteiligten sind dabei begeistert, denn wenn man die Personen geschickt durch den Prozess führt, fällt dieser gar nicht als schwer und langweilig auf.

Veröffentlicht unter Strategy & Methods | Verschlagwortet mit , , | Kommentar hinterlassen