Portugal
Há um ano, empreendemos uma tarefa difícil. Queríamos preservar as melhores partes do sistema operativo Ajax Hub 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. 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 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:
