Space Engine – a plataforma de servidores do ecossistema Space Intelligence
Servidores Space Engine
A plataforma Space em três modelos de implementação: de uma nuvem partilhada a uma instalação no seu próprio centro de dados. Decide onde funcionam os servidores, quem os opera e onde ficam os dados.
Os servidores Space Engine são o back end de todo o sistema Space: recebem eventos de fechaduras, terminais, videoporteiros, elevadores e sensores, executam comandos e disponibilizam-nos às suas aplicações através de uma API. A mesma plataforma Space Engine funciona em cada um dos três modelos, pelo que escolher um modelo é uma decisão sobre infraestrutura e responsabilidade, não sobre funcionalidades.
Três modelos de implementação
Space Engine Self-Hosted
O mesmo software nas suas instalações ou no seu centro de dados, em duas variantes de entrega.

Space Engine On-Premise
Self-Hosted · BYOI · Kubernetes · Docker · bare metal
Implementação gerida pelo cliente (BYOI) na infraestrutura que possui ou fornece: Kubernetes, Docker ou bare metal, recomenda-se Linux. A infraestrutura tem de cumprir os requisitos mínimos; adaptamos a implementação ao seu ambiente.
Comparação de modelos
| Parâmetro | Space Engine Cloud | Space Engine Private Cloud | Space Engine Self-Hosted | |
|---|---|---|---|---|
| Space Engine Edge | Space Engine On-Premise | |||
| Localização | servidores bare metal em localizações da Space | infraestrutura da Space (Proxmox VE) | no edifício do cliente | infraestrutura e hardware do cliente |
| Isolamento | lógica (multi-tenant) | máquinas virtuais dedicadas (single-tenant) | física, rede isolada, opção air-gap | total, na rede do cliente, opção air-gap |
| Operado por | Space | Space | o cliente, com apoio da Space | a equipa de TI do cliente, com apoio de implementação da Space |
| Ambiente | gerido pela Space | máquinas virtuais Proxmox VE | servidor Intel, configuração base i5-6400 / 16 GB | Kubernetes, Docker ou bare metal; recomenda-se Linux |
| Escalabilidade | a cargo da Space | mais recursos de máquinas virtuais | configuração ampliada ou cluster Kubernetes | de um servidor a um cluster |
| Cliente típico | hotéis, escritórios, edifícios sem TI própria | organizações que precisam de isolamento sem servidores próprios | edifícios que exigem infraestrutura isolada: administração, hospitais, infraestruturas críticas | grandes organizações com TI e centro de dados próprios |
Para CTO, arquitetos de TI, CISO e integradores
Uma plataforma, três modelos, controlo total
Uma combinação pouco comum: a mesma plataforma e a mesma API, de uma nuvem partilhada a uma instalação air-gapped no seu próprio centro de dados. Por isso o Space Engine serve hotéis, escritórios e imobiliário comercial, residencial e PRS, saúde, setor público, infraestruturas críticas e indústria, enquanto o controlo da infraestrutura e dos procedimentos de segurança pode ficar do seu lado.
Soberania e residência dos dados
Escolhe onde funcionam os servidores e onde os dados são guardados: na nuvem Space, numa nuvem privada ou no seu próprio edifício. Isto facilita uma arquitetura que cumpra os requisitos do RGPD e da NIS2.
A sua governação de segurança
Nos modelos on-premise a infraestrutura segue os seus procedimentos: segmentação de rede, opção air-gap, gestão própria de identidades e chaves quando aplicável, política própria de cópias de segurança e recuperação (DR), gestão de alterações e janelas de atualização à sua escolha.
Cada componente autenticado
Cada dispositivo liga-se ao broker MQTT com o seu próprio ID e chave, e cada aplicação usa a API com as suas próprias chaves e tokens JWT. Uma boa base para uma abordagem zero trust. O histórico de eventos e o estado dos comandos formam um registo de auditoria.
Sem dependência do fornecedor
A mesma API em todos os modelos e migração entre eles sem substituir dispositivos: muda o endereço do servidor nos hubs, não o hardware das portas. Nunca é obrigado a usar uma nuvem pública.
Um único stack para acessos e edifício
Controlo de acessos, fechaduras, videoporteiros, elevadores, automação do edifício e medição de energia numa só plataforma e, no ecossistema Space, também carregamento de VE, armazenamento de energia e terminais de pagamento. Integração independente do fabricante.
Tecnologia leve e escalável
Microsserviços orientados a eventos, MQTT com cerca de 30 MB de tráfego por hub por mês, API REST e WebSocket. Implementação em contentores (Docker, Kubernetes), em bare metal ou numa nuvem privada Proxmox VE, de um servidor a um cluster.
Vai muito além das plataformas smart típicas e dos BMS clássicos
| Plataforma smart típica na nuvem | BMS clássico | SPACE Engine | |
|---|---|---|---|
| Opções de implementação | normalmente apenas a nuvem pública do fornecedor | normalmente local, na arquitetura do fabricante | três modelos: Cloud (SaaS), Private Cloud e Self-Hosted (Edge ou On-Premise) |
| Localização dos dados | determinada pelo fornecedor | no edifício | à sua escolha: nuvem Space, nuvem privada ou o seu edifício |
| Controlo da segurança pelo cliente | limitado às definições da conta | depende do integrador e do fabricante | total nos modelos on-premise: rede, cópias, atualizações, auditoria |
| Abertura da API | muitas vezes API limitada ou integrações apenas para parceiros | muitas vezes protocolos fechados e interfaces licenciadas | API REST documentada, WebSocket e webhooks, iguais em todos os modelos |
| Âmbito da integração | sobretudo dispositivos smart home | sobretudo instalações do edifício (AVAC, iluminação) | acessos, fechaduras, videoporteiros, elevadores, automação e energia num só stack |
| Escalabilidade | dentro dos planos do fornecedor | expansão de hardware e licenças | de um servidor a um cluster Kubernetes; mudança de modelo sem substituir dispositivos |
Comparação qualitativa com soluções típicas de cada categoria; os produtos concretos podem variar.
Arquitetura da plataforma
O mesmo stack funciona em todos os modelos: num único servidor, em máquinas virtuais ou num cluster Kubernetes.

1. Dispositivos
Fechaduras, terminais de parede e faciais, videoporteiros, controladores de elevador, sensores, interruptores e contadores. Os dispositivos Z-Wave ligam-se através dos hubs Space Gate (segurança S2, AES-128); as fechaduras NB-IoT e Wi-Fi e os dispositivos TCP, através de serviços adaptadores dedicados.
2. Broker MQTT
Os hubs e dispositivos trocam com o servidor mensagens MQTT leves em canais separados para relatórios, comandos e respostas. Um hub representa cerca de 30 MB por mês, sobretudo heartbeat.
3. Microsserviços Space Engine
O serviço principal regista e autentica dispositivos e aplicações, traduz os protocolos dos dispositivos e mantém as sombras de dispositivo (estado em cache), o fluxo de eventos e o registo de operações. Ao lado funcionam adaptadores de protocolo e um serviço de integração e notificações (webhooks, e-mail, SMS, push, cenas temporizadas e condicionais).
4. Camada de dados
Cache e fluxos de eventos, uma fila de comandos para dispositivos em repouso, uma base de dados NoSQL de dispositivos e utilizadores e uma base de dados de séries temporais com pipeline de dados.
5. API e aplicações
API REST (HTTP/JSON) para comandos e consultas, WebSocket para eventos em tempo real e webhooks HTTP para sistemas externos. A documentação da API descreve 273 métodos e 120 tipos de eventos. É usada pela app Space, pela consola web, por sistemas hoteleiros (PMS), BMS e aplicações de parceiros.
Segurança
Dispositivos
Cada dispositivo autentica-se com a sua própria chave e o conteúdo das mensagens é cifrado com a chave do dispositivo, que nunca é enviada pela rede. O rádio Z-Wave é protegido por S2 com AES-128.
Aplicações e API
O acesso à API exige um token JWT assinado com a chave da aplicação; cada aplicação tem as suas próprias chaves. A plataforma suporta comunicação cifrada HTTPS e WSS.
Rede e dados
Nos modelos on-premise a plataforma funciona na sua rede, também sem acesso à internet; pode bloquear o tráfego de saída na firewall. As chaves, as permissões e o histórico de eventos ficam na sua infraestrutura.
Auditoria e atualizações
O histórico de aberturas, tentativas falhadas e o estado de cada comando formam um registo de auditoria. O firmware dos dispositivos é atualizado por OTA; nos modelos on-premise é o cliente que define as datas das atualizações.
Perguntas frequentes
Space Engine Cloud quando importa arrancar depressa sem infraestrutura própria. Space Engine Private Cloud quando precisa de isolamento mas não quer manter servidores. Space Engine Self-Hosted quando o sistema deve funcionar nas suas instalações: o Edge é um appliance pronto que selecionamos e configuramos, e o On-Premise é uma implementação na infraestrutura que possui ou fornece. Ajudamos a escolher o modelo adequado.
Sim. Todos os modelos usam a mesma plataforma, a mesma API e os mesmos dispositivos. Na migração muda o endereço do servidor nos hubs, não o hardware no edifício.
Nos modelos on-premise (Space Engine Edge, Space Engine On-Premise), sim: toda a plataforma funciona na rede local do edifício. No Space Engine Cloud e no Space Engine Private Cloud os hubs ligam-se ao servidor pela internet.
Muito pouca. A comunicação MQTT é muito leve: um hub envia cerca de 30 MB de dados por mês, sobretudo mensagens heartbeat dos dispositivos.
Através da API REST (HTTP/JSON), WebSocket e webhooks HTTP, iguais em todos os modelos. Disponibilizamos a documentação da API (em inglês) aos parceiros de integração mediante pedido.
Vamos escolher o modelo para o seu projeto
Fale-nos do seu edifício e dos requisitos de segurança e propomos um modelo de implementação, uma arquitetura e uma configuração de servidor.
Ligue: +48 533 909 533

