Einleitung

Um Effizienz sowie Effektivität von Produktionsprozessen zu steigern, werden zunehmend Techniken und Methoden aus dem Gebiet der Data Analytics in der Industrie eingesetzt. Maschinen und andere Geräte sind in den Fabriken heutzutage mit einer größeren Anzahl an Sensoren ausgestattet, so dass eine umfängliche Datengrundlage für analytische Techniken und Methoden entsteht. Zur Verarbeitung dieser Daten ist es notwendig, diese zunächst über ein Netzwerk auf einen Server zu übertragen, so dass analytische Algorithmen Anwendung finden können. Dabei tritt das Thema der Latenzzeit für den Einsatz von Analytics in Echtzeit im Rahmen des Produktionsprozesses in den Vordergrund. Für viele Anwendungen innerhalb der Produktionsumgebung ist es von entscheidender Bedeutung, die analytische Verarbeitung in (nahezu) Echtzeit zu betreiben. Andernfalls verlieren die erzeugten Ergebnisse ihren Nutzen, führen zu Fehlern oder sogar zu einem Produktionsstopp. Auch Produktionsleitsysteme (Manufacturing Execution Systems, MES), welche ihren Ursprung bereits in den 1980er Jahren haben, stoßen mit herkömmlichen Netzwerk-Architekturen hierbei an ihre Grenzen [1].

Edge Computing

Heutzutage produziert die stetig steigende Anzahl verbauter Sensoren, die als Datenproduzenten angesehen werden können, große Datenmengen an der Edge (Ecken oder Rand) eines Netzwerks [3]. Durch die steigende Datenmenge stößt die zentrale Datenverarbeitung, beispielsweise durch Cloud Computing (CC), an ihre Grenzen. Der Transfer aller erhobenen Daten in die Cloud, um diese dort zu verarbeiten nimmt zu viel Zeit in Anspruch und macht eine Verarbeitung in Echtzeit nahezu unmöglich [2].

Herkömmliche Client-Server Architekturen haben den Nachteil, dass die zentralisierte Datenverwaltung und -verarbeitung einen Engpass darstellt, welcher durch Überlastung zu erheblichen Verzögerungen führen kann [78]. Ein Konzept um Bandbreite zu sparen und die hohen Latenzzeiten, die beim Datentransfer in die Cloud entstehen, zu minimieren ist EC. Der dezentrale Ansatz verfolgt das Ziel die Datenverarbeitung nicht in der Cloud, sondern an der Edge durchzuführen [4]. Dabei lässt sich die Edge als Rechen-oder Netzwerkressource definieren, die sich entlang des Pfades zwischen dem Datenproduzenten und der Cloud befinden [2]. Die Objekte, welche die Rechenoperationen verarbeiten, werden als Fog-oder Edge Knoten (Node) bezeichnet und befinden sich an der oben genannten Edge des Netzwerkes [3]. Neben der Bezeichnung EC ist zuvor bereits der Begriff Fog Computing (FC) genutzt worden. Dieser wurde im Jahr 2011 von Cisco präsentiert und wie folgt definiert: "FC is a highly virtualised platform that provides compute, storage and networking services between end devices and traditional cloud computing data centres, typically, but not exclusively located at the edge of the network. [7]" Darüber wird FC von Varghese et al. [8] als Ergänzung zu CC zur Dezentralisierung von Rechenressourcen mit dem Ziel, die Servicequalität zu verbessern beschrieben [8,9]. Dabei stellt die Virtualisierung eine Schlüsseltechnologie im Bereich von FC dar. Aufgrund immer leistungsfähiger Rechenhardware wurde diese mit dem Ziel entwickelt die Verschwendung von Ressourcen zu minimieren und die Nutzung der Hardware für mehrere Anwendungen parallel zu ermöglichen. Dies vereinfacht die Wartung und Pflege der Systeme und bringt zugleich Vorteile im Bereich der IT-Sicherheit mit sich [10] .

In diesem Kontext argumentiert IBM ähnlich wie Cisco; sie verwenden jedoch den Begriff des EC [26]. Obwohl in der wissenschaftlichen Diskussion gegensätzliche Meinungen vorhanden sind, die zwischen den Konzepten EC und FC unterscheiden, werden diese in einigen Publikationen synonym verwendet [2,11,12].

Ergebnisse der Literaturanalyse

Um die zu untersuchende Literatur zu klassifizieren, erfolgte zunächst die Betrachtung der Abstracts der identifizierten Beiträge. Dabei erfolgte eine Zusammenfassung der Beiträge anhand ihrer Leitthemen manuell in einzelne Cluster. Basierend auf den inhaltlichen Schwerpunkten der Artikel resultiert jeweils eine Bezeichnung zur Kennzeichnung der genutzten Gruppen, die im Weiteren zur Identifikation der thematischen Ausrichtungen der 65 Publikationen dient: theoretisch-strukturorientiert, anwendungsorientiert, sicherheitsorientiert und analytisch orientiert.

Theoretisch-strukturorientierte Veröffentlichungen

Mit 26 der 65 relevanten Publikationen fand für mehr als ein Drittel der identifizierten Beiträge eine Einordnung in die Hauptklasse theoretisch-strukturorientiert statt. Da es sich bei EC um eine Netzwerkarchitektur handelt, ist dieser hohe Anteil nicht überraschend. Der Fokus dieser Publikationen liegt hierbei größtenteils in den Bereichen der Architektur, einer begriffenen Auseinandersetzung mit dieser sowie der Diskussion der Eigenschaften von EC-Architekturen.

Begriffe. In der betrachteten Diskussion ist eine begriffliche Auseinandersetzung der Konzepte EC und FC enthalten. Es herrscht jedoch Uneinigkeit, inwieweit die Konzepte sich überscheiden und welche Unterscheidungen hervorgehoben werden müssen. Während Shi et al. [2] und Yi et al. [11] die beiden Konzepte synonym verwenden, unterscheiden Jang et al. [14] wie folgt: EC beschreibt eine Komponente oder Teilmenge von FC. Während FC die Art und Weise wie Daten über den kompletten Prozess verarbeitet werden beschreibt, bezieht sich EC laut dieser Meinung nur auf die Verarbeitung der Daten in der Nähe des Sensors, an dem Daten erzeugt werden. Weiterhin beschreiben Escamilla-Ambrosio et al. [9] folgende zwei Hauptunterschiede zwischen EC und FC: 1) FC arbeitet mit der Cloud, während EC durch den Ausschluss der Cloud definiert ist. 2) FC ist eine mehrschichtige und hierarchische Architektur, während EC eine Beschränkung auf drei oder vier Schichten vorsieht. Das Ziel, Cloud-Ressourcen und -Dienste näher an die Geräte, Sensoren und andere Datenproduzenten zu koppeln, ist jedoch für EC und FC identisch [9]. Um dieses Ziel zu erreichen werden Fog-oder Edge-Schichten genutzt, die zu einem Paradigmenwechsel innerhalb der Netzwerkinfrastruktur führen [28]. Diese Schichten arbeiten dabei wie eine Brücke zwischen dem Internet of Things (IoT), den Datenproduzenten und den entfernten Datenzentren [15]. EC oder FC stellen in diesem Zusammenhang keine Alternative zum CC dar. Vielmehr werden, um große Datenmenge in geringer Zeit verarbeiten zu können, Kombinationen aus Cloud-und Edge Schichten genutzt. Daher wird EC auch als Erweiterung des CC angesehen [37].

Eigenschaften. Die Implementierung einer EC-Architektur kann die Lasten im Netzwerk innerhalb der Fabrik erheblich reduzieren [17]. Luntovskyy und Nedashikivskiy [15] halten zudem folgende Eigenschaften von FC fest: geringe Latenz, Standortwahrnehmung, weite geografische Verteilung, große Anzahl an Knoten, Mobilität, IPv6 empfohlen, Streaming und Echtzeitanwendungen sowie Heterogenität der Knoten. Die Auswirkungen auf Effizienz und Flexibilität des Unternehmens sowie auf das Ressourcenmanagement und die Vorteile gegenüber CC sind neben den zuvor genannten, die Verringerung der Distanz zwischen Client und Server, welche Verzögerungen reduzieren und eine Interaktion in Echtzeit möglich machen. Zudem lassen sich Vorteile im Bereich Mobilität der einzelnen Knoten ausmachen [31].

Architektur. Verbreitet in der betrachteten Literatur ist die 3-Tier-Architektur [2,8,15,14,19,20]. Eine solche Architekturform kann durch ihre hohe Verbreitung als Grundlage für EC oder FC angesehen werden. Nodes-, Fog-oder Edge Schichten befinden sich dabei innerhalb des physischen Standorts der datenproduzierenden Geräte, während die Cloud Schicht außerhalb liegt [38]. Auch Architekturen mit mehr als drei Schichten sind möglich und werden in der Literatur diskutiert. Beispielsweise veröffentlichten Shaaban et al. [18] ein Referenz-IoT-Modell mit dem Namen Cloud Web of Things (CloudWoT). Aber auch die Blockchain Technologie findet Einsatz bei dem Aufbau von EC-Architekturen [14,39].

Die Bezeichnung der verschiedenen Schichten (Layer) und Geräte sind in der bestehenden Literatur nicht konsistent und können daher zu Verwirrung führen. Ein verbreiteter Ansatz ist die Bezeichnung Edge Device für ein Gerät innerhalb der Nodes Schicht. Dies kann beispielsweise ein Sensor in einer einzelnen Maschine sein [32]. Der Begriff Edge Node beschreibt dagegen einen Router oder einen Switch innerhalb der Fog oder Edge Schicht [9].

Anwendungsorientierte Veröffentlichungen

Etwa 40% der untersuchten Publikationen ließen sich der Hauptklasse anwendungsorientiert zuordnen. In den meisten dieser Beiträge werden spezifische Smart-Factory-Szenarios erörtert. Dabei werden Anwendungen für verschiedene Branchen und Bereiche, Techniken und Methoden sowie verschiedene Protokolle und Frameworks in der betrachteten Literatur diskutiert.

Branchen und Anwendungsbereiche.

McKee et al. [29] veröffentlichten einen Überblick über den Stand der Technik in den Bereichen Automatisierung, Autonomes Fahren, Energieeffizienz, Smart Manufacturing in Industrie 4.0 und Gesundheitswesen, wobei eine Relevanz von EC diesen Bereichen festgehalten wird. Im Gesundheitswesen finden EC-Architekturen beispielsweise bei Smart Healthcare System Anwendung [40]. Ashjaeiet et al. [38] haben in diesem Kontext erörtert, dass EC im Bereich des Wartungs-und Instandhaltungsmanagements nutzenstiftend eingesetzt werden kann. Dabei ist es nötig, dass das auslösende Ereignis, beispielsweise eine kritische Information eines Sensors, mit möglichst geringer Latenzzeit beantworten werden kann. Für ein solches Szenario ist eine reine cloudbasierte Lösung im Gegensatz zu einer EC-Architektur ungeeignet. Weitere Publikationen diskutieren den Einsatz von EC-Architekturen im Bereich von Predictive Maintenance. Dabei besteht das Ziel darin, die Maschinenlebenszeit durch die Minimierung der Datenübertragungszeiten und der Verminderung des Energieverbrauches zu erhöhen [33]. Auch im Bereich des Supply Chain Management finden EC-Architekturen Einsatz. Zhang et al. [39] nutzt dafür die Blockchain Technologie, um Wissen über die gesamte Lieferkette im Bereich des Supply Chain Management zu teilen. Wang et al. [31] betrachten den Einsatz von FC in einer logistischen Produktionskette und nennt die reibungslose Bereitstellung aller nötigen Information für alle beteiligten Personen als Hauptvorteil [31]. Auch in den Bereichen der Geo-IoT [41], Smart Grids [42] und der Entwicklung des 5G Netzes [43] werden EC-Architekturen verwendet und diskutiert. Bei der Umsetzung des 5G Paradigmas kommen neben Technologien zur Virtualisierung auch CC, EC und FC zum Einsatz, um die Latenzzeiten zu minimieren [19]. In diesem Zusammenhang wird auch der Begriff Mobile Edge Computing (MEC) verwendet [21].

Werkzeuge und Techniken. Die steigende Anzahl an Sensoren innerhalb einer Fabrik stellt einen treibenden Faktor für verschiedenste Anwendungen in dem genannten

Spannungsfeld dar [44]. Um solche Anwendungen dahin gehend zu unterstützen, ihre Ergebnisse in Echtzeit generieren zu können, werden IT-Services an der Edge des Netzwerks gehostet [28]. Eine Herausforderung besteht darin, die große Menge erhobener Daten zu verwalten und nutzenstiftend zu verarbeiten [29]. Die untersuchten Veröffentlichungen diskutieren im Zusammenhand mit EC Themen wie Augmented Reality (AR) im Bereich Industrie 4.0 [45], selbstanpassende Herstellungsprozesse [46], Gestenerkennung zur Interaktion zwischen Mensch und Maschine [31] oder Echtzeit Aufgabenverarbeitungsmethoden [34]. Um eine effiziente Verteilung der Lasten zu generieren, werden Methoden und Techniken zur Virtualisierung eingesetzt. Dabei stellen beispielsweise Network Funktion Virtualization (NFV) und Software Defined Networking (SDN) wichtige Frameworkkomponenten bei der Umsetzung von 5G dar [43]. Neben den vielen genannten Vorteilen von EC, geben Lee et al. [47] zu bedenken, dass ein Edge-Gerät im Regelfall eine geringere Hardwarekapazität als ein Server aufweist. Daher untersuchten sie die Verarbeitungswerkzeuge Apache Flink, Apache Spark und Apache Storm für den Einsatz auf Edge-Geräten. Bei diesen Analysen stellte sich heraus, dass Storm nicht für die Verarbeitung auf einem Edge-Gerät geeignet ist. Flink und Spark weisen hingegen eine Eignung auf.

Frameworks. Neben der Beschreibung der Architektur und der Infrastruktur von EC im Bereich der Smart Factory enthalten die betrachteten Publikationen auch die Darstellung von Frameworks wie der multi-tier Multi-access Edge Computing (mMEC) Architektur [19] oder dem eingeführten Framework des Production harmonizEd Reconfiguration of Flexible Robots and Machinery (PERFoRM) Projekts [48]. In diesem Zusammenhang haben Li et al. [17] eine adaptive Übertragungsarchitektur mit einem softwaredefinierten Netzwerk und EC veröffentlicht. Al-Jaroodi et al. [49] präsentieren mit Man4Ware eine serviceorientierte Middleware, welche die Entwicklung von Smart Manufacturing Anwendungen für den Betrieb innerhalb von Cloud oder Fog unterstützt. Kim et al. [50] veröffentlicht ein Compiler Runtime Framework, um die Latenzzeiten für die Verteilung der Berechnungen zu minimieren.

Protokolle. Um Latenzzeiten zu minimieren und Sicherheitsstandards im Bereich von EC zu integrieren, ist es notwendig die Protokolle zur Datenübertragung zu betrachten und weiter zu entwickeln. Peraltaet al. [37] präsentieren in ihrem Beitrag die Verwendung des Übertragungsprotokolls Message Queue Telemetry Transport (MQTT), welches innerhalb von EC-Architekturen im Bereich Industrie 4.0 Einsatz finden soll. Neben MQTT, werden in diesem Spannungsfeld auch das Advanced Message Queuing Protocol (AMQP) oder die Open Platform Communications Unified Architecture (OPC-UA) eingesetzt [51]. Jedoch auch das Hypertext Transfer Protocol (HTTP) und das Constrained Application Protocol (CoAP) sind gebräuchlich [9]. Alcaraz et al. [52] betrachten in diesem Kontext das Transmission Control Protocol/Intenet Prototocol (TCP/IP) und das Internet Control Message Protocol (ICMP) im Hinblick auf Sicherheitsaspekte.

Sicherheitsorientierte Veröffentlichungen

Durch die Verwendung einer EC-Architektur ist es nicht notwendig, alle Daten in die Cloud zu übertragen. Neben der potenziellen Verringerung der Gesamtlatenz ergeben sich durch den Einsatz von EC-Architekturen Vorteile im Bereich der IT-Sicherheit. Andererseits entstehen neue Herausforderungen, welche einer Lösung bedürfen.

Erhöhung des Sicherheitsgrades. Der Grund der Verwendung von EC basiert zumeist auf den Leistungsvorteilen. Die Dezentralisierung der Cloud mittels EC hilft jedoch auch typische Angriffe, wie beispielsweise Denial-of-Service (DoS) Attacken zu reduzieren und rechtfertigen somit den Einsatz von EC-Architekturen auch im Hinblick auf Sicherheitsaspekte [4]. Dabei wird unter anderem die Speicherung von sensiblen Rohdaten vereinfacht, da diese nur an der Edge gespeichert und somit vor unbefugten Zugriffen besser geschützt werden können [53]. Gleichzeitig reduziert der Einsatz von EC-Architekturen jedoch auch die Gefahr von Datenverlusten ohne, diese zentral in der Cloud speichern zu müssen [54].

Neue Herausforderungen. Eine sichere Verwendung einer EC-Architektur erfordert eine durchgehende und stabile IT-Sicherheit über das gesamte Netzwerk von der Edge bis hin zur Cloud. Darüber hinaus ist es notwendig, Richtlinien und Updates wie den gesamten IT-Sicherheitsprozess zu verwalten und zu kontrollieren [32]. Viele Herausforderungen ergeben sich aus typischen Schwachstellen im Netzwerkbereich. Zugängliche Ports oder Dienste, fehlende Isolationsmaßnahmen, Inkompatibilitäten oder unkontrollierte Netzwerkabschnitte können an dieser Stelle beispielhaft genannt werden [52]. Die Architektur von EC schafft jedoch auch neue Angriffspunkte und somit Sicherheitsbedenken. Mögliche Aggressoren konzentrieren sich nicht auf Cloud-Dienste, sondern greifen die einzelnen Dienstanbieter (Nodes oder Edges) direkt an. Daher ist es notwendig neue Sicherheitsmechanismen zu entwickeln [4]. Cisco hat beispielsweise ein IoT-Referenzmodell mit sieben Schichten entwickelt, das ein Sicherheitsmodul zur Verhinderung von Datenlecks oder verdächtigen Abfragen beinhaltet [44]. Alam et al. [44] halten fest, dass insbesondere die Edge Geräte anfällig für Distributed-Denial-of-Service (DDoS) Angriffe sind. Darüber hinaus stellen Sleep Deprivation Attaken (Schlafentzugsangriffe) eine Gefahr dar. Auch bestehen Risiken in Form von physischen Angriffen auf die Sensoren.

Analytisch orientierte Veröffentlichungen

In vielen Smart-Factory-Szenarios werden analytische Methoden angewandt. Innerhalb der betrachteten Beiträge konnten rund 9% der Hauptklasse analytisch orientiert zugeordnet werden. Innerhalb dieser Publikationen werden vordergründig die Verringerung der Latenzzeit sowie die Algorithmen untersucht.

Latenzzeiten. Wie groß die Latenz einer analytischen Aufgabe sein kann, hängt vordergründig von der Anwendung ab. Dabei gibt es eine Vielzahl von Anwendungen, welche die Berechnung der Ergebnisse in Echtzeit erfordern. Der Einsatz von EC und Analytics hat den Vorteil, dass die Berechnung physisch näher an den Maschinen und Datenquellen erfolgen kann und somit die Übertragungslatenzen minimiert werden [32,2]. Dadurch ist es nicht notwendig, die Ausgangsdaten in die Cloud zu übertragen. Fog Datenzentren sind dabei jedoch weniger ressourcenstark und kosteneffektiver als Cloud Rechenzentren, können aber Antworten in Echtzeit geben [55].

O'Donovan et al. [56] betrachten in diesem Kontext den Einsatz von Techniken und Methoden des Maschinellen Lernens. Ein Ergebnis innerhalb dieser Veröffentlichung ist, dass die Ausführungszeit bei der Verwendung einer Fog-Schnittstelle im Gegensatz zur Verwendung einer Cloud-Schnittstelle signifikant geringer ist. Zudem reduziert der Einsatz von Fog-Schnittstellen die Rate von Verbindungsausfällen erheblich. Maurer et al. [53] veröffentlichten eine integrierte Datenanalyse-Infrastruktur für die Smart Factory. Diese besteht aus der Shop-Floor-Schicht, der Datenerfassungseinheit und der Cloud. Die Berechnung der Analytics wird jedoch auf der Cloud-Ebene und nicht auf Ebene der Edge durchgeführt. Die Vorverarbeitung der Daten erfolgt jedoch bereits an der Datenerfassungseinheit, die als Edge angesehen werden kann.

Algorithmen. Um künftige Zustände zu prognostizieren und mögliche Reaktionen darauf in der Produktionsumgebung implementieren zu können, werden Algorithmen aus dem Bereich des Data Mining und des Maschinellen Lernens angewandt. In diesem Zusammenhang präsentieren Kiadi und Tan [55] ein mögliches Spektrum an Algorithmen aus dem Bereich des Maschinellen Lernens und deren Einsatzmöglichkeiten. Hill et al. [57] diskutieren das Thema Analytics basierend auf EC im Bereich Industrie 4.0 unter dem Begriff In-Transit Analytics. Neben der entwickelten Architektur wurden Algorithmen für spezielle Anwendungsfälle für den Einsatz am Edge-Knoten skizziert. Eine Reihe weiterer Autoren setzen sich mit dem Thema der Verwendung von Algorithmen aus dem Bereich des Maschinellen Lernens an der Edge auseinander [58,53,31,20,59]. Dabei finden Algorithmen zur Klassifikation, wie der k-Nearest Neighbor (kNN) [31] oder des Clustering, wie der k-means [59], Anwendung. Auch die Diskussion von Neuronalen Netzen ist in dem wissenschaftlichen Diskurs enthalten [20].

Diskussion der Ergebnisse

Die erzielten Ergebnisse der durchgeführten Analyse werden in diesem Abschnitt anhand der aufgestellten Forschungsfragen diskutiert.

7

Literatur