Stabiler, schneller sicherer

Neben einigen Neuerungen lag der Schwerpunkt der 4.8-Version bei der Erhöhung der Stabilität, was durch eine Verbesserung der Code-Qualität und durch die obligatorische Beseitigung bekannter Fehler erreicht werden soll sowie bei der Implementation neuer Sicherheits-Features. Der Vorrang der Sicherheitsfunktionen ist auch der Grund dafür, dass sich die Entwickler bei der Integration von Neuerungen zurück gehalten haben.

Dafür soll Xen ab sofort regelmäßig alle sechs Monate in einer neuen Version erscheinen, wie sich dem zugehörigen WIKI-Beitrag entnehmen lässt. Weitere Einzelheiten finden sich in den Release Notes und in der Feature List.

Xen lebt

Trotz der Vorherrschaft von ESXi, Hyper-V und KVM ist der Vierte im Bunde der großen Hypervisors nicht unterzukriegen. Lässt man mal VMware ESXi als Marktführer außen vor, das sowohl rein softwaregestützte Virtualisierung (bei VMware „Binary Translation“, BT genannt), als auch hardwaregestützte Virtualisierung sowie partielle Paravirtualisierung beherrscht, ist Xen nämlich der einzige Hypervisor, der im Zweifel auch ohne CPUs mit Hardware-VT-Unterstützung läuft, also auch auf reinen 32-Bit-Systemen oder der ARM-Architektur.

Beides ist für die Zukunft nicht unwichtig, sollten virtualisierte Systeme auch embedded laufen oder gar auf Smartphones. Außerdem bildet ein modifizierter Xen-Hypervisor seit nunmehr als 10 Jahren die Basis der Amazon Web Services (AWS). Es lohnt sich also durchaus, sich mit der Evolution beim Erfinders der Paravirtualisierung auseinanderzusetzen.

Xen 4.8 unter der Lupe

Xen 4.8 erscheint rund ein ½ Jahr nach Xen 4.7 und bietet mit den Scheduler Credit 2 eine verbesserte Version zum bisher eingesetzten Credit, ein universellen Scheduler, der in der neuen Version besser skaliert und bessere Latenzzeiten aufweist. Ferner soll eine Optimierung beim TLB Flush dafür sorgen, dass neue virtuelle Maschinen schneller starten.

Bei der Vorgängerversion benötigten vor allem große VMs mit mehreren hundert Gigabyte RAM mitunter mehrere Minuten für den Start. Bei Xen 4.8 hingegen soll die Startzeit unter 1 Minute bleiben.

Ferner haben die Entwickler die XSM-Richtliniendateien überarbeitet und neu organisiert. Sie sind jetzt nicht nur einfacher zu verstehen sondern lassen sich auch einfacher verwenden. Da sich eine Standardrichtlinie auch in die Xen-Binärdatei einbauen lässt, muss sie vom Bootloader nicht mehr separat geladen werden.

Neu ist auch, dass Live-Patching jetzt auch auf ARM-Chips (32 und 64 Bit) verfügbar ist. Zudem lassen sich beim Live-Patching in der Patch-Datei nun auch auszuführende Code-Blöcke angeben.

Zu den prozessorspezifischen Neuerungen gehören Optimierungen von Systemaufrufen, die sich mit der Zeit befassen, Support von AVX-512-Instruktionen oder eine Stabilisierung der PVH v2 DomU-Schnittstelle ohne PCI-Passthrough.

Windows Server 2012 R2/2016

Für die Einstellungen in diesem Bereich gehen Sie in den Optionen zu Updatequelle und Proxy. Hier können Sie die Aktualisierungen auch über Proxy-Server konfigurieren, natürlich mit der Möglichkeit einen Benutzernamen und ein Kennwort bereitzustellen.

Sobald Sie den Quell-WSUS-Server eingerichtet haben, rufen Sie auf den untergeordneten WSUS-Servern Optionen\Updatequelle und Proxyserver auf. Aktivieren Sie die Option „Von einem anderen Windows Server Update Services-Server synchronisieren“. Im Fenster geben Sie den Servernamen ein sowie den Port 8530, wenn Sie kein SSL konfiguriert haben. Nutzen Sie bereits SSL, verwenden Sie den entsprechenden Port. Im Fenster zur Steuerung des Upstream-Servers können Sie auch festlegen, dass der untergeordnete WSUS-Server auch die Einstellungen vom übergeordneten Server erhält. Dazu aktivieren Sie die Option „Dieser Server ist ein Replikat des Upstream-Servers“.

Nachdem Sie diese Option aktiviert haben, müssen Sie auf den untergeordneten Servern auch keine Updates mehr freigeben, da diese Option ebenfalls synchronisiert wird. Nach einigen Stunden sollten die Server miteinander synchronisiert sein. Im Bereich Downstreamserver in der Verwaltungskonsole von WSUS sehen Sie die untergeordneten WSUS-Server. In diesem Bereich können Sie den Server zur Verwaltung auch zur aktuellen Konsole hinzufügen und auf diesem Weg in einer WSUS-Konsole auch mehrere Server verwalten.

Windows Server 2016

Mit Conditional Access Control lassen sich vor allem mobile Anwender effizienter anbinden. Außerdem können Sie Rechner mit Windows 10 über Geräteauthentifizierung an Windows Server 2016 anbinden. Microsoft zeigt die Möglichkeiten dazu in der TechNet (https://technet.microsoft.com/en-US/library/mt622048.aspx).

Sie können in Windows Server 2016 auch Benutzerkonten in ADFS authentifizieren, die nicht aus einem Active Directory kommen. Beispiel dafür sind X.50000 kompatible LDAP-Verzeichnisse oder auch SQL-Datenbanken:

AD LDS

Apache DS

IBM Tivoli DS

Novell DS

Open LDAP

Open DJ

Open DS

Radiant Logic Virtual DS

Sun ONE v6, v7, v11

Passive Authentifizierungsmöglichkeiten wie SAML, OAuth, WS-Trust active authorization protocol und WS-Federation sind ebenfalls möglich. Windows Server 2016 bietet auch die Möglichkeit mehrere LDAP-Verzeichnisse mit einer ADFS-Farm zu verbinden.

Teil 3: vSphere HA

Neu in der HA-Implementation ist u. a. auch ein Feature namens Orchestrated VM Restart. Es erlaubt in Version 6.5 nicht nur, VMs nach einem Ausfall oder bevor ein Server zur Wartung in den Maintenance-Mode genommen wird, auf einem anderen Host neu starten, sondern auch deren Start-Reihenfolge durch relativ komplexe Regeln zu steuern.

Mit Orchestrated VM Restart kann der Administrator, Aneinanderreihungen voneinander abhängiger virtueller Maschinen oder ganze Gruppen solcher VMs festlegen und dann die Reihenfolge bestimmen, in der die einzelnen VMs neu gestartet werden. Der Admin kann sogar einstellen, dass ausgewählte VMs mit dem Booten warten, bis der VM sämtliche von ihr durch andere VMs bereitgestellte Dienste tatsächlich zur Verfügung stehen.

VM Restart Priority

In der bisherigen HA-Implementation (bis vSphere 6) gibt es hingegen nur die „VM Restart Priority“, welche der Admin mehr oder weniger prophylaktisch auf high, medium oder low setzen kann.

Um dies zu tun, wechselt man nicht etwa in den Detail-Bereich der HA-Settings, sondern navigiert in den Cluster-Einstellungen zum Bereich Configuration. Hier wählt man den Eintrag  VM Overrides und klickt auf Add. Mit dem grünen Plus-Symbol lassen sich dann einzelne VMs hinzufügen und mit individuellen Cluster-Einstellungen versehen, etwa im erwähnten Menü VM restart priority durch Auswahl eines der Einträge „low“, „medium“ oder „high“. Soweit so gut. Bei vSphere 6.5 kommen noch die Optionen „Lowest“ und „Highest“ hinzu.

Regel-abhängige VM-Restart-Priorität

Neu ist, dass VMware unterhalb des Menüs VM restart priority zwei weitere Menüs Start next priority VMs when, Additional delay und or after timeout occours at  hinzugefügt hat.
So kann der Admin etwa bei Start next priority VMs when Policies einstellen wie z. B. „Ressource Allocated“, „Powered On“ „Guest Heartbeat dedected“ oder „App Heartbeats detected“, ”wodurch” oder “durch was” der Start der nächsten Priority-Gruppe getriggert wird.

Dies erlaubt ein weitaus granulares Steuern, wann die jeweils nächst höher priorisierte VM/VM-Group startet. Die beiden letztgenannten Optionen setzen allerdings die VMware Tools voraus.

Hat der Admin die Start-Priorität an sich festgelegt, kann er bei Additional Boot-Delay bei Bedarf einstellen, wie lange auf den Start des nächste Batches gewartet werden soll. Unter „resources allocated” versteht VMware das pure Scheduling des Batches selbst, während “Powerd On” das Vervollständigen des PowerOn-Events als Trigger verwendet oder die Guest-, bzw. App-Heartbeat-Erkennung nach dem vollständigen Start der VM samt VMware-Tools und/oder der Anwendung.

Letzteres setzt voraus, dass App-HA aktiviert ist, was wiederum eine „App-HA-aware“ Applikation voraussetzt, während „VM-Monitoring“ (Guest-HA) nur das Aktivieren der Funktion in den HA-Settings benötigt. Allerdings benötigen beide Funktionen die VMware-Tools für das Austauschen von Guest-, bzw. App-Heartbeats zwischen VM und Host.

Der Stellenwert von OPC UA für moderne HMIs

Die Kommunikation zwischen Mensch und Maschine erfordert Schnittstellen, die weder dem Menschen noch der Maschine zuzuordnen sind. Über diese HMIs (Human-Machine-Interfaces) können Maschinen und Anlagen überwacht und gesteuert werden. Doch in einer Anlage sind Komponenten der verschiedensten Hersteller verbaut, dieser heterogene Mix macht das schnelle Erstellen von HMIs nahezu unmöglich, wenn jeder Hersteller ein anderes Kommunikationsprotokoll verwendet und daher für jedes Einzelteil eine neue Schnittstelle programmiert werden muss.  

OPC UA ist ein nicht mehr ganz so neuer Industriestandard für die Maschinenkommunikation, der diesen Irrsinn unnötig macht. In Ermangelung einer Alternative haben sich nahezu alle Hersteller aus der Automatisierungstechnik diesem Standard angeschlossen, der eine herstellerunabhängige Kommunikation über eine Protokollform ermöglicht.

HMIs sind heute in der Regel nicht mehr als mobile Endgeräte (z.B. Smartphone oder Tablet), über die Anlagen gesteuert werden. Dafür müssen die Daten ausgelesen und geschrieben werden.

Mittlerweile können HMIs ohne großen Programmieraufwand via Konfiguration erstellt werden und inzwischen gilt dies auch für OPC UA SChnittstellen. Ob Mensch oder Maschine ist letztlich egal, denn OPC UA wird durch einfach verständliche HMIs von beiden verstanden.

Konfigurierbare Schnittstellen zwischen Menschen, Maschinen und Systemen sind die Grundlage von effizienter Maschinenkommunikation. Nicht auszudenken wäre der Programmieraufwand und damit der Preis, müssten Anwendungen für Steuerung und Überwachung von Großanlagen nach wie vor herkömmlich programmiert und für jede Komponente eine einzelne Schnittstelle erstellt werden. Doch letztlich ist es nicht nur Zeit- und Geldaufwand, der konventionell programmierte Anwendungen inzwischen altmodisch und nicht mehr zeitgemäß erscheinen lässt. Auch die Flexibilität lässt stark zu wünschen übrig. Und was haben Nutzer von Anwendungen, die nicht auf dem aktuellsten Stand sind und mit denen unter Umständen nicht mehr alle Komponenten einer Anlage gesteuert werden können, weil es ein neues Bauteil gibt, zu dem noch keine Schnittstelle programmiert wurde?

Dank standardisierter Schnittstellen lassen sich alle OPC UA fähigen Geräte mit nur einem Schnittstellentyp in Anwendungen integrieren. Damit kommt der Standard den modernen Anforderungen an Anwendungsumsetzung entgegen: schnell und flexibel.

Durch Konfiguration ebensolcher OPC UA Schnittstellen können Maschinen und Anlagen binnen weniger Minuten in Anwendungen integriert werden, so dass alle Datenpunkte ausgelesen und mit entsprechenden Funktionen in der App belegt werden können, so lassen sich Geschwindigkeiten anpassen oder Temperatur- und Drucksensoren überwachen.

Durch moderne Konfigurationsmöglichkeiten von Anwendungen mit dem Feature Maschinenkommunikation über gängige Webtechnologien wird es erstmals möglich, schnell und flexibel Apps für mobile Endgeräte zu erstellen. Ohne den herstellerübergreifenden OPC UA-Standard wäre die Umsetzung solcher Anwendungen trotz Konfiguration weit weniger einfach und schnell.

Damit bildet OPC UA eine Säule der Basis für moderne HMIs, andere Säulen sind Webtechnologien und Systemvernetzung.

Denn nur, wenn die Fülle an benötigten Schnittstellen konfigurier- und damit nachhaltig anpassbar ist, wird die notwendige Systemvernetzung möglich.

Eine einzige Anwendung, sagen wir für die Wartung des Maschinenparks eines einzigen Produktionsbetriebs benötigt Daten aus mehreren Systemen: Datenbanken zur Speicherung und Analyse der gemessenen Werte der Anlage, Ticketsystem, Ersatzteillagerverwaltung, Arbeitszeiterfassung. Doch nur, wenn alle dieses Systeme in eine Anwendung integriert werden, also ihre Daten liefern und auch Informationen empfangen können, werden Anwendungen mit echtem Mehrwert möglich.

Die Konfigurierbarkeit von OPC UA Schnittstellen liefert einen wichtigen Beitrag dazu. Ob Daten nun vom Menschen oder anderen Maschinen genutzt werden, ist irrelevant, denn beides ist möglich.

Eine DNS für das Internet der Dinge

Eine gemeinsame Sprache könnte Abhilfe schaffen. Die Geräte selbst müssen intelligenter werden. In einem biologischen Organismus steckt in jeder einzelnen Zelle das komplette Erbgut mit jeweils unterschiedlichen Arbeitsanweisungen. Dies könnte auch ein Vorbild für das Internet der Dinge sein.

All die verschiedenen Geräte für verschiedene Aufgaben in einem Internet der Dinge kommunizieren heute meist über ihre eigenen, vom jeweiligen Hersteller mitgelieferten proprietären Systeme. Zwar gibt es bereits gewisse Standards in der IoT, allerdings je nach Industrie jeweils nur in ihren eigenen Anwendungsgebieten. Sollen unterschiedlichen Bereiche aber nun zusammenarbeiten, wird eine Installation sehr schnell komplex. Der Hard- und Softwareaufwand beispielsweise für die Übersetzung und Konsolidierung der Daten verursacht zudem hohe Kosten in der Anschaffung aber vor allem auch in der Wartung. Fällt eine Steuereinheit aus, ist oft das gesamte System betroffen. Auch in Sachen Sicherheit ergeben sich so vielfältige Angriffspunkte.

Zentrale Steuerungen machen IoT-Systeme anfällig

Die Mehrzahl aller Lösungen im IoT ist heute grundsätzlich zentral gesteuert. Sensoren sammeln Daten ein und schicken diese an eine Steuereinheit wie etwa ein Gateway vor Ort oder einen Server in der Cloud. Diese werten die Daten aus und schicken Befehle an die mit der Installation verbundenen Aktoren: Im Bereich der Gebäudeautomation können das beispielsweise Heizungsanlagen, Lichtschalter, Tür- und Torsteuerungen oder automatisierte Beschattungsanlagen sein. Allein für sich genommen sind alle Aktoren und Sensoren ziemlich hilflos. Nur durch die Zentrale sind sie in der Lage, ihre Aufgaben zu erfüllen und miteinander zu interagieren. Doch sind solche Ökosysteme auf Dauer überlebensfähig? Wie sieht es mit der Erweiterbarkeit aus? Wie anpassungsfähig sind sie für zukünftige Herausforderungen?

Die Evolution liefert das Vorbild für das Internet der Dinge

Die Evolution lehrt uns, dass sich nur die Entwicklungen durchsetzen, die sich als praktikabel und an ihre Umwelt optimal angepasst erweisen. Die Natur sortiert seit je her schwerfällige und unflexible Erscheinungen aus. Übertragen wir das Internet der Dinge – so wie es heute existiert – in die Biologie, so könnten wir es mit einem Organismus vergleichen, indem nur eine zentrale Zelle, ausgestattet mit einer zentralen DNS, viele andere „dumme Zellen“ steuert. Ein solcher Organismus wäre wohl auf Dauer viel zu schwerfällig und vor allem zu anfällig, als dass ihm ein langes Überdauern beschieden wäre. Stattdessen hat die Natur es so eingerichtet, dass jede Körperzelle das vollständige Erbgut des gesamten Organismus beinhaltet. Nur durch kleine Abweichungen, so genannte Schaltermoleküle auf dem Erbgut, „weiß“ die Zelle, welche spezielle Aufgabe sie in ihrem Organismus auszuführen hat.

Mehr Intelligenz in die Geräte verlagern

Genauso funktioniert Lemonbeat. Unsere DNS ist die „Lemonbeat smart Device Language“ oder kurz „LsDL“. Dabei handelt es sich um eine auf XML-basierende, universelle Auszeichnungssprache die in der Lage ist, die Eigenschaften eines jeden beliebigen Gerätes zu beschreiben und diese Informationen mit anderen Geräten auszutauschen. Damit können Geräte im Internet der Dinge selbsttätig Aktionen ausführen und die Informationen direkt untereinander austauschen. Die Kommunikation wird wie in einem biologischen Organismus dezentral gesteuert. Die Intelligenz wandert von einer zentralen Einheit direkt in das jeweilige Gerät. Durch eine einmalige initiale Konfiguration wissen alle Geräte in einem „IoT-Organismus“, mit wem sie Daten austauschen sollen und welche Aktionen je nach empfangenen Werten auszuführen sind. Ändern sich die Voraussetzungen, fallen Geräte weg oder kommen neue hinzu, kann das Verhalten jederzeit im Livebetrieb angepasst werden. Dieser Ansatz ist äußert flexibel, anpassungsfähig und auch zukunftssicher. In einer Körperzelle funktioniert das auf ähnliche Weise. Jede Zelle trägt die DNS in sich, dennoch erledigen sie individuelle Aufgaben.

Interoperabilität entfesselt das IoT-Potenzial

Hersteller, die ihre Geräte fit für das Internet der Dinge machen wollen, sehen sich mit sehr hohem Entwicklungsaufwand konfrontiert. Eine Entwicklungsarbeit, die zudem meist nicht ihrem Kerngeschäft entspricht. Wer vorher Lichtschalter, Lampen, Thermostate, Bewegungsmelder oder Temperatursensoren hergestellt hat, muss sich plötzlich überlegen was alles notwendig ist, um diese Geräte „smart“ zu machen. Wie werden die Daten übertragen, wohin fließen die Daten, wie steht es um die Sicherheit, wer entwickelt die notwendigen Applikationen oder stellt die Server für den Betrieb bereit? Gibt es bereits Systeme an die man andocken könnte, wenn ja, für welches entscheide ich mich? Wie steht es um deren Zukunftssicherheit?

In dem Bericht „The Internet of Things: Mapping The Value Beyond The Hype“* des McKinsey Global Institutes bescheinigen die Marktforscher dem Internet der Dinge ein riesiges Potenzial, einen weltweiten Markt von bis zu 11,1 Billionen US-Dollar bis zum Jahr 2025. Aber nur, wenn wir es schaffen, einige Herausforderungen zu meistern. Als eine große Hürde nennt das Unternehmen dabei die Interoperabilität. „Vom gesamten potenziellen wirtschaftlichen Wert, den das Internet der Dinge ermöglicht, macht die Interoperabilität durchschnittlich 40 Prozent, in einigen Anwendungen sogar bis zu 60 Prozent aus.“

Unser Stack, implementiert auf einem kleinen Chip, übersetzt die Zustandsdaten eines jeden beliebigen Gerätes nach LsDL. Zur Kommunikation mit anderen Geräten setzt die Sprache auf den IP-Standard und ist für Sub-GHz Funk (868 MHz), LoRa und Ethernet verfügbar. Grundsätzlich lässt sie sich aber auf jedem beliebigen physikalischen Übertragungsweg implementieren.

Um dieser Idee Vorschub zu leisten haben wir die Spezifikationen für jedermann offengelegt und arbeiten mit anderen namhaften Teilnehmern der Industrie innerhalb der so genannten „Web of Things Interest Group“, einer Arbeitsgruppe des World Wide Web Konsortiums (W3C), dem Gremium zur Standardisierung von Techniken im World Wide Web, weiter an einem weltweit gültigen Standard, einer DNS für das Internet der Dinge.

Smart Factory – Die Produktion der Zukunft

Es ist unbestritten, dass das Thema Smart Production vor dem Hintergrund des zunehmenden internationalen Wettbewerbs an Bedeutung gewinnt. Damit Deutschland künftig ein attraktiver Standort für produzierende Unternehmen bleibt, müssen diese in der Lage sein profitabel zu produzieren. Produkte nach Losgröße 1 ohne wesentliche Steigerung der Fertigungskosten zu produzieren wird für Unternehmen daher künftig ein Indikator für die Smart Factory sein. Über den Erfolg bestimmt dann neben der Wandlungsfähigkeit der Produktion ein hoher Vernetzungsgrad entlang der gesamten Wertschöpfungskette – bis zum Endprodukt. Wie das konkret umgesetzt wird, hängt maßgeblich von den bestehenden Rahmenbedingungen ab. Klar ist, die Smart Factory lässt sich nicht als Lösung überstülpen, viel mehr muss die smarte Version einer bestehenden Produktion so individuell sein, wie es die Prozesse eines produzierenden Unternehmens selbst sind.

Individuelle Ideen für die Produktion von Morgen

Vor der Überlegung, wie Industrie 4.0 technologisch in die bestehende Produktion gebracht wird, muss also die Überlegung stehen, welche Methoden, Ideen oder Ansätze zu einer Verbesserung des bestehenden, individuellen Produktionsprozesses führen können. Diese Verbesserung kann darin liegen, ressourceneffizienter zu produzieren, Doppelaufwendungen entlang des Planungsprozesses zu vermeiden um damit das Anlagenengineering deutlich zu verkürzen. Für Maschinen- und Anlagenbauer könnten etwa Vorteile daraus resultieren eine projektierte Anlage beim Kunden zu beobachten und durch Sammeln und Auswerten von Daten und Information aus dem Lifecycle Rückschlüsse für die eigene Entwicklung zu ziehen oder dem Kunden Empfehlungen zum aktuellen Betrieb der Anlage an die Hand zu geben.

Erst messen dann lenken

In welcher Methode auch immer die Transformation von der bestehenden zur smarten Fabrik liegen könnten – sie alle setzen die Vernetzung bestehender Prozesse und Abläufe voraus. In vertikaler Richtung, vom Leitsystem in die Feldebene also, ebenso wie in horizontaler Ausrichtung, nämlich über die unterschiedlichen Schritte einer Wertschöpfung hinweg. Heute steht einer solch vollständigen Vernetzung häufig noch der Umstand entgegen, dass Daten nicht durchgängig generiert und genutzt werden. Sowohl bei der vertikalen Integration – insbesondere aber bei der horizontalen Integration entlang der Wertschöpfungskette, existieren diverse Modell- und Systembrüche, die es schwierig machen, Daten sinnvoll miteinander in Kombination zu bringen. In der Regel setzt jeder Industrie 4.0-Ansatz darum zuerst voraus, Daten zu erfassen und sie zu digitalisieren. Dieser Schritt ist es also, der den zentralen Gedanken von Industrie 4.0 ermöglicht: Das Sammeln, Vernetzten und Auswerten von Daten aus dem Produktionsprozess, um diese so gewinnbringend zu verwerten, dass ein nachhaltiger Mehrwert für das Unternehmen entsteht.

Datentransparenz für die Smart Factory

Wesentlichen Kriterien, die eine jede Smart Factory darum charakterisieren sind diejenigen, die das Messen, Vernetzen und Auswerten von Daten ermöglichen:

  • Sensorik in allen Ebenen bis hinunter zum Produkt und in das Produkt hinein
  • Vernetzung aller Komponenten und Internetanbindung
  • Maximale IT-Sicherheit

Der erste Schritt auf diesem Weg ist die Transparenz über alle Produktions- und Anlagendaten. Nur wenn die Daten zu Informationen verdichtet, miteinander in Beziehung gebracht und geeignet aufbereitet werden, können Maßnahmen eigenleitet werden, die die Prozesse verbessern. Damit dies gelingt, müssen Sensoren produkt- und produktionsrelevante Daten in der Feldebene erfassen. Sie müssen dazu in der Anlagenarchitektur berücksichtigt oder dem Produkt mitgegeben werden – beispielsweise in Form eines RFID-Chips. Für produktionsrelevante Daten, die von Sensoren an Maschinen und Anlagen erfasst werden, besteht die Herausforderung weniger im Sammeln der Daten, als darin, die Daten sicher und fehlerfrei von der Feldebene in eine übergeordnete Ebene zu bringen – ein MES (Manufacturing Execution System) beispielsweise oder eine Cloud. Doch wie gelingt das?

Flexible Automatisierungslösungen

Einen entscheidenden Beitrag leisten hier Automatisierungslösungen wie das modulare WAGO I-/O-System 750, das mit über 500 verschiedenen Modulen eine passende Lösung für nahezu jeden Anwendungsbereich bietet – so können Signale von der Feldebene immer zuverlässig eingesammelt und weiterverarbeitet werden. Ergänzt durch die Controller-Familie PFC von WAGO können verschiedene Schnittstellen und Feldbusse wie OPC-UA, CANopen, PROFIBUS DP, DeviceNet und Modbus-TCP herstellerunabhängig genutzt werden. Auch Lösungen unter Einsatz von IoT-Protokollen, wie MQTT befinden sich im Leistungsportfolio. Entsprechend sind die WAGO-Controller auch als skalierbare Knotenpunkte und Gateways bei bereits bestehenden Automatisierungssystemen einsetzbar, ohne in den eigentlichen Automatisierungsprozess einzugreifen – die Daten werden parallel abgegriffen und können dann an eine übergeordnete Ebene geschickt werden: an ein MES oder ebenso an eine Cloud.

Sicherheit geht vor

In diesem Zusammenhang klingen die mit einer Cloudanbindung verbundenen Vorteile vielversprechend: Cloud-Lösungen sind flexibel, skalierbar, überzeugen durch eine hohe Verfügbarkeit und die Möglichkeit des zentralen Zugriffs. Sie lassen sich ebenfalls nutzen, um große Datenmengen bequem zu managen. Dass die Cloud in Deutschland dennoch nicht die Akzeptanz findet, die sich vermuten ließe, hat viel mit dem Gesichtspunkt der IT-Security und des Knowhow-Schutzes zu tun, die vor allem dann ablehnend bewertet werden wenn es darum geht, geschäftskritische Daten in der Cloud vorzuhalten. Wer die Vorteile einer Cloud nutzen möchte, sollte die dazu erforderlichen Maßnahmen mitdenken, die in Sachen IT-Sicherheit getroffen werden müssen. Sicherheit lässt sich nicht allein durch den Zukauf bestimmter technischer Komponenten gewährleisten, sondern kann nur als maßgeschneiderte Lösung, also als „Security by Design“ erreicht werden. Am Ende des Tages muss das System ganzheitlich betrachtet und bewertet werden. Das gilt insbesondere für alle Außengrenzen und Schnittstellen zu Fremdsystemen und kann nur durch eine strategische Aufbereitung erreicht werden. Dafür ist „Defense in Depth“ eine Voraussetzung. Security lässt sich nicht „überstülpen“, sondern erfordert auf die jeweiligen Schutzziele angepasste Sicherheitsstrategien.

Daten gewinnbringend nutzen

Anwendungen zur Datenanalyse spielen eine entscheidende Rolle, um in der entstandenen Datenflut nicht unterzugehen. Werden Sie richtig eingesetzt und nutzen sie die individuell relevanten KPIs einer Produktion, kann der bestehende Prozess elementar verbessert werden – etwa mit Blick auf den Faktor Zeit, Ressource oder Energie. Und so ist auf dem Weg zur Smart Factory bereits mehr getan als der erste Schritt.

SSL in WSUS nutzen

Nachdem Sie das Serverzertifikat installiert haben, rufen Sie im IIS-Manager Sites\WSUS-Verwaltung auf. Klicken Sie danach auf Bindungen und bearbeiten die Bindung für SSL zum Port 8531. Hier können Sie jetzt auch das installierte Zertifikat auswählen.

Zusätzlich müssen Sie noch für die folgenden untergeordneten Verzeichnisse der Seite WSUS-Verwaltung die SSL-Einstellungen aufrufen und danach die Option SSL erforderlich aktivieren:

  • ApiRemoting30
  • ClientWebService
  • DssAuthWebService
  • ServerSyncWebService
  • SimpleAuthWebService

Nachdem Sie SSL für WSUS aktiviert haben, erhalten Sie eine Fehlermeldung, wenn Sie die WSUS-Verwaltungskonsole öffnen.

Damit die Konsole wieder funktioniert öffnen Sie zunächst eine Befehlszeile und wechseln in das Verzeichnis „C:\Programme\Update Services\Tools“. Geben Sie den Befehl wsusutil ConfigureSSL <Name des Zertifikats>.

Im nächsten Schritt entfernen Sie die veraltete HTTP-Verbindung in der WSUS-Verwaltungskonsole und fügen über das Kontextmenü eine neue Verbindung hinzu. Geben Sie den Servernamen ein sowie die korrekte Portnummer für die Anbindung an SSL. Aktivieren Sie außerdem die Option „Verbindung mit diesem Server über SSL herstellen“.

Achten Sie aber darauf, dass Sie auch in den Gruppenrichtlinien zur Anbindung der Clients den Port zur Verfügung auf 8531 setzen müssen. Der HTTP-Port 8530 steht nicht mehr zur Verfügung. Sie finden die Einstellungen über Computerkonfiguration\Richtlinien\Administrative Vorlagen\Windows-Komponenten\Windows Update. Passen Sie die Einstellung „Internen Pfad für den Microsoft Updatedienst angeben“ an.

Active Directory – Vertrauensstellungen

Die Verwaltung der Vertrauensstellungen findet mit Hilfe des Snap-Ins Active Directory-Domänen und -Vertrauensstellungen statt. Wenn Sie in diesem Snap-In die Eigenschaften einer Domäne aufrufen, finden Sie auf der Registerkarte Vertrauensstellungen alle Vertrauensstellungen dieser Domäne und die dazugehörigen Informationen.

Außer den automatisch eingerichteten Vertrauensstellungen können Sie zusätzliche manuelle Vertrauensstellungen einrichten. Für viele Administratoren ist die Richtung der Vertrauensstellungen noch immer gewöhnungsbedürftig, da die einzelnen Begriffe teilweise etwas verwirrend sind. Generell gibt es in Active Directory zunächst zwei verschiedene Arten von Vertrauensstellungen: unidirektionale und bidirektionale. Bei unidirektionalen Vertrauensstellungen vertraut eine Domäne der anderen, aber nicht umgekehrt. Das heißt, die Benutzer der Domäne 1 können zwar auf Ressourcen der Domäne 2 zugreifen, aber die Benutzer in der Domäne 2 nicht auf Ressourcen in der Domäne 1. Dieser Vorgang ist auch umgekehrt denkbar.

Klicken Sie auf die Schaltfläche Neue Vertrauensstellung. Es erscheint der Assistent zur Einrichtung neuer Vertrauensstellungen. Bestätigen Sie das Fenster und geben Sie auf der zweiten Seite den Namen der Domäne an, zu der Sie eine Vertrauensstellung einrichten wollen. Wichtig ist, dass die Namensauflösung zwischen den Domänen funktioniert.