// iiot-vertrauensplattform · souverän · air-gap

Die Vertrauensplattform für souveränes IIoT.

Hardware-Identität, lokale Entscheidung, autonome Aktion, Air-Gap. Vier offene und prüfbare Schichten — nehmen Sie einen Baustein, mehrere oder den kompletten Stack.

Demo-Konsole ansehen → Was die Plattform kann Technische Dokumentation

// platform telemetry

devices.enrolled412 policy.evals.local12 847 attestations.signed1 976 audit.entries8 402 satellites.online99.4 % stackEU / open

// demo data — Demonstrationsprüfstand

// snapshot · Prüfstand Île-de-France

▸Ops-Devices ist die souveräne Vertrauensplattform für das IIoT.

Trust-Buster ist das erste darauf aufgebaute System: ABAC-Zugriffskontrolle mit Abschalt-Satelliten, vor Ort bereitgestellt und betrieben. trust-buster.com ↗

// was die plattform kann

Fähigkeiten

Auf dem Prüfstand demonstrierte Fähigkeiten.

Wahrnehmen: Passive RF-Erkennung (BLE / WiFi), Korrelation von Anwesenheit, Kartografie, Signaturen des Stromverbrauchs (NILM — nur Bestätigung, niemals Identitätsnachweis).
Identifizieren: Verankerte Hardware-Identität (Enclave, IoT SAFE), von der Enclave signierte mTLS-Attestierung, Enrollment von Legacy-Anlagen ohne diese zu verändern.
Entscheiden: Richtlinien lokal und offline auf Basis eines signierten Manifests ausgewertet; Anti-Rollback durch monotone Zähler; kein Serveraufruf auf dem kritischen Pfad.
Handeln: Stromabschaltung, Flussfilterung, Vertrauens-Proxy pro Schnittstelle (BLE, USB, Ethernet, seriell, RS-485 / Modbus).
Nachweisen: Signiertes Audit-Protokoll, append-only, Nichtabstreitbarkeit, SIEM-Export (syslog / CEF).
Interoperieren: Standard-MQTT 5.0, REST / OpenAPI, Webhooks, Grenzadapter (CoT für die Verteidigung).
Bereitstellen: On-Premise, vollständiger Air-Gap oder souverän gehostet; 3 Form-Faktoren.

// 4 unabhängige schichten

Technische Bausteine

Jede Schicht ist dokumentiert, versioniert und unabhängig nutzbar. Sie kaufen, was Ihrem aktuellen Stack fehlt — keine monolithische Lösung.

L1

Hardware

3 Form-Faktoren (Cube, Hutschiene/DIN-Rail, gehärtet IP68) · ESP32-S3 + Sicherheitsbaustein

Einsatzbereite Standard-Firmware, öffentliche Datenblätter, Schaltpläne auf NDA-Anfrage. Die Vertrauenskette ist in einem nach Common Criteria EAL5+ zertifizierten Sicherheitsbaustein verankert (geerbte Enclave von Tiempo Secure, via Sequans Monarch 2): Der private Schlüssel wird dort erzeugt und verlässt ihn nie. Die Zertifizierung betrifft den Baustein, nicht Ops-Devices.

MCU: ESP32-S3 / ESP32-C6
Mobilfunk: Walter (Sequans Monarch 2, FR/BE)
Funk: BLE 5.0 + WiFi 6
Laden: Qi 5V + USB-C
Gehäuse: 12 cm Würfel, IP nicht spezifiziert v1
Sicherheitsbaustein: CC EAL5+ zertifiziert (Tiempo Secure)
Protokoll: IoT SAFE (GSMA RP.25)
Privater Schlüssel: In der Enclave erzeugt, nie im RAM
Attestierung: mTLS X.509 von Enclave signiert, nicht Firmware

L2

Firmware

Open-Source-ESP32-Firmware, SDK, signiertes OTA über hawkBit

Apache 2.0, in Europa entwickelt, prüfbar, reproduzierbarer Build. Konfigurierbare Profile (Alarm, Gateway, Steuerung). Passen Sie die MQTT-Payloads an Ihre Randbedingungen an, fügen Sie Ihre Erkennungs-Heuristiken hinzu.

Lizenz: Apache 2.0
Framework: ESP-IDF v5.1+
MQTT: 5.0 + mTLS X.509 (TLS 1.3)
OTA: Ed25519-signiert, hawkBit
Sicherheit: AES-256-GCM, ECDH/HKDF
Anti-Rollback: Monotone Zähler in der Enclave

L3

Backend & API

MQTT-Aufnahme, Richtlinien, signiertes Protokoll, REST + Webhooks

Python asyncio + PostgreSQL/TimescaleDB. OpenAPI-dokumentierte REST-API, MQTT-Webhooks, ProtoBuf-Aufnahme. On-Premise selbst hostbar (Air-Gap möglich) oder souverän gehostet. Die Plattform verteilt die Richtlinien; sie ist niemals an der Entscheidung beteiligt.

Stack: Python 3.12 + asyncio
DB: PostgreSQL + TimescaleDB
Broker: EMQX 5 (MQTT 5.0) — Demo
Souveräner Broker: HiveMQ / VerneMQ / Mosquitto
API: REST OpenAPI + Webhooks
Export: SIEM syslog / CEF
Bereitstellung: Podman / Docker / On-Prem / Air-Gap

L4

Überwachungskonsole

SvelteKit-Frontend + Three.js 3D-Würfel — Echtzeitüberwachung

Open-Source, anpassbar (Logo, Farben, Faces, Beschriftungen). Admin-Dashboards, Nachrichten-Inbox, Multi-Cube, RF-Kartografie. Unter Ihrer Marke bereitstellbar (Option OEM / White-Label).

Stack: SvelteKit 2 + Tailwind 3
3D: Three.js
Auth: OIDC (LemonLDAP, Keycloak…)
i18n: FR / DE / IT inklusive
Lizenz: Apache 2.0 + OEM-Vereinbarung

// architektur

Ein Anker, viele Satelliten.

Der Anker ist von den Geräten, die er schützt, entfernt und schützt mehrere davon: Er wird niemals direkt mit einem von ihnen verkabelt. Der Cube ist der Vertrauensanker und der Entscheidungspunkt einer Zone. Die Satelliten setzen durch, einer je Schnittstelle. Der Cube delegiert niemals Autorität: Er stellt signierte, kurzlebige Capabilities aus, mit begrenzter Lebensdauer und an den Kontext gebunden. Er vertraut einem Satelliten niemals — er verifiziert.

Kontrollierte Schnittstelle	Satellit	Rolle	Status
230 V Stromversorgung	Shelly (gehärteter Serienstand, detached input)	Abschaltung / Freigabe eines Geräts	● Demonstrator
BLE-Peripheriegeräte	BLE-Proxy	Tastatur, Maus, drahtloses Peripheriegerät	● Roadmap
USB-Bus	USB-HID-Filter — STM32H7 (zwei USB-Kerne)	USB-Tastatur — Referenzfall des vollständigen Ablaufs	● Roadmap
Kabelgebundenes Netz	Ethernet-Gate	OT-Segment	● Roadmap
Serielle Schnittstelle	Serielles Gateway — STM32 + isolierter ST3485E	Legacy-SPS mit Modbus RTU (RS-485 / RS-232)	● Roadmap

Der Stromversorgungs-Satellit im Detail

Er ist der einzige Satellit im Betrieb. Der Cube delegiert ihm keinerlei Autorität: Er stellt ihm eine signierte, kurzlebige Capability mit kurzer TTL aus und verifiziert seinen Zustand.

Hardware: Shelly (Allterco, Bulgarien — ISO 27001)
Firmware: Serien-Firmware, gehärtet — kein Reflash
Eingang: Detached input — der Taster meldet, das Relais gehorcht nur dem Cube
Deaktiviert: Cloud, BLE, Schedules, Webhooks
Beim Start: Power-on OFF-Zustand (fail-closed)
Verbindung: MQTT over mTLS, authentifizierte Weboberfläche
Interlock: Messung vorgelagert (Pro 1PM, DIN-Schiene) vs. nachgelagert (Plug S)
Prüfstand: 2× Plug S Gen3, 1× Pro 1PM, 1× EM Gen3, 1× Plus i4 DC
Portierbarkeit: Plug S Gen3 = ESP32-C3: Die Firmware des Cube ist darauf nicht portierbar

Auf den Satelliten ist die Souveränität real

Die Satelliten benötigen keinen Funk: Der ESP32-Kompromiss des Cube entfällt dort. Sie basieren auf STMicroelectronics (französisch-italienisch) — STM32-MCU und Sicherheitselement STSAFE-A120, zertifiziert nach Common Criteria EAL5+. Die Enforcement-Punkte, im Kontakt mit der kritischen Anlage, verfügen somit über eine europäische Hardware-Vertrauenswurzel — die der Cube v1 nicht hat, da seine Enclave unter die Kontrolle von Qualcomm geraten ist. Der auf den Satelliten validierte STSAFE-A120 ist der Kandidat für den Cube v2.

Tamper- / Selbstheilungsschleife

Erkennung des Resets eines Satelliten (Wiederauftauchen des Standard-AP, MQTT-LWT) → Fail-Closed-Lockdown der Zone → authentifiziertes Re-Enrollment mit Evil-Twin-Schutz. Ein differentieller Strom-Interlock (Messung vorgelagert vs. nachgelagert) meldet eine physische Umgehung.

Das erste auf diesem Muster aufgebaute System

Wir haben mit der ABAC-Zugriffskontrolle samt Satellit zur Stromabschaltung begonnen — das ist das System Trust-Buster, vor Ort bereitgestellt und betrieben. Dasselbe Muster erstreckt sich auf BLE, USB, Ethernet und seriell.

→ trust-buster.com ↗

// autorisierung

Das ABAC-Modell — drei niemals vermischte Fragen

Kontextbezogene Autorisierung: Subjekt × Ressource × Ort × Zeitfenster, auf Basis eines signierten Manifests.

Faktor	Frage	Mechanismus	Sicherheitsstatus
Anwesenheit	Wo — wer ist wahrscheinlich da?	RSSI-Ko-Präsenz von enrollten Geräten	Gate — notwendig, niemals hinreichend
Identität	Wer — ist er es wirklich?	Kryptografisches Challenge-Response (Sicherheitselement des Smartphones ↔ Enclave des Cube)	Nachweis
Berechtigung	Was — darf er das, hier, jetzt?	Von der Autorität signiertes Manifest: vorgesehene Tätigkeit (Tag, Ort, Ressource), TTL	Recht

Goldene Regel

Der RSSI sagt „er ist da“; die Kryptografie sagt „er ist es wirklich“. Eine physische Aktuierung wird niemals allein auf den passiven dritten Faktor gestützt. Das NFC-Badge ist ein Näherungszeiger — es bestimmt, wen man challengen muss — kein Identitätsnachweis.

Autorisierungsautomat

1 · ANFRAGE Abgetrennter Satelliteneingang (Tastendruck) → Anfrage an den Cube. Die Taste betätigt niemals direkt das Relais.
2 · GATE Ko-lokalisierte RSSI-Anwesenheit mindestens eines enrollten Kandidaten → andernfalls Ablehnung: niemand Plausibles in der Zone.
3 · NACHWEIS Challenge des Cube → vom Sicherheitselement des Smartphones signierte Antwort (an den Kontext gebundene Nonce: Ressource, Zone, Zeitfenster).
4 · RECHT Signiertes Manifest verifiziert: vorgesehene Tätigkeit, an diesem Tag, an diesem Ort, für diese Ressource; TTL nicht abgelaufen; monotoner Zähler (Anti-Rollback).
5 · CAPABILITY Ausstellung einer signierten, kurzlebigen Capability an den betreffenden Satelliten.
6 · AUSFÜHRUNG Der Satellit führt aus; der Cube protokolliert (signiertes Protokoll, append-only). Jeder fehlgeschlagene Schritt → protokollierte Ablehnung mit Begründung.

Air-Gap: das Fehlen einer Echtzeit-Sperrung kompensieren

Kurze TTL auf den Manifesten (der Ablauf ersetzt die Sperrung), monotone Zähler in der Enclave (Anti-Rollback der Richtlinien), an den Kontext gebundene Nonces im Challenge-Response.

// unser souveränitäts-ansatz

Warum ESP32 in einem als souverän bezeichneten Stack?

[01] Der ESP32 (Espressif) ist kein europäischer MCU — warum daran festhalten? ▶

Weil er heute das einzige reife Open-Source-Ökosystem mit BLE 5 + WiFi 6 + Funk-Koexistenz zu diesem Preis ist. Einen EU-MCU in v1 zu erzwingen, würde die Hardwarekosten verdoppeln und das Produkt um 18 Monate verzögern. Wir stehen dazu und dokumentieren es: Das Lieferketten-Risiko liegt allein auf der Silizium-Schicht — weder auf der Firmware (Open-Source EU) noch auf der Plattform (on-premise selbst hostbar).

[02] An welcher europäischen Alternative arbeiten Sie? ▶

STM32WB-Variante (STMicroelectronics, FR/IT) + europäisches RF-Modul, geplant für v2.0 (Q4 2027). Für Kunden, die eine 100 % EU-Lieferkette ohne Kompromisse verlangen, wird diese Variante mit akzeptabler Verschlechterung der Funk-Koexistenz verfügbar sein (BLE 5 ohne gleichzeitiges WiFi).

[03] Und das Walter-Modul (LTE-M)? ▶

Walter wird in Belgien von DPTechnics entwickelt und gefertigt, basierend auf einem Sequans Monarch 2-Modem (FR). EU-Lieferkette auf der Mobilfunk-Schicht — nützlich, um die Souveränität auf dem kritischen Uplink zu demonstrieren.

[04] Und die Cloud-Plattform / die Daten? ▶

OVHcloud Frankreich (Datacenter Roubaix). PostgreSQL + TimescaleDB, Mosquitto, LemonLDAP::NG (FR), Garage S3 (Deuxfleurs FR). Keine Abhängigkeit von US-Hyperscalern. Alle Daten bleiben in der EU, das KMS steht on-prem unter Ihrer Kontrolle, wenn Sie es wünschen. Im Air-Gap verlassen keinerlei Daten den Standort.

[05] Kann die Firmware vor der Bereitstellung geprüft werden? ▶

Ja. Die Firmware ist Open-Source (Apache 2.0), reproduzierbarer Build, signierte Releases. Sie können jede Zeile prüfen oder von einem Dritten prüfen lassen. Ein entscheidendes Argument gegenüber proprietären Firmwares großer Hersteller.

[06] Ihr EAL5+-Sicherheitsbaustein — was ändert das konkret? ▶

Der private Schlüssel des Geräts wird direkt in der Enclave erzeugt (IP Tiempo Secure, via Sequans Monarch 2). Er gelangt nie ins RAM oder den ESP32-Flash. Ein Angreifer, der die Firmware kompromittiert, kann ihn nicht extrahieren. Jeder mTLS-Handshake wird von der Enclave signiert — nicht vom Host-SoC. Genau das formalisiert der Standard GSMA IoT SAFE. Zwei ehrliche Klarstellungen: Die Common-Criteria-Zertifizierung EAL5+ betrifft den Baustein, nicht Ops-Devices; und EAL5+ ist nicht der höchste Grad der Skala (sie reicht bis EAL7). Nach unserem Kenntnisstand bietet kein europäischer Akteur diese Kombination in diesem Segment an.

[07] Warum EMQX, obwohl der Hersteller chinesisch ist? ▶

EMQX wird auf dem Demonstrationsprüfstand wegen seiner Reife und Leistung im Clustering eingesetzt. Für Verteidigungskontexte oder solche, die maximale Souveränität erfordern (ANSSI-Konformität, klassifizierte Perimeter), setzen wir HiveMQ (DE), VerneMQ oder Mosquitto (Eclipse Foundation, Open Source) ein. Wir verwenden ausschließlich Standard-MQTT 5.0 ohne proprietäre Erweiterungen, gerade um portabel zu bleiben. Die Wahl des Brokers ist im HBOM jeder Bereitstellung dokumentiert und berührt nicht die kryptografische Vertrauenskette.

[08] Stellen Sie ein SBOM und ein HBOM bereit? ▶

Ja. Unser SBOM (Software Bill of Materials) wird im Format CycloneDX 1.6 erzeugt und deckt alle Firmware-Abhängigkeiten (ESP-IDF, mbedTLS, esp-mqtt) und Backend-Abhängigkeiten (Python, PostgreSQL, Broker) ab. Unser HBOM (Hardware Bill of Materials) dokumentiert jede physische Komponente mit Hersteller, Entwurfsland, Fertigungsland und Souveränitätsstufe, gemäß IPC-1752A und NIST SP 800-161. Diese Dokumente sind auf NDA-Anfrage verfügbar und im CRA-Konformitätsdossier enthalten, das mit jeder Bereitstellung geliefert wird.

[09] Tiempo Secure wurde von Qualcomm übernommen — was wird aus Ihrer Souveränität? ▶

Qualcomm hat Tiempo Secure und die 4G-IoT-Assets von Sequans erworben: Die IP der Enclave steht nunmehr unter US-amerikanischer Kontrolle. Unsere Souveränität ist daher eine operative und eine konzeptionelle: keine ausländische Cloud, kein Remote-Kill-Switch, vollständiger Air-Gap, europäische Entwicklung und Integration. Wir behaupten nicht, eine zu 100 % europäische IP zu haben. Die Roadmap für Cube v2 zielt auf einen diskreten, europäisch zertifizierten Sicherheitsbaustein (ST, Infineon, NXP). Das ist nicht bloß eine Absicht: Unsere Satelliten — die Enforcement-Punkte im Kontakt mit der Anlage — sind rund um den STSAFE-A120 (STMicroelectronics, CC EAL5+) spezifiziert, eine wirklich europäische Hardware-Vertrauenswurzel. Wir validieren sie zuerst dort und portieren sie anschließend auf den Cube.

[10] Was können Sie nicht? ▶

Wir messen die physische Distanz nicht: kein Distance Bounding, das Channel Sounding von BLE 6.0 ist auf unserer aktuellen Hardware nicht verfügbar. Ein Relay-Angriff (Wormhole) bleibt daher möglich. Wir erkennen und protokollieren ihn — signiertes Protokoll, Korrelationen, differentieller Strom-Interlock — aber wir behaupten nicht, ihn zu blockieren. Der einzige harte präventive Hebel bleibt die Stromabschaltung. Das ist in unserem Bedrohungsmodell dokumentiert, zusammen mit den übrigen Restrisiken.

// konformität

Konformität in der Nachweis-Version

Konzipiert nach IEC 62443-4-2, mit einer Architektur, die auf die grundlegenden Anforderungen FR1 bis FR7 ausgerichtet ist. Designziel: SL-C 2 (Industrie).

⚠ Bewertung durch Dritte noch nicht erfolgt. Wir weisen keinerlei SL-Stufe als erlangt aus: Ein SL-C erfordert eine Drittbewertung, die wir nicht haben.

Mapping IEC 62443 — grundlegende Anforderungen

Anforderung	Wie die Architektur sie erfüllt
FR1 Identifizierung & Authentifizierung	Hardware-Identität in der Enclave, Challenge-Response Sicherheitselement des Smartphones ↔ Cube, von der Enclave signierte mTLS X.509-Attestierung.
FR2 Nutzungskontrolle	ABAC-Autorisierung auf Basis eines signierten Manifests (Subjekt × Ressource × Ort × Zeitfenster), kurze TTL, kurzlebige Capabilities je Satellit.
FR3 Systemintegrität	Ed25519-signiertes OTA, Anti-Rollback durch monotone Zähler in der Enclave, Open-Source-Firmware mit reproduzierbarem Build.
FR4 Vertraulichkeit der Daten	mTLS (TLS 1.3), AES-256-GCM, ECDH/HKDF. Privater Schlüssel in der Enclave erzeugt und dort verwahrt, nie im RAM exponiert.
FR5 Eingeschränkter Datenfluss	Lokale Entscheidung, kein Serveraufruf auf dem kritischen Pfad, vollständiger Air-Gap möglich. Die Satelliten besitzen keinerlei dauerhafte Autorität.
FR6 Reaktion auf Ereignisse	Signiertes Audit-Protokoll append-only, Erkennung von Tamper/Reset eines Satelliten, Fail-Closed-Lockdown der Zone, SIEM-Export (syslog / CEF).
FR7 Verfügbarkeit der Ressourcen	Offline-Betrieb by design, Power-on-Zustand OFF, authentifiziertes Re-Enrollment nach einem Vorfall.

Register der Restrisiken — veröffentlicht

Risiko	Eingestandene Haltung
Relay / Wormhole (BLE)	Auf der aktuellen Hardware nicht lösbar (es würde das Channel Sounding von BLE 6.0 erfordern). Detektivische Haltung: Erkennung + Zuordnung, keine beanspruchte Prävention. Einziger harter präventiver Hebel: die Stromabschaltung.
Physischer Zugang / Teardown	Ein längerer physischer Zugang erlaubt es, die Hardware zu zerstören. Der Teardown ist erkennbar — er zerstört den Unversehrtheitsnachweis — aber er ist nicht verhinderbar.
Denial of Service durch Fail-Closed	Die Fail-Closed-Haltung kann ausgenutzt werden, um einen Stillstand herbeizuführen. Eingestandene Entscheidung: Im Zweifel hält die Anlage an.
Silizium-Lieferkette	ESP32 (Espressif) und die IP der Enclave nunmehr unter Kontrolle von Qualcomm. Öffentlich dokumentiert (SBOM / HBOM), niemals verschleiert.

CRA-Positionierung

SBOM CycloneDX 1.6, HBOM IPC-1752A / NIST SP 800-161, dokumentiertes Bedrohungsmodell (STRIDE), veröffentlichtes Restrisiko-Register. Konformitätsdossier wird mit jeder Bereitstellung geliefert.

// f&e-journal

Die Alternativen, die wir verworfen haben

Jede strukturgebende Entscheidung wird mit der verworfenen Alternative und deren Begründung festgehalten.

Verworfen	Gewählt	Begründung
Sonoff	Shelly (Allterco, BG, ISO 27001)	Nativ local-first, detached input, Hutschienen-Varianten, EU-Herkunft, MQTT over TLS.
Die Satelliten neu flashen	Gehärtete Serien-Firmware + Sperrprofil	Das OTA von Shelly ist ECDSA-signiert; ein UART-Teardown wäre destruktiv und würde den Unversehrtheitsnachweis zerstören.
Mongoose OS	Gehärtete Shelly-Serien-Firmware	Veraltet, älter als die ESP32-C3-Unterstützung.
Der RSSI allein als Autorisierung	Triptychon Anwesenheit + Identität + Berechtigung	Per Relay spoofbar, wirkungslos unter MAC-Randomisierung. Der RSSI bleibt ein Gate, niemals ein Nachweis.
Das NFC-Badge als Identitätsnachweis	Badge = Näherungszeiger	Klonbar, kein challengebares Geheimnis.
NILM als Identitätsnachweis eines Geräts	NILM = nur Bestätigung	Lastsignaturen sind nicht beweiskräftig.
Dauerhafte, an die Satelliten delegierte Autorität	Vom Cube ausgestellte, signierte kurzlebige Capabilities	Internes Zero-Trust: verifizieren, niemals glauben.
Prävention gegen Relay-Angriffe beanspruchen	Detektivische Haltung + Zuordnung	Der Wormhole-Angriff ist ohne BLE 6.0 Channel Sounding nicht lösbar. Neu bewertbar beim Übergang auf BLE 6.0.
EAL5+ als Zertifizierung von Ops-Devices darstellen	Immer „vom Baustein geerbt“	Technische Ehrlichkeit: Überzogene Behauptungen rächen sich in der Due Diligence.
Der RF-Scan als Markteintrittsbarriere	Die IoT-SAFE-Integrationsschicht	Passives Scannen ist in wenigen Wochen reproduzierbar. Der echte Vorsprung liegt in der Integration der Vertrauenskette.
ESP32 für die Satelliten	STM32 (ST, FR/IT)	Ein Satellit benötigt keinen Funk: Der Kompromiss, der dem Cube den ESP32 aufzwingt, entfällt. Eine zu 100 % europäische Kette wird möglich.
Ein nicht-europäisches Sicherheitselement (Microchip ATECC)	STSAFE-A120 (ST, CC EAL5+)	Wirklich europäische Hardware-Vertrauenswurzel auf den Enforcement-Punkten — und Kandidat für den Cube v2.
Ein einziger USB-Controller (OTG) für den HID-Proxy	STM32H7 — zwei unabhängige USB-Kerne	Der OTG wechselt die Rolle: Er kann nicht gleichzeitig Host und Device sein. Ein Tastatur-Proxy erfordert beides.
Ein nicht isolierter serieller Satellit	Galvanische Trennung von Daten und Stromversorgung	Ein OT-Bus ist gestört (Gleichtaktspannung von mehreren hundert Volt): ohne Isolation sporadische Ausfälle und Hardware-Risiko.

Produktkatalog

Wir befinden uns im Demonstrator-Stadium.

Ebene 1 — Form-Faktoren (Hardware)

Ref.	Bezeichnung	Status
OPS-FF-CUBE	Interaktiver Leucht-Cube — 12 cm, NFC, RGB-LEDs, Qi+USB-C	● Demonstrator
OPS-FF-DIN	Hutschienengehäuse 35 mm — 24V DC, RS-485, IP20, Industrie	● Roadmap
OPS-FF-HARD	Gehärtetes wasserdichtes Gehäuse — IP68, Feld / Außenbereich	● Roadmap

Ebene 2 — Software-Profile (pro Cube)

Ref.	Bezeichnung	Status
PROFILE-ALERT	Reiner Alarmmodus — nicht-intrusiv, null Infrastrukturänderung	● Demonstrator
PROFILE-GW	Netzwerk-Gateway-Modus — aktive Unterbrechung nicht autorisierter Flüsse	● Roadmap
PROFILE-CTRL	Direktsteuerungsmodus — ABAC + Aktuierungs-Satellit	● Demonstrator

Ebene 3 — Plattform (Abonnement)

Ref.	Bezeichnung	Status
OPS-PLATFORM-EDGE	On-Prem-/Air-Gap-Lizenz — keine Cloud-Verbindung erforderlich	● Roadmap
OPS-PLATFORM-SAAS	Souverän gehostet — OVH Frankreich, Multi-Site, REST-API	● Demonstrator
OPS-PLATFORM-OEM	White-Label — rebrandbare Konsole, Royalty, dedizierter Support	● Roadmap

Stufe 4 — Satelliten (Durchsetzungspunkte)

Ref.	Bezeichnung	Status
OPS-SAT-PWR	230-V-Abschaltung — gehärtete Shelly-Stock-Firmware, detached input	● Demonstrator
OPS-SAT-485	Serielles Gateway RS-485 / RS-232 — STM32 + isolierter ST3485E + STSAFE-A120	● Roadmap
OPS-SAT-HID	USB-HID-Filter — STM32H7 (zwei USB-Kerne) + STSAFE-A120	● Roadmap

Historische Referenzen (OPS-CUBE-S3, OPS-WLT-*, OPS-RF-CORE, OPS-MAP-SAAS…): in diese Architektur umklassifiziert. Zuordnungstabelle in der technischen Dokumentation, auf NDA-Anfrage.

Engineering-Grundsätze

Open-Source: Offener Stack (Apache 2.0), prüfbar, reproduzierbarer Build. Keine Black Box.
Souveränität: EU-Hosting, europäische Entwicklung und Integration. Dokumentierte Lieferkette (SBOM / HBOM) — Grenzen inbegriffen.
Lokale Entscheidung: Die Richtlinie wird auf dem Cube ausgewertet, offline. Kein Serveraufruf auf dem kritischen Pfad, vollständiger Air-Gap möglich.

// segmentregel

Welcher Kanal für welchen Bedarf?

Kritische Situationen — gefährliche Anlagen, sensibler Perimeter, bindende Konformität, gerichtsfeste Nachvollziehbarkeit — werden als betriebener Dienst von Trust-Buster abgedeckt: Hardware vor Ort bereitgestellt und betrieben. → trust-buster.com ↗

Automatisierungsbedarf und Standardbereitstellungen laufen über die Plattform und ihr Netz aus Integratoren und Wiederverkäufern.

// distribution & oem

Distribution, Wiederverkäufer, OEM

Sie bauen Ihren Stack auf unseren Bausteinen auf, setzen sie bei Ihren Kunden ein oder bieten die Plattform unter Ihrer eigenen Marke an.

Entdeckung

Kostenlos

Den Stack vor dem Engagement bewerten

▸ Zugang zur vollständigen technischen Dokumentation
▸ 1 Demo-Sonde 30 Tage geliehen
▸ Demo-Konsole mit Testkonto
▸ E-Mail-Support (Antwort in 5 Werktagen)

Autorisierter Wiederverkäufer

Rahmenvertrag

Unsere Bausteine bei Ihren Kunden einsetzen

▸ Gestaffelte Hardware-Mengenpreise
▸ Technische Schulung 2 Tage (Paris oder remote)
▸ Vierteljährlich geteilte Produkt-Roadmap
▸ Prioritäts-Support (SLA 1 Werktag)
▸ Logo "Autorisierter Wiederverkäufer" auf Ihrer Website

OEM / White-Label

Maßgeschneidert

Unsere Bausteine unter Ihrer Marke anbieten

▸ Plattform unter Ihrer Marke (Front + Konsole)
▸ Co-Branding Hardware (Sticker, Verpackung)
▸ Vierteljährlicher technischer Ausschuss
▸ Vertragliches SLA-Engagement
▸ Feste Royalty oder prozentual nach Volumen

Ihren Fall besprechen Technische Dokumentation ansehen

// technischer kontakt

Die Plattform bewerten oder Partner werden.

Beschreiben Sie Ihren technischen Bedarf: welche Bausteine, welche Integration, welches Zielvolumen. Technische Dokumentation, Datenblätter, SBOM / HBOM und Bedrohungsmodell unter NDA verfügbar. Wir melden uns innerhalb von 5 Werktagen.

E-Mail contact@ops-devices.eu

Plattform ops-devices.eu

Betriebenes System trust-buster.com ↗

Hosting OVH Frankreich