Współczesne firmy stale dążą do osiągania coraz więcej przy mniejszym nakładzie zasobów i pracy. W miarę upływu czasu tworzenie systemów wbudowanych stało się z kolei niezwykle złożone. Rozważmy, chociażby włącznik światła podłączony do Internetu. Jego jedyną funkcją jest włączanie i wyłączanie oświetlenia, ale do zbudowania takiego urządzenia potrzebne są sterowniki niskopoziomowe, systemy czasu rzeczywistego (RTOS), stosy łączności, połączenie z chmurą, mechanizmy bezpieczeństwa, konstrukcje o niskim zużyciu energii i zdolność do odzyskiwania danych po przerwie w dostawie prądu. Wiedza i umiejętności programistyczne niezbędne współcześnie są ogromne i, szczerze mówiąc, stają się coraz bardziej nieuzasadnionym wymaganiem. W ciągu ostatnich kilku lat w branży oprogramowania dla systemów wbudowanych pojawiło się przekonanie, że dalsza perspektywa jego tworzenia niekoniecznie będzie polegać na pisaniu kodu. Czy to oznacza, że rozwiązania typu no-code zdominują przyszłość systemów wbudowanych? Przyjrzyjmy się im bliżej.
Co to jest no-code?
Gdy mówimy o opcji typu no-code, mamy na myśli narzędzia wysokiego poziomu, które najczęściej wykorzystują graficzny interfejs użytkownika (GUI), aby umożliwić projektowanie i wdrażanie systemu na platformach embedded. Programista nie musi koniecznie znać języka programowania. Musi zrozumieć koncepcje oprogramowania na wysokim poziomie, podczas gdy narzędzie wykorzystuje te założenia do generowania kodu niskiego poziomu. Na przykład, jeśli chcemy zaimplementować maszynę stanów, po co zajmować się edycją i manualnym pisaniem kodu w C/C++ czy Rust? Maszyna stanów to koncepcja wysokopoziomowa, a jako programistom systemowym nie zawsze zależy nam na tym, w jakim dokładnie języku jest ona zaimplementowana. Istotne są jednak szczegóły odnośnie do jej projektowania. Jeśli możemy użyć narzędzia wysokiego poziomu do określenia zachowania takiego urządzenia, a następnie pozwolić temu instrumentowi wygenerować implementację, to jest to dla nas wielka korzyść!
W przeszłości rozwój oprogramowania wbudowanego zawsze zaczynał się na poziomie układu, sprzętu i rozwijał, aż do osiągnięcia wymaganych funkcji przez produkt. Taka praktyka jest ukochana przez inżynierów elektroników i programistów systemów wbudowanych! Poświęcamy uwagę bitom i bajtom, mapom pamięci i rejestrów... Niestety z punktu widzenia biznesu, zarządzanie i klienci niekoniecznie przejmują się tymi aspektami. Zależy im na pożądanych funkcjach, które pomogą uzyskać cel. To prowadzi do pojawienia się podejścia o odwrotnym przebiegu prac — z góry na dół.
Kod kontra no-code
Rozwiązania typu no-code niekoniecznie przyspieszą testowanie produktu przez firmę, która zaczyna od funkcji. Warto pokazać je klientom i uzyskać od nich opinie, które są niezbędne do stworzenia udanego produktu na końcu procesu. Idea no-code otwiera możliwość projektowania systemu przez osoby bez dogłębnej wiedzy w zakresie języków programowania. Jest to bardzo atrakcyjne z punktu widzenia biznesu, co skłania firmy do wdrażania tej koncepcji.
Idee takie jak no-code i projektowanie oparte na modelu istnieją w branży oprogramowania od dziesięcioleci. Są też narzędzia typu STMCubeMx, Matlab, MCUXpresso i inne, które pozwalają na pewnym poziomie uniknąć konieczności pisania kodu. To interesujące rozwiązania, które z roku na rok stają się coraz lepsze. Niemniej niektóre firmy borykają się z kosztami braku instrumentów do kodowania, a inne narzędzia po prostu nie są wystarczająco rozwinięte. Mogą one przyspieszyć proces rozwoju, ale nadal wymagają od programisty znajomości wielu podstawowych szczegółów.
Wszystko to prowadzi do ciekawego punktu dotyczącego tworzenia oprogramowania wbudowanego. Jest ono wyjątkowe, ponieważ programiści, zajmujący się tym kodem, muszą zrozumieć, co dzieje się z tym źródłowym. Jeśli zaistnieją problemy z wydajnością, z pamięcią czy wiele innych, które często pojawiają się w systemach wbudowanych, podejście no-code nie będzie odpowiednim rozwiązaniem. Programiści muszą zrozumieć swój sprzęt i proces kompilacji. Abstrahowanie od szczegółów na wyższym poziomie może przyspieszyć proces tworzenia oprogramowania, ale w końcu coś pójdzie nie tak, a wtedy niezbędna będzie specjalistyczna wiedza do przezwyciężenia trudności.
Podsumowanie
Chociaż podejście no-code stanowi fascynujący obszar, to niekoniecznie zdominuje on dziedzinę tworzenia oprogramowania. No-code może znaleźć zastosowanie, zwłaszcza w kwestii projektowania architektury na wysokim poziomie, budowania interfejsów użytkownika i zarządzania zachowaniem oraz sterowania stanem. Być może w przyszłości pojawi się standardowa metoda tworzenia oprogramowania, która zastąpi kod lub modele, ale wydaje się, że jesteśmy jeszcze daleko od takiej rzeczywistości, szczególnie w przypadku systemów wbudowanych. Uformowało się wiele interesujących koncepcji i pomysłów z dziedziny no-code, ale prawdopodobnie minie kolejna dekada lub więcej, zanim podejście to zdominuje w pełni tę branżę. Może przyspieszy to przyjęcie narzędzi opartych na sztucznej inteligencji, ale zawsze będzie potrzebna dogłębna wiedza na temat niskopoziomowych aspektów programowania systemów wbudowanych.
Źródło: https://www.embedded.com/will-no-code-solutions-dominate-the-future-of-embedded/
Co to jest no-code?
Gdy mówimy o opcji typu no-code, mamy na myśli narzędzia wysokiego poziomu, które najczęściej wykorzystują graficzny interfejs użytkownika (GUI), aby umożliwić projektowanie i wdrażanie systemu na platformach embedded. Programista nie musi koniecznie znać języka programowania. Musi zrozumieć koncepcje oprogramowania na wysokim poziomie, podczas gdy narzędzie wykorzystuje te założenia do generowania kodu niskiego poziomu. Na przykład, jeśli chcemy zaimplementować maszynę stanów, po co zajmować się edycją i manualnym pisaniem kodu w C/C++ czy Rust? Maszyna stanów to koncepcja wysokopoziomowa, a jako programistom systemowym nie zawsze zależy nam na tym, w jakim dokładnie języku jest ona zaimplementowana. Istotne są jednak szczegóły odnośnie do jej projektowania. Jeśli możemy użyć narzędzia wysokiego poziomu do określenia zachowania takiego urządzenia, a następnie pozwolić temu instrumentowi wygenerować implementację, to jest to dla nas wielka korzyść!
W przeszłości rozwój oprogramowania wbudowanego zawsze zaczynał się na poziomie układu, sprzętu i rozwijał, aż do osiągnięcia wymaganych funkcji przez produkt. Taka praktyka jest ukochana przez inżynierów elektroników i programistów systemów wbudowanych! Poświęcamy uwagę bitom i bajtom, mapom pamięci i rejestrów... Niestety z punktu widzenia biznesu, zarządzanie i klienci niekoniecznie przejmują się tymi aspektami. Zależy im na pożądanych funkcjach, które pomogą uzyskać cel. To prowadzi do pojawienia się podejścia o odwrotnym przebiegu prac — z góry na dół.
Kod kontra no-code
Rozwiązania typu no-code niekoniecznie przyspieszą testowanie produktu przez firmę, która zaczyna od funkcji. Warto pokazać je klientom i uzyskać od nich opinie, które są niezbędne do stworzenia udanego produktu na końcu procesu. Idea no-code otwiera możliwość projektowania systemu przez osoby bez dogłębnej wiedzy w zakresie języków programowania. Jest to bardzo atrakcyjne z punktu widzenia biznesu, co skłania firmy do wdrażania tej koncepcji.
Idee takie jak no-code i projektowanie oparte na modelu istnieją w branży oprogramowania od dziesięcioleci. Są też narzędzia typu STMCubeMx, Matlab, MCUXpresso i inne, które pozwalają na pewnym poziomie uniknąć konieczności pisania kodu. To interesujące rozwiązania, które z roku na rok stają się coraz lepsze. Niemniej niektóre firmy borykają się z kosztami braku instrumentów do kodowania, a inne narzędzia po prostu nie są wystarczająco rozwinięte. Mogą one przyspieszyć proces rozwoju, ale nadal wymagają od programisty znajomości wielu podstawowych szczegółów.
Wszystko to prowadzi do ciekawego punktu dotyczącego tworzenia oprogramowania wbudowanego. Jest ono wyjątkowe, ponieważ programiści, zajmujący się tym kodem, muszą zrozumieć, co dzieje się z tym źródłowym. Jeśli zaistnieją problemy z wydajnością, z pamięcią czy wiele innych, które często pojawiają się w systemach wbudowanych, podejście no-code nie będzie odpowiednim rozwiązaniem. Programiści muszą zrozumieć swój sprzęt i proces kompilacji. Abstrahowanie od szczegółów na wyższym poziomie może przyspieszyć proces tworzenia oprogramowania, ale w końcu coś pójdzie nie tak, a wtedy niezbędna będzie specjalistyczna wiedza do przezwyciężenia trudności.
Podsumowanie
Chociaż podejście no-code stanowi fascynujący obszar, to niekoniecznie zdominuje on dziedzinę tworzenia oprogramowania. No-code może znaleźć zastosowanie, zwłaszcza w kwestii projektowania architektury na wysokim poziomie, budowania interfejsów użytkownika i zarządzania zachowaniem oraz sterowania stanem. Być może w przyszłości pojawi się standardowa metoda tworzenia oprogramowania, która zastąpi kod lub modele, ale wydaje się, że jesteśmy jeszcze daleko od takiej rzeczywistości, szczególnie w przypadku systemów wbudowanych. Uformowało się wiele interesujących koncepcji i pomysłów z dziedziny no-code, ale prawdopodobnie minie kolejna dekada lub więcej, zanim podejście to zdominuje w pełni tę branżę. Może przyspieszy to przyjęcie narzędzi opartych na sztucznej inteligencji, ale zawsze będzie potrzebna dogłębna wiedza na temat niskopoziomowych aspektów programowania systemów wbudowanych.
Źródło: https://www.embedded.com/will-no-code-solutions-dominate-the-future-of-embedded/
Fajne? Ranking DIY
