Space Engine: la plataforma de servidores del ecosistema Space Intelligence
Servidores Space Engine
La plataforma Space en tres modelos de despliegue: desde una nube compartida hasta una instalación en su propio centro de datos. Usted decide dónde funcionan los servidores, quién los opera y dónde se quedan los datos.
Los servidores Space Engine son el back end de todo el sistema Space: reciben eventos de cerraduras, terminales, videoporteros, ascensores y sensores, ejecutan comandos y los ponen a disposición de sus aplicaciones mediante una API. La misma plataforma Space Engine funciona en cada uno de los tres modelos, así que elegir un modelo es una decisión sobre infraestructura y responsabilidad, no sobre funciones.
Tres modelos de despliegue
Space Engine Cloud
SaaS · multi-tenant · bare metal
Nube compartida (SaaS) en servidores bare metal de Space. Aislamiento lógico de clientes, sin infraestructura propia, el inicio más rápido.
Space Engine Private Cloud
IaaS · single-tenant · Proxmox VE
Nube privada en infraestructura de Space: máquinas virtuales Proxmox VE dedicadas solo para usted, gestionadas por Space. El aislamiento de un servidor dedicado con la comodidad de la nube.
Space Engine Self-Hosted
El mismo software en sus instalaciones o en su centro de datos, en dos variantes de entrega.
Space Engine Edge
Self-Hosted · appliance · plug-and-play
Un appliance: módulo de servidor listo cuyo hardware seleccionamos y preconfiguramos. Lo conecta en sus instalaciones y funciona; los datos se quedan in situ y, si hace falta, el sistema funciona sin internet.
Space Engine On-Premise
Self-Hosted · BYOI · Kubernetes · Docker · bare metal
Despliegue gestionado por el cliente (BYOI) en la infraestructura que usted posee o aporta: Kubernetes, Docker o bare metal, se recomienda Linux. La infraestructura debe cumplir los requisitos mínimos; adaptamos el despliegue a su entorno.
Comparación de modelos
| Parámetro | Space Engine Cloud | Space Engine Private Cloud | Space Engine Self-Hosted | |
|---|---|---|---|---|
| Space Engine Edge | Space Engine On-Premise | |||
| Ubicación | servidores bare metal en ubicaciones de Space | infraestructura de Space (Proxmox VE) | en el edificio del cliente | infraestructura y hardware del cliente |
| Aislamiento | lógica (multi-tenant) | máquinas virtuales dedicadas (single-tenant) | física, red aislada, opción air-gap | total, en la red del cliente, opción air-gap |
| Operado por | Space | Space | el cliente, con soporte de Space | el equipo de TI del cliente, con soporte de implantación de Space |
| Entorno | gestionado por Space | máquinas virtuales Proxmox VE | servidor Intel, configuración base i5-6400 / 16 GB | Kubernetes, Docker o bare metal; se recomienda Linux |
| Escalabilidad | a cargo de Space | más recursos de máquinas virtuales | configuración ampliada o clúster Kubernetes | de un servidor a un clúster |
| Cliente típico | hoteles, oficinas, edificios sin TI propia | organizaciones que necesitan aislamiento sin servidores propios | edificios que requieren infraestructura aislada: administración, hospitales, infraestructuras críticas | grandes organizaciones con TI y centro de datos propios |
Para CTO, arquitectos de TI, CISO e integradores
Una plataforma, tres modelos, control total
Una combinación poco habitual: la misma plataforma y la misma API, desde una nube compartida hasta una instalación air-gapped en su propio centro de datos. Por eso Space Engine encaja en hoteles, oficinas e inmuebles comerciales, residencial y PRS, sanidad, sector público, infraestructuras críticas e industria, mientras el control de la infraestructura y de los procedimientos de seguridad puede quedar de su lado.
Soberanía y residencia de datos
Usted elige dónde funcionan los servidores y dónde se almacenan los datos: en la nube Space, en una nube privada o en su propio edificio. Esto facilita una arquitectura que cumpla los requisitos del RGPD y NIS2.
Su gobierno de la seguridad
En los modelos on-premise la infraestructura sigue sus procedimientos: segmentación de red, opción air-gap, gestión propia de identidades y claves cuando proceda, política propia de copias de seguridad y recuperación (DR), gestión de cambios y ventanas de actualización elegidas por usted.
Cada componente autenticado
Cada dispositivo se conecta al broker MQTT con su propio ID y clave, y cada aplicación usa la API con sus propias claves y tokens JWT. Una buena base para un enfoque zero trust. El historial de eventos y el estado de los comandos forman un registro de auditoría.
Sin dependencia del proveedor
La misma API en todos los modelos y migración entre ellos sin sustituir dispositivos: cambia la dirección del servidor en los hubs, no el hardware de las puertas. Nunca está obligado a usar una nube pública.
Un solo stack para accesos y edificio
Control de accesos, cerraduras, videoporteros, ascensores, automatización del edificio y medición de energía en una sola plataforma, y en el ecosistema Space también recarga de VE, almacenamiento de energía y terminales de pago. Integración independiente del fabricante.
Tecnología ligera y escalable
Microservicios orientados a eventos, MQTT con unos 30 MB de tráfico por hub al mes, API REST y WebSocket. Despliegue en contenedores (Docker, Kubernetes), en bare metal o en una nube privada Proxmox VE, de un servidor a un clúster.
Va mucho más allá de las plataformas smart típicas y los BMS clásicos
| Plataforma smart típica en la nube | BMS clásico | SPACE Engine | |
|---|---|---|---|
| Opciones de despliegue | normalmente solo la nube pública del proveedor | normalmente local, con la arquitectura del fabricante | tres modelos: Cloud (SaaS), Private Cloud y Self-Hosted (Edge u On-Premise) |
| Ubicación de los datos | la determina el proveedor | en el edificio | a su elección: nube Space, nube privada o su edificio |
| Control de la seguridad por el cliente | limitado a los ajustes de la cuenta | depende del integrador y del fabricante | total en los modelos on-premise: red, copias, actualizaciones, auditoría |
| Apertura de la API | a menudo API limitada o integraciones solo para socios | a menudo protocolos cerrados e interfaces con licencia | API REST documentada, WebSocket y webhooks, iguales en todos los modelos |
| Alcance de la integración | principalmente dispositivos smart home | principalmente instalaciones del edificio (HVAC, iluminación) | accesos, cerraduras, videoporteros, ascensores, automatización y energía en un solo stack |
| Escalabilidad | dentro de los planes del proveedor | ampliación de hardware y licencias | de un servidor a un clúster Kubernetes; cambio de modelo sin sustituir dispositivos |
Comparación cualitativa con soluciones típicas de cada categoría; los productos concretos pueden variar.
Arquitectura de la plataforma
El mismo stack funciona en todos los modelos: en un único servidor, en máquinas virtuales o en un clúster Kubernetes.
1. Dispositivos
Cerraduras, terminales de pared y faciales, videoporteros, controladores de ascensor, sensores, interruptores y contadores. Los dispositivos Z-Wave se conectan a través de los hubs Space Gate (seguridad S2, AES-128); las cerraduras NB-IoT y Wi-Fi y los dispositivos TCP, mediante servicios adaptadores dedicados.
2. Broker MQTT
Los hubs y dispositivos intercambian con el servidor mensajes MQTT ligeros por canales separados para informes, comandos y respuestas. Un hub supone unos 30 MB al mes, sobre todo heartbeat.
3. Microservicios Space Engine
El servicio principal registra y autentica dispositivos y aplicaciones, traduce los protocolos de los dispositivos y mantiene las sombras de dispositivo (estado en caché), el flujo de eventos y el registro de operaciones. Junto a él funcionan adaptadores de protocolo y un servicio de integración y notificaciones (webhooks, e-mail, SMS, push, escenas programadas y condicionales).
4. Capa de datos
Caché y flujos de eventos, una cola de comandos para dispositivos en reposo, una base de datos NoSQL de dispositivos y usuarios y una base de datos de series temporales con canal de datos.
5. API y aplicaciones
API REST (HTTP/JSON) para comandos y consultas, WebSocket para eventos en tiempo real y webhooks HTTP para sistemas externos. La documentación de la API describe 273 métodos y 120 tipos de eventos. La utilizan la app Space, la consola web, los sistemas hoteleros (PMS), los BMS y las aplicaciones de socios.
Seguridad
Dispositivos
Cada dispositivo se autentica con su propia clave y el contenido de los mensajes se cifra con la clave del dispositivo, que nunca se envía por la red. La radio Z-Wave está protegida por S2 con AES-128.
Aplicaciones y API
El acceso a la API requiere un token JWT firmado con la clave de la aplicación; cada aplicación tiene sus propias claves. La plataforma admite comunicación cifrada HTTPS y WSS.
Red y datos
En los modelos on-premise la plataforma funciona en su red, también sin acceso a internet; puede bloquear el tráfico saliente en el cortafuegos. Las claves, los permisos y el historial de eventos se quedan en su infraestructura.
Auditoría y actualizaciones
El historial de aperturas, intentos fallidos y el estado de cada comando forman un registro de auditoría. El firmware de los dispositivos se actualiza por OTA; en los modelos on-premise usted fija las fechas de actualización.
Preguntas frecuentes
Space Engine Cloud cuando importa empezar rápido sin infraestructura propia. Space Engine Private Cloud cuando necesita aislamiento pero no quiere mantener servidores. Space Engine Self-Hosted cuando el sistema debe funcionar en sus instalaciones: Edge es un appliance listo que seleccionamos y configuramos, y On-Premise es un despliegue en la infraestructura que usted posee o aporta. Le ayudamos a elegir el modelo adecuado.
Sí. Todos los modelos usan la misma plataforma, la misma API y los mismos dispositivos. En la migración cambia la dirección del servidor en los hubs, no el hardware del edificio.
En los modelos on-premise (Space Engine Edge, Space Engine On-Premise), sí: toda la plataforma funciona en la red local del edificio. En Space Engine Cloud y Space Engine Private Cloud los hubs se conectan al servidor por internet.
Muy poca. La comunicación MQTT es muy ligera: un hub envía unos 30 MB de datos al mes, sobre todo mensajes heartbeat de los dispositivos.
Mediante la API REST (HTTP/JSON), WebSocket y webhooks HTTP, iguales en todos los modelos. Facilitamos la documentación de la API (en inglés) a los socios de integración bajo petición.
Elijamos el modelo para su proyecto
Cuéntenos cómo es su edificio y sus requisitos de seguridad, y le propondremos un modelo de despliegue, una arquitectura y una configuración de servidor.
Llame al: +48 533 909 533