CAN and Higher Level Protocols

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.


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

www.kvaser.com

    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

www.sae.org

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

http://www.osek-vdx.org

  • 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

www.odva.org

 

    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 - přehled struktury identifikátorů

    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:

 

 
Identifier bits 10 9 8 7 6 5 4 3 2 1 0
Význam Dir Device Address PDU type
DB0
7 6 5 4 3 2 1 0
RRE 0 R OGID
DB1
7 6 5 4 3 2 1 0
Variable ID

   

    RRE:

            Request

            Response

            Error

    0:

            Fragment

    OGID:

            Object ID

            Group ID

 


CAL/CAN Open

www.can-cia.com

Stranky canlab s.r.o.

 

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

http://www.ib-martin.com/

    Letecká technika.

 

    Identifikátory jsou děleny do 6 skupin dle priority:

 

 

    Datová část pak má tuto strukturu:

 


ISO BUS (ISO11783)

http://www.isobus.net/

 

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


CAN Calibration Protocol

http://www.asam.net

 


NMEA 2000

NMEA: National Marine Electronics Association

 

Protokol založený na CAN sběrnici pro lodní elektronická zařízení.

 


VSCP (Very Simple Control Protocol)

http://www.vscp.org

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: