KAN åbne
CANopen er en åben netværksprotokol på topniveau til tilslutning af indlejrede enheder i indbyggede transport- og industrinetværk . Den bruger CAN -realtidsprotokollen som et netværks- og transportlag . Bruges til at forbinde sensorer, aktuatorer og programmerbare logiske controllere til hinanden. Åben standard.
Typiske applikationer
Hovedsageligt i bevægelseskontrolsystemer, i montage-, svejse- og transportenheder. Anvendes til enkeltkabelforbindelse af multi-input sensorbokse, smarte sensorer, pneumatiske ventiler, stregkodelæsere, aktuatorer og operatørkonsoller.
Fordele
Sammenlignet med andre CAN-baserede netværk er CANopen-netværket mere velegnet til højhastigheds-bevægelseskontrolsystemer og feedback-kontrolsløjfer. Høj pålidelighed, rationel brug af båndbredde, strømforsyning via netværkskabel.
Ulemper
Lav prævalens uden for Europa.
Perspektiver
Ud over at være en applikationslagsprotokol betyder CANopen medlemskab af en "hobby" hardwaredesignklub. Mere information kan findes på CiA's hjemmeside (www.can-cia.org). Alle, der finder det nødvendigt, kan tilslutte sig denne organisation. Organisationen forener blandt andet de førende bilproducenter i Europa.
Struktur af standarder
Organisationens struktur afspejler strukturen i de standarder, der styrer driften af CANopen-netværk.
Applikationslagsprotokollen er baseret på DS.301-dokumentet, som igen er en praktisk udvikling af ideerne, der er erklæret i CiA DS-201-207-dokumenterne. Den definerer protokollerne til konfiguration og drift af netværket.
CANopen-netværket er fokuseret på brugen af mikrocontrollere, inklusive de billigste, derfor er det opdelt i en række valgfrie undersystemer, som kun tillader brug af de nødvendige funktioner.
Netværkets funktion er udveksling af data. For at forstå funktionen af CANopen-netværket opdeler vi alle data i funktionelle og teknologiske.
Funktionelle data - de data, der beskriver målets funktion af systemet (temperatur, størrelsen af aktuatorernes kontrolhandlinger), de data, der ville blive transmitteret mellem enhederne, selvom en anden kommunikationslinje end CAN blev brugt som et link , for eksempel LIN eller USB , eller Ethernet , eller I2C .
Teknologiske data - dem, der sikrer netværkets funktion som helhed, kontrol af den korrekte drift af alle noder, konfiguration af dele af systemet - de data, hvis udseende er forbundet med brugen af CANopen-netværket og ikke direkte afhænge af de opgaver, systemet løser.
Dokument CiA DS-201 identificerer 4 hovedgrupper af undersystemer (Fig. 3 CiA DS-201)
CMS - beskeder. Disse omfatter: funktionel dataudveksling, hastemeddelelsesudveksling, anmodningsdataudveksling,
styring af objektordbog
NMT - netværksstyring, kontrol af netværksenheder
DBT - Dynamic Identifier Allocation
LMT - enhedskonfigurationsstyring
- 1. Real-time udveksling af funktionelle data nøgleord PDO, CMS (hovedundersystemet i princippet valgfrit, men hvis der ikke er nogen af de andre undersystemer, så kan dette tomme sæt kun kaldes CANopen potentielt).
Eksempel: Rumtemperaturstyring hovedenhed, temperaturmålere, varmelegemer/fordampere
- Objektordbogen er ikke et undersystem af PDO, SDO, entry, Index nøgleordet . Ordbogen bruges af alle undersystemer og beskriver de måldata, der skal udveksles, udvekslingsreglerne. Du kan drage en parallel med registreringsdatabasen i Windows.
Eksempel: Enkeltpunktstemperatur og varme-/fordamperkontrolparameter
- 2. Synkronisering af dataudvekslingsnøgleord SYNC (valgfrit, men det samme hensigtsmæssige undersystem som undersystem 1). Når du bruger dette undersystem, er der en synkroniseringsmeddelelsesgenerator i netværket, som periodisk transmitterer en SYNC-besked med høj prioritet. Efter fremkomsten af en sådan meddelelse i netværket udveksler alle synkroniserede enheder data inden for et bestemt tidsinterval (synkront dataudvekslingsvindue). Kollisioner (samtidig transmission af data fra to eller flere enheder) løses på niveau med det fysiske lag af CAN-protokollen. Ordbogen over objekter indeholder krydsreferencer, hvorfra hvilke data skal tages og hvilke data der skal placeres hvor. Applikationer indsamler således ikke data alene, blot i visse variabler (fra applikationens synspunkt) dukker der jævnligt nye data op, ligesom kontrolhandlinger. I denne tilstand kan udvekslingen ikke kun finde sted mellem sensorerne og hovedenheden, men også mellem sensorerne, uden om hovedenheden.
- Asynkron dataudveksling. Inkluderer udveksling af meddelelser om netværksstyring (netværksknudestyring) Netværksstyring, NMT-tjenester , meddelelser om netværkskontrol undersystem (mulighed for registrering af netværksfejl) Fejlkontrol , hastemeddelelser - nødobjekter (detektering af knudeoperationsfejl) Emergency Object, EMCY . Meddelelser fra denne klasse kan vises når som helst, inklusive i vinduet for synkron dataudveksling. Disse beskeder har en høj prioritet (højere end de beskeder, der udgør datapakker), og kollisioner løses på niveau med det fysiske lag af CAN-protokollen. For at implementere disse undersystemer i netværket tildeles en enhed (på netværksdesignstadiet) ansvarlig for driften af et bestemt undersystem. Derudover er der mekanismer til dynamisk tildeling af sådanne enheder. Nu i detaljer.
- 3. Styring af netværksknuder Netværksstyring, NMT Services (valgfrit undersystem). Netværket kan designes på en sådan måde, at hver enhed efter at have tændt, efter afsluttet initialisering, vil gå i klar-tilstand, men vil ikke deltage i udvekslingen af funktionelle data, før netværksstyringsmasteren (NMT-master) tillader dens drift . I klar tilstand deltager enheden ikke i udvekslingen af funktionelle data, men kan udveksle procesdata. I klar-tilstand kan enheden konfigureres (se undersystem til styring af objektordbog nedenfor). Ved at bruge dette undersystem kan netværksmasteren nulstille og genstarte enhver af de noder, der kræver en sådan procedure. Masteren modtager beskeder fra enheden, der angiver enhedens reelle tilstand, hvis den reelle tilstand ikke matcher den forventede, så betragtes dette som en fejl. Fejlsvar diskuteres nedenfor.
- 4. Netværkskontrol (detektion af netværksfejl) NMT-fejlkontrolprotokoller, Node Guarding, Heartbeat Protocol (valgfrit undersystem). Nogle systemer (især dem, der er relateret til sikkerhed) skal overvåge tilstedeværelsen og brugbarheden af alle standardsensorer.
Eksempel: Endeafbryder, når den udløses, skal motoren straks slukke.
Hvis selve sensoren pludselig bliver defekt, når endestopafbryderen er lukket, vil den ikke sende en besked om dette til hovedenheden, som er fyldt med en nødsituation, derfor, hvis en fejlfunktion af en sådan sensor opdages, er nødvendigt for straks at slukke motoren
Netværksfejldetektering ( Node Monitoring ) udføres på to lignende måder [1]
- I. Navnopkald for nodebevogtende noder . Masteren spørger periodisk de noder, der svarer. Så snart noden holder op med at reagere, noteres en fejl for denne sensor, og masteren kan i overensstemmelse med arbejdslogikken stoppe potentielt farlige processer. En node, der ikke vil blive pollet i et vist tidsrum (linjen er brudt), markerer også en fejl for sig selv. Ulemperne ved denne metode er, at anmodninger fra masteren optager en del af netværkets båndbredde, og svigt af en enkelt node (master) fører til fejl i hele netværket.
- II. Styre ur. Heartbeat ( lit. engelsk "heartbeat" ). Alle netværksknuder sender uafhængigt, uden anmodning, regelmæssigt beskeder om deres tilstand - "hjerteslagsmeddelelse". Hvis der ikke er nogen beskeder fra en node i kontrolintervallet, markerer andre noder, der abonnerer på dens beskeder, en fejl for sig selv. Denne metode er blottet for manglerne ved den forrige og anbefales til brug i moderne systemer [2] .
For hvert specifikt netværk er kun én kontrolmetode, enten Node Guarding eller Heartbeat Protocol, tilladt.
- 5. Ændring af objektordbogen. nøgleord PDO, SDO, PDO-mapping Objektordbogen indeholder data, der udveksles efter PDO princippet, beskriver sammensætningen og strukturen af disse data. Ved hjælp af dataudveksling efter behov (SDO) kan du ændre det datasæt, der udveksles efter PDO-princippet. SDO-dataudveksling er mulig både i klar-tilstand og i køretilstand. Efter at have tændt for strømmen, men før netværksdriften startes, er det således muligt at konfigurere alle netværksenheder til at udveksle de nødvendige data og derefter starte netværket. Når ordbogens struktur ændres under drift, skal følgende punkter tages i betragtning:
- SDO-børsen har en lavere prioritet end PDO-børsen, så der kan være et tidspunkt, hvor en del af ordbogen allerede er ændret i overensstemmelse med de nye krav, en del er endnu ikke ændret, og i det øjeblik en PDO-børs vil forekomme.
- Da enheder, der sender og modtager PDO'er, skal forstå hinanden, kan der opstå en situation, hvor en enhed vil arbejde med den nye struktur, og den anden med den gamle.
Disse to eksempler viser muligheden for kun at ændre ordbogens struktur, når netværket er stoppet, det er desværre ikke altid muligt.
- 6. Skift data efter anmodning. Ud over at ændre ordbogen kan en app på én enhed downloade data til en anden enhed. Forskellen mellem PDO- og SDO-kommunikation fra et applikationssynspunkt. Ved udveksling af PDO sker alt automatisk i henhold til visse regler, og applikationen, uden at referere til netværksprimitiver, modtager data fra variabler, som om dataene blev opnået inde i netop denne enhed. For at modtage data i henhold til SDO-princippet skal en applikation bruge netværkstjenester til at anmode om data fra en anden enhed, og først derefter, efter at have modtaget et svar, bruge dataene til arbejdet. Derfor bør rygraden i dataudveksling bygges på PDO-udveksling. Desværre er der grænser for størrelsen af dataene (8 bytes for PDO, men du kan bruge flere af disse stykker). Og kun når det er absolut nødvendigt at bruge SDO. I SDO-dataudveksling kaldes den enhed, der blev kontaktet med en anmodning om at modtage eller skrive (dowload/upload) data, SDO-serveren, og den enhed, der startede udvekslingen, kaldes klienten. Afhængig af mængden af data, der overføres, udføres udvekslingen efter forskellige algoritmer og kan ikke være mindre effektiv end PDO-udvekslingen. SDO-exchange giver dig mulighed for at kontrollere nøjagtigheden af data, hvilket endda giver dig mulighed for at downloade stykker af eksekverbar kode.
- 7. Nødobjekter, hastemeddelelser. Nødobjekt, EMCY . Under drift kan enheden opdage fejl i driften af sit program eller i driften af elektronikken. I dette tilfælde, jo hurtigere alle andre dele af systemet bliver underrettet om dette, jo bedre og driften af et sådant system vil være sikrere. Hastemeddelelser med høj prioritet bruges til dette formål. Sådanne meddelelser sendes, når en fejl opdages, og når fejlen forsvinder. Standarden beskriver fejlklasser, sådanne parametre kan være strøm, spænding, temperatur. Hvis nødmeddelelsesmekanismen er aktiveret i netværket, skal enheder forstå mindst to meddelelser - Generel fejl (uden specifikation af kategorier), fejlnulstilling. Hver type fejl kan specificeres med en anden hel byte, som kan kode for eksempel nummeret på den kontrollerede kæde.
- Fejl ved behandling. Basisstandarden beskriver kun, hvordan man rapporterer fejl, og definerer kategorier af fejl. Yderligere afklaring og reaktion på fejlen bestemmes af systemudvikleren.
Ovenstående punkter er beskrevet i CiA DS-201-207 og CiA DS-301. Udvikleren af systemet "fra bunden" kan selvstændigt bestemme de funktionelle krav til nettet, kontrollerede parametre og adfærdsscenarier i tilfælde af fejl. Men da CANopen-netværk bruges af et stort antal producenter, som allerede har udviklet systemer, der dækker mange industrier, er der kommet anbefalinger om, hvilke parametre, som minimum dette eller hint system skal fungere, og hvilke typer reaktioner på bestemte specifikke fejl, der til en bestemt enhedsklasse. Disse anbefalinger er udstedt i form af standarder i CiA DS-4**-serien. Dette gør det muligt at producere dele af systemer frem for hele systemer, og disse nye instrumenter vil integreres perfekt med systemer udviklet af anerkendte producenter. Nogle af disse standarder er allerede åbne (etablerede), nogle forbliver i små grupper af producenters ejendom (nye, med forbehold for ændringer). Hovedårsagen til, at der er så mange lukkede dokumenter, er, at disse ikke kun er anbefalinger, men standarder, hvis de ikke følges, vil systemet ikke fungere. Når der foretages ændringer i dokumenter, sendes nye versioner til alle medlemmer af denne interessegruppe. Interessegrupper er ikke en lukket kaste, alle kan være med i en eller anden gruppe. En forudsætning er et kontant bidrag. De opkrævede beløb afhænger af virksomhedens størrelse og er demokratiske i forhold til små virksomheder.
FAST BELØB MEDLEMSGEBYRER (ÅR) INKLUSIVE TYSKKE SKATTER
mere end 100.000 medarbejdere: 8.700,00 Euro 10.353,00 Euro
fra 10.000 til 99.999 ansatte: 5.200,00 Euro 6.188,00 Euro
fra 1.000 til 9.999 medarbejdere: 4.100,00 Euro 4.879,00 Euro
fra 100 til 999 ansatte: 2.100,00 Euro 2.499,00 Euro
fra 50 til 99 ansatte: 1.500,00 Euro 1.785,00 Euro
fra 10 til 49 ansatte: 900,00 Euro 1.071,00 Euro
fra 1 til 9 ansatte: 650,00 Euro 773,50 Euro
for skoler og universiteter: 520,00 Euro 618,80 Euro
Alle data om, hvilke grupper der findes, hvilke standarder de har udviklet og hvordan man forbinder dem, er placeret på can-cia.org-webstedet, som i dette tilfælde er det vigtigste organiserende organ og mekanisme for public relations.
Industrielle netværk i CAN-familien
Se også
CiA (engelsk) .
Noter
- ↑ CANopen Basics - Bevogtning og hjerteslag (downlink) . Hentet 28. april 2016. Arkiveret fra originalen 21. maj 2016. (ubestemt)
- ↑ Olaf Pfeiffer, Andrew Ayre, Christian Keydel Embedded Networking with CAN and CANopen - Copperhill Media, 2008
Links
| Industrielle netværk |
|---|
| Styresystem busser |
|
|---|
| Distribueret periferiudstyr |
|
|---|
| Drivteknologi |
|
|---|
| Markenheder |
|
|---|
| Bygningsautomatisering |
|
|---|