Portugal
Há um ano, empreendemos uma tarefa difícil. Queríamos preservar as melhores partes do sistema operativo Ajax Hub (2G) existente, retirar ao mesmo tempo quaisquer pontos fracos e construir uma base sólida que nos permita continuar a desenvolver o sistema de segurança Ajax. No fim de contas, o hub é como um cérebro de confiança. Precisa de ser o elo mais excecional e fiável da cadeia. Milhares de horas de engenharia, centenas de iterações e várias soluções elegantes de software levaram-nos ao OS Malevich. Não se trata apenas de mais uma atualização. É um sistema operativo para hub completamente novo.
Quando se chega a um beco sem saída, não se deve ter medo de virar para trás
Há três anos, decidimos criar um centro de gestão de segurança inteligente— Ajax Hub (2G). Redigimos os requisitos técnicos e começamos a pensar como o fazer. Tínhamos três opções — utilizar C, utilizar um sistema operativo de tempo real ou utilizar o Linux.
Um programa C típico que asseguraria o controlo absoluto como sistema operativo, uma vez que nós próprios tivéssemos escrito cada componente do sistema. A contrapartida era que o projeto demoraria muito tempo, a sua escalabilidade teria sido fraca e teria necessitado de muita depuração.
O Linux oferecia várias soluções prontas a utilizar, assim como a possibilidade de desenvolvimento em paralelo, ou seja, rápido. Seríamos capazes de programar em linguagem de alto nível, utilizar abstrações e criar uma aplicação mais complexa. Mas ao mesmo tempo, teríamos vulnerabilidades, não teríamos limites de tempo para as operações e com frequência não iríamos ter os melhores controladores. Isto seria inaceitável — nós vendemos segurança e fiabilidade.
Portanto, escolhemos um sistema operativo de tempo real (RTOS). Este sistema deu-nos a oportunidade de criar uma aplicação simultaneamente multifuncional e fiável. Os sistemas operativos de tempo real são utilizados em elevadores, travões automóveis e mísseis balísticos. São extremamente fiáveis, porque se um mecanismo não funcionar dentro de um período de tempo estrito, o evento deixa de fazer sentido e ocorre uma catástrofe. Esta é uma diferença fundamental entre o RTOS e o Linux, onde as operações aguardam numa fila de execução. E também é uma das razões pelas quais o Linux não é utilizado em sistemas de segurança profissionais.
O desenvolvimento demorou um ano e meio. Criámos um OS compatível com protocolos avançados de comunicação em nuvem através de vários canais. O sistema gere uma rede de centenas de dispositivos rádio. Pode simultaneamente enviar mensagens de alarme através de canais IP, ligar para telefones e enviar SMS. Possui todas as capacidades necessárias de um sistema de segurança profissional e protege contra ataques. Sendo assim, conseguimos cumprir o nosso objetivo inicial. Disponibilizámos uma funcionalidade abrangente, ao mesmo tempo que garantimos elevada fiabilidade.
No entanto, assim que o Hub (2G) foi lançado, surgiu uma onda de pedidos de novas funcionalidades. As centrais recetoras de alarmes solicitaram uma ligação direta ao hub, contornando a nossa nuvem. Os nossos parceiros noruegueses queriam que um detetor de incêndio fosse capaz de disparar todos os detetores de incêndio num sistema quando detetasse um incêndio, e queriam que isso acontecesse à velocidade dos alarmes de incêndio com fios. O mercado alemão exigiu que o produto cumprisse as normas europeias de Grau 2 e fosse compatível com um teclado de sistema de segurança. Na Malásia e na Dinamarca, os utilizadores pretendiam capacidades de automatização abrangentes para as casas. Para a Itália, uma função em separado para os instaladores era muito importante.
A arquitetura existente não nos permitia expandir a funcionalidade rapidamente. Pudemos adicionar funcionalidades às aplicações móveis rapidamente, uma vez que estas estão em ambientes de desenvolvimento de alto nível, mas criar software para o hub requeria mais tempo. As alterações eram difíceis de testar e a sua implementação necessitava de demasiados recursos. Para criar lógica complexa, precisávamos de um novo nível de abstração, uma separação entre hardware e software.
Tínhamos de decidir como continuar a construir o sistema. Precisávamos de mudar para o Linux? Refinar gradualmente o nosso OS? Precisávamos de manter a fiabilidade e a estabilidade do sistema operativo de tempo real, mas, ao mesmo tempo, precisávamos da escalabilidade de um sistema operativo de alto nível, como o Linux. Mais uma vez, as soluções prontas a utilizar não funcionaram connosco, por isso tivemos de criar a nossa própria solução.
A simplicidade só tem valor se for fundada na complexidade
A base do nosso novo OS era a ideia da simplificação. Definimos condições para nós próprios: adicionar funcionalidades não deve complicar o sistema ou reduzir a velocidade de desenvolvimento. Para não nos desviarmos do objetivo, o projeto foi denominado “Malevich”, em honra do famoso artista nascido em Kiev, Kazimir Malevich. O seu “Black Square” (Quadrado Negro) é um exemplo expressivo de uma ideia brilhante baseada na simplicidade infinita.
Para criar o OS Malevich, tínhamos de mudar tudo — a arquitetura, a abordagem de programação, os padrões de código e design, a organização do trabalho, o ambiente de desenvolvimento. Apesar de o sistema operativo continuar a focar-se no tempo de execução de processos, começou a ganhar funcionalidades do Linux. Implementámos um mecanismo semelhante para atribuir o tempo da CPU. Como resultado, o processador do hub utiliza um máximo de 20%, mesmo ao executar tarefas intensivas em termos de recursos. O sistema também se tornou modular; são utilizadas API padrão para permitir a interação entre elementos. É fácil trabalhar com módulos, pois os erros podem ser rapidamente identificados e eliminados e é simples aumentar a funcionalidade e experimentar atingir a eficiência ideal.
Configuramos os produtos Ajax da mesma forma em termos de velocidade de desenvolvimento. Podemos implementar novas funcionalidades para o hub, servidor e app de forma igualmente rápida. Não existem limitações técnicas para as nossas ideias.
Procedimento de atualização do Hub
Nos dias de hoje, um programa de computador não é habitualmente considerado um objeto de arte. A sua beleza não é compreendida pelas massas. Mas estamos confiantes de que, ao longo do tempo, as ideias que implementámos se tornarão um clássico na Internet das coisas.
Leia mais:
