Mechanizmy bezpieczeństwa w przemysłowych sieciach komputerowych na przykładzie sieci CAN.

Rozdział 99 Mechanizmy bezpieczeństwa w przemysłowych sieciach komputerowych na przykładzie sieci CAN. Andrzej KWIECIEŃ Politechnika Śląska, Instytut Informatyki andrzej.kwiecien@polsl.pl Paweł MOROZ Politechnika Śląska, Instytut Informatyki pawel.moroz@polsl.pl Streszczenie Sieć komputerowa często zlokalizowana jest w niekorzystnym środowisku, mogącym powodować przekłamania przesyłanych informacji. Dlatego każda sieć musi posiadać mechanizmy wykrywania błędów. Liczba nie wykrytych błędów przez zaimplementowane mechanizmy wyznacza poziom bezpieczeństwa transmisji. Parametr ten jest jednym z kluczowych elementów wykorzystywanych przy doborze sieci do zastosowania, szczególnie w sieciach przemysłowych. W rozdziale przedstawiono niektóre z dostępnych mechanizmów bezpieczeństwa oraz dyskusję nad kierunkami modyfikacji, które mogą poprawić jego poziom. 1. Wstęp Naturalny rozwój zastosowania systemów informatycznych w motoryzacji, wykreował architekturę gwiazdy jako topologii dominującej. Było to spowodowane stopniowym wzrostem liczby urządzeń w samochodach. Pojawiające się układy mogły być sterowane i monitorowane za pomocą systemów informatycznych. Dobrym przykładem owego rozwoju jest sieć CAN, po raz pierwszy zaprezentowana w 1982 roku przez firmę BOSCH. Założenia sieci CAN były na tyle elastyczne i w minimalny sposób określone, że zainteresowały się nim inne gałęzie przemysłu. Obecnie sieć CAN oprócz motoryzacji możemy spotkać w aparaturze medycznej, urządzeniach przemysłowych, a także w systemach inteligentnych budynków i sprzęcie gospodarstwa domowego. Sieć CAN wykorzystuje tylko trzy warstwy modelu ISO/OSI: fizyczną, łącza danych i aplikacyjną. Jest to zabieg celowy, ponieważ charakter wymian w sieci nie

2 A. Kwiecień, P. Moroz wymaga mechanizmów obsługiwanych przez pozostałe warstwy. Ponadto zminimalizowane są opóźnienia powstałe podczas przechodzenia informacji przez stos ISO/OSI. Specyfikacja protokołu ogranicza się do opisania najważniejszych elementów. Dla warstwy fizycznej określa mechanizmy kodowania i synchronizacji informacji oraz mechanizm rozstrzygania kolizji. Dla warstwy łącza danych wyznacza budowę ramki, sposoby obsługi błędów i mechanizm synchronizacji węzłów. Ostatnia warstwa (aplikacyjna) zawiera implementację zasad wymiany ruchu w sieci. Warstwa ta nie jest ujęta w specyfikacji, a jej działanie zależy od programisty. W związku z dużą elastycznością protokołu na całym świecie zaczęły powstawać pomysły rozwiązań dla warstwy aplikacyjnej. Z czasem część z nich stała się standardem. Najbardziej znane są: CANOpen, DeviceNet, CANKingdom. Możliwości modyfikacji nie kończą się na warstwie aplikacyjnej. Również w warstwie fizycznej możliwe są pewne zmiany. Opracowano standardy CAN potrafiące pracować z wykorzystaniem tylko jednej linii transmisji danych. Rozwiązanie to nazywa się Fault- Tolerant. Protokół doczekał się standaryzacji w 1993 roku. Opis protokołu CAN zawarty jest w dokumencie opatrzonym numerem ISO 11898-1, a popularna i najczęściej wykorzystywana wersja CAN - High Speed opisana jest w ISO11898-2. Natomiast specyfikacja sieć Fault-Tolerant zawarta jest w normie ISO 11898-3. 2. Budowa ramki CAN Ramki w sieci CAN dzielimy na ramki komunikacyjne i sterujące. Do ramek komunikacyjnych zaliczamy ramki zdalnego żądania i danych, a do sterujących należą ramki błędu oraz przeciążenia. Korzystając z CAN mamy do wyboru dwa rodzaje ramek 2.0A (ang. Standard CAN), wcześniej nazywany 1.1 i 2.0B (ang. Extended CAN). Główną różnicą jest wydłużenie identyfikatora wiadomości z 11 do 29 bitów. Wraz ze wzrostem długości identyfikatora, zachowano tzw. zgodność wsteczną, czyli możliwość jednoczesnego wykorzystywania obu rodzajów ramek w jednej sieci transmisyjnej. Rys. 1. Budowa ramek CAN 2.0A i 2.0B [7]

Mechanizmy bezpieczeństwa w przemysłowych 3 Na nagłówek ramki składają się następujące elementy: SOF (ang. Start of Frame) początek ramki. Wartość pola wynosi 0, ID (ang. Identifier) identyfikator, RTR (ang. Remote Transmission Request) gdy flaga ustawiona jest na 1 oznacza, że jest to ramka zdalnego żądania (prośba o przysłanie danych), a stan 0 oznacza nadawanie ramki danych (wartość 0), IDE (ang. Identifier Extension) - wartość tego pola równa 1 oznacza, wydłużenie identyfikatora o młodsze 18 bitów, które umieszczone są zaraz za nim. Gdy w polu występuje wartość 0 oznacza, że identyfikator ma długość tylko 11 bitów, RB0 (ang. Reserved Bit 0) pole zarezerwowane, do ewentualnego wykorzystania, DLC (ang. Data Length Code) informuje o długości pola danych. Przyjmuje wartości od 0 do 8. Kodowanie tych bitów w obszarze DLC jest reprezentacją binarną przekazywanej wartości. Dla ramek rozszerzonych (ang. Extended), występują dodatkowo: SRR (ang. Substitute Remote Request) występuje, gdy IDE ma wartość 1, i przyjmuje tą samą wartość, RB1 (ang. Reserved Bit 1) odpowiednik RB0. W celu przesłania ciągu bitów pomiędzy węzłami wykorzystywana jest magistrala, a kontrole dostępu oparto na mechanizmie CSMA/CR (ang. Carrier Sense Multiple Access/Collision Resolution), w którym wszyscy nadawcy w obszarze rozstrzygania kolizji sprawdzają czy stan łącza odpowiada wartości bitu nadawanego. W przypadku braku zgodności węzeł wycofuje się z nadawania i przechodzi w tryb odbioru. 3. Mechanizmy bezpieczeństwa w sieci CAN. Podczas każdej transmisji, mogą powstać błędy związane z oddziaływaniami na medium, jego budową lub błędami komunikujących się węzłów. Dlatego każda sieć musi posiadać zabezpieczenia transmisji, na podstawie, których określa się jej bezpieczeństwo. Kryterium to jest podstawą przy wyborze sieci przemysłowych. Wynika to z postawionych wymagań i charakteru pracy, jaką maja wykonywać. Dlatego w sieci CAN określonych jest aż pięć mechanizmów kontroli poprawności transmisji przedstawionych w [1, 5, 8, 9]: 1. Sprawdzanie bitów (ang. Bit Check) każdy nadawca prowadzi nasłuch łącza i porównuje wartości nadawane ze stanem łącza. W przypadku wykrycia wystąpienia na łączu stanu bitu o wartości przeciwnej do wartości bitu nadawanego węzeł uznaje, iż wystąpił błąd. Wyjątek stanowi obszar rozstrzygania kolizji (ang. Arbitration Field) i okno potwierdzeń (ang. ACK Slot). 2. Budowa Ramki (ang. Frame Check) w [2] określane jest to, jako kontrola poprawności końca ramki, a w [1] zalicza się do tego obszaru SOF, RTR, IDE, DLC, CRCDEL, ACKDLE, EOF i odstęp między ramkami. Dokumentacja zawęża listę pól do: CRCDEL, ACKDLE, EOF i odstępu między ramkami, przestawionych w prezentacji [8]. Każdy odbiornik sprawdza wartość tych pól i w razie wystąpienia stanu niedozwolonego zgłasza błąd poprzez ramkę błędu. Błędy przedstawionych pól są właśnie błędami formy (ang. Form Errors).

4 A. Kwiecień, P. Moroz 3. Suma kontrolna (ang. Cyclic Redundancy Check) wartość o określonej liczbie bitów, wyliczana jest na podstawie wielomianu generacyjnego. W sieci CAN wykorzystywany jest wielomian generacyjny 15-stego stopnia (1). 15 14 10 8 7 4 3 CRC = x + x + x + x + x + x + x + 1 (1)[9] Za jego pomocą wyliczana jest suma kontrolna pól START OF FRAME, ARBITRATION FIELD, CONTROL FIELD, DATA FIELD (gdy występuje) i dołączany jest on za polem danych. 4. Kontrola Potwierdzeń (ang. Acknowledge Check) każdy węzeł nadający nasłuchuje potwierdzenia w oknie potwierdzeń (ACK) od przynajmniej jednego węzła. Jeżeli nadawca nie uzyska odpowiedzi, w tym momencie uznaje że wystąpił błąd potwierdzenia (ang. Acknowledgement Error) i dokonuje retransmisji do momentu jego uzyskania. 5. Zasada wstawiania bitów (ang. Stuff Rule Check) wszystkie węzły sprawdzają poprawność wstawiania bitów. Gdy węzeł wykryje więcej niż 5 kolejnych bitów tego samego stanu, uznaje iż wystąpił Błąd Wstawiania Bitów (ang. Stuff Error) i wysyła ramkę błędu (ang. Error Frame). 4. Poziom detekcji błędów w sieci CAN Dokumentacja sieci CAN, podaje właściwości detekcyjne przedstawionych mechanizmów. Protokół wykrywa[9]: wszystkie błędy globalne, wszystkie błędy u nadawcy są wykrywane, jest wykrywanych do 5 błędów losowych, błędy blokowe krótsze niż 15 bitów, wszystkie parzyste liczby błędów. Rys. 2. Mechanizm powstawania błędów blokowych[1] Całkowite prawdopodobieństwo niewykrycia uszkodzonej ramki (P NI ), zależy od prawdopodobieństwa wystąpienia błędnej ramki (PBR) i jest mniejsze niż:

Mechanizmy bezpieczeństwa w przemysłowych 5 11 P NI = PBR 4,7 10 (2) Matematyczną analizą bezpieczeństwa transmisji w sieci CAN przedstawiono w [1]. Po raz pierwszy zauważono problem występowania przekłamań blokowych po zmianie stanu tylko dwóch bitów (rys. 2). W pracy [10] przedstawiono wyniki swoich badań dotyczących bezpieczeństwa transmisji. Wykazano, że prawdopodobieństwo niewykrycia błędu w ramce już przy 2 błędach wynosi 32 ramki z 250*10 6. Podczas tych badań stwierdzono, że mechanizmy zabezpieczające w sieci CAN najbardziej podatne są na przekłamanie od 2 do 13 bitów. We wnioskach wydali dla organizacji National Automated Highway System Consortium negatywną ocenę poziomu bezpieczeństwa. W celu ilustracji poziomu niebezpieczeństwa wyznaczono liczbę nie wykrytych wiadomości w zależności od stopy błędu BER (ang. Bit Error Rate), dla liczby 200 milionów pojazdów pokonujących 2,469 biliona (ang.trillion) mil z prędkością 30mph (tabela 1). Tabela 1 Liczba nie wykrytych ramek zależnie od stopy błędu [10] BER Liczba nie wykrytych wiadomości 1 * 10-4 21.8 wiadomości / godzinę 1 * 10-5 5.2 wiadomości / dzień 1 * 10-6 0.05 wiadomości / dzień Rys. 3. Prawdopodobieństwa niewykrycia błędu po zastosowaniu dodatkowych zabezpieczeń[10] W podsumowaniu, jako zalecenie [10] przedstawiono kilka propozycji poprawy poziomu wykrywania błędów zarówno programowych jak i sprzętowych. Są to:

6 A. Kwiecień, P. Moroz dodatkowe CRC umieszczane na jednym lub dwóch ostatnich bajtach, dodatkowa suma kontrolna (SUMA), dodatkowa suma kontrolna (XOR), wyliczanie sumy kontrolnej dla ramki po mechanizmie Bit Stuffing. Wyniki symulacji wprowadzenia trzech pierwszych zmian przedstawia wykres na rys. 3. Ostatnie rozwiązanie nie jest przedstawione na grafie a jedynie wskazane. Przy jego implementacji występuje problem uniknięcia wykorzystania mechanizmu wstawiania bitów w obszarze CRC. 5. Możliwości rozszerzenia bezpieczeństwa transmisji Założenia sieci CAN tworzone były w latach 80-tych, gdy rozwój elektroniki, szczególnie w zakresie niskoprądowych układów zintegrowanych, był minimalny. Obecnie elektronika dysponuje znacznie większą wiedzą i technologią, co umożliwia stworzenie szybszych i bardziej energooszczędnych układów. W związku z pojawieniem się nowych technologii, dokonano przeglądu i analizy konstrukcji mechanizmów bezpieczeństwa, pod kątem poprawy ich wyników. Na ich podstawie sformułowano kilka tez: 1. Kontrola większej liczby elementów stałych ramki (SRR, RB0, RB1) zwiększy wykrywanie błędów. 2. Kontrola poprawności pola DLC poprawi bezpieczeństwo transmisji. 3. Zmiana kodowania długości w obszarze DLC może podnieść poziom bezpieczeństwa. 4. Redukcja liczby bitów wstawionych spowoduje zmniejszenie prawdopodobieństwa wystąpienia zjawiska powstawania błędów blokowych. 5. Zmiana mechanizmu sumy kontrolnej jest wstanie poprawić bezpieczeństwo transmisji. 5.1. Kontrola większej liczby elementów stałych ramki (SRR, RB0, RB1) zwiększy wykrywanie błędów Według założeń tej tezy istnieje duże prawdopodobieństwo, że weryfikacja liczby elementów stałych ramki (ang. Fixed-Form) będzie skutkowała zwiększeniem wykrywalności błędów. Można to uzyskać poprzez zwiększenie liczby badanych elementów o trzy dodatkowe pola, które nie podlegały wcześniej weryfikacji. Dzięki temu może zostać wykryte wystąpienie błędu blokowego w obszarze objętym wstawianiem bitów. Poza tym zwiększy się prawdopodobieństwo wykrycia błędów pojedynczych, gdyż testowana jest poprawna wartość dodatkowych 3 bitów. 5.2. Kontrola poprawności pola DLC poprawi bezpieczeństwo transmisji Kolejna teza zakłada wprowadzenie kontroli poprawności pola DLC. Obecnie, wszystkie stany nieokreślone tego pola traktowane są jako stan reprezentujący długość pola danych równą 8-miu bajtom [9]. Pomysł polega na uznaniu wszystkich obecnych

Mechanizmy bezpieczeństwa w przemysłowych 7 stanów nieokreślonych jako stany niedozwolone. W efekcie, wystąpienie takiego stanu skutkowało by to zgłoszeniem błędu. 5.3. Zmiana kodowania długości w obszarze DLC może podnieść poziom bezpieczeństwa Inną propozycją dotyczącą obszaru DLC jest zmiana jego kodowania. Obecnie na wykorzystywanych 4 bitach (16 stanach) zakodowanych jest tylko 9 informacji. Pozostałe wartości są niewykorzystane. Wydłużenie pola danych nie jest możliwe ze względu na parametry wykorzystywanej sumy kontrolnej. Dlatego rozpatrywana jest zmiana kodowania w tym obszarze, w taki sposób, aby dla jak największej liczby stanów odległość Hamminga wynosiła 2. Oczekiwana wartość odległości Hamminga dla danego obszaru oznacza wykrycie zmiany jednego bitu. 5.4. Redukcja liczby bitów wstawionych spowoduje zmniejszenie prawdopodobieństwa wystąpienia zjawiska powstawania błędów blokowych Występowanie bitów wstawionych powoduje wydłużenie ramki, a tym samym czasu transmisji. Jednocześnie zmniejsza się prawdopodobieństwo wykrycia błędu, co omówiono w podrozdziale 4. Z tego względu celem jest uzyskanie jak najmniejszej liczby bitów nadmiarowych. Może to zmniejszyć prawdopodobieństwo przekłamania dodanego bitu i wystąpienia ryzyka związanego z powstaniem błędu blokowego. Jednocześnie zwiększy się sprawności protokołu [3]. Sprawność dookreślona jest zależnością (3): LData η = 100% (3) L Frame gdzie: L Data liczba bitów danych, L Frame całkowita długość ramki. Aby uzyskać mniejszą liczbę bitów wstawionych, przebadany zostanie wpływ niektórych elementów nagłówka, takich jak identyfikator lub pole DLC na liczbę bitów nadmiarowych. Zagadnienie liczby bitów wstawionych w pole danych zostało już omówione [6], a wpływ na zawartość tego pola mają projektanci konkretnego systemu. 5.5. Zmiana mechanizmu sumy kontrolnej jest w stanie poprawić bezpieczeństwo transmisji Ostatnia propozycja bazuje na przebudowie podstawowego mechanizmu bezpieczeństwa, jakim jest suma kontrolna CRC. Istnieją już takie rozwiązania, na przykład w sieci LIN[4], gdzie dokonano podziału sumy kontrolnej na sumę nagłówka i sumę pola danych. Adaptacja takiego rozwiązania dla sieci CAN mogłaby przynieść pewne korzyści. Po pierwsze skrócenie długość ramek bez pola danych, ze względu na brak występowania pola, które ta suma miałaby zabezpieczać. Możliwe jest też podjęcie

8 A. Kwiecień, P. Moroz próby dobrania innej, krótszej sumy kontrolnej. Niestety wprowadzenie tych zmian wiąże się również z pewnymi zagrożeniami. Może dojść do pogorszenia parametrów sumy kontrolnej. Wynika to z zasady działania sumy CRC, to znaczy CRC nie jest w stanie wykryć więcej błędów seryjnych niż stopień wielomianu go wyznaczający. Analizując wnioski z artykułu [10] można rozpatrzyć korzyści płynące z wydłużenia sumy kontrolnej zabezpieczającej ramkę. Z tego powodu zagadnienie to wymaga szeregu badań, analiz i symulacji. Dopiero wykonanie kilku modeli i porównanie uzyskanych poziomów wykrywalności błędów, może udowodnić stawianą tezę. 6. Weryfikacja postawionych tez Przedstawione w podrozdziale 5 tezy muszą zostać poddane weryfikacji. W tym celu stworzona zostanie aplikacja, która umożliwi testowanie dokonywanych zmian. Aplikacja wykonana zostanie na komputer klasy PC. W związku możliwością wykorzystania istniejącego kodu (klasy reprezentującej ramkę CAN), do wykonania całego programu wykorzystany zostanie język Python. Działanie programu przedstawia rys. 4. Generator Strumienia Danych Weryfikacja strumienia Symulator Kanału Transmisyjnego i Generator Zakłóceń Rys. 4. Ogólny schemat badania Ponieważ program ma symulować działanie sieci, poszczególne części programu będą odpowiadać elementom sieci rzeczywistej. Podział nastąpi według funkcjonalności opisywanej przez model ISO/OSI. Szczegółowo strukturę programu przedstawiono na rys. 5. Każda z warstw ma wykonywać określone zadania: 1. Warstwa aplikacyjna (App) będzie udostępniać strukturę ramki danych, którą należy wypełnić. Następnie wygeneruje strumień, przesyłany do warstwy niższej.

Mechanizmy bezpieczeństwa w przemysłowych 9 Umożliwi jednocześnie zamianę strumienia otrzymanego z warstwy niższej na wartości poszczególnych pól. 2. Warstwa łącza danych (DLL) ma zamieniać otrzymany strumień na ciąg bitów gotowych do wysłania. W tym celu wykona funkcję odpowiadającą zastosowaniu mechanizm wstawiania bitów. 3. Warstwa fizyczna (PHY) w tym badaniu odpowiadać będzie za transmisję i generowanie błędów. Każda warstwa będzie również zbierać informacje o wykrytych błędach. Dane Warstwa App Warstwa DLL N a d a w c a O d b i o r c a Weryfikacja Warstwa App Warstwa DLL 6.1. Warstwa aplikacyjna Warstwa PHY Rys. 5. Podział zadań programu na poszczególne grupy Zadaniem warstwy aplikacyjnej jest tworzenie strumienia danych na podstawie wartości poszczególnych pól. Jednocześnie ważne jest uproszczenie wprowadzania modyfikacji w budowie ramki CAN. W tym celu stworzono klasę, a każde występujące w ramce CAN pole, przedstawiono jako zmienną tej klasy. Każda klasa przedstawiająca zmienioną ramkę CAN dziedziczy klasę bazową (klasę CAN), a następnie wprowadza w niej swoje zmiany. Zbiór funkcji tej warstwy odpowiada jednocześnie za wyliczenie sumy kontrolnej, budowanie strumienia bitów i przekazywanie ramki następnej warstwie. Weryfikuje również poprawność wiadomości przy odbieraniu strumienia z warstwy łącza danych. Zastosowanie takiego rozwiązania oszczędza czas i zapobiega powstawaniu błędów podczas wprowadzania modyfikacji w kodzie programu.

10 A. Kwiecień, P. Moroz 6.2. Warstwa łącza danych Głównym zadaniem tej warstwy jest obsługa mechanizmu nazywanego bit-stuffing. Warstwa u nadawcy wykonuje wspomniane wcześniej wstawianie bitów, a u odbiorcy funkcję odwrotną czyli bit-destuffing. Warstwa ta przeprowadza weryfikację poprawności ramki wykrywając wystąpienie ciągu niedozwolonego (powyżej pięciu jednakowych stanów). W razie nie wykrycia błędu przekazuje oczyszczony (pozbawiony bitów nadmiarowych) strumień danych do warstwy wyższej. 6.3. Warstwa fizyczna Założeniem autorów programu jest modyfikacja zawartości wszystkich ramek i zliczanie tych, w których nie zostanie wykryty błąd. Do wprowadzenia błędu w losowym miejscu niezbędne jest zastosowanie funkcji generującej liczby pseudolosowe. Przed wykorzystaniem generatora liczb pseudolosowych należy sprawdzić jego powtarzalność (częstość występowania tych samych wartości) i określić na ile wyniki uzyskane z jego pomocą pokrywają się z wynikami uzyskanymi poprzez przebadanie całej próby. Liczby wylosowane przez generator liczb wskazywać będą, które pozycje mają zostać przekłamane. Na wskazanym bicie można wygenerować błąd w następujący sposób: ustawienie wartości na logiczną 1, ustawienie wartości na logiczna 0, zmiana wartości na przeciwną. W prowadzonych badaniach zastosowane zostanie ostatnie z przedstawionych sposobów tworzenia błędów. Dla uzyskania tego rozwiązania wykorzystana zostanie funkcja exlusiveor. W warstwie tej zostaną zaimplementowane funkcje umożliwiające symulowanie powstawania dwóch rodzajów błędów: blokowych i losowych. Możliwe będzie również ustawienie poziomu powstawania błędów, wyrażonych przez liczbę bitów zmienionych lub procentowy udział bitów błędnych w całkowitej długości ramki. 7. Wnioski Analiza zagadnienia bezpieczeństwa w sieci CAN wykazała pewne słabe punkty tego protokołu. Natomiast jego popularność zachęca do weryfikacji przedstawionych wyników, oraz poszukiwania zaspokojenia oczekiwań przemysłu. Nowe technologie w elektronice dają możliwość ich realizacji bez utraty innych ważnych parametrów. W dalszych pracach planowane jest stworzenie stanowiska badawczego umożliwiającego testowanie różnych modyfikacji mechanizmów bezpieczeństwa. Symulacje komputerowe wykazujące szansę poprawienia bezpieczeństwa transmisji powinny być następnie zaimplementowane w układzie FPGA, aby wykonać eksperymenty i testy w warunkach rzeczywistych. Podsumowaniem przeprowadzonych badań będzie ocena przedstawionych tez, a także w razie ich potwierdzenia przygotowania gotowych rozwiązań.

Mechanizmy bezpieczeństwa w przemysłowych 11 Literatura 1. Charzinski J.: Performance of the Error Detection Mechanisms in CAN, Proceedings of the 1 st International CAN Conference, Mainz. 09.1994. 2. Dach M., Werewka J.: Analiza czasów reakcji w systemie kontrolno-diagnostycznym, X Konferencja Systemów Czasu Rzeczywistego, Ustroń 09.2003. 3. Kwiecień A.: Analiza przepływu informacji w komputerowych sieciach przemysłowych. Gliwice. 2000 4. LIN Specification Package Revision 2.0, LIN Consortium, www.lin-subbus.org, 2003. 5. mbus: An overview of Controller Area Network (CAN) Technology, Nov. 2003. 6. Nolte T., Hansson H., Norstrom C., Punnekkat S.:Using bit-stuffing distributions in CAN analysis. IEEE Real-Time Embedded Systems Workshop 3.12.2001. 7. Passemard M.: Atmel Microcontrollers for Controller Area Network, Atmel, 2004. 8. Prezentacja CANPRES ver. 20, Siemens Microcontrollers Inc. 10.1998. 9. Robert Bosch GmbH: Bosch CAN Specification, www.semiconductors.bosch.de, Stuttgart 1991. 10. Tran E., Koopman P.:Multi-Bit Error Vulnerabilities in the Controller Area Network Protocol, Carnegie Mellon University, 05.1999.