Anybus CompactCom on mbed

EXAMENS ARBETE

Dataingenjör 180hp

Anybus CompactCom on mbed

F¨ orord

Denna rapport ¨ ar resultatet utav ett examensarbete som utf¨ ordes v˚ arterminen 2015 p˚ a HMS Industrial Networks AB i Halmstad. Examensarbetet ing˚ ar i h¨ ogskoleingenj¨ orsutbildningen med inriktning dataingenj¨ or p˚ a H¨ ogskolan i Halm- stad.

Ett stort tack riktas till PhD. Nicholas Wickstr¨ om f¨ or st¨ od och hj¨ alp med rap-

porten. Ett tack riktas ¨ aven emot HMS Industrial Networks AB, med Jonas

Green i spetsen, f¨ or att vi fick g¨ ora examensarbetet hos dem samt f¨ or den hj¨ alp

de erbjudit under arbetet.

Sammanfattning

D˚ a mjukvara som ¨ ar beroende utav h˚ ardvaruperiferi ska anv¨ andas p˚ a en ny plattform betyder detta att implementationen f¨ or denna h˚ ardvaruperiferi beh¨ over anpassas till den nya plattformen. Detta g¨ or att resurser anv¨ ands utan att egent- ligen tillf¨ ora n˚ agot till mjukvarans funktionalitet. Genom att utveckla mjukvara som ¨ ar plattformsoberoende sparas dessa resurser och kan anv¨ andas mer kon- struktivt d˚ a mjukvaran l¨ att kan ˚ ateranv¨ andas p˚ a en ny plattform.

Projektets m˚ al ¨ ar att porta en driver och g¨ ora denna plattformsoberoen-

de genom att initiera den h˚ ardvaruperiferi som drivern beh¨ over med hj¨ alp av

ARM mbeds bibliotek f¨ or h˚ ardvaruabstraktion. Genom att applicera vatten-

fallsmodellen med testdriven utveckling blev resultatet en fungerande prototyp

i form av ett mbed-bibliotek som validerades genom att anv¨ anda samma kod p˚ a

tv˚ a mbed-kompatibla plattformar. Detta resultat j¨ amf¨ ordes mot den existerande

drivern.

Abstract

When software dependent on hardware peripherals is used on a new platform the implementation requires adaptation of the hardware peripherals to the new platform. This means that resources are being used without bringing anything new to the software’s functionality. By developing cross-platform software these resources can be saved and used more constructively as the software easily can be reused on a different platform.

The goal of this project is porting a driver, and initiate its hardware perip-

herals and make it cross-platform enabled using ARM mbeds hardware abstrac-

tion library. By applying the waterfall model in combination with test driven

development the result is a functioning prototype as an mbed library, validated

by using the same code on different mbed-enabled platforms. This result was

compared to that of the existing driver.

Inneh˚ all

1 Inledning 1

1.1 Syfte . . . . 1

1.2 M˚ al . . . . 2

1.3 Avgr¨ ansningar . . . . 2

1.4 Fr˚ agest¨ allningar . . . . 2

2 Bakgrund 3 2.1 Anybus . . . . 3

2.1.1 Anybus CompactCom . . . . 3

2.1.2 Anybus objektmodell . . . . 4

2.2 Arduino shield . . . . 6

2.2.1 Arduino shield till Anybus CompactCom . . . . 6

2.3 Plattformsoberoende . . . . 7

2.3.1 CMSIS . . . . 7

2.3.2 Mbed . . . . 8

2.3.3 ASF . . . . 9

2.4 Vattenfallsmodellen . . . . 10

3 Metod 11 3.1 Utvecklingsmetodik . . . . 11

3.2 Projektets krav . . . . 11

3.2.1 MoSCoW . . . . 11

3.3 Mjukvarudesign . . . . 11

3.3.1 Inkapslingsobjekt . . . . 12

3.3.2 Objekt Design . . . . 13

3.3.3 Meddelandehantering . . . . 15

3.4 Implementation . . . . 17

3.4.1 Spr˚ akl¨ ankning . . . . 17

3.4.2 Testdriven utveckling . . . . 17

3.4.3 XP . . . . 17

3.5 Validering . . . . 18

3.5.1 White box testning . . . . 18

3.5.2 Black box testning . . . . 18

3.5.3 Grey box testning . . . . 18

4 Resultat 19 4.1 Analys av projektets krav . . . . 19

4.2 Design . . . . 20

4.2.1 Inkapsling utav C-driver . . . . 20

4.2.2 Design av Anybusobjekt . . . . 21

4.2.3 Meddelandehanterare . . . . 21

4.3 Implementation . . . . 22

4.3.1 Modularisering . . . . 22

4.3.2 Objektorienterad representation . . . . 23

4.3.3 Testdriven utveckling . . . . 24

4.4 Validering . . . . 24

4.4.1 Test emot ett n¨ atverk . . . . 25

4.4.2 Test av plattformsoberoende . . . . 26

4.4.3 Applikation med bibliotek fr˚ an mbed . . . . 26

4.4.4 Evaluering av krav . . . . 28

5 Diskussion 29 5.1 Samh¨ allsaspekter . . . . 30

6 Slutsats 31 Referenser 33 A Bilaga 1: Krav p˚ a projektet 37 B Bilaga 2: Projektets Tidsplan 39 Figurer 1 Anybus CompactCom module med EtherNet/IP gr¨ anssnitt. . . . 1

2 Robot kommunicerar med ett industriellt n¨ atverket via Anybus CompactCom. . . . 3

3 Objekt inneh˚ aller ett antal instanser. Instanserna inneh˚ aller i sin tur attribut. . . . 4

4 Kommunikation med Application Data Object. . . . 5

5 Arduino Proto Shield med Arduino standardens formfaktor.[5]. . 6

6 Applikationen kommunicerar med Anybus CompactCom via en Arduino shield. . . . 7

7 Demonstration utav hur pinben¨ amningen efter Ardunino stan- dard kan anv¨ andas till flera plattformar. . . . 9

8 Vattenfallsmodellen.[14] . . . . 10

9 Typisk Singleton deklaration. . . . 13

21 Kodexempel f¨ or den minimala koden som f˚ ar upp Anybus Com- pactCom p˚ a n¨ atverket med hj¨ alp av det nya biblioteket. . . . 27 22 Skapande och registrering av EtherNet/IP objekt. I exemplet de-

finieras produktnamn. . . . 27

Akrynomer

API: Application Programming Interface ASF: Atmel Software Framework

CMSIS: Cortex Microcontroller Software Interface Standard IDE: Integrated Development Environment

I

C: Inter-Integrated Circuit

GPIO: General-purpose input/output

SPI: Serial Peripheral Interface

XP: Extreme Programming

1 INLEDNING

1 Inledning

Mjukvara som anv¨ ander sig utav h˚ ardvaruperiferi ¨ ar h˚ art ihopknuten med just hur den aktuella utvecklingsplattformen initierar och anv¨ ander h˚ ardvaruperiferin.

Genom att dra nytta utav ett verktyg som anv¨ ander ett generellt s¨ att att ini- tiera denna h˚ ardvaruperiferi blir det l¨ attare att ˚ ateranv¨ anda mjukvaran p˚ a en ny utvecklingsplattform.

Ett s˚ adant utvecklingsverktyg ¨ ar mbed som erbjuds utav ARM. Genom att anv¨ anda mbed-kompatibla utvecklingsplattformar som f¨ oljer Arduino standard [1] kan utvecklaren skapa mjukvara som ¨ ar plattformsoberoende i den aspekt att alla mbed-kompatibla utvecklingsplattformar som f¨ oljer Arduino standard kan anv¨ anda sig utav samma kod.

F¨ or att utnyttja dessa egenskaper tillsammans med existerande mjukvara beh¨ over en anpassning till denna nya milj¨ o g¨ oras.

Uppdragsgivare till projektet ¨ ar HMS Industrial Networks AB. De arbetar med industriella n¨ atverk med ett fokus p˚ a att erbjuda l¨ osningar f¨ or kommunikation med olika industriella n¨ atverk. Den produkt som behandlas i denna rapport ¨ ar Anybus CompactCom varianten module, se Figur 1, som m¨ ojligg¨ or kommunika- tion mellan en enhet och ett industriellt n¨ atverk. F¨ or att anv¨ anda denna kr¨ avs en driver.

Figur 1: Anybus CompactCom module med EtherNet/IP gr¨ anssnitt.

1.1 Syfte

Syftet med projektet ¨ ar att utveckla ett bibliotek f¨ or Anybus CompactComs driver med hj¨ alp utav mbed. Detta ska g¨ ora det enklare f¨ or potentiella kunder att s¨ atta upp en applikation och testa funktionaliteten hos Anybus CompactCom.

Biblioteket kan g¨ oras plattformsoberoende genom att p˚ a f¨ orhand initiera den h˚ ardvarufunktionalitet som kr¨ avs, s˚ asom GPIO, SPI och timer. Kunden kan p˚ a s˚ a vis v¨ alja den mikrokontroller som l¨ ampar sig b¨ ast eller redan finns tillg¨ anglig.

Mbed erbjuder en l¨ osning f¨ or att initiera h˚ ardvarufunktionaliteten, oberoende

av vilken mbed-st¨ odd mikrokontroller med arduino interface som anv¨ ands. D˚ a

1 INLEDNING 1.2 M˚ al

biblioteket ¨ ar plattformsoberoende sparar kunden ¨ aven resurser i och med att denne inte beh¨ over implementera h˚ ardvaruperiferin.

1.2 M˚ al

M˚ alet med projektet ¨ ar att g¨ ora Anybus CompactComs driver plattformsobe- roende med hj¨ alp utav mbeds bibliotek f¨ or h˚ ardvaruabstraktion. Detta g¨ ors genom att initiera den h˚ ardvarufunktionalitet som beh¨ ovs f¨ or att driva Anybus CompactCom vilket tidigare gjordes utav anv¨ andaren.

En objektorienterad representation utav Anybus Objektmodell ska utvecklas samt en meddelandehanterare till denna. Det som ska skapas ¨ ar en prototyp som skall validera att mbed kan g¨ ora detta f¨ or Anybus CompactCom-drivern.

1.3 Avgr¨ ansningar

Det kommer inte g˚ a att anv¨ anda flera instanser utav Anybus CompactCom- drivern d˚ a det inte g˚ ar att ansluta flera moduler till samma utvecklingskort.

I sin f¨ orl¨ angning betyder det att endast en modul kommer kunna anv¨ andas i en applikation. Biblioteket kommer inte heller att ha st¨ od f¨ or alla industriella n¨ atverk. Detta beror p˚ a det stora antal utav industriella n¨ atverk som finns p˚ a marknaden vilket g¨ or att projektets tidsresurser inte r¨ acker till. Endast SPI kommer att anv¨ andas f¨ or kommunikation mellan modulen och utvecklingskortet eftersom den Arduino-shield som kommer att anv¨ andas som ett interface mellan modul och plattform endast st¨ odjer detta.

1.4 Fr˚ agest¨ allningar

• Hur portas ett existerande bibliotek utvecklat i C till mbed?

• Hur designas en objektorienterad anpassning av Anybus CompactCom- drivern till mbed?

• Hur valideras resultatet?

2 BAKGRUND

2 Bakgrund

2.1 Anybus

Anybus ¨ ar en familj av produkter framtagna utav HMS Industrial Networks AB. Dessa produkter anv¨ ands f¨ or att m¨ ojligg¨ ora kommunikation mellan och med olika industriella n¨ atverk [2].

2.1.1 Anybus CompactCom

En av produkterna i Anybus familjen ¨ ar Anybus CompactCom [3]. Denna pro- dukt ¨ ar skapad f¨ or att ge en enhet m¨ ojlighet att kommunicera med ett specifikt n¨ atverk.

Detta kan exempelvis anv¨ andas d˚ a en robot som hanterar produkter som r¨ or sig p˚ a ett produktionsband beh¨ over m¨ ojlighet att kommunicera den motor driver produktionsbandet samt andra robotar. Genom att ansluta en Anybus CompactCom till roboten g¨ ors det m¨ ojligt att kommunicera med ett specifikt industriellt n¨ atverk, se Figur 2.

Figur 2: Robot kommunicerar med ett industriellt n¨ atverket via Anybus Com- pactCom.

Genom att anv¨ anda Anybus CompactCom abstraheras datan som skickas i den n¨ atverksspecifika protokollet genom att denna ¨ overs¨ atts till generisk data och p˚ a s˚ a vis ges anv¨ andaren m¨ ojlighet att fokusera p˚ a hur datan ska hanteras ist¨ allet f¨ or att beh¨ ova behandla hela n¨ atverket.

Anybus CompactCom finns i tre olika utf¨ oranden. Dessa kallas Chip, Brick samt Module.

Module ¨ ar en fullst¨ andig produkt med n¨ atverkskort samt n¨ atverksinterface som g¨ or det m¨ ojligt att anv¨ andas direkt.

Chip och Brick erbjuder kunden att v¨ alja hur mycket utav h˚ ardvaran de vill

g¨ ora sj¨ alva f¨ or att det ska passa s˚ a bra som m¨ ojligt i deras produkt. Chip ¨ ar

exempelvis endast n¨ atverkskortet som kunden f˚ ar bygga in i sin produkt.

2 BAKGRUND 2.1 Anybus

2.1.2 Anybus objektmodell

Anybus anv¨ ander sig utav en objektmodell som fungerar p˚ a samma s¨ att oav- sett vilket industriellt n¨ atverk som anv¨ ands genom att dra nytta utav de olika n¨ atverkens likheter [4]. Objektmodellens uppgift ¨ ar att sortera och lagra data som i applikationen anv¨ ands f¨ or att skapa en struktur d¨ ar data som ¨ ar relevant f¨ or ett gemensamt ¨ andam˚ al h˚ alls inom samma objekt.

Figur 3: Objekt inneh˚ aller ett antal instanser. Instanserna inneh˚ aller i sin tur attribut.

Objekten inneh˚ aller i sin tur ett antal instanser d¨ ar data ytterligare delas in med relevant data, se Figur 3. Instanserna inneh˚ aller i sin tur ett antal attribut.

Dessa attribut inneh˚ aller den faktiska datan som lagras, tillsammans med ett namn som beskriver vad datan ¨ ar till f¨ or. Alla attribut ¨ ar inte n¨ odv¨ andiga f¨ or anv¨ andaren att implementera och antalet attribut skiljer sig beroende p˚ a objekt.

Genom att implementera ett objekt ger det en funktionalitet emot n¨ atverket.

2 BAKGRUND 2.1 Anybus

Figur 4: Kommunikation med Application Data Object.

I Figur 4 demonstreras hur data utbyts mellan ett n¨ atverk och ett objekt. Ap- plication Data Objects funktion ¨ ar att ¨ ar ett speciellt objekt och det inneh˚ aller den data som cykliskt utbyts med n¨ atverket, f¨ orutsatt att det ¨ ar implementerat.

Gemensamt f¨ or alla objekt ¨ ar de acykliska f¨ orfr˚ agningar som skickas ifr˚ an n¨ atverket. Denna f¨ orfr˚ agan ¨ ar riktad emot ett specifikt attribut genom att be- skriva vilket objekt, instans och attribut som ska l¨ asas. F¨ orfr˚ agan besvaras sedan med ett meddelande som inneh˚ aller v¨ ardet om objektet, instansen och attributet

¨ ar implementerat. Om objektet, instansen eller attributet inte ¨ ar implementerat

skickas ist¨ allet ett felmeddelande till modulen som beskriver vad som var fel.

2 BAKGRUND 2.2 Arduino shield

2.2 Arduino shield

Arduino shield ¨ ar en p˚ abyggnad till de utvecklingsplattformar som har Arduino interface. Dessa shields har Arduino standards formfaktor och kan p˚ a s˚ a vis l¨ att anslutas till utvecklingsplattformar. Figur 5 visar Arduino Proto Shield med Arduino standardens formfaktor.

Figur 5: Arduino Proto Shield med Arduino standardens formfaktor.[5].

2.2.1 Arduino shield till Anybus CompactCom

Till Anybus CompactCom har en shield skapats f¨ or att enkelt kunna samman-

koppla denna med en utvecklingsplattform med Arduino interface. P˚ a s˚ a vis ¨ ar

2 BAKGRUND 2.3 Plattformsoberoende

Figur 6: Applikationen kommunicerar med Anybus CompactCom via en Ardu- ino shield.

2.3 Plattformsoberoende

Plattformsoberoende mjukvara kan anv¨ andas p˚ a flera olika plattformar utan att beh¨ ova modifieras. Nedan f¨ oljer exempel p˚ a verktyg f¨ or att g¨ ora mjukvara plattformsoberoende.

2.3.1 CMSIS

ARM Cortex Microcontroller Software Interface Standard (CMSIS) [6] ¨ ar en h˚ ardvaruabstraktion utav Cortex-M processorer. CMSIS utvecklades f¨ or att un- derl¨ atta ˚ ateranv¨ andingen utav kod och p˚ a s˚ a vis spara resurser genom att erbju- da ett gemensamt API f¨ or att standardisera ˚ atkomsten av h˚ ardvarukomponenter hos Cortex-M baserade mikrokontrollerkort. CMSIS kan indelas i tre lager:

Core Peripheral Access Layer (CPAL)

CPAL ¨ ar det l¨ agsta lagret i CMSIS. H¨ ar definieras adresser och metoder f¨ or

˚ atkomst till de gemensamma komponenterna och funktionaliteten som finns i Cortex-M familjen, s˚ asom processorregister och NVIC.

Middleware Access Layer (MWAL)

MWAL lagret definierar ˚ atkomsten till periferin genom ett gemensamt API.

Detta lager anpassas till respektive mikrokontrollerkort av dess leverant¨ or.

Device Peripheral Access Layer (DPAL)

I DPAL definieras addresser till h˚ ardvaruregister tillsammans med den funktio-

nalitet som ¨ ar specifik f¨ or varje mikrokontrollerkort och erbjuds av dess leve-

rant¨ or.

2 BAKGRUND 2.3 Plattformsoberoende

2.3.2 Mbed

Mbed[7], utvecklat av ARM, bygger p˚ a CMSIS och ¨ ar skapad f¨ or utveckling ut- av ett stort antal ARM Cortex-M baserade utvecklingskort som f¨ oljer Arduino standard. ¨ Aven om processorchippet ¨ ar likadant p˚ a dessa kort kan implementa- tionen av periferin skilja sig beroende p˚ a tillverkare och modell [1].

Mbed ger utvecklaren m¨ ojlighet att anv¨ anda deras f¨ ordefinierade bibliotek

som abstraherar de h˚ ardvarurelaterade funktionerna s˚ asom SPI, GPIO och ti-

mers i dessa kort[8]. Detta bibliotek kan anv¨ andas av samtliga mbed-st¨ odda

plattformar med Arduino interface. H˚ ardvarufunktionaliteten deklareras genom

att man anger vilken pinne som funktionen skall knytas till. Denna pinne anges

efter Arduinostandardens namn, i.e. pinne 0 ¨ ar pinne D0 definierat i Ardui-

nostandarden [9]. Figur 7 visar hur utvecklingskorten LPCXpresso1549 [10] och

Nucleo L152RE [11] pinouts ¨ ar definierade. De gr¨ ona definitionerna beskriver

pinnens namn i enlighet med Arduino standarden medans den bl˚ aa definitio-

nen ¨ ar specifik f¨ or utvecklingskorten. Dessa definitioner anv¨ ands i koden f¨ or att

knyta ¨ onskad h˚ ardvarufunktionalitet till ¨ onskad pinne.

2 BAKGRUND 2.3 Plattformsoberoende

(a) LPCXpresso1549 Arduino headers.

(b) Nucleo L152RE Arduino headers.

Figur 7: Demonstration utav hur pinben¨ amningen efter Ardunino standard kan anv¨ andas till flera plattformar.

2.3.3 ASF

Atmel Software Framework (ASF) [12] ¨ ar ett mjukvarubibliotek som utges av

Atmel och ger en h˚ ardvaruabstraktion till utvecklingskort fr˚ an Atmel. Till skill-

2 BAKGRUND 2.4 Vattenfallsmodellen

nad fr˚ an CMSIS och mbed, som arbetar f¨ or att abstrahera de skillnader som finns i implementationen av utvecklingskort fr˚ an olika tillverkare erbjuder ASF en h˚ ardvaruabstraktion som ¨ ar specifik f¨ or sina egna kort.

2.4 Vattenfallsmodellen

Vattenfallsmodellen[13] ¨ ar en utvecklingsmetodik framtagen f¨ or mjukvaruut- veckling. Metoden specificerar projektets process genom att dela upp projek- tet i flera steg. Arbetet liknas vid ett fl¨ ode d¨ ar varje steg m˚ aste uppfyllas in- nan projektet kan g˚ a vidare till n¨ asta steg. Denna metod anv¨ ander sig utav l˚ angtidsplanering d¨ ar projektets milstolpar planeras in i b¨ orjan utav projektet.

Figur 8: Vattenfallsmodellen.[14]

Figur 8 demonstrerar vattenfallsmodellens fl¨ ode. Projektet p˚ ab¨ orjas genom att ta fram vilka krav som st¨ alls. Efter detta framst¨ alls en design f¨ or hur pro- jektet ska n˚ a de resultat som uppfylller kraven. Denna design st˚ ar sedan till grund f¨ or hur implementationen utav mjukvaran utf¨ ors. Implementationen ¨ ar den praktiska delen utav projektet d¨ ar funktionaliteten skapas utifr˚ an de de- signval som gjorts.

F¨ ordelar med denna utvecklingsmetod ¨ ar framf¨ or allt dess tydliga struktur

3 METOD

3 Metod

3.1 Utvecklingsmetodik

F¨ or att arbeta effektivt i ett projekt beh¨ ovs ett strukturerat och f¨ orbest¨ amt ar- betsm¨ onster eller arbetsmetod anv¨ andas. Detta hj¨ alper projektets medlemmar att veta vad de skall g¨ ora, b˚ ade i den n¨ armaste tiden men ¨ aven fram˚ at. Genom att anv¨ anda sig utav en f¨ orbest¨ amd arbetsmetod definieras projektets milstol- par. Datum s¨ atts f¨ or dessa i b¨ orjan utav projektet. Milstolparna beskriver n¨ ar resultat ska vara uppn˚ adda och vad resultatet utav dessa f¨ orv¨ antas vara [15].

3.2 Projektets krav

Kravanalys ¨ ar ett tidigt steg i mjukvaruutveckling och ¨ ar kritiskt f¨ or ett lyckat projekt. Genom att analysera kraven ¨ ar det l¨ attare att f¨ orst˚ a kraven och inse vilken betydelse dessa har f¨ or projektet [16].

3.2.1 MoSCoW

MoSCoW-metoden [17] ¨ ar en metod f¨ or att ta fram och prioritera krav i olika kategorier beroende p˚ a vilka konsekvenser det f˚ ar f¨ or projektet om dessa krav inte uppfylls. Kraven ordnas in efter:

”Must”, vilket ¨ ar krav som projektet m˚ aste uppfylla f¨ or att ¨ over huvud taget r¨ aknas som godk¨ ant. Ber¨ aknas dessa krav fr˚ an b¨ orjan vara om¨ ojliga att uppfyl- la finns ingen mening att forts¨ atta projektet. Detta kan vara krav som g¨ or en produkt olaglig eller medf¨ or en allt f¨ or h¨ og s¨ akerhetsrisk om de inte uppfylls.

”Should”, vilket ¨ ar krav som har h¨ og prioritet och ska uppfyllas om m¨ ojligt, men ¨ ar inte kritiska f¨ or att n˚ a ett godk¨ ant resultat. ¨ Onskad funktionalitet kan ofta uppn˚ as med en work-around om dessa krav inte uppfylls.

”Could”, vilket ¨ ar krav som ¨ ar ¨ onskv¨ arda att uppfyllas, men prioriteras bara om tid och andra resurser till˚ ater detta.

”Won’t”, detta ¨ ar projektets avgr¨ ansningar och inkluderar funktionalitet som

¨ ar ¨ onskv¨ ard att implementera i framtiden, men vars prioritet ¨ ar l¨ agst.

3.3 Mjukvarudesign

F¨ or att resultatet utav en mjukvaruutveckling skall n˚ a en h˚ allbar niv˚ a beh¨ ovs en mjukvarudesign. Denna tas fram efter att projektets krav framst¨ allts och med dessa i fokus tas en design fram f¨ or att kraven ska uppfyllas.

D˚ a projektet utvecklas i C++ b¨ or de f¨ ordelar som kommer med objektorien-

terad programmering, som inte finns i C, tas till vara. Detta handlar framf¨ orallt

om att applicera k¨ anda design patterns som kan l¨ osa de utmaningar som st¨ alls

3 METOD 3.3 Mjukvarudesign

vid en design utav mjukvara [18]. Dessa beskriver l¨ osningar som har anv¨ ants ota- liga g˚ anger och d˚ a ¨ aven utvecklats till mer och mer eleganta och l¨ attapplicerade l¨ osningar.

En annan viktig aspekt i objektorientrad programmering ¨ ar m¨ ojligheten till

˚ ateranv¨ andningsbar kod. Med detta menas att objekt kan utvecklas p˚ a ett s¨ att att det kan anv¨ andas i flera olika sammanhang. Genom att f¨ oredra objektkom- position ¨ over objektarv kan tv˚ a klasser utvecklas som tillsammans utg¨ or den funktionalitet som ¨ onskas, men som ¨ aven kan anv¨ andas vid andra tillf¨ allen.

Detta g¨ or att utvecklaren inte beh¨ over skapa ett helt nytt objekt varje g˚ ang ut- an kan ist¨ allet anv¨ anda sig utav de tidigare utvecklade objekten som har testats och fungerar.

3.3.1 Inkapslingsobjekt

Genom att skapa ett inkapslingsobjekt utnyttjas den objektorienterade pro- grammeringens f¨ orm˚ aga att kapsla in data och funktioner genom att tilldela dem egenskaperna public, protected och private. Det ideala ¨ ar att kapsla in s˚ a mycket information som m¨ ojligt, genom att deklarera datan som private, f¨ or att andra klasser inte skall kunna komma ˚ at dessa direkt. Ist¨ allet erbjuds funktioner f¨ or att komma ˚ at dessa, med hj¨ alp av egenskapen public [19].

Eftersom den shield, som anv¨ ands f¨ or att sammankoppla en Anybus CompactCom-modul med ett utvecklingskort, inte har st¨ od f¨ or flera moduler p˚ a ett kort kan det uppst˚ a problem om fler ¨ an en instans av drivern skapas.

D¨ arf¨ or beh¨ ovs en s¨ akerhets˚ atg¨ ard g¨ oras f¨ or att s¨ akerst¨ alla att anv¨ andaren inte sj¨ alvmant skapar fler instanser utav denna. L¨ osningar f¨ or detta ¨ ar att antingen anv¨ anda en statisk klass eller en singleton-klass [20].

Statisk klass

En statisk klass inneb¨ ar att den inte kan bli instansierad och inneh˚ aller statiska

metoder [21]. Denna funktionalitet kan anv¨ andas d˚ a ett objekt endast har me-

toder som bara opererar p˚ a input parametrar. Nackdelar med anv¨ andningen av

en statisk klass ¨ ar att denna endast till˚ ater statiska variabler.

3 METOD 3.3 Mjukvarudesign

class Singleton {

private:

static Singleton* _instance = 0;

Example(){};

public:

getInstance() {

if(_example = 0) {

_instance = Singleton();

}

return _instance;

} };

Figur 9: Typisk Singleton deklaration.

3.3.2 Objekt Design

Creational design patterns [18] beskriver hur skapandet av objekt ska ske. Po- lymorfism ¨ ar ett centralt begrepp f¨ or flera utav dessa patterns. Genom att f¨ orst se vad som ¨ ar gemensamt i alla objekt kan ett abstrakt objekt skapas som de konkreta objekten sedan ¨ arver ifr˚ an. I de konkreta objekten definieras de delar som ¨ ar specifikt f¨ or just det objektet medans det ¨ arver de generella delarna ifr˚ an den abstrakta klassen.

Tillv¨ agag˚ angs¨ attet f¨ or att skapa dessa objekt skiljer sig i design patterns beroende p˚ a vilket problem de ¨ amnar l¨ osa. Nedan beskrivs dessa.

Factory Method

Vid till¨ ampning utav polymorfism kan det vara sv˚ art f¨ or en klass att avg¨ ora vilket utav underklasserna som skall skapas. Factory Method[18] l¨ oser detta genom att f¨ orst skapa en abstrakt klass som beskriver hur nya produkter skall skapas. Denna klass kallas i exemplet i Figur 10 f¨ or Creator. Creator definierar vidare en metod d¨ ar skapandet utav nya produkter definieras.

I Figur 10 demonstreras en till¨ ampning av Factory Method d¨ ar parametern id best¨ ammer vilken underklass av Product som skapas.

Abstract Factory

Abstract Factory [18] anv¨ ands n¨ ar man vill erbjuda ett flertal objekt med be-

gr¨ ansningen utav att endast deras interface skall ges till anv¨ andaren och inte

dess implementation.

3 METOD 3.3 Mjukvarudesign

class Creator {

public:

virtual Product* Create(ProductId id) {

if(id==MINE) return new MyProduct();

if(id==YOUR) return new YourProduct();

return 0;

} };

Figur 10: Factory Method till¨ ampning.

Builder

Till skillnad fr˚ an de tv˚ a ¨ ovre designm¨ onstren bygger inte Builder [18] p˚ a poly- morfism, utan anv¨ ands d˚ a skapandet av ett objekt blir f¨ or komplext. Detta kan vara objekt som har m˚ anga konstruktorer med olika parametrar samt de objekt vars hela inneh˚ all m˚ aste skapas p˚ a en g˚ ang och inte kan fyllas p˚ a efter hand.

Exempel p˚ a detta kan vara objekt vars attribut har f¨ ordefinierade startv¨ arden och enbart till˚ ater f¨ or¨ andring av dessa vid ett tillf¨ alle. Problemet kan d˚ a upp- st˚ a att konstruktorer skapas med parametrar f¨ or varje attribut och dess olika kombinationer.

Detta problem l¨ oser Builder genom att metoder f¨ or att skapa sm˚ a delar av

objektet anropas varefter objektet byggs ihop och h¨ amtas i sin helhet. Figur 11

visar detta som ett sekvensdiagram.

3 METOD 3.3 Mjukvarudesign

3.3.3 Meddelandehantering

N¨ ar m˚ anga objekt beh¨ over kommunicera med varandra kan en meddelandehan- terare skapas.

Mediator

Denna meddelandehanterare kan bygga p˚ a designm¨ onstret Mediator [18] vars funktion ¨ ar att l˚ ata en klass agera nod i ett n¨ atverk av m˚ anga objekt som dirigerar meddelanden mellan objekten, f¨ or att l˚ ata objekten slippa ha referenser till varandra. Ett klassdiagram som beskriver detta visas i Figur 12.

Figur 12: Mediator

3 METOD 3.3 Mjukvarudesign

Chain of Responsibility

Aven Chain of Responsibility [18] ¨ ¨ ar ett design pattern som kan appliceras p˚ a en meddelandehanterare genom att l˚ ata meddelandet vandra i en kedja, d¨ ar varje l¨ ank utg¨ ors av ett objekt som antingen hanterar meddelandet eller skickar det vidare i kedjan. Ett exempel p˚ a detta design pattern visas i Figur 13.

Figur 13: Chain of Responsibility

3 METOD 3.4 Implementation

3.4 Implementation

D˚ a mjukvarudesignen har tagits fram beh¨ ovs en metod f¨ or att till¨ ampa denna praktiskt. Den kod som ¨ ar n¨ odv¨ andig f¨ or att n˚ a de resultat som motsvarar de krav som st¨ alls p˚ a projektet skall implementeras men ¨ aven testas under utvecklingens g˚ ang f¨ or att minimera risken f¨ or buggar d˚ a samtliga delar utav mjukvaran s¨ atts ihop till det kompletta resultatet.

3.4.1 Spr˚ akl¨ ankning

F¨ or att kunna kompilera C-kod i en C++ kompilator beh¨ over en spr˚ akl¨ ankning g¨ oras. Detta inneb¨ ar att samtliga header-filer till C-koden deklareras s˚ asom vi- sas i Figur 14 vilket g¨ or att denna del utav koden ist¨ allet kompileras emot en C kompilator [22].

#ifdef __cplusplus extern "C"{

#endif

#import "c_header.h"

#import "another_c_header.h"

#ifdef __cplusplus }

#endif

#include "cpp_header.h"

Figur 14: Spr˚ akl¨ anking fr˚ an C till C++.

3.4.2 Testdriven utveckling

En metod som kan anv¨ andas vid implementation utav kod ¨ ar testdriven utveck- ling. Utvecklingen i denna metod sker genom att utvecklaren f¨ orst beskriver den

¨ onskade funktionaliteten f¨ or ett kodstycke eller en funktion. D¨ arefter s¨ atts upp ett antal testfall upp som t¨ acker samtliga till˚ atna och otill˚ atna scenarion f¨ or att se till att den faktiska funktionaliteten ¨ overensst¨ ammer med den f¨ orv¨ antade.

Genom att sedan producera minimal kod f¨ or att koden ska passera testen bildas en testdriven utveckling [23].

3.4.3 XP

Extreme programming(XP) [24] utvecklades som ett hj¨ alpmedel f¨ or sm˚ a team

inom mjukvaruutveckling f¨ or att l¨ attare hantera f¨ or¨ andring i de krav som st¨ alls

p˚ a ett projekt. XP bygger till stor del p˚ a konstant testande och uppdelningen av

projektet sker i sm˚ a steg, d¨ ar tidsplan s¨ atts f¨ or timmar och minuter, j¨ amf¨ ort med

veckor och m˚ anader i andra metoder. En viktig aspekt XP ¨ ar pair programming.

3 METOD 3.5 Validering

Pair programming

Pair programming [25] bygger p˚ a att programmering av mjukvara g¨ ors av ett par samarbetande utvecklare vid samma dator. De tv˚ a programmerarna har tv˚ a olika roller, ”Driver” och ”Observer”, som byts med j¨ amna mellanrum. Driverns uppgift ¨ ar att aktivt producera kod. Detta ¨ ar personen som sitter med kontroll

¨ over mus och tangentbord. Medan drivern utvecklar koden fokuserar Observern p˚ a att dubbelkolla stavning och syntax i koden samt att planera och t¨ anka ut en design av mjukvarans n¨ asta steg.

Pair programming medf¨ or att b˚ ada utvecklarna fokuserar mer tid p˚ a att utveckla mjukvara och mindre tid p˚ a s˚ adant som inte ¨ ar n¨ odv¨ andigt f¨ or utveck- lingen, s˚ asom att l¨ asa mail och ta telefonsamtal p˚ a grund av det grupptryck som g¨ or att utvecklarna inte vill sl¨ osa varandras tid. Probleml¨ osningen sker

¨

aven snabbare d˚ a programmerarna arbetar i ett par d˚ a dessa l¨ attare kan bolla id´ eer med varandra och komma fram till en b¨ attre l¨ osning. Kunskap delas ¨ aven konstant mellan programmerarna vilket g¨ or att deras l¨ arande sker snabbare ¨ an om de hade arbetat individuellt.

3.5 Validering

F¨ or att validera och verifiera funktionalitet hos mjukvara, samt att m˚ alen ¨ ar uppn˚ adda l¨ ampar sig mjukvarutester. F¨ or att validera att r¨ att mjukvara skapas anv¨ ands ofta black box testning. F¨ or att verifiera att mjukvaran skapas r¨ att anv¨ ands ofta white box testning. [26]

3.5.1 White box testning

White box testning [26] ¨ ar en testmetod som inriktar sig emot tester utav den

inre delarna av ett system. Testaren har generellt god kunskap om systemets inre

struktur och testar enskilda funktioner. Genom att anv¨ anda white box testning

s¨ akerst¨ alls det att systemet fungerar i alla sina delar. En nackdel kan dock vara

den stora m¨ angd tid som kan kr¨ avas vid komplexa test.

4 RESULTAT

4 Resultat

4.1 Analys av projektets krav

De krav som st¨ alldes p˚ a projektets finns i Bilaga 2. Dessa krav analyserades med hj¨ alp av av MoSCoW-metoden f¨ or att definiera varje kravs betydelse f¨ or projektet. Resultatet utav denna analysering ger en prioritering utav vilka krav som ¨ ar n¨ odv¨ andiga f¨ or projektet och vilka krav som ¨ ar ¨ onskad funktionalitet men som inte ¨ ar ett m˚ aste f¨ or att projektets resultat ska fungera som det ¨ ar t¨ ankt.

D˚ a krav som enligt MoSCoW-metoden definieras som MUST ¨ ar n¨ odv¨ andiga f¨ or projektet och b¨ or d¨ arf¨ or tillfredsst¨ allas innan fokus g˚ ar ¨ over p˚ a krav som definieras som SHOULD eller COULD.

Projektets krav bed¨ omdes som f¨ oljer.

• Krav 1, Det ska inte vara m¨ ojligt att skapa flera instanser av Anybus CompactCom-drivern:

SHOULD

Kravet togs fram d˚ a det i dagsl¨ aget inte ¨ ar m¨ ojligt att anv¨ anda flera Any- bus CompactCom-moduler p˚ a ett utvecklingskort med Arduino-anslutning.

Det inte ¨ ar kritiskt att kravet uppfylls f¨ or att n˚ a en fungerande prototyp d˚ a detta l¨ att kan uppfyllas genom att inte skapa fler instanser av drivern.

• Krav 2, Plattformen ska kunna startas om fr˚ an mjukvaran:

COULD

Med detta menas att b˚ ade modul och utvecklingskort ska kunna startas om ifr˚ an applikationen. Detta ¨ ar ett krav p˚ a ut¨ okad funktionalitet som ef- terfr˚ agas av uppdragsgivaren. Funktionaliteten ¨ ar inte p˚ a n˚ agot vis kritisk f¨ or projektets framg˚ ang och prioriteras d¨ arf¨ or l˚ agt.

• Krav 3, Drivern ska kunna initieras och ta sig upp p˚ a n¨ atverket:

MUST

Om detta krav inte uppfylls fallerar projektet d˚ a dess huvuddel handlar om n¨ atverkskommunikation. Utan detta g˚ ar det heller inte att testa n˚ agot.

• Krav 4, Den existerande drivern i C ska l¨ amnas som den ¨ ar:

MUST

F¨ or att underl¨ atta f¨ or framtida uppdateringar togs detta krav fram p˚ a f¨ orfr˚ agan av uppdragsgivaren vilket inneb¨ ar att en inkapsling av den exi- sterande drivern m˚ aste g¨ oras.

• Krav 5, H˚ ardvarufunktionalitet s˚ asom GPIO, SPI och timer ska initieras oberoende utav mbed-mikrokontroller:

MUST

Kravet speglar projektets huvudsyfte. Uppfylls inte detta anv¨ ands ¨ aven

mbed inkorrekt och projektet blir s˚ aledes inte avklarat.

4 RESULTAT 4.2 Design

• Krav 6, M¨ ojlighet att registrera applikations- och n¨ atverksobjekt ska fin- nas:

MUST

Utan detta g˚ ar det inte att testa eller validera programmets funktionalitet

• Krav 7, Ett n¨ atverksobjekt ska vara skapat:

MUST

Detta kr¨ avs f¨ or att kunna f¨ orse modulen med grundfunktionaliteten f¨ or n¨ atverket. Ett f¨ orslag fr˚ an uppdragsgivaren ¨ ar att detta interface ska vara mot EtherNet/IP.

• Krav 8, Get/Set-funktionalitet f¨ or attributen i applikations- och n¨ atverksobjekten ska finnas:

MUST

Utan m¨ ojlig ˚ atkomst till objektens attribut g˚ ar det inte att testa att r¨ att v¨ arde finns i attributen.

4.2 Design

4.2.1 Inkapsling utav C-driver

Med h¨ ansyn till Krav 4 utformades ett inkapslingsobjekt som ett lager f¨ or an-

passning till mbed runt den existerande Anybus CompactCom-drivern. Detta

gjordes genom att inkludera de aktuella filerna ifr˚ an denna till inkapslingsob-

jektet. Genom att identifiera de funktioner som f¨ orv¨ antas finnas tillg¨ angliga

f¨ or anv¨ andaren skapas motsvarande metoder i inkapslingsobjektet inom vilka

direkta anrop g¨ ors till relevant funktion i drivern. P˚ a s˚ a vis beh˚ alls det interfa-

ce som redan innan finns emot denna driver. Figur 15 illustrerar hur anropen

mellan inkapslingsobjekt och h˚ ardvarufunktionalitet sker via drivern, ¨ aven fast

h˚ ardvarulagret ligger i inkapslingsobjektet.

4 RESULTAT 4.2 Design

4.2.2 Design av Anybusobjekt

F¨ or att lagra den data som kr¨ avs av Anybus objektmodell har tre klasser desig- nats enligt Figur 16. En av dessa ¨ ar Attribute, som lagrar attributens data. En annan klass ¨ ar Instance, vilket inneh˚ aller en map av Attribute samt accessors och mutators till dessa. Den tredje klassen, Anybus BaseObj, ¨ ar en abstrakt klass som inneh˚ aller en map av Instance samt metoder f¨ or hantering av de med- delanden som skickas till objekten. De objekt som beh¨ ovs i applikationen ¨ arver ifr˚ an denna abstrakta klass, och enbart implementation av den objektspecifika funktionaliteten g¨ ors.

Figur 16: Objektmodell.

Valet utav att anv¨ anda en map ist¨ allet f¨ or en array f¨ or att hantera instanser och attribut grundas i Anybus Objektmodell. Den s¨ ager att det inte ¨ ar obliga- toriskt att implementera samtliga instanser eller attribut som finns beskriva i objektmodellen. Eftersom en map ¨ ar dynamisk s˚ a ger det m¨ ojlighet f¨ or att skapa de instanser och attribut och l¨ agga in dem i en sorterad struktur. D˚ a samtliga instanser och attribut kommer med ett index kan detta index anv¨ andas som key i mapen och p˚ a s˚ a vis ¨ ar det enkelt att h¨ amta ut dessa eller avg¨ ora om dessa inte ¨ ar implementerade och allts˚ a inte inlagda i strukturen.

4.2.3 Meddelandehanterare

F¨ or att hantera de meddelanden som kommer ifr˚ an modulen designades klas- serna som en Chain of Responsibility. De objekt som finns beh¨ over inte kom- municera med varandra direkt, utan ett meddelande skickas mellan modulen och applikationen. Detta meddelande har en tydlig destination vilket g¨ or att Mediator inte l¨ ampar sig v¨ al f¨ or detta. Meddelandehanteringen fungerar genom ett meddelande skickas genom en kedja av objekt d¨ ar varje objekt i kedjan best¨ ammer om detta kan besvara den f¨ orfr˚ agan som finns inuti meddelandet eller om fr˚ agan ska passas vidare. Meddelandehanteraren erbjuder en publik funktion g¨ or det m¨ ojligt att registrera objekt till den interna strukturen.

Figur 18 visar hur relationerna ifr˚ an MsgHandler till Attribute ¨ ar. Rent

konkret tar MsgHandler emot ett meddelande ifr˚ an modulen och kollar ifall

4 RESULTAT 4.3 Implementation

Figur 17: Meddelandehantering.

det objekt som beskrivs i f¨ orfr˚ agan finns registrerat. Om det inte finns skickas d˚ a ett felmeddelande tillbaka till modulen som beskriver att det efterfr˚ agade objektet inte var implementerat. Om objektet d¨ aremot finns s˚ a skickas f¨ orfr˚ agan vidare till objektets Handle. P˚ a liknande vis forts¨ atter f¨ orfr˚ agan sin v¨ ag emot attributet. Om objektet, instnansen och attributet, beskrivet i f¨ orfr˚ agan, ¨ ar implementerat h¨ amtas v¨ ardet som finns i Attribute och skickas till modulen. P˚ a s˚ a vis best¨ ammer varje l¨ ank i kedjan om den har m¨ ojlighet att svara meddelandet eller om den beh¨ over skicka vidare fr˚ agan.

4.3 Implementation

Projektets utveckling skedde i tv˚ a delar. Den f¨ orsta delen innebar att kapsla in Anybus CompactComs-driver i ett C++ objekt. Den andra delen av utveck- lingen handlade om att utveckla ny funktionalitet och skapa en objektorienterad representation utav Anybus Objektmodell samt en meddelandehanterare.

4.3.1 Modularisering

Denna implementation handlade inte om att utveckla ny funktionalitet utan

att ˚ aterge driverns funktioner i en ny milj¨ o. Eftersom drivern redan erbjuds till

HMS kunder kan det antas att den ¨ ar v¨ altestad och d¨ arf¨ or ¨ ar vidare testning

4 RESULTAT 4.3 Implementation

direkt fr˚ agar modulen om vilket tillst˚ and denna befinner sig i. Detta ¨ ar dock ingen bra l¨ osning eftersom all kommunikation mellan drivern och modulen g˚ ar

¨ over samma medium och d¨ arf¨ or tar detta upp on¨ odig plats. Ist¨ allet kan man l˚ ata drivern rapportera hela v¨ agen upp till inkapslingsobjektet. Detta inneb¨ ar att problemet ist¨ allet handlar om encapsulation. D˚ a tillst˚ andet b¨ or represente- ras med en privat variabel inom inkapslingsobjektet f¨ or att f¨ orhindra att detta

¨ andras utifr˚ an beh¨ ovs en metod f¨ or att drivern skall kunna uppdatera denna variabel. Om en publik metod hade implementerats hade detta inneburit att

¨ aven anv¨ andaren hade haft m¨ ojlighet att ¨ andra tillst˚ and, vilket inte ¨ ar till˚ atet d˚ a detta styrs av modulen. Ist¨ allet utnyttjades C++ nyckelord friend[29]. Ge- nom att deklarera den funktion i drivern som vill uppdatera tillst˚ andet som friend ger det denna funktion till˚ atelse att se och modifiera privata variabler inom inkapslingsobjektet.

4.3.2 Objektorienterad representation

Implementationen utav den objektorienterade representationen utav Anybus Objektmodell samt den meddelandehanterare som anv¨ ands till denna gjordes utifr˚ an de tidigare satta designvalen.

Implementation sker ifr˚ an grunden och d¨ arf¨ or m˚ aste denna implementation testas grundligt f¨ or att s¨ akerst¨ alla funktionaliteten. Den testades d¨ arf¨ or f¨ or sig innan den lades till i driverns funktionalitet. Testerna skapades genom att poten- tiella meddelanden skapades manuellt och skickades in i meddelandehanteraren.

Exempelvis lades objekt nummer 1, se Figur 18 ,till i meddelandehanteraren.

I det objektet var ¨ aven instans nummer 1 implementerat. I denna instans var

¨ aven attribut nummer 1 och 3 implementerat. D¨ arefter skickades ett medde- lande adresserat till objekt 1, instans 1, attribut 1. Genom att verifiera att meddelandehanteraren svarade med v¨ ardet i attribut 1 bekr¨ aftas det att med- delandehanteraren kan h¨ amta v¨ arden n¨ ar de ¨ ar implementerade. Det testades

¨

aven att skriva meddelande riktat till objekt nummer 1, instans nummer 1,

attribut 2 f¨ or att verifiera att meddelandehanteraren svarade att attributet in-

te var implementerat. Test gjorde ocks˚ a riktat till objekt 1, instans 2 f¨ or att

verifiera att meddelandehanteraren svarade att instansen inte var implemente-

rad. Slutligen testades s˚ a att r¨ att svar gavs d˚ a meddelandet fr˚ agade efter ett

objekt inte var implementerat. D˚ a dessa test gick igenom verifierades det att

funktionaliteten var som f¨ orv¨ antad.

4 RESULTAT 4.4 Validering

Figur 18: Exempel p˚ a ett Objekt d¨ ar Instans 1 ¨ ar implementerad med Attribut 1 och 3.

4.3.3 Testdriven utveckling

Som metod f¨ or att implementera biblioteket i mbed anv¨ andes testdriven ut-

veckling. Detta l¨ ampade sig v¨ aldigt bra f¨ or b˚ ada delarna utav implementation

men av olika anledningar. F¨ or den f¨ orsta delen d¨ ar drivern kapslades in anv¨ andes

testdriven utveckling som en verifikation utav att detta gjordes p˚ a r¨ att s¨ att. Med

hj¨ alp utav en exempelapplikation skapad av HMS kunde ett scenario s¨ attas upp

i C. Detta scenario efterh¨ armades sedan med dess motsvarighet i C++ genom

4 RESULTAT 4.4 Validering

scenario bygger vidare p˚ a en befintlig exempelapplikation som HMS erbjuder sina kunder och bygger p˚ a att ett antal instanser definieras med dess attribut.

N˚ agra utav dessa l¨ aggs till i den cykliska I/O datan och andra g˚ ar endast att l¨ asa ut via acykliska f¨ orfr˚ agningar. D¨ arefter skapas ett test f¨ or detta scenariot i form av ett Python-script som appliceras p˚ a den nuvarande Anybus CompactCom- drivern skriven i C. Detta test ¨ ar en modifierad variant av ett av de test HMS anv¨ ander och efterliknar EtherNet/IPs beteende och testet ses d¨ arf¨ or som ett black box test. Vid en viss f¨ orfr˚ agan eller tillf¨ alle f¨ orv¨ antas ett visst resultat utan att unders¨ oka att alla delar inom systemet g¨ ors p˚ a korrekt s¨ att. D˚ a resultatet st¨ ammer ¨ overens med det f¨ orv¨ antade resultatet kan prototypens funktionalitet bekr¨ aftas.

4.4.1 Test emot ett n¨ atverk

F¨ or att verifiera att prototypen ¨ ar kompatibel med ett n¨ atverk anv¨ andes EIPscan [30] som verktyg. Detta ¨ ar ett program vilket k¨ ors p˚ a en PC. Genom att kopp- la samman prototypen med datorn, se Figur 19 , ¨ ar det m¨ ojligt att skapa en anslutning med prototypen.

Figur 19: Anybus CompactCom utbyter data med det industriella n¨ atverket via en ethernet kabel.

D˚ a programmet och prototypen har anslutits startar utbytet utav den cyklis- ka datan. I prototypen anv¨ andes Application Data Objektet som ¨ ar ansvarigt f¨ or den cykliska datan. Det vill s¨ aga attribut i detta objekt uppdateras med den data som finns tas emot i den cykliska datan.

De v¨ arden som tas emot anv¨ andes f¨ or att styra statusen hos fyra LEDs som befinner sig p˚ a Anybus CompactCom shielden. Genom att ¨ andra v¨ ardet p˚ a aktuell data i EIPscan var d˚ a det f¨ orv¨ antade resultatet att motsvarande LED p˚ a shielden skulle lysa eller slockna. Detta testades b˚ ade genom att ¨ andra ett v¨ arde i taget men ¨ aven genom att byta flera utav dem p˚ a samma g˚ ang. Resultatet utav dessa tester visade att datan togs emot som f¨ orv¨ antat.

F¨ or att verifiera att ¨ aven de v¨ arden som applikationen skriver till n¨ atverket

lades ytterligare tv˚ a v¨ arden in i applikationen. Dessa uppdaterades genom att

knappar p˚ a shielden trycktes ned. Genom att verifiera att v¨ ardet ¨ andrades i

4 RESULTAT 4.4 Validering

EIPscan ¨ ar ¨ aven detta resultat det f¨ orv¨ antade.

4.4.2 Test av plattformsoberoende

F¨ oreg˚ aende test har skett p˚ a tv˚ a de plattformarna Nucleo-L152RE fr˚ an STM samt LPCXpresso1549 fr˚ an NXP. D˚ a b˚ ada korten anv¨ ander samma bibliotek och passerar testen ¨ oppnar det f¨ or att detta fungerar f¨ or fler mbed-kompatibla plattformar. Figur 20 demonstrerar hur samma kod anv¨ ands p˚ a b˚ ada plattfor- marna.

Figur 20: Samma kod anv¨ ands p˚ a b˚ ada plattformarna.

4.4.3 Applikation med bibliotek fr˚ an mbed

4 RESULTAT 4.4 Validering

#include "Abcc.h"

int main(){

ABCC* abcc;

abcc = ABCC:GetInstance();

while(1){

switch(abcc->RunModule()){

case ABCC_Driver_Setup:

abcc->UserInitComplete();

break;

} } }

Figur 21: Kodexempel f¨ or den minimala koden som f˚ ar upp Anybus Com- pactCom p˚ a n¨ atverket med hj¨ alp av det nya biblioteket.

...

Anybus_EIPObj* eip = new Anybus_EIPObj();

eip->SetProductName("Robot3");

abcc->RegisterObject(eip);

...

Figur 22: Skapande och registrering av EtherNet/IP objekt. I exemplet definie-

ras produktnamn.

4 RESULTAT 4.4 Validering

4.4.4 Evaluering av krav Krav Uppfyllt Beskrivning

1 Ja F¨ or att uppfylla detta krav konstruerades inkaps- lingsobjektet som en Singleton.

2 Nej Kravet hade l˚ ag prioritet och resurser lades p˚ a att uppfylla de andra kraven. Utvecklingskorten har med sitt Arduino-interface en reset-pinne. N¨ ar denna s¨ atts l˚ ag startas kortet om. Genom att anv¨ anda den shield som sitter p˚ a kortet till att s¨ atta denna pinne l˚ ag hade kravet kunant uppfyllas.

3 Ja Kravets uppfyllnad verifierades genom att utl¨ asa den information som finns p˚ a modulens tv˚ a leds.

4 Ja Ingen modifiering av drivern gjordes, ist¨ allet skapa- des ett lager runt denna f¨ or anpassning till mbed.

5 Ja Detta gjordes genom att anv¨ anda mbeds initiering av h˚ ardvarufunktionaliteten. Biblioteket kan anv¨ andas med samma kod av minst tv˚ a olika plattformar.

6 Ja Biblioteket inneh˚ aller en meddelandehanterare med funktionalitet f¨ or att registrera generella Anybusob- jekt.

7 Ja Ett objekt f¨ or EtherNet/IP skapades.

8 Ja Funktionalitet f¨ or Get och Set finns i det abstrak- ta objektet som applikations- och n¨ atverksobjekten

¨ arver.

5 DISKUSSION

5 Diskussion

Projektet var utformat f¨ or att unders¨ oka om det gick att anv¨ anda mbed f¨ or att g¨ ora Anybus CompactCom plattformsoberoende vilket resultaten visar ¨ ar m¨ ojligt. D˚ a projektet inte hade tillg˚ ang till fler ¨ an tv˚ a olika plattformar har detta endast testats p˚ a dessa tv˚ a. Det ¨ ar troligt att konceptet fungerar f¨ or alla mbed- kompatibla plattformar med Arduino interface eftersom samtliga anv¨ ander sig utav samma bibliotek f¨ or h˚ ardvaruabstraktionen.

F¨ or skapandet utav objekten som beskrivs av Anybus Objektmodell valdes att inte f¨ olja n˚ agot design pattern fullt ut. Det som ¨ ar utvecklat ¨ ar ist¨ allet de ob- jekt som Abstract Factory eller Factory Method (Se 3.3.2) sedan skulle skapa f¨ or applikationen. Dessa creational patterns ¨ overfl¨ odiga och i v¨ arsta fall f¨ or komplicerade f¨ or det h¨ ar projektet. Det problem som de i m˚ anga fall l¨ oser ¨ ar att erbjuda anv¨ andaren f¨ arre klasser och p˚ a s˚ a vis f¨ arre namn att h˚ alla reda p˚ a. Detta l¨ ampade sig inte i detta projekt eftersom varje objekt motsvarar en funktionalitet emot n¨ atverket. D¨ arf¨ or skapar anv¨ andaren de objekt som skall anv¨ andas genom att ange vilket objekt de vill anv¨ anda. Om n˚ agon utav des- sa factories hade implementerats hade det ¨ aven begr¨ ansat HMS m¨ ojlighet att publicera biblioteket eftersom att anv¨ andaren inte kan ¨ andra implementationen utav ett bibliotek. D¨ arf¨ or hade HMS varit tvugna att implementera samtliga objekt innan biblioteket publicerades ist¨ allet f¨ or att ge anv¨ andaren m¨ ojlighet att implementera saknade objekt.

Utvecklingen utav dessa objekt med hj¨ alp av polymorfism g¨ or det v¨ aldigt enkelt f¨ or framtida utvecklare att bygga p˚ a biblioteket med de kvarst˚ aende ob- jekten. De beh¨ over d˚ a endast implementera de objektspecifika metoderna f¨ or det nya objektet.

Ett design pattern som hade kunnat anv¨ andas vid instansiering utav objek- ten till Anybus Objektmodell skapas ¨ ar Builder (Se 3.3.2). Eftersom Builder till¨ ampas f¨ or att f¨ orst bygga ihop de olika komponenterna inom ett objekt hade detta gjort det m¨ ojligt f¨ or att s¨ akerst¨ alla att anv¨ anderen har implementerat samtliga komponenter denne vill ha innan objektet skapas. Genom att ¨ aven till¨ ampa Singleton (Se 3.3.1) i Builder hade det s¨ akerst¨ allt att endast ett objekt utav samma underklass blir skapat. Inspiration fr˚ an detta designm¨ onster togs vid de olika objektens skapande. Exempel p˚ a detta ¨ ar objektet f¨ or EtherNet/IP, som har enskilda metoder f¨ or att s¨ atta ett startv¨ arde p˚ a olika attribut i objek- tet. D˚ a dessa attribut inte f˚ ar modifieras p˚ a annat s¨ att ¨ an via ett meddelande fr˚ an modulen d˚ a denna ¨ ar ig˚ ang hade en fortsatt p˚ abyggnad av Builder l¨ ampat sig f¨ or att s¨ akerst¨ alla att dessa attribut bara kan skapas innan start.

D˚ a projektet enbart var en prototyp lades f˚ a resurser p˚ a att optimera biblioteket.

Vid en vidareutveckling hade d¨ arf¨ or minnesanalys och optimering l¨ ampat sig

f¨ or att se var gr¨ ansen g˚ ar f¨ or vilka utvecklingsplattformar som kan anv¨ anda

biblioteket.

5 DISKUSSION 5.1 Samh¨ allsaspekter

5.1 Samh¨ allsaspekter

Projektet ¨ ar riktat emot att erbjuda ett bibliotek som finns tillg¨ angligt online p˚ a mbed. Detta ska f¨ orhoppningsvis sprida teknologin till omr˚ aden d¨ ar denna inte funnits tidigare. D˚ a kunderna beh¨ over spendera mindre resurser p˚ a att skapa en fungerande applikation kundens ekonomiska tillv¨ axt gynnas. Projektet bidrar ¨ aven positivt ur ett h˚ allbarhetsperspektiv, d˚ a anv¨ andaren av biblioteket g¨ or det m¨ ojligt f¨ or anv¨ andaren att anv¨ anda en utvecklingsplattform de redan och p˚ a s˚ a vis ˚ ateranv¨ anda sin h˚ ardvara ist¨ allet f¨ or att k¨ opa in ny.

D˚ a projektet har g˚ att ut p˚ a att ˚ aterge Anybus CompactComs driver i en ny milj¨ o har projektet i sig inte adderat n˚ agon funktionalitet emot n¨ atverk som kan p˚ averka samh¨ allet negativt.

Projektet inneb¨ ar ¨ aven f¨ ordelar f¨ or ekonomin eftersom anv¨ andaren utav bib- lioteket inte beh¨ over s˚ a mycket resureser f¨ or att testa om Anybus CompactCom

¨ ar en l¨ osning f¨ or dem.

6 SLUTSATS

6 Slutsats

Resultaten visar att projektets m˚ al ¨ ar uppfyllda och fr˚ agest¨ allnignarna ¨ ar besva- rade. Ett bibliotek i C++ har utvecklats det ¨ ar m¨ ojligt att, med hj¨ alp av mbed, g¨ ora Anybus CompactComs driver plattformsoberoende. Genom att dra nytta utav mbeds h˚ ardvaruabstraktion till mbed-kompatibla plattformar med Ardu- ino standard kan anv¨ andaren enkelt byta plattform utan att beh¨ ova adaptera h˚ ardvarupereferi till den nya plattformen.

D˚ a design patterns ofta beskrivs v¨ aldigt generellt ¨ ar det sv˚ art men ¨ aven

¨ ovefl¨ odigt att f¨ olja helt. Det viktiga ¨ ar att se vilket problem de l¨ oser och hur l¨ osningen ser ut. Genom att anv¨ anda en modifierad variant utav dessa kan man, kanske, f˚ a en b¨ attre l¨ osning f¨ or det specifika problemet.

Kravet om att l¨ amna drivern som den ¨ ar och l¨ agga ett lager f¨ or anpassning

mot mbed runt denna har till stor del p˚ averkat de designval som gjorts d˚ a detta

mbed-anpassade lager m˚ aste samverka med driverns funktioner.

6 SLUTSATS

REFERENSER REFERENSER

Referenser

[1] Mbed Platforms,

https://developer.mbed.org/platforms/?form-factor=5, 2015. [Onli- ne; accessed 15-May-2015].

[2] Anybus Fieldbus and Ethernet connectivity solutions, www.anybus.com, 2015. [Online; accessed 07-June-2015].

[3] Anybus CompactCom

40-series,

http://www.anybus.com/products/AnybusCompactCom40.shtml, 2015.

[Online; accessed 15-May-2015].

[4] Anybus CompactCom 40 Software Design Guide,

http://anybus.com/upload/Anybus-CompactComM40Module-2178-AnybusCompactCom40SoftwareDesignGuide.

pdf, 2015. [Online; accessed 15-May-2015].

[5] http://www.arduino.cc/en/Main/ArduinoProtoShield, 2015. [Online;

accessed 07-June-2015].

[6] http://www.doulos.com/knowhow/arm/CMSIS/CMSIS_Doulos_Tutorial.

pdf, 2015. [Online; accessed 07-June-2015].

[7] ARM mbed Developer Site,

https://developer.mbed.org/, 2015. [Online; accessed 15-May-2015].

[8] Mbed Libraries,

https://developer.mbed.org/users/mbed_official/code/mbed/, 2015.

[Online; accessed 15-May-2015].

[9] Mbed in a Nutshell,

http://husk.eecs.berkeley.edu/courses/cs294-84-fall14/index.

php/Mbed_in_a_Nutshell, 2015. [Online; accessed 15-May-2015].

[10] LPCXpresso,

https://developer.mbed.org/platforms/LPCXpresso1549/, 2015. [Onli- ne; accessed 15-May-2015].

[11] NUCLEO-L152RE,

https://developer.mbed.org/platforms/ST-Nucleo-L152RE/, 2015.

[Online; accessed 15-May-2015].

[12] Embedded Software Solution for Atmel Flash MCUs,

http://asf.atmel.com/docs/latest/, 2015. [Online; accessed 09-June- 2015].

[13] Sommerville, Ian. ”Software process models.” ACM Computing Surveys

(CSUR) 28.1 (1996): 269-271.

REFERENSER REFERENSER

[14] ”Waterfall model” by Peter Kemp / Paul Smith - Adapted from Pa- ul Smith’s work at wikipedia. Licensed under CC BY 3.0 via Wikime- dia Commons, http://commons.wikimedia.org/wiki/File:Waterfall_

model.svg#/media/File:Waterfall_model.svg, 2015. [Online; accessed 15-May-2015].

[15] The Benefits of Adhering to Software Development Methodology Concepts, http://www.seguetech.com/blog/2013/07/23/

benefits-adhering-software-development-methodology-concepts, 2015. [Online; accessed 15-May-2015].

[16] Maguire, Martin, and Nigel Bevan. ”User requirements analysis.” Usability.

Springer US, 2002. 133-148.

[17] Hatton, Sarah. ”Choosing the right prioritisation method.” Software Engi- neering, 2008. ASWEC 2008. 19th Australian Conference on. IEEE, 2008.

[18] Gamma, E., R. Helm, R. Johnson, J. Vlissides. Design Patterns: Elements of Reusable Object-Oriented Software. Addison-Wesley, Reading, MA, 1995.

[19] Snyder, Alan. ”Encapsulation and inheritance in object-oriented program- ming languages.” ACM Sigplan Notices. Vol. 21. No. 11. ACM, 1986.

[20] Singleton VS. Static Classes,

http://www.c-sharpcorner.com/UploadFile/akkiraju/

singleton-vs-static-classes/, 2015. [Online; accessed 15-May-2015].

[21] Static Classes and Static Class Members,

https://msdn.microsoft.com/en-us/library/79b3xss3.aspx, 2015.

[Online; accessed 15-May-2015].

[22] Compatibility of C and C++,

http://en.cppreference.com/w/cpp/language/language_linkage,

2015. [Online; accessed 15-May-2015].

REFERENSER REFERENSER

[27] Linzhang, Wang, et al. Generating test cases from UML activity diagram based on gray-box method.Software Engineering Conference, 2004. 11th Asia-Pacific. IEEE, 2004.

[28] Map - C++ Reference,

http://www.cplusplus.com/reference/map/map/, 2015. [Online; accessed 15-May-2015].

[29] http://www.cplusplus.com/doc/tutorial/inheritance/, 2015. [Onli- ne; accessed 07-June-2015].

[30] http://network.pyramidsolutions.com/software-products/

development-testing-tools/ethernetip-scanner-simulator-eipscan/,

2015. [Online; accessed 07-June-2015].

REFERENSER REFERENSER

A BILAGA 1: KRAV P˚ A PROJEKTET

A Bilaga 1: Krav p˚ a projektet

• 1 Det ska inte vara m¨ ojligt att skapa flera instanser av Anybus CompactCom- drivern

• 2 Modulen ska kunna startas om fr˚ an mjukvaran

• 3 Drivern ska kunna initieras och ta sig upp p˚ a n¨ atverket

• 4 Den existerande drivern i C ska l¨ amnas som den ¨ ar

• 5 H˚ ardvarufunktionalitet s˚ asom GPIO, SPI och timer ska initieras obero- ende utav mbed-mikrokontroller

• 6 M¨ ojlighet att registrera applikations- och n¨ atverksobjekt ska finnas

• 7 Ett n¨ atverksobjekt ska vara skapat

• 8 Get/Set-funktionalitet f¨ or attributen i applikations- och n¨ atverksobjekten

ska finnas

A BILAGA 1: KRAV P˚ A PROJEKTET

B BILAGA 2: PROJEKTETS TIDSPLAN

B Bilaga 2: Projektets Tidsplan

Figur 23

Oliver Brunnegård Dataingenjör

Högskolan i Halmstad 2015 Daniel Westerlund

Dataingenjör

Högskolan i Halmstad 2015