Space Engine – die Serverplattform des Space-Intelligence-Ökosystems
Space Engine Server
Die Space-Plattform in drei Bereitstellungsmodellen: von der gemeinsam genutzten Cloud bis zur Installation in Ihrem Rechenzentrum. Sie entscheiden, wo die Server laufen, wer sie betreibt und wo die Daten bleiben.
Space Engine Server bilden das Backend des gesamten Space-Systems: Sie empfangen Ereignisse von Schlössern, Terminals, Gegensprechanlagen, Aufzügen und Sensoren, führen Befehle aus und stellen sie Ihren Anwendungen über eine API bereit. Dieselbe Space-Engine-Plattform läuft in jedem der drei Modelle; die Wahl des Modells ist also eine Entscheidung über Infrastruktur und Verantwortung, nicht über Funktionen.
Drei Bereitstellungsmodelle
Space Engine Cloud
SaaS · Multi-Tenant · Bare Metal
Gemeinsam genutzte Cloud (SaaS) auf Bare-Metal-Servern von Space. Logische Mandantentrennung, keine eigene Infrastruktur, schnellster Start.
Space Engine Private Cloud
IaaS · Single-Tenant · Proxmox VE
Private Cloud auf Space-Infrastruktur: dedizierte virtuelle Proxmox-VE-Maschinen nur für Sie, verwaltet von Space. Isolation eines dedizierten Servers mit dem Komfort der Cloud.
Space Engine Self-Hosted
Dieselbe Software in Ihrem Objekt oder Rechenzentrum, in zwei Liefervarianten.
Space Engine Edge
Self-Hosted · Appliance · Plug-and-Play
Eine Appliance: ein fertiges Servermodul, dessen Hardware wir auswählen und vorkonfigurieren. Vor Ort anschließen und loslegen; die Daten bleiben vor Ort, und bei Bedarf läuft das System ohne Internet.
Space Engine On-Premise
Self-Hosted · BYOI · Kubernetes · Docker · Bare Metal
Kundenverwaltete Bereitstellung (BYOI) auf Infrastruktur, die Sie besitzen oder bereitstellen: Kubernetes, Docker oder Bare Metal, Linux empfohlen. Die Infrastruktur muss die Mindestanforderungen erfüllen; die Bereitstellung passen wir an Ihre Umgebung an.
Modellvergleich
| Parameter | Space Engine Cloud | Space Engine Private Cloud | Space Engine Self-Hosted | |
|---|---|---|---|---|
| Space Engine Edge | Space Engine On-Premise | |||
| Standort | Bare-Metal-Server an Space-Standorten | Space-Infrastruktur (Proxmox VE) | im Objekt des Kunden | Infrastruktur und Hardware des Kunden |
| Isolation | logisch (Multi-Tenant) | dedizierte virtuelle Maschinen (Single-Tenant) | physisch, isoliertes Netz, Air-Gap-Option | vollständig, im Kundennetz, Air-Gap-Option |
| Betrieb durch | Space | Space | der Kunde, mit Unterstützung von Space | die IT des Kunden, mit Implementierungsunterstützung von Space |
| Umgebung | von Space verwaltet | virtuelle Proxmox-VE-Maschinen | Intel-Server, Basiskonfiguration i5-6400 / 16 GB | Kubernetes, Docker oder Bare Metal; Linux empfohlen |
| Skalierung | übernimmt Space | mehr VM-Ressourcen | erweiterte Konfiguration oder Kubernetes-Cluster | vom Einzelserver bis zum Cluster |
| Typischer Kunde | Hotels, Büros, Objekte ohne eigene IT | Organisationen, die Isolation ohne eigene Server brauchen | Objekte mit isolierter Infrastruktur: Verwaltung, Krankenhäuser, kritische Infrastruktur | große Organisationen mit eigener IT und eigenem Rechenzentrum |
Für CTOs, IT-Architekten, CISOs und Integratoren
Eine Plattform, drei Modelle, volle Kontrolle
Eine selten anzutreffende Kombination: dieselbe Plattform und dieselbe API, von der gemeinsam genutzten Cloud bis zur Air-Gap-Installation in Ihrem eigenen Rechenzentrum. Deshalb passt Space Engine zu Hotels, Büros und Gewerbeimmobilien, Wohngebäuden und PRS, Gesundheitswesen, öffentlichem Sektor, kritischer Infrastruktur und Industrie, während die Kontrolle über Infrastruktur und Sicherheitsverfahren bei Ihnen bleiben kann.
Datensouveränität und Datenresidenz
Sie wählen, wo die Server laufen und wo die Daten gespeichert werden: in der Space Engine Cloud, in einer Private Cloud oder im eigenen Objekt. Das erleichtert eine Architektur, die DSGVO- und NIS2-Anforderungen erfüllt.
Ihre Security Governance
In den On-Premise-Modellen folgt die Infrastruktur Ihren Verfahren: Netzsegmentierung, Air-Gap-Option, eigenes Identitäts- und Schlüsselmanagement, wo anwendbar, eigene Backup- und DR-Richtlinie, Change Management und von Ihnen gewählte Update-Fenster.
Jede Komponente authentifiziert
Jedes Gerät verbindet sich mit eigener ID und eigenem Schlüssel mit dem MQTT-Broker, jede Anwendung nutzt die API mit eigenen Schlüsseln und JWT-Tokens. Eine solide Grundlage für einen Zero-Trust-Ansatz. Ereignishistorie und Befehlsstatus bilden einen Audit-Trail.
Kein Vendor Lock-in
Dieselbe API in allen Modellen und Migration zwischen ihnen ohne Gerätetausch: Es ändert sich die Serveradresse in den Zentralen, nicht die Hardware an den Türen. Kein Zwang zur Public Cloud.
Ein Stack für Zutritt und Gebäude
Zutrittskontrolle, Schlösser, Gegensprechanlagen, Aufzüge, Gebäudeautomation und Energiemessung in einer Plattform, im Space-Ökosystem auch E-Ladestationen, Energiespeicher und Zahlungsterminals. Herstellerneutrale Integration.
Schlanke, skalierbare Technologie
Ereignisgesteuerte Microservices, MQTT mit etwa 30 MB Datenverkehr pro Zentrale und Monat, REST-API und WebSocket. Bereitstellung in Containern (Docker, Kubernetes), auf Bare Metal oder in einer Proxmox-VE-Private-Cloud, vom Einzelserver bis zum Cluster.
Geht weit über typische Smart-Plattformen und klassische GLT hinaus
| Typische Cloud-Smart-Plattform | Klassische GLT | SPACE Engine | |
|---|---|---|---|
| Bereitstellungsoptionen | meist nur die Public Cloud des Anbieters | meist lokal, in der Architektur des Herstellers | drei Modelle: Cloud (SaaS), Private Cloud und Self-Hosted (Edge oder On-Premise) |
| Speicherort der Daten | vom Anbieter festgelegt | im Objekt | Ihre Wahl: Space Engine Cloud, Private Cloud oder Ihr Objekt |
| Sicherheitskontrolle beim Kunden | auf Kontoeinstellungen beschränkt | abhängig von Integrator und Hersteller | vollständig in den On-Premise-Modellen: Netz, Backups, Updates, Audit |
| Offenheit der API | oft eingeschränkte API oder nur Partnerintegrationen | oft geschlossene Protokolle und lizenzierte Schnittstellen | dokumentierte REST-API, WebSocket und Webhooks, in jedem Modell gleich |
| Integrationsumfang | hauptsächlich Smart-Home-Geräte | hauptsächlich Gebäudetechnik (HLK, Beleuchtung) | Zutritt, Schlösser, Gegensprechanlagen, Aufzüge, Automation und Energie in einem Stack |
| Skalierung | im Rahmen der Anbietertarife | Erweiterung von Hardware und Lizenzen | vom Einzelserver bis zum Kubernetes-Cluster; Modellwechsel ohne Gerätetausch |
Qualitativer Vergleich mit typischen Lösungen der jeweiligen Kategorie; einzelne Produkte können abweichen.
Plattformarchitektur
Derselbe Stack läuft in jedem Modell: auf einem Einzelserver, in virtuellen Maschinen oder in einem Kubernetes-Cluster.
1. Geräte
Schlösser, Wand- und Gesichtsterminals, Gegensprechanlagen, Aufzugssteuerungen, Sensoren, Schalter und Zähler. Z-Wave-Geräte verbinden sich über Space Gate Zentralen (S2-Sicherheit, AES-128), NB-IoT- und WLAN-Schlösser sowie TCP-Geräte über eigene Adapterdienste.
2. MQTT-Broker
Zentralen und Geräte tauschen mit dem Server schlanke MQTT-Nachrichten auf getrennten Kanälen für Berichte, Befehle und Antworten aus. Eine Zentrale verursacht etwa 30 MB pro Monat, überwiegend Heartbeat.
3. Space-Engine-Microservices
Der Kerndienst registriert und authentifiziert Geräte und Anwendungen, übersetzt Geräteprotokolle und pflegt Geräteschatten (zwischengespeicherter Zustand), den Ereignisstrom und das Betriebsprotokoll. Daneben laufen Protokolladapter und ein Integrations- und Benachrichtigungsdienst (Webhooks, E-Mail, SMS, Push, zeit- und bedingungsgesteuerte Szenen).
4. Datenschicht
Cache und Ereignisströme, eine Befehlswarteschlange für schlafende Geräte, eine NoSQL-Datenbank für Geräte und Nutzer sowie eine Zeitreihendatenbank mit Datenpipeline.
5. API und Anwendungen
REST-API (HTTP/JSON) für Befehle und Abfragen, WebSocket für Live-Ereignisse und HTTP-Webhooks für externe Systeme. Die API-Dokumentation beschreibt 273 Methoden und 120 Ereignistypen. Sie wird von der Space App, der Webkonsole, Hotelsystemen (PMS), GLT und Partneranwendungen genutzt.
Sicherheit
Geräte
Jedes Gerät authentifiziert sich mit eigenem Schlüssel, und die Nachrichteninhalte werden mit dem Geräteschlüssel verschlüsselt, der nie über das Netz übertragen wird. Die Z-Wave-Funkstrecke schützt S2 mit AES-128.
Anwendungen und API
Der API-Zugriff erfordert ein mit dem Anwendungsschlüssel signiertes JWT-Token; jede Anwendung hat eigene Schlüssel. Die Plattform unterstützt verschlüsselte Kommunikation über HTTPS und WSS.
Netz und Daten
In den On-Premise-Modellen läuft die Plattform in Ihrem Netz, auch ohne Internetzugang; ausgehenden Verkehr können Sie an der Firewall sperren. Schlüssel, Berechtigungen und Ereignishistorie bleiben in Ihrer Infrastruktur.
Audit und Updates
Die Historie von Öffnungen, Fehlversuchen und der Status jedes Befehls bilden einen Audit-Trail. Gerätefirmware wird per OTA aktualisiert; in den On-Premise-Modellen bestimmen Sie die Update-Termine.
Häufige Fragen
Space Engine Cloud, wenn ein schneller Start ohne eigene Infrastruktur zählt. Space Engine Private Cloud, wenn Sie Isolation brauchen, aber keine Server betreiben wollen. Space Engine Self-Hosted, wenn das System bei Ihnen laufen soll: Edge ist eine fertige Appliance, die wir auswählen und konfigurieren, On-Premise eine Bereitstellung auf Infrastruktur, die Sie besitzen oder bereitstellen. Wir helfen bei der Wahl des passenden Modells.
Ja. Alle Modelle nutzen dieselbe Plattform, dieselbe API und dieselben Geräte. Bei der Migration ändert sich die Serveradresse in den Zentralen, nicht die Hardware im Objekt.
In den On-Premise-Modellen (Space Engine Edge, Space Engine On-Premise) ja: Die gesamte Plattform läuft im lokalen Netz des Objekts. Bei Space Engine Cloud und Space Engine Private Cloud verbinden sich die Zentralen über das Internet mit dem Server.
Sehr wenig. Die MQTT-Kommunikation ist sehr schlank: Eine Zentrale überträgt etwa 30 MB Daten pro Monat, überwiegend Heartbeat-Nachrichten der Geräte.
Über REST-API (HTTP/JSON), WebSocket und HTTP-Webhooks, in jedem Modell gleich. Die API-Dokumentation (auf Englisch) stellen wir Integrationspartnern auf Anfrage zur Verfügung.
Finden wir das passende Modell für Ihr Projekt
Erzählen Sie uns von Ihrem Objekt und Ihren Sicherheitsanforderungen, und wir schlagen Bereitstellungsmodell, Architektur und Serverkonfiguration vor.
Rufen Sie an: +48 533 909 533