← Strona główna
Rozwój embedded krytyczny pod kątem bezpieczeństwa według norm
Ponad 35 lat doświadczenia w bezpieczeństwie funkcjonalnym, systemach czasu rzeczywistego i rozwoju bliskim sprzętowi — znam normy istotne dla motoryzacji, medycyny i przemysłu.
Rozwój embedded krytyczny pod kątem bezpieczeństwa nie jest kwestią pojedynczych funkcji, lecz całościowego podejścia: od analizy wymagań przez architekturę i implementację do weryfikacji i dokumentacji. Kto zleca w tym obszarze, nie szuka tylko dobrego programisty, lecz kogoś, kto rozumie współzależność normy, metody i kodu — i kto realistycznie potrafi oszacować nakład pracy, jaki wynika z przestrzegania.
Następujące trzy obszary kompetencji są podstawą mojej pracy. Nakładają się na siebie w prawie każdym projekcie.
Doświadczenie
1. Doświadczenie
Ponad trzy dekady rozwoju embedded — od początków kariery w rozwoju silników do obecnej działalności jako niezależny konsultant. W segmencie premium doświadczenie nie jest argumentem marketingowym, lecz warunkiem: kto rozwija systemy czasu rzeczywistego bliskie sprzętowi lub oprogramowanie układowe krytyczne pod kątem bezpieczeństwa, potrzebuje pamięci tych trybów awarii, które nie są w podręcznikach.
- Ponad 35 lat rozwoju embedded (od 1990)
- Początki kariery w Mercedes-Benz, Stuttgart-Untertürkheim
- Projekty dla wielu dużych producentów w Niemczech, Wielkiej Brytanii i USA — oraz dla ich francuskich i niemieckich dostawców
- Działalność międzynarodowa w Niemczech i Francji
- 2002 — założenie Navimess Elektronik (później zamkniętej)
- 2012 — założenie SCHMITT CONSULTING S.A.R.L. we Francji
- Diplom-Informatiker (FH), kierunek informatyka techniczna
- Praca dyplomowa z techniki regulacji ze sterownikami sprzętu czasu rzeczywistego w asemblerze
Normy
2. Normy i standardy
Znam normy istotne dla rozwoju krytycznego pod kątem bezpieczeństwa w motoryzacji, medycynie i przemyśle. «Znam» oznacza tu: znam wymagania, metody i typowe pułapki — i potrafię ocenić, jaki normatywny nakład pracy pasuje do Państwa projektu, a jaki byłby niewspółmierny. W projektach pracuję jako programista w ramach przestrzegania norm ustanowionych przez klienta; nie obejmuję samodzielnej roli normatywnego audytora.
- ISO 26262 — Bezpieczeństwo funkcjonalne (motoryzacja, ASIL A do D)
- IEC 61508 — Bezpieczeństwo funkcjonalne (przemysł, SIL 1 do 4)
- IEC 62304 — Cykl życia oprogramowania (wyroby medyczne, klasy A/B/C)
- IEC 60601-1 — Bezpieczeństwo urządzenia (medycyna)
- RTCA/DO-178B — Oprogramowanie lotnicze (DAL A do E)
- Automotive SPICE — Ocena procesów w projektach motoryzacyjnych
- MISRA-C / MISRA-C++ — Reguły kodowania dla oprogramowania C/C++ istotnego dla bezpieczeństwa
Zarządzanie
3. Zarządzanie projektem
Projekty embedded rzadko fail-ują na technice, często na komunikacji i prowadzeniu. Moje zarządzanie projektem jest nakierowane na to, czego oczekują klienci segmentu premium: śledzalne terminy, przejrzyste koszty, jasne przekazania. Nie pracuję z przeładowaną metodyką, lecz z tym, czego projekt rzeczywiście potrzebuje.
- Ścisłe zarządzanie terminami i kosztami
- Regularne uzgodnienia z klientem w uzgodnionym rytmie
- Oferty z gwarancją ceny dla umów ze stałą ceną
- Transfer wiedzy do zespołów klienta na końcu projektu
- Koordynacja zewnętrznych dostawców i obszarów wewnętrznych
- Dokumentacja techniczna i śledzalne przekazanie kodu
- Gotowość do podpisania NDA i poufne traktowanie treści projektu
Dodatkowe punkty ciężkości techniczne
Poza trzema głównymi polami 35 lat praktyki wyłoniło wiele treściowych punktów ciężkości, które często czynią różnicę w projektach:
- Systemy czasu rzeczywistego i rozwój bare-metal
- Programowanie bliskie sprzętowi na małych mikrokontrolerach, z systemem operacyjnym czasu rzeczywistego lub bez. Doświadczenie w deterministycznym taktowaniu, architekturach przerwań i optymalizacji przy ograniczeniach pamięci i czasu wykonania.
- Weryfikacja FPGA
- Rozwój w VHDL i SystemVerilog, z testbenchami i systematyczną weryfikacją. Projekty FPGA nie są «oprogramowaniem na chipie» — kierują się własnymi regułami, i właśnie tam wiele projektów utyka.
- Przejęcie kodu i inżynieria odwrotna
- Analiza odziedziczonych baz kodu — asembler, C, C++, często bez dokumentacji — i ich systematyczne przygotowanie dla zespołu klienta. Projekt Stihl (zob. referencje) jest tego przykładem.
- Szyfrowanie i bezpieczna komunikacja
- Rozwój procedur kryptograficznych i bezpiecznej komunikacji magistralowej w kontekście embedded, gdzie biblioteki standardowe nie pasują — od podpisanych aktualizacji oprogramowania układowego przez bezpieczne bootloadery do rozwiązań szyfrowania szytych na miarę. Uwaga: powyżej pewnego poziomu szyfrowania może być potrzebne pozwolenie właściwego organu, ponieważ niektórych technologii szyfrowania nie wolno eksportować do wszystkich krajów. Obowiązek pozwolenia jest sprawdzany wspólnie przed rozpoczęciem.
Co te kompetencje znaczą dla Państwa
Jeśli macie Państwo projekt, w którym przestrzeganie norm, wymagania czasu rzeczywistego lub złożoność bliska sprzętowi odgrywają rolę — i jednocześnie nie chcecie Państwo zatrudniać całego zespołu specjalistów, lecz jedną osobę z przeglądem i zobowiązaniem do dostawy — to współpraca jest prawdopodobnie odpowiednia.