Die Challenges
4 Challenges. ~20 Teams. Hardware wird bereitgestellt. Ihr programmiert die Logik. Beste Lösung gewinnt.
Was ist ein Sihlicon Hub?
Einfache Erklärungen für alle, die noch nie von Active Energy Nodes gehört haben.
Ein Sihlicon Hub ist wie ein intelligentes Energiesystem, das viel mehr kann als nur heizen. Stell dir vor: Du hast eine Solaranlage auf dem Dach, die tagsüber viel Energie produziert. Normalerweise geht diese Energie ins Netz oder wird verschwendet.
Ein Sihlicon Hub nutzt diese Energie intelligent:
- Batterie: Speichert Sonnenenergie für die Nacht
- Computer: Erledigt Aufgaben, wenn viel Solar-Energie da ist
- Wärme: Die Abwärme vom Computer heizt dein Haus
- Resilienz: Bei Stromausfall versorgt die Batterie dein Quartier
Es ist kein "Wasserkocher" – es ist ein Aktiver Energie-Knoten, der alle diese Funktionen intelligent kombiniert.
Die Schweiz braucht mehr dezentrale Energie-Infrastruktur. Statt riesige Rechenzentren zu bauen, die Flüsse erhitzen, können wir kleine, intelligente Systeme in geeigneten Räumen installieren, die Häuser heizen und gleichzeitig Computer-Aufgaben erledigen.
Energie-Souveränität: Wir werden weniger abhängig von grossen Energie-Konzernen und Cloud-Anbietern. Jeder kann seinen eigenen kleinen Energie-Knoten betreiben.
Resilienz: Wenn das Stromnetz ausfällt, können Nachbarschaften sich gegenseitig mit Energie versorgen. Die Batterien im Hub werden zu Notstromquellen.
Effizienz: Statt Computer-Abwärme zu verschwenden, nutzen wir sie zum Heizen. Das ist viel effizienter als separate Systeme.
3 Tage, 4 Challenges: Jedes Team wählt ein Challenge-Paket und programmiert daran. Hardware wird bereitgestellt – ihr schreibt die Grid-OS Logik. Mehrere Teams arbeiten parallel am gleichen Paket – die beste Lösung gewinnt.
Simulation-to-Reality: Ihr entwickelt gegen den Sihl-Sim (Digital Twin) lokal, testet auf dem 5V Safety Avatar, und finalisiert auf der supervised Reference Hardware. Kein Pfad ist "richtig" – nur Trade-offs.
Euer Code: Alles, was ihr programmiert, gehört euch. Hardware-Designs unter CERN-OHL-P/MIT (vollständig frei), Grid-OS Code unter SVG-L (schützt das Netz). Ihr könnt es forken, kommerzialisieren, oder in eurem eigenen Projekt nutzen. Wir ermutigen das.→ Mehr zum Dual-Lizenz-Modell
Preisgeld: Alle vier Challenges sind gleichwertig. Teilnahmegebühren fließen in den Prize Pool. Bewertung durch Jury nach technischer Qualität, Vollständigkeit, und Integration.
Übersicht
Vier Challenges bauen aufeinander auf: Von lokalen Sensoren über Multi-Node-Koordination bis zur Grid-Integration und rechtlichen Grundlagen.
⚠️ Pro Team nur 1 Challenge
- • Temperatursensoren auslesen und kalibrieren
- • Thermische Daten in Echtzeit verarbeiten
- • Lokale Speicherung der Sensor-Logs
- • Node Dashboard für Monitoring bauen
- • Mehrere Nodes koordinieren und synchronisieren
- • Failover-Logik bei Ausfall eines Nodes
- • Netzwerk-Synchronisation zwischen LEGs
- • Koordinations-Dashboard für Überwachung
- • Load Balancing über mehrere LEG-Gruppen
- • VPP Integration für Strommarkt-Teilnahme
- • Inter-LEG Compute Credits: Hubs handeln Rechenkapazität in kWh
- • System Dashboard für Gesamtübersicht
- • LEG-Statuten und Vertragsvorlagen erstellen
- • StromVG/EnG Compliance sicherstellen
- • Hardware Reuse (CE-Kennzeichnung, PrSG)
- • Haftungsklärung und Versicherungsfragen
Jedes Team wählt eine Ebene. Die inneren Schichten (Sensoren) liefern Daten für die äußeren Schichten (Grid-OS). Rechtliche Grundlagen (LEG) ermöglichen das Gesamtsystem.
🍿 Snackathons (OPTIONAL · CHF 80)
Pilot-Events im Frühling 2026 · Alle Details →
Spezialeinheit · Mit Bewerbung
Drei Pfade. Euer Team entscheidet.
Kein Pfad ist "richtig". Nur Trade-offs. Ihr evaluiert und wählt.
Der Öltank
Immersion Cooling
Server baden in dielektrischem Öl. Lautlos, effizient, fast 100% Wärmeabfuhr. Aber: Öl muss gehandhabt werden. Brandschutz ist real. Wartung ist komplex.
Pro
- + 99% Wärmeabfuhr
- + Lautlos
- + GPU-Lebensdauer
Contra
- − Öl-Handling
- − Brandschutz
- − Komplexe Wartung
Die Server-Komponenten (CPU, GPU) werden vollständig in spezielles, nicht-leitfähiges Öl getaucht. Das Öl leitet Wärme direkt von den Chips ab – viel effizienter als Luftkühlung. Es ist wie ein Ölbad für Computer: Die Wärme wird direkt ins Öl übertragen und dann über einen Wärmetauscher ins Heizungssystem geleitet.
Wähle diesen Pfad, wenn:
- Du maximale Wärmeausbeute brauchst (99%)
- Lautlosigkeit wichtig ist (keine Lüfter)
- Du bereit bist, mit Öl-Handling umzugehen
- Du professionelle Wartung planst
Öl-Handling: Dielektrisches Öl (z.B. Midel 7131) muss fachgerecht gehandhabt werden. Leckagen müssen sofort erkannt werden.
⚠️ Spezifische Risiken:
- • Öl-Leckage: Umweltverschmutzung, Rutschgefahr
- • Brandrisiko: Öl ist brennbar (Flashpoint >200°C)
- • Öl-Dämpfe: Gesundheitsrisiko bei Einatmung
✓ Schutzmassnahmen:
- • Leckwanne (Auffangbehälter) für alle Ölsysteme
- • Brandschutzsystem kompatibel mit Öl
- • Belüftungssystem für Dampf-Abzug
Brandschutz: Öl ist brennbar. Leckwannen, Brandschutz-Massnahmen und Not-Aus-Schalter sind Pflicht.
Wartung: Komplexer als Wasser-Systeme. Öl muss regelmässig überprüft und eventuell gewechselt werden.
Die Wasserschleife
Direct-to-Chip
Direct-to-Chip Kühlung mit Standard-Komponenten. Bewährt, verfügbar, reparierbar. Aber: Nur 60-70% Wärmeabfuhr. Nicht so elegant.
Pro
- + Bewährte Technik
- + Standard-Teile
- + Einfache Reparatur
Contra
- − 60-70% Capture
- − Leckage-Risiko
- − Pumpen-Geräusch
Kühlwasser wird direkt auf die CPU/GPU-Chips geleitet über spezielle Kühlplatten. Die Wärme wird ins Wasser übertragen und dann über einen Wärmetauscher ins Heizungssystem. Es ist wie eine Auto-Kühlung: Bewährt, Standard-Komponenten, einfach zu reparieren. Aber nicht alle Wärme wird erfasst – ein Teil geht über die Luft verloren.
Wähle diesen Pfad, wenn:
- Du bewährte, einfache Technik bevorzugst
- Standard-Komponenten wichtig sind (einfache Beschaffung)
- Einfache Wartung und Reparatur Priorität haben
- 60-70% Wärmeausbeute ausreichend ist
Wärmeausbeute: Nur 60-70% der Wärme wird erfasst. Der Rest geht über die Luft verloren. Nicht so effizient wie Immersion.
Leckage-Risiko: Wasser und Elektronik sind eine gefährliche Kombination. Leckwannen und Überwachung sind Pflicht.
⚠️ Spezifische Risiken:
- • Elektrokontakt: Wasser + Strom = Lebensgefahr (tödliche Ströme möglich)
- • Leckage: Wasserschaden, Kurzschluss, Systemausfall
- • Pumpen-Ausfall: Führt zu Überhitzung und möglichem Systemausfall
✓ Schutzmassnahmen:
- • Vollständig isolierte Systeme (Wasser nie in Kontakt mit Strom)
- • Leckage-Erkennungssensoren mit sofortiger Abschaltung
- • Redundante Pumpen für Ausfallsicherheit
- • RCD/GFCI-Schutz für alle wassernahen Systeme
Geräusch: Pumpen machen Geräusche. Nicht so lautlos wie Immersion-Cooling.
Der Boost
Heat Pump Integration
Server-Wärme (45-55°C) als Quelle für eine Wärmepumpe. Wird auf 70°C+ gehoben, genug für Radiatoren. Aber: Komplexität und COP-Trade-offs.
Pro
- + 70°C+ Output
- + Radiator-tauglich
- + Höchste Nutzung
Contra
- − Komplexität
- − Strom für Pumpe
- − COP-Verluste
Die Abwärme vom Server (45-55°C) wird als Quelle für eine Wärmepumpe genutzt. Die Pumpe "pumpt" die Temperatur auf 70°C+ hoch – genug für normale Radiatoren. Es ist wie eine umgekehrte Klimaanlage: Statt Kälte zu erzeugen, erzeugt sie höhere Wärme. Die höchste Nutzung der Server-Wärme, aber auch die komplexeste Lösung.
Wähle diesen Pfad, wenn:
- Du hohe Temperaturen brauchst (70°C+ für Radiatoren)
- Maximale Wärmenutzung wichtig ist
- Du bereit bist, mit komplexer Technik umzugehen
- Du die zusätzlichen Kosten für die Wärmepumpe akzeptierst
Komplexität: Wärmepumpen sind komplexe Systeme. Mehr Komponenten = mehr Fehlerquellen. Professionelle Installation empfohlen.
⚠️ Spezifische Risiken:
- • Hochdruck: Kältemittel unter hohem Druck (professionelle Überwachung erforderlich)
- • Kältemittel-Austritt: Umweltgefahr, Gesundheitsrisiko, Ozonabbau
- • Komplexe Fehlerketten: Mehrere Systeme müssen zusammenarbeiten
✓ Schutzmassnahmen:
- • Druck-Überwachung mit automatischer Abschaltung
- • Dichtheitsprüfung vor Inbetriebnahme
- • Professionelle Installation durch zertifizierte Techniker
- • Redundante Sicherheitssysteme
Stromverbrauch: Die Wärmepumpe braucht selbst Strom. COP (Coefficient of Performance) bestimmt, wie effizient das ist. COP 3 = 1 kWh Strom erzeugt 3 kWh Wärme.
Kosten: Wärmepumpen sind teuer. Die Investition muss sich durch höhere Wärmenutzung lohnen.
Profis vor Ort, damit ihr euch auf die Lösung konzentrieren könnt.
Details zu allen Challenges
Jedes Team wählt eine Challenge als Hauptfokus. Mehrere Teams arbeiten parallel an der gleichen Challenge. Beste Lösung gewinnt.
Sensor Integration
Sensor-Daten-Pipelines mit Live-Monitoring, Daten-Validierung, Dual-Topic-Migration (`sihlhack/*`/`sihlhub/*`) und API-Integration.
End-to-End Demo-Kit
Messbarer Energie-Flow mit reproduzierbarer Ein-Knopf-Demo
📖 Erklärung
Sensor Integration bedeutet: Du baust Daten-Pipelines, die alle Sensoren (Temperatur, Durchfluss, Leistung, Batterie) verbinden und die Daten in Echtzeit überwachen. Zusätzlich baust du ein Dashboard mit echten Live-Daten (keine Fake-Visualisierungen). Es ist wie das Nervensystem des Systems – es sammelt alle Informationen und zeigt sie transparent an.
Ohne Sensor-Daten kann das System nicht intelligent reagieren. Sensor Integration ist die Grundlage für Grid-OS Logik und Multi-Node Safety Koordination – beide brauchen zuverlässige, validierte Sensordaten. Das Dashboard macht das System transparent und vertrauenswürdig.
Du baust Sensor-Daten-Pipelines, die alle Sensoren (Temp, Flow, Power, Battery SOC) verbinden, ein Real-Time Monitoring Dashboard (nur echte Daten, kein Fake), ein Data Validation Framework, API-Integration mit Grid-OS, und CSV/JSON Export für alle Metriken.
Funktionsweise
Sensor-Daten werden über I2C/SPI gesammelt, über MQTT/Mosquitto übertragen, in InfluxDB gespeichert und in Echtzeit visualisiert (WebSockets). Während der Migration werden `sihlhack/*` (kanonisch) und `sihlhub/*` (legacy) verarbeitet. Das Data-Validation-Framework stellt sicher, dass alle Sensordaten korrekt sind.
Architektur
Sensor-Layer (I2C/SPI) → Data Pipeline (MQTT: `sihlhack/*` + `sihlhub/*`) → InfluxDB → Data Validation → Real-Time Dashboard (WebSockets + React/Vue) → CSV/JSON Export → API Integration (Grid-OS)
Integration
Integriert mit Reference-Hardware-Sensoren, Grid-OS-Logik (Scheduling), Multi-Node-Safety-Koordination (Anomalie-Erkennung) und Dashboard als Truth-Layer mit echten Daten.
📦 Deliverables
- ✓Sensor Data Pipeline (Temp, Flow, Power, Battery SOC)
- ✓Real-Time Monitoring Dashboard (nur echte Daten)
- ✓Data Validation Framework
- ✓API Integration mit Grid-OS
- ✓Sensor-Map mit Kalibrierhinweisen
- ✓CSV/JSON Export für alle Metriken
📊 Bewertungskriterien
🔧 Empfohlene Open-Source Tools
Metriken-Sammlung fuer P_solar, P_compute, Temperaturen
GitHub →Time-Series DB fuer Sensor-Zeitreihen und Alert-Auswertung
GitHub →IoT-Plattform mit Inverter-APIs (Fronius, SMA)
GitHub →MQTT-Broker fuer Sensor-Kommunikation
GitHub →Multi-Node Safety Koordination
Multi-Node-Sicherheitsverriegelungen, Anomalie-Erkennungs-Algorithmen, Not-Aus-Logik und netzwerkweite Sensor-Validierung.
Hardware Safety & Thermal Baseline
BOM, Safety Case und thermische Charakterisierung
📖 Erklärung
Multi-Node Safety Koordination bedeutet: Du programmierst Software-Sicherheitsverriegelungen, die mehrere Nodes koordiniert sichern. Es ist wie ein verteilter Sicherheitswächter – die Software synchronisiert Safety-Checks über mehrere Nodes und erkennt Ausfälle im Netzwerk.
Sicherheit ist nicht verhandelbar. Ein System aus mehreren verbundenen Nodes braucht koordinierte Safety-Massnahmen. Multi-Node Safety Koordination stellt sicher, dass Ausfälle einzelner Nodes keine Gefahr für das Gesamtnetz darstellen.
Du programmierst Multi-Node-Sicherheitsverriegelungen: Netzwerkweite Anomalie-Erkennung, Emergency Stop Logik mit Failover, verteilte Sensor-Validierung, und Inter-Node Safety Interlocks. Alles API-basiert.
Funktionsweise
Multi-Node-Anomalie-Erkennungs-Algorithmen synchronisieren Safety-Checks über mehrere Nodes und erkennen verteilte Fehler. Emergency-Stop-Logik koordiniert Abschaltungen über Nodes mit Failover-Mechanismen. Netzwerkweite Sensor-Validierung erkennt ausgefallene Nodes. Vor jeder Aktorik wird eine fail-closed Safety-Clearance geprüft.
Architektur
Multi-Node Sensor Input → Distributed Anomaly Detection → Inter-Node Safety Interlocks (Zephyr RTOS/Python + Network Sync) → Coordinated Emergency Stop → API Integration (Multiple Nodes)
Integration
Integriert mit Sensor Integration Package (alle Nodes), Grid-OS Logik (Scheduler-Koordination), und Reference Hardware über standardisierte APIs. Safety-Funktionen sind verteilt und netzwerkfähig.
📦 Deliverables
- ✓Safety Interlock Software (Anomalie-Erkennung)
- ✓Emergency Stop Logic
- ✓Sensor Validation Framework
- ✓Safety Case (Software-basiert)
- ✓Integration mit Reference Hardware
📊 Bewertungskriterien
Grid-OS Logik
Scheduler-Entwicklung mit Solar-Budget-Algorithmen, Deferred Compute Logik und Load Shedding Policies.
Grid-OS Minimal Controller
Scheduler mit Solar-Budget, Fallback-Policy und API
📖 Erklärung
Grid-OS Logik ist das "Gehirn" des Systems. Es entscheidet intelligent, wann Computer-Aufgaben laufen, wann die Batterie geladen wird, und wann Wärme produziert wird. Du programmierst den Scheduler, der Solar-Budget berechnet und Compute-Jobs entsprechend plant.
Ohne intelligente Steuerung wäre das System nur ein passives Heizsystem. Grid-OS Logik macht es intelligent: Es nutzt Sonnenenergie optimal, verschiebt Computer-Aufgaben auf Zeiten mit viel Solar (Deferred Compute), und kann bei Netzproblemen automatisch reagieren (Load Shedding).
Du programmierst einen Scheduler mit Solar-Budget-Algorithmen, Deferred Compute Logik, und Load Shedding Policies. Dazu kommt inter-LEG Compute Credit Scheduling: Hubs inserieren verfügbare Rechenkapazität in kWh, andere Hubs können diese für Jobs beanspruchen. Das System entwickelt gegen den Sihl-Sim (Digital Twin), testet auf dem Safety Avatar, und deployt auf der supervised Reference Hardware.
Funktionsweise
Der Scheduler liest Solar-Budget von Inverter-APIs, berechnet verfügbare Energie, und plant Compute-Jobs entsprechend. Deferred Compute verschiebt Jobs auf Zeiten mit viel Solar. Load Shedding Policies definieren Verhalten bei Solar-Ausfall oder Netz-Instabilität. Überschüssige Kapazität wird als Compute Credits (kWh, 15-Min-Fenster) an andere Hubs im LEG Marketplace angeboten. Integration mit Sihl-Sim API für Simulation.
Architektur
Input Layer (Solar APIs/Swissgrid Signals) → Policy Engine (Node-RED/Python) → Scheduler (k3s/Ollama for intelligent scheduling) → Output Layer (Compute Control/Battery Management) → API Gateway (NATS/OpenTelemetry)
Integration
Integriert mit Sihl-Sim (Digital Twin API), Solar-Invertern (Fronius/SMA), Swissgrid-Signalen (Frequenz/Spannung), Compute-System (Grid-OS → Server Control), Battery Management, und Reference Hardware.
📦 Deliverables
- ✓Scheduler v0 (Solar-Budget → Compute-Limit)
- ✓Deferred Compute Algorithmus
- ✓Load Shedding Policies
- ✓API Spec + Implementation
- ✓Integration mit Sihl-Sim (Digital Twin)
📊 Bewertungskriterien
🔧 Empfohlene Open-Source Tools
Metriken-Sammlung fuer P_solar, P_compute, Temperaturen
GitHub →Time-Series DB fuer Sensor-Zeitreihen
GitHub →IoT-Plattform mit Inverter-APIs (Fronius, SMA)
GitHub →MQTT-Broker fuer Sensor-Kommunikation
GitHub →LEG Rechtsgrundlagen & Hardware-Compliance
Rechtliche Templates für LEG-Gründung und Hardware-Wiederverwendungs-Compliance (CE-Kennzeichnung, Gewährleistung, Haftung).
📖 Erklärung
LEG Legal & Hardware Compliance ist ein Baukasten für die rechtliche LEG-Gründung plus Hardware-Wiederverwendungs-Compliance. Es enthält alle Dokumente für legales Energie-Sharing und klärende Leitfäden zur sicheren Wiederverwendung von Server-Hardware (CE-Kennzeichnung, Gewährleistung, Haftung).
Die rechtliche Gründung einer LEG ist komplex und Hardware-Reuse wirft Compliance-Fragen auf (CE-Markierung bei Umbauten, Gewährleistung bei gebrauchter Hardware, Haftung bei Fehlfunktion). Dieser Pack macht beides einfacher und rechtssicher.
Du erstellst ein komplettes Template-Set: Statuten für die LEG, Verträge zwischen Teilnehmenden, FAQ zu rechtlichen Fragen, regulatorische Checkliste, plus Hardware-Reuse Compliance (CE-Kennzeichnung, Gewährleistung, Haftung), Versicherungs-Checkliste, und PrSG-Leitfaden (Produktsicherheit).
Funktionsweise
Templates basieren auf Schweizer Recht und gängigen Praxisanforderungen. Statuten definieren die rechtliche Struktur (AG oder Genossenschaft). Verträge regeln Energie-Sharing zwischen Teilnehmenden. Checkliste deckt regulatorische Anforderungen ab (Netzbetreiber, Steuern, Haftung). Hardware Compliance deckt CE-Kennzeichnung (relevante Richtlinien bei Umbauten), Gewährleistung (gebrauchte Komponenten), PrSG (Produktsicherheitsgesetz), und Versicherungsanforderungen.
📦 Deliverables
- ✓Template-Set (Statuten + Vertrag + FAQ)
- ✓Regulatorische Checkliste
- ✓Risiko-/Haftungsklärung
- ✓Hardware-Reuse Compliance (CE-Kennzeichnung, Gewährleistung, Haftung)
- ✓Versicherungs-Checkliste
- ✓PrSG-Leitfaden (Produktsicherheit)
📊 Bewertungskriterien
👥 Team (4 Personen)
Team Red: Hacke unser System
Ethisches Hacking: Teste Hardware, Software und APIs auf Schwachstellen. Inklusive physischer Sicherheitsanalyse der Hubs.
Team-Grösse: 10-15 Personen (ein Team) · Ein einziges Team
💻 Digitale Angriffsvektoren
- →API-Schwachstellen (Injection, Auth Bypass)
- →Grid-OS Scheduler Exploits
- →Dashboard XSS/CSRF
- →Netzwerk-Sniffing & MitM
- →Firmware-Analyse
🔧 Physische Angriffsvektoren
- →Gehäuse-Manipulation (Tamper Detection)
- →USB/Serial Port Angriffe
- →Sensor-Spoofing (Temp, Flow)
- →Stromversorgung-Manipulation
- →Physischer Zugang zu Öl/Kühlkreislauf
🛡️ Hardening-Massnahmen entwickeln
Nach dem Finden von Schwachstellen: Wie können die Hubs gehärtet werden?
📦 Deliverables
- [✓]Security Audit Report (Digital + Physical)
- [✓]Proof-of-Concept Exploits
- [✓]Hardening Recommendations
- [✓]Tamper-Detection Konzept
🛠️ Skills
🎯 Bewerbungsverfahren
Team Red ist die einzige Challenge mit Selektionsverfahren. Wir suchen erfahrene Security-Researcher mit nachweisbarer Expertise für ein einziges Team mit 10-15 Personen. Die reguläre Hackathon-Anmeldung gilt hier nicht. Bewirb dich separat.
Bewerbung beinhaltet: CV/Portfolio · Security-Erfahrung · Motivation · GitHub/CTF-Profile
⚠ Nur mit expliziter Genehmigung · Responsible Disclosure Required · NDA wird unterzeichnet ⚠
Was bedeutet das eigentlich?
Technische Begriffe, die in den Challenges verwendet werden, kurz erklärt.
Competition-Modell
Wie die Bewertung funktioniert
📊 Team-Verteilung
Alle Challenges sind gleichwertig. Bewertung erfolgt durch Jury nach technischer Qualität, Vollständigkeit, und Integration.
Der Sihlicon Hub v1.0
Hardware, die heizt. Software, die steuert. Ein komplettes System für die Energiewende.
Compute-Szenarien
Der Sihlicon Hub läuft intelligente Workloads, die mit Solar-Energie flexibel sind. Wärme ist das Hauptprodukt, Compute ist der nützliche Nebeneffekt.
Primäre Anwendungen
Dokument-Digitalisierung
Historische Archive aus dem Sihltal werden digitalisiert: OCR für alte Dokumente, Handschriften-Erkennung, Metadaten-Extraktion.
KI-Inferenz (Lokale LLMs)
Schweizerdeutsche Dokumente übersetzen, Named Entity Recognition, Textklassifikation. Alle Daten bleiben in der Schweiz.
Zeitreihen-Vorhersage
Solar-Produktion vorhersagen, Wärmebedarf prognostizieren, Grid-Last antizipieren. Kritisch für Grid-OS Scheduling.
Video/Bild-Verarbeitung
Batch-Transcoding, Thumbnail-Generierung, Bildverbesserung für Archive. GPU-intensiv, hohe Wärmeausbeute.
Wie funktioniert es?
1. Solar-Überschuss
Grid-OS erkennt verfügbare Energie
2. Compute startet
Jobs werden basierend auf Priorität und Energie-Budget geplant
3. Wärme wird genutzt
Abwärme heizt Gebäude oder wird ins Fernwärmenetz eingespeist
Energie-bewusstes Scheduling: Jobs laufen nur, wenn Solar-Energie verfügbar ist. Bei Grid-Problemen werden Jobs pausiert oder gedrosselt.
Flexible Workloads: Alle Compute-Jobs sind unterbrechbar und können bei Bedarf pausiert werden, um das Grid zu unterstützen.
Heat Accounting: Jede kWh Compute wird automatisch als Wärme verbucht und kann als Credit genutzt werden.
Content-Addressed Storage: Dateien werden über ihren Inhalt identifiziert (nicht über Dateinamen). Gleicher Inhalt = gleiche ID, automatische Deduplizierung.
Replikation: Jede Datei wird auf mindestens 3 Hubs gespeichert. Kein Single Point of Failure. Alle Daten bleiben in der Schweiz.
Tiering: Hot (NVMe) für häufig genutzte Daten, Cold (HDD) für Archive, Glacier (Tape) für Langzeit-Backup.
Inter-Hub Trading: Hubs mit Überschuss verkaufen Compute, Storage oder Wärme an Hubs mit Bedarf. Lokale Elektrizitätsgemeinschaften (LEGs) handeln Ressourcen.
Dynamische Preise: Preise passen sich an Energie-Verfügbarkeit, Grid-Bedingungen und Angebot/Nachfrage an.
Settlement: Abrechnung über interne Credits oder direkt in CHF via Stripe Connect.
Willst du wissen, wie diese Workloads implementiert werden?
Grid-OS Challenge anschauen →Welches Paket packst du an?
Wähle deine Rolle bei der Anmeldung und finde ein Team für dein Paket.