metody ograniczania liczby bitów nadmiarowych w...

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-


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


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


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).


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.


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),


— 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-


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


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


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.


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.


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ć


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)


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.


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-


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,


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.


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:


— 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,


— 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,


Rysunek 2.12. Cykliczny model węzła sieci [62]


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-


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


(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)


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.


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


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ą).


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


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


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)


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ż


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


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.


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-


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


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]


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.


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:


— 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


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),


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.


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).


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ą.


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-


(a) Ramka CAN2.0A

(b) Ramka CAN2.0B

Rysunek 6.3. Histogram liczby wstawek bitowych na każdy bit danych.


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)


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.


(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


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)


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)


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)


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


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


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]


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.


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


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


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-


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 . . .


S I I R R R


F D S E D R 1 0

0 . . . 0 1 . . . 0 0 0 0000 . . .

↓0 . . . 0 1 . . . 0 0 0 1000 . . .


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.


Ostatnia próba modyfikacji polega na zmianie obecnego zachowania się

ramki CAN, w momencie przesyłania żądania informacji - za pomocą tzw.


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 . . .


S I I R R R


F D S E D R 1 0

0 . . . 0 1 . . . 0 0 0 0000 . . .

↓0 . . . 0 1 . . . 0 0 0 000 . . .


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.


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 . . .


S I I R R R


F D S E D R 1 0

0 . . . 0 1 . . . 0 0 0 0000 . . .

↓0 . . . 0 1 . . . 1 0 0 0000 . . .


Rysunek 6.9. Oczekiwany efekt związany z wysyłaniem danych w ramkach zdal-

nego żądania, dla jednego z przypadków.


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-





od wartości identyfikatora [33]


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


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





od wartości identyfikatora [32]


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


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.


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


skrócenia pola DLC


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).


(c) dla ramki standardowej

(d) dla ramki rozszerzonej




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


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.


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


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


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


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,


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


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-


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


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


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.


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ę.


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


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:


— 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.


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ó-


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


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


(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


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;


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


wartości identyfikatora [33] . . . . . . . . . . . . . . . . . . . . . . . . 77


wartości identyfikatora [32] . . . . . . . . . . . . . . . . . . . . . . . . 79


wartości identyfikatora . . . . . . . . . . . . . . . . . . . . . . . . . . 81


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


zmiany kodowania obszaru DLC . . . . . . . . . . . . . . . . . . . . . 80

6.19. Średnia liczba wstawek bitowych w nagłówku ramki CAN ze

skróconym polem DLC(BSavg) . . . . . . . . . . . . . . . . . . . . . . 82


skrócenia pola DLC . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82

6.21. Średnia liczba wstawek bitowych w nagłówku ramki CAN ze

skróconym polem DLC . . . . . . . . . . . . . . . . . . . . . . . . . . 84


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


Spis tabel 107

6.37. Wartości średnie opóźnień w sieci CAN poprzez zastosowanie


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:



[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



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



[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:



[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 ).


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-


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ł


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]


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ę-


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.


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].


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,


— 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


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


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


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 ++){


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 ; ) {}


}}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 ) ;



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 ) ;



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 ) ;



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} ;


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 ( 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 ( u i n t 8 i = 1 0 ; i > 0 ; i−−){// DataSecureCRC15 (1000000 , 13000000 , errRate [ j ] ) ;

DataSecureCRC15 CAN ForSetLen (1000000 , 13000000 , errRate [ j ] , 0) ;









}∗/

}


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 ) ;


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 ;


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++;


}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 ;



eTab++;

xTab++;

dTab++;

}}

void DataLinkLayer : : NoErrors (void ){uint8 ∗ xTab , ∗ eTab , ∗ dTab ;

dTab = this−>afstufBT ;


eTab = this−>e r r tab ;

this−>errWpos = this−>xorWpos = this−>afWpos ;


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 ;


}} 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){


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 . 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 . 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 . 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 ’ ] )




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


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


s e l f .RTR[ ’ va l ’ ] = −1

s e l f .SRR[ ’ va l ’ ] = 0

s e l f . IDE [ ’ va l ’ ] = 1


s e l f .RTR[ ’ va l ’ ] = 1

s e l f .SRR[ ’ va l ’ ] = −1

s e l f . IDE [ ’ va l ’ ] = 0


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 ’ ]


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 ’ ]


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 ’ ]


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 ’ ]


s e l f .RTR[ ’ va l ’ ] = Lab Supp . B i t s2 In t ( InStream [ SPos : EPos ] )

#RB1


SPos = EPos

EPos += s e l f .RB1[ ’ l en ’ ]


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 ’ ]


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 ’ ]


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


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 ’ ]


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 ’ ]


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 ’ ]


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 ’ ]


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 ’ ]


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 ’ ]


s e l f . INTSPACE[ ’ va l ’ ] = Lab Supp . B i t s2 In t ( InStream [ SPos : EPos ] )


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) ) :


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) :


s e l f .RB0 = { ’ l en ’ : 1 , ’ va l ’ : 1}

#c l a s s CANDTL3b

class CANDTL3b(CAN) :


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) :


#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) :


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


#−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−#−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−#∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗# ∗# Klasa r e p r e z e n t u j a c a warstwe l a c z a danych ∗# ∗#∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗class DLL:


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


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


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


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 ∗


#∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗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 ∗#∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗


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 , ’ | ’ ) )


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 :


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



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


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


#∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗# 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 ( )


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 ’ :


# 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 ’ :


# 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


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 )



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 )


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 )



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 )


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 )


Dodatek F. Kod programu dla mikroporcesora 154


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 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 )


CHANGE TO LOW(CANBITOUT) ; // crc12 ”0” ( 1 )

KEEP TO LOW; // crc11 ”0” ( 2 )



KEEP TO LOW; // crc08 ”0” ( 2 )








delay ms (1000) ;

}

void send RB0ExtendedFrameWithOutCRC () {SET TRIS E(0 x02 ) ;


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 )



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 )



KEEP TO LOW; // id11 . 0 1 ”0” ( 2 )




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 )



KEEP TO LOW; // id18 . 1 2 ”0” ( 2 )

KEEP TO LOW; // id18 . 1 1 ”0” ( 3 )

KEEP TO LOW; // id18 . 1 0 ”0” ( 4 )



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 )



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 HIGH(CANBITOUT) ; // rb1 ”0” ( 5 )


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 )



KEEP TO LOW; // data1 . 7 ”0” ( 2 )

KEEP TO LOW; // data1 . 6 ”0” ( 3 )

KEEP TO LOW; // data1 . 5 ”0” ( 4 )


KEEP TO HIGH; // data1 . 3 ”1” ( 2 )

KEEP TO HIGH; // data1 . 2 ”1” ( 3 )

KEEP TO HIGH; // data1 . 1 ”1” ( 4 )






KEEP TO LOW; // crc11 ”0” ( 2 )



KEEP TO LOW; // crc08 ”0” ( 2 )








delay ms (1000) ;

}void send RB0ExtendedFrameWithCRC () {

SET TRIS E(0 x02 ) ;


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 )



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 )



KEEP TO LOW; // id11 . 0 1 ”0” ( 2 )




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 )



KEEP TO LOW; // id18 . 1 2 ”0” ( 2 )

KEEP TO LOW; // id18 . 1 1 ”0” ( 3 )

KEEP TO LOW; // id18 . 1 0 ”0” ( 4 )



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 )



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 )



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 )



KEEP TO LOW; // data1 . 7 ”0” ( 2 )

KEEP TO LOW; // data1 . 6 ”0” ( 3 )

KEEP TO LOW; // data1 . 5 ”0” ( 4 )


KEEP TO HIGH; // data1 . 3 ”1” ( 2 )

KEEP TO HIGH; // data1 . 2 ”1” ( 3 )

KEEP TO HIGH; // data1 . 1 ”1” ( 4 )



KEEP TO LOW; // crc14 ”0” ( 2 )

KEEP TO LOW; // crc13 ”0” ( 3 )

KEEP TO LOW; // crc12 ”0” ( 4 )



KEEP TO LOW; // crc09 ”0” ( 2 )

KEEP TO LOW; // crc08 ”0” ( 3 )

KEEP TO LOW; // crc07 ”0” ( 4 )

KEEP TO LOW; // crc06 ”0” ( 5 )






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) ;

}}

metody ograniczania liczby bitów nadmiarowych w...

Documents