FRA SENSOR TIL WEB TIL MONITOR

af

Mikkel Helge Rasmussen

Kurt Jeritslev

Slutopgave i Sustainable electronic and IT (SUSIE)

Ingeniørhøjskolen I København

d. 03-01.2013

RESUMÉ

Fra Sensor til Web til Monitor

En rapport dækkende processen fra dataopsamling til præsentation på Internettet.

En sensor leverer data via en trådløs overførsel til en hoved-controller, der efterfølgende sender data

videre til en web-server, hvor de præsenteres og kan tilgås af evt. relevante brugere for videre anvendelse.

Det udviklede system kan benyttes til ’proof of concept’ for f.eks. temperaturovervågning, monitorering

af luftkvalitet, monitorering af ventilationsbehov og lignende applikationer.

Dette dokument beskrivelser hele procesforløbet – med hovedvægt på hvilke kommunikationsprotokoller

og –standarder (Zig(X)Bee, IEEE 802.15.4, IP, TCP, IEEE 802.3, IEEE 802.2), der finder anvendelse i

løsningsmodellen.

Desuden omhandles Life Cycle Assesment (livscyklusvurdering) for en del af de indgående enheder, idet

den valgte løsning med trådløs overførsel af data fra sensor til hoved-controller sammenholdes med en

tilsvarende fast trådet løsningsmodel.

Endelig diskuteres en række aspekter ved andre løsningsmodeller, når der opereres med mange

sensorer/aktuatorer, herunder forskellige energimæssige aspekter ved forskellige løsninger.

i

INDHOLDSFORTEGNELSE

Indledning ................................................................................................... 1 Undersøgelsens formål ............................................................................................ 1 Oversigt over valgt løsningsmodel ........................................................................ 1

Detaljer i løsningsmodellen (Hardware-software) ....................................... 3 Sensor ........................................................................................................................ 3 Aktuator .................................................................................................................... 3 XBee kommunikationsprotokol ............................................................................. 5 XBee topologi .......................................................................................................... 7 XBee opsætning. ...................................................................................................... 8 XBee kommunikation. ............................................................................................ 9 Arduino I-Board sw-programflade. .....................................................................11 Arduino-Internet interface (w5100) .....................................................................12 Cosm server application (interface og protokoller) ...........................................18 Konklusion Hardware-Software ..........................................................................21

Energibehov, fremskaffelse og forbedringsmuligheder ............................ 22 Livscyklusvurdering (LCA, MECO) .......................................................... 25

XBee ........................................................................................................................26 Solcelle og genopladelig batteri ............................................................................26 Trådet løsning ........................................................................................................26 Konklusion LCA, MECO ....................................................................................27 Diskussion af forbedringsmuligheder set fra et LCA perspektiv .....................27

Konklusion ’fra sensor til web til monitor’ ................................................. 28 Diskussion af forbedringsmuligheder..................................................................28

Kommentarer til susie kurset ..................................................................... 29 Diskussion af forbedringsmuligheder..................................................................29

Appendiks.................................................................................................. 31

ii

ORDLISTE

LCA. Life Cycle Assesment (livscycklusvurdering) er en række metoder, der benyttes til vurdering af et produkts miljømæssige belastning ’fra vugge til grav’.

MECO er en række metoder til at vurdere de miljømæssige forbrug/konsekvenser over et produkts levetid (fra vugge til grav,) når det drejer sig om Materials, Energy, Chemicals og Other.

Sensor. En mekanisk/elektronisk enhed, der afgiver et elektrisk signal, når det påvirkes af en bestemt fysisk begivenhed – f.eks. en temperatursensor, luftfugtighedssensor..osv.

Aktuator. En elektronisk/mekanisk enhed, der udfører en bestemt elektronisk/mekanisk handling, når det påvirkes af et elektrisk signal – f.eks. en elektronisk styret ventil, dørlås…osv.

XBee. Et elektronisk modul til trådløs overførsel af data med udgangspunkt i IEEE 802.15.4. Tillader punkt-til-punkt kommunikation eller netværkskommunikation.

Arduiono. Open Source single board Microcontroller.

IP. Internet Protocol – a sæt regler der finder anvendelse ved kommunikation over Internettet Internet.

TCP. Transmission Control Protocol – en af hovedprotokollerne, der anvendes ved IP internetkommunikation.

IEEE. Institute of Electrical and Electronics Engineering.

1

Kapitel 1

INDLEDNING

Brugen af (trådløse) målesensorer kombineret med vedvarende energikilder åbner nye mulighed for at foretage mere omfattende og detaljere studier af f.eks. miljøforhold end det tidligere var praktisk muligt.

Undersøgelsens formål

Formålet med indeværende øvelse er at afprøve de forskellige metoder, der finder anvendelse ved udviklingen af bæredygtig elektronik. Dvs. designe under hensyntagen til et begrænset strømforbrug leveret af en vedvarende energikilde, vurdere hvorledes designet kan optimeres til minimal energiforbrug, samt vurdere hvilke ressourcer og energimængder et design kræver i produktets levetid. Endelig laves en sammenlignende MECO analyse mellem 2 forskellige implementeringer af sensorelektronikken (trådløs hhv. trådet udgave). Opgavespecifikationen fremgår af appendiks 1.

Oversigt over valgt løsningsmodel

Den valgte løsning fremgår af figur 1 på næste side - yderste højre kolonne, der viser en sensor koblet på et XBee end-modul: De målte data sendes trådløst til et XBee-coordinator modul installeret sammen med en Arduino microprocessor med tilhørende Ethernet interface. Den valgte løsning registrer lysintensitet – specielt ved lavere belysninger. De målte data sendes 1 gang i minuttet via XBee moduler og Arduino til en web-applikation på cosm.com, hvor data kan vises og senere hentes via en almindelig webbrowser koblet på internettet (illustreret med PC’en yderst til venstre). Det er tanken at den målte lysintensitet via en remote pc-webbrowser anvendes til at styre en eksterns lyskilde (der ikke påvirker den registrerede måling). Vi har i opgaveløsningen lagt vægt på de protokoller og processer, der indgår fra sensor til web-service. Egentlig hardware design mv. er holdt på et absolut minimum for at kunne afprøve hele systemflowet. På de efterfølgende sider gennemgås hardware og software i detaljer.

2

Figur 1 viser processen fra sensorregistrering til webapplikation til Monitor

3

Kapitel 2

DETALJER I LØSNINGSMODELLEN

(HARDWARE-SOFTWARE)

Sensor

Sensorer anvendes til at omsætte fysiske størrelse som temperatur, tryk, luftfugtighed, luftforurening/kvalitet mv. til elektriske størrelser, der efterfølgende kan benyttes til at foretage en egentlig overvågning af den fysiske størrelse og (om ønskeligt) på baggrund af den målte størrelse træffe beslutning om at ændre de fysiske forhold, som sensoren registrerer. Eksempelvis ved anvendelse af en temperaturmåler til efterfølgende styring af et varmeelement via en ren elektrisk styring eller vha. en aktuator el.lign. – se nedenfor; en lysmåling anvendt til automatisk tænding af nødbelysning, en luftkvalitetsmåling til styring af udluftning osv. Vi har valgt at måle ’dagslys’-lysintensiteten ved svage niveauer med henblik på f.eks. styring af kunstig belysning i et drivhus, tænding af udendørs/indendørslys el.lign.

Ved lave lysintensiteter leverer en solcelle en outputspænding som er proportional1 med lysintensiteten, hvorfor en måling af denne vil give mulighed for at detektere lave lysværdier. Den anvendte solcelle kan levere op mod 3 Volt ved maksimal indstråling (med Schottky diode og batteri forbundet, så batteriet oplades – se senere). XBee analoge input tillader en inputspænding på maximum 1.2 Volt i forbindelse med A-D konvertering, hvorfor der er indsat en spændingsdeler parallelt med solcellen og midtpunktet er forbundet til XBee’s analoge input.

Aktuator

Aktuatorer anvendes til at omsætte elektriske signaler til fysisk/mekaniske bevægelser som f.eks. åbne et vindue, låse en dør, aktivere et relæ, dreje en antenne osv.. Eftersom opgaveformuleringen ikke stiller krav om anvendelse af aktiv styring i end-noden, har vi valgt ikke at realisere noget sådant. Vi vil dog diskutere nogle af de fundamentale problemstillinger omkring en sådan styring senere.

1 http://www.pveducation.org/pvcdrom/solar-cell-operation/effect-of-light-intensity viser output fra solcelle som funktion af lysintensistet og belastningsmodstand. Bemærk at outputspændingen ændres meget drastisk ved meget lav lysintensitet, samt at hældningen på kurven kan justeres vha f.eks. en parallelmodstand over solcellen, hvis det ønskes.

4

Solcelle og Power Supply til sensor/aktuator

Et XBee modul kan operere med en forsyningsspænding på 2.1 – 3.6 Volt. Udnyttes ’sleep’ funktionen kan strømforbruget nedsættes væsentligt – ligesom strømforbruget nedsættes med faldende forsyningsspænding, hvorfor en lav spænding kan være en fordel med henblik på at spare energi. Det er derfor valgt at forsyne XBee end-modulet med ca. 2.4 Volt fra 2 seriekoblede genopladelige batterier. Som følge heraf er valgt en solcelle på 70cm^2 (den havde vi til rådighed), der via en Schottky-diode (for lavt spændingstab) forsyner et genopladeligt batteri, så systemet kan holdes i drift over en længere periode uden sollys.

Fra Appendix 2 samt energi beregnings kapitlet, hvor detaljer og beregninger fremgår, skal fremhæves: Average supply current of sensor circuit and XBee (incl. leakage current in rechargeable battery): 0.9 mA Average supply power of sensor circuit and XBee ( …do……+ loss in schottkydiode ………………….) : 2.5 mW Safety factor of selected solar area: 55 x theoretical needed value (please refer to appendix) Battery capacity needed for 48 hours of operation without sunlight: 43 mAh Expected lifetime with no daylight to recharge: 100 days Placed in inside in a window frame facing outwards - In winter indirect sunlight (no direct sunlight) it charges the battery with 2.4 Volt, 1.3mA ie. 3.2 mW ! (just enough, but far below SolarCellEffiencyIndoor with no safetyfactor). When placed in a window exposed to direct winter sun in the afternoon the battery charges at 2.4V, 15 mA ie. 36 mW which is well above the needed demand. (efficiency 0.005 compared to full daylight intensity). The glass window will modify the spectrum of the direct sunlight thus changing the efficiency too. For at opnå en bedre energiudnyttelse bør der sættes en power booster mellem solcellen og det genopladelige batteri, så solcellen altid bliver holdt på max-power-output punktet. (Vi har valgt ikke at optimere på dette felt, med mindre tiden tillader). Ydermere bør der anvendes batterier med meget lav lækstrøm. (Vi har helt bevidst valgt almindelige NiMH batterier netop for at se hvor godt de performer). Såfremt XBee anvendes til at styre en aktuator kan det være nødvendigt med separat/dubleret power supply/regualator til aktualtorelektronikken grundet krav til spænding- og strømniveauer.

5

XBee kommunikationsprotokol

Kommunikationen mellem de forskellige XBee enheder er trådløs, og bruger ZigBee protokollen til at styre denne. Selve ZigBee protokollen består kun af de tre øverste lag (applikation, transport og netværk), da den bruger IEEE 802.15.4 standardens specifikation af de to nederste lag i protokol stakken. Selvom ZigBee protokollen benytter sig af forskellige lag som de fleste andre netværksprotokoller, så er der en væsentlig forskel. Hvor man normalt kan ændre i de forskellige lag i en protokol hvis man har brug for at håndtere dette lags opgaver på en anden måde, så er dette ikke muligt i ZigBee protokollen. Dette er fordi ZigBee protokollen er designet ud fra IEEE 802.15.4 standarden, og bruger direkte nogle af dens specielle mekanismer.

PHY og MAC laget. Hovedopgaverne i PHY laget er at transportere bits over det fysiske radiomedie, mens MAC laget sørger for at der kun kan kommunikeres med en af gangen, ved brug af carrier sense multiple access with collision avoidance (CSMA/CA). Begge disse lag bygger som beskrevet tidligere på IEEE 802.15.4 standarden, og ZigBee bruger derfor også det samme MAC adresse format som IEEE 802.15.4 gør, der inkluderer muligheden for at bruge korte adresser, der kun er 16 bits lange. I teorien vil dette betyde at hvert ZigBee netværk der bruger denne opsætning kun kan være på op til 65.536 nodes, i praksis vil nogle af disse adresser dog være reserveret til andre ting som f.eks. broadcasts, så det reelle antal af nodes vil være lidt mindre. MAC laget i IEEE 802.15.4 sørger udover collision control også for at verificere om en pakke er blevet modtaget korrekt, ved at udveksle acknowledgments med den anden part, og om nødvendigt sende pakken igen. ZigBee protokollen bruger dog ikke alle ting fra IEEE 802.15.4 standarden, som bl.a. beacon mode der kan synkronisere netværkets nodes, men som dog ville øge kompleksiteten af ZigBee protokollen, og derfor er undladt. NWK laget. Adressering og routing er hovedopgaverne i NWK laget. Til det bruges der to former for data levering; broadcasts og unicasts. Multicasts understøttes også, men bliver her udført som et broadcast med efterfølgende filtrering af de pakker der blev sendt til de modtagere der ikke skulle modtage dem. Broadcasts sender den samme pakke ud til alle nodes på netværket, men kan begrænses til kun at kunne bevæge sig igennem et bestemt antal nodes. Det er dog stadig en dyr operation der lægger meget pres på

6

netværket. Unicasts derimod sendes kun til den node de er adresseret til, men kræver at netværket kan finde ud af at route pakkerne ordentligt. I ZigBee findes der to måder at route på; network routing og source routing. I source routing specificer man som afsender præcis den vej man vil sende sin pakke, hvilket kan være smart i store netværk hvor de enkelte nodes routing table ellers ville blive meget stor. Source routing er dog kun tilgængeligt i ZigBee Pro. Network routing fungerer i kraft af at alle nodes har en routing table som de kan slå op i, for at finde ud af hvor de skal sende en pakke hen for at den ender det rigtige sted. Der er to forskellige måder at lave network routing på; mesh routing og tree routing. Ved tree routing bruger man en træ struktur hvor coordinatoren er root, end nodes er leaf nodes og alt i mellem er routere, mens man i mesh routing ofte forbinder routerne på kryds og tværs. Tree routing er ikke muligt i ZigBee Pro. Som udgangspunkt kender de forskellige nodes ikke hinanden før man skal til at sende en pakke ud. Før den sendes ud sender man nemlig en routing request ud til alle nodes i netværket, der når de modtager den opdaterer deres routing table med hvilken node de skal sende deres pakker til hvis de skal sendes til den node der sendte routing requesten ud. Alle nodes ved nu hvordan de kommer hen til vores start node, og kan nu svare tilbage til den. Men for at start noden også kan sende pakker til den node den vil kommunikere med, skal routing tablen også opdateres den anden vej. Det sker når routing requesten når den specificerede node, der så sender et unicast svar tilbage til start noden. Når det svar bliver sendt af sted gennem den routing path der tidligere blev opdaget da routing requesten blev sendt ud, opdaterer hver node som svaret passerer deres routing tables igen, så de nu har finder ud af hvordan man kommer til den specificerede node fra start noden. Så snart svaret er modtaget igen hos start noden er der altså etableret en vej gennem netværket, og man kan begynde at udveksle pakker. APS sublaget. Er et tyndt lag der har til opgave at filtrere duplikerede pakker fra samt at udveksle acknowledgements for at sikre sig at det er de rigtige pakker der er nået frem. AF laget. AF laget binder de kørende applikationer eller profiles som de hedder i ZigBee, sammen med de pakker der kommer gennem protokol stakken. Hver ZigBee profil er identificeret med et tal mellem 0 og 240 der bliver kaldt for et end point, og som fungerer på samme måde som et port nummer i IP stakken. Når en pakke modtages sendes indholdet til den applikation der er registreret med det end point der følger med pakken, og hvis der ikke er noget registreret smides pakken bare væk. End pointet 0 er dog reserveret til ZDO profilen. ZDO laget / profilen. Er teknisk set ikke et lag, men er en slags kontrol applikation der startes op i AF laget, og har til opgave at sætte netværket op og holde styr på bl.a. netværkets sikkerhed. Det opererer derfor også i ZWK og APS lagende, foruden AF laget.

7

XBee topologi Netværk topologi beskriver hvordan et netværk er sat sammen, eller hvilke nodes der er forbundet til hinanden. I vores projekt har vi ikke brugt nodes nok til at kunne komme ind på netværk topologi, men i større netværk er det vigtigt at man tænker lidt over hvordan man sætter sit netværk sammen, alt efter hvad man ønsker at opnå. Herunder findes en kort gennemgang af nogle af de mest normale netværk topologier, der dog også sagtens kan blandes og bruges sammen i det samme netværk. Mesh topologi. I et mesh netværk kan de forskellige routere enten være forbundet til alle andre routere i netværket (kaldet full mesh), eller de kan bare være forbundet til et par andre routere (partial mesh). Begge måder resulterer normalt i at der er mange alternative router fra en node til en anden, hvilket er en af de største fordele ved et mesh netværk. Det betyder nemlig at netværket kan fungere selvom en enkelt node går ned, og resulterer kun i at trafikken bliver sendt over andre nodes i stedet. Internettet er et mesh netværk. Star topologi. De fleste hjemmenetværk er sat op i en star topologi, der betyder at alle nodes er forbundet til en central node i midten. Styrken ved dette er at det er meget simpelt at holde styr på, og at netværket ikke går ned hvis en af ydernoderne går ned. Men det betyder også at hele netværket går ned hvis der sker noget med den centrale node. Ring topologi. Hver node er forbundet til to og kun to andre nabo nodes, således at de forskellige nodes sidder i en slags seriel forbindelse der danner en ring. Trafikken går enten med eller mod uret, men altid i samme retning. Fordelen ved en ring topologi er at der ikke skal bruges nogen central node for at holde styr på netværket, til gengæld kan man ikke ændre i de forskellige nodes uden at netværket påvirkes, og i værste fald går ned. Udover disse tre findes der også tree og bus topologierne. I bus topologien er alle nodes forbundet til det samme kabel, det fungerer dog kun godt i små netværk, mens tree topologien fungerer som en masse star netværk der er sat sammen i et træ format. Valget af den rette topologi kommer altså meget an på størrelsen af netværket, og om hvordan man vil have netværket skal fungere hvis der er en node der går ned.

8

XBee opsætning.

XBee delen af vores projekt består af en endnode der skal sende nye målinger direkte til en coordinator efter et bestemt interval. Fordi setupet er ret simpelt har vi også ladet endnoden styre hvornår målingerne skal sendes, i modsætning til at lade coordinatoren bede endnoden om at sende en ny måling efter det samme interval. Vores begrundelse for dette valg var at det var mere simpelt, og at vi ikke havde brug for de fordele der ville komme ud af at styre det i coordinatoren, der især kommer til udtryk i et netværk med flere endnodes hvor kan være smart at styre det hele det samme sted. Da vi gerne vil formindste energi forbruget af vores endnode så meget som muligt har vi også valgt at holde den i sleep mode så længe den ikke sender data af sted. For at sætte netværket op mellem vores endnode og coordinator skal deres PAN ID sættes til det samme tal, og deres destination address skal sættes til den andens adresse. PAN ID'et sørger for at de tilslutter sig det samme netværk, mens destinationsadressen definerer hvilken node de skal sende data til. Derudover skal API Enable sættes til 1 da vi bruger API mode uden escape characters. I endnoden skal vi også definere på hvilken pin vores input kommer ind, og sætte IO sampling rate der styrer hvor ofte vi læser værdien af dette input. Endelig sættes sleep mode til cyclic sleep, der får noden til at gå i sleep mode i et interval der defineres i cyclic sleep period, før den sender en måling af sted på netværket og derefter går tilbage i sleepmode.

9

XBee kommunikation.

Vores XBee devices har 5 forskellige modes de hele tiden står og skrifter i mellem. Idle mode er normaltilstanden hvor XBee enheden ikke gør noget, og det er kun herfra man skifte til et af de andre fire modes (og fra dem kan man kun skifte tilbage til idle mode). I command mode kan man ændre på opsætningen af enheden, mens man i sleep mode sparer energi men bliver nødt til at blive vækket igen (enten via. tid eller en ved at ændre værdien af en pin) før enheden er funktionel igen. I transmit mode sender den data fra dens serial transmit buffer afsted på netværket, og i receive mode modtager den data fra netværket og placerer det i sin serial transmit buffer. Det vil sige at når begge vores XBee moduler er sat op og tændt, vil endnoden starte op og skrifte til transmit mode hvor den vil tage et data sample fra det definerede input pin og sende den afsted mod coordinatoren ved hjælp af den tidligere beskrevet ZigBee protokol. Coordinatoren vil skifte til receive mode hvor den modtager dataene fra endnoden som den placerer i sin serial transmit buffer i nedenstående format.

ZigBee IO Data Sample Rx Indicator, fra det officielle datasheet.

10

ZigBee protokollen sikrer at data overførelsen er lykkedes ved at sende en acknowledgement tilbage til endnoden, der når denne modtages skifter til sleep mode, mens coordinatoren skifter tilbage til idle mode. Modtages denne acknowledgement ikke i endnoden bliver dataene sendt igen. Det kan også ske at acknowledgementet går tabt selvom coordinatoren modtog dataene, hvilket vil betyde at coordinatoren vil modtage det samme data igen, fordi endnoden gik ud fra den ikke var modtaget. ZigBee protokollen har ingen måder at filtrere disse duplikerede pakker fra, så det skal gøres i selve applikationen hvis denne kun skal modtage en måling af gangen. Dette acknowledgement styres i ZigBee protokollens netværks lag. I vores projekt sker der ikke noget ved at lade vores applikation modtage den samme data måling igen, så vi har ikke forsøgt at filtrere dem fra. Hvis det var nødvendigt kunne det i et system som vores med meget lang tid mellem vores målinger, gøres ved at måle tiden mellem hver modtaget måling, og hvis målingen var den samme og modtaget indenfor kort tid af den anden kunne man der ignorere den anden måling.

11

Arduino I-Board sw-programflade.

Vores program starter med at starte en 9600 baud rate seriel forbindelse op der senere bruges til at læse hvad der bliver sendt til vores XBee coordinator. Derefter forsøger vi at forbinde til internettet ved at bede DHCP protokollen om at give os en IP adresse. Lykkes det ikke forsøger vi at oprette en forbindelse med en statisk IP adresse i stedet for. Vi forsøger nu at læse en modtaget pakke, når vi kan se at vi har data nok i vores XBee coordinators serial transmit buffer til at en hel pakke kan være modtaget. Hvis den første byte er start byten 0x7E forsøger vi at verificere resten af den modtagende pakke, ved at tjekke om de bytes vi har i bufferen passer med formatet på den pakke vi regner med at modtage fra XBee endnoden. I denne proces tjekker vi bl.a. om pakken kommer fra den rigtige node ved at tjekke adressen, og om pakken er kommet sikkert over ved at lave et checksum check, hvor vi udregner en checksum og sammenligner med den vi har modtaget. Passer pakkens format ikke starter vi forfra og venter igen på at der er nok data i bufferen til at en pakke kan være modtaget. Verificerer vi en pakke starter vi en forbindelse op til port 80 på cosm serveren (hvor HTTP sendes igennem) og hvis det lykkes, sender vi en HTTP PUT request med vores data til serveren. Selve formattet beskrives senere i rapporten. Til sidst flusher vi det respond vi får fra cosm serveren for at gøre plads i bufferen til næste respond. Vi kunne godt tjekke at vi får en ACK fra serveren, men i dette projekt sender vi en ny pakke hvert 20. sekund, og synes derfor ikke det giver mening at forsøge at sende gammelt data igen selvom første forsendelse mislykkedes. Men det er helt sikkert noget man burde gøre i andre tilfælde. Resten af koden er tjeks der sørger for at der ikke opstår fejl hvis noget uventet skulle opstå.

12

Arduino-Internet interface (w5100)

Arduino I-board har en on-borad W5100 Ethernet interface controller2:

“The W5100 is a full-featured, single-chip Internet-enabled 10/100 Ethernet controller designed for embedded applications where ease of integration, stability, performance, area and system cost control are required. The W5100 has been designed to facilitate easy implementation of Internet connectivity without OS. The W5100 is IEEE 802.3 10BASE-T and 802.3u 100BASE-TX compliant.” Ethernettet anvender Carrier Sense Multiple Access with Collision Detection (CSMA/CD), hvor en node, der ønsker at sende noget, venter til der er ’tomt’ på linien. Dernæst sendes af sted. Mens der sendes, monitoreres der på linjen for at sikre at der ikke forekommer andre signaler mens der sendes (kollisionskontrol). Hvis der er kollisioner stoppes transmissionen og der udsendes et ’jamming’ signal. Hver node venter derefter en given tid inden der prøves igen. Metoden virker fint så længe der ikke er alt for stor trafikmængde på linien. Kommunikation op mod Internettet sker via TCP/IP protokoller kombineret med IEEE802.2 samt IEEE802.3 standard interfaces. TCP

Transport Communication Protokol TCP giver mulighed for forbindelse mellem to host-computere (via de underliggende lag i OSI-modellen). Den host, der ønsker at oprette forbindelse, sender en TCP-request til modtager host’en sammen med et unik sessionsnummer (socket nummer og portnummer). Portnummeret er relateret til den form for forbindelse der ønskes (eks. FTP port 21). Modtagerhosten returnerer derefter ligeledes et unikt sessionsnummer (socketnummer og portnummer). Når forbindelsen således er etableret kan datastrømmen udveksles mellem de to computer. Data, der ønskes udvekslet vha. TCP-protokollen, indkapsles med en TCP-header, hvis formål det er at medsende de nødvendige informationer, for at sikre en korrekt overførsel af data.

2 W5100 Datasheet, WIZnet, http://www.wiznet.co.kr

13

TCP HEADER - 16 bit værdier (ialt20 bytes excl. Data)

Source Port

nummeret på den lokale port

Destination Port Sequence Number

check af overførsel af resp. Pakkenummer

Acknowledge Number Data Offset | reserved |Flags

offset - angiver start af data, flags - type af flag U(rgent) A(cknowledge)...

Window

antal datablokke som modtageren kan acceptere lige nu

Checksum

checksum for data + header

Urgent Pointer

Data

Som led i overførslen er anvendes acknowledgement for at sikre at alle pakker kommer over indenfor et fastlagt tidsrum. Udløber perioden uden en pakke er nået frem laves retransmission. Samtidig anvendes et glidende vindue, hvor modtageren kan fortælle hvor mange pakker den kan modtage lige nu så der ikke sendes mere til modtageren, end den er klar til at modtage. UDP kan anvendes som alternativ til TCP – men UDP har ikke indbygget sikkerhed for at pakkerne kommer frem. IP

Fra Transportlaget (TCP) afleveres data til Netværkslaget, der skal sende data det rigtige sted hen (IP – Internet Protokol). ”Den protokol det meste internettrafik "rider" på hedder internetprotokollen som hyppigt forkortes til IP. I dag (2011) menes i langt de fleste tilfælde IPv4. Internetprotokollen er en netværkslagsprotokol. En IP-adresse (Internet Protokol-adresse, eller mindre korrekt en IP) er et unikt nummer som netværksenheder (f.eks. computere) bruger til at kommunikere med hinanden over Internetprotokollen (IP). Alle enheder, der skal kommunikere på IP-laget – blandt andet computerservere, routere, netværksprintere, internet-Telefaxmaskiner, IP-telefoner, – skal have deres egen unikke adresse. Dette sikrer, at kommunikationen mellem de forskellige enheder ikke bliver blandet sammen. Ligesom vejnavne og telefonnumre identificerer individuelle bygninger eller telefoner, identificerer IP-adresser en opkobling med en netværksenhed.”3 IP laget er ansvarligt for routing af data mellem computerne. IP protokollen gør ikke noget i sig selv for at sikre en sikker transport – sikkerheden skal indbygges i det overliggende TCP lag.

3 http://da.wikipedia.org/wiki/Internetprotokol

14

IP-adresserne indkapsler informationen, der kommer fra TCP-laget, så der kommer en header ’rundt om’ TCP informationen. Såfremt den modtagne datapakke har en størrelse, der overskrider den maks. tilladelige datastørrelse, opdeler IP datamængden i flere pakker og sender disse hhv. samler flere pakker ved modtagelsen og sætter data sammen til et korrekt datasæt. Sker der fejl undervejs rapporterer IP om dette. IPv4 anvender 32 bit til internetadresserne mens den nyere IPv6 benytter 128 bit (se næste afsnit mht. adressevalg mv).

IPv4-HEADER Version | header length | type of service

type of service relaterer sig til prioritet mht. delay

total length identification D | M | fragment offset

D - do not fragment data M-fragment data

time-to-live | protocol

sikrer at data ikke 'cykler rundt for evigt'

header checksum source IP address

32 bit

destination IP address

32 bit

options

debugging, error kontrol etc…

data =< 64 kB

IPv6 anvender 128 bits adresser og IPv6 headeren indeholder IKKE checksum. Derfor SKAL der anvendes checksum fra TCP-laget. Samtidig tillader IPv6 variabel headerstil, hvor hovedheaderen efterfølges af en mulig række ’underfelter’ med ekstra information om rutingen/routere, hvorfor headeren er lidt anderledes. Eftersom IPv6 ikke har været anvendt i projektet vil dette ikke blive behandler nærmere, men der henvises i stedet til den obligatoriske bog i faget. IEEE 802.2 Logic Link Control (LLC)

LLC i Ethernet protokollen udgør en del af data link laget i OSI modellen.

Datarammen4 indeholder node-adressering (DSAP-distination og SSAP-source MAC adresser) efterfulgt af en kontrol-ramme, som bl.a. angiver hvilken type information, der er tale om. Endelig følger data.

4 Cisco, http://www.cisco.com/en/US/tech/tk331/tk336/technologies_tech_note09186a0080094777.shtml

15

Der findes 3 forskellige kontrol-rammer: en informations-ramme indeholder data, en overvågnings-ramme benyttes til ackowledgement og en unummereret-ramme, der benyttes til kontrolformål. “An LLC frame is called an LLC Protocol Data Unit (LPDU), and is formatted as shown here: DSAP (1 byte)-SSAP (1 byte)-Control Field (1 or 2 bytes)-Information Field (0 or more bytes)” En mere detaljeret oversigt over LC datarammen fremgår næste side. This section provides information on LLC frame formats:

DSAP/SSAP Control

Destination Service Access Point (1 byte)

Control Field - Unnumbered (1 byte)

Dddd ddxx

Xxxx xx1x

Xxxx xxx1

Dest. Addr.

IEEE Defined

Group Address

CCCC CC11

000F 1111

010P 0011

011F 0011

011P 1111

100F 0111

101z 1111

111z 0011

xx-xx

0F-1F

43-53

63-73

6F-7F

87-97

AF-BF

E3-F3

Unnumbered format

Disconnect Mode

Disconnect

Unnumbered Ack.

SABME

Frame Reject

XID

Test

Source Service Access Point (1 byte)

Control Field - Supervisory ( 2 bytes )

ssss ssxx

xxxx xx1x

xxxx xxx1

Source Address

IEEE defined

Response LPDU

CCCC CC01

0000 0001

0000 0101

0000 1001

xx-xx

01-xx

05-xx

09-xx

Supervisory Format

Receiver Ready

Receiver Not Ready

Reject

Control Field - Information frames (2 bytes)

ssss sss0 xxxx Information format

P = Poll bit set to "1" F = Final bit set to "1" Z = Poll/Final bit set to either "0" or "1"

16

IEEE 802.3

Data Link laget og Det fysiske Laget i OSI-modellen dækkes tilsammen af LLC (IEEE 802.2) og MAC

(Media Access Control, IEEE 802.3). 802.3 rammeformatet er:

IEEE 802.3 frame format Preample

7-bytes, hver med mønster 10101010 til synkronisering

Start delimiter (SDF)

1-byte, 10101011 indikerer at en brugbar ramme sendes

Destination address

48 bit mac-adresse

Souce address Length LLC Frame Check Sequence (FCS)

Cyclic-Redundancy-Check CRC eller checksum

Delay

96-byte for at sikre minimum-afstand mellem frames

CSMA/CD er implementeret i MAC laget, der ved sending modtager LLC data, beregner FCS, tilføjer Preampl og øvrige frame-format-data. Ved modtagning tjekkes antal bytes, der modtages og at FCS er korrekt. Desuden sikres at kollisioner undgås. Internet og IP adresser

Internettet ’adresseres’ via IP-adresse numre. I praksis angives adresser dog oftest med egentlig ’navngivning’ som f.eks. www.ihk.dk – angiver at netværket er .dk domæne, ihk er institutionen og .www er lokalhosten. Hver institution på nettet har en Domain Name Server database, der holder styr på navne og IP numre i det pågældende netværk – dvs. man vha. name-serveren kan lave opslag om hvor den aktuelle datapakke skal sendes hen ud fra de givne navne og/eller IP-adresser i meddelelsen. Hvis IP-adressen ligger indenfor egen institution kan den sendes (ned) til den korrekte host/eller undernetværk – alternativt kan pakken ekspederes videre til det overliggende netværk, som så udreder den videre forsendelse. Eks: ved opslag på www.dsb.dk fra ihk netværket vil den lokale navneserver konstatere at dsb ikke er en del af ihk netværket, hvorfor meddelelsen i princippet sendes til .dk domæne serveren. Her konstateres at dsb er en del af .dk undernettet og meddelelsen videresendes derfor til dsb. IP adresse

En IP (IPv4) adresse består af 2 felter med i alt 32 bit – et venstre felt, der identificerer netværket samt et højrefelt, der identificerer hosten. Alt efter hvor mange bit, der anvendes til at identificere netværket hhv. hosten fås 3 forskellige klasser:

8 bit 8 bit 8 bit 8 bit netværksdel hostdel

Class A 0nnnnnnn hhhhhhhhh hhhhhhhhh hhhhhhhh 1 - 126 0.0.1 - 255.255.254

Class B 10nnnnnn nnnnnnnn hhhhhhhhh hhhhhhhh 128.1 - 191.254 0.1 - 255.254

Class C 110nnnnn nnnnnnnn nnnnnnnn hhhhhhhh 192.0.1 - 223.255.254 1 - 254

17

Det er muligt at definere et subnet ved brug af en ’maske’ således at de netværksbestemmende bits sættes til 1 mens de resterende bit sættes til 0. Dermed anvendes en del af ’hostdelen’ som lokal undernet-identifikation og systemet kan således indeholde flere undernetværk i steder for enkelt-host’s. I IPv6 udgøres en IP adresse af 128 bit, hvorfor dette adressevalg forventes at finde anvendelse i rigtig mange år fremover. IPv6 giver yderligere mulighed for Neighbor Discovery (ND) dvs. detektering af omgivende netværksnoder og router-veje, der anvendes, men specielt Neighbor Unreachability Detection (NUD) giver mulighed for at finde alternative routing-veje hvis en af noderne i omgivelserne fejler.

18

Cosm server application (interface og protokoller)

Cosm (www.cosm.com) giver mulighed for at en klient vha. kan åbne en TCP forbindelse til webserveren. Efter endt transaktion kan forbindelsen enten lukkes eller forblive åben for en senere transaktion. HTTP request Når TCP-forbindelsen er etableret kan klienten sende data til webserveren/cosm vha en HTTP request PUT (nye data sendes) eller POST (supplerende data sendes) sammen med identifikation af hvilke data, der overføres. Alternativt kan klienten anmode om data fra webserveren/cosm vha. en HTTP request GET (sammen med identifikation af hvilke data der ønskes). Serveren responderer ved at sende en statuskode retur til klienten f.eks. 200 OK – se afsnit om Arduino SW, hvor der foretages error-check. Evt. efterfølges statuskoden af ønskede data, såfremt serveren skal sende data. Desuden sendes en række statusinformationer fra cosm til klienten. Eks på klient-server kommunikation (sammenblandet med egne print-statements se demoprogram i appendix 6):

HTTP/1.1 200 OK Date: Thu, 29 Nov 2012 15:12:43 GMT Content-Type: text/plain; charset=utf-8 Connection: close X-Runtime: 157 X-Pachube-Logging-Key: logging.bP5AUbzf26ivO2TJ6jZ2 Set-Cookie: _pach After read Before read core_app_session=BAh7BjoPc2Vzc2lvbl9pZCIlNTQ5ZDJkZTc0NDAwODk3YzNmYjU1NGU4ZmVlMDNiYzg%3D--b27de5acbab26f92b71e883deb9ceb6a62445801; domain=.cosm.com; path=/; expires=Thu, 13-Dec-2012 15:12:43 GMT; Http After read Before read Only X-PachubeRequestId: 1173704a294d89968d816c773c3030c94c952a41 Cache-Control: max-age=0 X-PachubePurgeCache: t:feeds/77832,web:feed:77832 Content-Length: 1 Vary: Accept-Encoding After read Before upload Connection started Connection closed After upload Before read

19

Sikkerhed Sikkerheden mellem klient og webserver opretholdes ved at klienten sender en nøgleID med sammen med feedsID og dataID, samt sensordata, når der overføres data til cosm. Desuden tillades kryptering vha. SSL (Secure Socket Layer) så nøgleID mv. ikke kan læses af uvedkommende. Data format Data, der overføres mellem klient og server kan forekomme i flere forskellige formater:

EEML – Extended Environmental Markup Language, se http://www.eeml.org/ JSON – JavaScript Object Notaion, se http://www.json.org/ CSV – Comma Separated Values, se http://en.wikipedia.org/wiki/Comma-separated_values

EEML har de mest udbyggede data, idet formatet giver mulighed for at specificere tid og sted for datatagningen. Se http://www.eeml.org/xml/0.5.1/complete.xml for praktisk eksempel på ’fuld’ datasæt. Til gengæld er transmissionsmængden mellem klient og server tilsvarende stor (med tilhørende ekstra energiforbrug etc). JSON er mere kompakt – se http://json.org/example.html for sammenligning af JSON og XML. CSV indeholder mindst mulig information i klient-server overførslen, idet identifikationen på målingerne sker i en ’header’ mens der kun sendes sensordata i selve transmissionen. Det er den sidste metode CSV , vi anvende i vores tilfælde. Først etableres forbindelsen og der sendes en PUT request med efterfølgende feedID

void uploadDataToCosm(String cosmData) { // If there is a successful connection if (client.connect(server, 80)) { // Send the HTTP PUT request client.print("PUT /v2/feeds/"); client.print(FEEDID); client.println(".csv HTTP/1.1"); client.println("Host: api.cosm.com"); client.print("X-ApiKey: "); client.println(APIKEY); client.print("User-Agent: "); client.println(USERAGENT); client.print("Content-Length: "); client.println(cosmData.length()); client.println("Content-Type: text/csv"); client.println("Connection: close"); client.println(); client.println(cosmData); } else { // If no connection could be made client.stop(); }

20

// Note the time that the connection was made or attemted lastConnectionTime = millis();

Når forbindelsen er på plads sendes data som uploadDataToCosm(dataString); hvor csv-formatet skabes med: dataString = "sensor1, " + String(analogLow + (analogHigh * 256)); Monitoring through the Internet (HTML programming)

HTTP GET- request giver mulighed for at anmode om data fra web-serveren , så de modtagne data kan anvendes i en lokal kontrol-loop el.lign. f.eks. på den aktuelle Arduino processor … og om ønskeligt at sende information til et XBee-end-modul og dermed lade det styre en ekstern enhed. Som tidligere nævnt har vi valgt IKKE at gøre dette – men anvender i stedet en standard web-browser til at monitorere data-graferne på cosm. Ulempen ved at monitorere over en standard web-browser består i at ens evt. dataudtræk bliver afhængig af formatering etc. af den side, man trækker data fra, hvis udtrækket skal anvendes til automatisk regulering/ovevågning…..en ulempe, der kan undgås ved at trække data direkte med en GET-request. Vi har valgt ikke at gå dybere i detaljer med denne virkemåde grundet manglende tid.

21

Konklusion Hardware-Software

Den udviklede løsning virker fint til det ønskede formål, men timing-problemer i systemet bør undersøges nærmere og optimeres, hvis det er hensigten at koble mange sensorer på hhv. hvis XBee end-noden skal kontrollere en eller flere aktuatorer, som aktiveres af Arduino. I forhold til den anvendte applikation vil it-sikkerhed også være et emne, som skal have en høj prioritet; specielt hvis der anvendes elektronisk styring af alle funktioner i f.eks. et intelligent hus. (hvad hvis strømmen forsvinder, hvor lang tid kan man fungere uden strøm, hvor nemt kan man ’hacke’ sig til at åbne låse, gøre huset ubrugeligt ved styring af temperatur, ventilation etc…). Diskussion af fremtidig udvikling af hardware-software Den største ’enkeltkilde’ i effektforbruget på sensorsiden er den trådløse overførsel mellem XBee end-node og XBee coordinator. Denne trådløse forbindelse ’sender energi i alle retninger’ grundet antennens rundstrålende karakter. En lidt bedre effektivitet kunne altså opnås såfremt der installeres retningsbestemte antenner – med tilhørende øget besvær med montering og ’trimning’ af sender/modtage-retning. Alternativt kan anvendes trådet overførsel af data fra sensor til hoved-controller - sandsynligvis med væsentlig højere installationsomkostninger end en trådløs forbindelse. Det kan give en meget mere direkte kontrol med sensorenheden uden store effekttab, eftersom hoved-controlleren blot kan aktivere sensormålingen, når der er behov for det. Sidstnævnte er også mulig via den trådløse opsætning – men i så fald kræves at XBee end-node ikke går i fuld sleep mode men holder modtageren tændt, så den kan modtage besked om hvornår den skal blive aktiv igen. Endelig kan man, når der anvendes mange sensorer evt. med hver sin XBee, benytte nogle af XBee’erne som routere – så de afstandsmæssigt bliver placeret til at minimere det samlede energiforbrug. En sådan optimering skal ske på baggrund af den aktuelle installation i den aktuelle bygning under hensyntagen til bl.a. støjforhold og andre genevirkninger (afskærmning pga. vægge, installationer mv.). Skal der ske aktiv styring i end-noden f.eks. vha. aktuatorer vil der ofte være et væsentlig større energibehov end hvis der blot skal måles. Det skyldes at mange aktuatorer kræver tilstrækkelig energi til at kunne foretage den fornødne omsætning til mekanisk bevægelse (overvinde friktion, levere slagkraft etc). Udvikling af aktuatorer med meget lav energiforbrug kan således være nødvendigt.

22

Kapitel 3

ENERGIBEHOV, FREMSKAFFELSE OG FORBEDRINGSMULIGHEDER

En mere udbredt anvendelse af sensorer og aktuatorer til overvågning og kontrol af f.eks. miljømæssige parametre kræver tilstedeværelse af energi for at forsyne sensorelektronikken samt sikre signaloverførslen mellem målestationer og hoved-controller. Der kan derfor være behov for at foretage energihøstning ’ på stedet’ , hvis man over større afstande skal undgå en dyr installation vha. f.eks. kabeltræk. På baggrund heraf har vi som målestation valgt at implementere en sensorløsning bestående af et solpanel og et XBee modul (til dataregistrering og transmission til hoved-controller).

Sensor og XBee end-node

Et XBee modul kan operere med en forsyningsspænding I området 2.1 – 3.6 Volt. Ved transmission anvendes ca. 50 mA mens det i ’sleep mode’ er muligt at bringe strømforbruget ned på 1 uA alt efter hvilken ’sleep-mode’ XBee bringes i. Strømforbruget i sleep-mode falder kraftigt efterhånden som forsyningsspændingen aftager, hvorfor det kan være en fordel at operere med så lav en forsyningsspænding som muligt. Foruden strømforbruget til XBee vil der også være et strømforbrug til en sensor. Alt efter sensortype kan dette forbrug nemt ligge i samme størrelsesorden som XBee gennemsnitsforbrug, om end det er muligt at programmere XBee således at der kun tilføres power til den eksterne sensor, når XBee er i aktiv mode - dvs. strømforbruget i ’sleep-perioden’ kan nedbringes væsentligt alt efter hvilken sensor der anvendes. Til vort formål ønskes monitorering af dagslysintensitet, hvilket sker ved at måle udgangsspændingen fra en solcelle (der anvendes til at oplade et genopladeligt batteri). Dette er vort valg og anses for at være tilstrækkelig præcist til at vurdere om evt. ekstra belysning skal tændes. Den pågældende løsning har den fordel at energihøstning og monitorering sker med samme enhed. En vurdering af energibehovet til at drive sensor og XBee modul fremgår af appendiks 2 (matlab program) idet følgende hoveddata er anvendt: Der transmitteres en gang i minuttet med et strømforbrug på ca. 50 mA. (af ca. 1 sekunds varighed) Strømforbrug i ’sleep-mode’ er ca. 1uA (med en varighed på ca 59 sekunder). Det betyder at der er behov for ca. 0.9 mA i gennemsnit ved en forsyningsspænding på min. 2.1 Volt. Energy harvesting, Solcelle og genopladeligt batteri

Alt efter sensortype og ønsket om hvilke parametre, der ønskes overvåget, er der forskellige muligheder for at lave energihøstning. Således kan nævnes (se overhead udleveret under kurset) områder som solenergi, radio-bølge-energi, kropsvarme, termisk energi, krop-bevægelsesenergi, luftstrømning, blodstrømning, vibrationer og piezoelektrisk energi. Med undtagelse af solenergi (100 mW/cm^2) gælder for de øvrige kilder, at den mulige energiudvinding er meget begrænset (typisk i området 0.1-100 uW/cm^2).

23

For solenergi gælder at energi-indfaldet er i størrelsesordenen 1 kW/m^2 ved direkte sollys svarende til de 100mW/cm^2 nævnt ovenfor. Er den aktuelle lys intensitet lavere – så er energihøst-udbyttet naturligvis også lavere… Skal der høstes energi fra en indendørs belysning f.eks. en 10 W sparepære – så skal en solcelle være placeret meget tæt på lyskilden for at give et brugbart udbytte, idet lys intensiteten fra sparepæren ligger langt under solens indstrålede intensitet. I appendiks 2 fremgår hvor stor en solcelle, der er behov for at kunne levere den nødvendige energi i gennemsnit, når solcellen er placeret indenfor i et lokaleoplyst med direkte/indirekte sollys. Forudsætningen for beregningen er at solcellen effektivt kan opfange 2% af det indfaldne sollys. Under de givne forudsætninger er behovet for at kunne levere de nødvendige 2.5 mW at solcellen har et areal på minimum 1.2 cm^2. I praksis er anvendt en solcelle på 70 cm^2 hvilket giver en sikkerhedsmargin på 55 x – eller med andre ord: man kan tillade at lysstyrken varierer en faktor 55 uden at mangle energi. Eftersom lysets intensitet i løbet af en dag kan variere væsentlig mere end 55 x så er sikkerhedsmargenen måske ikke stor nok til praktisk anvendelse indendørs (se appendiks for målte data). XBee coordinator og Arduino

Sammen med en Arduino-processor (I-board) anvendes XBee som modtager af den trådløse dataoverførsel. Data fra XBee decodes af Arduino’en og tilpasses til videre transmission via trådet Ethernet. Også her er det muligt at anvende ’sleep’ funktion for såvel XBee som Arduino. Alt efter hvilken strategi, man anvender kan der opnås en større eller mindre gevinst på energiforbruget. Dog skal man være opmærksom på at det kræver en vis tid at starte både XBee og Arduino op igen efter ’sleep-mode’ så energigevinsten kan være begrænset såfremt systemet skal modtage data fra mange trådløse enheder uden tab af data. Vi har valgt ikke at sætte XBee coordinatoren hhv. Arduino i ’sleep-mode’, men blot konstatere fra øvelsen tidligere på semestret med strømbesparende ’sleepmode’ at dette kan realiseres, hvis tiden i øvrigt tillader eller der stilles eksplicitte krav til strømforbruget. Hvilke udfordringer det evt. kan give diskuteres sidst i kapitlet. Internet

I det omfang man selv er ’herre’ over sit lokale netværk kan de elektriske enheder naturligvis forsynes via vedvarende energi svarende til solceller mv. nævnt ovenfor. Et par af de væsentlige beslutningsparametre for hvilken power supply form, der anvendes, vil være forsyningssikkerhed, driftsikkerhed, driftstidspunkter, omfang af trafik mv... Konklusion Energibehov

For et ’prof of concept’ som indeværende projekt går det udmærket med at anvende en solcelle til energihøstning, da energibehovet er meget lille. Men selv her kan vi konstatere at vi næppe vil kunne benytte systemet indendørs, hvor belysningsintensiteten er meget begrænset. Skal systemet drive mange sensorer eller måske endda aktuatorer, som typisk er væsentlig mere strømkrævende, så vil indeværende løsning næppe være god nok.

24

Anvendelse af sleep-funktioner kan give yderligere energibesparelser – men kræver udvidede software rutiner til at sikre det samlede netværks validitet. Diskussion omkring anvendelse af vedvarende energi

En større anvendelse af vedvarende energi til at drive sensorer (og evt. også internet-nodes) kræver udvikling af sensorer med speciel fokus på energiforbruget – ligesom der er behov for yderligere udvikling af ’energi-høstere’ med høj virkningsgrad. Client-server energiforholdene er uafklarede i indeværende kursus, men der er ingen tvivl om at der kan ligge en stor energibesparelse hvis systemerne kan skræddersys til det ønskede formål (kommunikationsform, omfang, hastighed etc). Det står dog i skærende kontrast til at bevare en stor fleksibilitet, så man ikke skal rekonfigurere client-server kommunikationen hver gang man ændre i sine applikationer.

25

Kapitel 4

LIVSCYKLUSVURDERING (LCA, MECO)

Målet for LCA analyse er at se forskellen mellem en wireless sensorløsning og en trådet sensorløsning. Med udgangspunkt i forskellen mellem de to løsninger beregnes materialeforbrug samt energiforbrug ved hver af løsningerne: Detaljerne findes i regnearket LCAtotalsolution.xlsa Til LCA evalueringen anvendes et MECO afbildning: ” The MECO chart provides an overview of the relevant product lifecycle. It presents indicators for environmental

impacts within the following categories: Materials, Energy, Chemicals, and Other”5 Målet for analysen er at se forskellen mellem en wireless sensorløsning og en trådet sensorløsning, når systemerne forventes at skulle fungere i 10 år. Med udgangspunkt i forskellen mellem de to løsninger beregnes materialeforbrug samt energiforbrug ved hver af løsningerne: Detaljerne findes i regnearket LCAtotalsolution.xlsa Materialeforbruget estimeres ud fra vægten af de indgående printkort/komponenter. Dette gøres for rå-materiale-fasen og produktionsfasen som en samlet størrelse, baseret på erfaringstal udleveret under kurset (se regneark faneblad XBee øverste venstre felter). Energiforbruget estimeres ligeledes ud fra de indgående dele Energiforbruget i drift estimeres for en levetid på 10 år Energiforbruget (genvindingsenergi) estimeres ved disposal fasen. Løsningsmodel 1 (wireless): En sensor med tilhørende selvforsynende strømkilde (solpanel + genopladelige batterier) er forbundet til en interfaceenhed/trådløs transmitter, som sender data trådløst til et (online) dataopsamlingssted. Løsningsmodel 2 (trådet): En sensor er forbundet til en interfaceenhed/trådet transmitter, som sender data via kabel til et (online) dataopsamlingssted. Strømforsyning til sensoren leveres gennem den trådede forbindelse. Resultatet for de to løsninger holdes op mod hinanden. For begge løsningers vedkommende er sensorelektronikken vurderet til at være det samme (i vort tilfælde med en kompleksitet svarende til et XBee modul). XBee modulet er derfor udeladt ved sammenligningen af de to løsninger – men for god ordens skyld er der regnet energi og ressource på XBee modulet også. Ligeledes er opsamlingselektronikken vurderes til at være ens i de to tilfælde og er derfor ikke medtaget i den sammenlignende evaluering. I beregningerne er der ikke taget hensyn til forbruget i transportfasen – men dette vil sandsynligvis belaste den trådløse løsning yderligere pga større transport verden rundt i forbindelse med produktionsprocessen. Hovedresultatet ses næste side - detailmaterialet kan findes i spreatsheet LCAtotalsolution.xlsa.

5 Handbook on Environmental Assessment of Products (del af pensum)

26

XBee

En analyse af et XBee modul fremgår af regnearkets faneblad XBee. Resultatet er ikke medtaget her eftersom en elektronikmængde svarende til XBee forventes at indgå i begge løsninger.

Solcelle og genopladelig batteri

MECO chart for Wireless transmission system (excl Xbee) due to Solar Cell and Battery

raw materials

phase Production

phase Use phase Disposal

phase Transport

phase

raw material Quantity(kg) incl in ->

Resources(mPR) incl in -> 94+15=109

Energy Primary(MJ) 2039+365=3004 1,38 4,25

Resources

Chemicals

Other

Trådet løsning

MECO chart for wired transmission system (excl.XBee) due to 50m wire (values in mPR):

raw materials

phase Production

phase Use phase Disposal

phase Transport

phase

raw material Quantity(Kg) incl in ->

Resources(mPR) incl in -> 3,3

Energy Primary(MJ) 7,16 1,38 5,5

Resources(mPR)

Chemicals

Other

27

Konklusion LCA, MECO

Som det klart fremgår af ovenstående er der et væsentlig forhøjet ressourceforbrug ved anvendelse af solcelle og genopladeligt batteri i løsning 1 i forhold til at anvende en trådet løsning. Dette er forventeligt fordi solceller udgør en mere energikrævende proces end fremstilling af Cu-tråd. Dertil kommer at man ved den trådløse forsyning først skal konverter lys (elektromagnetiske bølger med meget begrænset effekt til rådighed) til dc-energi for efterfølgende at konvertere tilbage vha. den trådløse transmission.

Diskussion af forbedringsmuligheder set fra et LCA perspektiv

Skal ressourcebelastningen bringes ned for den trådløse enhed er det klart ud fra ovenstående at de knappe ressourcer for såvel råmaterialemængden som energiforbruget skal ned for solcellerne og batterierne. En løsningsvej kan være en anden type solceller – etc en type, som kan trykkes direkte på folie for derved at spare en energikrævende produktionsproces – forudsat at de indgående materialer er ’en mindre knap’ ressource end de sjældne metaller, der indgår i IC-produktion. Tilsvarende gør sig gældende for batteriet – måske man kan trykke solcelle og batteri som en samlet enhed ?? En anden indgangsvinkel kan være at nedbringe energibehovet til drift – fordi man dermed kan mindske størrelsen på de indgående solceller og batterier – med tilsvarende reduktion i materialer og energiforbrug.

28

Kapitel 5

KONKLUSION ’FRA SENSOR TIL WEB TIL MONITOR’

Det har lykkes os at lave et lille system der i den ene ende kan lave en måling, der så går hele vejen gennem en wireless XBee forbindelse, og via. et arduino I-Board uploades til internet siden cosm. Vores XBee endnode er drevet af en solcelle, med den ide at den skulle være selvforsynende med energi. Endvidere har vi analyseret over både energi forbrug og livscyklus. Da vi har været en lille gruppe uden alt for meget tid tilrådighed, besluttede vi os for at holde systemet minimalt og så simpelt så muligt og der er derfor massere af forbedringsmuligheder til vores løsning, hvor nogle af dem er beskrevet nedenunder. Vi er dog tilfredse med resultatet der har givet os en god introduktion til emnet som vi føler vi kan bygge videre på.

Diskussion af forbedringsmuligheder

I forhold til den implementerede løsning, vil dette energimæssigt kunne forbedres ved større fokus på energiforbruget i sensor-XBee-delen og reducering af energiforbruget i XBee-Arduino-Ethernet delen. Således vil en større anvendelse af ’sleep’-funktioner kunne mindske energiforbruget – men det kræver at de anvendte softwarealgoritmer forfines til at håndtere specielt ’manglende synkronisering’ mellem enhederne, ligesom automatisk indmelding/udmelding af sensorer/nodes i kredsløbet vil være nødvendigt. Set i relation til sikkerhed, så er der absolut ingen hensyn taget til dette – hverken i programkoden for at verificere evt. data (validering af dataområde, validering af ’dataudvikling, validering af korrekt fungerende sensorer, check af strømforbrug til sensor osv.) eller for at sikre at processoren ikke ryger på afveje (watch-dog-timer anvendelse, melding af fejl til kontrolenhed mv…) En lang række simple sikkerhedsfunktioner er således slet ikke overvejet (eksempelvis: kan man få for varmt vand ud af en vandhane, hvis hanen og temperaturen er fjernkontrolleret). Et ‘fuld-elektroniske’ højhus er meget følsomt over for ’hacking’ af systemerne og huset kan gøres ubrugeligt eller direkte livsfarligt ved f.eks. brand (manglende brand-pumpe-aktivering, manglende stop af ventilation pga. røg, manglende brandmelding…), elevatorhåndtering osv…..

29

Kapitel 6

KOMMENTARER TIL SUSIE KURSET

Den udleverede litteraturmængde sammenholdt med implementering af et komplet system inkl. anvendelse af protokoller, softwareskrivning og opbygning af hardwarekendskab gør workloaden i kurset ganske overvældende (set i forhold til point-tilskrivningen). Det har ind imellem været svært at opretholde ’bæredygtigheds’-fokus fordi de praktiske problemer snarere relaterede sig til softwareimplementering. En del af dette tilskrives dog at kurset kører for første gang og det derfor ikke har været mulig på forhånd at vurdere tidsforbruget i de enkelte deløvelser mv. Samlet set vurderes kurset som godt, det kommer rundt om alle de nødvendige elementer for at dække hele spektret fra sensor til web til monitor/aktuator

Diskussion af forbedringsmuligheder

Vort forslag til forbedring kan være en struktur, hvor der helt fra starten lægges vægt på bæredygtighed og hvor elementerne i slutopgaven i praksis kan løses hen gennem semesteret – dermed gives der større frihed til at stille differentierede slutopgaver (f.eks. analyse af udvalgte problemstillinger) til de enkelte grupper alt efter interesse mv.. Fordelingen hen gennem semesteret af delopgaver betyder desuden at alle i gruppen får mulighed for at arbejde med alle problemstillingerne – så man ikke ’falder i den fælde’ at et stort projekt er afviklet, hvor de enkelte deltagere reelt kun lærer en lille del af det tekniske indhold (nemlig det man selv beskæftigede sig med). Rent konkret foreslås at software og hardware gennemgås parallelt med bæredygtighed

Teknik LCA Øvelse LCA Øvelse teknik

Arduino struktur, LCA, MECO LCA analyse af Arduino simple eksempler, A/D, digital input etc

digital sensor, analog sensor

Arduino digital/analog sensor

XBee kommunikation Strømforbrug LCA analyse af XBee XBee transmission,

XBee og Arduino sleep mode problematikker

Energiforbrug/ strømbesparelse sleepmode

Energiforbrug XBee Arduino

XBee transmission, sleepmode

Sensor->arduino ZigBee protokoller

Arduino upload til web TCP/IP, Ethernet, HTTP…

Energiforbrug Energivurdering, LCA af Ethernet sender/modtager mv.

Cosm upload

Arduino download fra web, protokoller fortsat

Cosm download

Arduino controlling XBee end-node output

Energiforbrug Energi og LCA

Sikkerhedsmæssige perspektiver

Internationale standarder/mål…

Slutøvelse+rapport Slutøvelse+rapport

30

I kurset bliver sikkerhed stort set ikke berørt. Det bør inddrages, da ’fuld-elektroniske’ højhuse kan blive endog meget følsomme over for ’hacking’ af systemerne og gøre huset ubrugeligt eller direkte livsfarligt ved f.eks. brand (manglende brand-pumpe-aktivering, manglende stop af ventilation pga røg, manglende brandmelding…), elevatorhåndtering osv…..

31

APPENDIKS

Appendiks 1: Project in sustainable electronic and it. 32 Appendiks 2: Solar Cell Charger for XBee end device. 33 Appendiks 3: Nickel–metal hydride battery. 36 Appendiks 4: XBee materialemængder og typer. 48 Appendiks 5: LCA analyse på wireless løsning versus trådet løsning. 49 Appendiks 6: Kildekode til brugt program på Arduino I-Board. 51 Appendiks 7: Cisco: LLC layer. 55

32

Appendiks 1:

Project in sustainable electronic and it

Chose a problem domain for which it’s relevant to monitor and/or control environmental data In the design there must be an autonomous node using a ZigBEE protocol in the XBEE module which communicate with a microcontroller. Autonomous means that there the XBEE node must only be supplied by “natural energy”. Consider the need for energy – how much time can it sleep or be idle and how much time does it really need sampling data. The other nodes can be battery operated – find out how long the battery will last for a given use-case The XBee nodes communicate with a microcontroller containing the ZigBee coordinator and which also must have access to the internet. The microcontroller should act as a client, which can forward the data through the LAN – to either using the web-service on cosm.com or thingspeak.com or another web server with a database and a graphical presentation of the measured data. If you wish to control some actuators/devices this can be done trough an embedded server in the microcontroller or from the server by a “GET request” from the embedded client to the web service cosm.com – which then controls the actuator/devices An Analysis of the energy consumption for the whole system should be done – using data sheets and practical measurements in the different states of uses. The project should evaluate the system or at least one subsystems environmental impact using a LCA analysis as you got introduced through the lecture. The Project is documented in a report and on a poster for the last school day event in the hall and for exam presentation. A running demo for the last school day event The documentation should at least contain: -documentation for the communication chain from Xbee modules to the cosm.com server or alternative. Different protocols used should be documented. -documentation for the program in the microcontroller. -an analysis of the energy consumption for all parts in the communication chain and a discussion for how to minimize it. The solution/the practical implementation should strive for the minimum consumption seen in relation to the chosen problem domain. Alternative solutions and/or an optimal hardware/soft ware plat form can be discussed. -a documentation for how a Xbee end node can be powered or is powered through environmental energy source” -an LCA analysis on a part of the system -a reflection over the SUSIE class – what can be improved The Project must be done in groups of student. 2012-10-23 Ole Schultz

33

Appendiks 2:

Solar Cell Charger for XBee end device A XBee module can run from 2.1V to 3.6V. The sleep-current is decreasing fast with decreasing supply voltage level – a low supply voltage can be an advantage for long time performance/power saving. For this reason a simple solar cell has been chosen together with a Schottky-diode and a high capacity rechargeable battery (to obtain long time performance without solar light).

The calculation of Power needed and the necessary size of a solar panel is presented in appendix 2. The main results presented here is: Average current of circuit (incl. leakage current in rechargeable battery): 0.9 mA Average power of circuit ( …do……+ loss in schottkydiode ………………….) : 2.5 mW Safety factor of selected solar area: 55 x theoretical needed value (please refer to conclusion) Battery capacity needed for 48 hours of operation without sunlight: 43 mAh Expected lifetime with no daylight to recharge: 100 days Measured data for Solar cell battery charger: Placed in inside in a window frame facing outwards - In winter indirect sunlight (no direct light) it charges the battery with 2.4 Volt, 1.3mA ie. 3.2 mW ! (just enough, but far below SolarCellEffiencyIndoor with no safetyfactor). When placed in a window exposed to direct winter sun in the afternoon the battery charges at 2.4V 15 mA ie. 36 mW which is well above the needed demand. (efficiency 0.005 compared to full daylight intensity). The glass window will modify the spectrum of the direct sunlight thus changing the efficiency too. Conclusion on Solar Cell Charger: Above data clearly indicates that operating ‘indoor only’ will have an increased ‘risc’ of not obtaining enough power and further optimization will thus be needed. As solar cell has been chosen, no further optimization has been made to improve efficiency in power conversion from solar cell to battery. Further improvement will be needed. Possible action: 1. Optimize for max-power-transfer (use step-up, step-down SMPS converter) 2. Use controlled low resistive MOSFET switch instead of a Schottky Diode

34

3. Optimize for best possible battery voltage choise 4. Optimize for low leakage current to improve long time survival 5. Possible usage of super capacitor instead of battery Matlab file with calculations of need power / Needed size of Solar Panel – results have been inserted into the matlab-file to allow for easy reading. % Solar power used to charge batteri for XBee % % % Solar cell is powering a rechargeble battery directly through a % Schottky diode (for low loss). SchottkyDiodeVoltageDrop = 0.4 % Battery: Maxell Nickel-Metal Hydride 2500mAh hr6/1.2V/AA % No specifc details have been found on leakage but % indications shows leakage < 70uA (20-80% lost capacity within 2 years) BatteryVoltage = 2.4 BatteryLeakageCurrent = 70e-6 BatteryCapacity = 2500e-3 % Solar cell: unidentified cell from solar lamp panel % Output Voltage: max appr. 6 volt % Area: 10cm x 7 cm = 70cm^2 % Efficiency and spectrum sensitivity unknown % output calculated based upon daylight intensity as reference DaylightIntensity = 1e3 SolarCellEfficiencyDaylight = 0.1 SolarCellEfficiencyIndoor = 0.02 SolarCellArea = 70e-4 % XBee transmitting intensity details XBeeTransmittime = 1 XBeePausetime = 59 XBeeTransmitCurrent = 50e-3 XBeePauseCurrent = 1e-6 % Energy needed to run (for 1 sec) IsecCircuit = (XBeeTransmittime*XBeeTransmitCurrent + XBeePausetime*XBeePauseCurrent + BatteryLeakageCurrent*60/60 IsecCircuit = 0.9mA average (peak: 50 mA) PsecCircuit = IsecCircuit*(BatteryVoltage+SchottkyDiodeVoltageDrop) PsecCircuit = 2.5mW average (peak: 50mW) % Size of Solar cell needed (as absolute minimum) AreaSolarCellNeeded = PsecCircuit/(SolarCellEfficiencyIndoor*DaylightIntensity) AreaSolarCellNeeded = 1.2 cm^2 % Safety factor in solar cell size (should be > 10 times based on outdoor highlightlevel)

35

SafetyFactor = SolarCellArea/AreaSolarCellNeeded SafetyFactor = 55 % MUST run for at least 48 hours without dataloss BatteryCapacityNeededfor48hours = Isec*60*60*48/(10e-3*60*60) % mAh BatteryCapacityNeededfor 48hours = 43 mAh % Expected lifetime in dark room BatteryMinVoltage = 2.1 ExpectedLifetimeNoLightDays = (BatteryCapacity/IsecCircuit)/24*(2.1/2.4) % days ExpectedLifetimeNoLightDays = 100 days Results obtained during calculations:

36

Appendiks 3:

Kilde:

Wikipedia, the free encyclopedia http://en.wikipedia.org/wiki/NiMH

Nickel–metal hydride battery

Nickel–metal hydride battery

Modern, high capacity NiMH rechargeable cells

specific energy 60–120 W·h/kg

[1]

energy density 140–300 W·h/L

specific power 250–1000 W/kg

Charge/discharge

efficiency

66%[2]

Energy/consumer-price 2.75 W·h/US$[2]

Self-discharge rate 30%[1]

(2%[3]

)/month

(temperature dependent)

37

Cycle durability 500–1,000

Nominal cell voltage 1.2 V

A nickel–metal hydride battery, abbreviated NiMH or Ni-MH, is a type of rechargeable

battery. It is very similar to the nickel–cadmium cell (NiCd). NiMH use positive electrodes of

nickel oxyhydroxide (NiOOH), like the NiCd, but the negative electrodes use a hydrogen-

absorbing alloy instead of cadmium, being in essence a practical application of nickel–

hydrogen battery chemistry. A NiMH battery can have two to three times the capacity of an

equivalent size NiCd, and their energy density approaches that of a lithium-ion cell.

The typical specific energy for small NiMH cells is about 100 W·h/kg, and for larger NiMH

cells about 75 W·h/kg (270 kJ/kg). This is significantly better than the typical 40–60 W·h/kg

for NiCd, and similar to the 100-160 W·h/kg for lithium-ion batteries. NiMH has a volumetric

energy density of about 300 W·h/L (1080 MJ/m³), significantly better than NiCd at 50–150

W·h/L, and about the same as lithium-ion at 250-360 W·h/L.

NiMH batteries have replaced NiCd for many roles, notably small rechargeable batteries.

NiMH batteries are very common for AA (penlight-size) batteries, which have nominal charge

capacities (C) ranging from 1100 mA·h to 2800 mA·h at 1.2 V, measured at the rate that

discharges the cell in five hours. Useful discharge capacity is a decreasing function of the

discharge rate, but up to a rate of around 1×C (full discharge in one hour), it does not differ

significantly from the nominal capacity.[4]

NiMH batteries normally operate at 1.2 V per cell,

somewhat lower than conventional 1.5 V cells, but will operate most devices designed for that

voltage.

About 22% of portable rechargeable batteries sold in Japan in 2010 were NiMH.[5]

In

Switzerland in 2009, the equivalent statistic was approximately 60%.[6]

This percentage has

fallen over time due to the increase in manufacture of lithium-ion batteries: in 2000, almost half

of all portable rechargeable batteries sold in Japan were NiMH. By 2011, NiMH only

represented about 22% of secondary batteries.[5]

The significant disadvantage of NiMH batteries is the high rate of self-discharge; NiMH

batteries lose up to 20% of their charge on the first day and up to 4% per week of storage after

that. In 2005, a low self-discharge (LSD) variant was developed. LSD NiMH batteries

significantly lower self-discharge, but at the cost of lowering capacity by about 20%.

38

History

Disassembled NiMH AA cell:

1 - Positive terminal

2 - Outer metal casing (also negative terminal)

3 - Positive electrode

4 - Negative electrode with current collector (metal grid, connected to metal casing)

5 - Separator (between electrodes).

See also: History of the battery

The first consumer grade NiMH cells for smaller applications appeared on the market in 1989,

the culmination of over two decades of research and development.[7]

The earliest pioneering work on NiMH batteries—essentially based on sintered Ti2Ni+TiNi+x

alloys for the negative electrode and NiOOH-electrodes for the positives—was performed at

the Battelle-Geneva Research Center starting after its invention in 1967. The development

work was sponsored over nearly two decades by Daimler-Benz in Stuttgart, Germany, and by

Volkswagen AG within the framework of Deutsche Automobilgesellschaft, now a subsidiary of

Daimler AG. The batteries showed high specific energy up to 50 W·h/kg (180 kJ/kg), power

density up to 1000 W/kg and a reasonable life of 500 charge cycles (at 100% depth of

discharge). Patent applications were filed in European countries (priority: Switzerland), the

United States, and Japan, and the patents transferred to Daimler-Benz.[8]

Interest grew in the 1970s with the commercialisation of the nickel–hydrogen battery for

satellite applications. Hydride technology promised an alternative much less bulky way to store

the hydrogen. Research carried out by Philips Laboratories and France's CNRS developed new

high-energy hybrid alloys incorporating rare earth metals for the negative electrode. However,

these suffered from the instability of the alloys in alkaline electrolyte and consequently

insufficient cycle life. In 1987, Willems and Buschow demonstrated a successful battery based

on this approach (using a mixture of La0.8Nd0.2Ni2.5Co2.4Si0.1) which kept 84% of its charge

capacity after 4000 charge-discharge cycles. More economically viable alloys using

mischmetal instead of lanthanum were soon developed and modern NiMH cells are based on

this design.[9]

Ovonic Battery Co. in Michigan altered and improved the Ti-Ni alloy structure and

composition according to their patent[10]

and licensed NiMH batteries to over 50 companies

worldwide. Ovonic's NiMH variation consisted of special alloys with disordered alloy structure

and specific multicomponent alloy compositions. Unfortunately, linked to their composition,

the calendar and cycle life of such alloys always remains very low, and all NiMH batteries

manufactured at the present time consist of AB5-type rare earth metal alloys.

39

Positive electrode development was done by Dr. Masahiko Oshitani from GS Yuasa Company,

who was the first to develop high-energy paste electrode technology. The association of this

high-energy electrode with high-energy hybrid alloys for the negative electrode led to the new

environmentally friendly high-energy NiMH cell.

Currently, more than 2 million hybrid cars worldwide are running with NiMH batteries,[11]

Many of these batteries are manufactured by PEVE (Panasonic) and Sanyo.

In the EU and due to the Battery Directive, Nickel–metal hydride batteries have replaced Ni–

Cd batteries for portable use by consumers.

Electrochemistry

The negative electrode reaction occurring in a NiMH cell is:

H2O + M + e- OH

- + MH

The charge reaction is read left-to-right and the discharge reaction is read right-to-left.

On the positive electrode, nickel oxyhydroxide, NiO(OH), is formed:

Ni(OH)2 + OH- NiO(OH) + H2O + e

-

The "metal" M in the negative electrode of a NiMH cell is actually an intermetallic compound.

Many different compounds have been developed for this application, but those in current use

fall into two classes. The most common is AB5, where A is a rare earth mixture of lanthanum,

cerium, neodymium, praseodymium and B is nickel, cobalt, manganese, and/or aluminium.

Very few cells use higher-capacity negative material electrodes based on AB2 compounds,

where A is titanium and/or vanadium and B is zirconium or nickel, modified with chromium,

cobalt, iron, and/or manganese, due to the reduced life performances.[12]

Any of these

compounds serve the same role, reversibly forming a mixture of metal hydride compounds.

When overcharged at low rates, oxygen produced at the positive electrode passes through the

separator and recombines at the surface of the negative. Hydrogen evolution is suppressed and

the charging energy is converted to heat. This process allows NiMH cells to remain sealed in

normal operation and to be maintenance-free.

NiMH cells have an alkaline electrolyte, usually potassium hydroxide. For separation

hydrophilic polyolefin nonwovens are used.[13]

Charging

The charging voltage is in the range of 1.4–1.6 V/cell. In general, a constant-voltage charging

method cannot be used for automatic charging. When fast-charging, it is advisable to charge the

NiMH cells with a smart battery charger to avoid overcharging, which can damage cells and

even be dangerous.[14]

A NiCd charger should not be used as an automatic substitute for a

NiMH charger.

40

Trickle charging

The simplest way to safely charge a NiMH cell is with a fixed low current, with or without a

timer. Most manufacturers claim that overcharging is safe at very low currents, below 0.1 C

(where C is the current equivalent to the capacity of the battery divided by one hour).[15]

The

Panasonic NiMH charging manual warns that overcharging for long enough can damage a

battery and suggests limiting the total charging time to 10 to 20 hours.[14]

Duracell further suggests that, for applications where the battery must be kept in a fully charged

state, a trickle charge at C/300 can be used.[15]

Some chargers do this after the charge cycle, to

offset the natural self-discharge rate of the battery. A similar approach is suggested by

Energizer[16]

which indicates that the self catalysis can recombine gas formed at the anode for

charge rates up to C/10, but as this leads to cell heating, recommends C/30 or C/40 for

indefinite applications where long life is important. This is the approach taken in maintained

emergency light fittings (which in Europe must remain on for 4 hours in the event of a power

cut) where the design remains essentially the same as that used in older NiCd units, but for an

increase in the trickle charging resistor value. In comparison, NiCd cells can ordinarily be

charged indefinitely at C/10 without damage.

Panasonic's handbook, however, recommends that NiMH batteries on standby are kept charged

by a lower duty cycle approach, where a pulse of a higher current is used whenever the battery's

voltage drops below 1.3 V. This can extend battery life and use less energy.[14]

ΔV charging method

NiMH Charge curve

In order to charge a NiMH battery faster than the trickle method suggested above, a charger

must know when to stop charging in order to avoid damaging the battery. One method is to

monitor the change of voltage across the battery with time. As can be seen in the charge curve

diagram, when the battery is fully charged the voltage across its terminals drops slightly. The

charger can detect this and stop charging. This method is often used with nickel-cadmium cells

which have a large drop in voltage at full charge but the voltage drop is much less pronounced

for NiMH and can be non-existent at low charge rates, which can make the approach

unreliable. Another option is to monitor the change of voltage with respect to time and stop

when this becomes zero, but this runs the risk of premature cutoffs.[15]

With this method, a much higher charging rate can be used than with a trickle charge, up to 1

C. At this charge rate, looking for a voltage drop, ΔV is approximately 5–10mV per cell.[14]

Since this method measures the voltage across the battery, a constant current (rather than a

41

constant voltage) charging circuit must be used. This is unlike a lead–acid cell for example,

which can, in theory, be more easily charged at a suitably chosen constant voltage.

ΔT temperature charging method

The ΔT temperature change method is similar in principle to the ΔV method. Because the

charging voltage is nearly constant, constant-current charging delivers energy at a near-constant

rate. When the cell is not fully charged, most of this energy is converted to chemical energy.

However, when the cell reaches full charge, most of the charging energy is converted to heat.

This increases the rate of change of battery temperature, which can be detected by a sensor such

as a thermistor. Both Panasonic and Duracell suggest a maximum rate of temperature increase

of 1 °C per minute. Using a temperature sensor also allows an absolute temperature cutoff,

which Duracell suggests at 60 °C.[15]

With both the ΔT and the ΔV charging methods, both manufacturers recommend a further

period of trickle charging to follow the initial rapid charge.

Safety

NiMH that popped its cap due to failed safety valve

A good safety feature of a custom-built charger is to use a resettable fuse in series with the cell,

particularly of the bimetallic strip type. This fuse will open if either the current or the

temperature goes too high.[15]

Modern NiMH cells contain catalysts to immediately deal with gases developed as a result of

over-charging without being harmed (2 H2 + O2 ---catalyst → 2 H2O). However, this only

works with overcharging currents of up to 0.1C (nominal capacity divided by 10 hours). As a

result of this reaction, the batteries will heat up considerably, marking the end of the charging

process.[15]

Some quick chargers have a fan to keep the batteries cool.

A method for very rapid charging called in-cell charge control involves an internal pressure

switch in the cell, which disconnects the charging current in the event of overpressure.

There is an inherent risk with NiMH chemistry that overcharging will cause a buildup of

hydrogen, causing the cell to rupture. Therefore, cells have a vent. Hydrogen will be emitted

from the vent in the event of serious overcharging.[17]

42

Discharging

A fully charged cell supplies an average 1.25 V/cell during discharge, down to about 1.0–1.1

V/cell (further discharge may cause permanent damage in the case of multi-cell packs, due to

polarity reversal). Under a light load (0.5 ampere), the starting voltage of a freshly charged AA

NiMH cell in good condition is about 1.4 volts;[18]

Over-discharging

A complete discharge of a cell until it goes into polarity reversal can cause permanent damage

to the cell. This situation can occur in the common arrangement of four AA cells in series in a

digital camera, where one will be completely discharged before the others due to small

differences in capacity among the cells. When this happens, the good cells will start to drive the

discharged cell in reverse, which can cause permanent damage to that cell. Some cameras, GPS

receivers and PDAs detect the safe end-of-discharge voltage of the series cells and auto-

shutdown, but devices like flashlights and some toys do not. A single cell driving a load can't

suffer from polarity reversal, because there are no other cells to reverse-charge it when it

becomes discharged.

Irreversible damage from polarity reversal is a particular danger in systems, even when a low

voltage threshold cutout is employed, where cells in the battery are of different temperatures.

This is because the capacity of NiMH cells significantly declines as the cells are cooled. This

results in a lower voltage under load of the colder cells.[19]

Self-discharge

NiMH cells historically had a somewhat higher self-discharge rate (equivalent to internal

leakage) than NiCd cells. The self-discharge varies strongly with temperature where lower

storage temperature leads to slower discharge rate and longer battery life. The self-discharge is

5 – 20% on the first day and stabilizes around 0.5 – 4% per day at room

temperature.[20][21][22][23][24]

But at 45 °C it's approximately 3 times as high.[15]

This is not a

problem in the short term but makes them unsuitable for many light-duty uses, such as clocks,

remote controls, or safety devices, where the battery would normally be expected to last many

months or years. The highest capacity cells on the market (>8000 mA·h) are reported to have

the highest self-discharge rates.[citation needed]

Low self-discharge cells

43

Eneloop low self-discharge NiMH batteries

A new type of nickel–metal hydride cell (the low self-discharge nickel-metal hydride battery,

LSD NiMH) was introduced in 2005 that reduces self-discharge and therefore lengthens shelf

life. By using an improved electrode separator and improved positive electrode, manufacturers

claim the cells retain 70% to 85% of their capacity after one year when stored at 20 °C (68 °F).

These cells are marketed as "hybrid", "ready-to-use" or "pre-charged" rechargeables. Standard

NiMH batteries may lose half their charge in the same time period. Retention of charge

depends a lot on the battery's impedance or internal resistance (the lower the better), and on the

size of the battery as well as the mAh rating. Besides the longer shelf life, they are otherwise

similar to normal NiMH batteries of equivalent capacity and can be charged in typical NiMH

chargers.

Low self-discharge cells have lower capacity than some standard NiMH cells due to the larger

area of the separator. The highest capacity low-self-discharge cells have 2000–2500 mA·h and

1000 mA·h capacities for AA and AAA cells respectively, compared to 2800 mA·h and 1300

mA·h for standard AA and AAA cells.[25]

C types are typically higher than their usual NiMH

cousins, with 4000 mA·h and the D type being 8000 mA·h[citation needed]

.

High quality separators are very important for battery performance. Thick separators take up

space and reduce capacity, while providing a low-tech way of reducing self discharge, while

thin separators tend to raise the self discharge rate. Some batteries may have overcome this

obstacle with more precise manufacturing techniques and by using a more advanced sulfonated

polyolefin separator.[further explanation needed]

Batteries with low internal resistance waste less energy and capacity on self-heating during

rapid discharge and recharge. Low self-discharge NiMH batteries typically have significantly

less internal resistance than traditional NiMH batteries.[citation needed]

LSD NiMH batteries were introduced in November 2005 by Sanyo,[26]

marketing them under

the brand "eneloop".

There are many brand names for LSD NiMH batteries. Most manufacturers produce only size

AAA and AA batteries, and most low self discharge batteries are sold in these sizes. Larger size

C and D cells are available, though some are merely AA cells inside a C/D-sized case. Maha

offers an LSD "D"-cell called the "Imedion" self-rated at 9500 mAh, Accupower offers the

"Acculoop" self-rated at 8500 mAh, and Tenergy offers the "Centura" self-rated at 8000

mAh.[citation needed]

Varta (USA: Rayovac) and Ansmann increased their LSD NiMH batteries' capacity to roughly

2300 mAh. Sanyo introduced a new version of its Eneloop batteries with increased capacity

and life expectancy. The "Eneloop plus" incorporates a PTC thermistor that disconnects the

power if the battery overheats, in order to make it safe for use in toys for small children.

44

Environmental impact

Improper disposal of NiMH batteries poses less environmental hazard than that of NiCd

because of the absence of toxic cadmium. However, mining and processing the various

alternate metals that form the negative electrode may pose other types of environmental impact,

depending on the metal, mining method, and environmental practices of the mine.

Most industrial nickel is recycled, due to the relatively easy retrieval of the magnetic element

from scrap using electromagnets, and due to its high value.[citation needed]

Comparison with other battery types

NiMH cells and chargers are readily available in retail stores in the common sizes AAA and

AA. Adapter sleeves are available to use the more common AA size in C and D applications.

The sizes C and D cells are somewhat available, but are often just a AA core hidden in an outer

shell, with a rating of about 2500 mA·h, much less than ordinary alkaline C and D

batteries.[citation needed]

Real NiMH C and D batteries are expensive (and the chargers are

uncommon); they should be rated at least 5000 mA·h for C and 10,000 mA·h for D sizes.

PP3 (nine volt) NiMH batteries are available; these usually have an output voltage of 8.4 V (1.2

× 7) and a capacity of roughly 200 mA·h.[27]

Also available are eight-cell nine volt batteries

with a nominal output voltage of 9.6 V (1.2 × 8).

NiMH cells are not expensive, and the voltage and performance is similar to primary alkaline

cells in those sizes; they can be substituted for most purposes. Although alkaline cells are rated

at 1.5 volts and NiMH cells at 1.2 volts, during discharge the alkaline voltage eventually drops

below that of NiMH. This is particularly true for high drain applications, where the voltage of

even a fresh alkaline battery can be lower than a NiMH battery while under a load.

Furthermore, NiMH batteries offer a flatter discharge curve, particularly at higher current

draw.[28]

NiMH cells are often used in digital cameras and other high drain devices, where over the

duration of single charge use they outperform primary (such as alkaline) batteries.[28]

Applications that require frequent replacement of the battery, such as toys or video game

controllers, also benefit from use of rechargeable batteries. With the development of low self-

discharge NiMHs (see section above), many occasional-use and very low-power applications

are now candidates for NiMH cells.[29]

NiMH cells are particularly advantageous for high current drain applications, due in large part

to their low internal resistance. Alkaline batteries, which might have approximately 3000 mA·h

capacity at low current demand (200 mA), will have about 700 mA·h capacity with a 1000 mA

load.[30]

Digital cameras with LCDs and flashlights can draw over 1000 mA, quickly depleting

alkaline batteries. NiMH cells can deliver these current levels and maintain their full capacity.

Certain devices that were designed to operate using primary alkaline chemistry (or zinc–

carbon/chloride) cells will not function when one uses NiMH cells as substitutes. However, this

is rare, as most devices compensate for the voltage drop of an alkaline as it discharges down to

about 1 volt. Low internal resistance allows NiMH cells to deliver a near-constant voltage until

they are almost completely discharged. This will cause a battery level indicator to overstate the

45

remaining charge if it was designed to read only the voltage curve of alkaline cells. The voltage

of alkaline cells decreases steadily during most of the discharge cycle.

Lithium-ion batteries have a higher specific energy than nickel–metal hydride batteries,[31]

but

they are significantly more expensive to produce.[32]

In October 2009, ECD Ovonics announced

that their next-generation NiMH batteries will provide specific energy and power that are

comparable to those of lithium ion batteries at a cost that is significantly lower than the cost of

lithium ion batteries.[32]

Applications

High power Ni-MH battery of Toyota NHW20 Prius, Japan

Nickel–metal hydride 24V battery pack made by VARTA, Museum Autovision, Altlussheim,

Germany

Applications of NiMH electric vehicle batteries includes all-electric plug-in vehicles such as

the General Motors EV1, Honda EV Plus, Ford Ranger EV and Vectrix scooter. Hybrid

vehicles such as the Toyota Prius, Honda Insight, Ford Escape Hybrid, Chevrolet Malibu

Hybrid, and Honda Civic Hybrid also use them. NiMH technology is used extensively in

rechargeable batteries for consumer electronics, and it will also be used on the Alstom Citadis

low floor tram ordered for Nice, France; as well as the humanoid prototype robot ASIMO

designed by Honda. NiMH batteries are also commonly used in remote control cars.

Electric vehicles

Main article: Patent encumbrance of large automotive NiMH batteries

Stanford R. Ovshinsky invented and patented (a popular improvement of) the NiMH battery

and founded Ovonic Battery Company in 1982. General Motors purchased the patent from

Ovonics in 1994. By the late 1990s, NiMH batteries were being used successfully in many fully

electric vehicles, such as the General Motors EV1 and Dodge Caravan EPIC minivan. In

October 2000, the patent was sold to Texaco and a week later Texaco was acquired by

Chevron. Chevron's Cobasys subsidiary will only provide these batteries to large OEM orders.

General Motors shut down production of the EV1 citing lack of battery availability as one of

46

their chief obstacles. The Cobasys control of NiMH batteries has created a patent encumbrance

of large automotive NiMH batteries.[33][34][35][36][37]

Telecommunications

In recent years, NiMH batteries are being deployed to provide reliable backup power to load

equipment located in a network environment of a typical telecommunications service provider.

The NiMH batteries are recommended for use in the Central Office (CO), Outside Plant (OSP),

and at locations such as Controlled Environmental Vaults (CEVs), Electronic Equipment

Enclosures (EEEs), huts, and in uncontrolled structures such as cabinets.

To ensure conformance and product safety, the telecommunications industry has accepted a

three-level compliance system, which is described in GR-3168, Generic Requirements for

Nickel Metal Hydride (NiMH) Battery Systems for Telecommunications Use. The compliance

system provides a common framework for evaluating and qualifying various NiMH battery

technologies. The framework intends to alleviate the complexities associated with product

introduction and qualification.

The service life of NiMH batteries is extremely important in a telecommunications

environment. The main failure modes of lead-acid batteries are very temperature sensitive. Grid

corrosion and water loss are sped up as the battery temperature increases. The rate of battery

degradation doubles with each 8 °C (15°F) rise in temperature. Thus, a battery designed to

operate for 10 years at 25 °C (77°F) approximately would last only 5 years at 33 °C (92°F), and

would last only 2.5 years at 42 °C (107°F).

Nickel–cadmium (NiCd) batteries fail in a different manner. NiCd batteries are susceptible to

failures caused by short circuiting due to dissolution/crystallization reactions occurring at the

negative electrode, which can result in dendrite growth of Cd creating a short to the positive

plate.

NiMH batteries do not fail in the same way as NiCd or lead-acid batteries. NiMH batteries fail

in two predominant modes that are somewhat interrelated. The metal hydride material used for

the negative electrode undergoes gradual corrosion in a strong alkaline environment. This

corrosion results in less negative active material for hydrogen storage and also consumes water

from the electrolyte.

This results in a gradual loss of power as water is consumed, increasing the cell resistance and a

gradual loss in capacity as active material is converted to corrosion products. By optimization

of the alloy composition, this corrosion process can be controlled at very low rates. The rate of

corrosion will be impacted by various factors including temperature, State of Charge (SoC),

and control of overcharge and oxygen recombination. Studies under controlled overcharge

conditions predict that the rate of battery degradation will double for approximately each 20 °C

(36°F) rise in temperature. Thus, a battery designed to operate for 20 years at 25 °C (77°F)

would last 10 years at 45 °C (113°F). Extrapolation beyond 45 °C is not linear since other

failure modes, caused by decreasing charge acceptance resulting in positive electrode swelling

and thermal instability, could control the battery life.

47

Retrieved from "http://en.wikipedia.org/w/index.php?title=Nickel–

metal_hydride_battery&oldid=524204884"

48

Appendiks 4:

XBee materialemængder og typer:

49

Appendiks 5:

LCA analyse på wireless løsning versus trådet løsning. Løsningsmodel 1 (wireless): En sensor med tilhørende selvforsynende strømkilde (solpanel + genopladelige batterier) er forbundet til en interfaceenhed/trådløs transmitter, som sender data trådløst til et (online) dataopsamlingssted. Løsningsmodel 2 (trådet): En sensor er forbundet til en interfaceenhed/trådet transmitter, som sender data via kabel til et (online) dataopsamlingssted. Strømforsyning til sensoren leveres gennem den trådede forbindelse. Målet for LCA analyse er at se forskellen mellem en wireless sensorløsning og en trådet sensorløsning. Med udgangspunkt i de to forskellige løsninger beregnes materialeforbrug samt energiforbrug ved hver af løsningerne:

a) Materialeforbruget estimeres ud fra vægten af de indgående printkort/komponenter, der er

forskellige for de to løsninger. Dette gøres for rå-materiale-fasen og produktionsfasen som

en samlet størrelse, baseret på erfaringstal udleveret under kurset.

b) Energiforbruget estimeres ligeledes ud fra de indgående dele

c) Energiforbruget i drift estimeres for en levetid på 10 år

d) Energiforbruget (genvindingsenergi) estimeres ved disposal fasen.

Resultatet for de to løsninger holdes op mod hinanden. For begge løsningers vedkommende er sensorelektronikken vurderet til at være det samme (i vort tilfælde med en kompleksiset svarende til et XBee modul). XBee modulet er derfor udeladt ved sammenligningen af de to løsninger – men for god ordens skyld er der regnet energi og ressource på XBee modulet også. Ligeledes er opsamlingselektronikken vurderes til at være ens i de to tilfælde og er derfor ikke medtaget i den sammenlignende evaluering. Hovedresultatet ses næste side - detailmaterialet kan findes i spreatsheet LCAtotalsolution.xlsa.

50

Løsning 1 (wireless):

MECO chart for Wireless transmission system (excl Xbee) due to Solar Cell and Battery

raw materials

phase Production

phase Use phase Disposal

phase Transport

phase

raw material Quantity(kg) incl in ->

Resources(mPR) incl in -> 94+15=109

Energy Primary(MJ) 2039+365=3004 1,38 4,25

Resources

Chemicals

Other

Løsning 2 (trådet):

MECO chart for wired transmission system (excl. Xbee) due to 50m wire (values in mPR)

raw materials phase

Production phase Use phase

Disposal phase

Transport phase

raw material Quantity(Kg) incl in ->

Resources(mPR) incl in -> 3,3

Energy Primary(MJ) 7,16 1,38 5,5

Resources(mPR)

Chemicals

Other

Konklusion: Som det klart fremgår af ovenstående er der et væsentlig forhøjet ressourceforbrug ved anvendelse af solcelle og genopladeligt batteri i løsning 1 i forhold til at anvende en trådet løsning. Dette er forventeligt fordi solceller udgør en mere energikrævende proces end fremstilling af Cu-tråd. Dertil kommer at man ved den trådløse forsyning først skal konverter lys (elektromagnetiske bølger med meget begrænset effekt til rådighed) til dc-energi for efterfølgende at konvertere tilbage aht den trådløse transmissionen. I ovenstående er ikke taget hensyn til forbruget i transportfasen – men dette vil sandsynligvis belaste den trådløse løsning yderligere pga større transport verden rundt i forbindelse med produktionsprocessen.

51

Appendiks 6:

Client-Cosm kommunikation.

Kildekode til brugt program på Arduino I-Board.

#include <SPI.h>

#include <Ethernet.h>

#define APIKEY "7rM9u6n3UeyXXslrPGdDwY4nYrGSAKxleGdrakh5QTM5MD0g"

#define FEEDID 89822

#define USERAGENT "Cosm Arduino Example (89822)"

// Set MAC Address

byte mac[] = {0x36, 0x37, 0x3A, 0x0A, 0x00, 0x05};

// Set IP Address

IPAddress ip(172,30,250,5);

// Name Address for Cosm API

char server[] = "api.cosm.com";

// Source address of the connected zigbee device

byte addr[] = {0x00, 0x13, 0xA2, 0x00, 0x40, 0x79, 0x9B, 0x12};

// Variables used for connection information

unsigned long lastConnectionTime = 0;

boolean lastConnected = false;

EthernetClient client;

// Variables used for data passing

String sensorName = "SensorData";

int sensorReading = 0;

int analogHigh = 0;

int analogLow = 0;

void setup() {

Serial.begin(9600);

delay(1000);

if (Ethernet.begin(mac) == 0) {

// DHCP failed to give an IP Address, so a fixed IP address is used.

Ethernet.begin(mac, ip);

}

}

void loop() {

// Try to read a package.

52

if (readPackage() == -1) {

return;

}

// Stop the client if there is no net connection, but there was one last time

if (!client.connected() && lastConnected) {

Serial.println("Stop client");

client.stop();

}

// If no connection is open, open one and send data to cosm

if(!client.connected()) {

uploadDataToCosm(sensorName, sensorReading);

}

// Empty the buffer

if (client.available()) {

client.flush();

}

// Store the state of the connection

lastConnected = client.connected();

}

int readPackage() {

analogHigh = 0;

analogLow = 0;

// If enough bytes for the complete package is in the buffer

if(Serial.available() >= 21) {

// Look for the start byte

if (Serial.read() == 0x7E) {

// Calculate the amount of bytes that should be expected

// from this point to the checksum

int dataLength = (Serial.read() << 8) + Serial.read();

// Varibles used to calculate the checksum

int tempRead = 0;

int checksum = 0;

// Check if the frame type is correct

tempRead = Serial.read();

checksum = checksum + tempRead;

if (tempRead != 0x92) return -1;

53

// Check if the address is correct

for (int i = 0; i < 8; i++) {

tempRead = Serial.read();

checksum = checksum + tempRead;

delayMicroseconds(500);

if (tempRead != addr[i]) return -1;

}

// Ignores the 16-bit address

for (int i = 0; i < 2; i++) {

checksum = checksum + Serial.read();

delayMicroseconds(500);

}

// Check if receive option confirms that the packet was acknowledged (0x01)

// and that the packet was sent from an end device (0x40).

tempRead = Serial.read();

checksum = checksum + tempRead;

if (tempRead != 0x41) return -1;

// Check if number of samples is correct

tempRead = Serial.read();

checksum = checksum + tempRead;

if (tempRead != 0x01) return -1;

// Ignores the bytes before the data values

for (int i = 13; i < (dataLength - 2); i++) {

checksum = checksum + Serial.read();

}

// Read data values

analogHigh = Serial.read();

checksum = checksum + analogHigh;

analogLow = Serial.read();

checksum = checksum + analogLow;

sensorReading = analogLow + (analogHigh * 256);

// Validates the checksum

checksum = 0xFF - checksum;

tempRead = Serial.read();

if ((byte)tempRead != byte(checksum)) {

54

return -1;

}

}

}

return 0;

}

void uploadDataToCosm(String name, int value) {

// If there is a successful connection

if (client.connect(server, 80)) {

String cosmData = name + ", " + String(value);

// Send the HTTP PUT request

client.print("PUT /v2/feeds/");

client.print(FEEDID);

client.println(".csv HTTP/1.1");

client.println("Host: api.cosm.com");

client.print("X-ApiKey: ");

client.println(APIKEY);

client.print("User-Agent: ");

client.println(USERAGENT);

client.print("Content-Length: ");

client.println(cosmData.length());

client.println("Content-Type: text/csv");

client.println("Connection: close");

client.println();

client.println(cosmData);

} else {

// If no connection could be made

client.stop();

}

}

55

Appendiks 7:

Cisco: LLC layer

Introduction

IEEE standard 802.2 defines Logical Link Control (LLC) as a data link control layer used on 802.3, 802.5, and other networks. IBM originally designed LLC as a sublayer in the IBM Token Ring architecture.

Prerequisites

Requirements

Cisco recommends that you have knowledge of these topics:

A basic understanding of LLC

Components Used

This document is not restricted to specific software and hardware versions.

The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If your network is live, make sure that you understand the potential impact of any command.

Conventions

Refer to Cisco Technical Tips Conventions for more information on document conventions.

Background Information

The LLC layer provides connectionless and connection-oriented data transfer.

Connectionless data transfer is commonly referred to as LLC type 1, or LLC1. Connectionless service does not require you to establish data links or link stations. After a Service Access Point (SAP) has been enabled, the SAP can send and receive information to and from a remote SAP that also uses connectionless service. Connectionless service does not have any mode setting commands (such as SABME) and does not require that state information is maintained.

Connection-oriented data transfer is referred to as LLC type 2, or LLC2. Connection-oriented service requires the establishment of link stations. When the link station is established, a mode setting command is necessary. Thereafter, each link station is responsible to maintain link state information.

56

Implementations of LLC

LLC2 is implemented whenever Systems Network Architecture (SNA) runs over a LAN or virtual LAN. LLC2 is also directly encapsulated into Frame Relay. Sometimes the router simply passes LLC2 frames and sometimes the router implements an LLC2 linkstation. NetBIOS also uses LLC. NetBIOS uses LLC1 to locate a resource. LLC2 connection-oriented sessions are then established.

The router implements an LLC2 stack when any of these features are enabled:

Data-Link Switching (DLSw) (connection to LAN) Remote Source-Route Bridging (RSRB) with local ACK Channel Interface Processor (CIP) Advanced Peer-to-Peer Networking (SNASwitching (SNASw)) Synchronous Data Link Control (SDLC) to LCC Conversion (SDLLC)

Basic Information You Must Know in Order to Troubleshoot

A basic knowledge of LLC is enough to isolate and resolve most problems. Because there are no link states or sessions to maintain, problems are rare in LLC1.

In LLC2, two categories of problems can occur:

1. Sessions that do not establish 2. Established sessions that intermittently fail

In order to solve these issues you need to know about these topics:

LLC Frame Formats LLC2 Modes and Session Establishment LLC2 Asynchronous Balanced Mode Operation LLC2 Error Conditions

LLC Frame Formats

This section provides information on LLC frame formats.

DSAP/SSAP Control

Destination Service Access Point (1 byte)

Control Field - Unnumbered (1 byte)

dddd

ddxx

xxxx

xx1x

xxxx

xxx1

Dest.

Addr.

IEEE

Defined

Group

Address

CCCC CC11

000F 1111

010P 0011

011F 0011

011P 1111

100F 0111

xx-xx

0F-1F

43-53

63-73

6F-7F

87-97

Unnumbered format

Disconnect Mode

Disconnect

Unnumbered Ack.

SABME

Frame Reject

57

101z 1111

111z 0011

AF-BF

E3-F3

XID

Test

Source Service Access Point (1 byte)

Control Field - Supervisory ( 2 bytes )

ssss

ssxx

xxxx

xx1x

xxxx

xxx1

Source

Address

IEEE

defined

Response

LPDU

CCCC CC01

0000 0001

0000 0101

0000 1001

xx-xx

01-xx

05-xx

09-xx

Supervisory Format

Receiver Ready

Receiver Not Ready

Reject

Control Field - Information frames (2 bytes)

ssss sss0 xxxx Information format

P = Poll bit set to "1" F = Final bit set to "1" Z = Poll/Final bit set to either "0" or "1"

An LLC frame is called an LLC Protocol Data Unit (LPDU), and is formatted as shown here:

DSAP (1 byte)-SSAP (1 byte)-Control Field (1 or 2

bytes)-Information Field

(0 or more bytes)

DSAP Field

The Destination Service Access Point (DSAP) identifies the SAP for which the LPDU is intended. The DSAP consists of six address bits, a user bit (U) and an Individual/Group (I/G) bit, organized as shown here:

D-D-D-D-D-D-D-I/G

The U bit indicates whether the address is defined by the IEEE (1) or user-defined (0). The I/G bit indicates whether the SAP is a group address (1) or individual address (0). For our purposes, neither of these bits are too important. All you really need to know is that the DSAP is the destination of the LPDU. Some common ones appear over and over.

SSAP Field

The Source Service Access Point (SSAP) identifies the SAP which originated the LPDU. The SSAP consists of six address bits, a user bit (U) and a Command/Response (C/R) bit, organized as shown here:

S-S-S-S-S-S-U-C/R

The U bit indicates whether the address is defined by the IEEE (1) or user-defined (0). The C/R bit indicates whether the LPDU is a command or response. When LPDU frames are received, the C/R bit is not considered part of the SSAP. Therefore, the SSAP is normally considered to be only the leftmost seven bits.

58

Control Field

The LPDU control field contains command, response, and sequence number information. You need to know how to decode the control field in order to determine what happens on a particular LLC2 session. However, decoding information is readily available.

There are three typws of frames:

I Frames Supervisory Frames Unnumbered Frames

Although each type has a different format for the control field, you can easily distinguish them through an examination of two bits in the control field.

X-X-X-X-X-X-X-0 = I Frame

X-X-X-X-X-X-0-1 = Supervisory Frame

X-X-X-X-X-X-1-1 = Unnumbered frame

The next few sections explain each type of control field.

I Frame

I frames enable you to transfer sequentially-numbered LPDUs that contain information (connection-oriented) between link stations. The format of the I frame contains an NS and NR count. The NS count is the sequence number (modulo 128) of the LPDU currently in transmission. The NR count is the sequence number of the next LPDU I frame that the sender expects to receive. To help you later, remember that NR means "next receive."

NS-NS-NS-NS-NS-NS-NS-0-NR-NR-NR-NR-NR-NR-P/F

The P/F bit is called the P bit in command LPDUs and the F bit in response LPDUs. The P/F bit is set in command LPDUs to request that the remote link station send a response with this bit set. Only one response must be received with the F bit set for every command sent with the P bit set. There are some other details about the use of the P/F bit in relation to error recovery, but that is the general rule.

Supervisory Frame

Supervisory frames perform supervisory control functions, for example, to acknowledge I Frames (RR), to request retransmission of I frames (REJ), and to request temporary suspension (RNR) of I frames. Supervisory frames do not contain an information field. Therefore, supervisory frames do not affect the NS in the sending station, and so do not contain an NS field. Here is the format of a supervisory frame:

0-0-0-0-S-S-0-1-NR-NR-NR-NR-NR-NR-NR-P/F

59

The "S" bits indicate the type of supervisory frame.

B'00' = Receiver Ready

A station uses the RR to indicate that the station is ready to receive, and contains the NR count of the next I frame that is due to arrive. When a station sends an RR frame, the station acknowledges receipt of numbered I frames from the remote station of up to NR - 1.

B'01'=Receiver Not Ready

A station uses the RNR to indicate that the station is temporarily not ready to receive. RNR also contains the NR count which follows the same rules RR. Transient periods of RNRs are not always indicative of a network problem. If RNRs are persistent, look for congestion in the end station.

B'10'=Reject

A station uses the REJ to request the retransmission of I frame LPDUs starting with the number indicated in the NR count. REJ is not indicative of a serious problem (which means it is recoverable). If you see many REJ commands, look for missing (dropped) I frames in the opposite direction. Do not confuse an REJ with a Frame reject (FRMR). A FRMR is an unnumbered frame and is always indicative of a serious problem.

Unnumbered Frames

Unnumbered frames provide link control functions, for example, mode setting commands and responses. In some cases, unnumbered information frames can also be sent. Unnumbered frames are only one byte in length. They do not contain fields for NR or NRS counts. Here is the format of an unnumbered frame:

M-M-M-P/F-M-M-1-1

The "M" bits indicate the type of unnumbered frame.

B'00011'=DM Response (0x1F)

A link station sends a DM response to report that it is in asynchronous disconnect mode. This means is that the link is not active. If a link station was active and suddenly begins to send DMs, the link station was probably reset.

B'01000'=DISC Command (0x53)

A link station sends a DISC to terminate asynchronous balanced mode. The DISC command informs the remote link station that it suspends operation. The correct response to a DISC command is a UA (if the station is in ABM), or a DM (if the station is in ADM).

B'01100'=UA Response(0x73)

60

A link station sends an UA in response to the SABME and DISC commands.

B'01111'=SABME Command(0x7F)

A link station sends a SABME to initiate data transfer in asynchronous balanced mode. The correct response to a SABME is a UA. When a station receives a SABME command, the station resets the NR and NS counts to zero. The sending station does likewise when it receives the UA response.

B'10001'=FRMR Response(0x87)

A link station sends a Frame Reject response to report an error in an incoming LPDU from the other link station. When you see a FRMR, the station that sends the FRMR has detected an unrecoverable error. It is not the cause of the error. Any frames that arrive after the FRMR error has occurred are ignored until a DISC or SABME is received.

A FRMR response contains information about the cause of the FRMR condition.

Bytes 0 and 1 contain the contents of the control field of the LPDU which caused the frame reject. Bytes 2 and 3 contain the NS an NR counts, respectively. Byte 4 contains several bits that identify the type of error as shown here:

0-0-0-V-Z-Y-W-X

The V bit indicates that the NS number carried by the control field in bytes 0 and 1 is invalid. An NS is invalid if greater than or equal to the last NS plus the maximum receive window size. When this condition occurs, the link station sends a REJ LPDU, not a FRMR response.

The Z bit indicates that the NR that the control field carries indicated in bytes 0 and 1 does not refer to either the next I frame or an I frame that has already been transmitted but not acknowledged.

Note: It is all right to receive the the same NR count multiple times.

The NR count is only invalid if the count references an I frame that has already been acknowledged or if the count skips ahead to one that has not been transmitted yet. The former is the most common case of this type of error. When you see this type of error, it usually means frames were received out of sequence, and you should look for the network that delivers frames out of order. It is possible that the sending link station transmitted them out of order, but very unlikely.

The Y bit indicates that the length of the I field in the received LPDU exceeded the available buffer capacity. If this situation occurs, look for problems in the end stations, not the network.

61

The X bit indicates that the LPDU contained an I field when it must not have, or a FRMR response was received that did not contain 5 bytes. This appears to be an end station problem, not a network problem.

The W bit indicates that an unsupported LPDU was received. This is an end station problem.

B'10111' XID Command or Response

A link station uses the XID command to convey characteristics of the sending node and to cause the remote link station to respond with an XID response. Link stations can send and receive XIDs in various formats, including SNA formats.

B'11100' TEST Command or Response

A link station sends the TEST command to cause the remote link station to respond with a TEST response as soon as possible. The TEST command is generally used for path discovery in a source-route bridging environment.

LLC Control Field Summary

Value Unnumbered Frames

0x0F or 0x1F Disconnect Mode (DM) Response

0x43 or 0x53 Disconnect (DISC) Command

0x63 or 0x73 Unnumbered Acknowledgment (UA) Response

0x6F or 0x7F Set Asynchronous Balanced Mode (SABME) Command

0x87 or 0x97 Frame Reject (FRMR) Response

0xAF or 0xBF Exchange Id (XID) Command or Response

0xE3 or 0xF3 Test (TEST) Command or Response

Value Supervisory Frames

0x01 Receiver Ready (RR)

0x05 Receiver Not Ready (RNR)

0x09 Reject (REJ)

62

Value Information Frames

0bnnnnnnn0 Information Frame (INFO)