Nederland
Een jaar geleden begonnen we aan een moeilijke taak. We wilden de beste elementen van het bestaande besturingssysteem van de Ajax-Hub (2G) behouden, maar tegelijk de zwakke punten eruit halen en een solide basis leggen waarmee wij het Ajax-beveiligingssysteem verder zouden kunnen ontwikkelen. De hub is immers als een soort braintrust. Het moet de meest uitzonderlijke en betrouwbare schakel in de keten zijn. Duizenden uren aan engineering, honderden iteraties en verscheidene elegante software-oplossingen hebben ons uiteindelijk bij OS Malevich gebracht. Het is geen gewone update. Het is een volledig nieuw besturingssysteem van de hub.
Als u ergens op vastloopt, wees dan niet bang om terug te gaan naar de vorige versie
We besloten drie jaar geleden om een intelligent centrum voor beveiligingsbeheer te creëren: de Ajax-Hub (2G). We schreven de technische vereisten uit en begonnen na te denken over hoe we het moesten doen. Er waren drie mogelijkheden: C gebruiken, een realtime besturingssysteem gebruiken of Linux gebruiken.
Een typisch C-programma dat absolute controle zou verzekeren als een besturingssysteem, aangezien we elk onderdeel van het systeem zelf geschreven zouden hebben. Het nadeel was dat het project lang zou hebben geduurd, dat de schaalbaarheid slecht zou zijn geweest en dat er veel debugging nodig zou zijn.
Linux bood een heleboel kant-en-klare oplossingen en de mogelijkheid tot een parallelle en dus snelle ontwikkeling. We zouden hogere programmeertalen kunnen gebruiken, kunnen gebruikmaken van abstracties en een complexere toepassing kunnen bouwen. Maar tegelijkertijd zouden we kwetsbaarheden hebben, zouden we geen tijdslimieten voor activiteiten hebben en zouden we vaak niet de beste drivers hebben. Dat zou onaanvaardbaar zijn: we verkopen immers veiligheid en betrouwbaarheid.
Daarom hebben we gekozen voor een realtime besturingssysteem (RTOS). Het gaf ons de mogelijkheid om tegelijk een multifunctionele en betrouwbare toepassing te creëren. Realtime besturingssystemen worden gebruikt in liften, autoremmen en ballistische raketten. Ze zijn maximaal betrouwbaar, want als een mechanisme niet werkt binnen een strikt tijdsbestek, dan heeft de gebeurtenis geen zin meer en doet zich een catastrofe voor. Dit is een belangrijk verschil tussen RTOS en Linux, waar operaties in een wachtrij staan voor uitvoering. En dat is een van de redenen waarom Linux niet gebruikt wordt in professionele beveiligingssystemen.
De ontwikkeling duurde anderhalf jaar. We hebben een OS gemaakt dat geavanceerde communicatieprotocollen via de cloud over verschillende kanalen ondersteunt. Het beheert een netwerk van honderden radioapparaten. Het kan gelijktijdig alarmberichten versturen via IP-kanalen, telefoons bellen en sms-berichten versturen. Het beschikt over alle nodige professionele beveiligingsmogelijkheden en beschermt tegen aanvallen. We hebben dus ons oorspronkelijke doel kunnen bereiken. We zorgden voor uitgebreide functionaliteiten en tegelijkertijd voor een hoge betrouwbaarheid.
Maar zodra de Hub (2G) was uitgebracht, kwam er een golf van verzoeken om nieuwe functies. Beveiligingsbedrijven vroegen om een rechtstreekse verbinding met de hub, waarbij onze cloud werd omzeild. Onze Noorse partners wilden dat één branddetector alle branddetectoren in een systeem kon laten afgaan wanneer het een brand detecteerde en ze wilden dat dat gebeurde met de snelheid van bekabelde branddetectoren. De Duitse markt eiste dat het product voldeed aan de Europese normen van klasse 2 en ze wilden dat het een toetsenbord van een beveiligingssysteem kon ondersteunen. De gebruikers in Maleisië en Denemarken wilden uitgebreide automatiseringsmogelijkheden voor in huis. En voor Italië was een aparte rol voor de installateurs zeer belangrijk.
Door de bestaande architectuur konden we de functionaliteiten niet snel uitbreiden. We konden snel functies toevoegen aan de mobiele toepassingen, omdat ze ontwikkelomgevingen op hoog niveau hadden, maar het schrijven van software voor de hub vergde meer tijd. Wijzigingen waren moeilijk te testen en de uitvoering ervan vergde te veel middelen. We hadden een nieuw abstractieniveau nodig, een scheiding tussen hardware en software om complexe logica te kunnen bouwen.
We moesten beslissen hoe we het systeem verder zouden uitbouwen. Moesten we overschakelen op Linux? Of geleidelijk ons OS verfijnen? We moesten de betrouwbaarheid en stabiliteit van het realtime besturingssysteem behouden, maar tegelijkertijd hadden we de schaalbaarheid van een besturingssysteem op hoog niveau zoals Linux nodig. Opnieuw werkten de kant-en-klare oplossingen niet voor ons, dus moesten we onze eigen oplossingen bedenken.
Eenvoud heeft alleen waarde als het geworteld is in complexiteit
De basis van ons nieuwe OS vond zijn oorsprong in vereenvoudiging. We legden onszelf voorwaarden op: functies toevoegen mag het systeem niet ingewikkelder maken of de ontwikkelingssnelheid verminderen. We wilden niet van de koers afdwalen en dus kreeg het project de codenaam “Malevich,” ter ere van de beroemde, in Kiev geboren kunstenaar, Kazimir Malevich. Zijn “Zwart Vierkant” is een levendig voorbeeld van een briljant idee, gebaseerd op oneindige eenvoud.
Om OS Malevich te ontwikkelen, moesten we alles veranderen: de architectuur, de programmeringsaanpak, de coderings- en ontwerpnormen, de planning van de werkzaamheden en de ontwikkelomgeving. Hoewel de focus van het besturingssysteem op de uitvoeringstijd van processen bleef liggen, begon het kenmerken van Linux te krijgen. We implementeerden een soortgelijk mechanisme voor de toewijzing van CPU-tijd. Daardoor gebruikt de processor van de hub maximaal 20%, zelfs wanneer hij taken uitvoert die veel middelen vergen. Het systeem is ook modulair geworden. Er worden standaard API’s gebruikt om interactie mogelijk te maken tussen elementen. Het is makkelijk om met modules te werken, fouten kunnen snel opgespoord en geëlimineerd worden, en het is eenvoudig om de functionaliteit uit te breiden en te experimenteren om de ideale efficiëntie te bereiken.
We stellen Ajax-producten gelijk wat betreft ontwikkelingssnelheid. We kunnen nieuwe functies voor de hub, de server en de app even snel implementeren. Er zijn geen technische beperkingen aan onze ideeën.
Procedure voor het bijwerken van de hub
Tot op de dag van vandaag wordt een computerprogramma gewoonlijk niet gezien als een kunstvoorwerp. De schoonheid ervan wordt door de massa niet begrepen. Maar we hebben er alle vertrouwen in dat de ideeën die we hebben geïmplementeerd, mettertijd een klassieker zullen worden in het Internet of Things.
Meer informatie:
