DE102024106300A1

DE102024106300A1 - Echtzeit-controller zur reduzierung des co2-fussabdrucks

Info

Publication number: DE102024106300A1
Application number: DE102024106300.9A
Authority: DE
Inventors: Soumyendu Sarkar; Avisek Naug; Ricardo Luna Gutierrez; Antonio Guillen Perez; Sahand Ghorbanpour
Original assignee: Hewlett Packard Enterprise Development LP
Current assignee: Hewlett Packard Enterprise Development LP
Priority date: 2023-05-26
Filing date: 2024-03-05
Publication date: 2024-11-28
Also published as: CN119024734A; US20240392988A1

Abstract

Es werden Systeme und Verfahren zur gleichzeitigen Optimierung des Energieverbrauchs, der flexiblen Lastverschiebung und der Batteriebetriebsentscheidungen in Echtzeit durch Reinforcement Learning (RL) bereitgestellt. Beispiele umfassen das Erhalten von Zuständen eines Systems, das eine Vielzahl von Subsystemen umfasst, und das Empfangen von Belohnungen von einem digitalen Zwilling des Systems durch RL-Agenten, wobei die Belohnungen eine Vielzahl von Belohnungen umfassen, die jeweils mit einem Subsystem verbunden sind. Das Beispiel beinhaltet auch das Bestimmen von Aktionen durch die RL-Agenten, basierend auf den Zuständen und jeder der Belohnungen. Jeder RL-Agent ist einem Teilsystem zugeordnet und weist einer Belohnung, die dem zugeordneten Teilsystem entspricht, ein Gewicht zu, das größer ist als die den Belohnungen der anderen Teilsysteme zugewiesenen Gewichte. Das System kann dann entsprechend den Aktionen gesteuert werden, um das System in aktualisierte Zustände zu überführen.

Description

Querverweise auf verwandte Anwendungen
Diese Anmeldung beansprucht den Nutzen und die Priorität der vorläufigen US-Anmeldung Nr. 63/504,664 , die am 26. Mai 2023 eingereicht wurde und deren Inhalt durch Bezugnahme in vollem Umfang in das vorliegende Dokument aufgenommen wird.
Hintergrund
Der Kohlenstoff-Fußabdruck ist ein Indikator, der die Gesamtmenge der von einem System emittierten Treibhausgase vergleicht. Eine gängige Definition des Kohlenstoff-Fußabdrucks ist ein Maß für die Gesamtmenge der Kohlendioxid- (CO₂) und Methanemissionen (CH₄) eines definierten Systems unter Berücksichtigung aller relevanten Quellen, Senken und Speicher innerhalb der räumlichen und zeitlichen Grenzen des Systems. Der Kohlenstoff-Fußabdruck wird in der Regel in Tonnen Emissionen (CO₂ -Äquivalent) pro Vergleichseinheit, z. B. pro Jahr, pro Monat usw., angegeben. Für ein System kann der Kohlenstoff-Fußabdruck sowohl die direkten als auch die indirekten Emissionen umfassen, die durch das System verursacht werden. Direkte Emissionen beziehen sich auf Emissionen aus Quellen, die direkt von dem System stammen, und indirekte Emissionen beziehen sich auf Emissionen aus Quellen, die dem System vor- oder nachgelagert sind und von Aktivitäten des Systems herrühren, unabhängig davon, ob sie von dem System kontrolliert werden oder nicht.
Kurzbeschreibung der Zeichnungen
Die vorliegende Offenbarung wird in Übereinstimmung mit einer oder mehreren verschiedenen Ausführungsformen unter Bezugnahme auf die folgenden Figuren im Detail beschrieben. Die Figuren dienen lediglich der Veranschaulichung und stellen lediglich typische oder beispielhafte Ausführungsformen dar.

Die 1A und 1B zeigen die Architektur eines beispielhaften Rahmens zur Reduzierung des Kohlenstoff-Fußabdrucks von Rechenzentren (DC-CFR) in Übereinstimmung mit Implementierungen der vorliegenden Offenbarung.
2 ist ein schematisches Diagramm der Abhängigkeiten und des Informationsaustauschs zwischen den Teilsystemen eines Rechenzentrums.
3 ist ein schematisches Blockdiagramm eines Beispielprozesses des Verstärkungslernens in Übereinstimmung mit Implementierungen der vorliegenden Offenbarung.
4 ist ein Beispiel für eine Computerkomponente, die verwendet werden kann, um verschiedene Merkmale der Kohlenstoff-Fußabdruck-Reduzierung in Übereinstimmung mit den hier offengelegten Implementierungen zu implementieren.
5 ist ein Beispiel für ein Computersystem, das zur Umsetzung verschiedener Merkmale der Verringerung des CO2-Fußabdrucks im Rahmen der vorliegenden Offenlegung verwendet werden kann.

Die Figuren sind nicht erschöpfend und beschränken die vorliegende Offenbarung nicht auf die genaue Form, die offengelegt wird.
Detaillierte Beschreibung
Nachhaltigkeit und die Verringerung des CO2-Fußabdrucks werden zu einer Priorität für Regierungen und Unternehmen weltweit. Der derzeitige Anstieg der globalen Durchschnittstemperatur ist schneller als frühere Veränderungen und wird in erster Linie durch Aktivitäten verursacht, bei denen fossile Brennstoffe zur Strom- und Energieversorgung verbrannt werden. Prognosen zufolge wird die Informations- und Kommunikationstechnologie bis 2030 7 bis 20 % des weltweiten Strombedarfs ausmachen. Ein großer Teil des daraus resultierenden globalen Kohlenstoff-Fußabdrucks entfällt auf Datenzentren. Fußabdruck dieser Rechenzentren wird in den kommenden Jahren tendenziell zunehmen, und zwar alle zehn Jahre um das 6-fache.
Um Nachhaltigkeit zu erreichen, müssen verschiedene voneinander abhängige Energieverbrauchsfaktoren von Rechenzentren optimiert werden, wie z. B. der Stromverbrauch für den Betrieb des Rechenzentrums (z. B. für die Kühlung und die IT-Arbeitslast), die Verlagerung flexibler Arbeitslasten auf der Grundlage der Verfügbarkeit erneuerbarer Energien in einem Stromnetz und die Nutzung von in Batterien gespeichertem Strom aus dem Stromnetz. Flexible Last bezieht sich auf bestimmte IT-Arbeitslasten, die von einer Aufgabe zur anderen oder von einem Zeitpunkt zum anderen verschoben werden können, um andere Aspekte des Rechenzentrums zu optimieren. Statische oder unflexible Arbeitslasten sind Arbeitslasten, die nicht verschoben werden dürfen und möglicherweise notwendig sind, um eine Aufgabe wie geplant zu erledigen.
Konventionell erfolgt die Optimierung dieser Stromverbrauchsfaktoren offline, wobei jeder Faktor separat und isoliert optimiert wird. Die konventionellen Systeme sind nicht in der Lage, die verschiedenen Energieverbrauchsfaktoren von Rechenzentren gleichzeitig in Echtzeit zu optimieren. Dies liegt daran, dass die gleichzeitige Optimierung aufgrund der komplexen Abhängigkeiten zwischen den verschiedenen zu optimierenden Energieverbrauchsfaktoren sowie der Abhängigkeit der Energieverbrauchsfaktoren von externen Faktoren, wie z. B. dem Wetter und der Verfügbarkeit erneuerbarer Energien im Stromnetz, ein schwer zu lösendes Problem darstellt.
Es wurden analytische Methoden vorgeschlagen. Diese vorgeschlagenen Methoden beruhen jedoch auf statischen Offline-Analysen und optimieren die Kühlung von Rechenzentren (z. B. Heizungs-, Lüftungs- und Klimaanlagen) nicht mit externen Faktoren wie Wettervorhersagen, um den Gesamtenergieverbrauch mit umfassenden Maßnahmen zur Kohlenstoffreduzierung zu senken. Darüber hinaus sammeln die statischen Analysemethoden Vorhersagen zur Kohlenstoffintensität (CI) für den nächsten Tag, trainieren Modelle zur Vorhersage von Energieangebot und -nachfrage für den nächsten Tag und verwenden sie, um analytisch die beste Arbeitslastverteilung im Rechenzentrum zu finden, um den gesamten Kohlenstoff-Fußabdruck zu minimieren. Bei diesen „Day-ahead“-Analysen wird der Netto-Kohlenstoff-Fußabdruck aufgrund der Verschiebung von Arbeitslasten innerhalb eines 24-Stunden-Zeitraums möglicherweise übersehen, so dass es an Granularität für Echtzeit-Implementierungen mangelt. Darüber hinaus ist es aufgrund der sich ändernden Wettermuster möglicherweise nicht möglich, sich auf langfristige Prognosemodelle zu verlassen. Darüber hinaus haben die komplexen Abhängigkeiten zwischen Energieverbrauch, Lastausgleich und Energiespeicherung sowie der Informationsaustausch zwischen den einzelnen Aspekten die Entwicklung einer kohärenten Strategie zur gleichzeitigen Verringerung des CO2-Fußabdrucks unter Nutzung aller drei Möglichkeiten in Echtzeit behindert. Fußabdruck für ein ganzes System mit diesen Analysemethoden zu reduzieren, hat sich aufgrund der Komplexität dieser einzelnen Probleme sowie der Abhängigkeit von relativ langen Prognosehorizonten (z. B. 24 Stunden) als schwierig erwiesen.
Im Gegensatz dazu bieten Beispiele der Technologie der vorliegenden Offenlegung einen Rahmen, der Reinforcement Learning (RL) nutzt, um den Energieverbrauch, die flexible Lastverschiebung und Entscheidungen zum Batteriebetrieb gleichzeitig in Echtzeit zu optimieren, wodurch die technischen Unzulänglichkeiten der bisherigen Lösungen überwunden werden. Diese Optimierung kann auf der Grundlage von Prognosen externer Faktoren (z. B. Kohlenstoffintensität im Netz und Wetterbedingungen, um nur einige Beispiele zu nennen) unter Verwendung mehrerer Agenten erfolgen. Solche Prognosen können relativ kurze Horizonte haben, z. B. weniger als 24 Stunden, weniger als 12 Stunden, weniger als 1 Stunde usw. In einigen Fällen können die Vorhersagehorizonte der vorliegenden Offenlegung sehr kurz sein, z. B. 1-Minuten-Horizonte oder weniger. Somit kann die hier beschriebene Implementierung auf Vorhersagen eines beliebigen kurzfristigen Horizonts basieren, wie er für eine gewünschte Anwendung gewünscht wird. Auf diese Weise kann die hier offengelegte Technologie die Nachteile bestehender, isolierter Methoden wirksam abmildern, indem sie einen Rahmen bereitstellt, der die komplexen Abhängigkeiten und den Informationsaustausch zwischen einzelnen Optimierungsstrategien verwaltet, die von konkurrierenden Subsystemen in Rechenzentren eingesetzt werden.
Die hier verwendete Kohlenstoffintensität (CI) bezieht sich auf die Menge an Kohlendioxidemissionen (CO₂), die vom Stromnetz pro Einheit der aus dem Netz verbrauchten Elektrizität erzeugt wird und die je nach Stromquelle (z. B. fossile Brennstoffe, erneuerbare Energie usw.) und Energieverbraucher zu einem bestimmten Zeitpunkt variiert. Eine hohe Entnahme von nicht erneuerbaren Energiequellen aus dem Netz würde also als ein Zeitraum mit hohem CI gelten, während ein niedriger CI bedeutet, dass Energie aus umweltfreundlicheren Energiequellen verfügbar ist.
Der Rahmen gemäß der vorliegenden Offenlegung stellt einen digitalen Zwilling eines realen Rechenzentrums bereit, der den Betrieb des Rechenzentrums simuliert. Das Framework nutzt RL, um Energieverbrauchsfaktoren (z. B. Energieverbrauch, Lastverschiebung und Energiespeicheroperationen) für den digitalen Zwilling in Echtzeit ganzheitlich zu optimieren und optimierte Richtlinien zu erlernen, die zur Steuerung des Betriebs des realen Rechenzentrums verwendet werden können. Der digitale Zwilling kann vom Rechenzentrum über Echtzeit-Änderungen der Betriebsbedingungen informiert werden, so dass der digitale Zwilling dynamisch an die sich ändernden Bedingungen angepasst werden kann. Der Rahmen optimiert gleichzeitig den Stromverbrauch des digitalen Zwillings durch RL, die durch die sich ändernden Betriebsbedingungen informiert wird. Beispiele für die offengelegte Technologie adressieren das exponentielle Wachstum der Stromverbrauchsanforderungen durch Entkopplung der Probleme in separate Teilprobleme durch RL Markov Decision Processes (MDP) Formulierungen. Die offengelegte Technologie löst gleichzeitig die RL-MDP-Formulierungen, um eine Echtzeit-Optimierungsstrategie für den CO2-Fußabdruck zu entwickeln, die auf eine nachhaltige Reduzierung des CO2-Fußabdrucks zugeschnitten ist. Die optimierten Strategien können dann zur Konfiguration und Steuerung des Betriebs eines realen Rechenzentrums verwendet werden.
In Beispielimplementierungen umfasst der Rahmen eine Vielzahl von RL-Agenten, die auf der Grundlage historischer Daten trainiert werden, um adaptive Strategien zu entwickeln, die optimiert sind, um die komplexen und miteinander verknüpften Energieverbrauchsfaktoren in Echtzeit zu berücksichtigen. Der Rahmen verwaltet die komplexen Abhängigkeiten und den Informationsaustausch zwischen diesen RL-Agenten über die MDP-Formulierungen, um eine integrierte Echtzeitlösung zur Reduzierung des CO2-Fußabdrucks bereitzustellen.
Gemäß den hier offengelegten Beispielen kann ein Rechenzentrum aus Sicht der Steuerung in eine Reihe von Subsystemen unterteilt werden, wie z. B. ein Kühlsubsystem (z. B. ein HLK-System), ein Lastverschiebungs-Subsystem, das die Arbeitslast des Rechenzentrums flexibel verschiebt, und Energiespeicher-Subsysteme, die aus Energiespeichergeräten (z. B. Batterien eines USV-Systems) bestehen, die vom Stromnetz geladen und für eine unterbrechungsfreie Stromversorgung entladen werden können. Jedes Subsystem kann durch ein entsprechendes Subsystemmodell (auch als digitaler Zwilling des Subsystems bezeichnet) simuliert werden, das Teil des systemweiten digitalen Zwillings sein kann. Jedem Teilsystem kann ein RL-Agent aus der Vielzahl der RL-Agenten zugeordnet und mit einem entsprechenden Teilsystemmodell verbunden werden. Beispielsweise kann ein RL-Agent für die Energieoptimierung bereitgestellt werden, der mit dem Modell des Teilsystems Kühlung verbunden und so konfiguriert ist, dass er optimierte Richtlinien für die Steuerung des Teilsystems Kühlung bestimmt, um den Gesamtenergieverbrauch aufgrund der IT-Arbeitslast und der Kühlung zu minimieren. Dieser RL-Agent kann Wettervorhersagen nutzen, um die Energiereduzierung weiter zu optimieren. Ein Lastverschiebungs-RL-Agent kann über eine Schnittstelle mit einem Lastverschiebungs-Subsystemmodell verbunden und so konfiguriert werden, dass er optimierte Richtlinien für die Verschiebung flexibler Last von Zeiträumen mit geringer Verfügbarkeit erneuerbarer Energien im Stromnetz zu hoher Verfügbarkeit (z. B. hohe bis niedrige Kohlenstoffintensität (CI) im Netz) ermittelt. Der RL-Agent für die Lastverschiebung kann auch zukünftige Vorhersagen für die CI (z. B. kann eine hohe CI während der Mittagszeit auftreten, wenn es hohe IT-Lasten gibt) und Wettervorhersagedaten nutzen. Ein RL-Agent für die Energiespeicherung kann auch über eine Schnittstelle mit einem Modell des Energiespeicher-Subsystems verbunden werden und so konfiguriert werden, dass er optimierte Richtlinien für die Energiespeicherung in den Batterien des Energiespeicher-Subsystems während Zeiten mit niedrigem CI bestimmt und gespeicherte Energie aus den Batterien während Zeiten mit hohem CI entlädt, um den Energieverbrauch des Rechenzentrums zu unterstützen. Der RL-Agent für die Energiespeicherung kann auch die nichtlinearen Lade- und Entlademuster der Batterien berücksichtigen.
Das Framework kann gemäß verschiedener Implementierungen die komplexen Abhängigkeiten und den Informationsaustausch zwischen den mehreren RL-Agenten durch eine kollaborative Belohnung verwalten. Die kollaborative Belohnung umfasst Belohnungen für jedes Teilsystemmodell, und jede Belohnung ist für jeden RL-Agenten eindeutig gewichtet. Das heißt, dass zum Beispiel jedes Teilsystemmodell eine Belohnung ausgeben kann (z. B. gibt das Kühlungs-Teilsystemmodell eine Kühlungsbelohnung aus, das Lastverschiebungs-Teilsystemmodell eine Lastverschiebungsbelohnung usw.). Die einzelnen Belohnungen können zu einer kollaborativen Belohnung kombiniert werden, die auf den jeweiligen RL-Agenten zugeschnitten ist, indem eine Belohnung, die von einem dem jeweiligen RL-Agenten zugeordneten Teilsystemmodell ausgegeben wird, stärker gewichtet wird als die anderen Belohnungen. Im Falle des RL-Agenten für die Energieoptimierung kann beispielsweise die vom Modell des Teilsystems Kühlung ausgegebene Belohnung mit 0,8 gewichtet werden, während die anderen Belohnungen mit 0,1 gewichtet werden. Auf diese Weise kann jeder Agent alle anderen Belohnungen berücksichtigen und Aktionen festlegen, die das gesamte System optimieren, im Gegensatz zur egoistischen individuellen Optimierung. Dies steht im Gegensatz zu konventionellen, nicht-RL-basierten Systemen, bei denen jedes Teilsystem die Überlegungen und Handlungen anderer Teilsysteme nicht kennt oder in Echtzeit berücksichtigt.
Auf der Grundlage der individuell zugeschnittenen kollaborativen Belohnungen, die in der offengelegten Technologie bereitgestellt werden, und der Echtzeit-Betriebsbedingungen des Rechenzentrums kann jeder RL-Agent Maßnahmen zur Steuerung seines entsprechenden Teilsystems bestimmen, um nicht nur das individuelle Teilsystem, sondern auch den systemweiten Rechenzentrumsbetrieb zu optimieren. Die individuell zugeschnittenen kollaborativen Belohnungen ermöglichen es jedem einzelnen Agenten, die verschiedenen Abhängigkeiten zwischen den Teilsystemen zu berücksichtigen.
Dementsprechend bietet die hier offengelegte Technologie ein auf Multi-Agenten-RL basierendes, kohlenstoffemissionsbewusstes, ganzheitliches Echtzeit-Kontrollsystem zur Optimierung nachhaltiger Rechenzentren durch effiziente Kühlung, Umverteilung flexibler Server-Arbeitslasten und Batteriespeicher für die Hilfsenergieversorgung. Die hier offengelegte Technologie kann helfen, komplexe Abhängigkeiten zwischen steuernden RL-Agenten mit dynamischen externen Abhängigkeiten zu lösen und schafft einen Leistungsgewinn gegenüber statischen Optimierern, wie oben beschrieben. Darüber hinaus kann die hierin beschriebene Technologie ein Rechenzentrum im Hinblick auf mehrere Ziele wie die Verringerung des CO2-Fußabdrucks, den Energieverbrauch und die Energiekosten optimieren. Optimierungen durch die offengelegte Technologie können mit Hilfe von Industriestandard-Simulatoren und -Modellen an mehreren geografischen Standorten durchgeführt werden, an denen der Bau von Rechenzentren möglich ist, mit unterschiedlichen Wettermustern und über mehrere Jahreszeiten hinweg. Die offengelegte Technologie kann zum Beispiel eine durchschnittliche Senkung der Energiekosten um 8,04 % im Vergleich zu einer konventionellen Steuerung auf der Grundlage von Industriestandards der American Society of Heating, Refrigerating and Air-Conditioning Engineers (ASHRAE) und des Residential Building Committee (RBC) erreichen. Darüber hinaus kann die Technologie gemäß der vorliegenden Offenlegung zusätzliche Emissionssenkungen durch Batterie- und Lastverschiebungsoptimierung ermöglichen, was zu einer durchschnittlichen Senkung der Kohlendioxidemissionen um beispielsweise 9,06 % in verschiedenen Rechenzentrumskonfigurationen führt.
Darüber hinaus bietet der Rahmen, der einen digitalen Zwilling des Rechenzentrums, einen RL-Agenten und eine RL-Schnittstelle umfasst, eine skalierbare und modulare Architektur, die auf zusätzliche optimierende Steuerungen erweitert werden kann und dazu beitragen kann, die Bemühungen des Ökosystems zur Kohlenstoffreduzierung zu demokratisieren. Beispielsweise können Implementierungen der vorliegenden Offenlegung über mehrere physische Teile eines Rechenzentrums (z. B. mehrere Räume, mehrere Städte, mehrere geografische Regionen usw.) skaliert werden. Die Skalierbarkeit kann durch den digitalen Zwilling erreicht werden, der jedes Teilsystem als Ganzes modellieren oder die Teilsysteme in kleinere Teile aufteilen kann (z. B. pro Raum, pro geografische Region usw.).
Es sollte beachtet werden, dass die Begriffe „optimieren“, „optimal“ und dergleichen, wie sie hier verwendet werden, verwendet werden können, um die Leistung so effektiv oder perfekt wie möglich zu machen oder zu erreichen. Wie jedoch ein Fachmann, der dieses Dokument gelesen hat, erkennen wird, kann Perfektion nicht immer erreicht werden. Dementsprechend können diese Begriffe auch bedeuten, die Leistung so gut oder effektiv wie unter den gegebenen Umständen möglich oder praktikabel zu machen oder zu erreichen, oder die Leistung besser zu machen oder zu erreichen als die, die mit anderen Einstellungen oder Parametern erreicht werden kann.
In den 1A und 1B ist eine Systemarchitektur 100 eines Beispiels für ein Rahmenwerk zur Reduzierung des Kohlenstoff-Fußabdrucks von Rechenzentren (DC-CFR) gemäß den Implementierungen der vorliegenden Offenlegung dargestellt. Die Systemarchitektur 100 umfasst ein Rahmenwerk 110, das über ein Netzwerk 190 mit einem physischen System 160 kommunikativ verbunden ist. Wie hierin verwendet, bezieht sich der Begriff „Framework“ auf eine Kombination von Komponenten (z. B. Kombinationen aus einem Mikroprozessor, einem Kern eines Multi-Core-Mikroprozessors, einem Mikrocontroller, einer programmierbaren integrierten Schaltung, einem programmierbaren Gate-Array oder dergleichen) und die Art und Weise, wie diese Komponenten miteinander kommunizieren."
In diesem Beispiel wird das physische System 160 als physisches, real existierendes Rechenzentrum bereitgestellt, das durch das Framework 110 simuliert wird. Der Rahmen 110 umfasst einen digitalen Zwilling 114, der ein digitales Modell des Rechenzentrums 176 ist, das für die Simulation des Betriebs des Rechenzentrums 176 konfiguriert ist. Der digitale Zwilling 114 kann eine digitale Nachbildung des physischen Systems 160 sein, die als ausführbarer Code implementiert ist, der in einem Speicher gespeichert ist und von einem Prozessor ausgeführt wird (z. B. wie das Computersystem 500, das im Zusammenhang mit 5 beschrieben wird).
Das physische System 160 kann verschiedene Sensoren und Internet-of-Things umfassen, um die Betriebsbedingungen des physischen Systems 160 zu erfassen, unter denen das Rechenzentrum 176 in der realen Welt arbeitet. Die Betriebsbedingungen können über das Netzwerk 190 als Eingabedaten an das Framework 110 übermittelt werden. Die Eingabedaten können dem Framework 110 in Echtzeit zugeführt werden, wenn die Betriebsbedingungen im physischen System 160 erfasst werden. Der Rahmen 110 kann die Eingabedaten empfangen und die Eingabedaten als Zustände in den digitalen Zwilling 114 einspeisen. Durch Anwendung der Zustände auf den digitalen Zwilling 114 kann der Betrieb des physischen Systems 160 unter den durch die Eingangsdaten dargestellten Betriebsbedingungen simuliert werden.
Der Rahmen 110 kann so konfiguriert werden, dass er auf der Grundlage der Simulationen Modelle des maschinellen Lernens (ML) ausführt, um Entscheidungen über Aktionen zum Übergang von Betriebszuständen des Rahmens 110 zu treffen, die den Rahmen 110 im Hinblick auf mehrere Ziele der Reduzierung des CO2-Fußabdrucks, des Energieverbrauchs und der Energiekosten optimieren. Aktionen, die zur Optimierung der verschiedenen Ziele bestimmt wurden, können dem Rahmenwerk 110 über ein Netzwerk 190 als Anweisungen zur Steuerung des Rechenzentrums 176 gemäß den bestimmten Aktionen übermittelt werden. Als Ergebnis kann das physische System 160 dann so gesteuert werden, dass das Rechenzentrum 176 für die verschiedenen Ziele der Reduzierung des CO2-Fußabdrucks, des Energieverbrauchs und der Energiekosten im gesamten physischen System 160 optimiert wird.
Wie bereits angedeutet, ist der digitale Zwilling 114 ein Modell, das den Betrieb des gesamten Rechenzentrums 176 simulieren kann. Der digitale Zwilling 114 umfasst eine Vielzahl von digitalen Zwillingen oder Modellen eines Teilsystems, von denen jedes den Betrieb eines einzelnen Teilsystems des Rechenzentrums 176 simuliert. Die Subsystemmodelle können durch Anwendung von Zuständen und Aktionen ausgeführt werden, die die Modelle in einen nächsten Zustand überführen. Jedes Modell simuliert die Vorgänge (z. B. Aktionen) des jeweiligen Teilsystems entsprechend den Zuständen. Zustände können sich auf eine Reihe von Informationen beziehen, die die zu einem bestimmten Zeitpunkt zu simulierenden Betriebsbedingungen definieren. Die Zustände können auf Informationen beruhen, die aus dem physischen System 160 gewonnen wurden. In diesem Beispiel umfasst der digitale Zwilling 114 ein Modell des Teilsystems Kühlung 120, ein Modell des Teilsystems Energiespeicherung 130 und ein Modell des Teilsystems Lastverschiebung (z. B. Arbeitslast) 132.
Das Modell des Kühlungs-Subsystems 120 kann die Temperaturregulierung eines Rechenzentrums nachahmen oder anderweitig simulieren, z. B. durch HLK-Systeme und Temperaturüberwachung durch einen Thermostat 122. Das heißt, das Kühlungs-Teilsystemmodell 120 kann ein HLK-Systemmodell enthalten, das simuliert werden kann, um die Temperaturen eines digitalen Zwillings 114 durch Überwachung der simulierten Temperaturen durch einen Thermostat 122 zu steuern. In diesem Fall können Aktionen, die in das Kühlungs-Subsystemmodell 120 eingegeben werden, einen Temperatursollwert für das Rechenzentrum beinhalten, der innerhalb des Modells festgelegt und zur Steuerung des Betriebs des HLK-Systemmodells verwendet wird.
In einigen Ausführungsformen, wie in 1A dargestellt, kann das Modell des Kühlungs-Teilsystems 120 eine oder mehrere Zonen 124a-124n umfassen, die verschiedene Untergruppen von Rechenzentren darstellen können. Ein Unternehmen kann zum Beispiel eine Reihe von einzelnen Rechenzentren betreiben, die über verschiedene Regionen verteilt sind. In verschiedenen Regionen herrschen unterschiedliche Wetterbedingungen und andere Variationen der Betriebsbedingungen, die sich auf die Temperaturregelung der einzelnen Rechenzentren auswirken. Um einer solchen Konfiguration gerecht zu werden, kann das Kühlungs-Subsystem-Modell 120 eine Reihe von separaten diskreten Zonen 124a-124n umfassen, die jeweils so konfiguriert sind, dass sie Kühlungs-Subsysteme für diese Zone modellieren. Jede Zone 124a-124n umfasst ein entsprechendes HLK-Systemmodell 126a-126n bzw. ein Rechenzentrumsmodell 128a-128n, um jede Zone separat zu modellieren. Der Thermostat 122 überwacht die simulierte Temperatur jeder Zone im Hinblick auf den Temperatursollwert. Der Temperatursollwert kann im Vorfeld eines Simulationsschritts festgelegt werden. Auch wenn sich das hier beschriebene Beispiel auf regionale Unterschiede bezieht, sind andere Unterteilungen von Rechenzentren im Rahmen der vorliegenden Offenlegung möglich.
Das Modell des Energiespeicher-Subsystems 130 kann die Energiespeicherung durch das Rechenzentrum in Batterie-Subsystemen nachahmen oder anderweitig simulieren. Das Energiespeicher-Subsystemmodell 130 kann zum Beispiel ein USV-Systemmodell enthalten, das für die Energiespeicherung und - entladung aus Batterien simuliert werden kann. Das Modell des Energiespeicher-Subsystems 130 kann das Laden der Batterie-Subsysteme zur Energiespeicherung und das Entladen zur Energienutzung entsprechend der Simulation des Rechenzentrums simulieren.
Das Modell des Lastverschiebungs-Subsystems 132 kann die Verschiebung der flexiblen Arbeitslast, die während der Simulation des Rechenzentrums durchgeführt wird, nachahmen oder anderweitig simulieren. Zum Beispiel können Operationen, die vom Rechenzentrum durchgeführt werden, die Nutzung von Rechenressourcen erfordern, die das Rechenzentrum belasten. Das Modell des Lastverschiebungs-Subsystems 132 kann so konfiguriert werden, dass es die Verschiebung von Arbeitslasten zwischen den verfügbaren Ressourcen zur Erledigung von Aufgaben simuliert. Bestimmte Arbeitslasten können als flexible Lasten betrachtet werden, die verschoben werden können, um andere Aspekte des Rechenzentrums auf der Grundlage von Betriebsbedingungen, wie z. B. CI und Wettervorhersagen, zu optimieren. So kann es beispielsweise optimal sein, flexible Arbeitslasten auf Zeiten mit niedrigem CI und/oder niedrigen Wettervorhersagen zu verlagern, was den Kohlenstoffausstoß des Rechenzentrums verringern kann.
Der Rahmen 110 umfasst auch Steueragenten 116, die so konfiguriert sind, dass sie Anweisungen zur Steuerung des digitalen Zwillings 114 in Form von Aktionen geben. Die Steueragenten 116 umfassen eine Vielzahl von RL-Agenten 134-138, von denen jeder einem Teilsystem des Datenzentrums entspricht. Jeder RL-Agent 134-138 kann als maschineller Lernalgorithmus bereitgestellt werden, der Zustände 118 in Form von Eingabedaten aus dem physischen System 160 empfängt, wie z. B. Wetterinformationen (z. B. Wettervorhersagen), Netz-, Energie- und Kohlenstoffverteilung, berechnete Arbeitslast und andere Betriebsbedingungen, aber nicht darauf beschränkt. Jeder RL-Agent 134-138 kann auch simulierte Zustände in Form von Zustandsinformationen 150 (auch als Beobachtungen bezeichnet) vom digitalen Zwilling 114 erhalten, die aktuelle Zustände (z. B. simulierte Betriebsbedingungen) der Teilsystemmodelle darstellen.
Der maschinelle Lernalgorithmus jedes RL-Agenten 134-138 kann ein Verstärkungsalgorithmus sein, der jeden RL-Agenten auf eine entsprechende Strategie trainiert, die so konfiguriert ist, dass sie eine individuell zugeschnittene kollaborative Belohnung optimiert (wie weiter unten ausführlicher beschrieben wird). Die individuell zugeschnittene kollaborative Belohnung kann repräsentativ für die Effektivität von Aktionen sein, die auf den Eingangszuständen 118 basieren, und kann verwendet werden, um die Strategie zur Bestimmung zukünftiger Aktionen zu informieren. Die von jedem RL-Agenten angewandte Strategie versucht, sowohl sein eigenes zugehöriges Teilsystemmodell zu optimieren, als auch optimale systemweite Abläufe zu berücksichtigen.
Jedes Subsystemmodell berechnet und gibt eine entsprechende Belohnung aus, die in der Belohnungsinformation 148 enthalten ist, die den Steueragenten 116 zur Verfügung gestellt wird. Die einzelnen entsprechenden Belohnungen können aggregiert und auf eine Weise gewichtet werden, die für jedes Teilsystem individuell zugeschnitten ist, so dass die RL-Agenten 134-138 Aktionen bestimmen können, die sowohl für ihr eigenes Teilsystemmodell als auch für das System als Ganzes optimal sind.
Im Beispiel von 1A umfassen die Steueragenten 116 einen RL-Agenten für Energieverbrauch 134, einen RL-Agenten für Lastverschiebung 136 und einen RL-Agenten für Energiespeicherung 138. Der RL-Agent 134 für den Energieverbrauch ist so konfiguriert, dass er den Energieverbrauch des realen Kühlsubsystems durch Interaktionen mit dem Kühlsubsystemmodell 120 optimiert. Der Lastverschiebungs-RL-Agent 136 ist so konfiguriert, dass er die Lastverschiebung des realen Lastverschiebungs-Subsystems durch Interaktionen mit dem Lastverschiebungsmodell des Subsystemmodells 132 optimiert. Der RL-Agent 138 für die Energiespeicherung ist so konfiguriert, dass er die Energiespeicherung des realen Batterie-Subsystems durch Interaktionen mit dem Energiespeicher-Subsystemmodell 130 optimiert.
Rechenzentren, wie z. B. das Rechenzentrum 176, können einen erheblichen Teil des weltweiten Energieverbrauchs ausmachen, und die Bemühungen um eine Verringerung der Kohlenstoffemissionen haben zugenommen. Ein Ansatz ist die kohlenstoffbewusste Arbeitslastplanung (CAS), die flexible Arbeitslasten nutzt, um die Kohlendioxidemissionen zu senken, indem sie auf Zeiten mit niedriger CI umdisponiert werden. Obwohl nicht alle Arbeitslasten flexibel sind (z. B. tolerant gegenüber Verzögerungen), gibt es einige Anwendungen wie die Datenverarbeitung, bei denen ein beträchtlicher Teil der Arbeitslast verschoben werden kann.
Die Kontrollagenten 116, wie z. B. der Lastverschiebungs-RL-Agent 136, können zur Optimierung der Arbeitslastplanung in Rechenzentren eingesetzt werden. Indem der Lastverschiebungs-RL-Agent 136 darauf trainiert wird, intelligente Entscheidungen darüber zu treffen, wann die Arbeitslasten zugewiesen werden sollen, können der Energieverbrauch gesenkt und die thermische Effizienz erhöht werden. Der Rahmen 110 kann so implementiert werden, dass er gleichzeitig die Arbeitslastplanung durch den Lastverschiebungs-RL-Agenten 136 und die Kühlsysteme durch den Energieverbrauchs-RL-Agenten 134 verwaltet, um die Gesamteffizienz zu verbessern. Die Steueragenten 116 können einen ereignisgesteuerten RL-Ansatz verwenden, der den Energieverbrauch reduziert, indem die Arbeitslastplanung und die Kühlvorgänge nach bestimmten Ereignissen, wie z. B. einer Überhitzung des Racks, ausgeführt werden. Die Steueragenten 116 können auch zur Vorhersage der thermischen Dynamik und zur Reduzierung des Energieverbrauchs durch Verschiebung der Arbeitslast eingesetzt werden. Darüber hinaus können die Steuerungsagenten 116 zur Optimierung der oben genannten Punkte eingesetzt werden, wobei auch die Energiequelle und die Optimierung der Kohlenstoffemissionen berücksichtigt werden.
Der Rahmen 110 umfasst auch eine RL-Schnittstelle 112, die eine Vielzahl von Wrappern für die Verbindung mit jedem der RL-Agenten 134-138 bereitstellt. Im Beispiel von 1A umfasst die RL-Schnittstelle 112 eine Energieverbrauchs-Verschalung 140, die bereitgestellt werden kann, um das Kühlungs-Subsystemmodell 120 zu kapseln und Daten in ein Format zu konvertieren, das auf das Kühlungs-Subsystemmodell 120 angewendet und von diesem verarbeitet werden kann. Beispielsweise kann der Energieverbrauchs-Wrapper 140 vorgesehen werden, um die Aktion 146 in ein Format zu konvertieren, das vom Subsystemmodell 120 für die Kühlung ausgeführt werden kann. Die RL-Schnittstelle 112 umfasst auch einen Lastverschiebungsmodell-Wrapper 142 und einen Energiespeichermodell-Wrapper 144, die bereitgestellt werden können, um das Lastverschiebungsmodell-Subsystemmodell 132 bzw. das Energiespeichersubsystemmodell 130 zu kapseln und Daten in ein Format zu konvertieren, das auf jedes Subsystemmodell angewendet und von diesem verarbeitet werden kann. Die RL-Schnittstelle 112 kann auch einen RL-Agenten-Wrapper 152 enthalten, der vorgesehen ist, um die Steueragenten 116 zu kapseln und Daten (z. B. Zustände 118, Belohnungsinformationen 148 und Zustandsinformationen 150) in ein Format zu konvertieren, das von den RL-Agenten verarbeitet werden kann.
In 1B zeigt das physikalische System 160 ein schematisches Blockdiagramm eines realen Rechenzentrums 176 und der Umgebung, in der das Rechenzentrum 176 arbeitet. Beispielsweise kann das Rechenzentrum 176 über eine Infrastruktur 164 Energie aus einem Stromnetz 162 beziehen. Das Stromnetz 162 umfasst eine Vielzahl von Energiequellen, wie fossile Brennstoffe, erneuerbare Energiequellen usw. In dem in 1B gezeigten Beispiel umfasst das Stromnetz 162 nicht-erneuerbare Energiequellen, wie z. B. Kohle, Erdgas, Öl, Kernenergie, um nur einige zu nennen. Das Stromnetz 162 umfasst auch erneuerbare Energiequellen, wie z. B. Solarenergie, Wasserkraft, saubere nukleare Energiequellen, Windenergie, Wasserkraft, um nur einige zu nennen.
Das Stromnetz 162 umfasst auch einen oder mehrere Sensoren 168, die so konfiguriert sind, dass sie die Energiepegel im Stromnetz 162 von den verschiedenen Energiequellen überwachen und eine Messung von CI auf der Grundlage der Energiepegel im Stromnetz 162 bestimmen. In einem Beispiel kann CI als durchschnittliche CO₂ -Emissionen gemessen werden, die vom Stromnetz 162 pro von Energieverbrauchern, einschließlich des Rechenzentrums 176, verbrauchter Stromeinheit aus dem Netz 162 erzeugt werden. In einem Beispiel ist die CI-Messung ein externer Faktor, der dem Framework 110 als Eingangsdaten zugeführt werden kann. In einem Beispiel können die Sensoren 168 unter anderem ein Energiezähler sein, der Energieinformationen zur Schätzung des Netz-CI verwendet.
Das physikalische System 160 kann auch Wetterstationssensoren 166 oder Umweltüberwachungsgeräte enthalten, die so konfiguriert sind, dass sie Wetterdaten messen und quantifizieren, um sowohl aktuelle als auch vorhergesagte Wettervorhersagen zu bestimmen. Beispiele für Umgebungsüberwachungsgeräte 166 umfassen unter anderem piezoelektrische Sensoren und/oder Membransensoren zur Erfassung des atmosphärischen Drucks; Temperatursensoren (z. B. Thermoelemente, Widerstandstemperaturdetektoren (RTDs), Thermistoren usw.) zur Messung der Temperatur; Feuchtigkeitssensoren (z. B. Hygrometer und dergleichen) zur Messung der Umgebungsfeuchtigkeit; Sensoren für Windgeschwindigkeit und -richtung (z. B. Anemometer, Aerovane und dergleichen); Niederschlagssensoren (z. B. Regenmesser und dergleichen). In einem Beispiel können die Wetterdaten ein externer Faktor sein, der dem Rahmenwerk 110 als Eingangsdaten zugeführt werden kann.
Das Rechenzentrum 176 empfängt Arbeitslastdaten von Arbeitslastanforderungen 174. Workloads können Aufgaben definieren und Rechenzentrumsressourcen für die Ausführung der Aufgaben anfordern. In einem Beispiel können Arbeitslasten als prozentuale CPU-Auslastung (CPU%) gemessen werden, die auf der Grundlage des für die Ausführung der Arbeitslast erforderlichen Prozentsatzes bestimmt wird. Wie oben angedeutet, kann es sich bei den Arbeitslasten um flexible oder nicht flexible Lasten handeln.
Wie oben beschrieben, kann der Rahmen 110 Richtlinien optimieren, die dem Rechenzentrum 176 als Optimierungsstrategien zur Steuerung der Betriebsbedingungen des Rechenzentrums 176 zur Verfügung gestellt werden können. Im Beispiel von 1B kann der Rahmen 110 die Steueranweisungen mit den optimierten Strategien an die Teilsysteme 170 liefern. Die Steueranweisungen können als Signale bereitgestellt werden, die über das Netzwerk 190 übertragen werden. Wie bereits erwähnt, können die Teilsysteme 170 eine Reihe von Teilsystemen umfassen, wie z. B. ein Kühlungs-Teilsystem 182 (z. B. ein HLK-System), ein Lastverschiebungs-Teilsystem 184 und ein Batterie-Teilsystem 186, ohne darauf beschränkt zu sein. Das Teilsystem 182 für die Kühlung kann einen Temperatursollwert entsprechend den Steueranweisungen des Rahmens 110 einstellen und den Betrieb des HLK-Systems so steuern, dass der Temperatursollwert nicht überschritten wird. Das Lastverschiebungs-Teilsystem 184 kann Steueranweisungen erhalten, die die aktuelle Arbeitslastverteilung optimieren, um die Rechenressourcen zu verwalten. Das Batterie-Subsystem 186 kann Steueranweisungen vom Rahmenwerk 110 empfangen und die Batterien entsprechend den Anweisungen laden und/oder entladen.
Das Rechenzentrum 176 gibt Leistungsindikatoren 180 aus, die auf den Betriebsbedingungen der Teilsysteme 170 basieren. Die ausgegebenen Leistungsindikatoren 180 können unter anderem den Kohlenstoff-Fußabdruck auf der Grundlage der aktuellen Betriebsbedingungen, den Energieverbrauch (z. B. die tatsächlich verbrauchte Energie, gemessen in BTUs, kwh usw.) und die Energiekosten (z. B. ein Produkt des Energieverbrauchs, skaliert mit einem Wert, der die Kosten pro Energieeinheit bestimmt, bezeichnet als Einheitskosten/kwh oder $/kwh) umfassen. Die Output-Leistungsindikatoren 180 werden an das System 110 als Eingangsdaten zurückgemeldet, die Zustände zur weiteren Verfeinerung des RL-Trainings der Steueragenten 116 definieren können.
Das Netzwerk 190 kann ein drahtgebundenes oder drahtloses Netzwerk sein, das den kommunikativen Austausch von Informationen und Daten zwischen dem Rahmen 110 und dem physischen System 160 ermöglicht. Bei dem Netzwerk 190 kann es sich auch um ein öffentliches oder privates Netzwerk wie das Internet oder ein anderes Kommunikationsnetzwerk handeln, das die Verbindung zwischen dem Rahmen 110 und dem physikalischen System 160 ermöglicht. Das Netzwerk 190 kann Telekommunikationsleitungen von Drittanbietern beinhalten, wie z. B. Telefonleitungen, Koaxialkabel, Glasfaserkabel, Satellitenkommunikation, zellulare Kommunikation und ähnliches. Das Netzwerk 190 kann eine beliebige Anzahl von zwischengeschalteten Netzwerkgeräten enthalten, wie z. B. Switches, Router, Gateways, Server und/oder Steuerungen. Das Netzwerk 190 kann verschiedene Server oder andere Computersysteme umfassen, wie z. B. das Computersystem 500 von 5.
2 ist ein schematisches Diagramm der Abhängigkeiten und des Informationsaustauschs zwischen den RL-Agenten 134-138 von 1A. 2 zeigt sowohl interne als auch externe Abhängigkeiten von Aktionsbestimmungen zwischen den RL-Agenten 134-138 von 1A. Pfeile, die auf einen gegebenen RL-Agenten zeigen, stellen externe oder interne Abhängigkeiten dar, die als Eingangszustände fungieren, die sich auf die vom gegebenen RL-Agenten getroffenen Handlungsentscheidungen auswirken. Pfeile, die von einem gegebenen RL-Agenten wegzeigen, stellen Aktionen dar, die von dem gegebenen RL-Agenten bestimmt werden, die, wie in 2 gezeigt, als Eingangszustand für einen anderen RL-Agenten bei der Bestimmung seiner eigenen Aktionen dienen können.
Wie oben beschrieben, mangelt es konventionellen Ansätzen zur Kohlenstoffreduzierung an Echtzeit-Fähigkeiten und an der effektiven Kombination mehrerer Kontrollstrategien aufgrund der komplexen Abhängigkeiten und Ausgleichsziele der konkurrierenden RL-Agenten, wie in 2 dargestellt. Die hier offengelegte Technologie entkoppelt die Reduzierung des CO2-Fußabdrucks teilweise in Teilprobleme. Jeder RL-Agent löst eine individuelle Markov-Entscheidungsprozess-Formulierung (MDP), während individuelle Belohnungen und sich überschneidende Zustandsvariablen in einer Multi-Agenten-Umgebung aggregiert werden, um die komplexen Abhängigkeiten in Echtzeit zu lösen. Dieser Entwurf kann einen umfassenden Echtzeit-Optimierer für den CO2-Fußabdruck nachhaltiger Gesellschaften liefern, der über bestehende Strategien hinausgeht und eine anpassungsfähige und robuste Lösung bietet.
MDP ist ein mathematischer Rahmen, der eine formale Methode zur Modellierung der Entscheidungsfindung in einer dynamischen Umgebung bietet, wie z. B. der Rahmen 110, in dem die Aktionen eines RL-Agenten den Zustand der Umgebung beeinflussen und der Zustand der Umgebung die Belohnungen und einen nachfolgenden Zustand bestimmt. Formal kann ein MDP als ein Tupel (S, A, P, R, y) definiert werden. S ist der Zustandsraum, der alle möglichen Zustände der Umgebung enthält, die in der offengelegten Technologie als Rahmen 110 betrachtet werden können. A ist der Aktionsraum, der alle möglichen Aktionen enthält, die ein gegebener Agent der Umwelt für den Übergang zwischen Zuständen anbieten kann. P ist die Übergangswahrscheinlichkeitsfunktion, die die Wahrscheinlichkeit des Übergangs von einem Zustand in einen anderen Zustand in Abhängigkeit von einer Aktion definiert. R ist die Belohnungsfunktion, die eine Belohnung berechnet, die der Agent für die Durchführung einer Aktion in einem bestimmten Zustand erhält. γ ist ein Abzinsungsfaktor, der die Bedeutung zukünftiger Belohnungen im Vergleich zu unmittelbaren Belohnungen bestimmt.
Zu jedem Zeitpunkt, Schritt t, beobachtet der Agent den aktuellen Zustand s_t ∈ S, und wählt eine Aktion a_t ∈ A auf der Grundlage einer Strategie π (a|s_tt). Die Aktion verändert den Zustand der Umgebung (z. B. Übergänge), und der Agent erhält eine Belohnung r_t = R(s_t, a_t) von der Umgebung auf der Grundlage der Übergangswahrscheinlichkeit P(s_t+1|s, a_tt). Wobei s_t+1 einen nächsten Zustand der Umgebung darstellt, der auf der Aktion a_t basiert, die der RL-Agent im Zustand s_t durchgeführt hat. In einigen Beispielen kann s_t+1 als s_t' dargestellt werden.
Um das MDP zu lösen, können RL-Algorithmen verwendet werden, um die Politik π(a|s_tt) des Agenten zu optimieren. Die Strategie ist eine Funktion, die Zustände auf Aktionen abbildet und das Verhalten des Agenten in der Umgebung bestimmt. Während einer Trainingsphase interagiert der Agent mit der Umwelt, beobachtet den aktuellen Zustand und wählt Aktionen aus, um die Belohnungen zu optimieren. Die Handlungen des Agenten wirken sich auf den Zustand der Umgebung aus, was wiederum die Belohnungen und den nachfolgenden Zustand beeinflusst. Der Agent lernt aus dem Feedback, das ihm die Umwelt in Form von Belohnungen gibt, und passt seine Strategie entsprechend an.
Während die obige Diskussion des allgemeinen MDP-Ansatzes einen Ansatz mit einem einzigen Agenten vorsieht, nutzen die hier offengelegten Implementierungen das MDP, um das Problem der Energie- und CO2-Reduzierung für Rechenzentren anzugehen, indem sie drei voneinander abhängige MDPs berücksichtigen, die die Verlagerung der Arbeitslast, den Energieverbrauch durch Kühlungsoptimierung bzw. die ergänzende Energieversorgung durch Energiespeichersysteme berücksichtigen. Um dies zu erreichen, werden drei MDPs, wie in Tabelle 1 unten beschrieben, konstruiert, eines für jeden RL-Agenten 134-138, die die in 2 zusammengefassten Abhängigkeiten aufweisen: (1) ein Lastverschiebungs-MDP (MDP_LS), das gelöst werden kann, um den Kohlenstoff-Fußabdruck zu reduzieren, indem die Arbeitslasten des Rechenzentrums in kohlenstoffarme Stunden verschoben werden und der Energieverbrauch reduziert wird; (2) ein Energieverbrauchs-MDP (MDP_E ), das gelöst werden kann, um den Energieverbrauch des Rechenzentrums zu reduzieren, indem der Kühlsollwert optimiert wird; und (3) ein Energiespeicher-MDP (MDP_BAT), das gelöst werden kann, um den Kohlenstoff-Fußabdruck zu reduzieren, indem die Batterie auf der Grundlage der Kohlenstoffintensität des Netzes geladen und entladen wird. Der Energieverbrauchs-RL-Agent 134 kann das MDP_E lösen; der Lastverschiebungs-RL-Agent 136 kann das MDP_LS lösen; und der Energiespeicher-RL-Agent 138 kann das MDP_BAT lösen.
Das MDP_E kann wie folgt definiert werden. Der Zustandsraum S kann aus physikalischen und thermischen Betriebsbedingungen des Rechenzentrums (z. B. Rechenzentrum 176) bestehen, die mit s_t ∈ S bezeichnet werden. Dazu können externe Faktoren gehören, wie z. B. die relative Außentemperatur, die Innentemperatur, der Kühlungs-Sollwert, der HLK-Energieverbrauch, der IT-Energieverbrauch (ITE), der Gesamtenergieverbrauch sowie der Tag des Jahres und die Tageszeit. Die externen Faktoren können z. B. vom physischen System 160 über verschiedene Sensoren und Überwachungsgeräte erhalten werden, wie oben im Zusammenhang mit den 1A-1B beschrieben. Der Zustandsraum S kann auch Zustände enthalten, die durch das Kühlsubsystemmodell 120 simuliert werden und von den in 2 dargestellten Abhängigkeiten abhängig sein können. Der Aktionsraum A kann einen diskreten Satz von Delta-Aktionen enthalten, die Änderungen des Kühlungs-Sollwerts des Kühlungs-Teilsystems darstellen, bezeichnet durch _t ∈ A. Beispielhafte Delta-Aktionen können unter anderem {-5, -2, -1, -0,5, 0, 0,5, 1, 2, 5} umfassen, die in Grad Fahrenheit, Celsius, Kelvin usw. angegeben werden. Die Übergangsfunktion P(s_t+1|s_t, a_t) kann durch Lernen der physikalischen und thermischen Eigenschaften des Rechenzentrums, des Kühlungs-Subsystems und der externen Wettervorhersage modelliert werden. Der Sollwert kann durch das Modell des Kühlsubsystems 120 simuliert werden und stellt eine Wahrscheinlichkeit für den Übergang vom Zustand st in den Zustand s_t+1 nach Durchführung der Aktion a_t dar.
Die Belohnungsfunktion r(s_t, a_t) kann einen Anreiz für den RL-Agenten 134 schaffen, den Energieverbrauch und die Gesamtkosten für Strom zu minimieren, indem sie den negativ normierten Gesamtstromverbrauch und den Strompreis multipliziert. Diese Belohnungsfunktion kann als Energienutzungsbelohnung (r_E) bezeichnet werden. Sie ist definiert als r(s_t, a_t)=-c(s_t) · e(s_t, a_t), wobei c(s_t) die Stromkosten und e(s_t, a_t) der Energieverbrauch im Zustand s_t nach Durchführung der Aktion a_t sind. Anders ausgedrückt: r_E = - (Gesamtenergieverbrauch x Kosten pro kWh). Der Diskontierungsfaktor (γ) kann in einigen Beispielen auf 0,99 gesetzt werden, was bedeutet, dass zukünftige Belohnungen als wichtig angesehen werden. Das Ziel des RL-Agenten 134 für den Energieverbrauch besteht darin, eine Strategie π(a_t | s_t) zu erlernen, die die erwartete kumulative Belohnung über die Zeit maximiert. Zur Optimierung der Strategie des Agenten kann ein Algorithmus zur proximalen Strategieoptimierung (PPO) oder ein ähnliches Verfahren verwendet werden.
Während des Trainings interagiert der Energieverbrauchs-RL-Agent 134 mit der simulierten Umgebung (z. B. dem Modell des Kühlsubsystems 120), indem er den aktuellen Zustand s_t beobachtet und Aktionen a_t auswählt, um den Energieverbrauch zu optimieren und die Kosten zu senken. Die vom RL-Agenten 134 durchgeführten Aktionen können den Zustand der Umgebung beeinflussen, was sich wiederum auf die Belohnungen und den nachfolgenden Zustand auswirkt. Der Agent lernt aus den Rückmeldungen, die das Modell des Kühlsubsystems 120 liefert, und passt seine Strategie und Wertfunktion entsprechend an.
Für das MDP_LS formuliert die offengelegte Technologie das Problem als sequentielles MDP, bei dem der Lastverschiebungs-RL-Agent 136 Zugang zu begrenzten Informationen hat. Dies steht im Gegensatz zu herkömmlichen Methoden, die davon ausgehen, dass sie 24 Stunden im Voraus Zugang zu Informationen über die Kohlenstoffintensität und die Arbeitslast haben und einen statischen Greedy-Algorithmus für die Arbeitslastzuweisung verwenden. In diesem Fall hat der Lastverschiebungs-RL-Agent 136 Zugang zu N Stunden zukünftiger Kohlenstoffprognosen. Der Lastverschiebungs-RL-Agent 136 erhält zu Beginn eines jeden Tages eine bestimmte Menge an flexibler Arbeitslast und wählt die optimalen Zeitfenster aus, um die Arbeitslast vor dem Ende des Tages zuzuweisen. Die Kapazität des Rechenzentrums kann begrenzt sein, so dass die Arbeitslast nicht in allen Zeitfenstern zugewiesen werden kann.
Ein Beispiel für ein kohlenstoffbewusstes MDP zur Arbeitslastoptimierung_LS kann wie folgt definiert werden. Der Zustandsraum S kann wie folgt angegeben werden: S:{DC_t, LoadLeft_t, CIt, ..., CI_t+N} wobei DC_t die reale Arbeitslast des Rechenzentrums ist (z. B. erhalten aus Arbeitslastanforderungen 174), LoadLeft_t die Menge flexibler Arbeitslast ist, die den Ressourcen des Rechenzentrums innerhalb eines Zeitraums N zugewiesen werden soll, und CI die aktuelle Kohlenstoffintensität des Netzes und ihre Prognose bis zu einem Zeitschritt t+N ist (z. B. erhalten von einem oder mehreren Sensoren 168). Der Aktionsraum A kann als binärer diskreter Aktionsraum betrachtet werden, in dem ein _t ∈ {0,1} auf dem Lastverschiebungs-RL-Agent 136 die Entscheidung trifft, dem Rechenzentrum im aktuellen Zeitschritt t eine bestimmte Menge an Arbeitslast zuzuweisen, die die maximale Kapazität nicht überschreiten darf, oder im Leerlauf zu bleiben.
Beispielsweise kann die Belohnungsfunktion wie folgt definiert werden: r_t =-(_rcarbon,t + _rpenalty), wobei _rcarbon,t der Netto-Kohlenstoff-Fußabdruck für den Energieverbrauch des Rechenzentrums zum Zeitpunkt t ist (z. B. CO₂ Fußabdruck zum Zeitpunkt t) und _rpenalty eine Lastverschiebungsstrafe zum letzten Zeitschritt eines Tages ist, wenn der Agent die vordefinierte Arbeitslast im gegebenen Zeitrahmen nicht zugewiesen hat, und ansonsten 0. Die Lastverschiebungsstrafe (oder _LSPenalty) kann ein skalarer Wert der nicht zugewiesenen flexiblen Arbeitslast sein, der gewählt wird, um die Zuweisung der nicht zugewiesenen flexiblen Arbeitslast zu veranlassen. Diese Belohnungsfunktion kann als Lastverschiebungs-Belohnungsfunktion (r_LS) bezeichnet werden, die als r_LS = -(CO₂ Fußabdruck+ _LSPenalty) beschrieben werden kann. Um den Netto-Kohlenstoff-Fußabdruck für den Zeitschritt t zu erhalten, kann die aus dem Netz bezogene Nettoenergie (ng_t) auf der Grundlage der Steuerungsentscheidung berechnet und dann mit der entsprechenden Kohlenstoffintensität des Netzes in diesem Zeitschritt t (z. B. CI_t) multipliziert werden. Die Übergangsfunktion p(s_t, a_t, s_t+1) kann auf einem deterministischen Modell beruhen. Es kann eine Grundauslastung vorgesehen werden, die nicht in jedem Zeitschritt flexibel ist. Die Grundlast kann erhöht werden, indem bei jedem Zeitschritt t neue Last aus dem flexiblen Budget zugewiesen wird, bis das flexible Lastbudget leer ist oder das Rechenzentrum seine maximale Kapazität erreicht hat. In einer Beispielimplementierung kann der Zeitrahmen für die Arbeitslastplanung auf ein 24-Stunden-Fenster mit einem Prognosehorizont von N=4 beschränkt werden.
Für die Optimierung der Batterieleistung kann das MDP_BAT wie folgt erstellt werden. Der Zustandsraum kann als S:{Load_dc, Battery_SOC, CI_t, ... , CI_t+N}, wobei Last_dc die momentane Rechenzentrumslast ist, die auf den Aktionen von Agent A_E (z. B. Energieverbrauchs-RL-Agent 134) und der anschließenden Lastverschiebung durch Agent A_LS (z. B. Lastverschiebungs-RL-Agent 136) basiert, Batterie_SOC der Batterieladezustand (SoC) ist und CI der aktuelle CI und seine Prognose bis zu einem Zeitschritt t+N ist. Dabei ist N ein Parameter, der je nach Zuverlässigkeit des Vorhersagemodells gewählt werden kann. In einer Beispielimplementierung kann eine konservative Schätzung von N=4 Stunden verwendet werden. Der Aktionsraum A kann als {i_t, ... , i_t+N}, wobei jedes i_τ für τ ∈ (t, t+N) die möglichen Aktionen des Ladens, Entladens oder Inaktivierens der Batterie in jedem dieser Zeitschritte angibt. Bei jedem Zeitschritt τ plant der RL-Agent 138 für die Energiespeicherung also die nächsten N Schritte. Beim Senden der Aktion an das tatsächliche Batteriesystem im Rechenzentrum 176 kann jedoch die Aktion zum Zeitschritt τ = t verwendet werden.
Die Belohnung kann der Netto-Kohlenstoff-Fußabdruck für die Batterie über die N Schritte auf der Grundlage der obigen Aktionssequenz der Länge N sein. So kann zu jedem Zeitschritt die aus dem Netz entnommene Nettoenergie (ng_τ, τ ∈ (t, t+N)) auf der Grundlage der Aktionssequenz berechnet und mit der entsprechenden Kohlenstoffintensität des Netzes CI_t, ..., CI_t+N zu diesen Zeitpunkten multipliziert werden. Zum Beispiel kann die Belohnung (r_t) aus einem skalaren Punktprodukt eines Vektors der für das Netz bezogenen Nettoenergie $(\bar{n g_{τ}})$
) und einem Vektor der Kohlenstoffintensität im Netz $(C I_{τ}) (z . B . r_{t} (s_{t}, a_{t}) = - \bar{n g_{τ}} \cdot \bar{C I_{τ}}) .$
Diese Belohnungsfunktion kann als Energiespeicher-Belohnungsfunktion (r_BAT) bezeichnet werden, die als r_BAT= - (CO₂ Fußabdruck) beschrieben werden kann. Der Aktionsraum kann als multidiskreter Raum in der Umwelt implementiert werden. Die Übergangsfunktion p(s_t, a_t, s_t+1) basiert auf einem linearen Batteriedegradationsmodell, wie es in der Technik bekannt ist.
Zusätzlich können in einigen Beispielen realistische Lade- und Entladeraten festgelegt werden, um den Batteriebetrieb realistischer zu gestalten. Dies kann durch Ableitung von Lade- und Entladeraten aus Sigmoidkurven für das Batteriespeicher-Subsystem erfolgen. Diese Kurven erzeugen lineare Lade-/Entladeraten unter dem nominalen Batterie-SoC. Die Laderate ist bei niedrigem SoC am höchsten und umgekehrt. In ähnlicher Weise können die Entladeraten bei niedrigem SoC am niedrigsten sein und umgekehrt. Für die Bedarfskurve des Rechenzentrums kann der momentane Bedarf des Rechenzentrums verwendet werden, der auf der optimalen Leistung des Agenten A_E (z. B. Energieverbrauch RL-Agent 134) basieren kann. Die Werte für die Kohlenstoffintensität können auf der Grundlage der momentanen Verfügbarkeit der verschiedenen Energiequellen im Netz geschätzt werden.

In Tabelle 1 sind die oben genannten MDP-Formulierungen zusammengefasst. Tabelle 1

	MDP_LS Flexible Load Shifting	MDP_E Energy HVAC Optimizer	MDP_BAT Battery Agent
State: S_t	Time, DC temperature, IT Load, Unassigned Flexible Load, DC Energy, Carbon Inte nsity, Battery charge	Time, DC temperature, Weather, DC Energy, IT Load, HVAC Setpoint	Time, DC Energy, Battery Charge, Carbon Intensity
Action: A_t	Assign Flexible Load, Idle	HVAC Setpoint	Charge, Supply, Idle
Reward: R_t+1(S_t,A_t)	0.8 * r_LS + 0.1 * T_E + 0.1 * T_BAT	0.1 * T_LS + 0.8 * r_E + 0.1 * T_BAT	0.1r_LS +0.1r_E+ 0.8 * T_BAT

Wie aus den MDP-Beschreibungen in Tabelle 1 hervorgeht, gibt es eine Kette von Abhängigkeiten vom RL-Agenten 136 für die Lastverschiebung über den RL-Agenten 134 für den Energieverbrauch und dann über den RL-Agenten 138 für die Energiespeicherung. Der RL-Agent 134 für den Energieverbrauch entscheidet auf der Grundlage der aktuellen Arbeitslast, der Netz-Cl, des aktuellen Stromverbrauchs des Rechenzentrums und des aktuellen thermischen Zustands des Rechenzentrums, ob die Last verschoben werden soll oder nicht. Die sich daraus ergebende Arbeitslast wird vom RL-Agenten für den Energieverbrauch 134 zusammen mit anderen Variablen, wie z. B. Wettervorhersagen und aktuellem Batterie-SoC, verwendet, um den Energiebetrieb angesichts des Temperatursollwerts zu optimieren. Das Modell des Kühlsubsystems 120 wird dann zur Schätzung des Energieverbrauchs im nächsten Intervall verwendet. Diese Informationen werden zusammen mit dem Netz-Cl vom RL-Agenten 138 für die Energiespeicherung berücksichtigt, um die Batterie über das Stromnetz zu laden oder zu entladen (oder im Leerlauf zu belassen) oder Hilfsstrom zu liefern, um die Netzabhängigkeit zu verringern.
Die mehrstufige und zyklische Abhängigkeit in der obigen Problemformulierung schafft Möglichkeiten für inkrementelle Energie- und CO2-Einsparungen, birgt aber auch einige Herausforderungen in Bezug auf die Trainingskonvergenz für die RL-Agenten. Ein kollaboratives Belohnungssystem, ähnlich dem Multi-Agent Reinforcement Learning (MARL), kann eingesetzt werden, um den RL-Agenten zu helfen, die gemeinsamen Zustandsvariablen, die von anderen MDPs erhalten wurden, den Belohnungen der Agenten zuzuordnen. Der kollaborative Reward-Rahmen, von dem ein Beispiel in Tabelle 1 dargestellt ist, aggregiert die Reward-Funktionen der einzelnen MDPs zu einer kollaborativen Reward-Funktion, die auf jedes MDP zugeschnitten ist. Für eine gegebene MDP-Formulierung ist die Reward-Funktion beispielsweise eine Summierung der einzelnen Reward-Funktionen jeder MDP-Formulierung, wobei jede einzelne Reward-Funktion entsprechend einer vorgegebenen Gewichtung gewichtet wird. Die Gewichtung einer einzelnen Reward-Funktion, die einer bestimmten MDP-Formulierung entspricht, ist größer als die Gewichtung der anderen Reward-Funktionen. Wie in Tabelle 1 gezeigt, beträgt beispielsweise für das MDP_LS die Gewichtung von r_LS 0,8 und die Gewichtung von r_BAT und r_E 0,1. Ähnliche Gewichtungen sind für MDP_E und MDP_BAT angegeben. Hierbei handelt es sich jedoch um anschauliche Beispiele. Es kann jede beliebige Gewichtung angewendet werden, so dass die kollaborative Belohnung w * r + w *r + w_1LS2E3BAT * r ist, wobei w + w + w₁₂₃ = 1.
Außerdem müssen die niedriger gewichteten Belohnungsfunktionen nicht dasselbe Gewicht haben. Im Fall des MDP_LS kann die kollaborative Belohnung beispielsweise w * r + w * r + w_1LS2E3BAT * r sein, wobei w₁ größer ist als w₂ und w₃. In diesem Fall können w₂ und w₃ den gleichen Wert haben oder unterschiedlich sein und w₂ kann größer oder kleiner als w₃ sein. Beispielsweise kann die kollaborative Belohnung für das MDP_LS 0,7*r_LS + ,1*r_E + ,2*r_BAT sein. Die Gewichte für die anderen MDPs können nach ähnlichen Prinzipien implementiert werden.
3 ist ein schematisches Blockdiagramm eines Beispielprozesses 300 von RL in Übereinstimmung mit Implementierungen der vorliegenden Offenbarung. Prozess 300 veranschaulicht einen verallgemeinerten Multi-Agent-Reinforcement-Learning-Algorithmus (MARL) Prozess, der vom Framework 110 unter Verwendung der oben beschriebenen MDP-Formulierungen ausgeführt wird: MDP_LS, MDP_E, und MDP_BAT Ziel des Prozesses 300 ist es, dass die RL-Agenten 134-136 eine Strategie erlernen, die den gesamten Kohlenstoff-Fußabdruck des Rechenzentrums (z. B. des Rechenzentrums 176) in Echtzeit optimal reduziert, indem sie die mehreren MDPs im digitalen Zwilling 114 gleichzeitig lösen.
Prozess 300 bietet ein Beispiel für Verstärkungslernen, das von den Steueragenten 116 durchgeführt wird, um optimale Strategien zu erlernen, die individuell zugeschnittene kollaborative Belohnungsfunktionen auf der Grundlage von diskreten Belohnungen maximieren, die von einem digitalen Zwilling 114 erhalten werden. Zu den Steueragenten 116 gehören beispielsweise RL-Agenten 134-138, die als ML-Algorithmen bereitgestellt werden können, die mit den entsprechenden Subsystemmodellen des digitalen Zwillings 114 in diskreten Zeitschritten über den RL-Agenten-Wrapper 152 (in 3 nicht dargestellt) interagieren. Zu jedem Zeitpunkt t erhält jeder RL-Agent aktuelle Zustandsinformationen 150 und Belohnungsinformationen 148 von den entsprechenden Teilsystemmodellen des digitalen Zwillings 114. Die Zustandsinformationen 150 können auch externe Informationen enthalten, die aus der realen Umgebung bezogen werden, wie z. B. Wettervorhersagen, Cl-Vorhersagen und Prognosen zur Arbeitsbelastung.
Jeder RL-Agent 134-138 wählt eine Aktion 146 aus einer Reihe verfügbarer Aktionen aus, die an die entsprechenden Subsystemmodelle des digitalen Zwillings 114 gesendet wird. Der digitale Zwilling 114 wechselt in einen neuen Zustand (z. B. geht jedes Teilsystem auf der Grundlage der empfangenen Aktionen in einen neuen Zustand über) und bestimmt eine aktualisierte Belohnungsinformation, die mit dem Übergang verbunden ist. Beispielsweise berechnet der RL-Agent 134-138 Aktionen 146, die an das Kühlungs-Teilsystemmodell 120, das Energiespeicher-Teilsystemmodell 130 bzw. das Lastverschiebungsmodell-Teilsystemmodell 132 (in 3 nicht dargestellt) gesendet werden, was jedes Teilsystemmodell veranlasst, in einen neuen Zustand überzugehen und eine diskrete Belohnung für diesen neuen Zustand zu berechnen (z. B. r_LS, r_E und r_BAT). Die aktualisierten Zustände und Belohnungsinformationen werden dann an die RL-Agenten 134-138 zurückgegeben, von denen jeder eine individuell zugeschnittene kollaborative Belohnung wie oben beschrieben berechnet und seine Strategie aktualisiert. Die RL-Agenten 134-138 berechnen dann eine nächste Aktion für den nächsten Zeitschritt t+N. Das Ziel der RL-Agenten 134-138 ist es, Strategien zu erlernen, die ihre entsprechende kollaborative Belohnungsfunktion maximieren.
Im Einzelnen kann eine systematische Implementierung der Mehrfachagenten durchgeführt werden, die die in 2 dargestellten Abhängigkeiten zwischen den einzelnen Agentenaktionen und den nächsten Zuständen berücksichtigt. Der RL-Agent 136 für die Lastverschiebung, der RL-Agent 134 für den Energieverbrauch und der RL-Agent 138 für die Energiespeicherung können gleichzeitig für die optimale Lastverschiebung (MDP_LS), die Energieoptimierung (MDP_E) bzw. den optimalen Batteriebetrieb (MDP_BAT) initialisiert werden. Zu diesem Zeitpunkt kann der digitale Zwilling 114 initialisiert werden, einschließlich des Kühlungs-Teilsystemmodells 120, des Energiespeicher-Teilsystemmodells 130 und des Lastverschiebungsmodell-Teilsystemmodells 132. Zustandsvariablen, wie z. B. die Temperatur des Rechenzentrums, die gesamte IT-Arbeitslast, die nicht zugewiesene flexible Last, der Energieverbrauch des Rechenzentrums und die Batterie-SoC-Informationen können vom digitalen Zwilling 114 und/oder dem Rechenzentrum 176 abgerufen und in einer Datenbank 314 als Zustandsinformationen 150 gespeichert werden. Die Zustandsinformationen können durch das Kühlungs-Subsystemmodell 120, das Energiespeicher-Subsystemmodell 130 und das Lastverschiebungsmodell-Subsystemmodell 132 abgeleitet und der Datenbank 314 zur Speicherung zur Verfügung gestellt werden. Netzdaten, wie z. B. Kohlenstoffintensität, Wetterbedingungen und Daten zur Auslastung des Rechenzentrums, können ebenfalls in der Datenbank 314 als Zustandsinformationen 150 für jeden Zeitpunkt gespeichert werden. Diese Zustandsinformationen 150 können somit von den RL-Agenten 134-138 gemeinsam genutzt werden. In Echtzeit interagiert jeder RL-Agent 134-138 mit seinem jeweiligen MDP, um Rollout-Informationen (S_t, A_t, S_t', R_t+1, γ, done) in den jeweiligen Speicherpuffern 334, 336 und 338 zu sammeln. Beachten Sie, dass S_t' mit S_t+1 austauschbar ist, wie oben beschrieben. „Done“ ist ein boolesches Flag, das in RL verwendet wird, um die Beendigung einer Episode anzuzeigen, die die Dauer eines Rollouts sein kann und von der Umgebung/MDP bestimmt werden kann. Beispiele für die Rollout-Informationen sind in Tabelle 1 aufgeführt. Wie hier verwendet, kann sich „interagieren“ auf den RL-Agenten beziehen, der Aktionen auf dem MDP ausführt (nicht löst), um Rollout-Informationen als Ausgabe zu erhalten. Der Begriff „lösen“ kann im RL-Sprachgebrauch eine andere Bedeutung haben, wobei in den hier verwendeten RL-Methoden ein RL-Agent das MDP nicht direkt, sondern indirekt durch Interaktion mit dem MDP und Bildung einer internen Darstellung des MDP lösen kann.
Im Betrieb fragt der Lastverschiebungs-RL-Agent 136 die Zustandsinformationen 150 nach Zeit und Netzkohlenstoffintensität ab. Der Lastverschiebungs-RL-Agent 136 erhält die nicht zugewiesene flexible Last aus dem MDP_LS; der Energieverbrauchs-RL-Agent 134 erhält die Temperatur des Rechenzentrums, die aktuelle IT-Last und den Energieverbrauch des Rechenzentrums aus dem MDP_E; und der Energiespeicher-RL-Agent 138 erhält die Batterie-SoC-Informationen aus dem MDP_BAT. Der Lastverschiebungs-RL-Agent 136 verwendet diese Informationen, um zu entscheiden, ob er die flexible Last von diesem Zeitschritt auf einen anderen Zeitschritt umverteilt oder im Leerlauf bleibt. Die daraus resultierenden IT-Lastinformationen werden an den RL-Agenten 134 für den Energieverbrauch weitergegeben. Der Energieverbrauchs-RL-Agent 134 verwendet die Zeit sowie die Temperatur des Rechenzentrums, den Energieverbrauch des Rechenzentrums und den Temperatursollwert, die er aus einem vorherigen Zeitschritt des MDP_E erhalten hat, um einen Sollwert für den aktuellen Zeitschritt festzulegen. Das Kühlungs-Subsystemmodell 120 des digitalen Zwillings 114 berechnet eine resultierende Änderung des Energieverbrauchs und der Temperatur des Rechenzentrums, die das Kühlungs-Subsystemmodell 120 an das MDP_E zurückmeldet. Der RL-Agent 138 für die Energiespeicherung erhält die Zeit, den Energieverbrauch des Rechenzentrums von der MDP_E, den aktuellen Ladezustand der Batterie und die Informationen zur Kohlenstoffintensität, um zu entscheiden, ob die Batterie vom Netz geladen, die Batterie entladen werden soll, um den Energiebedarf des digitalen Zwillings 114 zu ergänzen, oder ob sie im Leerlauf bleiben soll.
In einem Beispiel legen die RL-Agenten 134-138 ihre jeweiligen Aktionen fest und geben die Aktionen im selben Zeitschritt an die Umwelt ab. Die Aktionen können jedoch in einer bestimmten Reihenfolge an der Umgebung ausgeführt werden. In einer Beispielimplementierung kann die Reihenfolge Lastverschiebungsteilsystem, Kühlungsteilsystem und Batteriespeicherteilsystem sein. In einem anderen Beispiel kann die Reihenfolge je nach der gewünschten Anwendung unterschiedlich sein.
In einer anderen Beispielimplementierung können die RL-Agenten bei jedem Rollout-Schritt (z. B. bei jedem Zeitschritt) einen Schritt der Interaktion mit ihren jeweiligen MDPs abschließen, wodurch ein asynchrones, gleichzeitiges Rollout entsteht. Aus Sicht der Implementierung dieses Beispiels müssen die einzelnen RL-Agenten das Rollout-Informationstupel nicht sofort nach der Durchführung einer Aktion erhalten. Sie können warten, bis sie wieder an der Reihe sind, eine Aktion zu bestimmen und auszuführen. Diese Wartezeit kann es ermöglichen, die Auswirkungen früherer Aktionen der anderen RL-Agenten in alle MDPs einzubeziehen, was dazu genutzt werden kann, die individuell zugeschnittene kollaborative Belohnung jedes RL-Agenten zu bestimmen. Das heißt, in jedem Zeitschritt kann jeder RL-Agent mit seinem jeweiligen MDP interagieren, um eine individuell zugeschnittene kollaborative Belohnung zu berechnen, die als Grundlage für die Aktionen des nächsten Zeitschritts verwendet werden kann. Die individuell zugeschnittenen kollaborativen Belohnungen berücksichtigen also die Auswirkungen der Aktionen aller RL-Agenten. Diese hierarchische Formulierung ist auch in Tabelle 1 dargestellt und ermöglicht es den RL-Agenten, die Auswirkungen ihrer individuellen Handlungen in voneinander abhängigen MDPs zu berücksichtigen.
In regelmäßigen Abständen können die in den Speicherpuffern 334, 336 und 338 gespeicherten Daten zur Aktualisierung der Strategien der einzelnen Agenten verwendet werden. In einer Beispielimplementierung können die Richtlinien mithilfe eines PPO-Algorithmus aktualisiert werden, um eine dezentrale Richtlinie und eine dezentrale Kritik (Wertfunktion) zu lernen. In diesem Fall interagiert jeder RL-Agent über seine individuell zugeschnittene kollaborative Belohnungsfunktion und gemeinsame Zustandsinformationen, weiß aber ansonsten nichts von den Aktionen der anderen Agenten. Es kann jedoch auch jeder andere Off-Policy- oder Policy-Gradient-Algorithmus verwendet werden. Einige Implementierungen können beispielsweise einen Multi-Agent Deep Deterministic Policy Gradient (MADDPG) Algorithmus verwenden, der den Deep Deterministic Policy Gradient (DDPG) Algorithmus zu einem Multi-Agent Policy Gradient Algorithmus erweitert, bei dem dezentralisierte Agenten einen zentralen Kritiker auf der Grundlage der Beobachtungen und Aktionen aller Agenten lernen. Hier bezieht sich ein Kritiker auf einen Teil einer Klasse von RL-Algorithmen, die aus einem Akteur und einem Kritiker bestehen. Der Akteur (oder die Politik) entscheidet über die Aktionen, während der Kritiker ein Maß dafür liefert, wie gut oder schlecht die Aktionen sind (z.B. die Belohnung), um die Politik zu informieren. In diesem Beispielfall verwenden die gelernten Strategien lokale Informationen jedes entsprechenden Akteurs während der Testzeit und nicht die Informationen anderer Akteure. Allerdings kann jeder Akteur die Beobachtungen und Aktionen aller drei Akteure nutzen.
Im Folgenden wird ein Beispielalgorithmus für das Training der RL-Agenten 134-138 in Pseudocode dargestellt:
4 zeigt ein Beispiel für eine Computerkomponente, die verwendet werden kann, um die Reduzierung des CO2-Fußabdrucks eines Systems in Übereinstimmung mit verschiedenen Ausführungsformen zu realisieren. Wie in 4 dargestellt, kann die Rechnerkomponente 400 beispielsweise ein Server-Computer, ein Controller oder eine andere ähnliche Rechnerkomponente sein, die Daten verarbeiten kann. In der Beispielimplementierung von 4 umfasst die Rechnerkomponente 400 einen Hardwareprozessor 402 und ein maschinenlesbares Speichermedium 404.
Bei dem Hardware-Prozessor 402 kann es sich um eine oder mehrere Zentraleinheiten (CPUs), halbleiterbasierte Mikroprozessoren und/oder andere Hardwarevorrichtungen handeln, die sich für den Abruf und die Ausführung von Anweisungen eignen, die auf dem maschinenlesbaren Speichermedium 404 gespeichert sind. Der Hardware-Prozessor 402 kann Befehle, wie die Befehle 406-412, abrufen, dekodieren und ausführen, um Prozesse oder Vorgänge zur Reduzierung des CO2-Fußabdrucks zu steuern. Alternativ oder zusätzlich zum Abrufen und Ausführen von Befehlen kann der Hardware-Prozessor 402 einen oder mehrere elektronische Schaltkreise enthalten, die elektronische Komponenten zur Ausführung der Funktionalität eines oder mehrerer Befehle umfassen, wie z. B. ein Field Programmable Gate Array (FPGA), einen anwendungsspezifischen integrierten Schaltkreis (ASIC) oder andere elektronische Schaltkreise.
Ein maschinenlesbares Speichermedium, wie das maschinenlesbare Speichermedium 404, kann ein beliebiges elektronisches, magnetisches, optisches oder anderes physikalisches Speichergerät sein, das ausführbare Anweisungen enthält oder speichert. Bei dem maschinenlesbaren Speichermedium 404 kann es sich beispielsweise um einen Direktzugriffsspeicher (RAM), einen nichtflüchtigen RAM (NVRAM), einen elektrisch löschbaren programmierbaren Festspeicher (EEPROM), ein Speichergerät, eine optische Platte oder ähnliches handeln. In einigen Ausführungsformen kann das maschinenlesbare Speichermedium 404 ein nichttransitorisches Speichermedium sein, wobei der Begriff „nicht-transitorisch“ nicht die transitorischen Übertragungssignale umfasst. Wie nachstehend im Detail beschrieben, kann das maschinenlesbare Speichermedium 404 mit ausführbaren Befehlen kodiert sein, zum Beispiel mit den Befehlen 406-412.
Der Hardware-Prozessor 402 kann den Befehl 406 ausführen, um Zustandsdaten zu erhalten, die für die Zustände des Systems repräsentativ sind. Das System umfasst eine Vielzahl von Subsystemen.
Bei dem System kann es sich beispielsweise um ein Rechenzentrum handeln, das ein Teilsystem zur Kühlung, ein Teilsystem zur Lastverlagerung und ein Teilsystem zur Energiespeicherung umfasst. Die Zustandsdaten können als Betriebsbedingungen aus dem physischen Rechenzentrum gewonnen werden, zum Beispiel von Sensoren, die die Betriebsbedingungen des Rechenzentrums überwachen. Die Zustandsdaten können gemäß einigen Beispielen interne Zustände des Systems und externe Zustände einer Umgebung für das System umfassen. Die internen Zustände können eines oder mehrere der folgenden Elemente umfassen: zugewiesene Arbeitslast, nicht zugewiesene Arbeitslast, Temperatur des Systems, Energieverbrauch des Systems und vom System gespeicherte Energie. Die externen Zustände können einen oder mehrere der folgenden Punkte umfassen: Netzkohlenstoffintensität, Wetter und Tageszeit.
Der Hardware-Prozessor 402 kann die Anweisung 408 ausführen, um durch eine Vielzahl von RL-Agenten Belohnungsdaten aus einem digitalen Zwilling des Systems zu empfangen, der die Operationen des Systems simuliert. Die Belohnungsdaten umfassen eine Vielzahl von Belohnungen, die jeweils mit einem Teilsystem der Vielzahl von Teilsystemen verbunden sind.
Der digitale Zwilling kann zum Beispiel eine Simulation des Rechenzentrums sein, wie oben in Verbindung mit den 1A und 1B beschrieben. Der digitale Zwilling kann Zustandsdaten empfangen, die den digitalen Zwilling so konfigurieren, dass er die Betriebsbedingungen des aktuellen Zustands des Rechenzentrums simuliert, Der digitale Zwilling kann auch Aktionsdaten empfangen, die einen Übergang zwischen den Zuständen des digitalen Zwillings simulieren. Basierend auf dem Übergang kann der digitale Zwilling Belohnungsdaten generieren, die repräsentativ für die Effektivität der Aktionen sind. Der digitale Zwilling kann die Belohnungsdaten der Vielzahl von RL-Agenten zum Training der RL-Agenten zur Verfügung stellen.
Jedes Teilsystem des digitalen Zwillings kann eine entsprechende Belohnung erzeugen, die in den Belohnungsdaten enthalten sein kann, die jedem der mehreren RL-Agenten zur Verfügung gestellt werden. Zum Beispiel kann eine erste Belohnung aus der Vielzahl der Belohnungen, die dem Teilsystem Kühlung entspricht, auf einer Simulation des Energieverbrauchs des Modells des Teilsystems Kühlung (z. B. des digitalen Zwillings des Teilsystems Kühlung) und einer Simulation der Energiekosten beruhen. Eine zweite Belohnung aus der Vielzahl der Belohnungen, die einem Lastverschiebungs-Teilsystemmodell entspricht, kann auf einem Kohlenstoff-Fußabdruck basieren, der sich aus einer Simulation eines Lastverschiebungs-Teilsystemmodells (z. B. eines digitalen Zwillings des Lastverschiebungs-Teilsystemmodells) und einer nicht zugewiesenen flexiblen Arbeitslast ergibt. Eine dritte Belohnung aus der Vielzahl der Belohnungen, die dem Energiespeicher-Subsystem entspricht, kann auf einer Simulation eines Kohlenstoff-Fußabdrucks des Energiespeicher-Subsystems durch das Energiespeicher-Subsystemmodell (z. B. digitaler Zwilling des Energiespeicher-Subsystems) basieren.
Der Hardware-Prozessor 402 kann den Befehl 410 ausführen, um eine Vielzahl von Aktionen durch die Vielzahl von RL-Agenten auf der Grundlage der Zustandsdaten und jeder der Vielzahl von Belohnungen zu bestimmen. Jeder RL-Agent der Vielzahl von RL-Agenten kann einem Subsystem der Vielzahl von Subsystemen zugeordnet sein und weist einer Belohnung der Vielzahl von Belohnungen, die dem zugeordneten Subsystem entsprechen, ein Gewicht zu, das größer ist als die Gewichte, die den Belohnungen zugeordnet sind, die den anderen Subsystemen entsprechen. Auf diese Weise können die einzelnen Belohnungen jedes Teilsystemmodells zu einer kollaborativen Belohnung aggregiert werden, die individuell auf jeden RL-Agenten zugeschnitten ist. Die individuell zugeschnittenen kollaborativen Belohnungen können repräsentativ für die Effektivität der von jedem RL-Agenten durchgeführten Aktionen sein, und zwar nicht nur für das entsprechende System, sondern auch für das System als Ganzes, indem die mit anderen Teilsystemen verbundenen Belohnungen berücksichtigt werden.
Wie oben in Verbindung mit 1A und 1B beschrieben, kann die Mehrzahl der RL-Agenten einen Energieverbrauchs-RL-Agenten, einen Lastverschiebungs-RL-Agenten und einen Energiespeicher-RL-Agenten umfassen, die jeweils einem Kühlteilsystem, einem Lastverschiebungs-Teilsystem und einem Energiespeicher-Teilsystem entsprechen. Die verschiedenen Teilsysteme sind voneinander abhängig, und als solche sind die RL-Agenten so konfiguriert, dass sie Aktionen sowohl in Abhängigkeit von den vorherigen Belohnungen als auch von Aktionen des anderen Teilsystems bestimmen.
In einigen Beispielen kann die vom Agenten für verstärkendes Lernen im Zusammenhang mit dem Teilsystem Kühlung bestimmte Aktion ein Kühlungs-Sollwert für das Teilsystem Kühlung sein. Eine Aktion, die von dem mit dem Lastverschiebungs-Subsystem assoziierten verstärkenden Lernagenten bestimmt wird, kann eine Zuweisung der Arbeitslast sein. Eine Aktion, die von dem mit dem Energiespeicher-Subsystem verbundenen Agenten für verstärkendes Lernen bestimmt wird, kann eine Lade- oder Entlademenge für das Energiespeicher-Subsystem sein.
In einem Beispiel bestimmen die Agenten mit verstärktem Lernen ihre jeweiligen Aktionen und geben die Aktionen im gleichen Zeitschritt aus. Die Aktionen können auf die Umgebung in der Reihenfolge Lastverschiebungs-Teilsystem, Kühlungs-Teilsystem und Batteriespeicher-Teilsystem ausgeführt werden.
Der Hardware-Prozessor 402 kann die Anweisung 412 ausführen, um das System entsprechend der Vielzahl von Aktionen in aktualisierte Zustände zu überführen. Beispielsweise können von den RL-Agenten Steueranweisungen generiert werden, die optimale Strategien darstellen, die von RL auf der Grundlage der individuell zugeschnittenen kollaborativen Belohnungen gelernt wurden. Die Steueranweisungen können an das System (z. B. das Rechenzentrum) übertragen werden, um die Betriebsbedingungen des Systems so zu konfigurieren, dass das System in einen aktualisierten Zustand übergeht, der den Kohlenstoff-Fußabdruck des Systems im Hinblick auf die aktuellen internen und externen Zustände optimiert. So können flexible Arbeitslasten im Hinblick auf die Netz-Kl und Batteriespeichersysteme SoC sowie Kühlstrategien im Hinblick auf das kommende Wetter zugewiesen werden. Darüber hinaus können die Kühlsubsysteme so gesteuert werden, dass sie die Temperatur auf der Grundlage der zugewiesenen Arbeitslast (sowohl flexibel als auch unflexibel) sowie unter Berücksichtigung der aktuellen Netz-Cl und der Batterie-SoC regulieren. Darüber hinaus kann das Batteriespeichersystem so optimiert werden, dass die Batterien bei niedrigem Netz-Cl geladen und bei hohem Netz-CI entladen werden, je nach Stromverbrauch des Rechenzentrums.
5 zeigt ein Blockdiagramm eines beispielhaften Computersystems 500, in dem verschiedene der hier beschriebenen Ausführungsformen implementiert werden können. Das Computersystem 500 umfasst einen Bus 502 oder einen anderen Kommunikationsmechanismus zur Übermittlung von Informationen sowie einen oder mehrere Hardware-Prozessoren 504, die mit dem Bus 502 zur Verarbeitung von Informationen verbunden sind. Bei dem/den Hardware-Prozessor(en) 504 kann es sich zum Beispiel um einen oder mehrere Allzweck-Mikroprozessoren handeln.
Das Computersystem 500 umfasst auch einen Hauptspeicher 506, wie z. B. einen Speicher mit wahlfreiem Zugriff (RAM), einen Cache und/oder andere dynamische Speichergeräte, die mit dem Bus 502 verbunden sind, um Informationen und Anweisungen zu speichern, die vom Prozessor 504 ausgeführt werden sollen. Der Hauptspeicher 506 kann auch zum Speichern temporärer Variablen oder anderer Zwischeninformationen während der Ausführung von Befehlen verwendet werden, die vom Prozessor 504 ausgeführt werden sollen. Solche Befehle, die in Speichermedien gespeichert werden, auf die der Prozessor 504 zugreifen kann, machen das Computersystem 500 zu einer Spezialmaschine, die für die Ausführung der in den Befehlen angegebenen Operationen angepasst ist. Im Hauptspeicher 506 können Informationen gespeichert werden, die maschinenlesbare Befehle für die Bereitstellung der Funktionalität des Rahmens 110 enthalten, wie z. B. der digitale Zwilling 114 und die darin enthaltenen Subsystemmodelle, Steueragenten 116 und andere Komponenten des Rahmens 110.
Das Computersystem 500 umfasst außerdem einen Festwertspeicher (ROM) 508 oder ein anderes statisches Speichergerät, das mit dem Bus 502 verbunden ist, um statische Informationen und Anweisungen für den Prozessor 504 zu speichern. Ein Speichergerät 510, z. B. eine Magnetplatte, eine optische Platte oder ein USB-Stick (Flash-Laufwerk) usw., ist vorgesehen und mit dem Bus 502 verbunden, um Informationen und Anweisungen zu speichern.
Das Computersystem 500 kann über den Bus 502 mit einer Anzeige 512, z. B. einer Flüssigkristallanzeige (LCD) (oder einem Touchscreen), verbunden sein, um einem Computerbenutzer Informationen anzuzeigen. Ein Eingabegerät 514, einschließlich alphanumerischer und anderer Tasten, ist mit dem Bus 502 gekoppelt, um Informationen und Befehlsauswahlen an den Prozessor 504 zu übermitteln. Eine andere Art von Benutzereingabegerät ist die Cursorsteuerung 516, wie z. B. eine Maus, ein Trackball oder Cursorrichtungstasten zur Übermittlung von Richtungsinformationen und Befehlsauswahlen an den Prozessor 504 und zur Steuerung der Cursorbewegung auf der Anzeige 512. In einigen Ausführungsformen können die gleichen Richtungsinformationen und Befehlsauswahlen wie bei der Cursorsteuerung über den Empfang von Berührungen auf einem Touchscreen ohne Cursor implementiert werden.
In einigen Implementierungen kann die Eingabevorrichtung 514 Ports oder andere Eingabeschnittstellen für den Empfang von Eingabedaten von einem realen System, wie dem physischen System 160 und den darin befindlichen Sensoren/loT-Geräten, umfassen. So kann die Eingabevorrichtung 514 Eingabedaten einschließlich interner Zustände und externer Faktoren empfangen, wie oben in Verbindung mit den 1A und 1B beschrieben.
Das Computersystem 500 kann ein Benutzerschnittstellenmodul zur Implementierung einer grafischen Benutzeroberfläche enthalten, das in einem Massenspeichergerät als ausführbare Softwarecodes gespeichert werden kann, die von dem/den Computergerät(en) ausgeführt werden. Dieses und andere Module können beispielsweise Komponenten wie Softwarekomponenten, objektorientierte Softwarekomponenten, Klassenkomponenten und Aufgabenkomponenten, Prozesse, Funktionen, Attribute, Prozeduren, Unterprogramme, Segmente von Programmcode, Treiber, Firmware, Mikrocode, Schaltkreise, Daten, Datenbanken, Datenstrukturen, Tabellen, Arrays und Variablen umfassen.
Im Allgemeinen kann sich das Wort „Komponente“, „Engine“, „System“, „Datenbank“, „Datenspeicher“ und dergleichen, wie es hier verwendet wird, auf eine in Hardware oder Firmware verkörperte Logik oder auf eine Sammlung von Softwareanweisungen beziehen, die möglicherweise Ein- und Ausstiegspunkte haben und in einer Programmiersprache wie z. B. Java, C oder C++ geschrieben sind. Eine Softwarekomponente kann kompiliert und zu einem ausführbaren Programm verknüpft werden, in einer dynamischen Link-Bibliothek installiert werden oder in einer interpretierten Programmiersprache wie BASIC, Perl oder Python geschrieben sein. Es ist klar, dass Softwarekomponenten von anderen Komponenten oder von sich selbst aus aufgerufen werden können und/oder als Reaktion auf erkannte Ereignisse oder Unterbrechungen aufgerufen werden können. Softwarekomponenten, die für die Ausführung auf Computergeräten konfiguriert sind, können auf einem computerlesbaren Medium, wie z. B. einer Compact Disc, einer digitalen Videodisc, einem Flash-Laufwerk, einer Magnetplatte oder einem anderen greifbaren Medium, oder als digitaler Download bereitgestellt werden (und können ursprünglich in einem komprimierten oder installierbaren Format gespeichert sein, das vor der Ausführung eine Installation, Dekomprimierung oder Entschlüsselung erfordert). Ein solcher Softwarecode kann teilweise oder vollständig in einem Speicher des ausführenden Computergeräts gespeichert werden, damit er von dem Computergerät ausgeführt werden kann. Softwareanweisungen können in Firmware, wie z. B. einem EPROM, eingebettet sein. Darüber hinaus können die Hardwarekomponenten aus verbundenen Logikeinheiten wie Gattern und Flipflops und/oder aus programmierbaren Einheiten wie programmierbaren Gatteranordnungen oder Prozessoren bestehen.
Das Computersystem 500 kann die hier beschriebenen Techniken unter Verwendung von kundenspezifischer festverdrahteter Logik, einem oder mehreren ASICs oder FPGAs, Firmware und/oder Programmlogik implementieren, die in Kombination mit dem Computersystem das Computersystem 500 zu einer Spezialmaschine macht oder programmiert. Gemäß einer Ausführungsform werden die hierin beschriebenen Techniken vom Computersystem 500 als Reaktion auf den/die Prozessor(en) 504 ausgeführt, der/die eine oder mehrere Sequenzen von einem oder mehreren im Hauptspeicher 506 enthaltenen Befehlen ausführt/ausführen. Solche Anweisungen können in den Hauptspeicher 506 von einem anderen Speichermedium, wie z. B. einem Speichergerät 510, eingelesen werden. Die Ausführung der im Hauptspeicher 506 enthaltenen Befehlssequenzen veranlasst den/die Prozessor(en) 504, die hier beschriebenen Prozessschritte durchzuführen. In alternativen Ausführungsformen können fest verdrahtete Schaltungen anstelle von oder in Kombination mit Softwareanweisungen verwendet werden.
Der Begriff „nichtflüchtige Medien“ und ähnliche Begriffe, wie sie hier verwendet werden, beziehen sich auf alle Medien, die Daten und/oder Befehle speichern, die eine Maschine in einer bestimmten Weise arbeiten lassen. Solche nichtflüchtigen Medien können nichtflüchtige Medien und/oder flüchtige Medien umfassen. Zu den nichtflüchtigen Medien gehören beispielsweise optische oder magnetische Festplatten, wie das Speichergerät 510. Zu den flüchtigen Medien gehören dynamische Speicher, wie der Hauptspeicher 506. Zu den gängigen Formen nichtflüchtiger Medien gehören beispielsweise Disketten, flexible Platten, Festplatten, Solid-State-Laufwerke, Magnetbänder oder andere magnetische Datenspeichermedien, CD-ROMs, andere optische Datenspeichermedien, physische Medien mit Lochmustern, RAM, PROM und EPROM, FLASH-EPROM, NVRAM, andere Speicherchips oder -kassetten sowie deren vernetzte Versionen.
Nicht-transitorische Medien unterscheiden sich von Übertragungsmedien, können aber in Verbindung mit ihnen verwendet werden. Übertragungsmedien sind an der Übertragung von Informationen zwischen nicht-transitorischen Medien beteiligt. Zu den Übertragungsmedien gehören z. B. Koaxialkabel, Kupfer- und Glasfaserkabel, einschließlich der Drähte, aus denen der Bus 502 besteht. Übertragungsmedien können auch in Form von Schall- oder Lichtwellen auftreten, wie sie bei der Datenkommunikation über Funk und Infrarot erzeugt werden.
Das Computersystem 500 umfasst auch eine Netzwerkschnittstelle 518, die mit dem Bus 502 verbunden ist. Die Netzwerkschnittstelle 518 stellt eine Zweiwege-Datenkommunikationsverbindung zu einer oder mehreren Netzwerkverbindungen her, die mit einem oder mehreren lokalen Netzwerken verbunden sind. Bei der Kommunikationsschnittstelle 518 kann es sich beispielsweise um eine ISDN-Karte (Integrated Services Digital Network), ein Kabelmodem, ein Satellitenmodem oder ein Modem handeln, um eine Datenkommunikationsverbindung zu einer entsprechenden Art von Telefonleitung herzustellen. Als weiteres Beispiel kann die Netzwerkschnittstelle 518 eine LAN-Karte sein, um eine Datenkommunikationsverbindung zu einem kompatiblen LAN (oder einer WAN-Komponente zur Kommunikation mit einem WAN) herzustellen. Es können auch drahtlose Verbindungen implementiert werden. In jeder dieser Implementierungen sendet und empfängt die Netzwerkschnittstelle 518 elektrische, elektromagnetische oder optische Signale, die digitale Datenströme mit verschiedenen Informationstypen übertragen.
Die Kommunikationsschnittstelle 518 kann Eingabeschnittstellen für den Empfang von Eingabedaten von einem realen System, wie dem physischen System 160 und den darin befindlichen Sensoren/IoT-Geräten, über ein Netzwerk (z. B. Netzwerk 190) sein. So kann die Netzwerkschnittstelle 518 Eingabedaten empfangen, einschließlich interner Zustände und externer Faktoren, wie oben in Verbindung mit den beschrieben.
Eine Netzverbindung ermöglicht in der Regel die Datenkommunikation über ein oder mehrere Netze zu anderen Datengeräten. So kann eine Netzverbindung beispielsweise eine Verbindung über ein lokales Netz zu einem Host-Computer oder zu Datengeräten eines Internetdienstanbieters (ISP) herstellen. Der ISP wiederum bietet Datenkommunikationsdienste über das weltweite Paketdatenkommunikationsnetz an, das heute gemeinhin als „Internet“ bezeichnet wird. Sowohl das lokale Netz als auch das Internet verwenden elektrische, elektromagnetische oder optische Signale, die digitale Datenströme übertragen. Die Signale über die verschiedenen Netze und die Signale auf der Netzverbindung und über die Kommunikationsschnittstelle 518, die die digitalen Daten zum und vom Computersystem 500 übertragen, sind Beispiele für Übertragungsmedien.
Das Computersystem 500 kann über das/die Netzwerk(e), die Netzwerkverbindung und die Kommunikationsschnittstelle 518 Nachrichten senden und Daten, einschließlich Programmcode, empfangen. In dem Internet-Beispiel könnte ein Server einen angeforderten Code für ein Anwendungsprogramm über das Internet, den ISP, das lokale Netzwerk und die Kommunikationsschnittstelle 518 übertragen.
Der empfangene Code kann durch den Prozessor 504 ausgeführt werden, sobald er empfangen wird, und/oder im Speichergerät 510 oder einem anderen nichtflüchtigen Speicher zur späteren Ausführung gespeichert werden.
Jeder der in den vorangegangenen Abschnitten beschriebenen Prozesse, Methoden und Algorithmen kann in Code-Komponenten verkörpert und vollständig oder teilweise durch diese automatisiert werden, die von einem oder mehreren Computersystemen oder Computerprozessoren mit Computerhardware ausgeführt werden. Das eine oder die mehreren Computersysteme oder Computerprozessoren können auch so betrieben werden, dass sie die Ausführung der entsprechenden Vorgänge in einer „Cloud Computing“-Umgebung oder als „Software as a Service“ (SaaS) unterstützen. Die Prozesse und Algorithmen können teilweise oder vollständig in anwendungsspezifischen Schaltkreisen implementiert sein. Die verschiedenen oben beschriebenen Merkmale und Verfahren können unabhängig voneinander verwendet oder auf verschiedene Weise kombiniert werden. Verschiedene Kombinationen und Unterkombinationen sollen in den Anwendungsbereich dieser Offenbarung fallen, und bestimmte Verfahrens- oder Prozessblöcke können in einigen Implementierungen weggelassen werden. Die hier beschriebenen Methoden und Prozesse sind auch nicht auf eine bestimmte Reihenfolge beschränkt, und die damit verbundenen Blöcke oder Zustände können in anderen geeigneten Reihenfolgen, parallel oder auf andere Weise ausgeführt werden. Blöcke oder Zustände können zu den offengelegten Beispielen hinzugefügt oder aus ihnen entfernt werden. Die Ausführung bestimmter Operationen oder Prozesse kann auf Computersysteme oder Computerprozessoren verteilt werden, die sich nicht nur in einer einzigen Maschine befinden, sondern über eine Reihe von Maschinen verteilt sind.
Eine Schaltung kann in jeder Form von Hardware, Software oder einer Kombination davon implementiert werden. Beispielsweise können ein oder mehrere Prozessoren, Controller, ASICs, PLAs, PALs, CPLDs, FPGAs, logische Komponenten, Software-Routinen oder andere Mechanismen implementiert werden, um eine Schaltung zu bilden. Bei der Implementierung können die verschiedenen hier beschriebenen Schaltungen als diskrete Schaltungen implementiert werden, oder die beschriebenen Funktionen und Merkmale können teilweise oder insgesamt auf eine oder mehrere Schaltungen aufgeteilt werden. Auch wenn verschiedene Merkmale oder Funktionselemente einzeln als separate Schaltungen beschrieben oder beansprucht werden, können diese Merkmale und Funktionen von einer oder mehreren gemeinsamen Schaltungen gemeinsam genutzt werden, und eine solche Beschreibung soll nicht voraussetzen oder implizieren, dass separate Schaltungen erforderlich sind, um diese Merkmale oder Funktionen zu implementieren. Wenn eine Schaltung ganz oder teilweise mit Software implementiert ist, kann diese Software so implementiert werden, dass sie mit einem Computer- oder Verarbeitungssystem arbeitet, das in der Lage ist, die in Bezug auf sie beschriebene Funktionalität auszuführen, wie z. B. das Computersystem 500.
Wie hierin verwendet, kann der Begriff „oder“ sowohl im einschließenden als auch im ausschließenden Sinne verstanden werden. Darüber hinaus ist die Beschreibung von Ressourcen, Vorgängen oder Strukturen im Singular nicht so zu verstehen, dass der Plural ausgeschlossen wird. Bedingte Ausdrücke wie z. B. „kann“, „könnte“, „könnte“ oder „kann“, sofern nicht ausdrücklich anders angegeben oder im Kontext anders verstanden, sollen im Allgemeinen zum Ausdruck bringen, dass bestimmte Ausführungsformen bestimmte Merkmale, Elemente und/oder Schritte enthalten, während andere Ausführungsformen diese nicht enthalten.
Die in diesem Dokument verwendeten Begriffe und Ausdrücke sowie deren Abwandlungen sind, sofern nicht ausdrücklich etwas anderes angegeben ist, nicht als einschränkend, sondern als offen zu verstehen. Adjektive wie „konventionell“, „traditionell“, „normal“, „Standard“, „bekannt“ und Begriffe mit ähnlicher Bedeutung sind nicht so zu verstehen, dass sie den beschriebenen Gegenstand auf einen bestimmten Zeitraum oder auf einen zu einem bestimmten Zeitpunkt verfügbaren Gegenstand beschränken, sondern sollten so verstanden werden, dass sie konventionelle, traditionelle, normale oder Standardtechnologien umfassen, die jetzt oder zu einem beliebigen Zeitpunkt in der Zukunft verfügbar oder bekannt sein können. Das Vorhandensein erweiternder Wörter und Formulierungen wie „eine oder mehrere“, „mindestens“, „aber nicht beschränkt auf“ oder ähnlicher Formulierungen in einigen Fällen ist nicht so zu verstehen, dass der engere Fall beabsichtigt oder erforderlich ist, wenn solche erweiternden Formulierungen nicht vorhanden sind.
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-Anmeldung Nr. 63/504,664 [0001]

Claims

Ein Verfahren, das Folgendes umfasst: Erhalten von Zustandsdaten, die für die Zustände des Systems repräsentativ sind, wobei das System eine Vielzahl von Subsystemen umfasst; Empfangen von Belohnungsdaten von einem digitalen Zwilling des Systems, der die Operationen des Systems simuliert, durch eine Vielzahl von Agenten des verstärkenden Lernens, wobei die Belohnungsdaten eine Vielzahl von Belohnungen umfassen, die jeweils mit einem Teilsystem der Vielzahl von Teilsystemen verbunden sind; Bestimmen einer Vielzahl von Aktionen durch die Vielzahl von Verstärkungs-Lern-Agenten, basierend auf den Zustandsdaten und jeder der Vielzahl von Belohnungen, wobei jeder Verstärkungs-Lern-Agent der Vielzahl von Verstärkungs-Lern-Agenten mit einem Subsystem der Vielzahl von Subsystemen assoziiert ist und einer Belohnung der Vielzahl von Belohnungen, die einem assoziierten Subsystem der Vielzahl von Subsystemen entspricht, ein Gewicht zuordnet, das größer ist als die Gewichte, die den Belohnungen zugeordnet sind, die anderen Subsystemen der Vielzahl von Subsystemen entsprechen; und Übergang des Systems in aktualisierte Zustände entsprechend der Vielzahl von Aktionen.
Verfahren nach Anspruch 1, wobei das System ein Rechenzentrum ist.
Verfahren nach Anspruch 1, wobei die mehreren Teilsysteme ein Kühlteilsystem, ein Lastverschiebungs-Teilsystem und ein Energiespeicher-Teilsystem umfassen.
Verfahren nach Anspruch 3, wobei eine erste Belohnung aus der Vielzahl der Belohnungen, die dem Kühlungs-Teilsystem entspricht, auf einem Maß für die vom System verbrauchte Energie und den Energiekosten basiert, wobei eine zweite Belohnung aus der Vielzahl der Belohnungen, die dem Lastverschiebungs-Teilsystem entspricht, auf einem Kohlenstoff-Fußabdruck des Lastverschiebungs-Teilsystems und der nicht zugewiesenen Arbeitslast basiert, und wobei eine dritte Belohnung aus der Vielzahl der Belohnungen, die dem Energiespeicher-Teilsystem entspricht, auf einem Kohlenstoff-Fußabdruck des Energiespeicher-Teilsystems basiert.
Verfahren nach Anspruch 3, bei dem eine Aktion, die von einem mit dem Kühlsubsystem assoziierten Verstärkungslernagenten bestimmt wird, von einer Aktion abhängt, die von einem mit dem Lastverschiebungssubsystem assoziierten Verstärkungslernagenten bestimmt wird, und von einer Aktion, die von einem mit dem Energiespeicher-Subsystem assoziierten Verstärkungslernagenten bestimmt wird.
Verfahren nach Anspruch 3, wobei eine Aktion, die von einem mit dem Kühlungs-Subsystem assoziierten Verstärkungs-Lern-Agenten bestimmt wird, ein Kühlungs-Sollwert für das System ist, wobei eine Aktion, die von einem mit dem Lastverschiebungs-Subsystem assoziierten Verstärkungs-Lern-Agenten bestimmt wird, eine Zuweisung der Arbeitslast ist, und wobei eine Aktion, die von einem mit dem Energiespeicher-Subsystem assoziierten Verstärkungs-Lern-Agenten bestimmt wird, ein Lade- oder Entladebetrag ist.
Verfahren nach Anspruch 3, wobei eine Aktion, die von einem mit dem Lastverschiebungs-Subsystem assoziierten Verstärkungs-Lernagenten bestimmt wird, von einer Aktion abhängt, die von einem mit dem Kühlungs-Subsystem assoziierten Verstärkungs-Lernagenten bestimmt wird, und von einer Aktion, die von einem mit dem Energiespeicher-Subsystem assoziierten Verstärkungs-Lernagenten bestimmt wird.
Verfahren nach Anspruch 3, bei dem eine Aktion, die von einem mit dem Energiespeicher-Subsystem assoziierten Verstärkungs-Lernagenten bestimmt wird, von einer Aktion abhängt, die von einem mit dem Kühl-Subsystem assoziierten Verstärkungs-Lernagenten bestimmt wird, und von einer Aktion, die von einem mit dem Lastverschiebungs-Subsystem assoziierten Verstärkungs-Lernagenten bestimmt wird.
Verfahren nach Anspruch 1, wobei die Zustandsdaten interne Zustände des Systems und Umgebungszustände einer Umgebung für das System umfassen, wobei die internen Zustände eines oder mehrere der folgenden Elemente umfassen: zugewiesene Arbeitslast, nicht zugewiesene Arbeitslast, Temperatur des Systems, Energieverbrauch des Systems und vom System gespeicherte Energie, und wobei die Umgebungszustände eines oder mehrere der folgenden Elemente umfassen: Netzkohlenstoffintensität, Wetter und Zeit.
Ein System zur Reduzierung des Kohlenstoff-Fußabdrucks eines Systems, das Folgendes umfasst: einen Speicher, der Anweisungen speichert; und einen oder mehrere Prozessoren, die mit dem Speicher verbunden und so konfiguriert sind, dass sie die Anweisungen ausführen, um: Erhalt von Zustandsdaten, die für die Zustände des Systems repräsentativ sind, wobei das System eine Vielzahl von Subsystemen umfasst; Empfangen von Belohnungsdaten von einem digitalen Zwilling des Systems, der den Betrieb des Systems simuliert, wobei die Belohnungsdaten eine Vielzahl von Belohnungen umfassen, die jeweils mit einem Teilsystem der Vielzahl von Teilsystemen verbunden sind; Bestimmen einer Vielzahl von Aktionen durch eine Vielzahl von Verstärkungs-Lern-Agenten, basierend auf den Zustandsdaten und jeder der Vielzahl von Belohnungen, wobei jeder Verstärkungs-Lern-Agent der Vielzahl von Verstärkungs-Lern-Agenten mit einem Subsystem der Vielzahl von Subsystemen assoziiert ist und einer Belohnung der Vielzahl von Belohnungen, die einem assoziierten Subsystem der Vielzahl von Subsystemen entspricht, ein Gewicht zuordnet, das größer ist als die Gewichte, die den Belohnungen zugeordnet sind, die den anderen Subsystemen der Vielzahl von Subsystemen entsprechen; und Übergang des Systems in aktualisierte Zustände entsprechend der Vielzahl von Aktionen.
System nach Anspruch 10, wobei es sich bei dem System um ein Rechenzentrum handelt und die mehreren Teilsysteme ein Kühlteilsystem, ein Lastverschiebungs-Teilsystem und ein Energiespeicher-Teilsystem umfassen.
System nach Anspruch 11, bei dem eine Aktion, die von einem mit dem Kühlsubsystem assoziierten Verstärkungslernagenten bestimmt wird, von einer Aktion abhängt, die von einem mit dem Lastverschiebungs-Subsystem assoziierten Verstärkungslernagenten bestimmt wird, und von einer Aktion, die von einem mit dem Energiespeicher-Subsystem assoziierten Verstärkungslernagenten bestimmt wird.
System nach Anspruch 11, wobei eine Aktion, die von einem mit dem Kühlungs-Subsystem assoziierten Verstärkungs-Lernagenten bestimmt wird, ein Kühlungs-Sollwert für das System ist, wobei eine Aktion, die von einem mit dem Lastverschiebungs-Subsystem assoziierten Verstärkungs-Lernagenten bestimmt wird, eine Zuweisung der Arbeitslast ist, und wobei eine Aktion, die von einem mit dem Energiespeicher-Subsystem assoziierten Verstärkungs-Lernagenten bestimmt wird, eine Lade- oder Entladungsmenge ist.
System nach Anspruch 11, wobei eine Aktion, die von einem dem Lastverschiebungs-Subsystem zugeordneten Verstärkungs-Lernagenten bestimmt wird, von einer Aktion abhängt, die von einem dem Kühlungs-Subsystem zugeordneten Verstärkungs-Lernagenten bestimmt wird, und von einer Aktion, die von einem dem Energiespeicher-Subsystem zugeordneten Verstärkungs-Lernagenten bestimmt wird.
System nach Anspruch 11, bei dem eine Aktion, die von einem mit dem Energiespeicher-Subsystem assoziierten Verstärkungslernagenten bestimmt wird, von einer Aktion abhängt, die von einem mit dem Kühl-Subsystem assoziierten Verstärkungslernagenten bestimmt wird, und von einer Aktion, die von einem mit dem Lastverschiebungs-Subsystem assoziierten Verstärkungslernagenten bestimmt wird.
System nach Anspruch 10, wobei die Zustandsdaten interne Zustände des Systems und Umgebungszustände einer Umgebung für das System umfassen, wobei die internen Zustände eines oder mehrere der folgenden Elemente umfassen: zugewiesene Arbeitslast, nicht zugewiesene Arbeitslast, Temperatur des Systems, Energieverbrauch des Systems und vom System gespeicherte Energie, und wobei die Umgebungszustände eines oder mehrere der folgenden Elemente umfassen: Netzkohlenstoffintensität, Wetter und Zeit.
Ein System, das Folgendes umfasst: einen digitalen Zwilling eines Rechenzentrums, wobei der digitale Zwilling eine Vielzahl von Subsystemmodellen umfasst, die einer Vielzahl von Subsystemen des Rechenzentrums entsprechen, und konfiguriert ist, um Zustände für jedes Subsystemmodell zu simulieren und Belohnungen für jedes Subsystemmodell zu bestimmen; und eine Vielzahl von Agenten für Verstärkungslernen, die mit dem digitalen Zwilling verbunden sind und so konfiguriert sind, dass sie: die simulierten Zustände und die Belohnungen von einem digitalen Zwilling erhalten, die Belohnungen zu aggregieren, und Bestimmen von Aktionen für jedes Teilsystemmodell auf der Grundlage der aggregierten Belohnungen, und Erzeugen von Steuersignalen für jedes Teilsystem entsprechend den bestimmten Aktionen, wobei das Datenzentrum auf der Grundlage der Steuersignale konfiguriert wird.
System nach Anspruch 17, wobei die Vielzahl von Teilsystemmodellen ein Kühlungs-Teilsystemmodell, ein Lastverschiebungs-Teilsystemmodell und ein Energiespeicher-Teilsystemmodell umfasst.
System nach Anspruch 17, wobei jeder Verstärkungs-Lern-Agent der Vielzahl von Verstärkungs-Lern-Agenten mit einem Subsystem-Modell der Vielzahl von Subsystem-Modellen verbunden ist, und wobei das Aggregieren der Belohnungen umfasst: durch jeden Verstärkungs-Lern-Agenten der Vielzahl von Verstärkungs-Lern-Agenten einer Belohnung der Belohnungen, die durch ein zugehöriges Teilsystemmodell bestimmt wurden, ein Gewicht zuweisen, das größer ist als die Gewichte, die den Belohnungen zugewiesen wurden, die durch die anderen Teilsystemmodelle bestimmt wurden.
System nach Anspruch 17 umfasst außerdem: Empfangen von Umgebungszuständen einer Umgebung für das Datenzentrum, wobei die Umgebungszustände eines oder mehrere der Elemente Netzkohlenstoffintensität, Wetter und Zeit umfassen, wobei die simulierten Zustände eines oder mehrere der folgenden Elemente umfassen: zugewiesene Arbeitslast, nicht zugewiesene Arbeitslast, Temperatur des Rechenzentrums, Energieverbrauch des Rechenzentrums und vom Rechenzentrum gespeicherte Energie.