Kommunikationsgränssnitt med CANopen

Transkript

1 Kommunikationsgränssnitt med CANopen Communication interface with CANopen Examensarbete inom högskoleingenjörsprogrammet Elektroingenjör ANDERS KLAVMARK TERJE VIKINGSSON Examinator: Bill Karlström Institutionen för Signaler och System Avdelningen för Signalbehandling CHALMERS TEKNISKA HÖGSKOLA Göteborg, Sverige, 2013

2 Förord Examensarbetet genomfördes under 11 veckor, våren 2013 på Saab AB, Electronic Defense Systems, EDS i Kallebäck, Göteborg. Denna rapport är ett examensarbete på 15 högskolepoäng och är utfört av Anders Klavmark och Terje Vikingsson från Chalmers Tekniska Högskola. Arbetet genomfördes på Saab AB, på avdelningen C3 (Command, Control and Communication) Training Systems & Computer Platforms. Tanken är att rapporten ska ge en inblick i möjligheten att använda CAN-buss kommunikation och genom att konfigurera systemets olika komponenter i ett nätverk kunna avläsa dess status. Under de tio veckor som spenderats på Saab har vi lärt oss mycket nytt och vi har fått en djupare förståelse för vad det innebär att arbeta som ingenjörer på ett företag som ligger i teknikutvecklingens framkant. Vi skulle vilja rikta ett speciellt tack till vår handledare på Saab, Gustav Jansson, för all hjälp och guidning. Utan honom skulle vi aldrig kommit dit vi är idag. Ytterligare anställda på Saab som vi skulle vilja tacka är Per Örbäck, Lars-Olof Aridun, Björn Andersson, Jonas Granath och övriga anställda på avdelningen. Tack också till Manne Stenberg, vår handledare på Chalmers. Sist men inte minst vill vi uttrycka ett stort tack till Anders Martinsson, sektionschef för Runtime Environments på Saab EDS, som gjorde detta examensarbete möjligt och snabbt såg till att vi kom in i gemenskapen. I

3 Sammanfattning Den här rapporten beskriver utvecklingen av en prototyp som visar funktionaliteten hos ett CANopen-nätverk med master-slave konfiguration. Till grund för arbetet ligger Saabs önskan om att implementera nätverket i sina markbaserade radarsystem. I dagsläget finns begränsade styr- och övervakningsmöjligheter, vilket är skälet till att man vill koppla samman ingående komponenter i ett nätverk. Tanken är att man ska övervaka dessa komponenter från en kontrollpanel med hjälp av CAN-buss via Ethernet, IEEE till kontrollenheten. En inledande studie av CAN-standarden ISO görs, där teknikens grunder förklaras och dess fördelar påvisas. Högnivåprotokollet CANopen utreds med en genomgång av funktionerna som karakteriserar det och dess relation till de lägre lagren i OSI-modellen. Hård- och mjukvara anskaffas och en fungerande prototyp utvecklas för en kommande demonstration. Avslutningsvis görs en genomgång av programdesignen och möjligheterna till fortsatt utveckling. II

4 Abstract This report describes the development of a prototype that demonstrates the functionality of a CANopen network with master-slave configuration. The basis of the work is Saab s wish to implement the network on their ground-based radar systems. Currently, the state control and monitoring capabilities of these units are limited, which is why their various electrical components need to be connected in a common network. The idea is to monitor these components from a control panel by CAN-bus via Ethernet, IEEE to the control unit. An initial study of the ISO CAN standard is made, where the basics of the technology are explained and its benefits demonstrated. The high-level CANopen protocol is investigated with an overview of the features that characterize it and its relation to the lower layers of the OSI-model. Hardware and software are acquired and a working prototype is developed for demonstration purposes. Finally, a review of the application design is done and the potential for further development is assessed. III

5 Innehållsförteckning Förord... I Sammanfattning... II Abstract... III Innehållsförteckning... IV Figurer... VI Ordlista... VIII 1 Inledning Bakgrund Syfte Precisering av arbetsuppgiften Avgränsningar Metod Kravinsamling Planering/tidsplan Analys Design Integration Demonstration Rapport Presentation Teknisk bakgrund Open System Interconnection, OSI Lager 7, Applikationslagret Lager 6, Presentationslagret Lager 5, Sessionslagret Lager 4, Transportlagret Lager 3, Nätverkslagret Lager 2, Datalänklagret Lager 1, Fysiska lagret Controller Area Network, CAN Varför CAN? Protokoll Topologi (Fysiska Lagret) Bitrepresentation (Fysiska Lagret) Arbitrering (Datalänklagret) Meddelandeformat (Datalänklagret) Felhantering (Datalänklagret) CANopen Struktur Objektlistan Adressering Kommunikationsmodeller Service Data Object Protocol, SDO Process Data Object Protocol, PDO Network Management Protocol, NMT Special Object Protocol Ethernet CANfestival IV

6 4 Genomförande Undersökning och val av hårdvara och mjukvara Hårdvara Mjukvara Programdesign Programdesign, Master Programdesign, Slav Integration av systemet Programkörning av systemet Resultat Slutsats Kritisk diskussion Fortsatt utveckling CANopen över EtherCAT? Intelligent Platform Management Interface, IPMI SAE J Befintligt CANopen-nätverk Referenser Bilagor Appendix A Artila Matrix Appendix B PEAK PCAN-USB Appendix C Kommunikationsgränssnittmanual V

7 Figurer Figur 1 Arthur/Giraffe (Saab AB, 2013)... 1 Figur 2 Översikt av hela nätverket... 2 Figur 3 Översikt av arbetsuppgiften... 3 Figur 4 Processindelning... 5 Figur 5 OSI-modellens kommunikationsväg... 8 Figur 6 CAN buss Figur 7 Maximal bithastighet och busslängd (Pfeiffer, Ayre & Keydel, 2003) Figur 8 Manchester och NRZ (Sony Corp.) Figur 9 Nominell bittid (Mannisto & Dawson, 2003) Figur 10 Arbitrering (Wells, 2001) Figur 11 CAN meddelanderam (Wells, 2001) Figur 12 CANopen sett från OSI-modellen (CAN in Automation 2002 CANopen Application Layer and Communication Profile) Figur 13 Datagången mellan de olika lagren (CAN in Automation CANopen) Figur 14 CANopen enhetsmodell (CAN in Automation CANopen) Figur 15 Objektlistans struktur Figur 16 Objektlistan index och delindex koncept Figur 17 Meddelandetypernas struktur Figur 18 Producer/Consumer-modell (CAN in Automation CANopen) Figur 19 Server/Client-modell (CAN in Automation CANopen) Figur 20 Master/Slave-modell (CAN in Automation CANopen) Figur 21 SDO-struktur i ett nätverk (CAN in Automation CANopen) Figur 22 Segmenterad SDO-överföring (CAN in Automation CANopen) Figur 23 Påskyndad SDO-överföring vid uppladdning (CAN in Automation CANopen) Figur 24 Segmenterad SDO-överföring vid uppladdning (CAN in Automation CANopen) Figur 25 Definition av SDO-parametrar (CAN in Automation CANopen) Figur 26 Objektlistans struktur med avseende på SDO (CAN in Automation CANopen) Figur 27 PDO struktur (CAN in Automation CANopen) Figur 28 Definition av kommunikationsparametrar Figur 29 Definition av mappningsparametrar Figur 30 Mappningsstruktur Figur 31 Objektlistans struktur med avseende på PDO (CAN in Automation CANopen) Figur 32 Olika överföringsmetoder (CAN in Automation CANopen) Figur 33 Hur olika överföringstyper sätts Figur 34 Överföring av PDO med fördröjningstid (CAN in Automation CANopen).. 39 Figur 35 Mappningsexempel för PDO (CAN in Automation CANopen) Figur 36 NMT-struktur (CAN in Automation CANopen) Figur 37 CANopen tillståndsmaskin (CAN in Automation CANopen Figur 38 NMT meddelandestruktur (CAN in Automation CANopen) Figur 39 SYNC-signalens gång i nätverket (CAN in Automation CANopen) Figur 40 SYNC-signalens tidsfönster och period (CAN in Automation CANopen) Figur 41 Time Stamp-struktur (CAN in Automation CANopen) Figur 42 Felmeddelandens gång i ett nätverk (CAN in Automation CANopen) VI

8 Figur 43 Felmeddelandets struktur (CAN in Automation CANopen) Figur 44 Fördefinierade akuta felkoder (CAN in Automation CANopen) Figur 45 Ethernet Meddelanderam (Singh, 2010) Figur 46 CANfestival-implementation(CANfestival, 2001) Figur 47 Artila Matrix 522 (Artila 2013) Figur 48 PEAK PCAN-USB (PEAK SYSTEMS 2013) Figur 49 Master/Slave-kommunikation (ICPDAS 2013) Figur 50 Kommunikationsbegränsningar Figur 51 Tillståndsmaskin (Pfeiffer, Ayre & Keydel, 2003) Figur 52 Översikt av systemet Figur 53 Programval vid körning av slavprogram VII

9 Ordlista ARM Baudrate CAN CANfestival CANopen CiA COB CRC CSMA DLC EOF Ethernet GNU IA IDE IEEE IFS IPMI ISO Linux MAC MMU NMT OS OSI Advanced RISC Machine, Processorarkitektur Måttenhet för signalöverföring Controller Area Network, Nätverksteknologi CANopen ramverk av typen öppen källkod Kommunikationsprotokoll och enhetsprofilspecifikation för inbyggda system CAN in Automation Communication Object Cyclic Redundancy Check Carrier-Sense Multiple Access Data Length Code End Of Frame Nätverksteknologi General Public License Operativsystem Information Assurance, term för beskrivning av informationssäkerhet. Identifier Extension Standard för Local Area Network, som reglerar Ethernet Intermission Frame Space Intelligent Platform Management Interface Specifikation för seriella kommunikationsteknologin Controller Area Network Unixliknande operativsystem Media Access Control Memory Management Unit, översätter virituella adresser till fysiska adresser i minnet. Network Management Operating System Open Systems Interconnection VIII

10 PDO RTR SAE SDO SNMP SOF SYNC Toolchain UCU UCP USB Process Data Object, finns två typer: Receive och Transmit (RPDO & TPDO) Remote Transmission Request Society of Automotive Engineers Service Data Object Simple Network Management Protocol Start Of Frame Signal som används för synkronisering Programmeringsverktyg User Control Unit User Control Panel Universal Serial Bus IX

11 1 Inledning I takt med att elektroniska system blir mer och mer komplexa, ökar behovet att kunna övervaka status på ingående delar i ett service- och underhållssyfte. Ett sätt att styra och övervaka detta är att koppla ihop alla ingående komponenter i ett nätverk och låta en kontrollpanel övervaka status i systemet. 1.1 Bakgrund Saab Electronic Defence Systems är en leverantör av mark- och flygbaserade radarsystem som används för att upptäcka, lokalisera och skydda mot hot. Här utvecklas bland annat radarsystemen Giraffe och Arthur, se Figur 1, vilka tillhandahåller övervakning och stridsledning för närluftvärnsystem respektive lokalisering av fientligt artilleri. I dessa system ingår flera olika hårdvarukomponenter som i dagsläget har begränsade styr- och övervakningsmöjligheter. I nuvarande system avläses status på komponenterna med diskreta signaler, men förmågan att kommunicera med dem via exempelvis Ethernet till/från en User Control Panel, UCP, saknas. En UCP är en panel/bildskärm med touch-funktionalitet där man kan styra, övervaka och presentera status för systemet. För att kunna möjliggöra detta behöver ingående noder konfigureras i ett nätverk. Tanken är att alla dessa komponenter ska kopplas samman i ett Controller Area Network, CAN, för att underlätta informationsöverföringen till UCP. Utöver kommunikationen med CAN-nätverket ska man från UCP kunna läsa av status, sätta diskreta signaler och även styra datorer/datorkort, se Figur 2. Figur 1 Arthur/Giraffe (Saab AB, 2013) 1

12 Figur 2 Översikt av hela nätverket 1.2 Syfte Syftet med detta projekt är att ge ett förslag på kommunikationsgränssnitt som kan lösa systemets behov av övervakning och kontroll av ingående noder/komponenter, samt att ta fram en prototyp för att genomföra en demonstration. Den prototyp som tagits fram är ett första steg i att visa hur framtida lösningar skulle kunna utformas för system hos Saab. 1.3 Precisering av arbetsuppgiften Arbetsuppgiften består i att undersöka om det finns produkter som uppfyller de krav som ställs och i så fall ge förslag på en lämplig enhet att utveckla en CAN-till- Ethernet-brygga på. Om ingen produkt kan tillfredsställa kraven skall en egen konstruktion tas fram. Vidare skall en simulerad CAN-buss miljö skapas. Två hårdvaruenheter behövs, en enhet för utveckling av bryggan och en CAN-till-USBadapter som möjliggör kommunikation mellan bryggan och den simulerade CANmiljön. Bryggan skall fungera som en master till den simulerade CAN-buss miljön och hela systemet skall kunna styras och övervakas via Ethernet, enligt Figur 3. Själva CAN-miljön skall realiseras med CANopen då Saab valt att använda denna standard i sina system. 2

13 Figur 3 Översikt av arbetsuppgiften För att styra kommunikationen mellan komponenterna behövs en User Control Unit, UCU, som bryggar kommunikationen mellan nätverken. Systemen som skall använda sig av enheten ställer krav på den i form av bland annat interoperabilitet med befintliga nätverk, säkerhet och tolerans mot yttre faktorer. Interoperabilitet: System som Arthur och Giraffe är ofta monterade på ett tyngre fordon, till exempel en lastbil. Elektroniken i dessa fordon kommunicerar redan via CAN, men med en standard för tyngre lastbilar och terrängfordon kallad J1939, vilken skiljer sig från den CANopen standard man ska implementera i systemet. Det är därför önskvärt att en UCU har minst två CAN-gränssnitt så att styrning och övervakning kan göras av systemet och dess transportplattform. Det innebär att UCU agerar gateway i systemet. Säkerhet: För systemet finns det krav på Information Assurance, IA, som begränsar lösningsalternativen. En utredning av aktuella protokoll behövs göras. För ingående elektronik kan Simple Network Management Protocol version 3, SNMPv3, vara en lösning om det kan uppfylla krav på IT-säkerhet. Styrning: För att kunna styra datorer/datorkort kan Intelligent Platform Management Interface, IPMI, vara en lösning, men då gäller att alla datorer/datorkort har stöd för detta. Minst två Ethernet-gränssnitt behövs därför, ett för kommunikation med UCP och ett för styrning av datorer/datorkort. 3

14 Tolerans mot yttre faktorer: Då enheten kan komma att användas i stort skiftande miljöer krävs att den har hög tolerans mot yttre faktorer såsom temperatur och vibrationer. Exakta specifikationer ges av standarderna; MIL-STD-810C och MIL- STD-810F. Övriga krav: Av enheten krävs att stöd finns för 28 V spänningsmatning, vilket ges av MIL-STD-1275D, men även stöd för mottagande av diskreta signaler och att en kort startup-tid kan erhållas. 1.4 Avgränsningar Initialt övervägdes att från grunden utveckla helt egna hård- och mjukvarulösningar, såsom en egen Linux-distribution med tillhörande kärna och toolchain. Denna tanke övergavs till förmån för inköpt hårdvara och färdiga protokollstackar. Skälet till det var att den hårdvara som hittades ansågs gångbar, då de flesta krav uppfylldes och mjukvaran var tillräckligt avancerad för våra behov. Vidare var det från början tänkt att både CAN och Ethernet skulle behandlas, det visade sig dock tidigt att det skulle bli knappt om tid och all fokus lades på utvecklingen av CAN, vilket gjorde att Ethernet-aspekten lämnades till en möjlig fortsatt utveckling. I arbetet har vi även valt att inte lägga allt för stor tyngd på kraven på IT-säkerhet och tolerans mot yttre faktorer, utan först och främst sett till att en fungerande prototyp framställts. En annan begränsning som gjorts är att vi bara använder oss av två noder, en master och en slav. Enheten har dock utbyggnadsmöjligheter för många fler noder. 4

15 2 Metod Forskning och utveckling kan på Saab beskrivas som en flerstegsprocess, Saab R&D process, se Figur 4, där varje steg är uppbyggt av flera underprocesser, med sina egna mål och delmål. Ett liknande tillvägagångssätt följdes under detta arbete. 2.1 Kravinsamling Figur 4 Processindelning Arbetet inleddes med flera möten med kollegor på Saab, där vi fick en mer ingående redogörelse om hur framtida system ska utformas och hur vår prototyp kommer att passa in i helheten. Tillsammans med de systemkrav och implementationsförutsättningar som specificerades togs en första skiss på designen fram. 2.2 Planering/tidsplan Inledningsvis analyserades även vad/vilka delar som skulle ta mest tid i anspråk och en planeringsrapport, vilken användes till grund för det fortsatta arbetet, gjordes. 2.3 Analys När planeringen av arbetet var gjord var nästa steg att bedöma huruvida det fanns lämplig hårdvara att köpa in eller om en egen konstruktion skulle tas fram. Vi var här tvungna att ta hänsyn till den funktionalitet vi ville uppnå och de krav som ställts. Parallellt med detta undersökte vi vilken typ av mjukvara som var lämplig att använda till CAN-buss miljön. 5

16 2.4 Design Vi behövde någon form av industriell box-dator eller utvecklingskort att upprätta som master till en CAN-buss miljö samt som brygga till Ethernet. Utöver det var det nödvändigt med en CAN-till-USB-adapter för att kunna kommunicera med en CANbuss miljö bestående av en eller flera slavar på en Linux-dator. Någon typ av CANopen protokollstack krävdes för att kunna bygga dessa master- och slavapplikationer. Det vore fördelaktigt om denna stöddes väl av hårdvaran och var förhållandevis billig. Det fanns ett antal olika alternativ på marknaden så vi tog beslutet att köpa in hårdvaran istället för att utveckla egen. Även en protokollstack av typen öppen källkod hittades. Blockschema över nätverket togs fram för att få en överblick hur systemet fysiskt skulle konfigureras. För att kunna styra signalerna i systemet togs även en switchpanel fram med tillhörande kablage. 2.5 Integration Då produkterna levererats började vi installera allt vi behövde för att få upp en korrekt utvecklingsmiljö för båda sidor av CAN-buss miljön, det vill säga, master- och slavsidan. CAN-gränssnitten och bussen konfigurerades. Därefter kördes exempelprogram mellan enheterna och testkörning gjordes. Fokus lades sedan på att bygga vidare på dessa program och modifiera dem så att rätt funktionalitet kunde uppnås. 2.6 Demonstration Verifiering av prototypens funktionalitet gjordes och verifierades med de krav man ställt på den. En manual som beskriver tillvägagångssättet för att få upp utvecklingsmiljö och köra prototypen skrevs, se kapitel

17 2.7 Rapport Rapportskrivandet påbörjades i mindre utsträckning när vi väntade på beställda produkter genom att vi strukturerade upp rapportens layout och påbörjade de inledande kapitlen. När produkterna levererades lades dock fokus på utveckling av hårdvara och mjukvara vilket gjorde att rapportskrivandet fick vänta. Parallellt med produktutvecklingen fördes dagbok/loggbok med anteckningar av olika designbeslut och implementationsförslag. Vid återupptagandet av rapportskrivandet hade vi stor nytta av dessa dagböcker och veckorapporter som kontinuerligt skrivits under arbetets gång. 2.8 Presentation När arbetet kring rapporten var i sitt slutskede så inleddes förberedandet inför slutpresentationen. Presentationen genomförs med en muntlig framställan med stöd av en Power Point presentation 7

18 3 Teknisk bakgrund Kommande underrubriker beskriver viktig och användbar information som ligger till grund för förståelse av senare delar av rapporten och arbetsuppgiften. Detta för att göra läsaren upplyst om termer och uttryck som används frekvent i senare delar av rapporten. 3.1 Open System Interconnection, OSI OSI-modellen karakteriserar och kategoriserar de interna funktionerna hos ett kommunikationssystem. Modellens arkitektur består av sju lager och fungerar som en plattform för beskrivning av nätverksprotokoll. Varje lager tjänar det lager som ligger ovanför och blir tjänad av det lager som ligger under, se Figur 5. OSI-modellen är konstruerad på ett sådant sätt att även de mest komplexa nätverk kan beskrivas med den, dock använder sig många nätverk inte av alla sju lager. Då CAN-nätverk ofta är slutna och behandlar relativt små och enkla meddelandestrukturer med data från till exempel tryck- och temperaturgivare är endast de två lägsta lagren inkluderade i CAN-specifikationen, ISO (Microsoft Corp, 2002) Figur 5 OSI-modellens kommunikationsväg 8

19 3.1.1 Lager 7, Applikationslagret Applikationslagret är det högsta lagret och närmast användaren. Det kan ses som ett fönster som användare och applikationsprocesser öppnar för att få tillgång till nätverkstjänster. (Microsoft Corp, 2002) Lager 6, Presentationslagret Presentationslagret formaterar data som skall presenteras i applikationslagret. Här översätts data från formatet använt av applikationslagret till ett gemensamt format som kan användas av de lägre lagren och tvärtom. Detta lager tillhandahåller även kompression och kryptering av data. (Microsoft Corp, 2002) Lager 5, Sessionslagret Sessionslagret tillhandahåller information om hur sessioner upprättas och avslutas mellan processer som körs på olika stationer. (Microsoft Corp, 2002) Lager 4, Transportlagret Transportlagret ser till att hela meddelanden tas emot felfritt och i rätt sekvens utan databortfall eller dupliceringar. Storleken och komplexiteten på detta lager beror på hur tillförlitligt nätverkslagret under det är, ett opålitligt nätverkslager kräver ett transportprotokoll med stor feldetekteringsmöjlighet. Till skillnad från de lägre lagren vars protokoll berör omedelbart avgränsande noder så är transportlagret och de ovanstående lagren så kallade källa till destination -lager. De är alltså endast bekymrade av kommunikationen från startnod till slutnod, inte de noder som passeras på vägen. (Microsoft Corp, 2002) 9

20 3.1.5 Lager 3, Nätverkslagret Nätverkslagret styr driften för delnätet och bestämmer, baserat på bland annat nätverksförhållanden och prioritet, vilken väg skickad data skall ta. (Microsoft Corp, 2002) Lager 2, Datalänklagret Datalänklagret tillhandahåller felfri överföring av datapaket mellan noder på det fysiska lagret vilket gör att lagren ovanför kan anta en felfri informationsöverföring dem emellan. Här ligger bland annat funktioner såsom CSMA/CA vilka används av CAN. (Microsoft Corp, 2002) Lager 1, Fysiska lagret Fysiska lagret är modellens lägsta lager och behandlar sändning och mottagning av bitströmmar över fysiska delar av nätverket, såsom kablage. Det tillhandahåller bland annat funktioner och information rörande datakodning, hårdvaruanslutningar och sändningstekniker. (Microsoft Corp, 2002) 10

21 3.2 Controller Area Network, CAN Controller Area Network, CAN, är ett seriellt bussystem ursprungligen utvecklat till fordonsapplikationer under tidigt 80-tal. Idag har i stort sett alla nyproducerade passagerarfordon i Europa minst ett CAN-nätverk. (CAN in Automation, CAN history, 2001) Det var under tidigt 1980-tal som ingenjörer hos Bosch evaluerade möjligheten att använda seriella bussystem i passagerarfordon. Microprocessorer hade blivit så små och kraftfulla att de i allt större utsträckning användes i fordon och i takt med att fler och fler elektriska system introducerades ökade behovet av att på ett effektivt sätt få dem att kommunicera med varandra. (Mannisto & Dawson, 2003) Då inga av de befintliga nätverksprotokollen ansågs uppfylla ingenjörernas krav fastslogs 1983 att man skulle utveckla ett helt nytt seriellt bussystem. Ett stort antal ingenjörer var involverade i utvecklingen, inte minst från biltillverkaren Mercedes- Benz och halvledartillverkaren Intel. I Detroit, under 1986 års Society of Automotive Engineers, SAE, kongress introducerades således vad man då kallade för Automotive Serial Controller Area Network och dess multi-master nätverksprotokoll. Det sistnämnda byggde på en icke-destruktiv förlikningsmekanism som gav det meddelande med högst prioritet tillträde till bussen utan någon fördröjning. En extensiv felhanteringsmekanism hade även implementerats, bland annat en automatisk avkoppling av noder som uppvisade ett felaktigt beteende. När det kom till själva busskommunikationen stack CAN ut från de, på den tiden, tillgängliga bussystemen. Skickade meddelanden identifierades genom deras innehåll och inte avsändarens eller mottagarens adresser. Meddelandets identifierare specificerade även dess prioritet på bussen. Ett år senare levererade Intel det första CAN-kontroller-chipet, endast fyra år efter att idén kläckts. (CAN in Automation, CAN history, 2001) 11

22 CAN blev under ett tidigt skede mycket populärt i Nordeuropa och trots att man utvecklat det med inriktning på applikationer inom fordonsindustrin kom de första från helt andra marknadsområden. Det användes i allt från hissar till maskiner inom textil- och sjukvårdsindustrin. Trots att det inom dessa områden började dyka upp olika typer av mer eller mindre standardiserade högnivåprotokoll förhöll sig majoriteten av dessa CAN-pionjärer till ett monolitiskt tillvägagångssätt. Funktioner som berörde kommunikation, nätverkshantering och applikationer var en och samma mjukvara. Under tidigt 1990-tal gick användare och tillverkare därför ihop och etablerade en neutral plattform för teknisk förbättring av CAN och marknadsföringen av det seriella bussystemet. Det var början till vad som skulle komma till att bli CAN in Automation, CiA, en organisation av internationella användare och tillverkare, ledande i utveckling och stöd av CAN-baserade högnivålager. En av de första uppgifterna man åtog sig var specificeringen av ett CAN-applikationslager (CAL). Då CAN helt och hållet är en datalagerimplementation fanns inga standarder för hur utbytet av data skulle se ut på applikationsnivå. Tillvägagångssättet för utvecklingen av CAL var teoretiskt sett helt korrekt och resultatet användbart inom industriella applikationer men en stor nackdel var att varje användare blev tvungen att designa en ny kommunikationsprofil. Ett europeiskt konsortium lett av Bosch hade lösningen på problemet och utvecklade en prototyp som skulle bli känd som CANopen. (CAN in Automation, CAN history, 2001) Applikationslagret, som senare kom att kallas Green Book var bland det första man specificerade men utöver utvecklingen av specifikationer såsom denna var en av huvuduppgifterna att skapa ett informationsutbyte mellan experter och de som intresserade sig för CAN. En internationell konferens hålls därför årligen. (CAN in Automation, CAN history, 2001) Varför CAN? Det multi-master system som används av CAN skiljer sig från traditionella nätverk såsom USB och Ethernet. Istället för att sända stora datablock mellan noder under uppsikt av en central kontrollenhet så skickas flera korta meddelanden ut till alla noder på nätverket. Meddelanden är alltså inte riktade till någon specifik nod utan det 12

23 är noderna själva som avgör om det meddelande som ligger på bussen är av intresse eller inte. Det finns ingen unik nod utan alla är likvärdiga och kan, förutsatt att bussen är ledig, när som helst skicka information till vilka andra noder som helst. Alla meddelanden som skickas är tillgängliga för alla noder på nätverket men då varje meddelande har en unik identifierare väljer noden individuellt om informationen är relevant eller om den ska ignoreras. Om en nod skulle sluta fungera påverkar det inte systemet utan de fungerande noderna kan fortsätta sin kommunikation. Denna teknik leder till effektivare meddelandekontroll och reducerar drastiskt kabelåtgången. Service- och underhållsuppgifter förenklas då hårdvara kan tas bort, bytas ut eller läggas till utan att på ett negativt sätt påverka nätverket. (Mannisto & Dawson, 2003) CAN-specifikationen, ISO-11898, beskriver hur information passerar mellan enheter på nätverket och använder sig av OSI-modellens två lägsta lager, datalänklagret och det fysiska lagret. Protokollet har vad man kallar carrier-sense multiple access with collision avoidance förkortat CSMA/CA. I praktiken betyder det att alla noder måste vänta på en fördefinierad tid av bussinaktivitet innan de får sända ett meddelande och att eventuella busskonflikter löses genom bitvis arbitrering baserad på en fördefinierad prioritet av olika meddelandes identifierare. Det meddelande som har högst prioritet vinner tillträde till bussen. Ett meddelande som till exempel förmedlar en motors varvtal ges högre prioritet än ett som innehåller information om motors temperatur då temperaturen inte behöver uppdateras lika ofta. (Corrigan, 2008) Protokoll Ett protokoll är en uppsättning regler som rör kommunikationen på nätverket. Det specificerar bland annat parametrar såsom vilken typ av data som kan skickas, hur meddelanden identifieras, hur datapaket är uppbyggda och mycket mer. Ofta kan nätverkstekniker såsom CAN och Ethernet beskrivas med flera olika protokoll men som skiljer sig i någon eller några av parametrarna ovan. (Wildpackets Inc.) 13

24 3.2.3 Topologi (Fysiska Lagret) Som kommunikationsnätverk är CAN mycket flexibelt då det endast implementerar delar av det fysiska lagret och datalänklagret. Ovanpå dessa lager kan sedan en mängd standardiserade högnivåprotokoll appliceras. En CAN-buss är ofta uppbyggd av ett tvinnat kabelpar som är terminerad med 120 Ω motstånd i båda ändar men det fysiska mediumet kan variera och vara av typen kraftledning, optisk fiber, med mera. Noder kopplas in på kablarna CAN_H respektive CAN_L (Hög/Låg), enligt Figur 6, och signalen utgörs av differensspänningen. (Pfeiffer, Ayre & Keydel, 2003) Figur 6 CAN buss En nod består av följande tre delar; Processor, CAN controller och tranceiver. Host Processor Nodens processor tolkar mottagna meddelanden men avgör även vilka meddelanden noden själv ska skicka. Till denna enhet kan sensorer, ställdon och styrenheter kopplas. CAN controller En nods kontroller har en inbyggd klocka och lagrar från bussen mottagna bitar i serie tills det att ett helt meddelande tagits emot och processorn kan hämta det. Vanligen sker detta efter det att kontrollern signalerat ett avbrott. Analogt för sändning, processorn lagrar meddelanden på kontrollern som sedan seriellt skickar bitarna ut på bussen. 14

25 Tranceiver (Transmitter/Receiver) Anpassar signalnivåer från bussen till nivåer som förväntas av kontrollern och tvärtom. Den innehåller även kablage som skyddar kontrollern från överspänning. Bussens läge beskrivs vanligen som antingen recessivt eller dominant där det förstnämnda inträffar när CAN_L och CAN_H har samma potential (2.5 V) och det sistnämnda när det är en potentialskillnad dem mellan (1.5 resp. 3.5 V). Ett recessivt läge på bussen motsvaras av CAN som en etta medans ett dominant läge motsvaras av en nolla. Den maximala hastigheten med vilken enheter på nätverket kan kommunicera med varandra beror av bussens fysiska längd och åskådliggörs i Figur 7 nedan. Långa kablar gör att det tar längre tid för en signal att färdas från en punkt i nätverket till en annan och tillbaka vilket resulterar i att bithastigheten måste sänkas för att undvika konflikt på bussen. När det gäller bithastighet benämns denna oftast i termer om tusentals bit per sekund (Kbps) eller miljoner bit per sekund (Mbps) och syftar på antal bitar som passerar en given punkt i nätverket per sekund. (Pfeiffer, Ayre & Keydel, 2003) Bithastighet Busslängd 1 Mbit/s 25 m 800 Kbit/s 50 m 500 Kbit/s 100 m 250 Kbit/s 250 m 125 Kbit/s 500 m 50 Kbit/s 1000 m Figur 7 Maximal bithastighet och busslängd (Pfeiffer, Ayre & Keydel, 2003) Som nämnts ovan är CAN ofta ett 2-kabel nätverk där endast CAN_H och CAN_L finns representerade. Beroende på applikation kan det dock behövas fler kablar/signaler såsom jord, spänningsmatning och sköldning. De kontakter som används kan variera och vara allt ifrån 9-pinnars D-Sub till 4-pinnars RJ10 och 8- pinnars RJ45. CAN är med andra ord inte särskilt kräset när det kommer till kontakter eller kablage, speciellt vid lägre hastigheter då toleransen är högre. (Pfeiffer, Ayre & Keydel, 2003) 15

26 3.2.4 Bitrepresentation (Fysiska Lagret) Non-Return to Zero CAN använder sig av bitkodningsmetoden NRZ, Non-Return to Zero. Denna metod kräver, till skillnad från bland annat Manchester-bitkodning, inte en signalövergång för att representera varje bit. Signalnivån ligger konstant över bittiden vilket gör att den för en sträng av ettor eller nollor kommer att hålla samma värde för så många bitar det behövs, se Figur 8. (Mannisto & Dawson, 2003) Figur 8 Manchester och NRZ (Sony Corp.) Med NRZ-kodning elimineras onödiga signalövergångar vilket gör att ett CANsystem kan kommunicera med nästan dubbla hastigheten för en given klockfrekvens jämfört med system som använder Manchester-kodning. Nackdelen är att signalen under långa tidsintervall kan ligga på ett konstant högt eller lågt värde vilket gör att nodernas interna klockor kan hamna ur synk. (Mannisto & Dawson, 2003) Det kan leda till svårigheter i att veta när en bit slutar och nästa börjar om det är mer än två ettor eller nollor i rad. CAN-protokollet använder sig därför av en teknik som kallas Bit Stuffing. Den har funktionen att vid ett bitmönster med fem identiska bitar i rad sätta in en signalövergång, en så kallad stuff bit. Noder använder denna bit för att synkronisera sina klockor och då alla noder håller uppsikt efter bitmönster med fem identiska bitar i rad så ignoreras stuff-biten automatiskt av mottagaren. (Pfeiffer, Ayre & Keydel, 2003) 16

27 Bit-timing och Synkronisering På det fysiska lagret använder sig CAN av synkron bitöverföring vilket ökar överföringskapaciteten men som i sin tur kräver sofistikerad bitsynkronisation. Noder i ett CAN-nätverk använder sig vanligen av två metoder för att synkronisera sina klockor, hårdsynkronisering och återsynkronisering. Hårdsynkronisering sker en gång vid en meddelandeöverföring, i början av ramen för ett nytt meddelande. Bussen är alltid i ett recessivt läge innan ett meddelande skickas så meddelanderamens första bit, SOF skickas alltid dominant. Noder på nätverket använder denna signalövergång för att synkronisera sina klockor men klarar ej av att behålla synkroniseringen genom ramens hela längd så det krävs kontinuerlig återsynkronisering. Detta sker inuti ramen för ett meddelande, varje gång bussen går från ett recessivt till ett dominant läge. (CAN in Automation, CAN physical layer, 2001) Specificerat finns också en nominell bithastighet som indikerar antal bitar som skickas av en ideal överförare utan återsynkronisation. Alla noder i ett CAN-nätverk måste ha samma nominella bithastighet. Nominell bittid är den tiden som krävs för att skicka en enskild bit över nätverket och används för att säkerställa att alla noder samplar bussen vid rätt tillfälle för att avgöra om bussen är i ett recessivt eller dominant läge, se Figur 9. Denna bittid kan delas upp i segment där varje segment är indelat i mindre enheter, så kallade time quanta. (Mannisto & Dawson, 2003) Figur 9 Nominell bittid (Mannisto & Dawson, 2003) 17

28 Den nominella bittiden har följande uppdelning: Synchronization Segment är det första segmentet och det är här som signalövergången förväntas inträffa. Propagation Delay Segment kompenserar för tiden det tar för signaler att färdas från en punkt i nätverket till en annan och elektriska komponenter att reagera på stimulus. Phase Buffer Segment (1 och 2) används för att kompensera nodoscillatorers tendens att hamna ur synk. Dessa segment är justerbara och kan göras längre/kortare utifrån givet fel. Återsynkronisationen sker här. Sample Point inträffar alltid mellan Phase buffer-segmenten och det är här som bussens läge samplas. (Mannisto & Dawson, 2003) Arbitrering (Datalänklagret) I OSI-modellens andra lager finns ett underliggande funktionslager kallat Media Access Control (MAC). Detta tillhandahåller kontrollmekanismer för adressering och åtkomst till noder inom nätverk med multiple access. Dessa mekanismer kan delas upp i två varianter; bestämd och slumpmässig åtkomstkontroll. Med bestämd åtkomstkontroll är tillträde till bussen satt innan en nod försöker nå den vilket garanterar att konflikt undviks. Detta involverar i de flesta fall en central kontrollenhet som styr åtkomsttilldelningen vilket ökar systemets sårbarhet då nätverket står och faller med denna. (Mannisto & Dawson, 2003) Slumpmässig åtkomstkontroll bygger på att noder när som helst kan komma åt bussen så länge denna är i recessivt tillstånd. Vanligast är kontrollmetoder baserade på så kallad Carrier-Sense Multiple Access (CSMA). Det betyder att alla noder lyssnar på bussen och de som har ett meddelande för sändning inväntar ett recessivt läge (bussen är ledig) innan de samtidigt börjar skicka sin data. Då endast en nod åt gången tillåts sända på bussen krävs åtgärder för att veta vilken nod som får prioritet. (Mannisto & Dawson, 2003) Busskrockar kan nämligen ske trots att noder lyssnar på bussen för att försäkra sig om att ingen annan sänder något samtidigt då det alltid finns en liten fördröjning innan en nods bitar når en annan nod. (Mannisto & Dawson, 2003) 18

29 Carrier-Sense Multiple Access with Collision Detection, CSMA/CD En vidareutveckling av ovanstående teknik är CSMA/CD där man lagt till en krockdetekteringsfunktion. Denna funktion tillåter meddelandekonflikt men ingriper när de inträffar. Som innan kommer varje nod att se om bussen är ledig innan de sänder men som sagt kan det, på grund av fördröjning i nätet, uppstå tillfällen där flera noder sänder samtidigt. Då dessa konstant lyssnar till vad som läggs på bussen upptäcks felet och alla noder avbryter sina sändningar. De väntar en individuellt slumpad tid och försöker därefter sända igen. Nackdelen med denna metod framträder när det är mycket tvister om vilken nod som ska sända då sändningar hela tiden avbryts vilket slösar bandbredd och skapar långa avbrott. (Mannisto & Dawson, 2003) Carrier-Sense Multiple Access with Collision Avoidance, CSMA/CA CAN-protokollet använder sig av en icke-destruktiv förlikningsmekanism, så kallad CSMA/CA. Principen är densamma som CSMA/CD med skillnaden att kollisioner undviks helt istället för att åtgärdas efter att de inträffat. Vidare är metoden ickedestruktiv, det vill säga, bussen kommer aldrig vara upptagen med datasändningar som konstant avbryts och återupptas. (Mannisto & Dawson, 2003) Trafiken kontrolleras genom att ge meddelanden med hög prioritet tillträde till bussen före meddelanden med lägre prioritet. Som nämnts tidigare börjar alla CANmeddelanden med ett arbitreringsfält som består av en SOF-bit, en 11 eller 29-bitars identifierare och en RTR-bit. Det är detta fält som identifierar meddelandet och bestämmer dess prioritet. Ett meddelande med en låg identifierare kommer oftare erhålla prioritet då identifieraren består av fler dominanta bitar (nollor). (Wells, 2001) Arbitreringen sker då nodernas identifieringsfält sänds och börjar med den mest signifikanta biten, bit 10 för ett 11-bitars ID. En binär nolla ses som en dominant bit vilken alltid skriver över en binär etta, vilken ses som en recessiv bit. Detta medför att bussens läge alltid kommer reflektera det meddelande ID som har högst prioritet, se Figur 10. Skulle en nod upptäcka att bussen håller ett värde som inte stämmer överens med det noden skickar, avbryter den omedelbart sin arbitreringsprocess och väntar till dess att bussen är ledig innan den på nytt försöker sända sitt meddelande. På detta sätt erhåller meddelandet med högst prioritet rätten till fortsatt sändning, helt obehindrat 19

30 och utan fördröjning. Arbitreringsprocessen illustreras i bilden ovan, där nod 1 har prioritet över nod 2 men där nod 3 har prioritet över dem båda. Bussens innehåll speglar således nod 3. (Wells, 2001) Figur 10 Arbitrering (Wells, 2001) Meddelandeformat (Datalänklagret) Ett CAN-system skickar data med hjälp av så kallade meddelanderamar (Frames). En meddelanderam kan ses som ett paket med information som innehåller ett komplett meddelande från en sändare. Det finns fyra olika typer av meddelanderamar: Data Frame. Används för överföring av data på nätverket Remote Frame. Skickas vid begäran av data från en nod till en annan. Error Frame. Skickas av mottagare om fel upptäckts i ett meddelande. Säger åt sändaren att skicka meddelandet igen. Kan skickas som aktiv eller passiv beroende på nodens tillstånd. Overload Frame. Skickas av mottagare för att be sändaren fördröja nästa meddelande. (Mannisto & Dawson, 2003) Dessa meddelanden kan ha ett av två olika format beroende på vilket protokoll man använder sig av. I huvudsak skiljer de sig endast på längden av identifieraren som används. CAN version 2.0A (Base Frame Format) har en 11-bitars identifierare 20

31 medan version 2.0B (Extended Frame Format) har stöd för både 11 och 29-bitars identifierare. (Wells, 2001) Ett generellt CAN meddelande börjar med en startbit (SOF) och följs sedan av ett arbitreringsfält som består av identifieraren och en Remote Transmission Request (RTR) bit, se Figur 11. Den sistnämnda skiljer på vad som är skickad data och vad som är en förfrågan om data. Därefter kommer ett kontrollfält som innehåller en IDentifier Extension (IDE) bit, för att göra skillnad på basformat och förlängt format och Data Length Code (DLC) som indikerar antal bytes som följer i Data-fältet. Skulle det aktuella meddelandet vara en förfrågan av information så innehåller detta fält antal efterfrågade data-bytes. Cyclic Redundancy Check (CRC) fältet innehåller en kontrollsumma som möjliggör utförandet av en integritetsförsäkran hos mottagaren. Fältet ACK står för Acknowledge och skickas alltid som en recessiv bit men skrivs över som en dominant bit av mottagaren om denne på ett korrekt vis mottagit meddelandet. För att indikera meddelandets slut används en End Of Frame (EOF) bit. Slutligen finns det en Intermission Frame Space (IFS) bit som indikerar det minsta antal bitar som skiljer fortlöpande meddelanden åt. (CAN in Automation, CAN protocol, 2001) Figur 11 CAN meddelanderam (Wells, 2001) 21

32 3.2.7 Felhantering (Datalänklagret) Datalänklagret i CAN-system har mycket effektiva mekanismer för detektering och hantering av fel: Bit Check, görs av nod vid egen sändning och bygger på att noden övervakar sin sändning. Upptäcks en recessiv bit när en dominant förväntades så signaleras bitfel. Frame Check, de olika meddelanderamarna innehåller fält som alltid håller samma värde, såsom SOF och EOF. Noder kontrollerar dessa värden för varje meddelande de tar emot, skulle ett fel upptäckas signaleras format-fel (Form Error). Cyclic Redundancy Check, applicerar en polynomekvation på det datablock som ska skickas och det beräknade resultatet placeras i meddelandets CRC-fält. Mottagande nod utför samma beräkning och jämför resultatet med det i CRC-fältet, upptäcks ett fel skickas ett felmeddelande till sändaren. Acknowledgement Check, de noder som skickat ett meddelande lyssnar efter ett bekräftelsemeddelande från minst en nod i nätverket. Tas inget sådant emot ses det som ett bekräftelsefel (Acknowledgement error) och noden kommer att fortsätta skicka sitt meddelande tills det att bekräftelse tagits emot. Stuff Rule Check, noder håller aktivt koll på överträdelser av regeln mot mer än fem identiska bitar i rad. Skulle det upptäckas skickas ett felmeddelande till sändaren. För att undvika att en defekt nod blockerar kommunikationen på hela nätverket har CAN designats för att automatiskt upptäcka felande noder och snabbt koppla bort dem. Alla noder har därför två felräknare, en för sändningsfel och en för mottagningsfel. Dessa räknas upp för respektive fel men ökningen per fel beror av vilken typ av fel det handlar om. En nod som ser att den är källan till ett fel ökar motsvarande räknare med 8 om det är sändningsfel och 9 om det är mottagningsfel. Upptäcks fel men källan inte är noden själv så ökas respektive räknare med 1. För varje lyckad sändning eller mottagning minskar respektive räknare med 1. 22

33 Dessa räknare placerar en nod i ett av tre tillstånd; aktiv, passiv eller av. En aktiv nod fungerar som den ska och får skicka felmeddelande till alla andra noder på nätverket. Passiva noder har en felräknare med ett värde som överstiger 127, de kan skicka och ta emot meddelanden men har bara tillåtelse att skicka passiva felmeddelanden om ett fel upptäcks. Skulle en passiv nod sända ett meddelande som innehåller fel blir den tvungen att vänta 8 bittider innan den får sända igen. För att en nod ska försättas i tillståndet av måste dess räknare för sändningsfel ha överstigit 255, det spelar ingen roll hur stort antal mottagningsfel noden har. En nod i detta tillstånd får inte på något sätt påverka bussen men kan fortfarande ta emot meddelanden. Denna respons på fel hjälper till att hålla nätverket i funktionsdugligt skick trots att en eller flera noder upphört att fungera normalt. Tack vare det faktum att noder kan återställa sig själva efter flera fel (minska sina räknare genom korrekt meddelandetransmission) har systemet goda återhämtningsmöjligheter. (Mannisto & Dawson, 2003) 23

34 3.3 CANopen Det var ett europeiskt konsortium lett av Bosch som utvecklade en ny prototyp av ett CAN-baserat applikationslager som skulle komma till att bli CANopen. Efter färdigställandet skickades det till CiA för underhåll som år 1995 publicerade en helt reviderad kommunikationsprofil för CANopen. I standarden, CiA 301 specificeras den grundläggande CANopen-enheten och kommunikationsprofiler medan mer avancerade enheter och kommunikationsprofiler är skapade utifrån denna grundläggande profil och specificeras i andra, högre, standarder. Dessa standarder används med fördel som mallar vid skapande och anpassning av egen CANopen enhet. CANopen har mycket flexibla konfigureringsmöjligheter och lämpar sig väl till inbyggda nätverk i all form av maskinkontroll och det blev mycket använt under sent 1990-tal då hela industrisegment adopterade lösningen. (CAN in Automation CAN history) (RT-Labs AB 2009) CANopen är en kommunikationsprotokollstack och enhetsprofilspecifikation, vilken representerar de högre lagren i OSI-modellen, ned till nätverkslagret, se Figur 12. De lägre lagren, datalänklagret och det fysiska lagret, är nästan alltid representerade av CAN. CANopen består av ett adresseringsschema, flera mindre kommunikationsprotokoll, en objektlista och ett applikationslager. (RT-Labs AB 2009) (Wikipedia 2013 CANopen) Figur 12 CANopen sett från OSI-modellen (CAN in Automation 2002 CANopen Application Layer and Communication Profile) 24

35 Kommunikationsprotokollstacken har som syfte att hantera de inkommande och utgående meddelandena, ansvara för enhetens signaler och dessutom sköta det logiska flödet hos enheten. Det finns en protokollstack i varje enhet och denna protokollstack kan anpassas för just den enhetens uppgift, men huvuddelen av protokollstacken är ändå likadan för samtliga enheter. (RT-Labs AB 2009) (Wikipedia 2013 CANopen) Struktur Kommunikationskonceptet bygger ju som sagt på OSI-modellen, där CANopen representerar de högre lagren med ett applikationslager och kommunikationsprofil och där de lägre lagren oftast representeras av CAN. Kommunikationsvägen mellan två enheter sker via de olika lagren, från applikationslagret på den sändande enheten ner till bussen och sedan vidare från bussen upp till applikationslagret på den mottagande enheten, enligt Figur 13. Kommunikationen som bildas mellan de olika lagren verkställs på olika sätt. På applikationslagret utbytes kommunikations- och applikationsobjekt. Dessa kan kommas åt från objektlistan via ett 16-bit index och ett 8-bit delindex. Mellan datalänklagren skickas information med nod-id och data. Kommunikationen på det fysiska lagret specificerar bitnivå och bit-tidstyrning. (Pfeiffer, Ayre & Keydel, 2003) (CAN in Automation CANopen) Figur 13 Datagången mellan de olika lagren (CAN in Automation CANopen) 25

36 En CANopen-enhet kan beskrivas i tre delar, vilka är kommunikation, objektlistan och applikation, se Figur 14. Utöver detta så behövs en tillståndsmaskin. Denna tillståndsmaskin ska innehålla tillstånden initiering, före driftläge, driftläge och stoppad. Kommunikationsdelen innehåller flera olika kommunikationsprotokoll som bland annat används för att skicka och ta emot data, konfigurera objektlistan och ändra tillstånd i tillståndsmaskinen. Var och en av dessa måste stödjas av varje enhet i ett CANopen-nätverk. I kommunikationsdelen finns även passande funktionalitet för att tolka och transportera data via de lägre lagren. Objektlistan knyter samman de tre delarna med varandra och innehåller information om enheten. I objektlistan finns information som har inflytelse på enhetens kommunikations- och applikationsobjekt. Applikationsdelen utför den önskade funktionen hos enheten då tillståndsmaskinen är i sitt driftläge. Det är applikationsdelen som tillhandahåller de eventuella processignalerna. (RT-Labs AB 2009) (Wikipedia 2013 CANopen) (CAN in Automation 2002 CANopen Application Layer and Communication Profile) Figur 14 CANopen enhetsmodell (CAN in Automation CANopen) 26

37 3.3.2 Objektlistan Den viktigaste delen i protokollstacken är objektlistan. Den är själva kärnan av varje CANopen-nod. Objektlistan fungerar som en uppslagstabell, där varje objekt adresseras genom ett 16-bit index och ett 8-bit delindex. Objekten kan kommas åt via att mottaga och sända Service Data Objects, SDO. Delar av objektlistan kan även mappas så att den kan kommas åt med Process Data Objects, PDO. Strukturen av objektlistan ges av att de 16-bitars indexen är indelade i olika sektioner, enligt Figur 15. (Pfeiffer, Ayre & Keydel, 2003) (CAN in Automation CANopen) (CAN in Automation 2002 CANopen Application Layer and Communication Profile DS301) Indexområde Beskrivning 0000h Reserverad 0001h 0FFFh Datatyper 1000h 1FFFh Kommunikationsposter 2000h 5FFFh Tillverkarspecifik 6000h 9FFFh Enhetsprofilparametrar A000h FFFFh Reserverad Figur 15 Objektlistans struktur Sektionen i indexområdet 0001h-0FFFh används för att definiera olika datatyper. Det finns två olika klasser av datatyper, standard och komplex. Standard innehåller definitioner för de vanliga datatyperna, såsom boolean, integer, sträng m.m. De komplexa datatyperna består av en eller flera ihopsatta standard-datatyper. Datatyperna definieras också olika beroende på om de är gemensamma för alla CANopen-enheter eller om de är specifika för en viss CANopen-enhet. (Pfeiffer, Ayre & Keydel, 2003) (CAN in Automation CANopen) Nästa sektion i indexområdet 1000h-1FFFh innehåller kommunikationsparametrar som beskriver det mesta om hur kommunikationen sker hos noden. Här finns information om hur kommunikation ska ske med SDO, PDO, Network Management samt Special Object. Förutom detta så finns övrig information om enheten och PDO mappningen till den tillverkarspecifika sektionen här. (Pfeiffer, Ayre & Keydel, 2003) (CAN in Automation CANopen) 27

38 Den tillverkarspecifika sektionen i indexområdet 2000h-5FFFh används av applikationsdelen framförallt för processignaler. Med hjälp av mappning kan processignalerna hanteras med PDO. (Pfeiffer, Ayre & Keydel, 2003) I nästa sektion i indexområdet 6000h-9FFFh definieras bland annat variablerna för de processignaler en enhet använder, men även dess standardkonfiguration och kommunikationsinställningar. (Pfeiffer, Ayre & Keydel, 2003) Objektlistans objekt adresseras som sagt med ett 16-bit index och ett 8-bit delindex. Konceptet bygger på att objektlistans poster först adresseras med 16-bit index, där posten kan innehålla en enkel variabel, ett register eller en tabell. När det handlar om register eller tabell, så används 8-bit delindex för att komma åt de enskilda variablerna i tabellen. Överst i tabellen anges antal poster i tabellen. Figur 16 är ett exempel på hur det skulle kunna se ut vid indexet 2001, som tillhör den tillverkarspecifika sektionen, där applikationsprogrammets processignaler lagras. (Pfeiffer, Ayre & Keydel, 2003) (CAN in Automation CANopen) Index Delindex Variabel Datatyp Värde 2001h 0h Antal poster Unsigned h 1h Räknare Unsigned h 2h Temperatur Unsigned h 3h Bränsle Unsigned8 10 Figur 16 Objektlistan index och delindex koncept Adressering I ett CAN-meddelande ingår det en identifierare i varje meddelande. Identifieraren brukar benämnas som COB-ID eller CAN-ID. CANopen använder sig av en 11-bit identifierare, som är uppdelad i två delar; funktionskod och nod-id. De fyra mest signifikanta bitarna är funktionskoden, vilket ger möjlighet till 16 olika funktionstyper, se Figur 17. Det är funktionskoden som definierar vad det är för typ av meddelande. De resterande sju bitarna är nod-id, som används för adressering av noder. Det finns maximalt stöd för 127 enheter på en buss med CANopen och dessa 28

39 adresseras med nod-id medan nod-id 0 adresserar samtliga enheter. (Pfeiffer, Ayre & Keydel, 2003) (CAN in Automation CANopen) Meddelandetyp Funktionskod Binär Resulterande COB-ID/CAN- Kommunikationsparametrar vid index ID NMT SYNC h 1005h, 1006h, 1007h Emergency h FFh 1014, 1015h TIME STAMP h 1012, 1013h PDO1 (tx) h 1FFh 1800h PDO1 (rx) h 27Fh 1400h PDO2 (tx) h 2FFh 1801h PDO2 (rx) h 37Fh 1401h PDO3 (tx) h 3FFh 1802h PDO3 (rx) h 47Fh 1402h PDO4 (tx) h 4FFh 1803h PDO4 (rx) h 57Fh 1403h SDO (tx) h 5FFh 1200h SDO (rx) h 67Fh 1200h NMT Error Control h 77Fh 1016h, 1017h Figur 17 Meddelandetypernas struktur Kommunikationen med CAN baseras på prioritet, där det är identifieraren som avgör hur hög prioritet ett meddelande har. Ju lägre värde på identifieraren desto högre prioritet har meddelandet. Det är därmed först och främst funktionskoden som avgör prioriteten för ett meddelande, eftersom den utgörs av de fyra mest signifikanta bitarna. Skulle däremot två likadana meddelandetyper skickas samtidigt är det nod-id som avgör, där nod-id 0 har högst prioritet och nod-id 127 har lägst. Det finns således två olika prioritetskategorier att använda sig av, en efter meddelandetyp och en efter enhetstyp. (Pfeiffer, Ayre & Keydel, 2003) (CAN in Automation CANopen) 29

40 3.3.4 Kommunikationsmodeller Modellen Producer/Consumer, se Figur 18, fungerar på så sätt att varje enhet på nätverket lyssnar på den sändande enheten och sedan själv bestämmer om den ska ta emot meddelandet eller inte. Det behövs således någon form av accepteringsfilter i enheten. Med denna modell kan man både sända meddelanden enligt push-modellen och begära ett meddelande enligt pull-modellen. (Pfeiffer, Ayre & Keydel, 2003) (CAN in Automation. CANopen) Figur 18 Producer/Consumer-modell (CAN in Automation CANopen) Tekniken för Server/Client-modellen, se Figur 19, är att klienten överför ett meddelande till servern, som sedan svarar klienten med en bekräftelse. Denna modell används mycket vid överföring av stora mängder data, då man kan överföra data man vill sända segment för segment. Modellen inkluderar upp- och nedladdning samt överföringsavbrytning. (Pfeiffer, Ayre & Keydel, 2003) (CAN in Automation CANopen) Figur 19 Server/Client-modell (CAN in Automation CANopen) 30

41 Master/Slave-modellen, se Figur 20, bygger på att endast kommunikation initierad från mastern är tillåten. Det är alltså helt och hållet mastern som sköter kommunikationen och kan både sända data till slaven och begära data från slaven. Slaven måste alltså alltid få en begäran från mastern innan den kan sända. (Pfeiffer, Ayre & Keydel, 2003) (CAN in Automation CANopen) Figur 20 Master/Slave-modell (CAN in Automation CANopen) Service Data Object Protocol, SDO SDO protokollet använder sig av en struktur enligt Server/Client-modellen och gör det möjligt att få tillgång till alla poster i en enhets objektlista. SDO används framförallt för att konfigurera en enhets objektlista. Vid kommunikation med SDO skickas alltid mottagningsbekräftelse, vilket gör att en SDO använder sig av två stycken dataramar med olika identifierare. Den som tillhandahåller objektlistan av enheterna i den upprättade kommunikationen är server och den andra är klient, se Figur 21. (Pfeiffer, Ayre & Keydel, 2003) (CAN in Automation CANopen) Figur 21 SDO-struktur i ett nätverk (CAN in Automation CANopen) 31

42 Med SDO kan data av alla storlekar överföras, men man använder sig av olika metoder beroende på storleken. Om datalängden är högst fyra bytes används en påskyndad överföring med Initiate Down/Upload protokollen genom att dataöverföringen görs samtidigt som initieringen. Om datalängden är mer än fyra bytes måste däremot överföringen göras segment för segment, det vill säga, data delas upp över flera CAN-meddelanden, se Figur 22. Efter att initiering gjorts med det första meddelandet kan de följande meddelandena innehålla sju bytes av användbar data. När sista segmentet överförs indikeras detta genom en slutindikator i meddelandet. Initiativ till en överföring görs alltid av klienten och det är som sagt servern som tillhandahåller objektlistan, dock kan både klient och server avbryta överföringen. En annan metod för överföring av väldigt stora datamängder med SDO är att överföra en sekvens av block. Ett block kan innehålla en sekvens av upp till 127 segment. En fördel med detta är att varje block bara bekräftas en gång. I exemplet nedan visas hur en segmenterad SDO-överföring kan gå till. I initiering sätts e till 0, för att definiera att det är just en segmenterad överföring som ska ske och inte en påskyndad överföring. En växelbit, t, används för att försäkra sig om att ett meddelande inte läses av två gånger. Dessutom sätts slutindikatorn, c, till 1 vid sista överföringen för att definiera ett avslut på överföringen. (Pfeiffer, Ayre & Keydel, 2003) (CAN in Automation CANopen) Figur 22 Segmenterad SDO-överföring (CAN in Automation CANopen) 32

43 Vid alla överföringsmetoder ingår alltid en kommandospecificerare, både för klienten, CCS, och för servern, SCS. Dessa definierar följande: Hämtning/Uppladdning Begäran/Svar eller bekräftan Segmenterad/Block/Påskyndad överföring Antal bytes Slutindikator Växelbit för varje följande segmentmeddelande Vid användandet av SDO för skrivning och läsning i objektlistan används alltid Initiate Down/Upload protokollen, se Figur 23, först oavsett om det handlar om en påskyndad överföring, segmenterad överföring eller blocköverföring. Platsen i objektlistan där data ska hämtas är adresserad med ett 16-bit index och ett 8-bit index. Vid påskyndad överföring placeras data i datafältet i slutet av meddelandet och vid de andra två metoderna används meddelandet enbart till initiering för resten av överföringen. Meddelandet svaras med ett bekräftelsemeddelande. (Pfeiffer, Ayre & Keydel, 2003) (CAN in Automation CANopen) S: Indikerar blockstorlek E: Indikerar påskyndad överföring N: Indikerar antal bytes X: Oanvända bitar CCS: Client Command Specifier SCS: Server Command Specifier Figur 23 Påskyndad SDO-överföring vid uppladdning (CAN in Automation CANopen) 33

44 Vid segmenterad överföring börjar segment av data att överföras mellan klient och server efter att initiering gjorts, se Figur 24. Varje segment bekräftas med ett bekräftelsemeddelande. (Pfeiffer, Ayre & Keydel, 2003) (CAN in Automation CANopen) C: Indikerar sista segmentet N: Indikerar antal bytes T: Växelbit X: Oanvända bitar CCS: Client Command Specifier SCS: Server Command Specifier Figur 24 Segmenterad SDO-överföring vid uppladdning (CAN in Automation CANopen) Meddelandeparametrar för SDO definieras vid index 22h i objektlistan, se Figur 25, som används för att ange vilket COB-ID en klient-till-server-kommunikation har och vilket COB-ID en server-till-klient-kommunikation har samt nod-id. SDO beskrivs sedan med hjälp av de definierade meddelandeparameterna med start vid 1200h för SDO-server och vid 1280h för klienten, enligt Figur 26. Det finns kapacitet för upp till 256 stycken SDO-kommunikationskanaler i ett enda CANopen-nätverk. (Pfeiffer, Ayre & Keydel, 2003) (CAN in Automation CANopen) Figur 25 Definition av SDO-parametrar (CAN in Automation CANopen) 34

45 Figur 26 Objektlistans struktur med avseende på SDO (CAN in Automation CANopen) Process Data Object Protocol, PDO CANopen har definierat PDO, som är ett mycket snabbare sätt att komma åt processignalerna än att använda sig av SDO. Kommunikation med PDO tillämpas enligt Producer/Consumer modellen, där processdata kan skickas från en enhet som agerar producent till en eller flera andra enheter som agerar konsument, enligt Figur 27. Man skiljer mellan skrivning av en PDO och läsning av en PDO, där Transmit PDO, TPDO, används för skrivning och Receive PDO, RPDO, används för läsning. Det är producenten som skickar en TPDO med en specifik identifierare, vilken matchar identifieraren för en RPDO av en eller flera konsumenter. En PDOs datafält kan som mest innehålla åtta bytes av processdata. (Pfeiffer, Ayre & Keydel, 2003) (CAN in Automation CANopen) Figur 27 PDO struktur (CAN in Automation CANopen) 35

46 I Objektlistan motsvaras en PDO av ett antal poster, vilka avgör beteende och sändningsteknik samt ger gränssnittet till applikationsprogrammets processignaler. Det finns två typer av parametrar för en PDO. Kommunikationsparametrarna beskriver beteendet för en PDO. De definierar vilket COB-ID som används, hur triggning sker och andra sändningsvillkor för en specifik PDO. Kommunikationsparametrarna definieras i index 20h i objektlistan, se Figur 28. Mappningsparametrarna definierar vilka av objektslistans poster, det vill säga, poster där applikationsprogrammets processignaler lagras, som ska ingå i en specifik PDO. Mappningsparametrarna definieras i index 21h i objektlistan, se Figur 29. Det går maximalt att mappa 64 objekt. (Pfeiffer, Ayre & Keydel, 2003) (CAN in Automation CANopen) Index Delindex Variabel Datatyp 0020h 0h Antal poster Unsigned8 0020h 1h COB-ID Unsigned h 2h Överföringstyp Unsigned8 0020h 3h Fördröjningstid Unsigned h 4h Reserverad Unsigned8 0020h 5h Händelsetimer Unsigned16 Figur 28 Definition av kommunikationsparametrar Index Delindex Variabel Datatyp 0021h 0h Antal poster Unsigned8 0021h 1h 1:a objektet Unsigned h 2h 2:a objektet Unsigned h 3h 3:e objektet Unsigned h 0021h 40h 64:e objektet Unsigned32 Figur 29 Definition av mappningsparametrar Varje objekt mappas med hjälp av en 32-bit variabel, där både adresseringen till korrekt plats i objektlistan, i form av ett 16-bit index och ett 8-bit delindex, och längden på objektet placeras, enligt Figur 30. (Pfeiffer, Ayre & Keydel, 2003) (CAN in Automation CANopen) 36

47 bit Index 8-bit Delindex Längd Figur 30 Mappningsstruktur För TPDO beskrivs beteendet och sändningstekniken med start vid 1800h och mappningen med start vid 1A00h. RPDO beskrivs på motsvarande sätt, men med beteendet och sändningstekniken med start vid 1400h och mappningen med start vid 1600h. I ett enda CANopen nätverk kan 512 TPDO och 512 RPDO användas, se Figur 31. (Pfeiffer, Ayre & Keydel, 2003) (CAN in Automation. CANopen) Figur 31 Objektlistans struktur med avseende på PDO (CAN in Automation CANopen) Kommunikationen för en PDO har tre olika utlösningsmetoder, se Figur 32. Den första utlösningsmetoden är att en applikationsspecifik händelse inträffar, som är specificerad i enhetsprofilen eller att en timer styr utlösningen. Den andra utlösningsmetoden är att en begäran av en PDO skickas från en annan enhet. Den tredje utlösningsmetoden är att överföringen utlöses av en mottagen SYNC-signal. Man skiljer på asynkron och synkron överföring, där synkron överföring innebär att en PDO enbart kan bli triggad av SYNC-signalen. En synkron överföring har också högre prioritet än en asynkron överföring. De två första alternativen är asynkrona, men de kan även kombineras med SYNC-signal, så att överföringen sker synkront. (Pfeiffer, Ayre & Keydel, 2003) (CAN in Automation CANopen) 37

48 Figur 32 Olika överföringsmetoder (CAN in Automation CANopen) En synkron överföring kan i sin tur delas in i periodisk och operiodisk synkron överföring. En periodisk synkron överföring innebär att en PDO utlöses regelbundet varje gång ett bestämt antal, mellan 1 upp till 240, SYNC-signaler mottagits. En operiodisk synkron överföring innebär att en PDO utlöses av att en SYNC-signal mottagits ihop med antingen en begäran från en annan enhet eller att en applikationsspecifik händelse inträffar. (Pfeiffer, Ayre & Keydel, 2003) (CAN in Automation CANopen) Överföringstypen av en PDO definieras med en kommunikationsparameter och genom att ange olika värden till parametern kan man utnyttja olika utlösningsmetoder, se Figur 33. (Pfeiffer, Ayre & Keydel, 2003) (CAN in Automation CANopen) Överföringstyp Synkron Begäran Händelse Beskrivning 0 X X Synkron, Operiodisk O Synkron, Periodisk Reserverade 252 X X Synkron, efter begäran 253 O Asynkron, efter begäran 254 O O Asynkron, specifik manufaktur händelse 255 O O Asynkron, specifk enhetsprofil händelse X = Båda måste inträffa O = En eller båda måste inträffa Figur 33 Hur olika överföringstyper sätts 38

49 För att förhindra att en PDO med högre prioritet blockar PDOs med lägre prioritet, genom att ockupera bussen hela tiden, kan en PDO tilldelas en fördröjningstid. Fördröjningstiden är den minsta tid som måste passera mellan två överföringar av en och samma PDO. Som man kan se i Figur 34 har PDO_2 och PDO_3 en lägre prioritet än PDO_1, men fördröjningstiden för PDO_1 gör att PDO_2 och PDO_3 kan få tillträde till bussen och sända. (Pfeiffer, Ayre & Keydel, 2003) (CAN in Automation CANopen) Figur 34 Överföring av PDO med fördröjningstid (CAN in Automation CANopen) Mappningen för en PDO görs som sagt med mappningsparametrar som definierar vad en specifik PDO ska innehålla för applikationsobjekt. I Figur 35 ses ett exempel på hur en PDO mappning kan se ut. Applikationsobjekten är placerade vid olika poster i objektlistan och dessa poster mappas till PDO_1 via mappningsparametrar, så att PDO_1 vet var dessa applikationsobjekt finns. (Pfeiffer, Ayre & Keydel, 2003) (CAN in Automation CANopen) Figur 35 Mappningsexempel för PDO (CAN in Automation CANopen) 39

50 3.3.7 Network Management Protocol, NMT NMT-protokollet fungerar enligt Master/Slave modellen, där en enhet i nätverket fungerar som en NMT-master medan de andra enheterna är NMT-slavar, enligt Figur 36. NMT-protokollet bidrar med flera olika funktioner, däribland initiering och styrning av NMT-slavar och nodövervakning. NMT-meddelanden är de meddelanden som har allra högst prioritet, då identifieraren är 0. (Pfeiffer, Ayre & Keydel, 2003) (CAN in Automation CANopen) Figur 36 NMT-struktur (CAN in Automation CANopen) Med NMT använder man sig av en tillståndsmaskin, se Figur 37 och det är masterenheten som styr slavenheterna mellan de olika tillstånden. Tillståndsmaskinen består av fyra tillstånd; initiering, före driftläge, driftläge och stoppad, där kommunikationen sker med fem olika NMT-kommandon för att styra en enhet till olika tillstånd. Vid strömpåslag initieras NMT-slavenheten automatiskt och går vidare till tillståndet före driftläge. I det här tillståndet kan enheten konfigureras med hjälp av SDO, svara på nodövervakning och hantera funktionen för sina interna applikationssignaler. En NMT-master kan sätta enheten till driftläge och i det tillståndet är enheten också tillåten att utföra ytterligare funktioner, som PDOöverföring och sända akuta felmeddelanden. Om en enhet sätts till tillståndet stoppad, så stoppas all kommunikation med SDO, PDO och andra funktioner, däremot hanteras fortfarande de interna applikationssignalerna. (Pfeiffer, Ayre & Keydel, 2003) (CAN in Automation CANopen) 40

51 Figur 37 CANopen tillståndsmaskin (CAN in Automation CANopen Kommunikationen mellan de olika tillstånden sker som sagt med fem olika NMTkommandon. Ett NMT-meddelande, se Figur 38, är uppdelat i två delar, där den första delen är på en byte och det är här NMT-kommandot placeras genom att olika värden anges för olika kommandon enligt: Starta enhet/sätt till driftläge = 1 Stoppa enhet/sätt till stoppad = 2 Sätt till före driftläge = 128 Återställ enhet/sätt till initiering = 129 Återställ kommunikation/sätt till initiering = 130 Den andra delen är också på en byte och här definieras nod-id för meddelandets destination. Man kan antingen ange nod-id för att välja en specifik nod eller 0 för att välja alla noder. (Pfeiffer, Ayre & Keydel, 2003) (CAN in Automation CANopen) Figur 38 NMT meddelandestruktur (CAN in Automation CANopen) 41

52 För att hålla koll på status för alla enheter finns det två protokoll, Node Guardingprotokollet och Heartbeat-protokollet. Node Guarding-protokollet fungerar som sådant att NMT-mastern regelbundet hämtar vilket tillstånd alla NMT-slavarna befinner sig i genom att skicka en begäran som svaras av slavarna. Dessa tillstånd jämförs sedan med tillstånd som registrerats i en nätverksdatabas för att säkerställa att alla enheter fungerar korrekt. Hearbeat-protokollet fungerar genom att NMT-slavarna periodiskt skickar ett hjärtslagsmeddelande med vilket tillstånd de befinner sig i till NMT-mastern. Periodtiden mellan två, på varandra följande, hjärtslag kan definieras och om inte NMT-mastern erhåller ett hjärtslags-meddelande inom denna tid signaleras ett fel. Man använder sig bara av en av dessa metoder och det är Heartbeatprotokollet som är rekommenderat. (Pfeiffer, Ayre & Keydel, 2003) (CAN in Automation CANopen) Special Object Protocol Det finns flera mindre protokoll, som tillhör Special Object protokollet och dessa är Synchronization Object (SYNC) protokollet, Time Stamp Object (TIME) protokollet och Emergency Object (EMCY) protokollet. (Pfeiffer, Ayre & Keydel, 2003) (CAN in Automation CANopen) SYNC-protokollet fungerar enligt Producer/Consumer modellen, där en enhet agerar producent och skickar en SYNC-signal till en eller flera andra enheter som agerar konsumenter, enligt Figur 39. Så fort SYNC-signalen tagits emot av en konsument börjar den utföra alla dess synkrona arbetsuppgifter. (Pfeiffer, Ayre & Keydel, 2003) (CAN in Automation CANopen) Figur 39 SYNC-signalens gång i nätverket (CAN in Automation CANopen) 42

53 SYNC-signalen ska ha snabb tillgång till bussen, så därför har den en mycket hög prioritet i form av en låg identifierare. I de allra flesta fall med CANopen har identifieraren värdet 128 eller 80h. Ingen form av data transporteras med SYNC signalen. SYNC signalens identifierare definieras vid index 1005h. (Pfeiffer, Ayre & Keydel, 2003) (CAN in Automation CANopen) En synkron överföring av en PDO innebär att överföringen är anpassad i förhållande till överföringen av SYNC-signalen. SYNC-signalen har ett givet tidsfönster, se Figur 40, som den synkrona PDO-överföringen sänds inom. Vid index 1006h definieras SYNC-signalens tidsfönster och vid index 1007h definieras tidsperioden mellan två följande SYNC-signaler. (Pfeiffer, Ayre & Keydel, 2003) (CAN in Automation CANopen) Figur 40 SYNC-signalens tidsfönster och period (CAN in Automation CANopen) TIME-protokollet fungerar också enligt Producer/Consumer-modellen med en sändande enhet som producent och minst en mottagande enhet som konsument, enligt Figur 41. Identifieraren för denna typ av meddelande är 256 eller 100h och är definierad vid index 1012h. Ofta representerar ett sådant meddelande en tid i millisekunder efter midnatt och antalet dagar sedan 1 januari 1984 och detta ger en datalängd på 6 bytes. En del nätverk med tidskritiska applikationer kräver mycket exakt synkronisering. Att synkronisera de lokala klockorna med en noggrannhet på mikrosekunden kan då vara nödvändigt för att justera den oundvikliga avdriften av de lokala klockorna. Det finns ett högupplöst synkroniseringsprotokoll som man kan tillämpa för att åstadkomma detta. Vid index 1013h definieras en 32-bitars variabel, som har en upplösning på 1 mikrosekund, som används som tidräknare. (Pfeiffer, Ayre & Keydel, 2003) (CAN in Automation CANopen) 43

54 Figur 41 Time Stamp-struktur (CAN in Automation CANopen) Även EMCY-protokollet fungerar enligt Producer/Consumer-modellen och utlöser ett felmeddelande om en enhet upptäcker ett allvarligt fel internt, se Figur 42. Detta felmeddelande skickas med hög prioritet till andra enheter på nätverket och det skickas bara en gång per händelse. (Pfeiffer, Ayre & Keydel, 2003) (CAN in Automation CANopen) Figur 42 Felmeddelandens gång i ett nätverk (CAN in Automation CANopen) Ett felmeddelande har en identifierare mellan 129 till 255 beroende på vad den sändande enheten har för nod-id. Ett felmeddelande innehåller 8 bytes, som är uppdelade i tre delar, enligt Figur 43. Den första delen är på 2 bytes och beskriver detaljerat vad det är för fel som inträffat genom att det finns fördefinierade koder för olika typ av fel, enligt Figur 44. Den andra delen är på 1 byte och är ett register där felen dokumenteras och lagras tills de är lösta, så denna delen beskriver inte bara det nyss inträffade felet utan även om det är nått annat typ av fel kvar inom enheten. Detta görs också genom att det finns fördefinierade koder för olika typ av fel, dock inte lika detaljerat. (Pfeiffer, Ayre & Keydel, 2003) (CAN in Automation CANopen) 44

55 Figur 43 Felmeddelandets struktur (CAN in Automation CANopen) Figur 44 Fördefinierade akuta felkoder (CAN in Automation CANopen) 45

56 3.4 Ethernet Ethernet är en teknologi för lokala nätverk, Local Area Network, LAN och introducerades av DIX-trion (Digital Equipment Corporation, Intel och Xerox) år Termen Ethernet hänvisar idag till en familj av nära relaterade protokoll som karakteriseras av det medium som används och den datahastighet som uppnås. De tidiga versionerna, version 1 & 2 Ethernet används fortfarande men många nya system nyttjar IEEE standarden från (Spencer, 2012) Ethernet tillhandahåller tjänster som täcks av OSI-modellens två lägsta lager, det fysiska lagret och datalänklagret. Signaler skickas med Manchesterkodning vilken bland annat har fördelen att signalen innehåller klockningsdata vilket medför att mottagaren kan synkronisera sin klocka och avgöra var en bit börjar och en annan slutar. Ett Ethernet nätverk har oftast en buss- eller stjärntopologi. Den förstnämnda utnyttjar samma princip som CAN, med ett gemensamt medium som alla enheter kopplas in på. Med en stjärntopologi är alla enheter inkopplade via en individuell kabel till en central enhet såsom en switch eller brygga. (Wildpackets Inc.) Enheter på ett Ethernet nätverk med busstopologi, som arbetar i halv-duplex läge, är liksom de på CAN sammankopplade via ett gemensamt medium vilket gör att någon form av Media Access Control, MAC, måste implementeras. Här används åtkomstmetoden Carrier-Sense Multiple Access with Collision Detection, CSMA/CD vilken beskrivits tidigare, se kapitel (Wildpackets Inc.) Alla enheter på nätverket har en unik fysisk identitet för kommunikation, en så kallad MAC-adress. Den är 48 bitar lång och används både för att specificera avsändare och mottagare av ett meddelande. Liksom CAN, har alla enheter tillgång till den data som skickas på nätverket men istället för att använda identifierare används direkt adressering. Det första en enhet gör när ett meddelande läggs ut på mediumet är att analysera adressfältet, stämmer destinationsadressen ej överens med enhetens egen adress så avslutas läsningen. Ett undantag är om destinations- och avsändaradressen är lika, då är meddelandet riktat till alla enheter på nätverket. (Wildpackets Inc.) 46

57 Figur 45 Ethernet Meddelanderam (Singh, 2010) Ethernets versionsmångfald har lett till att flera olika meddelandeformat uppstått, men ett generellt meddelande består av delarna illustrerat i Figur 45. Alla meddelanden startar med en ingress på 64 bitar som består både av skiftande 1:or och 0:or som mottagaren använder för att synkronisera med den inkommande signalen och ett 8-bitars SOF fält. Därefter följer en 48-bitars destinationsadress, en 48-bitars avsändaradress och en 16-bitars typindikerare för identifiering av vilket protokoll som används. Datafältet innehåller meddelandet och är i storleksordningen 46 till 1500 bytes. Sist är ett 32-bitars CRC fält. (Wildpackets Inc.) All kommunikation sänds på nätverket i form av sådana meddelanderamar eller paket. Dessa innehåller alltså den data som ska skickas, tillsammans med information om bland annat mottagaren och avsändaren. Paket konstrueras genom att den applikation som genererar data skickar denna till en protokollstack som sedan delar upp datan i mindre bitar och lägger till ett omslag (eng. Wrapper) till varje databit. Omslaget gör att databitarna kan assembleras i korrekt följd av mottagande applikation. Protokollstacken skickar därefter vidare paketen, som nu har omslag, till hårdvaruenheten som i sin tur lägger till ytterliggare omslag för att leda meddelandet till dess rätta destination på nätverket. I mottagaränden görs samma steg fast i reverserad ordning. (Wildpackets Inc.) 47

58 3.5 CANfestival CANfestival är ett gratis CANopen-ramverk och tillhandahåller en plattformsoberoende CANopen-stack för implementation av master- eller slavnoder, se Figur 46 för en detaljerad översikt. Det är ett pågående projekt som startades 2001 av Edouard Tisserant men har sedan dess växt och drivs nu även av medlemarna Francis Dupin och Laurent Bessard. (CANfestival, 2001) CANfestival överensstämmer med CANopen DS301. V.4.02 och innehåller förutom funktioner såsom SDO, PDO och NMT även ett verktyg för att generera objektlistor för noder. Det är rekommenderat att köra CANfestival under en Linux-distribution men det går även att köra under Windows med Cygwin installerat. Beroende på vilket operativsystem biblioteket installeras på så varierar stödet för olika CAN-gränssnitt. För tillverkare såsom IXXAT eller Kvazer erbjuds endast stöd för Windows, medan PEAK Systems produkter stöds av de vanligaste Linux/Windows distributionerna. Med CANfestival går det även att skapa virtuella gränssnitt vilket kan vara tacksamt vid testning. (CANfestival, 2001) Figur 46 CANfestival-implementation(CANfestival, 2001) 48

59 CANfestival innehåller flera exempelprogram vilka kan vara mycket användbara ur ett inlärningsperspektiv. Biblioteket innehåller bland annat program för uppstart och test av master-slave konfiguration och virtuella gränssnitt. (CANfestival, 2001) 49

60 4 Genomförande Projektet kan delas in i ett antal olika moment med avseende på utförandet. Det första momentet bestod, förutom att läsa på om CAN och CANopen, av att undersöka utbudet på marknaden efter lämplig hård- och mjukvara. Gemensamt för dessa var att alla skulle ha stöd eller vara uppbyggda för CANopen, då Saabs system ska använda sig av denna standard och att de i största möjliga mån skulle uppnå de tidigare specificerade kraven och önskemålen. Det fastslogs att det skulle vara både enklare och bättre att utgå ifrån mer färdigutvecklade produkter och program istället för att utveckla helt nya från grunden. En hårdvaruenhet att upprätta som master i en CANopen miljö behövdes. För att uppfylla kraven på hårdvaran, bland annat krav på uppstartstider, pekades det ganska snart på en ARM processor med MMU-stöd som levereras med någon form av Linux OS-distribution, med passande GNU toolchain. Det behövdes även en CAN-till-USB-adapter för att möjliggöra kommunikation mellan mastern och en simulerad CANopen miljö bestående av en eller flera slavar på en dator. Krav för denna adapter var att den skulle vara kompatibel med valet av mjukvara. Utöver dessa hårdvaruenheter behövdes en passande mjukvara att använda för utveckling av hela CANopen miljön, det vill säga både master- och slavsidan. Krav för denna mjukvara var att den antingen skulle möjliggöra enkel utveckling av egna master- och slavapplikationer eller fungera som en färdig simulerad CANopen miljö, framförallt med avseende på slavsidan. Nästa moment bestod i att utveckla CANopen miljön. Implementationsmässigt delas detta upp i två olika delar, en masterdel och en slavdel. Mastern på hårdvaruenheten skulle kunna styra och hantera övervakning av slaven, men även kunna begära och tolka slavens status. De sista momenten bestod av integrering och programkörning av systemet, det vill säga CANopen-miljön med en master på hårdvaruenheten och en slav på en bärbar dator samt med GPIO signaler. Integrering var något som gjordes för att kunna upprätta önskad kommunikation i systemet medan programkörning av systemet gjordes för att kunna korrigera eventuella fel i master- och slavdelen. 50

61 4.1 Undersökning och val av hårdvara och mjukvara Vid sökandet efter kvalificerad hård- och mjukvara fanns det som sagt många krav och önskemål att ta hänsyn till. I följande kapitel beskrivs hård- och mjukvarulösningarna samt varför de valdes Hårdvara Efter en tids efterforskning hittades till slut några tänkbara alternativ av typerna utvecklingskort och framförallt industriella boxdatorer. De utvecklingskort som hittades hade i sitt basutförande endast ett fåtal av de önskade gränssnitten och det krävdes således ytterligare tillbehör för att uppfylla kravet på interoperabilitet. Därför prioriterades andra alternativ, såsom industriella boxdatorer. Dessa boxdatorer var i regel bättre i avseende på uppfyllnad av kraven, men många visade sig sakna stöd för fler än ett CAN- och Ethernetgränssnitt. Det alternativet som anammades var en Artila Matrix 522, se Figur 47, som är en industriell Linux-box-dator med ARM-processor. Anledningen till detta var att den uppfyllde många av de krav och önskemål vi hade för en sådan enhet, tack vare följande egenskaper och funktioner: ARM9 Processor, 400 MHz med MMU Två CAN 2.0A/2.0B Två 10/100 Mbps Ethernet 9 40 VDC spänningsmatning Färdiginstallerat Linux OS GNU toolchain tillgänglig Support SocketCAN and CANopen Library Stödet av CANopen var nödvändigt, inte minst för att projektet baseras på CANopen, men även det extra stödet för SocketCAN var välkommet. SocketCAN är en uppsättning drivrutiner och en protokollstack som möjliggör simultan tillgång till en CAN-enhet från flera applikationer. Vidare tillåts en applikation prata med flera CAN-nätverk samtidigt. 51

62 De två CAN-gränssnitten gjorde att kravet för interoperabilitet uppfylldes, genom att det ena CAN-gränssnittet kan användas för styrning och övervakning av systemet och det andra CAN-gränssnittet kan användas för systemets transportplattform, till exempel en lastbil. De två Ethernet-gränssnitten gjorde det möjligt för kommunikation med UCP och styrning av datorer/datorkort samtidigt, så det kravet uppfylldes också. Det fanns krav på att stöd skulle finnas för 28 V spänningsmatning och då den har stöd för 9 40 VDC spänningsmatning uppfylldes även detta krav. I övrigt är den lätthanterad och enkel att komma igång med, då den har ett färdiginstallerat OS och en tillgänglig passande toolchain. Tolerans mot yttre faktorer, såsom temperatur och vibrationer, och de övriga kraven, såsom kort startup-tid och hantering av diskreta signaler, var några vi inte tog full hänsyn till, men det är fullt möjligt att dessa krav kan uppfyllas. Den hade ytterligare användbara egenskaper och funktioner, såsom två seriella gränssnitt, två USB-gränssnitt, 21 programmerbara digitala in- och utsignaler samt låg strömförbrukning. En annan fördel med Artila Matrix 522 gentemot många andra alternativ, såsom utvecklingskort, var det faktum att den är inkapslad. För mer information om Artila Matrix 522, se kapitel 8.1. Figur 47 Artila Matrix 522 (Artila 2013) 52

63 Vid sökandet av en USB-till-CAN-adapter ställdes kravet att den skulle ha bästa möjliga kompabilitet med CANfestival, då vi valde att använda denna mjukvara, se kapitel Det fanns flera adaptrar som hade stöd för CANfestival, men många av dessa var plattformsberoende, därför valde vi att köpa in och använda oss av en från PEAK Systems, PEAK PCAN-USB, se Figur 48, då denna hade stöd för de vanligaste Linux/Windows-distributionerna. För mer information om PEAK PCAN-USB, se kapitel 8.2. Figur 48 PEAK PCAN-USB (PEAK SYSTEMS 2013) Mjukvara Vid sökningen efter en lämplig mjukvara var vi först ute efter en som tillhandahöll en färdig simulerad CANopen miljö med avseende på slavsidan och att därefter själva enbart skapa masterdelen till denna simulerade CANopen miljö. En sådan mjukvara visade sig vara svår att få tag på till ett rimligt pris. Vi övergav därför denna idé och började istället undersöka om en färdig CANopen-protokollstack kunde vara ett alternativ, där man med dess hjälp kunde skapa egna master- och slavapplikationer. Det visade sig att det absolut var en möjlighet och då vi sökte efter ett alternativ av typen öppen källkod upptäckte vi CANfestival. Vi beslutade att vi skulle använda oss av denna protokollstack på båda enheterna, det vill säga både för master på den inköpta hårdvaruenheten och för slav på en bärbar dator. Det ingick flera olika testprogram i CANfestival och de visade sig vara mycket användbara som grund för skapandet av master- och slavapplikationer. 53

64 4.2 Programdesign När det kom till utvecklingen av master- och slavapplikationer skulle mastern på hårdvaruenheten kunna styra och hantera övervakning av slaven, men även begära och tolka slavens status. För att lyckas med det har CANopen olika kommunikationsprotokoll som används för olika ändamål och kommunikationsvägen för dessa ges av Figur 49 nedan. All kommunikation mellan master och slav initieras av mastern med undantag för felmeddelanden. Figur 49 Master/Slave-kommunikation (ICPDAS 2013) Det är masterns uppgift att konfigurera slaven, framförallt med avseende på de olika kommunikationsprotokollens funktion. Det görs med SDO-kommunikation genom att mastern skriver in information på korrekt plats i slavens objektlista. Med PDO-kommunikation kan mastern begära och få information om slavens status. Detta genom att skicka en PDO-begäran till slaven om att få ett eller flera aktuella statusvärden, som lagras i slavens objektlista. Slaven tillhandahåller sedan mastern dessa statusvärden genom att skicka dem till mastern, som i sin tur lagrar dem i sin objektlista. 54

65 Mastern skall, med ett visst tidsintervall, kontinuerligt skicka synkroniseringssignaler med SYNC-kommunikation, detta kan bland annat användas vid PDOkommunikation för att synkronisera kommunikationsöverföringen. Mastern skall konstant övervaka slavenheten, så att mastern vet att den fungerar korrekt, detta görs med NMT Err Control och vanligast är att använda sig av en hjärtslagsmetod, där slaven skickar vilket tillstånd den befinner sig i till mastern. Detta är något som görs periodvis, och periodtiden för detta konfigureras av mastern. EMCY-kommunikation används när ett fel har inträffat på enheten och det är bara slaven som skall sända sådana typer av felmeddeladen, där mastern skall stå som mottagare. Givetvis kan fel inträffa även på masterenheten, men då behövs och skall inte det rapporteras vidare till andra enheter. Time Stamp-kommunikation har vår master inget behov av, så det behövs inte implementeras. Mastern skall kunna styra slaven mellan olika tillstånd i CANopens tillståndsmaskin, se Figur 51, med NMT-kommunikation, där varje tillstånd har specifika arbetsuppgifter och varierande begränsningar vad gäller användandet av olika kommunikationsprotokoll enligt Figur 50. Mastern skall också använda sig av CANopens tillståndsmaskin, men till skillnad från slaven skall mastern hantera övergångar på egen hand. Figur 50 Kommunikationsbegränsningar (Pfeiffer, Ayre & Keydel, 2003) Figur 51 Tillståndsmaskin (Pfeiffer, Ayre & Keydel, 2003) 55

66 Till CANfestival ingick som sagt flera olika testprogram, varav ett innehöll både en master och en slav. Vi valde att nyttja detta testprogram för att skapa både vår master och vår slav genom att vi modifierade programmet. Detta program gick att köra med både master och slav aktiva eller med enbart en av dem. Det var mycket användbart för oss, då vi kunde modifiera två testprogram, där masterdelen modifierades på den ena och slavdelen på den andra. Således kördes programmen, den ena på hårdvaruenheten och den andra på den bärbara datorn, mot varandra. Det som utgör själva kärnan i en nod är objektlistan. Det är i objektlistan som all information om noden finns, till exempel hur kommunikation med de olika kommunikationsprofilerna ska fungera och lagring av processignaler. Med CANfestival ingick ett program för att kunna skapa nya objektlistor och ändra tidigare gjorda objektlistor. Med detta program modifierade vi vissa delar av testprogrammens objektlistor till att passa våra önskemål för både master- och slavnoden Programdesign, Master Objektlistan för mastern modifierades genom att alla RPDO, som skulle användas för läsning av slavens statusvärden, mappades till korrekta platser i masterns objektlista, så att statusvärdena kunde lagras där. Dessa platser och variabler för masterprogrammets processignaler definierades på ett sätt som gav önskvärd funktion. Vid start av själva masterprogrammet initieras mastern genom att bland annat sätta dess nod-id till 1. Nu initierar mastern också hårdvaruenhetens General Purpose Input/Output, GPIO, som ska användas för att begära de olika statusvärdena samt tända en grön LED som indikerar att slavenheten fungerar som den ska. Det görs genom att alla 21 pinnar definieras som insignaler förutom pin 12, som definieras som utsignal. Mastern konfigurerar sina fyra RPDO för att matcha slavens fyra TPDO, så att kommunikationen ska fungera mellan dessa, genom att skriva i sin egen objektlista. Efter detta går mastern vidare till tillståndet före driftläge. 56

67 När slaven har initierats korrekt och befinner sig i tillståndet före driftläge precis som mastern, konfigurerar mastern slavens överföringsteknik, när det gäller alla fyra TPDO, till att enbart sändas vid mottagande av PDO-begäran från mastern. Denna konfigurering görs genom SDO och på så sätt ändras informationen i nodens objektlista. Mastern konfigurerar också periodtiden, för sändning av slavens hjärtslag, till 1000 ms. Därefter går mastern vidare till driftläge och begär att slaven ska göra detsamma genom att skicka ett NMT-meddelande. I detta läge har programmet nått sin fulla potential och det är nu mastern kan börja begära statusvärden från slaven. Mastern skickar kontinuerligt synkroniseringssignaler med ett tidsintervall av en halv sekund mellan två på varandra följande synkroniseringssignaler. Dessa kan användas för att trigga och synkronisera slavens PDO-överföring, en funktion vi inte använder då vi istället utnyttjar begäran för att trigga slavens PDO överföring. Vid varje skickad synkroniseringssignal granskar mastern de fyra första GPIO-signalerna. Dessa pinnar används för att begära olika statusvärden från slaven genom att varje pinne är matchad med en RPDO. Så om någon av dessa GPIO-pinnar är höga ska mastern skicka en PDO-begäran för den eller de RPDO som motsvaras av den eller de höga GPIO-pinnarna. Mastern kan även ta emot felmeddelanden från slaven. Tas ett sådant emot så sätts GPIO pin 13 till hög, vilket släcker den gröna LED-lampan och ett fel har indikerats. Åtgärdas felet så meddelas mastern om det och lampan tänds igen Programdesign, Slav Objektlistan för slaven modifierades på liknande sätt som för mastern genom att alla TPDO, som skulle användas för överföring av slavens statusvärden, mappades till korrekt platser i slavens objektlista, så att värden hämtas därifrån. Dessa platser och variabler för slavprogrammets processignaler definierades på ett önskvärt sätt. Vid start av slavprogrammet hämtas en sökväg till en fil som slaven ska hämta sina statusvärden ifrån. Slaven initieras genom att bland annat sätta sitt nod-id till 2. Efter det går den vidare till tillståndet före driftläge. 57

68 När slaven har initierats korrekt och befinner sig i tillståndet före driftläge konfigureras den av mastern. Slaven går sedan vidare till driftläge när ett NMTmeddelande med en sådan begäran mottagits från mastern. I driftläge kan slaven ta emot begäran av statusvärden, i form av PDO, från mastern. Mastern svarar med en TPDO, som motsvarar den begäran som mottagits, innehållande det aktuella statusvärdet. Slaven mottar också kontinuerligt synkroniseringssignaler från mastern. Vid varje mottagen signal uppdaterar slaven sina statusvärden genom att öppna och läsa av den fil som den tidigare hämtade sökvägen pekar på. Värdena lagras i slavens objektlista. Skulle de överträda gränserna som satts för de individuella värdena skickas ett felmeddelande med tillhörande felkod till mastern. Av felkoden framgår det vad för typ av fel som inträffat. När slaven är i driftsläge hanterar den även två räknare, en som räknar upp och en som räknar ner. 58

69 4.3 Integration av systemet Integration av systemet var något som påbörjades direkt vid leverans av de beställda produkterna och pågick sedan parallellt med utvecklingen av CANopen-miljön. Testprogrammet som ingick med CANfestival kunde man ju som sagt köra med både master och slav aktiva eller enbart en av dem. Vi började därför testningen med att köra programmet på en bärbar Linux-dator med både master och slav aktiva. Detta gjordes genom att vi använde oss av ett bibliotek, tillhörande CANfestival, som gjorde det möjligt att skapa virtuella CAN-gränssnitt och köra programmet via dessa. En likadan testning utfördes på hårdvaruenheten, Artila Matrix 522, för att säkerställa att programmet fungerade även där. Efter att dessa test lyckats var nästa steg att köra programmet via de verkliga CAN-gränssnitten. Vid användning av CAN-gränssnitt är det viktigt att tänka på att de ska vara terminerade på ett korrekt sätt och att baudrate för de använda CAN-gränssnitten matchas. På Artila Matrix 522 var emellertid termineringen inbyggd, men på PEAK PCAN-USB saknades den, så vi terminerade denna ände med 120 Ω. Att inställningen av baudrate stämmer överens är en nödvändighet för att kommunikationen ska fungera och ställdes in till 250 Kbit/s för de båda gränssnitten. Då Artila Matrix 522 har två CAN-gränssnitt valde vi först att testköra programmet mellan dessa två gränssnitt, istället för de två virtuella CAN-gränssnitten. Detta genomfördes med hjälp av ett annat bibliotek, tillhörande CANfestival, som gjorde användningen av SocketCAN möjlig. Enhetens CAN-gränssnitt måste ha stöd för detta, genom att vara korrigerat och installerat som nätverksgränssnitt, något som Artila Matrix var redan från början. Därefter var det dags att upprätta kommunikationen mellan master- och slavenheten via PEAK PCAN-USB genom att köra ett program på varje enhet, med en master på Artila Matrix 522 och en slav på den bärbara Linux-datorn. På Artila Matrix 522 körde vi programmet på samma sätt som vid föregående testning med undantag för att vi inaktiverade slaven. På den bärbara Linux-datorn valde vi också att använda oss av 59

70 det bibliotek, tillhörande CANfestival, som gjorde användningen av SocketCAN möjlig. Vi var även tvungna att korrigera och installera PEAK PCAN-USB som ett nätverksgränssnitt för att SocketCAN skulle stödjas. På den bärbara Linux-datorn körde vi sedan programmet med enbart en slav genom att inaktivera mastern. Det visade sig slutligen att kommunikation mellan de två enheterna fungerade på önskat sätt, vilket gjorde att all fokus nu kunde läggas på att modifiera och bygga vidare på testprogrammen. Naturligtvis fortsatte testningen, men nu med syftet att upptäcka och korrigera eventuella fel som uppstått efter implementering av nya funktioner. 60

71 4.4 Programkörning av systemet Efter mycket modifiering av programmen så fungerade till slut CANopen-miljön på ett önskvärt sätt. Systemet bestod nu av en master på Artila Matrix 522 och en slav på Linux-datorn och kommunikationen gick via PEAK PCAN-USB enligt Figur 52. Dessutom är en GPIO-anslutning, med switchar och en LED, kopplad till Artila Matrix 522. Switcharna används för att begära statusvärden av slaven, medan LEDlampan indikerar om dessa statusvärden är acceptabla eller inte. Figur 52 Översikt av systemet Vid en programkörning av systemet ska flera parametrar anges, dels för masterprogrammet och dels för slavprogrammet, se Figur 53. De är likadana för båda programmen med undantag för att sökvägen till filen som innehåller statusvärdena även ska anges i slavprogrammet. De resterande alternativen som ska anges för båda programmen är sökväg till biblioteket, vilka/vilket gränssnitt slaven och/eller mastern ska använda och baudrate för slaven och/eller mastern. Figur 53 Programval vid körning av slavprogram 61

72 5 Resultat Målsättningen med examensarbetet var att ta fram en prototyp för att kunna genomföra en demonstration och ge förslag till hur kommunikationsgränssnittet kan användas i systemet. Användbar inköpt hård- och mjukvara har identifierats och använts. Den hårdvara som använts köptes in, istället för att en egen konstruktion togs fram och mjukvaran bestod av protokollstackar av typen öppen källkod. Majoriteten av de krav som ställts på enheten är uppfyllda: Kravet på interoperabilitet uppfylls då enheten har mer än två CAN- och Ethernetgränssnitt. Toleransen mot yttre faktorer togs i beaktande vid inköpen och kraven uppfylls till stora delar, dock råder det osäkerhet kring prototypens mottståndskraft mot vibrationer. De övriga kraven rörande spänningsmatning uppfylls och uppstartstid kan troligen uppfyllas. En prototyp av ett CANopen-nätverk med master-slave konfiguration har tagits fram. En lyckad kommunikation mellan olika noder har åstadkommits och prototypens funktionalitet kan demonstreras med de testprogram som utvecklats. Mastern kan via en switchbräda styras till att begära information om status från slavnoden. Slavnodens statusvärden uppdateras från en fil, så det är enkelt att ändra dessa efter behov. De programkörningar som gjorts har visat att systemet fungerar som tänkt och slaven svarar på de anrop/förfrågningar som görs från mastern. Nodövervakning sker och felmeddelanden både skickas och hanteras på korrekt sätt. Sammantaget fungerar prototypen som tänkt och tillhandahåller Saab med en grundläggande plattform för simulering och utveckling. 62

73 6 Slutsats Inom ramen för detta projekt har en prototyp, som visar funktionaliteten hos ett CANopen-nätverk med master-slave konfiguration, tagits fram. Denna prototyp är till hjälp för Saab, som kan använda den till att utvärdera möjligheten att implementera tekniken i markbaserade radarsystem. Enheten tillhandahåller goda förutsättningar till fortsatt utveckling då den grundläggande kommunikationen med CANopen redan är implementerad. En stor del av arbetet bestod av inlärning och att studera CAN och det högre applikationsprotokollet CANopen. Avgränsningar gjordes tidigt i arbetet, bland annat togs beslutet att inte implementera styrningen av datorer/datorkort med IPMI. Även funktionen att kunna styra masterenheten och övervaka resten av CANopen-nätverket från en kontrollpanel via Ethernet valdes att inte implementeras. En alternativ lösning gjordes dock för styrning av masterns statusbegäran till slaven, i form av digitala insignaler som kunde ställas via en switchbräda. En LED som visade slavens status implementerades även. Det visade sig vara ett bra beslut att avvakta med Ethernet, då inköp av komponenter och utveckling av ett CANopen-nätverk tog längre tid än vad som först avsatts till de ändamålen. Mjukvaran som användes bestod av CANfestivals protokollstack, vilken implementerar ett CANopen-ramverk och är av typen öppen källkod. Den hårdvara som representerade CAN-nätverkets master och således systemets UCU var en Artila Matrix 522 industriell Linux boxdator. En CANopenslavnod skapades på en bärbar dator med Linux OS. Kommunikationen dem emellan gick via en PEAK PCAN-USB-adapter. Den färdiga prototypen består alltså av en CANopen-master som med adaptern kan kommunicera med en, på en bärbar dator implementerad, slavnod. Tack vare det faktum att den UCU som valts har mer än ett CAN- och Ethernetgränssnitt bereds goda möjligheter till utveckling av prototypen. Styrning av UCU och datorer/datorkort via Ethernet samt integrering av ytterligare en CANstandard, såsom transportfordonets egen, är ett nästa steg i denna utveckling. 63

74 6.1 Kritisk diskussion Den prototyp som tagits fram beskriver funktionen hos ett CANopen-nätverk med en masternod och en slavnod. Trots att avgränsningar gjordes i arbetets början är resultatet tillfredsställande och förutsättningarna för fortsatt utveckling goda. Det finns dock utrymme för förbättring av de implementerade funktionerna hos prototypen. Det faktum att nätverket endast är uppbyggt av två noder gör att några av fördelarna med CAN och CANopen, såsom arbitrering, inte åskådliggörs. Skälet till detta var tidsbrist, men prototypen hade bättre påvisat dessa fördelar och varit närmare de verkliga systemen om fler implementerats. Då den ursprungliga tanken om att implementera Ethernet lades åt sidan till förmån för utveckling av CAN, saknades ett mer avancerat och tillfredsställande sätt att styra vår master. Den går nu efter en förutbestämd programslinga där den enda riktiga styrning som görs är vid ställandet av de digitala insignalerna via switchbrädan. Vi utnyttjar således inte masterns fulla potential, då vi inte har möjlighet att styra när och hur dess olika kommunikationsprotokoll ska användas. Prototypen uppfyllde med säkerhet de flesta krav som ställts på den. Det krävs dock ytterligare utredning för att helt säkerställa att alla krav uppfyllts. Trots dessa brister har en god grund för fortsatt utveckling skapats och vi är nöjda med resultatet. 64

75 6.2 Fortsatt utveckling De områden som står näst på tur att implementeras är många av de avgränsningar som gjorts tidigare och även vidareutveckling av det befintliga CANopen-nätverket CANopen över EtherCAT? Då steget att bygga prototypen till att inkludera möjligheten att hantera och styra CANopen-nätverket och datorer/datorkort via Ethernet ansågs för stort och tidskrävande lämnades det till möjlig fortsatt utveckling. Ethernet for Control Automation Technology, EtherCAT är en nätverksteknologi som gör att stora delar av CANopens protokollstackar kan återanvändas. Den stödjer alla CANopens enhetsprofiler och utnyttjar PDO, SDO, NMT och objektlista. En möjlig vidareutveckling skulle därför kunna vara att implementera stöd för EtherCAT i den prototyp som utvecklats. Ett annat alternativ skulle vara att helt konfigurera om nätverket till EtherCAT. Visserligen skulle nätverket inte längre vara av typen CANopen men samma funktioner skulle finnas tillgängliga och master/slaveimplementation möjlig. (Beckhoff, 2005) Intelligent Platform Management Interface, IPMI Själva styrningen av datorer/datorkort skulle kunna implementeras med hjälp av IPMI om det uppfyller krav på IA-säkerhet. IPMI kan ses som ett subsystem vilket fungerar helt oberoende av operativsystemet och ger operatörer tillgång till datorer/datorkort även om operativsystemet ej körs. Det kan alltså användas till att få tillgång till datorer/datorkort innan systemets primära mjukvara hunnit starta eller om det helt saknas. Datorn eller kortet behöver inte ens vara påslaget för att IPMI-tjänsten ska fungera, det räcker att enheten har ström och är inkopplad på bussen. 65

76 6.2.3 SAE J1939 Stöd för lastbilsstandarden SAE J1939 kan implementeras på den UCU som tagits fram. Ett oanvänt CAN-gränssnitt finns på enheten men en utredning av möjlig mjukvara skulle behöva göras, då den protokollstack som hittills använts har saknat stöd för denna standard Befintligt CANopen-nätverk Ett område att utveckla, som endast skulle kräva mindre modifiering av aktuella program för att realisera, är att lägga till ytterligare slavnoder i nätverket. Det skulle bland annat möjliggöra bättre evaluering av systemet som helhet. 66

77 7 Referenser Artila (2013). Embedded Networking and Computing < ( ) Beckhoff, Martin (2005). CANopen over EtherCAT < ( ) CANfestival (2001) < ( ) CAN in Automation. CAN history < ( ) CAN in Automation. CANopen < ( ) CAN in Automation (2002). CANopen Application Layer and Communication Profile < CANCANopen%20CD%20V5.1/standard/ds301.pdf> ( ) CAN in Automation. CAN physical layer < ( ) CAN in Automation. CAN protocol < ( ) CAN in Automation. Controller Area Network < ( ) Corrigan, Steve. (2008). Introduction to the Controller Area Network (CAN) < ( ) ICPDAS (2013) CANopen Master Library < ( ) Mannisto, Daniel & Dawson, Mark. (2003). An Overview of Controller Area Network < ( ) 67

78 Microsoft Corp (2002). The OSI Model s Seven Layers < ( ) PEAK SYSTEMS (2013). PCAN-USB < commerce_pi1%5bcatuid%5d=6&tx_commerce_pi1%5bshowuid%5d=16> ( ) Pfeiffer, Olaf, Ayre, Andrew & Keydel, Christian (2003). Embedded Networking with CAN and CANopen, San Clemente, CA : RTC Books RT-Labs AB (2009). CANopen. < ( ) Saab AB (2013). Arthur WLR < _WLR_Weapon_Locating_Radar_System_Saab/Technical_specifications/> ( ) Saab AB (2013). Giraffe AMB Surveillance System < Surveillance/Giraffe-AMB/Technical-specifications/> ( ) Singh, Deep, Akash (2010). What is Ethernet CSMA/CD < ( ) Sony Corp. The Technology behind High-Speed Processing < ( ) Spencer, Will (2012). Ethernet < ( ) Wells, J, Christopher (2001). Industrial Networks Controller Area Network. < ( ) Wikipedia (2013). CANopen < ( ) Wildpackets Inc. Ethernet Packets and Protocols < ( ) 68

79 8 Bilagor 8.1 Appendix A Artila Matrix

80 70