Att utöka noggrannheten i mätsystemet HiMacs

       

Datateknik C, Examensarbete, 15 högskolepoäng 

   

ATT UTÖKA NOGGRANNHETEN 

 

I MÄTSYSTEMET HIMACS

    Johannes Carlsson och Jonatan Hägglund    Dataingenjörsprogrammet, 180 högskolepoäng    Örebro vårterminen 2015                Examinator: Lars Karlsson     

TO INCREASE MEASURING ACCURACY IN THE SYSTEM HIMACS 

                 

Sammanfattning 

Industrin är idag helt beroende av datasystem till olika delar av verksamheten. I takt med att  systemen blir kraftfullare växer möjligheterna för ökad kontroll och precision. Ju fler defekter  och fel som kan upptäckas innan leverans desto nöjdare kunder fås och medför färre onödiga  kostnader vid exempelvis återkallelser. Givetvis är detta önskvärt från industrins sida och  leder till att kraven på datasystemen blir ständigt högre.    Denna rapport avhandlar möjligheterna att höja mätfrekvensen för ett befintligt industriellt  realtidssystem som körs på en PC med Windows som operativsystem och är avsett för  testkörning och mätning av motorer och transmissioner. Begränsningarna som medföljer då  ett icke­realtidsoperativsystem används reds ut och det alternativ som HiMacs använder  utvecklat av Beckhoff Automation beskrivs.    Projektet var utredande och olika lösningsförslag togs fram och vägdes mot varandra för att  komma fram till den mest pålitliga lösningen.      

Abstract

  The industry is now entirely dependent on computer systems in various parts of the  organization. As systems become more powerful the opportunities for increased control and  precision grows. The more defects and faults that can be detected before delivery, more  customer satisfaction is obtained which leads to fewer unnecessary costs connected to, for  example, recalls. Of course, this is desirable from the industry and leads to higher demands  for information systems.     This report discusses the opportunities to increase the measuring frequency of an existing  industrial real­time system running on a PC with Windows as operating system that is  designed for test runs and measurements of engines and transmissions. Limitations that  comes with using a non­real time operating system in a real time industrial application is  cleared up. The option for real time communication that HiMacs uses, developed by  Beckhoff Automation, is also described.    The project was investigative and various proposed solutions were developed and compared  to each other to achieve the most reliable solution.           

Förord

  Vi vill börja med att tacka alla på HiQ­kontoret i Arboga som gett oss ett väldigt gott  bemötande och välkomnat oss som en del av gänget under dessa veckor. Ett speciellt tack till  vår handledare på HiQ, Thomas Tinglöf, som gav oss möjligheten till detta arbete och Anders  Lindén som funnits till hands under projektets gång för frågor och praktiska råd.  Studiebesöket på Volvo CE i Eskilstuna uppskattades och ett tack riktas till Ronny Sandehav  som tog emot och visade oss runt. Slutligen ska Kjell Mårdensjö från universitetet ha ett tack  för sin handledning och hjälp med att ordna fram hårdvara för simulering av “riktig” mätdata.   

Inneh˚

all

1 Inledning 3 1.1 Bakgrund . . . 3 1.1.1 Systembeskrivning . . . 3 1.2 Projekt . . . 6 1.3 Syfte . . . 6 1.4 Krav . . . 6 1.5 Arbetsf¨ordelning . . . 7

2 Metoder och verktyg 8 2.1 Metoder . . . 8

2.2 Verktyg . . . 8

2.3 Ovriga resurser . . . .¨ 9

3 Realtids¨overf¨oring av data 10 3.1 Realtidssystem . . . 10

3.2 TCP/IP och UDP/IP f¨or realtidskommunikation . . . 11

3.3 Ethernet och realtid . . . 11

3.4 Windows och realtid . . . 13

4 Analys av systemet 15 4.1 En f¨orsta provk¨orning . . . 15

4.2 Testprojekt . . . 15

4.2.1 TwinCAT-konfiguration . . . 15

4.2.2 Avgr¨ansning av HiMacs . . . 17

4.3 Studiebes¨ok p˚a Volvo CE . . . 19 4.4 Design av l¨osningskoncept . . . 19 4.4.1 Koncept 1 . . . 20 4.4.2 Koncept 2 . . . 20 4.4.3 Koncept 3 . . . 21 5 Implementation 22 5.1 L¨osningskoncept 1 . . . 22 5.2 L¨osningskoncept 2 . . . 23 5.3 L¨osningskoncept 3 . . . 25 6 Resultat 26 6.1 Resultat av test . . . 26 6.1.1 Testmetod . . . 26 6.1.2 Testresultat f¨or L¨osningskoncept 1 . . . 28 6.1.3 Testresultat f¨or L¨osningskoncept 2 . . . 28

6.2 Det f¨ardiga systemet . . . 29

6.2.1 Systembeskrivning . . . 29

6.2.2 Vad som l¨oses . . . 30

7 Diskussion 31 7.1 Uppfyllande av projektets krav . . . 31

7.2 Speciella resultat och slutsatser . . . 32

7.3 Projektets utvecklingspotential . . . 32

7.4 Reflektion kring eget l¨arande . . . 33

1

Inledning

1.1

Bakgrund

HiQ ¨ar ett konsultf¨oretag med IT-inriktning som idag(2015) har kontor i Sve-rige, Finland och Ryssland. Med ca 1400 anst¨allda ¨ar f¨oretaget verksamma inom allt ifr˚an spelprogrammering till webbutveckling och inbyggda system. HiQ i Arboga har under flera ˚ar arbetat med att utveckla och underh˚alla ett m¨at- och styrsystem f¨or testk¨orningssekvenser av motorer och transmissioner. Systemet heter HiMacs och anv¨ands av Volvo i Sverige och internationellt. Volvo CE i Eskilstuna ¨ar ett av dessa f¨oretag.

1.1.1 Systembeskrivning

F¨ardigkonstruerade motorer/transmissioner placeras i en testrigg d¨ar de uts¨atts f¨or en simulerad testk¨orning. I realtid skickar testriggen olika typer av m¨atdata till ett f¨altbussystem. Denna m¨atdata kan exempelvis komma ifr˚an temperatur-och tryckgivare men ¨aven digitala signaler som talar om ifall alla d¨orrar till te-strummet ¨ar st¨angda. F¨altbussystemet som anv¨ands ¨ar utvecklat av Beckhoff Automation och best˚ar av s˚a kallade “klossar” uppbyggda av en busskopp-lare och ett antal olika terminaler f¨or in- och utdata. En PC med Windows som operativsystem kommunicerar med dessa Beckhoff-klossar. Det ¨ar ifr˚an denna PC olika testsekvenser konfigureras och ¨overvakas.

I v˚art fall best˚ar Beckhoff-h˚ardvaran av en EtherCAT1 _{busskopplare som} kontakten med PC:n sker via, ett varierande antal terminaler f¨or I/O2 och en “bus end plate” som markerar slutet f¨or terminalklossen och skyddar mot st¨orningar. Terminalklossar kan via EtherCAT kopplas ihop med andra klos-sar och d˚a m¨ojligg¨ora placering av klossarna intill det som ska m¨atas av f¨or att undvika l˚ang och r¨orig kabeldragning. Figur 1 visar detta. [1]

1

Ethernetbaserat protokoll anpassat f¨or realtids¨overf¨oring inom automation. 2_{Input/output - in och utsignaler}

Figur 1: Bild p˚a Beckhoff-klossar sammankopplade via EtherCAT. K¨alla: http://www.beckhoff.de/images/EtherCAT/et9000_et9200_et9300_ _web_main.jpg

Klossarna programmeras och konfigureras med hj¨alp av Beckhoffs egna programvara TwinCAT som HiMacs i sin tur kommunicerar med via Ether-CAT f¨or att spara och reagera p˚a m¨atdata. HiMacs ¨ar huvudprogrammet med menyer f¨or olika inst¨allningar samt det program varifr˚an de ¨ovriga delarna av systemet startas. Dessa ¨ar:

• HiCore – k¨arnan i HiMacs d¨ar grundkonfigurationen utf¨ors • HiVision – programmet f¨or anv¨andargr¨anssnitt

• HiSequence – programvara f¨or inst¨allning av simuleringssekvenser • HiUtility – programmet f¨or projektkonfigurering

• Alarms – s¨akerhetslarm

HiCore ¨ar k¨arnan i systemet som knyter samman in- och utdata med anv¨ andar-gr¨anssnitt, larm och testsekvenser. Se figur 2 nedan.

Figur 2: Visar en f¨orenklad ¨oversikt av HiMacssystemet.

Vid testk¨orning av exempelvis en motor utf¨ors m¨atningar simultant p˚a flera typer av indata via separata kanaler. Operat¨oren kan v¨alja ut vilka ka-naler av data (I/O) som skall l¨asas av och bygga upp sekvenser som kan styra en motors gasreglage, v¨axling och inbromsning och starta ig˚ang inspelningar av de utvalda kanalerna vid specifika tidpunkter eller h¨andelser.

Den h¨ar typen av m¨atsystem ¨ar av flera anledningar n¨odv¨andiga f¨or den till-verkningsindustri som Volvo CE tillh¨or. Tid sparas d˚a det g˚ar att genomf¨ora testk¨orningar mycket mer accelererat j¨amf¨ort med att testa i en riktig ma-skin, ett test som skulle tagit 10000 timmar i maskin g˚ar uppskattningsvis att utf¨ora p˚a endast 2500 timmar. En annan anledning ¨ar att testmilj¨on blir kontrollerad, det vill s¨aga att v¨ader, underlag och annat relaterat till milj¨on som kan p˚averka en maskin blir fullst¨andigt k¨ant och g¨or det l¨attare att analysera tester. Att testa specifika delkomponenter som vid verklig k¨orning inte uts¨atts f¨or s˚a stora p˚afrestningar g˚ar d˚a att uts¨atta f¨or extrem belast-ning f¨or att uppt¨acka eventuellt felaktigt beteende. P˚a Volvo CE kan tester f¨or en motor eller transmission ta 5-6 m˚anader innan testobjektet f˚ar gr¨ont ljus. Det ¨ar viktigt med avl¨asning p˚a h¨og frekvens f¨or att “spikar”, det vill s¨aga avstickande m¨atv¨arden, inte ska missas f¨or att ge en r¨attvisande bild av beteendet. F¨or vissa typer av m¨atv¨arden kan f¨or¨andringar ske v¨aldigt snabbt och d˚a kr¨avs en h¨ogre frekvens ¨an m¨atv¨arden som inte f¨or¨andras lika fort. Detta ¨ar information vi tog del av fr˚an anst¨allda p˚a Volvo CE.

1.2

Projekt

Grunden till projektet lades n¨ar HiQ s˚ag ett behov av att f˚a h¨ogre m¨atfrekvens i systemet HiMacs ¨an d˚avarande l¨aget. Programmet kunde d˚a maximalt inh¨amta 1000 m¨atningar per sekund p˚a grund av att C# inte st¨odjer en timer med en uppdateringsfrekvens snabbare ¨an 1 kHz. ¨Ovrig m¨atdata fr˚an h˚ardvaran kastades bort. Projektuppdraget gick d¨arf¨or ut p˚a att ta fram m¨ojliga l¨osningar f¨or HiMacs att utf¨ora m¨atningar med en h¨ogre frekvens samt att utv¨ardera och realisera den b¨ast l¨ampade l¨osningen. D˚a HiMacs var ett omfattande system best˚aende av ca 680 koddokument, kr¨avdes av oss en ¨

overgripande f¨orst˚aelse f¨or hur dessa samverkade och i sin tur interagerade med TwinCAT och Beckhoff-klossarna. Ut¨over sj¨alva m¨atf¨orb¨attringen kom projektet att omfatta:

• Avgr¨ansning av systemet

• Unders¨okning av hur m¨atdata h¨amtas in, lagras samt avl¨ases f¨or visu-alisering.

• Att inh¨amta kunskap om styrning av en Beckhoff-kloss via TwinCAT samt PLC-programmering.

• Framtagning och utv¨ardering av konkreta l¨osningar.

1.3

Syfte

Syftet med detta projekt var att g¨ora HiMacs m¨atningar mer tillf¨orlitligt. N¨ar det uppst˚ar ett signifikant fel i en motor under test s˚a m˚aste det uppt¨ackas av m¨atsystemet. I och med att m¨atfrekvensen h¨ojs s˚a ¨okar ¨aven noggrannheten vilket g¨or att fler fel kan uppt¨ackas.

1.4

Krav

De uppst¨allda kraven f¨or projektet:

• En utf¨orlig unders¨okning av potentiella l¨osningar till att ¨oka m¨atfrekvensen hos HiMacs ska utf¨oras.

• Ett l¨osningsf¨orslag ska v¨aljas ut och implementeras med delar av Hi-Macs.

• M¨atfrekvensen (f) f¨or HiMacs skall efter projektet definieras som: 1000 < f < ∞ Hz

• Den utf¨orda l¨osningen ska fungera med samtliga delar av HiMacs. • L¨osningen ska testk¨oras tillsammans med Volvo CE:s testrigg.

1.5

Arbetsf¨

ordelning

Under projektets analysfas arbetade b˚ada deltagarna tillsammans med att f¨orst˚a hur HiMacs fungerade och insamling av informationen som anv¨andes. D¨arefter fortsatte samarbetet men Jonatan lade mer fokus p˚a en eventuell l¨osningsid´e p˚a HiMacs-sidan och Johannes tittade mer p˚a vilka m¨ojligheter som fanns p˚a TwinCAT-sidan. Diskussioner f¨ordes st¨andigt under hela pro-jektet och implementationen av den slutgiltiga l¨osningen utf¨ordes av b˚ada deltagarna.

2

Metoder och verktyg

2.1

Metoder

Under arbetet f¨oljdes SCRUM-metodiken. Det innebar att: • skapa en product backlog

• planera sprintar

• h˚alla dagliga SCRUM-m¨oten • skriva dagbok

• utv¨ardera f¨oreg˚aende sprint

Arbetet bestod av tv˚a faser: Analysfasen och programmeringsfasen. Dessa blev uppdelade i ett antal SCRUM-sprintar med olika delm˚al. Projektet in-leddes med analysfasen d¨ar kunskap om HiMacs, Beckhoff-h˚ardvaran, Twin-CAT inh¨amtades. Denna del kom att fortg˚a under hela projektet. Syftet med analysfasen var att ¨oka f¨orst˚aelse f¨or den h˚ard- och mjukvara projektet be-handlade, hitta l¨osningsf¨orslag till problemet samt att evaluera dessa med hj¨alp av systemanalys. Under denna fas betraktades relevanta delar av Hi-Macs och TwinCAT-gr¨anssnittet som ett sammanh¨angande system f¨or att m¨ojligg¨ora applicering av systemanalytiska metoder.

Programmeringsfasen delades in i tre delar:

• Design – skapa en ¨overgripande plan f¨or hur l¨osningsid´en ska realise-ras programmeringsm¨assigt. UML-diagram ritas upp f¨or att visa p˚a struktur och relation mellan klasser och olika delar av systemet. • Implementation – programmera enligt den planerade designen. Best˚ar

till stor del av probleml¨osning. Om designbrister uppt¨acks kan dessa beh¨ova ˚atg¨ardas.

• Test – testningar av den implementerade l¨osningen. Sker kontinuerligt. Eftersom att det valda arbetss¨attet SCRUM ¨ar av agil art s˚a skedde arbetet iterativt. Faserna kom d¨arf¨or till stor del att ske parallellt.

2.2

Verktyg

De uppgifter som projektet innefattade anv¨andes PC-maskiner p˚a operativ-systemet Windows med f¨oljande mjukvara:

• GITHub – Versionshanterare f¨or programmeringsprojekt

• Visual Studio 2013 – Utvecklingsmilj¨o av mjukvara fr˚an Microsoft som anv¨andes f¨or programmering i C#

• TwinCAT – Mjukvara som ger en vanlig PC realtidssystemsegenska-per och sk¨oter styrningen och konfiguration av Beckhoff-klossar. Visual Studio 2010 med TwinCAT integrerat anv¨ands som utvecklingsmilj¨o.

2.3

Ovriga resurser

¨

Ett studiebes¨ok hos Volvo CE i Eskilstuna skedde den 29:e april f¨or att ge en bild av hur HiMacs anv¨ands hos kund. Ronny Sandehav tog emot och visade oss runt.

Beckhoff-klossar tillhandah¨olls av HiQ. Dessa anv¨andes f¨or att testk¨ora b˚ade de tidigaste f¨ors¨oken av kommunikationstester och senare potentiella l¨osningar. En funktionsgenerator kopplades in till Beckhoff-klossarna f¨or att f˚a f¨oruts¨agbar och mer frekvent m¨atdata. Denna l˚anandes ut av ¨Orebro Universitet tillsam-mans med ett oscilloskop.

3

Realtids¨

overf¨

oring av data

D˚a ¨overf¨oring av data ska ske mellan enheter inneb¨ar det en del krav p˚a systemet. Om det finns krav r¨orande svarstider kallas dessa realtidssystem och exempel p˚a till¨ampningar ¨ar styrning av robotar i industrin, trafikljus i v¨agkorsningar och m¨at- och styrsystem f¨or testk¨orningssekvenser av motorer och transmissioner s˚asom HiMacs. [2]

3.1

Realtidssystem

Begreppet realtid inom datavetenskap brukar delas upp i “h˚ard”, “mjuk” och “fast” realtid. Hur ett realtidssystem klassificeras beror p˚a hur allvarliga f¨oljderna blir av att missa en specificerad deadline (tidsgr¨ans). F¨or h˚arda realtidssystem kan konsekvenserna bli katastrofala om en deadline missas medans d˚a ett mjukt realtidssystem inte h˚aller en deadline ger det endast upphov till f¨ors¨amrad kvalitet av arbetet det ¨ar byggt f¨or. Fasta realtidssy-stem ger inga katastrofala konsekvenser men slutar vara anv¨andbart om en deadline inte h˚allits. [3]

En indelning av h¨andelse- och tidstriggade realtidssystem finns ¨aven med olika egenskaper. Det f¨orstn¨amnda inneb¨ar att systemet l˚ater signifikanta h¨andelser trigga ig˚ang olika processaktiviteter. I tidstriggade system triggas aktiviteter periodiskt vid f¨orutbest¨amda tidpunkter. Beroende p˚a till¨ampningen v¨aljs den ena eller den andra typen. H¨andelsetriggade system ¨ar mer dynamis-ka och schemal¨aggningen anpassar sig efter vilka h¨andelser som sker. Tidstrig-gade system ger d¨aremot b¨attre garantier d˚a noggrann schemal¨aggning i de-signfasen g¨or att tids˚atg˚angen g˚ar att f¨orutsp˚a precist och dessa f¨oredras vid s¨akerhetskritiska till¨ampningar. [4]

D˚a ett h˚art realtidssystem ska konstrueras med tuffa tidskrav kan det va-ra l¨ampligt att bygga det p˚a ett realtidsoperativsystem som ¨ar skapat f¨or att kunna ge tidsgarantier. Ett s˚adant ska klara av att l˚ata processer sl¨appa kon-trollen av CPU:n, g¨ora ett s˚a kallat processbyte och v¨anta en specificerad tid eller p˚a en viss h¨andelse. Mekanismer f¨or hantering av gemensamma resurser f¨or skrivning och l¨asning m˚aste finnas samt att efter att en process blivit avbruten se till att den forts¨atter d¨ar den slutade. [2] Under kapitel 4 som ber¨or projektets genomf¨orande kopplas det ovan n¨amnt ihop med HiMacs och vilket typ av realtidssystem det ¨ar.

3.2

TCP/IP och UDP/IP f¨

or realtidskommunikation

IP-baserad n¨atverkskommunikation f¨or realtids¨overf¨oring anv¨ands idag i stor utstr¨ackning i till¨ampningar som str¨omning av multimedia och inh¨amtning av data fr˚an sensorer av olika slag. I korta drag inneb¨ar IP (Internet Pro-tocol) att samtliga enheter i ett n¨atverk blir tilldelad en IP-adress och d˚a ett meddelande ska skickas skapas paket med information uppdelat i olika f¨alt varav ett s˚adant f¨alt ansvarar f¨or mottagarens IP-adress. IP anv¨ands ofta ihop med ett transportprotokoll som till exempel TCP och UDP som ger ut¨okade funktioner f¨or ¨overf¨oringen och hantering av paket. TCP skapar en f¨orbindelse mellan avs¨andare och mottagare f¨or att hela tiden verifiera att skickade paket kommit fram. UDP g¨or inte detta utan skickar paket och ¨ar ointresserad av att f˚a en bekr¨aftelse fr˚an mottagaren men kan d¨arf¨or skicka paket snabbare. [5]

Varken TCP eller UDP ¨ar skapade f¨or att anv¨andas i ett realtidssystem men beroende p˚a typen av system kan kraven f¨or mjuk realtid uppfyllas. Eftersom UDP inte garanterar att datapaketen kommer fram till slut s˚asom TCP g¨or kan UDP vara l¨ampligt d˚a exempelvis snabb ¨overf¨oring ska ske d¨ar det senaste paket ers¨atter det f¨oreg˚aende. TCP som ¨ar mer p˚alitligt tack vare dess kontrollmekanismer l¨ampar sig d˚a mer ˚at styrinstruktioner som inte f˚ar komma bort vid ¨overf¨oringen. [6]

3.3

Ethernet och realtid

1983 blev n¨atverksprotokollet Ethernet standardiserat som en del av IEEE 802.33 och idag anv¨ands tekniken i stort sett av samtliga lokala n¨atverk s˚asom hem- och kontorsn¨atverk. Tekniken som bygger p˚a IP ¨overf¨or data i s˚a kal-lade “frames” ist¨allet f¨or paket men vars struktur fortfarande ¨ar uppdelad i olika f¨alt med information om till exempel mottagaradress, avs¨andaradress, de data som ska ¨overf¨oras och en checksumma f¨or verifiering av att medde-landet ¨ar oskadat (se figur 4). Ethernet har l¨ange ansetts vara ol¨ampligt som ¨

overf¨oringsteknik inom industrin d¨ar h¨oga krav p˚a tillf¨orlitlighet och deter-minism st¨allts men har p˚a senare tid blivit allt vanligare i dessa typer av till¨ampningar. [7]

En orsak till att Ethernet inte alltid l¨ampar sig till industrin ¨ar dess metod f¨or n¨atverks˚atkomst kallad MAC (Media Access Control) som anv¨ander algorit-men “Carrier Sense Multiple Access with Collision Detection”. Den fungerar

3_{Institute of Electrical and Electronics Engineers uppr¨atth˚aller standarder och} publi-cerar litteratur inom ingenj¨orsvetenskap

som f¨oljande: n¨ar en enhet vill anv¨anda n¨atverket g¨ors en kontroll om det ¨ar ledigt. Om s˚a inte ¨ar fallet g¨ors ett nytt f¨ors¨ok efter en slumpm¨assig tid. Om tv˚a enheter f¨ors¨oker f˚a ˚atkomst till n¨atverket exakt samtidigt sker en kollision och b¨agge enheterna v¨antar en slumpm¨assig tid varp˚a de f¨ors¨oker p˚a nytt. Denna ˚atkomstmetod g¨or att det kan ske of¨oruts¨agbara f¨orseningar av data-paket om systemet best˚ar av mer ¨an en enhet som kommunicerar parallellt vilket ofta ¨ar fallet f¨or realtidssystem inom industrin. Modifikationer av Et-hernet har gjorts f¨or att minska antalet kollisioner och ¨oka f¨oruts¨agbarheten, bland annat genom att anv¨anda switchar som anv¨ander k¨oer dit datapaket l¨aggs ist¨allet f¨or att ge en slumpm¨assig v¨antetid d˚a ¨overf¨oringsmediet ¨ar upp-taget. Denna l¨osning ihop med anv¨andande av partvinnade kablar m¨ojligg¨or ¨

overf¨oring med full duplex4 _{men p˚a grund av att k¨oerna fortfarande kan r˚aka} ut f¨or “overflow” kvarst˚ar en del brister. [7, 8]

Varf¨or intresset f¨or tekniken vuxit beror p˚a att Ethernet blivit snabbt, l¨attanv¨ant och billigt [7]. Ytterligare faktorer som ¨oppnat f¨or fler till¨ampningsomr˚aden ¨

ar att olika designs¨att av realtidssystem f¨or att t¨acka upp Ethernets svag-heter och s¨arskilda Ethernetbaserade protokoll f¨or industrin utvecklats. Ett s˚adant utvecklades 2003 av Beckhoff Automation k¨ant som EtherCAT (Et-hernet for Control Automation Technology) ing˚ar i standarden IEC 61158 d¨ar industriella n¨atverksprotokoll avsedda f¨or realtidssystem samlats. [9] Det som g¨or EtherCAT annorlunda mot andra Ethernet-l¨osningar ¨ar tv˚a huvudsakliga f¨or¨andringar. Den f¨orsta ¨ar att det implementerats ett nytt s¨att att hantera ¨overf¨orda frames. Ist¨allet f¨or att med ett typiskt industriellt Ethernet-n¨atverk l˚ata varje slavnod efter att ha tagit emot ett datapaket tolka och kopiera informationen anv¨ander slavnoder i EtherCAT-baserade n¨atverk en s¨arskild h˚ardvara f¨or l¨asning av data. H˚ardvaran kallas “Field-bus Memory Management Unit” (FMMU) och den stora skillnaden med att nyttja denna ¨ar att datapaketet under l¨asning samtidigt skickas vidare till n¨asta enhet i n¨atverket och blir endast f¨ordr¨ojt ett f˚atal nanosekunder per enhet det passerar.

Denna FMMU ¨ar en del av varje I/O-terminal som utg¨or en tidigare n¨amnd Beckhoff-kloss. Den andra f¨or¨andringen ¨ar hur en Ethernet-frame ¨ar struktu-rerad f¨or att vara optimerad f¨or decentraliserade I/O-enheter. Grundstruk-turen f¨or en Ethernet-frame ¨ar densamma f¨or EtherCAT men genom att dela upp dataf¨altet i en EtherCAT specifik “Header” och ett “EtherCAT Telegram” best˚aende av ett antal “datagram” d¨ar sj¨alva meddelandet och

tillh¨orande information ligger kan ytterligare data skickas(Se figur 4). Detta g¨or att kontrolldata kan skickas med inuti en frame och ger m¨ojlighet att adressera 65535 olika slavnoder med en enda Ethernet-frame. [10, 9]

Figur 4: Visar hur EtherCAT strukturerar data f¨or att skicka via en Ethernet-frame. K¨alla: http://www.ethercat.org/pdf/english/ EtherCAT_Introduction_0905.pdf

3.4

Windows och realtid

Operativsystemet Windows f¨or vanliga persondatorer ¨ar inget realtidsopera-tivsystem d˚a det inte kan ge garantier vad g¨aller den maximala tids˚atg˚angen en process beh¨over f¨or att slutf¨ora en operation och bli redo att sl¨appa ifr˚an sig CPU:n. Det som hindrar Windows fr˚an att kunna uppfylla dessa krav ¨

ar bland annat p˚a grund av bakgrundsprocesser (Windows Services) som i vanliga fall anropas och k¨ors d˚a operativsystemet anser att det passar och stj¨al CPU:ns uppm¨arksamhet i ett antal mikrosekunder. Exempel p˚a s˚adana ¨ar olika programvaror, b˚ade fr˚an Microsoft och fr˚an andra utveckla-re, som k¨or tunga ber¨akningar som annars skulle gjort anv¨andargr¨anssnittet l˚angsammare. Dock finns s¨att att komma runt detta och beroende p˚a hur h˚arda tidskraven ¨ar finns det olika m¨ojliga l¨osningar. [11, 12]

Om kraven endast ligger p˚a niv˚an av tiondels millisekunder kan det r¨acka att inaktivera samt schemal¨agga vissa bakgrundsoperationer som annars k¨ors i Windows. Fortfarande kan inga garantier ges utan egna m¨atningar och tester kr¨avs och en f¨oruts¨attning att systemet inte kan ge katastrofala f¨oljder vid en missad deadline. [13]

olika distribut¨orer av h¨ogpresterande I/O-regulatorer som erbjuder realtidse-genskaper. Som tidigare n¨amnts anv¨ander HiMacs-systemet sig av Beckhoff Automations l¨osning med ett modul¨art f¨altbussystem byggt p˚a EtherCAT f¨or realtidssystem. Genom att anv¨anda Beckhoffs h˚ardvara g˚ar man runt proble-met som andra l¨osningar baserade p˚a vanliga Ethernet-protokollet lider av med att varje datapaket m˚aste bli “mottaget, tolkat och kopierat” vid varje ansluten enhet. Detta tack vare dess anv¨andning av FMMU-tekniken som beskrivits ovan.

Eftersom en EtherCAT-frame har samma utseende som ett Ethernetpaket s˚a st¨ods operativsystemets hela funktionalitet f¨or samtliga kompatibla Et-hernetprotokoll och d¨arf¨or kan till exempel TCP/IP anv¨andas parallellt med realtids¨overf¨oring via EtherCAT. Alla Ethernetpaket, inklusive EtherCAT, tas emot och unders¨oks av TwinCAT som separerar de paket med realtids-anknytning och skickar vidare de ¨ovriga till operativsystemet. [9]

4

Analys av systemet

F¨or att f˚a en f¨orst˚aelse f¨or systemets omfattning, m¨ojligheter och begr¨ansningar inleddes projektet med en omfattande analysfas. Efter och under analy-sen togs id´eer till m¨ojliga l¨osningar fram. D¨arefter kunde olika l¨osningar implementeras och testas. Slutligen togs beslut om vilken l¨osning som var l¨ampligast.

4.1

En f¨

orsta provk¨

orning

Analysfasen inleddes med att k¨ora HiMacs som en operat¨or p˚a industrin anv¨ander systemet f¨or att f˚a en f¨orst˚aelse f¨or ett typiskt anv¨andningsscenario som vi var intresserade av. Under denna testk¨orning skapades en bra grund av f¨orst˚aelse f¨or HiMacs.

F¨or att starta en inspelning m˚aste man f¨orst skapa en inspelare (Recorder). Sedan best¨ammer anv¨andaren vilka kanaler inspelaren skall lyssna p˚a och vilken frekvens (≤ 1000Hz) inspelningen skall utf¨oras p˚a. N¨ar en inspelning skall startas g˚ar det ¨aven att st¨alla in en f¨orinspelning (pre-trigg) f¨or att f˚a en bild av m¨atv¨ardena b˚ade innan och efter en viss tidpunkt.

Sekvenser (HiSequence) ¨ar i HiMacs l¨angre testk¨orningar d¨ar HiMacs s˚av¨al styr reglage p˚a exempelvis en motor som tar in m¨atdata fr˚an testriggen. En sekvens kan best˚a av flera inspelare som startar och stoppar inspelningen p˚a olika tidpunkter och kan str¨acka sig ¨over mer ¨an ett dygn.

4.2

Testprojekt

Testprojekt var mycket v¨asentliga under systemanalysen. Syftet med test-projekten var att skapa djupare f¨orst˚aelse genom avgr¨ansning och egen im-plementation.

4.2.1 TwinCAT-konfiguration

Det f¨orsta testprojektet var att ˚aterskapa den TwinCAT-konfiguration som vi tilldelats i b¨orjan av projektet. Detta gjordes f¨or att se hur omfattande den d˚avarande h˚ardvarukoden var samt hur en TwinCAT-konfiguration ¨ar upp-byggd. Resultatet blev att vi lyckades ˚aterskapa TwinCAT-konfigurationen. Den visade sig best˚a av en enkel uppbyggnad: En process har ett antal in- och utkanaler representerade som variabler som ¨ar direkt l¨ankade till h˚ardvarans respektive in och ut kanaler. Man kan se processen som ett I/O-gr¨anssnitt

f¨or HiMacs; processen kontaktas av HiMacs som k¨anner av dessa variablers namn, typ, storlek mm.

Efter vidare efterforskningar kunde vi ocks˚a se att frekvensen f¨or en pro-cess i TwinCAT ¨ar st¨allbar och att den kortaste cykeltiden som kan f˚as ¨ar 50 µs. Eftersom att TwinCAT ¨ar den delen som arbetar p˚a h˚ardvaran s˚a sattes med denna uppt¨ackt en f¨orsta absolut ¨ovre gr¨ans av ¨overf¨oringsfrekvens till 20 kHz. Den ursprungliga frekvensen i TwinCAT var 1 kHz eftersom att en h¨ogre frekvens aldrig tidigare beh¨ovt anv¨andas.

Figur 5: Visar den ursprungliga TwinCAT-konfigurationen f¨or Beckhoff-klossen som anv¨andes.

4.2.2 Avgr¨ansning av HiMacs

Det andra testprojektet utarbetades samtidigt som det f¨orsta och gick ut p˚a att avgr¨ansa den kod i HiMacs som ¨ar n¨armast ansvarig f¨or inkommande data ifr˚an TwinCAT. Syftet var att f˚a svar p˚a:

• Har HiMacs en absolut gr¨ans av 1 kHz p˚a hantering av inkommande data?

• Hur och var sparas och hanteras inkommande data?

Resultatet blev att vi lyckades avgr¨ansa HiMacs som planerat och kom fram till f¨oljande.

I HiMacs ligger en klass som agerar gr¨anssnitt mot TwinCAT och kallas klienthanteraren. HiMacs har en klienthanterare och den kan endast existera i en instans. Syftet f¨or instansen ¨ar att vid uppstart av HiMacs identifiera varje kanal p˚a TwinCAT som skall anv¨andas och sedan f˚a uppdateringar om v¨ardet av och fr˚an dessa kanaler. Genom att skicka ett symbolnamn f¨or varje kanal (exempelvis “Task.Inputs.AI 00”), vilken datatyp kanalen skickar och om kanaluppdateringen skall ske cykliskt (tidstriggat) eller vid f¨or¨andring (h¨andelsetriggat i h˚ardvaran) s˚a skapas kontakt. I HiMacs ¨ar all kanalkom-munikation med TwinCAT h¨andelsetriggade. Viktigt att observera h¨ar ¨ar att s˚av¨al de cykliska som de h¨andelsetriggade uppdateringarna sker p˚a vill-kor fr˚an timern i TwinCAT p˚a grund av att b˚ada typerna uppdaterar Hi-Macs med triggning av C#-Events. Den h¨andelsetriggade funktionen anropas allts˚a:

• Vid cyklisk uppdatering i h˚ardvaran k ∗ ftc

g˚anger per sekund, d¨ar k ¨ar antalet kanaler och ftc ¨ar uppdateringsfre-kvensen i TwinCAT

• Vid h¨andelsetriggad uppdatering i h˚ardvaran k

P n=1

ftcmn

g˚anger per sekund, d¨ar k ¨ar antalet kanaler och ftcmn ¨ar den genom-snittliga uppdateringsfrekvensen f¨or kanalen i TwinCAT.

N¨ar klienthanteraren tar emot en uppdatering inneh˚aller denna ett v¨arde men ocks˚a en tidsst¨ampel p˚a 100 nanosekunders uppl¨osning. Klienthantera-ren identifierar vilken kanal uppdateringspaketet kommer ifr˚an och sparar undan v¨ardet till ett annat objekt, v¨ardeleverant¨oren, men struntar i att ta hand om tidsst¨ampeln. V¨ardeleverant¨oren ¨ar en del av en kanal i Hi-Macs. Varje kanal i HiMacs har allts˚a varsin instans av detta objekt. Fr˚an en cyklisk uppdateringsprocess p˚a 1 kHz i v¨ardeleverant¨oren skickas v¨ardet

sedan vidare till kanalens egentliga v¨ardevariabel. Det ¨ar ifr˚an denna varia-bel som inspelaren cykliskt h¨amtar v¨ardet och sparar ner p˚a olika filformat. Uppdateringsfrekvensen f¨or inspelaren sker p˚a en annan Timer ¨an den f¨or v¨ardeleverant¨oren och ¨ar st¨allbar upp till 1 kHz.

En viktig insikt vi erfordrade var att ett kanalv¨arde kan skrivas ¨over fle-ra g˚anger mellan inspelarens varje sampling”. P˚a grund av detta kan HiMacs ses som ett mjukt realtidssystem d˚a samtliga meddelande ej garanteras att tas omhand. Samtidigt finns det viktiga v¨arden fr˚an till exempel d¨orren till testrummet men ¨aven f¨or s˚adana meddelanden f¨orlitar sig HiMacs p˚a att m¨atfrekvensen ¨ar nog h¨og f¨or att inte missas.

Figur 6: Visar i stora drag vart indata tas emot och skickas vidare asynkront (tre separata Timers som triggar Update-anrop).

4.3

Studiebes¨

ok p˚

a Volvo CE

Efter cirka 4 veckor in i projektet gjorde vi ett studiebes¨ok hos Volvo Con-struction Equipment i Eskilstuna d¨ar vi blev guidade runt f¨or att titta p˚a hur dem anv¨ande sig av HiMacs-systemet. Vi var framf¨orallt intresserade av hur deras behov s˚ag ut g¨allande snabbare m¨atfrekvens och hur ett typiskt scenario f¨or en testk¨orning s˚ag ut. Vi l¨arde oss att de egentligen inte bru-kar nyttja mycket snabbare frekvens ¨an 2 kHz i dagsl¨aget och att detta var intressant f¨or indata med extremt k¨ansliga sensorer s˚asom tryckgivare. En testrigg kunde anv¨anda sig av mellan 10-70 kanaler varav endast ett f˚atal kunde kr¨ava h¨ogre frekvens ¨an 1 kHz.

4.4

Design av l¨

osningskoncept

Efter att ha byggt de olika testprojekten och f¨ors¨okt f˚a f¨orst˚aelse f¨or vilka delar av kommunikationen mellan HiMacs och TwinCAT-sidan som erbj¨od

utrymme f¨or modifikationer hade vi en del l¨osningsid´eer som ans˚ags m¨ojliga. Det vi fr¨amst hade i ˚atanke vid designen av t¨ankbara l¨osningskoncept var hur mycket exekveringstiden f¨or ett cykelvarv i HiMacs skulle ¨oka eftersom denna inte f˚ar ¨overstiga cykeltiden (1 millisekund). Med viss r˚adgivning fr˚an anst¨allda p˚a HiQ togs f¨oljande koncept fram f¨or att ge HiMacs en h¨ogre m¨atfrekvens.

4.4.1 Koncept 1

Varje mottaget meddelande skickat fr˚an h˚ardvaran till HiMacs sparas i n˚agon typ av buffer ist¨allet f¨or att endast skriva ¨over det f¨oreg˚aende meddelandet. Begr¨ansningen av den Timer som anv¨ands i HiMacs g˚as runt genom att vid varje tick (en g˚ang per millisekund) h¨amta hela buffern inneh˚allande ett l¨ampligt antal v¨arden. Om buffern d˚a hinner fyllas med exempelvis 5 v¨arden varje millisekund skulle detta ge en frekvens p˚a 5 kHz. Kanalklassen i HiMacs modifieras f¨or att inte l¨angre vara begr¨ansad till transport av endast ett v¨arde i taget. Tidsst¨ampeln som medf¨oljer i ett meddelande omh¨andertas till skillnad fr˚an hur det ¨ar i nul¨aget f¨or att kunna paras ihop med v¨ardet. P˚a det s¨attet ges v¨ardena de exakta tidst¨amplarna d˚a v¨ardet m¨attes av ist¨allet f¨or d˚a v¨ardet blev inspelat baserat p˚a Timer-klockan. P˚a TwinCAT-sidan kortas cykeltiden ner (frekvensen ¨okas) f¨or att st¨amma ¨overens med den ¨

onskade m¨atfrekvensen.

Figur 7: Visar det f¨orsta l¨osningskonceptet. 4.4.2 Koncept 2

En virtuell modul i TwinCAT och paketerar n antal v¨arden p˚a frekvensen n∗1000 Hz per kanal. Efter n antalet cykler skickar TwinCAT paketet till Hi-Macs genom att trigga C#-Event. Antal anrop f¨or eventet begr¨ansas d¨arf¨or till 1000 ∗ (antaletkanaler) per sekund vilket har varit uppdateringsfrekven-sen f¨or detta event i HiMacs grundutf¨orande. Varje mottaget meddelande

skickat fr˚an h˚ardvaran till HiMacs packas upp och sparas i n˚agon typ av buffer ist¨allet f¨or att ett v¨arde skrivs ¨over flera g˚anger mellan inspelarens utf¨orande. Begr¨ansningen av den Timer som anv¨ands i HiMacs g˚as runt genom att vid varje tick (en g˚ang per millisekund) h¨amta hela buffern inneh˚allande ett l¨ampligt antal v¨arden. Om buffern d˚a hinner fyllas med exempelvis 5 v¨arden varje millisekund skulle detta ge en frekvens p˚a 5 kHz. Kanalklassen i HiMacs modifieras d¨arav f¨or att kunna packa upp ett paket av v¨arden och spara i en buffer.

Figur 8: Visar det andra l¨osningskonceptet. 4.4.3 Koncept 3

En inspelningsmodul separerad ifr˚an HiMacs skapas i C eller C++. Modulen har en icke-cyklisk konversation med HiMacs men h¨ogfrekvent cyklisk kom-munikation med TwinCAT. N¨ar en inspelning skall starta f˚ar modulen ett meddelande ifr˚an HiMacs och b¨orjar d˚a spela in med en frekvens h¨ogre ¨an vad HiMacs ¨ar kapabel till. HiMacs beh˚aller sin kommunikation med TwinCAT i realtid f¨or att kunna uppt¨acka eventuella alarm och m¨atarvisualisering i re-altid. Efter inspelning h¨amtar HiMacs det data som den nya modulen spelat in och sparar undan p˚a ¨onskat vis. P˚a detta s¨att slipper klienthanteraren i HiMacs bli stressat under inspelning.

Figur 9: Visar det tredje l¨osningskonceptet.

5

Implementation

5.1

L¨

osningskoncept 1

D˚a ett f¨ors¨ok att implementera detta l¨osningskoncept gjordes var den f¨orsta utmaningen att se ¨over hur en kanal skulle modifieras f¨or att hantera flera v¨arden i taget. En buffer skapades i “Channel”-klassen f¨or att transportera de v¨arden som tagits emot sedan den f¨oreg˚aende Timer-uppdateringen. D˚a en kanal i HiMacs har m˚anga beroenden och stort ansvar var det viktigt att f¨olja samma m¨onster som systemet f¨oljde. Genom att titta p˚a hur ett “Va-lue” tidigare hade implementerats gick detta utan st¨orre bekymmer. Valet av typ av buffer f¨oll p˚a “ConcurrentQueue” f¨or att garantera tr˚ads¨akert be-teende. F¨or att para ihop ett v¨arde med sin tidsst¨ampel valde vi datatypen “Tuple<long timestamp, double value>” och dessa paket s¨atts ihop direkt ett mottagningsevent triggats och l¨aggs i k¨on. Denna k¨o skickas sedan vidare till sin kanal vid anrop av v¨ardeleverant¨orens “Update”-funktion som sker varje Timer-tick och nollst¨alls d¨arefter f¨or att ta emot nya paket. F¨or att undvika att k¨on ¨ar upptagen med att l¨agga till ett paket samtidigt som vida-retransporten i “Update”-funktionen skulle ske sattes ett l˚as ¨over k¨o-objektet vid b˚ada operationerna.

och tidsst¨amplar bidrog med ny information. Eftersom vi hade tidsst¨amplarna ihop med varje nytt v¨arde kunde vi se under hur l˚ang tid ett v¨arde f¨orblivit detsamma utan att skicka mer data ¨an n¨odv¨andigt.

En inspelning ¨ar ofta det s¨att som anv¨ands f¨or att ¨overvaka v¨ardena under en testk¨orning och d¨arf¨or blev det naturligt att f¨ors¨oka g¨ora en inspelning med h¨ogre uppl¨osning f¨or att testa om denna metod fungerade. HiMacs skriver ner en inspelning till flera olika format men vi valde att endast skriva till xml-fil f¨or att begr¨ansa projektet. “Recorder”-klassens “Update”-funktion anropas grundinst¨allningarna en g˚ang varje ms och utf¨or d˚a en s˚a kallad “sampling”. I denna tilldelas en 1-dimensionell array f¨or tidsst¨amplarna och 2-dimensionell array f¨or m¨atv¨ardena tillh¨orande ett inspelningsobjekt nya v¨arden. Varf¨or tidsst¨amplarna endast anv¨ander en 1-dimensionell array ¨ar f¨or att alla ka-naler delar p˚a samma tidsst¨ampel medans m¨atv¨ardena ordnas efter kanal. Precis vid start av en inspelning initieras b˚ada arrayerna med v¨ardet 0 p˚a alla platser. Varje inspelat v¨arde kallades f¨or ett “sample”.

L¨osningen f¨or mer h¨oguppl¨ost inspelning utan att g˚a ifr˚an den Timer-baserade “samplingen” blev att l˚ata varje “sample” best˚a utav fler ¨an ett v¨arde. Ge-nom att l˚ata array:en f¨or inspelade m¨atdata bli 3-dimensionell ordnad p˚a formatet [KanalIndex, SampleIndex, T uple < long, double > −index] gick det att med en extra “for-loop” spela in snabbare. Tidsst¨amplarna som ti-digare var gemensamma f¨or alla inspelade kanaler ¨andrades ocks˚a till en 3-dimensionell array f¨or att st¨amma ¨overens med m¨atv¨ardena.

Efter att ha testat och f˚att en inspelning att fungera uppt¨acktes det att 0:or ibland uppstod f¨or b˚ade m¨atv¨ardena och tidsst¨amplarna. Det berodde p˚a att en ¨ovre gr¨ans beh¨ovde s¨attas p˚a k¨on med tupler f¨or att kunna s¨aga med vilken m¨atfrekvens inspelningen hade skett och om v¨ardeleverant¨oren inte hunnit f˚a in detta antal tupler f¨orblev v¨ardena p˚a de index 0 fr˚an initi-eringen. Eftersom meddelandena fr˚an h˚ardvaran till HiMacs, h¨amtning fr˚an v¨ardeleverant¨oren till respektive kanal samt “samplingen” i inspelaren sker asynkront ¨ar detta en naturlig f¨oljd. D˚a det enda detta inneb¨ar ¨ar att syste-met inte hunnit f˚a in mer data skapades en funktion som ersatte dessa 0:or med den saknade tidst¨ampeln och en kopia p˚a det senaste “riktiga” v¨ardet.

5.2

L¨

osningskoncept 2

L¨osningskoncept 2 har m˚anga likheter med L¨osningskoncept 1 struktur av Hi-Macs. D¨arf¨or utf¨ordes L¨osningskoncept 2 som en utveckling av L¨osningskoncept 1. D¨ar 1:an tar emot v¨arden ifr˚an TwinCAT och skickar vidare f¨or att l¨agga

i en buffer som t¨oms varje millisekund, tar 2:an ist¨allet emot ett paket och skickar paketet f¨or uppackning och placering i v¨ardebuffern.

Det st¨orsta som skiljer koncept 1 och 2 ifr˚an varandra ¨ar s¨attet som Twin-CAT och Beckhoff arbetar p˚a. N¨ar detta skulle utvecklas fanns tv˚a val f¨or sj¨alva programmeringen. TwinCAT 3 till˚ater n¨amligen att skapa realtidspro-gram, inte bara i PLC-spr˚ak enligt IEC 61131-3 -standarden, utan ocks˚a i C/C++. Till en b¨orjan gjordes ett testprojekt i ST (Structured Text) d¨ar koppling ifr˚an h˚ardvarans ing˚angar l¨ankades till variabler i koden som sedan togs hand om i en lista vilken t¨omdes n¨ar den var full. Syftet var helt enkelt att testa p˚a spr˚aket ST.

Ett antagande togs d¨arefter att en modul i spr˚aket ST skulle bli sv˚ar att f˚a kompatibel till flera konfigurationer av TwinCAT. D¨arf¨or testades ist¨allet att skapa en modul i C++. Detta visade sig dock medf¨ora andra problem: Vid minnesallokering av den array, vars uppgift var att representera v¨ardepaketet, kraschade programmet. N¨ar ett realtidsprojekt i C/C++ skapas f¨or Beckhoff-klossen s˚a medf¨oljde mycket kr¨avande kod f¨or att kunna implementera ob-jektorienterad struktur. Ett beslut togs d˚a ist¨allet att forts¨atta utvecklingen i ST. Detta gjordes utifr˚an antagandet att ¨aven om ett ST-program skulle inneb¨ara kr˚angligare konfigurationer f¨or anv¨andaren s˚a blir koden mycket mer effektiv eftersom att spr˚aket ¨ar mer h˚ardvarun¨ara ¨an C++. ST blev den slutgiltiga v¨agen f¨or programmeringen av TwinCAT-modulen.

F¨or att med events kunna skicka och ta emot v¨arden s˚a m˚aste dataty-pen st¨odjas, vilket arrayer inte g¨or i TwinCAT. F¨orst testades att l¨agga de uppsamlade v¨ardena, separerade med kommatecken, i en str¨ang eftersom vi uppt¨ackte att str¨angar st¨oddes som datatyp i ¨overf¨oring. Men ¨aven denna datatyp hade problem att komma fram till HiMacs. D˚a testades ist¨allet att anv¨anda den st¨orsta till˚atna typen av heltalsvariabel vilket var 64-bitars hel-talsvariabel. P˚a grund av att de analoga kanaler som k¨ors har en uppl¨osning p˚a 16 bitar s˚a blev tanken att vi kan koda in 4 stycken m¨atv¨arden i en 64 bitars heltalsvariabel genom att skifta in 16 bitar (v¨arde = 0), addera senaste v¨ardet och repetera detta p˚a en frekvens fyra g˚anger s˚a stor som frekvensen f¨or skickning till HiMacs. P˚a detta vis kan vi f¨or kanaler av 16 bitar tillhan-dah˚alla 4 kHz m¨atfrekvens, f¨or 8 bitar 8 kHz och f¨or enstaka bitar (digitala kanaler) erbjuda den absoluta gr¨ansen p˚a 20 kHz om s˚a skulle ¨onskas. Det Event som HiMacs prenumererar p˚a mot TwinCAT ¨ar ifr˚an enbart en process (“gr¨anssnittsprocess”) p˚a TwinCAT. Genom att anv¨anda en eller flera (f¨or HiMacs dolda) PLC-processer med en h¨ogre arbetsfrekvens kan

anv¨andaren v¨alja enskilda terminaler i klossen som ska ha h¨ogre uppdate-ringsfrekvens ¨an andra kanaler och koppla dem via den h¨ogfrekventa proces-sen och sedan vidare in i gr¨anssnittsprocessen.

5.3

L¨

osningskoncept 3

Det tredje l¨osningskonceptet blev aldrig implementerat d˚a vi bed¨omde att tiden inte skulle r¨acka till och att de f¨orsta tv˚a koncepten var bra nog f¨or att l¨osa uppgiften. L¨osningskoncept 3 beskrivs allts˚a inte ytterligare i denna rapport.

6

Resultat

Efter att implementation och tester slutf¨orts slogs den slutgiltiga l¨osningen fast. Det testerna visade i form av tidskritiska omr˚aden och totala begr¨ansningar kombinerat med kunskap om hur systemet anv¨ands i industrin l˚ag helt till grund vid valet av l¨osning.

6.1

Resultat av test

6.1.1 Testmetod

Under implementeringen av de tv˚a l¨osningskoncepten gjordes l¨opande tester f¨or att uppt¨acka brister i den skrivna koden. Dessa varierade fr˚an g˚ang till g˚ang men innebar ofta inspelningar med olika antal kanaler, m¨atfrekvens och inspelningsl¨angd.

N¨ar de b˚ada l¨osningarna ans˚ags vara f¨ardiga gjordes mer generella och likv¨ardiga tester. F¨or detta anv¨andes HiMacs egna sekvensprogram d¨ar olika inspelare sattes ig˚ang med olika inst¨allningar r¨orande tid och m¨atfrekvens. Inspelarna tittade p˚a samma 8 kanaler p˚a vilka vi genererade en sinuskurva. Vi valde att l˚ata en av sekvenserna l˚ata inspelningsl¨angden ¨oka fr˚an 60 sekunder till 180 i tre steg och den andra spela in med en m¨atfrekvens p˚a 1, 2 respektive 4 kHz. Sj¨alva ¨overf¨oringskommunikationen sker hela tiden s˚a systemet pressas s˚a fort HiMacs startats och d¨arf¨or l¨ats systemet st˚a p˚a en stund innan test-sekvenserna och en stund efter. Resultatet av inspelningarna analyserades manuellt men ¨aven automatiserat av en funktion som ber¨aknade differenser av tidsst¨amplarna och skrev resultatet till text-fil (se figur 10 och 11 nedan).

Figur 10: En testsekvens d¨ar tre ˚atskilda inspelare triggas vid olika tidpunkter med olika inspelningsl¨angd.

Figur 11: En testsekvens d¨ar tre ˚atskilda inspelare triggas vid olika tidpunkter med olika inspelningsl¨angd.

6.1.2 Testresultat f¨or L¨osningskoncept 1

Testerna under implementationen visade att det var viktigt att anpassa storleken av k¨on efter klockfrekvensen som TwinCAT skickar meddelanden med f¨or att minimera antalet med “samplade” 0:or. D˚a klockfrekvensen i TwinCAT st¨alldes p˚a 5 kHz och h¨ogre blev systemet m¨arkbart instabilt. Eftersom en m¨atfrekvens p˚a 5 kHz inte ¨ar till n˚agon st¨orre nytta f¨or kun-derna i dagsl¨aget var detta inget f¨or¨odande f¨or l¨osningskonceptet men tydde p˚a att en flaskhals vid data¨overf¨oringen mellan klienthanteraren i HiMacs och Beckhoff-h˚ardvaran fanns. H¨ogsta stabila frekvens bed¨omdes d¨arf¨or till 2 kHz men d˚a inga tester gjordes i industrin d¨ar ett betydligt st¨orre antal kanaler anv¨ands ¨ar detta sv˚art att garantera. En m¨atfrekvens ¨overstigande 10 kHz ¨ar m¨ojlig men p˚a grund av instabilitet ¨ar det inget att rekommendera. F¨ordelar med denna l¨osning, f¨orutom att den f¨ordubblar m¨atfrekvensen, ¨ar att ingen annorlunda konfiguration beh¨over g¨oras i TwinCAT mot hur det fungerade tidigare.

En nackdel som blir st¨orre d˚a antalet kanaler ¨okar ¨ar att det inte finns m¨ojlighet att v¨alja ut enskilda kanaler som ska uppdateras i snabbare takt utan samtliga tvingas i s˚a fall ¨oka frekvensen. Det kan bli p˚afrestande i kli-enthanteraren d¨ar triggade event tas omhand.

Vid testsekvensen klarade sig det f¨orsta l¨osningskonceptet utan problem d˚a buffern endast h¨oll ett v¨arde ˚at g˚angen (1 kHz) och inspelningsl¨angden ¨okade. Systemet blev tyngre belastat d˚a h˚ardvaran fortfarande skickade data med 4 kHz men detta gick allts˚a bra. Vid testsekvensen med h¨ogre m¨atfrekvenser gick 2 kHz bra utan bekymmer men d˚a frekvensen h¨ojdes till 4 kHz skedde en krasch av HiMacs.

6.1.3 Testresultat f¨or L¨osningskoncept 2

Testerna f¨or L¨osningskoncept 2 visar p˚a en ¨overf¨oring av paket utan skr¨apv¨arden. N¨ar skr¨apv¨arden eller tomma v¨arden skrivits i L¨osningskoncept 1 p˚a grund av den asynkrona ¨overf¨oringen beh¨ovdes en lagningsfunktion som anropas efter avslutad inspelning. Detta undvek L¨osningsf¨orslag 2.

Eftersom att den delen som jobbar p˚a h¨og frekvens i L¨osningskoncept 2 ligger p˚a h˚ardvaran som ¨ar gjord f¨or att hantera realtidsoperationer ges en garanti att ett paket med ¨onskat antal v¨arden mottas p˚a HiMacs-sidan. ¨Overf¨oringen blir allts˚a konsistent.

Testsekvenserna gick felfritt b˚ade vid ¨okande inspelningstid och vid upp-trappande m¨atfrekvenser. Av vad dessa tester visar f˚as en stabilare l¨osning med detta koncept men det kr¨aver n˚agot mer konfigurering som inkluderar ett antal rader ST-kod p˚a TwinCAT-sidan.

6.2

Det f¨

ardiga systemet

Utifr˚an resultatet fr˚an testerna av de tv˚a l¨osningskoncepten och observatio-ner under implementationen valdes till slut L¨osningskoncept 2 ut. Testerna visade tydligt att det f¨orsta konceptet inte var stabilt vid h¨ogre frekvenser och ¨okande antal kanaler. D˚a L¨osningskoncept 2 aldrig st¨otte p˚a problem un-der v˚ara tester blev det tydligt vilket koncept vi skulle forts¨atta med. ¨Aven v˚ar erh˚allna kunskap om systemet v¨agde in.

6.2.1 Systembeskrivning

I den slutgiltiga l¨osningen l¨ankas f¨orst de kanaler p˚a h˚ardvaran som skall l¨asas av p˚a h¨og frekvens till variabler i en h¨ogfrekvent PLC-process. De l¨ankade va-riablerna har samma storlek och typ som inkommande data. I PLC-processen finns dessutom f¨or varje h¨ogavl¨ast kanal en 64-bitars heltalsvariabel som ¨ar l¨ankad till den l˚agfrekventa processen som HiMacs kommunicerar med. P˚a varje klockcykel i den h¨ogfrekventa processen bitskiftas x antal nollor in ifr˚an v¨anster p˚a 64-bitarvariabeln, d¨ar x ¨ar bitstorleken av den kanalens data. D¨arefter adderas det senaste inkomna v¨ardet till 64-bitarvariabeln. Om bit-storleken p˚a indata ¨ar 16 bitar sker denna paketering p˚a 4000 Hz, 8 bitar s˚a sker paketeringen p˚a 8000 Hz och 32 bitar sker paketeringen p˚a 2000 Hz. D˚a flera m¨atv¨arden inkommer i samma paket delar dessa ¨aven den tids-st¨ampel som medf¨oljer. Eftersom vi var garanterade ¨onskat antal m¨atv¨arden i varje paket kunde deras tidsst¨ampel ber¨aknas genom att l¨agga till cykeltiden dividerat med antalet m¨atv¨arden. Detta valdes dock bort f¨or att f˚a inspel-ningar med kontinuitet d˚a inkommande data sker vid “OnChange”-event och inspelningar kan d˚a f˚a stora hopp i tidst¨amplarna. Ist¨allet anv¨andes system-klockans tidpunkt vid inspelning p˚a samma s¨att som HiMacs tidigare gjort. Det slutgiltiga systemet visas n˚agot f¨orenklat i figur 12.

Figur 12: Visar den slutliga l¨osningen i sin helhet (n˚agot f¨orenklat) med b˚ade h˚ardvaru- och mjukvaru-sidan. Systemet ¨ar konfigurerat f¨or de tv˚a analoga kanalerna “Analog In 1” och “Analog In 2” att m¨atas av p˚a 4000 Hz. 6.2.2 Vad som l¨oses

M¨atfrekvensen kan med den framtagna l¨osningen ¨overstiga 1 kHz. Det ex-tra arbete som beh¨ovs f¨or ge h¨ogre m¨atfrekvens utf¨ors nu till st¨orsta del p˚a TwinCAT-sidan i h˚ardvaran och belastar inte HiMacs med snabbare

mot-tagningsfrekvens. Ett lika stort antal event triggas i HiMacs som i dess grundutf¨orande men med ett st¨orre antal m¨atv¨arden som mottas.

Inga on¨odiga processer sker tack vare att enskilda terminaler kan knytas till processer med h¨og frekvens och ¨ovriga terminaler som ej beh¨over nyttja h¨ogre frekvens kan arbeta som tidigare.

Med den h¨ogre frekvensen har Volvo CE b¨attre m¨ojligheter till att uppt¨acka spikar under tester av motorer och transmissioner. Dessutom kan de kompo-nenter som m¨ats studeras noggrannare eftersom att en h¨ogre uppl¨osning av detta erh˚alls med den h¨oga m¨atfrekvensen. Ett exempel p˚a detta visas i figur 13 som visar ett urklipp av inspelning p˚a en 50 Hz sinuskurva.

Figur 13: Visar en m¨atning av en genererad 50 Hz-kurva med en inspelnings-frekvens p˚a 1 respektive 4 kHz.

7

Diskussion

7.1

Uppfyllande av projektets krav

De krav som st¨alldes upp inf¨or projektet f¨orblev of¨or¨andrade. En unders¨okning har genomf¨orts och lett fram till tre l¨osningskoncept varav tv˚a faktiskt blev implementerade och uppfyllde det st¨allda kravet p˚a att ge HiMacs-systemet en h¨ogre m¨atfrekvens. L¨osningen som i slut¨andan valdes ut hade m˚anga delar gemensamt med den som valdes bort d˚a b˚ada kr¨avde f¨or¨andringar i HiMacs f¨or att kunna st¨odja snabba inspelningar.

L¨osningen gav en m¨atfrekvens p˚a 4 kHz f¨or m¨atv¨arden av 16-bitars heltal vilket vi efter studiebes¨oket hos Volvo CE fick veta ¨ar det dubbla mot vad

de i nul¨aget kan nyttja. Vi har ¨aven f˚att veta att det ¨ar denna datatyp som oftast anv¨ands d˚a h¨ogre frekvenser ¨ar av intresse. Vi och HiQ satte aldrig n˚agon ¨ovre gr¨ans f¨or m¨atfrekvensen och b˚ada parter ¨ar n¨ojda med resultatet.

¨

Onskem˚alet inf¨or projektet om att f˚a l¨osningen att fungera med samtliga delar av HiMacs ¨ar p˚a ett s¨att uppn˚add d˚a den ¨ar integrerad i systemet utan att hindra ¨ovrig funktionalitet i systemet. D¨aremot finns en del funktionali-tet som ˚aterst˚ar att implementera och vidareutveckla. ¨Onskem˚alet om att ha testk¨ort v˚ar version i en riktig testrigg hos Volvo CE uppfylldes inte under projektets g˚ang p˚a grund av brist p˚a tid. Det senare ¨onskem˚alet var bra men halvv¨ags in i projektet, efter att ha varit p˚a studiebes¨oket, ins˚ag vi att ett s˚adant test skulle kr¨ava ytterligare ett antal veckor att genomf¨ora.

D˚a systemanalysen var omfattande och inl¨arningen av systemet tog mer tid ¨

an v¨antat blev tidsuppskattning av de sprintar vi st¨allde upp v¨aldigt sv˚ara att utf¨ora korrekt. Det berodde delvis p˚a hur v˚ara “sprint-tasks” formulera-des inledningsvis d˚a de ofta blev breda utan tydliga m˚al men ocks˚a p˚a grund av komplexiteten i systemet. I efterhand skulle vi kunnat planera tydliga-re sprintar f¨or att inte fastna med en sprint och snabbare kunnat komma fram till l¨osningskoncept. Alternativt kunde vi ha avvaktat med SCRUM-metodiken tills det att implementationsfasen inletts. N˚agot annat vi hade kunnat g¨ora annorlunda f¨or att minska on¨odig tidspress var att i st¨orre ut-str¨ackning arbeta med rapporten parallellt med det praktiska arbetet.

7.2

Speciella resultat och slutsatser

Det absolut viktigaste med denna l¨osning ¨ar den minimering av on¨odiga processer eftersom att enskilda kanaler kan v¨aljas som h¨oguppl¨osta i kopp-ling genom PLC-processer. Dessutom kan de terminaler i h˚ardvaran som inte beh¨over uppdateras p˚a h¨ogre frekvens kopplas direkt till gr¨anssnittsprocessens uppdateringsfrekvens. Nackdelen med detta ¨ar att m¨ojligheten f¨or snabb och anv¨andarv¨anlig konfigurering blir sv˚arare. N¨ar en h¨og avl¨asningsfrekvens ¨

onskas beh¨ovs nya ST-variabler skapas och kopplas via paketeringskoden.

7.3

Projektets utvecklingspotential

¨

Onskem˚alet att f˚a v˚ar l¨osning att fungera med alla delar av HiMacs ¨ar ett sj¨alvklart n¨asta steg f¨or projektet. Vi s˚ag inga direkta kompabilitetsproblem med v˚ar design men f¨or att ˚astadkomma detta kr¨avs mindre f¨or¨andringar i m˚anga delar av systemet. Begr¨ansningen vi gjorde att bara spela in i xml-format handlade om tidsbrist och att f˚a l¨osningen att st¨odja de ¨ovriga

for-maten som anv¨ands av systemet endast skulle kr¨ava lite arbete.

Eftersom att 64-bitars heltal anv¨ands f¨or ¨overf¨oringen av data p˚a h¨ogre frekvens blir den maximala m¨atfrekvensen beroende av vilken typ av data som skickas fr˚an terminalerna. Anv¨andbarheten av v˚ar l¨osning hade kunnat p˚averkas negativt av detta men som redan n¨amnts ¨ar den vanligaste datatyp f¨or m¨atv¨arden med snabba f¨or¨andringar 16-bitars heltal. Dessutom ¨ar s¨attet att paketera v¨arden p˚a inte om¨ojligt att byta ut mot exempelvis anv¨anda en array eller str¨ang som buffer. Dessa tv˚a mer uppenbara alternativ valdes helt enkelt bort p˚a grund det blev problem att komma ˚at v¨ardena p˚a HiMacs-sidan. Sedan kan det finnas f¨ordelar med att skicka data med en primitiv datatyp f¨or att minimera datam¨angden vid ¨overf¨oring ¨aven om detta inte ¨ar n˚agot riktig flaskhals vad vi vet.

P˚a TwinCAT-sidan g˚ar det eventuellt att underl¨atta f¨or anv¨andaren vid kon-figurering f¨or att denne inte ska beh¨ova f¨orst˚a PLC-programmering. D˚a det endast kr¨aver ett f˚atal kodrader f¨or att l¨agga till kanaler med h¨ogre frekvens ¨

ar inte detta n˚agot stort problem men kan vara intressant f¨or kunden i de fall d˚a HiQ:s konsulter inte deltar vid installationen.

7.4

Reflektion kring eget l¨

arande

Projektet har innefattat mycket analys av nya system och nya utvecklings-milj¨oer. Detta har varit ett bra test p˚a att l¨ara sig f¨orst˚a en ny situation i utveckling av programvara. Vi har tidigare under utbildningen studerat och skapat realtidssystem och dess processhantering, n˚agot som kommit till anv¨andning framf¨orallt n¨ar TwinCAT-sidan skulle analyseras och program-meras.

Den breda kunskapen om programmeringsspr˚ak vi f˚att fr˚an v˚ar utbildning gav oss m¨ojligheterna att snabbt skapa en grundlig f¨orst˚aelse f¨or Structured Text.

Att jobba med programmering och mjukvaruutveckling ¨ar givetvis n˚agot vi sysslat med i utbildningen men vissa saker har varit nya f¨or oss. Analys av ett st¨orre befintligt system ¨ar n˚agot vi inte ¨ovat s¨arskilt mycket p˚a under utbildningen. Att prova p˚a programmering i arbetslivet har ocks˚a det varit en ny och nyttig erfarenhet.

Referenser

[1] Beckhoff, Verl: Beckhoff Automation GmbH and Co. KG, 2014. Bes¨oktes: 2015-04-10 URL: www.beckhoff.se/se/beckhoff/default.htm

[2] Dahl, Ola, “Realtidsprogrammering”, Studentlitteratur, 2004, ISBN 91-44-03130-0

[3] Srinivasan, Balaji; Pather, Shyamalan; Hill, Robert; Ansari, Furquan; Douglas, Niehaus, “A Firm Real-Time System Implementation Using Commercial Off-The-Shelf Hardware and Free Software”, Real-Time Te-chnology and Applications Symposium, 1998. Proceedings. Fourth IEEE, University of Kansas, ISBN: 0-8186-8569-7

[4] H. Kopetz , “Event-triggered versus time-triggered real-time systems”, Lecture Notes in Computer Science, Operating Systems of the 90s and Beyond, Heidelberg, Germany: Springer-Verlag, 1991, vol. 563

[5] Wang, Shiw-Yuan, “Evaluating and improving the TCP/UDP performan-ces of IEEE 802.11(p)/1609 networks”, Computers and Communications, 2008, ISCC 2008, Sid. 163-168, ISBN: 978-1-4244-2702-4

[6] University of Glasgow, “Real-Time Communication on IP Networks”, Real-Time and Embedded Systems Lecture 17, Bes¨oktes: 2015-05-19, URL: https://csperkins.org/teaching/rtes/lecture17.pdf

[7] Decotignie, J.-D., “Ethernet-Based Real-Time and Industrial Communi-cations”, Proceedings of the IEEE (Volume:93, Issue:6), Sid. 1102-1117, Neuchatel (Switzerland) : IEEE, 2005

[8] Cisco, “Carrier Sense Multi-Access/Collision Detection (CSMA/CD)”, Ethernet, Bes¨oktes: 2015-05-16, URL: http://www.cisco.com/en/US/ tech/tk389/tk214/tk125/tsd_technology_support_sub-protocol_ home.html

[9] Beckhoff, “Principle of Operation”, Beckhoff EtherCAT, Bes¨oktes: 2015-05-19, URL: http://support.multiprox.be/Beckhoff/Catalog/ english/ethercat/aufbau.htm?id=20433492043354

[10] Wang, Lei; Li, Mu Guo; Wang, Jing; Zhang Qun, “The Design and Performance Analysis for Real-Time EtherCAT Network Data Acquisi-tion System”, Intelligent Control and InformaAcquisi-tion Processing (ICICIP) - 2010 International Conference, sid. 466-469, Dalian (China) : IEEE, 2010, ISBN-10: 978-1-4244-7047-1

[11] Terhell, Daniel, “Windows and Real-Time”, Open System Re-sources Inc., The NT Insider 2014 Issue3 (Sept-Oct), Bes¨oktes: 2015-06-05, URL: https://www.osr.com/nt-insider/2014-issue3/ windows-real-time/

[12] Microsoft, “Introduction to Windows Service Applications”, Bes¨oktes: 2015-06-02, URL: https://msdn.microsoft.com/en-us/library/ d56de412%28v=vs.110%29.aspx

[13] Wang, Lifanf; Zhou, XingShe; Jiang, ZeJun; Zhang, Aihua, “A Real-Time Process Scheduling Policy in Windows”, 2012 International Con-ference on Computer Science and Service Systems, sid. 22-24, Nanjing : IEEE, ISBN: 978-1-4673-0721-5