Tento dokument obsahuje soubor poznámek a částí různých materiálů nalezených na internetu k jednotlivým protokolům. Nejedná se tedy o ucelený text, spíše jde o takový poznámkový blok, ve kterém jsem si chtěl uložit pohromadě základní informace k dané problematice. Proto se také nejedná o konečnou verzi textu, vždy když narazím na něco, co sem patří, budu se snažit tento text doplnit.
- J1939
- CAN Kingdom
- OSEK
- DeviceNet
- Smart Distributed Systems
- CAL/CAN Open
- MilCAN
- CANaerospace
- ISO BUS (ISO11783)
- CAN Calibration Protocol
- NMEA 2000
- VSCP (Very Simple Control Protocol)
Struktura identifikátorů u high-level protokolů CAL/CANopen, DeviceNet a SDS. Zdroj: CAN-based Higher Layer Protocols and Profiles, Prof. Dr.-Ing. K. Etschberger, IXXAT Automation GmbH. |
CAN Kingdom
Celý systém je přirovnán k království - říši - kingdom. Tato říše má hlavní město - capital s vládcem - king , který je zodpovědný za pravidla a řízení říše. V království pak jsou jednotlivá města, každé z nich má své správce - mayor. Všechny informace mezi obyvateli království jsou předávány poštovním systémem. Každé město má poštovní stanici s pošťákem.
Termíny používané ve specifikaci mají tyto významy:
Capital - King | Network Manager |
Postal system | CAN bus, CAN protocol |
City - Mayor | CAN node |
Post Office - Postmaster | CAN controller |
Envelope - Obálka | CAN ID |
Letter - Dopis | CAN Message |
Page - Stránka | CAN data block |
Line - Řádek | CAN data byte |
Dopis má vždy 1 obálku. Jedna stránka může mít 0 až 8 řádek.
Specifikace není kompletní, systémový designer dotvoří specifikaci dle požadavků konkrétního systému.
J1939
Protokol je určen zejména pro nákladní automobily a autobusy.
Specifikace protokolu je tvořena těmito částmi:
- J1939/11 Physical Layer
- J1939/21 Data Link Layer
Obecné vlastnosti sběrnice CAN pro komunikaci jednotek v rámci hnacího řetězce vozidla.
- J1939/71 Application Layer
Definice jednotlivých zpráv a jejich vlastnosti.
- identifikátor zprávy
- frekvenci nebo podmínky pro vysílání zprávy.
- uspořádání a kódování datové části.
- J1939/01 Truck & Bus overall doc.
- J1939/02 Agricult. overall doc.
- J1939/31 Network Layer
- J1939/81 Network Management
Přenosová rychlost je pevně stanovena na 250 000 bitů/s.
Datová část má vždy délku 8 bajtů.
Protokol využívá rozšířených identifikátorů, identifikátor má následující strukturu:
Bity ID | b28-b26 | b25 | b24 | b23-b16 | b15-b8 | b7-b0 |
Význam |
Priority | Reserved | Data page | Data Content | PDU specific | Source Address |
Data Content:
Value | PDU specific |
0 - 239 | Destination Address |
240 - 255 | Extended Data Content |
Časový interval vysílání zprávy na CAN bus je určován s ohledem na důležitost obsažených informací a pohybuje se od 10 ms (tj. vysílání 100-krát za sekundu) do 1 sekundy. Pro některé zprávy není perioda opakování určena, takové zprávy se vysílají jen na vyžádání (obvykle obsahují diagnostiku daného zařízení) nebo ve specifických případech (např. po zastavení motoru).
Datová část zprávy obsahuje aktuální hodnoty určených veličin. Zařízení, která zprávu vysílají, nemusí "vyplnit" všechny předpisem definované hodnoty, ale musí na jejich místě vysílat byte, jehož všechny bity mají hodnotu rovnou 1. To zajišťuje kompatibilitu stávajících i budoucích verzí jednotek připojených na CAN. Data o rozsahu větším než 8 bytů (např. informace o konfiguraci motoru) se vysílají v blocích po 8 bytech s tím, že před zahájením takového přenosu je vysílána speciální informační zpráva.
Celkem definuje předpis SAE J 1939 (verze z roku 1999) 145 zpráv, které specifikují přenos i ta-kových informací jako blokování immobilizéru, teplotu povrchu pneumatik a vozovky nebo lase-rové navádění tahače na přívěs.
Některé adresy jednotek v rámci hnacího řetězce vozidla:
00h .... motor
03h .... převodovka
0Bh .... ABS / ASR.
Většina jednotek vysílá několik různých zpráv (tj. zpráv s odlišnými identifikátory).
Současný motor obvykle vysílá následující periodické zprávy:
- Electronic Engine Controller #1, interval: 10 ms
- Electronic Engine Controller #2, interval: 50 ms
- Electronic Engine Controller #3, interval: 250 ms
- Cruise Control/ Vehicle Speed, interval: 250 ms
- Engine Temperature, interval: 1000 ms
- Ambient conditions, interval: 1000 ms
- Inlet/Exhaust conditions, interval: 1000 ms
- Engine configuration, interval: 1000 ms (rozsáhlá zpráva rozdělená do 4 bloků)
Příklad:
Zpráva EEC1
vysílá: motor
identifikátor: 0CF00400h
perioda: 10 ms
obsahuje hodnoty:
- kód zařízení, které aktuálně řídí kroutící moment motoru: volnoběh, pedál akcelerátoru, cruise-control, ABS, ASR, převodovka, omezovač rychlosti, omezovač otáček, omezovač kroutícího momentu...
- otáčky motoru: 0 - 8000 ot/min
- řidičem požadovaný kroutící moment (vyjádřený v procentech referenčního kroutícího momentu)
- aktuální kroutící moment (vyjádřený v procentech referenčního kroutícího momentu)
OSEK
https://de.wikipedia.org/wiki/OSEK
-
OSEK (z němčiny Offene Systeme und deren Schnittstellen fur die Elektronik im Kraftfahrzeuge) je operační systém - vyšší vrstva komunikačního protokolu sběrnice CAN pro automobilové aplikace.
-
OSEK není vázán jen na sběrnici CAN, ale může být implementován na další např. VAN, J1850.
-
Jeho počátek je v roce 1993, kdy se na jeho vzniku podílelo několik členů - Adam Opel, BMW, Daimler-Benz, IIT Uni.of Karlsruhe, PSA-Renault, Robert Bosch, Siemens, Volkswagen.
-
Ve stejné době byla vyvíjena druhá iniciativa ve Francii - VDX (Vehicle Distributed eXecutive), nakonec byl OSEK a VDX sjednocen do společného sdružení OSEK/VDX.
-
Smyslem operačního systému OSEK je sjednotit komunikaci různých řídících jednotek s různými mikroprocesory a od různých výrobců na jednom standardu, který výsledně povede ke snížení vývojových nákladů a zkrácení vývoje stále složitějších automobilových sítí.
-
V čele sdružení OSEK je řídící skupina složená z uvedených zakládajících členů, pod ní jsou 3 oficiální pracovní skupiny - Operating System (OS), Communication (COM), Network Management (NM).
-
Praktickými aplikacemi OSEK v praxi je pak vznik vývojových softwarových nástrojů pro různé typy mikroprocesorů, ve kterých vývojáři píší programy jednodušeji už přímo v operačním systému OSEK. Přechod z jednoho typu mikroprocesoru na druhý je pak také snadnější, protože program je vzdálen od vlastního hardware mikroprocesoru.
DeviceNet
Protokol využívá standardních 11 bitových identifikátorů. Identifikátory mají tuto strukturu:
Identifier bits | Idenity Usage | ||||||||||
10 | 9 | 8 | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | |
0 | Group 1 Msg ID | Source MAC ID | Message Group 1 | ||||||||
1 | 0 | MAC ID | Group 2 Msg ID | Message Group 2 | |||||||
1 | 1 | Group 3 Msg ID | Source MAC ID | Message Group 3 | |||||||
1 | 1 | 1 | 1 | 1 | Group 4 Msg ID |
Message Group 4 (reserved for future use) |
|||||
1 | 1 | 1 | 1 | 1 | 1 | 1 | X | X | X | X | Invalid CAN IDs |
DeviceNet popisuje všechna data a funkce zařízení které jsou viditelné prostřednictvím sítě CAN sběrnice pomocí objektového modelu. Objekt je reprezentován abstraktním popisem komponent uvnitř zařízení. Objekt je reprezentován svými atributy, funkcemi službami a chováním.
Atributy reprezentují data které jsou přístupné pomocí DeviceNetu. Může to být status objektu, sériové číslo a samozřejmě procesní data jako poloha, tlak, teplota atd.
Služby slouží k volání funkcí a metod objektu. Například pro čtení/zápis jednotlivých atributů.
Chování objektu popisuje jak zařízení reaguje na vnitřní či vnější události. Interní událostí může být uplynutí nějakého času, externí pak například změna procesních dat.
Data a služby objektu jsou přístupné pomocí adresní hierarchie, která má tyto komponenty:
- Device Address (MAC ID: Media access control identifier)
- Class ID
- Instance ID
- Attribute ID
- Service Code
Smart Distributed Systems
www.honeywell.com/sensing/prodinfo/sds/
Tento protokol využívá standardního 11 bitového identifikátoru. Ten má následující tvar:
Pro DLC=0:
Identifier bits | 10 | 9 | 8 | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 |
Význam | Direction | Device Address | PDU type |
Direction:
0 - Host to Guest
1 - Guest to Host
Device Address:
0 - 125
PDU type:
0 - Change of state OFF
1 - Change of state ON
2 - OFF Ack
3 - ON Ack
4 - Write OFF
5 - Write ON
6 - Write OFF Ack
7 - Write ON Ack
Pro DLC>0:
|
||||||||||||||||||||||||
DB0 | ||||||||||||||||||||||||
|
||||||||||||||||||||||||
DB1 | ||||||||||||||||||||||||
|
RRE:
Request
Response
Error
0:
Fragment
OGID:
Object ID
Group ID
CAL/CAN Open
CAL:
Protokol CAL (CAN aplication leyer) byl původně vyvinut firmou Philips Medical Systems, v současné době je rozvíjen a podporován organizací CiA (CAN in Automation).
Flexibilní a vhodný pro uzavřené systémy.
Obsahuje 272 předdefinovaných standardních identifikátorů.
8 tříd priority.
CAL je založen na 4 skupinách servisních služeb CMS, NMT,LMT a DBT.
Servisní služby CMS
- protokol typu servis-klient, možno i více klientů a serverů v síti
- 8 prioritních skupin
- výměna aplikačních dat prostřednictvím komunikačních objektů, možnost segmentace dat
- každá komunikační objekt identifikován CAN identifikáorem
Typy komunikačních objektů:
- proměnné (data do 8 bytů)
- domény (datové pakety delší než 8 bytů)
- události
Servisní služby NMT
- řízení činnosti uzlu z hlediska jeho začlenění do sítě, konfigurace parametrů a přípravy výměny aplikačních dat prostřednictvím CMS protokolu
- v síti může být pouze 1 NMT master
- současně může být konfigurován pouze 1 slave uzel
- každý slave uzel je identifikován jedinečnou adresou NMTNoteAddres kterou je v síti identifikován (možno změnit LMT službou)
NMT služby zajišťují:
- test přítomnosti uzlu
- přidělení CAN identifikátoru pro službu NodeGuarding
- konfigurace parametrů zařízení
- přidělení CAN identifikátorů CMS objektů
- zapojení uzlu do systému
- testování životnosti uzlu Node Guard protokolem
Servisní služby DBT
- umožňuje během procesu konfigurace uzlu NMT službou dynamicky přidělovat identifikátory CAN protokolu CMS komunikačním objektům
- v síti může být pouze 1 DBT master
- přidělení CAN identifikátorů CMS komunikačním objektům
- přidělování priorit CMS komunikačním objektům
- test konfliktů přidělených identifikátorů mezi jednotlivými uzly
Servisní služby LMT
- služba dovoluje změnit základní parametry uzlu, pomocí nichž je uzel identifikován pro další služby
- nastavení základních identifikačních parametrů, podle kterých je uzel v síti identifikován
- možnost změny komunikační rychlosti pro všechny uzly najednou
Tabulka přidělení CAN identifikátorů CAL protokolu:
CAL protokol | CAN identifikátor |
NMT start/stop services | 0 |
CMS object priority 0 | 1 - 220 |
... | |
CMS object priority 7 | 1541 - 1760 |
NMT Node Guard Protocol | 1761 - 2015 |
reserved | 2016 - 2019 |
LMT Services - answers | 2020 |
LMT Services - requests | 2021 |
NMT Identify Node Protocol | 2022 |
DBT Services - answers | 2023 |
DBT Services - requests | 2024 |
NMT Services - answers | 2025 |
NMT Services - requests | 2026 |
reserved | 2027-2031 |
CANopen:
CANopen je podmnožinou CAL, je rozšířen o standartizační prvky, kterými jsou definice jednotlivých šablon komunikačních a aplikačních vlastností zařízení.
Navrženy komunikační profily pro IO a pohony.
MilCAN
Struktura identifikátoru je navržena tak, aby nekolidovala se zprávami ve formátu J1939. Následující tabulky porovnávají strukturu ID těchto protokolů.
MilCAN
Bity ID | b28-b26 | b25 | b24 | b23-b16 | b15-b8 | b7-b0 |
Význam |
Priority | Reserved=1 | Request |
Message Primary Type |
Message Sub-Type |
Source Address |
SAE J1939
Bity ID | b28-b26 | b25 | b24 | b23-b16 | b15-b8 | b7-b0 |
Význam |
Priority | Reserved=0 | Data page |
PDU Format (Data Content) |
PDU specific | Source Address |
CANaerospace
Letecká technika.
Identifikátory jsou děleny do 6 skupin dle priority:
Datová část pak má tuto strukturu:
ISO BUS (ISO11783)
Komunikační standard založený na sběrnici CAN dle definice CAN 2.0 B určený pro zemědělské a lesnické stroje. Standard má tyto části:
-
Part 1: General standard for mobile data communication
-
Part 2: Physical layer
-
Part 3: Data link layer
-
Part 4: Network layer
-
Part 5: Network management
-
Part 6: Virtual terminal
-
Part 7: Implement messages applications layer
-
Part 8: Power train messages
-
Part 9: Tractor ECU
-
Part 10: Task controller and management information system data interchange
-
Part 11: Mobile data element dictionary
-
Part 12: Diagnostic
-
Part 13: File Server
NMEA 2000
NMEA: National Marine Electronics Association
Protokol založený na CAN sběrnici pro lodní elektronická zařízení.
VSCP (Very Simple Control Protocol)
Tento protokol je navržen pro použití v domácí automatizaci. Je navržen ve dvou stupních. Level 1 využívá jako přenosové médium sběrnice CAN. Level 2 je pak navržen pro přenos pomocí TCP/IP (nebo jiných) přenosových mechanizmů. Specifikaci verze 1.30 lze stáhnout zde.
-
využívá 29 bitové identifikátory
-
je podporováno až 254 nodů.
-
přenosová rychlost 500kbitů/s, jsou povoleny i jiné rychlosti, ale tato musí být vždy podporována
Struktura 29-bitového identifikátoru má tento tvar: