Polska
Rok temu postawiliśmy sobie trudne zadanie. Chcieliśmy zachować najlepsze elementy istniejącego systemu operacyjnego Ajax Hub (2G), jednocześnie usuwając wszelkie słabości i tworząc mocne fundamenty, które umożliwiłyby nam dalsze rozwijanie systemu alarmowego Ajax. Przecież hub jest jak zespół ekspertów. Musi być najbardziej wyjątkowym i niezawodnym ogniwem łańcucha. Tysiące godzin spędzonych na pracach inżynieryjnych, setki wersji i kilka eleganckich rozwiązań programowych doprowadziły do powstania OS Malevich. To nie jest po prostu kolejna aktualizacja. To całkiem nowy system operacyjny huba.
Po wjechaniu w ślepą uliczkę nie bój się zawrócić
Trzy lata temu postanowiliśmy stworzyć inteligentne centrum zarządzania ochroną — Ajax Hub (2G). Rozpisaliśmy wymagania techniczne i zaczęliśmy zastanawiać się, jak tego dokonać. Mieliśmy trzy opcje — użycie języka C, użycie systemu operacyjnego czasu rzeczywistego lub użycie Linuxa.
Typowy program C zapewniłby kompletną kontrolę, ponieważ każdy element systemu byłby napisany przez nas. Wadą było to, że projekt zabrałby więcej czasu, nie byłby dobrze skalowalny i wymagałby dużo debugowania.
Linux oferował gotowe rozwiązania, jak również możliwość jednoczesnego i szybkiego rozwoju. Bylibyśmy w stanie programować w językach wysokiego poziomu, korzystać z abstrakcji i zbudować bardziej złożoną aplikację. Jednocześnie mielibyśmy do czynienia z lukami, nie mielibyśmy limitów czasu operacji i często nie posiadalibyśmy najlepszych sterowników. To byłoby nie do zaakceptowania — w końcu sprzedajemy bezpieczeństwo i niezawodność.
Dlatego postawiliśmy na system operacyjny czasu rzeczywistego (RTOS). Umożliwiło nam to stworzenie aplikacji wielofunkcyjnej, a jednocześnie niezawodnej. Systemy operacyjne czasu rzeczywistego są używane w windach, hamulcach samochodowych i pociskach balistycznych. Są maksymalnie niezawodne, ponieważ jeśli mechanizm nie zadziała w ściśle określonym czasie, zdarzenie nie ma sensu i dochodzi do katastrofy. Jest to kluczowa różnica między RTOS a Linuxem, w którym operacje oczekują na wykonanie w kolejce. Jest to też jedna z przyczyn, dla których Linux nie jest używany w profesjonalnych systemach alarmowych.
Prace zajęły nam półtora roku. Stworzyliśmy system operacyjny, który obsługuje zaawansowane chmurowe protokoły komunikacji na kilku kanałach. Zarządza siecią setek urządzeń radiowych. Potrafi wysyłać komunikaty alarmowe przez kanały IP, telefony i SMS. Ma wszystkie możliwości oczekiwane od profesjonalnego systemu alarmowego i chroni przed atakami. Udało nam się osiągnąć zamierzony cel. Zapewniliśmy doskonałą funkcjonalność i wysoką niezawodność.
Ale wraz z premierą Hub (2G) otrzymaliśmy ogromną ilość próśb o wprowadzenie nowych funkcji. Agencje ochrony prosiły o możliwość bezpośredniego podłączenia do huba z pominięciem naszej chmury. Nasi norwescy partnerzy chcieli, aby jeden czujnik pożarowy mógł uruchomić wszystkie czujniki w systemie w przypadku wykrycia ognia. I żeby działo się to tak szybko, jak w przewodowych alarmach pożarowych. Rynek niemiecki domagał się, aby produkt spełniał wymogi normy europejskiej Klasy 2 i obsługiwał klawiaturę systemu alarmowego. W Malezji i Danii użytkownicy chcieli szerokich możliwości automatyzacji domu. We Włoszech bardzo ważna była oddzielna rola dla instalatorów.
Istniejąca architektura nie umożliwiała szybkiego rozszerzania funkcjonalności. Mogliśmy szybko dodawać funkcje do aplikacji mobilnych, korzystając ze środowisk programistycznych wysokiego poziomu, ale napisanie oprogramowania huba wymagało więcej czasu. Zmiany trudno było przetestować, a ich wdrożenie wymagało wielu zasobów. Aby stworzyć kompleksową logikę, potrzebowaliśmy nowego poziomu abstrakcji — rozdzielenia oprogramowania od sprzętu.
Zdecydowaliśmy się na dalszą rozbudowę systemu. Czy musieliśmy przejść na Linuxa? Stopniowo ulepszać nasz system operacyjny? Musieliśmy zachować niezawodność i stabilność systemu czasu rzeczywistego, ale jednocześnie potrzebowaliśmy skalowalności systemu operacyjnego wysokiego poziomu, takiego jak Linux. Po raz kolejny gotowe rozwiązania się nie sprawdziły, dlatego potrzebowaliśmy własnych.
Prostota ma wartość tylko wtedy, gdy jest zakorzeniona w złożoności
Podstawą naszego nowego systemu operacyjnego była idea upraszczania. Postawiliśmy sobie warunki: dodanie funkcji nie powinno skomplikować sytemu ani spowolnić szybkości rozwoju oprogramowania. Aby nie zboczyć z kursu, nazwaliśmy projekt „Malevich” na cześć słynnego kijowskiego artysty Kazimierza Malewicza. Jego „Czarny kwadrat” to doskonały przykład genialnego pomysłu opartego na prostocie.
Aby stworzyć OS Malevich, musieliśmy wszystko zmienić — architekturę, podejście do programowania, standardy kodowania i projektowania, organizację pracy i środowisko programistyczne. Mimo że system operacyjny nadal skupiał się na czasie wykonania procesów, zaczął nabierać funkcji Linuxa. Zaimplementowaliśmy podobny mechanizm przydzielania czasu procesora. W rezultacie procesor huba wykorzystuje nie więcej niż 20% możliwości, nawet gdy wykonuje zadania wymagające dużej ilości zasobów. System stał się także modularny. Standardowe API służą do umożliwiania interakcji między elementami. Z modułami pracuje się łatwo: można szybko zidentyfikować i wyeliminować błędy, a zwiększenie funkcjonalności i eksperymentowanie w celu osiągnięcia idealnej wydajności są prostsze.
W zakresie szybkości rozwoju oprogramowania wszystkie produkty Ajax traktujemy tak samo. Możemy równie szybko wdrożyć nowe funkcje huba, serwera i aplikacji mobilnej. Nasze pomysły nie mają ograniczeń technicznych.
Dziś program komputerowy zazwyczaj nie jest uznawany za dzieło sztuki. Masowi odbiorcy nie rozumieją jego piękna. Ale wierzymy, że z czasem zaimplementowane przez nas pomysły wejdą do kanonu Internetu rzeczy.
Dowiedz się więcej:
