Introductie

CANopen® is een hoger protocol voor gedistribueerde industriële automatiseringssystemen gebaseerd op CAN. CANopen werd ontwikkeld binnen de CAN-in-Automation (CiA®) groep van gebruikers en producenten. Het is gestandaardiseerd als CENELEC EN 50325-4. Kort na het verschijnen hiervan vond CANopen een brede acceptatie, met name in Europa waar het systeem kan worden gezien als de toonaangevende standaard voor op CAN gebaseerde industriële en embedded systeemoplossingen.

CANopen structuur

Introductie

CANopen is een gestandaardiseerde communicatieoplossing voor gedistribueerde automatiseringssystemen op basis van CAN (Controller Area Network) dat de volgende mogelijkheden biedt: Verzenden van tijd kritische procesgegevens volgens het producent/consument-principe.

• Gestandaardiseerde beschrijving van aangesloten apparaten (gegevens, parameters, functies, programma’s) in de vorm van zogenaamde "object dictionary".
• Toegang tot alle “objects” van een apparaat via een gestandaardiseerd verzend protocol volgens het client/server-principe.
• Gestandaardiseerde hulpmiddelen voor apparaat monitoring (node monitoring/hartslag), foutsignalering (met noodoproep), en netwerk coördinatie (Netwerk management).
• Gestandaardiseerde systeem hulpmiddelen voor synchronisatie (synchronisatieberichten) en centraal tijdstempel.
• Gestandaardiseerde hulpfuncties voor configuratie, baudrate en apparaat identificatie via de bus.
• Gestandaardiseerd toewijzingsmechanisme voor berichten ID’s voor eenvoudige systeemconfiguratie in de vorm van zogenaamde “predefined connection set”.

Basis Communicatie

Object Dictionary (OD) en Electronic Data Sheet (EDS)

Een van de belangrijkste eigenschappen van CANopen is de gestandaardiseerd apparaat-beschrijving de zogenaamde Object Directory (OD). Het is een tabel die dezelfde structuur heeft voor alle soorten van apparaten. Zo is het mogelijk om toegang te krijgen van de "buiten", dat wil zeggen via de CAN-bus, tot alle belangrijke gegevens, parameters en functies van een apparaat middels een logisch adressysteem (index, sub-index).

CANopen Basis structuur

Apparaat Configuratie via SDO's

Service Data Objects (SDO's)

Specifieke communicatie-objecten, de zogenaamde "Service Data Objects" (SDO's) worden gebruikt voor directe toegang tot CANopen apparaten. Met deze "Service Data Objecten" kunnen Object Directory items worden gelezen en geschreven, waarbij de communicatie altijd plaatsvindt als een 1:1-verbinding (peer-to-peer) tussen twee nodes (bijvoorbeeld een configuratie node en een node die geconfigureerd wordt ). De overdracht van gegevens vindt plaats met ontvangst bevestiging, en dat betekent dat er twee CAN-berichten per aansluiting zijn vereist: een bericht voor het verzoek aan de netwerk node (SDO aanvraag of "Client SDO") en een tweede voor de reactie (SDO reactie of "Server SDO") van de node.

SDO Verzoek & Reactie

Proces informatie-uitwisseling met PDO

Broadcasting

De belangrijkste taak van een CANopen systeem is natuurlijk de uitwisseling van procesgegevens. Hiervoor worden niet alleen de meeste van de CAN-ID’s gereserveerd, maar ook het grootste deel van de Object Directory. Voor de transmissie van procesgegevens gebeurt dit zonder extra protocol overhead en verloopt volgens het zogenaamde "producent / consumenten principe". Dit betekent dat een bericht verzonden door een CAN node (de "producent") kan worden ontvangen door alle andere CAN nodes (de "consumenten"). Dit principe wordt aangeduid als "broadcasting" en is een zeer effectieve manier van datatransmissie, vooral als een bericht (bijvoorbeeld een synchronisatie-bericht) wordt verzonden aan alle procesdeelnemers tegelijkertijd.

Noodoproep

Foutmeldingen

Omdat CAN (en dus CANopen) geen hiërarchisch master/slave systeem is , en node- monitroing alleen iets zegt over de communicatie en niets over de actuele node status, beschikt ieder node over een hoge prioriteit CAN identifier om error situaties te melden. Dit mechanisme wordt aangeduid als "Emergency Messaging” (noodoproep) en het bijbehorende communicatie-object "Emergency Message” (noodbericht). Een dergelijk noodbericht bestaat uit acht data bytes in de volgende vorm:

Netwerkmanagement (NMT)

Naast het leveren van diensten en protocollen voor de overdracht van procesgegevens en de configuratie van apparaten, vereist de werking van een gedistribueerd systeem over een netwerk functies voor de besturing en de communicatie status van de individuele netwerk nodes. Omdat de gegevensoverdracht van CANopen apparaten in veel gevallen event-georiënteerd is, is de continue monitoring van de communicatie met de netwerk nodes ook vereist. CANopen biedt zogenaamde "Network Management” (netwerkbeheer) diensten en protocollen voor deze taken, namelijk:

• Besturing van de communicatie-status van de netwerk nodes en
• Node monitoring.

Node bewaking & hartstlag

CANopen Apparaat Monitoring

Om de continuïteit van het netwerk van nodes te waarborgen, biedt CANopen twee alternatieven:

• Cyclische opvragen van de node-status door een hogere orde bijvoorbeeld door de zogenaamde CANopen NMT-master, het "Node Guarding"-principe (Node Bewaking); of
• Automatische transmissie van een "Heartbeat Message" (hartslag bericht ) door de netwerk nodes, het "heartbeat"-principe.

Één CAN-ID per node is nodig om de communicatie status van het apparaat te volgen. Hiervoor zijn lage prioriteit bericht id's, met een waarde van 1792 + node-ID, gereserveerd voor.

Standaard voorkeur instellingen

Standaard netwerkstructuur

Om de configuratie van eenvoudige netwerkstructuren beperkt te houden, ondersteunt de CANopen standaard voorkeur instellingen van de bericht-id's ("Predefined Connection Set"). Een eenvoudig netwerkstructuur heeft ken 1: n communicatie tussen een stuurapparaat (Master) en een aantal lagere orde apparaten (Slaves). Deze set van standaard voorkeur instellingen ondersteunt een noodbericht per node, synchronisatie-en tijdstempel berichten, een SDO-aansluiting per apparaat, de NMT-berichten voor node controle en -monitoring en tot 4 zend- en 4 ontvangst PDO's per apparaat.

Layer Setting Services (LSS)

Interconnectie in een CANopen netwerk

Zoals reeds eerder vermeld, er moet aan twee voorwaarden worden voldaan voor de interconnectie van CANopen-apparaten binnen een netwerk:

• Alle apparaten moet dezelfde baudrate gebruiken, en
• Alle CANopen node-id’s moet uniek zijn.

In de begintijd van CANopen konden het node-ID en de baudrate met DIP-switches op apparaten ingesteld worden. Tegenwoordig liggen dergelijke instelling natuurlijk in non-volatile geheugen vast. De CANopen-specificatie DS-306: Layer Setting Services (LSS) beschrijft hoe deze belangrijke waarden kunnen worden ingesteld via de bus met behulp van een eenvoudig protocol. Voorwaarde voor het gebruik van LSS, naast de softwareondersteuning door de node zelf, een 1:1 bedrading vast met de node. De baudrate en het node-ID kunnen dan worden ingesteld via dialoogvorm. De COB-ID 0x7E5 wordt gebruikt voor CAN-berichten naar het apparaat, het apparaat reageert hierop via COB-ID 0x7E4. LSS berichten zijn altijd de volle 8 bytes lang. Ongebruikte bytes zijn gereserveerd en moeten worden geïnitialiseerd met 0.

Apparaat- en applicatieprofielen

CiA standaard profielen

Met CiA 301, de fundamentele CANopen specificatie, als basis zijn er ondertussen een groot aantal CANopen documenten gepubliceerd die aanvullende normeren voor apparaten of standaard toepassingen. In deze aanvullende normen (apparaat- en applicatieprofielen), worden het gedrag en de parameters van gestandaardiseerde CANopen apparaten of applicaties vastgesteld middels overeenkomstige items in de Object Directory. Het doel van de normalisatie van apparaat profielen is dat apparaten van een bepaalde klasse onderling uitwisselbaar zijn, en zodoende zorg dragen voor leverancier-onafhankelijkheid.