Oprogramowanie aplikacyjne ma wygodną relację z błędami. Coś się psuje, powstaje poprawka, wychodzi tego samego popołudnia.
Zupełnie inny zestaw zasad
Oprogramowanie wbudowane żyje wewnątrz produktu. Sterownik silnika, medyczna pompa infuzyjna, pojazd, termostat, satelita, czujnik fabryczny. Zasady zmieniają się na cztery sposoby, i każdy z nich kształtuje sposób wykonywania tej pracy.
Sprzęt jest stały. Jeśli procesor jest za wolny, pamięć za mała albo peryferium niewłaściwe, nie da się zaktualizować danego egzemplarza. Można zmienić tylko oprogramowanie, i w końcu nawet tego nie da się zmienić.
Zasoby są ograniczone i małe. W wielu produktach kilobajty, nie gigabajty. Dynamiczna alokacja pamięci jest często wprost zabroniona, bo nieudana alokacja nie ma akceptowalnej reakcji, a fragmentacja po latach nieprzerwanej pracy jest nieprzewidywalna.
Terminy są realne. Przekroczenie jednego może oznaczać błędne sterowanie silnikiem, niestabilność pętli regulacji albo niezadziałanie funkcji bezpieczeństwa.
Awaria jest fizyczna. Awaria oprogramowania aplikacyjnego pokazuje komunikat. Awaria oprogramowania wbudowanego coś porusza, coś grzeje albo coś zatrzymuje.
Ta dyscyplina nie definiuje się przez język. Definiuje się przez to, że nie możesz później zmienić zdania.
Co obejmuje ten kierunek
Zakres: mikrokontrolery, rozwój oprogramowania układowego, systemy operacyjne czasu rzeczywistego, interfejsy sprzętowo-programowe, sterowniki urządzeń i bezpieczeństwo systemów wbudowanych.
Cztery obszary.
Interfejsy sprzętowe. Rejestry, peryferia, przerwania, magistrale komunikacyjne i lektura kart katalogowych, która się z tym wiąże.
Architektura oprogramowania układowego. Pętle bez systemu operacyjnego (bare metal), systemy operacyjne czasu rzeczywistego, dekompozycja zadań oraz decyzje szeregowania leżące pod spodem.
Programowanie w ograniczeniach. Praca w ramach budżetu pamięci, czasu i mocy oraz dowodzenie, że się w nim zmieściłeś.
Cykl życia. Mechanizmy aktualizacji, bezpieczeństwo, diagnostyka i długoterminowe utrzymanie.
Czas rzeczywisty oznacza terminy, nie szybkość
To pojęcie stale jest odczytywane błędnie. Czas rzeczywisty to nie stwierdzenie o wydajności. To stwierdzenie o przewidywalności.
Twardy system czasu rzeczywistego musi zakończyć daną czynność przed danym terminem, za każdym razem. Średnia wydajność nie ma znaczenia. System, który reaguje średnio w pięćdziesiąt mikrosekund, a raz na godzinę w pięć milisekund, nie był szybki przez większość czasu. Zawiódł, raz na godzinę.
Z tego wynikają trzy pojęcia, będące sednem tej dyscypliny.
Czas wykonania w najgorszym przypadku. Nie typowy, nie zmierzony przy normalnym przebiegu. Najdłuższy możliwy czas wykonania kodu, gdy każda gałąź trafia najgorzej, każdy odczyt z pamięci podręcznej chybia, a każde przerwanie ląduje w najgorszym możliwym momencie. Projekt wykonuje się względem tej liczby.
Opóźnienie przerwań i jitter. Ile czasu mija, zanim system zareaguje na zdarzenie zewnętrzne, i jak bardzo to się różni. Jitter ma w aplikacjach sterowania takie samo znaczenie jak opóźnienie, bo pętla regulacji zakłada stały interwał próbkowania i degraduje się, gdy go nie dostaje.
Priorytety i szeregowanie. Co działa, gdy gotowych jest kilka rzeczy naraz, i co się dzieje, gdy zadanie o niskim priorytecie trzyma zasób potrzebny zadaniu o wysokim priorytecie. Ta sytuacja, odwrócenie priorytetów, spowodowała realne i dobrze udokumentowane awarie w dostarczonych systemach, a mechanizmy, które jej zapobiegają, istnieją właśnie dlatego, że nie jest ona oczywista.
Błędy, które istnieją tylko w pracy wbudowanej
Kategoria awarii, z którą deweloperzy aplikacji rzadko się spotykają, a inżynierowie wbudowani stale.
Warunki wyścigu z przerwaniami. Kod główny i procedura obsługi przerwania dotykają tej samej zmiennej, a przerwanie ląduje między odczytem a zapisem. Zdarza się raz na dziesięć tysięcy uruchomień i znika, gdy dodasz instrukcję wypisującą.
Przepełnienie stosu. W wielu małych systemach brak ochrony pamięci, więc stos po cichu wrasta w inne dane, a objaw pojawia się gdzie indziej, znacznie później.
Uszkodzenie pamięci. Błąd wskaźnika lub przepełnienie bufora, które uszkadza dane należące do zupełnie innego podsystemu, dając awarię, której lokalizacja nie ma nic wspólnego z przyczyną.
Zachowanie zależne od czasu. Kod, który działa przy jednej częstotliwości zegara, jednym poziomie optymalizacji kompilatora albo jednej temperaturze, a zawodzi przy innej.
Heisenbugi. Usterki, które znikają pod debugerem, bo jego podłączenie zmienia synchronizację, która je spowodowała.
Praktyczną konsekwencją jest to, że debugowanie systemów wbudowanych opiera się na narzędziach, które obserwują, nie zakłócając: ślad sprzętowy, analizatory stanów logicznych, oscyloskopy i instrumentacja zaprojektowana w samym produkcie. Nauka odczytywania sygnału na oscyloskopie to nie nostalgia. To często jedyny sposób, by zobaczyć usterkę.
Gdzie to się mieści w domenie
Systemy wbudowane i sprzęt komputerowy to piąty z dziewięciu kierunków w domenie półprzewodników, elektroniki i kwantów Astra Trainer. Łączy się z inżynierią elektroniki, bo niemal każda płytka niesie oprogramowanie układowe, a te dwie role dzielą granicę, wokół której często się spierają, oraz z projektowaniem chipów, gdzie programy systemu na chipie potrzebują biegłości po obu stronach.
Łączy się też na zewnątrz z robotyką, gdzie warstwa sterowania jest wbudowana, z zaawansowaną produkcją w zakresie sterowania przemysłowego oraz z medycyną i healthtech, gdzie urządzenia niosą obowiązki regulacyjne. Zobacz tu dziewięć kierunków.
Wysyłka to początek dziesięcioletniego obowiązku
Czujnik przemysłowy, urządzenie medyczne, pojazd czy element infrastruktury budynku będzie w eksploatacji przez dekadę albo dłużej. Jeśli łączy się z siecią, cały ten okres to ekspozycja.
Trzy problemy odróżniające bezpieczeństwo systemów wbudowanych od bezpieczeństwa serwerów, i żaden z nich nie ma czystej odpowiedzi.
Aktualizacja jest trudna i ryzykowna. Urządzenia mogą być nieosiągalne, zasilane bateryjnie, ograniczone pasmem albo fizycznie niedostępne. Aktualizacja, która zawiedzie w połowie, może pozostawić urządzenie bezużytecznym, co dla jednych produktów oznacza wizytę serwisową, a dla innych stratę. Bezpieczna, wznawialna, weryfikowana aktualizacja to problem projektowy, który trzeba rozwiązać, zanim pierwszy egzemplarz opuści fabrykę, bo nie da się go dodać później do urządzeń już działających w terenie.
Kryptografia musi przetrwać. Klucze i algorytmy wybrane dziś pozostają w urządzeniach przez cały okres eksploatacji. To miejsce, w którym ten kierunek spotyka się z komunikacją, pomiarami i bezpieczeństwem kwantowym, a odpowiedzią jest zwinność kryptograficzna: projektowanie tak, by algorytm dało się wymienić, zamiast zakładać, że pierwszy wybór jest trwały.
Obowiązek staje się coraz bardziej prawny. Kilka jurysdykcji wprowadziło wymogi dotyczące produktów podłączonych do sieci, w tym zakaz uniwersalnych domyślnych haseł, obowiązek ujawnienia, jak długo będą dostarczane aktualizacje bezpieczeństwa, oraz procesy zgłaszania podatności. Szczegóły różnią się między rynkami i się zmieniają, ale kierunek zmian jest spójny: wsparcie bezpieczeństwa staje się deklarowanym zobowiązaniem z określonym czasem trwania, a nie kwestią dobrej woli.
Role po imieniu
Inżynierowie oprogramowania wbudowanego. Rola szeroka.
Inżynierowie oprogramowania układowego. Najbliżej sprzętu.
Twórcy sterowników urządzeń.
Inżynierowie systemów czasu rzeczywistego, do aplikacji krytycznych czasowo i sterujących.
Inżynierowie wbudowanego Linuksa, osobna specjalizacja względem pracy z mikrokontrolerami.
Inżynierowie integracji sprzętu i oprogramowania, uruchamiający nowe płytki.
Inżynierowie bezpieczeństwa systemów wbudowanych. Bezpieczny rozruch, obsługa kluczy, infrastruktura aktualizacji.
Inżynierowie bezpieczeństwa funkcjonalnego, do systemów motoryzacyjnych, przemysłowych i medycznych.
Inżynierowie testów i walidacji systemów wbudowanych, w tym testów typu hardware-in-the-loop.
Kogo można w to przekwalifikować
Inżynierowie oprogramowania aplikacyjnego. Największa pula. Wnoszą strukturę, dyscyplinę narzędziową i nawyki kontroli wersji, których zespołom wbudowanym często brakuje. To, czego trzeba nauczyć wprost, to model sprzętowy: rejestry, przerwania, czas i powód, dla którego dynamiczną alokację traktuje się z podejrzliwością.
Technicy i inżynierowie elektronicy. Konwersja z drugiej strony, mają już intuicję sprzętową, potrzebują struktury programistycznej.
Personel sterowania przemysłowego i automatyki. Programiści sterowników PLC już rozumieją zachowanie czasu rzeczywistego, deterministyczne skanowanie i ograniczenia przemysłowe.
Inżynierowie testów. W walidację i testy hardware-in-the-loop.
Inżynierowie IT i sieci. W pracę z urządzeniami podłączonymi do sieci i bezpieczeństwo systemów wbudowanych, gdzie wiedza o protokołach się przenosi, a ograniczenia zasobowe – nie.
Inżynierowie serwisu terenowego. W diagnostykę i inżynierię wsparcia, mając wiedzę o awariach w terenie, której nikt w dziale rozwoju nie ma.
Bezpieczeństwo funkcjonalne i urządzenia regulowane. Oprogramowanie wbudowane w urządzeniach medycznych, pojazdach, lotnictwie, maszynach przemysłowych i systemach związanych z bezpieczeństwem podlega wiążącym normom i reżimom regulacyjnym z wymogami dotyczącymi procesu rozwoju, dokumentacji, weryfikacji i kontroli zmian. Poziomy nienaruszalności bezpieczeństwa przypisuje się w drodze formalnej oceny, a certyfikację wydają właściwe jednostki. Szkolenie buduje kompetencje inżynierskie i świadomość, gdzie te obowiązki mają zastosowanie. Nie nadaje ono certyfikacji, statusu oceniającego bezpieczeństwo ani uprawnień do wydania oprogramowania w regulowanym produkcie.
Co z tego wynika
Pracę wbudowaną definiują ograniczenia, a nie język. Stały sprzęt, mała pamięć, twarde terminy i długi okres eksploatacji.
Czas rzeczywisty oznacza dotrzymywanie terminu za każdym razem. Liczy się czas wykonania w najgorszym przypadku, nie średnia.
Charakterystyczne błędy to usterki czasowe, współbieżności i pamięci, które ukrywają się przed debugerami, dlatego narzędzia obserwacji sprzętowej pozostają kluczowe.
Aktualizacja i zwinność kryptograficzna muszą być zaprojektowane, zanim pierwszy egzemplarz opuści fabrykę, bo nie da się ich dodać później do urządzeń już działających w terenie.
A dwa najlepsze źródła nowych inżynierów wbudowanych podchodzą z przeciwnych stron: deweloperzy aplikacji, którzy potrzebują modelu sprzętowego, i technicy, którzy potrzebują struktury programistycznej.
Co naprawdę oznacza czas rzeczywisty?
Dotrzymanie określonego terminu za każdym razem, a nie szybkie działanie. System, który reaguje szybko średnio, a czasem się spóźnia, zawiódł, bo w aplikacjach sterowania i bezpieczeństwa to właśnie spóźniona reakcja ma znaczenie.
Dlaczego w systemach wbudowanych unika się dynamicznej alokacji pamięci?
Bo alokacja może się nie udać, a często nie ma akceptowalnej reakcji na taką sytuację, a fragmentacja po latach ciągłej pracy jest trudna do przewidzenia. Wiele projektów alokuje pamięć statycznie przy starcie.
Dlaczego błędy w systemach wbudowanych tak trudno odtworzyć?
Bo wiele z nich zależy od czasu. Wyścigi przerwań, przepełnienia stosu i uszkodzenia pamięci dają objawy dalekie od przyczyny, a podłączenie debugera zmienia synchronizację, która je spowodowała.
Dlaczego bezpieczeństwo systemów wbudowanych trzeba zaprojektować z wyprzedzeniem?
Bo urządzenie może być w eksploatacji przez dekadę, a mechanizmu aktualizacji, obsługi kluczy i możliwości wymiany algorytmów kryptograficznych nie da się dodać do egzemplarzy już wdrożonych w terenie.
Czy deweloperzy aplikacji mogą przejść do pracy wbudowanej?
Tak, i wnoszą przydatną strukturę oraz dyscyplinę narzędziową. Luką, której trzeba nauczyć wprost, jest model sprzętowy: rejestry, przerwania, zachowanie czasowe i ograniczenia zasobowe.