Auralink: Eine Physical-AI-Referenzarchitektur als Forschungssystem
Auralink ist eine von Hyperion erstellte Physical-AI-Forschungsreferenz für EV-Ladeinfrastruktur — eine sicherheitsrelevante, normengeregelte Domäne. Sie wurde in Simulation und begrenzten Umgebungen bewertet und innerhalb einer kontrollierten Forschungsgrenze dokumentiert. Diese Seite nutzt sie zur Prüfung von Architektur- und Sicherheitsentscheidungen, nicht als Nachweis für Produktivität, Geschwindigkeit, externe Kundenarbeit oder Zertifizierung.
Zuletzt geprüft: Juni 2026
Inhalt
Auralink ist eine von Hyperion erstellte Physical-AI-Forschungsreferenz für EV-Ladeinfrastruktur. Sein Charger-OS ist an ISO 15118-20 und OCPP ausgerichtet, und die Architektur bietet eine prüfbare Referenz für Edge-First-Betrieb, explizite Service-Grenzen und begrenzte Agentenbefugnis. Sie wurde in Simulation und begrenzten Umgebungen bewertet und innerhalb einer kontrollierten Forschungsgrenze dokumentiert.
Die Referenzthese: Physical AI, als Forschungssystem, in einer sicherheitsrelevanten Domäne
Die meiste Diskussion über agentische KI bleibt in Demos und Benchmarks. Auralink ist eine von Hyperion erstellte Forschungsreferenz für EV-Ladeinfrastruktur, bewertet in Simulation und begrenzten Umgebungen und innerhalb einer kontrollierten Forschungsgrenze dokumentiert. Damit lassen sich Architekturentscheidungen bei expliziter Evidenzgrenze prüfen.
Die These dieser Seite ist eng: Auralink ist eine Physical-AI-Referenzarchitektur für eine normengeregelte physische Domäne. Es wird nicht als Geschwindigkeitsgeschichte, Kundenfallstudie oder Beleg privater Repository-Skalierung präsentiert.
Zwei Eigenschaften definieren die Designabsicht der Referenz. Erstens Souveränität: Die Quellarchitektur zielt auf betreiberkontrollierte Infrastruktur und erfordert keine externe Cloud im Steuerpfad. Zweitens Edge-First-Kontinuität: Sie ist darauf ausgelegt, bei gestörter oder ausgefallener Konnektivität einen begrenzten lokalen Betrieb aufrechtzuerhalten. In einer physischen Domäne bleiben beides sicherheitsrelevante Anforderungen, die Hardware- und Feldvalidierung erfordern.
Ein Hinweis zur Ehrlichkeit, vorab und weiter unten erneut genannt: Auralink ist eine von Hyperion erstellte Forschungsreferenz. Sie wird hier zur Prüfung von Architektur- und Sicherheitsentscheidungen verwendet. Es ist kein externes Kundenprojekt, und nirgendwo auf dieser Seite werden Namen oder Ergebnisse externer Kunden beansprucht.
Was Auralink zu einer nützlichen Referenz macht
System als Forschungssystem
Eine implementierte Forschungsarchitektur für physische Ladeinfrastruktur, bewertet in Simulation und begrenzten Umgebungen und innerhalb einer kontrollierten Forschungsgrenze dokumentiert.
Normengeregelte Domäne
EV-Laden ist sicherheitsrelevant und durch ISO 15118-20 und OCPP geregelt.
Souveräne Infrastruktur
Für betreiberkontrollierte Infrastruktur ausgelegt; der Steuerpfad erfordert keine externe Cloud.
Edge-First / offline-fähig
Darauf ausgelegt, bei gestörter oder fehlender Konnektivität weiterzuarbeiten.
Architektur: Edge-First, eigene Services, Agenten
Auralinks Quellarchitektur definiert ein Fan-out aus kleinen Einheiten, die für eine unabhängige Bereitstellung am Edge vorgesehen sind, mit einer durch explizite Befugnis begrenzten agentischen Schicht. Die folgenden Beschreibungen geben Designabsicht und Simulationsumfang wieder, ohne privates Inventar zu veröffentlichen oder eine physische Bereitstellung zu implizieren.
Zur agentischen Schicht: die Agenten unterstützen den Betrieb — sie erfassen, schlussfolgern und arbitrieren Aktionen innerhalb begrenzter Befugnis. Das Engineering-Team entwirft, prüft und besitzt das System. Die Agenten bauen oder deployen es nicht eigenmächtig; sie handeln innerhalb einer Hülle, die die Architektur definiert.
Implementierte Forschungsarchitektur
ImplementierungsstatusDie Referenz implementiert Edge-First-Zerlegung, explizite Schnittstellen und eine durchgesetzte Trennung zwischen Agentenlogik und deterministischen Kontrollen. Private Repository-Inventardaten sind aus diesem öffentlichen Nachweis ausgeschlossen.
eigene Services
Gemessen: eigene ServicesDas System ist in eigene Services zerlegt. Das ist eine Fan-out-Architektur: kleine, unabhängig deploybare Einheiten mit eng gefassten Verantwortlichkeiten, die über wohldefinierte Verträge kommunizieren. Die Service-Grenze ist es, die das System beobachtbar, einzeln testbar und auf Einheitsebene wiederherstellbar macht.
Begrenzte KI-Agenten
Agentische SchichtDie Forschungsimplementierung definiert Rollen für KI-Agenten, die den Betrieb durch Erfassen, Schlussfolgern und Vorschlagen von Aktionen innerhalb begrenzter Befugnis unterstützen. Das Engineering-Team entwirft, prüft und besitzt das System; die Architektur definiert die Hülle.
Edge-First-Betrieb, offline-fähig
Edge-FirstAuralinks Quellarchitektur zielt auf eine Platzierung an oder nahe der Ladeinfrastruktur und auf Kontinuität bei gestörter oder ausgefallener Konnektivität. Edge-First ist eine Sicherheits- und Kontinuitätsanforderung für spätere Validierung, kein Bereitstellungsnachweis. Das Design erfordert für lokale Entscheidungen keinen Roundtrip zu einer entfernten Cloud.
Abbildung auf den Physical-AI-Stack: Sense → Orchestrate
Hyperion fasst Physical AI als sechs Verben: Sense · Connect · Compute · Reason · Act · Orchestrate. Die folgende Abbildung zeigt, wie Auralinks Quellarchitektur die beabsichtigten Verantwortlichkeiten jeder Schicht ausdrückt. Sie beschreibt Designabsicht und Simulationsumfang, nicht beobachteten Betrieb auf physischer Ladeinfrastruktur.
Sense
Die Quellarchitektur definiert die Edge-Erfassung von Telemetrie aus Ladehardware, Leistungselektronik, Sitzungszustand und Umgebungssignalen. Die Erfassung physischer Signale bleibt ein separates Tor für Hardware-Integration und Validierung.
Connect
Die Quellarchitektur definiert Schnittstellen für offene Protokolle und richtet das Charger-OS an OCPP und ISO 15118-20 aus. Aktuelle Geräte- und herstellerübergreifende Interoperabilität bleiben separate Validierungstore.
Compute
Die Quellarchitektur platziert Berechnung auf betreiberkontrollierter Edge-Infrastruktur und zerlegt Workloads in eigene Services nahe der Hardware, die sie später bedienen würden. Das Design erfordert keine externe Cloud-Steuerebene für lokale Logik.
Reason
Die Quellarchitektur begrenzt eine agentische Schicht, die über erfassten oder simulierten Zustand schlussfolgert und Aktionen innerhalb begrenzter Befugnis diagnostiziert, vorschlägt oder arbitriert. Verhalten auf physischen Systemen bleibt qualifizierter Integration und Validierung unterworfen.
Act
Die Quellarchitektur definiert kontrollierte Schnittstellen, über die vorgeschlagene Aktionen Ladeinfrastruktur erreichen könnten. Physische Aktuierung, Protokollinteroperabilität und Sicherheitsverhalten bleiben separate Qualifizierungstore.
Orchestrate
Die Quellarchitektur definiert eine Orchestrierungsschicht, die Lebenszyklus, Bereitstellung, Versionierung und Wiederherstellung über Edge-Standorte, Services und Agenten koordinieren soll. Der physische Betrieb über mehrere Standorte muss noch validiert werden.
Normen & Sicherheit: ISO 15118-20, OCPP und eine durchgesetzte Hülle
EV-Laden ist eine normengeregelte Domäne. Auralinks Quellarchitektur richtet das Charger-OS an ISO 15118-20 und OCPP aus und definiert eine begrenzte Hülle für die agentische Schicht. Dies ist architektonische Ausrichtung zur Prüfung und späteren Validierung, keine Zertifizierung oder validierte physische Interoperabilität.
Wichtige Grenze: die Sicherheits- und Konformitätsbewertungsanforderungen hängen vom System und seinem vorgesehenen Verwendungszweck ab, einschließlich der Frage, ob eine benannte Stelle einzubeziehen ist. Das Material auf dieser Seite ist ein technischer Nachweis, der beschreibt, wie das System für eine normengeregelte Domäne architektiert ist — es ist keine Zertifizierung und behauptet keine. Für das Projekt, das ein Sicherheitsargument zusammenstellt, siehe Hyperions Leistung Safety-Case & Certification.
ISO 15118-20
Straßenfahrzeuge — Kommunikationsschnittstelle Fahrzeug-zu-Netz — Teil 20
ISO 15118-20 spezifiziert die Anwendungs- und Darstellungsschicht der zweiten Generation für die Kommunikation zwischen einem Elektrofahrzeug und der Ladeinfrastruktur, einschließlich Sitzungsaushandlung, sicherer Kommunikation und Szenarien bidirektionaler Leistungsübertragung. Es ist die Norm, die regelt, wie ein Ladepunkt und ein Fahrzeug eine Ladesitzung aufbauen und durchführen.
In Auralink
Auralinks Charger-OS ist auf der Sitzungsebene an ISO 15118-20 ausgerichtet. Für eine Referenzarchitektur ist der relevante Punkt struktureller Natur: Das System ist so ausgelegt, dass die Aushandlung zwischen Fahrzeug und Infrastruktur der geltenden Norm entspricht statt einem Ad-hoc-Protokoll.
OCPP
Open Charge Point Protocol
OCPP ist das offene, herstellerneutrale Protokoll für die Kommunikation zwischen Ladepunkten und einem zentralen Managementsystem. Es ist der De-facto-Interoperabilitätsstandard für EV-Ladenetze und deckt Transaktionen, Konfiguration, Firmware-Verwaltung und Diagnose über heterogene Hardware hinweg ab.
In Auralink
Auralinks Quellarchitektur richtet das Charger-OS an OCPP aus und sieht vor, dass die Schnittstellen der Management-Ebene einem dokumentierten offenen Vertrag folgen. Aktuelle Protokollinteroperabilität und Konformität bleiben separate Validierungstore.
Wie ein Edge-Agentik-System für eine normengeregelte Domäne architektiert wird
Autonomie arbeitet innerhalb einer durchgesetzten Hülle
Die agentische Schicht schlussfolgert und schlägt innerhalb begrenzter Befugnis vor. Die Grenzen — was das System unter welchen Bedingungen befehlen darf — sind durch die Architektur und die geltenden Normen definiert, nicht durch die Agenten selbst. Diese Trennung ist das Architekturmuster, das ein agentisches System in einer sicherheitsrelevanten Domäne vertretbar macht.
Offene Normen als Konformitätssubstrat
Die Ausrichtung des Charger-OS an ISO 15118-20 und OCPP definiert ein Ziel für von außen beobachtbares Verhalten gegenüber dokumentierten, auditierbaren Verträgen. Nachgewiesene Konformität und Interoperabilität erfordern separate Validierung.
Edge-First für Kontinuität und lokalen Determinismus
Das Design zielt auf Edge-Betrieb und Kontinuität bei gestörter Konnektivität, sodass lokale Entscheidungspfade keinen Roundtrip zu einer entfernten Cloud erfordern. Sicherer Offline-Betrieb bleibt eine Anforderung für Hardware- und Feldvalidierung.
Souveräne Infrastruktur: der Betreiber besitzt das Substrat
Das Design zielt auf betreiberkontrollierte Infrastruktur und vermeidet eine erforderliche externe Cloud im Steuerpfad. Dieses Souveränitätsziel ist eine Architekturanforderung, kein Nachweis einer laufenden Bereitstellung.
Evidence
Die Belege werden im Kontext dargestellt. Die Forschungsreferenz ist ein public technical preprint, nicht begutachtet; seine Ergebnisse werden hier nicht reproduziert, und es ist kein Feld- oder kommerzielles Ergebnis.
Öffentliches technisches Preprint Preprint 2603.08736 des Gründers, „Autonomous Edge-Deployed AI Agents for Electric Vehicle Charging Infrastructure Management“ (am 24. Februar 2026 bei arXiv eingereicht). Der zitierte Eintrag ist ein Preprint und kein Nachweis einer begutachteten Veröffentlichung.
Forschung zu Edge-Agenten — das arXiv-Preprint (2603.08736)
Das arXiv 2603.08736 des Gründers (Februar 2026) beschreibt am Edge betriebene Agenten für die autonome Vorfalllösung. Es ist ein public technical preprint, nicht begutachtet; seine Ergebnisse werden hier nicht reproduziert, und es ist kein Feld- oder kommerzieller Nachweis.
Implementierte Architekturmuster
Edge-First-Zerlegung, eine agentische Schicht innerhalb einer durchgesetzten Hülle und normausgerichtete Schnittstellen sind in einem Forschungssystem implementiert. Dies belegt weder Deployment und Leistung noch private Repository-Skalierung.
Eine normengeregelte Domäne, von Grund auf
EV-Ladeinfrastruktur ist eine sicherheitsrelevante, normengeregelte Domäne. Der relevante Beleg ist kein einzelner Benchmark, sondern die Tatsache, dass die Architektur darauf gebaut wurde, innerhalb der Beschränkungen dieser Domäne zu arbeiten — Ausrichtung an ISO 15118-20 und OCPP, Edge-First-Betrieb und begrenzte Agentenbefugnis — statt nachträglich an sie angepasst zu werden.
Was es ist — und was es nicht ist
Auralink ist eine von Hyperion erstellte Physical-AI-Forschungsreferenz. Auf dieser Seite wird sie zur Prüfung von Architektur- und Sicherheitsentscheidungen in einer normengeregelten, sicherheitsrelevanten Domäne verwendet.
Es ist kein externes Kundenprojekt und beansprucht keine Namen, Logos oder Ergebnisse von Kunden. Die hier zitierte Forschung ist arXiv 2603.08736, ein public technical preprint, nicht begutachtet; seine Ergebnisse werden hier nicht reproduziert. Private Inventardaten werden nicht veröffentlicht.
Das Preprint ist keine begutachtete Veröffentlichung. Und um die Normengrenze erneut zu nennen: die Sicherheits- und Konformitätsbewertungsanforderungen hängen vom System und seinem vorgesehenen Verwendungszweck ab, einschließlich der Frage, ob eine benannte Stelle einzubeziehen ist — das Material hier ist ein technischer Nachweis, keine Zertifizierung.
Häufig gestellte Fragen
Ist Auralink ein externes Kundenprojekt?
Nein. Auralink ist eine von Hyperion erstellte Physical-AI-Forschungsreferenz. Sie wird auf dieser Seite zur Prüfung von Architektur- und Sicherheitsentscheidungen in einer normengeregelten, sicherheitsrelevanten Domäne vorgestellt. Es ist kein externes Kundenprojekt, und hier werden keine Namen oder Ergebnisse externer Kunden beansprucht.
Welche Normen gelten für Auralink?
Auralink ist eine Forschungsreferenz für EV-Ladeinfrastruktur, eine normengeregelte Domäne. Die Quellarchitektur ist an ISO 15118-20 und OCPP ausgerichtet. Aktuelle Interoperabilität und physische Integration bleiben separate Validierungstore.
Können Sie das für mein sicherheitskritisches System bauen?
Die relevanten Hyperion-Projekte sind Physical-AI-Deployment (Edge-First-Architektur, agentische Schichten und Integration für physische Systeme) und Safety-Case & Certification-Unterstützung (Zusammenstellung des technischen Nachweises, den ein Sicherheitsargument erfordert). Der richtige Ausgangspunkt ist ein Gespräch über Ihre Domäne, ihre geltenden Normen und wo ein edge-deployed System passt. Siehe /services/physical-ai-deployment und /services/safety-case-certification.
Ist die zitierte Forschung begutachtet?
Nein. arXiv 2603.08736 (Februar 2026) ist das public technical preprint des Gründers, nicht begutachtet; seine Ergebnisse werden hier nicht reproduziert. Es ist kein begutachtetes, Feld- oder kommerzielles Ergebnis.
Quellen und Referenzen
Cherifi, M. (2026). "Autonomous Edge-Deployed AI Agents for Electric Vehicle Charging Infrastructure Management." https://arxiv.org/abs/2603.08736
Kontext: Public technical preprint arXiv 2603.08736 (Februar 2026) des Gründers. Nicht begutachtet; seine Ergebnisse werden hier nicht reproduziert, und es ist kein Feld- oder kommerzielles Ergebnis.
ISO (2022). "ISO 15118-20: Road vehicles — Vehicle to grid communication interface — Part 20."
Kontext: Internationale Norm, die die Anwendungs- und Darstellungsschicht der zweiten Generation für die Kommunikation zwischen Fahrzeug und Infrastruktur spezifiziert, einschließlich Sitzungsaushandlung, sicherer Kommunikation und bidirektionaler Leistungsübertragung.
Open Charge Alliance (2024). "OCPP — Open Charge Point Protocol."
Kontext: Offenes, herstellerneutrales Protokoll für die Kommunikation zwischen EV-Ladepunkten und einem zentralen Managementsystem. Der De-facto-Interoperabilitätsstandard für EV-Ladenetze.
Ihr sicherheitskritisches System besprechen
Wenn Sie Physical AI für eine sicherheitsrelevante, normengeregelte Domäne bauen — und wollen, dass die Architektur einer Prüfung standhält — beginnen Sie mit einem Gespräch. Hyperion bringt Erfahrung mit Forschungsarchitektur und -evaluation mit edge-deployed, agentischen Systemen ein und arbeitet an der Seite Ihres Teams am Deployment und an dem technischen Nachweis, den ein Sicherheitsnachweis erfordert.
Gründer & Leiter KI-Strategie
Mohammed Cherifi ist Gründer von Hyperion Consulting und auf Produktentscheidungen für Physical-AI-Systeme spezialisiert. In dieser Referenz ordnet er Architektur und Evaluation innerhalb offengelegter Evidenz- und Befugnisgrenzen ein.
Verwandte Ressourcen
Physical-AI-Deployment
Edge-First-Architektur, agentische Schichten und Integration für sicherheitsrelevante physische Systeme
Safety-Case & Certification
Technische Nachweise für die Sicherheitsargumentation zusammenstellen; die Konformitätsbewertung folgt dem anwendbaren Verfahren
Sim-to-Real für die Industrierobotik
Die Sim-to-Real-Lücke schließen: von Physiksimulation bis zur Edge-Inferenz auf dem Roboter
Physical-AI-Produktmanagement
Das Product System — Strategie, Discovery, Produktisierung, Launch, Skalierung