Programowanie i Robotyka
Wzorce projektowe są bardzo popularnym tematem wśród programistów. Zwykle rozmawia się o nich w kontekście języków obiektowych i dużych systemów. Jednak podobnie jak z innymi zagadnieniami dotyczącymi architektury – część wzorców da się z powodzeniem przenieść na grunt systemów embedded. W dzisiejszym wpisie opowiem o trzech wzorcach z najpopularniejszego katalogu wzorców – książki „Gang of four” – które mogą zrobić najwięcej dobrego w architekturze systemów embedded.
Continue reading
Dobra architektura nie powstaje od razu. Jest ona raczej wypracowana na bazie różnych doświadczeń. Jednak w większości systemów jest ona określana na sztywno na samym początku, kiedy jeszcze nie mamy wystarczającej wiedzy, aby zrobić ją dobrze. Jest to źródłem wielu problemów z utrzymaniem. Zamiast tego powinniśmy pogodzić się z faktem, że dobre rozwiązania wymagają czasu i umożliwić architekturze ewolucję.
Continue reading
Z czego składa się architektura? Z modułów i warstw. To jest intuicyjny podział wynikający z potrzeby dzielenia złożonych problemów na mniejsze i grupowania podobnych zadań. Jednak o ile co do samego istnienia warstw i modułów nikt nie ma zastrzeżeń, to strategie ich wydzielania zależą często tylko od naszej fantazji. Dzisiaj zdefiniujemy sobie czym są owe moduły i warstwy oraz w jaki sposób powinny być wydzielane. Od razu uprzedzam, że będę tutaj mówił o architekturze dużego systemu realizującego wiele zadań jednocześnie. Duża część projektów embedded jest na tyle prostych, że tak skomplikowana architektura byłaby w nich jedynie obciążeniem.
Continue reading
W systemach embedded zwykle skupiamy się na niskopoziomowych interakcjach ze sprzętem. Poznajemy nowe interfejsy, wykorzystujemy kolejne zewnętrzne układy i wykorzystujemy nowe rodziny procesorów. Jednak to z czym sobie naprawdę nie radzimy to poskromienie rosnącej złożoności tworzonych przez nas systemów. W większości systemów prawdziwym problemem jest architektura, czyli systematyczne podejście do radzenia sobie z tą złożonością. Jako branża embedded nie potrafiliśmy do tej pory stworzyć jasnych zasad tworzenia architektury i utrzymywania jej w projekcie. Zwykle dominują dwa podejścia – albo architektury nie ma wcale, albo tworzona jest na początku przed rozpoczęciem kodowania i okazuje się niepraktyczna. W tym wpisie dzielę się swoimi spostrzeżeniami na temat problemów z architekturą w embedded.
Continue readingDistortos to system operacyjny czasu rzeczywistego (RTOS) napisany w C++ z myślą o procesorach ARM Cortex-M, a szczególnie STM32. Pisałem już o nim przy okazji ciekawych projektów C++ Embedded i łazika na NASA Space Apps. Aplikacja na STM w łaziku chyba jednak będzie za prosta, żeby dawać do niej RTOSa, ale ostatnio zacząłem przepisywać Micromouse do C++ i tam już się nada. Źródła distortosa możecie znaleźć na GitHubie, a dokumentację na stronie projektu. Jest on jeszcze w dosyć wczesnej fazie rozwoju, dlatego nie posiada aż tak rozbudowanej dokumentacji i przykładów. Może to być pewną barierą na początku, jednak z czasem na pewno to się zmieni.
Continue reading
Zwykle przyjmujemy, że koszt wytworzenia systemu safety-critical spełniającego wymagane normy jest dziesięciokrotnie wyższy, niż zwykły projekt posiadający te same wymagania funkcjonalne. Po przeczytaniu poprzednich części serii powinniście mieć całkiem dobre wyobrażenie skąd biorą się dodatkowe koszty. W tym artykule omówię koszty developmentu, zewnętrznego kodu i narzędzi.
Continue reading
W większości projektów, gdy mamy możliwość wykorzystania jakiegoś istniejącego rozwiązania, w ogóle się nie zastanawiamy. Dużo publicznego kodu znajdziemy na GitHubie, a w JavaScripcie wychodzi tyle nowych bibliotek, że są one nawet częścią pijackiej gry. Jak już pewnie się domyślacie – w systemach safety-critical sytuacja jest zgoła odmienna. Użycie zewnętrznego kodu podlega specjalnym procedurom i w normach nazywane jest właśnie tytułowym akronimem SOUP, czyli Software of Unknown Provenance, lub Software of Uncertain Pedigree. Nazwy te od razu zwracają uwagę na podstawowy problem tego softu – jego nieznane pochodzenie, historię i proces wytwarzania.
Było już o technikach wykorzystywanych na poziomie projektu i kodu oraz o wpływie języka programowania na bezpieczeństwo. Dzisiaj odpowiemy sobie na pytanie w jaki sposób zarządzać ryzykiem, wykrywać potencjalnie niebezpieczne zachowania i dodawać odpowiednie środki zaradcze do projektu.
W poprzednim artykule opisywałem ogólne techniki zalecane przy developmencie systemów safety-critical. Dzisiaj natomiast przyjrzymy się bliżej zaleceniom dotyczącym języków programowania. Wiemy już, że język używany w tego typu systemach powinien być kompilowany i silnie typowany. Jakie jeszcze wymagania powinien spełniać? Jakie języki wykorzystywane są w praktyce? Poniżej znajdziesz odpowiedzi na te pytania.
Jak wspomniałem w poprzednim wpisie, normy definiują różne poziomy bezpieczeństwa w zależności od możliwych skutków błędnego działania systemu. Tym poziomom odpowiadają konkretne wskaźniki statystyczne. O ile sprawdzają się one w przypadku układów psujących się w sposób łatwy do opisania prawdopodobieństwem – jak na przykład części elektroniczne – to soft zawiera częściej błędy systematyczne, czyli po prostu bugi. Poza tym wymaganych statystyk nie da się zmierzyć, ani przewidzieć na etapie projektowania. Zamiast tego tworząc software powielamy pewne rozwiązania, które sprawdziły się w istniejących systemach. Polecane rozwiązania są często opisane w normach. Przyjrzymy się więc dzisiaj praktykom zalecanym przez normę kolejową EN50128.