Upload
dinhmien
View
238
Download
0
Embed Size (px)
Citation preview
Politechnika Śląska
Wydział Automatyki, Elektroniki i Informatyki
Instytut Informatyki
Paweł Moroz
Rozprawa doktorska
Metody ograniczania liczby bitównadmiarowych w protokołachwykorzystujących mechanizm
wstawiania bitów
Promotor:
Prof. dr hab. inż. Andrzej Kwiecień
Gliwice, 2010
Spis treści
Rozdział 1. Wprowadzenie . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.1. Analiza teoretyczna problemu . . . . . . . . . . . . . . . . . . . . . 10
1.2. Cel pracy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
1.3. Tezy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
1.4. Zakres pracy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
Rozdział 2. Sieciowe systemy komputerowe . . . . . . . . . . . . . . 14
2.1. Wprowadzenie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.1.1. System scentralizowany . . . . . . . . . . . . . . . . . . . . 16
2.1.2. System rozproszony . . . . . . . . . . . . . . . . . . . . . . . 16
2.1.3. System czasu rzeczywistego . . . . . . . . . . . . . . . . . . 17
2.2. Rozproszony system czasu rzeczywistego . . . . . . . . . . . . . . . 21
2.2.1. Model analityczny . . . . . . . . . . . . . . . . . . . . . . . 23
2.3. Wybrane parametry sieci komputerowych . . . . . . . . . . . . . . 29
2.3.1. Dostęp do łącza . . . . . . . . . . . . . . . . . . . . . . . . . 31
2.3.2. Parametry transmisji . . . . . . . . . . . . . . . . . . . . . . 31
2.4. Podsumowanie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
Rozdział 3. Mechanizm działania i metody wyznaczania liczby
wstawek bitowych . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
3.1. Metody wyznaczania wartości najgorszych . . . . . . . . . . . . . . 39
3.1.1. Metoda wykorzystująca algorytm postępowania . . . . . . . 40
3.1.2. Własna metoda obliczeniowa . . . . . . . . . . . . . . . . . 41
3.2. Wykorzystanie metod wyznaczania wstawek bitowych . . . . . . . . 42
Rozdział 4. Przykłady metod skracania czasu transmisji
komunikatów stosowanych w sieciach stosujących wstawki bitowe 45
4.1. Metoda zmiany struktury sieci . . . . . . . . . . . . . . . . . . . . . 46
4.2. Metoda minimalizacji długości ramek . . . . . . . . . . . . . . . . . 47
Spis treści 3
Rozdział 5. Własna metoda oceny i ograniczenia liczby wstawek
bitowych . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
Rozdział 6. Przykład zastosowania własnej metody oceny i
ograniczenia liczby wstawek bitowych . . . . . . . . . . . . . . . . . 54
6.1. Metodyka wykonywania eksperymentów . . . . . . . . . . . . . . . 54
6.2. Wybranie interesujących parametrów . . . . . . . . . . . . . . . . . 56
6.3. Analiza ramki . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
6.3.1. Budowa ramki . . . . . . . . . . . . . . . . . . . . . . . . . 57
6.3.2. Definicje zmiennych i stałych . . . . . . . . . . . . . . . . . 57
6.3.3. Wyznaczenie wartości pesymistycznych i średnich . . . . . . 59
6.3.4. Obliczenie wartości mierzonych parametrów . . . . . . . . . 66
6.4. Ocena protokołu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
6.5. Określenie wrażliwych miejsc . . . . . . . . . . . . . . . . . . . . . . 69
6.6. Wskazanie możliwych zmian . . . . . . . . . . . . . . . . . . . . . . 69
6.7. Analiza zmodyfikowanej ramki . . . . . . . . . . . . . . . . . . . . . 72
6.7.1. Wyznaczenie wartości średnich i pesymistycznych . . . . . . 75
6.7.2. Wyznaczenie i porównanie wartości mierzonych . . . . . . . 84
6.8. Ocena zaproponowanych zmian . . . . . . . . . . . . . . . . . . . . 91
6.8.1. Ustawienie bitu RB0 na 1 . . . . . . . . . . . . . . . . . . . 91
6.8.2. Zmiana kodowania obszaru DLC . . . . . . . . . . . . . . . 91
6.8.3. Skrócenie pola DLC . . . . . . . . . . . . . . . . . . . . . . 92
6.8.4. Przesyłanie danych w ramce zdalnego żądania . . . . . . . . 92
6.9. Weryfikacja zgodności ze standardem . . . . . . . . . . . . . . . . . 93
6.10. Wnioski . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
Rozdział 7. Wnioski końcowe i podsumowanie . . . . . . . . . . . . . 96
7.1. Wnioski dotyczące przedstawionych metod . . . . . . . . . . . . . . 96
7.2. Wnioski dotyczące CAN . . . . . . . . . . . . . . . . . . . . . . . . 98
7.2.1. Zalecenia projektowe dotyczące protokołu CAN . . . . . . . 101
7.3. Oryginalny dorobek . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
Spis rysunków . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
Spis tabel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
Bibliografia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108
Dodatek A. Opis protokołu Controller Area Network . . . . . . . . 116
A.1. Historia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117
A.2. Model OSI dla sieci CAN . . . . . . . . . . . . . . . . . . . . . . . . 118
A.2.1. Warstwa Fizyczna . . . . . . . . . . . . . . . . . . . . . . . 118
A.2.2. Warstwa łącza danych . . . . . . . . . . . . . . . . . . . . . 122
Spis treści 4
A.3. Podsumowanie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127
Dodatek B. Kod programu C++ . . . . . . . . . . . . . . . . . . . . . 129
B.1. Platforma.cpp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129
B.2. DataLinkLayer.h . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134
B.3. CANFrameClass.h . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138
Dodatek C. Kod programu w Pythonie . . . . . . . . . . . . . . . . . 140
C.1. Kod biblioteki Frames.py . . . . . . . . . . . . . . . . . . . . . . . . 140
C.2. Kod biblioteki DLL.py . . . . . . . . . . . . . . . . . . . . . . . . . 144
C.3. Kod biblioteki PHY.py . . . . . . . . . . . . . . . . . . . . . . . . . 147
C.4. Kod biblioteki LabSupp.py . . . . . . . . . . . . . . . . . . . . . . . 149
Dodatek D. Kod serwera . . . . . . . . . . . . . . . . . . . . . . . . . . 151
Dodatek E. Kod klienta . . . . . . . . . . . . . . . . . . . . . . . . . . . 152
Dodatek F. Kod programu dla mikroporcesora . . . . . . . . . . . . 153
Spis treści 5
Streszczenie
Część główna pracy została ujęta w sześciu rozdziałach.
We wstępie zamieszczono krótki przegląd przez analizę literaturową. Przed-
stawiono pokrótce problematykę jaką praca ta będzie poruszać oraz zaprezen-
towano szkic opracowanej metody. W podrozdziale 1.2 zamieszczono główne
cele pracy.
W rozdziale 2 scharakteryzowano systemy komputerowe, ze szczególnym
uwzględnieniem rozproszonych systemów czasu rzeczywistego. Zwrócono uwa-
gę na ich rodzaje, sposoby klasyfikacji, metody podziału, modele opisu i ana-
lizy takich systemów. Zaprezentowano także szczegółowy opis elementu ta-
kiego systemu jakim jest sieć i parametry ją opisujące.
Rozdział 3 zawiera szczegółowy opis mechanizmu wstawek bitowych. Za-
mieszczono szczegółowy opis zastosowań i przyczyn wykorzystania nadmia-
rowości jaką są wstawki bitowe. Omawiając różne implementacje tego me-
chanizmu w popularnych protokołach, przybliżono problem wartości pesymi-
stycznych liczby wstawek bitowych, w tym zaprezentowano dwie metody ich
wyznaczania: bazującą na specyfikacji oraz własną.
Kolejny rozdział jest to przedstawienie zebranej wiedzy literaturowej do-
tyczącej zwiększania wydajności systemów, wykorzystujących do komunikacji
protokoły z mechanizmem wstawek bitowych. Zaprezentowano w nim stoso-
wane rozwiązania dla warstwy fizycznej i aplikacyjnej.
W rozdziale 5 autor zaprezentował własną metodę służącą do oceny i ogra-
niczenia liczby wstawek bitowych. Składa się ona z 6 kroków.
W następnym rozdziale (6) zastosowano opisany już mechanizm postępo-
wania na wybranym protokole. Autor ze względu na przemysłowe zastosowa-
nia postanowił przeprowadzić cały opisany wcześniej proces na przykładzie
protokołu CAN. We wcześniejszych rozdziałach omówione zostały możliwe
zmiany w innych warstwach, dlatego tym razem przeanalizowano modyfika-
cje na poziomie warstwy łącza danych. Modyfikacje te polegały na zmianie
kodowania lub długości wybranych pól nagłówka. Jednocześnie autor spraw-
dzał czy wprowadzone zmiany zgodne są z przyjętym standardem. Uzyskane
wyniki posłużyły zarówno do oceny opracowanej i opisanej w rozdziale 5
metody, jak również do przeanalizowania wpływu kodowania i układu pól na
wstawki bitowe w ramkach protokołu CAN.
Rozdział 6 stanowi podsumowanie przeprowadzonych badań. Zamieszczo-
no w nim wnioski końcowe jak i spostrzeżenia wyniesione z przeprowadzonych
Spis treści 6
eksperymentów. Dotyczą one nie tylko opracowanych przez autora metod:
wyznaczania liczby wstawek i oceny i ograniczenia liczby wstawek w ramce,
ale również dotyczą protokołu CAN. Te ostatnie zakończone zostały wysto-
sowaniem kolejnego zalecenia dla projektantów.
Po części głównej pracy umieszczono spis umieszczonych rysunków oraz
tabel, a także literaturę do której autor odnosi się w niniejszej pracy.
Na końcu zamieszczono informacje dodatkowe, stanowiące i rozszerzające
wiedzę czytelnika o omawianym zagadnieniu. Umieszczono w nich także kody
programów stanowiących ważną część stanowiska badawczego.
Rozdział 1
Wprowadzenie
System informatyczny jest to zbiór połączonych ze sobą elementów (sprzę-
tu, oprogramowania) służący do przetwarzania zgromadzonych danych, w ce-
lu realizacji określonych zadań [36]. Systemy informatyczne wraz z rozwojem
technologii komputerowych zwiększyły swoje możliwości i zakres zastosowań.
Wraz z rozwojem technologii powstała potrzeba komunikacji pomiędzy po-
szczególnymi komputerami (węzłami systemu). Dla komputerów osobistych
oraz dużych serwerów, najważniejsza jest przepustowość magistrali [23]. Wy-
nika to z konieczności przesyłania zazwyczaj dużej liczby danych. Natomiast
nie ma zbytniego znaczenia opóźnienie powstające podczas transmisji. Dzie-
je się tak, ponieważ komputery te wykonują operacje niedeterministyczne.
Dopiero w ostatnich latach zwiększyło się w Internecie wykorzystanie pro-
tokołów mających za zadanie dostarczenie informacji w określonym czasie.
Wiąże się to z dwoma aspektami. Z jednej strony, współczesne technologie
kompresji danych zaczynają pozwalać przesyłać informacje głosowe i dźwię-
kowe z wykorzystaniem sieci rozległych. Z drugiej strony, zwiększyła się do-
stępność odpowiedniej szybkości łączy, które można kupić za niewygórowa-
ną cenę. Przykładowymi rozwiązaniami, dla których oprócz przepustowości
(rozdział 2.3.2) konieczne jest zapewnienie innych parametrów transmisji to:
telewizja i radio internetowe lub rozmowy głosowe popularnie nazywane Vo-
IP (ang. Voice Over IP) [19, 86]. Wiąże się to z dynamicznym rozwojem
technologii jakości usług - QoS (ang. Quality of Service) [11, 17, 35]. Jej
zadaniem jest odfiltrowanie ramek wymagających natychmiastowego dostar-
czenia, przez węzeł pośredniczący (przełącznik, router) i przesłania ich przed
ramkami mogącymi dotrzeć z większym opóźnieniem.
Inną gałęzią informatyki, gdzie przepustowość od początku była tylko
jednym z kilku ważnych parametrów są sieci przemysłowe. Są to sieci nie-
zbędne przy tworzeniu systemów czasu rzeczywistego. Systemy te charak-
teryzują się wysokimi wymaganiami dotrzymania czasu dostarczenia wiado-
Rozdział 1. Wprowadzenie 8
mości i właśnie dla takich systemów opracowane zostały specjalne proto-
koły komunikacyjne sieci przemysłowych [29]. Z tego względu od początku
prac nad rozwiązaniami komunikacyjnymi dla systemów przemysłowych duży
nacisk kładziono na zapewnienie wartości wystarczających do zrealizowania
poprawnej transmisji: zmienności oraz czasu realizacji wymiany informacji
w systemie. Jednocześnie z wprowadzeniem różnych protokołów (między in-
nymi ProfiBus, FIP, CAN, ModBus, LonWorks) [59, 77] pojawiły się roz-
wiązania modelujące i symulujące proces wymiany. Jednym z ważniejszych
narzędzi do modelowania jest sieć Petriego wraz z różnymi rozszerzeniami
[2, 60, 69, 72, 85]. W każdym z zaprezentowanych modeli (rozdział 2.2) czas
transmisji zajmuje kluczowe miejsce. Opracowanie metody skrócenia czasu
wymiany może przynieść znaczącą korzyść, a mianowicie zazwyczaj jej za-
stosowanie wpłynie na czas transmisji w każdym z węzłów. Poza modelami
i rozwiązaniami symulacyjnymi, odzwierciedlającymi działanie systemu, za-
gwarantowanie czasu dostarczenia wiadomości można uzyskać w jeszcze jeden
sposób, wykorzystując mechanizm planowania cyklu wymiany (szeregowanie)
[13, 14, 79]. Zależnie od sposobu dostępu do medium (Token, PDC, CSMA,
Master-Slave) [7], wykorzystywane są różne mechanizmy.
Konstrukcja protokołu komunikacyjnego musi nie tylko uwzględniać wy-
mogi transmisji danych (tj. efektywności lub szybkości) ale również zagwa-
rantować poprawną interpretację informacji przesyłanej (w warstwie fizycz-
nej i logicznej). Dla przykładu, w sieciach o węzłach z równoprawnym do-
stępem do łącza, często wykorzystywane są pewne ciągi bitów jako ramki
sterujące, głównie ramki informujące o wystąpieniu błędów lub kolizji. Z te-
go względu w warstwę łącza danych wpleciony jest algorytm zapewniający
uniknięcie wystąpienia ciągu niedozwolonego w poprawnej ramce, taki jak
mechanizm wstawiania bitów (ang. bit-stuffing) [10, 49, 87]. Innym zasto-
sowaniem tego rozwiązania to zapewnienie maksymalnego czasu pomiędzy
re-synchronizacjami nadawcy i odbiorców. Te zadania mogą być realizowane
przez zastosowanie między innymi:
— doboru odpowiedniego kodowania informacji w łączu (np. kodowanie Man-
chester),
— kodowania informacji w warstwie łącza danych (np. kodowanie 4b/5b,
ModBus ASCII),
— wydłużanie informacji poprzez dodawanie bitów zapewniających spełnie-
nie oczekiwanych parametrów (wstawki bitowe).
Ze względu na coraz większą złożoność systemów wbudowanych [3], wzra-
Rozdział 1. Wprowadzenie 9
sta maksymalne wykorzystanie łącza. Aby zachować determinizm czasowy
jaki oczekiwany jest od stosowanej sieci, konieczna jest dokładna analiza
i optymalizacja planowanego ruchu. Z tego względu poszukiwane są rozwiąza-
nia, które zapewnią najlepszą lub zbliżoną do najlepszej wymianę informacji.
W sieciach przemysłowych w tym celu tworzy się plan wymiany komunikatów,
którego wykonanie nie może przekroczyć maksymalnego, dopuszczalnego cza-
su wymiany. W tym celu opracowano różne metody szeregowania podzielone
na grupy: RMS [15, 55, 77] lub EDF [15, 47]. Przy wykorzystaniu metody sze-
regowania należy za każdym razem brać pod uwagę wartości pesymistyczne
poszczególnych transmisji.
Aby zwiększyć możliwość przesyłania informacji w sieci, prowadzone ba-
dania koncentrują się na lepszym planowaniu transmisji lub próbie lepsze-
go oszacowania wartości pesymistycznej, wykorzystywanej do wyznaczania
czasu wymiany [49, 50]. W protokołach, w których nadmiarowość zależna
jest od przesyłanych danych, próbuje się zmniejszyć liczbę bitów nadmiaro-
wych, wprowadzając modyfikacje na poziomie warstwy aplikacyjnej. Przykła-
dem jest propozycja wprowadzenia dodatkowych modyfikacji na polu danych
[48]. Dla sieci CAN dodatkowo wyznaczono grupy identyfikatorów, dzieląc
je na podstawie liczby bitów wstawionych w nagłówek [48]. Publikacja oma-
wiająca to zagadnienie jest jedną z nielicznych, zajmującą się analizą zacho-
wania warstwy łącza danych, w zależności od przesyłanych informacji.
Gdy niewystarczająca wartość przepustowości uniemożliwia przeprowa-
dzenie wszystkich wymian w jednym segmencie sieci, należy wprowadzić
zmiany w warstwie fizycznej. Najczęstszym rozwiązaniem jest segmentacja
(zastosowanie podsieci [6, 27, 46]). Innym rozwiązaniem jest zmiana całego
mechanizmu komunikacji na bardziej wydajny. Segmentacja jest to podział
sieci na mniejsze fragmenty. Uzyskuje się to albo poprzez stworzenie sie-
ci hierarchicznej (przez jeden węzeł cała wydzielona podsieć ma możliwość
komunikowania się z pozostałymi węzłami sieci nadrzędnej), albo poprzez
zastosowanie przełączników (ang. switch). Jednym z opisanych w literaturze
rozwiązań jest koncepcja FastCAN. Jest to idea wykorzystania dwóch równo-
ległych kanałów do przesyłania informacji [9, 78]. Zwiększenie przepustowości
uzyskuje się dodając kolejną magistralę, dzieląc jednocześnie ramkę na część
sterującą (nagłówek) oraz dane.
Przeprowadzona analiza wykazała ciągły wzrost zapotrzebowania na pa-
smo transmisyjne w sieciach przemysłowych. Wskazuje na to zarówno opra-
cowanie nowych rozwiązań sieciowych (np. LIN, FlexRay), jak i ciągłe prace
Rozdział 1. Wprowadzenie 10
nad poprawą wykorzystywanych metod oceny szeregowania i oszacowania
czasu trwania poszczególnych cykli. W literaturze natomiast nie spotkano
analiz warstwy łącza danych protokołów wykorzystujących mechanizm wsta-
wek bitowych, pod kątem oceny wpływu poszczególnych pól na całkowitą
długość ramki. Brak takich rozwiązań nasuwa pytanie o możliwości ograni-
czenia liczby wstawek bitowych poprzez odpowiednią budowę ramki, a co
za tym idzie zwiększenie liczby przesyłanych informacji. Nasuwa się również
pytanie czy możliwym jest określenie metody postępowania aby takie ba-
dania przeprowadzić. Przeprowadzenie operacji redukcją wstawek bitowych
przyczyni się do lepszego wykorzystania pasma w stosowanych protokołach,
zmniejszając również parametry czasowe dostarczenia pojedynczej informa-
cji. Prowadzone badania mogą dostarczyć również informacji o koszcie (cza-
sie) jaki jest ponoszony przy zastosowaniu badanego mechanizmu w protoko-
łach komunikacyjnych. Uzyskane w trakcie badań wyniki wskażą czy warto
jest przeprowadzać redukcję wstawek, według zaproponowanej opracowanej
metody.
1.1. Analiza teoretyczna problemu
Analiza mechanizmu wstawek bitowych wykazuje dla warunków krańco-
wych wysoki narzut protokołu. Jednak mechanizm ten ze względu na ści-
słą zależność od przesyłanych danych umożliwia ograniczenie narzutu z nim
związanego. Wśród stosowanych rozwiązań najczęściej mechanizm wstawek
bitowych zabezpiecza przed wystąpieniem ciągów N-bitowych albo tylko jed-
nego stanu łącza (zera lub jedynki) [24, 75] albo obu stanów [59]. Roz-
mieszczenie pól, oraz ustawiane wartości mogą wpływać na liczbę wystąpień
wstawek bitowych. Mając pewien wycinek ramki (rysunek 1.1) i warunek
· · · 4 bity 1 bit 4 bity · · ·
Rysunek 1.1. Zależności pomiędzy długością ciągu zabronionego a polami steru-
jącymi
wystąpienia wstawki bitowej po przesłanych 5 jednakowych bitach, może
okazać się że zależnie od dobranego kodowania pól dłuższych, wstawka może
nie wystąpić w ogóle lub bardzo rzadko. Oczywiście wystąpić może również
sytuacja odwrotna, gdzie ze względu na stosowane kody informacji może po-
wstać wstawka „permanentna” (zawsze występująca). Oprócz odpowiedniego
Rozdział 1. Wprowadzenie 11
dobierania kodowania informacji w poszczególnych polach można dokonać
przemieszczenia względem siebie pól, zwracając uwagę aby jak najrzadziej
pojawiały się niedozwolone bloki bitów (w tym przypadku 5 zer lub jedynek).
Takim elementem jest najczęściej nagłówek ramki, zawierający zbiór wydzie-
lonych logicznie obszarów (np. typ, rodzaj, długość). Jeżeli pewne znaczniki
występują obok siebie to może okazać się, że zawierają wartości tworzące ciąg
spełniający warunek wystąpienia wstawki. Niestety w tym obszarze użyt-
kownik protokołu ma niewielkie pole działania (może dotyczyć jedynie prób
doboru wartości niektórych pól), co nie zawsze uchroni przed pojawieniem się
wstawek. Uwaga zwrócona na nagłówek jest o tyle istotna, gdyż nieodpowied-
nie ułożenie pól oraz ustawione wartości nagłówka mogą spowodować że po
tym samym bicie ramki pojawi się wstawka. Takie zachowanie w nagłówku
ma niekorzystny wpływ poprzez efekt skali, a więc częstego występowania
w komunikacji (każda ramka). Inaczej jest w obszarze pola danych, gdzie
użytkownik takiej sieci zawsze ma możliwość dopasowania metody kodowa-
nia danych na poziomie aplikacyjnym i w ten sposób próbować ograniczać ich
wystąpienie. Rzadsze wykorzystanie wstawek bitowych doprowadzi do uzy-
skania krótszych ramek (ramek z mniejszą liczbą wstawek), a tym samym do
zwiększenia sprawności protokołu.
Przykład 1. Przyjmując że strumień informacji jest zabezpieczany za po-
mocą wstawek bitowych 6/5, co oznacza że po 5 jednakowych wartościach
wstawiana jest wartość przeciwna, to dla obszaru tak zabezpieczonego współ-
czynnik przyrostu długości ramki wynosi 1,25. Przy zabezpieczaniu 100 bi-
towego ciągu uzyskujemy do wysłania maksymalnie ciąg 125 bitów. Gdyby
udało się uzyskać poprawę 1 lub 2 bitów to ramka skróciła by się o około 1%.
Jak już wspomniano, efektywne przesyłanie danych zależy od projektan-
ta. Natomiast w strukturę ramki można jedynie ingerować tworząc nowy
protokół lub odpowiedni kontroler sieci. Dlatego na etapie projektowania
ważnym wydaje się przetestowanie wypływu zastosowanego układu pól i war-
tości na wstawki bitowe.
Do tej pory nie spotkano się prezentacją metody oceny protokołu pod
kątem liczby wstawek bitowych. W literaturze zajmującej się wstawkami bi-
towymi również nie analizowano wpływu budowy nagłówka na liczbę wy-
stępujących wstawek bitowych, a obszar ten ze względu na występowanie
w każdej ramce może mieć większe znaczenie dla wykorzystania łącza niż
pole danych (szczególnie dla krótkich ramek sterujących).
Rozdział 1. Wprowadzenie 12
1.2. Cel pracy
Celem pracy było opracowanie metody analizy ramek protokołów wyko-
rzystujących mechanizm wstawek bitowych, w celu ograniczenia ich wystę-
powania przy zachowaniu takich właściwości protokołu jak:
— maksymalna długość ramki,
— opóźnienie,
— zmienność.
W analizowanej literaturze nie spotkano się z opisem metody weryfikacji po-
prawności budowy ramki (szczególnie pod kątem wpływu wartości poszcze-
gólnych pól na całkowitą długość ramki). Jak już wspomniano, wpływ na czas
transmisji mają wstawki bitowe, związane z wartościami poszczególnych pól.
Na podstawie przeprowadzonej analizy literaturowej można wywnioskować,
iż problem związany ze zwiększeniem przepustowości jest ważny. Cel tych
badań dobrze współgra z tendencjami światowymi przedstawianymi w pu-
blikacjach [6, 8, 9, 27, 28, 58, 61]. Publikacje te poszukują rozwiązań, które
umożliwiły by przesyłanie większej ilości informacji. W rezultacie niniejsza
praca powinna zwrócić uwagę projektantów na znaczenie układu i kodowania
pól, a także pokazać w jaki sposób można sprawdzić czy opracowane ram-
ki dają najlepsze rozwiązania. Zadanie to zrealizowano poprzez przebadanie
i wprowadzenie kilku modyfikacji na jednym z dostępnych protokołów. Po-
równywanymi parametrami były: sprawność, opóźnienie i zmienność czasu
transmisji pojedynczej ramki.
1.3. Tezy
W wyniku badań literaturowych sformułowano następujące tezy pracy:
Teza 1. W protokołach wykorzystujących mechanizm wstawek bitowych, przez
odpowiednie dobranie wartości kodów poszczególnych pól i ich rozmieszczenie,
można zmniejszyć występowanie wstawek bitowych, co w konsekwencji skraca
długość ramki i poprawia parametry czasowe transmisji.
Teza 2. Istnieje możliwość opracowania metody weryfikacji doboru kodów
i układu pól w ramkach, z wstawkami bitowymi, w celu ograniczenia występo-
wania wstawek bitowych.
Rozdział 1. Wprowadzenie 13
1.4. Zakres pracy
Na początku przeprowadzono analizę literaturową w celu wyszukania
opracowanych już rozwiązań likwidacji wstawek w ramkach oraz ewentual-
nych opracowanych już metod badania omawianego problemu. Następnym
krokiem jest przedstawienie algorytmu postępowania w celu sprawdzenia czy
interesujący protokół jest dobrze zbudowany pod kątem występowania wsta-
wek bitowych. Ostatnim etapem będzie weryfikacja opisanego algorytmu.
Ponieważ praca ma na celu weryfikację poprawności przyjętej metody pod
kątem skuteczności i celowości jej stosowania, do testów wybrano jeden z już
opracowanych i stosowanych protokołów.
Prezentowana praca ma charakter teoretyczno-doświadczalny. Metoda zo-
stała podzielona na:
1. wybranie interesujących parametrów,
2. badanie zachowania się ramki i wyznaczenie określonych parametrów,
3. na podstawie uzyskanych wyników dokonujemy oceny protokołu,
4. wyznaczenie wrażliwych miejsc na pojawienie się wstawek,
5. w razie konieczności wprowadzenie zmian (w budowie ramki lub kodowa-
niu pól),
6. wyznaczenie nowych wartości parametrów i porównanie różnic.
Część eksperymentalna składa się z kilku etapów przedstawiających stoso-
wanie opracowanej metody badawczej na przykładzie wybranego protokołu.
Na początku wyznaczone zostały kluczowe parametry wykorzystywane póź-
niej do oceny wprowadzonych zmian. Następnie zbadano zachowanie się ram-
ki ze względsu na wstawki bitowe, aby wyszukać podatne miejsca. Po uzy-
skaniu informacji o tzw. „słabych punktach ramki”, czyli miejscach gdzie
najczęściej występują wstawki, określone zostały przyczyny oraz opracowano
propozycje zmian. Dla tych modyfikacji, przeprowadzono te same symulacje
jak dla ramki bazowej. Symulacja ta przeprowadzona została na kompute-
rze za pomocą specjalnie napisanych przez autora pracy programów. Na ich
podstawie wyznaczone zostały te same parametry co dla ramki bez zmian.
Ostatnim etapem było porównanie i ocena uzyskanych rezultatów. Na pod-
stawie przeprowadzonych eksperymentów dokonano oceny postawionych tez.
Rozdział 2
Sieciowe systemy komputerowe
2.1. Wprowadzenie
Bardzo często używane jest pojęcie systemu komputerowego [29], lub za-
miennie systemu informatycznego [62, 81]. Niestety trudno jest spotkać się
w literaturze z jego definicją. W mowie potocznej bardzo często system kom-
puterowy traktowany jest jako oprogramowanie (system operacyjny i pro-
gramy) umieszczone w komputerze. Niektóre publikacje, poruszające różne
zagadnienia systemów komputerowych, nie definiują tego pojęcia, uznając je
za pojęcie podstawowe i oczywiste. Może to być założenie mylne, powodujące
błędne rozumienie przedstawionego zagadnienia, szczególnie przy omawianiu
systemów, które nie ograniczają się do pojedynczego urządzenia.
Istnieje podejście formalne wykorzystywane w rozporządzeniach rządu
RP (definicja 1)[21].
Definicja 1. System komputerowy jest to sprzęt komputerowy i związane
z nim oprogramowanie, skompletowane i zainstalowane w celu wykonania
specyficznej funkcji lub szeregu funkcji.
Ilustrację tej definicji przedstawiono na rysunku 2.1.
Innym bardziej szczegółowym określeniem systemu informatycznego jest
definicja umieszczona w dokumencie opublikowanym przez Unię Europejską
[57]:
Definicja 2. System informatyczny oznacza wszelkie urządzenia lub grupę
połączonych lub powiązanych urządzeń, z których jedno lub więcej, zgodnie
z oprogramowaniem, dokonuje automatycznego przetwarzania danych kom-
puterowych, jak również danych przechowywanych, przetwarzanych, odzyska-
nych lub przekazanych przez nie w celach ich eksploatacji, użycia, ochrony
lub utrzymania.
Rozdział 2. Sieciowe systemy komputerowe 15
Rysunek 2.1. Abstrakcyjne wyobrażenie elementów systemu komputerowego [63]
Definicja 2 jako definicja prawna jest bardzo precyzyjna. Dokładnie opi-
suje działanie takiego systemu. W literaturze naukowej najczęściej spotyka
się definicję 3 [67].
Definicja 3. Systemem komputerowym nazywamy zorganizowany zbiór obiek-
tów (podsystemów), które są od siebie zależne i stanowią pewną częściowo
zamkniętą (względem relacji zależności) jednostkę.
Wszystkie definicje (również te nie przedstawione jak [81]), próbują opisać
bardzo szerokie pojęcie, co prowadzi do tworzenia albo pojęcia bardzo ogól-
nego, a przez to nieprecyzyjnego, albo bardzo złożonego, mogącego stawać
się mało zrozumiałym. Bardziej formalne określenia systemu komputerowe-
go opracowywane są przez naukowców zajmujących się teorią informatyki,
a dokładniej teorią obliczeń (ang. computability theory)[83].
Systemy komputerowe klasyfikuje się najczęściej według następujących
kryteriów:
— sposób transmisji danych (zdalne, lokalne, mieszane),
— sposób przetwarzania danych (wsadowe, konwersacyjne, mieszane),
— sposób użytkowania zasobów (jednodostępowe, wielodostępowe),
Rozdział 2. Sieciowe systemy komputerowe 16
— rozmieszczenie terytorialne (scentralizowane, rozproszone).
Interesującą nas klasyfikacją będzie podział ze względu na rozmieszczenie
terytorialne. Ponieważ większość systemów komputerowych wykorzystywa-
nych w przemyśle, są to systemy rozproszone, toteż zagadnienia dotyczące
takich systemów będą poruszane w tej pracy.
2.1.1. System scentralizowany
System scentralizowany był pierwszym rozwiązaniem systemów, wyko-
rzystywanych w informatyce. Wynikało to z ceny i dostępności komputerów.
Początkowo, w latach 40 dwudziestego wieku, były to jednostki bardzo du-
że (zajmujące całe pomieszczenia) [72, 73], jednocześnie koszt ich zakupu
i utrzymania był na tyle wysoki, że duże firmy i jednostki naukowe posiadały
tylko jeden taki komputer. Nawet dziś większość użytkowników komputerów
korzysta z systemów scentralizowanych (stacja robocza). Takie rozwiązanie,
jak każde rozwiązanie posiada swoje wady i zalety. Zaletami systemu scen-
tralizowanego są:
— łatwe zarządzanie,
— szybki dostęp do wszystkich zasobów,
— pełna kontrola nad zasobami.
System taki posiada również pewne wady:
— trudniejsze rozszerzanie systemu,
— ograniczenie terytorialne,
— problemy z tworzeniem systemu z nadmiarowością (systemu posiadają-
cego elementy mogące być wykorzystane w momencie awarii elementu
podstawowego),
— wysoki koszt zwiększenia mocy obliczeniowych,
— mała niezawodność (awaria jednego elementu powoduje zatrzymanie ca-
łego systemu).
2.1.2. System rozproszony
Odkrycie układów scalonych zapoczątkowało miniaturyzację kompute-
rów, która następnie spowodowała ich upowszechnienie. Kolejnym krokiem
rozwoju informatyki było pojawienie się potrzeby wymiany informacji po-
między poszczególnymi urządzeniami. Aby zrealizować te wymagania opra-
cowano pierwsze sieci komputerowe [65]. Zmieniło to całkowicie podejście
do systemów komputerowych - ich działania i funkcji. Jedno urządzenie zo-
Rozdział 2. Sieciowe systemy komputerowe 17
stało zastąpione przez rozproszoną, odrębną grupę jednostek obliczeniowych,
tworzących spójną logiczną całość [82]. Wiązało się to z uzyskaniem różnych
korzyści [56, 71, 76, 82]:
— współdzielenie zasobów (ang. resource sharing) - wiele węzłów może ko-
rzystać ze wspólnych zasobów,
— otwartość (ang. openness) - niski koszt rozbudowy systemu,
— współbieżność (ang. concurrent) - przetwarzanie równoległe na poziomie
systemu bez przełączania procesów,
— możliwość niezależnej modyfikacji programu poszczególnych węzłów bez
zakłócania pracy pozostałych,
— redukcja długości przewodów komunikacyjnych systemu (nawet w stosun-
ku 5:1)
— odporność na błędy (ang. fault tolerance) - odpowiednia konfiguracja mo-
że zwiększyć niezawodności poprzez przejmowanie obowiązków uszkodzo-
nych węzłów przez węzły sprawne,
— skalowalność (ang. scalability) - możliwość rozbudowy systemu z zacho-
waniem podobnej wydajności,
— niższy koszt zwiększenia mocy obliczeniowa,
— optymalny dobór urządzeń pomiarowych,
— wysoka niezawodność (awaria jednego elementu nie powoduje zatrzyma-
nia całego systemu),
— łatwe i nisko kosztowe zwiększanie mocy obliczeniowych.
Zastosowanie systemu rozproszonego wprowadza jednocześnie pewne za-
grożenia. Głównymi problemami systemu rozproszonego (ang. distributed sys-
tem)[82] jest komunikacja pomiędzy węzłami. Powoduje to powstanie nie-
pewności dostarczenia wiadomości, powstania nieprzewidywalnego opóźnie-
nia lub przekłamania wiadomości. System rozproszony musi być przygoto-
wany na takie zdarzenia, dlatego przy doborze odpowiedniego mechanizmu
komunikacyjnego należy uwzględnić cechy protokołu i oczekiwania systemu
(rozdział 2.3).
2.1.3. System czasu rzeczywistego
Pojęcie czasu rzeczywistego (ang. real-time system) jest pojęciem względ-
nym. Ponieważ nie da się zdefiniować fizycznych wartości czasu, dla których
uznamy że system jest czasu rzeczywistego. Wartość graniczna zależy od za-
dania jakie dany system ma wykonywać. Na przykład, czas reakcji poduszki
Rozdział 2. Sieciowe systemy komputerowe 18
powietrznej w samochodzie musi mieścić się w dość wąskim przedziale czasu
(około 15 milisekund). Innego czasu reakcji oczekujmy od naszego odtwarza-
cza MP3, który po wybraniu utworu, może nawet kilka sekund czekać zanim
rozpocznie odtwarzanie, ale po rozpoczęciu odtwarzania musi nieprzerwanie
otrzymywać kolejne porcje danych aby nie nastąpiła przerwa w odtwarzanym
utworze. Oba systemy można uznać za systemy czasu rzeczywistego.
System czasu rzeczywistego lub nazywany także systemem działającym
na bieżąco [56] można zdefiniować jako [64]:
Definicja 4. System czasu rzeczywistego to sprzęt i oprogramowanie, którego
poprawne działanie zależy od wyników przez niego wytwarzanych oraz czasu
potrzebnego do ich przygotowania.
System musi potrafić zareagować na zdarzenie (ang. dependability) [68] w cza-
sie nie przekraczającym pewnej określonej wartości [26], niezależnie od ak-
tualnego obciążenia systemu [71]. Wymaganie wygenerowania odpowiedzi w
określonym czasie, nie może być przekroczone nawet podczas wystąpienia
błędu. Kolejnym zagadnieniem jakie musi uwzględniać system, to obsługa
wszystkich sytuacji nietypowych. Zadanie to jest jednym z najtrudniejszych,
gdyż wymaga od projektanta przewidzenia zdarzeń, które nie są opisane
w specyfikacji.
W literaturze [1, 54, 67] najczęściej wykorzystywaną definicja jest:
Definicja 5. System czasu rzeczywistego jest to system komputerowy, w któ-
rym obliczenia są wykonywane współbieżnie z procesem zewnętrznym (oto-
czeniem) w celu sterowania, nadzorowania lub terminowego reagowania na
zdarzenia występujące w tym procesie(otoczeniu)
Schemat elementów systemu czasu rzeczywistego przedstawia rysunek 2.2.
W zależności od dopuszczalnego odstępstwa od czasu reakcji rozróżniamy
następujące typy ograniczeń [67, 71]:
— ostre (ang. Hard RealTime),
— łagodne (ang. Firm RealTime),
— słabe (ang. Soft RealTime).
Ostre wymagania czasowe
System o ostrych (twardych) wymaganiach czasowych jest to system wy-
magający wykonania każdego zadania w dokładnie określonym nieprzekra-
czalnym okresie czasu. Nie tolerowane są jakiekolwiek odstępstwa od za-
danych ograniczeń. Warunek spełnienia oczekiwań może przyjmować dwie
Rozdział 2. Sieciowe systemy komputerowe 19
Rysunek 2.2. System czasu rzeczywistego i jego otoczenie [68]
postaci: mniej lub bardziej rygorystyczną. W bardziej rygorystycznym przy-
padku odpowiedź systemu powinna być przesłana do otoczenia w określonym
momencie czasu. System nieznacznie łagodniejszy to system, w którym od-
powiedź musi być dostarczona nie później niż do określonego momentu czasu.
Ten rodzaj systemu można zapisać formalnie jako:
z(t) =
u t0 < t < tT
−∞ t tT(2.1)
6
-
z(t)
tt0 tT−∞
u
?
Rysunek 2.3. System o ostrych wymaganiach czasowych [22, 80]
Łagodne wymagania czasowe
Systemom o łagodnych wymaganiach czasowych stawia się dwa ograni-
czenia. Pierwsze ograniczenie (krótszy czas reakcji), można bezkarnie prze-
kroczyć. Drugie (dłuższy czas reakcji) ograniczenie musi zostać spełnione.
Do tego czasu system musi wygenerować odpowiedź na zaistniałe zdarzenie.
Rozdział 2. Sieciowe systemy komputerowe 20
Przedstawioną definicję ilustruje wzór 2.2 i wykres na rysunku 2.4.
z(t) =
u t0 < t < tT
0 t tT(2.2)
[80]
6
-
z(t)
tt0 tT−∞
u
Rysunek 2.4. System o łagodnych wymaganiach czasowych [22, 80]
Słabe wymagania czasowe
Jest to system, w którym oczekuje się aby średni czas odpowiedzi mie-
ścił się w wyznaczonych granicach. Zbyt późne dostarczenie odpowiedzi nie
powoduje dyskwalifikacji systemu, może natomiast mieć niekorzystny wpływ
na jego pracę. Opis matematyczny systemu przedstawia wzór 2.3,
z(t) =
u t0 < t < t1
u tT−ttT−t1 t1 < t < tT
0 t tT
(2.3)
[80] a jego reprezentacja graficzna przedstawiona jest na rysunku 2.5.
6
-
z(t)
tt0 t1 tT−∞
uJ
JJ
JJ
JJJ
Rysunek 2.5. System o łagodnych wymaganiach czasowych [22, 80]
Spełnienie wymagań
Do spełnienia wymagań systemu czasu rzeczywistego konieczne jest aby
suma czasów trwania poszczególnych zadań mieściła się w zadanym zakresie.
Rozdział 2. Sieciowe systemy komputerowe 21
W tym celu należy tak dobrać i zbudować elementy (sprzęt i oprogramo-
wanie) aby całościowo spełniały postawione warunki. Jednym z elementów
takiego systemu może być sieć. Zmniejszenie czasu przesyłania informacji
(czasu przygotowania, przesłania i odbioru) wpłynie korzystnie na całkowity
czas, pozwalając wykonać więcej zadań w jednym cyklu wymiany albo wręcz
będzie jedyną możliwością na zrealizowanie wymaganych zadań.
2.2. Rozproszony system czasu rzeczywistego
Systemy komputerowe dzieli się ze względu na rozdrobienie terytorialne
lub wymagany czas reakcji. Dokładną charakterystykę poszczególnych po-
działów przedstawiono w rozdziale 2.1. Szczególnym przypadkiem systemu, z
którym często przy realizacji procesów przemysłowych mamy do czynienia to
rozproszone systemy czasu rzeczywistego (ang. distributed real time systems).
Zastosowanie takiego rozwiązania wiąże się z charakterem pracy systemu w
warunkach przemysłowych - nieustannie zmieniające się stany procesów mo-
nitorowanych przez system. Specyfika zastosowania wymaga od systemów
następujących cech:
— odporność na zakłócenia,
— niezawodność,
— szybkość reakcji,
— rozproszoność,
— przewidywalność.
Systemy scentralizowane nie mogły spełnić wszystkich wymagań. Głównym
problemem było sterowanie układami automatycznej regulacji poprzez jed-
nostkę centralną. Z tego powodu do systemów komputerowych, pomimo pew-
nych niedogodności, wprowadzono rozproszenie. Podział systemu, umożli-
wił stworzenie wielu, często autonomicznych węzłów, mogących w skrajnych
przypadkach (braku komunikacji z pozostałymi węzłami), podejmować nieza-
leżne decyzje (głównie przejście do stanu bezpiecznego (ang. safety position)).
Na system rozproszony czasu rzeczywistego składają się dwa elementy
[29]:
— system rozproszony (rozdział 2.1.2),
— system czasu rzeczywistego (rozdział 2.1.3).
W omawianych systemach niezwykle ważnym elementem jest czas. Jest to
element krytyczny, z punktu widzenia sterowanych urządzeń. Aby zachować
Rozdział 2. Sieciowe systemy komputerowe 22
determinizm, musimy w odpowiedni sposób połączyć ze sobą pewne własno-
ści takiego systemu [29]:
— działanie ciągłe,
— interakcja między procesami asynchronicznymi,
— przewidywalność opóźnień,
— nieokreśloność i brak cykliczności zachowań,
— globalność zegara,
— wielowątkowość interakcji procesów.
Problemem przy tworzeniu rozwiązań czasu rzeczywistego jest ocena zacho-
wania się systemu. Bardzo prosta jest ocena poszczególnych elementów (pro-
gramu, pojedynczej wymiany w sieci). Bez najmniejszych problemów można
zaplanować cykl węzła sterującego (rysunek 2.6), z podziałem na poszczegól-
ne obszary:
— czas testu i konfiguracji (T0),
— czas akwizycji stanów wejść (T1),
— czas realizacji programu (TAP ),
— czas wymiany komunikatów (TK),
— czas aktualizacji stanów (T2).
Na podstawie szeregowania można wyznaczyć czas cyklu węzła (wzór 2.4).
TA = T0 + T1 + TAP + TK + T2 (2.4)
Czasy poszczególnych operacji wynikają z własności fizycznych węzła
(czasu przetwarzania wejść/wyjść lub prędkości procesora). Podobnie sprawa
wygląda gdy próbujemy poddać analizie czasowej, wymianę informacji w wy-
korzystywanej sieci. Wiadomo, że na czas przesyłania komunikatu (rysunek
2.7) wpływ mają następujące czynniki:
— przygotowanie ramki (τF ),
— czas nadawania (τT ),
— czas propagacji (τP ),
— czas odbioru (τR),
— czas weryfikacji ramki (τV ).
Suma wymienionych wartości (całkowity czas transmisji atomowej TTD), przy
założeniu że czasy nadawania i odbioru są jednakowe (τT = τR = τT/R):
TTD = τF + τT/R + τP + τV (2.5)
Rozdział 2. Sieciowe systemy komputerowe 23
Rysunek 2.6. Podstawowy cykl pracy sterownika jednoprocesorowego [29]
2.2.1. Model analityczny
Wyznaczanie czasu transmisji poszczególnych węzłów wykonuje się za po-
mocą prostego algorytmu. Problem pojawia się w momencie analizy oddziały-
wania pomiędzy węzłami. Pomimo iż jako niezależne układy takiego systemu
będą zachowywać się deterministycznie i przewidywalnie, to wcale nie muszą
się tak samo zachowywać jako element całego systemu. Pierwszym proble-
mem jest przepustowość łącza, która tylko w nieznacznym stopniu może być
zajmowana przez każdy z węzłów. Dlatego konieczne jest takie rozplanowanie
czasu trwania cykli poszczególnych węzłów, aby wymiany komunikatów nie
kolidowały ze sobą na współdzielonym łączu. Jednocześnie ważne jest aby
każdy z węzłów nie produkował więcej danych niż będzie w stanie przesłać.
W innym przypadku spowoduje to zapełnienie kolejki koprocesora sieci i jed-
nocześnie uniemożliwi pracę w czasie rzeczywistym.
Rozdział 2. Sieciowe systemy komputerowe 24
Rysunek 2.7. Czas transmisji ramki [66]
Systemy informatyki przemysłowej poddane są oddziaływaniu czynników
zewnętrznych (pogody lub zakłóceń) i muszą działać w sposób ciągły w każ-
dych warunkach. Ze względu na oddziaływanie niekorzystnych czynników
mogą podczas transmisji występować błędy. W momencie wystąpienia błędu
wymagane jest jego wykrycie i retransmisja wiadomości. Z tego względu,
każdy system musi być przygotowany na konieczność retransmisji pewnej
porcji informacji.
Węzeł systemu musi mieć możliwość wyznaczenia czasów granicznych
(ang. dead line), dlatego jednym z rozwiązań są zegary wewnętrzne. Ponieważ
działają one niezależnie od innych zegarów, wymagają strojenia (synchroni-
zacji). Zegar ten jest niezbędny do wyznaczenia wartości globalnych oraz do
monitorowania systemu.
Jak przedstawiono, istnieje interakcja zarówno wewnątrz węzłów jak i po-
między nimi. Aby móc porównywać różne rozwiązania konieczne jest stwo-
rzenie modelu, do którego dopasowywane będą testowane implementacje. W
literaturze spotkano się z trzema modelami. Zostały one podzielone według
pewnych cech. W każdym z nich element komunikacji pomiędzy węzłami
stanowi ważny element systemu wprowadzający znaczne opóźnienia (najwol-
niejsza praca, największa odległość, najwięcej niezależnych procesów).
Model struktury fizycznej
Głównym założeniem modelu jest podział systemu ze względu na zasoby
fizyczne poszczególnych węzłów. Wyróżnić możemy:
— jednostkę centralną,
— protokół komunikacyjny,
— stację operatorską,
— medium transmisyjne.
Każdy element, wykonuje pewne zadania, na których wykonanie potrzebuje
czasu. Dodatkowo mogą wystąpić interakcje pomiędzy poszczególnymi war-
stwami, powodujące dodatkową konsumpcję czasu. Na rysunku 2.8 przedsta-
Rozdział 2. Sieciowe systemy komputerowe 25
wiony jest model rozproszonego systemu przemysłowego. Zaletą tego mode-
Rysunek 2.8. Model przemysłowego systemu komputerowego [29]
lu jest podział odzwierciedlający zazwyczaj funkcje pogrupowane w osobne
układy scalone. Umożliwia to przeprowadzenie analizy, która jednoznacznie
wskaże najsłabszy punkt każdego węzła oraz systemu.
Węzeł systemu. Funkcję węzła stanowi najczęściej specjalnie przygotowa-
ny mikrokomputer lub uniwersalna programowalna jednostka. Na nim uru-
chamiane jest oprogramowanie zarządzające i sterujące. Posiada ono moż-
liwość sterowania portami wejść/wyjść (ang. Input/Output) oraz kontaktu
z innymi węzłami. Czas wykonania poszczególnych elementów cyklu zależny
jest od wykorzystywanej jednostki centralnej oraz od programisty tworzącego
kod programu. Dla realizacji komunikacji z innymi węzłami wykorzystywany
jest dedykowany koprocesor sieciowy.
Protokół komunikacyjny. Protokół komunikacyjny jest to zbiór reguł al-
bo inaczej mówiąc specjalny język porozumiewania się węzłów, umożliwiający
im swobodną dla wszystkich zrozumiałą komunikację. W protokole zawierają
się informacje o sposobie przydzielania zasobów, nadawania oraz interpreta-
cji występujących stanów. Dodatkowo każdy protokół posiada zabezpieczenia
pozwalające wykryć przekłamanie informacji. Ważnym elementem protokołu,
Rozdział 2. Sieciowe systemy komputerowe 26
Rysunek 2.9. Model węzła sieci [29]
wpływającym na powstałe opóźnienia jest organizacja transmisji. W dostęp-
nych protokołach możemy spotkać się z następującymi rozwiązaniami:
— Producent - opcjonalnie Dystrybutor - Konsument,
— Klient - Serwer,
— Master - Slave,
— Bezpośrednie.
Implementacja protokołu może być wykonana za pomocą programu wykony-
wanego przez jednostkę centralną węzła [6, 27, 46] lub poprzez dedykowane
układy [4, 39, 38]. Implementacja protokołu jako kod programu w procesorze
jest rozwiązaniem zazwyczaj nie zalecanym, gdyż zajmuje dodatkowy czas
procesora. Drugim rozwiązaniem jest wykorzystanie dedykowanych układów
zewnętrznych (podłączanych za pomocą prostych, o niewielkim zasięgu, pro-
tokołów komunikacyjnych) lub wbudowanych układów w wykorzystywane
jednostki centralne. Połączenie procesora z koprocesorem sieci umożliwia
przyspieszenie systemu oraz obniżenie kosztów jego wykonania.
Medium transmisyjne. W zależności od wykorzystywanego protokołu ko-
munikacyjnego mamy do wyboru różne medium transmisyjne. Rozróżniamy:
— przewód miedziany - transmisja wykorzystująca zmiany prądów lub na-
pięć,
— światłowód - transmisja, w której poszczególne wartości bitowe przekazy-
wane są za pomocą sygnałów świetlnych,
— fale radiowe - odpowiednie kodowanie bitów, w częstotliwości wykorzy-
stywanego pasma radiowego.
Rozdział 2. Sieciowe systemy komputerowe 27
Niektóre protokoły umożliwiają wybranie jednego z kilku dostępnych me-
diów transmisyjnych, zależnie od zastosowanego nadajniko-odbiornika (ang.
transceiver). Jego zadaniem jest zamiana reprezentacji cyfrowej na postać
analogową podczas nadawania, a podczas odbierania interpretacji stanu łącza
i zamianie go na wartości cyfrowe.[41] W zależności od stosowanego medium
transmisyjnego, w systemie mogą występować różne czasy opóźnień związane
z transmisją danych.
Stacja operatorska. Jest to jednostka centralna wykorzystywana do wi-
zualizacji zachodzących procesów. Można ją traktować jak węzeł omówiony
w rozdziale 2.2.1 i podlegać będzie tym samym założeniom. Inną możliwością
jest wyodrębnienie jej, jako węzła o wyjątkowych cechach. Należy pamiętać,
że w węźle takim zazwyczaj wykorzystywany jest jeden z dostępnych sys-
temów operacyjnych czasu rzeczywistego. Wykorzystywany on jest jako or-
ganizator dostępu do zasobów współdzielonych, przez poszczególne procesy.
Najczęściej elementami współdzielonymi są:
— pamięć,
— ekran,
— procesor.
Do stworzenia węzła sterującego wykorzystuje się komputer klasy PC. Kom-
puter wymaga przygotowania pod kątem instalacji specjalnego systemu czasu
rzeczywistego [71] oraz oprogramowania wizualizacyjnego [12]. Dostępne są
również gotowe systemy wizualizacyjne na przykład SCADA [84]. Na tak
przygotowanej stacji uruchamiane jest oprogramowanie sterująco-kontrolne,
umożliwiające operatorowi nadzorowanie i modyfikacje sterowanych przez
dany system procesów.
Model kolejkowy
Trudno jest podczas opracowywania modelu uwzględnić wszystkie aspek-
ty. Zazwyczaj dla uproszczenia i możliwości opisania poprzez reguły matema-
tyczne, redukuje się model do elementów o największym znaczeniu. Czasami
jednak okazuje się, że gotowe modele nie uwzględniają pewnych elementów,
na które z pewnych powodów należy zwrócić uwagę. Przykładem takiego
rozwiązania jest model kolejkowy. Główny nacisk tego modelu bazuje na ana-
lizie opóźnień powstałych poprzez oczekiwanie danych na ich przetworzenie.
Rozróżnia się kolejki na następujących poziomach:
Rozdział 2. Sieciowe systemy komputerowe 28
— aplikacji; wpływ na powstałe opóźnienie może mieć na przykład równo-
czesny odczyt pomiaru z kilku czujników;
— komunikacji; reprezentuje opóźnienia powstałe w protokole komunikacyj-
nym, związane z przygotowaniem wiadomości oraz oczekiwaniem na wy-
słanie;
— dostępu do medium; wpływ na powstające opóźnienie ma wykorzystywa-
ny dostęp do medium. W zależności od protokołu na opóźnienie może mieć
wpływ priorytet wiadomości, czas oczekiwania na żeton lub przydzielone
okno czasowe.
Węzeł takiego modelu podzielony jest w sposób standardowy na oprogra-
mowanie, koprocesor sieciowy i samą sieć. Posiada jednak jeszcze elementy
pośrednie - kolejki oczekiwania. Kolejki te umieszczone są na wszystkich wej-
ściach i wyjściach danych. Zarówno poprzez urządzenia sterujące, jak i sieć.
Rysunek 2.10. Model węzła sieci [62]
Cały model składa się z poszczególnych elementów połączonych siecią.
Elementy takiego modelu nie są poddawane dokładnej analizie, formułując
je tylko jako zadania wprowadzające opóźnienia. Ze względu na współużytko-
wanie komponentów systemu, opisywane kolejki mają charakter rozkładów.
Proponowane rozwiązanie wykorzystane zostało do rozpatrywania wymiany
informacji na zasadzie: każdy-z-każdym i producent-konsument
Model cykliczny
W systemach przemysłowych, prowadzi się ciągły monitoring urządzeń
poprzez odczytywanie parametrów. Omawiany model wykorzystuje prace
w cyklu. Każdy węzeł reprezentowany jest jako pewien cykl pracy. Na niego
składają się kroki przedstawione na rysunku 2.6, rozszerzone o:
— inicjalizację cyklu,
Rozdział 2. Sieciowe systemy komputerowe 29
— komunikację z programatorem.
Wszystkie wymienione elementy dzielą czas węzła, dla którego całkowity czas
cyklu wynosi 360o. Model węzła przedstawia rysunek 2.11.
Rysunek 2.11. Cykliczny model węzła sieci [62]
Cykle poszczególnych węzłów połączone są w „makrocykl”. Całkowity
czas trwania cyklu jest sumą wszystkich mikrocylki składających się na da-
ny cykl. W modelu tym można rozróżnić wiele cykli pracy, uwzględniając
dla każdego makro cyklu udział innych węzłów, a nawet innych mikro cykli
węzłów występujących. Ogólny schemat działania przedstawia rysunek 2.12.
2.3. Wybrane parametry sieci komputerowych
Jak już wspomniano jednym z kluczowych elementów systemu jest sieć
komputerowa. Początkowo sieci wprowadzono w celu połączenia wielu kom-
puterów w system komunikacji niedeterministycznej - wymiany dokumen-
tów i usług. Rozwój tej technologii obfitował w wiele różnych rozwiązań.
Aby ujednolici opis wszystkich protokołów komunikacyjnych stworzono mo-
del dzielący cały mechanizm na poszczególne zadania - warstwy. Dzięki temu
możliwe jest porównywanie i prezentację działania wszystkich metod komu-
nikacji za pomocą jednego modelu referencyjnego - modelu OSI.
Zachowanie sieci jest zdeterminowane przez wiele czynników między in-
nymi: dostęp do łącza, organizację transmisji oraz topologię sieci. Każde roz-
wiązanie korzysta z innego zestawu tych elementów, które w połączeniu z
możliwościami uzyskanymi przez implementacje poszczególnych warstw OSI,
Rozdział 2. Sieciowe systemy komputerowe 30
Rysunek 2.12. Cykliczny model węzła sieci [62]
Rozdział 2. Sieciowe systemy komputerowe 31
dają różne wartości parametrów transmisji. Inne są też ceny poszczególnych
elementów, niezbędne do stworzenia interfejsu sieciowego. Literatura podaje
kilka kroków koniecznych do dobrania odpowiedniego protokołu [30, 70]:
— klasyfikacja sieci względem specyfiki ruchu,
— określenie wymogów czasowych transmisji,
— określenie sprawności i przepustowości protokołu.
2.3.1. Dostęp do łącza
W zależności od łącza danych, architekt systemu zmuszony jest dopaso-
wać się do możliwości i technicznych ograniczeń danego protokołu. Metody
dostępu do łącza można podzielić na deterministyczne i niedeterministyczne
[30]. Za deterministyczne uważane są te, w których każdy węzeł ma zagwa-
rantowany dostęp do medium (TDMA, Token Passing). Niedeterministyczne
natomiast to protokoły, w których czas realizacji któregokolwiek zadania mo-
że być niemożliwy do oszacowania. Głównie problem ten występuje przy me-
todzie współzawodniczenia w dostępie do medium (CSMA) [7]. Wspomniane
metody charakteryzują się:
1 Metoda wielodostępu z podziałem czasu (ang. TDMA). W metodzie tej
każdy węzeł ma przydzielony czas transmisji, tzw. okno czasowe. Na ba-
zie tego protokołu zbudowano systemy wymiany informacji z krążącym
żetonem (ang. Token),
2 Metoda wielodostępu z wykrywaniem nośnej (ang. CSMA). Metoda bar-
dzo popularna głównie za sprawą sieci Ethernet. Jest to protokół złożony
wymagający stosowania skomplikowanych algorytmów rozstrzygania mo-
gących się pojawiać kolizji. Stosując metodę CSMA można spotkać się
z jedną z dwóch metod jej rozstrzygnięcia: poprzez jej wykrycie (CSMA-
/CD) lub uniknięcie (CSMA/CA). Sieci oparte na protokole CSMA cha-
rakteryzują się [51]:
— małymi opóźnieniami przy niskim obciążeniu,
— wysokim wykorzystaniem przepustowości przy dużym obciążeniu,
— dużymi opóźnieniami przy dużym obciążeniu łącza.
2.3.2. Parametry transmisji
Aby dokonać odpowiedniego wyboru sieci do zastosowań lub umożliwić
stworzenie matematycznego opisu sieci stosowanego następnie w modelach
niezbędne jest określenie jej wymagań za pomocą pewnych parametrów. Mu-
Rozdział 2. Sieciowe systemy komputerowe 32
szą one dotyczyć zarówno zasięgu takiej sieci jak i szybkości przesyłania,
i czasu dostarczenia wiadomości. Istnieje przynajmniej kilka najczęściej wy-
korzystywanych parametrów:
— czas propagacji(ang. latency),
— zmienność (ang. jitter),
— przepustowość (ang. bandwidth),
— prędkość Transmisji (ang. bit rate),
— opóźnienie (ang. delay),
— obciążenie (ang. utilization),
— sprawność.
Ich liczba związana jest ze złożonością procesu, który próbują opisać. Jednym
z kluczowych parametrów nie występujących w powyższym wyliczeniu jest
odległość o jaką mogą być oddalone węzły. Jednak celem tego podrozdziału
jest przedstawienie parametrów samej transmisji. Ich wartości bywają bez-
pośrednio zależne albo od maksymalnej długości medium, albo zależne od
aktualnie wykorzystywanej długość.
Wartości reprezentujące poszczególne parametry opisują: cechy fizyczne
łącza (czas propagacji i przetwarzania sygnału), topologie i organizacje do-
stępu do łącza oraz budowę i złożoność samego algorytmu.
Poza popularnymi (standardowymi) parametrami, opracowywane są pa-
rametry mające na celu umożliwienie dodatkowego porównania protokołu dla
specyficznych wymagań. Przykładem takiego parametru jest rezerwa czasowa
(podrozdział 2.3.2).
Opóźnienie
Bardzo często przy omawianiu sieci komputerowych zamiennie stosuje się
nazwy Latency i Delay. Oba wyrazy oznaczają opóźnienie. Wydaje się, że
stosowanie ich zamiennie nie jest stosowne. Na podstawie spostrzeżeń i za-
stosowań poszczególnych słów w literaturze, Latency powinno być rozumiane
jako opóźnienie powstałe przez czas propagacji. Wartość tę opisują zjawiska
fizyczne. Mogą one dotyczyć medium transmisyjnego jak i sygnału przetwa-
rzanego przez układy cyfrowe.
Delay natomiast jest to całkowite opóźnienie powstałe podczas transmisji.
Zależnie od analizowanej wymiany może dotyczyć ruchu pakietu w jednym
kierunku lub uwzględniać również czas odpowiedzi. Wpływ na nie ma wiele
składników: czas propagacji, oczekiwanie w kolejce, przetwarzanie informacji
oraz czas transmisji. Przykładem aplikacji mierzącej całkowite opóźnienie
Rozdział 2. Sieciowe systemy komputerowe 33
(Di) jest ping. Opóźnienie to można wyznaczyć na podstawie wzoru 2.6:
Di = Tei − Tsi (2.6)
gdzie: Tei jest to czas zakończenia odbierania ramki przez odbiorcę, a Tsi jest
to czas rozpoczęcia procesu nadawania wiadomości. Dla wymiany uznanej
jako przesłanie pojedynczego pakietu informacji na poziomie warstwy łącza
danych, za matematyczną metodę wyznaczenia opóźnienia można przyjąć
wzór 2.5, przyjmując τF , τT i τV równe 0.
Di = τR + τP (2.7)
Zmienność
Podczas każdej wymiany komunikatów występują odchylenia (Ji). Odchy-
lenie to jest wyznaczane jako różnica w czasie dostarczenia wiadomości i od
wartości średniej (wzór 2.8 [86]). Wartość tego odchylenia zależy od wielu
czynników takich jak: sposób dostępu do łącza czy przepustowość.
Ji = Davg −Di (2.8)
Jmax = Davg −Dmaxi (2.9)
gdzie:
Di - wartość opóźnienia dla i-tej transmisji,
Davg - wartość średnia opóźnienia,
Dmaxi - wartość najbardziej odbiegająca od średniej.
Zmienność (Jmax) jest to najgorsza wartość odchylenia jaka może wystąpić
lub jaka wystąpiła (wzór 2.9). Oznacza jednocześnie poziom nieprzewidy-
walności łącza, co w przypadku sieci przemysłowych ma ogromne znaczenie.
Tworząc systemy dąży się do zminimalizowania wartości tego parametru.
Prędkość transmisji
Prędkość transmisji jest jednym z kluczowych parametrów. Jest to liczba
bitów przesyłanych przez medium transmisyjne w jednostce czasu. Zazwy-
czaj jednostką jest bit/sec. Zdarza się jednak podawanie prędkości transmisji
w bodach.
Bod jest to pojedynczy stan łącza. Rozróżnienie takie występuje, gdyż
w wielu przypadkach bod odpowiada jednemu bitowi, jednak są protokoły
komunikacyjne (np. komunikacja modemowa), które w jednym bodzie mogą
przenosić informację zawartą na kilku bitach.
V =liczba bitów
czas transmisji(2.10)
Rozdział 2. Sieciowe systemy komputerowe 34
Przepustowość i wydajność
Pasmo transmisji jest to maksymalna liczba bitów jaka może zostać prze-
słana przez łącze. Jest to wartość możliwa do osiągnięcia tylko przy idealnych
warunkach transmisji. Średnią liczbę bitów przesyłaną przez łącze określa się
mianem wydajności (ang. throughput).
Obciążenie
W sieci CSMA bardzo ważne jest obciążenie, gdyż w zależności od tego
parametru, kształtuje się między innymi czas oczekiwania na dostęp do łącza
[51]. We wszystkich omawianych modelach systemu komputerowego parametr
ten był uwzględniany, albo jako jeden z elementów systemu wymiany komuni-
katów (podrozdział 2.2.1), albo (np. w systemie kolejkowym) przedstawiony
za pomocą czasu oczekiwania wiadomości w kolejce wiadomości do nadania.
U =Wydajność
Pasmo Transmisji(2.11)
Sprawność
Sprawność jest jednym parametrów uzupełniających informacje o przepu-
stowości kanału. Wartość tego parametru wyraża nadmiar informacji wystę-
pujący przy przesłaniu wiadomości pomiędzy stacjami. Matematyczny zapis
tego parametru wyraża wzór 2.12.
µ =Liczba bitów informacyjnych
Całkowita liczba bitów(2.12)
W zależności od sposobu komunikacji, wartość sprawności może być wyli-
czona dla jednej ramki (gdy do przesłania informacji wymagana jest poje-
dyncza ramka) lub szeregu wymienionych pomiędzy węzłami ramek. W dru-
gim przypadku Całkowita liczba bitów reprezentować będzie sumę wszyst-
kich przetransmitowanych znaków (bitów wszystkich ramek niezbędnych do
zrealizowania wymiany informacji). Prowadzone badania dotyczyły warstwy
łącza danych, dlatego wartość sprawności wyznaczana jest z pominięciem roz-
ważań dotyczących sposobu wymiany i potwierdzania odebrania informacji.
Z tego względu pozwolono sobie zastosować rozwiązanie opisujące szczególny
przypadek sprawności zdefiniowany za pomocą wzoru 2.13 [42, 31]. Często
tak zdefiniowana sprawność nazywana jest również narzutem protokołu.
µ =LDataLFrame
(2.13)
gdzie: LData - liczba bitów danych,
LFrames - całkowita liczba bitów związanych z dostarczeniem wiadomości.
Rozdział 2. Sieciowe systemy komputerowe 35
Rezerwa czasowa
W celu oceny systemu przemysłowego nie wystarczą standardowe para-
metry. Opracowywane są dodatkowe wskaźniki, umożliwiające lepszą ocenę
możliwości dotrzymania wymogów czasowych. Jednym z takich wskaźników
jest względna rezerwa czasowa [16]. Jest to czas o jaki może zostać wydłu-
żone jedno zadanie τx przy zachowaniu ograniczenia czasowego innego τi,
wybranego zadania. Wskaźnik ten wyznacza się poprzez poszukiwanie ilości
czasu jaka zostaje do wykorzystania pomiędzy kolejnymi wymianami - rezer-
wa czasowa (ang. spare capacity). W celu zastosowania tej metody musi być
spełnionych kilka warunków:
— połączenie magistralowe,
— dostęp do łącza na zasadzie priorytetów,
— zadanie τx musi mieć wyższy priorytet od zadania τi.
Aby wyznaczyć wartość globalną, nie zaburzającą żadnego z zadań o niż-
szym priorytecie, należy wyznaczyć współczynnik ten dla wszystkich zadań
τi, a następnie wybrać wartość najmniejszą.
2.4. Podsumowanie
W rozdziale 1 przedstawiono problematykę dotyczącą wybranej grupy
protokołów przemysłowych, poruszanych w rozprawie doktorskiej. Aby przy-
bliżyć problematykę, której praca dotyczy, w tym rozdziale przedstawiono
definicję i podział systemów wykorzystujących badane protokoły. Następnie
dla konkretnego już systemu zaprezentowano spotkane w literaturze teore-
tyczne modele jego podziału. Podczas omawiania modeli systemów kompu-
terowych wskazano różne spojrzenia na zachodzące w nich zjawiska wpły-
wające na czas cyklu, oraz przedstawiono znaczenie sieci dla całkowitego
czasu trwania cyklu pojedynczego układu pomiarowego (węzła) jak i całego
systemu. Na tej podstawie można stwierdzić, że często dystrybucja informa-
cji stanowi słaby punkt systemu. Wynika to z ograniczeń fizycznych tego
elementu (długość medium, czas propagacji czy przepustowość kanału trans-
misyjnego). Na podstawie analizy tych modeli można wyciągnąć wniosek, iż
uzyskanie nawet nieznacznej poprawy parametru jakim jest opóźnienie, może
przełożyć się na znaczną poprawę czasu trwania całego cyklu. Bierze się to z
tak zwanego efektu skali, czyli z wielokrotnego występowania pojedynczego
zdarzenia (np: komunikacji), dzięki czemu pozornie niewielkie różnice prze-
kładają się na duże korzyści. Wnioski wyciągnięte z analizy przedstawionych
Rozdział 2. Sieciowe systemy komputerowe 36
modeli stanowiły jeden powodów zwrócenia uwagi na efektywność protokołów
wykorzystujących mechanizm wstawek bitowych.
Poszukiwanie metod badawczych, doprowadziło do ogólnie znanych i sto-
sowanych podczas modelowania zjawisk zachodzących w systemach kompute-
rowych sieci Petriego lub coraz popularniejszych modeli zapisanych w języku
UML. Jednak rozpatrywanie poprawy parametrów na poziomie warstwy łą-
cza danych, wykluczyły te metody do zastosowania w procesie oceny i popra-
wy protokołów, ze względu na brak jakichkolwiek matematycznych wzorców
opisujących parametry zmienionego środowiska. Dlatego uznano że lepszym
rozwiązaniem będzie bezpośrednie modelowanie zachodzących zjawisk na wy-
branej grupie danych.
Rozdział 3
Mechanizm działania i metody
wyznaczania liczby wstawek bitowych
Od dawna w wielu tworzonych i stosowanych protokołach można spo-
tkać się z zastosowaniem mechanizmu dodawania kolejnych bitów, który nosi
miano wstawek bitowych. Zasada działania tego mechanizmu jest bardzo pro-
sta. Mechanizm ten, polega na umieszczeniu w transmitowanym strumieniu
danych, przez warstwę łącza danych, bitów dodatkowych. Celem tych dodat-
kowych bitów jest uniknięcie na łączu szeregu niepożądanych bitów. Może
to dotyczyć elementu sygnalizacyjnego (ramka błędu, sygnalizacja kolizji,
flaga początku lub końca transmisji) ale także wiązać się to może z zachowa-
niem synchronizacji węzłów, czyli dopasowaniem liczników czasu odbiorców
z nadawcą. W zależności od specyfikacji protokołu i celu w jakim go zastoso-
wano istnieje możliwość jego wykorzystania przy wystąpieniu ciągu wartości
pojedynczego stanu (samych jedynek lub zer - protokoły HDLC i USB) lub
obu stanów (CAN). Odbiorcy znając algorytm postępowania dokonują ope-
racji odwrotnej i usuwają z odczytanego strumienia bity, wartości których
były efektem działania omawianego algorytmu po stronie nadawczej.
Rysunek 3.1. Przykład wstawiania i usuwania bitów w celu uniknięcia wystąpienia
„1111”
Ponieważ odbiorca w trakcie usuwania wstawek traktuje odbierany ciąg
informacji jako poprawny, może zdarzyć się przypadek w którym błędnie za-
kwalifikuje jakiś bit jako wstawiony lub pominie bit rzeczywiście dodany. Mi-
mo możliwości wystąpienia takiego błędu, zazwyczaj jest on wykrywany albo
na poziomie warstwy łącza danych ramki (wystąpienie ciągu niedozwolonego
Rozdział 3. Mechanizm działania i metody wyznaczania... 38
lub niepoprawnej długości ramki), albo na poziomie logicznym (wartości pól
przetworzonej ramki przyjmują błędne wartości), lub dzięki sumie kontrolnej
która zwróci wartość błędną.
Rysunek 3.2. Powstanie błędu blokowego po przekłamaniu dwóch bitów [10].
Już w 1994 opisano pojawiające się podwyższenie ryzyka powstania błędu
niewykrytego. Jako jeden z pierwszych, w odniesieniu do sieci przemysłowych
z wstawkami bitowymi, poruszył to Joachim Charzinski [10]. Zauważył on
możliwość powstania błędu blokowego (przekłamania grupy bitów), jedynie
przy zmianie wartości na dwóch pozycjach (rysunek 3.2).
Szerzej zagadnieniami bezpieczeństwa, w tym tematyką błędów związa-
nych z wstawkami bitowymi, omówiono prowadząc analizy poziomu bezpie-
czeństwa sieci CAN [74]. W podsumowaniu przedstawiono, iż najbardziej na
przekłamania niewykryte ramka jest podatna wtedy gdy wystąpi od 2 do 13
błędów (rysunek 3.3).
Zaproponowano również rozszerzenie zabezpieczeń o dodatkowe sumy kon-
trolne umieszczane w polu danych. Autor w przytoczonej pracy nie poddał
badaniom wpływu zmniejszenia liczby wstawek bitowych, na poziom wykry-
wania błędów.
Mechanizm wstawek bitowych ma na celu realizację jednej z dwóch funk-
cji:
— synchronizacji węzłów (np.: USB, CAN),
— zapewnienia przeźroczystości protokołu (np.: HDLC, CAN).
W systemach rozproszonych wymagana jest synchronizacja, gdyż bardzo
trudno jest stworzyć oraz dopasować zegary taktujące, tak aby pracowały
z tą samą szybkością (generowały zmiany stanów z tą samą częstotliwością).
Rozdział 3. Mechanizm działania i metody wyznaczania... 39
Rysunek 3.3. Prawdopodobieństwo niewykrycia błędu w zależności od liczby po-
wstałych przekłamań [74].
Dodatkowo na pracę układów taktujących ma również wpływ temperatura
oraz poziom napięcia, który może być różny na każdym z układów biorących
udział w transmisji. W przypadku protokołów zespolonych (przesyłających
dane i synchronizację za pomocą wspólnego sygnału) węzeł nadawczy z od-
biorcami synchronizuje się stosując zazwyczaj jedno ze zboczy (np. przejście
ze stanu 1 na 0) występujące w przesyłanej informacji. Może się jednak zda-
rzyć sytuacja, w której nadawca będzie musiał przesłać informację reprezen-
towaną na łączu jako długi ciąg wartości jednego stanu. Wtedy przez cały
ten czas synchronizacja nie nastąpi. Efektem tego może być błędna interpre-
tacja nadawanych stanów - odczytanie zbyt dużej liczby bitów (dołożenie)
lub mniejszej liczby bitów (zgubienie). Aby temu zapobiec jedną z metod
jest zastosowanie właśnie wstawek bitowych - wymuszanie wstąpienia zmia-
ny stanu, co pewną maksymalną liczbę bitów. Na tej podstawie wylicza się
również maksymalne dopuszczalne różnice w szybkości pracy stosowanych
zegarów.
3.1. Metody wyznaczania wartości najgorszych
W niektórych protokołach wykorzystuje się pewne kombinacje bitów do
sterowania przepływem informacji w łączu (np.: sygnalizacja początku lub
końca transmisji). Aby taka kombinacja bitów nie wystąpiła w środku ram-
ki, stosuje się różne mechanizmy: wstawki bitowe, odstępy bajtowe [24] lub
zmiany kodowania informacji (np.: kodowanie ASCII protokołu MODBUS)
[40]. Każda metoda dokłada na poziomie warstwy łącza danych dodatkowe
Rozdział 3. Mechanizm działania i metody wyznaczania... 40
informacje (nadmiarowość), zamieniając poszczególne porcje danych (całą
informacje lub tylko wybrane kombinacje) w dłuższe ciągi bitowe. Dzięki
temu uzyskujemy gwarancję wykonania poprawnej transmisji.
3.1.1. Metoda wykorzystująca algorytm postępowania
Każda z metod wnosi pewną nadmiarowość, a więc i zajmuje pewną część
czasu transmisji ramki. Wyznaczenie liczby wstawek dla poszczególnych ra-
mek jest niezmiernie trudne, ze względu na dużą zależność od przesyłanego
strumienia danych, a jeden bit jest w stanie znacząco wpłynąć na liczbę
ich wystąpień. Dlatego większość prowadzonych badań opiera się o wartości
eksperymentalne. Matematycznie jedynie da się wyznaczyć wartości brze-
gowe (pesymistyczne), nie ma jednego wzoru do wyznaczenia maksymalnej
liczby takich wystąpień, a wszystko zależy od specyfikacji protokołu. Gdy
zabezpieczamy przed wystąpieniem jednego wzorca (tylko ciągu jedynek lub
zer),np.: protokół USB, wystarczy że długość zabezpieczanego ciągu (n - licz-
ba bitów) podzielimy przez długość ciągu niedozwolonego (m) pomniejszoną
o 1 (wzór 3.1).
BS1pes =
⌊n
m− 1
⌋(3.1)
Inaczej jest gdy chcemy wyznaczyć wartość pesymistyczną dla algorytmu
stosującego zabezpieczenie zarówno przed wzorcem składającym się z samych
zer jak i jedynek (np.: CAN). Wtedy nie można skorzystać ze wzoru 3.1, ale
trzeba uwzględnić że wstawka bitowa może być pierwszym bitem nowego
niedozwolonego wzorca (wzór 3.2).
Rysunek 3.4. Przykłady strumieni danych, powodujących wstawienie największej
liczby wstawek ( a) przy ochronie przed jednego rodzaju wstawkami, b) przy ochro-
nie przed oboma rodzajami wstawek)
BS2pes =
⌊n− 1m− 2
⌋(3.2)
Uzyskiwane w ten sposób wartości dla poszczególnych protokołów po-
trafią być znaczące, co dokładnie można zauważyć w dokumentacji proto-
kołu USB. Zwraca on uwagę na narzut związany z zastosowaniem wstawek
Rozdział 3. Mechanizm działania i metody wyznaczania... 41
bitowych [75, 18]. We wzorach na całkowitą długość ramki uwzględnia się
długość pola danych ze współczynnikiem 1,1667, co stanowi (7/6). Ten sam
współczynnik dla sieci CAN wynosi już 1,25 (5/4) oraz w sieci HDLC 1,20
(6/5).
3.1.2. Własna metoda obliczeniowa
Jednak przedstawione wartości są uzyskane za pomocą zgrubnego oszaco-
wania (dającego gwarancję nie przekroczenia uzyskanej wartości). Problem
jest z oszacowaniem rzeczywistej wartości pesymistycznej i średniej. Gdy me-
chanizm wstawek bitowych zabezpiecza strumienie o dowolnej zawartości, to
wyznaczona wartość za pomocą podanych wzorów 3.1 i 3.2 jest popraw-
na. W momencie gdy w skład obszaru chronionego wchodzą elementy stałe
albo o ograniczonym zakresie wartości (jak na przykład nagłówek), warto-
ści rzeczywiste mogą odbiegać od uzyskiwanych wartości pesymistycznych
(być mniejsze czyli korzystniejsze). Dla takich przypadków można wykonać
dokładne wyliczenia badając wszystkie ramki. Rozwiązanie to jednak jest
bardzo czasochłonne. Dlatego analizując działanie tego mechanizmu posta-
nowiono opracować metodę dokładniejszego oszacowania (przybliżenia się do
wartości rzeczywistych), dzieląc ów obszar na kilka części (rysunek 3.5). Jed-
nocześnie ze względu na budowę i szczególny charakter nagłówka może się
okazać, że nie wystąpią w nim wartości powodujące powstanie najgorszego
przypadku.
Rysunek 3.5. Przykładowy podział ramki na część nagłówka, pola danych i sumy
kontrolnej.
Zaletą tej metody jest możliwość wyznaczenia liczby wstawek bitowych
dla poszczególnych elementów, za pomocą przebadania: wszystkich możli-
wych ciągów, losowego zbioru ramek, a następnie wstawienie uzyskanych
rezultatów do odpowiedniego wzoru 3.3 lub 3.4 [43].
BS1pes =
⌊CNagłówek +RNagłówek + CDane +RDane + CCRC +RCRC
m− 1
⌋
(3.3)
Rozdział 3. Mechanizm działania i metody wyznaczania... 42
BS2pes =
⌊CNagłówek +RNagłówek + CDane +RDane + CCRC +RCRC − 1
m− 2
⌋
(3.4)
Przy każdym podziale takiego obszaru należy sprawdzić czy nie spowo-
duje on straty jednej wstawki bitowej, z powodu braku oddziaływania bitów
z jednej części na drugą (co ma miejsce w rzeczywistych warunkach).
Rysunek 3.6. Przykładowy podział ramki na część nagłówka, pola danych i sumy
kontrolnej.
Można to wykonać sprawdzając czy suma reszt z dzielenia (Rx) po po-
dzieleniu przez długość ciągu po którym występuje wstawka, pomniejszona
o 1, i zaokrągleniu w dół da wynik większy od zera (odpowiednio wzór 3.5
i 3.6).
BS1Corr =
⌊RNagłówek +RDane +RCRC
m− 1
⌋(3.5)
BS2Corr =
⌊RNagłówek +RDane +RCRC − 1
m− 2
⌋(3.6)
Podobne rozwiązanie można zastosować dla wartości średnich, zamienia-
jąc reguły dotyczące wartości pesymistycznych na wartości średnie. W tym
przypadku również należy zastanowić się czy lub jak podział wpłynie na
uzyskiwane rezultaty. Przykładem zastosowania takiego podziału jest wy-
znaczenie wartości średnich dla ramek sieci CAN [44].
3.2. Wykorzystanie metod wyznaczania wstawek
bitowych
Przedstawiona metoda może być przydatna przy wyznaczaniu niektó-
rych parametrów sieciowych dla protokołów stosujących mechanizm wstawek
np: opóźnienie czy zmienności transmisji. Przydatna może okazać się również
Rozdział 3. Mechanizm działania i metody wyznaczania... 43
do oceny protokołu, gdyż wartość pesymistyczna może występować bardzo
rzadko lub w ogóle. Sprawność pojedynczej ramki wyznacza się jako:
µBS =Długość pola danych
Całkowitą długość ramki + Wstawki bitowe(3.7)
Natomiast opóźnienie jest różnie rozumiane. Można wyznaczyć opóźnienie
jako czas trwania wysłania komunikatu liczony od momentu zgłoszenia chęci
jej nadania do czasu zakończenia odczytywania informacji. Ponieważ w tej
definicji na opóźnienie składa się kilka elementów: czas dostępu do łącza,
czas transmisji i opóźnienie tam powstałe (na łączu, urządzeniach pośredni-
czących) oraz czas samej transmisji, to wskazanie wpływu wstawek bitowych
na ten proces jest bardzo trudne. Dlatego bardzo przydatne jest porównanie
takiego opóźnienia, w którym pominięte zostaną inne czynniki, a więc czas
samej transmisji (3.8).
Di =Całkowitą długość ramki + Wstawki bitowe
Prędkość transmisji+ Czas opóźnienia łącza
(3.8)
Ostatnim zaproponowanym parametrem jest maksymalne odchylenie od war-
tości średniej czasu transmisji (zmienność). Aby ją wyznaczyć dla danej wy-
miany od wartości średniej opóźnienia należy odjąć wartość dla danej wy-
miany.
Ji = |Davg −Di| (3.9)
Uwzględniając jako jedyny czynnik zmienności - wstawki bitowej - można
wyznaczyć zmienność jako:
Jmax =
∣∣∣BSavg−BSmaxv
∣∣∣∣∣∣BSavgv
∣∣∣(3.10)
gdzie: v oznacza prędkość transmisji.
Ponieważ uzyskiwane współczynniki są znaczące, prowadzi się szereg ba-
dań dotyczących wpływu wstawek bitowych w poszczególnych rozwiązaniach.
Poczynając od modelowania tego mechanizmu za pomocą sieci Petriego [20]
przez złożone analizy wpływu ich występowania na przepustowość, do metod
ograniczenia ich występowania, bez konieczności modyfikacji ramki. Przykła-
dami prowadzonych analiz jest zarówno publikacja dotycząca obciążenia sieci
USB [18], jak i analizy dotyczące na przykład sieci CAN [74]. W protokole
CAN ma to ogromne znaczenie ze względu na swój przemysłowy charakter
i wymagania czasowe jakie przed tą siecią są stawiane. Jednocześnie prowa-
dzone są prace nad poprawą (zmniejszeniem) liczby występujących wstawek
Rozdział 3. Mechanizm działania i metody wyznaczania... 44
bitowych. Znaczenie redukcji liczby wstawek bitowych wskazują prowadzone
badania analityczne przedstawione w artykule opublikowanym w 2005 ro-
ku [5]. W artykule tym, wykazuje się możliwość poprawy średniego rozkładu
liczby wstawek bitowych poprzez rozszerzenie tego mechanizmu o mechanizm
przestawiania bitów (ang. bit flipping).
Przedstawione informacje wskazują, że zarówno środowiska twórców pro-
tokołów jak i naukowców coraz większą wagę przykładają do znaczenia wsta-
wek bitowych, coraz obszerniej zajmując się tym problemem podczas oceny
protokołu. Z tego względu każdy, kto chce skorzystać z sieci wykorzystującej
omawiany mechanizm, musi zrozumieć jego działanie nie tylko dla ogólnego
przypadku, ale także w odniesieniu do konkretnej implementacji.
Rozdział 4
Przykłady metod skracania czasu
transmisji komunikatów stosowanych
w sieciach stosujących wstawki bitowe
Gdy twórca systemu nie jest w stanie zrealizować potrzebnej wymiany
- zapewnienie odpowiednich parametrów transmisji - niezbędne jest szuka-
nie możliwych „oszczędności” czasu lub zwiększenia pasma. „Oszczędność”
czasu jest to szukanie rozwiązań skracających pojedynczy czas wymiany dla
zrealizowania postawionego celu. Jest to zadanie trudne, ingerujące zazwy-
czaj w cały projekt, wymagające wielu zmian. Rozszerzenie pasma jest zada-
niem prostszym. Można je zrealizować albo poprzez zmianę protokołu trans-
misyjnego albo poprzez podział fizycznego medium na mniejsze segmenty.
Dla zrealizowania wymiany deterministycznej w pewnych rodzajach aplika-
cji (np.: w samochodach) stosuje się kilka oddzielnych sieci, z podłączoną
różną liczbą węzłów - zależnie od dopuszczalnych opóźnień (rysunek 4.1).
Modyfikacje warstwy fizycznej mogą polegać również na zmianie medium
Rysunek 4.1. Schemat sieci w samochodzie Volkswagen Passat [14]
Rozdział 4. Przykłady metod skracania czasu transmisji... 46
transmisyjnego na takie, które pozwala przesyłać więcej danych. Innym roz-
wiązaniem jest zmiana kodowania informacji, lub zwiększenie szybkości jej
nadawania. Dwie ostatnie zmiany często wiążą się ze zmianami protokołu.
W warstwach pośrednich istnieje zazwyczaj ograniczona możliwość po-
prawy wydajności, ze względu na konieczność zgodności z przyjętym stan-
dardem. Dopiero w „warstwach wysokich” (aplikacji) można bez ograniczeń
próbować poprawiać wydajność.
4.1. Metoda zmiany struktury sieci
Literatura opisuje kilka możliwych rozwiązań zwiększających maksymal-
ną liczbę przesłanych informacji. Są to rozwiązania bazujące na topologii lub
organizacji transmisji. Rozwiązania te próbują ominąć różne ograniczenia
sieci magistralowej. Jedna z propozycji zrównoleglenia transmisji została na-
zwana FastCAN [9], gdzie każdy węzeł posiada dwa jednokierunkowe kanały.
Jeden z nich (Forward Channel) jest kanałem arbitrażowym. W nim odbywa
się wyłanianie nadawcy. Natomiast drugi kanał (Reverse Channel) służy wy-
łącznie do przesyłania danych. Kierując się doświadczeniami z rozwojem sieci
Ethernet podejmuje się próby zwiększenia pasma poprzez zastosowanie kon-
centratora (ang. hub) sieci [6], dzieląc całą sieć na segmenty. Jego głównym
celem jest zazwyczaj poprawa odporności na uszkodzenia, ale jednocześnie
uzyskuje się możliwość jednoczesnego nadawania przez kilka węzłów. Popra-
wa dotyczy głównie uszkodzeń węzłów oraz przerwania lub zwarcia medium.
Opracowanie takiego urządzenia dostarczyło jednak wielu problemów oraz
wprowadziło nowe niebezpieczeństwo związane z uszkodzeniem samego kon-
centratora, co grozi całkowitym zatrzymaniem komunikacji w sieci.
Do odciążenia sieci głównej projektuje się również inne, tańsze rozwią-
zania tzw. podsieci (dla sieci CAN jest prosty protokół LIN [28]) lub opra-
cowanie rozwiązań mających zastąpić obecne protokoły (np. FlexRay). Fla-
xRex został opracowany jako szybszy i wydajniejszy protokół (pozwalający
przesłać większą liczbę danych). LIN natomiast zaprojektowany został jako
podsieć sieci CAN. W założeniach tego protokołu była prostota działania,
niewielka prędkość oraz zgodność długości pola danych z ramką CAN.
Rozdział 4. Przykłady metod skracania czasu transmisji... 47
4.2. Metoda minimalizacji długości ramek
W sieciach komputerowych wykorzystujących mechanizm wstawiania bi-
tów, wpływ na długość całkowitą ramki mają wartości pól zabezpieczonych
przez ten mechanizm. Redukcja liczby bitów nadmiarowych możliwa jest po-
przez wykorzystywanie takich wartości, które w jak najmniejszym stopniu
skutkują wystąpieniem niepożądanych ciągów bitów. Dla przykładu w pro-
tokole, wykorzystywanym jako model sieci z wstawkami, możliwa jest reduk-
cja liczby wstawek bitowych poprzez dobór identyfikatorów wiadomości oraz
dopasowanie pola danych.
Najlepszym rozwiązaniem, w celu redukcji wstawek bitowych z pozio-
mu aplikacji [48], okazało się przemieszanie przesyłanych danych. Aby tego
dokonać zastosowano na obszarze danych funkcję eXlusiveOR, przyjmując
jako drugi parametr funkcji ciąg naprzemiennych zer i jedynek. W ten spo-
sób uzyskano znaczną redukcję występowania wstawek bitowych. Uzyskane
wyniki uzasadniono częstym występowaniem długich ciągów jednakowych
bitów (zer), wynikający z przesyłania niskich wartości na długich polach
danych. Rezultaty przeprowadzonych eksperymentów przedstawia rysunek
4.2. W podsumowaniu autorzy wskazują na znaczenie unikania wstawek bi-
towych, a maska w metodzie XOR dobrana musi zostać do przesyłanych
danych.
Rysunek 4.2. Porównanie liczby bitów wstawionych w ramkę z 8 bajtowym polem
danych.[14]
Przebadano również liczbę bitów wstawianą w nagłówek, a wyniki przed-
Rozdział 4. Przykłady metod skracania czasu transmisji... 48
stawiono w tabelach 4.1 i 4.2. Identyfikatory podzielono ze względu na liczbę
bitów wstawionych, dla danego typu ramki.
Liczba bitów wstawionychLiczba bajtów danych
0 1 2-3 4-7 8
0 0 0 0 745 1131
1 1332 1436 1490 1005 765
2 634 560 520 279 145
3 81 51 38 19 7
4 1 1 0 0 0
Tabela 4.1. Podział liczby nagłówków ze względu na liczbę bitów wstawionych dla
ramek CAN 2.0A. [48]
Liczba bitów wstawionychLiczba bajtów danych
0 1 2-3 4-7 8
0 0 0 0 15,09 22,91
1 26,98 29,98 30,18 35,60 38,67
2 40,09 40,74 41,03 31,49 26,59
3 24,01 22,65 21,94 13,93 9,62
4 7,49 6,44 5,93 3,39 1,97
5 1,31 1,00 0,86 0,46 0,23
6 0,13 <0,01 0,06 0,03 0,01
7 0,01 <0,01 <0,01 <0,01 <0,01
8 <0,01 <0,01 <0,01 <0,01 <0,01
9 <0,01 0 0 0 0
Tabela 4.2. Procentowy podział liczby nagłówków ze względu na liczbę bitów wsta-
wionych dla ramek CAN 2.0B. [48]
W dostępnej literaturze przedstawiono możliwość ograniczenia liczby wsta-
wek poprzez odpowiedni dobór identyfikatora (tabele 4.1 i 4.2). Wyniki do-
tychczasowych badań nagłówka wskazują wpływ niektórych elementów, wy-
łączając identyfikator, na liczbę wstawek bitowych. Szczególnie zastanawia-
jąca jest przyczyna występowania pewnych typów ramek, dla których nie ma
ani jednego identyfikatora nie powodującego wystąpienia w nagłówku wsta-
wek bitowych. Na tej podstawie autor niniejszej pracy uznał że istnieją inne
pola w nagłówku będące odpowiedzialne za pojawianie się wstawek, a nie
Rozdział 4. Przykłady metod skracania czasu transmisji... 49
tylko badane przez autorów publikacji identyfikatory. Rezultatami poczynio-
nych obserwacji jest opracowanie kilku modyfikacji (rozdział 6) w warstwie
łącza danych (dotyczących nagłówka) mających na celu zmniejszenie w nim
występujących liczby wstawek, a w rezultacie poprawienie parametru jakim
jest sprawność ramki.
Tworzenie i stosowanie różnych metod umożliwiających zwiększenie licz-
by wymian informacji pomiędzy układami, jest sygnałem informującym o ist-
nieniu potrzeby przesyłania większych porcji informacji uzyskiwanych po-
przez opracowywanie kolejnych usprawnień.
Rozdział 5
Własna metoda oceny i ograniczenia
liczby wstawek bitowych
Przeprowadzona analiza literaturowa, wykazała duże zainteresowanie te-
matyką ograniczania liczby wstawek bitowych. Przedstawione w rozdziale 4
metody są rozwiązaniami operującymi na zmianach w budowie fizycznej sie-
ci, logicznej lub konfiguracji protokołu. Wymaga więc od użytkownika dużej
wiedzy z zakresu zachowania się wykorzystywanych ramek. Dodatkowo każde
rozwiązanie dodawane do warstwy aplikacyjnej stanowi pewien narzut cza-
sowy i dodatkowe obciążenie procesora. Opracowana metoda ma umożliwić
ocenę protokołów właśnie pod kątem liczby pojawiających się wstawek. Do-
tyczy to szczególnie nowych, projektowanych rozwiązań. Wydaje się jednak
że może być także stosowane przy ocenie danego zastosowania.
Proces analizy składa się z 6 kroków [45] (rysunek 5.1):
1. wybranie interesujących parametrów,
2. analiza ramki i wyznaczenie określonych parametrów,
3. ocena protokołu,
4. określenie wrażliwych miejsc,
5. wskazanie możliwych zmian,
6. analiza zmodyfikowanej ramki.
Wybranie interesujących parametrów
W rozdziale 2 zebrano kilka najczęściej pojawiających się parametrów
protokołów komunikacyjnych. Przedstawiono również różne oczekiwania i po-
trzeby stosowanych rozwiązań. W zależności od zastosowań projektant jako
kluczowe może przyjmować różne, często z goła odmienne parametry. Ten
etap ma właśnie za zadanie wybrać parametry uznane za ważne, a następnie
na podstawie uzyskanych wyników wyznaczyć ich wartości dla badanej ramki
lub protokołu.
Rozdział 5. Własna metoda oceny i ograniczenia... 51
Rysunek 5.1. Schemat blokowy postępowania z wykorzystaniem opracowanej
metody[45]
Rozdział 5. Własna metoda oceny i ograniczenia... 52
Analiza ramki i wyznaczenie określonych parametrów
Po wybraniu parametrów kluczowych należy wskazać informacje niezbęd-
ne przy ich wyznaczaniu. Głównie jest to przebadanie zachowania się ram-
ki, pod wpływem zmiany danych, na liczbę wstawek bitowych. W tym celu
należy wyznaczyć zależnie od potrzeb np: wartości pesymistyczne, średnie,
itd. Jednak zastosowanie wyznaczania wartości pesymistycznej na podstawie
zasady działania protokołu (paragraf 3.1.1) nie jest rozwiązaniem wystarcza-
jącym, gdyż dla wielu wprowadzanych zmian wartość ta nie ulegnie zmianie.
Jednocześnie uzyskiwane wartości mogą znacząco odbiegać od wartości rze-
czywistych. Z tego względu zalecane jest stosowanie metod symulacyjnych.
Jedną z nich jest metoda przedstawiona w paragrafie 3.1.2. Polega ona na
podziale całej ramki na kilka części i wyznaczenia w sposób symulacyjny
(np. poprzez przebadanie losowej grupy wartości przez ten obszar przyjmo-
wanych) liczby wstawek bitowych poszczególnych obszarów. Zaletą takiego
rozwiązania jest konieczność wyznaczenia nowych wartości tylko dla części
ramki, w której nastąpiła zmiana. Uzyskane na tym etapie wyniki posłużą
do oceny protokołu oraz wyznaczenia interesujących parametrów. W trakcie
generowania tych wartości przydatne, a nawet wskazane jest wyznaczenie roz-
kładu wstawek bitowych po kolejnych bitach danych (histogram). Zastosowa-
nie tej analizy ułatwi wskazanie obszarów ramki gdzie najczęściej występują
bity niepożądane.
Ocena protokołu
W kroku tym przystępuje się do oceny protokołu zbierając uzyskane in-
formacje z dwóch poprzednich punktów. W momencie gdy uzna się wartości
wybranych parametrów za niewystarczające należy przejść do kolejnych kro-
ków metody.
Określenie wrażliwych miejsc
W tym momencie bardzo przydatne będą wyniki zbudowanego histogra-
mu. Oczywiście można wykonać analizę teoretyczną ramki, wyszukując ana-
litycznie miejsc gdzie najczęściej pojawiają się wstawki. Jednak ze względu
na dużą zależność liczby wstawek od przesyłanych danych a czasami i od
wcześniej przesłanych wstawek wychwycenie wszystkich takich miejsc może
być bardzo trudne. Analizując algorytm wstawek bitowych można zauważyć,
iż dla obszarów, gdzie mogą wystąpić dowolne bloki danych, szansa wystą-
pienia wstawki bitowej jest w takim obszarze dla każdego bitu jednakowa.
Rozdział 5. Własna metoda oceny i ograniczenia... 53
Największe zaburzenia powinny natomiast pojawić się w miejscach, gdzie
zawartość obszaru jest ograniczona (np.: w nagłówku). I od takiego przypad-
ku zazwyczaj można rozpocząć analizę. Pozwoli to jednocześnie skrócić czas
przeprowadzania eksperymentu.
Uwaga! Gdy badamy konkretną implementacje każde ze stosowanych pól
może być ograniczone (zarówno nagłówek jest takim obszarem jak i pole
danych). Dlatego w tym przypadku niezbędna jest analiza całej ramki.
Na podstawie uzyskanych wyników w połączeniu z opracowywaną lub
stworzoną specyfikacją można przystąpić do kolejnego etapu.
Wskazanie możliwych zmian
Gdy istnieją miejsca o ponadprzeciętnym występowaniu wstawek (czę-
stości ich pojawiania się) są to miejsca, w obszarze których można uzyskać
poprawę (zmniejszenie) liczby wstawek bitowych. Teraz należy określić zakres
możliwych zmian (np.: zmiana kodowania pewnych informacji, długości lub
położenia niektórych bloków, itd.). Gdy wytypowane już zostaną możliwe do
wprowadzenia zmiany należy ocenić skuteczność wymyślonych modyfikacji.
Do tego celu posłuży ostatni krok metody.
Analiza zmodyfikowanego protokołu
Podobnie jak dla ramki przed rozpoczęciem procesu wyznaczania liczby
wstawek, wyznaczamy wartości parametrów lub ich składowe, aby następnie
przystąpić do porównania uzyskanych rezultatów. Gdy wyniki osiągną zada-
ny cel lub uzna się postawiony cel za niemożliwy do osiągnięcia następuje
zakończenie procesu dopasowania ramki.
W kolejnym rozdziale przedstawiona metoda została poddana weryfikacji
na przykładzie protokołu CAN.
Rozdział 6
Przykład zastosowania własnej
metody oceny i ograniczenia liczby
wstawek bitowych
Jako ilustrację opracowanej metody wybrano protokół CAN. Jest to sieć
przemysłowa, a wiec o znacznie większych wymaganiach co do czasu odpowie-
dzi, jak i determinizmu. Przy okazji jako prosta sieć może w trakcie kolejnych
kroków dostarczyć wiedzy o wpływie konstrukcji ramki (w szczególności na-
główka) na liczbę wstawek bitowych. W cytowanej literaturze przedstawiono,
że dla ramek najkrótszych (czyli z zerowym polem danych) we wszystkich
nagłówkach wystąpi przynajmniej jedna wstawka bitowa (tabele 4.1 i 4.2).
Na podstawie zdobytej wiedzy o zachowaniu się protokołu wykorzystują-
cego wstawki bitowe, analizy specyfikacji i przedstawionymi opracowanymi
już rozwiązaniami oraz zastosowaniu opisywanej we wcześniejszym rozdziale
metody, zaproponowano kilka własnych rozwiązań mających na celu również
zmniejszyć liczbę wstawek bitowych. Metoda ma za zadanie zdiagnozować
problem i wprowadzać zmiany na poziomie warstwy łącza danych ISO/OSI,
co w przypadku już istniejących protokołów wiąże się z możliwością wystąpie-
nia niezgodności z algorytmami stosowanymi w dotychczasowych układach.
W takich przypadkach konieczna jest zawsze dyskusja nad zmianami, z per-
spektywy zgodności ze standardem.
6.1. Metodyka wykonywania eksperymentów
Przy kolejnych krokach niezbędne jest wykonywanie symulacji, dlatego
konieczne było przygotowanie odpowiednich narzędzi programistycznych. Sy-
mulacje można podzielić na kilka etapów, w których wykorzystywane były
różne - stworzone przez autora aplikacje. W trakcie badań ze względu na
ograniczenia jednego środowiska autor przepisał stanowisko badawcze do in-
nej platformy językowej. W fazie wstępnej badań zakładając konieczność
przeanalizowania wielu próbek (ramek), uznano że najlepszym rozwiązaniem
będzie wykorzystanie aplikacji napisanej w języku C++ (załącznik B.1). Roz-
Rozdział 6. Przykład zastosowania własnej metody... 55
wiązanie to było wystarczające dla krótszych ramek, jednak przy ramkach
z długimi adresami (np. 29 bitów) wyznaczenie wartości średnich stało się
bardziej złożone. Główny problem to przechowywanie wyników całkowitych
eksperymentów - suma wyników cząstkowych przekraczała 232 − 1. Dlate-
go zmieniono stosowany język programowania na Python-a. Dzięki niemu
po wykonaniu biblioteki symulacyjnej, łatwo można było wykonywać ekspe-
rymenty.
Wspomniana biblioteka składa się z 4 części:
1. Frames.py(załącznik C.1) - zawiera klasę odzwierciedlającą budowę ram-
ki. Zawiera wszystkie dostępne dla użytkownika pola. Jednocześnie umoż-
liwia konfigurowanie to jest zmianę długości i wartości kodowych dla
poszczególnych pól. Dzięki temu za pomocą jednej linijki kodu można
zmodyfikować zachowanie się protokołu.
2. DLL.py(załącznik C.2) - klasa zawierająca funkcje realizujące zadania
warstwy łącza danych to jest: generowanie sumy kontrolnej, weryfika-
cja odebranych ramek, generowanie, wstawianie i usuwanie wstawek bito-
wych. W klasie tej umieszczono funkcje wyświetlające zbierane statystyki
dotyczące liczby i rozkładu wstawek bitowych.
3. PHY.py(załącznik C.3) - zadaniem stworzonej klasy jest generowanie błę-
dów. Umożliwia ona symulowanie jednego z trzech rodzajów błędów: lo-
sowych, blokowych i błędów wstawek bitowych. Posiada również funkcje
wyświetlającą statystki wygenerowanych błędów.
4. Lab_Supp.py(załącznik C.4) - zbiór funkcji pomocniczych przydatnych
przy wyświetlaniu wyników.
Jednak aby przebadać wszystkie wartości identyfikatora, ze względu na czas
generowania wyników przez program symulujący (do 26 godzin), niezbędne
było zaimplementowanie badań rozproszonych. W tym celu wykorzystano
dostępne komputery laboratoryjne w okresie przerwy semestralnej oraz spe-
cjalnie napisane aplikacje klienta (załącznik E) i serwera (załącznik D). Były
to dwie aplikacje napisane z wykorzystaniem języka Python. Komunikacja
odbywała się poprzez tworzenie połączeń wykorzystując mechanizm socke-
tów. Po połączeniu się klienta z serwerem, najpierw zwracane były wyniki
poprzednich badań, a następnie serwer zwracał w postaci tekstowej kolejną
próbkę danych. Jeżeli komunikacja uruchamiana była po raz pierwszy klient
zwracał zamiast wyników linię pustą. Wszystkie dane przechowywane były
w plikach tekstowych:
Rozdział 6. Przykład zastosowania własnej metody... 56
— tsdata.txt- odpowiednio przygotowane linie danych, z których każda
zawierała parametry kolejnego eksperymentu.
— fsdata.txt- w pliku tym przechowywane były wysłane do badania linie
parametrów, oraz daty zakończenia wyznaczania wyników.
— results.txt- zapisywano w nim informacje o podłączeniu nowego kom-
putera oraz uzyskane rezultaty.
Gdyż do wcześniejszych (wstępnych) badań napisano już aplikację przyjmują-
cą parametry jako kolejne elementy w linii poleceń, zadaniem aplikacji klienta
było pobranie parametrów eksperymentu, uruchomienie wcześniej opracowa-
nego programu oraz przesłanie rezultatów do serwera.
Na ostatnim etapie analizy niektóre rozwiązania badane były pod kątem
zgodności ze standardem poprzez wykorzystanie zestawu uruchomieniowego
firmy CCS. Jesto to układ składający się z 4 węzłów połączonych siecią. Aby
zweryfikować rozwiązanie jeden z procesorów za pomocą specjalnego progra-
mu generował odpowiednie sekwencje bitowe (o długości zgodnej z prędkością
pracy magistrali) i wysyłał je na transceiver, który umieszczał je na łączu
z zachowaniem odpowiednich wartości napięć zadanych stanów. Przygotowa-
nie ramki, to jest umieszczenie reprezentacji bitowej nagłówka, pola danych
oraz sumy kontrolnej, spoczywała na autorze. Aby zachować dokładne czasy
trwania każdego bitu stosowano rozkazy asemblerowe (załącznik F). Drugi
węzeł wyposażony w kontroler sieci MCP2515 odczytywał wysyłane komuni-
katy i wyświetlał je poprzez kanał RS232 na ekranie komputera.
W trakcie oceny prezentowanych rozwiązań zastosowany został następu-
jący wzorzec. W celu uwypuklenia różnic pomiędzy poszczególnymi rozwią-
zaniami, porównywane będą liczby wstawek bitowych dla samego nagłówka.
Wartości dla całej ramki zastosowane będą dopiero przy wyznaczaniu porów-
nywanych parametrów. Do oszacowania liczby wstawek bitowych wykorzy-
stana zostanie metoda podziału ramki na trzy części: nagłówka, pola danych
i sumy kontrolnej (wzór 3.4).
6.2. Wybranie interesujących parametrów
Ze względu na potrzebę oceny wyników wprowadzonych zmian konieczne
było wybranie przynajmniej kilku parametrów. Aby dokonać najlepszego wy-
boru spośród najpopularniejszych cech zebrano je i przedstawiono w punk-
cie 2. Jednocześnie usystematyzowano niektóre pojęcia, różnie definiowane
i prezentowane przez autorów w swoich publikacjach. Na podstawie zebranej
Rozdział 6. Przykład zastosowania własnej metody... 57
wiedzy uznano iż najlepiej wpływ badanych zmian na cykl systemu wyrażą
następujące parametry:
— zmienność,
— opóźnienie,
— sprawność.
Wybrane parametry bardzo dobrze przedstawiają determinizm czasowy sie-
ci, którego znajomość jest warunkiem koniecznym przy wyborze protokołu
podanym na początku paragrafu 2.3. Jednocześnie wskazanym parametrom
i metodom ich poprawy podporządkowano budowę stanowiska badawczego -
programów badawczych i testujących zaimplementowane rozwiązania.
6.3. Analiza ramki
Aby zrozumieć zachodzące zależności w ramce należy szczegółowo zapo-
znać się z jej budową (kolejnością i funkcjami poszczególnych pól), a także
z metodą komunikacji i wymiany informacji.
6.3.1. Budowa ramki
W protokole CAN rozróżniamy dwa typy ramek (rysunek 6.1): 2.0A -
Standardowe oraz 2.0B - Rozszerzone. Nazwy wskazują że standard 2.0B
pojawił się później jako rozszerzenie protokołu. Informacje o typie ramki
zawarty jest w bicie IDE. Oprócz tego w nagłówku występują jeszcze pola:
początku ramki (SOF), identyfikatora (ID), długości pola danych (DLC),
danych (DATA), suma kontrolna (CRC), flaga informująca o wysłaniu ramki
żądania zdalnej transmisji (RTR) oraz bity zarezerwowane RB*. Ze wzglę-
du ma metodę dostępu do łącza (Wired-AND) rywalizację wygrywa węzeł
nadający ramkę o niższym identyfikatorze. Więcej informacji o ramce jak
i protokole przedstawiono w załączniku A.
6.3.2. Definicje zmiennych i stałych
W kolejnych podrozdziałach do prezentacji wpływu wstawek wykorzysty-
wane będą pewne wartości wynikające z budowy ramki, a ogólną budowę
przykładowej ramki przedstawiono na rysunku 6.1. Dlatego przed przystą-
pieniem do wyznaczania kolejnych parametrów zebrano i wyjaśniono wyko-
rzystywane nazwy zmiennych i stałych (wynikających z budowy ramki):
— długość nagłówka ramki (LHeader),
Rozdział 6. Przykład zastosowania własnej metody... 58
S R I R
O I T D B DLC DATA
F D T E 0
0 . . . b 0 0 bbbb . . .(a) Ramka w standardzie 2.0A
S I I R R R
O I I D I T B B DLC DATA
F D S E D R 1 0
0 . . . 0 1 . . . b 0 0 bbbb . . .(b) Ramka w standardzie 2.0B
Rysunek 6.1. Budowa ramki CAN.
— całkowita długość ramki bez uwzględnienia odstępu międzyramkowego
(IFS) i pola danych (Data) (LFAll/wIFS,Data),
— całkowita długość ramki bez pola danych (Data) (LFAll/wData = LFAll/wIFS,Data+
LIFS, gdzie LIFS = 3),
— długość obszaru ramki podlegającego szpikowaniu bitami bez uwzględ-
nienia obszaru danych (LFBS/wData).
Poszczególne wartości wyrażone są w funkcji ramki, którą opisują, i w ra-
zie potrzeby długości pola danych wyrażonych za pomocą (DLC):
— LHeader(CAN20A) = 19 i LHeader(CAN20B) = 39,
— LFAll/wIFS,Data(CAN20A) = 44 i LFAll/wIFS,Data(CAN20B,DLC) = 64,
— LFAll/wData(CAN20A) = 47 i LFAll/wData(CAN20B,DLC) = 67,
— LFBS/wData(CAN20A) = 34 i LFSB/wData(CAN20B) = 54,
Ponieważ długość ramki zależy od długości pola danych (DLC), na pod-
stawie przedstawionych wartości można wyznaczyć długość całkowitą (LFAll =
LFAll/wData + 8 · DLC), długość całkowitą bez odstępu międzyramkowego
(LFAll/wIFS = LFAll/wIFS,Data + 8 ·DLC) i całkowitą długość obszaru podle-
gającego wstawianiu bitów (LFBS = LFBS/wData + 8 ·DLC):
— LFAll/wIFS(CAN20A,DLC) = 44..108 i LFAll/wIFS(CAN20B,DLC) =
64..128,
— LFAll(CAN20A,DLC) = 47..111 i LFAll(CAN20B,DLC) = 67..131,
— LFBS(CAN20A,DLC) = 34..98 i LFBS(CAN20B,DLC) = 54..128.
Rozdział 6. Przykład zastosowania własnej metody... 59
6.3.3. Wyznaczenie wartości pesymistycznych i średnich
Jak już wspomniano wartości pesymistyczne nie dostarczają pełnego ob-
razu o rozkładzie liczby wstawek bitowych w całej próbce. Dlatego oprócz
wartości granicznych wyznaczono wartości średnie. Jednocześnie obie warto-
ści potrzebne są do wyznaczenia niektórych parametrów (np.: zmienności).
Wartości Pesymistyczne
Dla ramki możliwe jest wyznaczenie maksymalnej liczby bitów wstawio-
nych na podstawie specyfikacji (wzór 6.1) [50]:
BSpes =⌊LFBS/wData + 8 ·DLC − 1
4
⌋(6.1)
oraz całkowitej długości pesymistycznej ramki wykorzystywanej do planowa-
nia czasu wymiany:
LCp/wIFS = LFAll/wIFS(FrameType,DLC) +⌊34 + 8 ·DLC − 1
4
⌋(6.2)
Co po podstawieniu odpowiedniej wartości LBS/wData daje dla ramki typu A:
BSpes =⌊34 + 8 ·DLC − 1
4
⌋(6.3)
LCp/wIFS = 8 ·DLC + 44 +⌊34 + 8 ·DLC − 1
4
⌋(6.4)
, a dla ramki typu B:
BSpes =⌊54 + 8 ·DLC − 1
4
⌋(6.5)
LCp/wIFS = 8 ·DLC + 64 +⌊54 + 8 ·DLC − 1
4
⌋(6.6)
.
Na podstawie tych wzorów wyznaczono wartości pesymistyczne przedsta-
wione w tabeli 6.1.
DLC 0 1 2 3 4 5 6 7 8
CAN 2.0A [bit] 8 10 12 14 16 18 20 22 24
CAN 2.0B [bit] 13 15 17 19 21 23 25 27 29
Tabela 6.1. Pesymistyczna wartość liczby bitów wstawionych, w zależności od dłu-
gości pola danych (BSpes).
Wartości z tabeli 6.1 przekładają się na udział procentowy liczby bitów
wstawionych w całkowitej długości ramki (tabela 6.2).
Rozdział 6. Przykład zastosowania własnej metody... 60
DLC 0 1 2 3 4 5 6 7 8
CAN 2.0A [%] 15,38 16,13 16,67 17,07 17,39 17,65 17,86 18,03 18,18
CAN 2.0B [%] 16,88 17,24 17,53 17,76 17,95 18,11 18,25 18,37 18,47
Tabela 6.2. Udział procentowy liczby bitów wstawionych w całkowitej długości
ramki (ramka CAN wraz z bitami wstawionymi bez uwzględnienia w długości
ramki obszaru IFS)(LCp/wIFS).
Teoretyczne wyliczenia wykazały możliwość obciążenia pasma do 20%
przez sygnały dodatkowe - nie przenoszące żadnej informacji. W celu po-
twierdzenia tego wyniku wykonano kilka eksperymentów symulacyjnych. Dla
każdego zestawu wartości pól DLC, IDE, RTR wyznaczono 15 milionów loso-
wych par identyfikatora i pola danych. Generator liczb pseudolosowych miał
rozkład równomierny. Ze względu na występowanie w obszarze podlegającym
mechanizmowi wstawek bitowych nie tylko elementów zmiennych (ID, DLC,
DATA, CRC) ale również elementów stałych (SOF, RB0, RB1), może okazać
się że rzeczywista całkowita liczba wstawek występujących w pojedynczej
ramce będzie się różnić od wartości oczekiwanych na podstawie obliczeń.
Wykonany eksperyment, którego wyniki przedstawiono w tabeli 6.3 oraz na
rysunku 6.2, potwierdził stawiane przypuszczenia.
DLC 0 1 2 3 4 5 6 7 8
CAN 2.0A [bit] 6 7 9 10 11 12 12 13 14
CAN 2.0B [bit] 10 10 11 13 12 13 14 15 15
Tabela 6.3. Symulacyjne wartości liczby bitów wstawionych, w zależności od dłu-
gości pola danych (BSsim).
(a) Ramka CAN2.0A (b) Ramka CAN2.0B
Rysunek 6.2. Liczba wstawek bitowych, wyznaczona metodą eksperymentalną.
Rozdział 6. Przykład zastosowania własnej metody... 61
Uzyskane rezultaty obarczone są pewnym błędem, wynikającym z ogra-
niczonej próbki i sposobu jej uzyskania. Różnica wartości na poziomie 30%
wskazuje jednak na istnienie korzystniejszych wartości granicznych. Ekspe-
ryment jednocześnie pokazał znaczenie nie tylko wartości pesymistycznych,
ale również wartości średnich, przy ocenie tego mechanizmu.
Podczas badań, których wyniki przedstawiono na rysunku 6.2 wykonano
również histogram (analizę rozkładu występowania wstawek bitowych po po-
szczególnych bitach (rysunek 6.3)).
Zauważając pewne anomalia rozkładu bitów nadmiarowych w nagłów-
ku (na przykład dla krótkich ramek zawsze występuje wstawka) postano-
wiono skorzystać z przedstawionego rozwiązania podziału obszaru wstawek
bitowych na trzy części (z wykorzystaniem wzorów 3.4 i 3.6): nagłówka
(BSHEADER), pola danych (BSDATA) i sumy kontrolnej (BSCRC) [43].
BS = BSHeader+BSData+BSCRC+BSCorr = BSHeader+BSData+BSCRC+1
(6.7)
Znając rzeczywiste wartości pesymistyczne liczby wstawek bitowych na-
główka (BSHeader) - na podstawie wyników przedstawionych w tabelach 4.1 i
4.2 - można spróbować wykonać dokładniejsze oszacowanie wartości pesymi-
stycznych (wzór 6.7), a tylko do wyznaczenia wartości BSDATA i BSCRC wy-
korzystać wartości teoretyczne (dla rozpatrywanego przypadku bLbits4 c, gdzie
Lbits reprezentuje długość bitową pola, dla którego wyznaczana jest wartość
pesymistyczna). Stosując tą metodę uzyskano poprawę wartości pesymistycz-
nych, w stosunku do wartości teoretycznych (tabela 6.1), maksymalnie o 1 bit
(tabela 6.4).
DLC 0 1 2 3 4 5 6 7 8
CAN 2.0A [bit] 8 10 11 13 15 17 19 21 23
CAN 2.0B [bit] 13 14 16 18 20 22 24 26 28
Tabela 6.4. Pesymistyczna wartość liczby bitów wstawionych, w zależności od dłu-
gości pola danych, z wykorzystaniem badań dotyczących pesymistycznych wartości
liczby wstawek bitowych nagłówka CAN).
Wartość Średnia
Pole danych i sumy kontrolnej charakteryzują się stałym prawdopodo-
bieństwem wystąpienia wstawki bitowej, dlatego przy wyznaczaniu wartości
średniej postanowiono skorzystać z opracowanej przez autora metody z wyko-
Rozdział 6. Przykład zastosowania własnej metody... 62
(a) Ramka CAN2.0A
(b) Ramka CAN2.0B
Rysunek 6.3. Histogram liczby wstawek bitowych na każdy bit danych.
Rozdział 6. Przykład zastosowania własnej metody... 63
rzystaniem podziału ramki, podobnie jak to miało miejsce przy wyznaczaniu
wartości pesymistycznych (wzór 6.7).
Na podstawie tych samych wyników losowej próbki danych, określono
prawdopodobieństwo wystąpienia wstawki dla każdego bitu obszarów da-
nych i sumy kontrolnej, na poziomie 0,033(3) [wstawki bitowej/bit]. Ozna-
cza to, że na danym polu w trzech procentach ramek występuje wstawka
bitowa. Dlatego aby potwierdzić poprawność wyznaczonego rozkładu, wyko-
nano kilka eksperymentów. Początkowo wybrano losowe długości strumienia
i wygenerowano wszystkie kombinacje bitów. Dla każdego n bitowego stru-
mienia wyznaczano rozkład wstawek bitowych. Badane strumienie danych
wydłużano o kolejne bity: od 12 do 26 (rysunek 6.4). Ponieważ badany jest
Rysunek 6.4. Wybrane wartości rozkładu wstawek bitowych po poszczególnych
bitach.
obszar, który poprzedzony jest innymi bitami, z wyniku odrzucono pierwsze
9 bitów. Dla pozostałych stanów uzyskano wartość zbliżoną do oczekiwanej.
Aby wyznaczyć granicę dla wartości średniej wykonano kolejny eksperyment.
Tym razem napisana została aplikacja generująca nieskończony, losowy ciąg
binarny. Dla takiego ciągu wyznaczane były wstawki bitowe. W rezultacie
dla 45 045 388 562 bitów dodanych zostało 1 501 499 900. Z tego wynika
że na każdy bit danych przypada średnio 0,033(3) bita wstawki.
Można to przełożyć na wartość średnią liczby wstawek bitowych, która
wynosi:
BSDataavg = 3, 3% · 8 ·DLC (6.8)
Rozdział 6. Przykład zastosowania własnej metody... 64
oraz
BSCRCavg = 3, 3% · 15 (6.9)
BSCRCavg = 0, 495 [bitów] (6.10)
Wyznaczone wartości, uzyskane na podstawie eksperymentów, są tylko przy-
bliżeniem wartości średniej. Na różnicę pomiędzy wartością przybliżona a war-
tością rzeczywistą mogą mieć wpływ:
— rozbieżność zachowania się początku pola danych, w stosunku do modelu
przyjętego,
— nieznaczne różnice w liczbie wystąpień wstawek bitowych po poszczegól-
nych polach.
1 2 3 4 5 6 7 8
BSDataavg 0,264 0,528 0,792 1,056 1,320 1,584 1,848 2,112
Tabela 6.5. Średnia liczba wstawek bitowych w obszarze danych
Bazując na wyznaczonej klasyfikacji liczby wstawek bitowych (z tabel 4.1
i 4.2) przedstawionych na wykresach (rysunek 6.3.3) wyznaczono wartości
średnie nagłówka. Uzyskano je sumując wszystkie ramki z odpowiednimi wa-
gami (jako wagę przyjęto liczbę wstawek bitowych dla danej grupy ramek)
i dzieląc przez całkowitą liczbę ramek:
BSHeaderavg =1
LiczbaID·∑ (Liczba Ramek ·Waga) (6.11)
Podstawiając odpowiednie wartości uzyskano wartości średnie zamiesz-
czone w tabeli 6.6. Na tej podstawie wartość średnią dla całego obszaru
0 1 2-3 4-7 8
CAN20A 1,39 1,32 1,29 0,79 0,53
CAN20B 2,165 2,10 2,06 1,56 1,30
Tabela 6.6. Średnia liczba wstawek bitowych w obszarze nagłówka (BSHeaderavg)
podlegającego mechanizmowi wstawiania bitów zawiera tabela 6.7.
Rozdział 6. Przykład zastosowania własnej metody... 65
(a) dla ramki standardowej
(b) dla ramki rozszerzonej
Rysunek 6.5. Liczba ramek z wyznaczoną wartością wstawek bitowych, zależnie
od wartości identyfikatora
Rozdział 6. Przykład zastosowania własnej metody... 66
0 1 2 3 4 5 6 7 8
CAN20A 1,885 2,084 2,314 2,578 2,342 2,606 2,870 3,134 3,133
CAN20B 2,660 2,857 3,085 3,352 3,116 3,380 3,644 3,908 3,905
Tabela 6.7. Średnia liczba wstawek bitowych w ramce CAN(BSavg)
6.3.4. Obliczenie wartości mierzonych parametrów
Sprawność
Jest to jeden z prostszych wskaźników. Dla ramki przesyłającej informacje
za obszar danych uznano tylko i wyłącznie pole danych: LData = 8 · DLC.
Podstawiając tą wartość do wzoru 2.13 uzyskamy:
µ =8 ·DLCLFrame
(6.12)
W zależności od przyjętej długości ramki LFrame możemy uzyskać spraw-
ność ramki na poziomie warstwy łącza danych (µ/wBS) lub fizycznej (µBS).
W zależności od poziomu, sprawność wyrażać się będzie jako:
µ/wBS =8 ·DLCLFAll/wIFS
(6.13)
µBS =8 ·DLCLCp/wIFS
(6.14)
Z przedstawionych rozwiązań do oceny proponowanych zmian wybrano µBS.
Jego wartość zależna jest od wszystkich pól i mechanizmów wykorzystywa-
nych podczas transmisji.
Rozwijając równanie 6.14, uzyskamy:
µBS =8 ·DLC
8 ·DLC + LFAll/wIFS,Data +BSHeader +BSDATA +BSCRC(6.15)
Podstawiając w miejsca zmiennych reprezentujących wstawki bitowe, war-
tości średnie z tabeli 6.7 uzyskamy sprawność średnią µBSavg , a wybierając
wartości pesymistyczne BSpes, uzyskamy sprawność pesymistyczną (µBSpes).
Wyliczone wartości dla obu podstawień liczby wstawek bitowych umieszczono
w tabeli 6.8.
Opóźnienie
Przystosowując wzór 2.3.2 do warunków badanej sieci, można go zapisać
jako:
Di = τs + τp (6.16)
Rozdział 6. Przykład zastosowania własnej metody... 67
1 2 3 4 5 6 7 8
CAN2.0A pes 0,131 0,229 0,300 0,3556 0,400 0,436 0,467 0,492
CAN2.0A avg 0,148 0,257 0,340 0,408 0,462 0,506 0,543 0,576
CAN2.0B pes 0,094 0,168 0,228 0,278 0,320 0,356 0,386 0,413
CAN2.0B avg 0,107 0,193 0,263 0,323 0,373 0,415 0,453 0,485
Tabela 6.8. Wartości średnie i pesymistyczne sprawności dla ramki CAN
czyli czas transmisji/odbioru wiadomości (τs) oraz czas propagacji (τp). War-
tości tych czasów można wyznaczyć na podstawie wzorów 6.17 i 6.18.
τs =LFAll/wIFSi +BS
v(6.17)
τp =l
vp(6.18)
gdzie: l - długość magistrali,
v - prędkość transmisji,
vp - szybkość propagacji sygnału transmisyjnego w łączu.
Dla sieci mówimy o opóźnieniu pojedynczej transmisji (Di - wzór 6.19)
oraz opóźnieniu maksymalnym występującym w danej sieci (Dmax - wzór
6.20).
Di =LFAll/wIFSi +BSi
v+
l
vp(6.19)
Dmax =LFAll/wIFS +BSmax
v+
l
vp(6.20)
Część τp jest stała i zależna od konkretnej implementacji (rodzaju i dłu-
gości medium transmisyjnego). W celu wykonania porównania przyjęto pręd-
kość transmisji (v) równe 1 Mbps, a długość (l) wynoszącą 40 m i vp odpo-
wiadająca w przybliżeniu prędkości propagacji sygnału elektrycznego w prze-
wodzie miedzianym (23 ·c). Na tej podstawie wyznaczono wartości średniego i
maksymalnego opóźnienia, przedstawione odpowiednio w tabelach 6.9 i 6.10
0 1 2 3 4 5 6 7 8
CAN20A [µs] 46,085 54,284 62,514 70,778 78,542 86,806 95,070 103,334 111,332
CAN20B [µs] 66,86 75,057 83,288 91,552 99,316 107,580 115,844 124,108 132,105
Tabela 6.9. Wartości średnie opóźnień w sieci CAN (Davg)
Rozdział 6. Przykład zastosowania własnej metody... 68
Zmienność
Sieć przemysłowa musi zachowywać się przewidywalnie, zapewniając sta-
ły czas dostarczenia wiadomości. W sieci zastosowanej jako ilustracja ba-
danego problemu na zmienność mogą wpływać: błędy transmisji, priorytet
wiadomości oraz wstawki bitowe. Każdy z wymienionych czynników wpływa
na zwiększenie zapotrzebowania nadawcy na pasmo, co przekłada się na ob-
ciążenie sieci, a w konsekwencji na czas transmisji. Jest to jeden z czynników
powodujący że przy projektowaniu systemów przemysłowych z wykorzysta-
niem protokołu CAN, organizacja CiA zaleca wykorzystanie do 50 % pasma.
Zmienność ściśle zależy od występujących w sieci opóźnień. Jej wartość
można wyznaczyć albo teoretycznie określając wartości graniczne opóźnienia
i wartość średnią, albo metodą eksperymentalną, mierząc czas transmisji dla
przykładowej próbki ramek. Dla tego przypadku, ze względu na charakter
pracy, wybrano rozwiązanie bazujące na wyznaczaniu wartości teoretycznych.
Jmax =
|Davg −Dmax||Davg −Dmin|
gdzie:Dmin jest to opóźnienie powstałe podczas transmisji ramki bez wstawek
bitowych. Po uwzględnieniu założeń dotyczących uwzględnianych elementów
wpływających na opóźnienie wykorzystać można wzór 3.10. Na tej podstawie
wyznaczono wartości maksymalne dla poszczególnych długości ramek, przy
prędkości transmisji v = 1Mbps (tabela 6.11).
6.4. Ocena protokołu
Na podstawie wykonanych badań uzyskano szczegółową wiedzę na temat
wpływu poszczególnych elementów na liczbę wstawek. Szczególnie dotyczy to
nagłówka, który powtarza się dla dużej liczby ramek, w przeciwieństwie do
pola danych i pól kontroli poprawności (np. CRC), które są zależne od prze-
syłanych wartości. Analiza protokołu wykazała, że w niektórych ramkach wy-
stępują wstawki permanentne. My jako konstruktorzy lub osoby które mogą
0 1 2 3 4 5 6 7 8
CAN20A [µs] 51,2 61,2 70,2 80,2 90,2 100,2 110,2 120,2 130,2
CAN20B [µs] 76,2 85,2 95,2 105,2 115,2 125,2 135,2 145,2 155,2
Tabela 6.10. Maksymalne wartości opóźnień w sieci CAN (Dmax)
Rozdział 6. Przykład zastosowania własnej metody... 69
0 1 2 3 4 5 6 7 8
CAN20A 5,115 6,916 7,686 9,422 11,658 13,394 15,130 16,866 18,868
CAN20B 9,34 10,143 11,912 13,648 15,884 17,620 19,356 21,092 23,095
Tabela 6.11. Zmienność maksymalna w sieci CAN, dla ramek o różnej długości
(Jmax)
wprowadzić zmiany chcemy sprawdzić czy jest możliwe zlikwidowanie takiej
wstawki oraz czy można to zrobić zachowując opracowane już założenia.
6.5. Określenie wrażliwych miejsc
Podczas wyznaczania liczby wstawek bitowych w ramkach, rejestrowano
jednocześnie pozycje po których bity te się pojawiały. Zarejestrowane dane
przedstawiono na rysunku 6.3. Zaskoczenie wzbudziło bardzo duże odchylenie
od wartości średniej występujące na wykresie, wskazujące że dla niektórych
rodzajów ramek, za wstawkę permanentną odpowiada jedno miejsce. Pola
znajdujące się w tym obszarze były niezmienne w badanej grupie. Z te-
go względu nasuwa się przypuszczenie, że występujące anomalia wynikają
z budowy ramki. Na podstawie tych wyników, widać również że przy próbie
wyznaczenia wartości średniej liczby wstawek bitowych w ramce, największe
zaburzenia występują w obszarze nagłówka. Aby określić przyczynę takie-
go zachowania rozpisano wygląd nagłówka podczas transmisji (tabela 6.12).
Wytłuszczone bity są odpowiedzialne za wystąpienie jednej wstawki bito-
wej. W skład tych bitów wchodzą: RTR, RB0, RB1, DLC. Na tej podstawie
dokonano opracowania kilku możliwych zmian.
6.6. Wskazanie możliwych zmian
Próby wprowadzania zmian w ramce protokołu, wymagają szczegółowej
znajomości nie tylko samej budowy, ale również wytycznych co do zachowania
się węzłów podczas tworzenia i odbierania wiadomości. Szczególnie dotyczy
to zachowania się węzłów odbierających na wystąpienie różnic w stosunku
do ramki wzorcowej. Czasami może zdarzyć się, że pomimo wystąpienia war-
tości niepoprawnej (przekłamania bitu), węzeł odbierający nie zasygnalizuje
błędu, a zignoruje dany bit, lub dokona jego korekcji. Niektóre omówione
Rozdział 6. Przykład zastosowania własnej metody... 70
Tabela 6.12. Zawartość nagłówka ramki CAN
(a) CAN2.0A
Długość pola danych SOF ID RTR IDE RB0 DLC
0 0 ... 0 0 0 0000
1 0 ... 0 0 0 0001
2 0 ... 0 0 0 0010
3 0 ... 0 0 0 0011
4 0 ... 0 0 0 0100
5 0 ... 0 0 0 0101
6 0 ... 0 0 0 0110
7 0 ... 0 0 0 0111
8 0 ... 0 0 0 1000
(b) CAN2.0B
Długość pola danych SOF ID11 SSR IDE ID18 RTR RB0 RB1 DLC
0 0 ... 0 1 ... 0 0 0 0000
1 0 ... 0 1 ... 0 0 0 0001
2 0 ... 0 1 ... 0 0 0 0010
3 0 ... 0 1 ... 0 0 0 0011
4 0 ... 0 1 ... 0 0 0 0100
5 0 ... 0 1 ... 0 0 0 0101
6 0 ... 0 1 ... 0 0 0 0110
7 0 ... 0 1 ... 0 0 0 0111
8 0 ... 0 1 ... 0 0 0 0000
zmiany można wykorzystać, w celu ograniczenia liczby wstawek bitowych,
z zachowaniem zgodności.
W trakcie analizowania protokołu powstało kilka koncepcji zmian warto-
ści niektórych pól (RB0 i DLC) oraz wykorzystanie ramki zdalnego żądania
do przesyłania danych. Przedstawione poniżej rozwiązania są tylko niektóry-
mi z możliwych zmian (według autora) nieznacznie ingerującymi w protokół.
Ustawienie bitu RB0 na 1
Bit RB0 w standardzie CAN, określony jest jako bit zarezerwowany do
przyszłego wykorzystania. Opisując wartość jaką to pole powinno przyjmo-
wać specyfikacja Bosch [59] podaje: „bity RB0 i RB1 należy wysyłać w stanie
dominującym, ale odbiorca odbierze poprawnie zarówno stan dominujący jak
Rozdział 6. Przykład zastosowania własnej metody... 71
i recesywny”1. Do wprowadzenia jednej zmiany autor badań spróbował wy-
korzystać przedstawioną cechę protokołu, zmieniając wartość tego pola z do-
minującego na recesywny. Po weryfikacji teoretycznej i określeniu korzyści
związanych z taką zmianą, należy przystąpić do oceny zgodności rozwiązań
z implementacją standardu.
Zmiana kodowania
Kolejne pole poddane analizie to pole DLC. Jego długość wynosi 4 bity,
co umożliwia zakodowanie do 16 stanów. Obecnie wykorzystywanych jest
tylko 9 z nich (tabela 6.13). Zauważając niedogodności związane z kodami
Długość pola danych DLC
0 0
1 1
2 2
3 3
4 4
5 5
6 6
7 7
8 8..15
Tabela 6.13. Tablica kodów długości pola danych w obszarze DLC [59]
dla długości pola danych mniejszych od 4, autor podjął próby wyszukania
i zmiany kodowania długości w polu DLC w taki sposób, aby wykorzystać
kody najmniej wpływające na liczbę pojawiających się wstawek bitowych.
Skrócenie pola DLC do 3 bitów
Podobnie jest z kolejną propozycją dotyczącą obszaru DLC, a mianowicie
jej skrócenie do 3 bitów. Jest to znacząca zmiana gdyż oprócz zmiany dopusz-
czalnych wartości pola, ingeruje się w jego długość. Argumentem za skróce-
niem tego pola jest zastosowanie 4 bitowego pola w niewielkim stopniu go
wykorzystując. Ponieważ jak już wspomniano wykorzystywanych jest tylko 9
stanów, można zastanowić się nad ograniczeniem liczby stanów kodowych
do 8 (3 bitów). W efekcie, konieczne byłoby zrezygnowanie z możliwości
1 „The reserved bits have to be sent ’dominant’, but receivers accept ’dominant’ and
’recessive’ bits in all combinations.”[59]
Rozdział 6. Przykład zastosowania własnej metody... 72
przesyłania ramki o jednej długości (np: 8 bajtowych paczek danych lub
uniemożliwić przesyłanie ramki danych z zerową długością pola danych).
Przesyłanie danych w ramce zdalnego żądania
Standard CAN pozwala na przesyłanie ramek zdalnego żądania o zerowej
długości pola danych, niezależnie od ustawionej wartości pola DLC. Mo-
że zaistnieć konieczność sparametryzowania przesyłanego żądania transmisji
(np. wskazać czujnik, który należy odczytać lub określić dokładność pomia-
ru), wtedy trzeba albo stosować kilka identyfikatorów, z przypisanymi do
każdego identyfikatora parametrami, albo wysyłać ramkę danych, na którą
węzeł odbierający odpowie. Zamiast tego można by wykorzystać przezna-
czoną do tego celu ramkę zdalnego żądania. Jednocześnie zmianie uległ by
rozkład bitów wstawionych w nagłówku (zmiana bitu RTR), co mogło by
korzystnie wpłynąć na całkowitą długość ramki.
6.7. Analiza zmodyfikowanej ramki
Po wskazaniu i wstępnym przeanalizowaniu zmian (w stosunku do wyma-
gań systemu lub grupy systemów dla którego jest tworzony) można przystąpić
do oceny ich skuteczności. Do porównania wybrano 4 modyfikacje w warstwie
łącza danych:
— ustawienie bitu RB0 na 1,
— zmiana kodowania obszaru DLC,
— skrócenie pola DLC,
— przesyłanie danych w ramce zdalnego żądania.
Analizę rozpoczęto od szczegółowego omówienia założeń poszczególnych zmian.
Ustawienie bitu RB0 na 1
Na podstawie analizy przyczyn występowania wstawek bitowych, zapro-
ponowano jako jeden ze sposobów rozdzielenia występującego ciągu zer zmia-
nę ustalonej wartości niewykorzystywanego obecnie bitu RB0. Wykonanie za-
proponowanej zmiany powinno spowodować zmniejszenie lub zlikwidowanie
występowania wstawki bitowej w tym obszarze (rysunek 6.7). Analiza specyfi-
kacji wykazała bardzo ogólny opis interpretacji tego bitu. Ogranicza się on do
określenia wartości wymaganych (zera) przy nadawaniu oraz dopuszczalnych
wartości (zera lub jedynki) podczas odbierania. Brak jest jasnego wyjaśnienia
czy wartość odczytana tego bitu jest uwzględniana przy przetwarzaniu ramki
Rozdział 6. Przykład zastosowania własnej metody... 73
S R I R
O I T D B DLC DATA
F D T E 0
0 . . . 0 0 0 0000 . . .
↓0 . . . 0 0 1 0000 . . .
(a) Ramka w standardzie 2.0A
S I I R R R
O I I D I T B B DLC DATA
F D S E D R 1 0
0 . . . 0 1 . . . 0 0 0 0000 . . .
↓0 . . . 0 1 . . . 0 0 1 0000 . . .
(b) Ramka w standardzie 2.0B
Rysunek 6.6. Oczekiwany efekt związany ze zmianą wartości bitu RB0, dla jednego
z przypadków.
(do usuwania wstawek bitowych i wyznaczenia sumy kontrolnej), czy przyj-
mowane są wartości domyślne (takie jakie według specyfikacji powinny być
nadane). Dlatego w celu sprawdzenia możliwości zastosowania ramki z ta-
ką modyfikacją w obecnie występujących sieciach wymagane jest wykonanie
odpowiedniego eksperymentu.
Zmiana kodowania obszaru DLC
Kolejną omawianą modyfikacją jest zmiana kodowania poszczególnych
długości pola danych. Informacja o długości pola danych kodowana jest na
4 bitach, a do zakodowania jest tylko 9 wartości. Występowanie dla większo-
ści kodów na najstarszej pozycji zera powoduje, że dla kodów długości pola
danych od 0 do 4 bajtów zawsze wystąpi jedna wstawka bitowa w obszarze
nagłówka. Wykorzystanie większej liczby kodów, dla których na najstarszej
pozycji będzie występować jedynka (rysunek 6.7), powinno ograniczyć liczbę
występujących wstawek bitowych. Niestety taka zmiana spowoduje niezgod-
ność węzłów i zgłaszanie błędów przez węzły zgodne ze specyfikacją. Według
specyfikacji węzeł każdą wartość opisującą długość pola danych nie wystę-
pującą w tablicy kodowej interpretuje jako kod, któremu przypisano długość
pola danych mieszczącą 8 bajtów. Inne rozwiązanie, takie jak wydłużenie
ramki do maksymalnie 15 bajtów danych nie jest możliwe ze względu na ce-
Rozdział 6. Przykład zastosowania własnej metody... 74
S R I R
O I T D B DLC DATA
F D T E 0
0 . . . 0 0 0 0000 . . .
↓0 . . . 0 0 0 1000 . . .
(a) Ramka w standardzie 2.0A
S I I R R R
O I I D I T B B DLC DATA
F D S E D R 1 0
0 . . . 0 1 . . . 0 0 0 0000 . . .
↓0 . . . 0 1 . . . 0 0 0 1000 . . .
(b) Ramka w standardzie 2.0B
Rysunek 6.7. Oczekiwany efekt związany ze zmianą kodowania, dla jednego z przy-
padków.
chy sumy kontrolnej. Wielomian wykorzystywany w tym protokole najlepiej
zabezpiecza informacje (najwyższy poziom wykrycia błędu) o długości od 64
do 112 bitów [25].
Skrócenie pola DLC
Inny pomysł modyfikacji obszaru DLC polega na ograniczeniu liczby wy-
korzystywanych bitów do trzech (rysunek 6.8). Taka zmiana zmniejsza do-
stępną liczbę kodów z 16 do 8. Ponieważ wykorzystywanych jest 9 stanów,
nie możliwe będzie zakodowanie jednego ze stanów. Podczas eksperymen-
tów przyjęto, iż nie będzie możliwe wysyłanie ramek zawierających 8 bajtów
danych. W efekcie uzyskamy skrócenie ramki o 1 bit. Ograniczenie liczby
wstawek bitowych w głównej mierze będzie dotyczyć dłuższych ramek, gdzie
oprócz korzyści związanych ze zmniejszeniem się długości samego nagłówka
dojdzie mniejsza liczba wstawek bitowych. Przy normalnym kodowaniu efekt
zmniejszenia liczby wstawek bitowych występował dopiero dla długości 4
bajtów danych.
Przesyłanie danych w ramce zdalnego żądania
Ostatnia próba modyfikacji polega na zmianie obecnego zachowania się
ramki CAN, w momencie przesyłania żądania informacji - za pomocą tzw.
Rozdział 6. Przykład zastosowania własnej metody... 75
S R I R
O I T D B DLC DATA
F D R E 0
0 . . . 0 0 0 0000 . . .
↓0 . . . 0 0 0 000 . . .
(a) Ramka w standardzie 2.0A
S I I R R R
O I I D I T B B DLC DATA
F D S E D R 1 0
0 . . . 0 1 . . . 0 0 0 0000 . . .
↓0 . . . 0 1 . . . 0 0 0 000 . . .
(b) Ramka w standardzie 2.0B
Rysunek 6.8. Oczekiwany efekt związany ze zmianą kodowania.
ramki zdalnego żądania. Dla ramki zgodnej ze standardem, niezależnie od
wartości pola DLC, pole danych nie występuje. Należy dokładnie przeanali-
zować i ocenić potencjalne korzyści z wprowadzenia możliwości przesyłania
danych w ramce RTR. Dla przykładu, wprowadzając taką modyfikacje możli-
we będzie parametryzowanie zapytania wywoływanego przez ramkę zdalnego
żądania. Innym potencjalnym wykorzystaniem takiej funkcjonalności byłaby
możliwość przesyłania ramek zdalnego żądania, z jednoczesną odpowiedzią
na inne zapytanie. Przy obecnym rozwiązaniu, jedynie za pomocą pola DLC
można parametryzować wywoływany rozkaz.
Wstępna analiza ramki (rysunek 6.9), wskazuje także możliwość ogra-
niczenie liczby wstawek bitowych, występujących podczas takiej transmisji.
W głównej mierze powinno to dotyczyć ramek najdłuższych.
6.7.1. Wyznaczenie wartości średnich i pesymistycznych
Po opracowaniu i przedstawieniu szczegółowych założeń dla tych modyfi-
kacji należy powtórzyć te same operacje, jakim poddano ramkę początkową
i wyznaczyć nowe wartości wstawek bitowych.
Rozdział 6. Przykład zastosowania własnej metody... 76
S R I R
O I T D B DLC DATA
F D R E 0
0 . . . 0 0 0 0001 . . .
↓0 . . . 1 0 0 0001 . . .
(a) Ramka w standardzie 2.0A
S I I R R R
O I I D I T B B DLC DATA
F D S E D R 1 0
0 . . . 0 1 . . . 0 0 0 0000 . . .
↓0 . . . 0 1 . . . 1 0 0 0000 . . .
(b) Ramka w standardzie 2.0B
Rysunek 6.9. Oczekiwany efekt związany z wysyłaniem danych w ramkach zdal-
nego żądania, dla jednego z przypadków.
Ustawienie bitu RB0 na 1
Dla każdej kombinacji wartości nagłówka wyznaczono podobnie jak miało
to miejsce dla nie zmienionej ramki CAN (6.3.3), podział identyfikatorów
ze względu na liczbę wystąpień wstawek bitowych (rysunek 6.7.1).
Na tej podstawie uzyskano informacje o wartości pesymistycznej oraz
średniej liczbie wstawek bitowych nagłówka. Uzyskane wartości są jednako-
0-8
CAN20A 0,390
CAN20B 1,165
Tabela 6.14. Średnia liczba wstawek bitowych w nagłówku ramki CAN ze zmianą
bitu RB0(BSavg)
we dla wszystkich długości pola danych (tabela 6.14) i lepsze od najlepszego
rezultatu standardowej ramki CAN przy wartości DLC = 8. Wartość średnia
dla ramki standardowej ze zmianą wynosi 0,39 bita/nagłówek i jest mniejsza
od ramki „standardowej” (DLC=8) o 0,27 bita/nagłówek. Dla ramki „roz-
szerzonej” ze zmianą wartość średnia wynosi 1,165 bita/ramkę i jest mniejsza
o 0,13 bita/nagłówek. Wprowadzenie tej zmiany umożliwiło poprawę o 1 bi-
Rozdział 6. Przykład zastosowania własnej metody... 77
(a) dla ramki standardowej
(b) dla ramki rozszerzonej
Rysunek 6.10. Liczba ramek z wyznaczoną wartością wstawek bitowych, zależnie
od wartości identyfikatora [33]
Rozdział 6. Przykład zastosowania własnej metody... 78
t/ramkę dla ramek najkrótszych i tylko około 0,135 bita/ramkę dla ramek
najdłuższych (DLC = 8). Wartości pesymistyczne natomiast różnią się mak-
symalnie o jedne bit. Zmniejszenie liczby wstawek bitowych spowodowało
skrócenie ramki „standardowej” o maksymalnie 2,2%, a ramki „rozszerzonej”
o 1,5%. Pełne wyniki przedstawiono w tabeli 6.15.
typ 0 1 2 3 4 5 6 7 8
CAN 2.0A [%] 2,2 1,7 1,44 1,27 0,51 0,46 0,42 0,39 0,12
CAN 2.0B [%] 1,5 1,25 1,08 0,98 0,40 0,37 0,35 0,32 0,10
Tabela 6.15. Wyznaczone zmiany całkowitej długości ramki poprzez zastosowanie
zmiany wartości bitu RB0
Zmiana kodowania obszaru DLC
Wykonano eksperyment klasyfikujący identyfikatory, na podstawie liczby
wstawek występujących w nagłówku (rysunek 6.7.1). Na tej podstawie wy-
znaczono parametry średniej (tabela 6.16) i pesymistycznej liczby wstawek
bitowych dla poszczególnych kodów. Uzyskane rezultaty wykorzystane zo-
stały do wyznaczenia wartości średnich, wykorzystywanych do wyznaczania
parametrów sieci. Zamieszczone wyniki dają dla większości badanych kodów
9-14 15
CAN20A 0,525 0,660
CAN20B 1,298 1,431
Tabela 6.16. Średnia liczba wstawek bitowych w nagłówku ramki CAN dla warto-
ści DLC z przedziału ∈ 〈9 . . . 15〉)
lepsze wyniki niż kody obecnie stosowane, zarówno przy wartościach średnich
jak i pesymistycznych. Wyjątek stanowi kod „1111”, dający poprawę w sto-
sunku do wszystkich obecnie stosowanych kodów z wyjątkiem „1000”. Dla
tej wartości zwiększa się prawdopodobieństwo wystąpienia wstawki bitowej,
gdy przed bitami opisującymi długość pola danych zostanie wstawiony już
bit dodatkowy, o wartości równy 1. Pozostałe kody zmniejszają średnią liczbę
wstawek bitowych w nagłówku od 0,26 - 0,86 bita/nagłówek.
Obecna kolejność kodów powoduje, że ramki najkrótsze przy tym samym
identyfikatorze mają wyższy priorytet. Podczas zmiany kodów, aby pozosta-
wić obecne zachowanie się ramek podczas rozstrzygania kolizji, niezbędne jest
Rozdział 6. Przykład zastosowania własnej metody... 79
(a) dla ramki standardowej
(b) dla ramki rozszerzonej
Rysunek 6.11. Liczba ramek z wyznaczoną wartością wstawek bitowych, zależnie
od wartości identyfikatora [32]
Rozdział 6. Przykład zastosowania własnej metody... 80
przypisanie krótszym ramkom, kodów odpowiadających niższym wartościom
dziesiętnym (tabela 6.17).
Długość
pola danych Kodowanie
0’ 0111
1’ 1000
2’ 1001
3’ 1010
4’ 1011
5’ 1100
6’ 1101
7’ 1110
8’ 1111
Tabela 6.17. Proponowane zmiany w kodowaniu długości pola danych)
Zastosowanie nowych propozycji kodów daje możliwość skrócenia całko-
witej długości ramki (tabela 6.18).
typ 0’ 1’ 2’ 3’ 4’ 5’ 6’ 7’ 8’
CAN 2.0A [%] 1,31 1,48 1,23 1,08 0,34 0,31 0,28 0,26 -0,12
CAN 2.0B [%] 0,90 1,07 0,92 0,84 0,27 0,25 0,23 0,22 -0,10
Tabela 6.18. Wyznaczone zmiany całkowitej długości ramki poprzez zastosowanie
zmiany kodowania obszaru DLC
Skrócenie pola DLC
Pomiędzy uzyskanymi wynikami (rysunek 6.12), a rezultatami dla obecne-
go standardu, występuje pewna zależność. Otóż udało się potwierdzić przed-
stawione przypuszczenie o możliwości uzyskania znacznie lepszych wyników
liczby wstawek bitowych, niż ma to miejsce dla normalnej ramki CAN. Jedy-
nie dla zerowej długości pola danych w ramce, nie można znaleźć odpowied-
nika. Dla pozostałych kodów, wartości pokrywają się odpowiednio z kodami
(w reprezentacji dziesiętnej):
— 1 ⇒ 2 - 3,
— 2 - 3 ⇒ 4 - 7,
— 4 - 7 ⇒ 8 - 14.
Rozdział 6. Przykład zastosowania własnej metody... 81
Rysunek 6.12. Liczba ramek z wyznaczoną wartością wstawek bitowych, zależnie
od wartości identyfikatora
(a) dla ramki standardowej
(b) dla ramki rozszerzonej
Rozdział 6. Przykład zastosowania własnej metody... 82
Uzyskanie znacznie wcześniej niskich wartości średniej liczby wstawek bi-
towych może dodatkowo poprawić wartości wyznaczanych parametrów. Po-
mimo występowania zestawu bitów, wymuszającego dodanie wstawki bitowej
w badanym obszarze, uzyskane wartości średnie są niższe w stosunku do war-
tości uzyskiwanych dla obecnie wykorzystywanych ramek o zerowej długości
pola danych (o ponad 0,3 bita/nagłówek).
0 1 2 - 3 4 - 7
CAN20A 1,357 1,291 0,791 0,525
CAN20B 2,130 2,060 1,560 1,298
Tabela 6.19. Średnia liczba wstawek bitowych w nagłówku ramki CAN ze skróco-
nym polem DLC(BSavg)
Skrócenie nagłówka ramki o jeden bit, w połączeniu ze zmniejszeniem
występowania wstawek bitowych, doprowadziło do uzyskania, nie porówny-
walnego z innymi rozwiązaniami, poziomu skrócenia ramki.
typ 0 1 2 3 4 5 6 7
CAN 2.0A [%] 2,25 1,91 2,41 2,13 1,62 1,46 1,33 1,23
CAN 2.0B [%] 1,55 1,38 1,80 1,64 1,28 1,18 1,09 1,02
Tabela 6.20. Wyznaczone zmiany całkowitej długości ramki poprzez zastosowanie
skrócenia pola DLC
Przesyłanie danych w ramce zdalnego żądania
Tezę dotyczącą redukcji liczby wstawek bitowych, podczas transmisji w ram-
ce zdalnego żądania, spróbowano potwierdzić, podobnie jak miało to miejsce
dla innych zmian, za pomocą wykonania pełnego badania nagłówka. Jako
pełne badanie rozumie się wygenerowanie wszystkich możliwych jego kombi-
nacji. Rezultaty tych badań przedstawiono na rysunku 6.7.1. Uzyskane wyni-
ki okazały się lepsze od oczekiwanych. Jeżeli chodzi o średnią liczbę wstawek
bitowych to dla długości pola danych od 4 do 8 bajtów uzyskano wartości
najniższe, w porównaniu do wszystkich przeprowadzonych badań. Również
wartości pesymistyczne są najniższe - dla ramkę typu standardowego wynosi
zawsze 3 bity/nagłówek, a dla ramki typu rozszerzonego udaje się uzyskać
ich zmniejszenie do 7 bitów/nagłówek. Przedstawione rezultaty przekładają
się na uzyskane średnie skrócenie długości ramki (tabela 6.22).
Rozdział 6. Przykład zastosowania własnej metody... 83
(c) dla ramki standardowej
(d) dla ramki rozszerzonej
Rysunek 6.13. Liczba ramek z wyznaczoną wartością wstawek bitowych, zależnie
od wartości identyfikatora
Rozdział 6. Przykład zastosowania własnej metody... 84
0-1 2-3 4-8
CAN20A 1,324 0,357 0,324
CAN20B 2,098 1,131 1,098
Tabela 6.21. Średnia liczba wstawek bitowych w nagłówku ramki CAN ze skróco-
nym polem DLC
typ 0 1 2 3 4 5 6 7 8
CAN 2.0A [%] 0,14 0,00 1,50 1,32 0,57 0,54 0,49 0,45 0,18
CAN 2.0B [%] 0,10 0,00 1,12 1,02 0,47 0,43 0,40 0,37 0,15
Tabela 6.22. Wyznaczone zmiany całkowitej długości ramki poprzez zastosowanie
przesyłania danych w ramce zdalnego żądania
6.7.2. Wyznaczenie i porównanie wartości mierzonych
Po określeniu wpływu zmian w ramce na liczbę wstawek bitowych, można
przystąpić do wyznaczania porównywanych parametrów transmisji. Wartości
zostały pogrupowane według rodzaju zmian.
Ustawienie bitu RB0 na 1
Sprawność
Uzyskaną poprawę sprawności przedstawiono w tabeli 6.23. W zależności
1 2 3 4 5 6 7 8
CAN2.0A 0,151 0,261 0,344 0,411 0,464 0,508 0,545 0,577
CAN2.0B 0,108 0,195 0,265 0,324 0,374 0,417 0,453 0,486
Tabela 6.23. Wartości średnie sprawności dla ramki CAN ze zmienioną wartością
bitu RB0
od długości nagłówka i pola danych ramki, poprawa sprawności waha się po-
między 0,4% i 0,1% dla ramki CAN2.0A i poniżej 0,1% dla ramek CAN2.0B.
Największą poprawę uzyskano dla ramek o długości pola danych: 2 i 3 bajty.
Opóźnienie
Korzyści związane ze zmniejszeniem się liczby wstawek bitowych wyraźnie
uwidaczniają się przy wyznaczaniu opóźnienia. W przykładzie wyznaczono
czas transmisji dla sieci o prędkości transmisji 1 [Mbit/s]. Z tego względu
Rozdział 6. Przykład zastosowania własnej metody... 85
skrócenie ramki o każdy dodatkowy bit przekłada się na skrócenie transmisji
o 1 µs.
0 1 2 3 4 5 6 7 8
CAN20A [µs] 45,085 53,349 61,613 69,877 78,141 86,405 94,669 102,933 111,197
CAN20B [µs] 65,860 74,124 82,388 90,652 98,916 107,180 115,444 123,708 131,972
Tabela 6.24. Wartości średnie opóźnień w sieci CAN ze zmienioną wartością bitu
RB0
Dla wartości średnich opóźnienia (tabela 6.24), poprawa nastąpiła dla
wszystkich dostępnych długości. Oznacza to, że prezentowana modyfikacja
pozytywnie wpłynęła na ramki dla długości pola danych (każdej wartości
DLC). Wartości pesymistyczne (tabela 6.25) uległy zmniejszeniu jedynie dla
najkrótszych ramek (DLC = 0 lub 1 dla ramki CAN2.0A i DLC = 0 dla
ramki CAN2.0B). Tabela 6.26 zawiera informacje o zysku, powstałym po-
0 1 2 3 4 5 6 7 8
CAN20A [µs] 50,2 60,2 70,2 80,2 90,2 100,2 110,2 120,2 130,2
CAN20B [µs] 75,2 85,2 95,2 105,2 115,2 125,2 135,2 145,2 155,2
Tabela 6.25. Maksymalne wartości opóźnień w sieci CAN ze zmienioną wartością
bitu RB0
przez zmianę wartości bitu RB0, uzyskiwanym podczas przesyłu każdej ram-
ki. Okazało się, że nie tylko ramki najkrótsze, w których zmniejszeniu uległy
wartości pesymistyczne liczby wstawek bitowych, uzyskały znaczny spadek
opóźnienia. Również dla ramek mieszczących 2 i 3 bajty danych udało się
zyskać około 1 bitu/ramkę.
0 1 2-3 4-7 8
CAN20A [µs] 1,000 0,934 0,901 0,401 0,135
CAN20B [µs] 1,000 0,933 0,900 0,400 0,133
Tabela 6.26. Różnica wartości opóźnień ramki w sieci CAN oraz ramki ze zmie-
nioną wartością bitu RB0
Przykład 1. Zakładając występowanie w sieci CAN przeważającej wielkości
ramek krótkich (od 0 do 3 bajtów danych), można wyznaczyć przykładowy
zysk z zastosowania takiej optymalizacji. Jako średnią wartość długości ram-
ki przyjęto 60 bitów, a prędkość transmisji 1 Mbit/s. Dla takich warunków
Rozdział 6. Przykład zastosowania własnej metody... 86
przybliżona liczba zaoszczędzonych bitów wynosi 14000 bit/s. Przekłada się
to na 230 dodatkowych takich ramek, które można przesłać w tym samym
czasie.
Zmienność
Zmiany inaczej wpłynęły na parametr zmienności (tabela 6.27). Dla po-
przednich parametrów wartości zmian dla ramki typu 2.0A i 2.0B były zbli-
żone. W przypadku zmienności występują różnice dla obu typów ramek.
Dla ramek „standardowych” pomijając ramki najkrótsze (DLC = 0 i 1),
wzrost zmienności jest proporcjonalny ze średnim zmniejszeniem opóźnień.
Przy ramkach „rozszerzonych” wartości pokrywają się dla wszystkich dłu-
gości ramek, z wyłączeniem ramki bez pola danych. Dla tych przypadków
różnica zmienności pomiędzy ramką ze zmianami i bez nich jest bliska zeru.
Powstałe różnice wynikają, ze zmiany wartości pesymistycznych opóźnień
ramki tylko dla niektórych długości pola danych.
0 1 2 3 4 5 6 7 8
CAN20A 5,115 6,851 8,587 10,323 12,059 13,795 15,531 17,267 19,003
CAN20B 9,340 11,076 12,812 14,548 16,284 18,020 19,756 21,492 23,228
Tabela 6.27. Zmienność maksymalna w sieci CAN przy zastosowaniu ramek ze
zmienioną wartością bitu RB0
Zmiana kodowania obszaru DLC
Sprawność
Poprzez zmianę kodowania uzyskano poprawę sprawności (tabela 6.28)
ramki danych. Dla ramek typu CAN 2.0A największą zmianę sprawności
uzyskano dla długości danych równej 3 bajty (0,4%). Najgorszy przypadek -
pogorszenie się sprawności - uzyskano przy długości 8 bajtów danych (0,07%).
Podobnie jest dla ramki typu 2.0B, największy zysk uzyskano dla ramki o 3
bajtowym polu danych (0,22%) i dla 8 bajtów danych pogorszenie o 0,05%.
Opóźnienie
Ponieważ wszystkie wyznaczane wartości są powiązane z wartością śred-
nią liczy wstawek bitowych, również w parametrze jakim jest opóźnienie wi-
dać różnicę w liczbie wstawek bitowych. Opóźnienie w sieci 1 Mbps (tabela
6.29) udało się zredukować nawet o 0,8 µs/ramke. Jest to poprawa znacząca,
Rozdział 6. Przykład zastosowania własnej metody... 87
1’ 2’ 3’ 4’ 5’ 6’ 7’ 8’
CAN2.0A 0,150 0,260 0,344 0,410 0,463 0,507 0,544 0,575
CAN2.0B 0,108 0,194 0,265 0,324 0,373 0,416 0,453 0,485
Tabela 6.28. Wartości średnie sprawności dla ramki CAN ze zmienionym kodowa-
niem obszaru DLC
0’ 1’ 2’ 3’ 4’ 5’ 6’ 7’ 8’
CAN20A [µs] 45,486 53,484 61,748 70,012 78,276 86,540 94,804 103,068 111,468
CAN20B [µs] 66,200 74,257 82,251 90,785 99,049 107,313 115,557 123,841 132,238
Tabela 6.29. Wartości średnie opóźnień w sieci CAN ze zmienionym kodowaniem
obszaru DLC
szczególnie gdy taki wynik uzyskuje się dla krótkich ramek (przesyłających
niewielką liczbę danych - do 3 bajtów). Pełne wyniki umieszczone zostały
w tabeli 6.30.
Ponieważ nastąpiło zwiększenie liczby wstawek dla ramek najdłuższych,
wydłużeniu uległ również średni czas transmisji o 0,135 µs/ramke.
0’ 1’ 2’-3’ 4’-7’ 8’
CAN20A [µs] 0,599 0,799 0,766 0,266 -0,135
CAN20B [µs] 0,600 0,800 0,767 0,267 -0,133
Tabela 6.30. Różnica wartości opóźnień ramki w sieci CAN oraz ramki ze zmie-
nioną wartością bitu RB0
Zmienność
Zmienność dla tego rozwiązania zmniejszyła się jedynie dla ramek, w któ-
rych wartość pesymistyczna również się zmniejszyła (tabela 6.31). Maksymal-
ny spadek zmienności wynosi 0,4 µs/ramkę. W pozostałych przypadkach,
ponieważ poprawie uległa tylko wartość średnia, a pesymistyczna pozostała
bez zmian, zmienność wzrosła.
Skrócenie pola DLC
Sprawność
Pomimo nie uzyskania średniej liczby wstawek bitowy na najniższym po-
ziomie, sprawności (tabela 6.32) dla tych ramek są najwyższe. Dla „długich
Rozdział 6. Przykład zastosowania własnej metody... 88
0’ 1’ 2’ 3’ 4’ 5’ 6’ 7’ 8’
CAN20A 4,714 6,716 8,452 10,188 11,924 13,660 15,396 17,132 19,732
CAN20B 8,940 10,943 12,679 14,415 16,151 17,887 19,623 21,359 23,962
Tabela 6.31. Zmienność maksymalna w sieci CAN z zastosowaniem ramek o zmie-
nionym kodowaniu obszaru DLC
1 2 3 4 5 6 7
CAN2.0A 0,151 0,263 0,347 0,415 0,469 0,513 0,550
CAN2.0B 0,108 0,196 0,267 0,327 0,377 0,420 0,457
Tabela 6.32. Wartości średnie sprawności dla ramki CAN ze skróconym polem
DLC
ramek” sprawność protokołu wzrasta o około 0,7% dla ramek „standardo-
wych” i około 0,4% dla ramek „rozszerzonych”.
Opóźnienie
Ponieważ wzrost sprawności uzyskano poprzez zmniejszenie liczby bitów
potrzebnych do przesłania wiadomości, zmniejszeniu uległ czas potrzebny do
przesłania takiej ramki. Dla wybranej konfiguracji sieci (opisanej w rozdziale
6.3.4), uzyskano rezultaty przedstawione w tabeli 6.33. Porównując je z wy-
0 1 2 3 4 5 6 7
CAN20A [µs] 43,70 51,96 60,22 68,49 76,75 85,02 93,28 101,54
CAN20B [µs] 65,826 74,024 81,788 90,052 98,049 106,313 114,577 122,841
Tabela 6.33. Wartości średnie opóźnień w sieci CAN ze skróconym polem DLC
nikami otrzymanymi dla ramki bez wprowadzanych modyfikacji, okazuje się
że wykorzystując omawianą właśnie modyfikacje można zyskać do 1.5 bita-
/ramkę (tabela 6.34).
Zmienność
Ponieważ średnia długość ramki jest mniejsza niż ma to miejsce w ram-
ce zbudowanej na podstawie standardu, również poprzez zmniejszenie liczby
wstawek bitowych, dla przypadków w których nie uległa zmianie maksymalna
liczba wstawek bitowych zmienność jest większa. Gdy poprzez wprowadzoną
zmianę udało się zmniejszyć pesymistyczną liczbę wstawek bitowych w na-
Rozdział 6. Przykład zastosowania własnej metody... 89
0-1 2-3 4-7
CAN20A [µs] 1,033 1,500 1,266
CAN20B [µs] 1,033 1,500 1,267
Tabela 6.34. Różnica wartości opóźnień ramki w sieci CAN oraz ramki ze skróco-
nym polem DLC
główku, również zmienność uległa poprawie. Wynika to z wzoru na zmien-
ność.
0 1 2 3 4 5 6 7
CAN20A 5,15 5,95 8,19 9,92 11,92 13,66 15,40 17,13
CAN20B 9,374 10,176 12,412 14,148 16,151 17,887 19,623 21,359
Tabela 6.35. Zmienność maksymalna w sieci CAN przy zastosowaniu ramek
ze skróconym polem DLC
Przesyłanie danych w ramce zdalnego żądania
Sprawność
Wpływ na uzyskiwane wartości sprawności (tabela 6.36) ma tylko ogra-
niczenie liczby wstawek bitowych. Poprawa sprawności dla ramek o długości
1 2 3 4 5 6 7 8
CAN2.0A 0,148 0,261 0,345 0,411 0,464 0,508 0,545 0,577
CAN2.0B 0,107 0,195 0,265 0,324 0,374 0,417 0,454 0,486
Tabela 6.36. Wartości średnie sprawności dla ramki CAN poprzez zastosowanie
przesyłania danych w ramce zdalnego żądania
pola danych wynoszącego 8 bitów, jest zbliżona do sprawności dla ramki
bez zmian. Dla pozostałych ramek standardowych sprawność poprawiła się
zależnie od długości od 0,10% (DLC=8) do 0,45% (DLC=3). Przy ramkach
rozszerzonych z tą zmianą uzyskuje się poprawę od 0,07% (DLC=8) do 0,27%
(DLC=3).
Opóźnienie
Dla tych samych parametrów łącza, jak w poprzednich badaniach, uzy-
skano zmniejszenie średniego opóźnienia (tabela 6.37) wynikającego i odpo-
wiadającego zmniejszeniu liczby wstawek bitowych. W rezultacie uzyskano
Rozdział 6. Przykład zastosowania własnej metody... 90
0 1 2 3 4 5 6 7 8
CAN20A [µs] 46,019 54,283 61,580 69,844 78,075 86,339 94,603 102,867 111,131
CAN20B [µs] 66,793 75,057 82,354 90,618 98,849 107,113 115,377 123,641 131,905
Tabela 6.37. Wartości średnie opóźnień w sieci CAN poprzez zastosowanie prze-
syłania danych w ramce zdalnego żądania
(tabela 6.38) poprawę maksymalną wynoszącą dla obu typów ramki 0,933
[µs] (DLC=2 lub 3). Nieznaczna poprawa (najgorszy rezultat), podobnie jak
miało to miejsce dla sprawności, uzyskano przy długości pola danych rów-
nemu 8 bitom - poniżej 1 ns. Nie rozpatrywana przy sprawności ramka bez
pola danych uzyskała zmniejszenie opóźnienia o 0,06 µs.
0 1 2-3 4-7 8
CAN20A [µs] 0,066 > 0,001 0,934 0,467 0,201
CAN20B [µs] 0,067 > -0,001 0,933 0,467 0,199
Tabela 6.38. Różnica wartości opóźnień ramki w sieci CAN przy przesyłaniu da-
nych w ramce zdalnego żądania
Zauważalne, w porównaniu z innymi modyfikacjami, jest brak poprawy
wartości średnich dla ramek o długości 1. Jednocześnie należy zaznaczyć,
że skróceniu o 1 bit uległy wartości pesymistyczne długości ramki, przy
ramkach najkrótszych (dla standardu CAN2.0A przy DLC=0 i 1 oraz dla
standardu CAN2.0B przy ramce o wartości DLC=0 i od 4 do 8) (tabela
6.39).
0 1 2 3 4 5 6 7 8
CAN20A [µs] 50,2 60,2 70,2 80,2 90,2 100,2 110,2 120,2 130,2
CAN20B [µs] 75,2 85,2 95,2 105,2 115,2 125,2 135,2 145,2 155,2
Tabela 6.39. Maksymalne wartości opóźnień w sieci CAN przy przesyłaniu danych
w ramce zdalnego żądania
Zmienność
Zmienność ze względu na zależność od dwóch czynników (opóźnienia śred-
niego i opóźnienia maksymalnego), daje zupełnie inne wartości zmian niż ma
to miejsce przy opóźnieniu. Omawiana modyfikacja jest jedną z nielicznych,
w której poprawa zmienności dotyczyła aż tak dużej liczby rodzajów ramek.
Rozdział 6. Przykład zastosowania własnej metody... 91
0 1 2 3 4 5 6 7 8
CAN20A 4,181 5,917 8,619 10,355 11,125 12,861 14,597 16,333 18,069
CAN20B 8,407 10,143 12,846 14,582 15,351 17,087 18,823 20,559 22,295
Tabela 6.40. Zmienność maksymalna w sieci CAN przy przesyłaniu danych w ram-
ce zdalnego żądania
Nawet dla długości danych wynoszących 1 bajt, przy ramce CAN 2.0A uzy-
skano poprawę. Poprawę zmienności uzyskano dla wszystkich ramek, w któ-
rych zmniejszeniu uległy wartości pesymistyczne opóźnień.
6.8. Ocena zaproponowanych zmian
6.8.1. Ustawienie bitu RB0 na 1
Omawiana modyfikacja wprowadza znaczne skrócenie dla długości danych
z zakresu od 0 do 3 bajtów. Uzyskana poprawa na poziomie 1 bitu/ramkę
oprócz skrócenia czasu transmisji daje również możliwość przesłania do 230
dodatkowych ramek, w jednym okresie czasu. Niespodziewany poziom po-
prawy uzyskano dla zmiany przy długości pola danych 2 lub 3 bajty.
Zastosowanie tego rozwiązania w gotowych sieciach - możliwość podłą-
czania kolejnych węzłów zawierających zmodyfikowane układy - jest warte
rozpatrzenia. Daje wiele korzyści związanych z czasem transmisji, jednocze-
śnie zachowuje zgodność wsteczną z opracowanymi rozwiązaniami (a przy-
najmniej z rozwiązaniami firmy MicroChip).
6.8.2. Zmiana kodowania obszaru DLC
Przedstawione rozwiązanie, również dało oczekiwaną poprawę. Wstawie-
nie jedynki na najstarszej pozycji poprawiło osiągane rezultaty, zbliżając się
do wyników osiągniętych podczas zmiany wartości bitu RB0. Jedynie przy
wykorzystaniu kodu zawierającego cztery jedynki, podwyższeniu uległa war-
tość średnia wstawek bitowych w tym obszarze. Z tego względu rezultaty
osiągane dla ramek najdłuższych okazywały się gorsze niż dla ramki bez
zmiany kodowania. Jednak wykorzystany kod (1111) uzyskuje lepsze war-
tości średnie od wszystkich kodów wykorzystywanych w obecnych ramkach,
z wyłączeniem kodu 1000. Jego jedyną wadą jest większa liczba wstawek
bitowych przy wartościach pesymistycznych, co przekłada się na zwiększenie
opóźnienia, w stosunku do ramki standardowej o 0,8 µs/ramkę.
Rozdział 6. Przykład zastosowania własnej metody... 92
6.8.3. Skrócenie pola DLC
Przedstawione rozwiązanie w dwojaki sposób skraca długość ramki, po-
przez:
— skrócenie nagłówka,
— zmniejszenie liczby wstawek w nagłówku.
Skrócenie nagłówka dało oszczędność jednego bitu w każdej ramce, kosztem
skrócenia maksymalnej długości pola danych do 7 bajtów. Ocena wykorzy-
stania ramek najdłuższych (mieszczących 8 bajtów danych) nie jest możliwa,
ze względu na brak dostępu do wykonanych implementacji (np. systemów
sterowania pojazdami, budynkami lub aparaturą medyczną). Należy jednak
zwrócić uwagę, że dzięki zaoszczędzeniu tego bitu udało się uzyskać tak
znaczną poprawę wszystkich przedstawionych parametrów. Ponieważ uzy-
skane rezultaty tylko w nieznacznym stopniu zostały osiągnięte poprzez re-
dukcję wstawek bitowych (maksymalnie 0,5 bita/ramkę, gdy w najlepszych
rozwiązaniach udało się zaoszczędzić ponad 1 bit/ramkę).
W rozwiązaniu tym nie udało się wyeliminować dla wszystkich długości
danych ramek, w których nagłówku powstaje przynajmniej jedna wstawka
bitowa, a jedynie zmniejszyć ich liczbę z czterech do dwóch. Jednak skrócenie
obszaru DLC niweluje występowanie tej wstawki. Zauważono również zależ-
ność pomiędzy długością pola danych a liczbą wstawek bitowych. Otóż dla
„nowych” ramek liczba wstawek bitowych w nagłówku odpowiada wartości
pola DLC pomnożonego przez 2. Istnieje jeden wyjątek, gdy w ramce nie ma
obszaru danych.
6.8.4. Przesyłanie danych w ramce zdalnego żądania
Rozwiązanie to jako jedyne, dla większości rodzajów ramek w standardzie
CAN 2.0B, poprawia wartości pesymistyczne. Dla ramek standardu CAN
2.0A, uzyskano już takie obniżenie wartości pesymistycznej, z wyłączeniem
„skrócenia pola DLC”. Niestety takie rozwiązanie jest niezgodne ze opisem
standardu i powodowało by zgłaszanie błędu przez węzły zgodne z przyjętym
standardem.
Zebrane doświadczenie można wykorzystać podczas projektowania syste-
mu wykorzystującego wymiany asynchroniczne. Ponieważ wartość pola DLC
nie ma wpływu na długość pola danych (pole to zawsze w ramce zdalnego
żądania nie występuje), można skracać czas transmisji takiej ramki, poprzez
wstawienie odpowiedniej wartości (kody odpowiadające długości pola danych
Rozdział 6. Przykład zastosowania własnej metody... 93
z zakresu od 4 do 8). Oczywiście można takiej optymalizacji dokonać jedynie
w momencie gdy pole to nie zawiera żadnych informacji (np. o dokładności
odczytu przesyłanej odpowiedzi, lub wskazania zestawu odczytów jakie są
oczekiwane w ramce, itp.).
6.9. Weryfikacja zgodności ze standardem
Podczas przeprowadzania analizy teoretycznej, wynikła możliwość zasto-
sowania zmodyfikowanych ramek w obecnie stosowanych sieciach. Po analizie
specyfikacji protokołu CAN uznano że jedyną zmianą rokującą szanse na za-
chowanie zgodności jest zmiana wartości bitu RB0. Aby potwierdzić tą tezę
niezbędne było wykonanie eksperymentu, polegającego na sprawdzeniu za-
chowania się sprzętowych kontrolerów sieci CAN, na ramkę ze zmienionym
bitem RB0.
Do wykonania takiego badania wykorzystano płytkę uruchomieniową opra-
cowaną przez firmę CCS, wraz z dołączonym do niej kompilatorem języ-
ka C/C++, na procesory firmy MicroChip. Na płytce umieszczono cztery
elementy systemu komputerowego połączone magistralą CAN. Dodatkowo
umieszczono wyprowadzenia TX i RX umożliwiające podłączenie zewnętrz-
nego układu do magistrali, oraz wyprowadzenia H i L, będącymi wypro-
wadzeniami poszczególnych linii magistrali. Do eksperymentu wykorzystano
dwa „moduły” (zestawy procesor + kontroler CAN). Jeden zaprogramowano
do ciągłego monitorowania magistrali i wysyłania poprzez magistrale RS-232
zawartość odczytanych ramek. W drugim układzie przygotowano reprezenta-
cje bitową ramki, z zachowaniem odpowiednich czasów trwania każdego bitu
dopasowanego, do prędkości transmisji magistrali.
Aby wyznaczyć ciąg wartości, jaki powinien wystąpić na magistrali, wy-
korzystano stosowaną do wyznaczania liczby wstawek bitowych w nagłówku
bibliotekę symulującą działanie sieci CAN. Za jej pomocą udało się szybko
uzyskać zarówno miejsca, w których należy umieścić wstawki bitowe, jak
również wyznaczyć sumę kontrolną. Zarówno dla ramki „normalnej” (zgod-
nej ze standardem) jak i zmodyfikowanej, wyznaczono ciągi je reprezentujące
za pomocą tej samej aplikacji.
Podczas badań niezmiernie ważne było dotrzymanie rygorów czasowych
narzuconych przez prędkość transmisji. Dlatego postanowiono zrezygnować z
czytelności kodu (stosowania kodu języka C), na rzecz kontroli czasu zmiany
i trwania poszczególnych bitów. W tym celu stworzono cztery makrodefinicje:
Rozdział 6. Przykład zastosowania własnej metody... 94
— CHANGE_TO_HIGH(BIT) #asm BSF 0xF8D.0 #endasm; delay_us(8);
— CHANGE_TO_LOW(BIT) #asm BCF 0xF8D.0 #endasm; delay_us(8);
— KEEP_TO_LOW delay_us(8);
— KEEP_TO_HIGH delay_us(8);
Rozróżniono zmianę stanu od jego trwania, aby umożliwić jak najczęstsze
wykorzystywanie rozkazu NOP, jednocześnie jak największą dokładność cza-
su trwania poszczególnych bitów. Kod każdej ramki składał się wyłącznie
z tych czterech rozkazów, nie stosując jednocześnie żadnych instrukcji mogą-
cych dodatkowo wydłużyć czas wykonania kodu (np: pętli, warunków). Cały
kod programu wykonywanego na mikrokontrolerze zamieszczono w załączni-
ku (załącznik F).
Dla sprawdzenia poprawności działania przygotowanego programu na mi-
kro procesor wykonano najpierw próbę przesłania „normalnej” ramki, a do-
piero następnie przystąpiono do nadawania ramek z modyfikacjami. Ponieważ
standard nie precyzuje metody sprawdzania sumy kontrolnej (czy przyjmo-
wana jest wartość odczytana z łącza, czy oczekiwana) przygotowano dwie
zmienione ramki: bez wyznaczenia nowej sumy kontrolnej i z nową sumą kon-
trolną. Dla przypadku pierwszego moduł monitorujący, nie przesyłał żadnych
informacji do komputera, natomiast na analizatorze stanów logicznych, widać
było zgłoszenie błędu sygnalizowane za pomocą ramki błędu. W drugim przy-
padku na obu urządzeniach monitorujących, widać było poprawne odczyty -
na komputrze pojawiały się przesyłane komunikaty, a na analizatorze widać
było zmianę nadawanago bitu ACK, z recesywnego na dominujący. Zmiana
taka oznacza poprawne odczytanie ramki przez przynajmniej jeden węzeł.
6.10. Wnioski
W trakcie badań, na przykładzie sieci CAN, wykazano możliwości jakie
istnieją w stosowanych protokołach dotyczące poprawy niektórych parame-
trów. Wszystkie przedstawione propozycje umożliwiają skrócenie długości
ramki. W niektórych przypadkach jest to poprawienie rezultatu zarówno
średniego jak i pesymistycznego, w innych przypadkach dotyczy to tylko
wartości średniej. Niestety większość z zaproponowanych zmian nie jest moż-
liwa do implementacji w omawianym standardzie. Jedynie zmiana bitu RB0
zachowała by z nią zgodność, a jej zastosowanie wymaga opracowania nowe-
go układu nadajnika. Uzyskiwane przy tej zmianie wartości porównywanych
parametrów są zbliżone do wartości uzyskiwanych podczas innych zmian.
Rozdział 6. Przykład zastosowania własnej metody... 95
Podczas porównywania parametrów największe zaskoczenie wywołały war-
tości opóźnienia. Otóż okazało się że pomimo skracania długości ramki całko-
witej, zmienność rzadziej spadała w stosunku do innych parametrów, których
poprawa występowała zawsze lub prawie zawsze. Otóż okazało się że bar-
dzo często dużo lepiej wypadają wartości średnie opóźnień, a wiec rzadziej
występują ramki najdłuższe. Natomiast trudniej jest zredukować wartości
pesymistyczne, gdyż często zdarza się że problem wartości pesymistycznej
dotyczy jednej ramki.
Również skrócenie pola DLC, nie ograniczyło w sposób znaczny liczby
wstawek. Więcej korzyści uzyskano ze względu na skrócenie samego nagłów-
ka, niż poprzez ograniczenie występowania bitów dodatkowych, a uzyskany
rezultat był gorszy od innych proponowanych rozwiązań.
Rozdział 7
Wnioski końcowe i podsumowanie
Wyniki niniejszej pracy powodują wyciągnięcie szeregu wniosków, w kon-
tekście wykorzystania zaproponowanej metody, rezultatów jej zastosowania
a także wniosków dotyczących zachowania się wstawek bitowych w ramkach
protokołu CAN. Jednocześnie oprócz metody oceny i ograniczenia liczby
wstawek bitowych, zaprezentowano metodę pomocniczą, wykorzystaną w ce-
lu dokładniejszego i szybszego wyznaczenia wartości średnich i pesymistycz-
nych liczby wstawek bitowych.
W trakcie prowadzonych prac udało się wykazać postawione we wstępie
tezy. Zaprezentowana metoda oceny i poprawy ramek protokołów ze wstaw-
kami (rozdział 5) została następnie zastosowana na przykładowej ramce. Za-
stosowanie tej metody umożliwiło wychwycenie, wskazanie i zweryfikowanie
rozwiązań ograniczających występowanie tzw. „słabych miejsc”. Druga z po-
stawionych tez została potwierdzona podczas stosowania opracowanej meto-
dy. W szczególności dotyczyło to badania zmian wartości pól DLC i RB0
(podrozdział 6.7).
7.1. Wnioski dotyczące przedstawionych metod
W toku prowadzonych prac opracowano dwie metody:
— Metoda oceny i ograniczenia liczby wstawek bitowych;
— Metoda obliczeniowa wyznaczania liczby wstawek bitowych;
Metoda obliczeniowa wyznaczania liczby wstawek bitowych
Jest to opracowane rozwiązanie, mające na celu umożliwienie uzyskania
dokładniejszego oszacowania liczby wstawek bitowych, zmniejszając jedno-
cześnie czas potrzebny do wyznaczenia tych wartości. Założeniem tej metody
jest podzielenie obszaru wstawek bitowych na bloki bitowe. Zastosowanie ta-
Rozdział 7. Wnioski końcowe i podsumowanie 97
kiego podejścia pozwala na ograniczenie czasu potrzebnego do wyznaczenia
liczby wstawek poprzez:
— jednokrotne wyznaczenie wartości bloków niezmienianych w trakcie ba-
dań,
— zastosowanie metod matematycznych dla niektórych bloków,
— wykorzystanie symulacji dla wybranych bloków z różną dokładnością wy-
niku (pełna - przebadanie wszystkich możliwych kombinacji lub częściowa
- wyłonienie próbki losowej)
Zastosowanie tej metody jest nieocenione w przypadku wyznaczania war-
tości średnich, gdzie stosowanie metod matematycznych nie może mieć za-
stosowania, lub opracowanie odpowiedniego wzorca jest bardzo złożone. Na-
tomiast dla wyznaczania wartości pesymistycznych, w porównaniu z metodą
w oparciu o algorytm postępowania (wstawiania bitów), uzyskany wynik nie
jest zależny tylko od długości ale również od stosowanych kodów. Zastoso-
wanie podziału obszaru wstawek przyspiesza ocenę protokołu jak i wprowa-
dzonych zmian pod kątem wartości pesymistycznej liczby wstawek bitowych,
dla parametrów zastosowanych do oceny ramki przykładowego protokołu.
Metoda oceny i ograniczenia liczby wstawek bitowych
Metoda główna składa się sześciu kroków w dwóch etapach:
1. wyznaczenie słabych punktów protokołu,
2. wprowadzeni modyfikacji do ramek.
Etapy te poprzedzone są wytypowanie interesujących parametrów i częściowo
od nich zależne są przeprowadzane eksperymenty. W trakcie oceny przykła-
dowej ramki (rozdział 6) okazało się że parametr jakim jest zmienność jest
nieodpowiedni. Ze względu na sposób jego wyznaczania, wartość zmienno-
ści może wzrosnąć, pomimo zmniejszenia ogólnej liczby wystąpień wstawek
bitowych, poprzez pozostanie bez zmian wartości pesymistycznej.
Sama metoda umożliwia wprowadzanie modyfikacji zarówno na pozio-
mie warstwy łącza danych jak i aplikacyjnej (np. kodowanie przesyłanych
danych, odpowiedni dobór wartości pól nagłówka, zmiana kodowania niektó-
rych z wykorzystywanych pól). Wyznaczenie tzw. „słabych miejsc” zaleca się
wykonać poprzez sporządzenie histogramu wystąpień wstawek bitowych po
bitach ramki, badając losowo wybrane lub wszystkie ramki. Takie rozwią-
zanie można zastąpić analizą teoretyczną, jednak duża zależność od wcze-
śniejszych danych oraz wstawek znacznie utrudnia przeprowadzenie takiej
oceny. W tracie badania przykładowego protokołu okazało się, że w niektó-
Rozdział 7. Wnioski końcowe i podsumowanie 98
rych implementacjach zmiana jednego bitu może spowodować wzrost liczby
wstawek z wartości minimalnych (zazwyczaj 0) do wartości maksymalnych
liczby wystąpień wstawek.
Wykonane eksperymenty pozwalają stwierdzić, że omawiana metoda umoż-
liwia:
— badanie tworzonych protokołów,
— testowanie już dostępnych rozwiązań,
— testowanie konkretnych implementacji.
W zależności od tego co poddajemy analizie, musimy dobierać odpowiednie
rozwiązania i zakres symulacji. Gdy analizujemy zachowanie się ramki dla
dowolnych danych (zastosowanie pierwsze i drugie), badania koncentrują się
na obszarze nagłówka. Wynika to z występowania dopuszczalnych warto-
ści np. w polu danych, które zazwyczaj są nieokreślone (mogą występować
wszystkie kombinacje bitów). Inaczej jest w nagłówku, gdzie wartości pól
mają zakres ograniczony lub występują inne zależności (np: wystąpienie pew-
nej wartości jednego pola determinuje wystąpienie pewnej wartości w innym
polu).
Proces ograniczania wstawek bitowych na poziomie łącza danych wymaga
dobrej znajomości działania mechanizmu i modyfikowanego protokołu. Nato-
miast podczas testów i poprawy konkretnej implementacji, zazwyczaj wyma-
gane jest badanie symulacyjne całego obszaru wstawek. W tym przypadku
możliwe jest poszukiwanie również możliwości ograniczenia liczby wstawek
bitowych w warstwie aplikacyjnej z wykorzystaniem metod przedstawionych
w rozdziale 4.
7.2. Wnioski dotyczące CAN
Proces przeprowadzania zmniejszenia występowania wstawek bitowych
zaprezentowano na przykładzie ramki protokołu CAN. Ponieważ jak przed-
stawiono w analizie literaturowej, możliwości redukcji wstawek w warstwie
aplikacyjnej są dobrze omówione, opracowaną metodę zastosowano w celu
ograniczenia wstawek poprzez modyfikacje warstwy łącza danych.
Przy tej analizie metoda podziału ramki w celu uproszczenia i przyspie-
szenia obliczeń, okazała się bardzo przydatna. Dla sieci CAN znacząco ograni-
czyła czas potrzebny na przebadanie wszystkich ramek, wyznaczenie metodą
symulacyjną liczby wstawek tylko dla nagłówka. Dla pozostałych elementów
Rozdział 7. Wnioski końcowe i podsumowanie 99
zabezpieczanych również przez ten mechanizm można było zastosować wzór
na bazie algorytmu.
Po wykonaniu histogramu (rysunek 6.3), okazało się że w nagłówku ramki
występuje jeden „słaby punkt”. Na tej podstawie autor zaproponował prze-
analizowanie następujących zmian:
— ustawienie bitu RB0 na wartość 1;
— zmiana kodowania obszaru DLC;
— skrócenie pola DLC;
— przesyłanie danych w ramce zdalnego żądania;
Każda z tych propozycji poprzedzona została analizą wpływu na zakres do-
stępnych „usług”. Po wykonaniu pozostałych kroków na przedstawionych
modyfikacjach uzyskano następującą liczbę wstawek w nagłówku (rysunki 7.1
i 7.2). Modyfikacje te umożliwiły skrócenie przesyłanej ramki maksymalnie
o 1 bit. Należy jednak zwrócić uwagę, że poprawę tą uzyskano zmieniając
jedno z pól wycinka ramki o długości 7 bitów. W konsekwencji umożliwia to
w niektórych przypadkach skrócenie całkowitej długości ramki o ponad 2%
(dotyczy to ramek najkrótszych). Niestety w trakcie prac okazało się, że nie
zawsze da się wprowadzić zmiany w strukturze ramki zgodne ze standardem.
Czasami niezbędne jest przeprojektowanie protokołu aby uzyskać oczekiwane
rezultaty.
Wykonując różne zmiany zaobserwowano ciekawe zachowanie samego me-
chanizmu wstawek bitowych. Najważniejszą z nich było stwierdzenie, że skra-
canie pola nie zawsze ograniczy liczbę wstawek bitowych (wyniki dla skróce-
nia pola DLC). Więcej korzyści przyniosło skrócenie długości nagłówka, niż
ograniczenie liczby wstawek bitowych przez nie spowodowane. A ten ostatni
parametr był gorszy od innych analizowanych w tej pracy rozwiązań.
Bardzo ciekawymi rozwiązaniami okazały się natomiast zmiana kodowa-
nia RB0. Jest to ”bit zarezerwowany” do przyszłych zmian. Jednak od ponad
15 lat żadna zmiana nie została wprowadzona, a pozycja obecnego standardu
jest na tyle stabilna (powszechność) oraz prowadzone prace nad następnymi
rozwiązaniami (protokołami), że kolejne zmiany wydają się być mało praw-
dopodobne. Z tych względów zmiana wspomnianego bitu może okazać się do-
brym rozwiązaniem. Zapewnia jednakową liczbę identyfikatorów dla których
w nagłówku występuje taka sama liczba wstawek, niezależnie od długości
pola danych. Przy niektórych wartościach DLC poprawie uległy wszystkie
wartości (optymistyczne, średnie i pesymistyczne), a dla pozostałych średnie
i pesymistyczne. Jednocześnie rozwiązanie jako jedyne z przedstawionych jest
Rozdział 7. Wnioski końcowe i podsumowanie 100
(a) Zmiana bitu RB0 (b) Zmiana kodowania pola DLC
(c) Skrócenie pola DLC (d) Dane w ramce RTR
Rysunek 7.1. Liczba nagłówków z określoną wartością wstawek bitowych, zależnie
od wartości identyfikatora, dla ramek standardowych
(a) Zmiana bitu RB0 (b) Zmiana kodowania pola DLC
(c) Skrócenie pola DLC (d) Dane w ramce RTR
Rysunek 7.2. Liczba nagłówków z określoną wartością wstawek bitowych, zależnie
od wartości identyfikatora, dla ramek rozszerzonych
Rozdział 7. Wnioski końcowe i podsumowanie 101
w pełni kompatybilne z obecnym standardem, co zostało wykazane poprzez
omówiony eksperyment (opis testów - rozdział 6.7.2, kod programu - załącz-
nik F).
Rozwiązaniem dobrym, choć niezgodnym z obowiązującym standardem,
okazała się zmiana kodowania obszaru DLC. Ponieważ na 4 bitach przesyłane
jest 9 z 16 stanów. Dlatego możliwa jest zmiana. Przebadanie nagłówka ze
wszystkimi możliwymi kodami ujawniło, że dla kodów o wartości 8 do 14
uzyskano najkorzystniejsze rezultaty liczby wstawek.
7.2.1. Zalecenia projektowe dotyczące protokołu CAN
Przeprowadzony eksperyment zastosowania opracowanej metody na ram-
ce CAN zaowocował dołożenie do już opisanych zaleceń, kolejnego dotyczą-
cego ramek RTR. Dotychczas w literaturze zwracano uwagę na znaczenie
identyfikatora przy przesyłaniu ramek. Na podstawie uzyskanych rezultatów
przesyłania danych w ramce zdalnego żądania oraz zachowania się ramki
RTR przy ustawieniu długości pola DLC (niezależnie od wartości pola DLC,
w ramce RTR pola danych nie występuje) można zalecić aby w miarę moż-
liwości (gdy wartość pola DLC nie ma znaczenia) przy przesyłaniu ramek
RTR korzystać z ustawionego pola DLC na długość pola danych większą
bądź równą 2. Gdyż właśnie dopiero od tych wartości DLC w nagłówku
istnieją identyfikatory, dla których nie wystąpi ani jedna wstawka bitowa.
7.3. Oryginalny dorobek
Autor za swój oryginalny dorobek uważa w szczególności:
1. metodę oceny i ograniczenia liczby wstawek bitowych;
2. metodę wyznaczania lepszego przybliżenia wartości średnich i pesymi-
stycznych;
3. wskazanie przyczyn nadmiernego występowania wstawek, dla obszaru na-
główka ramki protokołu przemysłowego;
4. wskazanie możliwości zastosowania modyfikacji RB0, będącej zgodnym ze
standardem CAN;
5. stosowanie w ramkach zdalnego żądania wyższych wartości pól DLC, po-
mimo zawsze zerowej długości pola danych;
6. spostrzeżenia dotyczącego wykorzystania zmienności, jako kryterium oce-
ny protokołu poddawanego modyfikacji;
Rozdział 7. Wnioski końcowe i podsumowanie 102
Zarówno sam schemat postępowania jak i konkretne zmiany mogą po-
służyć w dalszych pracach. Zastosowany schemat sprawdził się w przypadku
weryfikacji poprawności konstrukcji ramki, a zaproponowane zmiany posłużą
jako krok do opracowania własnego protokołu komunikacyjnego o wyższych
parametrach czasowych a podobnym modelu adresacji i transmisji danych.
Spis rysunków
1.1. Zależności pomiędzy długością ciągu zabronionego a polami sterującymi 10
2.1. Abstrakcyjne wyobrażenie elementów systemu komputerowego [63] . . 15
2.2. System czasu rzeczywistego i jego otoczenie [68] . . . . . . . . . . . . 19
2.3. System o ostrych wymaganiach czasowych [22, 80] . . . . . . . . . . . 19
2.4. System o łagodnych wymaganiach czasowych [22, 80] . . . . . . . . . 20
2.5. System o łagodnych wymaganiach czasowych [22, 80] . . . . . . . . . 20
2.6. Podstawowy cykl pracy sterownika jednoprocesorowego [29] . . . . . . 23
2.7. Czas transmisji ramki [66] . . . . . . . . . . . . . . . . . . . . . . . . . 24
2.8. Model przemysłowego systemu komputerowego [29] . . . . . . . . . . 25
2.9. Model węzła sieci [29] . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
2.10. Model węzła sieci [62] . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
2.11. Cykliczny model węzła sieci [62] . . . . . . . . . . . . . . . . . . . . . 29
2.12. Cykliczny model węzła sieci [62] . . . . . . . . . . . . . . . . . . . . . 30
3.1. Przykład wstawiania i usuwania bitów w celu uniknięcia wystąpienia
„1111” . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
3.2. Powstanie błędu blokowego po przekłamaniu dwóch bitów [10]. . . . . 38
3.3. Prawdopodobieństwo niewykrycia błędu w zależności od liczby
powstałych przekłamań [74]. . . . . . . . . . . . . . . . . . . . . . . . 39
3.4. Przykłady strumieni danych, powodujących wstawienie największej
liczby wstawek ( a) przy ochronie przed jednego rodzaju wstawkami,
b) przy ochronie przed oboma rodzajami wstawek) . . . . . . . . . . . 40
3.5. Przykładowy podział ramki na część nagłówka, pola danych i sumy
kontrolnej. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
3.6. Przykładowy podział ramki na część nagłówka, pola danych i sumy
kontrolnej. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
4.1. Schemat sieci w samochodzie Volkswagen Passat [14] . . . . . . . . . 45
4.2. Porównanie liczby bitów wstawionych w ramkę z 8 bajtowym polem
danych.[14] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
Spis rysunków 104
5.1. Schemat blokowy postępowania z wykorzystaniem opracowanej
metody[45] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
6.1. Budowa ramki CAN. . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
6.2. Liczba wstawek bitowych, wyznaczona metodą eksperymentalną. . . . 60
6.3. Histogram liczby wstawek bitowych na każdy bit danych. . . . . . . . 62
6.4. Wybrane wartości rozkładu wstawek bitowych po poszczególnych
bitach. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
6.5. Liczba ramek z wyznaczoną wartością wstawek bitowych, zależnie od
wartości identyfikatora . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
6.6. Oczekiwany efekt związany ze zmianą wartości bitu RB0, dla jednego
z przypadków. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
6.7. Oczekiwany efekt związany ze zmianą kodowania, dla jednego z
przypadków. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
6.8. Oczekiwany efekt związany ze zmianą kodowania. . . . . . . . . . . . 75
6.9. Oczekiwany efekt związany z wysyłaniem danych w ramkach zdalnego
żądania, dla jednego z przypadków. . . . . . . . . . . . . . . . . . . . 76
6.10. Liczba ramek z wyznaczoną wartością wstawek bitowych, zależnie od
wartości identyfikatora [33] . . . . . . . . . . . . . . . . . . . . . . . . 77
6.11. Liczba ramek z wyznaczoną wartością wstawek bitowych, zależnie od
wartości identyfikatora [32] . . . . . . . . . . . . . . . . . . . . . . . . 79
6.12. Liczba ramek z wyznaczoną wartością wstawek bitowych, zależnie od
wartości identyfikatora . . . . . . . . . . . . . . . . . . . . . . . . . . 81
6.13. Liczba ramek z wyznaczoną wartością wstawek bitowych, zależnie od
wartości identyfikatora . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
7.1. Liczba nagłówków z określoną wartością wstawek bitowych, zależnie
od wartości identyfikatora, dla ramek standardowych . . . . . . . . . 100
7.2. Liczba nagłówków z określoną wartością wstawek bitowych, zależnie
od wartości identyfikatora, dla ramek rozszerzonych . . . . . . . . . . 100
A.1. Warstwy OSI protokołu CAN . . . . . . . . . . . . . . . . . . . . . . . 118
A.2. Kodowanie NRZ [34] . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119
A.3. Segmenty czasu pojedyńczego bitu [34] . . . . . . . . . . . . . . . . . 120
A.4. Mechanizm wstawiania bitów w sieci CAN [52] . . . . . . . . . . . . . 122
A.5. Rozstrzyganie kolizji . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123
A.6. Budowa ramek informacyjnych sieci CAN [52] . . . . . . . . . . . . . 124
A.7. Model Stanów Węzła sieci CAN [38] . . . . . . . . . . . . . . . . . . . 127
Spis tabel
4.1. Podział liczby nagłówków ze względu na liczbę bitów wstawionych dla
ramek CAN 2.0A. [48] . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
4.2. Procentowy podział liczby nagłówków ze względu na liczbę bitów
wstawionych dla ramek CAN 2.0B. [48] . . . . . . . . . . . . . . . . . 48
6.1. Pesymistyczna wartość liczby bitów wstawionych, w zależności od
długości pola danych (BSpes). . . . . . . . . . . . . . . . . . . . . . . 59
6.2. Udział procentowy liczby bitów wstawionych w całkowitej długości
ramki (ramka CAN wraz z bitami wstawionymi bez uwzględnienia w
długości ramki obszaru IFS)(LCp/wIFS). . . . . . . . . . . . . . . . . . 60
6.3. Symulacyjne wartości liczby bitów wstawionych, w zależności od
długości pola danych (BSsim). . . . . . . . . . . . . . . . . . . . . . . 60
6.4. Pesymistyczna wartość liczby bitów wstawionych, w zależności
od długości pola danych, z wykorzystaniem badań dotyczących
pesymistycznych wartości liczby wstawek bitowych nagłówka CAN). . 61
6.5. Średnia liczba wstawek bitowych w obszarze danych . . . . . . . . . . 64
6.6. Średnia liczba wstawek bitowych w obszarze nagłówka (BSHeaderavg) . 64
6.7. Średnia liczba wstawek bitowych w ramce CAN(BSavg) . . . . . . . . 66
6.8. Wartości średnie i pesymistyczne sprawności dla ramki CAN . . . . . 67
6.9. Wartości średnie opóźnień w sieci CAN (Davg) . . . . . . . . . . . . . 67
6.10. Maksymalne wartości opóźnień w sieci CAN (Dmax) . . . . . . . . . . 68
6.11. Zmienność maksymalna w sieci CAN, dla ramek o różnej długości
(Jmax) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
6.12. Zawartość nagłówka ramki CAN . . . . . . . . . . . . . . . . . . . . . 70
6.13. Tablica kodów długości pola danych w obszarze DLC [59] . . . . . . . 71
6.14. Średnia liczba wstawek bitowych w nagłówku ramki CAN ze zmianą
bitu RB0(BSavg) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
6.15. Wyznaczone zmiany całkowitej długości ramki poprzez zastosowanie
zmiany wartości bitu RB0 . . . . . . . . . . . . . . . . . . . . . . . . 78
Spis tabel 106
6.16. Średnia liczba wstawek bitowych w nagłówku ramki CAN dla wartości
DLC z przedziału ∈ 〈9 . . . 15〉) . . . . . . . . . . . . . . . . . . . . . . 78
6.17. Proponowane zmiany w kodowaniu długości pola danych) . . . . . . . 80
6.18. Wyznaczone zmiany całkowitej długości ramki poprzez zastosowanie
zmiany kodowania obszaru DLC . . . . . . . . . . . . . . . . . . . . . 80
6.19. Średnia liczba wstawek bitowych w nagłówku ramki CAN ze
skróconym polem DLC(BSavg) . . . . . . . . . . . . . . . . . . . . . . 82
6.20. Wyznaczone zmiany całkowitej długości ramki poprzez zastosowanie
skrócenia pola DLC . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
6.21. Średnia liczba wstawek bitowych w nagłówku ramki CAN ze
skróconym polem DLC . . . . . . . . . . . . . . . . . . . . . . . . . . 84
6.22. Wyznaczone zmiany całkowitej długości ramki poprzez zastosowanie
przesyłania danych w ramce zdalnego żądania . . . . . . . . . . . . . 84
6.23. Wartości średnie sprawności dla ramki CAN ze zmienioną wartością
bitu RB0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
6.24. Wartości średnie opóźnień w sieci CAN ze zmienioną wartością bitu
RB0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
6.25. Maksymalne wartości opóźnień w sieci CAN ze zmienioną wartością
bitu RB0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
6.26. Różnica wartości opóźnień ramki w sieci CAN oraz ramki ze zmienioną
wartością bitu RB0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
6.27. Zmienność maksymalna w sieci CAN przy zastosowaniu ramek ze
zmienioną wartością bitu RB0 . . . . . . . . . . . . . . . . . . . . . . 86
6.28. Wartości średnie sprawności dla ramki CAN ze zmienionym
kodowaniem obszaru DLC . . . . . . . . . . . . . . . . . . . . . . . . . 87
6.29. Wartości średnie opóźnień w sieci CAN ze zmienionym kodowaniem
obszaru DLC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
6.30. Różnica wartości opóźnień ramki w sieci CAN oraz ramki ze zmienioną
wartością bitu RB0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
6.31. Zmienność maksymalna w sieci CAN z zastosowaniem ramek o
zmienionym kodowaniu obszaru DLC . . . . . . . . . . . . . . . . . . 88
6.32. Wartości średnie sprawności dla ramki CAN ze skróconym polem DLC 88
6.33. Wartości średnie opóźnień w sieci CAN ze skróconym polem DLC . . 88
6.34. Różnica wartości opóźnień ramki w sieci CAN oraz ramki ze
skróconym polem DLC . . . . . . . . . . . . . . . . . . . . . . . . . . 89
6.35. Zmienność maksymalna w sieci CAN przy zastosowaniu ramek
ze skróconym polem DLC . . . . . . . . . . . . . . . . . . . . . . . . . 89
6.36. Wartości średnie sprawności dla ramki CAN poprzez zastosowanie
przesyłania danych w ramce zdalnego żądania . . . . . . . . . . . . . 89
Spis tabel 107
6.37. Wartości średnie opóźnień w sieci CAN poprzez zastosowanie
przesyłania danych w ramce zdalnego żądania . . . . . . . . . . . . . 90
6.38. Różnica wartości opóźnień ramki w sieci CAN przy przesyłaniu
danych w ramce zdalnego żądania . . . . . . . . . . . . . . . . . . . . 90
6.39. Maksymalne wartości opóźnień w sieci CAN przy przesyłaniu danych
w ramce zdalnego żądania . . . . . . . . . . . . . . . . . . . . . . . . . 90
6.40. Zmienność maksymalna w sieci CAN przy przesyłaniu danych w
ramce zdalnego żądania . . . . . . . . . . . . . . . . . . . . . . . . . . 91
A.1. Maksymalna prędkość w zależności od długości magistrali [34] . . . . 120
Bibliografia
[1] IEEE/ANSI Std 729. Glossary of Software Enginnering Terminology. IEEE
Computer Society Press, Los Alamitos, California, 1984.
[2] Marian Adamski. Bezposrednia implementacja sieci petriego w reprogramo-
walnych układach cyfrowych. II Krajowa Konferencja - Reprogramowalne
Układy Cyfrowe RUC’2000, strony 131–138, Szczecin, Kwiecień 2000.
[3] Shri Amit, Prakash Singh. Analysis of optimization techniques of can proto-
col bandwidth utilization. National Conference on Trends in computational
techniques in engineering, Longowal, 2004.
[4] Atmel Corporation. Microcontroller with LIN Transceiver, 5V regulator
and Watchdog, 2007. [dostęp: 2010-04-10] http://www.atmel.com/dyn/
resources/prod_documents/doc9111.pdf.
[5] Sharon Aviran, Paul H. Siegel, Jack Keil Wolf. An improvement to the
bit stuffing algorithm. IEEE Transactions on information theory, strony
2885–2891, 2005. [dostęp: 2010-04-10] http://citeseerx.ist.psu.edu/
viewdoc/download?doi=10.1.1.59.166&rep=rep1&type=pdf.
[6] Manuel Barranco, Julian Proenza, Guillermo Rodriguez-Navas, Luis Almeida.
An active star topology for improving fault confinement in can networks.
IEEE Transactions on Industrial Informatics, 2(2):78–85, Maj 2006.
[7] Dariusz Borkowski. Różnorodność i próby ujednolicenia przemysłowych sie-
ci kontrolno-pomiarowych. Internet. [dostpęp: 2010-04-10] http://zm219.
zmet.agh.edu.pl/~bednar/praca/PSKP.pdf.
[8] Gianluca Cena, Adriano Valenzano. An improved can fieldbus for industrial
applications. IEEE Transactions on Industrial Electronics, 44(4):553–564,
Sierpień 1997. [dostęp: 2010-04-10] http://ieeexplore.ieee.org/iel1/
41/13284/00605633.pdf?tp=&isnumber=13284&arnumber=605633.
[9] Gianluca Cena, Adriano Valenzano. Fastcan: High-performance enhan-
ced can-like network. IEEE Transactions on Industrial Electronics,
42(2):951–963, Sierpień 2000. [dostęp: 2010-04-10] http://ieeexplore.
ieee.org/iel5/41/18639/00857976.pdf.
[10] Joachim Charzinski. Performance of the error detection mechanisms in can.
Bibliografia 109
Proceedings of the 1st International CAN Conference, strony 1/20–1/29,
Wrzesień 1994. [dostęp 2008-04-19] http://www.jcho.de/jc/Pubs/cia-94.
pdf.
[11] Yeonjoon Chung, Min Ho Park, Eui Hyun Paik. A qos negotiable service
framework for multimedia services connected through subscriber networks.
Consumer Electronics, 2006. ISCE ’06. 2006 IEEE Tenth International Sym-
posium, strony 1–4, 2006. [dostęp: 2010-04-10] http://ieeexplore.ieee.
org/iel5/11112/35627/01689454.pdf?arnumber=1689454.
[12] Rafał Cupek. Metody wizualizacji rozproszonych procesów przemysłowych.
Praca doktorska, Politechnika Śląska, Gliwice, 1998.
[13] Mirosław Dach, Jan Werewka. Analiza czasów reakcji w systemie
kontrolno-diagnostycznym. X Konferencja SYSTEMY CZASU RZECZY-
WISTEGO, strony 157–168, 2003.
[14] Robert I. Davis, Alan Burns, Reinder J. Bril, Johan J. Lukkien. Controller
area network (can) schedyulability analysis: Refuted, revisited and revised.
Real-Time Systems, wolumen 35, strony 239–272, Kwiecień 2007.
[15] Andrzej Drwal. Zagadnienie podziału na podsieci w systemach rozproszonych
czasu rzeczywistego. V Konferencja SYSTEMY CZASU RZECZYWISTE-
GO, strony 17–28, 1998.
[16] Andrzej Drwal. Analiza rezerwy czasowej pojedyńczego zadania dla sieci
przemysłowej o ostrych ograniczeniach czasowych. VI Konferencja SYSTE-
MY CZASU RZECZYWISTEGO, strony 21–30, 1999.
[17] Dutkiewicz Eryk, Paul Boustead. Analysis of per-flow and aggregate qos
in scalable qos networks. Networks, 1999. (ICON ’99) Proceedings. IEEE
International Conference, strony 289–294, Wrzesień 1999.
[18] John Garney. An analysis of throughput characteristics of universal serial
bus. Internet. [dostęp: 2009-06-13] www.usb.org/developers/whitepapers/
bwpaper2.pdf.
[19] Bur Goode. Voice over internet protocol (voip). Proceedings of
the IEEE, wolumen 90, strony 1495–1517, Wrzesień 2002. [dostęp:
2010-04-10] http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.
1.1.120.9785&rep=rep1&type=pdf.
[20] Mohamed G. Gouda. Modeling and verification of a bit-stuffing proto-
col using communicating finite state machines. Raport instytutowy, De-
partamet of Computer Sciences University of Texas at Austin, Austin, Te-
xas 78712, 1984. [dostęp:2010-04-10] http://www.cs.utexas.edu/ftp/pub/
techreports/tr84-32.pdf.
[21] Inspektor do Spraw Substancji i Preparatów Chemicznych. Zarządzenie nr
11/2003 Inspektora do Spraw Substancji i Preparatów Chemicznych w spra-
Bibliografia 110
wie ustalenia refulaminu kontroli weryfikacji zgodności z zasi Dobrej Praktyki
Laboratoryjnej, 2003. [dostęp 2008-04-19] http://www.chemikalia.gov.pl/
files/regulamin-dpl.pdf.
[22] Mirosław Jedynak, Adam Łączyński. Modelowanie systemów typu rt z
wykorzystaniem uml. Systemy Czasu Rzeczywistego, [dostęp: 2010-04-10]
http://m.jedynak.pl/systemy_czasu_rzeczywistego/referat.pdf.
[23] Piotr Kasprzyk. Badania efektywności rozwiązań sprzętowych i programowych
systemów multimedialnych. Praca doktorska, Politechnika Śląska, Gliwice,
2003.
[24] Bob Kinicki. Bit and byte stuffing. Wykłady z Sieci Komputerowych,
Worcester Polytechnic Institute, Listopad 2004. [dostęp: 2010-04-10] http:
//web.cs.wpi.edu/~rek/Undergrad_Nets/B01/BitByteStuffing.pdf.
[25] Philip Koopman, Tridib Chakravarty. Cyclic redundancy code (crc)
polynomial selection for embedded networks. The International
Conference on Dependable Systems and Networks, 2004. [dostęp:
2010-04-10] http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.
1.1.5.5027&rep=rep1&type=pdf.
[26] Jacek Kowolik. Analiza przydatności protokołu can do realizacji informa-
tycznych systemów przemysłowych. Praca magisterska, Politechnika Śląska,
2007.
[27] Zygmunt Kubiak. Problematyka sieci miejscowej lin. IVX Konferencja SYS-
TEMY CZASU RZECZYWISTEGO, strony 404–412, 2007.
[28] Kvaser. Introduction to the lin bus. Internet. [dostęp 2007-10-23] http:
//www.kvaser.com/can/misc/lin/lin-bus.htm.
[29] Andrzej Kwiecień. Analiza przepływu informacji w komputerowych sieciach
przemysłowych. Studia Informatica, Politechnika Śląska, 2002. [dostęp:
2010-04-10] http://zui.aei.polsl.pl/~zpzi/dokumenty/rhab_AK.pdf.
[30] Andrzej Kwiecień, Piotr Gaj. Kryteria doboru protokołów komunikacyjnych
w sieciach przemysłowych. Studia Informatica, wolumen 22, Gliwice, 2001.
Wydawnictwo Politechniki Śląskiej. [dostęp: 2010-04-10] http://zui.aei.
polsl.pl/~zpzi/publikacje/Piotr01.pdf.
[31] Andrzej Kwiecień, Paweł Moroz. Mechanizmy bezpieczeństwa w przemysło-
wych sieciach komputerowych na przykładzie sieci can. Współczesne aspekty
sieci komputerowych. Tom 1, strony 331–340. Instytut Informatyki, Politech-
nika Śląska w Gliwicach, WKiŁ, 2008.
[32] Andrzej Kwiecień, Paweł Moroz. Redukcja występowania mechanizmu
bit-stuffing poprzez modyfikacje nagłówka - pola dlc. Współczesne aspekty
sieci komputerowych. Tom 1, strony 341–350. Instytut Informatyki, Politech-
nika Śląska w Gliwicach, WKiŁ, 2008.
Bibliografia 111
[33] Andrzej Kwiecień, Paweł Moroz. Wpływ konstrukcji nagłówka na jego dłu-
gość przy stosowaniu mechanizmu wstawiania bitów. Współczesne aspekty
sieci komputerowych. Tom 1, strony 341–350. Instytut Informatyki, Politech-
nika Śląska w Gliwicach, WKiŁ, 2008.
[34] Daniel Mannisto, Mark Dawson. An overview of controller area network
(can) technology. Raport instytutowy, Machine Bus Corporation, November
2003. [dostęp; 2010-04-10] http://www.parallax.com/dl/docs/prod/comm/
cantechovew.pdf.
[35] Yasunori Matsui, Seiji Kihara, Atsushi Mitsuzawa, Stoshi Moriai. An extensi-
ble object model for qos specification in adaptive qos systems. Object-Oriented
Real-Time Distributed Computing, 1999. (ISORC ’99) Proceedings. 2nd IEEE
International Symposium, strony 129–132, 1999.
[36] Zygmunt Mazur, Teresa Mendyk-Krajewska. Bezpieczeństwo systemów te-
leinformatycznych w ujęciu wybranych dokumentów normalizacyjnych. XIV
Konferencja SYSTEMY CZASU RZECZYWISTEGO, strony 265–300, 2007.
[37] Linden McClure. Controller area newtork, 1998. Siemens Microelectro-
nics, Inc., [dostęp: 2008-05-14] http://ece-www.colorado.edu/~mcclurel/
CANPRES.pdf.
[38] MicroChip Technology Inc. MCP2515 Stand-Alone CAN Controller With
SPI Interface, 2007. [dostęp: 2010-04-10] http://ww1.microchip.com/
downloads/en/DeviceDoc/21801d.pdf.
[39] MicroChip Technology Inc. LIN Transceiver with Voltage Regulator,
2008. [dostęp: 2010-04-10] http://ww1.microchip.com/downloads/en/
DeviceDoc/22018e.pdf.
[40] Wojciech Mielczarek. Szeregowe interfejsy cyfrowe. Helion, 1994.
[41] Paweł Moroz. Driver komunikacyjny sieci can dla mikrosterowników z rodziny
avr. Praca magisterska, Politechnika Śląska, 2005.
[42] Paweł Moroz. Optymalizacja długości pakietu w sieci can. Modele i zasto-
sowania systemów czasu rzeczywistego, strony 253–262. Polskie Towarzystwo
Informatyczne, Warszawa, WKiŁ, 2008.
[43] Paweł Moroz. Metoda wyznaczania wartości pesymistycznej liczby wstawek
bitowych. Techniczne i teoretyczne aspekty współczesnych sieci kompute-
rowych, strony 197–202. Instytut Informatyki, Politechnika Śląska Gliwice,
WKiŁ, 2009.
[44] Paweł Moroz. Metoda wyznaczania wartości średnich liczby wstawek bito-
wych dla ramki can. Systemy czasu rzeczywistego. Postępy badań i zastoso-
wania, strony 357–366. Politechnika Warszawska, Wojskowa Akademia Tech-
niczna, Warszawa, WKiŁ, 2009.
[45] Paweł Moroz. Metoda postępowania zastosowana do ograniczenia liczby po-
Bibliografia 112
jawiających się wstawek bitowych, na poziomie warstwy łącza danych. Kon-
ferencja Systemy Czasu Rzeczywistego [Przyjęta do druku], 2010.
[46] Motorola GmbH, Munich, Germany. LIN Specification Package, wydanie 2.0,
September 2003. [dostęp: 2010-04-10] http://www.lin-subbus.de/.
[47] Thomas Nolte. Reducing Pessimism and Increasing Flexibility in the Con-
troller Area Network. Praca doktorska, Vasteras, Sweden, Maj 2003. [dostęp:
2010-04-10] http://www.mrtc.mdh.se/publications/0535.pdf.
[48] Thomas Nolte, Hans Hansson, Christer Norstrom. Minimizing can
response-time jitter by message manipulation. Proceedings of the 8th
IEEE Real-Time and Embedded Technology and Applications Symposium
(RTAS’02), strony 197–206, San Jose, California, USA, Wrzesień 2002. IEEE
Computer Society. [dostęp: 2010-04-10] http://www.mrtc.mdh.se/index.
php?choice=publications&id=0421.
[49] Thomas Nolte, Hans Hansson, Christer Norstrom. Probabilistic worst-case
response-time analysis for the controller area network. Proceedings of the
9th IEEE Real-Time and Embedded Technology and Applications Symposium
(RTAS’03), strony 200–207, Washington, DC (relocated from Toronto), USA,
Maj 2003. IEEE Computer Society. [dostęp: 2010-04-10] http://www.mrtc.
mdh.se/index.php?choice=publications&id=0521.
[50] Thomas Nolte, Hans Hansson, Christer Norstrom, Sasikumar Punnek-
kat. Using bit-stuffing distributions in can analysis. Proceedings of
the 7th IEEE Real-Time and Embedded Systems Workshop (RTES’01),
London, UK, December 2001. IEEE Computer Society. [dostęp:
2010-04-10] http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.
1.1.17.1719&rep=rep1&type=pdf.
[51] Tom Nute. Hcsma - a nearly conflict-free hybrid csma protocol with
high utilization. Computer Network Symposium, strony i–vi, Grudzień
1984. [dostęp: 2010-04-10] http://ieeexplore.ieee.org/iel4/5588/
14962/00680777.pdf?arnumber=680777.
[52] Michael Passemard. Atmel microcontrolers for controller area network (can).
Raport instytutowy, Industrial Control Business Development Director, At-
mel Corporation, 2004. [dostęp: 2010-04-10] http://www.atmel.com/dyn/
resources/prod_documents/doc4069.pdf.
[53] Ryszard Pełka. Mikrokontrolery. Architektura, programowanie, zastosowania.
WKiŁ, Warszawa, 1999.
[54] A. Piórkowski. Optymalizacja transmisji asynchronicznej w systemach rozpro-
szonych czasu rzeczywistego. Praca doktorska, Akademia Górniczo Hutnicza,
Kraków, 2004.
[55] Adam Piórkowski, Jan Werewka. Analiza czasowa komunikacji asynchronicz-
Bibliografia 113
nej systemów rozproszonych czasu rzeczywistego. X Konferencja SYSTEMY
CZASU RZECZYWISTEGO, strony 59–69, 2003.
[56] Roman A. Plaza, Eugeniusz J. Wróbel. Systemy czasu rzeczywistego. Wy-
dawnictwo Naukowo-Techniczne (WNT), Warszawa, 1988.
[57] Rada Unii Europejskiej. Decyzja ramowa rady 2005/222/WSiSW
w sprawie ataków na systemy informatyczne. [dostęp 2008-04-19]
http://eur-lex.europa.eu/LexUriServ/LexUriServ.do?uri=OJ:L:
2005:069:0067:0071:PL:PDF.
[58] Makowitz Rainer, Temple Christopher. Flexray - a communication ne-
twork for automotive control systems. 2006 IEEE International Work-
shop on Factory Communication Systems, strony 207–212, Czerwiec
2006. [pobrane:2010-04-10] http://ieeexplore.ieee.org/iel5/11171/
35963/01704153.pdf?arnumber=1704153.
[59] Robert Bosch GmbH, Stuttgart. CAN Specification, wydanie version 2.0,
09 1991. [dostęp: 2010-04-10] http://www.semiconductors.bosch.de/pdf/
can2spec.pdf.
[60] Krzysztof Sacha. Specyfikacja i projektowanie oprogramowania — część ii.
sieci petriego. Internet. [dostęp 2008-04-28] http://www.ia.pw.edu.pl/
~sacha/petri.html.
[61] F. Sethna, E. Stipidis, F. H. Ali. What lessons can controller area ne-
tworks learn from flexray. Vehicle Power and Propulsion Conference, Wind-
sor, September 2006. [pobrane:2010-04-10] http://ieeexplore.ieee.org/
iel5/4211249/4211250/04211348.pdf?arnumber=4211348.
[62] Marcin Sidzina. Dynamiczne modyfikacje programu aplikacji sterownika swo-
bodnie programowalnego celem zwiększenia częstości wymian komunikatów w
przemysłowych systemach komputerowych. Praca doktorska, Politechnika Ślą-
ska, Gliwice, 2008.
[63] Abraham Silberschatz, Peter B. Galvin, Greg Gagne. Podstawy systemów
operacyjnych. WNT, Warszawa, 2005.
[64] Ian Sommerville. Projektowanie oprogramowania czasu rzeczywistego, 2000.
[65] Mark Sportack. Sieci Komputerowe. Księga Eksperta. Helion, Gliwice, 1999.
[66] William Stallings. Data and Computer Communications. Prentice Hall, New
Jersey, 1997.
[67] Tomasz Szmuc. Modele i metody inżynierii oprogramowania systemów czasu
rzeczywistego. AGH Uczelniane wydawnictwo naukowo dydaktyczne, Kraków,
2001.
[68] Tomasz Szmuc, Gilles Motet. Specyfikacja i projektowanie oprogramowania
systemów czasu rzeczywistego. AGH Uczelniane wydawnictwo naukowo dy-
daktyczne, Kraków, 2000.
Bibliografia 114
[69] Marcin Szpyrka. Badanie zgodności modelu systemu czasu rzeczywistego ze
specyfikacją wymagań. VI Konferencja SYSTEMY CZASU RZECZYWI-
STEGO, strony 42–50, 1999.
[70] Magdalena Szymczyk. Problemy komunikacyjne w systemach czasu rzeczywi-
stego i systemach wbudowanych. Andrzej Kwiecień Piotr Gaj, redaktor, IX
Konferencja SYSTEMY CZASU RZECZYWISTEGO, strony 75–84, Gliwice,
Wrzesień 2002. Instytut Informatyki Politechniki Śląskiej.
[71] Piotr Szymczyk. Systemy operacyjne czasu rzeczywistego. AGH Uczelniane
wydawnictwo naukowo dydaktyczne, Kraków, 2003.
[72] Andrew S. Tanenbaum. Sieci Komputerowe. Helion, Gliwice, 2004.
[73] Andrew S. Tanenbaum. Strukturalna organizacja systemów komputerowych.
Helion, Gliwice, 2006.
[74] Seushiuan Tran, Philip Koopman. Mulit-bit error vulnerabilityies in the con-
troller area network protocol. Raport instytutowy, Carnegie Mellon Uni-
versity, Pittsburg, 1999. [dostęp: 2010-04-10] http://www.ece.cmu.edu/
~koopman/thesis/etran.pdf.
[75] USB Implementers Forum. Universal Serial Bus Specification, wydanie 2.0,
2000. [dostęp: 2010-04-10] http://www.usb.org/developers/docs/usb_20_
052510.zip.
[76] Jan Werewka. Systemy rozproszone sterowania i akwizycji danych. Sterowniki
Programowalne i magistrale miescowe. CCATIE, Kraków, 1998.
[77] Jan Werewka, Sławomir Żaba, Andrzej Drwal. Zagadnienie badania charak-
terystyk czasowych i przepustowości magistral miejscowych. IV Konferencja
SYSTEMY CZASU RZECZYWISTEGO, strony 325–336, Wrocław, 1997.
Oficyna Wydawnicza Politechniki Wrocławskiej.
[78] Zimmermann Werner, Schmidgall Ralf. Magistrale danych w pojazdach. Pro-
tokoły i standardy. Wydawnictwa Komunikacji i Łączności, Warszawa, 2008.
[79] Wikipedia. Komunikacja sterowników plc. Internet. [dostęp 2008-04-07]
http://strony.aster.pl/jarcyk/base/comm.html.
[80] Wikipedia. System czasu rzeczywistego. Internet. [dostęp 2008-04-19] http:
//pl.wikipedia.org/wiki/System_czasu_rzeczywistego.
[81] Wikipedia. System informatyczny. Internet. [dostęp 2008-04-19] http://pl.
wikipedia.org/wiki/System_informatyczny.
[82] Wikipedia. System rozproszony. Internet. [dostęp 2008-04-19] http://pl.
wikipedia.org/wiki/System_rozproszony.
[83] Paweł Wnuk. Definicje i historia systemów komputerowych. Inter-
net. [dostęp 2008-04-19] http://www.iair.mchtr.pw.edu.pl/~pwnuk/
podreczniki/podrecznik_syst_komputerowe/druk.php?id=9.
[84] Wonderware, Irvine. SCADA System – InTouch, wydanie rev. 1.3,
Bibliografia 115
2006. [dostęp: 2010-04-10] http://rose.aei.polsl.pl/~zpzi/_teaching/
Instrukcje/manual_intouch.pdf.
[85] Praca zbiorowa pod red. Zbigniewa Czecha. Programowanie współbieżne: wy-
brane zagadnienia. Wydawnictwo Politechniki Śląskiej, Gliwice, 1999. Skrypt
uczelniany.
[86] S. Zeadally, F. Siddiqui, P. Kubher. Voice over ip in intranet and internet envi-
ronments. IEE Proceedings - Comunications, wolumen 151, strony 263–269,
Czerwiec 2004. [dostęp: 2010-04-10] http://ieeexplore.ieee.org/stamp/
stamp.jsp?arnumber=01309780.
[87] Bartłomiej Zieliński. Ocena efektywności protokołu ax.25. Współczesne
aspekty sieci komputerowych. Tom 1, strony 127–136. Instytut Informatyki,
Politechnika Śląska Gliwice, WKiŁ, 2008.
Dodatek A
Opis protokołu Controller Area
Network
Przykładem protokołu, dla którego występuje omówiony we wstępie pro-
blem jest Controller Area Network (CAN). Jest to protokół sieciowy prze-
znaczony do realizacji taniej i efektywnej komunikacji pomiędzy procesorami
rozproszonego systemu komputerowego. Opracowany został w związku z mi-
niaturyzacją procesorów oraz zwiększeniem ich zastosowania w systemach
kontroli i sterowania elementów pojazdów mechanicznych. Obecnie spotkać je
możemy w systemach sterowania silnikiem, w układach aktywnego zawiesze-
nia, systemach przeciwpoślizgowych ABS, układach sterowania oświetleniem,
sterownikach poduszek powietrznych, klimatyzacji i układach zabezpieczają-
cych przed kradzieżą i włamaniem [53]. Wzrost liczby stosowanych układów
spowodował nie wyobrażalny przyrost połączeń pomiędzy poszczególnymi
układami. Niezbędne okazało się opracowanie sposobu wymiany informacji
pomiędzy układami umożliwiający zmniejszenie całkowitej długości wyko-
rzystywanego okablowania. Jednocześnie sieć ta miała spełniać wygórowane
wymagania czasowe.
Pomysł firmy Robert Bosch GmbH i firmy Intel polegał na stworzeniu bar-
dzo prostej sieci wykorzystującej połączenie magistralowe. Zarządzenie siecią
nie wymaga węzła sterującego, nie występują również złożone algorytmy od-
twarzania żetonu, a wszystkie węzły mają jednakowy dostęp do medium.
Zastosowanie takiego protokołu powoduje uzyskanie większej efektywności
transmisji, a przesyłanie informacji pomiędzy węzłami za pomocą magistrali
pozwala zredukować długość przewodów w niektórych przypadkach nawet
o 90%. Brak centralnego węzła umożliwia proste dołączanie kolejnych urzą-
dzeń bez konieczności rekonfiguracji całej sieci.
Zazwyczaj do transmisji wykorzystywana jest para skręconych przewo-
dów, umożliwiająca transmisję szeregową. Ze względów fizycznych (czasu
propagacji), prędkość transmisji jest związana z długością magistrali. Gdy
węzeł chce przesłać komunikat musi poczekać na wolne łącze, a transmi-
Dodatek A. Opis protokołu Controller Area Network 117
towana wiadomość jest dostępna dla wszystkich węzłów. Zawartość ramki
rozróżniana jest poprzez identyfikator, dzieki czemu każdy węzeł może fil-
trować przesyłane wiadomości i odczytywać tylko te wiadomości, które są
do niego skierowane. W protokołach, gdzie wszystkie węzły mają jednakowy
dostęp do magistrali niezbędne jest opracowanie mechanizmu rozstrzygania
kolizji. W tym przypadku zastosowano bezstratny mechanizm dla CSMA,
co spowodowało traktowanie identyfikatora jako priorytetu wiadomości.
Do rozwoju tego standardu przyczyniła się budowa protokołu umożliwia-
jąca tworzenie własnej warstwy aplikacyjnej, dzieki czemu w początkowym
okresie powstało bardzo dużo różnych opracowań. W efekcie w latach 90-tych
podjęto prace nad opracowaniem kilku standardów (CANOpen, SDS, Devi-
ceNet).
A.1. Historia
Prace nad siecią CAN rozpoczęły się w 1983 roku [14], a samą sieć po raz
pierwszy zaprezentowana w 1986 roku na konferencji SAE (ang. Society of
Automotive Engineers) w Detroit. Bardzo szybko bo już rok później opra-
cowano pierwsze kontrolery - Intel (82526) i Philips (82C200). Pierwszy raz
sieć CAN została wykorzystana przez Mercedesa S-klasy wyprodukowanego
w 1991 roku. W początkowym okresie rozwoju użytkownicy tworzyli własne
protokoły warstwy aplikacyjnej, przez co powstała szeroka gama rozwiązań.
Niektóre z nich osiągnęły rangę standardów narodowych lub nawet między-
narodowych. W roku 1992 zawiązało się stowarzyszenie CiA (ang. Can in
Automation), a w kolejnym roku Międzynarodowa Organizacja Standaryza-
cji (ang. International Standards Organization) opublikowała zatwierdzony
standard, nadając mu numer 11898 [34]. Opracowany protokół przewidywał
wymianę informacji wyzwalaną zdarzeniami. Rozwój i coraz szersze wyko-
rzystanie protokołu spowodował konieczność opracowania kolejnego standar-
du, który byłby w stanie sprostać coraz ostrzejszym wymaganiom czaso-
wym. Efektem było opracowanie i opublikowanie w 2000 roku standardu
ISO 11898-4, zawierającego opis standardu TTCAN (ang. Time Triggered
CAN ).
Dodatek A. Opis protokołu Controller Area Network 118
A.2. Model OSI dla sieci CAN
W związku z charakterem sieci - jego otwartą budową - brakiem złożonej
struktury sieciowej, jak ma to miejsce na przykład w sieci Ethernet, możliwe
jest zredukowanie liczby warstw do trzech: fizycznej, łącza danych i aplika-
cyjnej (rysunek A.1). Dodatkową zaletą pominięcia niektórych warstw jest
zmniejszenie opóźnienia przez nie generowanego.
Rysunek A.1. Warstwy OSI protokołu CAN
Standard zatwierdzony przez organizację OSI opisuje parametry tylko
dwóch najniższych warstw, a o zawartości warstwy aplikacyjnej decyduje
projektant systemu.
A.2.1. Warstwa Fizyczna
Warstwa fizyczna odpowiada za realizację połączenia pomiędzy węzłami.
Dotyczy to zarówno wyboru medium transmisyjnego jak i sposobu kodowa-
nia. Nadajnik tłumaczy postać cyfrową otrzymaną z warstwy 2 i przekłada
ją na postać analogową, zależną od wykorzystywanego medium. U odbiorcy
wartwa ta dokonuje procesu odwrotnego i odczytane stany na łączu zamienia
na postać cyfrową. Dla sieci CAN, standard (ISO-11898-1) w minimalny spo-
sób opisuje medium transmisyjne. Świadczą o tym dostępne rozwiązania wy-
korzystujące przewód miedziany, światłowód i fale radiowe. Szersze omówie-
nie poszczególnych standardów kodowania informacji oraz rodzaju medium
transmisyjnego zawierają kolejne dokumenty standaryzacyjne: ISO-11898-2
(ang. High speed-CAN ) i ISO-11898-3 (ang. Fault Tolerant CAN ).
Dla najpopularniejszego rozwiązania - High Speed CAN - określona jest
transmisja z wykorzystaniem przewodu dwużyłowego. W nim przeprowadza-
Dodatek A. Opis protokołu Controller Area Network 119
na jest transmisja różnicowa, powodująca zmniejszenie prawdopodobieństwa
przekłamania informacji.
Reprezentacja bitów
Istnieje kilka rodzajów kodowania informacji w łączu (Non Return to
Zero, Manchester, 4b5b). Każde z nich posiada pewne wady jak i zalety.
W stosowanej przy transmisji w sieci CAN metodzie NRZ (rysunek A.2)
trudno jest rozróżnić liczbę takich samych bitów. Jedyną możliwością jest
bazowanie na wyliczeniach lokalnego zegara taktującego. Niestety nie jest
możliwe utrzymanie synchronizacji dwóch zegarów przez bardzo długi czas.
Dlatego niezbędna jest co pewien okres czasu tak zwana resynchronizacja,
czyli wymuszenie występowania w tych samych chwilach zmian stanów zegara
taktującego - zazwyczaj do nadawcy wiadomości.
Rysunek A.2. Kodowanie NRZ [34]
Na łączu rozróżniamy dwa stany: recesywny (logiczna 1) i dominujący
(logiczne 0). W zależności od rodzaju sieci CAN, występują różne metody za-
miany informacji na stany łącza. Przy transmisji wykorzystującej High Speed
CAN stan recesywny odpowiada wartości napięcia na obu liniach (CAN L
i CAN H) równemu 2.5V, a stan dominujący gdy napięcie na linii CAN L
wynosi 1.5V a na CAN H odpowiednio 3.5V. Standardzie Fault Tolerant różni
się jedynie wartościami poszczególnych linii w stanie dominującym (CAN H
= 0 i CAN L = 5). Dzięki większym różnicom w wartości sygnału na liniach
możliwa sjest poprawna transmisja, nawet przy uszkodzeniu magistrali.
Prędkość transmisji
Bardzo ważną rolę odgrywają własności fizyczne medium, które jest wyko-
rzystywane. Przy każdej transmisji niezbędne jest uwzględnienie parametru
jakim jest czas propagacji (ang. latency). Założenia sieci wymagają, że węzeł
Dodatek A. Opis protokołu Controller Area Network 120
może rozpocząć nadawanie kolejnego bitu dopiero po ustaleniu stanu na łą-
czu. Sytuacja taka ma miejsce dopiero po podwójnym czasie przejścia sygnału
przez magistrale. Im dłuższa magistrala tym mniejsza prędkość transmisji
(tabela A.1).
Długość Prędkość Transmisji
40 m 1000 kbps
100 m 500 kbps
250 m 250 kbps
500 m 125 kbps
1000 m 50 kbps
2500 m 20 kbps
5000 m 10 kbps
Tabela A.1. Maksymalna prędkość w zależności od długości magistrali [34]
Bit Timing i Synchronizacja
Innym zjawiskiem wpływającym na konstrukcję protokołu jest osiąganie
stanu ustalonego. Uzyskanie tego stanu, jest zależne od medium i środowiska
w jakim się znajduje. Aby dostosować działanie protokołu do konkretnego
środowiska każdy bit podzielony jest na cztery segmenty (rysunek A.3).
Rysunek A.3. Segmenty czasu pojedyńczego bitu [34]
Dodatek A. Opis protokołu Controller Area Network 121
Poszczególne segmenty podzielone są na mniejsze jednostki zwane kwan-
tami czasu (TQ). Każdy segment opisuje się za pomocą ustalanej liczby
kwantów czasu, dzięki czemu możliwe jest modyfikowanie czasu trwania po-
szczególnych segmentów, dając możliwość dobrania optymalnego momentu
próbkowania.
— Sync - segment synchronizacji, rozpoczyna każdy bit pojawiający się na
magistrali. Węzły odbiorcze oczekują w tym czasie rozpoczęcia nadawania
kolejnego bitu. W przypadku wystąpienia opóźnienia wyznaczany jest
błąd fazy. Czas trwania segmentu synchronizacji wynosi 1 TQ.
— Prop-seq - segment propagacji, opóźnia moment próbkowania magistrali
przez węzeł odbiorczy, umożliwiając propagację sygnału w linii. Wszyst-
kie węzły prowadzą w tym czasie nasłuch łącza po to, aby wykryć wy-
stępowanie kolizji. Czas trwania powinien wynosić podwojone opóźnienie
pomiędzy dwoma najbardziej oddalonymi węzłami. Jego wartość zgodnie
ze specyfikacją może wynosić od 1 do 8 TQ.
— Phase 1 - segment kompensacji błędu fazy 1, pozwala na opóźnienie mo-
mentu próbkowania w przypadku, gdy nadajnik jest wolniejszy od odbior-
nika. Próbkowanie linii przez odbiornik odbywa się w ostatnim kwancie
czasu. Czas trwania wynosi od 1 do 8 TQ.
— Phase 2 - segment kompensacji błędu fazy 2, wykorzystywany jest do skra-
cania długości bitu w przypadku, gdy nadajnik jest taktowany szybszym
zegarem. W tej fazie również może wystąpić od 1 do 8 TQ.
Wspomniano już o problemie związanym z synchronizacją zegarów. Węzły
sieci synchronizują się z nadawcą przy każdym przejściu z bitu recesywnego
na dominujący. Przy transmisji wykorzystywane są dwa mechanizmy:
— synchronizacji (ang. hard synchronization), wywoływany przez bit SOF.
— resynchronizacji, występujący przy każdym przejściu stanu ramki z rece-
sywnego na dominujący.
Synchronizacja zapewniona jest na początku każdej ramki. Natomiast aby
zagwarantować pewien maksymalny czas, po którym nastąpi resynchroniza-
cja wprowadzono mechanizm wstawiania bitów (ang. Bit-stuffing).
Wstawianie bitów
Mechanizm wstawiania bitów (ang. bit-stuffing), oprócz zapewnienia syn-
chronizacji, został wykorzystany w sieci CAN dla uniknięcia wystąpienia
ciągu, będącego sygnałem o wykryciu błędu transmisji przez dowolny wę-
Dodatek A. Opis protokołu Controller Area Network 122
zeł w sieci. Polega to na uniemożliwieniu wystąpienia ciągu 6 jednakowych
stanów poprzez wstawienie bitu komplementarnego po 5 takich samych war-
tościach. Działanie przedstawiono na rysunku A.4. Wstawianie bitów wyko-
Rysunek A.4. Mechanizm wstawiania bitów w sieci CAN [52]
nywane jest po stronie nadawczej w warstwie fizycznej. Mechanizm odwrot-
ny, nazywany destuffing, odbywa się we wszystkich odbironikach podczas
odczytu informacji z łącza. Wykorzystanie mechanizmu wstawiania bitów
powoduje obniżenie sprawności protokołu (rozdział 3).
Przyjęte długości ciągów zabezpieczanych powodują, że resynchronizacja
nastąpi najpóźniej co 10 bitwów danych, lub co 11 bitów w łączu.
A.2.2. Warstwa łącza danych
Głównym zadaniem warstwy łącza danych jest przekształcenie łącza trans-
misyjnego w linię, która dla wyższych warstw będzie sprawiać wrażenie wol-
nej od błędów [72]. W tym celu warstwa ta musi zostać uzbrojona w pewne
mechazmy: szeregowania paczek, kontroli poprawności oraz reagowania na
zdarzenia w łączu. Za szeregowanie informacji odpowiedzialne są mechanizmy
dostępu do łacza danych oraz mechanizmy rozstrzygania kolizji. Po wysła-
niu, a w szczególności po odebraniu informacji, niezbędne jest sprawdzenie
poprawności otrzymanej informacji. Z tego powodu każdy protokół posia-
da zaimplementowane specjalne mechanizmy (w tym przypadku aż 5). Gdy
węzeł na podstawie tych zaasad wykryje, że ramka jest niepoprawna wte-
dy taki odbiorca, poprzez wysłanie ramki błędu, powiadamia o tym fakcie
wszystkie pozostałe węzły w szczególności nadawcę. Do tego wykorzystywane
są specjalne ramki sygnalizujące wystąpienie błędu. Dodatkowo w warstwie
tej mogą znajdować się rozwiązania, związane z planowanym zastosowaniem
takiej sieci. Na przykład w sieci CAN, warstwa ta kontroluje liczbę błędów
powstałą na sieci.
Dodatek A. Opis protokołu Controller Area Network 123
Rozstrzyganie kolizji
Dostęp do łącza jest realizowany na zasadzie wielodostępu (CSMA). Każ-
de urządzenie w dowolnej chwili może rozpocząć nadawanie, jeżeli tylko me-
dium transmisyjne jest wolne. Może zdarzyć się, co występuje we wszystkich
tego typu sieciach, rozpoczęcie transmisji przez dwa lub więcej węzłów, czyli
kolizja. Zjawisko takie może wystąpić ze względu na omawiany już parametr
fizyczny łącza jakim jest czas propagacji. Sieć CAN zstosowała mechanizm
nie powodujący utraty już przesłanych bitów. Wykorzytano w tym celu wła-
sność fizyczną łącza - iloczyn na łączu (ang. Wired-AND). Każdy nadawca
zobowiązany jest do kontroli stanu łącza i sprawdzania jego poprawności
(podrozdział A.2.2). Gdy w obszarze arbitrażu wystąpi niezgodność węzeł
wycofuje się i przechodzi w stan nasłuchiwania. Dzieje się tak do momentu
Rysunek A.5. Rozstrzyganie kolizji
pozostania tylko jednego nadawcy. Taki mechanizm powoduje, że identyfika-
tor staje się jednocześnie priorytetem. W literaturze ten mechanizm dostępu
do łącza jest różnie nazywany:
1. CSMA/CD/NDA (ang. Carrier Sense Multiple Access/Collision Detec-
tion with Non-destructive arbitration) [53],
2. CSMA/CA /w NDBWA (ang. Carrier Sense Multiple Access/Collision
Avoidence with Non-Destructive Bit Wise Arbitration) [34],
3. CSMA/CD /w AWD (ang. Carrier Sense Multiple Access/Collision De-
tection with Arbitration on Message Priority) [37],
4. CSMA/BC (ang. Carrier Sense Multiple Access/Bit wise Connection)[13].
Dodatek A. Opis protokołu Controller Area Network 124
Rodzaje i budowa ramek
W sieci CAN mogą wystąpić cztery rodzaje ramek [59]:
— danych (ang. data frame) (ramka informacyjna),
— zdalnego żądania (ang. remote frame) (ramka informacyjna),
— błędu (ang. error frame)(ramka sterująca),
— przepełnienia (ang. overload frame)(ramka sterująca).
Najczęściej występują ramki danych i zdalnego żądania. Za ich pomocą
realizowana jest cała wymiana informacji w sieci CAN. Pozostałe są ramka-
mi sterującymi. Ramki danych i zdalnego żądania dzielone są na dwa typy:
standardowa (ang. Standard) (tzw. 2.0A) i rozszerzona (ang. Extended)(tzw.
2.0B). Podział ten wynika ze stopniowego rozwoju protokołu. W 1991 roku
identyfikator wiadomości został wydłużony z 11 do 29 bitów. Poza zmianą
identyfikatora, wprowadzone zostały nieznaczne modyfikacje, w celu zacho-
wania zgodności obu formatów i możliwości ich jednoczesnego występowania
w sieci. Budowę tych ramek przedstawiono na rysunku A.6.
Rysunek A.6. Budowa ramek informacyjnych sieci CAN [52]
W skład nagłówka ramki CAN wchodzą następujące elementy [32]:
— 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,
— 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,
Dodatek A. Opis protokołu Controller Area Network 125
— RB0 (ang. Reserved Bit 0 ) - pole zarezerwowane, do ewentualnego wyko-
rzystania,
— DLC (ang. Data Length Code) - informuje o długości pola danych. Przyj-
muje wartości od 0 do 8. Kodowanie tych bitów w obszarze DLC jest
reprezentacją binarną przekazywanej wartości.
Dla ramek rozszerzonych, 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.
Wykrywanie błędów
Podczas każdej transmisji, mogą powstać błędy związane z oddziaływa-
niami 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 wy-
borze 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 [37, 31, 10, 34, 59]:
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 wy-
krycia wystąpienia na łączu stanu bitu przeciwnego do wartości nadawa-
nej, węzeł uznaje iż wystąpił błąd. Wyjątek stanowi pole rozstrzygania
kolizji (ang. Arbitration Field) i okno potwierdzeń (ang. ACK Slot)
2. Budowa ramki (ang. Frame Check) - w [13] określone jest to jako kontrola
poprawności końca ramki. Dokładnie przedstawiono to w [37] określa-
jąc liczbę pól do CRCDEL, ACKDEL, EOF i odstępu między ramkami.
Każdy odbiornik sprawdza wartość tych pól i w razie wystąpienia stanu
niedozwolonego zgłasza błąd. Takie błędy to są właśnie błędy formy (ang.
Form Errors).
3. Suma kontrolna (ang. Cyclic Redundancy Check) - wartość o określonej
liczbie bitów, wyliczany na podstawie wielomianu generacyjnego. W sieci
CAN wykorzystywany jest wielomian generacyjny 15-stego stopnia x15 +
x14 + x10 + x8 + x7 + x4 + x3 + 1 [59]. Za jego pomocą wyliczana jest
wartość CRC dla pól pomiedzy SOF i CRC.
4. Kontrola potwierdzeń (ang. Acknowledge Check) - każdy węzeł nadający
nasłuchuje potwierdzenia w oknie potwiedzeń (ACK) od przynajmniej
jednego węzła. Jeżeli nadawca nie uzyska odpowiedzi, w tym momęcie
Dodatek A. Opis protokołu Controller Area Network 126
uznaje że wystąpił błąd potwierdzenia (ang. Acknowledgement Error) i
dokonuje retransmisji do momentu uzyskania takiego potwierdzenia.
5. Kontrola zasady 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).
Efektem działania przedstawionych zabezpieczeń mają być deklarowane
przez producenta parametry wykrywalności błędów [59]:
— wszystkie błędy globalne,
— wszystkie lokalne błędy nadawcy,
— do 5 losowych błędów,
— błędy blokowe do 15 bitów,
— nieparzysta liczba błędów.
Prawdopodobieństwo powstania ramki z niewykrytym błędem wynosi:
PNDF = MessageErrorRate · 4.7 · 10−11 (A.1)
Obsługa błędów
Każdy węzeł, który wykryje błąd generuje ramkę błędu, zakończoną ośmio-
ma bitami recesywnymi. Zawartość ramki zależy od stanu w jakim znajdu-
je się węzeł. Zmianie podlegają: dostęp do łącza danych, długości odstępu
międzyramkowego (IFS) (ang. Inter Frame Space) i/lub sposób sygnalizacji
wykrycia błędu. Wprowadzenie takiego mechanizmu ma zapobiec zakłuceniu
transmisji w łączu przez uszkodzony węzeł. Stan kontrolera sieci ustala się
na podstawie wartości dwóch liczników błędu:
— Licznik błędów odbiorczych (ang. Receive Error Counter) (REC),
— Licznik błędów nadawczych (ang. Transmit Error Counter)) (TEC).
Gdy wartość obu liczników jest poniżej 128 to kontroler jest w stanie ak-
tywnego zgłaszania błędów (ang. Error-Acitve). W tym stanie węzeł może
swobodnie nadawć i odbierać wiadomości, a pole flagi błędu (ang. Error Flag
Field) w ramce błędu zawiera same bity dominujące. Odstęp między ramko-
wy wynosi 3 bity, jednak jeżeli wartość któregokolwiek z liczników osiągnie
lub przekroczy wartość 128, to węzeł przechodzi w stan pasywnego zgłaszania
błędów (ang. Error-Pasive). Stan ten różni się od stanu aktywnego długo-
ścią IFS równą 11 bitów oraz zamianą wartości dominujących na recesywne
w ramce błędów. Ostatni z możliwych stanów jest uaktywniany, gdy war-
tość licznika TEC będzie większa od 255 - odłączenie węzła. Gdy węzeł jest
Dodatek A. Opis protokołu Controller Area Network 127
odłączony od magistrali nie może mieć żadnego wpływu na magistralę (może
jedynie odczytywać jej stan). Zmiana wartości liczników pod wpływem ruchu
sieciwego opisana jest w dokumentacji [59] (rysunek A.7).
Rysunek A.7. Model Stanów Węzła sieci CAN [38]
A.3. Podsumowanie
W rozdziale tym przedstawiono podstawowe informacje o ramce CAN.
Omówiono zarówno budowe najważniejszych ramek (Ramki danych i zdalne-
go żądnia), mechanizmy zabezpieczenia danych, czy dostęp do medium. Za-
prezentowano również badania dotyczące wykorzystania mechanizmu wsta-
wek bitowych. Pokazały one nikłe zainteresowanie tematyką bit-stuffingu.
Wynikać to może z dużej zmienności i zależności powstawania dodatkowych
bitów od przesyłanych danych. Badania prowadzone w celu ograniczenia
występowania wstawek bitowych dla warstwy aplikacyjnej, zakończyły się
opracowaniem kilku rozwiązań przedstawionych w rozdziale 4. Przedstawio-
no również podstawowe metody ustalania priorytetów, dla których dużą rolę
odgrywa całkowita długość ramki (w tym wstawki bitowe). Ponieważ wstawki
te wpływają na wiele różnych aspektów komunikacji w sieci CAN, zagadnienie
to wydaje się być ważne. Studjując literaturę dotyczącą sieci CAN powstaje
pytanie czy istnieje możliwość „zaoszczędzenia” kilku bitów na poziomie war-
stwy łącza danych. Na końcu rozdziału wyznaczono wartości dla wybranych
Dodatek A. Opis protokołu Controller Area Network 128
parametrów, które w kolejnych rozdziałach będą służyć jako punkt odniesie-
nia przy ocenie wprowadzanych modyfikacji.
Dodatek B
Kod programu C++
B.1. Platforma.cpp
#include <s t d i o . h>
#include <s t d l i b . h>
#include <time . h>
#include <s t r i n g . h>
#include ”DataLinkLayer . h”
#include ”CANFrameClass . h”
#include ”Probes . h”
#define uint32 unsigned long int
#define uint16 unsigned short int
#define uint8 unsigned char
//∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗// f u n k c j e n i e k l a s o w e
void IncFrameData ( u int8 DTL, uint8 ∗DataTab) ;
void IncFrameData ( u int8 DTL, double ∗DataTab){(∗DataTab)++;
i f ( (∗DataTab == 0) && (DTL > 1) )
IncFrameData (DTL−1, &(DataTab [ 1 ] ) ) ;
}
void dPrintTab (double ∗Tab , u int8 TabLen){double ∗cTab = Tab ;
for ( ; TabLen > 0 ; TabLen−−, cTab++)
p r i n t f ( ”%.0 f | ” , ∗cTab) ;
p r i n t f ( ”\n” ) ;
}
void u8PrintTab ( uint8 ∗Tab , u int8 TabLen){uint8 ∗cTab = Tab ;
for ( ; TabLen > 0 ; TabLen−−, cTab++)
p r i n t f ( ”%d | ” , ∗cTab) ;
p r i n t f ( ”\n” ) ;
}//∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗// Funkcje Badan
void CAN BitStuf f ing ErrorDetect ion ( u int8 min errors , u int8 max errors , u int8 DTL, uint8 tab ){uint8 s t u f f e d b i t s = 0 , chkst r ;
double ProbeTab [ 1 0 ] [ 5 0 ] [ 2 ] ;
// w y c z y s z c z e n i e t a b l i c y wynikow
for ( u int8 j = 0 ; j < 10 ; j++)// e r r o r s
for ( u int8 k = 0 ; k < 50 ; k++)// b i t s t u f f e d
for ( u int8 l = 0 ; l < 2 ; l++) // b e f o r / a f t e r
ProbeTab [ j ] [ k ] [ l ] = 0 ;
class CANFrame f1 ;
class DataLinkLayer s1 ;
for ( u int8 e r r o r s = max errors ; e r r o r s >= min er ro r s ; e r ro r s−−){p r i n t f ( ”ERRORS = %d\n” , e r r o r s ) ;
for ( u int32 id = 0x7FF ; id < 0x800 ; id−−){
Dodatek B. Kod programu C++ 130
for ( u int16 count =1000; count > 0 ; count−−){f 1 . SetID ( id ) ;
f 1 . SetRemote (No) ;
f 1 . SetExtended (No) ;
f 1 . SetDTL(DTL) ;
f1 .cCRC() ;
s1 . PStream ( f1 . RetSOF ( ) , 1) ;
s1 . PStream ( f1 . RetID ( ) , 11) ;
s1 . PStream ( f1 . RetIsR ( ) , 1) ;
s1 . PStream ( f1 . RetIsE ( ) , 1) ;
s1 . PStream (0 x00 , 1) ;
s1 . PStream ( f1 . RetDTL( ) , 4) ;
s1 . PStream ( f1 .RetCRC() , 15) ;
s t u f f e d b i t s = s1 . DoBitStuf ( ) ;
ProbeTab [ e r ro r s−min er ro r s ] [ s t u f f e d b i t s ] [ 0 ]++;
s1 . S i ng l eEr r o r s ( e r r o r s ) ;
chks t r = s1 . ChkOutStream ( ) ;
i f ( chkst r > 0)
ProbeTab [ e r ro r s−min er ro r s ] [ s t u f f e d b i t s ] [ 1 ]++;
s1 . ResetAl lPos ( ) ;
}}for ( u int8 i = 0 ; i < 30 ; i++)
p r i n t f ( ”%.0 f | ” , ProbeTab [ e r ro r s−min er ro r s ] [ i ] [ 0 ] ) ;
p r i n t f ( ”\n” ) ;
for ( u int8 i = 0 ; i < 30 ; i++)
p r i n t f ( ”%.0 f | ” , ProbeTab [ e r ro r s−min er ro r s ] [ i ] [ 1 ] ) ;
p r i n t f ( ”\n” ) ;
}getchar ( ) ;
}//∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗
int main ( )
{/∗ Wyznaczenie k t r e i d e n t y f i k a t o r y i l e maja b i t w wstawionych ∗/
// S o r t B i t S t u f f i n g H e a d e r ( 1 ) ;
/∗ BADANIE 9 − Wyszukanie ID z n a j m n i e j s z a l i c z b a wstawionych b i t o w d l a nag lowka poprawionego∗/
/∗ f o r ( u i n t 8 e = 0 ; e < 2 ; e++)
f o r ( u i n t 8 r = 0 ; r < 2 ; r++)
f o r ( u i n t 8 l = 0 ; l < 1 6 ; l ++){p r i n t f (”%d %d %d |” , e , r , l ) ;
B i t S t u f f i n g H e a d e r I I ( l , r , e ) ;
}
/∗ BADANIE 8 − Przebadan ie i l e b i t o w z o s t a n i e wstawionych w o b s z a r z e
i d e n t y f i k a t o r a przy calym naglowku ∗/
/∗f o r ( u i n t 8 e = 0 ; e < 2 ; e++){
p r i n t f (”%d |” , e ) ;
B i t S t u f f i n g I D i n H e a d e r ( e ) ;
}
// #d e f i n e RATETAB 44
/∗ BADANIE 7 − Wyznaczenie l i c z b y i d e n t y f i k a t o r o w o 0 , 1 , 2 . . . b i t w dodanych ∗/
/∗f o r ( u i n t 1 6 i d = 5 ; i d < 3 0 ; i d++){
p r i n t f (” ID=%d | | ” , i d ) ;
B i t S t u f f i n g I D ( i d ) ;
}
/∗ BADANIE 6 − Wyszukanie ID z n a j m n i e j s z a l i c z b a wstawionych b i t o w ∗/
/∗f o r ( u i n t 8 e = 0 ; e < 2 ; e++)
f o r ( u i n t 8 r = 0 ; r < 2 ; r++)
f o r ( u i n t 8 l = 0 ; l < 1 6 ; l ++){
Dodatek B. Kod programu C++ 131
p r i n t f (”%d %d %d |” , e , r , l ) ;
B i t S t u f f i n g H e a d e r ( l , r , e ) ;
}
/∗ BADANIE 5 − Tworzenie Histogramu d l a ramek ∗/
#define LOOPS 5
#define MAX LONGINT 3000000
#define BEGIN ID 11 2048
#define BEGIN ID 29 536870911
uint8 l , r , e ;
double f rames no ;
// frames no = 2048 ;
l = 0 ; r = 0 ; e = 0 ;
i f ( e == 0)
frames no = BEGIN ID 11 ;
else
f rames no = BEGIN ID 29 ;
for ( l = 0 ; l <= 15 ; l++){r = 0 ;
for ( u int8 round = LOOPS; round > 0 ; round−−){i f ( frames no > MAX LONGINT){
p r i n t f ( ”%.0 f | %d | %d | %d | | ” , (double ) MAX LONGINT, e , r , l ) ;
B i tStu f f ingHis togram ( l , r , e , ( u int32 ) MAX LONGINT) ;
for ( t ime t t = time (NULL) + 5 ; time (NULL) < t ; ) {}}else{
p r i n t f ( ”%.0 f | %d | %d | %d | | ” , frames no , e , r , l ) ;
B i tStu f f ingHis togram ( l , r , e , ( u int32 ) frames no ) ;
for ( t ime t t = time (NULL) + 5 ; time (NULL) < t ; ) {}}}
r = 1 ;
for ( u int8 round = LOOPS; round > 0 ; round−−){i f ( frames no > MAX LONGINT){
p r i n t f ( ”%.0 f | %d | %d | %d | | ” , (double ) MAX LONGINT, e , r , l ) ;
B i tStu f f ingHis togram ( l , r , e , ( u int32 ) MAX LONGINT) ;
for ( t ime t t = time (NULL) + 5 ; time (NULL) < t ; ) {}}else{
p r i n t f ( ”%.0 f | %d | %d | %d | | ” , frames no , e , r , l ) ;
B i tStu f f ingHis togram ( l , r , e , ( u int32 ) frames no ) ;
for ( t ime t t = time (NULL) + 5 ; time (NULL) < t ; ) {}}}f rames no ∗= 256;
}
/∗ BADANIE 4 . 2 − Sprawdzenie o d z w i e r c i e d l e n i a r e z u l t a t w modelu pr zy
u d z i a l e odpowiednio − d l a k a d e j p r b y 3M n i e s i e za soba p o w t a r z a l n o s c ∗/
/∗
#d e f i n e LOOPS 5
#d e f i n e MAX LONGINT 3000000
#d e f i n e BEGIN ID 11 2048
#d e f i n e BEGIN ID 29 536870911
u i n t 8 l , r , e ;
d o u b l e f rames no = BEGIN ID 29 ;
// frames no = 2048 ;
l = 0 ; r = 0 ; e = 1 ;
f o r ( l = 0 ; l <= 8 ; l ++){r = 0 ;
f o r ( u i n t 8 round = LOOPS; round > 0 ; round−−){i f ( f rames no > MAX LONGINT){
p r i n t f (”%.0 f | %d | %d | %d | | ” , ( d o u b l e ) MAX LONGINT, e , r , l ) ;
BitStuf f ingInCANFrame ( l , r , e , ( u i n t 3 2 ) MAX LONGINT) ;
f o r ( t i m e t t = time (NULL) + 5 ; t ime (NULL) < t ; ) {}}e l s e {
p r i n t f (”%.0 f | %d | %d | %d | | ” , frames no , e , r , l ) ;
BitStuf f ingInCANFrame ( l , r , e , ( u i n t 3 2 ) f rames no ) ;
f o r ( t i m e t t = time (NULL) + 5 ; t ime (NULL) < t ; ) {}
Dodatek B. Kod programu C++ 132
}}r = 1 ;
f o r ( u i n t 8 round = LOOPS; round > 0 ; round−−){i f ( f rames no > MAX LONGINT){
p r i n t f (”%.0 f | %d | %d | %d | | ” , ( d o u b l e ) MAX LONGINT, e , r , l ) ;
BitStuf f ingInCANFrame ( l , r , e , ( u i n t 3 2 ) MAX LONGINT) ;
f o r ( t i m e t t = time (NULL) + 5 ; t ime (NULL) < t ; ) {}}e l s e {
p r i n t f (”%.0 f | %d | %d | %d | | ” , frames no , e , r , l ) ;
BitStuf f ingInCANFrame ( l , r , e , ( u i n t 3 2 ) f rames no ) ;
f o r ( t i m e t t = time (NULL) + 5 ; t ime (NULL) < t ; ) {}}}f rames no ∗= 256 ;
}∗/
/∗ BADANIE 4 − Sprawdzenie o d z w i e r c i e d l e n i a r e z u l t a t w modelu pr zy
u d z i a l e odpowiednio − d l a k a d e j p r b y 3M n i e s i e za soba p o w t a r z a l n o s c ∗/
/∗#d e f i n e LOOPS 1
#d e f i n e MAX LONGINT 3000000
// d o u b l e amount e lements [ 5 ] = {0 .005 , 0 . 0 1 , 0 . 0 2 , 0 . 0 5 , 0 . 1 0} ;
u i n t 8 l , r , e ;
l = 0 ; r = 0 ; e = 0 ;
d o u b l e f rames no = 2048;
f o r ( u i n t 8 p = 0 ; p < 5 ; p++){f rames no = 2048 ;
l = 0 ; r = 0 ; e = 0 ;
f o r ( l = 0 ; l <= 3 ; l ++){r = 0 ;
f o r ( u i n t 8 round = 1 ; round > 0 ; round−−){// f o r ( d o u b l e f a = frames no∗ amount e lements [ p ] ; f a > 0 ; f a = f a − MAX LONGINT){
i f ( f rames no > MAX LONGINT){p r i n t f (”% f | %.0 f | %d | %d | %d | | ” , amount e lements [ p ] , ( d o u b l e ) MAX LONGINT, e , r , l ) ;
BitStuf f ingInCANFrame ( l , r , e , ( u i n t 3 2 ) MAX LONGINT) ;
f o r ( t i m e t t = time (NULL) + 5 ; t ime (NULL) < t ; ) {}}e l s e {
p r i n t f (”% f | %.0 f | %d | %d | %d | | ” , amount e lements [ p ] , frames no , e , r , l ) ;
BitStuf f ingInCANFrame ( l , r , e , ( u i n t 3 2 ) f a ) ;
f o r ( t i m e t t = time (NULL) + 5 ; t ime (NULL) < t ; ) {}}
// }}r = 1 ;
f o r ( u i n t 8 round = 1 ; round > 0 ; round−−){// f o r ( d o u b l e f a = frames no∗ amount e lements [ p ] ; f a > 0 ; f a = f a − MAX LONGINT){
i f ( f rames no > MAX LONGINT){p r i n t f (”% f | %.0 f | %d | %d | %d | | ” , amount e lements [ p ] , ( d o u b l e ) MAX LONGINT, e , r , l ) ;
BitStuf f ingInCANFrame ( l , r , e , ( u i n t 3 2 ) MAX LONGINT) ;
f o r ( t i m e t t = time (NULL) + 5 ; t ime (NULL) < t ; ) {}}e l s e {
p r i n t f (”% f | %.0 f | %d | %d | %d | | ” , amount e lements [ p ] , frames no , e , r , l ) ;
BitStuf f ingInCANFrame ( l , r , e , ( u i n t 3 2 ) f a ) ;
f o r ( t i m e t t = time (NULL) + 5 ; t ime (NULL) < t ; ) {}}
// }}f rames no ∗= 256;
}}∗/
/∗ BADANIE 3 − Sprawdzenie modelu pod katem z g o d n o s c i z r z e c z y w i s t y m i ∗/
/∗ parametrami ws tawian ia b i t o w d l a 3M probek ∗ 5 ∗/
/∗#d e f i n e LOOPS 5
d o u b l e amount e lements [ 5 ] = {0 .005 , 0 . 0 1 , 0 . 0 2 , 0 . 0 5 , 0 . 1 0} ;
Dodatek B. Kod programu C++ 133
u i n t 8 l , r , e ;
l = 0 ; r = 0 ; e = 0 ;
d o u b l e f rames no = 2048;
f o r ( u i n t 8 p = 0 ; p < 5 ; p++){l = 0 ; r = 0 ; e = 0 ;
f o r ( l = 0 ; l <= 8 ; l ++){r = 0 ;
f o r ( u i n t 8 round = LOOPS; round > 0 ; round−−){p r i n t f (”% f | %.0 f | %d | %d | %d |” , amount e lements [ p ] , f rames no∗ amount e lements [ p ] , e , r , l ) ;
BitStuf f ingInCANFrame ( l , r , e , 3000000) ;
f o r ( t i m e t t = time (NULL) + 5 ; t ime (NULL) < t ; ) {}}r = 1 ;
f o r ( u i n t 8 round = LOOPS; round > 0 ; round−−){p r i n t f (”% f | %.0 f | %d | %d | %d |” , amount e lements [ p ] , f rames no∗ amount e lements [ p ] , e , r , l ) ;
BitStuf f ingInCANFrame ( l , r , e , 3000000) ;
f o r ( t i m e t t = time (NULL) + 5 ; t ime (NULL) < t ; ) {}}f rames no ∗= 256;
}}∗/
/∗ BADANIE 2 − Blok danych z a b e z p i e c z o n y c h suma k o n t r o l n a CRC15 0x573A ∗/
/∗
f l o a t errRate [RATETAB] = { 1 . 0 , 2 . 0 , 3 . 0 , 4 . 0 , 5 . 0 , 6 . 0 , 7 . 0 , 8 . 0 , 9 . 0 , 1 0 . 0 ,
1 1 . 0 , 1 2 . 0 , 1 3 . 0 , 1 4 . 0 , 1 5 . 0 , 1 6 . 0 , 1 7 . 0 , 1 8 . 0 , 1 9 . 0 , 2 0 . 0 ,
2 1 . 0 , 2 2 . 0 , 2 3 . 0 , 2 4 . 0 , 2 5 . 0 , 2 6 . 0 , 2 7 . 0 , 2 8 . 0 , 2 9 . 0 , 3 0 . 0 ,
3 1 . 0 , 3 2 . 0 , 3 3 . 0 , 3 4 . 0 ,
0 . 1 , 0 . 2 , 0 . 3 , 0 . 4 , 0 . 5 , 0 . 6 , 0 . 7 , 0 . 8 , 0 . 9 , 0 . 9 9} ;
f o r ( u i n t 8 k = 0 ; k <= 8 ; k++)
f o r ( s h o r t i n t j = RATETAB−1; j >= 0 ; j−−)
f o r ( u i n t 8 i = 1 0 ; i > 0 ; i−−){DataSecureCRC15 0x573A ForSetLen (1000000 , 13000000 , errRate [ j ] , k ) ;
}∗/
/∗ BADANIE 1 − Blok danych z a b e p i e c z o n y suma k o n t r o l n a CRC15 CAN ∗/
/∗f o r ( u i n t 8 k = 0 ; k <= 8 ; k++)
f o r ( s h o r t i n t j = RATETAB−1; j >= 0 ; j−−)
f o r ( u i n t 8 i = 1 0 ; i > 0 ; i−−){DataSecureCRC15 0x573A ForSetLen (1000000 , 13000000 , errRate [ j ] , k ) ;
}∗/
/∗f l o a t errRate [RATETAB] = { 1 . 0 , 2 . 0 , 3 . 0 , 4 . 0 , 5 . 0 , 6 . 0 , 7 . 0 , 8 . 0 , 9 . 0 , 1 0 . 0 ,
1 1 . 0 , 1 2 . 0 , 1 3 . 0 , 1 4 . 0 , 1 5 . 0 , 1 6 . 0 , 1 7 . 0 , 1 8 . 0 , 1 9 . 0 , 2 0 . 0 ,
2 1 . 0 , 2 2 . 0 , 2 3 . 0 , 2 4 . 0 , 2 5 . 0 , 2 6 . 0 , 2 7 . 0 , 2 8 . 0 , 2 9 . 0 , 3 0 . 0 ,
3 1 . 0 , 3 2 . 0 , 3 3 . 0 , 3 4 . 0 ,
0 . 1 , 0 . 2 , 0 . 3 , 0 . 4 , 0 . 5 , 0 . 6 , 0 . 7 , 0 . 8 , 0 . 9 , 0 . 9 9} ;
f o r ( s h o r t i n t j = RATETAB−1; j >= 0 ; j−−)
f o r ( u i n t 8 i = 1 0 ; i > 0 ; i−−){// DataSecureCRC15 (1000000 , 13000000 , errRate [ j ] ) ;
DataSecureCRC15 CAN ForSetLen (1000000 , 13000000 , errRate [ j ] , 0) ;
DataSecureCRC15 CAN ForSetLen (1000000 , 13000000 , errRate [ j ] , 1) ;
DataSecureCRC15 CAN ForSetLen (1000000 , 13000000 , errRate [ j ] , 2) ;
DataSecureCRC15 CAN ForSetLen (1000000 , 13000000 , errRate [ j ] , 3) ;
DataSecureCRC15 CAN ForSetLen (1000000 , 13000000 , errRate [ j ] , 4) ;
DataSecureCRC15 CAN ForSetLen (1000000 , 13000000 , errRate [ j ] , 5) ;
DataSecureCRC15 CAN ForSetLen (1000000 , 13000000 , errRate [ j ] , 6) ;
DataSecureCRC15 CAN ForSetLen (1000000 , 13000000 , errRate [ j ] , 7) ;
DataSecureCRC15 CAN ForSetLen (1000000 , 13000000 , errRate [ j ] , 8) ;
}∗/
}
Dodatek B. Kod programu C++ 134
B.2. DataLinkLayer.h
#define uint32 unsigned long int
#define uint16 unsigned short int
#define uint8 unsigned char
#define t B e f o r e S t u f f 0
#define t A f t e r S t u f f 1
#define tGenError 2
#define tError 3
class DataLinkLayer{private :
u int8 bfstufBT [ 2 0 0 ] ; // t a b l i c a danych w e j s c i o w y c h
uint8 afstufBT [ 2 0 0 ] ; // t a b l i c a po w s t a w i e n i u b i t o w
uint8 xortab [ 2 0 0 ] ; // t a b l i c a b ledow
uint8 e r r tab [ 2 0 0 ] ; // t a b l i c a po b l e d a c h
uint8 bfWpos , bfRpos ; // a k t u a l n a d l u g o s c s t r u m i e n i a
uint8 afWpos , afRpos ; // a k t u a l n a d l u g o s c s t r u m i e n i a
uint8 xorWpos , xorRpos ;
u int8 errWpos , errRpos ;
u int8 blen ; // d l u g o s c b i t o w jednakowych po k t o r y c h n a s t a p i w s t a w i e n i e
public :
DataLinkLayer ( void ) ;
void ResetAl lPos ( void ) ;
void ResetRPos ( u int8 tabID ) ;
void ResetWPos ( u int8 tabID ) ;
void PutStream ( uint32 strim , u int8 pos , u int8 l en ) ; // d o p i s a n i e na koncu do 32 b i t o w
void PStream ( uint32 strim , u int8 l en ) ;
u int8 DoBitStuf ( void ) ;
void DontBitStu f f ing ( void ) ;
u int8 GetStream ( uint8 tabID , uint32 ∗ strim , u int8 pos , u int8 l en ) ; // p o b r a n i e s t rumenia od p o z y c j i ( pos ) i o d l u g o s c i ( l e n )
uint8 GStream( uint8 tabID , uint32 ∗ strim , u int8 l en ) ;
u int8 S ing l eEr r o r s ( u int8 number ) ;
u int8 GroupErrors ( u int8 ge r r po s ) ;
void NoErrors ( void ) ;
void PrintTab ( uint8 tabID ) ;
u int8 ChkOutStream ( void ) ;
void B i t S t u f f i n g H i s t (double ∗ tH i s t ) ;
} ;
DataLinkLayer : : DataLinkLayer (void ) {// spos = 0 ;
srand ( time (NULL) ) ;
u int8 ∗af , ∗bf , ∗er , ∗xr ;
a f = this−>afstufBT ;
bf = this−>bfstufBT ;
er = this−>e r r tab ;
xr = this−>xortab ;
for ( u int8 i = 200 ; i > 0 ; i−−){∗ a f = ∗bf = ∗ er = ∗xr = 0 ;
a f++;
bf++;
er++;
xr++;
}
afWpos = afRpos = 0 ;
bfWpos = afRpos = 0 ;
xorWpos = xorRpos = 0 ;
errWpos = errRpos = 0 ;
blen = 5 ;
} ;
void DataLinkLayer : : PutStream ( uint32 strim , u int8 pos , u int8 dlen ){uint8 ∗ tmpBT;
// w s t a w i a n i e k o l e j n y c h b i t o w w t a b l i c e od podanej p o z y c j i
// s p r a w d z e n i e czy n i e wyjedz iemy poza obecna d l u g o s c
i f ( pos+dlen > this−>bfWpos )
this−>bfWpos = pos+dlen ;
tmpBT = ( this−>bfstufBT )+pos ;
s tr im <<= (32−dlen ) ;
Dodatek B. Kod programu C++ 135
for ( u int8 i=dlen ; i > 0 ; i−−){∗tmpBT = ( str im & 0x80000000 ) >> 31 ;
str im <<= 1;
tmpBT++;
}} ;
void DataLinkLayer : : ResetAl lPos (void ){this−>bfWpos = this−>bfRpos = 0 ;
this−>afWpos = this−>afRpos = 0 ;
this−>xorWpos = this−>xorRpos = 0 ;
this−>errWpos = this−>errRpos = 0 ;
} ;
void DataLinkLayer : : ResetRPos ( u int8 tabID ){switch ( tabID ){case 0 : this−>bfRpos = 0 ; break ;
case 1 : this−>afRpos = 0 ; break ;
case 2 : this−>xorRpos = 0 ; break ;
case 3 : this−>errRpos = 0 ; break ;
}}
void DataLinkLayer : : ResetWPos ( u int8 tabID ){switch ( tabID ){case 0 : this−>bfWpos = 0 ; break ;
case 1 : this−>afWpos = 0 ; break ;
case 2 : this−>xorWpos = 0 ; break ;
case 3 : this−>errWpos = 0 ; break ;
}}
void DataLinkLayer : : PStream ( uint32 strim , u int8 dlen ){// w s t a w i e n i e do s t r u m i e n i a od p i e r w s z e g o wolnego
uint8 ∗ tmpBT = &(this−>bfstufBT [ this−>bfWpos ] ) ;
this−>bfWpos += dlen ;
str im <<= (32−dlen ) ;
for ( u int8 i=dlen ; i > 0 ; i−−){∗tmpBT = ( str im & 0x80000000 ) >> 31 ;
str im <<= 1;
tmpBT++;
}} ;
void DataLinkLayer : : PrintTab ( uint8 tabID ){uint8 ∗tmpBT;
uint8 ∗pos ;
switch ( tabID ){case 0 : tmpBT = this−>bfstufBT ; pos = &(this−>bfWpos ) ; break ;
case 1 : tmpBT = this−>afstufBT ; pos = &(this−>afWpos ) ; break ;
case 2 : tmpBT = this−>xortab ; pos = &(this−>xorWpos ) ; break ;
case 3 : tmpBT = this−>e r r tab ; pos = &(this−>errWpos ) ; break ;
}for ( u int8 i = ∗pos ; i > 0 ; i−−){
p r i n t f ( ”%d | ” ,∗tmpBT) ;
tmpBT++;
}p r i n t f ( ”\n” ) ;
} ;
u int8 DataLinkLayer : : DoBitStuf (void ){uint8 ∗ if tmp BT , ∗ of tmp BT ;
uint8 l a s t b i t = 0 , sb count = 0 ;
u int8 StufBitCount = 0 ;
if tmp BT = this−>bfstufBT ;
of tmp BT = this−>afstufBT ;
this−>afWpos = this−>bfWpos ;
for ( u int8 i = this−>bfWpos ; i > 0 ; i−−){∗of tmp BT = ∗ if tmp BT ;
i f (∗ i f tmp BT == l a s t b i t ){sb count++;
i f ( sb count == this−>blen ){StufBitCount++;
of tmp BT++;
∗of tmp BT = l a s t b i t ˆ 0x02 ;
Dodatek B. Kod programu C++ 136
this−>afWpos++;
l a s t b i t = ( l a s t b i t +1) & 0x01 ;
sb count = 1 ;
}} else {
l a s t b i t = l a s t b i t ˆ 0x01 ;
sb count = 1 ;
}of tmp BT++;
if tmp BT++;
}return StufBitCount ;
}
void DataLinkLayer : : DontBitStu f f ing (void ){uint8 ∗ if tmp BT , ∗ of tmp BT ;
if tmp BT = this−>bfstufBT ;
of tmp BT = this−>afstufBT ;
this−>afWpos = this−>bfWpos ;
for ( u int8 i = this−>bfWpos ; i > 0 ; i−−, of tmp BT++, if tmp BT++)
∗of tmp BT = ∗ if tmp BT ;
}
uint8 DataLinkLayer : : GetStream ( uint8 tabID , uint32 ∗ strim , u int8 pos , u int8 l en ){uint8 ∗ of BT ;
uint8 ∗ s l e n ;
switch ( tabID ){case 0 : of BT = this−>bfstufBT ; s l en = &(this−>bfRpos ) ; break ;
case 1 : of BT = this−>afstufBT ; s l en = &(this−>afRpos ) ; break ;
case 2 : of BT = this−>xortab ; s l e n = &(this−>xorRpos ) ; break ;
case 3 : of BT = this−>e r r tab ; s l e n = &(this−>errRpos ) ; break ;
}i f ( pos + len > ∗ s l e n ){return 0xFF ;
} else{∗ str im = 0 ;
∗ s l e n += len ;
for ( u int8 i = len ; i > 0 ; i−−){∗ str im <<= 1;
∗ str im ˆ= ∗of BT ;
of BT++;
}}}
uint8 DataLinkLayer : : GStream( uint8 tabID , uint32 ∗ strim , u int8 l en ){uint8 ∗ of BT ;
uint8 ∗ s l en , ∗pos ;
switch ( tabID ){case 0 : of BT = &(this−>bfstufBT [ this−>bfRpos ] ) ; s l e n = &(this−>bfWpos ) ; pos = &(this−>bfRpos ) ; break ;
case 1 : of BT = &(this−>afstufBT [ this−>afRpos ] ) ; s l e n = &(this−>afWpos ) ; pos = &(this−>afRpos ) ; break ;
case 2 : of BT = &(this−>xortab [ this−>xorRpos ] ) ; s l e n = &(this−>xorWpos ) ; pos = &(this−>xorRpos ) ; break ;
case 3 : of BT = &(this−>e r r tab [ this−>errRpos ] ) ; s l e n = &(this−>errWpos ) ; pos = &(this−>errRpos ) ; break ;
}i f (∗ pos + len > ∗ s l e n ){return 0xFF ;
} else{∗ str im = 0 ;
∗pos += len ;
for ( u int8 i = len ; i > 0 ; i−−){∗ str im <<= 1;
∗ str im ˆ= ∗of BT ;
of BT++;
}}}
uint8 DataLinkLayer : : S i ng l eEr r o r s ( u int8 number ){uint8 pos , s t r i m l e n = this−>afWpos ;
u int8 ∗xTab = this−>xortab ;
u int8 ∗eTab = this−>e r r tab ;
u int8 ∗dTab = this−>afstufBT ;
for ( u int8 i =200; i >0; i−−){∗xTab = 0 ;
xTab++;
Dodatek B. Kod programu C++ 137
}this−>xorWpos = this−>afWpos ;
xTab = this−>xortab ;
for ( number ; number > 0 ; ){pos = ( uint8 ) ( ( ( double ) rand ( ) ∗ (double ) ( s t r i m l e n ) ) / (RAND MAX+1) ) ;
i f (xTab [ pos ] != 0x04 ){xTab [ pos ] ˆ= 0x04 ;
number−−;
}}this−>errWpos = this−>xorWpos ;
for ( u int8 i = this−>xorWpos ; i > 0 ; i−−){∗eTab = (∗xTab>>2) ˆ (∗dTab&0x01 ) ˆ ( ( (∗dTab)&0x02 )>>1) ;
eTab++;
xTab++;
dTab++;
}}
uint8 DataLinkLayer : : GroupErrors ( u int8 ge r r po s ){uint8 pos , s t r i m l e n ;
u int8 ∗xTab = this−>xortab ;
u int8 ∗eTab = this−>e r r tab ;
u int8 ∗dTab = this−>afstufBT ;
s t r i m l e n = this−>afWpos − ge r r po s ;
for ( u int8 i =200; i >0; i−−){∗xTab = 0 ;
xTab++;
}this−>xorWpos = this−>afWpos ;
pos = ( uint8 ) ( ( ( double ) rand ( ) ∗ (double ) ( s t r i m l e n ) ) / (RAND MAX+1) ) ;
xTab = this−>xortab + pos ;
for ( g e r r po s ; g e r r po s > 0 ; ger r pos−−){∗xTab ˆ= 0x04 ;
xTab++;
}this−>errWpos = this−>xorWpos ;
xTab = this−>xortab ;
for ( u int8 i = this−>xorWpos ; i > 0 ; i−−){∗eTab = (∗xTab>>2) ˆ (∗dTab&0x01 ) ˆ ( ( (∗dTab)&0x02 )>>1) ;
eTab++;
xTab++;
dTab++;
}}
void DataLinkLayer : : NoErrors (void ){uint8 ∗ xTab , ∗ eTab , ∗ dTab ;
dTab = this−>afstufBT ;
xTab = this−>xortab ;
eTab = this−>e r r tab ;
this−>errWpos = this−>xorWpos = this−>afWpos ;
for ( u int8 i = this−>xorWpos ; i > 0 ; i−−){∗eTab = (∗xTab>>2) ˆ (∗dTab&0x01 ) ˆ ( ( (∗dTab)&0x02 )>>1) ;
eTab++;
xTab++;
dTab++;
}}
uint8 DataLinkLayer : : ChkOutStream (void ){uint8 ∗ i f BT = this−>e r r tab ;
u int8 ∗ s l e n = &(this−>errWpos ) ;
u int8 ∗pos = &(this−>errRpos ) ;
u int8 sb count = 0 ;
u int8 l a s t b i t = 3 ;
// i f tmp BT = t h i s−>b f s t u f B T ;
// of tmp BT = t h i s−>a f s tu fBT ;
for ( u int8 i = this−>errWpos ; i > 0 ; i−−){i f (∗ i f BT == l a s t b i t ){sb count++;
i f ( sb count > this−>blen ){return this−>errWpos − i ;
Dodatek B. Kod programu C++ 138
}} else {
l a s t b i t = ∗ i f BT ;
sb count = 1 ;
}i f BT++;
}return 0 ;
}
void DataLinkLayer : : B i t S t u f f i n g H i s t (double ∗ tH i s t ){// p r i n t f (”%d ” , s i z e o f (∗ t H i s t ) / s i z e o f ( d o u b l e ) ) ;
// i f ( ( s i z e o f ( t H i s t ) / s i z e o f ( d o u b l e ) ) < t h i s−>bfWpos ){// p r i n t f (” Blad : Zbyt k r o t k a t a b l i c a Histogramu\n ”) ;
// }// e l s e {
uint8 ∗pAFtable = this−>afstufBT ;
uint8 NotStu f f edBit s = 0 ;
for ( u int8 pos = this−>afWpos ; pos > 0 ; pos−−, pAFtable++, NotStu f f edBi t s++){i f ( ( (∗ pAFtable ) & 0x02 ) == 0x02 ){NotStuf fedBits−−;
tH i s t [ NotStu f f edBit s ]++;
}}
// }}
B.3. CANFrameClass.h
#define No 0
#define Yes 1
#define MAX20AID 0 x 7 f f
#define MAX20BID 0x1FFFFFFF
class CANFrame
{private :
u int8 SOF; // StartOfFrame
uint32 ID ; // I d e n t y f i k a t o r (11 b v 28 b )
uint8 IsExtended ; //Ramka r o z s z e r z o n a (1 b )
uint8 IsRemote ; //Ramka z d a l n a (1 b )
uint8 DTL; // Data Lenght (4 b )
uint8 Data [ 8 ] ; //Dane ( 0 . . 6 4 b )
uint16 CRC; //Suma Kontro lna CRCˆ15 (15 b )
void PartCRC( uint32 Input , u int8 Len , u int8∗ nxBit , u int8∗ nxCRC) ;
public :
CANFrame( void ) ;
void SetID ( uint32 ID) ;
void SetExtended ( u int8 IsExtended ) ;
void SetRemote ( u int8 IsRemote ) ;
void SetDTL( uint8 DTL){ this−>DTL = DTL; } ;
void SetData ( u int8 DTL, uint8 ∗Data ) ;
void cCRC( void ) ;
u int32 RetID ( void ) { return this−>ID ; } ;
u int16 RetCRC( void ){ return this−>CRC; } ;
u int8 RetDTL( void ){ return this−>DTL; } ;
u int8 RetIsE ( void ){ return this−>IsExtended ; } ;
u int8 RetIsR ( void ){ return this−>IsRemote ; } ;
u int8 RetSOF( void ){ return this−>SOF; } ;
} ;
CANFrame : : CANFrame(void ){ID = 0 ;
IsExtended = No ;
IsRemote = No ;
DTL = 0 ;
CRC = 0 ;
}
void CANFrame : : SetID ( uint32 ID){
Dodatek B. Kod programu C++ 139
this−>ID = ID ;
}
void CANFrame : : SetExtended ( uint8 IsExtended ){this−>IsExtended = IsExtended ;
}
void CANFrame : : SetRemote ( u int8 IsRemote ){this−>IsRemote = IsRemote ;
}
void CANFrame : : SetData ( u int8 DTL, uint8 ∗Data ){memcpy( this−>Data , Data , DTL) ;
this−>DTL = DTL;
}
void CANFrame : : PartCRC( uint32 Input , u int8 Len , u int8∗ nxBit , u int8∗ nxCRC){Input = Input << (32 − Len ) ;
u int32 t In = 0 ;
for ( ; Len > 0 ; Len−−, Input = Input <<1){i f ( ( Input & 0x80000000 ) == 0x80000000 ) // spr war tosc b i t u
∗nxBit = 1 ; // u s t a l e n i e w a r t o s c i
else
∗nxBit = 0 ; // u s t a l e n i e w a r t o s c i
∗nxCRC = (∗ nxBit ) ˆ ( ( this−>CRC >> 14) & 0x7FFF) ; // CRCNXT = NXBIT ˆ CRC[ 1 4 ]
this−>CRC = (( this−>CRC << 1) & 0x7FFF) ; // CRC[ 1 4 : 1 ] = CRC[ 1 3 : 0 ]
i f (∗nxCRC)
this−>CRC = ( this−>CRC ˆ 0x4599 ) & 0x7FFF ;
}}
void CANFrame : : cCRC( void ){uint8 nxBit , nxCRC;
nxBit = nxCRC = 0 ;
// wyznaczen ie d l u g o s c i ramki
this−>CRC = 0x0000 ; // i n i c j a l i z a c j a r e j e s t r u przesownego
i f ( this−>IsExtended == No) {PartCRC( this−>SOF, 1 , &nxBit , &nxCRC) ;
PartCRC( this−>ID , 11 , &nxBit , &nxCRC) ;
PartCRC( this−>IsRemote , 1 , &nxBit , &nxCRC) ;
PartCRC(0 x00 , 2 , &nxBit , &nxCRC) ;
PartCRC( this−>DTL, 4 , &nxBit , &nxCRC) ;
for ( int i = 0 ; i < this−>DTL; i++)
PartCRC( this−>Data [ i ] , 8 , &nxBit , &nxCRC) ;
}else {
PartCRC (( this−>ID >> 18) , 12 , &nxBit , &nxCRC) ;
PartCRC(1 , 1 , &nxBit , &nxCRC) ; //SRR
PartCRC( this−>IsExtended , 1 , &nxBit , &nxCRC) ; //IDE
PartCRC (( this−>ID & 0x3FFFF) , 18 , &nxBit , &nxCRC) ; //ID [ 1 7 . . 0 ]
PartCRC( this−>IsRemote , 1 , &nxBit , &nxCRC) ;
PartCRC(0 x00 , 2 , &nxBit , &nxCRC) ;
PartCRC( this−>DTL, 4 , &nxBit , &nxCRC) ;
for ( int i = 0 ; i < this−>DTL; i++)
PartCRC( this−>Data [ i ] , 8 , &nxBit , &nxCRC) ;
}}
Dodatek C
Kod programu w Pythonie
C.1. Kod biblioteki Frames.py
import DLL
import Lab Supp
#∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗# Klasa za jmujaca s i e przygotwaniem ∗# ramki CAN ∗#∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗class CAN:
def i n i t ( s e l f ) :
s e l f .SOF = { ’ l en ’ : 1 , ’ va l ’ : 0} #S t a r t Of Frame
s e l f . ID = { ’ l en ’ : 29 , ’ va l ’ : 0} #I d e n t i f i e r
s e l f . ID1 = { ’ l en ’ : 11}s e l f . ID2 = { ’ l en ’ : 18}s e l f . IDE = { ’ l en ’ : 1 , ’ va l ’ : 1} #I d e n t i f i e r E x t e n t i o n
s e l f .SRR = { ’ l en ’ : 1 , ’ va l ’ : 1} #S u p s t i t u t e Remote Reques t
s e l f .RTR = { ’ l en ’ : 1 , ’ va l ’ : 1} #Remote Transmit ion Reques t
s e l f .DLC = { ’ l en ’ : 4 , ’ va l ’ : 0} #Data Lenght Count
s e l f . DLCTableCode = {0 :0 , 1 : 1 , 2 : 2 , 3 : 3 , 4 : 4 , 5 : 5 , 6 : 6 , 7 : 7 , 8 : 8 , 9 : 8 , 10 : 8 , 11 : 8 , 12 : 8 , 13 : 8 , 14 : 8 , 15 :8}s e l f . Data = [ ] #Dane
s e l f .RB0 = { ’ l en ’ : 1 , ’ va l ’ : 0} #Reserved Bi t 0
s e l f .RB1 = { ’ l en ’ : 1 , ’ va l ’ : 0} #Reserved Bi t 1
s e l f .CRC = { ’ l en ’ : 15 , ’ va l ’ : 0} #C y c l i c Redundancy Check
s e l f .CRCDEL = { ’ l en ’ : 1 , ’ va l ’ : 1} #CRC D e l i m i t e r
s e l f .ACK = { ’ l en ’ : 1 , ’ va l ’ : 1} #Acknowledge
s e l f .ACKDEL = { ’ l en ’ : 1 , ’ va l ’ : 1} #Acknowledge D e l i m i t e r
s e l f .EOF = { ’ l en ’ : 7 , ’ va l ’ : 0x7F} #End Of Frame
s e l f . INTSPACE = { ’ l en ’ : 3 , ’ va l ’ : 0x07} #InterFrame Space
s e l f . nxBi t = 0 #NXBIT wykorzys tywany przy o b l i c z a n i u CRC
s e l f . nxCRC = 0 #CRCNXT wykorzys tywany pr zy o b l i c z a n i u CRC
SOF = { ’ l en ’ : 1 , ’ va l ’ : 0} #S t a r t Of Frame
ID = { ’ l en ’ : 29 , ’ va l ’ : 0} #I d e n t i f i e r
ID1 = { ’ l en ’ : 11}ID2 = { ’ l en ’ : 18}IDE = { ’ l en ’ : 1 , ’ va l ’ : 0} #I d e n t i f i e r E x t e n t i o n
SRR = { ’ l en ’ : 1 , ’ va l ’ : 1} #S u p s t i t u t e Remote Reques t
RTR = { ’ l en ’ : 1 , ’ va l ’ : 0} #Remote Transmit ion Reques t
DLC = { ’ l en ’ : 4 , ’ va l ’ : 0} #Data Lenght Count
Data = [ ] #Dane
RB0 = { ’ l en ’ : 1 , ’ va l ’ : 0} #Reserved Bi t 0
RB1 = { ’ l en ’ : 1 , ’ va l ’ : 0} #Reserved Bi t 1
CRC = { ’ l en ’ : 15 , ’ va l ’ : 0} #C y c l i c Redundancy Check
CRCDEL = { ’ l en ’ : 1 , ’ va l ’ : 1} #CRC D e l i m i t e r
ACK = { ’ l en ’ : 1 , ’ va l ’ : 1} #Acknowledge
ACKDEL = { ’ l en ’ : 1 , ’ va l ’ : 1} #Acknowledge D e l i m i t e r
EOF = { ’ l en ’ : 7 , ’ va l ’ : 0x7F} #End Of Frame
INTSPACE = { ’ l en ’ : 3 , ’ va l ’ : 0x07} #InterFrame Space
nxBi t = 0 #NXBIT wykorzys tywany przy o b l i c z a n i u CRC
nxCRC = 0 #CRCNXT wykorzys tywany przy o b l i c z a n i u CRC
#−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−#∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗# Klasa za jmujaca s i e przygotwaniem ∗# ramki CAN ∗
Dodatek C. Kod programu w Pythonie 141
# ∗# Funkcja w y l i c z a j a c a c z e s c i o w e CRC ∗#∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗
def GeneratePartCRC ( s e l f , value , l en ) :
Mask = 1 # p r i n t ”%d | %d | %d | %x ; ” % ( s e l f .CRC, va lue , len , mask )
Mask <<= len−1
while l en > 0 :
i f ( ( value & Mask) == Mask) :
s e l f . nxBi t = 1
else :
s e l f . nxBi t = 0
s e l f . nxCRC = s e l f . nxBi t ˆ ( ( s e l f .CRC[ ’ va l ’ ] >> 14) & 0x1 ) # CRCNXT = NXTBIT EXOR CRC RG(14)
s e l f .CRC[ ’ va l ’ ] = ( s e l f .CRC[ ’ va l ’ ] << 1) & 0x7FFF # CRC RG( 1 4 : 1 ) = CRC RG( 1 3 : 0 )
# CRC RG( 0 ) = 0
i f ( s e l f . nxCRC) : # IF CRCNXT THEN
s e l f .CRC[ ’ va l ’ ] = ( s e l f .CRC[ ’ va l ’ ] ˆ 0x4599 ) & 0x7FFF # CRC RG( 1 4 : 0 ) = CRC RG( 1 4 : 0 ) EXOR (0 x4599 )
l en −= 1
value = ( value << 1) & ( ( Mask<<1)−1) #p r i n t ”%4x | %x/%x | %d | %x | %x ; ” % ( s e l f .CRC, va lue , mask , len , s e l f . n x B i t , s e l f . nxCRC )
#−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−#∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗# Klasa za jmujaca s i e przygotwaniem ∗# ramki CAN ∗# ∗# Funkcja w y l i c z a j a c a CRC ∗#∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗
def GenerateCRC ( s e l f ) :
s e l f .CRC[ ’ va l ’ ] = 0
s e l f . nxBi t = 0
s e l f . nxCRC = 0
s e l f . GeneratePartCRC ( s e l f .SOF[ ’ va l ’ ] , s e l f .SOF[ ’ l en ’ ] )
#warunek d l a ramki Standardowej
i f ( s e l f . IDE [ ’ va l ’ ] == 0) :
s e l f . GeneratePartCRC ( s e l f . ID [ ’ va l ’ ]&0x7FF , s e l f . ID1 [ ’ l en ’ ] )
s e l f . GeneratePartCRC ( s e l f .RTR[ ’ va l ’ ] , s e l f .RTR[ ’ l en ’ ] )
s e l f . GeneratePartCRC ( s e l f . IDE [ ’ va l ’ ] , s e l f . IDE [ ’ l en ’ ] )
s e l f . GeneratePartCRC ( s e l f .RB0[ ’ va l ’ ] , s e l f .RB0[ ’ l en ’ ] )
#warunek d l a ramki R o z s z e r z o n e j
i f ( s e l f . IDE [ ’ va l ’ ] == 1) :
s e l f . GeneratePartCRC (( s e l f . ID [ ’ va l ’ ]&0x1FFFFFFF)>>s e l f . ID2 [ ’ l en ’ ] , s e l f . ID1 [ ’ l en ’ ] )
s e l f . GeneratePartCRC ( s e l f .SRR[ ’ va l ’ ] , s e l f .SRR[ ’ l en ’ ] )
s e l f . GeneratePartCRC ( s e l f . IDE [ ’ va l ’ ] , s e l f . IDE [ ’ l en ’ ] )
s e l f . GeneratePartCRC (( s e l f . ID [ ’ va l ’ ]&0x3FFFF) , s e l f . ID2 [ ’ l en ’ ] )
s e l f . GeneratePartCRC ( s e l f .RTR[ ’ va l ’ ] , s e l f .RTR[ ’ l en ’ ] )
s e l f . GeneratePartCRC ( s e l f .RB1[ ’ va l ’ ] , s e l f .RB1[ ’ l en ’ ] )
s e l f . GeneratePartCRC ( s e l f .RB0[ ’ va l ’ ] , s e l f .RB0[ ’ l en ’ ] )
s e l f . GeneratePartCRC ( s e l f . DLCTableCode [ s e l f .DLC[ ’ va l ’ ] ] , s e l f .DLC[ ’ l en ’ ] )
#o b l i c z e n i e sumy k o n t r o l n e j d l a p o l a danych
i f s e l f .DLC > 0 :
for DLC in range ( s e l f . DLCTableCode [ s e l f .DLC[ ’ va l ’ ] ] ) :
s e l f . GeneratePartCRC ( s e l f . Data [ DLC ] , 8)
return s e l f .CRC[ ’ va l ’ ]
#−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−#∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗# Wygenerowanie t a b l i c y s t r u m i e n i a ∗#∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗
def CAN2DLL( s e l f ) :
s e l f . GenerateCRC ()
BitsStream = [ ]
BitsStream += Lab Supp . In t2B i t s ( s e l f .SOF[ ’ va l ’ ] , s e l f .SOF[ ’ l en ’ ] )
#warunek d l a ramki Standardowej
i f ( s e l f . IDE [ ’ va l ’ ] == 0) :
# BitsStream += Lab Supp . I n t 2 B i t s ( s e l f . ID [ ’ v a l ’ ]&0 x7FF , s e l f . ID1 )
BitsStream += Lab Supp . In t2B i t s ( s e l f . ID [ ’ va l ’ ]&(2∗∗ s e l f . ID1 [ ’ l en ’ ]−1) , s e l f . ID1 [ ’ l en ’ ] )
BitsStream += Lab Supp . In t2B i t s ( s e l f .RTR[ ’ va l ’ ] , s e l f .RTR[ ’ l en ’ ] )
BitsStream += Lab Supp . In t2B i t s ( s e l f . IDE [ ’ va l ’ ] , s e l f . IDE [ ’ l en ’ ] )
BitsStream += Lab Supp . In t2B i t s ( s e l f .RB0[ ’ va l ’ ] , s e l f .RB0[ ’ l en ’ ] )
i f ( s e l f . IDE [ ’ va l ’ ] == 1) :
#warunek d l a ramki R o z s z e r z o n e j
# Bi tsS tream += Lab Supp . I n t 2 B i t s ( ( s e l f . ID [ ’ v a l ’ ]&0x1FFFFFFF)>> s e l f . ID2 , s e l f . ID1 )
BitsStream += Lab Supp . In t2B i t s ( ( s e l f . ID [ ’ va l ’ ]&(2∗∗ s e l f . ID [ ’ l en ’ ] )−1)>>s e l f . ID2 [ ’ l en ’ ] , s e l f . ID1 [ ’ l en ’ ] )
BitsStream += Lab Supp . In t2B i t s ( s e l f .SRR[ ’ va l ’ ] , s e l f .SRR[ ’ l en ’ ] )
BitsStream += Lab Supp . In t2B i t s ( s e l f . IDE [ ’ va l ’ ] , s e l f . IDE [ ’ l en ’ ] )
# BitsStream += Lab Supp . I n t 2 B i t s ( ( s e l f . ID [ ’ v a l ’ ]&0x3FFFF) , s e l f . ID2 )
BitsStream += Lab Supp . In t2B i t s ( ( s e l f . ID [ ’ va l ’ ]&(2∗∗ s e l f . ID2 [ ’ l en ’ ]−1) ) , s e l f . ID2 [ ’ l en ’ ] )
BitsStream += Lab Supp . In t2B i t s ( s e l f .RTR[ ’ va l ’ ] , s e l f .RTR[ ’ l en ’ ] )
Dodatek C. Kod programu w Pythonie 142
BitsStream += Lab Supp . In t2B i t s ( s e l f .RB1[ ’ va l ’ ] , s e l f .RB1[ ’ l en ’ ] )
BitsStream += Lab Supp . In t2B i t s ( s e l f .RB0[ ’ va l ’ ] , s e l f .RB0[ ’ l en ’ ] )
BitsStream += Lab Supp . In t2B i t s ( s e l f . DLCTableCode [ s e l f .DLC[ ’ va l ’ ] ] , s e l f .DLC[ ’ l en ’ ] )
# p r i n t Bi t sS tream [−4: ]
#Umieszczanie danych w s t r u m i e n i u danych
i f s e l f .DLC > 0 :
for DLC in range ( s e l f . DLCTableCode [ s e l f .DLC[ ’ va l ’ ] ] ) :
BitsStream += Lab Supp . In t2B i t s ( s e l f . Data [ DLC ] , 8)
BitsStream += Lab Supp . In t2B i t s ( s e l f .CRC[ ’ va l ’ ] , s e l f .CRC[ ’ l en ’ ] )
BitsStream += Lab Supp . In t2B i t s ( s e l f .CRCDEL[ ’ va l ’ ] , s e l f .CRCDEL[ ’ l en ’ ] )
BitsStream += Lab Supp . In t2B i t s ( s e l f .ACK[ ’ va l ’ ] , s e l f .ACK[ ’ l en ’ ] )
BitsStream += Lab Supp . In t2B i t s ( s e l f .ACKDEL[ ’ va l ’ ] , s e l f .ACKDEL[ ’ l en ’ ] )
BitsStream += Lab Supp . In t2B i t s ( s e l f .EOF[ ’ va l ’ ] , s e l f .EOF[ ’ l en ’ ] )
#Gdy w y s t e p u j e InterFrame Space doda j na koncu
i f s e l f . INTSPACE[ ’ l en ’ ] > 0 :
BitsStream += Lab Supp . In t2B i t s ( s e l f . INTSPACE[ ’ va l ’ ] , s e l f . INTSPACE[ ’ l en ’ ] )
return BitsStream
#−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−#∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗# Wygenerowanie t a b l i c y s t r u m i e n i a ∗#∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗
def RTRSRRv0( s e l f ) :
s e l f .RTR[ ’ va l ’ ] = 0
s e l f .SRR[ ’ va l ’ ] = −1
s e l f . IDE [ ’ va l ’ ] = 0
def RTRSRRv1( s e l f ) :
s e l f .RTR[ ’ va l ’ ] = −1
s e l f .SRR[ ’ va l ’ ] = 0
s e l f . IDE [ ’ va l ’ ] = 1
def RTRSRRv2( s e l f ) :
s e l f .RTR[ ’ va l ’ ] = 1
s e l f .SRR[ ’ va l ’ ] = −1
s e l f . IDE [ ’ va l ’ ] = 0
def RTRSRRv3( s e l f ) :
s e l f .RTR[ ’ va l ’ ] = −1
s e l f .SRR[ ’ va l ’ ] = 1
s e l f . IDE [ ’ va l ’ ] = 1
def DLL2CAN( s e l f , InStream ) :
RTRSRR = {0 : s e l f .RTRSRRv0, 1 : s e l f .RTRSRRv1, 2 : s e l f .RTRSRRv2, 3 : s e l f .RTRSRRv3}#dodanie c i s z y
i f l en ( InStream ) < 150 :
InStream += [ 1 ] ∗ (150 − l en ( InStream ) )
#SOF
SPos = 0
EPos = SPos + s e l f .SOF[ ’ l en ’ ]
i f l en ( InStream ) > EPos :
s e l f .SOF[ ’ va l ’ ] = Lab Supp . B i t s2 In t ( InStream [ SPos : EPos ] )
#ID1
SPos = EPos
EPos += s e l f . ID1 [ ’ l en ’ ]
i f l en ( InStream ) > EPos :
s e l f . ID [ ’ va l ’ ] = Lab Supp . B i t s2 In t ( InStream [ SPos : EPos ] )
#RTR i IDE
SPos = EPos
EPos += s e l f .RTR[ ’ l en ’ ] + s e l f . IDE [ ’ l en ’ ]
i f l en ( InStream ) > EPos :
tmpVal = Lab Supp . B i t s2 In t ( InStream [ SPos : EPos ] )
RTRSRR. get ( tmpVal , ’ Error tmpVal ’ ) ( )
#Ramka20A
# i f tmpVal == 2 or tmpVal == 0 :
#Ramka20B
i f tmpVal == 3 or tmpVal == 1 :
#ID2
SPos = EPos
EPos += s e l f . ID2 [ ’ l en ’ ]
i f l en ( InStream ) > EPos :
s e l f . ID [ ’ va l ’ ] <<= s e l f . ID2 [ ’ l en ’ ]
s e l f . ID [ ’ va l ’ ] += Lab Supp . B i t s2 In t ( InStream [ SPos : EPos ] )
#RTR
SPos = EPos
EPos += s e l f .RTR[ ’ l en ’ ]
i f l en ( InStream ) > EPos :
s e l f .RTR[ ’ va l ’ ] = Lab Supp . B i t s2 In t ( InStream [ SPos : EPos ] )
#RB1
Dodatek C. Kod programu w Pythonie 143
SPos = EPos
EPos += s e l f .RB1[ ’ l en ’ ]
i f l en ( InStream ) > EPos :
s e l f .RB1[ ’ va l ’ ] = Lab Supp . B i t s2 In t ( InStream [ SPos : EPos ] )
#RB0
SPos = EPos
EPos += s e l f .RB0[ ’ l en ’ ]
i f l en ( InStream ) > EPos :
s e l f .RB0[ ’ va l ’ ] = Lab Supp . B i t s2 In t ( InStream [ SPos : EPos ] )
#DLC
SPos = EPos
EPos += s e l f .DLC[ ’ l en ’ ]
i f l en ( InStream ) > EPos :
s e l f .DLC[ ’ va l ’ ] = Lab Supp . B i t s2 In t ( InStream [ SPos : EPos ] )
#I f DLC i s b i g g e r then 8 DLC has v a l u e e q u a l 8
i f s e l f .DLC[ ’ va l ’ ] > 8 :
s e l f .DLC[ ’ va l ’ ] = 8
#o b s l u g a danych
i f s e l f .DLC[ ’ va l ’ ] >= 0 and s e l f .DLC[ ’ va l ’ ] <= 8:
for Byte in range ( s e l f .DLC[ ’ va l ’ ] ) :
SPos = EPos
EPos += 8
i f l en ( InStream ) > EPos :
s e l f . Data += [ Lab Supp . B i t s2 In t ( InStream [ SPos : EPos ] ) ]
else :
print ’ Errors ’ + s t r ( s e l f .DLC[ ’ va l ’ ] )
#CRC
SPos = EPos
EPos += s e l f .CRC[ ’ l en ’ ]
i f l en ( InStream ) > EPos :
s e l f .CRC[ ’ va l ’ ] = Lab Supp . B i t s2 In t ( InStream [ SPos : EPos ] )
#CRCDEL
SPos = EPos
EPos += s e l f .CRCDEL[ ’ l en ’ ]
i f l en ( InStream ) > EPos :
s e l f .CRCDEL[ ’ va l ’ ] = Lab Supp . B i t s2 In t ( InStream [ SPos : EPos ] )
#ACK
SPos = EPos
EPos += s e l f .ACK[ ’ l en ’ ]
i f l en ( InStream ) > EPos :
s e l f .ACK[ ’ va l ’ ] = Lab Supp . B i t s2 In t ( InStream [ SPos : EPos ] )
#ACKDEL
SPos = EPos
EPos += s e l f .ACKDEL[ ’ l en ’ ]
i f l en ( InStream ) > EPos :
s e l f .ACKDEL[ ’ va l ’ ] = Lab Supp . B i t s2 In t ( InStream [ SPos : EPos ] )
#EOF
SPos = EPos
EPos += s e l f .EOF[ ’ l en ’ ]
i f l en ( InStream ) > EPos :
s e l f .EOF[ ’ va l ’ ] = Lab Supp . B i t s2 In t ( InStream [ SPos : EPos ] )
#IFS
SPos = EPos
EPos += s e l f . INTSPACE[ ’ l en ’ ]
i f l en ( InStream ) > EPos :
s e l f . INTSPACE[ ’ va l ’ ] = Lab Supp . B i t s2 In t ( InStream [ SPos : EPos ] )
#−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−#∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗# Wygenerowanie t a b l i c y s t r u m i e n i a ∗#∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗
def InputFullFrame ( s e l f , ID=0, IDE=0, RTR=0, Data =[ ] , RB0=0, RB1=0, CRC=0, ACK=0, CRCDEL=1, ACKDEL=1, SOF=0) :
DLC = len ( Data )
i f IDE == 0 :
s e l f . ID [ ’ l en ’ ] = 11
s e l f . ID [ ’ va l ’ ] = ID
else :
s e l f . ID [ ’ l en ’ ] = 29
s e l f . ID [ ’ va l ’ ] = ID
s e l f . IDE [ ’ va l ’ ] = IDE
s e l f .RTR[ ’ va l ’ ] = RTR
i f RTR == 1 :
s e l f .DLC[ ’ va l ’ ] = 0
else :
i f ( (DLC >= 0) & (DLC <= 8) ) :
Dodatek C. Kod programu w Pythonie 144
s e l f .DLC[ ’ va l ’ ] = DLC
for i in range (DLC) :
s e l f . Data = Data
else :
print ’ Blad z l a wartosc DLC: ’ + i n t 2 s t r (DLC)
s e l f .RB0[ ’ va l ’ ] = RB0
s e l f .RB1[ ’ va l ’ ] = RB1
s e l f .CRC[ ’ va l ’ ] = CRC
s e l f .ACK[ ’ va l ’ ] = ACK
s e l f .CRCDEL[ ’ va l ’ ] = CRCDEL
s e l f .ACKDEL[ ’ va l ’ ] = ACKDEL
s e l f .SOF[ ’ va l ’ ] = SOF
#∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗# Klasa za jmujaca s i e przygotwaniem ∗# ramki CAN ∗# ∗# Funkcja w y l i c z a j a c a CRC ∗#∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗
def PrintSetup ( s e l f ) :
print ’SOF:\ t ’ , s e l f .SOF
print ’ ID :\ t ’ , s e l f . ID
print ’ ID1 :\ t ’ , s e l f . ID1
print ’ ID2 :\ t ’ , s e l f . ID2
print ’RTR:\ t ’ , s e l f .RTR
print ’ IDE :\ t ’ , s e l f . IDE
print ’SRR:\ t ’ , s e l f .SRR
print ’DLC:\ t ’ , s e l f .DLC
print ’DLCtCode :\ t ’ , s e l f . DLCTableCode
print ’RB0:\ t ’ , s e l f .RB0
print ’RB1:\ t ’ , s e l f .RB1
print ’CRC:\ t ’ , s e l f .CRC
print ’CRCDEL:\ t ’ , s e l f .CRCDEL
print ’ACK:\ t ’ , s e l f .ACK
print ’ACKDEL:\ t ’ , s e l f .ACKDEL
print ’EOF:\ t ’ , s e l f .EOF
print ’INTSPACE:\ t ’ , s e l f . INTSPACE
#∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗# Koniec k l a s y Ramki CAN ∗#∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗
#c l a s s CANRB0 1
class CANRB0 1(CAN) :
def i n i t ( s e l f ) :
s e l f .RB0 = { ’ l en ’ : 1 , ’ va l ’ : 1}
#c l a s s CANDTL3b
class CANDTL3b(CAN) :
def i n i t ( s e l f ) :
s e l f .DLC = { ’ l en ’ : 3 , ’ va l ’ : 0} #Data Lenght Count
DLC = { ’ l en ’ : 3 , ’ va l ’ : 0} #Data Lenght Count
#c l a s s CANDTLs4b
class CANDTLs4b(CAN) :
def i n i t ( s e l f ) :
#w e r s j a 1
s e l f . DLCTableCode = {0:4 , 1 : 8 , 2 : 9 , 3 : 10 , 4 : 11 , 5 : 12 , 6 : 13 , 7 : 14 , 8 :15}#w e r s j a 2
s e l f . DLCTableCode = {0:7 , 1 : 8 , 2 : 9 , 3 : 10 , 4 : 11 , 5 : 12 , 6 : 13 , 7 : 14 , 8 :15}class CANDTL3b RB0 1(CANDTL3b) :
def i n i t ( s e l f ) :
s e l f .RB0 = { ’ l en ’ : 1 , ’ va l ’ : 1}#c l a s s CANRData − r e a l i z o w a n e razem z normalnym CANem
#c l a s s CANMoreSecurity − p r z e b a d a c poziom b e z p i e c z e n s t w a p o p r z e z sprawdzan ie poprawnosc i k o l e j n y c h p o z y c j i
#c l a s s CANMoreSecurity (CAN) :
# d e f i n i t ( s e l f ) :
C.2. Kod biblioteki DLL.py
import Lab Supp
import PHY
Dodatek C. Kod programu w Pythonie 145
#−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−#−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−#∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗# ∗# Klasa r e p r e z e n t u j a c a warstwe l a c z a danych ∗# ∗#∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗class DLL:
def i n i t ( s e l f ) :
s e l f . PHYLayer = PHY. Medium ()
s e l f . Beg inOfStu f f ing = 0 # Pocza tek d z i a l a n i a a l gory tmu ws tawian ia b i t o w
s e l f . EndOfStuff ing = 10 # L i c z b a b i t o w l i c z o n a od prawej s t r o n y
s e l f . LenghtSameBits = 5 # Dlugosc b i t o w t e g o samego typu , po ktorym n a s t e p u j e dodanie b i t u komplementarnego
s e l f . tBSStats = [ ]
s e l f . fBSStats = { ’make ’ : ’ ’ , ’ f i l e ’ : ’ ’} #S t a t y s t y k i L i c z b y b i t o w wstawionych
#count : On/ Of f
# f i l e : nazwa p l i k u wynikowego
s e l f . oBSStats = { ’make ’ : ’ ’}s e l f . tBSHist = [ ]
s e l f . fBSHist = { ’make ’ : ’ ’ , ’ f i l e ’ : ’ ’} #Histogram L i c z b y b i t o w wstawionych
#count : On/ Of f
# f i l e : nazwa p l i k u wynikowego
s e l f . oBSHist = { ’make ’ : ’ ’}s e l f . tOnes = [ ]
s e l f . cBitStuffMM = 0 #T a b l i c a z a w i e r a j a c a w i l u ramkach przy o d b i o r z e wykry to b l a d BS ( BitStufMishMash )
s e l f . sRMOnesAtBegin = ’ ’ #setRemoveOnesAtBegining
PHYLayer = PHY. Medium ()
CANStream = [ ]
Beg inOfStu f f ing = 0 # Pocza tek d z i a l a n i a a l gory tmu ws tawian ia b i t o w
EndOfStuff ing = 10 # L i c z b a b i t o w l i c z o n a od prawej s t r o n y
LenghtSameBits = 5 # Dlugosc b i t o w t e g o samego typu , po ktorym n a s t e p u j e dodanie b i t u komplementarnego
tBSStats = [ ]
fBSStats = { ’make ’ : ’ ’ , ’ f i l e ’ : ’ ’} #S t a t y s t y k i L i c z b y b i t o w wstawionych
#count : On/ Of f
# f i l e : nazwa p l i k u wynikowego
oBSStats = { ’make ’ : ’ ’}tBSHist = [ ]
fBSHist = { ’make ’ : ’ ’ , ’ f i l e ’ : ’ ’} #Histogram L i c z b y b i t o w wstawionych
#count : On/ Of f
# f i l e : nazwa p l i k u wynikowego
oBSHist = { ’make ’ : ’ ’}tOnes = [ ]
cBitStuffMM = 0 #T a b l i c a z a w i e r a j a c a w i l u ramkach przy o d b i o r z e wykry to b l a d BS ( BitStufMishMash )
sRMOnesAtBegin = ’ ’ #setRemoveOnesAtBegining
#∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗# Z a p i s u j e l i c z b e j e d y n e k na p o s z c z e g o l n y c h p o z y c j a c h ∗#∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗
def Ones ( s e l f ) :
i f l en ( s e l f . tOnes ) < l en ( s e l f . CANStream) :
s e l f . tOnes += [ 0 ] ∗ ( l en ( s e l f . CANStream)−l en ( s e l f . tOnes ) )
for Pos in range ( l en ( s e l f . CANStream) ) :
i f s e l f . CANStream [ Pos ] == 1 :
s e l f . tOnes [ Pos ] += 1
#∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗# Wysyla dane do medium t r a n s m i s y j n e g o ∗#∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗
def Send ( s e l f , CANStream) :
s e l f . CANStream = CANStream
s e l f . Ones ( )
s e l f . B i t S t u f f i n g ( )
s e l f . PHYLayer . Transmiss ion ( s e l f . CANStream)
#∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗# Odebranie danych z medium t r a n s m i s y j n e g o ∗#∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗
def Receive ( s e l f ) :
s e l f . CANStream = s e l f . PHYLayer . Receive ( )
#∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗# Przeprowadzen ie c a l k o w i t e g o procesu t r a n s m i s j i ∗#∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗
def Transmiss ion ( s e l f , CANStream) :
s e l f . Send (CANStream)
s e l f . Receive ( )
#∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗# Przeprowadznie na s t r u m i n i u procesu ws tawian ia b i t o w ∗
Dodatek C. Kod programu w Pythonie 146
#∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗def B i t S t u f f i n g ( s e l f ) :
#wyznaczen ie d l u g o s c i p o c z a t k o w e j do s t a t y s t y k i d l u g o s c i b i t u
# beforeBS = l e n ( s e l f . Bi t sS tream )
BSCount = 0
StreamPos = s e l f . Beg inOfStu f f ing
SameBitStream = [ ]
while StreamPos <= ( len ( s e l f . CANStream)−( s e l f . EndOfStuff ing+s e l f . LenghtSameBits ) ) :
# p r i n t s e l f . LenghtSameBits , ’ | ’ , s e l f . EndOfStu f f ing , ’ | ’ , l e n ( s e l f . Bi t sS tream ) , ’ | ’ , StreamPos , ’ | ’ , ( ( l e n ( s e l f . Bi t sS tream ) )−( s e l f . E n d O f S t u f f i n g+ s e l f . LenghtSameBits ) )
SameBitStream = [ s e l f . CANStream [ StreamPos ] ] ∗ s e l f . LenghtSameBits
i f s e l f . CANStream [ StreamPos : StreamPos+s e l f . LenghtSameBits ] == SameBitStream :
s e l f . CANStream [ StreamPos : StreamPos+s e l f . LenghtSameBits ] = s e l f . CANStream [ StreamPos : StreamPos+s e l f . LenghtSameBits ]+ [ ( s e l f . CANStream [ StreamPos ]ˆ0 x01 ) ]
#o b s l u z e n i e generowania his togramow
i f ( s e l f . fBSHist [ ’make ’ ] == ’ Yes ’ ) :
HistPos = StreamPos+s e l f . LenghtSameBits−BSCount−1
i f ( l en ( s e l f . tBSHist ) <= HistPos ) :
s e l f . tBSHist += [ 0 ] ∗ ( HistPos−l en ( s e l f . tBSHist )+1)
s e l f . tBSHist [ HistPos ] += 1
BSCount += 1
StreamPos += s e l f . LenghtSameBits−1
StreamPos += 1
#wyznaczen ie d l u g o s c i s t r u m i e n i a po z a s t o s o w a n i u b i t s u f f i n g u
afterBS = len ( s e l f . CANStream)
#a k t u a l i z a c j a s t a t y s t y k B i t S t u f f i n g u
i f ( s e l f . fBSStats [ ’make ’ ] == ’ Yes ’ ) :
#s p r a w d z e n i e czy t a b l i c a j e s t w y s t a r c z a j a c o d l u g a
# i f l e n ( s e l f . t B S S t a t s )<=(af terBS−be foreBS +1) :
i f ( l en ( s e l f . tBSStats ) <= (BSCount ) ) :
#w r a z i e k o n i e c z n o s c i w y d l u z e n i e t a b l i c y
s e l f . tBSStats += [ 0 ] ∗ ( BSCount−l en ( s e l f . tBSStats )+1)
s e l f . tBSStats [ BSCount ] += 1
#∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗# Przeprowadznie na s t r u m i n i u procesu c z y s z c z e n i a s t r u m i e n i a ∗#∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗
def BitDeStu f f ing ( s e l f ) :
BSMMFlag = 0
De lL i s t = [ ]
#Wlaczenie o p c j i usuwania ”1” na p o c z a t k u do napo tkan ia p i e r w s z e g o ”0”
i f s e l f . sRMOnesAtBegin == ’ Yes ’ :
#Usuwanie j e d y n e k na p o c z a t k u
while s e l f . CANStream [ 0 ] == 1 :
del s e l f . CANStream [ 0 ]
#Usuwanie b i t o w wstawionych
#Kopia t a b l i c y z a w i e r a j a c a j e d y n i e o b s z a r p o d l e g a j a c y B i t S t u f i n g o w i
i f s e l f . EndOfStuff ing > 0 :
BDSStream = s e l f . CANStream [ s e l f . Beg inOfStu f f ing :− s e l f . EndOfStuff ing ]
else :
BDSStream = s e l f . CANStream [ s e l f . Beg inOfStu f f ing : ]
StreamPos = 0
while StreamPos <= ( len (BDSStream) − ( s e l f . LenghtSameBits+1) ) :
SameBitStream = [ s e l f . CANStream [ StreamPos ] ] ∗ s e l f . LenghtSameBits
i f s e l f . CANStream [ StreamPos : StreamPos+s e l f . LenghtSameBits ] == SameBitStream :
De lL i s t += [ StreamPos+s e l f . LenghtSameBits ]
i f s e l f . CANStream [ StreamPos ] != ( s e l f . CANStream [ StreamPos+s e l f . LenghtSameBits ] ˆ 0x01 ) :
s e l f . cBitStuffMM += 1
BSMMFlag = 1
StreamPos = len (BDSStream)
StreamPos += s e l f . LenghtSameBits − 1
StreamPos += 1
DelPos = 0
for DelPos in range ( l en ( De lL i s t ) ) :
del BDSStream [ De lL i s t . pop ( ) ]
i f BSMMFlag == 1 :
s e l f . CANStream = [ ]
else :
i f s e l f . EndOfStuff ing > 0 :
s e l f . CANStream [ s e l f . Beg inOfStu f f ing :− s e l f . EndOfStuff ing ] = BDSStream
else :
s e l f . CANStream [ s e l f . Beg inOfStu f f ing : ] = BDSStream
return 0
#∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗# Wygenerowanie s t a t y s t y k ∗#∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗
Dodatek C. Kod programu w Pythonie 147
def Pr in tSta t s ( s e l f , ID , header = ’ ’ , bottom = ’ ’ ) :
s e l f . PHYLayer . Pr in tS ta t s ( ID)
i f s e l f . oBSStats [ ’make ’ ] == ’ Yes ’ :
i f s e l f . fBSStats [ ’make ’ ] == ’ Yes ’ :
print ”%s ||% s ” % (ID , Lab Supp . B i t s2St r ( s e l f . tBSStats , ’ | ’ ) )
#Z a p i s z do p l i k u
i f s e l f . fBSStats [ ’ f i l e ’ ] != ’ ’ :
i f header != ’ ’ :
Lab Supp . Write2Fi le ( s e l f . fBSStats [ ’ f i l e ’ ] , ’ a+’ , header )
Lab Supp . Write2Fi le ( s e l f . fBSStats [ ’ f i l e ’ ] , ’ a+’ , ”%s ||% s\n” % (ID , Lab Supp . B i t s2St r ( s e l f . tBSStats , ’ | ’ ) ) )
i f bottom != ’ ’ :
Lab Supp . Write2Fi le ( s e l f . fBSStats [ ’ f i l e ’ ] , bottom )
# p r i n t ’ wydrukowano p l i k : ’+ s e l f . f B S S t a t s [ ’ f i l e ’ ]+ ’\n ’
# i f s e l f . oBSHist [ ’ make ’ ] == ’ Yes ’ :
i f s e l f . fBSHist [ ’make ’ ] == ’ Yes ’ :
print ”%s ||% s ” % (ID , Lab Supp . B i t s2St r ( s e l f . tBSHist , ’ | ’ ) )
#Z a p i s z do p l i k u
i f s e l f . fBSHist [ ’ f i l e ’ ] != ’ ’ :
i f header != ’ ’ :
Lab Supp . Write2Fi le ( s e l f . fBSHist [ ’ f i l e ’ ] , ’ a+’ , header )
Lab Supp . Write2Fi le ( s e l f . fBSHist [ ’ f i l e ’ ] , ’ a+’ , ”%s ||% s\n” % (ID , Lab Supp . B i t s2St r ( s e l f . tBSHist , ’ | ’ ) ) )
i f bottom != ’ ’ :
Lab Supp . Write2Fi le ( s e l f . fBSStats [ ’ f i l e ’ ] , bottom )
# p r i n t ’ wydrukowano p l i k : ’+ s e l f . fBSHis t [ ’ f i l e ’ ]
return 0
#−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−#−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−#a = CAN( )
#a . ID [ ’ v a l ’ ]=1000
#a . IDE [ ’ v a l ’ ]=0
#a .CRC[ ’ v a l ’ ]=2
#p r i n t a .CRC[ ’ v a l ’ ]
#a . ALL2DLL( )
C.3. Kod biblioteki PHY.py
import random
import Lab Supp
import sys
#random . seed ( )
# 1) Wstawianie b i t o w
# 2) Generowanie b ledow
# a ) Losowych ( t y p e = Random)
# b ) Blokowych ( t y p e = Block )
# c ) Przek lamania b ledow wstawionych ( t y p e = B i t S t u f )
#−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−#−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−#∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗# Klasa za jmujaca s i e o b s l u g a ∗# warstwy f i z y c z n e j l a c z a ∗#∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗class Medium :
def i n i t ( s e l f ) :
s e l f . InStream = [ ]
s e l f . ErrorTab = [ ]
s e l f . OutStream = [ ]
s e l f . Errors = { ’ type ’ : ’ ’ , ’ amount ’ : 0}s e l f . ErrorsRange = { ’ begin ’ : 0 , ’ end ’ : 0}s e l f . tE r r o r sS ta t s = [ ]
s e l f . oErrorStat s = { ’make ’ : ’ ’}s e l f . fE r r o rS t a t s = { ’make ’ : ’ ’ , ’ fname ’ : ’ ’} #S t a t y s t y k i wystepowania b ledow
#count : On/ Of f
#fname : nazwa p l i k u wynikowego
s e l f . tLenStats = [ ]
s e l f . oLenStats = { ’make ’ : ’ ’}s e l f . fLenStats = { ’make ’ : ’ ’ , ’ fname ’ : ’ ’} #S t a t y s t y k i d l u g o s c i ramki
#count : On/ Of f
#fname : nazwa p l i k u wynikowego
Dodatek C. Kod programu w Pythonie 148
InStream = [ ]
ErrorTab = [ ]
OutStream = [ ]
Errors = { ’ type ’ : ’ ’ , ’ amount ’ : 0}ErrorsRange = { ’ begin ’ : 0 , ’ end ’ : 0} #b e g i n j a k i end przy jmuja w a r t o s c i d o d a t n i e
#b e g i n oznacza i l e znakow od p o c z a t k u n i e b e d z i e przek lamywanych
#end oznacza i l e znakow od konca n i e b e d z i e przek lamywanych
tE r r o r sS ta t s = [ ]
oErrorStat s = { ’make ’ : ’ ’}fE r r o rS ta t s = { ’make ’ : ’ ’ , ’ fname ’ : ’ ’} #S t a t y s t y k i wystepowania b ledow
#count : On/ Of f
#fname : nazwa p l i k u wynikowego
tLenStats = [ ]
oLenStats = { ’make ’ : ’ ’}fLenStats = { ’make ’ : ’ ’ , ’ fname ’ : ’ ’} #S t a t y s t y k i d l u g o s c i ramki
#count : On/ Of f
#fname : nazwa p l i k u wynikowego
#∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗# Generowanie Pojedynczych Bledow Losowych ∗#∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗
def S inge lB i tE r r o r s ( s e l f ) :
tStreamLen = len ( s e l f . InStream )
i f ( s e l f . Errors [ ’ amount ’ ] < 1 . 0 ) :
tEr ro r s = tStreamLen ∗ s e l f . Errors [ ’ amount ’ ]
else :
tEr ro r s = s e l f . Errors [ ’ amount ’ ]
# i f ( s e l f . t E r r o r s S t a t s == [ ] ) :
s e l f . tE r r o r sS ta t s = [ 0 ] ∗ tStreamLen
s e l f . ErrorTab = [ 0 ] ∗ tStreamLen
while tEr ro r s > 0 :
pos = random . randint ( s e l f . ErrorsRange [ ’ begin ’ ] , tStreamLen−1− s e l f . ErrorsRange [ ’ end ’ ] )
i f ( s e l f . ErrorTab [ pos ] == 0) :
s e l f . ErrorTab [ pos ] = 1
s e l f . tE r r o r sS ta t s [ pos ] += 1
s e l f . OutStream [ pos ] = s e l f . InStream [ pos ] ˆ 1
else :
tEr ro r s += 1
tErro r s −= 1
#∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗# Generowanie Blokowych Bledow ∗#∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗
def Mult iB i t sError s ( s e l f ) :
tStreamLen = len ( s e l f . InStream )
i f ( s e l f . Errors [ ’ amount ’ ] < 1 . 0 ) :
tEr ro r s = tStreamLen ∗ s e l f . Errors [ ’ amount ’ ]
else :
tEr ro r s = s e l f . Errors [ ’ amount ’ ]
s e l f . ErrorTab = [ 0 ] ∗ tStreamLen
ErrorBegin = random . randint ( s e l f . ErrorsRange [ ’ begin ’ ] , tStreamLen−tErrors−s e l f . ErrorsRange [ ’ end ’ ] )
StartPos = ErrorBegin
s e l f . ErrorTab [ StartPos : StartPos+tErro r s ] = [ 1 ]∗ tEr ro r s
s e l f . OutStream [ : ] = s e l f . InStream [ : ]
s e l f . OutStream [ StartPos : StartPos+tErro r s ] = map(lambda Bit : Bit ˆ0x01 , s e l f . OutStream [ StartPos : StartPos+tErro r s ] )
# d e f S t u f f B i t s E r r o r s ( s e l f ) :
def Send ( s e l f , InStream ) :
s e l f . InStream = InStream
def SimulateErrors ( s e l f ) :
i f s e l f . Errors [ ’ type ’ ] == ’Random ’ : #b l e d y lo sowe
s e l f . S i ng e lB i tE r r o r s ( )
i f s e l f . Errors [ ’ type ’ ] == ’ Block ’ : #b l e d y grupowe
s e l f . Mul t iB i t sError s ( )
#i f s e l f . Errors [ ’ t y p e ’ ] == ’ B i t S t u f ’ : #b l e d y b i t s t u f
# s e l f . S t u f f B i t s E r r o r s ( )
# p r i n t s e l f . B i t sS tream
def Receive ( s e l f ) :
return s e l f . OutStream
#∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗# Wykonanie s y m u l a c j i t r a n s m i s j i ∗#∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗
def Transmiss ion ( s e l f , InStream ) :
s e l f . Send ( InStream )
s e l f . S imulateErrors ( )
Dodatek C. Kod programu w Pythonie 149
return s e l f . Receive ( )
#∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗# Wygenerowanie s t a t y s t y k ∗#∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗
def Pr in tSta t s ( s e l f , ID) :
# i f s e l f . oLenSta t s [ ’ make ’ ] == ’ Yes ’ :
# p r i n t ”%s | |% s\n” % ( ID , Lab Supp . B i t s 2 S t r ( s e l f . fBSSta t s , ’ | ’ ) )
# i f s e l f . f L e n S t a t s [ ’ make ’ ] == ’ Yes ’ :
#Z a p i s z do p l i k u
# p r i n t ”%s | |% s\n” % ( ID , Lab Supp . B i t s 2 S t r ( s e l f . fBSSta t s , ’ | ’ ) )
# p r i n t ’ Zap i s do p l i k u ’
# i f o E r r o r s S t a t s [ ’ make ’ ] == ’ Yes ’ :
# p r i n t ”%s | |% s\n” % ( ID , Lab Supp . B i t s 2 S t r ( s e l f . t E r r o r s S t a t s , ’ | ’ ) )
# i f fBSHis t [ ’ make ’ ] == ’ Yes ’ :
#Z a p i s z do p l i k u
# p r i n t ”%s | |% s\n” % ( ID , Lab Supp . B i t s 2 S t r ( s e l f . t E r r o r s S t a t s , ’ | ’ ) )
# p r i n t ’ Zap i s do p l i k u ’
return 0
C.4. Kod biblioteki LabSupp.py
#∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗# Zamiana l i c z b y na t a b l i c e r e p r e z e n t a c j i ∗# b i t o w e j [H: L ] ∗#∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗def In t2B i t s ( Integer , Lenght ) :
BitsStream = [ ]
Mask = 1
Mask <<= ( Lenght −1)
while Lenght > 0 :
i f ( ( In t eg e r & Mask) == Mask) :
BitsStream . append (1)
else :
BitsStream . append (0)
Lenght −= 1
Int ege r <<= 1
return BitsStream
def Bi t s2 In t ( Stream ) :
In t eg e r = 0
for Pos in range ( l en ( Stream ) ) :
I n t eg e r <<= 1
Int ege r += Stream [ Pos ]
return In t eg e r
def Bit s2St r ( Stream , Separator ) :
return Separator . j o i n (map(lambda Bit : s t r ( Bit ) , Stream ) )
def ProgresBar ( BarSize , CurrBarPos , PercDoneWork ) :
import sys
i f ( CurrBarPos != ( in t ) ( BarSize∗PercDoneWork ) ) :
CurrBarPos = ( in t ) ( BarSize∗PercDoneWork )
# s y s . s t d o u t . w r i t e (”% s\ r ” % ’ ’ . j o i n ( [ ’∗ ’ ]∗ t S c a l e ) )
sys . stdout . wr i t e ( ’∗ ’ )
sys . stdout . f l u s h ( )
return CurrBarPos
def FrameMarks ( Stream , MarkType , iMarkPlaces ) :
MarkPlaces = iMarkPlaces [ : ]
i f MarkType == ’ Lenght ’ :
for Pos in range ( l en ( MarkPlaces ) ) :
i f Pos > 0 :
MarkPlaces [ Pos ] += MarkPlaces [ Pos−1]
StartPos = 0
Correct ion = 0
for Place in MarkPlaces :
Place += Correct ion
Stream [ StartPos : Place ] = Stream [ StartPos : Place ] + [ ’ | ’ ]
Correct ion += 1
StartPos = Place
Dodatek C. Kod programu w Pythonie 150
return Stream
def Write2Fi le ( fName , fType , S t r ing ) :
F i l e = open ( fName , fType )
F i l e . wr i t e ( St r ing )
F i l e . f l u s h ( )
F i l e . c l o s e ( )
Dodatek D
Kod serwera
from socket import ∗HOST = ’ 157 . 158 . 57 . 37 ’ # Symbo l ic name meaning t h e l o c a l h o s t
PORT = 50007 # A r b i t r a r y non−p r i v i l e g e d p o r t
s = socket (AF INET ,SOCK STREAM)
s . bind ( (HOST, PORT) )
#format o f r e s p o n s e message (DO NOT ALTER IF YOU DONT KNOW WHAT U R DOING)
import time
s . l i s t e n (10)
while 1 :
conn , addr = s . accept ( )
print ’ Connected by ’ , addr
data = conn . recv (1024)
i f not data : break
f t s = open ( ’ t sdata . txt ’ , ’ r ’ )
f i n = f t s . read ( ) . s p l i t ( ’\n ’ )
f t s . c l o s e ( )
f s = open ( ’ f sda ta . txt ’ , ’ a ’ )
r e s = open ( ’ r e s u l t s . txt ’ , ’ a ’ )
t = time . l o c a l t ime ( )
print data
r e s . wr i t e ( s t r ( t [ 0 ] )+’− ’+s t r ( t [ 0 ] )+’− ’+s t r ( t [ 1 ] )+’− ’+s t r ( t [ 2 ] )+’ ’+s t r ( t [ 3 ] )+’ : ’+s t r ( t [ 4 ] )+’ : ’+s t r ( t [ 5 ] )+’ ’+s t r ( addr )+’\n ’+data )
l i n e p a r = f i n . pop (0)
conn . send ( l i n e p a r )
f t s = open ( ’ t sdata . txt ’ , ’w ’ )
f s . wr i t e ( s t r ( t [ 0 ] )+’− ’+s t r ( t [ 0 ] )+’− ’+s t r ( t [ 1 ] )+’− ’+s t r ( t [ 2 ] )+’ ’+s t r ( t [ 3 ] )+’ : ’+s t r ( t [ 4 ] )+’ : ’+s t r ( t [ 5 ] )+’ ’+s t r ( addr )+’ ’+l i n e p a r+’\n ’ )
f t s . wr i t e ( ’\n ’ . j o i n ( f i n ) )
f t s . f l u s h ( )
f t s . c l o s e ( )
r e s . c l o s e ( )
#conn . c l o s e ( )
Dodatek E
Kod klienta
import os
from socket import ∗HOST = ’ 157 . 158 . 57 . 37 ’ # Symbo l ic name meaning t h e l o c a l h o s t
PORT = 50007 # A r b i t r a r y non−p r i v i l e g e d p o r t
#format o f r e s p o n s e message (DO NOT ALTER IF YOU DONT KNOW WHAT U R DOING)
#s = s o c k e t (AF INET , SOCK STREAM)
import time
r e s u l t s = ’ Pierwsze Uruchomienie ’
while (1 ) :
s = socket (AF INET , SOCK STREAM)
s . connect ( (HOST, PORT) )
s . send ( s t r ( r e s u l t s ) )
param = s . recv (1024)
print param
r e s u l t s = os . popen ( ’ python CAN 29bit . py ’+param) . read ( )
r e s u l t s = param +’\n ’+ r e s u l t s
s . c l o s e ( )
Dodatek F
Kod programu dla mikroporcesora
#include <18f458 .H>
#define CAN BRG SYNCH JUMP WIDTH 0 // s y n c h r o n i z e d jump wid th ( d e f : 1 x Tq)
#define CAN BRG PRESCALAR 4 // baud r a t e g e n e r a t o r p r e s c a l a r ( d e f : 4) ( Tq = (2 x (PRE + 1) ) / Fosc )
#define CAN BRG SEG 2 PHASE TS TRUE // phase segment 2 t ime s e l e c t b i t ( d e f : f r e e l y programmable )
#define CAN BRG SAM 0 // sample o f t h e can bus l i n e
#define CAN BRG PHASE SEGMENT 1 5 // phase segment 1 ( d e f : 6 x Tq)
#define CAN BRG PROPAGATION TIME 2 // p r o p a g a t i o n t ime s e l e c t ( d e f : 3 x Tq)
#define CAN BRG WAKE FILTER FALSE// s e l e c t s can bus l i n e f i l t e r f o r wake up b i t
#define CAN BRG PHASE SEGMENT 2 5 // phase segment 2 t ime s e l e c t ( d e f : 6 x Tq)
#define CAN USE RX DOUBLE BUFFER TRUE // i f b u f f e r 0 o v e r f l o w s , do NOT use b u f f e r 1 t o put b u f f e r 0 data
#include <can−18xxx8 . c>
#f u s e s HS,NOPROTECT,NOLVP,NOWDT
#use delay ( c l ock =20000000)
#define CANBITOUT PIN E0
#define CANBITIN PIN E1
#define CHANGE TO HIGH(BIT) #asm BSF 0xF8D.0 #endasm ; de lay us (8) ;
#define CHANGE TO LOW(BIT) #asm BCF 0xF8D.0 #endasm ; de lay us (8) ;
#define KEEP TO LOW de lay us (8) ;
#define KEEP TO HIGH de lay us (8) ;
void send NormalExtendedFrame ( ) {SET TRIS E(0 x02 ) ;
CHANGE TO LOW(CANBITOUT) ; // s o f ”0” ( 1 )
KEEP TO LOW; // id11 . 1 1 ”0” ( 2 )
KEEP TO LOW; // id11 . 1 0 ”0” ( 3 )
KEEP TO LOW; // id11 . 0 9 ”0” ( 4 )
KEEP TO LOW; // id11 . 0 8 ”0” ( 5 )
CHANGE TO HIGH(CANBITOUT) ; //BS ”1” ( 1 )
CHANGE TO LOW(CANBITOUT) ; // id11 . 0 7 ”0” ( 1 )
KEEP TO LOW; // id11 . 0 6 ”0” ( 2 )
KEEP TO LOW; // id11 . 0 5 ”0” ( 3 )
KEEP TO LOW; // id11 . 0 4 ”0” ( 4 )
KEEP TO LOW; // id11 . 0 3 ”0” ( 5 )
CHANGE TO HIGH(CANBITOUT) ; //BS ”1” ( 1 )
CHANGE TO LOW(CANBITOUT) ; // id11 . 0 2 ”0” ( 1 )
KEEP TO LOW; // id11 . 0 1 ”0” ( 2 )
CHANGE TO HIGH(CANBITOUT) ; // i s s ”1” ( 1 )
KEEP TO HIGH; // i d e ”1” ( 2 )
CHANGE TO LOW(CANBITOUT) ; // id18 . 1 8 ”0” ( 1 )
KEEP TO LOW; // id18 . 1 7 ”0” ( 2 )
KEEP TO LOW; // id18 . 1 6 ”0” ( 3 )
KEEP TO LOW; // id18 . 1 5 ”0” ( 4 )
KEEP TO LOW; // id18 . 1 4 ”0” ( 5 )
CHANGE TO HIGH(CANBITOUT) ; //BS ”1” ( 1 )
CHANGE TO LOW(CANBITOUT) ; // id18 . 1 3 ”0” ( 1 )
KEEP TO LOW; // id18 . 1 2 ”0” ( 2 )
KEEP TO LOW; // id18 . 1 1 ”0” ( 3 )
KEEP TO LOW; // id18 . 1 0 ”0” ( 4 )
CHANGE TO HIGH(CANBITOUT) ; // id18 . 0 9 ”1” ( 1 )
CHANGE TO LOW(CANBITOUT) ; // id18 . 0 8 ”0” ( 1 )
KEEP TO LOW; // id18 . 0 7 ”0” ( 2 )
KEEP TO LOW; // id18 . 0 6 ”0” ( 3 )
KEEP TO LOW; // id18 . 0 5 ”0” ( 4 )
KEEP TO LOW; // id18 . 0 4 ”0” ( 5 )
CHANGE TO HIGH(CANBITOUT) ; //BS ”1” ( 1 )
Dodatek F. Kod programu dla mikroporcesora 154
CHANGE TO LOW(CANBITOUT) ; // id18 . 0 3 ”0” ( 1 )
KEEP TO LOW; // id18 . 0 2 ”0” ( 2 )
KEEP TO LOW; // id18 . 0 1 ”0” ( 3 )
KEEP TO LOW; // r t r ”0” ( 4 )
KEEP TO LOW; // rb1 ”0” ( 5 )
CHANGE TO HIGH(CANBITOUT) ; //BS ”1” ( 1 )
CHANGE TO LOW(CANBITOUT) ; // rb0 ”0” ( 1 )
KEEP TO LOW; // d l c 4 ”0” ( 2 )
KEEP TO LOW; // d l c 3 ”0” ( 3 )
KEEP TO LOW; // d l c 2 ”0” ( 4 )
CHANGE TO HIGH(CANBITOUT) ; // d l c 1 ”1” ( 1 )
CHANGE TO LOW(CANBITOUT) ; // data1 . 8 ”0” ( 1 )
KEEP TO LOW; // data1 . 7 ”0” ( 2 )
KEEP TO LOW; // data1 . 6 ”0” ( 3 )
KEEP TO LOW; // data1 . 5 ”0” ( 4 )
CHANGE TO HIGH(CANBITOUT) ; // data1 . 4 ”1” ( 1 )
KEEP TO HIGH; // data1 . 3 ”1” ( 2 )
KEEP TO HIGH; // data1 . 2 ”1” ( 3 )
KEEP TO HIGH; // data1 . 1 ”1” ( 4 )
KEEP TO HIGH; // crc15 ”1” ( 5 )
CHANGE TO LOW(CANBITOUT) ; //BS ”0” ( 1 )
CHANGE TO HIGH(CANBITOUT) ; // crc14 ”1” ( 1 )
KEEP TO HIGH; // crc13 ”1” ( 2 )
CHANGE TO LOW(CANBITOUT) ; // crc12 ”0” ( 1 )
KEEP TO LOW; // crc11 ”0” ( 2 )
CHANGE TO HIGH(CANBITOUT) ; // crc10 ”1” ( 1 )
CHANGE TO LOW(CANBITOUT) ; // crc09 ”0” ( 1 )
KEEP TO LOW; // crc08 ”0” ( 2 )
CHANGE TO HIGH(CANBITOUT) ; // crc07 ”1” ( 1 )
KEEP TO HIGH; // crc06 ”1” ( 2 )
KEEP TO HIGH; // crc05 ”1” ( 3 )
KEEP TO HIGH; // crc04 ”1” ( 4 )
CHANGE TO LOW(CANBITOUT) ; // crc03 ”0” ( 1 )
CHANGE TO HIGH(CANBITOUT) ; // crc02 ”1” ( 1 )
KEEP TO HIGH; // crc01 ”1” ( 2 )
delay ms (1000) ;
}
void send RB0ExtendedFrameWithOutCRC () {SET TRIS E(0 x02 ) ;
CHANGE TO LOW(CANBITOUT) ; // s o f ”0” ( 1 )
KEEP TO LOW; // id11 . 1 1 ”0” ( 2 )
KEEP TO LOW; // id11 . 1 0 ”0” ( 3 )
KEEP TO LOW; // id11 . 0 9 ”0” ( 4 )
KEEP TO LOW; // id11 . 0 8 ”0” ( 5 )
CHANGE TO HIGH(CANBITOUT) ; //BS ”1” ( 1 )
CHANGE TO LOW(CANBITOUT) ; // id11 . 0 7 ”0” ( 1 )
KEEP TO LOW; // id11 . 0 6 ”0” ( 2 )
KEEP TO LOW; // id11 . 0 5 ”0” ( 3 )
KEEP TO LOW; // id11 . 0 4 ”0” ( 4 )
KEEP TO LOW; // id11 . 0 3 ”0” ( 5 )
CHANGE TO HIGH(CANBITOUT) ; //BS ”1” ( 1 )
CHANGE TO LOW(CANBITOUT) ; // id11 . 0 2 ”0” ( 1 )
KEEP TO LOW; // id11 . 0 1 ”0” ( 2 )
CHANGE TO HIGH(CANBITOUT) ; // i s s ”1” ( 1 )
KEEP TO HIGH; // i d e ”1” ( 2 )
CHANGE TO LOW(CANBITOUT) ; // id18 . 1 8 ”0” ( 1 )
KEEP TO LOW; // id18 . 1 7 ”0” ( 2 )
KEEP TO LOW; // id18 . 1 6 ”0” ( 3 )
KEEP TO LOW; // id18 . 1 5 ”0” ( 4 )
KEEP TO LOW; // id18 . 1 4 ”0” ( 5 )
CHANGE TO HIGH(CANBITOUT) ; //BS ”1” ( 1 )
CHANGE TO LOW(CANBITOUT) ; // id18 . 1 3 ”0” ( 1 )
KEEP TO LOW; // id18 . 1 2 ”0” ( 2 )
KEEP TO LOW; // id18 . 1 1 ”0” ( 3 )
KEEP TO LOW; // id18 . 1 0 ”0” ( 4 )
CHANGE TO HIGH(CANBITOUT) ; // id18 . 0 9 ”1” ( 1 )
CHANGE TO LOW(CANBITOUT) ; // id18 . 0 8 ”0” ( 1 )
KEEP TO LOW; // id18 . 0 7 ”0” ( 2 )
KEEP TO LOW; // id18 . 0 6 ”0” ( 3 )
KEEP TO LOW; // id18 . 0 5 ”0” ( 4 )
KEEP TO LOW; // id18 . 0 4 ”0” ( 5 )
CHANGE TO HIGH(CANBITOUT) ; //BS ”1” ( 1 )
CHANGE TO LOW(CANBITOUT) ; // id18 . 0 3 ”0” ( 1 )
KEEP TO LOW; // id18 . 0 2 ”0” ( 2 )
Dodatek F. Kod programu dla mikroporcesora 155
KEEP TO LOW; // id18 . 0 1 ”0” ( 3 )
KEEP TO LOW; // r t r ”0” ( 4 )
CHANGE TO HIGH(CANBITOUT) ; // rb1 ”0” ( 5 )
CHANGE TO HIGH(CANBITOUT) ; //BS ”1” ( 1 )
KEEP TO HIGH; // rb0 ”1” ( 1 )
CHANGE TO LOW(CANBITOUT) ; // d l c 4 ”0” ( 2 )
KEEP TO LOW; // d l c 3 ”0” ( 3 )
KEEP TO LOW; // d l c 2 ”0” ( 4 )
CHANGE TO HIGH(CANBITOUT) ; // d l c 1 ”1” ( 1 )
CHANGE TO LOW(CANBITOUT) ; // data1 . 8 ”0” ( 1 )
KEEP TO LOW; // data1 . 7 ”0” ( 2 )
KEEP TO LOW; // data1 . 6 ”0” ( 3 )
KEEP TO LOW; // data1 . 5 ”0” ( 4 )
CHANGE TO HIGH(CANBITOUT) ; // data1 . 4 ”1” ( 1 )
KEEP TO HIGH; // data1 . 3 ”1” ( 2 )
KEEP TO HIGH; // data1 . 2 ”1” ( 3 )
KEEP TO HIGH; // data1 . 1 ”1” ( 4 )
KEEP TO HIGH; // crc15 ”1” ( 5 )
CHANGE TO LOW(CANBITOUT) ; //BS ”0” ( 1 )
CHANGE TO HIGH(CANBITOUT) ; // crc14 ”1” ( 1 )
KEEP TO HIGH; // crc13 ”1” ( 2 )
CHANGE TO LOW(CANBITOUT) ; // crc12 ”0” ( 1 )
KEEP TO LOW; // crc11 ”0” ( 2 )
CHANGE TO HIGH(CANBITOUT) ; // crc10 ”1” ( 1 )
CHANGE TO LOW(CANBITOUT) ; // crc09 ”0” ( 1 )
KEEP TO LOW; // crc08 ”0” ( 2 )
CHANGE TO HIGH(CANBITOUT) ; // crc07 ”1” ( 1 )
KEEP TO HIGH; // crc06 ”1” ( 2 )
KEEP TO HIGH; // crc05 ”1” ( 3 )
KEEP TO HIGH; // crc04 ”1” ( 4 )
CHANGE TO LOW(CANBITOUT) ; // crc03 ”0” ( 1 )
CHANGE TO HIGH(CANBITOUT) ; // crc02 ”1” ( 1 )
KEEP TO HIGH; // crc01 ”1” ( 2 )
delay ms (1000) ;
}void send RB0ExtendedFrameWithCRC () {
SET TRIS E(0 x02 ) ;
CHANGE TO LOW(CANBITOUT) ; // s o f ”0” ( 1 )
KEEP TO LOW; // id11 . 1 1 ”0” ( 2 )
KEEP TO LOW; // id11 . 1 0 ”0” ( 3 )
KEEP TO LOW; // id11 . 0 9 ”0” ( 4 )
KEEP TO LOW; // id11 . 0 8 ”0” ( 5 )
CHANGE TO HIGH(CANBITOUT) ; //BS ”1” ( 1 )
CHANGE TO LOW(CANBITOUT) ; // id11 . 0 7 ”0” ( 1 )
KEEP TO LOW; // id11 . 0 6 ”0” ( 2 )
KEEP TO LOW; // id11 . 0 5 ”0” ( 3 )
KEEP TO LOW; // id11 . 0 4 ”0” ( 4 )
KEEP TO LOW; // id11 . 0 3 ”0” ( 5 )
CHANGE TO HIGH(CANBITOUT) ; //BS ”1” ( 1 )
CHANGE TO LOW(CANBITOUT) ; // id11 . 0 2 ”0” ( 1 )
KEEP TO LOW; // id11 . 0 1 ”0” ( 2 )
CHANGE TO HIGH(CANBITOUT) ; // i s s ”1” ( 1 )
KEEP TO HIGH; // i d e ”1” ( 2 )
CHANGE TO LOW(CANBITOUT) ; // id18 . 1 8 ”0” ( 1 )
KEEP TO LOW; // id18 . 1 7 ”0” ( 2 )
KEEP TO LOW; // id18 . 1 6 ”0” ( 3 )
KEEP TO LOW; // id18 . 1 5 ”0” ( 4 )
KEEP TO LOW; // id18 . 1 4 ”0” ( 5 )
CHANGE TO HIGH(CANBITOUT) ; //BS ”1” ( 1 )
CHANGE TO LOW(CANBITOUT) ; // id18 . 1 3 ”0” ( 1 )
KEEP TO LOW; // id18 . 1 2 ”0” ( 2 )
KEEP TO LOW; // id18 . 1 1 ”0” ( 3 )
KEEP TO LOW; // id18 . 1 0 ”0” ( 4 )
CHANGE TO HIGH(CANBITOUT) ; // id18 . 0 9 ”1” ( 1 )
CHANGE TO LOW(CANBITOUT) ; // id18 . 0 8 ”0” ( 1 )
KEEP TO LOW; // id18 . 0 7 ”0” ( 2 )
KEEP TO LOW; // id18 . 0 6 ”0” ( 3 )
KEEP TO LOW; // id18 . 0 5 ”0” ( 4 )
KEEP TO LOW; // id18 . 0 4 ”0” ( 5 )
CHANGE TO HIGH(CANBITOUT) ; //BS ”1” ( 1 )
CHANGE TO LOW(CANBITOUT) ; // id18 . 0 3 ”0” ( 1 )
KEEP TO LOW; // id18 . 0 2 ”0” ( 2 )
KEEP TO LOW; // id18 . 0 1 ”0” ( 3 )
KEEP TO LOW; // r t r ”0” ( 4 )
CHANGE TO LOW(CANBITOUT) ; // rb1 ”0” ( 5 )
Dodatek F. Kod programu dla mikroporcesora 156
CHANGE TO HIGH(CANBITOUT) ; //BS ”1” ( 1 )
KEEP TO HIGH; // rb0 ”1” ( 2 )
CHANGE TO LOW(CANBITOUT) ; // d l c 4 ”0” ( 2 )
KEEP TO LOW; // d l c 3 ”0” ( 3 )
KEEP TO LOW; // d l c 2 ”0” ( 4 )
CHANGE TO HIGH(CANBITOUT) ; // d l c 1 ”1” ( 1 )
CHANGE TO LOW(CANBITOUT) ; // data1 . 8 ”0” ( 1 )
KEEP TO LOW; // data1 . 7 ”0” ( 2 )
KEEP TO LOW; // data1 . 6 ”0” ( 3 )
KEEP TO LOW; // data1 . 5 ”0” ( 4 )
CHANGE TO HIGH(CANBITOUT) ; // data1 . 4 ”1” ( 1 )
KEEP TO HIGH; // data1 . 3 ”1” ( 2 )
KEEP TO HIGH; // data1 . 2 ”1” ( 3 )
KEEP TO HIGH; // data1 . 1 ”1” ( 4 )
KEEP TO HIGH; // crc15 ”1” ( 5 )
CHANGE TO LOW(CANBITOUT) ; //BS ”0” ( 1 )
KEEP TO LOW; // crc14 ”0” ( 2 )
KEEP TO LOW; // crc13 ”0” ( 3 )
KEEP TO LOW; // crc12 ”0” ( 4 )
CHANGE TO HIGH(CANBITOUT) ; // crc11 ”1” ( 1 )
CHANGE TO LOW(CANBITOUT) ; // crc10 ”0” ( 1 )
KEEP TO LOW; // crc09 ”0” ( 2 )
KEEP TO LOW; // crc08 ”0” ( 3 )
KEEP TO LOW; // crc07 ”0” ( 4 )
KEEP TO LOW; // crc06 ”0” ( 5 )
CHANGE TO HIGH(CANBITOUT) ; //BS ”1” ( 1 )
KEEP TO HIGH; // crc05 ”1” ( 2 )
KEEP TO HIGH; // crc04 ”1” ( 3 )
KEEP TO HIGH; // crc03 ”1” ( 4 )
CHANGE TO LOW(CANBITOUT) ; // crc02 ”0” ( 1 )
KEEP TO LOW; // crc01 ”0” ( 2 )
CHANGE TO HIGH(CANBITOUT) ; //
delay ms (1000) ;
}
void main ( ) {
i n t32 r x i d ;
int i , rx l en , b u f f e r [ 8 ] ;
struct r x s t a t r x s t a t ;
int data [ 8 ] = {0xAA,0xAA,0xAA,0xAA,0xAA,0xAA,0xAA,0xAA} ;
char d lc = 1 ;
c a n i n i t ( ) ;
delay ms (1000) ;
while (TRUE){output low (PIN A5) ;
send RB0ExtendedFrameWithCRC () ;
delay ms (1000) ;
}}