logo elektroda
logo elektroda
X
logo elektroda
Adblock/uBlockOrigin/AdGuard mogą powodować znikanie niektórych postów z powodu nowej reguły.

5 przeszkód na drodze do wykorzystania Rusta w systemach wbudowanych

ghost666 29 Lip 2023 12:21 1341 7
  • Język programowania Rust zdobywa coraz więcej uwagi jako opcja warta wykorzystania. Jego możliwości w zakresie bezpieczeństwa pamięci są fascynujące, ale jak to często bywa, spożytkowanie ich może być trudniejsze niż się wydaje. Chociaż Rust stanowi interesującą opcję językową, istnieje co najmniej pięć znaczących przeszkód, które utrudniają jego adopcję w systemach wbudowanych. Przyjrzyjmy się kilku z nich.

    Przeszkoda #1 — wsparcie komercyjne

    Współczesne zespoły zajmujące się tworzeniem produktów wbudowanych zazwyczaj korzystają z komercyjnych narzędzi wsparcia, aby przyspieszyć rozwój oprogramowania. Na przykład producent mikrokontrolera przeważnie dostarcza sterowniki niskiego poziomu, systemy plików, systemy operacyjne czasu rzeczywistego (RTOS), narzędzia konfiguracyjne i wiele innych. To pomaga podkręcić tempo rozwoju, ponieważ większość pracy na niższym poziomie sprzętu została już wykonana. Do tej pory tylko nieliczni producenci mikrokontrolerów wspierają Rusta. Nadal dla klientów oferują oni wsparcie głównie dla języka C. Wszystko, co wykracza poza to, trzeba zrobić samodzielnie.

    Istnieją narzędzia, takie jak svd2rust, które programiści mogą zużytkować do konwersji plików SVD, które opisują peryferia mikrokontrolera, na tzw. peripheral crate. Instrument ten potrafi dosyć dobrze wygenerować taką: „skrzynkę”, którą programista może wykorzystać. Niestety, może wiązać się to z potencjalnymi problemami, takimi jak:

    * Znaczne różnice w jakości w zależności od producenta;
    * Rozwlekły i złożony kod generowany przez automatyczne narzędzie;
    * Brak komunikatów o błędach, co może skutkować dłuższym czasem debugowania;
    * Brak możliwości konfiguracji — instrument stosuje takie samo podejście do każdej paczki;
    * Wykorzystanie generyków i metaprogramowania może prowadzić do wydłużenia czasu kompilacji.

    Jeśli producent nie dostarcza pakietów wsparcia, to samemu trzeba rozwiązać wszystkie te niedogodności. Choć może to być ekscytujące i przynieść wiele cennych doświadczeń, może negatywnie wpłynąć na harmonogram i budżet projektu.

    Przeszkoda #2 — koszty szkoleń

    Rust nie jest językiem łatwym do nauki. Chociaż dzieli wspólne idee i koncepcje z wieloma innymi, w tym z C, krzywa uczenia się jest bardziej stroma. Gdy firma rozważa wprowadzenie nowego języka, musi zatrudnić inżynierów, którzy już znają tę technologię lub przeszkolić swój zespół. Grupy zainteresowane wykorzystaniem Rusta na platformach wbudowanych znajdą się w małej i niszowej społeczności. W tejże jest niewielu wykwalifikowanych inżynierów oprogramowania wbudowanego, którzy znają Rusta. Oznacza to, że konieczne może być płacenie więcej za tych nielicznych programistów, którzy są z nim zaznajomieni lub inwestowanie w szkolenie istniejącego zespołu. Tak czy inaczej, przekłada się to na zwiększenie wydatków.

    Szkolenie zespołu do nauki Rusta to dobry pomysł. Każda firma i programista powinien stale inwestować w siebie. Ta branża ewoluuje tak szybko, że jeśli się tego nie robi, to zostaje się w tyle. Jednak przejście z jednego języka programowania na inny musi przynieść zwrot z inwestycji dla firmy. Zwłaszcza w przypadku przeskoku na język o nieco niższej dojrzałości pokroju Rusta. Rezultat musi zaowocować zwrotem z inwestycji, takim jak lepsze zabezpieczenia, stabilniejszy system itp. Zespół planujący wykorzystać Rusta powinien obiektywnie ocenić, czy jest to odpowiednia droga do podążania.

    Szkolenie w tym przypadku nie ogranicza się do krótkiego 5-dniowego kursu. Nauka składni języka to jedno, ale nabycie w nim doświadczenia, unikanie rozmaitych pułapek i pisania wysokiej jakości, łatwego do utrzymania kodu, to zupełnie inna bajka. Tego nie da się ogarnąć w tydzień. W rzeczywistości nie można tego osiągnąć nawet w ciągu roku, choć w tym czasie uda się poczynić wydatne postępy. Dlatego początkowe koszty szkolenia mogą wydawać się niewielkie. Jednak całościowe obejmują opóźnienia w projektach, dodatkowe debugowanie i wolniejszy czas rozwoju, ponieważ zespół uczy się, jak odpowiednio stosować nowy język w swoich produktach. Nie oznacza to, że nie powinno się tego robić, ale trzeba to dokładnie ocenić i zdawać sobie sprawę, że to istotne i realne utrudnienie.

    Przeszkoda #3 — konserwatywne podejście do przyjmowania nowych technologii

    Jak łatwo zauważyć, nowe technologie są wdrażane w środowiskach rozwoju systemów wbudowanych bardzo powoli. Podczas projektowania produktów fizycznych w porównaniu z czystymi aplikacjami programowymi, wszelkie nowości wiążą się z ryzykiem skorelowanym z bezpieczeństwem, produkcją i właściwym działaniem układu. W przypadku software, skargi prowadzą do aktualizacji oprogramowania w ciągu 24 godzin. Jeśli pracujemy nad systemem w branży lotniczej, motoryzacyjnej lub nawet elektroniki użytkowej, niekoniecznie można mieć taką możliwość.

    Firmy bazujące na produktach fizycznych często ponoszą większe ryzyko niepowodzenia. Właściciele i menedżerowie przedsiębiorstw zwykle są bardziej oporni na potencjalne niebezpieczeństwa i wybierają technologie, które są znane i sprawdzone. (Spójrzmy na branżę wynoszenia pojazdów kosmicznych. Jak długo rozwój tego sektora niemalże stał w miejscu z powodu obaw przed ryzykiem?). Istnieją także często pewne inwestycje w obecne technologie, przepływy pracy i pozyskanych pracowników (patrz wyżej). Koszt zmiany może być znaczący dla ugruntowanej firmy, a korzyści z tego wynikające są potencjalnie niewielkie. Jeśli decyzję podejmuje mała marka, rozpoczynająca swoją działalność, nie ma jeszcze tych początkowych inwestycji, więc przyjęcie nowszego rozwiązania, takiego jak Rust, może być w tym przypadku rozsądne, ponieważ i tak trzeba stworzyć swoją infrastrukturę technologiczną i opracować procesy.

    Możliwość niepowodzenia nierzadko skłania firmy do korzystania z dostępnych technologii o niskim ryzyku, aby osiągnąć swoje cele biznesowe. Dlatego wiele przedsiębiorstw może spojrzeć na Rusta i zdecydować się na użycie C lub C++, ponieważ przyjęcie nowego rozwiązania, takiego jak Rust, nie daje żadnych rzeczywistych korzyści w porównaniu z tym, co jest już ugruntowane w branży. Nie powinniśmy tego mówić, ale doświadczona jednostka może zrobić to samo w C lub C++, co programista Rusta w tym języku, zachowując jednakie bezpieczeństwo (różnica jest jedynie wtedy, gdy nie mamy do czynienia z zaawansowanymi specjalistami w zakresie programowania).

    Przeszkoda #4 — integracja zestawu narzędzi

    Wielu programistów korzysta obecnie z systemów budowania, przepływów pracy i narzędzi, które używają zintegrowanego sposobu wytwarzania oprogramowania wbudowanego. Zastosowanie Rusta wymusi na tych jednostkach ponowne przemyślenie i przerobienie całego procesu rozwoju, ponieważ Rust może nie działać w zgodzie z istniejącymi zestawami instrumentów.

    Na przykład, klient, który zdecydował się na przesiadkę na Rusta, dotychczasowo wykorzystywał system czasu rzeczywistego (RTOS) i Tracealyzera od Percepio do monitorowania zadań i ich czasu realizacji. Jednak teraz firma ta planuje użyć RTIC (Real-Time Interrupt-driven Concurrency) z Rustem. W zespole programistów powstało pytanie: „Jak uzyskamy te same pomiary z naszego środowiska Rust?”. Odpowiedź na nie pozostaje jeszcze do ustalenia. Narzędzia, które poznali i nauczyli się wykorzystywać i od których są zależni, mogą już nie działać. (Wersja Tracealyzer dla bare-metal może funkcjonować, ale na ten moment nie jest to oczywiste, a co gorsze sprawdzenie tego wymaga stworzenia dużej części systemu).

    Może się okazać, że choć nowoczesny i wartościowy język Rust wydaje się świetnym wyborem, może spowodować, że będzie trzeba cofnąć się i stracić np. wgląd w swój system, który wcześniej mieliśmy, dzięki narzędziom pomocniczym. Aby odzyskać tę możliwość, trzeba samodzielnie opracować nowe instrumenty i techniki pomocnicze. Wyniki mogą być w porządku, ale wszyscy wiedzą, że zaprzepaszczony w ten sposób czas, to stracone środki i szanse na dalszy rozwój.

    Przeszkoda #5 — brak standaryzacji

    C i C++ mają standardy, do których można się odwołać i zrozumieć, co jest oficjalnie wspierane w danym języku, a co nie. Rust nie posiada formalnej specyfikacji ani standardu. Zespół za niego odpowiedzialny kieruje jego projektowaniem, a wszelkie zmiany przechodzą przez ustanowiony proces zgłaszania komentarzy (RFC). RFC oraz dokumentacja Rust stanowią efektywnie specyfikację języka, ale wysoce nieformalną.

    Brak takiej opcji oznacza, że wsparcie komercyjne dla tego języka w aplikacjach krytycznych dla bezpieczeństwa i innych obszarach, będzie w zasadzie nieistniejące. Kompilator Rusta, znany jako rustc, jest darmowy i otwartoźródłowy, ale nie ma wersji komercyjnej. Zainteresowana społeczność rozwija ten kompilator, a zespół Rusta nadzoruje postęp. Chociaż może to nie wydawać się dużym problemem, brak standaryzacji oznacza, że Rust może zmieniać kierunek rozwoju w jednej chwili. To może być świetne dla postępu i innowacji, ale nie dla specjalistów ds. systemów wbudowanych, którzy polegają na spójności dla produktów o długiej żywotności.

    Podsumowanie

    Czy te przeszkody mówią, że nie powinniśmy przyjmować Rusta w nowych projektach systemów wbudowanych? Nie! Jednakże wskazują, że każdorazowo trzeba dokładnie ocenić, czy jego wykorzystanie przyniesie korzyści firmie i zespołowi w tym projekcie. Jako branża, należy spodziewać się, że te utrudnienia będą istotnymi czynnikami, które mogą wpływać na to, dlaczego nie obserwujemy szybkiej adopcji Rusta. Będą oczywiście przedsiębiorstwa, które go przyjmą i osiągną sukces. Będą też takie, które go zaakceptują i nic godnego uwagi nie będzie z tego wynikać. Inni będą trzymać się sprawdzonych rozwiązań i prowadzić swoje działania jak zwykle, z wykorzystaniem dotychczasowych technologii.

    Rust jest ekscytującym językiem i oczekuje się, że powoli zyska sobie udziały w rynku. Należy założyć, że w ciągu najbliższej połowy dekady, więcej zespołów przyjmie jednak C++ niż Rusta. A czy Wam zdarzyło się programować w Rust? W szczególności na platformach wbudowanych? Jakie macie w tym zakresie doświadczenia i odczucia? Co w ogóle zmotywowało Was do wykorzystania tego nowego języka zamiast klasycznego C?

    Źródło: https://www.embedded.com/5-roadblocks-to-rust-adoption-in-embedded-systems/

    Fajne? Ranking DIY
    O autorze
    ghost666
    Tłumacz Redaktor
    Offline 
    Fizyk z wykształcenia. Po zrobieniu doktoratu i dwóch latach pracy na uczelni, przeszedł do sektora prywatnego, gdzie zajmuje się projektowaniem urządzeń elektronicznych i programowaniem. Od 2003 roku na forum Elektroda.pl, od 2008 roku członek zespołu redakcyjnego.
    https://twitter.com/Moonstreet_Labs
    ghost666 napisał 11960 postów o ocenie 10197, pomógł 157 razy. Mieszka w mieście Warszawa. Jest z nami od 2003 roku.
  • #2 20672571
    lemgo
    Poziom 14  
    #5 - trochę bzdura
    Rust ma ustanowione wersje (v2015, v2018). Ma zdefiniowany "language reference" https://doc.rust-lang.org/1.49.0/reference/. Czego tu brakuje?
    Jest na tyle konkretnie zdefiniowany, że dało się dla niego wyprowadzić gramatykę formalną https://github.com/antlr/grammars-v4/tree/master/rust - czego nie można powiedzieć o C++ (nie znalazłem gramatyki dla C++17 nawet)
    Zmiany w C++ nadzoruje, zatwierdza itp., dla odmiany chyba, komitet. Niewiele to się różni w pryncypiach od rozwoju Rust.

    #3 -
    ghost666 napisał:
    przyjęcie nowego rozwiązania, takiego jak Rust, nie daje żadnych rzeczywistych korzyści w porównaniu

    Daje. Trzeba ostrożnie, ale potrafię nazwać korzyści z nowocześnie zbudowanego języka, z nowoczesnymi prycypiami i paradygmatami.
    C ma już ponad 50 lat, niewiele odbiega od Cobolu, C++ ponad 20, obciążony zgodnością z C, wtedy nie wiedziano jeszcze, jak dobrze zaprojektowany winien być język żwawy, przydatny i bezpieczny.
  • #3 20672865
    _lazor_
    Moderator Projektowanie
    lemgo napisał:
    Rust ma ustanowione wersje (v2015, v2018). Ma zdefiniowany "language reference" https://doc.rust-lang.org/1.49.0/reference/. Czego tu brakuje?


    Dla przykładu "memory model"


    Ja nie czuje by rust dostarczał czegoś nowego, a chwalenie się że:

    "Rust’s rich type system and ownership model guarantee memory-safety and thread-safety — enabling you to eliminate many classes of bugs at compile-time."

    jest kpiną, bo po prostu pozamykali niektóre możliwości za unsave i się cieszą. Jeśli analogiczne możliwości uciąłbym w innym języku to uzyskuje ten sam efekt (co między innymi MISRA robi)
  • #4 20675125
    Nepto
    Poziom 19  
    Ja już wyrażałem swoją opinię co do tłumaczeń tekstów pana Jacoba Beningo. "Szkoda czasu i atłasu".

    Punkt #5 to typowy FUD. Co oznacza "formalny standard"? Dlaczego niby np. standard ISO miałby być lepszy niż standard producenta? Ile spośród używanych w praktyce języków jest standardami ISO (dla ciekawych: można to sprawdzić np. tutaj https://www.iso.org/ics/35.060/x/ )? Dlaczego komitet przy ISO miałby wytwarzać specyfikację lepszą niż jakikolwiek inny zespół?

    ghost666 napisał:
    Inni będą trzymać się sprawdzonych rozwiązań i prowadzić swoje działania jak zwykle, z wykorzystaniem dotychczasowych technologii.

    Problem jest taki, że świat się zmienia. W listopadzie 2022 roku NSA wydało dokument "Software Memory Safety" ( https://www.nsa.gov/Press-Room/News-Highlight...rotect-against-software-memory-safety-issues/ ) gdzie wyraźnie stwierdza
    Cytat:

    NSA advises organizations to consider making a strategic shift from
    programming languages that provide little or no inherent memory protection, such as
    C/C++, to a memory safe language when possible.

    Podążanie za radami pana Jacoba z embedded.com to prosta droga, żeby za parę lat obudzić się z ręką w nocniku, bo okaże się, że kolejnym krokiem np. certyfikacji typu FIPS będzie wymóg używania "memory-safe languagues".

    _lazor_ napisał:
    Dla przykładu "memory model"

    Czy dla porównania C99 specyfikował model pamięci?
  • #5 20675249
    _lazor_
    Moderator Projektowanie
    Nepto napisał:
    Czy dla porównania C99 specyfikował model pamięci?


    Brzmi to kuriozalnie, jakby rust miał zachęcić ludzi do przejścia z C99 na niego :D

    Java pokazała że brak memory modelu jest problemem i już od C11 i Cpp11 jest memory model co też podbiło ogólny standard dla języków. Rust jeszcze tego oficjalnie nie definiuje, chociaż jakaś implementacja musi tego być, ale oznacza że jest płynna.
  • #6 20676678
    Nepto
    Poziom 19  
    Oczywiście, że model pamięci to dobra rzecz i trochę przekornie wspomniałem właśnie o C99, który jeszcze tego nie miał. Chodziło mi o o to, że ludzie radzili sobie długo bez wsparcia na poziomie samego języka i dało się żyć, więc pewnie i z Rustem też dałoby się żyć. Ale przyznaję rację, że od nowoczesnego języka można tego wymagać.
  • #7 20676836
    _lazor_
    Moderator Projektowanie
    Ludzie wysłali w kosmos ludzi mając assemblera ;)

    Jak dla mnie wiara że coś automagicznie rozwiąże nasze problemy jest myśleniem życzeniowym. Brałem udział w rozwijaniu softu dla falowników ABB i tam bardzo mocno stosowali MISRA, statyczne narzędzia analizy kodu, doży coverage, sporo testów przed wdrożeniem oraz kod miał bardzo dobry proces projektu architektury softu. Kod pisało się co prawda nudno, ale błędów z "produkcji" była minimalna ilość.

    Tworzenie software to dużo więcej niż tylko język, jeśli rust zapewni wsparcie do nich to możemy zacząć mówić o jego użyciu w prawdziwym życiu.
  • #8 20684273
    Nepto
    Poziom 19  
    _lazor_ napisał:
    Tworzenie software to dużo więcej niż tylko język, jeśli rust zapewni wsparcie do nich to możemy zacząć mówić o jego użyciu w prawdziwym życiu.

    100% zgoda tutaj :)
REKLAMA