Deutschland
Vor einem Jahr nahmen wir eine schwierige Aufgabe in Angriff. Wir hatten vor, die besten Teile des bestehenden Betriebssystems für die Hub (2G)-Zentralen von Ajax beizubehalten, jegliche Schwachstellen zu beseitigen und eine solide Grundlage für die Weiterentwicklung des Ajax Sicherheitssystems zu schaffen. Die Hub-Zentrale ist schließlich so etwas wie ein Braintrust. Sie ist das außergewöhnlichste und zuverlässigste Glied der Kette. Tausende Entwicklungsstunden, Hunderte Iterationen und verschiedene elegante Softwarelösungen haben OS Malevich für Hub-Zentralen hervorgebracht. Es handelt sich dabei nicht nur um ein weiteres Update. Es ist vielmehr ein völlig neues Betriebssystem für Hub-Zentralen.
Wer in eine Sackgasse gerät, darf getrost kehrtmachen
Vor drei Jahren beschlossen wir, eine intelligente Sicherheitsverwaltungs-Zentrale ins Leben zu rufen. Das Ergebnis war Ajax Hub (2G). Nachdem wir das technische Konzept auf die Beine gestellt hatten, galt es, einen geeigneten Ansatz für die Umsetzung zu ermitteln. Dabei standen uns drei Möglichkeiten zur Verfügung: die Programmiersprache C, ein Echtzeit-Betriebssystem oder Linux.
Ein typisches C-Programm hätte ein Betriebssystem geliefert, das uns ein Höchstmaß an Kontrolle garantiert hätte, da wir in der Lage gewesen wären, jede Komponente des Systems selbst zu schreiben. Der Haken an der Sache war, dass die Umsetzung des Projekts längere Zeit in Anspruch genommen hätte, die Skalierbarkeit gelitten hätte und großer Aufwand zur Behebung von Fehlern erforderlich gewesen wäre.
Linux verfügte über zahlreiche vorgefertigte Lösungen und bot die Möglichkeit der parallelen und damit schnellen Entwicklung. Wir hätten die Möglichkeit gehabt, in Hochsprachen zu programmieren, Abstraktionen zu nutzen und eine komplexe Anwendung zu entwickeln. Gleichzeitig wäre es jedoch zu Schwachstellen gekommen, es hätte keine Zeitbegrenzungen für Vorgänge gegeben und wir hätten oft nicht die optimalen Treiber nutzen können. Das kam natürlich nicht in Frage – immerhin steht unser Angebot für Sicherheit und Zuverlässigkeit.
Also entschieden wir uns für ein Echtzeit-Betriebssystem (RTOS). Dadurch hatten wir die Möglichkeit, eine Anwendung bereitzustellen, die zugleich multifunktional als auch zuverlässig war. Echtzeit-Betriebssysteme werden in Aufzügen, Fahrzeugbremsen und ballistischen Raketen eingesetzt. Sie sind höchst zuverlässig, denn wenn ein Mechanismus nicht innerhalb eines streng begrenzten Zeitrahmens funktioniert, ist das Ereignis nicht mehr sinnvoll und es kommt zu einer Katastrophe. Hierin besteht ein entscheidender Unterschied zwischen RTOS und dem Linux-Betriebssystem, bei dem Vorgänge in eine Ausführungswarteschlange gestellt werden. Das ist einer der Gründe, warum Linux nicht in professionellen Sicherheitssystemen verwendet wird.
Die Entwicklung dauerte anderthalb Jahre. Wir haben ein Betriebssystem entwickelt, das fortschrittliche Cloud-Kommunikationsprotokolle über mehrere Kanäle unterstützt. Es verwaltet ein Netz aus Hunderten von Funkgeräten. Es kann gleichzeitig Alarmmeldungen über IP-Kanäle senden, Telefone anwählen und SMS-Nachrichten übermitteln. Es weist alle erforderlichen Fähigkeiten eines professionellen Sicherheitssystems auf und schützt effektiv vor Angriffen. So gelang es uns, unser anfänglich gesetztes Ziel zu erreichen. Wir stellten umfassende Funktionen bereit und sorgten zugleich für hohe Zuverlässigkeit.
Unmittelbar nach der Veröffentlichung des Hub (2G) wurden wir jedoch mit Anfragen in Bezug auf neue Funktionen überhäuft. Sicherheitsdienste verlangten eine Direktverbindung zur Hub-Zentrale unter Umgehung unserer Cloud. Unsere norwegischen Partner wünschten sich einen Feuermelder mit der Fähigkeit, bei Erkennung eines Feuers alle Feuermelder innerhalb eines Systems auszulösen – das Ganze mit der Geschwindigkeit eines kabelgebundenen Feuermelders. Der deutsche Markt verlangte, dass das Produkt die Anforderungen an Grade 2 der europäischen Normen für Alarmeinrichtungen erfüllen und Bedienteile für Sicherheitssysteme unterstützen sollte. In Malaysia und Dänemark forderten Anwender umfassende Hausautomatisierungsfunktionen. In Italien spielte für Installateure ein anderer Aspekt eine maßgebliche Rolle.
Die vorhandene Systemarchitektur erlaubte es uns nicht, unser Funktionsangebot zeitnah zu erweitern. Wir konnten zwar rasch Funktionen zur mobilen Anwendung hinzufügen, da fortschrittliche Entwicklungsumgebungen vorhanden waren, für das Schreiben der Software für die Hub-Zentralen war jedoch mehr Zeit erforderlich. Das Testen von Änderungen erwies sich als schwierig und die Umsetzung erforderte zu viele Ressourcen. Zur Entwicklung einer komplexen Logik benötigten wir eine neue Abstraktionsebene: eine Trennung zwischen Hardware und Software.
Wir mussten entscheiden, wie wir das System weiterentwickeln wollten. Mussten wir auf Linux umstellen? Allmählich unser Betriebssystem optimieren? Es galt, die Zuverlässigkeit und Stabilität unseres Echtzeit-Betriebssystems zu bewahren und gleichzeitig die Skalierbarkeit eines ansprechenden Betriebssystems wie Linux zu erzielen. Wie schon gesagt, waren bereits verfügbare Lösungen für unsere Zwecke nicht geeignet, sodass wir uns selbst behelfen mussten.
Einfachheit ist nur dann von Nutzen, wenn sie auf Komplexität beruht
Der Ausgangspunkt unseres neuen Betriebssystems war das Konzept der Einfachheit. Wir legten Bedingungen für unser Vorhaben fest: Das Hinzufügen von Funktionen durfte nicht das System verkomplizieren oder die Entwicklung verlangsamen. Um nicht vom Kurs abzukommen, wurde das Projekt „Malevich“ genannt, nach dem berühmten in Kiew geborenen Künstler Kasimir Malewitsch. Sein „Schwarzes Quadrat“ ist ein lebendiges Beispiel einer glänzenden Idee, die auf unbeschränkter Einfachheit beruht.
Um OS Malevich für Hub-Zentralen zu entwickeln, mussten wir alles überdenken – von der Systemarchitektur und dem Entwicklungsansatz über die Programmier- und Konzeptnormen bis hin zur Organisation der Arbeit und der Entwicklungsumgebung. Obwohl die Prozessausführungszeit weiterhin den Schwerpunkt des Betriebssystems bildete, begannen Funktionen zu entstehen, die denen von Linux ähnelten. Wir implementierten einen ähnlichen Mechanismus für die Zuteilung von CPU-Zeit. Infolgedessen nutzt der Prozessor unserer Hub-Zentralen heute selbst bei der Ausführung ressourcenintensiver Aufgaben maximal 20 Prozent der verfügbaren CPU. Das System basiert darüber hinaus heute auf einem modularen Konzept, wobei Standard-APIs die Interaktion zwischen Elementen ermöglichen. Die Arbeit mit Modulen gestaltet sich einfach: Es ist möglich, Fehler zeitnah zu ermitteln und zu beseitigen, Funktionen rasch zu verbessern und Experimente durchzuführen, um ein Maximum an Effizienz zu erreichen.
In Sachen Entwicklungszeit achten wir bei allen Ajax Produkten auf Ebenbürtigkeit. Wir können gleichermaßen schnell neue Funktionen für die Hub-Zentralen, den Server und die App implementieren. Unseren Ideen sind keine technischen Grenzen gesetzt.
11 neue Möglichkeiten mit Hub OS 2 Malevich für Hub-Zentralen
In der heutigen Zeit wird ein Computerprogramm in der Regel nicht als Kunstobjekt betrachtet. Seine Schönheit wird von den meisten Menschen verkannt. Wir sind jedoch überzeugt, dass die Ideen, die wir umgesetzt haben, sich im Laufe der Zeit zu einem Klassiker des Internets der Dinge entwickeln werden.
Erfahren Sie mehr:
