DE112017006994T5

DE112017006994T5 - Bereitstellung und verwaltung von microservices

Info

Publication number: DE112017006994T5
Application number: DE112017006994.7T
Authority: DE
Inventors: Katalin Bartfai-Walcott; Peggy J. Irelan; Hassna Moustafa
Original assignee: Intel Corp
Current assignee: Intel Corp
Priority date: 2017-02-05
Filing date: 2017-06-27
Publication date: 2019-10-17
Also published as: US20250036477A1; US11663047B2; US20200050494A1; US12141620B2; US11281499B2; US20220318066A1; US20230409407A1; WO2018144060A1

Abstract

Es wird ein Rechnersystem bereitgestellt, das eine Internet-der-Dinge- (loT-) Vorrichtung umfasst. Die loT-Vorrichtung umfasst eine gemeinsame Serviceschnittstelle (CSI), um ein selbstverwaltendes Netzwerk aus Vorrichtungen mit anderen Knoten, die die CSI umfasst, zu erzeugen.

Description

Querverweis auf verwandte Anmeldungen
Die vorliegende Anmeldung beansprucht den Nutzen des Einreichdatums der vorläufigen US-Patentanmeldung Seriennr. 62/454.891 , von Bartfai-Walcott et al., betitelt „MICROSERVICE PROVISION AND MANAGEMENT," eingereicht am 5. Februar 2017, die hierin durch Verweis aufgenommen ist.
Fachgebiet
Im Allgemeinen betreffen die vorliegenden Methoden das Internet der Dinge (loT). Im Speziellen betreffen die vorliegenden Methoden das Erhalten von Microservices in einer loT-Umgebung.
Hintergrund
Eine aktuelle Auffassung des Internets ist die Verbindung von Clients, wie z.B. Personal Computers, Tablets, Smartphones, Servers, digitale Bilderrahmen und viele andere Arten von Vorrichtungen, mit öffentlich zugänglichen Datenzentren, die in Serverfarmen gehostet sind. Diese Ansicht stellt jedoch nur einen kleinen Teil der gesamten Verwendung des global verbundenen Netzwerks dar. Derzeit gibt es eine sehr große Anzahl von verbundenen Quellen, die jedoch nicht öffentlich zugänglich sind. Beispiele umfassen Unternehmensnetzwerke, private Organisationssteuernetzwerke und Überwachungsnetzwerke, die die Welt umspannen und aus Anonymitätsgründen oft Peer-to-Peer-Weiterleitungen nutzen.
Schätzungsweise könnte das Internet der Dinge (loT) bis 2020 eine Internetverbindung zu mehr als 15 Milliarden Vorrichtungen bereitstellen. Für Organisationen können loT-Vorrichtungen Möglichkeiten für die Überwachung, Nachverfolgung oder Steuerung anderer Vorrichtungen und Elemente, einschließlich weiterer loT-Vorrichtungen, anderer Heim- und Industrievorrichtungen, Elemente in Fertigungs- und Nahrungsmittelproduktionsketten und dergleichen bereitstellen. Das Entstehen von loT-Netzwerken diente als Katalysator für eine grundlegende Veränderung der Intemetweiterentwicklung. In Zukunft wird sich das Internet voraussichtlich von einem primär menschenorientierten Dienst zu einer Infrastruktur entwickeln, in der Menschen schließlich nur noch Nebenakteure in einer verbundenen Welt von Vorrichtungen sind.
Bei dieser Auffassung wird das Internet ein Kommunikationssystem für Vorrichtungen und Netzwerken aus Vorrichtungen, um nicht nur mit Datenzentren, sondern miteinander zu kommunizieren. Die Vorrichtungen können zur Durchführung von Funktionen funktionelle Netzwerke oder virtuelle Vorrichtungen bilden, sich auflösen, sobald die Funktion durchgeführt wurde. Herausforderungen bestehen in der Freigabe von vertrauenswürdigen, sicheren und identifizierbaren Vorrichtungen, die nach Bedarf Netzwerke bilden können, um Aufgaben auszuführen.
Die ursprüngliche Einführung von loT-Vorrichtungen und Netzwerken in Heim-, Industrie-, Automobil- und anderen Anwendungen wurde in großem Ausmaß vertikalisiert. Beispielsweise stellen Anbieter üblicherweise End-to-End-Lösungen bereit, die stark integrierte Vorrichtungen, in vielen Fällen mit festgelegten Funktionen, und Gruppen von Vorrichtungen umfassen. Vorrichtungen mit festgelegten Funktionen können in Bezug auf die Rechnerleistung, Speicher oder andere Quellen eingeschränkt sein, wodurch die Adaptierbarkeit der loT-Netzwerke begrenzt ist. Neue funktionelle Modelle, um die Verwendung von dynamischen und verteilten Quellen zu koordinieren, können loT-Netzwerke adaptierbarer machen.
Figurenliste
Die vorliegenden Erfindung kann durch die folgende detaillierte Beschreibung und die beiliegenden Zeichnungen von zahlreichen Ausführungsformen der Erfindung noch umfangreicher verstanden werden, die jedoch nicht zur Einschränkung der Erfindung auf die spezifischen Ausführungsformen, sondern zur Erklärung und besseren Verständnis dienen sollen.

1 ist eine Zeichnung eines Cloud-Rechnernetzwerks oder einer Cloud in Kommunikation mit einer Anzahl von Internet-der-Dinge- (loT-) Vorrichtungen gemäß manchen Ausführungsformen.
2 ist eine Zeichnung ist eine Cloud-Rechnervorrichtung oder einer Cloud in Kommunikation mit einem Mesh-Netzwerk von loT-Vorrichtungen, bei denen es sich um ein Beispiel einer Fog-Vorrichtung handeln kann, die am Rand der Cloud operiert, gemäß manchen Ausführungsformen.
3(A) bis 3(C) sind schematische Diagramme eines Beispiels für ein Internet-der-Dinge- (loT-) System, das andere Vorrichtungen erkannt, Microservices herunterlädt und die Servicebereitstellung verwaltet, gemäß manchen Ausführungsformen.
4 ist ein schematisches Diagramm der Veränderungen an Cloud-Datenzentren und Netzwerken, die vorgenommen werden können, um sie an die aktuellen, hierin beschriebenen, Techniken anzupassen, gemäß manchen Ausführungsformen.
5 ist ein schematisches Diagramm eines serviceorientierten Cloud-Datenzentrums gemäß manchen Ausführungsformen.
6 ist eine schematische Zeichnung eines Infrastruktur- und Orchestrierungssystems gemäß manchen Ausführungsformen.
7 ist ein Blockdiagramm, das Schichten eines Datenzentrumsverbandsystems veranschaulicht, das anderen Systemen, einschließlich loT-Netzwerke, Microservices bereitstellen kann, gemäß manchen Ausführungsformen.
8 ist ein schematisches Diagramm einer Lieferkette, um Serviceverwaltung, Orchestrierung und Verbund-Cloud-Services bereitzustellen, gemäß manchen Ausführungsformen.
9 ist ein Blockdiagramm eines Beispiels für einen Datenzentrumsverwaltungsstapel zur Orchestrierung von Arbeitslast gemäß manchen Ausführungsformen.
10 ist ein schematisches Diagramm einer Orchestrierungsserviceverwaltungsstruktur gemäß manchen Ausführungsformen.
11 ist ein schematisches Diagramm eines Beispiels für eine Anwendung, die zerlegt und in Container verpackt wird, die dann Systemen bereitgestellt werden, gemäß manchen Ausführungsformen.
12 ist ein schematisches Diagramm, das ein Bereitstellungssystem einschließlich einer Einsatzebene und einer Ausführungsebene, gemäß manchen Ausführungsformen, zeigt.
13 ist ein schematisches Diagramm eines Datenzentrumsverbunds zur Orchestrierung und Verwaltung von Zusammenhängen in Vereinbarungen auf Serviceebene, gemäß manchen Ausführungsformen.
14 ist ein schematisches Diagramm eines Beispiels für einen Cloud-Servicelieferverwaltungsprozess, gemäß manchen Ausführungsformen.
15 ist ein schematisches Diagramm eines vereinfachten Beispiels für einen Orchestrierungsprozess gemäß manchen Ausführungsformen.
16 ist ein schematisches Diagramm eines weiteren Beispiels für die Verwendung eines Servicekatalogs zur Bereitstellung von Microservices gemäß manchen Ausführungsformen.
17 ist ein schematisches Diagramm eines Beispiels für eine Bereitstellung von loT-Daten/Analyse-Konsumentenservices gemäß manchen Ausführungsformen.
18 ist ein schematisches Diagramm eines Distributed Services Framework, in dem Microservice-Objekte an unterschiedlichen Orten für Operationen platziert werden können, gemäß manchen Ausführungsformen.
19 ist ein schematisches Diagramm eines gemeinsamen Serviceschnittstellen- (CSI-) Knotens zur Erkennung und Quellenidentifikation gemäß manchen Ausführungsformen.
20 ist ein Blockdiagramm eines Distributed Services Framework (DSF) gemäß manchen Ausführungsformen.
21 ist ein schematisches Diagramm eines Beispiels für ein loT-Netzwerk, das Knoten nutzt und für ein Distributed Services Framework freigegeben ist, gemäß manchen Ausführungsformen.
22 ist ein Blockdiagramm einer gemeinsamen Serviceschnittstellenarchitektur für einen Knoten, gemäß manchen Ausführungsformen.
23 ist ein Blockdiagramm eines Softwareverwaltungssystems für das loT und Microservice-Orchestrierung gemäß manchen Ausführungsformen.
24 ist ein schematisches Diagramm eines Aggregator-Microservice-Entwurfsmusters gemäß manchen Ausführungsformen.
25 ist ein schematisches Diagramm Verzweigungs-Microservice-Entwurfsmusters gemäß manchen Ausführungsformen.
26 ist ein schematisches Diagramm eines Proxy-Microservice-Entwurfsmusters gemäß manchen Ausführungsformen.
27 ist ein schematisches Diagramm eines kombinierten Microservice-Entwurfsmusters gemäß manchen Ausführungsformen.
28 ist ein schematisches Diagramm eines verketteten Microservice-Entwurfsmusters gemäß manchen Ausführungsformen.
29 ist ein schematisches Diagramm eines Softwarestapels für einen Cloud-Service-Datenzentrumsmanager (CSDM) gemäß manchen Ausführungsformen.
30 ist ein Blockdiagramm eines Beispiels für Komponenten, die in einer loT-Vorrichtung vorhanden sein können, um am DSF/CSI-Netzwerk teilzunehmen, gemäß manchen Ausführungsformen.
31 ist ein Blockdiagramm eines beispielhaften nichttransitorischen, maschinenlesbaren Mediums, das Code umfasst, um einen Prozessor anzuweisen, die Arbeitslasten zu platzieren, gemäß manchen Ausführungsformen.

Die gleichen Zahlen werden durchgängig in der Offenbarung und den Figuren genutzt, um gleiche Komponenten und Merkmale zu bezeichnen. Zahlen der Reihe 100 beziehen sich auf Merkmale, die ursprünglich in 1 zu finden sind; Zahlen der Reihe 200 beziehen sich auf Merkmale, die ursprünglich in 2 zu finden, usw.
Beschreibung der Ausführungsformen
In der folgenden Beschreibung werden zahlreiche Details erläutert, um eine umfangreichere Erklärung der vorliegenden Erfindung bereitzustellen. Fachleute auf dem Gebiet der Erfindung werden jedoch verstehen, dass die vorliegende Erfindung ohne diese spezifischen Details praktiziert werden kann. In anderen Fällen werden bekannte Strukturen und Vorrichtungen in Blockdiagrammform anstelle detailliert gezeigt, um zu verhindern, dass die vorliegende Erfindung unklar wird.
Viele Verwaltungs- und Verwaltbarkeitsmodelle nähern sich dem loT mit traditionellen Konzepten der Datenzentrumsquellenverwaltung an. IoT stellt jedoch zahlreiche einzigartige und komplexe Ressourcen- und Service-Interaktionen vor, die traditionelle Verfahren, Softwarearchitekturen und Servicelieferverfahren noch nicht verstehen. Wie hierin verwendet, sind Dinge im loT, wie z.B. Software- oder Hardwareressourcen, selten stationär, sondern können eine Richtung, Geschwindigkeit, Vektor und Bewegung aufweisen. Ganz gleich, wo sie verortet sind, können sie von ihren Steuerungen innerhalb der Richtlinien und Regeln, die in der Service-Verwaltungsdomäne erläutert sind, verwaltet werden.
Im loT können Dinge eingekapselt, verbunden, direkt oder indirekt verwaltet oder durch eine temporäre oder permanente Kette oder Autorität, genannt Verwahrung, zurückgehalten werden. Eine Änderung der Verwahrung oder Einkapselung für Ressourcen innerhalb des loT ist ein gängiges Konzept. Dinge, die hierin auch Objekte genannt werden, können direkt zugänglich sein oder indirekt durch eine übergeordnete oder alternative zuständige Vorrichtung für einen kurzen Zeitraum oder den gesamten Lebenszyklus verwaltet werden.
Eine ordentliche Servicelieferarchitektur kann die Fähigkeit umfassen, alle Dinge zu verwalten und zu steuern, die von diesem Hierarchietyp berücksichtigt werden. Darüber hinaus können Dinge klassifiziert sein und auf Basis dieser Klassifikation Einschränkungen in Bezug auf Verwaltung, Verwaltbarkeit und Steuerung aufweisen.
Dinge können offline sein oder sich im Energiesparmodus oder Schlafmodus befinden. Somit können Verfahren Zustände identifizieren und Wege für Out-Of-Band- (OOB-) Zugriff bereitstellen, um Dinge zu wecken. In manchen Beispielen verfügen Dinge mitunter nicht über die Fähigkeit, In-Band- (IB-) oder Out-Of-Band-Zugriff bereitzustellen. In diesen Fällen kann Zugriff unter Verwendung von Seitenband- (SB-) Zugänglichkeit erhalten werden, in der die Verwaltungsengine durch einen SoC, FPGA oder andere Verwaltbarkeits-Coprozessorlösungen freigegeben werden, die in einem Konnektor für die verfügbaren Schnittstellen für diese Vorrichtung platziert sind. Beispiele können einen universellen seriellen Bus (USB), verstärkte Netzwerk-Konnektoren, Funkschnittstellen, NIC-Adapter, Leuchtadapter und dergleichen umfassen.
Darüber hinaus können Dinge nicht zugänglich oder eingeschränkt zugänglich sein, oder der Zugriff kann beeinträchtigt oder kostenintensiv sein. Nicht alle loT-Vorrichtungen sind über das Internet oder private Netzwerke zugänglich. Zusätzlich dazu, wenn sich Netzwerktransporte verringern oder ändern, müssen die Servicerichtlinien mitunter alternative Analyse- und Serviceliefermechanismen innerhalb der Beschränkungen bereitstellen, wie z.B. Überlegungen zu Privatsphäre und Kosten. Dinge haben mitunter keinen Zugriff auf ein Verwaltungsnetzwerk, sodass das Produktionsnetzwerk (Daten) und Verwaltungsnetzwerk (Steuerung) von den Vorrichtungen und Netzwerken geteilt werden können. In diesen Beispielen stellen die Netzwerksysteme Unterstützung für sowohl Datenströme, bei einer Sicherstellung von Datentrennung, als auch Privatsphäre bereit. Das erfordert mitunter getrennte Sicherheits-, Einkapselungs-, Authentifizierungs- und Berechtigungssysteme. Darüber hinaus können die Datenströme eine Zeitkoordination nutzen, um dabei zu helfen, sicherzustellen, dass sowohl Produktionsdaten als auch Steuerungsdaten im Wesentlichen zur gleichen Zeit an den Zielen ankommen. Das kann durch Puffern und Synchronisieren am Datenursprung durchgeführt werden.
Dinge können spärlich am Rand bereitgestellt werden und Systeme können eine eingeschränkte Rechnerfunktionalität aufweisen. Um die Servicelieferrichtlinien des loT-Benutzers zu unterstützen, kann die Architektur die Fähigkeit umfassen, die Edge-Ressourcen zu gruppieren, um Edge- oder Fog-Analytik bereitzustellen. Die Systeme hierin stellen die Fähigkeit bereit, dass sich diese Ressourcen eigenständig aggregieren können, beispielsweise um einen Fog zu bilden, um einen locker verbundenen Cluster auf Basis der Serviceanforderungen aufzubauen.
Bei aktuellen Modellen können Dinge bestehende loT-Services und Serviceliefermodelle beeinträchtigen. Beispielsweise können Erkennungsservices hart kodierte DNS- oder DHCP-Services leiten, senden oder aufweisen, die Bandbreite benötigen. Außerdem sind Dinge mitunter nicht in der Lage, sich selbst zu verwalten oder auf externe Anfragen und Stimuli mit dem ausreichenden Verständnis zu antworten, welche Auswirkungen die Antwort auf ihre eigenen Operationen und Serviceselbstregulierung hat.
In den hierin beschriebenen Verfahren können sich Dinge ihrer Umgebungen und Peers in der Nähe bewusst sein, um Arbeit zu koordinieren, Orchestrierungs- (Service-) Verwaltung zu ermöglichen, eine Führung zu bestimmen oder Funktionen zu teilen, um ihre Aufgaben zu erfüllen. Die loT-basierte Lösung kann auf unterschiedliche Weise, an verschiedenen Orten, Regionen oder in unterschiedlichen Anwendungsfällen implementiert werden. Die Architektur kann Implementierungs-basierte Variationen in Bezug auf die Zugänglichkeit für Verwaltung, Hochladen von Daten und Analytik berücksichtigen.
Die hierin beschriebenen Mechanismen und Infrastruktur können ermöglichen, dass Anwendungen entwickelt, dynamisch eingesetzt und über loT-Vorrichtungen verwaltet werden, wodurch eine Software-definierbare loT-Infrastruktur erzeugt wird, die sich der verändernden Umgebung anpasst und Software umfassen kann, die umdefinierbar ist, um die Anforderungen des Benutzers oder Unternehmens zu erfüllen. In der loT-Infrastruktur können loT-Anwendungen aus einer Menge von Codemodulen bestehen, die hierin Microservices genannt werden und auf physischen Ressourcen dynamisch eingesetzt werden können, um ein bestimmtes Ziel eines Benutzers oder Unternehmens zu erreichen. Die Microservices können gebaut werden, um im gesamten Computerstapel eingesetzt werden zu können, beispielsweise u.a. in loT-Knoten, Rechnerknoten, Gateways, lokalen Fog-Vorrichtungen und der Cloud. Sie können in Form von Containern, Code in virtuellen Maschinen oder direkt auf Hardware programmierter Firmware eingesetzt werden. Wo und wie jede Komponente eingesetzt wird, kann von einem Orchestrierungsmechanismus dynamisch gesteuert werden.
Wie hierin beschrieben, umfassen die Verfahren ein Softwareliefersystem, das hierin Distributed Services Framework (DSF) genannt wird, und eine Verwaltungsstruktur, die hierin gemeinsame Serviceschnittstelle (CSI) genannt wird. Wie hierin verwendet, ist das DSF eine Serviceliefernetzwerkstruktur, die einen Bezugspunkt dazu bereitstellen kann, wie loT-Ressourcen verwaltet werden, um eine ordentliche und durchgängige Servicelieferung am Rand oder über die Cloud sicherzustellen. Diese verbesserte Architektur kann einige der Ressourcengrundservices in diesem Framework umfassen, ohne eine Agent- oder Middleware-Funktionalität zu nutzen.
Der Manager oder Besitzer der Ressourcendomäne kann die Einhaltung der vertraglichen Servicelieferung sicherstellen, wie z.B. Vereinbarungen auf Serviceebene (SLAs), in dem das DSF für eine ordentliche Ressourcenerkennung, - registrierung und -zertifizierung, Objektverwaltung und Microservice-Platzierung genutzt wird. Das kann dabei helfen, Echtzeitanforderungen zu erfüllen und Netzwerkressourcen zu optimieren. DSF kann die Ansammlung, Zusammensetzung und Kontextverwaltung on loT-Ressourcen, wie z.B. Vorrichtungen, traditionelle oder Altserver, Cloud-Ressourcen, Infrastrukturkomponenten und dergleichen kosteneffizient, dynamisch und fehlerresistent ermöglichen.
Außerdem kann die CSI, die als virtueller Datenbus fungiert, eine Ressourcenautonomie ermöglichen, indem das Ding freigegeben wird, u.a. selbstbeschreibend, selbstwahrnehmend und autonom zu sein. Die CSI kann außerdem eine lokale/Edge-Eigenorchestrierung bereitstellen. Darüber hinaus kann ein Ressource-Knoten unter einer CSI seine eigene Leistungsfähigkeit, finanziellen Wert, Benutzer- und Richtlinienallokation, Beibehaltung, Allokation und Funktionalität beschreiben. Die Beschreibung kann die standardmäßige Serviceebenen- und Serviceliefernomenklatur über eine Programmierschnittstelle (API) oder einen Data Distribution Service (DDS), wie z.B. publish/subscribe (Pub/Sub) oder andere Subskriptionsmodelle nutzen. Zusätzlich dazu kann die CSI eingebettete Richtlinien nutzen, um die Verwaltung, Steuerung und das Aufrufen von Ressourcen mit der Ressourcenschnittstelle selbst zu verbinden, was die Latenz der Antwort im Online-, Offline- und Energiesparzustand verringern kann. Die CSI stellt sich selbst als intelligentes Objekt dar, beispielsweise, um neue Protokolle für einen Representational State Transfer (REST), wie ein Constrained Application Protocol (CoAP), zu unterstützen und statische Metadaten, dynamische Metadaten und Service-bewusste Telemetrie bereitzustellen.
Wie hierin verwendet, ist die CSI ein intelligentes System, das ein Ding mit Selbstwahrnehmung, Autorität und Autonomie ausstatten kann. Dadurch wird die primäre Schnittstelle zur Kommunikation mit dem DSF und die Fähigkeit zur Eigenverwaltung bereitgestellt, um mehrere Ereignisse zur gleichen Zeit zu priorisieren und darauf zu antworten und bei der Sicherstellung einer organisierten, überprüften und akzeptablen Antwort von der Ressource oder dem Ding zu helfen. Die CSI kann alle Informationen umfassen, die die Ressource betreffen, beispielsweise Informationen, die von externen Referenzen erhoben wurden, wie eine Reputationsberechnung oder Feedback zum Erreichen von Zielen auf Serviceebene. Die CSI stellt außerdem die Fähigkeit bereit, Teil eines Services zu sein, Kontextinformationen für die Servicesitzung bereitzustellen und die Verbindungen in und aus einem Subnetz für die Servicesitzung zu verstehen, die hierin Nord- und Südverbindungen genannt werden können. Außerdem kann sie die Verbindungen und Funktionalitäten von Peer-Vorrichtungen im Subnetz verstehen, die hierin Ost- und Westverbindungen genannt werden können, um beispielsweise eine ordentliche Antwort auf eine Orchestrierungsanfrage, eine Serviceverwaltungsanfrage oder eine Wiederherstellungsanfrage sicherzustellen, wie wenn ein Ding ein lokales Ziel auf Serviceebene nicht erreicht.
Das DSF und die CSI können eine neue Architektur und Paradigma für loT-Software-definierte Infrastruktur (SDI) bereitstellen, die eine Netzwerkinfrastruktur umfassen kann, die die Wahrnehmung und Adaptierbarkeit an eine dynamische, sich ändernde Umgebung ermöglicht. In dieser SDI können die Dinge selbstwahrnehmend und selbstbeschreibend sein und Handlungen automatisch mit nahen ähnlich ausgestatteten Ressourcen peeren, kommunizieren und koordinieren. Services können unabhängig und auf eine Weise geroutet sein, die den Anforderungen der End-to-End-Services und zugeordneten SLAs entsprechen. Vorrichtungen können außerdem eine Wahrnehmung von ihrem Edge-Netzwerkstatus haben, in dem die Vorrichtungen, die die Microservices hosten, keine Server in Datenzentren sind. Die Microservices können für Zielressourcen dynamisch in Containern eingekapselt sein. Darüber hinaus können die Vorrichtungen selbst Konsumenten von anderen Microservices von anderen Vorrichtungen sein.
1 ist eine Zeichnung eines Cloud-Rechnernetzwerks oder einer Cloud 102, die in Kommunikation mit einer Reihe von Internet-der-Dinge- (IoT-) Vorrichtungen steht, gemäß manchen Ausführungsformen. Die Cloud 102 kann für das Internet oder ein lokales Netzwerk (LAN) oder ein Großraumnetzwerk (WAN), wie z.B. ein proprietäres Netzwerk für ein Unternehmen stehen. Die loT-Vorrichtungen können eine beliebige Anzahl von unterschiedlichen Arten von Vorrichtungen umfassen, die in zahlreichen Kombinationen gruppiert sind. Beispielsweise kann eine Verkehrssteuergruppe 106 loT-Vorrichtungen entlang von Straßen in einer Stadt umfassen. Diese loT-Vorrichtungen können Ampeln, Verkehrsflussüberwachungen, Kameras, Wettersensoren und dergleichen umfassen. Die Verkehrssteuergruppe 106 oder andere Untergruppen können durch drahtlose Verbindungen 108, wie z.B. Niedrigenergie-Großraum- (LPWA-) Verbindungen und dergleichen mit der Cloud 102 in Kommunikation stehen. Außerdem kann ein drahtgebundenes oder drahtloses Subnetzwerk 112 ermöglichen, dass die loT-Vorrichtungen miteinander kommunizieren, wie z.B. über ein lokales Netzwerk, ein drahtloses lokales Netzwerk und dergleichen. Die loT-Vorrichtungen können eine weitere Vorrichtung, wie z.B. ein Gateway 110 nutzen, um mit der Cloud 102 zu kommunizieren. In manchen Beispielen kann das Subnetzwerk 112 eine oder mehrere der loT-Vorrichtungen unter Verwendung eines drahtgebundenen Netzwerks mit dem Gateway 110 verbinden.
Darüber hinaus können beliebige der loT-Vorrichtungen außerdem einen oder mehrere Server (nicht gezeigt) nutzen, die operativ entlang von Gateway 110 oder zwischen der Gruppe 106 und dem Gateway 110 angeordnet sind, um die Kommunikation der Gruppe 106 mit der Cloud 102 oder mit dem Gateway 110 zu erleichtern. Beispielsweise können der eine oder die mehreren Server als Zwischennetzwerkknoten operieren, um eine lokale Edge-Cloud- oder Fog-Implementierung in einem lokalen Netzwerk zu unterstützen.
Die Netzwerktopologie kann unterschiedliche Arten von loT-Netzwerken umfassen, wie ein Mesh-Netzwerk über Bluetooth®-Niedrigenergie- (BLE-) Verbindungen. Andere Arten von loT-Netzwerken können ein drahtloses lokales Netzwerk (WLAN), um mit den loT-Vorrichtungen über die Verbindungen IEEE 802.11 (Wi-Fi®) zu kommunizieren, ein Mobilfunknetz, um mit den loT-Vorrichtungen über ein LTE/LTE-A-(4G)- oder 5G-Mobilfunktnetz zu kommunizieren und ein LPWA-Netzwerk umfassen. Ein LPWA-Netzwerk kann mit der Long-Range-Wide-Area-Network- (LoRaWAN™) Spezifikation, die von der LoRa-Alliance veröffentlicht wurde, kompatibel sein. Die Netzwerktopologie oder loT-Netzwerk(e) können IPv6 über Niedrigenergie-Großraumnetzwerke (LPWAN) umfassen, die mit einer von der Internet Engineering Task Force (IETF) veröffentlichten Spezifikation kompatibel sind. Darüber hinaus können die entsprechenden loT-Netzwerke mit einem externen Netzwerkanbieter, wie einem Tier-2- oder Tier-3-Anbieter im Internet über eine Vielzahl von Kommunikationsverbindungen kommunizieren. Die Kommunikationsverbindungen können eine LTE-Mobilfunkverbindung, eine LPWA-Verbindung oder eine Verbindung auf Basis des Standards IEEE 802.15.4, wie z.B. Zigbee® etc. umfassen. Die entsprechenden loT-Netzwerke können auch durch Netzwerk- und Internetanwendungsprotokolle, wie dem Constrained Application Protocol (CoAP) operieren. Die entsprechenden loT-Netzwerke können auch in die Koordinatorvorrichtungen, die eine Kette von Verbindungen bereitstellen, die Cluster-Bäume aus verbundenen Vorrichtungen und Netzwerken bilden, integriert sein.
Obwohl drahtlose Netzwerke und drahtgebundene Netzwerke, wie z.B. LPWA-Verbindungen, optische Verbindungen und dergleichen beschrieben werden, gilt anzumerken, dass eine beliebige Netzwerkart genutzt werden kann, um die Vorrichtungen miteinander oder mit einem Gateway 110 zu verbinden. Ein Netzwerk oder eine assemblierte Gruppe von Vorrichtungen kann über sowohl drahtlose als auch drahtgebundene Verbindungen aufweisen und kann beide gleichzeitig zwischen Knoten, Peers und Gateway-Vorrichtungen nutzen. Außerdem kann das Netzwerk oder die assemblierte Gruppe von Vorrichtungen drahtgebundene Netzwerke, drahtlose Netzwerke oder beides nutzen, um mit der Cloud und beliebigen Hochleistungsrechnervorrichtungen zu kommunizieren, die an der Lieferung der Services beteiligt sein können oder das hierin offenbarte unterstützen. Somit kann eine beliebige Verbindung 108 oder ein beliebiges Netzwerk 112 eine drahtgebundene oder eine drahtlose Verbindung nutzen. Darüber hinaus können loT-Vorrichtungen in direkter Kommunikation mit anderen Vorrichtungen in der Cloud 102 ohne die Verwendung von Gateway 110 stehen. Zusätzlich dazu können die Verbindungen 108 optische Signalpfade zwischen loT-Vorrichtungen mit der Cloud 102 und den Gateway(s) 110, einschließlich der Verwendung von MUXing/deMUXing-Komponenten nutzen, die die Verbindung zwischen den verschiedenen Vorrichtungen erleichtert.
Andere Gruppen von loT-Vorrichtungen können u.a. entfernte Wetterstationen 114, lokale Informationskiosken 116, Alarmsysteme 118, Geldautomaten 120, Alarmtafeln 122 oder sich bewegende Fahrzeuge, wie Einsatzfahrzeuge 124 oder andere Fahrzeuge 126 umfassen. Jeder dieser loT-Vorrichtungen kann in Kommunikation mit anderen loT-Vorrichtungen, mit Datenzentren, einschließlich Servern 104, oder beidem stehen.
Wie in 1 ersichtlich, kann eine große Anzahl von loT-Vorrichtungen durch die Cloud 102 kommunizieren. Dadurch wird ermöglicht, dass unterschiedliche loT-Vorrichtungen autonom Informationen anfordern oder anderen Vorrichtungen bereitstellen können. Beispielsweise kann die Verkehrssteuergruppe 106 eine aktuelle Wettervorhersage von einer Gruppe entfernter Wetterstationen 114 anfordern, die die Vorhersage ohne menschliches Eingreifen bereitstellen können. Da jede CSI-freigegebene Vorrichtung automatisch mit dem DSF verbunden werden kann, kann die Cloud zahlreiche „Service-Frequenzen“ freigeben, denen sich diese Ressourcen anschließen können.
Wenn sich bewegende loT-Vorrichtungen in Verwaltungsdomänen eintreten oder diese sich diesen nähern, können sie darüber hinaus neue Richtlinien empfangen, die für ihre Operation relevant sind. Wenn sich beispielsweise ein Rettungswagen einem Fahrzeug von hinten nähert, können relevante Metadaten und Telemetrien an das Fahrzeug gesendet werden, um eine vollständige Wahrnehmung der Umgebung und Einleitung operativer Veränderungen, wie dem Abfahren von der Straße und Halten, sicherzustellen. In einem weiteren Beispiel kann ein Auto, das Kalifornien verlässt und Nevada betritt, Richtlinien, wie z.B. Geschwindigkeitsbegrenzungen, die für Nevada relevant sind, empfangen.
In einem weiteren Beispiel kann ein Einsatzfahrzeug 124 von einem Geldautomaten 120 alarmiert werden, dass ein Einbruch im Gange ist. Wenn das Einsatzfahrzeug 124 in Richtung des Geldautomaten 120 fährt, kann es auf die Verkehrssteuergruppe 106 zugreifen, um eine Freigabe zu dem Ort anzufordern, beispielsweise durch das Schalten von Ampeln auf Rot, um Querverkehr an einer Kreuzung rechtzeitig zu blockieren, sodass das Einsatzfahrzeug 124 einen ungehinderten Zugang zur Kreuzung hat. Darüber hinaus kann das Einsatzfahrzeug 124 die Informationen, die es über sich selbst auf dem DSF aussendet, um sicherstellen zu können, dass andere loT-System, wie automatisierte Fahrzeuge, Straßenbeleuchtungen und Ampeln wahrnehmen, dass sich ein Fahrzeug mit hoher Priorität nähert und der Weg freigemacht werden muss.
Wie hierin beschrieben, umfassen die loT-Vorrichtungen der Verkehrssteuergruppe 106 mitunter nicht die Funktionalität dafür, dass das Einsatzfahrzeug 124 eine Freigabe anfordern kann. Wenn das Einsatzfahrzeug 124 in diesem Beispiel das Freigabe-Service anfordert, kann eine loT-Vorrichtung in der Verkehrssteuergruppe 106 oder der Gateway 110 anfordern, dass das Freigabe-Service über ein Distributed Services Framework (DSF) heruntergeladen wird. Die loT-Vorrichtungen können dann den Ort für das Freigabe-Service orchestrieren und das Freigabe-Service an einem Ort in der Verkehrssteuergruppe 106 aktivieren.
Wie hierin beschrieben, können loT-Vorrichtungen mit veränderten Bedingungen höhere Belastungen erfahren, was zu höheren Latenzzeiten, verringerter Leistung oder Datenverlust führt. Wenn das Einsatzfahrzeug 124 beispielsweise auf die Kreuzung zufährt, kann die erhöhte Kommunikation zwischen den Ampeln die Steuerungen in den Ampeln überlasten. Dementsprechend kann die Verkehrssteuergruppe 106 Operationen, wie z.B. Ampelsteuerung, von den Ampeln auf andere Vorrichtungen in der Verkehrssteuergruppe 106, wie Datenaggregatoren, Server oder andere Vorrichtungen, verlagern, um zu ermöglichen, dass der Freigabe-Service in den Ampeln durchgeführt wird. Diese Vorrichtungen können lokal in der Verkehrssteuergruppe 106 geortet oder über ein Netzwerk erreicht werden. Die genutzten Vorrichtungen implementieren die Anwendung oder können die Systeme im Einsatzfahrzeug 124 selbst umfassen.
Cluster von loT-Vorrichtungen, wie entfernte Wetterstationen 114 oder die Verkehrssteuergruppe 106, können ausgestattet sein, um mit anderen loT-Vorrichtungen sowie der Cloud 102 zu kommunizieren. Dadurch kann ermöglicht werden, dass die loT-Vorrichtungen einen Cluster von Vorrichtungen bilden und dadurch als eine Vorrichtung fungieren können, die als Fog-Vorrichtung bezeichnet werden kann. Die Fog-Vorrichtung wird in Bezug auf 2 genauer beschrieben.
2 ist eine Zeichnung 200 eines Cloud-Rechnernetzwerks oder einer Cloud 102, gemäß manchen Ausführungsformen, in Kommunikation mit einem Mesh-Netzwerk von loT-Vorrichtungen, bei denen es sich um ein Beispiel für eine Fog-Vorrichtung 202 handeln kann, die am Rand der Cloud 102 operiert. Elemente mit gleichen Zahlen sind wie in Bezug auf 1 beschrieben. Wie hierin verwendet, ist eine Fog-Vorrichtung 202 ein Cluster von Vorrichtungen, die gruppiert werden können, um eine spezifische Funktion durchzuführen, wie z.B. Verkehrssteuerung, Wetterüberwachung, Anlagensteuerung, Heimüberwachung und dergleichen.
Obwohl die Fog-Vorrichtung 202 in diesem Beispiel als Mesh-Netzwerk gezeigt wird, z.B. mit interaktiven Kommunikationsverbindungen zwischen jedem Vorrichtungspaar, kann eine Fog-Vorrichtung 202 von Vorrichtungen, die mit einem standardmäßigeren Netzwerk verbunden sind, gebildet werden. Beispielsweise können die Vorrichtungen entlang von Netzwerkkommunikationen platziert werden und durch die Gateways 110, wie in 1 gezeigt, kommunizieren. In diesem Beispiel kann die Fog-Vorrichtung 202 eine virtuelle Vorrichtung sein, die durch an jede Vorrichtung gesendete Identitätsnachweise, wie hierin beschrieben, implementiert werden.
Objekte, die die loT-Vorrichtungen können miteinander interagieren, um größere Funktionen, Ziele oder Arbeitsabläufe zu erreichen, wie z.B. die Bildung einer Fog-Vorrichtung. Objekte können in Bezug auf ihren Typ, z.B. durchgeführte Funktion, und Instanz, z.B. Anwesenheit identifiziert werden. Mehrere Objektinstanzen können die gleiche Typidentität aber verschiedene Instanzidentitäten aufweisen. Außerdem können mehrere Objektinstanzen in Gruppen organisiert werden, in denen eine Instanz der Gruppierung eine Identität aufweisen kann. Eine Gruppe von Dingen, die je nach Typ, z.B. Funktion, Status und Schnittstellensemantik, auf bestimmte Weise interagieren, kann ein zusammengesetztes Objekt darstellen. Die Zusammensetzung selbst kann eine Abstraktion von Typ und Instanz aufweisen. Daher folgen zusammengesetzte Objekte den gleichen Identitätsregeln wie atomare Objekte. Eine Zusammensetzung mit Typ- und Instanzeigenschaften ermöglicht eine Objekterweiterbarkeit durch Zusammensetzung.
Das Ding oder Objekt kann so lange andauern wie eine einzelne Vorrichtung, wie z.B. ein Kühlschrank, oder bis eine aktuelle Funktion abgeschlossen ist. Beispielsweise kann ein Kühlschrank als zusammengesetztes Objekt oder Fog-Vorrichtung 202 betrachtet werden, die aus mehreren anderen Objekten, wie einem Licht, einem Kompressor, einem Temperatursensor, einem Thermostat, einem Wasserspender, einem Eisbereiter und dergleichen besteht. Die anderen Objekte können jeweils atomar oder selbst zusammengesetzte Objekte sein. Beispielsweise kann es sich bei einem Eisbereiter um ein zusammengesetztes Objekt handeln, das aus atomaren Objekten, wie einem Temperatursensor, einem Thermostat, einem elektromagnetisch betriebenen Wasserventil, einem Zeitmesser, einem Eisbehälter und dergleichen besteht. Ein Beispiel für ein virtuelles zusammengesetztes Objekt oder eine Fog-Vorrichtung 202, die aus einer Reihe von physischen Vorrichtungen besteht, sind die hierin beschriebene Kreuzung und Einsatz-Cluster.
Dementsprechend kann die Objektidentität im Kontext von drei Abstraktionen verstanden werden: Objektinstanz, Objekttyp und Metaidentität. Eine Objektinstanz ist ein Rechnerelement, das endliche Ressourcen besetzt, wie Arbeitsspeicher, CPU, Bandbreite, Status und dergleichen. Eine Objektinstanziierung weist einen Lebenszyklus auf, der Erzeugung, Veränderung und Löschung umfasst. Ein Objekttyp ist ein logisches Konstrukt, das erwartetes oder mögliches Verhalten, Zustände und Zusammensetzung festlegt. Der Objekttyp kann Einschränkungen in Bezug auf das Verhalten und die Interaktion von Objekten bei ihrer Instanziierung festsetzen. Der Objekttyp kann außerdem die Anfragetypen, auf die das Objekt antworten kann, anzeigen, wie zum Beispiel die Schnittstelle.
Metaidentität ist eine Art um Metadatenkontext, in dem das Objekt existieren kann, zu definieren. Ein Objekt nimmt mitunter nicht wahr, dass es Metaidentität einkapselt. Objektinstanzen können dynamisch stereotypisierende Informationen anwenden, indem eine Gruppe mit dem gewünschten Metadatenkontext definiert wird und das Objekt dann in die Gruppe eingeschrieben wird.
Authentifizierung und Identität sind sortierte Punkte. Einer Objektidentität kann nicht geglaubt werden, wenn sie nicht authentifiziert wird. Eine Authentifizierung ohne Identität hat jedoch nur einen eingeschränkten Nutzen. Eine asymmetrische Schlüsselsignatur, wie z.B. ECDSA (Elliptic Curve Digital Signature Algorithm), RSA, oder dergleichen ist zur Authentifizierung unter der Erwartung, dass die Fähigkeit, den privaten Schlüssel zu kopieren oder zu verteilen, restriktiert ist, von Nutzen. Durch die Verwendung des Schlüssels wird ein Proof-a-Principal oder Agent begründet, der Zugriff auf den Schlüssel hat, obwohl dieser restriktiert ist. Daher muss der Principal oder Agent authentifiziert sein.
Die Authentifizierungssemantik folgt bei ihrer Anwendung auf Objektidentitäten ebenfalls den drei Abstraktionen Objektinstanz, Objekttyp und Metaidentität. Bei einer Objektinstanz legt die Authentifizierungs-Challenge-Response fest, dass die aktuelle Interaktion nur mit einer bestimmten Instanziierung des Objekts erfolgen kann. Bei einem Objekttyp bestätigt die Authentifizierungs-Challenge-Response, dass die aktuelle Interaktion durch die Semantik der Typidentifizierung eingeschränkt wird. Bei Metaidentität kategorisiert die Authentifizierungs-Challenge-Response die aktuelle Interaktion gemäß dem definierten Kontext.
Blockchains können genutzt werden, um Informationen für sowohl die Authentifizierung als auch Bildung der Vorrichtungen bereitzustellen. Blockchains können genutzt werden, um Identifikation zu dezentralisieren, da sie eine Vereinbarung zwischen den Vorrichtungen in Bezug auf Namen und Identitäten, die derzeit verwendet werden, bereitstellen können. Wie hierin verwendet, ist eine Blockchain eine verteilte Datenbank von Identitätsaufzeichnungen, die aus Datenstrukturblöcken besteht. Außerdem kann der Begriff Blockchain, wie hierin verwendet, ein oder mehrere andere Distributed-Ledger-Systeme umfassen. Andere Distributed-Ledger-Ansätze umfassen Ripple, Hyperledger, Multichain, Keyless Signature Infrastructure und dergleichen. Jeder Datenstrukturblock basiert auf einer Transaktion, wobei die Ausgabe eines neuen Namens an eine Vorrichtung, zusammengesetzte Vorrichtung oder virtuelle Vorrichtung ein Beispiel einer Transaktion darstellt.
Wenn Blockchains zur Identifizierung genutzt werden, kann eine Imitation durch das Beobachten einer erneuten Ausgabe von Namen und Identitäten ohne einen entsprechenden Abschluss detektiert werden. öffentliche Blockchains können von besonderem Nutzen sein, da sie ermöglichen können, dass eine vielseitige Gemeinschaft von Beobachtern eine falsche Benennung, bösartige Benennung oder den Ausfall einer Namensinfrastruktur detektiert. Daher kann eine vertrauenswürdige Identitätsinfrastruktur entscheidend für vertrauenswürdige loT-Netzwerke sein.
Obwohl die Fog-Vorrichtung 202 in diesem Beispiel so gezeigt wird, dass sie aus Vorrichtungen an einem einzigen Ort besteht, können Fog-Vorrichtungen Vorrichtungen an mehreren Orten umfassen, die gebildet sind, um spezifische Services bereitzustellen. Beispielsweise kann die Fog-Vorrichtung 202 entfernte Wetterstationen umfassen, die in der Cloud 102 liegen. Darüber hinaus kann ein Server 104, der sich in einem Datenzentrum befindet, von der Fog-Vorrichtung 102 zur Datenanalyse und für andere Services umfasst. Die Bildung der Fog-Vorrichtung 202 kann einfach durch das Teilen von Benennungs-, Typ- und Identifikationsinformationen, wie z.B. Gruppenidentitätsnachweise zwischen den unterschiedlichen Vorrichtungen, die die Fog-Vorrichtung bilden, erfolgen.
In diesem Beispiel umfasst die Fog-Vorrichtung 202 eine Gruppe von loT-Vorrichtungen an einer Verkehrskreuzung. Die Fog-Vorrichtung 202 kann unter Verwendung der hierin beschriebenen gemeinsamen Serviceschnittstelle (CSI) errichtet werden. Zusätzlich zur CSI können andere Techniken genutzt werden, beispielsweise kann die Fog-Vorrichtung 202 u.a. gemäß den vom OpenFog Consortium (OFC) veröffentlichten Spezifikationen gebildet werden. Diese Spezifikationen ermöglichen die Bildung einer Hierarchie von Rechnerelementen zwischen den Gateways 110, die die Fog-Vorrichtung 202 mit der Cloud 102 und Endpunktvorrichtungen verbinden, wie in diesem Beispiel Verkehrsampeln 204 und Datenaggregatoren 206. Die Fog-Vorrichtung 202 kann die kombinierten Prozessor- und Netzwerkressourcen nutzen, die das Kollektiv der loT-Vorrichtungen bereitstellt. Dementsprechend kann ein Fog-Vorrichtung 202 für eine Reihe von Anwendungen genutzt werden, wie z.B. Anlagensteuerung, Finanzmodellierung, Wettervorhersage, Verkehrsanalysen und dergleichen. Für jede Vorrichtung, die von der CSI für die Dauer des Services gesteuert wird, nimmt die CSI das Ziel auf Serviceebene (SLO) für die Ressource an, um sicherzustellen, dass die Vereinbarung auf Serviceebene (SLA) insgesamt für die Servicesitzung erreicht wird.
Beispielsweise kann der Verkehrsfluss über die Kreuzung von den Verkehrsampeln 204 gesteuert werden. Die Analyse des Verkehrsflusses und Steuerschemata können durch Aggregatoren 206 implementiert werden, die in Kommunikation mit den Verkehrsampeln 204 und einander stehen. Die Implementierung der Verkehrsflussanwendungen kann in den Verkehrsampeln 204 selbst stattfinden. Daten können in die Cloud 102 hochgeladen werden und Befehle von der Cloud 102 über die Gateways 110 empfangen werden, die in Kommunikation mit den Verkehrsampeln 204 und den Aggregatoren 206 stehen. Entfernte Vorrichtungen in der Cloud 102, die mit der Fog-Vorrichtung 202 verbunden sind, können über die Gateways 110 erreicht werden.
In der Fog-Vorrichtung 202 kann eine beliebige Anzahl von Kommunikationsverbindungen zur Kommunikation mit lokalen Vorrichtungen genutzt werden. Kurzstreckenverbindungen 208, die beispielsweise mit IEEE 802.15.4 kompatibel sind, können lokale Kommunikation zwischen loT-Vorrichtungen bereitstellen, die sich in der Nähe der Kreuzung befinden. Langstreckenverbindungen 210, die beispielsweise mit LPWA-Standards kompatibel sind, können Kommunikation zwischen den loT-Vorrichtungen und den Gateways 110 bereitstellen. Um das Diagramm zu vereinfachen, ist nicht jede Kommunikationsverbindung 208 oder 210 mit einer Bezugszahl beschriftet.
In diesem Beispiel kann die Fog-Vorrichtung 202 als stark vernetztes Netzwerk verstanden werden, in dem eine Vielzahl von loT-Vorrichtungen und anderen Vorrichtungen miteinander in Kommunikation stehen, beispielsweise durch die Kommunikationsverbindungen 208 und 210 und durch die Gateways 110. Das Netzwerk kann unter Verwendung der Standardspezifikation 1.0 des Open Interconnect Consortium (OIC), das von der Open Connectivity Foundation™ (OCF) am 23. Dezember 2015 veröffentlicht wurde, errichtet werden. Dieser Standard ermöglicht, dass die Vorrichtungen einander erkennen und Kommunikationen für Zwischenverbindungen aufbauen. Außerdem können andere Zwischenverbindungsprotokolle genutzt werden, wie z.B. u.a. das AllJoyn-Protokoll der AllSeen Alliance, das Optimized-Link-State-Routing- (OLSR-) Protokoll oder Better Approach To Mobile Ad-hoc Networking (B.A.T.M.A.N.). Wie hierin beschrieben, stellt die CSI eine Netzwerkkommunikation und ein Protokoll bereit, das zum Errichten der Fog-Vorrichtung 202 genutzt werden kann.
In manchen Aspekten kann die Kommunikation von einer loT-Vorrichtung entlang des bequemsten Pfads gesendet werden, um die Gateways 110 zu erreichen, zum Beispiel u.a. der Pfad mit den wenigsten dazwischenliegenden Hops oder der größten Bandbreite. In diesen Netzwerken stellt die Anzahl der Zwischenverbindungen eine wesentliche Redundanz bereit, wodurch Kommunikationen selbst beim Verlust von einer Reihe von loT-Vorrichtungen erhalten werden können.
In manchen Aspekten kann die Fog-Vorrichtung 202 vorübergehende loT-Vorrichtungen umfassen. Anders ausgedrückt, müssen nicht alle loT-Vorrichtungen dauerhafte Mitglieder der Fog-Vorrichtung 202 sein. Im beispielhaften System 200 haben sich beispielsweise drei vorübergehende loT-Vorrichtungen der Fog-Vorrichtung 202 angeschlossen, ein erster Fahrzeug 212, ein zweites Fahrzeug 214, und ein Fußgänger 216. In diesen Fällen kann die loT-Vorrichtung in die Fahrzeuge 212 und 214 eingebaut sein oder sich auf einer App oder einem Smartphone befinden, das vom Fußgänger 216 getragen wird. Weitere loT-Vorrichtungen können ebenfalls vorhanden sein, wie loT-Vorrichtungen in Radcomputern, Motorradcomputern, Drohnen und dergleichen. Außerdem können Services, die sich in Datenzentren befinden, wie Verkehrsanalyseservices zur Fog-Vorrichtung 202 auf vorübergehender oder dauerhafter Basis hinzugefügt werden. Wie hierin beschrieben, können diese Services vom und zum Datenzentrum zur Fog-Vorrichtung 202, wie z.B. zu den Datenaggregatoren 206, abhängig vom Ort, an dem die bereitgestellten Daten genutzt werden, verschoben werden.
Wie hierin beschrieben, können die Anwendungen, die die Fog-Vorrichtung steuern, auf beliebigen Ebenen operieren, was von einer Reihe von Faktoren abhängt, wie dem Zweck jeder Vorrichtung und der Last auf die Systeme. Beispielsweise können die Verkehrsampeln 204 Sensoren überwachen, um sich nähernden Verkehr, wie Fahrzeuge, Fußgänger, Fahrräder und dergleichen zu identifizieren, um eine Verkehrssteuerungsanwendung zu implementieren. Die Sensoren können Kameras sein, die Videostreams der Straßen erfassen und die Videostreams zur Analyse an die Verkehrsampeln 204 weiterleiten. Unter normalen Operationen können die Verkehrsampeln 204 miteinander kooperieren, um zu bestimmen, welche Straßen grüne Ampeln und welche Straßen rote Ampeln anzeigen.
Nichtsdestotrotz können die Verkehrsampeln 204 während Zeiten, in denen der Verkehr besonders stark ist, überlastet sein. Dementsprechend kann die Analyse des Verkehrs zu den Datenaggregatoren 206 oder Gateways 110 verlagert werden. Darüber hinaus können Teile des Analyse zu anderen Vorrichtungen verlagert werden, die in Kontakt mit den Verkehrsampeln 204 als Teil der Fog-Vorrichtung 202 stehen, wie die Fahrzeuge 212 und 214, je nach Kontaktzeit, Funktionalität von Fahrzeug 212 oder 214 und dergleichen. Sobald die Auslastung wieder zu einem Normalwert zurückkehrt, kann die Analyse zurück zu den Verkehrsampeln 204 verschoben werden.
Die aus den loT-Vorrichtungen gebildete Fog-Vorrichtung 202 kann den Clients in der Cloud 102, wie dem Server 104 als einzelne Vorrichtung am Rand der Cloud 102 präsentiert werden. In diesem Beispiel kann die Steuerkommunikation mit spezifischen Ressourcen in der Fog-Vorrichtung 202 ohne die Identifizierung einer spezifischen loT-Vorrichtung innerhalb der Fog-Vorrichtung 202 erfolgen. Wenn eine loT-Vorrichtung in der Fog-Vorrichtung 202 versagt, sind dementsprechend andere loT-Vorrichtungen in der Fog-Vorrichtung 202 mitunter in der Lage, eine Ressource zu erkennen und zu steuern, wie einen Aktuator oder eine andere Vorrichtung, die mit einer loT-Vorrichtung verbunden ist. Beispielsweise können die Verkehrsampeln 204 verdrahtet sein, um zu ermöglichen, dass eine beliebige der Verkehrsampeln 204 die Ampeln für die anderen Verkehrsampeln 204 steuert. Die Aggregatoren 206 können außerdem Redundanz bei der Steuerung der Verkehrsampeln 204 und anderen Funktionen der Fog-Vorrichtung 202 bereitstellen. Die Funktionalität kann in der CSI enthalten und durch diese erreichbar sein.
In manchen Beispielen können die loT-Vorrichtungen unter Verwendung eines imperativen Programmierstils konfiguriert werden, bei dem z.B. jede loT-Vorrichtung eine spezifische Funktion und Kommunikationspartner hat. Allerdings können die loT-Vorrichtungen, die die Fog-Vorrichtung 202 bilden, auch in einem deklarativen Programmierstil konfiguriert werden, mit dem ermöglicht wird, dass die loT-Vorrichtungen ihre Operationen und Kommunikationen umkonfigurieren können, um wünschenswerte Ressourcen als Antwort auf Zustände, Anfragen oder Vorrichtungsversagen zu bestimmen. Das kann dann durchgeführt werden, wenn sich vorübergehende loT-Vorrichtungen, wie der Fußgänger 216, der Fog-Vorrichtung 202 anschließen. Die Fähigkeit, Funktionalität und Bereitschaft einer loT-Vorrichtung mit einem Adhoc-System zusammenzuarbeiten oder zu kooperieren, wird von den lokalen Richtlinien und Steuerungen, wie vom Besitzer der Vorrichtung zugeordnet, bestimmt. Diese Informationen können in der CSI enthalten sein und können durch eine offene Standardschnittstelle erreichbar sein. Es gilt anzumerken, dass der Begriff offen nicht impliziert, dass auf die CSI ohne Berechtigungsnachweis zugegriffen werden kann. Die Bestimmung, wie die CSI erkannt, erreicht oder mit dieser kommuniziert werden kann, kann von den Sicherheitsrichtlinien, die u.a. von einem Systemmanager, von Peer-Vorrichtungen beim Verbinden oder vom Hersteller implementiert werden, festgelegt werden. Die Sicherheitsrichtlinien können ermöglichen, dass auf die CSI von vertrauenswürdigen Domänen, offeneren Domänen oder einem Hybrid aus beiden zugegriffen werden kann, wie vom Systemarchitekten bestimmt. Daher können Vertrauenswürdigkeit und Sicherheit Teil der Bildung der Fog-Vorrichtung 202 sein.
In Anwendungen kann eine Kombination von loT-Objekten, die einen imperativen Programmierstil nutzen, und Objekten, die einen deklarativen Programmierstil nutzen. Beispielsweise können Allzweck-loT-Vorrichtungen einen deklarativen Programmierstil operieren, um sich an verändernde Bedingungen anzupassen. Eingeschränktere loT-Vorrichtungen, wie Sensorvorrichtungen, haben mitunter nicht die Programmierleistung, um anpassungsfähigere Software zu umfassen.
Da der Fußgänger 216 sich eher langsamer fortbewegt als die Fahrzeuge 212 und 214, kann sich die Fog-Vorrichtung 202 umkonfigurieren, um sicherzustellen, dass der Fußgänger 216 ausreichend Zeit hat, um die Kreuzung zu überqueren. Das kann durch die Bildung einer temporären Gruppe der Fahrzeuge 212 und 214 und des Fußgängers 216 erreicht werden, um die Verkehrsampeln 204 zu steuern. Wenn eines oder beide der Fahrzeuge 212 oder 214 autonom sind, kann die temporäre Gruppe die Fahrzeuge dazu anweisen, vor den Verkehrsampeln 204 langsamer zu werden. Die temporäre Gruppe kann ein Microservice, z.B. genannt Fußgänger, herunterladen oder implementieren, um die Verkehrsgeschwindigkeiten an der Kreuzung zu steuern, während der Fußgänger vorhanden ist.
Wenn die vorübergehenden Vorrichtungen 212, 214 und 216 den Umkreis der Kreuzung verlassen, kann sich die Fog-Vorrichtung 202, die Fog-Vorrichtung 202 umkonfigurieren, um diese loT-Vorrichtungen aus dem Netzwerk zu entfernen. Beliebige Microservices, die temporär zur Steuerung der Kreuzung genutzt werden, wenn die vorübergehenden Vorrichtungen 212, 214 und 216 diese überqueren, können deaktiviert, zu anderen Vorrichtungen verschoben oder in einem Datenspeicher platziert werden. Wenn sich andere vorübergehende loT-Vorrichtungen der Kreuzung nähern, kann sich die Fog-Vorrichtung 202 umkonfigurieren, um jene Vorrichtungen zu umfassen, und kann nach Bedarf auf Microservices zugreifen.
Die Fog-Vorrichtung 202 kann die Verkehrsampeln 204 für eine Reihe von Kreuzungen, wie entlang einer Straße, zusammen mit allen vorübergehenden loT-Vorrichtungen entlang der Straße umfassen. Die Fog-Vorrichtung 202 kann sich dann in funktionelle Einheiten unterteilen, wie die Verkehrsampeln 204 und andere loT-Vorrichtungen in der Nähe einer einzelnen Kreuzung. Diese Art der Kombination kann die Bildung von größeren loT-Konstrukten, z.B. Gruppen von loT-Vorrichtungen, die eine bestimmte Funktion erfüllen, in der Fog-Vorrichtung 202 ermöglichen.
Wenn beispielsweise ein Einsatzfahrzeug zur Fog-Vorrichtung 202 hinzukommt, kann ein Einsatzkonstrukt oder eine virtuelle Vorrichtung erzeugt werden, die alle Verkehrsampeln für die Straße umfasst. Die loT-Vorrichtungen des Einsatzkonstrukts können auf Microservices zur Steuerung der Verkehrsampeln entlang der Straße zugreifen oder diese herunterladen. Das Einsatzkonstrukt kann eine Reihe von Microservices umfassen, die von einem Aufgabenbildrepositorium in der Fog-Vorrichtung 202 aktiviert oder in die Fog-Vorrichtung 202 vom Server 104 oder anderen Vorrichtungen in der Cloud 102 heruntergeladen werden. Darüber hinaus können die Aufgabenbilder von einem Einsatzfahrzeug, das sich der Fog-Vorrichtung 202 anschließt, heruntergeladen werden.
Das Einsatzkonstrukt kann die eingesetzten Arbeitslasten nutzen, um die Stelle und Fahrbahn für das Einsatzfahrzeug zu bestimmen. Die Arbeitslasten können dann die Verkehrsampeln 204 entlang der Straße dazu anweisen, für den entgegenkommenden Verkehr auf rot und für das Einsatzfahrzeug auf grün zu bleiben, und somit die Durchfahrt des Einsatzfahrzeuges zu beschleunigen.
Wie durch die Fog-Vorrichtung 202 veranschaulicht, ist die organische Weiterentwicklung von loT-Netzwerken entscheidend, um die Verwendbarkeit, Verfügbarkeit und Stabilität von loT-Implementierungen zu verbessern und zu maximieren. Die Verwendung von Anwendungen, die zwischen verschiedenen Rechnervorrichtungen verschoben werden, können die Adaptierbarkeit der Fog-Vorrichtung 202 erhöhen, z.B. indem eine einfachere Inkorporation neuer Funktionen bereitgestellt wird. Das wird genauer in Bezug auf 3 und 4 besprochen.
3(A) bis 3(E) sind schematische Diagramme eines Beispiels für ein Internet-der-Dinge- (loT-) System, das andere Vorrichtungen erkannt, Microservices herunterlädt und die Servicebereitstellung verwaltet, gemäß manchen Ausführungsformen. Manche Microservices sind unbeweglich, was bedeutet, dass sie auf einer einzigen Vorrichtung bleiben. Diese Microservices, die im Allgemeinen Einzweckfunktionen aufweisen können, können basierend auf den Anforderungen von der Service-Anfrage insgesamt komprimiert und entkomprimiert werden.
3(A) ist eine schematische Zeichnung eines Beispiels für eine Smart-Home-Umgebung 300, die Sensorknoten, Rechnerknoten und Aktuatorknoten umfasst. Diese Sensorknoten können Kameras 302 und 304, Mikrofon 306 und dergleichen umfassen. Die Rechnerknoten können ein Gateway 308, einen Personal Computer (PC) 310 und dergleichen umfassen. Die Aktuatorknoten können einen TV 312 und Alarm 314, ein Mobiltelefon 316 und dergleichen umfassen. Das Mobiltelefon 316 kann über einen Serviceanbieter, ein Radiosignal oder beides in Kommunikation mit dem Gateway 308 stehen. Das Radiosignal kann ein Wi-Fi®-Signal, ein Bluetooth®-Signal oder beides umfassen.
In diesem Beispiel kann ein Hausbesitzer entscheiden eine Poolüberwachungsanwendung zu installieren, um nicht autorisiertes Betreten um einen Pool 318 zu identifizieren. Die Poolüberwachungsanwendung kann Microservices umfassen, die von einem loT-Serviceanbieter durch loT-Vorrichtungen im Heimnetzwerk über DSF angefordert wurden. Die loT-Vorrichtungen können automatisch zahlreiche Microservices für die Poolüberwachungsanwendung bei zahlreichen Knoten im Haus einsetzen.
Beispielsweise kann ein Computervisions-Microservice, genannt Kleinkinddetektor 320, auf der Gartenkamera 302 installiert werden. Der Kleinkinddetektor 320 kann die Gegenwart von Erwachsenen und Kindern im Umkreis des Pools 318 identifizieren. Ein Anwendungs-Microservice 322 kann auf dem Gateway 308 installiert werden, um zu bestimmen, dass sich ein Kind im Garten befindet, aber kein Erwachsener anwesend ist. Ein Alarmauslöser-Microservice 324 kann auf dem Gateway 308 installiert werden, um einen Alarm zu aktivieren, beispielsweise um eine Warnmeldung 326 an das Mobiltelefon 316 zu senden, ein Auslösersignal 328 an den Alarm 314 zu senden oder beides.
Wie in 3(B) dargestellt kann eine Heimsicherheitsanwendung aktiviert werden. Szenenanalysealgorithmen, genannt Einbruchsdetektor 330, können eingesetzt werden, um die Kameraaufzeichnungen vom vorderen und hinteren Garten zu analysieren, um zu bestimmen, ob eine unautorisierte Person anwesend ist. Der Einbruchsdetektor 330 kann in der Vorgartenkamera 304 eingesetzt werden. Allerdings kann die Gartenkamera 302 mitunter nicht in der Lage sein, sowohl den Kleinkinddetektor 320 als auch den Einbruchsdetektor 330 aufzunehmen, ohne dass es zu einem bedeutenden Abfall der Servicemetrik kommt.
Die Unfähigkeit beide Microservices auf der Gartenkamera 302 bereitzustellen, während eine SLA (Vereinbarung auf Serviceebene) erhalten bleibt, kann von Analysefunktionen detektiert werden, die auf loT-Vorrichtungen im gesamten Netzwerk angewendet werden. Dementsprechend kann die Poolüberwachungsanwendung erneut eingesetzt werden. Ein Streamer-Microservice 332 kann vom loT-Serviceanbieter heruntergeladen und in der Gartenkamera 302 eingesetzt werden, und sowohl Videoanalyse-Microservices 320 als auch 330 können am Gateway 308 eingesetzt werden. Das Anwendungs-Microservice 334 für die Heimsicherheitsanwendung kann auf am Gateway 308 eingesetzt werden, in dem die Alarmauslöserlogik 324 aktiviert wird, um eine Warnmeldung 326 zu versenden, den Alarm 314 schlagen zu lassen oder beides, wenn beispielsweise eine unautorisierte Person detektiert wird oder wenn sich ein unbegleitetes Kind im Umkreis von Pool 318 aufhält. Obwohl der Einsatz die verfügbare Bandbreite des Heimnetzwerks verringert, wird ermöglicht, dass das gewünschte Ergebnis erzielt wird.
Wie in 3(C) dargestellt, kann ein Videostream 336 transcodiert und vom Gateway 308 zu einem TV 312 zum Ansehen geschickt werden. Die zusätzliche Last kann zu viel für den Gateway 308 sein, um seine Leistung bei gleichzeitiger Beibehaltung der SLA zu erbringen. Das kann von Analysefunktionen auf den loT-Vorrichtungen im Netzwerk detektiert werden, und die Videoanalyse-Microservices 320 und 330 können automatisch erneut auf PC 310 umgeschichtet werden.
Wenn das Videostreamen abgeschlossen ist, können die Videoanalyse-Microservices 320 und 330 auf den Gateway 308 umgeschichtet werden, um zu ermöglichen, dass der PC 310 für andere Zwecke genutzt wird oder herunterfährt. Wenn die Heimsicherheitsanwendung deaktiviert wird, können die Analysefunktionen auf den loT-Vorrichtungen bestimmen, dass der Kleinkinddetektor 320 auf die Gartenkamera 302 umgeschichtet wird und der Streamer 332 für zukünftige Verwendungen bewahrt oder verworfen wird. Dadurch werden die Metriken für das Netzwerk verbessert und alle Systeme enger in Richtung optimale Leistung bewegt.
4 ist ein schematisches Diagramm 400 der Veränderungen an Cloud-Datenzentren und Netzwerken, die gemacht werden können, um die hierin beschriebenen Verfahren zu berücksichtigen, gemäß manchen Ausführungsformen. In diesem Beispiel wird bei Implementierung der Bedarf nach Benutzerausführungsservices verringert, wodurch Infrastruktur- und Wartungskosten verringert werden. Services 402, die das betreffen kann, umfassen beispielsweise u.a. Endbenutzerfunktionen, Anwendungen, Anwendungsframeworks, Datenbanken, Systemverwaltung, logische Server und Speicher, Virtualisierung, des Betreiben der Systemwartung, physische Server und Speichernetzwerke und Datenzentrumseinrichtungen.
Beispielsweise kann eine hausinterne IT-Infrastruktur 404 vollständig vom Benutzer ausgeführt und gewartet werden. Das kann einem Unternehmen entsprechen, das sein eigenes Datenzentrum baut, Server kauft und diese wartet. Das Unternehmen konfiguriert den Server und führt die eigenen maßgeschneiderten Unternehmensanwendungen aus.
Es können jedoch niedrigere Kosten mit größerer Verlässlichkeit erzielt werden, wenn Services zu Serviceanbietern in der Cloud verlagert werden. Das kann auf einer Reihe hierarchischer Ebenen durchgeführt werden, beispielsweise kann ein Unternehmen beschließen, weniger physische Einrichtungen zu installieren, und dafür Infrastruktur als Service (laaS) 408 nutzen. In laaS 408 wird die Anzahl der vom Benutzer ausgeführten Prozesse 408A im Vergleich zum vom Serviceanbieter ausgeführten Prozesse 408B verringert. Beispielsweise kann ein Einzelhändler Speicherplatz in einem Cloud-Service mieten, um ein Projekt zu implementieren, bei dem Mitarbeiterkosten in der Cloud gespeichert werden.
Die Menge der Services, die vom Serviceprovider ausgeführt werden, können unter Verwendung von Plattform als Service (PaaS) 410 weiter verringert werden. Beispielsweise kann ein Benutzer in dem vom Benutzer ausgeführten Teil des Services 410A, eine benutzerdefinierte Anwendung schreiben, die Händlerprogrammierschnittstellen (APIs) nutzt, um auf gemeinsame Services zuzugreifen. In dem Teil des Serviceanbieters 410B entwickelt der Serviceanbieter Cloud-Plattformen, die es dem Benutzer ermöglichen, maßgeschneiderte Anwendungen unter Verwendung der APIs zu schreiben.
Ein größerer Nutzen wird bei der Verwendung von Software als Service (SaaS) oder Unternehmensprozesse als Service (BPaaS) 412 erzielt. Bei dieser Implementierung kann der benutzerausgeführte Teil 412A des Services lediglich Zugriff auf Daten bereitstellen, während sich der Serviceanbieter-ausgeführte Teil 412B des Systems um alle anderen Funktionen, wie z.B. externe Zugriffe, Wartung und dergleichen kümmert.
Bei den hierin beschriebenen Verfahren wird von Serviceanbietern gewartetes Cloud-Computing 414 genutzt, um einen Großteil der Funktionalität bereitzustellen. Der Benutzer stellt eine Serviceanfrage 414A, auf die vom Serviceanbieter reagiert wird.
Beispielsweise kann der Serviceanbieter vom Kunden angeforderten Services 414B gemäß einer Vertragsvereinbarung verwalten. Darüber hinaus kann der Serviceanbieter verhandelte Services 414C, erhalten, bei denen der Anbietern mit anderen Anbietern über die Lieferung der Services, die vom Kunden angefragt wurden, verhandelt. In den verhandelten Services 414C können Parameter bezüglich Datenzentrumsfunktionalität, Vereinbarungen auf Serviceebene (SLA), und Servicequalität (QoS) berücksichtigt werden. Andere vom Serviceanbieter verwaltete Services 414D können Gruppierungsportale umfassen, auf denen mehrere Serviceanbieter ihre Funktionalitäten bewerten. Services der Lieferkettenverwaltung/Infrastrukturserviceverwaltung (SCM/ISM) 414E können Serviceportale umfassen, auf denen mehrere Serviceanbieter ihre Funktionalitäten bewerben. Der Serviceanbieter kann beispielsweise eine autonome Infrastruktur 414F verwalten, bei der sich die Infrastruktur automatisch auf Basis der Serviceanforderungen aufbaut. Wenn Services, wie hausinterne IT-Services 404 zu den Cloud-Computing-Services 414 abwandern, nehmen die Anschaffungskosten ab und Skalierbarkeit und Anpassung nehmen zu.
Wie hierin beschrieben, können Services von einem Serviceprovider bereitgestellt werden, der Unternehmensservices und damit verbundene Arbeitsabläufe von der Infrastruktur abstrahiert und dadurch ermöglicht, dass diese Services auf verfügbaren und seriösen Infrastrukturkomponenten instanziiert werden. Beispielsweise kann ein servicedefiniertes Datenzentrum gebildet werden, dass sowohl Cloud-Computing-Komponenten als auch loT-Netzwerke umfasst. Die Bereitstellung der Services von den Serviceanbietern kann bei der Sicherstellung von Stabilität und fortlaufenden Operationen unterstützend wirken. Wie hierin beschrieben, kann das servicedefinierte Datenzentrum eine elastische Infrastruktur bereitstellen, deren Größe kundenspezifischen Bedürfnissen angepasst werden kann. Die Services können End-to-End-verwaltet werden, um die Servicelieferung zu steuern und die Servicestabilität zu unterstützen. Das servicedefinierte Datenzentrum kann sich auch an die Vereinbarungen auf Serviceebene (SLA) und Servicequalität- (QoS-) Erwartungen halten, die für Unternehmensservices und damit verbundene Arbeitsabläufe gelten.
5 ist ein schematisches Diagramm eines serviceorientierten Cloud-Datenzentrums 500 gemäß manchen Ausführungsformen. Das serviceorientierte Cloud-Datenzentrum 500 kann ein Reservoir von programmierbaren Servern 502, Netzwerken 504, und Speicherausstattung 506 bereitstellen, wodurch sowohl konvergierte als auch aufgegliederte Plattformarchitekturen, loT-Ressourcen und Fog-Systeme bereitstellen, die standardmäßige Bausteine in hoher Stückzahl bereitstellen, die für Cloud- und loT-Anwendungen optimiert sind, und Microservices bereitstellen. Solche Reservoirs können einzelne Rechnerknoten 508, Speicherknoten 510, Serverknoten 512 und Netzwerkknoten 514 umfassen.
Die Software, die das serviceorientierte Cloud-Datenzentrum 500 implementiert, kann eine Opensource-Cloud-Software 516, kommerzielle Cloud-Software 518 oder eine Kombination aus beidem umfassen. Das serviceorientierte Cloud-Datenzentrum 500 kann eine Reihe von Services und Analysefunktionen bereitstellen, einschließlich Servicequalität, Servicekapazitätsverwaltung, Orchestrierung und Arbeitslastverteilung. Die Servicekapazitätsverwaltung kann beispielsweise eine Servicedomänensteuerung und eine Arbeitslastdomänensteuerung umfassen.
Die Arbeitslastverteilung kann für eine diskrete Ressourcenreservierung, Schattenressourcenreservierung und Arbeitslastfingerabdrücke bereitgestellt werden. Diese Fingerabdrücke können als Arbeitslastobjekte angeführt werden, die die Ressourcenanforderungen für die Arbeitslast beschreiben, um diese zur Erfüllung mit den geeigneten Edge-, Fog- oder Datenzentrumsressourcen abzustimmen. Die von den Services und Analysefunktionen bereitgestellten Daten können einem Benutzer auf vielfältige Weise angezeigt werden. Beispielsweise kann eine Steuer- oder Konfigurationskonsole das Serviceergebnis und die Analyseergebnisse anzeigen. In weiteren Beispielen kann eine loT-Vorrichtung eine Anzeige und Eingabe, wie hierin beschrieben, umfassen und genutzt werden, um diese Daten anzuzeigen. Die Anzeigevorrichtung kann Benutzerinteraktionsoptionen umfassen, wenn es die Systemkonfiguration und Richtlinien erlauben. Die Servicequalitätsmessungen können Infrastrukturreputation und ehemalige Verwendungen, wie Reputationsanalysefunktionen bereitstellen, die zu Reputationsaggregation und dann Arbeitsablauf- und Servicelieferungs-QoS-Metriken führt.
Die Servicekapazitätsverwaltung kann die Entwicklung der Laufzeit und verfügbaren Cloud-Infrastrukturkapazität bereitstellen, einschließlich damit verbundener Services sowie Reservierungsverarbeitung. Das umfasst alle Datenzentrumselemente, von physischen Einrichtungen bis hin zu den Betriebssystemen, mit dem Ziel eine durchgängige Infrastruktur zu liefern. Die Servicekapazitätsverwaltung kann die Servicedomänensteuerung umfassen, die eine durchgängige Identifizierung, Anwendung und Konfiguration von Infrastrukturservices über das Netzwerk bereitstellt. Die Informationen der Servicekapazität können durch eine Standardschnittstelle auf dem DSF für die Verwaltungsdomäne verfügbar sein und auch für verbundene/zugeordnete Verwaltungsdomänen bereitgestellt werden. Die Services umfassen u.a. Elemente, wie Sicherheit, Entschädigung, Anspruch, Lizensierungsrichtlinien und Leitung, Planung und Verfügbarkeit. Die Arbeitslastdomänensteuerung kann eine einheitliche und koordinierte Arbeitslastpositionierung bereitstellen, beispielsweise indem Arbeitslasten einer Vorrichtung der niedrigsten Ebene am Rand eines Fogs oder einer Cloud zugeordnet werden, die in der Lage sind, die Kapazität zur Implementierung der Arbeitslast bereitzustellen.
Die Orchestrierung kann die Wahrnehmung von Arbeitsabläufen, Infrastrukturfunktionalität und Umgebungsservicebewertung auf Basis der Arbeitslastplatzierung bereitstellen. Darüber hinaus kann die Orchestrierung Service- und Arbeitslastdomänenkoordination bereitstellen, einschließlich einer Reihe von Protokollen, wie u.a. SOAP (Simple Object Access Protocol), RESTfuI (Representational State Transfer), S3 (Simple Storage Service von Amazon Web services), CDMI (Cloud Data Management Interface), HDFS (The Hadoop Distributed File System von Apache), GPFS (General Parallel File System von IBM, derzeit bekannt als IBM Spectrum Scale) und Lustre (ein Linux-Cluster-Rechnerprotokoll, das unter der allgemeinen öffentlichen GNU-Lizenz erhältlich ist).
Wie hierin verwendet, umfasst die Arbeitslastverteilung u.a. die Bestimmung, Identifizierung, Allokation, Reservierung und logische Ansammlung von Infrastrukturkomponenten. Das kann auf den Arbeitslastanforderungen, wie von der Arbeitslastvorlage definiert und der antizipierten Last, auf Basis von historischen und zeitbasierten Faktoren begründet werden. Eine diskrete Ressourcenreservierung kann die Allokation von physischen Ressourcen auf Basis der ursprünglichen Lastanforderungen umfassen. Diese Art der Reservierung kann alle Infrastrukturressourcen für die Arbeitslast nutzen. Wie hierin verwendet, ist die Schattenressourcenreservierung die Allokation von physischen Ressourcen auf Basis der Lastanforderungen insgesamt. Diese Art der Reservierung kann die Ressourcen identifizieren, ermöglicht aber, dass niedrigere Arbeitslasten auf Serviceebene ausgeführt werden, bis die ursprüngliche Arbeitslast die Ressourcen anfordert. Wie hierin verwendet, sind die Arbeitslastfingerabdrücke die Identifikationen der ursprünglichen Arbeitslastmodellierung, vergangener Arbeitslastinstanzen und erfolgreichen oder misslungenen Laufzeitereignissen.
Um die loT-spezifischen Anforderungen mit eindeutigen und komplexen Ressourcen- und Serviceinteraktionen zu unterstützen, wird hierin eine neue, leichtgewichtige Servicelieferstruktur, das DSF, beschrieben. Diese verbesserte Architektur kann sich grundsätzlich an mehrere der Basisressourcenservices im Framework richten, anstatt über einen Agent oder Middleware zu agieren. Bereitgestellte Services können u.a. Lokalisieren, Finden, Adressieren, Zurückverfolgen, Nachverfolgen, Identifizieren und Registrieren umfassen. Diese Services können wirksam werden, sobald die Ressourcen im Framework auftauchen. Der Manager oder Besitzer der Ressourcendomäne kann Verwaltungsregeln und Richtlinien nutzen, um eine ordentliche Ressourcenerkennung, -registrierung und -zertifizierung sicherzustellen. Dieser Mechanismus kann einen bestehenden Hub-Spoke oder zentralisierten Verwaltungsansatz vereinfachen und die Ressourcenverwaltungsfunktionen im Netzwerk platzieren.
Das Ressourcenverwaltungssystem kann ständig wachsam sein und Informationen über die Bewegung, Vektor und Richtung der Ressourcen weitergeben und diese Merkmale in den Vorrichtungen zugeordneten Telemetrie- und Metadaten beschreiben. Diese native loT-Service-Framework-Funktion kann u.a. für die Ressourcenverwaltung, Abrechnungs- und Verbrauchserfassung und Sicherheit genutzt werden. Dinge, die über dieses Framework verwaltet werden, müssen nicht erneut erkannt oder registriert werden, da die absoluten und relativen Orte ständig über die Ressourcenzuordnung zur Servicedomäne verfügbar sind und durch über die CSI verfügbare Datenerreichbarkeit angeführt/verstärkt werden.
Die gleiche Funktionalität kann auch auf verwandte Ressourcen angewendet werden, bei denen eine weniger intelligente Vorrichtung, wie ein Sensor, an eine verwaltbarere Ressource, wie ein loT-Gateway, angebunden wird. Das Framework kann Veränderungen der Aufbewahrung oder Einkapselung von Ressourcen wahrnehmen. Da die Dinge direkt erreichbar oder indirekt durch eine übergeordnete oder alternative verantwortliche Vorrichtung verwaltet werden können, kann dieser Strukturtyp über die Schnittstelle an das Service-Framework weitergeleitet und somit für externe Abfragemechanismen zugänglich gemacht werden.
Zusätzlich dazu kann das Framewerk Services wahrnehmen und die Servicelieferanforderungen mit der Funktionalität und Verfügbarkeit der Ressourcen und dem Zugriff für das Datenhochladen von den Datenanalysesystemen ausgeglichen werden. Falls sich die Netzwerktransporte verschlechtern, versagen oder sich zu einer Funktion mit höheren Kosten oder eine niedrigeren Bandbreite verändern, können die Servicerichtlinien-Überwachungsfunktionen alternative Analysefunktionen und Serviceliefermechanismen im Rahmen der Richtlinien oder Kosten des Nutzers bereitstellen. Bei dieser Funktion können die Richtlinien den Aufruf von Analyse- und Dashboard-Services am Rand auslösen, wodurch eine fortlaufende Serviceverfügbarkeit bei verringerter Treue oder Detailgenauigkeit sichergestellt wird. Sobald die Netzwerktransporte wieder eingerichtet sind, kann mit den regulären Datensammlungs-, Hochlade- und Analyseservices, beispielsweise unter regulären SLAs, fortgefahren werden. Wie hierin beschrieben, können die Daten einem Benutzer auf einer Steuerkonsole, einer loT-Vorrichtung oder über einen Proxy-Server, der beispielsweise keine zugelassenen Steuerfunktionen hat, angezeigt werden.
6 ist eine schematische Zeichnung eines Infrastruktur- und Orchestrierungssystems gemäß manchen Ausführungsformen. Das System umfasst eine Unternehmensanweisung 602, die Unternehmensregeln, Unternehmensziele und Unternehmensrichtlinien umfasst. Die Unternehmensziele können von den Unternehmensregeln in der Unternehmensrichtlinie gemessen werden. Die Unternehmensregel und Unternehmensrichtlinie leiten ein Unternehmensziel und - service in einer Firmenarchitektur 604.
In der Firmenarchitektur 604 können das Unternehmensziel und -service auf Unternehmensdomänen abgebildet werden, die sich sowohl innerhalb als auch außerhalb einer Organisation befinden. Die Unternehmensserviceanforderung identifiziert, dass die Vereinbarung auf Serviceebene (SLA) erfüllt wird, um die Art des Unternehmens zu unterstützen. Wie hierin verwendet, handelt es sich bei der SLA um einen Vertrag zwischen einem Serviceanbieter und einem Kunden, der auf messbare Weise spezifiziert, welche Services der Anbieter liefert und welche Strafen verhängt werden, wenn der Anbieter die aufgestellten Ziele nicht erreichen kann. Bei der SLA kann es sich um eine formelle Vereinbarung handeln, die Kostenverringerungen umfasst, wenn die aufgestellten Ziele nicht erreicht werden, oder um eine informelle Vereinbarung, wie zwischen einem Konsumenten und lokalen Vorrichtungen, die die lokalen Vorrichtungen anweisen, welche Änderungen vorgenommen werden müssen, wenn die SLA nicht erfüllt werden kann.
Die Unternehmensdomänen können die Schaffung einer Unternehmensinformationsarchitektur ermöglichen. Die Unternehmensinformationsarchitektur definiert die Interaktion zwischen den Serviceelementen und definiert den Arbeitsablauf. Somit kann die Unternehmensinformationsarchitektur die Entwicklung einer logischen Infrastrukturarchitektur einschließlich eines logischen Datenmodells ermöglichen.
Das logische Datenmodell beschreibt die SLA in Bezug auf Spezifikationen auf Serviceebene (SLS). Wie hierin verwendet, sind die SLSs technische Spezifikationen, die von der SLA abgeleitet werden. Eine SLS kann genutzt werden, um die Variablen zu definieren, die überwacht werden sollen, und führt zu Grenzwerten, die genutzt werden können, um die Servicedomäneninfrastruktur zu benachrichtigen und proaktiv zu verwalten.
Ein Betriebsdatenmodell kann vom logischen Datenmodell abgeleitet werden und ist ebenfalls Teil der logischen Infrastrukturarchitektur. Aus dem Betriebsdatenmodell kann ein technisches Datenmodell abgeleitet werden. Somit wird eine Unternehmensserviceanforderung in ein technisches Datenmodell, um alle Unternehmensdomänen zu identifizieren und damit verbundene Infrastrukturelemente, Verbindungen und technische Datenmodelle für die Anwendung zerlegt. Die logische Infrastrukturarchitektur, einschließlich des logischen Datenmodells, des Betriebsdatenmodells und des technischen Datenmodells können einem Cloud-Serviceliefermanager (CSDM) 606 zum Beispiel durch ein Firmenserviceportal bereitgestellt werden.
Der CSDM 606 stellt die Verwaltungsstruktur bereit, um die Unternehmens-SLA-Anforderungen und die Infrastrukturservicefunktionalitäten zu verbinden, verhandeln und orchestrieren. In manchen Beispielen kann der CSDM Wiederholungen nutzen, um die Ressourcen den Anforderungen anzupassen. Der Multiservice-Manager im CSDM 606 stellt die Orchestrierung und Verwaltung, Optimierung, Isolierung und das Teilen von Services bereit, die unter mehreren Mandanten laufen. Die Servicedomänensteuerung verwaltet die Logik für die preplow-Architektur und die Trennung für die Umgebungs- und Arbeitsablaufanforderungen von der Firmenarchitekturausgabe. Die Servicedomänensteuerung koordiniert mit dem Servicekapazitätsmanager und steuert lokale und Echtzeitaktualisierungen. Der Servicekapazitätsmanager hält die Kommunikation mit dem logischen Datenzentrumsmanager aufrecht, um die Datenzentrumsservicefunktionalität und -verfügbarkeit zu verstehen. Der Servicekapazitätsmanager kann auch die Richtlinien in Bezug auf Anspruch, Durchsetzung, Entschädigung und Laufzeit der Services melden und verwalten. Die Umgebungsdomänensteuerung und Arbeitslastdomänensteuerung halten die Kommunikation mit der Umgebungs- bzw. Arbeitslastinfrastruktursteuerung aufrecht, um die Datenzentrumsserviceallokation zu verstehen und zu koordinieren. Der CSDM 606 kann einem Infrastrukturverwaltungs- und Orchestrierungssystem 608 über ein Datenzentrum/Infrastruktur-Portal Informationen bereitstellen.
Das Infrastrukturverwaltungs- und Orchestrierungssystem 610 kann einen logischen Datenzentrumsmanager (LDCM) aufweisen, um eine Servicefunktionalitäts-, Laufzeit- und Verfügbarkeitsansicht der physischen Infrastruktur bereitzustellen. Der LDCM kann die Cloud-Planungs- und Bereitstellungsinfrastruktur mit Metriken zum besten Weg, nächsten Nachbar, verfügbarer Umgebung und verfügbarer Leistung bereitstellen. Der LDCM kann Infrastrukturtelemetrie und andere Einrichtungen, einschließlich Betriebssystembasierter Messungen, nutzen, um die Funktionalität des Datenzentrums für die Servicelieferung genau darzustellen. Der LDCM kann außerdem Daten von der CSI umfassen, um sicherstellen zu können, dass alle Ressourcen, Edge, Fog oder Datenzentrum von der LCDM-Struktur verwaltet werden. Das kann eine Risikobewertung und QoS-Aggregation und Auslieferung auf Infrastrukturebene umfassen. Der LDCM kann eine Echtzeitansicht des Datenzentrums bereitstellen, die dynamisch an die sich verändernden Bedingungen angepasst werden können.
Ein Ressourcen- und Kapazitätsmanager 612 kann die physischen Ressourcen des Datenzentrums umfassen. Die physischen Ressourcen können u.a. Software, wie Betriebssysteme, Bibliotheken und Add-ons von Drittanbietern umfassen. Hypervisors können umfasst sein, um virtuelle Maschinen zu steuern, das Hochfahren sicherzustellen und andere Funktionen auszuführen. Die Rechnerkomponenten können Rechnerknoten, Speicherknoten, Netzwerkknoten, getrennte Knoten und aufgegliederte Komponenten umfassen. Beispielsweise können die Rechnerkomponenten Server und andere Datenzentrumskomponente, loT-Vorrichtungen, die entweder in der Nähe oder entfernt vom Datenzentrum liegen, oder beides umfassen.
Die physischen Ressourcen können außerdem die Einrichtungen, wie z.B. u.a. Rahmen, Zeile, Ablagen, Schlitten, HVAC, Umgebung, Zugriff, Leistung und Ort umfassen. Der Ressourcen- und Kapazitätsmanager 612 kann Funktionen wie u.a. Anlagen- und Inventurerkennung, Anlagenverwendung, Einrichtungsverwaltung, Typologieverwaltung und zentrale Berichterstattung durchführen. Ereignisverwaltungsservices können umfasst sein, um das Überwachen einer Aufgabenarchitektur zu nutzen, einschließlich Funktionen wie Heartbeat-Services, Aufgabenbibliothek, Aufgabenskripte und andere.
7 ist ein Blockdiagramm, in dem Schichten eines Datenzentrumverbundsystems 700 gezeigt werden, das anderen Systemen, wie loT-Netzwerken, Mikroservices bereitstellen kann, gemäß manchen Ausführungsformen. Das Datenzentrumverbundsystem 700 kann eine Serviceorchestrierungsschicht 702 umfassen, die die Unternehmensserviceanfrage und die SLA/QoS-Parameter definiert. Die Serviceorchestrierungsschicht 702 kann die Serviceanfrage verwalten und sich an die SLA/QoS-Parameter laut den Vereinbarungen mit den Softwareanbietern halten. Die Serviceorchestrierungsschicht 702 kann beispielsweise Vorlage für die Services umfassen. Metriken für die Services können von den SLA/QoS-Parametern definiert werden. Gewährleistungsfunktionen können umfasst sein, um zu bestimmen, welche Maßnahmen ergriffen werden, wenn die Metriken nicht erfüllt werden. Sensing-Funktionen können mit anderen Schichten zum erhalten von Telemetriedaten arbeiten, ob zu bestimmen, ob die Metriken erfüllt werden.
Eine Arbeitslastorchestrierungsschicht 704 kann die angeforderte Anwendung oder das Service zerlegen und die Anwendungen, Arbeitsabläufe und wesentliche Leistungsindikatoren (KPIs) entgegen der SLA/QoS-Parameter und Servicekapazitätsmetriken definieren, um die Anfrage zu erfüllen. Die Arbeitslastorchestrierungsschicht 704 kann eine Software-definierte Infrastruktur bereitstellen, die beispielsweise u.a. virtuelle Rechnerressourcen, virtuelle Netzwerkressourcen, virtuelle Speicherressourcen und virtuelle Einrichtungen umfasst.
Eine Infrastrukturorchestrierungsschicht 706 kann die physische Infrastruktur steuern. Die Infrastrukturorchestrierungsschicht 706 kann Infrastrukturerfüllungselemente bereitstellen und einen optimalen Ort und Platzierung für die Arbeitslasten und Anwendungen bestimmen. Die Infrastrukturorchestrierungsschicht 706 kann die Infrastrukturfunktionalität und - Verfügbarkeit, beispielsweise einschließlich der physischen Infrastruktur, wie Rechnerressourcen, Netzwerkressourcen, Speicherressourcen und Datenplatzierung wahrnehmen. Außerdem kann die Infrastrukturorchestrierungsschicht 706 Infrastrukturverwaltungsfunktionalität umfassen, um die Verwendung der physischen Infrastruktur zu koordinieren.
Eine Einrichtungsverwaltungsschicht 708 kann spezifische Datenzentrumseinrichtungen verwalten, die von den anderen Schichten genutzt werden. Zusätzlich zu Einrichtungsverwaltungsfunktionen kann die Einrichtungsverwaltungsschicht Einrichtungsorte, Energiebedarf, HVAC und Sensing- oder Telemetriefunktionen verwalten.
8 ist ein schematisches Diagramm einer Lieferkette 800, um Serviceverwaltung, -orchestrierung und Verbund-Cloud-Services gemäß manchen Ausführungsformen bereitzustellen. Die Lieferkette 800 kann zwei Schichten umfassen. Eine Serviceverwaltungsschicht 802 kann die Funktionen umfassen, die zur Bereitstellung der Services genutzt werden. Eine Servicelieferungs- und Gewährleistungsschicht 804 kann mit anderen Systemen 806A bis 806C beispielsweise durch die logischen Datenzentrumsmodelle 808A bis 808C. Schnittstellen bilden. In der Serviceverwaltungsschicht 802 kann eine Serviceverwaltungsfunktion 810 die QoS für die bereitgestellten Services nachverfolgen, um zu bestimmen, ob diese die SLAs erfüllen.
Die Serviceverwaltungsschicht 802 kann die Lieferkettenservices 812, wie beispielsweise in Bezug auf 7 beschrieben, umfassen. Diese können u.a. ein Serviceinfrastrukturverwaltungssystem 814, ein Arbeitslastserviceverwaltungssystem 816 und ein Serviceorchestrierungsverwaltungssystem 818 umfassen. Eine logisches Serviceverwaltungs- und Servicelieferverhandlungsservice 820 können mit Systemen niedrigerer Ebene arbeiten, wie einer Serviceliefer-QoS-Funktion 822A bis 822C. Weitere Funktionen, wie die Ressourcenverbundservices 824A bis 824C und Servicedomänensteuerungen 826A bis 826C können mit der Serviceorchestrierung genutzt werden.
Die Serviceliefer- und Gewährleistungsschicht 804 kann Arbeitslastplanungs- und Bereitstellungsfunktionen 828A bis 828C umfassen, um die Platzierung oder Aktivierung (Entpacken und Laden) von Arbeitslasten wie Microservices zu bestimmen. Reputationsservices 830A bis 830C können die Operationen der Arbeitslasten auf bestimmten physischen Systemen oder Einrichtungen 832A bis 832C umfassen, um zu bestimmen, ob die Arbeitslasten auf eine den SLA-QoS-Metriken entsprechender Weise ausgeführt werden. Die Reputationsservices 830A bis 830C können außerdem Telemetrie der Metrikmessungen für die Serviceverwaltungsschicht 802 bereitstellen, beispielsweise zum Nachverfolgen durch die Serviceverwaltungsfunktion 810. Die Daten, die von der Telemetrie der Metrikmessungen bereitgestellt werden, können einem Benutzer auf unterschiedliche Weise, wie hierin beschrieben, angezeigt werden. Beispielsweise können die Metriken auf einer Verwaltungskonsole auf einer loT-Vorrichtung an einem entfernten Ort oder durch einen Proxy-Server angezeigt werden, der beispielsweise nicht über eine Steuerfunktionalität verfügt. Wie hierin angemerkt, kann die Anzeigevorrichtung Benutzerinteraktionsoptionen umfassen, falls diese von den ausgewählten Systemkonfigurationen und Richtlinien zugelassen werden.
9 ist ein Blockdiagramm eines Beispiels für einen Datenzentrumsverwaltungsstapel 900 zur Orchestrierung von Arbeitslasten gemäß manchen Ausführungsformen. Der Datenzentrumsverwaltungsstapel 900 kann Funktionen umfassen, um loT-Netzwerken sowie anderen Netzwerken über eine Cloud Microservices und andere Arbeitslasten bereitzustellen. Diese können eine Cloud-Servicelieferverwaltung (CSDM) 902 und Cloud-Servicearbeitslaststeuerung (CSWC) 904 umfassen. Cloud-Funktionen 906 können eine beliebige Anzahl von Funktionen umfassen, die in der Cloud abgeschlossen werden, wie Services und Arbeitslasten, die von den Netzwerkservern durchgeführt werden. Virtualisierungsfunktionen können Rechner-, Netzwerk- und Speicherfunktionen umfassen, wie beispielsweise Speicherservicevorlagen, Bildkataloge, das Bereitstellen von u.a. Benachrichtigungsfunktionen, Datenbankfunktionen und Ladefunktionen. Funktionen, die für die Bereitstellung der Services spezifisch sind, können die Anlagelokalisierungsservices 908, wie Inventurverwaltung, dynamische Anlagenlokalisierung, Servicekataloge und Anfrageerfüllung umfassen. Die Daten, die zur Bereitstellung der Funktionen genutzt werden, können auf Vorrichtungen angezeigt werden, die sich in der Nähe der Funktionsbenutzung befinden, beispielsweise loT-Vorrichtungen, die die Microservices anfordern oder zugeordnete Vorrichtungen, wie ein Verwaltungsserver, der sich in der Nähe der loT-Vorrichtungen befindet.
Die Cloud-Servicelieferverwaltungsfunktionen 902 können Sicherheitsservices 910, Anspruchs- und Regulierungsservices 912, Abrechnungs- und Ausgleichsservices 914 und Servicegewährleistungsservices 916 umfassen, wie das proaktive Abfragen von Infrastruktur, um u.a. eine Servicelieferung zu gewährleisten. Ein Fehlerbehebungs- und Aktualisierungsservice 918 kann sicherstellen, dass Microservices, die auf anderen Netzwerken, wie loT-Netzwerken, laufen, die neuesten Softwareversionen verwenden. QoS-Funktionen 920 können genutzt werden, um sicherzustellen, dass die SLA/QoS-Metriken erfüllt werden. Diese können Serviceebene- und Statusaggregationsservices 922, und Abrechnungs-, Verbrauchs- und Messaggregationsservices 924 umfassen.
10 ist ein schematisches Diagramm einer Orchestrierungsserviceverwaltungsstruktur 1000 gemäß manchen Ausführungsformen. Wie hierin beschrieben, können die Datenzentren 1002 über ein Orchestrierungssystem 1004 verfügen, um Microservices und andere Funktionen für andere Netzwerke und Systeme, wie u.a. andere Datenzentren und loT-Netzwerke bereitzustellen. Um diese Funktionen durchzuführen, kann ein Infrastrukturorchestrator 1006 mit den Datenzentren 1002 arbeiten, um Arbeitslasten an geeigneten Stellen zu platzieren. Der Infrastrukturorchestrator 1006 kann eine eingehende Serviceanfragenvorlage 1008 empfangen und aus den Telemetrieinformationen 1010 den geeigneten Platz bestimmen, um eine Arbeitslast dorthin zu senden. Die Telemetrieinformationen 1010 können eine Serviceansicht für den Infrastrukturaggregationspunkt umfassen, einschließlich Informationen wie Leistung, Verfügbarkeit und Servicefunktionalität der Datenzentren 1002. Die Datenzentren 1002 beschränken sich nicht auf große Cloud-Server, sondern können auch loT-Netzwerke oder lokalen Adhoc-Fog-Systeme, die auf loT-Vorrichtungen basieren, umfassen, wie beispielsweise in Bezug auf 11 beschrieben.
11 ist ein schematisches Diagramm eines Beispiels für eine Anwendung 1102, die zerlegt und in Containern 1104 verpackt wird, die dann den Systemen 1106 bereitgestellt werden, gemäß manchen Ausführungsformen. Wie hierin verwendet, können die Container 1104 Software-Wrapper sein, die ermöglichen, dass ein Codesegment unter verschiedenen Betriebssystemen, Hardware und dergleichen läuft. Bei diesem Ansatz wird die Anwendung 1102 in Komponenten oder Aufgaben 1108 zerlegt, die Aufgaben dann in Container 1104 verpackt, wodurch containerisierte Aufgaben 1110 entstehen und der Einsatz der containerisierten Aufgaben 1110 dann dynamisch auf physische oder virtuelle Vorrichtungen in den Systemen 1106 orchestriert. Wie hierin verwendet, können die Aufgaben 1108 als Microservices betrachtet werden, die einem Netzwerk über einen Serviceanbieter bereitgestellt werden. Die Container 1104 können Container 1104 umfassen, die für den Einsatz auf unterschiedlichen Hardwareplattformen und Betriebssystemen gedacht sind. Beispielsweise können die Container 1104 umfasst sein, um zu ermöglichen, dass die Aufgaben 1108 in virtuellen Maschinen (VMs), Floating Point Gate Arrays (FPGAs), Vorrichtungen mit spezialisierter Hardware, wie Sensoren, Aktuatoren und dergleichen und Systemen 1106, die u.a. die Security Guard Extensions (SGX) für sichere Operationen von Intel® nutzen, ausgeführt werden können.
Andere Arten von Containern 1104 können einen intelligenten Ding-Container/Stapel für Dinge der Klasse MCU/Quark umfassen, die über benachteiligte drahtlose Netzwerke (Mesh) laufen, wie Beleuchtung, Sensoranordnung, Thermostate, Kameraanordnungen und dergleichen. Diese Arbeitslasten können für die Vorrichtung spezifisch und nicht migriert sein.
Die Container 1104 können einen Maschinen-Container/Stapel für Maschinen umfassen, die leistungsstärkere Allzweckprozessoren, wie die Atomprozessoren von Intel, aufweisen, und die vielfältige Datenverarbeitungen über drahtgebundene oder drahtlose Netzwerke mit hoher Bandbreite durchführen können. Diese Maschinen können HVAC-Steuerungen, Zustandsüberwachungen, Autos, Züge und dergleichen umfassen.
Die Container 1104 können einen Betreiber-Container/Stapel für Server umfassen, der komplexere Funktionen ausführen kann. Die komplexeren Funktionen können beispielsweise Betriebsfunktionen, das Streamen von großen Daten, das Betreiben von Historian-Datenbanken, die Bereitstellung von operativen Analysefunktionen, die Implementierung von Steuer-Station/Raum-Funktionen, die Implementierung von Autonomie, kognitiver Datenverarbeitung und dergleichen umfassen.
Andere Container 1104 können einen lokalen Cloud-Container/Stapel umfassen. Dieser kann spezifische Funktionalitäten bereitstellen, beispielsweise um Maschinenparks zu betreiben. Darüber hinaus können diese eine Verbesserung gegenüber des Betreibercontainers darstellen und Daten für eine Ruhezustand/Bewegung-Filterung, Steuerfunktionen, Stufenzuweisung eines Systems, Failover-Antwort, App-Markt, Bereitstellung eines Maschinenparks und dergleichen hinzufügen.
Container 1104 kann einen mobilen UX-Container/Stapel umfassen, der beispielsweise dazu dient, auf Android und iOS zu laufen und eine mobile HMI-Konsole bereitzustellen. Dadurch können Fachleute auf dem Gebiet der Erfindung und Betreiber mobile Vorrichtungen nutzen, um über eine Konsole auf die Sensoren oder Maschinen zuzugreifen, Fernkonfigurationen, Einrichtung, Prozessüberwachung und dergleichen vorzunehmen.
Die Benutzung von Container 1104 ermöglicht, dass Aufgaben 1108 in andere Container 1104 umgepackt werden können, um in anderen Systemen 1106 eingesetzt zu werden, ohne dass der Code der Aufgaben 1108 umgeschrieben werden muss. Somit können containerisierte Aufgaben 1110 eingesetzt und dynamisch über heterogene Netzwerke von Systemen 1106 umgeschichtet werden. Die Orchestrierung des Einsatzes kann loT-Vorrichtungen 1112, Edge-Rechnervorrichtungen 1114, wie Cloud-Serviceanbieter (CSP) und Datenzentren, Gateways and Fog-Vorrichtungen 1116 oder eine Cloud-Infrastruktur umfassen. Wenn sich die System und Last verändert, können die containerisierten Aufgaben 1110 automatisch zwischen den verschiedenen Systemen 1106 verschoben werden, wie von den Pfeilen 1118 angezeigt. Die Zielsysteme 1106 können anfordern, dass containerisierte Aufgaben 1110 von einem Orchestrierungssystem bereitgestellt werden oder dass das Orchestrierungssystem nach Bedarf neue Komponenten baut.
12 ist ein schematisches Diagramm, das ein Bereitstellungssystem 1200 einschließlich einer Einsatzebene 1202 und Ausführungsebene 1204 gemäß manchen Ausführungsformen zeigt. Die Einsatzebene 1202 kann die ursprünglichen Funktionen 1206 zur Bereitstellung von Microservices wie das Definieren von Unternehmensanforderungen, Codieren oder Erhalten der ursprünglichen Microservices und den Einsatz der physischen Infrastruktur umfassen. Die Einsatzebene 1202 umfasst außerdem eine Reihe von automatisierten Funktionen, wie Mechanismen zum Eingliedern 1208 neuer Vorrichtungen in die Ausführungsebene 1204. Diese Vorrichtungen werden zu der Vorrichtung/Funktionalität-Abbildung 1210 hinzugefügt, die zur Orchestrierung des Einsatzes von Anwendungen und Funktionen von einer Orchestrierungsvorrichtung 1212 genutzt wird.
Jede eingegliederte Vorrichtung in der Ausführungsebene umfasst eine Steuerungsfunktionalität 1214, die den Einsatz von Softwarekomponenten verwaltet und verfügbare Ressourcen misst, wie CPU und Speichernutzung, Netzwerkbandbreite, Sicherheitsstatus und dergleichen. Die von den Vorrichtungen gemessene Ressourcennutzung kann an Vorrichtung/Funktionalität-Abbildung 1210 über ein Überwachung/Telemetrie-Instrument 1216 gesendet werden. Die Komponenten können von einer Baufabrik 1218 in Container verpackt werden. Die containerisierten Komponenten können zur späteren Verwendung in einem Aufgabenbildrepositorium 1220 gespeichert werden. In manchen Beispielen werden containerisierte Komponenten gelöscht, wenn sie nicht verwendet werden, und bei Bedarf von einem Serviceanbieter über DSF wiederhergestellt. Eine Aufgabeneinsatzabbildung 1222 kann genutzt werden, um nachzuverfolgen, wo die einzelnen containerisierten Komponenten einer Anwendung eingesetzt werden sollen.
Wie hierin beschrieben, kann eine Anwendung zur Implementierung eines Arbeitsablaufs erzeugt werden. Der Arbeitsablauf kann aus vernetzten funktionellen Blöcken bestehen, die aus anderen funktionellen Blöcken und Aufgaben bestehen können. Das Konzept besteht darin, ein Serviceorchestrierungssystem zu definieren und zu entwerfen, das die relevanten Ressourcen, ihre Funktionalitäten, Fähigkeiten, Allokationen, Berechtigungen und Zulassungen, die an einem Service beteiligt sind, wahrnimmt.
Das Ziel liegt darin, die Technologie, Schnittstellen und Funktionalitäten zu integrieren und ein Service mit einer Vereinbarung auf Serviceebene für einen Konsumenten und/oder Serviceurheber zu verwalten. Hierin beschriebene Systeme können das Zurückverfolgen, Nachverfolgen und Verwalten eines Services durch alle Elemente und Ressourcen, die das Service liefern, während des Lebenszyklus der Sitzung zu ermöglichen. Darüber hinaus können die Systeme die Wiederherstellung und Orchestrierung von Services ermöglichen, um sicherzustellen, dass die SLA auf Konsumentenebene erhalten wird und der Wiederherstellungsprozess transparent ist. Die Systeme können außerdem die Verwaltung der lokalen Ziele auf Serviceebene (SLOs) für Elemente und Ressourcen, wie in der CSI enthalten, umfassen, um sicherzustellen, dass der Orchestrator einen ordentlichen Wiederherstellungsprozess einsetzt.
Wenn beispielsweise eine Sicherheitsaufgabe in einem loT-netzwerk läuft, um Videoaufzeichnungen eines Orts bereitzustellen, und eine Verschlechterung der Netzwerkkommunikation eintritt, kann die Sicherheitsaufgabe automatisch versuchen, die Videoaufzeichnungen über andere Netzwerkverbindungen erneut zu routen. Bei diesem Beispiel können die Videoaufzeichnungen normalerweise durch ein erstes drahtloses Gateway, dann durch ein drahtgebundenes Netzwerk an eine Überwachungsstation gesendet werden. Wenn die drahtgebundene Netzwerkverbindung zu dem ersten drahtlosen Gateway jedoch unterbrochen wird, kann das erste drahtlose Gateway versuchen, die Kommunikation wiederherzustellen, indem es die Videoaufzeichnungen durch ein zweites drahtloses Gateway zu senden. Wenn die vollständige Wiederherstellung der Kommunikation nicht möglich ist, kann die Sicherheitsaufgabe einen Benutzer informieren, dass die verringerte Bandbreite eine vollständige Videokommunikation unmöglich macht, und bestimmen, obe der Benutzer mit unterbrochenen Standbildern fortfahren möchte. Da es sich bei der SLA um einen Bereich handelt, können alternativ dazu andere Wiederherstellungsverfahren die Beschleunigung von Services zwischen der Nord/Süd-Seite der nicht funktionierende Ressource oder eine Anfrage, die SLA zurücksetzen, falls eine Wiederherstellung nicht möglich ist, aber das Service mit einer gewissen Verschlechterung fortgeführt werden kann, umfassen.
Die beschriebenen Verfahren ermöglichen die Funktionalität für koordinierte Aktivitäten und außerdem die Fähigkeit, die Servicequalität zu messen, verwalten und sicherzustellen. Dadurch kann ermöglicht werden, dass die bereitgestellten Services den vertraglichen Vereinbarungen auf Serviceebene entsprechen. Darüber hinaus können Services, die von Verlässlichkeit abhängen, wie medizinische Services, Versicherungsservices, finanzielle Services und dergleichen, in der Lage sein, loT-Netzwerke für weitere Funktionalitäten zu implementieren.
13 ist ein schematisches Diagramm 1300 eines Datenzentrumsverbunds zur Orchestrierung und Verwaltung von Zusammenhängen in Vereinbarungen auf Serviceebene gemäß manchen Ausführungsformen. Im schematischen Diagramm 1300 stellt ein Kunde 1302 eine Serviceanfrage und definiert die SLA/QoS-Parameter bei Block 1304. Das kann unter einer Gesamtvereinbarung mit dem Serviceanbieter oder auf einer Service-zu-Service-Basis durchgeführt werden. Falls die Serviceanfrage oder die SLA/QoS-Parameter nicht wie in Block 1306 erfüllt werden können, kann der Prozessfluss zu Block 1304 für eine Neuverhandlung der Vereinbarung zurückkehren. Andererseits kann die Kundenanfrage zu einem Verbunddatenzentrumsservice, wie bei Block 1308 angezeigt, weitergeschickt werden, um zu bestimmen, ob Services, die die SLA/QoS erfüllen können, verfügbar sind.
Falls die Verhandlung erfolgreich ist, wie bei Block 1310 bestimmt, werden die Unternehmensserviceanfrage und die SLA/QoS-Parameter bei Block 1312, mit Eingaben vom Unternehmensservice 1314 definiert. Wenn die Unternehmensserviceanfrage oder die SLA/QoS-Parameter, wie bei Block 1315 angezeigt, nicht definiert werden können, kann die Anfrage zu einem Verbunddatenzentrumservice bei Block 1308 gesendet werden.
Wenn die Unternehmensserviceanfrage und die SLA/QoS-Parameter, wie bei Block 1316 angezeigt, definiert werden können, wird bei Block 1318 eine Arbeitsablaufserviceanalyse durchgeführt, um zu bestimmen, wo die Arbeitsabläufe platziert werden sollen. Die zusammengesetzten Arbeitsabläufe 1320 und die Analyseergebnisse können bei Block 1322 genutzt werden, um die Anwendungen, Arbeitsabläufe und KPls zu zerlegen und zu definieren. Das kann entgegen SLA/QoS-Parameter und Servicekapazitätsmetriken für die Knoten durchgeführt werden, die in der Arbeitsablaufserviceanalyse identifiziert wurden. Wenn bei Block 1324 bestimmt wird, dass die Zerlegung und Definition nicht erfolgreich war, kann der Prozessfluss zu Block 1318 zurückkehren, um die Arbeitsablaufserviceanalyse zu wiederholen. Wenn der Zerlegungs- und Definitionsvorgang bei Block 1322 erfolgreich war, wie durch Block 1326 angezeigt, kann an Block 1328 eine Arbeitsablauf- und Anwendungspassanalyse durchgeführt werden, um die Orte, an denen der Arbeitsablauf platziert werden soll, zu definieren.
Der Arbeitsablauf wird dann in ein Infrastrukturorchestrierungssystem 1330 eingespeist, um die Arbeitsabläufe und Microservices an den letztendlichen Orten einzusetzen. Das kann Parameter 1332 umfassen wie, z.B. ob die Arbeitslast singulär, geteilt, zustandslos oder zustandsorientiert ist. Bei Block 1334 werden die Arbeitsablaufpassanalyse von Block 1328 und die Parameter 1332 genutzt, um die Orte und Platzierungen der Arbeitslasten und Anwendungen zu zerlegen und zu bestimmen. Das kann mittels Anwendungscharakterisierung und den am besten passenden Parametern erfolgen. Falls die Platzierung, wie bei Block 1336 nicht erfolgreich ist, kann der Prozessfluss zu Block 1328 zurückkehren um die Passanalyse zu wiederholen.
Wenn die Arbeitslastplatzierung, wie bei Block 1338 bestimmt, erfolgreich ist, können bei Block 1340 eine Datenzentrumservice- und Kapazitätsanalyse durchgeführt werden, um Metriken für die Operationen zu erhalten, wenn die Arbeitslast durchgeführt wird. Die Datenzentrumservice- und Kapazitätsanalyse kann auf eine Datenzentrum-Servicekapazitätsansicht zugreifen, wie in Block 1342 gezeigt. Die Datenzentrum-Servicekapazitätsansicht kann von Funktionalitätsanalyseblöcken, einschließlich einer Umweltfunktionalität wie bei Block 1344 gezeigt und einer Arbeitsfunktionalität wie bei Block 1346 gezeigt, bereitgestellt werden. Die Funktionalitätsblöcke 1344 und 1346 können Eigenschaften wie u.a. Regelbefolgung, Entschädigung, Erfüllung (wie SLA/QoS-Metriken), Sicherheitsrichtlinien und Verfügbarkeit bestimmen. Diese Analysen können auf Metriken für virtuelle Systeme 1348 und physische Systeme 1350 basiert sein. Die Datenzentrum-Servicekapazitätsansicht kann auch physisch auf Verwaltungskonsolen, einer loT-Anzeige oder einer beliebigen anderen der hierin beschriebenen Anzeigeausführungen angesehen werden.
Eine Analyse der Einrichtung 1352 kann bestätigen, dass die Infrastrukturebene die angebotene Vertrags- und Anspruchsebene ausführt, wie bei Block 1354 angezeigt. Die Informationen können für ein Datenzentrumsanalyse, wie bei Block 1356 angezeigt, genutzt werden, die die Kapazität, Reputation, Verfall und dergleichen des Datenzentrums nachverfolgen kann. Wie hierin angemerkt, kann der Begriff Datenzentrum Cloud-basierte System, wie Server und andere Vorrichtungen in der Cloud, sowie Vorrichtungen, die sich am Rand der Cloud befinden, umfassen, wie z.B. u.a. Fog-Vorrichtungen, loT-Netzwerke und einzelne loT-Vorrichtungen, wie Smartphones, Tablets und dergleichen.
14 ist ein schematisches Diagramm eines Beispiels für einen Prozess 1400 für einen Cloud-Servicelieferverwaltungsprozess, gemäß manchen Ausführungsformen. Der Prozess 1400 kann einen Servicekatalog 1402 umfassen, der Vorrichtungen und Systemen Microservices bereitstellen kann. Der Servicekatalog 1402 kann Informationen über unterschiedliche verfügbare Microservices und einen Uniform Resource Locator (URL) bereitstellen, um auf die Microservices zuzugreifen. Der Servicekatalog 1402 kann Kern-Microservices, die zu den meisten Edge-Netzwerkknoten gesendet werden, und Komplementär-Microservices umfassen, die auf Anfrage geroutet werden. Darüber hinaus kann der Servicekatalog 1402 Microservices bereitstellt, wenn eine Serviceanfrage 1404 empfangen wird. Die Microservices können in einer Sequenz bereitgestellt werden, beispielsweise kann ein Gesichtsdetektions-Microservice, gefolgt von einem Gesichtserkennungs-Microservice, und dann einem Microservice zur Öffnung eines Garagentors, wenn ein Fahrzeug eintrifft, bereitgestellt werden. Dadurch wird die Bereitstellung von Microservices ermöglicht, damit loT-Services für neu installierte Vorrichtungen mit minimaler Konfiguration freigegeben werden können.
Die angeforderten Services können an eine Serviceverwaltungsfunktion 1406 geschickt werden. Die Serviceverwaltungsfunktion 1406 erfasst, aggregiert und versteht Funktionalität, Verfügbarkeit und Status der Infrastruktur. Darüber hinaus stellt die Serviceverwaltungsfunktion 1406 eine Abbildung der Infrastrukturfunktionalität bereit, einschließlich beispielsweise u.a. Sicherheit, Anspruch, Leistung, Durchsatz und Regulationsmetriken.
Wenn die Serviceverwaltungsfunktion 1406 bestimmt, dass die Infrastrukturberichte okay sind und die Funktionalitätsberichte okay sind, kann die Serviceanfrage 1404 zu einer Arbeitslastverwaltungsfunktion 1408 gesendet werden, die die Serviceanfrage zerlegen und die Arbeitslastanforderungen verstehen kann. Die Arbeitslastverwaltungsfunktion 1408 kann die Arbeitslastlieferung auf Infrastrukturelementen, wie loT-Vorrichtungen, Fog-Vorrichtungen, Datenzentren und dergleichen abbilden. Die Arbeitslastverwaltungsfunktion 1408 kann auch Arbeitslastmodellieragenten, falls verfügbar, ausführen, um den Servicedurchlauf auf der Infrastruktur, z.B. durch das Sammeln von Servicequalitäts- (QoS-) und Servicegewährleistungsdaten, zu modellieren. Wenn die Arbeitslastverwaltungsfunktion 1408 bestimmt, dass die Infrastrukturelemente unzureichend sind oder andere Gründe identifiziert, weshalb die Abbildung nicht abgeschlossen werden kann, kehrt sie zum Servicekatalog 1402 zurück, um zu bestimmen, ob andere Services genutzt werden können, um die Serviceanfrage 1404 abzuschließen. Beispielsweise kann die Serviceanfrage 1404 nicht verweigert oder für eine neue SLA neuverhandelt werden, wenn die Infrastruktur einen Mangel an Verfügbarkeit, Stabilität oder Belastbarkeit in den physischen Einheiten meldet. Weitere Gründe, um zum Servicekatalog zurückzukehren, umfassen eine Unfähigkeit die SLA-Parameter, die Serviceanfrageparameter oder die Arbeitslastanforderungen zu erfüllen.
Wenn die Arbeitslastverwaltungsfunktion 1408 bestimmt, dass die QoS- und Servicegewährleistungsberichte ausreichend sind, können Arbeitslasten von der Arbeitslastverwaltungsfunktion 1408 für eine Orchestrierungsverwaltungsfunktion 1410 bereitgestellt werden. Die Orchestrierungsverwaltungsfunktion 1410 kann Arbeitslasten, wie beispielsweise das Bereitstellen von Bildern, Herstellen von Verbindungen, Registrieren von Anspruch und Verwendung, Melden an Regulationsfunktionen und dergleichen, Infrastrukturelementen zuordnen. Die Infrastruktur-SLA kann aggregiert werden, um QoS-Metriken bereitzustellen. Den QoS-Überwachungsservices können weitere Servicegewährleistungsrückmeldungen bereitgestellt werden. Das kann gemeinsam mit QoS- und Investitionsrenditen- (ROI-) Metriken 1412 in der Cloud durchgeführt werden, die SLA-Metriken und qualitative und quantitative Lösungsvorteile umfassen. Die Orchestrierungsverwaltungsfunktion 1408 kann die Infrastrukturelemente erneut zuordnen, wenn eine Benachrichtigung über u.a. einen Fehlschlag einer Infrastruktur, einen SLA-Ausfall, Unzulänglichkeit auf Infrastruktursteuerebene oder Serviceveränderung empfangen wird.
Die Orchestrierungsverwaltungsfunktion 1410 stellt der Arbeitslaststeuerfunktion 1412 Informationen bereit. Die Arbeitslaststeuerfunktion 1410 sammelt und wartet Datenstatusinformationen über alle aktiven Arbeitslasten, die Nutzungsstatistiken über Knoten, wie Cloud-Datenzentren und andere Vorrichtungen, wie u.a. Fog-Vorrichtungen und loT-Vorrichtungen bereitstellen. Außerdem sammelt die Arbeitslaststeuerfunktion 1412 Nutzungs- und Kapazitätsinformationen für Arbeitslasten, die auf Knoten laufen. Die Arbeitslaststeuerfunktion 1402 sammelt und wartet außerdem Dateninfrastruktur-SLA-Metriken und u.a. Informationen über Fehlschläge, Diagnostik und Servicestatus. Wie hierin angemerkt, können die Daten und Nutzungsstatistiken auf einer Verwaltungskonsole und einer loT-Anzeige oder durch einen Proxy-Server beispielsweise ohne Steuerfunktionen angezeigt werden. Die Anzeige kann Benutzerinteraktionsoptionen umfassen, falls diese von der ausgewählten Systemkonfiguration und Richtlinie zugelassen werden.
Die Daten für die Arbeitslaststeuerfunktion 1412 können von einer Reihe unterschiedlicher Quellen gesammelt werden. Beispielsweise kann eine globale Richtlinienverwaltungsfunktion 1414 Richtlinien bezüglich u.a. Konfiguration, Bare-Metal-Bereitstellung, Überwachung, Ereignissen und Alarmmeldung bereitstellen. Weitere Richtlinien können Sicherheitsfragen, wie u.a. Authentifizierung, Autorisierung und Überprüfung betreffen. Die globale Richtlinienverwaltungsfunktion 1414 kann auf Richtlinien basierte Handlungen analysieren und melden.
Eine globale Ressourcenverwaltungsfunktion 1416 kann Ressourcen, wie u.a. beispielsweise Hardwareverwaltung, Firmware-Aktualisierungen, Lüfterverwaltung und Ortswahrnehmung melden und steuern. Das kann die Lokalisierung von Anlagen, wie z.B. loT-Vorrichtungen, Fog-Vorrichtungen und Datenzentren umfassen, die genutzt werden können, um Vorrichtungen zumindest teilweise basierend auf dem Ort der Vorrichtungen, der Nähe der Vorrichtungen, der Bandbreite zwischen Vorrichtungen, Kommunikationslatenzen und dergleichen zu verbünden.
Eine Knotenserviceverwaltungsfunktion 1418 kann vorrichtungsspezifische Funktionen bereitstellen, wie z.B. Wahrnehmung der thermischen Leistung, Wahrnehmung des Serverzustands, Datenerfassung bei erstem Fehlschlag, Laufzeitfehlerdetektion, Diagnostik und dergleichen. Darüber hinaus kann die Knotenserviceverwaltungsfunktion 1418 eine Fehlschlagvorhersage, dunkle Prozessor- und Arbeitsspeicheraktivierung, Funktionalitätsinventur und - konfiguration und dergleichen bereitstellen. Die Knotenserviceverwaltungsfunktion 1418 kann Leistungsstatistiken, beispielsweise basierend auf der Verwendung eines Systems oder einer virtuellen Maschine, sammeln. Die Knotenserviceverwaltungsfunktion 1418 kann sich außerdem um Systemsicherheitsfragen für die einzelnen Vorrichtungen kümmern, wie z.B. Hochfahrzeit und Laufzeitintegrität von Code.
Einrichtungen 1420 können der Arbeitslaststeuerung 1412 Metriken melden und Befehle von dieser empfangen. Die Daten von den Einrichtungen 1420 können Sensordaten über Prozessdateneinheiten, universelle Leistungsversorgungen, Kühlsysteme, Generatoren und Server umfassen. Darüber hinaus können die Einrichtungen 1420 eine aktive Datensammlung wie Informationssammlung von aktiven Sammelprotokollen, wie z.B. u.a. BACnet, Mod Bus und SNMP umfassen. Die Messungen können fortlaufend vorgenommen werden, wobei Echtzeitdaten integrierte IT-Datenpunkte aufweisen, um tägliche Zyklusschwankungen, Ereignis-basierte Analysen und dergleichen zu messen. Analysefunktionen können für eine effiziente Analyse integriert sein, beispielsweise die genaue Überwachung einer aktiven Umleitung der Datenzentrumseinrichtungen und -funktionalitäten für effizienteste Operationen. Bei loT-Netzwerken können die Einrichtungen 1420 Metriken für Elemente wie Reserveleistungsniveau, Speichernutzung, Kommunikationsbandbreite und dergleichen umfassen. Wie hierin angemerkt, können die Einrichtungsparameter auf einer Steuerkonsole, einer loT-Anzeige oder durch einen Proxy-Server, beispielsweise ohne Steuerfunktionen, angezeigt werden. Die Anzeige kann Benutzerinteraktionsoptionen umfassen, falls diese von der ausgewählten Systemkonfiguration und Richtlinie zugelassen werden.
Wenn die Arbeitslaststeuerfunktion 1412 bestimmt, dass es zu einer Änderung des Status oder der Struktur der Infrastruktur gekommen ist, kann sie die Steuerung zurück an die Serviceverwaltungsfunktion 1406 übergeben, um die Konfiguration zu wiederholen. Ähnlich dazu kann, wenn die Arbeitslaststeuerfunktion 1412 bestimmt, dass es zu einer Änderung der Arbeitslast oder der Arbeitslastanforderungen gekommen ist, die Steuerung zurück Orchestrierungsverwaltungsfunktion 1410 übergeben werden, um Elemente neu zuzuordnen.
15 ist ein schematisches Diagramm eines vereinfachten Beispiels für einen Orchestrierungsprozess 1500 gemäß manchen Ausführungsformen. Gleich nummerierte Elemente sind wie in Bezug auf 11 und 12 beschrieben. Dieses Beispiel, das Knoten in einem loT-Netzwerk nutzt, ist nur ein Beispiel dafür, wie die hierin beschriebenen Methoden genutzt werden können. Während der Anwendung können die Module in Clustern eingesetzt werden, wobei jeder eine kohärente Menge von physischen Vorrichtungen verwaltet. In weiteren Beispielen können Knoten eine beliebige Anzahl von Vorrichtungen umfassen, wie beispielsweise u.a. loT-Vorrichtungen, Smartphones, Computer, Tablets, Fog-Vorrichtungen, virtuelle Maschinen und Datenzentren.
Wenn neue loT-Vorrichtungen in das loT-System eingeführt werden, kann ein Vorrichtungseingliederungsinstrument 1208 kann die loT-Vorrichtungen und ihre Funktionalitäten identifizieren und der Vorrichtung/Funktionalität-Abbildung 1210 diese Informationen bereitstellen. Das Eingliederungsinstrument 1208 kann ein inhärenter Teil jeder loT-Vorrichtung, z.B. in einer CSI umfasst, sein. Eine physische Vorrichtungshierarchie 1502 kann erzeugt werden.
Zur Laufzeit kann eine Orchestrierungsvorrichtung 1212 genutzt werden, um Orte für Arbeitslasten zu bestimmen und die Microservices einzusetzen, aus denen einen Anwendung 1504 besteht. Jede Vorrichtung in der Konstellation von eingegliederten Vorrichtungen kann eine Steuerung 1214 umfassen, die den dem Überwachung/Telemetrie-Instrument 1216 aktuellen Vorrichtungszustand und Metriken, wie CPU-Nutzung, Netzwerkverbindung und dergleichen, zur Aufnahme in die Vorrichtung/Funktionalität-Abbildung 1210 meldet.
Die Vorrichtungsfunktionalität einschließlich einer Vorrichtungsabbildung und Metriken werden der Orchestrierungsvorrichtung 1212 von der Vorrichtung/Funktionalität-Abbildung 1210 bereitgestellt. Die Orchestrierungsvorrichtung 1212 erhält außerdem die Anwendungsstruktur und Servicequalitätsanforderungen für die Anwendung 1504. Wenn der Einsatz der Anwendung 1504 angefordert wird, kann die Orchestrierungsvorrichtung 1212 die Anwendungsdefinition, einschließlich Ressourcen und SLA-Anforderungen, und die Vorrichtung/Funktionalität-Abbildung 1210 nutzen, um eine Aufgabeneinsatzabbildung 1222. zu erzeugen. Die Aufgabeneinsatzabbildung 1222 umfasst das Abbilden von containerisierten Aufgaben 1110 auf einzelne Knoten, sowie die Spezifizierung der Zwischenverbindungen zwischen diesen Aufgaben.
Die Steuerung 1214 auf jedem Knoten kann ein geeignetes Microservice vom Microservice-Repositorium 1220 anfordern. Wenn das Microservice nicht verfügbar ist, beispielsweise noch nicht gebaut wurde, kann ein Aufgabenbild oder containerisiertes Microservice in Echtzeit von einer Baufabrik 1218 unter Verwendung der Servicecontainer 1104 gebaut werden.
Sobald das Aufgabenbild eingesetzt und gestartet wird, verbindet die Steuerung 1214 die Ein- und Ausgaben der containerisierten Microservices 1110 mit anderen containerisierten Microservices 1110 gemäß der Aufgabeneinsatzabbildung 1222 und die Anwendung 1504 startet.
Das Vorrichtungsüberwachungssystem 1216 kann damit fortfahren, die Telemetriedaten von der Steuerung 1214 zu überwachen und die Daten in die the Vorrichtung/Funktionalität-Abbildung 1210 einzuspeisen. Die Orchestrierungsvorrichtung 1212 kann bestimmen, dass SLA-Metriken von den aktuellen Vorrichtungen, wie von dem SLO gemessen, nicht erfüllt werden. Wenn dem so ist, kann die Orchestrierungsvorrichtung 1212 die Aufgabeneinsatzabbildung 1222 erneuern, um Aufgaben auf andere Vorrichtungen umzuschichten, um die Leistung zu verbessern und zu sehen, ob die SLA-Metriken erfüllt werden können. Wenn die SLA-Metriken nicht erfüllt werden können, kann die Orchestrierungsvorrichtung 1212 einen Benutzer über das Defizit benachrichtigen. Die Orchestrierungsvorrichtung 1212 kann Auswahlmöglichkeiten für alternative Konfigurationen oder Funktionalitätsebenen bereitstellen, um ein gewisses Ausmaß an Funktionalität zu behalten. Die Orchestrierungsvorrichtung 1212 kann mit dem Versuch fortfahren, die volle Funktionalität wiederherzustellen, um die SLA-Metriken zu erfüllen, wenn das System verändert wird. Wie hierin angemerkt, kann die Benachrichtigung auf einer Steuerkonsole und einer loT-Anzeige oder durch einen Proxy-Server beispielsweise ohne Steuerfunktionen angezeigt werden. Die Anzeige kann Benutzerinteraktionsoptionen umfassen, falls diese von der ausgewählten Systemkonfiguration und Richtlinie zugelassen werden.
Für die Umlagerung in ein Service-definiertes Datenzentrum können eine Reihe von Überlegungen in Betracht gezogen werden. Beispielsweise können Mehrmandatenkonzepte in alle Schichten der Servicelieferung, beginnend mit der Anwendung, einschließlich Benutzerschnittstelle und durch die Unternehmensschichtzerlegung und Infrastrukturservices eingebaut werden. Überlegungen hinsichtlich Mehrmandantenschaft und Noisy-Neighbor können ebenfalls in der CSI umfasst sein, um die Auswirkung eines neuen Services auf bestehende Services auf der gleichen Ressource zu verstehen. Das kann bei der Bereitstellung von Servicegewährleistung, Sicherheit, Transaktionsintegrität und einem verringerten Datenleckpotenzial helfen. Subskriptionen können zur Nachverfolgung von Details, wie z.B. spezifische Add-Ons und Funktionen, die der Kunde kauft, und Messung der genutzten Transaktionen und Funktionalitäten implementiert werden.
Eine Flexibilität der Monetarisierungsstrategien kann in Betracht gezogen und in das System eingebaut werden, um Aktualisierungen und Modifikationen entgegenzukommen. Automatisierte Bereitstellungs-, Abrechnungs- und Eingliederungsservices können genutzt werden, um die Skalierbarkeit der Verfahren zu verbessern. Das Anbieten der Services kann eine bedeutende Menge von Hilfsinfrastruktur umfassen, um ein hohes Ausmaß an Systemverfügbarkeit mit Kunden erhalten zu können, wie beispielsweise von SLAs bestimmt. Die Verfahren können die Grundlage für das Anbieten von Software als Service (SaaS) und Unternehmensprozesse als Service (BPaaS) zusammen mit den unterstützenden Unternehmenssystemen, um als Serviceanbieter fungieren zu können, bieten.
Ein Cloud-Serviceliefermanager (CSDM) kann unter Verwendung eines Schichtansatzes gebaut werden. Dadurch wird verhindert, dass eine gesamte Architektur auf einmal entwickelt werden muss. Darüber hinaus kann der CSDM Daten auf einer zuvor eingesetzten Schicht unter Verwendung eines Referenzstapels wie OSI, TCP/IP und dergleichen ermöglichen. Der CSDM kann einen verbesserten Testprozess ermöglichen, beispielsweise indem jede Schicht mit Parameterkontrollabschnitten untersucht wird und diese gemeldet werden. Dabei kann eine „Erwartung-gegenüber-Tatsache“-Differenzmaschine genutzt werden, die Grafiken nutzt, um die Präsentation zu verstärken. Die Grafiken können auf einem Verwaltungsserver oder einer loT-Vorrichtung in einem loT-Netzwerk angezeigt werden.
Der CSDM kann zusammen mit integrierten Entwicklungsumgebungen arbeiten, kann aber während Systemtestaktivitäten genutzt werden. Dadurch kann der CSDM Lücken hervorheben und Leistung charakterisieren, um Probleme zu erfassen und Inferenzmaschinen zu erzeugen, wenn Fehler in das System eingeführt werden. Darüber hinaus ermöglicht es dem CSDM u.a. Benachrichtigungen, SLA-Verstöße zu testen, bei der Grenzwerteinstellung zu helfen, Ladegeneratoren zu verwenden, um Umgebungen „aufzuputschen“ und Leistungslandschaften zu erfassen.
Während des Einsatzes kann der CSDM dann genutzt werden und Auslieferung und Rückholung von Anwendungen zu verwalten. Beispielsweise kann der CSDM genutzt werden, um die Planung zu Steuern, um stromabwärtige Einsätze ohne das durchlaufen aller stromaufwärtigen Schritte zu verhindern, wie bei der Verwendung von authentifizierten Arbeitsaufträgen. Darüber hinaus kann der CSDM eine geschichtete Bereitstellung mit Burn-in-Phasen in den Test-, Produktions- und Operationsumgebungen gewährleisten.
Während Operationen kann der CSDM Selbstservice-Schnittstellen und Meldeinstrumente bereitstellen, auf die von einem Verwaltungsserver oder von Steuerkonsolen auf loT-Vorrichtungen zugegriffen werden kann. Der CSDM kann auch ein integraler Bestandteil der Netzwerkoperationssteuerung (NOC) sein. Beispielsweise lernt der CSDM von Anomalien, erfasst Notlösungen und erzeugt Skriptversionen für automatisierte Aktualisierungen, einschließlich u.a. Arbeitsablaufaktualisierungen im veränderten Verwaltungssystem. Der CSDM verfügt über Sichtbarkeit über Scale-up- und Scale-out-Ressourcengruppierungen und kann auf Basis der definierten Grenzwerte, die während der Entwicklungsphase erfasst und während der Einsatzphase verfeinert wurden, Affinitäts- und Nichtaffinitäts-Arbeitslasten vorschlagen.
16 ist ein schematisches Diagramm eines weiteren Beispiels 1600 für die Verwendung eines Servicekatalogs 1602, um Microservices gemäß manchen Ausführungsformen bereitzustellen. Der Servicekatalog 1602 kann eine umfassende Liste verfügbarer Cloud-Services und Servicevorlagen 1604 umfassen, die wie hierin verwendet, Beschreibungen der Cloud-Services, ihrer Funktionen und der zur Bereitstellung des Services genutzten Technologien darstellen. Der Servicekatalog 1602 kann außerdem Optionen auf Serviceebene für SLAs und den verbundenen Kosten jeder Services auf jeder SLA-Ebene umfassen. Der Servicekatalog kann außerdem ein Selbstserviceportal für die Selbstbereitstellung von Cloud-Service auf Basis von Konsumenten-, Unternehmens- oder Organisationsanspruch und - anforderungen umfassen. Der Servicekatalog 1602 kann die Basis für Infrastruktur als Service (laaS), Plattform als Service (PaaS) und Software als Service (SaaS) bereitstellen.
Die Servicevorlagen 1604, die ausgewählt wurden, um die Serviceanfrage 1606 zu erfüllen, können an einen Arbeitslastmanager 1608 weitergeleitet werden. Der Arbeitslastmanager 1608 kann die Servicevorlagenanfrage annehmen, diese zerlegen und die Arbeitslastanforderungen und damit verbundenen QoS- und SLA-Anforderungen verstehen. Wie hierin verwendet, ist die Arbeitslast eine Abstraktion der tatsächlichen Arbeit, die eine Instanz oder Menge von Instanzen durchführen wird, einschließlich beispielsweise Datenverarbeitung, Vernetzung und Speicherung. Falls verfügbar lässt der Arbeitslastmanager 1608 einen Arbeitslastmodellieragent durchlaufen, um die wirksamsten Plattformen zum Hosten der Arbeitslast zu identifizieren. Der Arbeitslastmanager 1608 kann definieren, wie Arbeit in jeder Arbeitslast auf Ressourcen abgebildet werden, die von einer bestimmten Cloud angeboten werden. Falls verfügbar, kann ein Servicemodellieragent durchlaufen gelassen werden, um das Service zu identifizieren und gegen globale SLA- und ROI-Messungsmetriken zu verifizieren. Der Arbeitslastmanager 1608 kann dann die SLA- und ROI-Metriken mit dem Auftreten sammeln.
Dann kann ein Servicemanager 1610 genutzt werden, um die Status- und Zustandsinformationen von einer Cloud-Infrastruktur zu erfassen und anzufordern, beispielsweise unter Verwendung on Out-Of-Band- (OOB-) Verwaltungsinformationen und Serviceabfragen. Der Servicemanager 1610 kann horizontale Services, einschließlich beispielsweise Einrichtungen, Knoten, Gruppen, Richtlinien, Arbeitslasten, Steuerebenen, Verwaltungsfunktionen, Agenten und dergleichen nachverfolgen. Bei dem Servicemanager kann es sich außerdem um ein Service handeln, das auf dem DSF läuft, um Aktivitäten von Ressourcen, die von der CSI verwaltet werden, zu koordinieren. Die gesammelten Parameter können in eine Infrastrukturservicegewährleistung aggregiert werden. Das Serviceverwaltungssystem kann auch vertikale Services, einschließlich beispielsweise Sicherheit, Anspruch und Regulation, Leistung, Durchsatz, Zeitplanung, Stabilität, Funktionalität und dergleichen nachverfolgen. Die gesammelten Parameter können in eine Infrastrukturserviceverifikation zur Nachverfolgung aggregiert werden.
Ein Orchestrierungsmanager 1612 kann die Servicelieferung durch das Korrelieren der Anforderungen für die Arbeitslastzuordnung und der Infrastrukturerfüllungsanleitungen (wie der in Bezug auf 12 beschriebenen Aufgabeneinsatzabbildung 1222) orchestrieren, um das wirksamste Service an die beste Infrastrukturfunktionalität zu liefern, um die QoS- und ROI-Anforderungen zu erfüllen. Dementsprechend kann der Orchestrierungsmanager 1612 Infrastrukturelemente, wie beispielsweise Bildbereitstellung, Verbindungsherstellung, Anspruchsregistrierung, Berichten an Regulationsautoritäten und dergleichen zuordnen. Der Orchestrierungsmanager 1612 kann Infrastruktur-SLA aggregieren, um QoS-Metriken bereitzustellen und um den QoS-Überwachungsservices Servicegewährleistungsrückmeldungen bereitzustellen. Darüber hinaus kann der Orchestrierungsmanager 1612, wie hierin beschrieben, Infrastrukturelemente nach der Benachrichtigung über Fehlschlag, einen SLA-Ausfall, eine Unzulänglichkeit auf Steuerebene oder Serviceveränderung erneut zuordnen. Infrastrukturelemente können auch bei Veränderungen der Serviceanfrage oder der Bestimmung eines möglichen Fehlschlagereignisses neu zugeordnet werden. Eine Arbeitslastausgleichsanfrage von Services höherer Ebene kann auch die erneute Zuordnung von Infrastrukturelementen erzwingen, um SLAs für Services mit höherer Priorität oder Kosten zu erhalten.
17 ist ein schematisches Diagramm eines Beispiels 1700 für die Bereitstellung von IoT-Daten/Analyse-Konsumentenservices gemäß manchen Ausführungsformen. In Beispiel 1700 stehen loT-Netzwerke 1702 durch Operations- und Nutzungskanäle 1706 und Systemverwaltungskanäle 1708 in Kommunikation mit Cloud- und Analyseservices 1704.
Die Operations- und Nutzungskanäle 1706 können auf einer operativen Daten- und Serviceebene 1710 operieren. Diese Kanäle stellen Zugriff auf Vorrichtungsservices und Vorrichtungsdaten bereit, beispielsweise durch Daten- und Telemetriekanäle 1712. Steuerkanäle 1714 können die Steuerung von Services, Ressourcenaktuierung, Ereignisauslösung und Ereignisverwaltung ermöglichen.
Die Systemverwaltungskanäle 1708 operieren auf einer Verwaltungs- und Steuerebene 1716 und können die Verwaltung des System, einschließlich beispielsweise Betriebssystem, Firmware, BIOS, Verwaltungskanäle, Schnittstellen, und untergeordneter Vorrichtungen, wie Sensoren 1718 in Kommunikation durch ein Gateway 1720 ermöglichen. Ein Systemsteuerkanal 1722 kann die Steuerung des Systems, wie das Einleiten von Operationen und Aktivieren von Serviceprimitiven, wie u.a. Beschleunigern, Hardware-freigegebene Funktionen oder Betriebssystemfreigegebene Funktionen, ermöglichen. Ein Aktualisierungskanal 1724 kann die Aktualisierung des Betriebssystems oder der Firmware des Gateways 1720 oder deren untergeordneter Vorrichtungen, wie Sensoren 1718 ermöglichen. Ein Telemetriekanal 1726 kann die Kommunikation von SLA-Informationen und Funktionsinformationen vom loT-Netzwerk 1702, wie z.B. u.a. ordentliche Funktion der Vorrichtung, Diagnostik, Reputationsinformationen, Zerfallsrate und Operationseffizienzindikatoren ermöglichen.
18 ist ein schematisches Diagramm eines Distributed Services Framework 1800, in dem Microservice-Objekte an unterschiedlichen Orten für Operationen platziert werden können, gemäß manchen Ausführungsformen. Das Distributed Services Framework 1800 weist eine Steuerung 1802 auf, die von den Domänen geteilt wird, wie z.B. einer Edge- oder Fog-Seite 1804 und einer Cloud-Seite 1806. Die Domänen können von einem Fog-Service-Konnektor 1808, der Gateways, Router und drahtlose oder drahtgebundene Netzwerkverbindungen umfassen kann, gekoppelt werden.
Eine Überwachungsschaltung 1810 inspiziert die Infrastruktur, um sicherzustellen, dass die physischen Ressourcen und Schnittstellen verfügbar sind. Die Überwachungsschaltung kann bei einer Veränderung des Zustands der Schnittstellen oder Netzwerke eine Benachrichtigung ausgeben. Er kann mit einer Richtlinien- und Regelengine 1812 zusammenarbeiten, um neue Betriebsbedingungen auf Basis des vom Richtlinien- und Regelmanager 1812 bereitgestellten Leitfadens zu ermöglichen.
Eine Service-Framework-Steuerung 1814 verwaltet das gesamte Framework für die Service um sicherzustellen, dass physische und logische Verbindungen aktiv sind. Sie kann den ordentlichen Betrieb des Service-Mesh-Netzwerks ermöglichen und die Kommunikation zwischen Prozessen (IPC) verwalten.
Ein Objektrouter 1816 kann die Routerfunktionen für die Objekte zur Servicelieferung bereitstellen. Der Objektrouter 1816 kann außerdem das Erkennen von Objekten und das Abbilden von Objekten auf dem Service-Mesh-Netzwerk ermöglichen. Außerdem kann er die Platzierung von oder den Zugriff auf Objekte in der Verwaltungsdomäne steuern. Es gibt mehrere Objekttypen, einschließlich u.a. Ressourcenobjekt, Leader-Objekt, Serviceobjekt, Containerobjekt, Arbeitsablaufobjekt und Verbindungsobjekt.
Die Microservice-Kopplung 1818 kann die Servicelieferanleitungen, beispielsweise eine Aufgabeneinsatzabbildung umfassen. Sie kann sicherstellen, dass die Prä- und Post-Anforderungen für die Servicelieferung freigegeben sind. Die Microservice-Kopplung 1818 kann außerdem eine Servicezusammenfügung durchführen, beispielsweise, neben anderen Funktionen, indem die Ein- und Ausgaben bestimmter Services gekoppelt werden.
Zusätzlich zur Arbeit mit der Überwachungsschaltung 1810 kann der Richtlinien- und Regelmanager 1812 die Richtlinien und Regeln für Operationen umfassen. Diese können die Regeln und Verfahren für Schnittstellenumschaltung auf Basis von Überwachungsschaltungseingaben umfassen. Der Richtlinien- und Regelmanager kann Aktivitäten verwalten, die durch die Serviceunterbrechung im Fog-Service-Konnektor 1808 eingeleitet werden.
Die Microservice-Objekte 1802 können je nach operativen Funktionaltäten, SLAs und dergleichen platziert oder bewegt werden. Es können zwei Klassen von Microservice-Objekten 1802 identifiziert werden, und zwar unbeweglich Objekte 1820 und mobile Objekte 1822.
Ein unbewegliches Objekt 1820 ist ein Microservice-Objekt 1802, das in der Regel nicht von der Serviceseite, z.B. der Edge- oder Fog-Seite 1804 oder der Cloud-Seite 1806, auf der es platziert wurde, bewegt wird. Das kann am Zweck des unbeweglichen Objekts 1820 liegen, wenn beispielsweise ein Microservice-Objekt 1802 dazu gedacht ist, auf eine Datenbank zuzugreifen, kann es in der Nähe der Datenbank bewahrt werden. Darüber hinaus ist ein Microservice-Objekt 1802, das von einem Sensor für spezifische Sensoroperationen genutzt wird, wie die Temperaturdetektion auf einem Temperatursensor, in der Regel ein unbewegliches Objekt 1820. Unbewegliche Objekte können je nach Verwendung komprimiert und dekomprimiert werden. Sie werden genutzt, wenn die Einzweckfunktion einer Ressource spezifisch zugeordnet ist. Darüber hinaus können sie genutzt werden, wenn die Ressource nicht alle Microservices auf einmal aufgrund von Ausführungsplatzbeschränkungen ausführen kann. Vor dem Dekomprimieren und Laden bestimmt das System den aktuellen Ausführungsplatz und wertet die Fähigkeit, die neue Einzweckfunktion zu laden, sowie die Auswirkung auf die Ressourcenoperationen und den anderen Microservices zugeordneten SLOs aus.
Ein mobiles Objekt 1822 ist ein Microservice-Objekt 1802, das je nach Anwendungsfall, Implementierungsspezifizierung und Optimierungsanforderungen auf dem Service-Framework 1800 zwischen der Edge- oder Fog-Seite 1804 und der Cloud-Seite 1806 bewegt werden kann. Beispielsweise kann ein Microservice-Objekt 1802, das eine Berechnung durchführt, auf jeder Seite laufen, je nach dem, wo sich die Ergebnisse der Berechnung und Eingabedaten für die Berechnung befinden.
19 ist ein schematisches Diagramm für einen Knoten einer gemeinsamen Serviceschnittstelle (CSI) 1900 zum Erkennen und Identifizieren von Ressourcen, gemäß manchen Ausführungsformen. Der CSI-Knoten 1900 kann als kleinster gemeinsamer Nenner für eine Arbeitslast in Bezug auf die Servicezusammensetzung für die Lieferung fungieren. Er kann eine beliebige ein Service wahrnehmende Vorrichtung umfassen, von Konsumentenvorrichtungen, wie Smartphones und Tablets, bis hin zu Edge-Komponenten für die Lieferung. Er kann außerdem u.a. loT-Ressourcen, wie loT-Vorrichtungen und Fog-Vorrichtungen, Datenzentrumselemente und RSA-Komponenten umfassen.
Der CSI-Knoten 1900 kann Rechner-, Speicher- und Netzwerkelemente, sowie nicht zusammensetzbare Komponenten, wie u.a. Systems on a Chip (SoCs), FPGAs und Infrastrukturvorrichtungen umfassen. Der CSI-Knoten 1900 kann statische, Laufzeit- und Echtzeitanlagenvektoren 1902 aufweisen, die Funktionalität, Wert, Allokation und Funktion über eine gemeinsame Serviceschnittstelle 1904 beschreiben, indem u.a. standardmäßige Serviceebenen- und Serviceliefernomenklatur über eine Programmierschnittstelle (API), Pub/Sub, DDS, und RSS-Feeds verwendet wird.
Der CSI-Knoten 1900 kann eine neue Schnittstellen- und Verwaltbarkeitsengine, Prozessor und Softwaresystem definieren, das eine autonome Verwaltbarkeit und Ressourceneigenwahrnehmung bereitstellt. Der CSI-Knoten 1900 kann befähigt sein, um Entscheidungen zu treffen, die Entscheidungen zu erlassen und die Umgebung und andere umgebende intelligente Ressourcen wahrzunehmen. Dadurch kann die Latenz und die Abhängigkeit von einem Datenzentrum verringert werden, Entscheidungen über Situationen, die vom Datenzentrum entfernt oder lokal für ein loT-Netzwerk lokal sind, zu treffen und zu validieren. Ein neuer IP-Block, der ein Serviceprotokoll umfasst, kann genutzt werden, um eine Systemintegrationslösung für eine aktive Serviceverwaltbarkeit und eine intelligente Verwaltbarkeitsschnittstelle bereitzustellen. Darüber hinaus kann eine neue Verwaltbarkeitsschnittstelle zur Seitenbandverwaltung genutzt werden.
Ressourcen, die für CSI-Knoten 1900 freigegeben sind, können ad hoc organisierte Gruppen bilden, die die Schnittstelle nutzen, um Ressourcen in fest oder locker gekoppelte Serviceliefersysteme, wie hierin beschriebene Fog-Vorrichtungen zusammenzusetzen. Diese Systeme können zahlreiche homogene oder heterogene Netzwerk- und Infrastruktur- oder Schnittstellenelemente nutzen, um sich daran zu halten, oder die in der Lage sind, die gemeinsame Konsumenten- oder Sitzungsservice-Serviceschnittstelle zu liefern.
Die CSI-Knoten 1900 können das Eingliedern oder Peering sowie die Zuordnung zu einer Verwaltungsdomäne umfassen. Ein CSI-Knoten 1900 kann sowohl in einer physischen Landschaft 1905 als auch der logischen Landschaft 1906 bestehen. Die physische Landschaft 1905 beschreibt die beworbene Funktionalität für die Infrastrukturkomponenten in Bezug auf Services. Zwei der Vektoren 1902 existieren in der physischen Landschaft 1905. Die Daten von den Vektoren 1902 in der physischen Landschaft 1905 können genutzt werden, um für den Servicebereich eine Ansicht der physischen Landschaft 1905 zu bauen. Ein Funktionalitätsvektor 1908 beschreibt die Anlagenfunktionalität, Identität, Ort, Kapazität und Merkmale. er stellt Analysefunktionen verwertbare Intelligenz bereit. Ein Wertvektor 1910 beschreibt den Anlagenwert in Bezug auf die Kosten für Abrechnung, Ausgleich und Messung. Wie hierin angemerkt, kann die Verwendung der physische Landschaft 1905 und der logischen Landschaft 1906 auf einer Steuerkonsole und einer loT-Anzeige oder durch einen Proxy-Server beispielsweise ohne Steuerfunktionen angezeigt werden. Die Anzeige kann Benutzerinteraktionsoptionen umfassen, falls diese von der ausgewählten Systemkonfiguration und Richtlinie zugelassen werden.
Die anderen zwei Vektoren 1902 existieren in der logischen Landschaft 1906. Die logische Landschaft 1906 beschreibt die eigentlichen Echtzeit-Funktionalitäten in Bezug auf Services. Die logische Landschaft 1906 weist auch eine Schnittstelle 1912 auf, die an ein Distributed Services Framework (DSF) 1914 gekoppelt ist. Das DSF 1914 kann ein loT-Freizeichen bereitstellen, beispielsweise wobei der CSI-Knoten 1900 an Microservice-Anbieter in der Cloud gekoppelt wird. Wie hierin verwendet ist ein loT-Freizeichen ein kontinuierlich zugängliches und identifiziertes Service für die Bereitstellung von Code-Segmenten und anderen Microservices von Anbietern. Das loT-Freizeichen kann die anfänglichen Richtlinien und Verpflichtungsparadigmen für den Beitritt zu einem DSF-Verwaltungsnetzwerk bereitstellen.
Die von den Vektoren 1902 in der logischen Landschaft 1906 bereitgestellten Informationen können verwendet werden, um eine Ansicht der logischen Landschaft 1906 für den Servicebereich zu erstellen. Ein Funktionsvektor 1916 beschreibt die Anlagefunktion, Reputation und eigentliche Funktionalität basierend auf Alter, Verwendung und anderen Faktoren. Ein Allokationsvektor 1918 kann den Status der Anlagereservierung, der Zuordnung, der Sperre und der Laufzeit beschreiben.
Der CSI-Knoten 1900 kann mit anderen CSI-Knoten über die gemeinsame Serviceschnittstelle (CSI) 1904 kommunizieren. Die CSI 1904 kann ein Peering-System zur Eingliederung verwenden und sich selbst mit einer Verwaltungsdomäne assoziieren, die das DSF 1914 umfasst. Die Architektur, die die DSF/CSI-Kombination umfasst, ist abgeflacht und verteilt und erfordert kein zentrales Verwaltungssystem, um ein Ressourceninventar und die Beschreibung, Serviceassoziierung zu erhalten oder um eine Sitzungsverwaltung dieser Ressourcen durchzuführen. Die Peering-Benachrichtigung findet statt, wenn der CSI-Knoten 1900 dem 1914 beitritt, beispielsweise, indem er auf dem Netzwerk erscheint und mit dem loT-Freizeichen zu verbinden. Ein CSI-Knoten 1900 kann einige DSFs betreten, verwalten und zwischen einigen DSFs vermitteln, um sicherzustellen, dass die Services und Sitzungen, an denen er beteiligt ist, oder die er liefert, gegen SLAs durchgeführt werden. Dies kann durchgeführt werden, indem gegen die Sitzungsverbindung und Ziele auf Serviceebene und Spezifikationen gemessen wird.
Der CSI-Knoten 1900 kann einen Multi-DSF-Vermittler enthalten. Der Multi-DSF-Vermittler kann die Anforderungen für multiple DSF-Verbindungen und Sitzungsschnittstellen mit dem CSI-Knoten 1900 vermitteln, balancieren und lösen oder priorisieren. Ferner können multiple CSI-Knoten mit einem einzelnen DSF assoziiert sein und multiple DSFs können mit einem einzelnen CSI-Knoten assoziiert sein. Der CSI-Knoten 1900 kann die Beziehung mit den einzelnen oder multiplen DSFs, die mit dem CSI-Knoten 1900 assoziiert sind, verwalten. Dies kann helfen, sicherzustellen, dass das Verhalten von dem CSI-Knoten 1900 von dem CSI-Knoten 1900 von dessen Primärbesitzer verwaltet werden kann, während die Servicelieferung, -Verwaltung und Zulieferkette, die von dem DSF-Freizeichen definiert sind, mit der CSI verbunden sind.
Der CSI-Knoten 1900 kann einen Multi-DSF-Serviceorchestrator umfassen. Der Orchestrator kann die Funktionalität des CSI-Knotens 1900 identifizieren, um Services mit einer messbaren Service-Spezifikation (SLS) und Zielen auf Serviceebene (SLO) von dem CSI-Knoten 1900 an den übergreifenden Serviceorchestrator bereitzustellen, der normalerweise auf dem Service- oder Sitzungsanforderer läuft. Der Multi-DSF-Serviceorchestrator kann auch die SLS/SLO messen, um zu helfen, sicherzustellen, dass der CSI-Knoten 1900 den Teil des Service wie angefordert bereitstellt und Ereignisse/Logging und Benachrichtigungen bereitstellt, wenn die SLS/SLO nicht eingehalten werden. Der Multi-DSF-Serviceorchestrator kann auf der Ebene des CSI-Knotens 1900 eine Korrektur bereitstellen, wenn diese Funktion von dem Primärbesitzer des CSI-Knotens 1900 aktiviert wurde und erreichbar ist. Der Multi-DSF-Serviceorchestrator kann auch mit dem Service-Absender-Orchestrator arbeiten, um Metriken bereitzustellen, die beim Zurücksetzen oder Korrigieren von SLAs auf Block-Chain-Ebene helfen können.
Die CSI 1904 kann eine Anzahl von Funktionen umfassen, um Interaktionen zwischen CSI-Knoten zu erleichtern. Beispielsweise kann die CSI 1904 einen Vertrauensindex und eine Maschinenlerntechnik zu umfassen, um einen Einblick in die von den CSI-Knoten selbst gemessenen und von der Gemeinschaft gemessene Berechnungen der Zuverlässigkeit, Qualität der Leistungserbringung und der Fähigkeit, Funktionen bereitzustellen und Funktionen gegen vergangene, gegenwärtige und Echtzeit-Anforderungen oder aktuelle Sitzungsanforderungen. Diese Funktion kann Feedback zu Parametern, die mit Beeinträchtigung in der Sitzung, Funktionalität, Fähigkeit, Vertrauen und Zuverlässigkeit in Verbindung stehen, bestimmen, sicherstellen und bereitstellen. Diese Funktion kann auch Feedback zu Veränderungen bereitstellen, die die SLO/SLS-Metriken negativ beeinflussen können oder die eine messbare Auswirkung auf die End-zu-End-Service-Sitzungs-SLA haben können. Manche dieser Metriken können temporäre Beeinträchtigungen sein, aufgrund von externen Faktoren wie z. B. Temperatur, Druck, Resonanz und dergleichen, die auf den CSI-Knoten 1900 einwirken.
Die CSI 1904 kann auch eine vorhersagbare Service-Schnittstellen-Prognosefunktion umfassen. Diese Funktion kann die Verfügbarkeit des nächstbesten Netzwerks oder der nächstbesten Schnittstelle vorhersagen, basierend auf der Position oder der Signalstärke.
Die CSI 1904 kann auch eine Serviceverminderungsfunktion umfassen, um die Rate der Servicelieferung und eine assoziierte Serviceverminderung oder Signalverbesserung zu bestimmen. Sie kann verbessert werden, um Serviceeigenschaften zur Gewährleistung oder Gewährleistung für ein SLA aufrechtzuerhalten. Sie kann verwendet werden, um zu bestimmen, ob die Infrastruktur gut oder schlecht ist und ob der Trend der Serviceverminderungsrate in einer dynamischen Umgebung abfallend ist oder sich verbessert. Die Funktion kann helfen, sicherzustellen, dass das Service vollständig sein kann oder ob andere Aktionen für das Service erforderlich sind, wie z. B. eine Pause, ein Neustart, Abbruch, Fortsetzen, Puffer, Verteilen und Verbinden unter Verwendung anderer Ressourcen, unter anderem.
20 ist ein Blockdiagramm eines Distributed Services Frameworks (DSF) 2000 in Übereinstimmung mit manchen Ausführungsformen. Elemente mit derselben Nummerierung werden mit Bezug auf 19 beschrieben. Wie hierin beschrieben umfasst das DSF 2000 eine Schnittstelle, ein Protokoll und ein Netzwerk-Service, das die Fähigkeit für intelligente, selbstbewusste und autonome Vorrichtungen bereitstellt, ihre Interaktionen mit einem Serviceanbieter aufzunehmen, zu entdecken und zu verwalten, ohne ein zentrales Verwaltungssystem in der Cloud zu benötigen.
Das DSF 2000 kann das Verwaltungssystem für loT-Vorrichtungen und - Netzwerke abflachen. Dies kann die Verwaltungsservices abflachen, einschließlich Peering, Entdeckung, Aufnahme, Identifizierung und dergleichen, für die Millionen gesteuerten Vorrichtungen. Ferner kann das DSF 2000 intelligenten Ressourcen erlauben, zusammenzuarbeiten, zu kooperieren und Ad-hoc-Mesh-Sammlungen zu erstellen, um die Anforderungen für ein Service zu erzielen, die so nahe wie möglich am Ursprung der Serviceanfrage liegen.
Das DSF 2000 kann die Fähigkeit aktivieren, Ereignisse zu identifizieren, die aktiv auftreten. Es kann allen bereits in ein Ereignis involvierten Ressourcen oder Ressourcen, die in ein Ereignis involviert werden sollen, erlauben, Entscheidungen zu treffen und Aktivitäten zu koordinieren. Als ein Beispiel kann das Implementieren des DSF 2000 in die in Bezug auf 2 beschriebene Fog-gesteuerte Verkehrsampel erlauben, dass die Verkehrsampel und ein herankommendes Einsatzfahrzeug die Funktionen koordinieren, die erforderlich sind, um den Verkehr anzuhalten, um dem Einsatzfahrzeug zu erlauben, alle Kreuzungen ungehindert zu überqueren. In einem anderen Beispiel kann ein Rettungsfahrzeug von hinten auf einer Schnellstraße fahrende Autos zukommen. Ein zwischen den Fahrzeugen vernetztes DSF 2000 kann Microservices für die Koordination bereitstellen, die die Autos dazu veranlassen, zur Seite zu fahren und das Rettungsfahrzeug vorbeifahren zu lassen.
Das DSF 2000 stellt zwei Hauptschnittstellen bereit, einschließlich einer gemeinsamen Schnittstelleninfrastruktur, die mit Ressourcen kommunizieren kann, die an Bord kommen, bereits zugänglich sind oder den Zustand über die Schnittstelle verändern. Eine andere Schnittstelle kann die Fähigkeit bereitstellen, die Microservices zu verwalten, die mit den verfügbaren Ressourcen interagieren oder die damit arbeiten.
Das DSF 2000 kann in Verbindung mit einem vertrauenswürdigen Datenbus (TDS) 2002 arbeiten, um die Verwaltungsservices für die Ressourcen zu bestimmen. Die Services beginnen mit einer gemeinsamen Serviceschnittstelle (CSI) 1904, wie in Bezug auf den CSI-Knoten 1900 aus 1 beschrieben. Wie hierin beschrieben stellt der CSI 1904-Bus und das CSI 1904-Protokoll eine konstante und dynamische Verwaltung und Zugang für Ressourcen auf vier Vektoren bereit, einschließlich statischer, Laufzeit- und Echtzeit-Vektoren. Die CSI 1904 beschreibt die Funktionalität, den finanziellen Wert, die Nutzer- und Richtlinien-Zuweisung und Funktionalität, unter Verwendung der Standard-Service-Ebene und Servicelieferungsnomenklatur über APIs oder DDS-Subskriptionsmodelle. Zusätzlich dazu kann die CSI 1904 eingebettete Richtlinien umfassen, die die Verwaltung, Steuerung und Abruf von Ressourcen eng an die Ressourcenschnittstelle selbst koppeln, wodurch die Latenz der Antwort reduziert wird.
Der vertrauenswürdige Datenbus 2002 umfasst einen Namen basierend auf der Routingfunktion 2004. Das DSF 2000 verwendet die digitale Objektarchitektur(DOA)-Konvention, bei der der es eine Ansicht auf die physischen Ressourcen als Objekte mit Deskriptoren bereitstellt. Unter Verwendung der namensbasierten Routingfunktion 2004 können die Ressourcen und Dinge innerhalb von loT-Netzwerken direkt angesprochen werden, auf sie kann direkt zugegriffen werden und sie können direkt verändert werden, sogar ohne spezifisches Wissen über die Position oder eine vollständige Beschreibung des Dings.
Erkennungselement 2006 ist eines der Kern-Architekturelemente für das DSF 2000. Das Erkennungselement 2006 stellt eine leichte Servicelieferungsstruktur dar, die Services wie z. B. das Lokalisieren, Auffinden, Ansprechen, Zurückverfolgen, Nachverfolgen, Verfolgen, Identifizieren und Erfassen bereitstellt, um eine Ressourcenankunft auf dem Framework zu identifizieren. So kann der Manager oder der Besitzer der Ressourcendomäne spezifische Verwaltungsregeln und servicebewusste Richtlinien verwenden, um eine ordnungsgemäße Ressourcenentdeckung, -erfassung und -zertifizierung sicherzustellen.
Das DSF 2000 kann einige Zugangs- und Schnittstellenlösungen bereitstellen. Beispielsweise stellen publish/subscribe 2008 und request/response 2010-Lösungen einfache und effektive Wege bereit, Zugang zu den von der CSI 1904 bereitgestellten Ressourcendaten zu erhalten. Darüber hinaus können Ereignisse, die auf der verteilten Service-Schnittstellt 1912 auftreten, über eine Ereignis-gesteuerte Benachrichtigungsschnittstelle 2012 weitergegeben werden.
Ein Service-Framework-Protokoll 2014 verwaltet das komplette Framework für Services. Die Korrektur von SLOs, von der obersten Ebene, gegen Kombinationen von physischen Ressourcenelementen erfordert, dass auf einer gewissen Ebene in dem Verwaltungsstapel eine konsistente Repräsentation von physischen und logischen Ressourcenelementen gibt. Dies ist ein Problem für entstehende heterogene Umgebungen und in hochskalierten Szenarien, wo eine statische Zuordnung operational undurchführbar ist. Ein Ansatz zur Abbildung von Abhängigkeiten und Beziehungen zwischen Service-Ressourcen und Ressourcen unabhängig vom Abstraktionsgrad sind mehrschichtige und miteinander verbundene Graphen. Das Aufrechterhalten solch einer Darstellung der Landschaft kann wertvoll sein, wenn Konfigurationsoptionen modelliert werden oder wenn das Laufzeitsystem auf eine optimale Leistung, Effizienz, Zuverlässigkeit oder eine beliebige andere Metrik hin inspiziert wird. Ein Blick auf Korrelationen aus der Telemetrie kann auf Kausalitäten hinweisen. Insgesamt kann das Service-Framework-Protokoll 2014 dafür verantwortlich sein, dass auf die Ressourcen als physische Elemente ebenso wie logische Verbindungen zugegriffen werden kann, dass sie Steuer- und verwaltbar sind.
Ein Zielverwaltungsmodell für physische Ressourcen 2016 kann umfasst sein, um physische Ressourcen als Objekte zu verwalten. Jedoch kann es zweckmäßig sein, die Verbindung zu den physischen Ressourcen zur Steuerung und zur Verwaltung zu bewahren. Zu anderen Zwecken, wie z. B. Modellierung und Optimierung stellt die Architektur eine Zuweisung oder eine logische Schicht bereit, die eine gefilterte Perspektive bereitstellt. Es gibt zwei Schichten innerhalb des Zielverwaltungsmodells für physische Ressourcen 2016. Eine physische Schicht verfolgt Ressourcenkomponenten, basierend auf den Daten die durch die CSI 1904 bereitgestellt werden. Eine logische oder Zuweisungsschicht verfolgt eine Verkettung von Servicezielen, basierend auf den physischen Ressourcen innerhalb der loT-Ressourcenverwaltungsdomäne. Darüber hinaus fängt sie die aktuellen Betriebsressourcen ein, die von Microservice-Routing- und Verkettungsmechanismen bestimmt und verwaltet werden.
Das Zielverwaltungsmodell für physische Ressourcen 2016 kann vier Kernkomponenten zur Verwaltung der physischen Ressourcen als Objekte umfassen. Diese Komponenten können einen Ziel-Router 2018, Ziel-Erkennungselement 2020 und Ziel-Register 2022 und eine Ziel-Verkettung 2024 umfassen.
Der Ziel-Router 2018 stellt die Routing-Funktion für die Ziele für die Servicelieferung bereit. Diese Informationen können durch die Beschreibung der logischen oder der Zuweisungsschicht erhältlich sein. Darüber verwaltet die anfängliche Identifikation und Ziel-Erkennungselement 2020 sowie die Positionierung, Abbildung und Zielregistrierung 2022 auf dem DSF 2000.
Die Ziel-Verkettung 2024 umfasst die Beschreibung der zusammengefassten Ziele und ihrer Beziehungen. Sie kann sicherstellen, dass die Prä-Anforderungen und Post-Anforderungen für die Servicelieferung freigegeben sind und können Servicezusammenfügung durchführen.
Die DSF 2000-Architektur kann auch eine Microservice-Steuerung 2026 umfassen. Da das DSF 2000 agnostisch gegenüber allen Ressourcen ist, stellt es eine gleiche Fähigkeit dar, loT-Vorrichtungen und Cloud-Ressourcen zu verbinden und konsistenten Ressourcenverwaltungszugang über die Verwaltungsdomäne bereitzustellen. Aufgrund dieser allgegenwärtigen Funktionalität können die Microservices basierend auf den Servicelieferungseinschränkungen oder - anforderungen auf der effektivsten Position platziert werden, und dann dynamisch neu bereitgestellt, basierend auf den Änderungen in der Implementierung oder den Anwendungsfällen. Dieselben Microservices können auf der Cloud für Analytik in einer Implementierung und auf einer Edge-basierten Cluster-Analytik-Lösung in einer anderen angewandt werden. Die Microservice-Steuerung 2026 enthält Softwareelemente, um die korrekte Platzierung und Zusammenschaltung von Microservices sicherzustellen, um eine kontinuierliche Servicelieferung sicherzustellen.
Eine Infrastrukturüberwachungsschaltung 2028 untersucht die Infrastruktur, um sicherzustellen, dass physische Ressourcen und Schnittstellen verfügbar sind. Sie stellt Benachrichtigungen bei Veränderungen des Zustands bereit und arbeitet in Zusammenhang mit einer Richtlinien- und Regelfunktionseinheit, um alternative Servicelieferungsmechanismen innerhalb der Beschränkungen bereitzustellen, um einen angemessenen Betriebszustand sicherzustellen und eine Infrastruktur, basierend auf den Anweisungen.
Das DSF 2000 kann eine Richtlinien-Funktionseinheit 2030 umfassen, um die Richtlinien zu erstellen, zu verwalten, zu verteilen und zu widerrufen, die die Verwaltungsstruktur von Ressourcen beschreiben. Die Richtlinienfunktionseinheit 2030 umfasst die Richtlinien und die Regeln für den Betrieb, die Regeln und Verfahren für Schnittstellenumschaltung basieren auf Eingaben der Überwachungsschaltung und verwaltet Aktivitäten, die Aktivitäten, die durch eine Unterbrechung des Services im Serviceverbinder ausgelöst werden.
Die Microservice-Framework-Steuerung (MFC) 2032 ist der Mechanismus der die Microservices verwaltet und steuert, die über das DSF 2000 laufen. Die MFC 2032 ist verantwortlich für den Betrieb der Services, die über das DSF 2000 laufen, die Verbindungen zwischen den Ressourcenzielen und ihren Services und die Kontinuität der Benutzeranalysedienste. Die MFC 2032 kann einen Microservice-Router 2034 verwenden, einen Microservice-Injektor 2036 und ein Microservice-Vernetzungselement 2038, um die Service-Elemente ordnungsgemäß in eine Endzu-End-Lösung innerhalb der Beschränkungen der Umgebung und der physischen Ressourcen und Bedingungen zu routen, zu greifen, zu übertragen und zusammenzustellen. Die MFC 2032 umfasst auch eine Verwaltungs- und Durchsetzungsfunktion 2040, um die Richtlinien und Regeln durchzusetzen.
Das DSF 2000 kann einen Serviceverbinder 2042 umfassen, der eine logische Struktur ist, die als ein Weg für prozessübergreifende Kommunikation (IPC) zwischen dem Edge und der Cloud dient. Er stellt die Servicelieferungsgewährleistung bereit und erhält und verwaltet die Metriken und Messungen für die ordnungsgemäße Servicegewährleistung.
Wie hierin beschrieben funktioniert das DSF 2000 mit einem loT-Freizeichen, um zu bestimmen, wie Ressourcen anfänglich prüfen und einer Verwaltungsdomäne beitreten. Das loT-Freizeichen wird verwendet, um die Konversation zu beginnen, um eine Zulieferkette für Microservices aufzubauen.
Das DSF 2000 kann einen Microservice-Begleitagenten oder ein -Service umfassen, der bzw. das beschreibt, wie die Microservice-Ziele, die aktiviert, platziert und aktiviert wurden, um ein Sitzungsservice auszuführen, ausfindig gemacht, verfolgt und verwaltet werden können. Dies kann helfen, sicherzustellen, dass ein vertraglicher SLA geliefert, erhalten und orchestriert wird. Ferner kann der Microservice-Begleitagent oder -Service dabei helfen, dass der SLA gemessen und in Rechnung stellt wird.
Eine Multi-DSF-Richtlinienarchitektur oder Programmarchitektur kann die Architektur dafür bestimmen, wie ein DSF funktioniert, einschließlich dessen, wie die Richtlinien und die Regeln Strukturen sind. Die Programmarchitektur kann eine Schnittstellenspezifizierung umfassen, eine Strukturspezifizierung, eine Zielspezifizierung und eine Eingliederung/Anforderungsverwaltungsfunktion, unter anderem.
21 ist eine schematische Grafik eines Beispiels für ein loT-Netzwerk 2100, das Knoten 2102 verwendet, die für ein Distributed Services Framework in Übereinstimmung mit manchen Ausführungsformen aktiviert sind. Die Knoten 2102 können wie in Bezug auf den CSI-Knoten 1900 aus 19 beschrieben, sein. Jeder der Knoten 2102 kann mit anderen Knoten 2102 gekoppelt sein, beispielsweise über ein drahtgebundenes TCP/IP-Netzwerk, ein drahtloses Netzwerk, ein Mesh-Netzwerk oder beliebigen Kombinationen davon. Jeder Knoten kann auch eine physische Netzwerkschnittstelle 2104 sein. Zusätzlich zu der physischen Netzwerkschnittstelle 2104 kann jeder Knoten 2102 Rechner- und Speicherressourcen umfassen.
Eine verteilte Serviceschnittstelle 2106, die in dem Knoten 2102 umfasst ist, ist eine logische Schnittstelle zur Handhabung der Kommunikationen mit einem Distributed Services Framework (DSF), beispielsweise mit der Schnittstelle mit dem loT-Freizeichen, wie hierin beschrieben. Eine gemeinsame Serviceschnittstelle (CSI) 2108 ist eine logische Schnittstelle, die für die Kommunikation mit anderen loT-Vorrichtungen über die Netzwerkschnittstelle 2104 verwendet werden kann.
Die Knoten 2102 können eine Netzwerktopologie herstellen und mit anderen Knoten 2102 zusammenschalten. Peer-Verbindungen können durch die gemeinsame Serviceschnittstelle 2108 hergestellt werden. Jeder Knoten 2102 kann seinen Status, seine Identifikation, Position und dergleichen anzeigen. Jeder Knoten kann von dem gemeinsamen Service verwaltete Anlagen entdecken und Anlagen anzeigen, die von dem Knoten 2102 verwaltet werden. Dies kann ein Wissensframework für die Knoten 2102 in dem loT-Netzwerk 2100 herstellen.
Wie hierin beschrieben kann eine Anzahl von Steuerungsblöcken 2110 in jedem Knoten 2102 umfasst sein, die CSI, das DSF und andere Funktionen zu implementieren. Diese Steuerungsblöcke 2110 werden in 22 detaillierter beschrieben.
22 ist ein Blockschaltbild einer gemeinsamen Serviceschnittstellenarchitektur für einen Knoten 2102 in Übereinstimmung mit manchen Ausführungsformen. Die gleichen Zahlen sind wie in Bezug auf 21 beschrieben. Der Knoten 2102 kann eine Anlagenverwaltungsfunktion 2202 umfassen, um Anlagen, die mit dem Knoten 2102 verbunden sind und Anlagen, die in Kommunikation mit dem Knoten 2102 von anderen Knoten sein können, zu verwalten. Eine Zulieferungskettenverwaltungsfunktion 2204 kann Serviceanfragen handhaben, beispielsweise das Erhalten von Servicevorlagen 2206 von einem Microservice-Anbieter, gekoppelt durch die verteilte Serviceschnittstelle 2106. Ebenso können Schnittstellentranslatoren 2208 von dem Distributed Services Framework über die verteilte Serviceschnittstelle 2106 erhalten werden. Eine Serviceverwaltungsfunktion 2210 kann umfasst sein, um Microservices zu erhalten und kann die Microservices in dem Knoten 2202 implementieren. Serviceanalytik 2212 kann umfasst sein, um zu helfen, sicherzustellen, dass SLAs erfüllt werden. Eine Servicekohärenzfunktion 2214 kann sich mit anderen Knoten koordinieren, um Services für Anwendungen zu implementieren. Eine Benachrichtigungsfunktion 2216 kann verwendet werden, um Mitteilungen zwischen dem Knoten 2102 und anderen Systemen zu senden, wie z. B. einem Vorrichtungsbesitzer oder einem Serviceanfragenden. Eine Zuordnungs-/Reservierungs- und Sperrfunktion 2218 kann verwendet werden, um Ressourcen zu bestimmten Services zuzuweisen und um Services mit niedrigerer Priorität davon abzuhalten, zugewiesene Services zu übernehmen. Die Vernetzungs-/Dekompositionsfunktion 2220 kann verwendet werden, um Arbeitslasten in individuelle Microservices zu zerlegen, die erforderlich sein können, oder um Ergebnisse von unterschiedlichen Microservices für die Präsentation an einen Vorrichtungsbesitzer oder Serviceanfragenden zu präsentieren. Eine Lebenszyklusfunktion 2222 kann verwendet werden, um den übrigen Lebenszyklus für den Knoten 2102 zu verfolgen, einschließlich, beispielsweise, übriger Auslesungen/Schreibvorgänge auf einen nicht flüchtigen Speicher, übriger Batteriezyklen und dergleichen.
23 ist ein Blockdiagramm eines Softwareverwaltungssystems 2300 für loT und Microservice-Orchestrierung in Übereinstimmung mit manchen Ausführungsformen. Gleich nummerierte Elemente werden in Bezug auf 20 beschrieben. Das Softwareverwaltungssystem 2300 kann die hierin beschriebenen Elemente einbeziehen, um ein Distributed-Service-Framework-System unter Verwendung einer gemeinsamen Serviceschnittstelle bereitzustellen. Das Softwareverwaltungssystem kann Edge-Vorrichtungen 2302 umfassen, wie z. B. loT-Ressourcen 2304 und lokale Cloud-Services 2306, unter anderem. Das SoftwareVerwaltungssystem 2300 kann auch cloudbasierte Vorrichtungen 2308 umfassen, wie z. B. eine Serviceanbieter-Cloud 2310, die andere mögliche Services umfassen kann, wie z. B. Software als Service (SaaS) 2312, Plattform als Service (PaaS) 2314 und Infrastruktur als Service (SaaS) 2316. Andere Services, die von dem Cloud-Anbieter angeboten werden können, umfassen direkte Cloud-Services 2318, die auf virtuellen Maschinen in der Cloud laufen können und vermittelte Cloud-Services 2320, die in Clouds im Besitz anderer Anbieter 2322 laufen können.
Zusätzlich zu dem Distributed Services Framework 2000, kann das Softwareverwaltungssystem 2300 Werkzeuge für die Implementierung von Verwaltungsfunktionen umfassen. Diese können Analytik und Microservices 2324, und Verwaltung, Verwaltbarkeit und Steuerfunktionen (MMC) 2326 umfassen. Die MMC-Funktionen 2326 können Anlageservices 2328 umfassen, beispielsweise, wie in Bezug auf die gemeinsame Serviceschnittstelle 1900 von 19 beschrieben. Die MMC 2326 kann auch Telemetrieservices 2330 umfassen, um die Gesundheit, Reputation und Metadaten für Vorrichtungen zu verfolgen.
Es kann darauf hingewiesen werden, dass in dem Softwareverwaltungssystem 2300, die Edge-Vorrichtungen 2302 und Cloud-Vorrichtungen 2308 nicht nach Typ unterschieden werden, sondern lediglich nach Funktion. Dementsprechend können Arbeitslasten Edge-Vorrichtungen 2302, Cloud-Vorrichtungen 2308 oder beliebigen Kombinationen davon zugeordnet werden, durch das Distributed Services Framework 2000. Die Arbeitslasten oder Microservices können in jeder Anzahl von Mustern für die Implementierung auf den Systemen aggregiert werden.
24 ist eine schematische Abbildung eines Aggregator-Microservice-Entwurfsmusters 2400 in Übereinstimmung mit manchen Ausführungsformen. Das Aggregator-Microservice-Entwurfsmuster 2400 kann eine einfache Webseite als Aggregator 2402 verwenden, der mehrere Services 2404 aufruft, um die Funktionalität zu erzielen, die von der Anwendung erzielt wird. Da jeder Service 2404, A, B und C unter Verwendung eines leichten repräsentativen Statustransfer(REST)-Mechanismus exponiert werden kann, kann die Webseite die Daten zurückgewinnen und sie entsprechend verarbeiten oder anzeigen, beispielsweise auf einem Verwaltungsserver oder Steuerungsbildschirm für eine loT-Vorrichtung, unter anderem. Die Anzeige kann Benutzerinteraktionsoptionen umfassen, sofern dies von der Systemkonfiguration und den Richtlinien erlaubt ist. Ist eine Verarbeitung erforderlich, beispielsweise das Anwenden von Unternehmenslogik auf die Daten, die von den individuellen Services erhalten wurden, kann eine CDI-Bean verwendet werden, um die Daten umzuwandeln, sodass sie von der Webseite angezeigt werden können. Wie hierin verwendet ist eine CDI-Bean ein Java-Code-Segment, das unter Verwendung des Kontext- und Abhängigkeits-Einbringungs-Standards in JAVA paketiert wurde.
Ist keine Datenanzeige erwünscht und ist der Microserver ein Kompositum auf höherer Ebene, das von anderen Services konsumiert werden kann, kann der Aggregator 2402 die Daten von jedem der individuellen Microservices sammeln, Unternehmenslogik darauf anwenden und sie als REST-Endpunkt zu veröffentlichen. Die Daten können dann von anderen Services, die sie benötigen, konsumiert werden. Wenn multiple Service auf die Services 2404 zugreifen wollen, kann die Logik zu einem Kompositum-Microservice abstrahiert werden und dann in einen einzelnen Service aggregiert werden. Ein Vorteil der Abstrahierung auf dieser Ebene ist es, dass die einzelnen Services 2404 die Möglichkeit haben können, sich unabhängig weiterentwickeln zu dürften und die Aggregation wird von dem Kompositum-Microservice bereitgestellt.
Jeder der einzelnen Services 2404 kann auch seine eigene Zwischenspeicherung 2406 und Datenbank 2408 haben. Ist der Aggregator 2402 ein zusammengesetztes Microservice, kann er auch eine eigene Zwischenspeicherung und Datenbankschicht haben. Der Aggregator 2402 kann unabhängig skalieren, dementsprechend können zusätzliche Webserver aktiviert werden, wenn er eine Webseite ist.
25 ist eine schematische Abbildung eines Microservice-Gestaltungsmusters einer Programmverzweigung 2500 in Übereinstimmung mit manchen Ausführungsformen. In dem Microservice-Gestaltungsmuster einer Programmverzweigung 2500 ist die Aggregatorgestaltung erweitert, um eine simultane Antwortverarbeitung von zwei oder mehr Serviceketten 2504 zu erlauben. In dieser Anordnung kann der Aggregator oder Lastverteiler 2502 unterschiedliche Ketten oder eine einzelne Kette aufrufen, basierend auf den Unternehmensbedürfnissen. Darüber hinaus können Services wie z. B. A 2506 gleichzeitig unterschiedliche Ketten aufrufen, in diesem Fall kann dies dem Aggregator-Gestaltungsmuster ähneln. Alternativ dazu kann der Service A 2506 nur eine Kette aufrufen, basierend auf der Anfrage, die vom Client erhalten wird.
26 ist eine schematische Abbildung eines Proxy-Microservice-Gestaltungsmusters 2600 in Übereinstimmung mit manchen Ausführungsformen. Das Proxy-Microservice-Gestaltungsmuster 2600 kann als eine Variation des Aggregators betrachtete werden, der in Bezug auf 24 erläutert wurde. In diesem Beispiel muss keine Aggregation auf dem Client passieren, aber ein anderer Microservice kann basierend auf den Unternehmensbedürfnissen abgerufen werden. Wie der Aggregator kann der Proxy 2602 unabhängig skalieren. Dementsprechend kann jeder einzelne Service 2604 nicht dem Verbraucher offengelegt werden und kann stattdessen über Proxy 2602 laufen. Wie hierin angemerkt können die Daten von dem Proxy durch einen Proxyserver angezeigt werden, der beispielsweise keine Steuerungsfunktionen aufweist.
Proxy 2602 kann ein unintelligenter Proxy sein, da er die Anfrage an einen der Services 2604 überträgt. In anderen Beispielen kann es ein intelligenter Proxy sein, wobei einige Datenumwandlungen angewandt wurden, bevor die Antworten dem Client dienen. Ein Beispiel dafür würde auftreten, wenn die Präsentationsschicht für unterschiedliche Vorrichtung in dem intelligenten Proxy eingekapselt ist.
27 ist eine schematische Abbildung eines kombinierten Microservice-Gestaltungsmusters 2700 in Übereinstimmung mit manchen Ausführungsformen. Eine beliebige Kombination der Proxymuster kann verwendet werden. Beispielsweise kann ein erster Service 2702 einen zweiten Service 2704 aufrufen, der Serviceanfragen in eine Warteschlange 2706 platzieren kann. Andere Services 2708 können auf die Anfrage von der Warteschlange 2706 zugreifen und Ergebnisse zurück in die Warteschlange 2706 platzieren. In diesem Fall kann der zweite Service 2704 die Daten von der Warteschlange 2706 zurückgewinnen und sie entweder wieder dem anfänglichen Service 2702 oder einem Proxy 2710 bereitstellen.
28 ist eine schematische Abbildung eines verketteten Microservice-Gestaltungsmusters 2800 in Übereinstimmung mit manchen Ausführungsformen. Ein verkettetes Microservice-Gestaltungsmuster 2800 kann eine einzelne konsolidierte Antwort auf die Anfrage produzieren. In diesem Beispiel wird die Anfrage von dem Client von Service A 2802 erhalten, der dann mit Service B 2804 kommuniziert, der dann wiederum mit Service C 2806 kommuniziert. Beispielsweise können all die Services asynchrone HTTP-Anfrage-/Antwort-Nachrichtenübertragung verwenden.
Der Client kann von unmittelbaren Ergebnissen blockiert sein bis eine vollständige Kette von Anfrage/Antwort, beispielsweise Kommunikationen zwischen Service A 2802 und Service B 2804 und zwischen Service B 2804 und Service C 2806 vervollständigt ist. Die Anfrage von Service B 2804 an Service C 2806 kann völlig anders als die Anfrage von Service A 2802 an Service B 2804 aussehen. Ebenso kann die Antwort von Service B 2804 an Service A 2802 völlig anders als die Antwort von Service C 2806 an Service B 2804 aussehen.
Es kann zweckmäßig sein, die Servicekette kurz zu halten. Die synchrone Natur der Kette kann als lange clientseitige Wartezeit aufscheinen, insbesondere, wenn es eine Webseite ist, die darauf wartet, dass die Antwort angezeigt wird. Eine Kette mit einem einzelnen Microservice wird Singleton-Kette genannt. Dies kann erlauben, dass die Kette zu einem späteren Zeitpunkt erweitert wird.
29 ist eine schematische Abbildung eines Softwarestapel für einen Cloud Service Data Center Manager (CDSM) 2900 in Übereinstimmung mit manchen Ausführungsformen. Der CDSM 2900 kann einen feinkörnigen Überblick über Datencenteranlagen, Funktionalität und Kontext aufrechterhalten. Er kann verwendet werden, um die Infrastrukturreservierungsschemata und Platzierungsoptimierung zu verbessern. Der CDSM 2900 kann Abhängigkeiten im Kontext verstehen und stellt eine dynamische Servicelandschaft bereit. Er kann Echtzeit und Laufzeit als Kapazität bereitstellen, die verwendet wird, um Orchestrierungs- und Bereitstellungslösungen zu verbessern. Darüber hinaus kann der CSDM 2900 ein virtuelles Datencentermodell bereitstellen, das auf echten Anlagen für Servicemodellierung, Kundengewinnung, SLA und Auswertungen des Finanzverhaltens, unter anderem. Wie hierin verwendet können die Modellierungsergebnisse beispielsweise auf einer Steuerkonsole und loT-Anzeige oder durch einen Proxy-Server angezeigt werden, der keine Kontrollfunktionen aufweist. Die Anzeige kann Nutzerinteraktionsoptionen umfassen, sofern dies von der ausgewählten Systemkonfiguration und den Richtlinien erlaubt ist.
Um diese Aufgaben durchzuführen, kann der CSDM 2900 einige Kernfunktionen implementieren. Beispielsweise kann eine Datensammelfunktion 2902 Telemetrie und Metriken für die Plattform bereitstellen. Eine Analysefunktion 2904 kann Nutzen, Geschichte, Service, Reputation und Latenzzeitanalyse neben anderen Funktionen bereitstellen. Eine Reservierungsservicefunktion 2906 kann erlauben, dass Ressourcen evaluiert, gesichtet, reserviert, zur Verfügung gestellt oder freigegeben werden, unter anderem. Ein Informationskern 2908 kann eine feinkörnige Ressourcenanlagenliste beinhalten, die Anlagezustände, Abhängigkeiten, Fingerabdrücke und dergleichen umfasst. Eine Serviceebenen-Verwaltungsfunktion 2910 kann Ressourcen mit Serviceanforderungen in Bezug setzen. Eine Arbeitsablaufplatzierungs- und -optimierungsfunktion 2912 kann dann diese Informationen für Echtzeit-Arbeitsablaufplatzierung verwenden. Eine Metriknormalisierungs- und Datenbereinigungsfunktion 2914 kann verwendet werden, um regelmäßig die gesammelten Metriken zu bereinigen, beispielsweise indem Informationen nach einer vorausgewählten oder berechneten Zeitspanne entfernt werden oder indem Werte renormiert werden, wenn viel höhere oder viel niedrigere Werte erhalten werden. Die von dem CSDM 2900 gesammelten Informationen können verwendet werden, um ein Systemmodell 2916 zu erstellen. Das Systemmodell 2916 kann eine Bestimmung der Empfindlichkeit, des Stresses und des Verhaltens von Arbeitslastplatzierungen erlauben, indem die Arbeitslastplatzierungen unter Verwendung von Optimierungsalgorithmen modelliert werden.
30 ist ein Blockdiagramm von einem Beispiel für Komponenten, die in einer loT-Vorrichtung 3000 für die Teilnahme an dem DSF-/CSI-Netzwerk in Übereinstimmung mit manchen Ausführungsformen vorliegen können. Gleich nummerierte Elemente sind so, wie in Bezug auf die 16, 18, 20 und 21 beschrieben. Die loT-Vorrichtung 3000 kann beliebige Kombinationen der Komponenten umfassen, die in dem Beispiel gezeigt werden. Die Komponenten können als ICs implementiert werden, als Teile davon, diskrete elektronische Vorrichtungen oder andere Module, Logik, Hardware, Software, Firmware oder eine Kombination davon, adaptiert in der loT-Vorrichtung 3000 oder als anderweitig innerhalb eines Rahmens eines größeren Systems inkorporierte Elemente. Das Blockdiagramm von 30 ist dazu vorgesehen, eine Übersicht über Komponente der loT-Vorrichtung 3000 zu zeigen. Jedoch können manche der gezeigten Komponenten ausgelassen sein, zusätzliche Komponenten können vorliegen und eine unterschiedliche Anordnung der gezeigten Komponenten kann in anderen Implementierungen auftreten. Obwohl sie als eine loT-Vorrichtung 3000 gezeigt werden, kann angemerkt werden, dass eine beliebige Anzahl anderen Vorrichtungen an dem DSF-/CSI-Netzwerk teilnehmen kann, einschließlich, z. B., Datencentervorrichtungen, PC-Vorrichtungen, Tablets, Mobiltelefone, Gateways und vieler anderer.
Ferner kann die loT-Vorrichtung 3000 nicht all die Blöcke umfassen, die verwendet werden, um eine Anwendung zu orchestrieren. Beispielsweise kann die loT-Vorrichtung 3000 nur die Microservices umfassen, wie z. B. das unbewegliche Objekt 1820 oder das bewegliche Objekt 1822, die verwendet werden, um eine Anwendung oder einen Teil einer Anwendung zu implementieren. In anderen Beispielen kann die loT-Vorrichtung all die Werkzeuge umfassen, die verwendet werden, um Aufgaben für Anwendungen zu erstellen, einzusetzen und zu orchestrieren.
Die loT-Vorrichtung 3000 kann einen Prozessor 3002 umfassen, der ein Mikroprozessor, ein Mehrkernprozessor, ein Multithread-Prozessor, ein Ultra-Niederspannungsprozessor, ein eingebetteter Prozessor oder ein anderes bekanntes Prozessorelement sein kann. Der Prozessor 3002 kann ein Teil eines Ein-Chip-Systems (SoC) sein, in dem der Prozessor 3002 und andere Komponenten in ein einzige integrierte Schaltung oder ein einzelnes Paket, wie z. B. die Edison™ oder Galileo™-SoC-Platinen von Intel. Als ein Beispiel kann der Prozessor 3002 einen Intel^® Architecture Core™-basierten Prozessor, wie z. B. einen Quark™-, einen Atom™-, einen i3-, einen i5-, einen i7-, oder einen MCU-Klassen-Prozessor umfassen oder einen anderen solchen Prozessor, der bei der Intel^® Corporation, Santa Clara, CA erhältlich ist. Jedoch kann eine beliebige Anzahl anderer Prozessoren verwendet werden, wie z. B. erhältlich bei Advanced Micro Devices, Inc. (AMD) in Sunnyvale, CA, ein MIPS-basiertes Design von MIPS Technologies, Inc. in Sunnyvale, CA, ein ARM-basiertes Design, lizenziert von ARM Holdings, Ltd. oder eins seiner Kunden oder deren Lizenznehmer oder deren früher Anwender. Die Prozessoren können Einheiten wie z. B. einen A5-A9-Prozessor von Apple^® Inc., einen Snapdragon™-Prozessor von Qualcomm^®-Technologies, Inc., oder einen OMAP™-Prozessor von Texas Instruments, Inc. umfassen. Der Prozessor 3002 kann eine Grafikverarbeitungseinheit (GPU) oder ein Floating-Point-Gate-Array (FPGA) zusätzlich zu oder anstatt der hierin beschriebenen Prozessoren.
Der Prozessor 3002 kann mit einem Systemspeicher 3004 über einen Bus 3006 kommunizieren. Eine beliebige Anzahl von Speichervorrichtungen kann verwendet werden, um eine gegebene Menge Systemspeicher bereitzustellen. Beispielsweise kann der Speicher ein Direktzugriffsspeicher (RAM) in Übereinstimmung mit einer Joint Electron Devices Engineering Council (JEDEC)-Niedrigenergie-Doppeldatendate(LPDDR)-basiertes Design, wie z. B. der aktuelle LPDDR2-Standard gemäß JEDEC JESD 209-2E (veröffentlicht im April 2009) oder ein LPDDR-Standard der nächsten Generation, wie z. B. LPDDR3 oder LPDDR4, der Erweiterungen auf LPDDR2 bieten wird, um die Bandbreite zu steigern. In verschiedenen Implementierungen können die individuellen Speichervorrichtungen von einer beliebigen Anzahl unterschiedlicher Pakettypen sein, wie z. B. Single Die Package (SDP), Dual Die Package (DDP) oder Quad Die Package (Q17P). Diese Vorrichtungen können in manchen Ausführungsformen direkt auf ein Motherboard gelötet werden, um eine niedrigere Profillösung bereitzustellen, während in anderen Ausführungsformen die Vorrichtungen als ein oder mehrere Speichermodule konfiguriert sind, die wiederum über einen gegebenen Stecker an das Motherboard koppeln. Eine beliebige Anzahl anderer Speicherimplementierungen kann verwendet werden, wie z. B. als andere Typen von Speichermodulen, z. B. Dual Inline Memory Modules (DIMMs) unterschiedlicher Sorten, die microDIMMS oder MiniDIMMs einschließen, aber nicht darauf eingeschränkt sind. Beispielsweise kann ein Speicher zwischen 2GB und 16GB bemessen sein und kann als ein DDR3LM-Paket oder ein LPDDR2 oder LPDDR3-Speicher konfiguriert sein, der über eine Kugelgitteranordnung (BGA) an ein Motherboard angelötet ist.
Um eine anhaltende Speicherung von Informationen wie z. B. Daten, Anwendungen, Betriebssystemen und so weiter bereitzustellen kann ein Massenspeicher 3008 auch an den Prozessor 3002 über den Bus 3006 gekoppelt sein. Um ein schlankeres und leichteres Systemdesign zu ermöglichen, kann der Massenspeicher 3008 über ein Solid-State-Laufwerk (SSD) implementiert werden. Andere Vorrichtungen, die für den Massenspeicher 3008 verwendet werden können, umfassen Flash-Speicherkarten, wie z. B. SD-Karten, microSD-Karten, xD-Bildkarten und dergleichen und USB-Sticks.
In Niedrigenergieimplementierungen kann der Massenspeicher 3008 ein Speicher auf dem Chip sein oder Register, die mit dem Prozessor 3002 in Verbindung stehen. Jedoch kann in vielen Beispielen der Massenspeicher 3008 unter Verwendung eines Solid-State-Laufwerks (SSD) oder eines Festplattenlaufwerks (HDD) implementiert werden. Darüber hinaus kann eine beliebige Anzahl neuer Technologien für den Massenspeicher 3008 verwendet werden, zusätzlich zu oder anstatt von den beschriebenen Technologien, wie Widerstandsänderungsspeicher, Phasenänderungsspeicher, holographische Speicher oder chemische Speicher, unter anderem. Beispielsweise kann die IoT-Vorrichtung 3000 die 3D XPOINT-Speicher von Intel^® und Micron^® umfassen.
Die Komponenten können über den Bus 3006 kommunizieren. Der Bus 3006 kann eine beliebige Anzahl von Technologien umfassen, einschließlich Industriestandardarchitektur (ISA), erweiterte ISA (EISA); Peripheral Component Interconnect (PCI), Peripeheral Component Interconnect extendet (PCIx), PCI express (PCle) oder eine beliebige Anzahl von anderen Technologien. Der Bus 3006 kann ein proprietärer Bus sein, beispielsweise verwendet in einem SoC-basierten System. Andere Bussysteme können umfasst sein, wie z. B. eine I²C-Schnittstelle, I³C-Schnittstelle, eine SPI-Schnittstelle, Punkt-zu-Punkt-Schnittstellen und einen Energie-Bus, unter anderem.
Der Bus 3006 kann den Prozessor 3002 an einen Mesh-Sendeempfänger 3010 koppeln, für die Kommunikation mit anderen Mesh-Vorrichtungen 3012. Der Mesh-Sendeempfänger 3010 kann eine beliebige Anzahl an Frequenzen oder Protokollen verwenden, wie z. B. 2,4-Gigahertz(GHz)-Übertragungen unter dem IEEE 802.15.4 Standard, unter Verwendung des Bluetooth^®-Niedrigenergie(BLE)-Standards, wie definiert von der Bluetooth^® Special Interest Group oder dem ZigBee^®-Standard, unter anderem. Eine beliebige Anzahl an Funkvorrichtungen, konfiguriert für ein bestimmtes drahtloses Kommunikationsprotokoll kann für die Verbindungen mit den Mesh-Vorrichtungen 3012 verwendet werden. Beispielsweise kann eine WLAN-Einheit verwendet werden, um Wi-Fi™-Kommunikationen in Übereinstimmung mit dem Standard des Institute of Electrical and Electronics Engineers (IEEE) 802.11 zu implementieren. Zusätzlich dazu kann drahtlose Weitbereichskommunikation, z. B. gemäß einem zellularen oder anderen drahtlosen Weitbereichsprotokoll, über eine WWAN-Einheit auftreten.
Der Mesh-Sendeempfänger 3010 kann unter Verwendung mehrerer Standards oder Funkvorrichtungen auf verschiedenen Ebenen kommunizieren. Beispielsweise kann die loT-Vorrichtung 3000 mit geographisch naheliegenden Vorrichtungen, z. B. innerhalb von 10 Metern, kommunizieren, unter Verwendung eines lokalen Sendeempfängers, basierend auf BLE oder eines anderen Niedrigenergiefunkvorrichtungen, um Energie zu sparen. Weiter entfernte Mesh-Vorrichtungen 3012, z. B. innerhalb von 50 Metern, können über ZigBee oder andere Zwischenleistungsfunkvorrichtungen erreicht werden. Beide Kommunikationstechniken können über eine einzelne Funkvorrichtung auf unterschiedlichen Energieebenen stattfinden oder sie können über separate Sendeempfänger stattfinden, beispielsweise ein lokaler Sendeempfänger unter Verwendung von BLE und ein separater Mesh-Sendeempfänger unter Verwendung von ZigBee. Der Mesh-Sendeempfänger 3010 kann in ein MCU inkorporiert werden als eine Adresse, auf die direkt von dem Chip zugegriffen werden kann, wie z. B.in den Curie^®-Einheiten, die bei Intel erhältlich sind.
Ein Uplink-Sendeempfänger 3014 kann umfasst sein, um mit Vorrichtungen in der Cloud 102 zu kommunizieren. Der Uplink-Sendeempfänger 3014 kann ein LPWA-Sendeempfänger sein, der den IEEE 802.15.4-, IEEE 802.15.4g-, IEEE 802.15.4e-, IEEE 802.15.4k-, oder NB-loT-Standards unter anderem folgt. Die loT-Vorrichtung 3000 kann über einen weiten Bereich mit LoRaWAN™ (Long Range Wide Area Network), entwickelt von Semtech und der LoRa Alliance, kommunizieren. Die hierin beschriebenen Techniken sind nicht auf diese Technologien eingeschränkt, aber sie können mit einer beliebigen Anzahl von Cloud-Sendeempfängern verwendet werden, die Fern-Niedrigbandbreitenkommunikation, wie z. B. Sigfox und andere Technologien, verwendet werden. Ferner können andere Kommunikationstechniken, wie z. B. Kanal-Hopping in einem Zeitschlitzsystem, beschrieben in der IEEE 802.15.4e-Spezifikation, verwendet werden.
Eine beliebige Anzahl von anderen Funkvorrichtungskommunikationen und Protokollen kann zusätzlich zu den Systemen verwendet werden, die in Bezug auf den Mesh-Sendeempfänger 3010 und den Uplink-Sendeempfänger 3014 erwähnt wurden, wie hierin beschrieben. Beispielsweise können die Funkvorrichtungs-Sendeempfänger 3010 und 3012 einen LTE oder einen anderen zellularen Sendeempfänger umfassen, der Spreizspektrum(SPA/SAS)-Kommunikation für die Implementierung von Hochgeschwindigkeitskommunikation, wie z. B. für Videoübertragungen verwendet. Ferner kann eine beliebige Anzahl anderer Protokolle verwendet werden, wie z. B. Wi-Fi^®-Netzwerke für Kommunikation mit mittlerer Geschwindigkeit, wie z. B. Standbilder, Sensorauslesungen und Bereitstellung von Netzwerkkommunikation.
Die Funkvorrichtungs-Sendeempfänger 3010 und 3012 können Funkvorrichtungen umfassen, die mit einer beliebigen Anzahl von 3GPP (Third Generation Partnership Project)-Dokumenten, nämlich Long Term Evolution (LTE), Long Term Evolution-Advanced (LTE-A), Long Term Evolution-Advanced Pro (LTE-A Pro), oder Narrow Band loT (NB-loT), unter anderem. Es kann angemerkt werden, dass Funkvorrichtungen, die mit einer beliebigen Anzahl von anderen fixen, mobilen oder Satellitkommunikationstechnologien und -Standards kompatibel sind, ausgewählt werden können. Dies kann beispielsweise eine beliebige Mobilfunk-Weitbereichsfunktechnik umfassen, die z. B. ein Kommunikationssystem 5. Generation (5G), ein Globales System für Mobilkommunikation(GSM)-Funkkommunikationstechnologie, eine General Packet Radio Service (GPRS)-Funkkommunikationstechnologie oder eine Enhanced Data Rates for GSM Evolution (EDGE)-Funkkommunikationstechnologie umfassen kann. Andere Third Generation Partnership Project (3GPP)-Funkkommunikationstechnologien die verwendet werden können, umfassen UMTS (Universal Mobile Telecommunications System), FOMA (Freedom of Multimedia Access), 3GPP LTE (Long Term Evolution), 3GPP LTE Advanced (Long Term Evolution Advanced), 3GPP LTE Advanced Pro (Long Term Evolution Advanced Pro)), CDMA2000 (Code division multiple access 2000), CDPD (Cellular Digital Packet Data), Mobitex, 3G (Third Generation), CSD (Circuit Switched Data), HSCSD (High-Speed Circuit-Switched Data), UMTS (3G) (Universal Mobile Telecommunications System (Third Generation)), W-CDMA (UMTS) (Wideband Code Division Multiple Access (Universal Mobile Telecommunications System)), HSPA (High-speed Packet Access), HSDPA (High-Speed Downlink Packet Access), HSUPA (High-Speed Uplink Packet Access), HSPA+ (High-speed Packet Access Plus), UMTS-TDD (Universal Mobile Telecommunications System - Time-Division Duplex), TD-CDMA (Time Division - Code Division Multiple Access), TD-SCDMA (Time Division - Synchronous Code Division Multiple Access), 3GPP Rel. 8 (Pre-4G) (3rd Generation Partnership Project Release 8 (Pre-4th Generation)), 3GPP Rel. 9 (3rd Generation Partnership Project Release 9), 3GPP Rel. 10 (3rd Generation Partnership Project Release 10), 3GPP Rel. 11 (3rd Generation Partnership Project Release 11), 3GPP Rel. 12 (3rd Generation Partnership Project Release 12), 3GPP Rel. 13 (3rd Generation Partnership Project Release 13), 3GPP Rel. 14 (3rd Generation Partnership Project Release 14), 3GPP LTE Extra, LTE Licensed-Assisted Access (LAA), UTRA (UMTS Terrestrial Radio Access), E-UTRA (Evolved UMTS Terrestrial Radio Access), LTE Advanced (4G) (Long Term Evolution Advanced (4th Generation)), cdmaOne (2G), CDMA2000 (3G) (Code division multiple access 2000 (Third generation)), EV-DO (Evolution-Data Optimized or Evolution-Data Only), AMPS (1G) (Advanced Mobile Phone System (1st Generation)), TACS/ETACS (Total Access Communication System/Extended Total Access Communication System), D-AMPS (2G) (Digital AMPS (2nd Generation)), PTT (Push-to-talk), MTS (Mobile Telephone System), IMTS (Improved Mobile Telephone System), AMTS (Advanced Mobile Telephone System), OLT (Norwegisch: Offentlig Landmobil Telefoni, öffentliche Landmobiltelefonie), MTD (Schwedische Abkürzung für Mobiltelefonisystem D, oder Mobiltelefoniesystem D), Autotel/PALM (Public Automated Land Mobile), ARP (Finnisch: Autoradiopuhelin, „Autofunktelefon“), NMT (Nordic Mobile Telephony), Hicap (High capacity version of NTT (Nippon Telegraph and Telephone)), CDPD (Cellular Digital Packet Data), Mobitex, DataTAC, iDEN (Integrated Digital Enhanced Network), PDC (Personal Digital Cellular), CSD (Circuit Switched Data), PHS (Personal Handy-phone System), WiDEN (Wideband Integrated Digital Enhanced Network), iBurst, Unlicensed Mobile Access (UMA, auch bezeichnet als 3GPP Generic Access Network, oder GAN-Standard)), Wireless Gigabit Alliance (WiGig)-Standard, mmWave-Standards im Allgemeinen (drahtlose Systeme, die bei 10-90 GHz und darüber laufen, wie z. B. WiGig, IEEE 802.11ad, IEEE 802.11ay, und dergleichen. Zusätzlich zu den zuvor aufgelisteten Standards kann eine beliebige Anzahl an Satellit-Uplink-Technologien für den Uplink-Sendeempfänger 3014 verwendet werden, einschließlich, beispielsweise, Funkvorrichtungen, die mit Standards übereinstimmen, die von der ITU (International Telecommunication Union), oder dem ETSI (European Telecommunications Standards Institute), unter anderem, herausgegeben wurden. Die hierin bereitgestellten Beispiele gelten daher als anwendbar auf verschiedene andere Kommunikationstechnologien, die entweder schon existieren oder noch nicht formuliert wurden.
Der Mesh-Sendeempfänger 3010 und der Uplink-Sendeempfänger 3014 kann ein Teil einer einzelnen Funkvorrichtungseinheit sein, der beide Arten von Kommunikation bereitstellt. Ferner kann einer oder beide Sendeempfänger 3010 oder 3012, in Abhängigkeit von der Umgebung, in die die loT-Vorrichtung 3000 implementiert ist, eliminiert werden. Beispielsweise kann die loT-Vorrichtung alle Kommunikationen mit anderen Einheiten in einem Mesh 3012 oder einer Cloud 102 durch eine drahtgebundene Verbindung durchführen, die von einer Netzwerkschnittstellensteuerung (NIC) 3016 bereitgestellt wird.
Die NIC 3016 kann umfasst sein, um eine drahtgebundene Kommunikation mit der Cloud 102 oder mit anderen Vorrichtungen bereitzustellen, wie z. B. den Mesh-Vorrichtungen 3012. Die drahtgebundene Kommunikation kann eine Ethernet-Verbindung bereitstellen oder kann basierend auf anderen Arten von Netzwerken basieren, wie z. B. Controller Area Network (CAN), Local Interconnect Network (LIN), DeviceNet, ControlNet, Data Highway+, PROFIBUS, oder PROFINET und vielen anderen. Eine zusätzliche NIC kann umfasst sein, um die Verbindung mit einem zweiten Netzwerk zu erlauben, beispielsweise stellt eine NIC 3016 die Kommunikation mit der Cloud über Ethernet bereit und eine zweite NIC stellt die Kommunikation mit anderen Vorrichtungen über eine andere Art von Netzwerk bereit.
Der Bus 3006 kann den Prozessor 3002 an die Schnittstell 3018 koppeln, die verwendet wird, um externe Vorrichtungen zu verbinden. Die externen Vorrichtungen können Sensoren 3020 umfassen, wie z. B. Beschleunigungssensoren, Niveausensoren, Strömungssensoren, Temperatursensoren, Drucksensoren, barometrische Drucksensoren und dergleichen. Die Schnittstelle 3018 kann verwendet werden, um die loT-Vorrichtung 3000 mit den Aktuatoren 3022 zu verbinden, wie z. B. mit Netzschaltern, Ventilaktuatoren, einem akustischen Klangerzeuger, einer optischen Warnvorrichtung und dergleichen.
Eine Batterie 3024 kann die loT-Vorrichtung 3000 mit Energie versorgen, obwohl in den Beispielen, in denen die loT-Vorrichtung 3000 an einer fixen Position angebracht ist, sie eine Leistungsversorgung haben kann, die an ein Stromnetz gekoppelt ist. Die Batterie 3024 kann eine Lithiumionenbatterie, eine Metall-Luft-Batterie, wie z. B. eine Zink-Luft-Batterie, eine Aluminium-Luft-Batterie, eine Lithium-Luft-Batterie, ein hybrider Superkondensator und dergleichen sein.
Ein Batteriemonitor/Ladegerät 3026 kann in die loT-Vorrichtung 3000 inkludiert sein, um den Ladezustand (SoCh) der Batterie 3020 zu verfolgen. Der Batteriemonitor/Ladegerät 3026 kann verwendet werden, um andere Parameter der Batterie 3024 zu überwachen, um Fehlerprognosen bereitzustellen, wie z. B. den Gesundheitszustand (SoH) und den Funktionszustand (SoF) der Batterie 3024. Der Batteriemonitor/Ladegerät 3026 kann eine batterieüberwachende integrierte Schaltung umfassen, wie z. B. eine LTC4020 oder eine LTC2990 von Linear Technologies, eine ADT7488A von ON Semiconductor in Phoenix Arizona, oder eine IC von der UCD90xxx-Familie von Texas Instruments in Dallas, TX. Der Batteriemonitor/Ladegerät 3026 kann die Informationen über die Batterie 3024 an den Prozessor 3002 über den Bus 3006 kommunizieren. Der Batteriemonitor/Ladegerät 3026 kann auch einen Analog-Digital- (ADC-) Wandler umfassen, der dem Prozessor 3002 erlaubt, die Spannung der Batterie 3026 oder den Stromfluss von der Batterie 3024 direkt zu überwachen. Die Batterieparameter können verwendet werden, um Aktionen zu bestimmen, die die loT-Vorrichtung 3000 durchführen kann, wie z. B. Übertragungsfrequenz, Mesh-Netzwerkbetrieb, Messfrequenz und dergleichen.
Ein Leistungsblock 3028 oder eine andere Leistungsversorgung, die an ein Netz gekoppelt ist, kann mit dem Batteriemonitor/Ladegerät 3026 gekoppelt sein, um die Batterie 3024 zu laden. In manchen Beispielen kann der Leistungsblock 3028 durch einen drahtlosen Leistungsempfänger ersetzt sein, um die Leistung drahtlos zu erhalten, beispielsweise durch eine Rahmenantenne in der loT-Vorrichtung 3000. Eine drahtlose Batterieladeschaltung, wie z. B. ein LTC4020-Chip von Linear Technologies in Milpitas, CA kann unter anderem in dem Batteriemonitor/Ladegerät 3026 umfasst sein. Die spezifischen ausgewählten Ladeschaltungen hängen von der Größe der Batterie 3024 und daher von der erforderlichen Leistung ab. Das Laden kann unter anderem unter Verwendung des Airfuel-Standard, der von der Airfuel Alliance verkündet wurde, dem drahtlosen Qi-Ladestandard, der von dem Wireless Power Consortium verkündet wurde oder dem Rezence-Lade-Standard, der von der Alliance for Wireless Power verkündet wurde, durchgeführt werden. In manchen Beispielen kann der Leistungsblock 3028 durch Solarpanele, einen Wassergenerator oder andere Naturenergiesysteme vergrößert oder ersetzt werden.
Unterschiedliche Eingabe-/Ausgabe(I/O)-Vorrichtungen können in der IoT-Vorrichtung 3000 vorliegen oder damit verbunden sein. Beispielsweise kann ein Anzeigetreiber 3030 mit dem Prozessor 3002 über den Bus 3006 gekoppelt sein. Der Anzeigetreiber 3030 kann eine Anzeige mit Energie versorgen, beispielsweise als Teil einer Anzeige/Touchscreen 3032. Eine menschliche Maschinenschnittstelle 3034 kann an den Touchscreenteil der Anzeige/Touchscreen 3032 verbunden sein, um Eingaben zu erhalten.
Eine beliebige Anzahl an anderen Anzeigevorrichtungen kann verwendet werden, einschließlich Bildschirmen, Flachbildschirmen, LEDs, CRTs und dergleichen. Ebenso kann eine beliebige Anzahl anderer Eingabevorrichtungen einschließlich Tastaturen, Mäusen, Steuerkugeln und dergleichen verwendet werden. Die Anzeige kann umfasst sein, um Informationen anzuzeigen, wie z. B. Sensorauslesungen, Aktuatorpositionen, Konfigurationen und Fehlerbehebungsdaten und dergleichen. Die Eingabevorrichtungen können die Eingabe von Sollwerten, Konfigurationsinformationen und anderen Informationen erlauben, die für den Einsatz zweckmäßig sind. Ferner können Daten auf Vorrichtungen oder Systemen angezeigt werden, die kein Teil des Systemnetzwerks oder des vertrauenswürdigen Netzwerks sind. Daten jeglicher Art können auf der loT-Anzeige, Verwaltungsanzeigen, die mit dem loT-System verbunden sind oder anderen Anzeigen angezeigt werden, nachdem die entsprechenden Anmeldedaten eingegeben wurden. Diese können beispielsweise Benutzerdaten, Systembetreiberdaten, Zwischendaten, gespeicherte Daten und dergleichen umfassen. Eine Anzeige der Daten, um den Einsatz oder die Benutzerinteraktion zu fördern, um eine Dateneingabe zu verifizieren oder zu bestätigen kann bereitgestellt sein.
Der Massenspeicher 3008 kann eine Anzahl von Modulen umfassen, um die hierin beschriebenen Gruppenerstellungsfunktionen zu implementieren. Obwohl sie als Codeblocks in dem Massenspeicher 3008 gezeigt werden, ist zu verstehen, dass ein beliebiges der Module vollständig oder teilweise durch festverdrahtete Schaltungen ersetzt werden kann, die in eine anwendungsspezifische integrierte Schaltung (ASIC) eingebaut sind. Der Massenspeicher 3008 kann einen Orchestrierungsmanager 1608 umfassen, einen Servicemanager (CDSM) 1610 und einen Arbeitslastmanager 1612, um die Arbeitslasten wie hierin beschrieben zu platzieren. Ein unbewegliches Objekt 1820, ein bewegliches Objekt 1822 oder beides kann umfasst sein, um Teile von Anwendungen wie hierin beschrieben zu implementieren. Ein vertrauenswürdiger Datenbus 2002 und eine Microservice-Steuerung 2026 können umfasst sein, um auf ein DSF-Freizeichen zuzugreifen und um Services zu erhalten. Eine verteilte Service-Schnittstelle (DSI) 2106 und eine gemeinsame Service-Schnittstelle (CSI) 2108 können umfasst sein, um loT-Netzwerken beizutreten.
31 ist ein Blockdiagramm eines beispielhaften, nichttransitorischen maschinenlesbaren Mediums 3100, einschließlich eines Codes, der an Prozessor 3102 geleitet wird, um die Arbeitslasten gemäß einigen Ausführungsformen zu platzieren. Der Prozessor 3102 kann auf das nichttransitorische maschinenlesbare Medium 3100 über einen Bus 3104 zugreifen. Der Prozessor 3102 und Bus 3104 kann ausgewählt werden, wie in Bezug auf den Prozessor 3002 du den Bus 3006 aus 30 beschrieben. Das nichttransitorische maschinenlesbare Medium 3100 kann Vorrichtungen für den Massenspeicher 3008 von 30 umfassen oder kann optische Laufwerke, USB-Sticks oder eine beliebige Anzahl anderer Hardwarevorrichtungen umfassen.
Wie hierin beschrieben kann das nichttransitorische, maschinenlesbare Medium 3100 Code 3106 umfassen, um den Prozessor 3102 zu steuern, um Servicevorlagen von einem DSF zu erhalten. Code 3108 kann umfasst sein, um den Prozessor 3102 zu steuern, um einen Arbeitsablauf zu analysieren, um Services zu bestimmen. Code 3110 kann umfasst sein, um den Prozessor 3102 zu steuern, um Anwendungen, Arbeitsabläufe und KPIs zu zerlegen.
Das maschinenlesbare Medium 3100 kann Code 3112 umfassen, um den Prozessor 3102 zu steuern, um Anwendungen zu analysieren, um die Anwendungspassung in physischen Systemen zu bestimmen. Code 3114 kann umfasst sein, um den Prozessor 3102 zu steuern, um die Anwendungspositionen zu bestimmen. Code 3116 kann umfasst sein, um den Prozessor 3102 zu steuern, um die Anwendungsfunktionalität in Bezug auf SLAs zu messen. Code 3118 kann umfasst sein, um den Prozessor 3102 zu steuern, um eine Arbeitslast zu bewegen, beispielsweise um SLA zu verbessern.
Beispiele
Beispiel 1 umfasst ein Rechnersystem, das eine Internet-der-Dinge(loT)-Vorrichtung umfasst, die eine gemeinsame Serviceschnittstelle (CSI) umfasst, um ein selbstverwaltendes Netzwerk aus Vorrichtungen mit anderen Knoten einschließlich der CSI bildet.
Beispiel 2 umfasst den Gegenstand von Beispiel 1. In diesem Beispiel schließt die CSI an eine andere Vorrichtung an und stellt eine Beschreibung der loT-Vorrichtung und eine Funktionalität der loT-Vorrichtung bereit, und ist dazu da, von der anderen Vorrichtung eine Beschreibung der anderen Vorrichtung und eine Funktionalität der anderen Vorrichtung zu erhalten.
Beispiel 3 umfasst den Gegenstand von entweder Beispiel 1 oder 2. In diesem Beispiel ist die CSI dazu da, an eine andere Vorrichtung durch eine Anwendungsprogrammierschnittstelle (API) anzuschließen.
Beispiel 4 umfasst den Gegenstand eines beliebigen der Beispiele 1 bis 3. In diesem Beispiel ist die CSI dazu da, an eine andere Vorrichtung durch ein Data Distribution Service (DDS) anzuschließen.
Beispiel 5 umfasst den Gegenstand eines beliebigen der Beispiele 1 bis 4. In diesem Beispiel kann ein DDS in der CSI ein Publish/Subscribe- (Pub/Sub)-Subskriptionsmodell umfassen.
Beispiel 6 umfasst den Gegenstand eines beliebigen der Beispiele 1 bis 5. In diesem Beispiel umfasst die CSI eine virtuelle Schnittstelle um über ein Netzwerk zu kommunizieren.
Beispiel 7 umfasst den Gegenstand eines beliebigen der Beispiele 1 bis 6. In diesem Beispiel umfasst die CSI ein Kommunikationsprotokoll.
Beispiel 8 umfasst den Gegenstand eines beliebigen der Beispiele 1 bis 7. In diesem Beispiel umfasst die CSI einen Internetprotokoll(IP)-Block, der ein Serviceprotokoll umfasst, um eine Systemintegration und aktive Serviceverwaltung bereitzustellen.
Beispiel 9 umfasst den Gegenstand eines beliebigen der Beispiele 1 bis 8. In diesem Beispiel umfasst die CSI ein Peering-System zum Eingliedern neuer Vorrichtungen.
Beispiel 10 umfasst den Gegenstand eines beliebigen der Beispiele 1 bis 9. In diesem Beispiel umfasst die loT-Vorrichtung einen Arbeitslastmanager, um eine Servicevorlage zu erhalten, um die Servicevorlage zu zerlegen und um die Anforderungen für die Arbeitslast und QoS und SLA zu bestimmen. Die IoT-Vorrichtung umfasst einen Servicemanager, um Statusinformationen von einer Anzahl von Infrastrukturvorrichtungen zu erhalten und einen Orchestrierungsmanager, um die Anforderungen von dem Arbeitslastmanager und die Statusinformationen von dem Servicemanager zu erhalten und um einer Infrastrukturvorrichtung einen Service zuzuweisen.
Beispiel 11 umfasst den Gegenstand von einem beliebigen der Beispiele 1 bis 10. In diesem Beispiel umfasst die loT-Vorrichtung eine Distributed-Service-Schnittstelle (DSI), um Microservices von einem Distributed Services Framework (DSF) zu erhalten.
Beispiel 12 umfasst den Gegenstand eines beliebigen der Beispiele 1 bis 11. In diesem Beispiel ist ein Distributed Services Framework (DSF) dazu da, ein loT-Freizeichen bereitzustellen, um die loT-Vorrichtung an einen Microservice-Anbieter bereitzustellen.
Beispiel 13 umfasst den Gegenstand eines beliebigen der Beispiele 1 bis 12. In diesem Beispiel ist ein loT-Freizeichen von einem Distributed Services Framework (DSF) dazu da, eine Richtlinie in einem Verpflichtungsparadigma für den Beitritt in ein DSF-Verwaltungsnetzwerk bereitzustellen.
Beispiel 14 umfasst den Gegenstand eines beliebigen der Beispiele 1 bis 13. In diesem Beispiel umfasst ein Distributed Services Framework (DSF) einen Servicekatalog, der Servicevorlagen umfasst.
Beispiel 15 umfasst den Gegenstand eines beliebigen der Beispiele 1 bis 15. In diesem Beispiel umfasst die loT-Vorrichtung einen Multi-Distributed Services Framework(DSF)-Vermittler, um mehrere DSF-Sitzungen zu verbinden.
Beispiel 16 umfasst ein Verfahren zur Orchestrierung des Einsatzes von Anwendungen auf eine Internet-der-Dinge(loT)-Vorrichtung. Das Verfahren umfasst das Überprüfen eines loT-Freizeichens auf einem Distributed Services Framework (DSF), wobei das loT-Freizeichen Richtlinien und Verpflichtungsparadigmen für den Beitritt zu einem DSF-Verwaltungsnetzwerk bereitstellt.
Beispiel 17 umfasst den Gegenstand von Beispiel 16. In diesem Beispiel umfasst das Verfahren das Senden einer Serviceanfrage an einen Servicekatalog, der Microservices auflistet und das Empfangen einer Servicevorlage aus dem Servicekatalog.
Beispiel 18 umfasst den Gegenstand von entweder Beispiel 16 oder 17. In diesem Beispiel umfasst das Verfahren die Analyse der Infrastrukturfunktionalität. die Verfügbarkeit und den Status, um eine Infrastrukturabbildung zu erstellen.
Beispiel 19 umfasst den Gegenstand eines beliebigen der Beispiele 16 bis 18. In diesem Beispiel umfasst das Verfahren das Zerlegen einer Servicevorlage, um die Arbeitslastelemente zu zerlegen und um die Arbeitslastelemente auf Infrastrukturelemente in einer Infrastrukturabbildung abzubilden.
Beispiel 20 umfasst den Gegenstand eines beliebigen der Beispiele 16 bis 19. In diesem Beispiel umfasst das Verfahren das Zuweisen von Arbeitslastelementen an Infrastrukturelemente und das Sammeln von Servicequalitätsmetriken zum Betrieb der Arbeitslastelemente.
Beispiel 21 umfasst den Gegenstand eines beliebigen der Beispiele 16 bis 20. In diesem Beispiel umfasst das Verfahren das erneute Zuordnen von Arbeitslastelementen an unterschiedliche Infrastrukturelemente, wenn ein Versagen eine SLA zu erfüllen bestimmt wird.
Beispiel 22 umfasst den Gegenstand eines beliebigen der Beispiele 16 bis 21. In diesem Beispiel umfasst das Verfahren das Senden einer Serviceanfrage an einen Servicekatalog. Ein Unternehmensservice wird von dem Servicekatalog erhalten. Der Unternehmensservice wird analysiert, um den Arbeitsablauf zu bestimmen. Der Arbeitsablauf wird zerlegt, um Microservices und KPIs zu definieren. Die Microservices und KPIs werden analysiert, um eine Position in einer physischen Infrastruktur für die Zuweisung zu bestimmen. Die Microservices werden zu Infrastrukturelementen zugeordnet.
Beispiel 23 umfasst ein nichttransitorisches maschinenlesbares Medium, das einen Code umfasst, der bei seiner Ausführung einen Prozessor dazu anweist, eine Servicevorlage von einem Servicekatalog in einem Distributed Services Framework zu erhalten und den Arbeitsablauf der Servicevorlage zu analysieren, um Anwendungen, Arbeitsabläufe und zentrale Leistungsindikatoren zu bestimmen. Der Code ist umfasst, um den Prozessor zu steuern, um die Anwendung, die Arbeitsabläufe und zentrale Leistungsindikatoren zu analysieren, um Zuweisungspositionen zu bestimmen und um Anwendungspositionen zu Infrastrukturelementen zuzuweisen.
Beispiel 24 umfasst den Gegenstand von Beispiel 23. In diesem Beispiel umfasst das nichttransitorische maschinenlesbare Medium Code der bei seiner Ausführung den Prozessor anweist, den Betrieb der Anwendungen, Arbeitsabläufe und zentrale Leistungsindikatoren zu messen, um festzustellen, ob der Betrieb die Vereinbarung auf Serviceebene erfüllt.
Beispiel 25 umfasst den Gegenstand von entweder Beispiel 23 oder 24. In diesem Beispiel umfasst das nichttransitorische maschinenlesbare Medium Code, der, wenn er ausgeführt wird, den Prozessor steuert, um eine Anwendung, einen Arbeitsablauf oder einen zentrale Leistungsindikator zu bewegen, wenn eine Vereinbarung auf Serviceebene nicht erfüllt wird.
Beispiel 26 umfasst den Gegenstand eines beliebigen der Beispiele 23 bis 25. In diesem Beispiel umfasst das nichttransitorische maschinenlesbare Medium Code, der, wenn er ausgeführt wird, den Prozessor dazu lenkt, einen Microservice zu erhalten, um eine Aufgabe abzuschließen.
Beispiel 27 umfasst ein nichttransitorisches maschinenlesbares Medium einschließlich Anweisungen, um einen Prozessor in einem Knoten dazu zu lenken, eines der Verfahren der Ansprüche 16 bis 22 durchzuführen.
Beispiel 28 umfasst ein Gerät. das Mittel umfasst, um eines der Verfahren aus Anspruch 16 bis 22 durchzuführen.
Beispiel 29 umfasst ein Rechnersystem, das eine Internet-der-Dinge(loT)-Vorrichtung umfasst, das eine gemeinsame Serviceschnittstelle (CSI) umfasst, die Mittel umfasst, um ein selbstverwaltendes Netzwerk aus Vorrichtungen mit anderen Knoten einschließlich CSI herzustellen.
Beispiel 30 umfasst den Gegenstand von Beispiel 29. In diesem Beispiel dient die CSI dazu, eine Schnittstelle mit einer anderen Vorrichtung zu bilden und eine Beschreibung der loT-Vorrichtung und eine Funktionalität der loT-Vorrichtung bereitzustellen, wobei die CSI Mittel umfasst, um von einer anderen Vorrichtung eine Beschreibung der anderen Vorrichtung und eine Funktionalität der anderen Vorrichtung zu erhalten.
Beispiel 31 umfasst den Gegenstand eines der Beispiele 29 oder 30. In diesem Beispiel umfasst die CSI Mittel zur Schnittstellenbildung mit einer anderen Vorrichtung durch eine Programmierschnittstelle (API).
Beispiel 32 umfasst den Gegenstand eines beliebigen der Beispiele 29 bis 31. In diesem Beispiel umfasst die CSI Mittel zur Schnittstellenbildung mit einer anderen Vorrichtung durch ein Data Distribution Service (DDS).
Beispiel 33 umfasst den Gegenstand eines beliebigen der Beispiele 29 bis 32. In diesem Beispiel umfasst die CSI Mittel zum Eingliedern neuer Vorrichtungen.
Beispiel 34 umfasst den Gegenstand eines beliebigen der Beispiele 29 bis 33. In diesem Beispiel umfasst die loT-Vorrichtung einen Arbeitslastmanager, um eine Servicevorlage zu erhalten, die Servicevorlage zu zerlegen und die Anforderungen für die Arbeitslast und QoS und SLA zu bestimmen. Ein Servicemanager dient dazu, Statusinformationen von einer Anzahl von Infrastrukturvorrichtungen zu erhalten. Die loT-Vorrichtung umfasst Mittel, um die Anforderungen von dem Arbeitslastmanager und die Statusinformationen vom Servicemanager zu korrelieren und einer Infrastrukturvorrichtung ein Service zuzuordnen.
Beispiel 35 umfasst den Gegenstand eines beliebigen der Beispiele 29 bis 34. In diesem Beispiel umfasst die loT-Vorrichtung eine Distributed-Service-Schnittstelle (DSI), die Mittel zum Erhalten von Microservices von einem Distributed Services Framework (DSF) umfasst.
Beispiel 36 umfasst den Gegenstand eines beliebigen der Beispiele 29 bis 36. In diesem Beispiel umfasst ein Distributed Services Framework (DSF) Mittel zum Bereitstellen eines loT-Freizeichens, um die loT-Vorrichtung mit einem Microservice-Anbieter zu verbinden. Manche Ausführungsformen können in einer oder einer Kombination von Hardware, Firmware und Software implementiert werden. Manche Ausführungsformen können auch als Anweisungen implementiert werden, die auf einem maschinenlesbaren Medium gespeichert sind, die von einer Rechenplattform gelesen und ausgeführt werden, um die hierin beschriebenen Operationen durchzuführen. Ein maschinenlesbares Medium kann einen beliebigen Mechanismus zum Speichern oder Übertragen von Informationen in einer Form umfassen, die von einer Maschine, z. B. einem Rechner, lesbar ist. Beispielsweise kann ein maschinenlesbares Medium Festwertspeicher (ROM), Direktzugriffsspeicher (RAM); Magnetplattenspeichermedien; optische Speichermedien; Flash-SpeicherVorrichtungen; oder elektrische, optische, akustische oder andere Formen von sich ausbreitenden Signalen, z.B. Trägerwellen, Infrarotsignale, digitale Signale oder die Schnittstellen, die unter anderem Signale senden und/oder empfangen, umfassen.
Eine Ausführungsform ist eine Implementierung oder ein Beispiel. Bezugnahmen in der Beschreibung auf „eine Ausführungsform“, „manche Ausführungsformen“, „verschiedene Ausführungsformen“ oder „andere Ausführungsformen“ bedeuten, dass ein besonderes Merkmal, eine Struktur oder ein Kennzeichen, das in Verbindung mit den Ausführungsformen beschrieben wird, in zumindest manchen Ausführungsformen umfasst ist, aber nicht notwendigerweise in allen Ausführungsformen der Techniken. Die verschiedenen Erscheinungsbilder „einer Ausführungsform“ oder „mancher Ausführungsformen“ beziehen sich nicht notwendigerweise auf dieselben Ausführungsformen. Elemente oder Aspekte einer Ausführungsform können mit Elementen oder Aspekten einer anderen Ausführungsform kombiniert werden.
Nicht alle hierin beschriebenen und veranschaulichten Komponenten, Eigenschaften, Strukturen, Kennzeichen etc. müssen in einer bestimmten Ausführungsform oder in bestimmten Ausführungsformen umfasst sein. Gibt die Beschreibung an, dass eine Komponente, Eigenschaft, Struktur oder Charakteristik umfasst sein „kann“ oder „könnte“, beispielsweise, dass eine bestimmte Komponente, Eigenschaft, Struktur oder Kennzeichen nicht erforderlicherweise umfasst ist. Bezieht sich die Beschreibung oder der Anspruch auf „ein“ Element, bedeutet das nicht, dass nur ein solches Element vorliegt. Bezieht sich die Beschreibung oder der Anspruch auf „ein zusätzliches“ Element, schließt dies nicht aus, dass es mehr als dieses eine zusätzliche Element gibt.
Es ist anzumerken, dass obwohl manche Ausführungsformen in Bezug auf bestimmte Implementierungen beschrieben wurden, andere Implementierungen gemäß manchen Ausführungsformen möglich sind. Zusätzlich dazu muss die Anordnung und/oder Ordnung von Schaltungselementen oder anderen in den Zeichnungen veranschaulichten und/oder hierin beschriebenen Eigenschaften nicht auf die bestimmte veranschaulichte und beschriebene Weise angeordnet werden. Viele andere Anordnungen sind gemäß manchen Ausführungsformen möglich.
In jedem System, das in einer Figur gezeigt wird, können die Elemente in manchen Fällen die gleiche Bezugszahl oder eine andere Bezugszahl aufweisen, um anzuzeigen, dass die dargestellten Elemente unterschiedlich und/oder ähnlich sein können. Jedoch kann ein Element ausreichend flexibel sein, um unterschiedliche Implementierungen aufzuweisen und mit manchen oder all den hierin gezeigten oder beschriebenen Systemen zu funktionieren. Die verschiedenen in den Figuren gezeigten Elemente können gleich oder unterschiedlich sein. Welches als erstes Element und welches als zweites Element bezeichnet ist, ist willkürlich.
Die Techniken sind nicht auf die bestimmten hierin aufgelisteten Details beschränkt. Durchaus werden Fachleute auf dem Gebiet der Erfindung, denen diese Offenbarung vorliegt, verstehen, dass viele andere Variationen der vorangegangenen Beschreibung und der Zeichnungen innerhalb des Schutzumfangs der vorliegenden Techniken vorgenommen werden können. Dementsprechend definieren die nachfolgenden, beliebige Änderungen enthaltende Ansprüche den Schutzumfang der Techniken.
ZITATE ENTHALTEN IN DER BESCHREIBUNG
Diese Liste der vom Anmelder aufgeführten Dokumente wurde automatisiert erzeugt und ist ausschließlich zur besseren Information des Lesers aufgenommen. Die Liste ist nicht Bestandteil der deutschen Patent- bzw. Gebrauchsmusteranmeldung. Das DPMA übernimmt keinerlei Haftung für etwaige Fehler oder Auslassungen.
Zitierte Patentliteratur

US 62/454891 [0001]

Zitierte Nicht-Patentliteratur

Bartfai-Walcott et al., betitelt „MICROSERVICE PROVISION AND MANAGEMENT,“ eingereicht am 5. Februar 2017 [0001]

Claims

Rechnersystem, umfassend eine Internet-der-Dinge- (loT-) Vorrichtung, das eine gemeinsame Serviceschnittstelle (CSI) umfasst, um ein selbstverwaltendes Netzwerk aus Vorrichtungen mit anderen Knoten, die die CSI umfassen, zu erzeugen.
Rechnersystem nach Anspruch 1, wobei die CSI dazu dient, eine Schnittstelle mit einer anderen Vorrichtung zu bilden, eine Beschreibung der loT-Vorrichtung und eine Funktionalität der loT-Vorrichtung bereitzustellen und von der anderen Vorrichtung eine Beschreibung der anderen Vorrichtung und eine Funktionalität der anderen Vorrichtung zu erhalten.
Rechnersystem nach Anspruch 1, wobei die CSI zur Schnittstellenbildung mit einer anderen Vorrichtung durch eine Programmierschnittstelle (API) dient.
Rechnersystem nach Anspruch 1, wobei die CSI zur Schnittstellenbildung mit einer anderen Vorrichtung durch ein Data Distribution Service (DDS) dient.
Rechnersystem nach Anspruch 4, wobei das DDS ein Publish/Subscribe- (Pub/Sub-) Subskriptionsmodell umfasst.
Rechnersystem nach Anspruch 1, wobei die CSI eine virtuelle Schnittstelle zur Kommunikation über ein Netzwerk umfasst.
Rechnersystem nach Anspruch 1, wobei die CSI ein Kommunikationsprotokoll umfasst.
Rechnersystem nach Anspruch 1, wobei die CSI einen Internetprotokoll- (IP-) Block umfasst, der ein Serviceprotokoll umfasst, um eine Systemintegration und eine aktive Serviceverwaltung bereitzustellen.
Rechnersystem nach Anspruch 1, wobei die CSI ein Peering-System zum Eingliedern neuer Vorrichtungen umfasst.
Rechnersystem nach einem der Ansprüche 1 bis 9, wobei die loT-Vorrichtung Folgendes umfasst: einen Arbeitslastmanager, um eine Servicevorlage zu erhalten, die Servicevorlage zu zerlegen und die Anforderungen für die Arbeitslast, QoS und SLA zu bestimmen; einen Servicemanager, um Statusinformationen aus einer Vielzahl von Infrastrukturvorrichtungen zu erhalten; und einen Orchestrierungsmanager, um die Anforderungen vom Arbeitslastmanager und die Statusinformationen vom Servicemanager zu korrelieren und einer Infrastrukturvorrichtung ein Service zuzuordnen.
Rechnersystem nach einem der Ansprüche 1 bis 9, wobei die loT-Vorrichtung eine Distributed-Service-Schnittstelle (DSI) umfasst, um Microservices von einem Distributed Services Framework (DSF) zu erhalten.
Rechnersystem nach Anspruch 11, wobei das DSF zur Bereitstellung eines loT-Freizeichens dient, um die loT-Vorrichtung mit einem Microservice-Anbieter zu verbinden.
Rechnersystem nach Anspruch 12, wobei das loT-Freizeichen zur Bereitstellung einer Richtlinie und eines Verpflichtungsparadigmas zum Verbinden eines DSF-Verwaltungsnetzwerks dient.
Rechnersystem nach Anspruch 11, wobei das DSF einen Servicekatalog mit Servicevorlagen umfasst.
Rechnersystem nach Anspruch 11, wobei die loT-Vorrichtung einen Multi-DSF-Vermittler zum Verbinden mit mehreren DSF-Sitzungen umfasst.
Verfahren zum Orchestrieren des Einsatzes von Anwendungen an einer Internet-der-Dinge- (loT-) Vorrichtung, das das Zugreifen auf ein loT-Freizeichen auf einem Distributed Services Framework (DSF) umfasst, wobei das loT-Freizeichen Richtlinien und Verpflichtungsparadigmen zum Verbinden eines DSF-Verwaltungsnetzwerks bereitstellt.
Verfahren nach Anspruch 16, das Folgendes umfasst: das Senden einer Serviceanfrage an einen Servicekatalog, der Microservices auflistet; und das Empfangen einer Servicevorlage vom Servicekatalog.
Verfahren nach Anspruch 17, das das Analysieren von Infrastrukturfunktionalität, -verfügbarkeit und -status umfasst, um eine Infrastrukturabbildung zu erzeugen.
Verfahren nach Anspruch 18, das Folgendes umfasst: das Zerlegen der Servicevorlage, um Arbeitslastelemente zu bestimmen; und das Abbilden der Arbeitslastelemente auf Infrastrukturelemente in der Infrastrukturabbildung.
Verfahren nach Anspruch 19, das Folgendes umfasst: das Zuordnen der Arbeitslastelemente zu den Infrastrukturelementen; und das Sammeln von Servicequalitätsmetriken zur Operation der Arbeitslastelemente.
Verfahren nach einem der Ansprüche 16 bis 20, das das erneute Zuordnen von Arbeitslastelementen zu unterschiedlichen Infrastrukturelementen umfasst, wenn ein Versagen eine SLA zu erfüllen bestimmt wird.
Verfahren nach einem der Ansprüche 16 bis 20, das Folgendes umfasst: das Senden einer Serviceanfrage an einen Servicekatalog; das Erhalten eines Unternehmensservices vom Servicekatalog; das Analysieren des Unternehmensservices, um den Arbeitsablauf zu bestimmen; das Zerlegen eines Arbeitsablaufs, um Microservices und zentrale Leistungsindikatoren (KPIs) zu definieren; das Analysieren der Microservices und KPIs, um einen Ort in einer physischen Infrastruktur zur Zuordnung zu bestimmen; und das Zuordnen der Microservices zu Infrastrukturelementen.
Nichttransitorisches, maschinenlesbares Medium, das Code umfasst, der einen Prozessor bei seiner Ausführung zu Folgendem anweist: Erhalten einer Servicevorlage von einem Servicekatalog in einem Distributed Services Framework; Analysieren eines Arbeitsablaufs der Servicevorlage, um Anwendungen, Arbeitsabläufe und zentrale Leistungsindikatoren zu bestimmen; Analysieren der Anwendung, Arbeitsabläufe und zentralen Leistungsindikatoren, um Zuordnungsorte zu bestimmen; und Zuordnen der Anwendungsorte zu Infrastrukturelementen.
Nichttransitorisches, maschinenlesbares Medium nach Anspruch 23, das Code umfasst, der den Prozessor bei seiner Ausführung dazu anweist, die Operation der Anwendungen, Arbeitsabläufe und zentralen Leistungsindikatoren zu messen, um zu bestimmen, dass die Operation die Vereinbarung auf Serviceebene erfüllt.
Nichttransitorisches, maschinenlesbares Medium nach entweder Anspruch 23 oder 24, das Code umfasst, der den Prozessor bei seiner Ausführung dazu anweist, eine Anwendung, einen Arbeitsablauf oder einen zentralen Leistungsindikator zu bewegen, wenn eine Vereinbarung auf Serviceebene nicht erfüllt wird.
Nichttransitorisches, maschinenlesbares Medium nach entweder Anspruch 23 oder 24, das Code umfasst, der den Prozessor bei seiner Ausführung anweist, ein Microservice zu erhalten, um eine Aufgabe zu beenden.
Rechnersystem, umfassend eine Internet-der-Dinge- (loT-) Vorrichtung, das eine gemeinsame Serviceschnittstelle (CSI) umfasst, die Mittel zur Erzeugung eines selbstverwaltenden Netzwerks aus Vorrichtungen mit anderen Knoten, die die CSI umfassen, umfasst.
Rechnersystem nach Anspruch 27, wobei die CSI dazu dient, eine Schnittstelle mit einer anderen Vorrichtung zu bilden und eine Beschreibung der IoT-Vorrichtung und eine Funktionalität der loT-Vorrichtung bereitzustellen, wobei die CSI Mittel zum Erhalten einer Beschreibung der anderen Vorrichtung und einer Funktionalität der anderen Vorrichtung von der anderen Vorrichtung umfasst.
Rechnersystem nach Anspruch 27, wobei die CSI Mittel zur Schnittstellenbildung mit einer anderen Vorrichtung durch eine Programmierschnittstelle (API) umfasst.
Rechnersystem nach einem der Ansprüche 27 bis 29, wobei die CSI Mittel zur Schnittstellenbildung mit einer anderen Vorrichtung durch ein Data Distribution Service (DDS) umfasst.
Rechnersystem nach einem der Ansprüche 27 bis 29, wobei die CSI Mittel zum Eingliedern neuer Vorrichtungen umfasst.
Rechnersystem nach einem der Ansprüche 27 bis 29, wobei die loT-Vorrichtung Folgendes umfasst: einen Arbeitslastmanager, um eine Servicevorlage zu empfangen, die Servicevorlage zu zerlegen und Anforderungen für die Arbeitslast, QoS und SLA zu bestimmen; einen Servicemanager, um Statusinformationen von einer Vielzahl von Infrastrukturvorrichtungen zu erhalten; und Mittel, um die Anforderungen vom Arbeitslastmanager und die Statusinformationen vom Servicemanager zu korrelieren und einer Infrastrukturvorrichtung ein Service zuzuordnen.
Rechnersystem nach einem der Ansprüche 27 bis 29, wobei die loT-Vorrichtung eine Distributed-Service-Schnittstelle (DSI) umfasst, die Mittel zum Erhalten von Microservices von einem Distributed Services Framework (DSF) umfasst.
Rechnersystem nach Anspruch 33, wobei das DSF Mittel zum Bereitstellen eines loT-Freizeichens umfasst, um die loT-Vorrichtung mit einem Microservice-Anbieter zu verbinden.
Nichttransitorisches, maschinenlesbares Medium, das Anweisungen umfasst, um einen Prozessor in einen Knoten zu lenken, um eines der Verfahren nach Anspruch 16 bis 22 durchzuführen.
Vorrichtung, die Mittel zur Durchführung eines der Verfahren nach Anspruch 16 bis 22 umfasst.