AALBORG UNIVERSITET - DupontKoustrup.dk

Titelblad
AALBORG UNIVERSITET
Den Teknisk-Naturvidenskabelige Basisuddannelse
Titel: Automatisk radiatorstyring
Tema: Modellernes virkelighed
Undertema: Modeller for dynamiske systemer
Projektperiode: P2
Storgruppe: 9933
Projektgruppe: 220
Projektgruppens deltagere:
__________________
Christian Lodberg
__________________
Lars Alminde
__________________
Morten Bisgaard
__________________
Per Thoft Kærsgaard
__________________
Toke Koustrup
__________________
Tor Viscor
Vejledere:
Lars Peter Jensen
Søren Hansen
Oplagstal: 10
Rapport sideantal: 100
Bilag: 7
Afsluttet: 23. maj 2000
Synopsis.
Vi har i dette projekt valgt at arbejde med
automatisk radiatorsyring. Først analyseres
baggrunden for en sådan styring, hvorefter
der på baggrund af denne analyse benyttes
matematisk modellering til opstilling af en
model. Som led i opstillingen af den
matematiske model benyttedes test og
forsøgsresultater omkring en fysik model.
Den matematisk model blev brugt til
opstilling af en række regulerings algoritmer,
der implementeredes i hardwaren. Dvs. at vi
har skabt et embedded system, hvor vi har
realiseren softwareløsningen i en
hardwareløsning.
Desuden anvendes seriel kommunikation
mellem en PC og hardwaren. Sluttelig testes
løsningen og der laves en teknologi
vurdering, som anvendes med udgangspunkt
i samfundet.
I

I Forord
Forord & Læsevejledning
Vi er en gruppe på 6 personer, der har valgt at arbejde med automatisk radiatorstyring. Vi har valgt
projekt på baggrund af, at vi har set udfordringer og muligheder for udvikling inden for hardware
og software til løsning af problemstillingen.
II Læsevejledning
Kilder er markeret med firkantede klammer, f.eks. [Haugen]. Der vil af klammerne kun fremgå
efternavnet eller en unik betegnelse. Resten af oplysningerne kan findes i litteraturlisten. Figurer har
et unikt nummer. F.eks. figur 5.1. Alle figurer består af kapitlets nummer, efterfulgt af et
fortløbende nummer, startende forfra ved hver kapitelstart. Formler er angivet i parenteser efter
kapitel efterfulgt af et nummer. F.eks. vil den 3. formel i kapitel 2 være angivet (2.3).
Fodnoter er angivet med tal 1 skrevet med hævet skrift og henviser til en note nederst på siden.
Målgruppen er studerende på vores eget niveau og folk med interesse for hardware og software.
Vi er opmærksomme på, at kilder fra internettet jævnligt opdateres og flyttes, hvorfor de anvendte
kilder ligger på den vedlagte diskette i mappen "kilder". Når der henvises til integrerede
komponenter benyttes disses serienumre. For yderligere information omkring disse komponenter
henvises der til disses datablade.
II

III Rapport struktur
Vi vælger at opdele rapporten i 3 hoveddele:
− Analysedel
− Løsningsdel
− Vurderingsdel.
Indholdsfortegnelse
I analysedelen gennemføres først Problemanalysen for at undersøge om der er et marked for en
automatisk radiatorstyring, hvorefter projektet afgrænses til en løsning rettet imod en testmodel og
der opstilles krav til løsningsdelen. Derefter analyseres denne model i Modellering for at skabe
indblik i hvorledes system opfører sig og der opstilles en matematisk model til at beskrive denne
opførsel.
I løsningsdelen benyttes den matematiske model i Regulering som baggrund for en konstruktion
af en reguleringsalgoritme. Denne algoritme opstiller nogle krav til hardwaren der derefter
opbygges og beskrives i afsnittet Hardware. Så kan den serielle kommunikation opbygges og skaber
derved en kommunikationsvej for hardwaren udadtil, hvilket bliver beskrevet i Seriel
kommunikation. Efter at denne kommunikation er opbygget kan den softwaren der skal ligge i
hardwaren fremstilles på baggrund af de forrige afsnit i løsningsdelen og beskrives i MCUsoftware.
Endelig kan softwaren til PC'en udvikles som et interface således at det bliver muligt at
påvirke reguleringen, hvilket gøres i afsnittet PC-software.
I vurderingsdelen testes den samlede løsning og der konkluderes om hvorvidt løsningen opfylder
kravene opstillet i analysedelen. Derefter vurderes den behandlede teknologi i forhold til
forbrugeren og samfundet i Teknologi Vurdering og endelig konkluderes på baggrund af test og
teknologivurdering over den samlede rapport.
For at skabe overblik over rapportens opbygning opbygges et strukturdiagram, se nedenstående fig
A.
Problem-
analyse
Rapport
Analyse Løsning Vurdering
Model-
lering
Regule-
ring
Seriel-
kommunikation
Hardware Software
MCU PC
Figur A - Strukturdiagram over rapporten.
Test
Konklusion
Teknologi-
vurdering
Gennem rapporten forefindes strukturdiagrammet som i formindsket udgave i sidehovedet således
at læseren kan se i hvilken del af rapporten han befinder sig.
III

Indholdsfortegnelse
Indholdsfortegnelse
Indledning:
1.0 Indledning 1
2.0 Metodevalg 2
Analyse:
2.0 Problemanalyse 3
3.0 Modellering 22
Løsning:
4.0 Regulering 32
5.0 Hardware 46
6.0 Seriel Kommunikation 54
7.0 MCU-Software 66
8.0 PC-Software 75
Vurdering:
9.0 Test af løsning 78
10.0 Teknisk Delkonklusion 11
11.0 Teknologi vurdering 12
12.0 Konklusion 13
Litteraturliste:
13.0 Litteraturliste 14
Bilag:
14.0 Bilag 1 (Laplace) 15
15.0 Bilag 2 (Fysmod) 16
16.0
Appendiks:
17.0 Appendiks 1 16
IV

Indledning
Det initierende problem for dette projekt er:
Indledning
”Hvorfor er det relevant at styre radiatorer”
Det initierende problem er udsprunget fra en forestilling om, at der spildes energi ved udluftning,
fordi folk ofte ikke husker at slukke for radiatoren mens de lufter ud. Man kunne forestille sig, at
dette kunne overvindes ved en ”intelligent” radiator, som kan afgøre hvorvidt vinduet er åbent eller
ej, og på baggrund deraf beslutte sig for, om det kan betale sig at varme op eller ej. Man kan
endvidere forestille sig, at det er muligt at udbygge styringen med f.eks. natsænkning.
Det er dette problem, som danner baggrund for vores projekt, hvor vi vil fokusere på en realisering
af en styringsmekanisme til radiatorer i private hjem.
Side 1 af 113

1.0 Metodevalg
Metodebeskrivelse
Vi vil i dette kapitel beskrive og vurdere de forskellige metoder, som bruges under hver af de tre
forskellige faser af projektarbejdet.
Metoder i analysedelen
I analysedelen, benytter vi i problemanalysen os af en proaktiv teknologianalyse. Dvs. en analyse
af de omgivelser, der kunne blive berørt af, eller der kunne berøre, et givent produkt. Dette giver en
ide om hvorvidt det overhovedet kan betale sig at fortsætte med udviklingen af det givne produkt.
Dette gør vi ud fra viden tilegnet via skrevet tekst i form af bøger og materiale publiceret på
internettet.
Denne type analyse sætter os istand til at vurdere produktet i forhold til et marked, og den
forholder sig herfor til mulighederne i dette marked og er altså ikke en objektiv analyse af produktet
af dets muligheder. Den sætter os ikke istand til decideret at analysere, hvilke styrker og svagheder
der er knytter sig til produktet.
Derudover benytter vi os i modelleringskapitlet af matematisk modellering. Dette er en metode til
at finde en matematisk beskrivelse af dynamiske systemers opførelse under forskellige forhold.
Dette bruges blandt andet til at kunne simulere disse systemers opførelse, samt senere til udvikling
af reguleringssystemer for disses fysiske processer. Metoderne for bearbejdelse af dynamiske
systemer er beskrevet i bogen ”Modelering av dynamiske systemer” [Haugen].
Det er klart at matematisk modellering ikke kan beskrive virkeligheden nøjagtigt, men i stedet
giver mulighed for at give en tilnærmelse til virkeligheden beskrevet ved matematiske udtryk.
Vi anvender fysiske forsøg til verificering vore teorier og modeller, samt til at få indsigt i en række
sammenhænge, der kan bestemmes eksperimentelt. Fysiske forsøg vil altid være idealiserede idet
der kun udvælges specifikke måleparametre. Derudover påvirkes forsøg altid når der måles på
disse.
Metoder til softwareudvikling
Under løsningsdelen benytter vi en meget anvendt fremgangsmåde til problemløsning i udvikling
af software. Metoden benyttes ligeledes indirekte ved udviklingen af hardwaren. Metoden er bl.a.
beskrevet i bogen ”Practical Object Oriented Development in C++ and Java” af Cay s. Horstman
[Horstman]. Denne metode inddeler udviklingsarbejdet i følgende faser:
- Analyse
- Design
- Implementation
- Test
I analysefasen anerkendes problemet, hvorefter det kan analyseres. Denne analyse har til formål at
finde en overordnet struktur i problemet og finde ud af hvilke moduler det består af. Derefter
analyseres disse underproblemer for at finde frem til matematiske relationer og algoritmer, der kan
benyttes i løsningen af problemerne. Under analysefasen benyttes der ofte top-down diagrammer,
der viser hvilke delproblemer det oprindelige problem kan opdeles i.
I designfasen strukturers de, i analysefasen, fundne algoritmer til en helhed. Det skal bestemmes
hvordan de moduler og undermoduler, som blev beskrevet i analysen, skal sættes sammen, dvs.
Side 2 af 113

Metodebeskrivelse
dataflow på modulniveau, og det samme skal ske for de enkelte delelementer. Herefter kigges der
nærmere på de væsentligste programmeringsproblemer, som beskrives i flere detaljer og evt. skrives
som pseudokode for at anskueliggøre løsningen. Pseudokode er en forenkling af
programmeringssprog således, at det giver mulighed for at udvikle programkode uden af skulle
tænke på det specifikke programmeringssprogs detaljer, og det er herfor en god platform til brug i
implementationsfasen. I designfasen benyttes der flowcharts der viser hvorledes selve programmets
forløb er.
I implementationsfasen oversættes pseudokoden fra designfasen til det valgte
programmeringssprog. Der beskrives hvilke vanskeligheder der evt. er opstået under
implementeringen, og hvilke afvigelser og tilføjelser fra designfasen der evt. har vist sig
nødvendige.
I testfasen vil det færdige program vha. en driver og data fra virkeligheden blive testet for at
undersøge om det fungerer korrekt. Endvidere vil de afvigelser, der eventuelt måtte dukke op, blive
søgt forklaret. Der benyttes to forskellige typer test i rapporten [Koffman].:
- Bottom-up test
- Top-down test
Bottom-up test fungerer ved, at de enkelte undermoduler implementeres i en driver, som forsyner
undermodulet med data hvorved det bliver muligt at kontrollere om undermodulet fungerer efter
hensigten. Denne type test benyttes løbene under implementationen.
Top-down testen fungerer ved, at hovedprogrammet først testes hvorefter de enkelte undermoduler
indsættes løbende. Denne type test bruges typisk ved samlingen af de forskellige softwaredele til en
enhed.
For at implementere disse tests, bruges delvis fysiske tests og delvis computersimulering, som
agerer driver for de forskellige dele.
Som programmeringssprog har vi valgt henholdsvis C++ til udvikling af software til PC og C til
software på microcontrolleren. Dette er gjort dels fordi at C/C++ er fleksible sprog, som genererer
effektiv programkode. Derudover er det en fordel at arbejde med beslægtede sprog på de to
forskellige platforme, da dele af programkoden kan bruges på begge platforme uden et stort
konverteringsarbejde.
Metoder i vurderingsdelen
Ligesom i analysedelen, bruges også under vurderingsdelen fysiske forsøg. Her dog som et
testredskab til test af det færdige produkt.
Under udarbejdelsen af vores teknologivurdering, benytter vi os af SWOT-analysen som er en
analysetype, som søger at analysere et givent produkts styrker, svagheder, muligheder og trusler i
forhold til omgivelserne. SWOT-analysen er beskrevet i ”Strategi og planlægning som læreprocess”
af Lene Sørensen og Victor Vidal [Sørensen&Vidal].
Side 3 af 113

2.0 Problemanalyse
Problemanalyse
Da vi i dette projekt vil arbejde med radiatorstyring, vil vi i problemanalysen undersøge og
vurdere hvorvidt der er basis for at udvikle og producere et ”intelligent” radiatorstyringsprodukt.
Dette vil ske gennem en proaktiv problemanalyse som vurderer hvor stort markedspotentialet for
dette produkt er.
Vi vil starte med at kigge på de tekniske systemer for at se på hvordan opvarmningen af et hus
med radiator foregår. Dette vil være nødvendigt for at forstå, hvorvidt en regulator er nødvendig og
i så fald hvilke opgaver den bedst vil kunne løse. Endvidere vil vi diskutere produktets
markedspotentiale for forskellige opvarmningssystemer.
Vi vil derefter kigge på den internationale og nationale energipolitik, da denne i det længere løb vil
være medbestemmende for evt. love- og regelændringer, som i fremtiden vil påvirke det danske
varmeforsyningssystem.
Herefter vil vi beskæftige os med indeklimaproblemer affødt af forkert ventilation, og vi vil kigge
på de love og reglementer som er normsættende for indeklima. Herunder vil vi diskutere behovet
for udluftning.
I forbindelse med styring af radiatoren vil vi kigge på begrebet embedded technology, som ofte
sættes i forbindelse med ”intelligent” styring, hvorfor det kunne være relevant i forbindelse med en
implementering af en radiatorstyring.
De første tre afsnit bygger videre på hinandens resultater, mens afsnittet om embedded technology
kan læses for sig. Til slut i problemanalysen vil vi samle vore konklusioner og på den baggrund
lave problemformulering med projektafgrænsning og kravspecifikationer.
2.1 Teknisk System
Der findes i dag mange forskellige alternativer til opvarmning af boliger. I det følgende vil vi
fremdrage forskellige muligheder og derefter give en nærmere beskrivelse af den, for os, mest
relevante løsning. Vi ønsker dermed at undersøge, hvorfor radiatorer behøver styring. Endvidere vil
vi beskrive og vurdere forskellige varmecirkulationssystemer og derpå konkludere hvilke systemer,
der vil være mest relevant i forbindelse med automatisk radiatorstyring.
2.1.1 Forsyningskilder
En forsyningsmulighed for den private forbruger er elvarme, som giver god mulighed for præcis
regulering af opvarmningen. I dag benyttes elvarme stort set kun i f.eks. sommerhuse hvor
mulighederne for andre forsyningskilder er begrænsede enten pga. placering eller fordi
anskaffelsesprisen er for stor i forhold til forbruget.
Et mere udbredt alternativ er private brændselskedler, der forsyner enkelte husstande eller
boligblokke. Denne løsning er mere energiøkonomisk end elopvarmning, men lider under en relativ
høj anskaffelses pris og mulige problemer med brændselsforsyningen.
En tredje mulighed er forsyning fra et fjernvarmesystem, hvilket vil sige, at varmen bliver
produceret på et centralt sted og derefter sendt ud til forbrugerne i form af varmt vand.
Fjernvarme har en anskaffelsespris der svarer nogenlunde til anskaffelsesprisen på private
brændselskedler, men denne bliver ved fjernvarme reduceret meget, og i nogle tilfælde helt, af
tilskud fra staten og fjernvarmeværket selv. Et eksempel på dette er f.eks. Terndrup
Fjernvarmeværk, der ved at give gratis tilslutning har opnået en næsten total tilslutning i området.
Side 4 af 113

Problemanalyse
På landsbasis bliver fjernvarme i dag benyttet af over 50 % af Danmarks husstande [Rambøll] og
tilslutningen er stadig stigende.
2.1.2 Fjernvarmesystemet
Fjernvarmesystemet fungerer ved at samle varmeproduktion på et centralt sted og derefter
distribuere varmen ud til forbrugerne som varmt vand gennem et rørnet. En af fordelene ved at
samle varmeproduktionen på et sted, er muligheden for at benytte andre opvarmningskilder, end
ville være muligt ved lokal opvarmning. En af disse muligheder er bl.a. udnyttelsen af spildvarme
fra affaldsafbrænding eller røggas afkøling i industrien. En anden mulighed er at kombinere el- og
varmeproduktion på et kraftvarmeværk, hvor overskudsvarmen fra elproduktionen benyttes til
varme. På et traditionelt kraftvarmeværk overgår store dele af energien til kølevand som blot går til
spilde, men på et kraftvarmeværk benyttes der fjernvarmevand som kølevand, og der opnås dermed
en meget større udnyttelse af energien [Christensen].
Selvom et fjernvarmeværk benytter alternative opvarmningsmetoder så er en brændselskedel til
konventionelle brændsler som f.eks. olie eller gas stadig nødvendig for ethvert fjernvarmeanlæg.
Dette skyldes, at der stilles høje krav, både fra staten og forbrugerne, til fjernvarmeværkernes
forsyningssikkerhed. Hvis f.eks. vinteren er meget streng, vil det resultere i et øget varmeforbrug,
mens der er mindre spildvarme fra industrien. Dvs. at efterspørgslen stiger, mens udbuddet falder
og fjernvarmeværket vil så kunne opleve problemer med at følge med efterspørgslen, og den
konventionelle brændselskedel tages i brug.
En ulempe ved fjernvarme er det effekttab, der er i rørnettet, men på trods af dette tab, er fordelene
større end ulemperne så længe forbrugerne ikke er for spredte rent geografisk. Dette gælder også
hvis fjernvarmeværket udelukkende bruger f.eks. oliekedel og derfor ikke har de økonomiske
fordele ved udnyttelse af spildvarme fra f.eks. affaldsforbrænding.
For at minimere varmetabet i ledningsnettet bestræber fjernvarmeværkerne sig på at holde en lav
fremløbstemperatur, dvs. temperaturen på vandet når det forlader værket, og ligeledes om af få
afkølet vandet mest muligt for at få en lav returløbstemperatur - altså en generel reduktion af
temperaturniveauet i ledningsnettet. Dette gøres udfra betragtningerne om at varmeafgivning til
omgivelserne sker lineært, dvs. at des større differencen mellem fjernvarmerørene og jorden er, des
mere varmeafgivning finder der sted. For at sænke fremløbstemperaturen stilles der krav til
forbrugerens evne til at udnytte varmen fra fjernvarmevandet, dvs. at der skal uddrives den samme
varmemængde fra vand med lavere temperatur.
En sænkning af returløbstemperaturen i forhold til fremløbstemperaturen kræver, at forbrugeren
bliver bedre til at afkøle vandet. Denne forbedrede afkøling giver ligeledes den fordel, at
varmeværket skal pumpe mindre vand rundt i systemet, og sparer derfor strøm til
cirkulationspumperne.
2.1.3 Afregningsmetoder
Der er stor forskel på forskellige varmeværkers afregningsmetoder. Den mest almindelige i dag er
afregning efter jouleforbrug, mens der stadig nogle steder, som f.eks. i Aalborg, afregnes efter m 3 -
forbrug. Dette giver det problem, at man som forbruger sidst på fjernvarmenettet skal bruge mere
vand end først på nettet for at opnå samme opvarmning, idet vandet bliver afkølet efterhånden som
det kommer frem i nettet. Nogle værker har forsøgt sig med en kombination hvor forbrugere først
på nettet skulle betale efter m 3 -forbrug, mens forbrugere senere skulle afregne efter jouleforbrug,
Side 5 af 113

Problemanalyse
men dette system har vist sig at være problematisk idet forholdsregningen mellem de to metoder er
besværlig og svær at gøre retfærdig.
Afregning efter jouleforbrug er en mere ligefrem og retfærdig metode, idet forbrugerne betaler
præcist for den forbrugte energi. Metoden har dog den svaghed, at den ikke giver forbrugeren
enticament til at spare på vandmængden på samme måde som m 3 -afregning og giver derfor jvf.
2.2.2 fjernvarmeværket et energitab. Dette søger nogle værker at hindre ved at lægge en økonomisk
straf på forbrugerne, der har et for højt vandforbrug. Afregningsmetoden kan også afhænge af
hvilken installation den enkelte forbruger har.
Endelig benytter de fleste fjernvarmeværker sig af faste afgifter der ofte afhænger af størrelsen på
forbrugerens bolig enten regnet i m 2 eller m 3 . De faste afgifter giver det problem, at det ikke kan
betale sig økonomisk for forbrugeren f.eks. at få installeret solfangere som et supplement til
varmeforsyningen og dermed benytte mere miljørigtig energi.
2.1.4 Intern varmesystem
Når fjernvarmevandet er nået til forbrugerens
bolig findes der flere forskellige alternativer til at
udnytte det som varmekilde. Der skelnes i denne
forbindelse mellem direkte kobling (figur 2.1)
hvor fjernvarmevandet løber ind i boligen,
igennem radiatorerne og ud igen uden mellemled,
og indirekte kobling (figur 2.2) hvor boligen er
forsynet med privat cirkulationssystem med
cirkulationspumpe og hvor varmen bliver overført
gennem en varmeveksler. Fælles for de forskellige
systemer er, at overførselen af varme til
brugsvandet, dvs. vandet i vandhanerne, oftest
sker gennem en varmeveksler. Brugsvandet har
dog ingen praktisk betydning for selve
opvarmning- og radiatorsystemet, og vil derfor
ikke blive beskrevet yderligere.
Direkte forbindelse er den metode, hvor der
sker mindst energitab, idet der ingen
mellemled er involveret, og det er derfor den
metode der benyttes i næsten alle nybyggerier
i dag.
Indirekte forbindelse giver et energitab i
varmeveksleren, der med moderne teknikker
begrænser sig til omkring 5%. Ligeledes sker
der et elektrisk energitab idet systemet kræver
en cirkulationspumpe til at cirkulere vandet
gennem radiatorerne. Da der er tale om et
forholdsvis lille, men lukket system er der stor
forskel på om det er varmt eller koldt vand der
Figur 2.1 - Direkte koblet
fjernvarmesystem.
Figur 2.2 - Indirekte koblet fjernvarmesystem
med cirkulationspumpe og ekspansionsbeholder.
cirkulerer i systemet idet varmt vand udvider sig i forhold til koldt og derved skaber trykforskelle.
En ekspansionsbeholder er derfor nødvendig, som buffertank til udligning af trykforskel i systemet.
Side 6 af 113

2.1.5 Radiatorer
Problemanalyse
Radiatorerne er det led i systemet, der er beregnet til at afsætte varme i boligen. En radiator
fungerer på simplificeret form ved at fordele det varme vand ud på en større berøringsflade med
luften, og derved fås det til at afgive dets varme bedre.
Gamle radiatorer i ældre boliger fra før fjernvarmens tid, er ofte udformet til at kunne rumme
meget store mængder vand i forhold til overfladearealet, idet man med et privat cirkulationssystem
ikke bekymrede sig for hvor meget vandet blev afkølet. Hvis det ikke blev nedkølet helt kunne det
bare cirkulere endnu en gang. Problemet opstår når et sådant gammelt system bliver tilsluttet et
fjernvarmenet, og nedkølingseffektiviteten i boligens radiatorer er alt for dårlig. Hvis afregningen er
efter m 3 vil boligejeren komme til at betale alt for meget for opvarmningen. Dette er ikke et
umiddelbart problem hvis afregningen sker efter jouleforbrug, men i stedet kan boligejeren komme
til – jævnfør 2.2.2 - at skulle betale en afgift.
Dette problem løses med indsættelse af nye radiatorer, der i modsætning til ældre modeller kun
rummer nogle få liter vand og har et større overfladeareal, og dermed sørger for en effektiv afkøling
af vandet. Bedre afkøling giver mindre m 3 forbrug og derved billigere varme. Hvis en bolig
modtager fjernvarmevand på 80 o C og afkøler det med 30 o C til 50 o C giver dette en udnyttelse på
30.000 kcal/m 3 vand. Hvis boligens varmesystem forbedres således, at afkølingen kom op på 50 o C
så returtemperaturen bliver 30 o C, giver det en udnyttelse på 50.000 kcal/m 3 [Teknologisk Institut].
2.1.6 Regulering
Afkølingen af fjernvarmevandet afhænger ikke kun af selve radiatortypen, men ligeledes af
hvordan den reguleres. Reguleringen foregår ved hjælp af en variabel ventil, der kan regulere
vandgennemstrømningen i radiatoren. Dette kan foregå manuelt, men dette giver problemer med
indregulering, idet det ofte er store temperatursvingninger, der skal tages højde for, og det kræver
derfor ofte reguleringer. Svingningerne kan blandt andet skyldes vejrforandringer og/eller
gratisvarme fra personer og elinstallationer. Få mennesker har lyst til konstant at skulle regulere alle
boligens radiatorer og dermed opstår kravet om en automatisk regulering.
Dette gøres i dag hovedsageligt vha. termostater der i princippet fungerer som en slags
temperaturafhængig tænd/sluk kontakt, som regulerer gennemstrømningen i radiatoren således, at
temperaturen bliver holdt konstant. Dvs. at hvis der f.eks. er en stor opvarmning fra solen skruer
termostaterne ned for radiatorerne og omvendt.
Der er imidlertid visse begrænsninger ved termostater. Alle termostaterne skal justeres individuelt
og giver derfor ingen mulighed for central styring af hele boligens temperatur, og er er ingen direkte
mulighed for at natsænke temperaturen i nogle eller alle rum. Ligeledes opstår der et problem når
termostaten opfanger et pludselig temperaturfald f.eks. som følge af åbning af vindue. Termostaten
vil så forsøge at opveje temperaturfaldet ved at skrue helt op for radiatoren, og der vil derfor gå en
masse varme til spilde. Der er derfor brug for en metode til at registrere om det er nyttesløst for
termostaten at skrue op for temperaturen. Endelig vil en central styring lette reguleringen af
opvarmningen i boligen. En central styring vil nemmest kunne konstrueres elektronisk og dette vil
ligeledes åbne muligheder for en let implementation af natsænkning og individuel styring af
radiatorerne.
Side 7 af 113

2.1.7 Delkonklusion for det tekniske system
Problemanalyse
Vi kan konkludere, at en forbedret reguleringsmekanisme vil give en forbedret afkøling i
radiatorerne. Denne forbedrede afkøling giver et størst økonomisk og energimæssig gevinst for
forbrugeren ved et direkte koblet fjernvarmesystem, hvor det gælder om at få afkølet vandet så
meget som muligt, inden det ledes ud i rørnettet igen. Ved et internt varmecirkulationssystem, så
som private brændselskedler eller indirekte koblet fjernvarmesystem, kan afkølingen opnås ved blot
at lade vandet cirkulere i systemet.
Den økonomiske gevinst ved det direkte koblede fjernvarmesystem vil bestå i, at der ved m 3 -
afregning vil fås mere energi ud af hver m 3 og derved bruges der færre m 3 vand. Ved afregning efter
joule vil der kunne hentes en økonomisk gevinst, hvis den forbedrede nedkøling kan spare
forbrugeren for en økonomisk straf fra fjernvarmeværkets side.
Endvidere konkluderer vi, at der kan vindes mere ved en forbedret afkøling gennem regulering ved
gamle radiatorer end ved nye. Dette skyldes, at nye radiatorer i forvejen har en bedre afkøling end
gamle. Ydermere kan det konkluderes, at reguleringen skal gøres på en sådan måde, at der tages
hensyn til natsænkning, og at radiatoren skal slukkes når der åbnes vinduer. Ligeledes er central
styret regulering en god ide, idet det vil gøre reguleringen lettere.
Det er altså klart at produktet har størst markedspotentiale til fjernvarmesystemer, men derfor kan
der stadig være en økonomisk og/eller miljømæssig gevinst ved et sådant produkt til andre
varmesystemer. Vi vil herfor koncentrere os om et produkt til brug med fjernvarmesystemer.
2.2 Energipolitik
Vi vil i dette afsnit diskutere energipolitik. Først fra et overordnet synspunkt, hvorefter vi vil
beskrive udviklingen i den danske energipolitik. Dette gøres for at klarlægge hvorfor og hvorvidt
der er enticament til at arbejde med energibesparende foranstaltninger til fjernvarmemarkedet.
Side 8 af 113

2.2.1 Overordnet energipolitik
Der er siden oliekrisen i 1973 blevet
fokuseret på energiforbruget i Danmark, om
hvordan det kan mindskes og om hvordan
energisektoren kan effektiviseres. Ligeledes
fokuseres der på hvordan en økonomisk
effektiv energisektor med en høj
forsyningssikkerhed sikres. Dette skal gøres
på en miljømæssig bæredygtig måde.
Energiforbruget skal nedsættes, da den store
udledning af miljøbelastende gasser, der ved
energifremstilling slipper ud i atmosfæren, er
skyld i store miljømæssige problemer. En af
disse farlige gasser er drivhusgassen CO2,
hvor Danmarks udledning per indbygger
stadig er blandt den højeste i verden. Dette
nødvendiggør en reduktion af udledningen.
Den forøgede drivhuseffekt på kloden er et
globalt problem, så derfor ønsker regeringen,
at Danmark forsat skal have en aktiv rolle i
gennemførelsen af internationale initiativer
omkring CO2 udslip. Der gøres opmærksom
på dette afsnittet er skrevet efter kilderne,
[Miljø- og energiministeriet '99] og [Miljø-
og energiministeriet '98].
Problemanalyse
Fordelingen af EU’s forpligtelser i Kyotoaftalen
Mål i 2008 – 2012 i Ændringen af
forhold til udledning i udledneing af
1990
drivhusgasser i pct.
Luxemburg -28
Danmark -21
Tyskland -21
Østrig -13
Storbritannien -12,5
Belgien -7,5
Italien -6,5
Holland -6
Finland 0
Frankrig 0
Irland 13
Spanien 15
Grækenland 25
Portugal 27
EU samlet -8,1
Figur 2.3 – EU landenes forpligtelser i forbindelse med Kyotoaftalen.
Kilde: Evaluering af grønne afgifter og erhvervene 1999.
Regeringens vilje til at gøre en indsats udtrykkes bedst ved en stærk og troværdig hjemlig indsats.
Dette kræver at regeringen påvirker forbrugernes energivaner, og til dette har regeringen flere
muligheder. Folk kan tvinges gennem lovmæssige indgreb, afgifter, oplysningskampagner og der
kan gives økonomisk tilskud til f.eks. udskiftning af gamle hvidevarer. Endelig kan regeringen føre
strukturpolitik ved f.eks. at støtte fjernvarme.
Omdrejningspunktet i energipolitikken er den nationale indsats for CO2 reduktion og nye
internationale forpligtigelser i Kyotoaftalen supplerer nu den danske CO2–målsætning se (fig.2.3). I
1997 forbedres klimakonventionen ved vedtagelse af Kyoto-aftalen i henhold til den tidligere
Torontoaftale. Aftalen omfatter 160 lande, der bestræber sig på at sænke udledningen af CO2 og
andre drivhusgasser, se fig. 2.3. Danmark har i forbindelse med Kyoto-aftalen forpligtet sig til at
reducere den gennemsnitlige udledning af drivhusgasser med 21% i perioden 2008-2012 målt i
forhold til 1990 niveauet.
I 2005 skal Danmark, såvel som andre industrilande, have gjort bevislige fremskridt for at
overholde denne miljøforpligtigelse. De overordnede mål er store opgaver for Danmark,
sammenlignet med andre lande (se fig. 2.3), men det hænger sammen med, at Danmark gerne vil
fremstå som et foregangsland for en bæredygtig udvikling på energiområdet. Regeringen har derfor
i denne forbindelse i 1996 fremsat en energihandlingsplan kaldet ”Energi 21”.
De forskellige internationale aftaler og øget samarbejde har bevirket, at de enkelte lande har fået
mere indflydelse på udformningen af international energipolitik. Dette har betydet, at vi har fået en
bedre udformning og implementering af den nationale energipolitik i et samspil mellem
Side 9 af 113

Problemanalyse
internationale initiativer. Hermed har Danmark fået nogle gode muligheder for at sætte fingeraftryk
på internationale indsatsområder, da Danmark har store erfaringer på det energipolitiske område.
2.2.2 Energihandlingsplan – Energi 21
Energi 21 er en handlingsplan, som regeringen fremsatte i 1996. Handlingsplanen fremsætter nye
nationale initiativer, der kan beskrives under nøgleordene: ressourceudnyttelse og mindre
miljøbelastning.
I handlingsplanen fremgår det, at Danmark skal nå en CO2 reducering på 20% i 2005 i forhold til
1988 niveauet. I forbindelse med dette blev der i energi 21- ”nye rammer for den danske el- og
varmesektor og energibesparelse og effektivisering” - iværksat en række initiativer for at opfylde
denne reduktion. De nye initiativer skal sikre, at denne sektor fortsat vil være økonomisk og
teknologisk effektiv. Ydermere skal den indgå i en dynamisk samfundsudvikling, hvor
bæredygtighedsmålene forfølges også internationalt. Dette fører til, at sektoren skal arbejde for:
− Langsigtet, stabil udvikling af den danske energiforsyning.
− Åbenhed og inddragelse af forbrugere.
− Rationel ressourceanvendelse.
− Teknisk forsyningssikkerhed.
− Økonomisk effektivitet og samfundsøkonomisk optimering.
− Aktiv international indsats.
− Øget anvendelse af renere brændsler.
2.2.3 Rammer for den danske el- og varmesektor
I forlængelse af Energi 21 skal der således fastlægges en sammenhængende og langsigtet reform af
rammerne for el- og varmesektoren. Målsætningen herfor er[Auken]:
− At den danske el- og kraftvarmesektor styrkes.
− At der findes aktører til at fortsætte miljø- og energipolitikken.
− At forbrugerne fortsat har del i de anlægsaktiver, som de har finansieret.
− At dansk erhvervsliv sikres stabile el- og varmepriser.
− At danske leverandører har adgang til et stabilt investerings- og udviklingsmiljø på
hjemmemarkedet.
Det overordnede mål for disse målsætninger er CO2 reduktion. Dette kan gøres på to måder, enten
ved energibesparelse eller ved at gå over til vedvarende energi. Som eksempel på energibesparelse
kan man ved at omlægge den traditionelle el-produktion til kraftvarmeproduktion, udnytte den
energi, som før gik tabt i kølevandet.
Fjernvarmen har haft stor betydning for dansk energipolitik. Vi har været i stand til at omstille
dansk energiforsyning, der er mindre miljøbelastende. Udbredelsen af fjernvarme har ikke kun
opnået økonomiske, men også miljømæssige gevinster, jævnfør 2.1.2.
Danmark er førende i Europa indenfor kraftvarmeproduktion. Fjernvarmeudbygningen og de deraf
følgende besparelser yder et bidrag til, at de danske klimaforpligtelser, jvf. 2.1, opfyldes. Det er
derfor af høj prioritet for regeringen, at fjernvarmeproduktionen bevares og videreudvikles.
Regeringen har derfor iværksat særlige initiativer til etablering af små decentrale kraftvarmeværker.
[Miljø- og energiministeriet '98]
Side 10 af 113

2.2.4 Handlingsplan for energibesparelse
Problemanalyse
I forbindelse med energibesparelse ved rumopvarming, har Danmark i energi 21 forpligtet sig til at
reducere energibehovet til rumopvarmning i nybyggeri med 50%. Med det bygningsreglement der
trådte i kraft i 1995 er de 25% nået, men for at opnå de sidste 25% er der stadig brug for udvikling
af nye teknikker til energibesparelse. Energibesparelse er også et personligt ansvar, hvorfor
informationskampagner også er en del af regeringens politik.
[Dyck-Madsen]
2.2.5 Delkonklusion for energipolitik
Vi har i dette afsnittet belyst den danske energipolitik fra forskellig synsvinkler og kan
konkludere, at der er brug for reduktion af CO2-udslippet på baggrund af nationale og internationale
forpligtelser, og at dette kan realiseres gennem en reduktion af energiforbruget. Et af de skridt som
er sat i værk for at nå denne reduktion er den foresatte udbygning af kraftvarmeværkerne, som
bidrager positivt til Danmarks CO2 balance.
Vi kan altså konkludere, at der er gode muligheder i et energibesparende produkt rettet mod
fjernvarmesystemet, som et skridt på vejen mod et formindsket dansk energiforbrug. Et sådant
produkt kunne, jvf. 2.1.7, være en forbedret reguleringsmekanisme af fjernevarmeradiatorer.
2.3 Indeklima
Vi vil i dette afsnit undersøge om radiatorstyring er relevant udfra et sundhedsmæssigt synspunkt
og hvorfor udluftning er en nødvendighed. I det ovenstående afsnit blev energipolitikken i Danmark
gennemgået. Denne har sammen med sundhedspolitikken affødt en række love og reglementer
angående indeklimaet i huse og andre bygninger. Disse har relevans i forbindelse med vores
problemstilling, fordi dårligt ventilerede huse kræver mere manuel ventilation med vinduer, hvilket
er en af motivationsfaktorene til vores initierende problem. Endvidere fordi vores produkt er en
temperaturregulator vil vi undersøge temperaturens betydning for indeklimaet. Denne behandling
vil tage udgangspunkt i følgende reglementer:
− Bygningsreglement 1982
− Bygningsreglement 1995
Endvidere vil vi i gennemgangen tage udgangspunkt i et normalt parcelhus.
Side 11 af 113

2.3.1 Bygningsreglementer
Problemanalyse
En af følgerne af oliekrisen i 1973 var, at der bl.a. kom forslag til hvordan varmetabet i huse kunne
formindskes. Disse forslag mundede ud i bygningsreglementet fra 1982. Det havde det formål at
skulle mindske varmetabet i bygninger ved bl.a. at tætne husene i forhold til tidligere.
Ved indførslen af disse 1982 reglementet, fulgte der uheldigvis en uventet bieffekt med, som der
på det tidspunkt ikke var taget højde for. Ved at lave husene mere energirigtige med mindre
varmetab, blev husene mere tætte, faktisk så tætte, at husene ikke kunne ånde. Dette medførte at
husene ikke blev ventilerede ordentligt og derved skabtes et dårligt indeklima, som også
medvirkede til at ødelægge konstruktionerne. Den manglende udluftning/ventilation
nødvendiggjorde en revurdering af reglerne, således at husene blev ventileret, og derved undgik
man skader på huset og ikke mindst helbredet. Derfor blev der i 1995 indført love om hvordan og
hvor meget huse mindst skal ventileres. Dermed ikke sagt, at der ikke blev gjort noget før 1995
hvor lovene trådte i kraft, men der går noget tid inden de relevante myndigheder får undersøgt
sagen tilstrækkeligt til at lave et decideret reglement. Nedenfor ses et udsnit af reglementet fra 1995
[Boligministeriet].
Lov 11.1stk1
”Bygninger skal opføres, så der under normal brug af bygningerne kan opretholdes
et sundheds- og sikkerhedsmæssigt tilfredsstillende indeklima.”
Lov 11.2.2stk.3 [Boligministeriet]
”Kravene til ventilation i rum med normal rumhøjde anses for opfyldt, når tilførslen
af udeluft og udsugning udføres som angivet nedenfor. Størrelsen af udsugningen
er angivet som volumenstrøm i l/s.
Beboelsesrum
Tilførsel af udeluft: Oplukkeligt vindue, lem eller dør samt en eller flere udluftningsventiler med en
samlet fri åbning på mindst 30cm 2 pr. 25m 2 gulvareal…”
Ligeledes har alle andre rum i bebyggelsen lignende udluftningskrav, der indbefatter enten
oplukkelige vinduer, døre, lemme eller udluftningsventiler.
De væsentlige indeklimafaktorer, som påvirker mennesket, kan man opdele i følgende 4
hovedgrupper[Hørup].
− Termisk miljø, de faktorer der har betydning for menneskets varmebalance.
− Atmosfærisk miljø, de faktorer der har betydning for menneskets åndedræt og
lugtesans.
− Akustisk miljø, de faktorer der har betydning for menneskets lydopfattelse.
− Optisk miljø, de faktorer der har betydning for menneskets lysopfattelse.
Vi vil her nøjes med at kigge på de to første hovedgrupper, dvs. termisk og atmosfærisk miljø, da
de to andre, akustisk og optisk miljø, ikke bliver påvirket synderligt af ventilation eller temperatur
kontrol.
Side 12 af 113

2.3.2 Termisk miljø
For at mennesket føler sig godt tilpas,
kræver det en passende temperatur
omkring dem. Denne temperatur kaldes
komfortområdet, og er det
temperaturområde hvorved et menneske
hverken føler varme eller kulde[Statens
Byggeforskningsinstitut]. Dette
komfortområde er afhængig af personen
selv, arbejdet personen yder, påklædning,
luftfugtighed og lufthastighed. Et eksempel
på dette komfortområde er vist i fig. 2.5.
Figuren gælder for lufthastigheder på
omkring 0.2 m/s. Ved at ændre
lufthastigheden, påvirkes komfortområdet.
F.eks. vil en forøgelse af lufthastigheden til
0.4 m/s rykke komfortområdet 1 o C op,
mens en sænkning til 0.1m/s vil rykke
komfortområdet 1 o C ned. Men
lufthastigheder over 0.15 m/s ved
stilsidende tilstand og over 0.4 m/s ved
bevægende tilstand vil generelt føles
ubehageligt. Ligeledes vil lufthastigheder
på under 0.05 m/s give ubehag, da man her
får problemer med at afgive fugt og varme.
En anden temperaturfaktor der kan give
Problemanalyse
Figur 2.5 – Graf over
komforttemperaturent(den grå zone) for
lufttemperatur,afhængig af arbejdbelastning
og påklædnings grad [Boligministeriet].
ubehag, er temperaturændringen. F.eks. vil en daglig temperaturændring, i et opholdsrum, på mere
end 4 o C føles ubehagelig.
Kommer man ud af sit komfortområde, vil man i det kolde område opleve muskelspændinger,
nedsat bevægelighed, samt til sidst kulderystelser. I det varme område vil man opleve at
svedkirtlerne går i gang, intellektuelle og manuelle præstationer reduceres, fejlfrekvens øges, samt
hovedpine og anden utilpashed [Statens Byggeforskningsinstitut].
Temperaturændringer i luften vil også påvirke luftfugtigheden. Det er den effekt der ses, når der
dannes kondensvand på vinduet og fugt på væggene. Dette er vigtigt at huske, da mennesket ikke er
i stand til direkte at mærke om luften er fugtig eller tør.
2.3.3 Atmosfærisk miljø
Den måde vi mennesker opfatter det atmosfæriske indeklima på, er ofte afhængig af
forureningskilder af forskellige art[Hørup].
Disse kan i grove træk opdeles som følgende:
− Ubehagelige lugte
− Gasarter og dampe
− Husstøv
− Industristøv
Side 13 af 113

Problemanalyse
Vi vil her se bort fra industristøv, da vi som førnævnt vil beskæftige os med private boliger og
ikke med industrielle bygninger, samt forudsætter at industristøvet som regel ikke har den store
indflydelse på almindelige boliger, skoler osv. Vi vil til gengæld kigge på luftfugtighed, da denne
påvirker de andre forureningskilder [Statens Byggeforskningsinstitut].
Som nævnt ovenfor, vil temperaturændringer medføre ændringer i luftfugtigheden. Derudover vil
en person afgive fra 40 gram vanddamp til luften pr time ved stilstand, optil flere kilo ved hårdt
arbejde. Hvis luftfugtigheden er for lav, vil slimhinder og hals tørre ud, samt resultere i nedsættelse
af de naturlige filtreringsfunktioner. Et så tørt indeklima vil dog under normale omstændigheder
ikke findes i Danmark, medmindre man aktivt tørrer luften. Lignende symptomer kan til gengæld
også skyldes f.eks. gasser, dampe og støv, og vil derfor kunne observeres i Danmark.
For høj luftfugtighed er ikke i sig selv skadeligt for mennesker, men påvirker nogle af de andre
faktorer. Ved f.eks. ekstrem temperatur, vil en høj luftfugtighed forstærke dennes negative effekt på
kroppen(se 2.3.1). Der vil ved høj luftfugtighed, ske kondensation på bygningsmaterialerne. Dette
kan være direkte skadeligt for materialerne, samt give grobund for mikroorganismer som igen kan
være skadelige for mennesker.
Disse mikroorganismer, kan som de fleste andre småpartikler i husstøvet, blive optaget i
menneskets filtersystemer. Disse systemer vil dog kun optage en hvis procentdel, og der vil derfor
ved store forekomster stadig slippe en del igennem til vores indre organisme, hvilket kan resultere i
infektioner.
De andre dele af husstøv vil for det meste bestå af: bakterier, pollen, hudskæl, midedele, hår,
tekstilfibre, maling, træ, metal og beton. Alle disse elementer er der nok af i de fleste
vesteuropæiske huse til, at hvis der ikke bliver gjort noget ved det, vil det ophobe sig til
sundhedsskadelige mængder og føre til allergiske symptomer, så som astma, øjenkatar, eller
høfeber. Der er i Danmark ikke nogen love om maksimum støvindhold i et hus, men der er dog
udluftningslove som mindsker ophobning af støvet.
Ligeledes findes ingen officielle grænseværdier for gasser og dampe i boliger. De findes til
gengæld i industrien og ville med noget omregning kunne bruges i boliger. Gasser og dampe kan i
store koncentrationer være meget farlige, men vil i langt de fleste boliger ”kun” føre til fysisk
irritation. Den største kilde for gasser og dampe, kommer fra madlavning, rengøring og rygning.
Dog skal man passe på hvis man i sin bolig har et indelukket kontor med mange typiske elektriske
kontorartikler så som kopimaskiner, fax, computer, scanner, osv. Da disse kan fremkalde en del
ozon, som kan resultere i hovedpine, træthed, tørhed i hals og næse, og i store mængder,
ødelæggelse af lungernes funktion. Hvad rygning angår, menes en del af de stoffer cigarretrøg
består af, at være kræftfremkaldende, andre irriterer luftvejene og igen andre giver hovedpine og
svimmelhed. Der skal også tages hensyn til, at cigarretrøg i en rygers bolig, er en forholdsmæssigt
stor forureningskilde, og som grundregel skal et rum med ryger(e) have en 3 gange så stor
udluftning som ellers. Derudover er cigarretrøg også en stor forureningskilde rent lugtmæssigt. En
anden stor lugtmæssig forureningskilde er mennesket selv og eventuelle dyr i boligen, samt
madlavning, nybehandlede overflader og visse byggematerialer.
Om den præcise sammenhæng mellem lugte og sygdomme, findes endnu ikke noget sikkert, men
for det meste vil de ovennævnte faktorer/lugte ikke være sundhedsskadelige, men en gene for
beboerne. Men på trods af dette, vil det typisk være lugtgener alene, der får folk til at lufte ud, da
det er den af generne der er nemmest at opdage.
Side 14 af 113

2.3.4 Delkonklusion for indeklima
Problemanalyse
Det kan konkluderes, utilstrækkeligt ventilation er skadelige både for huset og dets beboere.
Ligeledes ses det, at en stor del af de danske boliger, bl.a. grundet bygningsreglement 82, ikke
automatisk bliver ventileret nok. Dette kompenseres der for ved åbning af vinduer og dette skaber
jvf. 2.1.7 og 2.2.5 et problem. Derfor er en automatisk reguleringsmekanisme specielt egnet i disse
Huse.
Endvidere har vi kigget på forudsætningerne for et godt indeklima, som er en stabil og passende
temperatur og god ventilation, som medvirker til at forhindre ophobningen af sundsskadelige
partikler og organismer. En reguleringsmekanisme kan holde temperaturen på et ønsket niveau og
kan endvidere reducere energispildet ved manuel udluftning, men pga. af f.eks. lugt gener vil man
aldrig komme helt ud over manuel udluftning.
2.4 Embedded technology
I de sidste par år har der været meget fokus på begrebet embedded technology (ET), men det er
stadigt meget svært præcist at forklare hvad det egentligt står for. I det følgende vil vi først beskrive
hvordan elektronisk styring har udviklet sig, hvorefter vi vil beskrive en række af
hverdagssituationer hvor brugeren enten i dag eller i fremtiden kan have glæde af ET. Meningen
med disse eksempler er, at de skal danne et indtryk af dette noget diffuse begreb.
Derefter vil vi forklare den udvikling som er sket indenfor elektronisk styring. På baggrund af
disse eksempler vil vi prøve at give en definition på ET, som vi vil anvende som referenceramme i
resten af projektet. Slutteligt vil vi diskutere hvorvidt og evt. hvordan ET kan have relevans i
forbindelse med styring af radiatorer.
2.4.1 Elektronisk styring før og nu
Førhen var elektronisk styring af flere enheder bygget op omkring en central computer(se fig. 2.6),
dette nødvendiggjorde, at der trækkes ledninger fra sensorer og til aktuatorer. Endvidere er der den
usikkerhed, at hvis computeren går ned, vil det stoppe
udførelse af alle opgaver.
Det er desuden en dyr løsning hvis der kun er få
opgaver som skal styres og derudover kan systemet
Sensor 1
Aktør 1
kun udbygges i det omfang, computeren har
overskydende regnekraft til.
Sensor 2
Styring
Aktør 2
Indenfor softwareudvikling er der i det sidste årti
sket en stor udvikling. Der er sket et skift af
programmeringsparadigme fra modulær
programmering til objekt orienteret programmering,
hvor det forsøges at indkapsle de enkelte opgaver i
enkelte enheder, der er lette at beskrive og anvende.
Sensor 3
Figur 2.6 - Eksempel på styring førhen. Alt data
samles og bearbejdes ét sted.
Denne udvikling skinner også igennem på
hardwaresiden, hvor der i dag designes distribuerede systemer, som løser opgaverne tæt på
problemet ved hjælp af en lille decentral computer. Disse decentrale computere kan overvåges og
modtage instruktioner fra en central computer gennem et netværk.
Side 15 af 113
Aktør 3

Problemanalyse
Denne decentrale arkitektur sikrer større pålidelighed, da en fejl et sted i systemet ikke blokerer
hele systemet grundet den store uafhængighed af de enkelte enheder.
Desuden er denne metode mere skalerbar, da det er lettere
at ændre på systemet eller tilføje flere enheder.
I mange situationer kan det vælges at lade de enkelte
systemers brugerflade være placeret på en PC, der har
forbindelse til systemerne gennem et netværk (se fig. 2.7).
Dvs. brugeren interagerer med systemerne via PC’en, mens
systemerne autonomt løser deres respektive opgave. Dette
gør det muligt at styre mange systemer central, samtidigt
med at regnekraften er placeret decentralt.
2.4.2 Eksempler på ET
Dataopsamling
og noget
styring
Embedded
system1
Embedded
system 2
Embedded
system 3
Figur 2.7 - Eksempel på moderne styring.
Selve styringen foregår hvor den skal bruges,
men overvåges centralt gennem et netværk.
En af ideerne bag ET er at give brugeren mere komfort, og at gøre styring af hverdags-elektroniske
apparater lettere. F.eks. kan der i dag købes kaffemaskiner, som gør det muligt at indstille et
tidspunkt, hvor den automatisk starter kaffebrygningen. Dette betyder for den morgentrætte bruger
ekstra komfort, da vedkommende kan stå op til en varm kop kaffe, hvor brugeren før måske ikke
havde tid til at vente på maskinen.
En anden af ideerne bag ET er at spare ressourcer for forbrugeren. Et eksempel på dette kunne
være de nye opvaskemaskiner fra Blomberg [Blomberg], som automatisk bedømmer hvor meget
opvask, der er i maskinen op på baggrund heraf regulerer vandmængden, så der ikke spildes unødig
energi og vand.
Et tredje sted ET gør sig gældende er i bilindustrien, hvor der i moderne biler anvendes elektronik
til styring af f.eks. ABS-bremser, tracktion-control og airbags. Disse mekanismer virker helt uden,
at brugeren behøver at være bevidst om det, hvilket er en vigtig pointe når der tales om ET, da det
skal være let for brugeren at anvende moderne teknologi uden at brugerne behøver at have indsigt i
de tekniske detaljer.
Eksempler på ET i den nære fremtid vil pege i retning af mere kommunikation mellem forskellige
ET enheder. Disse enheder vil endvidere optræde mere autonomt, dvs. de bliver i stand til at løse
mere komplicerede opgaver.
Et eksempel på en fremtidig ET-applikation kunne være det intelligente køleskab. Dette køleskab
kunne tænkes selv at holde styr på indholdet og sørge for at opretholde niveauet af dagligdagsvarer,
som f.eks. mælk eller smør, ved at bestille nye forsyninger over internettet.
Endvidere kunne man forstille sig, at der på husets pc kører et agentprogram som tilrettelægger
familiens diæt på baggrund af en opskriftsdatabase sammenholdt med det indhold som det
intelligente køleskab oplyser er til stede. Agenten vil så bestille de varer som dagens opskrift
kræver, men som ikke allerede er til stede i køleskabet.
2.4.3 Bluetooth netværk
Selvom udviklingen går stærkt, kræver kommunikation
mellem elektroniske enheder for det meste stadigvæk
kabler. At tilslutte en printer, modem eller mus kan, selv
her i starten af det 21. århundrede, være et
irritationsmoment. Der er nok mange der drømmer om, at
alt udstyret kunne ”tale” med hinanden, helt uden kabler.
Side 16 af 113
Figur 2.8 - En af anvendelses mulighederne
for Bluetooth.

Problemanalyse
I maj 1998 dannede Intel, Nokia, Ericsson, IBM og Toshiba Bluetooth Special Interest Group
(BSIG). Selve navnet ”Bluetooth” er inspireret af den danske konge Harald Blåtand, der levede fra
910 til 986.
I starten var det trådløs kommunikation mellem mobiltelefoner og andet udstyr, der var målet for
Bluetooth. Dette mål er senere blevet udvidet til at omfatte hele spektret fra kommunikation mellem
bærbare og stationære computere og deres udstyr til alle former for elektronik i hjemmet, så
hovedformålet med projekt Bluetooth er udvidet til nu også at udvikle billige og kompakte
kommunikationsmoduler, der kan bygges ind i næsten alt.
I dag er mere end 1100 firmaer med i BSIG og beskrivelsen af standarden fylder mere end 1500
sider. Bluetooth 1.0 standarten blev i foråret 1999 gjort offentligt tilgængelig, så alle har mulighed
for at udvikle til den.
Efterhånden som Bluetooth standarden og evt. lignende standarder bliver mere udbredte, vil det
blive lettere og billigere at producere produkter som kan kommunikere indbyrdes. F.eks. kunne det
intelligente køleskab (afsnit. 2.4.2) kommunikere med pc’en via Bluetooth.
Billig trådløs kommunikation, som Bluetooth, gør det nemt og billigt at installere elektroniske
systemer i hjemmet. Og gør det hermed lettere at skabe et ”intelligent hus” dvs. et hus med en lang
række af de elektroniske hjælpemidler, som der blev givet eksempler på i afsnit 2.4.2. (se fig. 2.8)
2.4.4 Arbejdsdefinition på ET
Som nævnt i indledningen er det svært at give en klar definition på begrebet ET, så i dette afsnit
vil vi undersøge begrebet og give en definition, der vil tjene som referenceramme gennem resten af
projektet. Da ET er et område med stor udvikling vil vi vores definition ikke relatere til ET i dag,
men mere til hvordan ET vil se ud i morgendagens samfund.
Oversættes ”embedded technology” direkte til dansk fås:
”indlejret teknologi”. Den teknologi, der refereres til er
elektronikken. Når man indlejrer elektronik, dvs. indkapsler
det, er selve elektronikken ”gemt” for brugeren, derfor må
brugeren anvende apparatets grænseflade, hvis
vedkommende vil påvirke det.
Et ET-system er kendetegnet ved, at der imellem dets
input og output foregår en avanceret beslutningsproces. For
at gøre denne beslutningsproces mulig er kernen i et ETsystem
en microcontroller, dvs. i princippet en lille
computer. Denne lille computer gør det muligt at køre
beslutningstagende software på systemet (se figur 2.9).
Grænsefladen mellem ET-systemet og omverden kan
etableres enten direkte som et antal knapper og displays
uden på det fysiske system og/eller gennem et netværk.
Input
Brugergrænseflade
Elektronik /
software
Output
Figur 2.9 - Når først systemet er tilsluttet,
kan man glemme alt om den avancerede
teknologi, som er indlejret i det.
Hvis styringen foregår gennem et netværk åbner det mulighed for, at mange systemer kan
overvåges og styres centralt, f.eks. fra en PC.
På baggrund af ovenstående kan vi opstille følgende tre vigtige kriterier, som vi vil lade definere et
ET-system gennem resten af rapporten:
– Systemet varetager en opgave, som kræver en autonom beslutningsproces.
Side 17 af 113
e
m
b
e
d
d
e
d
s
y
s
t
e
m

Problemanalyse
– Systemet betjenes gennem en grænseflade, som gør viden om systemdesignet unødvendigt.
– Systemet kan kommunikere med andre enheder, men er i øvrigt et ”stand alone” system.
Kigger vi igen på kaffemaskinen fra afsnit 2.4.1 er den, ifølge vores definition, ikke et ET-system,
fordi den ikke kan kommunikere med andre enheder og fordi dens styrings er baseret på en simpel
timer. Hvis en kaffemaskine skal være et ET system ifølge vores definition, skal den indeholdende
en microcontroller og mulighed for kommunikation, så man f.eks. kunne starte kaffemaskinen fra
sin mobiltelefon.
2.4.5 ET og varmestyring
I fremtidens intelligente hus kan vi forvente, at ejeren ønsker at kontrollere hele huset fra PC’en.
For at gøre dette muligt skal den beskrevne ET-teknologi anvendes. Dette gør sig også gældende
ved fremtidens opvarmingssystemer hvor brugeren vil kunne bestemme rumtemperaturerne centralt
fra PC'en. Desuden vil beboeren af det intelligente hus forvente mere af sit opvarmingssystem end
en boligejer forventer af sine termostater i dag. Den fremtidige boligejer kunne f.eks. ønske sig at
systemet kan:
– Tilpasse temperaturen efter beboernes døgnrytme, f.eks. natsænkning.
– Slukke for varmen hvis der udluftes.
– Føre statistik og evt. give forslag til besparelser.
Hvis vore antagelser omkring udviklingen i fremtiden viser sig at være rigtige vil der i fremtiden
komme et marked for ET systemer til styring af rumopvarmning hvorfor det vil være relevant at
begynde at udvikle løsninger til dette.
2.5 Problemformulering
I afsnittet om det tekniske system så vi, at der er størst potentiale i en forbedret
reguleringsmekanisme ved et direkte koblet fjernvarmesystem uanset afregningsmetoden.
I vores diskussion af energipolitikken blev det endvidere klart, at regeringen langt ud i fremtiden
vil støtte fjernvarmeproduktionen, da den medvirker til at nå de internationale og nationale
energimålsætninger, som Danmark har forpligtet sig til at opfylde. Desuden er regeringen
interesseret i løsninger, som kan medvirke til at sænke energiforbruget til opvarmning af boliger, for
at leve op til kravet omkring 50% reduktion af varmeforbruget i nybyggerier.
Indeklimaet i en del danske boliger viste sig at være et problem pga. de for høje krav til
energieffektivitet, som blev stillet i bygningsreglementet fra 1982. For at undgå dårligt indeklima i
disse huse, er det nødvendigt ofte at åbne vinduer for at ventilere boligen. Der er derfor potentiale i
en reguleringsmekanisme, som formindsker energitabet ved at detektere om et vindue er åbent og
lukke for radiatoren, mens der udluftes.
Embedded technology viste sig at rumme mange fremtidsperspektiver, og det må forventes at
fremtidens boligejere ønsker sig mere ”intelligente” huse, hvorfor ET netop er relevant, da det giver
denne mulighed. Endvidere gav vi vores bud på en definition på ET-begrebet, som grundlæggende
stiller krav om netværksforbindelse og en autonom beslutningsproces.
Alt i alt har vi altså fundet ud af, at det er relevant at styre en radiator fordi fjernvarmeværkerne
kræver stor afkøling af fjernvarmevandet, hvilket kan opnås gennem en god styring. Endvidere har
vi fundet ud af at udluftning er en nødvendighed i boligen i dag, og at dette oftest sker ved
Side 18 af 113

Problemanalyse
vinduesåbning og det er dermed relevant at styre en radiator i udluftningssituationer. Ligeledes
fandt vi ud af, at da radiatorstyring er energibesparende, og at der er politisk opbakning bag
miljøforbedrende tiltag.
Overordnet kan vi konkludere, at der er et godt potentiale i et produkt som opfylder følgende
betingelser:
– Det skal være designet til fjernvarmesystemer.
– Systemet skal forbedre udnyttelsen af varmen i fjernvarmevandet.
– Systemet skal minimere behovet for menneskelig regulering, dvs. det skal være intelligent nok
til at håndtere alle situationer, som måtte opstå (kravet om autonomi).
– Systemet bør kunne indgå i et netværk dedikeret til styring af alle automatiserede opgaver i en
bolig.
Herudover vil det være naturligt at produktet har en grafisk grænseflade placeret på boligens PC,
så alle radiatorer kan styres centralt. Disse betingelser vil vi lade være styrende for resten af
projektet og specielt for kravspecifikationerne.
2.5.1 Kravspecifikation
På baggrund af den forgangne analyse vil vi her formulere en række krav til et produkt, som kan
bruges til automatisk radiatorstyring. Der tages her sigte på specifikationer til et virkeligt produkt til
den private forbruger, som skal kunne klare sig på et virkeligt marked.
1. Produktet skal kunne foretage automatisk radiatorregulering.
2. Brugeren skal når produktet først er installeret ikke til daglig være opmærksom på det.
3. Produktets grænseflade skal være placeret på en PC, dels for at imødekomme vores krav om
netværkskommunikation, men også for at give mulighed for dataopsamling og samlet kontrol
over rumtemperaturer i huset.
4. Produktet skal kommunikere vha. Bluetooth - hvis vi havde valgt et ikke trådløst netværk, ville
installationsomkostningerne i allerede byggede boliger være for høje.
5. Produktet skal autonomt kunne regulere radiatoren på baggrund af brugerens ønsker om
passende temperatur. Dette vil sige, at systemet skal kunne klare alle situationer uden brugerens
indblanding, herunder afbrydning af opvarmning hvis vinduet åbnes.
6. Det software som styrer regulatorerne fra PC’en skal være driftsikkert, let at betjene og må kun
optage ressourcer i det omfang det er nødvendigt.
7. Produktet skal være drift- og personsikker og have et minimalt strømforbrug.
8. Endvidere skal produktet have en lang levetid (>15 år) idet dets omgivelser (hus, varmesystem)
ligeledes er langtidsinvesteringer.
Ovenstående krav opfyldes, af et produkt som benytter ET til regulering af radiatorer i private
hjem. Det skal dog bemærkes at Bluetooth-netværket nødvendigvis kræver, at der også i huset
installeres andre ET – applikationer som anvender Bluetooth, da hver enkelt enhed i netværket har
en begrænset rækkevidde, ca. 10m, hvorfor en besked må routes 1 igennem flere ET – applikationer,
før den når destinationen (PC’en).
Det bør også bemærkes, at produktet under alle omstændigheder bliver relativt dyrt, hvis det skal
implementeres i et helt hus, målgruppen er herfor begrænset til en gruppe af relativt velstående
1 Dvs. beskeden må anvende andre ET-applikationer som mellemstationer.
Side 19 af 113

Problemanalyse
mennesker, som finder denne ET - udviklingen interessant. På lang sigt, specielt i forbindelse med
nybyggeri, kan vi dog forvente, at produktet vil få en mere folkelig appel og pris.
2.5.2 Projekt-afgrænsning
Imidlertid er det produkt, som vi har specificeret i kravspecifikationerne uden for vores
rækkevidde at udvikle med vores nuværende ressourcer og tidsramme. Derfor vil vi følgende
skitsere en principiel løsning, som giver os mulighed for at afprøve nogle af de teknologier og ideer
som ville have indgået i en virkelig løsning, jvf. 2.6.
Vi har identificeret følgende punkter som nødvendige for at lave en principiel løsning, som i en vis
udstrækning har samme anvendelighed som en virkelig løsning.
1. En elektronisk løsning der autonomt kan regulere en radiator.
2. Et kommunikationsvej mellem den elektroniske løsning og en computer.
3. Et stykke software til PC, som agerer grænseflade mellem brugeren og det elektroniske
system.
Punkt 1, giver os mulighed for at eksperimentere med embedded technology. Punkt 2 erstatter
Bluetooth netværket med en simplere kommunikationsteknik, f.eks. seriel kommunikation og
endelig vil punkt 3 indeholde grænsefladen ligesom i den rigtige løsning, dog vil vi ikke stille krav
til, at grænsefladen skal kunne operere under et moderne styresystem (som f.eks. Windows).
Med hensyn til funktionalitet vil vi opstille følgende kriterier, som det afgrænsede system skal
kunne opfylde:
1. Det elektroniske system skal autonomt kunne overvåge temperaturen og på baggrund heraf
styre en radiator. Herunder:
a. Systemet skal kunne registrere om hvorvidt vinduet er åbent eller lukket på baggrund
af temperatur.
b. Systemet skal kunne udføre natsænkning.
c. Systemet skal kunne fungere som en termostat således, at en ønsket indetemperatur
opretholdes.
2. Det elektroniske system skal over forbindelsen til PC’en kunne:
a. Formidle dets status og rumtemperatur.
b. Modtage ønsket temperaturindstilling.
c. Modtage tidsramme for natsænkning.
3. PC-softwaren skal kunne opsamle information fra det elektroniske system og præsentere
disse til brugeren samt formidle brugerens ordrer til det elektroniske system, hvor de danner
grundlag for reguleringen.
4. Produktet skal konstrueres således at det fungerer under kontrollerede forhold i en
forsøgsopstilling med en elektrisk radiator, men skal ligeledes konstrueres på en sådan vis,
at det uden alvorlige komplikationer skal kunne implementeres i en virkelig bolig.
Side 20 af 113

Problemanalyse
I resten af projektet vil vi anvende denne afgrænsning som referenceramme og forsøge at udvikle
en løsning som lever op til de her specificerede krav. Endvidere vil vi ved rapportens afslutning
anvende denne afgrænsning til at vurdere hvorvidt det er lykkedes at opfylde disse specifikationer.
Som man vil bemærke gennem resten af projektet, vil vi gang på gang genopfinde hjulet, dvs.
udvikle løsninger fra bunden i stedet for at inddrage allerede eksisterende løsninger. Dette gøres
idet vi i dette studieprojekt ønsker at lære så meget som muligt.
Vi har valgt at udskifte vores varmekilde fra en varmtvandsradiator til en alm. el-radiator. Dette
skyldes, at vi ikke har ressourcer og tid nok til at lave en automatisk styring af en
varmvandsradiator, da det er meget mere kompliceret at beskrive matematisk.
Side 21 af 113

3.0 Modellering
Modellering
Vi vil her konstruere en simplificeret model for de termiske processer i et rum, idet en sådan
model senere kan blive en stor hjælp til udviklingen af de styringsalgoritmer, som skal
implementeres i vores produkt. For at sætte os i stand til at designe en effektiv model, vil vi først
benytte nogle analysemetoder, som giver os indblik i systemet og dets dynamik. Vi vil i denne
forbindelse benytte matematisk modellering. Idet vi først udvider vores forståelse af systemet vil vi
blive i stand til at træffe bedre og mere nuancerede designbeslutninger, og det giver os bedre
mulighed for på forhånd, at vurdere hvordan løsningerne vil opføre sig i den endelige
implementation.
3.1 Matematisk modellering
Matematiske modeller anvendes i dag i stor udstrækninger til produktudvikling. Som eksempel
kan nævnes softwarepakker, der kan hjælpe bygningsingeniøren med at bestemme belastninger af
de enkelte dele i et bygningsværk eller programmer, som kan bruges til støtte i udviklingen af
elektroniske kredsløb.
Når der udvikles en matematisk model analyseres sammenhænge mellem systemets input og
output. Målet er at give en matematisk beskrivelse af den ”sorte boks”, som forbinder input og
output (se fig. 3.1). Hvis dette skal lykkes kræver det, at systemet kan nedbrydes i så mange
enkeltdele, at de hver kan beskrives ved hjælp af kendte matematisk udtryk, hvorefter alle
udtrykkene samles i et sæt af ligninger, som udgør den
matematiske model. Dette viser sig ofte at være umuligt i
praksis, fordi virkeligheden er mere nuanceret end det er
overkommeligt at modellere. Derfor indgår der i modellen
en række af antagelser og afgrænsninger, som gør
modelleringsarbejdet overkommeligt.
I forbindelse med modeller vil vi beskrive deres
præcision, dvs. hvor mange antagelser og tilnærmelser der
Input "Sort boks" Output
Figur 3.1 - Den matematiske model søger at
beskrive hvad, som foregår i den sorte boks.
er er gjort i forbindelse med dem, som deres detaljeringsgrad. Des flere antagelser og tilnærmelser,
des lavere detaljeringsgrad.
Da en tilnærmet model i sagens natur ikke er helt præcis, er det vigtigt, at det vurderes hvad
modellen skal bruges til og på baggrund heraf hvilken detaljegrad der er nødvendigt, for at give
tilfredsstillende resultater.
Gennem arbejdet i den matematiske modelleringsproces opnås indsigt i de enkelte dele af systemet
og det samspil som er imellem dem.
Side 22 af 113

3.1.1 Mål for modellering
Modellering
Det system som er relevant for os at modellere, er et rum i en almindelige beboelsesejendom.
Dette specificerer vi til at være bestående af fire vægge, gulv, loft og et vindue, samt en
fjernvarmeradiator. Ved hjælp af ovenstående metoder er det vores mål at opnå følgende:
- Indsigt i systemet og dets dynamik.
- Mulighed for at bruge resultaterne i designfasen, specielt:
1. Mulighed for at vurdere løsningsforslag inden implementation.
2. Mulighed for at bestemme sensor antal og placeringer på baggrund af modellen.
3.2 Afgrænsning af det fysiske system
For at opnå en forståelse af de termiske forhold i et rum har vi valgt, at konstruere en skalamodel
hvori vi vil kunne afprøve den matematiske model under kontrollerede forhold. Grunden til, at vi
vælger at tilnærme et virkeligt rum med en skalamodel er, at der i virkeligheden er en masse
faktorer vi ikke, med de ressourcer og den tidsramme vi har, kan tage højde for i den matematiske
modellering. Den fysiske model er altså en tilnærmelse til virkeligheden og har derfor en laver
detaljeringsgrad end virkeligheden, men stadig med en højere detaljeringsgrad end den matematiske
model. Den giver os derfor god mulighed for at efterprøve om de antagelser og tilnærmelser vi gør i
forbindelse med den matematiske model fungerer. Endelig vil den give os den mulighed, at hvis der
opstår situationer, som ikke kan modelleres direkte matematisk, kan vi opstille nogle empirisk
bestemte ligninger på baggrund af forsøgsresultater fra skalamodellen.
3.2.1 Den fysiske model
Modellen er opbygget som en kasse hvor vægge, loft og gulv, alle er lavet af ens flamingo plader.
I en af modellens sider er der indsat et plexiglasvindue med mulighed for åbning og lukning (se
bilag ”fysmod”). Radiatoren er konstrueret af viklet kantaltråd uden kortslutninger, hvorover
spændingen kan reguleres. Heri ligger en væsentlig forskel fra et virkeligt rum, hvor der oftest vil
forefindes en varmtvandsradiator, men vi vælger at benytte en elradiatoren da en sådan er meget
lettere at have med at gøre. Vi gør følgende antagelser og tilnærmelser i den fysiske model i forhold
til et virkeligt rum.
– Vi negligerer et virkeligt rums interiør og dets indvirkning på varmeforhold.
– Vi betragter alle vægge som værende vendt ud mod de samme omgivelser, hvorimod et virkeligt
rum oftest vil have de fleste af væggene rettet mod forskellige omgivelser.
– Vi benytter en elradiator i stedet for en varmvandsradiator, da en elradiator er lettere at
konstruere og styre.
– Vi benytter vægge der kun består af et materiale, hvorimod vægge i et virkeligt rum vil bestå af
flere forskellige materialer.
– Da modellen er anbragt indendørs kan vi ikke lave forsøg under realistiske
udendørstemperaturer.
Side 23 af 113

3.2.2 De fysiske processer
Modellering
Vi ved fra termodynamikken, at vores fysiske system vil gå mod en tilstand af termodynamisk
ligevægt. Dvs. afgivelsen af termisk energi er lig med tilvæksten af termisk energi, dette vil ske når
enten systemets temperatur er ens med dets omgivelser, eller når tabet af termisk energi gennem
vægge og vindue tilsvarer til, den af radiatoren tilførte energi.
For at bestemme hvor hurtigt og ved hvilken temperatur, der opnås termodynamisk ligevægt, må
vi undersøge de fysiske processor som bidrager til ændringer i systemets indre energi. Disse er
tilførsel af energi fra radiatoren og afgivelse af energi gennem vægge og vindue.
I vores fysiske model sker energitilførslen fra en elektrisk radiator. Energien som omsættes i
radiatoren omsættes enten som varme i tråden eller luften, eller den omsættes til strålingsvarme. Vi
vil gøre den antagelse, at al effekt afsat i tråden, vil blive omsat til varme i luften.
Gennem vægge og vindue kan der både tilføres eller afgives energi til systemet afhængig af om
temperaturen er størst i systemet eller i dets omgivelser. Hvis kassen er lukket tæt til, vil alt varmen
blive transporteret gennem væggene og vinduet. Dette sker ved termisk konduktivitet, dvs.
varmeledning gennem materialet (se
fig. 3.2a).
På indersiderne i rummet vil
temperaturen nær vægge, gulv og loft
være lavere end den generelle
temperatur i rummet og på ydersiden
vil temperaturen være højere nær
vægge, gulv og loft end
udetemperaturen 2 (se fig. 3.2b). Dette
skyldes, at varmeovergangen i
materialerne påvirker temperaturen
omkring det ledende materiale. Disse
temperaturforskelle medfører, at der
ved vægge, gulv og loft, både på
ydersiden og indersiden, er et luftlag
Figur 3.2 - Graf der viser temperaturen som en funktion af
positionen gennem en væg. a viser forløbet uden konvektion, mens b
viser forløbet med konvektion.
med konvektionsstrømninger. Disse luftlag har betydning for varmekonduktiviteten, da den
afhænger af temperaturforskellen mellem inder- og yderside af muren, men de er imidlertid meget
besværlige, at modellere. Derfor er der ved varmetabsberegninger til bygninger indført en størrelse
kaldet overgangsisolans, som betegner den isolerende virkning af disse luftlag og beregnes som
konstant uafhængig af temperaturforskelle og materialer [Both].
3.3 Den matematiske model
Vi vil her udvikle en matematisk model af den i 3.2.1 beskrevne fysiske model. I det følgende vil
alle enkeltdelene blive beskrevet og bearbejdet, for derefter at blive samlet i en differentialligning,
som giver en tilnærmet beskrivelse af systemet. Herefter vil vi uddrage nogle matematiske
konklusioner på baggrund af denne og slutteligt vil vi sammenholde ligningen med forsøgsresultater
fra den fysiske model.
2 Det forudsættes her at indetemperaturen er højere end udetemperaturen.
Side 24 af 113

3.3.1 Varmekilde
Modellering
Vores varmekilde i den fysiske model er en elradiator, som vi antager afgiver alt effekten som
varme i luften. Endvidere antager vi, at ændringer i radiatorens effektafgivelse sker momentant. Vi
har altså en funktion R(t), som beskriver hvor meget effekt, der omsættes i radiatoren og dermed
fordeles i rummet som varme. Funktionen R(t) afhænger udelukkende af den elektriske energi, som
påføres systemet.
3.3.2 Effekttab gennem vinduer og vægge
Som beskrevet i 3.2.2 er effekttabet gennem en væg eller et vindue en kompliceret affære, idet der
både sker varmeledning og varmekonvektion. Det er herfor meget svært, at udvikle en matematisk
model for den dynamik, som udspiller sig ved og gennem væggen. Den del af varmetabet der sker
ved varmeledning, kan beskrives med formlen:
hvor:
t ude − tinde
P = A⋅
(3.1)
k
∆x
- P er den effekt der transporteres igennem materialet [W]
- tude er udetemperaturen [K]
- tinde er indetemperaturen [K]
- A er areal af overgangsmaterialet [m 2 ]
- k er varmeledningskoefficient [W/(m⋅K)]
- ∆x er tykkelsen af materialet [m]
Konstanterne k/∆x kaldes isolansen og betegnes R.
For at beskrive varmetabet der sker gennem varmekonvektion benyttes overgangsisolansen
Rovergang. Denne er jvf. 3.2.2 en tilnærmelse til konvektionen og benyttes ved, at den lægges til
isolansen. Dermed er varmetabet gennem konvektion tilnærmet ved udtrykket for
varmeledning[Both].
Denne formel opstilles for både vægge og vindue:
hvor:
&
- U(t) er udetemperaturen [K]
- T(t) er indetemperaturen [K]
- R er isolansen [(m 2 ⋅K)/W]
U ( t)
−T
( t)
P(
t)
vindue = Avindue
⋅
(3.2)
R + R
vindue
vægge
overgang
U ( t)
− T(
t)
P(
t)
vægge = Avægge
⋅
(3.3)
R + R
overgang
Vi kan nu opstille en differentialligning udfra loven om energibalance i et termisk system. Denne
ser ud som følger [Haugen]:
dE(
t)
= ∑ Q(
t)
i i (3.4)
dt
Side 25 af 113

hvor:
Modellering
– E er systemets termiske energi [J]
– t er tiden [s]
– ΣiQi er summen af energistrømninger i systemet, dvs. tilført energi pr. sek. [W]
Dette giver os følgende differentialligning for energibalancen af vores system:
hvor:
dE(
t)
= R(
t)
+ A
dt
vindue
U ( t)
−T
( t)
⋅
R + R
vindue
R(t) er radiatorens effekttilførsel [W].
3.3.3 Omregning fra energi til temperatur
overgang
+ A
vægge
U ( t)
−T
( t)
⋅
R + R
vægge
overgang
Indtil nu har vi kigget på tilførsel og tab af effekt, men som output er vi interesseret i en funktion,
som beskriver temperaturen i systemet. Et termisk systems energi (E) er proportional med
temperaturen hvor proportionalitetsfaktoren er systemets varmekapacitet (C):
hvor:
C ⋅ T ( t)
= E(
t)
(3.6)
T(t) er temperaturen af systemet [K]
C er systemets varmekapacitet [W/K]
At finde varmekapaciteten (C=m⋅c) for systemet er imidlertid besværligt, da det vil være en for
grov antagelse at sige, at temperaturen er konstant i hele systemet, vi er herfor nød til at kigge på
luften, vinduet og væggene for sig.
(3.5)
Vi vil antage at temperaturen i luften er homogen, hvorfor vi kan sige, at varmekapaciteten af
luften er:
hvor:
C = m ⋅ (3.7)
luft cluft
cluft er luftens specifikke varmekapacitet [W/(kg⋅K)]
mluft er luftens masse [kg]
Vanskeligere er det at bestemme varmekapaciteten for vægge og vindue, dette skyldes at
temperaturen som beskrevet i 3.2.2 ikke er homogen gennem materialet, da temperaturen falder fra
indersiden til ydersiden. Da vi antager, at der udelukkende transporteres varme gennem vægge og
vindue ved termisk konduktivitet, vil det sige, at temperaturen falder lineært gennem materialet. På
baggrund heraf tilnærmer vi temperaturen til at være gennemsnitstemperaturen i materialet. Vi kan
altså opstille følgende for den termiske energi i vægge og vindue:
T ( t)
+ U ( T )
Evindue = ( mvindue
⋅c
vindue ) (3.8)
2
&
Side 26 af 113

hvor:
Modellering
T ( t)
+ U ( T )
Evægge = ( mvægge
⋅c
vægge ) (3.9)
2
c er materialets specifikke varmekapacitet [W/(kg⋅K)]
m er materialets masse [kg]
Systemets samlede termiske energi bliver da:
T ( t)
+ U ( t)
E system = T ( t)
⋅C
luft + ⋅(
Cvindue
+ Cvægge
) (3.10)
2
Sammenholdes det ovenstående med formel 5 giver det følgende differentialligning for systemet:
d(
T ( t)
⋅ C
luft
T ( t)
+ U ( t)
+ ⋅ ( C
2
dt
vindue
+ C
vægge
))
= R(
t)
+ A
(3.11)
vindue
U ( t)
− T ( t)
⋅
R + R
vindue
overgang
+ A
vægge
U ( t)
− T ( t)
⋅
R + R
Vi vælger at betragte udetemperaturen som værende konstant, hvilket eliminerer U(t) på venstre
side i ligning 3.12, idet differentialkoefficienten til en konstant er nul. Dette giver følgende udtryk
der er repræsenteret som blokdiagram i figur 3.3:
1 1
d(
T ( t)
⋅ ( Cluft
+ Cvindue
+ Cvægge
))
2 2
U ( t)
− T ( t)
U ( t)
− T ( t)
= R(
t)
+ Avindue
⋅
+ Avægge
⋅
dt
R + R
R + R
R(t)
U(t)
+
+
A
R
tot
tot
+
−
C
luft
C
+
1
vindue
+ C
2
vægge
(3.12)
vindue
overgang
Figur 3.3 - Blokdiagram over den matematiske model.
T &
Side 27 af 113
T(t)
vægge
vægge
overgang
overgang

Modellering
Radiatoreffekten (R) summeres med effekttabet gennem vinduer og vægge. Ligningen forstærkes
med 1/Ctot der er den samlede varmekapacitet af systemet, hvorefter den integreres. Systemet har
tilbagekobling gemme effekttabet fra vinduer og vægge der benytter forskellen mellem T(t) og
udetemperaturen U(t) der forstærkes således, at den giver effekttabet.
3.3.4 Den matematiske models antagelser og tilnærmelser
I forbindelse med den matematiske model er der i det ovenstående blevet opstillet følgende
antagelser og tilnærmelser i forhold til den fysiske model.
- Alt effekt i kantaltråden afsættes til luften i modellen, og at det sker momentant.
- Varmen i luften fordeles således, at der er ens temperatur inde i hele modellen, dvs. at
temperaturen i luften er homogen.
- Temperaturen i omgivelserne regnes for konstant.
- Ved transporten gennem væggene beskrives følgerne af konvektion med konstanten Rg og
hele overgangen regnes derefter som konduktivitet.
- Modellen fungerer bedst omkring et arbejdspunkt ved stuetemperatur, ± 40°C da væsentlige
konstanter afviger udenfor dette område.
3.4 Bearbejdelse med laplacetransformationen
Laplacetransformationen er et nyttigt værktøj, der sætter brugeren i stand til at behandle
vanskelige differentialligninger, som ville være næsten umulige at løse på sædvanlig vis.
Laplaceoperatoren kan benyttes til at transformere differentialligninger over til rene algebraiske
udtryk, som kan bearbejdes på klassisk vis. Den algebraiske ligning, der fremkommer slutteligt
beskriver tidsresponset for det system, som differentialligningen blev stille op for. Dermed kan det
ses, hvordan systemet vil reagere som en funktion af tiden.
Metoder er som følger [Haugen]:
- Differentialligningen laplacetransformeres.
- De enkelte indgangsvariables laplacetransformerede funktionsudtryk findes og
indsættes. Indgangsvariablerne er de variable der kan ændres og dermed have
indflydelse på output.
- Ligningen opstilles som overføringsfunktionen, hvorfra de relevante oplysninger
om systemets forstærkning og tidskonstant kan findes.
Med overføringsfunktionen har vi opnået tilstrækkelig viden omkring systemet til at forudse
hvorledes det vil opføre sig. Hvis differentialligningen ønskes på algebraisk form fortsættes på
følgende vis:
- Ligningen ordnes således at udgangsvariablen, der er den variable som
tidsresponset ønskes for, isoleres.
- Ligningen kan inverslaplacetransformeres tilbage og giver så systemets
tidsrespons på algebraisk form, hvilket kan benyttet til verificere den matematiske
model og til at finde slutværditeoremet.
Side 28 af 113

Modellering
En differentialligning siges at befinde sig i tidsdomænet, mens den efter at være blevet
laplacetransformeret befinder sig i frekvensdomænet. Hvis der foretages
inverslaplacetransformation befinder ligningen sig igen i tidsdomænet, og kan derefter benyttes til
at forudsige systemets tidsrespons.
3.4.1 Arbejdspunktligning
Ved laplacetransformation mistes information omkring begyndelsesbetingelserne for det
modellerede system. For at imødegå dette vil vi lade vores matematiske beskrivelse tage
udgangspunkt i et veldefineret arbejdspunkt, dvs. vores ligning vil beskrive ændringer i forhold til
dette arbejdspunkt. En veldefineret tilstand i vores model indtræder når differentialledet i ligningen
for systemet er 0. Dvs. når temperaturen er stabil:
U ( 0)
−T
( 0)
U ( 0)
−T
( 0)
0 = R(
0)
+ Avindue
⋅
+ Avægge
⋅
(3.13)
R + R
R + R
vindue
overgang
vindue
overgang
For at finde frem til arbejdspunktsligningen, dvs. en ligning der beskriver ændringer udfra et
arbejdspunkt, trækkes ovenstående ligning 3.13 fra ligningen for modellen 3.12. Dette giver
følgende overføringsfunktion, hvori der indsættes konstanter, gældende for vores fysiske model (fra
bilag "Fysmod"):
∆T
( s)
1
=
⇒
∆R(
s)
⎛ 1 1 ⎞ A
A
vindue
vægge
s⎜C
luft + Cvindue
+ Cvægge
) ⎟ +
+
⎝ 2 2 ⎠ R + R R + R
(3.14)
∆T
( s)
0.
836
=
∆R(
s)
s ⋅ 991 + 1
vindue
overgang
vindue
overgang
I denne ligning kan forstærkningen aflæses til at være 0.836 og tidskonstanten til at være 991.
Hvis vi anvender slutværditeoremet på ligning 3.14. dvs. vi lader s gå mod nul, får vi at:
∆T = ∆R
⋅ 0.
836 (3.15)
Denne ligning fortæller hvor stor ændring i temperatur vi vil opnå ved en given effektændring, når
systemet igen når en stabil tilstand. Det vil sige, at hvis vi ønsker at hæve temperaturen med 10
grader, skal effektafgivelsens øges med 12W. Ligningen gælder generelt udfra et arbejdspunkt,
hvilket gør at den beskriver både opvarmning og nedkøling.
Selvom overføringsfunktionen er sætter os i stand til at forudsige systemets overordnede reaktion,
men for at kunne forudsige systemets værdi på et bestemt tidspunkt skal ligningen tilbage i
tiddomænet. Gennem inverslaplacetransformation fås følgende algebraiske udtryk for
differentialligning 2.13:
991
∆ T ( t)
= ∆R
⋅ 0.
836(
1−
e ) ) (2.16)
0
R0 er enhedsspringet i denne ligning og beskriver en konstant tilført radiator effekt, som
påbegyndes til tiden t=0.
− t
Side 29 af 113

Modellering
Udtrykket 3.17 har kun ∆R som input og afhænger derfor ikke af temperaturforskellen mellem
inde- og udetemperatur i det øjeblik ∆Ro ændres. Grunden til, at den ikke optræder i vores
arbejdspunktligning 3.16 er, at den elimineres under udledningen af denne (se bilag "LAPLACE").
Dette skyldes vores tilnærmelse om, at al varmetransport sker ved konduktivitet (jvf. 3.2.2). Des
større temperaturforskellen er des større betydning får konvektion. I vores model regnes
konvektionen konstant som en isolans på 0.17, men i virkeligheden ændrer denne sig med
temperaturforskellen. Overgangsisolansen er dog tilstrækkelig nøjagtig i et arbejdspunkt gældende
for både ude- og indetemperaturen omkring stuetemperatur. Vi kan altså derfor forvente, at
arbejdspunktligningen vil miste nøjagtighed des større temperaturforskellen er.
3.5 Verificering af den matematiske model
For at verificere om der er sammenhæng mellem den fysiske og den matematiske model, har vi
gennemført en række forsøg med den fysiske model. Vi kan derigennem undersøge om den række
af antagelser og tilnærmelser vi har foretaget i den matematiske model har været præcise nok til at
give et resultat, der stemmer overens med virkeligheden. Forsøgene blev udført som op- og afkøling
af kassen, hvor der blev taget temperaturmålinger indtil indetemperaturen havde stabiliseret sig.
Nærmere beskrivelse findes i forsøgsbeskrivelserne i (bilag ”Forsøgsbeskrivelser”).
Ved verifikation af arbejdspunktsligningen indsættes parametrene fra forsøg 1 i ligning 2.16 hvilket
giver følgende algebraiske udtryk.
∆ T ( t)
= 35 ⋅ 0.
836(
1−
e
− t
991
Denne plottes i fig. 2.2 sammen med forsøgsresultaterne fra forsøg 1.
Figur 3.4 – Grafen viser opvarmning for forsøget og den matematiske model.
Af fig. 3.4 ses det, at de to grafer følger hinanden og vi kan derfor sige, at antagelserne i den
matematiske model ikke er gået ud over nøjagtigheden i modellen. Den lille forskel der ligger i
slutværdierne kan skyldes f.eks. at modellen er dårligere isoleres en antaget i den matematiske
Side 30 af 113
)

Modellering
model, hvilket ganske rigtigt er tilfældet. Låget passer ikke helt præcist på modellen og vindue kan
ikke lukkets helt tæt til. Dette gør at den matematiske model har en større forstærkning end den
fysiske model.
For at verificere arbejdspunktligningen ved nedkøling betragtes den stabile termiske tilstand med
konstant effekt på radiatoren som det nye arbejdspunkt. Når effekten fjernes ved nedkølingsforsøget
kan ∆R(t) derfor betragtes som et negativ spring, hvilket plottes sammen med forsøgsresultaterne
fra forsøg x.x i fig. 3.5:
−0.
001155⋅t
∆ T ( t)
= −35⋅
0.
837(
1−
e )
Figur 3.5 – Grafen viser nedkøling for forsøget og den matematiske model.
Af fig. 3.5 ses at de to grafer for forsøget og den matematiske model følger hinanden pænt. Vi kan
se at afkølingen for den matematiske model går langsommere end for forsøget. Forskellen kan
ligesom sidst skyldes at den matematiske model er dårligere isoleres end antages, hvilket vil gøre
udligningen af temperaturen hurtigere.
3.6 Delkonklusion
Der kan fra det ovenstående konkluderes, at det gennem en række tilnærmelser og antagelser er
lykkedes, at skabe en matematisk model, der stemmer godt overens med den fysiske, de forklarede
fejlkilder taget i betragtning. Vores overføringsfunktion og arbejdspunktsligning giver en
tilstrækkelig detaljeret beskrivelse af systemet, som sætter os i stand til at forudsige systemets
opførsel.
Vi er opmærksomme på, at den matematiske model har et begrænset gyldighedsområde, idet den
er opbygget på baggrund af den fysiske model og derved kun forholder sig til virkeligheden gennem
antagelserne jvf. 3.2.1.
Side 31 af 113

4.0 Regulering
Regulering
Reguleringen skal opfylde projektafgrænsningens 1. punkt; "det elektroniske system autonomt
kunne overvåge temperaturen og på baggrund heraf styre en radiator” og de der tilhørende krav.
Kravene til reguleringsalgoritmen er jvf. 3.5.2 følgende:
1. Systemet skal kunne registrere om hvorvidt vinduet er åbent eller lukket på baggrund
af temperatur.
2. Systemet skal kunne udføre natsænkning.
3. Systemet skal kunne fungere som en termostat således, at en ønsket indetemperatur
opretholdes.
At der skal reguleres på baggrund af temperaturen betyder ifølge den matematiske model at
reguleringen både skal have indetemperaturen og en arbejdspunktstemperatur til rådighed. På
baggrund af konklusionerne til den matematiske model vil vi benytte denne til at opstille
reguleringsalgoritmerne for systemet.
Vi vil ikke udvikle styringsalgoritmer til et virkeligt rum, men i stedet koncentrere os om at
udvikle en styring til elradiatoren i den fysiske model. Vi vil imidlertid jvf. 2.5.1 bestræbe os på at
opbygge styringen således, at den nemt vil kunne implementeres i et virkeligt rum.
Der findes forskellige metoder til at konstruere en reguleringsalgoritme. Vi vælger at udvikle en
løsning udfra logisk tænkning, fremfor at benytte mere gennemprøvede og anerkendte metoder, da
løsningen skal bygge både på teorien fra den matematiske model og logiske valg fra empiriske
forsøg.
For at undersøge hvordan op- og nedkølingsprocesser finder sted når vinduet åbnes og lukkes vil
vi med den fysiske model gennemføre forsøg med forskellige sammensætninger af åbnet og lukket
vindue i både op- og nedkølingssammenhæng. Vi vil derefter sammenholde disse resultater med
resultaterne fra den matematisk model og derudfra opstille en metode til påvisning om hvorvidt
vinduet er åbent eller lukket.
For at lette udviklingsarbejdet vil vi programmere en computermodel i C++ til at simulere den
fysiske model på baggrund af differentialligning 3.12. Der simuleres på baggrund af
differentialligningen og ikke det algebraiske resultat fra den matematiske model idet det lettere
giver mulighed for at manipulere ligningen til at simulere f.eks. et åbent vindue. I
computermodellen kan reguleringsalgoritmerne implementeres som et modul og kan løbende
afprøves. Derved kan reguleringen komme til at fungere inden den implementeres i hardwaren.
4.1 Computersimulation
I modsætning til matematisk modellering, som udnytter symbolsk matematik, er
computersimulering baseret på numeriske metoder. Der er en klar sammenhæng imellem de to, idet
en computersimulering nødvendigvis må have nogle matematiske formler at simulere udfra. Men
fordelen er netop computerens store regnekraft kan bruges til at bearbejde matematiske udtryk, som
er vanskelige at bearbejde matematisk, f.eks. differentialligninger.
En anden fordel ved computersimulationen er dens mulighed for fleksibilitet. Den kan udvikles på
en sådan måde, at brugeren har god mulighed for at variere input og indsætte forskellige fysiske
konstanter og startbetingelser, hvilket hjælper brugeren til, at få indsigt i det modellerede system,
fordi vedkommende nemt kan ændre de forskellige variable og hurtigt få et resultat på baggrund
heraf. Endeligt kan modellen udvikles på en sådan måde, at det er muligt at indsætte procedurer,
Side 32 af 113

Regulering
som simulerer mulige løsningsforslag. Dette giver mulighed for at vurdere løsningens opførsel og
effektivitet, og hermed er der også mulighed for at opdage fejl eller mangler inden
implementeringsfasen påbegyndes. Der er altså mulighed for at bottom-up teste
reguleringsalgoritmerne inden implementationen i microcontrolleren.
4.2 Analyse af reguleringen
I analyse delen vil de enkelte problemstillinger blive analyseret og løst, og der vil blive opstillet
top-down diagrammer over løsningerne. Selve reguleringsmodulet opdeles i to hoveddele:
- Åbent vindue
- Lukket vindue
Under disse tre dele kaldes de enkelte
undermoduler. Initialiseringen gennemløbes
første gang og foretager de nødvendige
indledende manøvrer. Under de to hoveddele
åbent og lukket vindue skal
styringsalgoritmerne som tidligere specificeret
kunne løse følgende problemstillinger (fig. 4.1):
- Opretholdelse af ønsket
indetemperatur.
- Natsænkning.
- Registrering af åbnet vindue.
- Registrering af lukket vindue.
Regulering
Åbent vindue Lukket vindue
Registrering af
lukning af
vindue
Natsænkning
Registrering af
åbning af
vindue
Opretholdelse
af temperatur
Figur 4.1 – Topdown over reguleringsalgoritmens
opbygning i 2 hoveddele.
Under lukket vindue vil der blive testet for åbning af vindue, og der vil ligeledes blive gennemført
opvarmningstest som metode til registrering af åbent vindue i forbindelse med opvarmning. Under
åbent vindue vil der blive teste for lukning af vindue.
4.2.1 Opretholdelse af temperatur
Styringsalgoritmerne skal ligeledes kunne opretholde en ønsket temperatur i rummet og derved
fungere som en slags termostat. En ændring i rumtemperaturen kan betragtes som en ændring i
energistrømningerne i systemet, dvs. en stigning i temperaturen svarer til mere energistrømning ind
i systemet. Det betyder altså i praksis, at når temperaturen i rummet stiger skal effekten mindskes
således, at temperaturen igen er stabil. Det omvendt gør sig gældende ved et fald i temperaturen.
Stigninger i energistrømningerne ind i systemet vil i et virkeligt rum kunne bestå af varme fra elartikler
eller mennesker. I den fysiske model eksisterer disse faktorer ikke og svingninger i
effektindstrømningen vil kun finde sted gennem ændringer i udetemperaturen eller gennem kunstigt
fremkaldte ændringer. Dette kunne f.eks. være indsættelse af et ekstra varmelegeme. En sådan
effektændring indgår ikke i den matematiske model og styringen kan derfor ikke direkte tage højde
for den, hvilket skaber behovet for en speciel termostatfunktion.
Side 33 af 113

Regulering
En simpel og effektiv metode er at regulere udfra den effekt der oprindeligt skulle til for at
opretholde temperaturen, og det er derfor den metode vi vælger at arbejde videre med. Dvs. den
effekt der teoretisk skulle kunne opretholde den ønskede temperatur under forudsætning af at kun
udetemperaturen har indflydelse. Vi benytter altså udetemperaturen som arbejdspunkt, hvilket gør
at der altid bliver taget højde for ændringer i udetemperaturen. Denne teoretiske effekt (Wteo) kan
beregnes ved slutværditeoremet (ligning 3.16) udfra udetemperaturen på følgende vis:
hvor:
W
teo
Wteo er den teoretiske effekt.
Tønsket er den ønskede temperatur.
Tude er udetemperaturen.
Tønsket
−Tude
= (4.1)
0.
837
For at undersøge hvor meget der skal reguleres, benyttes forskellen mellem den ønskede
temperatur og den øjeblikkelige indetemperatur. Denne difference vil være negativ hvis
temperaturen er højere end den ønskede temperatur. Differencen multipliceres med en faktor (x) og
lægges derefter til den teoretiske effekt. Dette giver den reelle effekt (Wrel) der er den effekt der er
korrigeret for temperaturændringen.
hvor:
Wrel er den reelle effekt.
Tinde er indetemperaturen.
x er en skaleringsfaktor.
( T − T ) ⋅ x
Wrel = Wteo
+ ønsket inde
Med denne løsning kan der imidlertid opstå det problem at effekten og temperaturen stabiliseres et
stykke fra den ønskede værdi. Dette sker fordi reguleringen ikke har hukommelse. Den regulerer
udfra den øjeblikkelige situation og glemmer derved de ændring der er blevet gjort tidligere. Hvis
der kommer en ændring i energistrømningerne i systemet således, at der sker en effektstigning (se
tidligere i afsnittet), vil det forsage en opvarmning og indetemperaturen vil stige. Dette vil gøre, at
effekten vil falde proportionalt dermed. Når effekten falder vil stigningen blive mindre og
effektfaldet vil derfor også blive mindre. Dette gør, at der opnås en ligevægtstilstand, hvor
temperaturen og effekten vil stabilisere sig. I denne stabile tilstand har reguleringen glemt, at den
under opvarmningen, har sænket effekten. Temperaturen i den stabile tilstand er altså lavere den
ville være, hvis der ikke var blevet reguleret under opvarmningen. Reguleringen benytter dog stadig
denne "kunstigt" lave temperatur som udgangspunkt for at finde ud af, hvor meget effekten skal
sænkes for at modvirke den ekstra effektkilde og derved er problemet opstået. Dette problem kan en
stor skaleringsfaktor minimere.
Skaleringsfaktoren x er et udtryk for hvor hurtigt reguleringen skal finde sted, og den er ligeledes
et udtryk for hvor præcis reguleringen er. Des større faktoren, des hurtigere og mere præcis er
reguleringen. I dette tilfælde vælges x til 50 3 idet det giver en hurtig regulering og tillige en god
præcision. Dette giver følgende formel:
( T − T ) ⋅50
(4.2)
W rel = Wteo
+ ønsket inde (4.3)
3 Faktoren er bestemt udfra empiriske forsøg i computermodellen.
Side 34 af 113

Regulering
Når der benyttes så stor en faktor opstår imidlertid det problem, at effektspringene kan blive meget
store, og da radiatoren i den fysiske model har et begrænset virkeområde er det nødvendigt at
afgrænse effekten til et interval der svarer til radiatorens formåen. Intervallet sættes til at ligge
mellem 0 og 50 W.
Natsænkning:
Natsænkning implementeres let idet det blot kræver, at der i det specificerede tidsinterval
indsættes den ønskede nattemperatur som Tønsket.
4.2.2 Registrering af åbning af vindue
Vi vil her gennemføre en analyse af de processer der foregår i systemet og derigennem
fremkomme med en løsning til registrering af åbning af vindue. Ved en analyse af de termiske
processer i den fysiske model kan følgende opdeling gennemføres:
- Opvarmning med lukket eller
åbent vindue.
- Nedkøling med lukket eller
åbent vindue.
- Stabil tilstand med lukket eller
åbent vindue.
Vi har altså 3 tilstande der hver
kan optræde med 2 forskellige
situationer. De 3 tilstande med
lukket vindue er beskrevet
indgående i afsnittet om den
matematiske model, og vi vil derfor
først koncentrere os om
situationerne med åbent vindue.
Dette kan analyseres gennem
forsøg x.x (beskrevet i bilag
Figur 4.2 – Forsøg x.x. Temperaturen som en funktion af
tiden i sekunder. Først en opvarmning med lukket vindue
og derefter en nedkøling med åbent.
”forsøgsbeskrivelse”) der først beskriver en opvarmning med lukket vindue. Når temperaturen har
stabiliseret sig åbnes vinduet hvilket sætter en nedkøling med åbent vindue i gang (se fig. 4.2).
Under hele forløbet holdes radiatoreffekten konstant. På grafen ses det tydeligt hvornår vinduet blev
åbnet og hvilken effekt det fik på temperaturen. Åbningen resulterer i et drastisk fald i temperaturen
før den igen stabilisere sig på et lavere niveau.
Vi vælger at betragte processer med åbne vindue som værende 1. ordens funktioner og derfor
samme type funktion som processer med lukket vindue. Vi kan derfor ligeledes jvf. 3.4 betragte
opvarmning og nedkøling under samme funktion og stabil tilstand som værende slutværditeoremet
for dem. Vi har altså begrænset de før omtalte 3 tilstande med hver 2 situationer til følgende 2
hovedsituationer:
- Åbnet vindue.
- Lukket vindue.
Side 35 af 113

Regulering
Det er tydelig ud fra fig. 4.2 at tidsresponset og dermed tidskonstanten ikke er det samme med
åbent og lukket vindue, ligesom forstærkningen også er forskellig. Både tidskonstanten og
forstærkningen formindskes ved åben vindue, hvilket giver et forløb der er både hurtigere og med
mindre udslag. Dette stemmer overens med den logiske slutning at effekttabet vil blive større når
vinduet åbnes. Det kan sammenlignes med en forringelse af isolansen, dvs. en mindre R-værdi.
For at kunne registrere om hvorvidt vinduet er åbent er det essentielt at koncentrere sig om
detektering af skiftet mellem lukket til åbent. At konstatere et skift fra lukket til åbent er forholdsvis
enkelt udfra forsøgsresultaterne, der viser det før omtalte fald i temperaturen, når der er tale om
stabil tilstand og nedkøling. Hvis vinduet åbnes under opvarmning kan ændringen ses i
tidskonstanten og forstærkningen og radiatoren kan på baggrund deraf slukkes. Registreringen af
temperaturfaldet kan ske ved en lagring af indetemperaturen over et tidsrum og så sammenligne den
første med den sidste måling. Denne lagring kan finde sted i en tabel hvor alle pladserne rykkes en
plads bagud hver gang der kommer en ny måling, som så lægges ind på den først plads. Tidsrummet
der lagres over sættes til 120 sekunder idet der er tilstrækkelig tid til at ændringer i
indetemperaturen vil være synlige. Testen skal dog ikke finde sted i det tilfælde, hvor den ønskede
temperatur bliver sat ned således, at der fremkommer et tilsigtede temperaturfald. Dette betyder
altså at testen ikke skal udføres og tabellen ikke opdateres, når den ønskede temperatur er mindre
end indetemperatur. Ydermere skal tabellen initialiseres til den nye ønskede temperatur idet testen
ellers ville opfange et temperaturfald når der igen sammenlignes værdier i tabellen.
Alt efter vinduets størrelse og forskellen på udetemperatur og ønsket indetemperatur vil faldet ikke
altid være så drastisk som vist i fig. 4.3 og vil derfor måske ikke kunne registreres, men desto
mindre faldet er des mindre vil effekttabet fra radiatoren være.
4.2.3 Registrering af lukning af
vindue
Registrering af lukning af vindue er
vanskeligere end registrering af
åbning, idet der ikke umiddelbart kan
ses en ændring af temperturen som
følge af lukningen. Hvis vinduet
åbnes fra en stabil tilstand med effekt
på radiatoren vil radiatoren slukke og
der vil som tidligere beskrevet ske et
drastisk temperatur fald. Når vinduet
lukkes vil indvirkningerne på
indetemperaturen være meget
begrænsede og det besværliggør
registreringen der skulle ske netop på
baggrund af indetemperaturen.
Figur 4.3 – En nedkølingskurve fra den fysiske model med
slukket radiator og åbent vindue, hvor vinduet lukkes ca. ved
måling 430.
En løsningsmulighed kunne være at benytte det faktum, at væggene afkøles langsommere end
luften. Det vil så føre til, at når vinduet lukkes vil der ske en lille opvarmning af luften som følge af
væggenes højere temperatur. Dette er under forudsætning af, at vinduet ikke har været åbnet så
længe at væggene ligeledes er blevet nedkølet til udetemperaturen. Endvidere vil der når vinduet
lukkes opstå et lille temperaturspring idet trækken hører op. For at undersøge om hvorvidt dette kan
Side 36 af 113

Regulering
praktiseres er forsøg a.a blevet gennemført med målinger hver 10’ende sekund. Først opvarmes den
fysiske model til en stabil tilstand hvorefter vinduet åbnedes og radiatoren slukkedes. Da
temperaturen igen havde stabiliseret sig blev vinduet lukket og resultaterne sammenfattet i fig. 3.3.
Vinduet lukkes omkring den 440 måling og den forventede stigningen ses svagt. Stigningen er
imidlertid kun på ca. 0,5 grad og vil derfor være svær at detektere. I et virkeligt rum kan en så svag
stigning fremkomme på andre måder end ved vindueslukning. Dette kunne f.eks. være en person
der går forbi. I den fysiske model eksisterer der dog ikke sådanne fejlkilder og en stigning i
temperaturen vil derfor, hvor svag den end er, kunne bruges til at registrere en vindues lukning.
Registreringen skal blot ske meget nøjagtig.
At stigningen ikke blev så kraftig som forventet skyldes formodentlig at væggene i den fysiske
model er af flamingo, og derfor ikke
indeholder særlig meget mere
varmeenergi end luften. Hvis
vindueslukningen var foretaget
tidligere ville der have været mere
varmeenergi tilbage i væggene og
springet ville have været større.
Det spring der ses stammer
formodentlig fra det føromtalte
temperaturspring der kommer af at
trækken hører op når vinduet lukkes.
Var væggene derimod af mursten eller
lignende materiale der holder bedre på
varmen, ville springet sandsynligvis
være større. Endvidere ville et rum i et
typisk hus, hvor temperatursensoren
Figur 4.4 – Forsøgskurve i virkeligt rum med åbent vindue og
slukket radiator hvor vinduet lukkes ca. ved måling 360.
opsættes, have tilstødende rum langs de fleste af murerne. Hvis disse tilstødende rum ikke ligeledes
er blevet nedkølet vil der transporteres noget varme fra dem og ind i det afkølede rum og dette vil
resultere i en større spring i temperaturen når vinduet lukkes. For at afprøve dette er forsøg b.b
blevet gennemført i en almindelig lejlighed med målinger hver 10’ende sekund. Af fig. 4.4 ses
stigningen i temperaturen tydeligt omkring måling 350 hvor vinduet lukkes. Vi ser altså at metoden
kan benyttes i både den fysiske model, hvor registreringen skal ske efter en lille stigning, og i et
virkeligt rum hvor registreringen først skal ske efter en noget større stigning. Selve registreringen af
temperaturændringen kan ske analogt med registreringen af åbning.
En anden løsningsmulighed vil være at benytte den matematiske models tidskonstant og
forstærkning som registreringsparametre. Dette kunne gøres ved at sætte effekt på radiatoren og
derved påbegynde en opvarmning. Selve sammenligningen med den matematiske model kan foregå
på flere forskellige måder:
1. Opvarmning skal efter tidskonstanten have opnået 63% af sin endelige værdi som
er den fastsatte sluttemperatur:
Ttest
= ( Tønsket
− Tude
) ⋅ 0.
63
(4.4)
2. Hældningen på opvarmningen svarer det første stykke til tidskonstanten.
Side 37 af 113

hvor:
Regulering
3. Den matematiske model kan benyttes til at på et vilkårligt tidspunkt (t) beregne en
testtemperatur:
−0.
001155⋅t
Ttest
= R ⋅ 0.
837(
1−
e )
(4.4)
R er radiatoreffekten.
At benytte løsning 2 har den ulempe at opvarmningen er lidt ujævn i starten og det er derfor ikke
sikkert at hældningen vil svare helt til tidskonstanten selvom vinduet er lukket. Løsning 1 har den
ulempe at der skal ventes temmelig lang tid i vores model før testen kan udføres. Tidskonstanten er
991 sekunder hvilket ca. svarer til 15 minutter. Vi vælger derfor at benytte 3. mulighed med
beregning af testtemperaturen på et vilkårligt tidspunkt. Test tidspunktet sættes til 100 sekunder idet
der er et stort nok tidsrum til at opvarmningen kan komme over ujævnhederne i starten, mens det
stadig er noget kortere end tidskonstanten.
Den temperatur der beregnes er temperaturændringen fra det arbejdspunkt som opvarmningen
starter ved. Denne arbejdspunktstemperatur skal derfor lægges til testtempeaturen for at give et
resultat der kan sammenlignes med den virkelige indetemperatur. Det giver følgende ligning:
hvor:
T
T
test
test
= R ⋅ 0.
837(
1−
e
= R ⋅ 0.
0913 + T
−0.
001155 ⋅100
arbejd
Tarbejd er arbejdspunktstemperaturen.
) + T
Efter at testtemperaturen er beregnet kan forskellen mellem Ttest og Tinde så findes, og hvis der er
Tinde er mindre end Ttest så foregår opvarmningen ikke efter den matematiske model. Vinduet er
altså åbnet og opvarmningen standses. Hvis der er overensstemmelse mellem dem eller Tinde er
større end Ttest betyder det, at vinduet er lukket og opvarmningen kan fortsætte. Denne test kan så
udføres med passende tidsintervaller.
Denne løsning har den svaghed, at der gennemføres en masse unødvendige opvarmninger.
Endvidere tager løsningen ikke højde for om der under opvarmningen er sket en ændring i
udetemperaturen, men dette er mindre relevant, idet der sjældent vil ske mærkbare ændringer der
kan nå at få indflydelse, på de 100 sekunder som testen varer.
Metoden med opvarmningstest kan imidlertid bruges til at minimere problemerne i den første
løsningsmulighed ved, at kombinere de to løsninger. Den første løsning kan fortælle os om der er
sket en stigning, og at det kunne skyldes at vinduet er blevet lukket. Der påbegyndes så en
opvarmning med en effekt beregnet udfra formel 3.1 hvor der benyttes arbejdspunktstemperaturen i
stedet for udetemperaturen. Efter 100 sekunder kan den anden løsning teste om opvarmning følger
den matematiske model og dermed undersøge, om vinduet virkelig er blevet lukket. Hvis dette er
tilfældet kan der overgås til en effekt beregnet udfra udetemperaturen og dermed give en
opvarmning imod den ønskede temperatur. Hvis vinduet stadig er åbent, afbrydes opvarmningen og
der ventes til næste gang der sker en stigning i temperaturen. Opvarmningstesten stiller det krav til
termostatmodulet, at der ikke må reguleres under opvarmningen, idet det vil fremskynde
opvarmningen og dermed vil Ttest blive højere end beregnet. Det kræver derfor, at termostatmodulet
kun køres når opvarmningstesten er overstået.
arbejd
Side 38 af 113
⇔
(4.5)

Regulering
4.2.4 Sammenfatning af åbning og lukning af vindue
Analysen i 4.2.2 og 4.2.3 har givet os følgende værktøjer til registrering af skift mellem åbent og
lukket vindue:
- Åbning af vindue kan registreres ved et brat temperaturfald.
- Lukning af vindue kan registreres ved en stigning i indetemperaturen.
- Lukning af vindue kan bekræftes gennem en testopvarmning hvis parametre
sammenholdes med den matematiske models for lukket vindue. Hvis der er
overensstemmelse er vinduet lukket.
Registreringen af temperaturstigning og
temperaturfald kan principielt foregå på
samme vis, men da registreringen af faldet
ikke skal være så fintfølende som
registreringen af en stigning, og da der
ikke udføres test ved registreringen af fald,
vil det være hensigtsmæssigt med en
opsplitning. Registreringen af lukning skal
kunne opfatte en meget lille ændring, og
kan derfor komme til at registrere
ændringer der intet har med lukning af
vinduet at gøre. Disse vil blive korrigeret
af testopvarmningen. Registreringen af
fald vil ingen fejlkorrektion have og skal
derfor være sikker når den melder åbent
vindue. Da et åbent vindue vil give et brat
fald i temperaturen skal registreringen af åbning først ske efter en forholdsvis stort fald. Opdelingen
er skitseret i fig. 4.5 der viser et topdown over registrering af åbning og lukning, samt test af
lukningen. Denne opdeling giver en korrektion til hovedopdelingen af programmet i fig. 4.1, idet
opvarmningstesten skal indgå som et modul for sig.
4.3 Design af reguleringsalgoritmen
11:03
Registering af
lukning
Registering af
temperaturstigning
Registering af
åbning og
lukning
Test af
lukning
Test af om
opvarmning følger
matematisk model
Registrering
af åbning
Registering af
temperaturfald
Figur 4.5 – Topdown over registreringsalgoritmen til
registrering af åbning og lukning af vindue.
I designfasen vil det blive beskrevet hvordan løsningerne blive sammensat til en fungerende
helhed. Reguleringsalgoritmen konstrueres således, at den kan indsættes i et driverprogram som et
enkelt funktionskald. Dvs. at reguleringen skal finde sted i et enkelt modul der udfra ude- og
indetemperatur, samt forskellige brugerspecificerede input skal kunne foretage reguleringen og
derudfra returnere en effekt. Dette enkelte modul skal så indeholde de tre hoveddele i reguleringen:
Åbent vindue, lukket vindue og test. At samle reguleringen i et modul gør reguleringen lettere at
implementere i et driverprogram, der i dette tilfælde er computersimulationen. Denne opbygges som
en uendelig løkke, hvori reguleringen kaldes med passende tidsinterval. Dette betyder at
reguleringen skal konstrueres sådan, at den aldrig kan gå fast 4 , således at hele programmet standses.
Derfor kan reguleringen ligeledes betragtes som en uendelig løkke hvori driverprogrammet er
indbygget som en forsinkelse der sørger for, at reguleringen kun køres når det er tid. Det forløb der
4 Dvs. at programmet ikke må vente på at en begivenhed skal indtræffe.
Side 39 af 113

Regulering
kan ses i flowchartet i bilag 10 er en illustrering af, hvordan forløbet ser ud ”fra reguleringens
synspunkt”. I det endelige forløb ligger driverprogrammet som hovedmodulet, der kalder
reguleringen.
Der skelnes i opbygningen af reguleringen mellem tre tilstande(mode):
- 0 = Lukket vindue
- 1 = Åbent vindue
- 2 = Opvarmningstest
Initialisering
Først undersøges der om det er første gennemgang. Dette gøres ved kun at lade initialiseringen
køre, når en tællervariabel er 0, hvilket den er sat til fra starten af og som, når initialiseringen køres,
sættes til 1. Under initialiseringen sættes tilstand til 2 således, at der startes i testtilstand og derved
undersøges der for om vinduet er åbent. Endvidere initialiseres en tabel, der benyttes til registrering
af åbning og lukning af vinduet (jvf. 3.2.2), til indetemperaturen for at undgå problemer når tabellen
benyttes. I initialiseringen tages ligeledes kopi af indetemperaturen til brug som arbejdspunkt når
den første test skal udføres. Dette gør at reguleringen kan startes uvilkårligt om ude- og
indetemperatur er ens.
Natsænkning
Derefter undersøges om det er natsænkningstid og i så fald sættes den ønskede temperatur til
nattemperaturen og der tages en kopi af den oprindelige ønskede indetemperatur. Når
natsækningstiden slutter sættes sluttemperaturen igen til den oprindelige værdi gemt i kopien. For at
modvirke at temperaturfaldet frembragt af natsænkningen bliver registreret som vinduesåbning
initialiseres tabellen til den nye sluttemperatur og der testes ikke for åbning af vindue mens den
ønskede temperatur er mindre end indetemperaturen. Samme fremgangsmåde benyttes når den
ønskede temperatur ændres i anden sammenhæng.
Testtilstand
Der undersøges for hvilke tilstand reguleringen befinder sig i og hvis der er første gennemløb vil
det være 2, dvs. testtilstand. Dette sætter reguleringen istand til at vurdere om den befinder sig i
åbent eller lukket tilstand fra starten af. I testtilstanden beregnes først en opvarmningseffekt udfra
arbejdspunktet, der som tidligere nævnt er den temperatur testopvarmningen begyndes fra. Derefter
beregnes en testtid, der bestemmer hvornår sammenligningen mellem den virkelige og den
teoretiske indetemperatur skal finde sted. Den er, (jvf. 3.2.3), 100 sekunder hvortil der lægges en
variabel, testvar, der i første gennemløb er 0 og først benyttes ved næste testopvarmning. Den sættes
lig tiden inden der overgås fra tilstand åbent (1) til tilstand test (2) og sørger dermed for, at der
sammenlignes 100 sekunder efter testen begyndte. Hvis tiden er lig testtiden og det dermed er tid til
sammenligningen beregnes den teoretiske testtemperatur udfra arbejdspunktet og der undersøges
om den er større den virkelige indetemperatur. Hvis de stemmer overens eller indetemperaturen er
størst sættes tilstanden til lukket (0) og hvis ikke sættes tilstanden til åbent (1), hvorefter
registreringstabellen initialiseres til indetemperaturen. Dette gøres idet vinduestesten, i tilstand
åbent, ellers ville registrere den stigning der er sket i testopvarmningen og dermed vil der
påbegyndes en ny test.
Lukket vindue tilstand
Side 40 af 113

Regulering
Hvis vinduestesten forløber således, at der overgås til tilstand lukket, beregnes først den effekt der
skal til for at opnå den ønskede temperatur. Derefter køres termostatdelen således, at effekten
reguleres efter den ønskede temperatur. Endelig testes for temperaturfald og hvis et sådant er
tilstede og det er stort nok overgås til tilstand åbent.
Åbent vindue tilstand
I tilstand åbent sættes effekten til 0 og der testes for temperaturstigning og hvis en sådan
forekommer overgås til tilstand test. Ligeledes sættes arbejdspunktet lig med indetemperaturen
således, at når der overgås til test vil indetemperaturen, hvorfra testen startes, blive benyttet som
arbejdspunkt. Endelig sættes testvar som tidligere nævnt lig tiden.
For at spare plads og lette overskueligheden af programmet opbygges visse programdele som
selvstændige moduler:
- Initialisering af tabel
- Beregning af teoretiske effekt
Effektberegningen forløber helt analogt med formlerne specificeret i 4.2.1 , mens initialiseringen
af tabellen konstrueres med en løkke der for hver gennemløb tæller tabelpladsen en op og lægger
indetemperaturen ind derpå.
3.3.1 Design af undermoduler
Pseudokoden for undermodulerne kan findes i bilag ”regulering”.
Termostatmodul
Termostatmodulet skal regulere effekten således, at indetemperaturen holdes på det ønskede
niveau. Først beregnes den reelle effekt jvf. 3.2.1 og derefter gennemføres afgrænsningen af den
reelle effekt således, at den passer indenfor radiatorens formåen der ligger mellem 0 og 50 watt.
Modul til registrering af åbning og lukning
Registreringen af åbning og lukning af vindue forløber på næsten samme vis og derfor vil kun
åbningen blive beskrevet her. Den vil blive opbygget gennem lagring af indetemperaturen i en tabel,
der bliver 120 pladser stor. Tabellens værdier skal for hver gennemløb rykkes en plads således, at
den ældste værdi gilder ud og den nyeste værdi bliver indsat på den første plads. Først rykkes alle
tabelpladserne en plads i tabellen således, at plads 1 får plads 2’s værdi, plads 2 får plads 3’s værdi
osv. Dette fortsætter indtil plads 119 får 120’s værdi. Derefter lagres den nyeste temperatur på plads
120 og forskellen mellem den ældste og den nyeste værdi findes. Hvis der er et tilstrækkelig stort
fald i temperaturen fra første til sidste værdi er vinduet åbent. Hvis der var tale om registrering af
lukning skulle vinduet registreres som lukket, når der sker en tilstrækkeligt stort temperaturstigning.
Opvarmningstestmodulet
Opvarmningstesten skal undersøge om en opvarmning foregår med åbent eller lukket vindue. Den
bliver kun kaldt når opvarmningen har kørt testtiden på 100 sekunder. Først beregnes den teoretiske
temperatur der burde være ifølge den matematiske model. Denne temperatur beregnes udfra den
matematiske model ved tiden 100 sekunder hvortil der lægges arbejdspunktstemperaturen. Dernæst
undersøges om den teoretiske temperatur er større den virkelige temperatur, og hvis den er det, så er
vinduet stadig åbent. Hvis dette er tilfældet initialiseres vinduetest-tabelen til den nuværende
Side 41 af 113

Regulering
indetemperatur. Dette gøres som tidligere nævnt idet vinduestesten ellers ville finde en stigning fra
den først til den sidste værdi således, at vinduet igen ville blive registeret som lukket.
Side 42 af 113

Regulering
Computermodel
Ved udvikling af computermodellen tages der udgangspunkt i den matematiske model, men i
stedet for at løse differentialligningerne analytisk bruger computeren ”brute force” til at løse
problemerne, det vil sige computeren simulerer forløbet, ved at gennemføre iterative beregninger.
Simuleringen beregner først varmemængden ved start på simulationen. Derefter kører den en
løkke som modificerer varmemængden med effekt-bidrag, som beskrevet i den matematiske model
(afsnit 2.3). Under hver kørsel af løkken beregnes en ny indetemperatur, og relevante data udskrives
til skærmen.
Udover den funktionalitet, som er beskrevet ved ovenstående kode-udsnit, indeholder programmet
mulighed for at specificere startbetingelser, gemme data på disk med tidsbestemte intervaller og
afbryde under kørslen. For detaljer om implementationen af disse muligheder henvises til bilag
”kode”.
Simuleringsprogrammet skal kunne simulere de forskellige problemstillinger, som reguleringsalgoritmerne
skal tage højde for. Dette gøres så simpelt som muligt for ikke at skabe unyttige
forstyrrelser i programmet. En vinduesåbning simuleres gennem en forringelse af vinduets isolans
og en lukning af vinduet ved en genskabelse af vinduets oprindelige isolans. Derudover indsættes
der en lille forøgelse af effekttilførslen i kortere tid, for at simulere varmeafgivelsen fra væggene.
4.4 Implementation af computermodel og regulering
Selve implementationen i C++ kode er foregået med top-down metoden. Dette vil sige, at først
blev computermodellen programmeret først og gennemtestet. Derefter blev reguleringsmodulet
implementeret og den blev benyttet som platform for de øvrige undermoduler der blev
implementeret efterhånden. Der har altså hele tiden været et fungerende program som efterhånden
blev udbygget mere og mere med de forskellige reguleringsdele, for til sidst, at danne det færdige
program.
For at reguleringen fra gang til gang kan ”huske” de forskellige tilstande, som f.eks. om vinduet er
åbent eller lukket, er de fleste variable blevet deklareret for statiske. Det betyder at når
reguleringsfunktionen forlades, gemmes de statiske variables værdier.
Under implementationen blev computersimulationen udbygget med et array, der sørger for at
forsinke effekten fra reguleringen således, at der tages højde for, at der er en tidsforsinkelse i
radiatorens effektafgivelse. Dermed blev computersimulationen gjort mere virkelighedstro. Selve
forsinkelsen blev designes på samme vis som temperaturarrayet blev i vinduetest.
Side 43 af 113

4.5 Test
Regulering
For at vurdere om computermodellen er tilstrækkelig præcis som simulationsprogram på baggrund
af den fysiske model, er der blevet udført en simulering uden reguleringen indsat(se fig. 3.8).
Simulationen startes med ude- og indetemperatur på 20 grader og effekten 35 watt, samt
udskrivning til fil hver 10’ende sekund. Efter 4000 sekunder simuleres et åbent vindue og efter
7000 sekunder simuleres et lukket.
Figur 4.6 – Graf over en simulation i computermodellen over åbning og lukning af vindue.
Hvis fig. 4.8 sammenholdes med fig. 4.2 og 4.3 der er forsøgsgrafer fra den fysiske model ses det
at det er er god overensstemmelse mellem simuleringen af åbning og lukning af vindue og åbning
og lukning i den fysiske model. Værdien ved tidskonstanten og slutværdien for simulationen kan,
jvf. 2.4.1, beregnes på følgende vis:
Slutværdi = (effekt ⋅ 0.836) + Startværdi ⇔
Slutværdi = (35 ⋅ 0.836) + 20 = 50 (4.6)
Tidskonstantværdi = Slutværdi ⋅ 0.63 ⇔
Tidskonstantværdi = 50 ⋅ 0.63 ≈ 38 (4.7)
Hvis slutværdien og værdien ved tidskonstanten aflæses ses de til ca. at være henholdsvis 50 °C og
38 °C, hvilket svare helt overens med de beregnede værdier. Computermodellen kan hermed
opfylde sit formål (jvf. 3.0), som er at give mulighed for at afprøve forskellige
reguleringsmekanismer i modellen for, at vurdere deres effektivitet.
Reguleringen er blevet løbende testet i simulationsprogrammet, hvorved fejl og mangler kunne
rettes efterhånden som implementationen skred frem. Slutteligt er der blevet foretaget en række test.
for at undersøge, hvorvidt reguleringen lever op til de krav der blev stillet i 1.5.2. Første krav var at
reguleringen på baggrund af temperaturen skulle være i stand til at detektere åbning og lukning af
vindue. Figur 3.9 viser testresultaterne fra en simulering hvor inde- og udetemperaturen startes ved
20 grader og vinduet lukket. Der tages målinger hver 10 sekund. De første 100 sekunder køres der
opvarmningstest og denne konstaterede korrekt, at vinduet er lukket så opvarmningen fortsættes.
Termostatfunktionen træder derefter i kraft og sætte fuld effekt på, til den ønskede temperatur på 50
grader er opnået. Ved måling 500 simuleres en åbning af vinduet og ved 800 simuleres en lukning.
Side 44 af 113

Regulering
Den simulerede åbning registreres omkring måling 500 som den skal og der slukkes for effekten.
Ved måling 800 registreres en mulig lukning og en testopvarmning sættes i gang. Ved måling 810
konstaterer testen at vinduet er lukket og reguleringen sættes på og den ønskede temperatur opnås
igen.
Figur 4.7 – Forsøgsresultater fra simulering af åbning og lukning af vindue med regulering.
Det ses at reguleringen er i stand til at registrere åbning og lukning af vindue og reagere på
baggrund deraf. Krav 1 er altså opfyldt
For at undersøge om termostatfunktionen og natsænkningen fungerer blev følgende forsøg udført
(se fig. 4.10), hvor der tages målinger hver 10 sekund. Ude- og indetemperatur begynder ved 20
grader og stiger til 50 grader. Ved måling 250 sekunder indsættes en ekstra effektkilde på 10 watt
og den fjernes igen ved måling 400. Ved 500 påbegyndes natsækning til 35 grader som stoppes igen
ved måling 1000. Under natsænkningen indsættes der en effektkilde på –10 watt fra måling 600 til
700. Reguleringen reagerer som den skal på den ekstra effektkilde ved at sænke effekten med ca. 10
watt og holder derved temperaturen næsten konstant. Når natsækningen begynder sørger
reguleringen for at sænke temperaturen så hurtigt så muligt ved at sætte effekten lig 0 for derefter at
opretholde den ønskede nattemperatur. Effekttabet fra måling 600 til 700 tages ligeledes højde for
gennem reguleringen. Når natsænkningen slutter ved 1000 reguleres igen ind til den ønskede
dagtemperatur.
Side 45 af 113

Regulering
Figur 4.8 – Forsøgsresultater fra simulering af natsænkning og termostatfunktion.
Det ses at termostatfunktionen sænker effekten med ca. 10 watt når der indsættes en ekstra
effektkilde på 10 watt og forhøjre med 10 når der indsættes –10 watt. og holder derved
temperaturen konstant. Derved ses det at krav 2 og 3 fra 3.5.1 omkring natsænkning og regulering
er opfyldt tilfredsstillende.
Side 46 af 113

5.0 Hardwareløsningen
Hardwareløsning
For at kunne vise princippet i embedded technology, har vi valgt at bygge et hardware system
bestående af MCU (Micro Controller Unit) med tilhørende hukommelse og analoge kredsløb til
måling af temperaturer og regulering af effekt. Dette kapitel beskæftiger sig med fremstillingen af
denne hardwareløsning.
Der vil i dette afsnit blive gennemgående brugt nogle vigtige tekniske betegnelser. Disse vil kort
blive beskrevet her:
− En byte, bestående af 8 bit. Er den mindste enhed der opereres med i en MCU.
− Hukommelse. Her skelnes mellem to forskellige typer af hukommelse, data og program. Data
vil typisk ligge i en RAM kreds og vil blive slettet ved at forsyningsspændingen fjernes.
Program vil ligge i en EPROM (Eraseable Program Read Only Memory), dette er selve
programmet og vil ikke kunne ændres eller slettes af MCU’en.
− Hvis et signal er inverteret, vil det sige der er byttet om på logisk høj og lav, dvs. at en høj
spænding på et inverteret signal svarer til et binært 0. Dette er markeret med en streg over
forkortelsen.
5.1 Behovsanalyse for hardwareløsningen
Vi vil her analysere hvilke krav, som det givne stykke hardware må opfylde. Vi har følgende
overordnede krav fra problemanalysen (jvf. 2.7)
− En elektronisk løsning der autonomt kan regulere en radiator.
− Et netværk mellem den elektroniske løsning og en computer.
− Et stykke software til pc, som agerer grænseflade mellem brugeren og det elektroniske
system.
Herudaf kan vi se, at der stilles følgende krav til hardwareløsningen:
1. Den skal kunne regulere effekttilførslen til en radiator.
2. Den skal være i stand til at kommunikere med en PC.
Derudover kan vi på baggrund kapitlet om regulering tilføje følgende krav:
3. Den skal kunne måle to forskellige temperaturer.
4. Den skal have tilstrækkelig datakraft til at udføre de beregninger, som
reguleringsalgoritmen kræver.
Følgende vil vi beskrive hvordan vi har valgt at imødekomme disse krav. De enkelte hardwaredele
som her beskrives, vil blive uddybet nærmere under gennemgangen af design af løsningen.
Kravet om datakraft
For at opnå den fornødne datakraft, har vi valgt at bruge en Micro Controller Unit (MCU) af typen
80C535, som er produceret af Siemens. En MCU er en integreret kreds, som indeholder en Central
Side 47 af 113

Hardwareløsning
Processing Unit (CPU), samt en række periferi-enheder til løsning af diverse opgaver som f.eks.
seriel kommunikation eller analog til digital konvertering.
Denne MCU, som er en videreudvikling af den meget brugte 8051 fra INTEL, udmærker sig
specielt i forhold til andre 8-bits MCU’er ved at indeholde instruktioner til brug ved multiplikation
og division, hvilket er funktioner, som bruges indgående i reguleringsalgoritmen (jvf. 4.2)
For at kunne bruge MCU’en er det nødvendigt at forbinde den med ekstern hukommelse i form af
både ROM og RAM.
Kravet om kommunikation med PC
Den valgte MCU indeholder en periferie-enhed til seriel kommunikation. Brug af denne beskrives
udførligt i kapitlet om seriel kommunikation.
Kravet om effekt-regulering
MCU’en giver mulighed for at regulere en spænding mellem 0-5V ved hjælp af puls-breddemodulation
(beskrives i afsnit ”MCU-software”. Vha. af en transistor af typen MOSFET 5 og en
ekstern spændingskilde vil vi blive i stand til at regulere en vilkårlig stor spænding, afhængig af den
eksterne spændingsforsyning, og derved bliver det muligt, at styre effekt-afgivelsen i radiatoren.
Måling af temperaturer
Der findes specielle kredsløb til måling af temperaturer. En løsning er at bruge en LM35DZ, som
er en integreret kreds til måling af temperatur. Denne kreds har en udgangsspænding, der hænger
lineært sammen med den omgivende temperatur. Da disse sensorer kun har en udgangsspænding på
0 til 500 mV er det nødvendigt at forstærke signalet, tilpas til at MCU’ens analog til digital
konverter kan gennemføre konverteringen. Dette vælger vi at gøre med operationsforstærkere.
Det temperaturområde, som der skal måles i, er begrænset til området mellem 10 – 60°C, da
hardwareløsningen produceres med henblik på den fysiske model.
5.1.2 Overordnet løsningsskitse
På baggrund overvejelserne gjort i sidste afsnit
er der i fig. 5.1, opstillet en skitse af
hardwareløsningen, som viser de enkelte dele og
deres relative placering.
Vi har valgt at placere MCU’en og dens
tilhørende komponenter på et print, som herefter
kaldes for Single Board Computer (SBC).
Komponenterne til effektregulering og måling af
temperatur er placeret på et separat print.
Strømforsyningen, som er placeret på det
analoge print, skal levere passende spændinger til
de enkelte kredsløb.
Komponenten MAX232 er nødvendig for at
konvertere MCU’ens serielle signaler til et andet
spændingsniveau, som lever op til RS-232
standarden for seriel kommunikation (jvf. x.1.1).
5 En MOSFET er en effekttransistor.
Side 48 af 113
Analog print
Temperatur-
sensor ude
Forstærker
Temperatur-
sensor inde
Forstærker
Strøm-
forsyning
Effekttrin
Radiator
MCU
80C535
Single Board Computer
MAX232
Figur 5.1 - Hardwareløsningen kan samles
på to print. Et til MCU og et til analog delen.
PC
RAM
ROM

5.2 Design af hardwareløsning
Hardwareløsning
På baggrund af behovsanalysen, og den opstillede skitse af hardwareløsningen, vil vi i dette afsnit
beskrive designet af de enkelte dele og deres sammensætning.
5.2.1 SBC – Single board computer
I dette afsnit beskrives designet af SBC’en, under gennemgangen beskrives først begreber og
kredsløb, som knytter sig til MCU’ens brug af den eksterne hukommelse. Herefter beskrives de
andre kredsløb som med førnævnte tilsammen udgør SBC’en. For yderligere information, omkring
MCU’en henvises til dens databog [Siemens].
Clock-frekvens
MCU’en behøver et pulserende signal fra en krystal, for at kunne udføre operationer. Den valgte
type MCU forsynes typisk med en clock-frekvens på mellem 1 - 12MHz og vi har valgt en krystal
på 12 MHz. Denne clock-frekvens er som tidligere nævnt valgt, da den er specielt velegnet til brug i
forbindelse med seriel kommunikation, og desuden resulterer en højere clock-frekvens i en større
datakraft.
En machine cycles består af 12 clockpulser og dette betyder at ved 12MHz er en machine cycle 1
µs lang. En machine cycle er den tid MCU er om at udfører de mindste udregninger. Dette betyder
at med en clock-frekvens på 12MHz regner MCU med en hastighed af 1MHz.
Databus
Databussen er det sæt af forbindelser mellem MCU og den eksterne hukommelse hvori de data,
der sendes mellem førnævnte enheder transmitteres. Databussen på MCU’en er 8 bit bred, dvs. den
består af 8 forbindelser. Selve bussen består af port 6 0, som også bruges til adressebussens
mindstbetydende bits (0-7), så det er nødvendigt at skelne disse to fra hinanden ved hjælp af en
latch (beskrevet senere).
Adressebus
Adressebussen er ligeledes som databussen en gruppe af forbindelser på printet. Adressebussen
fortæller RAM og ROM, hvor i hukommelsen databussen enten skal modtage eller sende data fra
eller til.
MCU’en kan adressere op til 64kB vha. 16 adresse bit. Adressebussen realiseres ved at port 0
fungerer som de laveste adresser, og port 2 som de højeste.
Kontrolbus
Denne bus fortæller hukommelsen, hvilken type af hukommelse der skal reagere, og om der skal
læses eller skrives til den pågældende hukommelseskreds.
Kontrolbussen består af følgende signaler:
WR : Write. Bruges til at fortælle hukommelsen, at der nu skal skrives til den.
RD : Read. Bruges til at fortælle hukommelsen, at der nu skal læses i den.
PSEN : Program Store Enable. Bruges til at fortælle, at det er ROM der skal læses fra. MCU’en
kan ikke skrive i hukommelse, der aktiveres af dette signal.
6 De ben på MCU’en som står for at sende og modtage data, grupperes i grupper på 8, som hver kaldes for en port.
Side 49 af 113

Hardwareløsning
Latch
MCU’en benytter, ligesom Intels 8051, en multiplexed 7 data og adresse bus. For at skelne imellem
hvilke signaler, som hører til adressebussen og hvilke der hører til databussen, benyttes en latch af
typen 74HC573N.
I praksis betyder dette, at dataene stadigvæk findes på port 0, mens den laveste adresse-byte nu
findes på udgangen af 74HC573N.
Adresse byten på latchen opdateres fra MCU’en ved at MCU’en sætter kontrolsignalet ALE
(Adress Latch Enable), hvorefter latchen
læser værdien på port 0 og kopierer denne
værdi på sine egne udgange. Herefter sletter
MCU’en ALE-signalet, hvorefter værdien på
port 0 igen opfattes som databussen.
Dette giver mulighed for at sende både en
data- og en adressebyte på kun en port. Der
bliver derfor alt i alt overført 16 bit
information over kun 9 ben på MCU’en.
Implementeringen af 74HC573 ses på fig. 5.3.
Figur 5.2 – Diagram for latch-kredsløbet. Latchen læser den
nederste adressebusbyte fra MCU’ens port 0, når ALEsignalet
er højt.
Hukommelse
For at MCU’en skal kunne fungere er det
nødvendigt med hukommelse, da denne indeholder dels den programkode, som MCU’en skal
udføre og dels de variable som den skal arbejde på. Der skelnes her mellem to typer: ROM og
RAM.
ROM
Denne type af hukommelse skal programmeres på forhånd og kan ikke ændres eller slettes af
MCU’en. Det er i denne type af hukommelse at selve programkoden er placeret. Der bruges
EPROM af typen 27C512, hvilket giver 64kB program hukommelse.
En EPROM af typen 27C512 behøver, udover forbindelse til adresse og data bus, nogle
kontrolsignaler. Disse kontrol signaler skal fortælle EPROM om den skal være aktiv og om der skal
komme data ud på data bussen. Der bruges to kontrol signaler til 27C512: CE (chip enable) og OE
(output enable). Disse to skal begge to være logisk lav, når MCU’en ønsker data fra EPROM, derfor
kan PSEN sættes direkte til dem begge.
RAM
Er den hukommelse, som MCU’en skal lægge sine variabler og indsamlede data i. MCU’en har
512 bytes indbygget RAM. Opgaven stiller dog større krav til mængden af RAM. Derfor har vi
valgt at forsyne SBC-printet med en 20256, der giver os 32kB RAM. Der kræves flere
kontrolsignaler til RAM, end ROM. Dette skyldes at RAM-kredsen skal vide hvorvidt der skal
skrives eller læses i den. Der bruges i alt 3 kontrol signaler til RAM af typen 20256: WE (Write
Enable), OE (Output Enable) og CE (Chip Enable).
CE skal fortælle kredsen om den skal være aktiv. Dette signal har vi forbundet til adresse bit 15 8 ,
som altid er lavt ved adressering i de første 32kB. Derved bruges A15 til at aktiverer RAM. RAM
kredsen reagerer kun når CE er aktiv, samtidig med WE eller OE .
7 Dvs. at de samme udgange bruges til flere funktioner.
8 Dvs. den 16’ende bit.
Side 50 af 113

Hardwareløsning
OE virker som for ROM, fortæller om kredsen skal sende data til databussen fra den af
adressebussen angivne adresse. Dette signal er forbindet til kontrolbussens RD signal, der angiver
om der skal læses fra hukommelsen.
WE dette signal fortæller kredsen, at den data der er på databussen skal gemmes i den adresse der
er på adressebussen. Dette udføres dog kun hvisCE er aktiv. WE er forbundet til kontrolbussens
WR signal.
Reset-kredsløb
For at beskytte MCU’en mod
elektrisk støj i det øjeblik der
skabes et spændingsfald over den,
og for at give MCU’en tid til at
gennemføre et fuldt reset vi valgt
at lave et RC kredsløb (se fig.
5.3). Dette RC led er tilsluttet på
sådan en måde, at ved tilsluttet
forsyningsspænding vil
kondensatoren C5 lade op
begrænset af resistoren R8,
Figur 5.3 - Krystallet, X1, generer den nødvendige frekvens for at
MCU’en kan fungerer. RC leddet, der består af R8 og C5 ,laver "power
on reset".
hvorved forsyningsspændingen til MCU’en stiger jævnt til 5V. Desuden kan MCU’en genstartes
manuelt ved at kortsluttes gennem kondensatoren C5 vha. kontakten SW1.
Seriel interface
Den indbyggede serielle port på MCU benytter TTL-spændingsniveauer (0 til 5 Volt). Disse skal
(jvf. 5.1.2) omdannes til det spændingsniveau, som er specificeret af RS-232 standarden for seriel
kommunikation (+/-12V). For at omdanne disse niveauer benytter vi kredsen MAX232, der behøver
tilslutning til fire kondensatorer (jvf. "datablad") for at omdanne disse niveauer. Fordelen ved denne
kreds, er at vi ikke behøver en separat spændings forsyning på ± 12 Volt.
5.2.2 Analog print
Følgende gennemgås de forskellige teori om og design af de forskellige analoge kredsløb, som er
placeret på ”det analoge” print.
Temperaturmåling
Til måling af temperaturen både inde og ude benyttes to temperatursensorer af typen LM35. Disse
skal have en forsyningsspænding på mellem 4 og 20V. På diagrammet for hele det analoge kredsløb
(se bilag nr. ?), ses ben nr. 1, som er der hvor indgangsspændingen skal føres ind.
Udgangsspændingen (ben nr. 3) på temperatursensoren er 10mV/°C, dvs. at udgangsspændingen er
lineær afhængig af temperaturen.
Side 51 af 113

Forstærkning
Som beskrevet i tidligere (jvf. 5.1) er
udgangssignalet fra temperatursensorerne 0 –
500mV, men da analog til digital konverteren
skal bruge en spænding på 0 – 5V, vil det
betyde at en forstærkning på 10 gange er
nødvendig for at kunne konvertere signalet.
Til det bruger vi en operationsforstærker (Op
Amp).
Hardwareløsning
En operationsforstærker, forstærker i sig
selv flere 1000 gange. For at få den ønskede
forstærkning på 10 gange, bruges
modkoblings teknik.
Det der bliver forstærket i en Op Amp er
forskellen mellem + og – indgangene. Ved at
gøre den ene indgang afhængig af
udgangssignalet er der mulighed for at
Figur 5.4 – Operationsforstærker med modkobling.
regulerer forstærkningen. Dette er det der
kaldes for modkoblingsteknik.
Som det ses på fig. 5.5 er en del af udgangssignalet ført tilbage til den inverterede indgang, via en
spændingsdeler (Rm og Rn). Når der kommer spænding på Vin vil denne blive forstærket og komme
ud på Vout. Denne udgangsspænding vil blive delt i spændingsdeleren, og en del vil komme ind på
den inverterede indgang, derved vil spændingsforskellen mellem + og – indgangene blive mindre
og dermed vil udgangsspændingen falde. Ved at varierer forholdet mellem Rm og Rn er det muligt at
justerer forstærkningen.
Spændingsforstærkningen (Av) for en ikke-inverterende kobling beregnes som følgende:
⎛ Rm
⎞
A
⎜
⎟
V = + 1
⎝ Rn
⎠
Der vælges en modstand Rn til 1kΩ og da der ønskes en spændingsforstærkning på 10 gange, kan
modstanden Rm beregnes til følgende:
Rm = (A’-1)·Rn
Rm = (10-1)·1kΩ = 9kΩ
Da der skal bruges en meget presis forstærkning og mulighed for at kunne justerer denne, bruges en
multiturn potentiometer til Rm.
Side 52 af 113

Hardwareløsning
Effektregulering
Ved at benytte Timer 2 til generering af PBM, fås
et udgangssignal på 0 eller 5V fra MCU. Disse
pulser skal føre til en afsat effekt i en radiator,
mellem 0 og 50W. MCU’en kan klare at blive
belastet med 80µA, derfor er det nødvendigt at
forstærke pulsen.
Når pulsen går høj skal transistoren åbne hurtigt, da
der ellers vil blive afsat meget effekt i transistoren,
som vil medfører, at den vil brænde af. Derfor
benyttes her en MOSFET af typen BUZ90.
Fordelene ved at benytte en FET er at
indgangsimpedansen er stor, og derfor vil der ikke
blive trukket stor strøm fra MCU’en. En anden vigtig
fordel er, at en FET er meget hurtig. Det er vigtigt at Figur 5.5 – Effektregulering med PBM.
transistoren er hurtig, fordi at mellem de to yderpunkter afsættes der effekt i transistoren. De to
yderpunkter er henholdsvis 0 og 5 V på gate.
Da BUZ90 ikke har en indbygget beskyttelses diode sættes en modstand på 1MΩ mellem gate og
source, for at beskytte mod statisk elektricitet.
Selve opstillingen med BUZ90 ses på fig. 5.5.
Af databladet fremgår det at ved et input til gate på 5 V, er den indre modstand mellem drain og
source ca. 2,5 Ohm. Dette betyder at der afsættes en effekt i selve transistoren, som gør at den bliver
varm, derfor monteres en køleplade som kan aftage den effekt.
Strømforsyning
Der skal bruges 5V til SBC’en og temperatursensorerne, og der benyttes 12V og –5v til
operationsforstærkerne.
For at skabe disse spændingsnivauer benyttes spændingsregulatorer af typerne 78XX og 79XX.
XX angiver hvilken spænding regulatoren vil give. Typen 78XX vil give en positiv
udgangsspænding og 79XX vil give en negativ udgangsspænding.
For at få den ønskede forsyningsspænding, skal der tilføres en spænding på indgangen på mindst
2V over det ønskede udgangsspænding.
På diagrammet (se fig. 5.6) for spændingsregulatoren ses nogle kondensatorer der er ført til jord
(GND). Kondensatorerne er til for at fjerne elektrisk støj og for at forhindre spændingsregulatoren i
at gå i selvsving, hvilket kan fører til, at den brænder af.
Figur 5.6 - Diagram for spændingsforsyning.
Side 53 af 113

5.3 Implementation og test
Hardwareløsning
Selve implementationen designet kan ses på bilag x.x.x og bilag x.x.x, hvor diagrammerne for de
to print er gengivet.
For at teste SBC’en har vi programmeret simple programmer, som er brændt i en EPROM,
hvorefter disse er kørt på MCU’en. Kontrol af programudførelsen er sket ved at måle på de enkelte
ben ved hjælp af et oscilloskop. Disse testprogrammer indfattede bl.a.:
− Tael. Program der tæller op på portene 1, 4 og 5. På den laveste bit skal pulserne være
hurtigst og frekvensen halveres når der gås en bit op. Dette giver mulighed for at måle på
portene om MCU, ROM og Latch virker.
− All_1. Program der sætter alle port ben til logisk høj. Dette giver mulighed for at måle på
portene om MCU, ROM og Latch virker.
− All_0. Program der sætter alle port ben til logisk lav. Dette giver mulighed for at måle på
portene om MCU, ROM og Latch virker.
− PWM. Et program der skal lave pulsbredde modulation. Denne test giver mulighed for at
teste Timer 2, MCU, Latch og ROM.
− Seriel. Program der kan modtage en byte serielt, MCU trækker en fra denne byte og sender
den tilbage. Dette giver mulighed for at teste serielt interface, seriel porten og opsætningen
af seriel porten.
Alle disse test programmer gør det muligt at teste om hardwaren virker efter hendsigten.
Disse tests ville i starten kun køre en lille tid, for derefter at starte forfra. Gruppen undersøgte
sagen, og det viste sig at Siemens har udviklet på 80C535. Denne udvikling har ført til at ben 4 (PE)
skal sættes til stel, ellers startes Watchdog timeren 9 automatisk og resetter MCU efter 65536 µs. I
databladet fremgår det, at ved brug af ”C” kredse skal ben 4 sættes til Vcc. Forskellen fremgår dog
af betegnelsen på selve kredsen, de nye kredse hedder SAB80C535N LB.
De enkelte kredsløb på det analoge print blev testet, ved at måle udgangssignalerne med et
voltmeter. Der startedes med spændingsregulatorerne, for at have en fast forsyning til de andre dele
inden disse kontrolleres.
For at kalibrere var fremgangsmåden at starte med temperatursensorerne, for derefter at kalibrer
forstærkerne. Denne rækkefølge var nødvendig for at have et realistisk og kendt indgangssignal til
Op Amp. Kalibreringen blev foretaget ved, at sætter den ene temperatursensor ned i vand ved 10°C
og derefter indstille udgangsspændingen til 0V. Derefter blev forstærkningen kalibreret til 10 gange.
Den anden temperatursensor blev kalibreret ved sammenligning med den første sensor.
Kalibreringen blev afslutte med at sætte sensorerne til MCU og aflæse den målte værdi. Endelig er
hele hardwareløsningen blevet løbende testet i forbindelse med udviklingen af software til seriel
kommunikation og MCU-software. Idet at softwaren løbende er blevet afprøvet på MCU’en og
outputtet heraf evalueret (Jvf. ”Ser-kom” og ”MCU-SW”).
Under test af det analoge print blev det klart, at effekt driver transistoren bliver meget varm. Den
påmonterede køleplades temperatur måltes til 50 grader. Dette, har vi fundet, skyldes 3 ting:
9 En watchdog timer er, som navnet antyder, en vagthund. Når den startes vil den tælle til 65536 og derefter resette
MCU. Den kan dog nulstilles ved at sætte et flag.
Side 54 af 113

Hardwareløsning
1. Indgangsspændingen på gate er maksimum 5 volt. Derved er den indre modstand mellem drain
og source ca. 2,5 Ohm. Radiatoren trækker en strøm på ca. 1,15 A og derved er effekt bidraget
til transistoren ca. 6 Watt.
2. Når transistoren skal skifte mellem ON og OFF (F.eks. ved Timer 2 overflow) afsættes der
effekt i transistoren. Dette skyldes at transistoren ikke er helt ON før der begynder at løbe strøm
til radiatoren.
3. Radiatoren er viklet som en spole, derved fås en spole virkning når der skiftes mellem tænd og
slukket. Dette gør, at ved et skift fra slukket til tænd vil spolen (radiatoren) trække en stor strøm,
men forsyningsspændingen vil stadigvæk ligge over transistoren. Derved afsættes der en spids
effekt på ca. 44 Watt i transistoren. Disse 44 Watt afsættes dog kun kortvarigt, men de afsættes
ved hver Timer 2 overflow.
At radiatoren virker som spole (3) kan der ikke umiddelbart gøres noget ved, dette ses der også
bort fra da det er en demomodel. Det skal dog huskes at den effekt der rent faktisk bliver afsat i
selve radiatoren er en smule mindre end den beregnede. Dette resulterer som sagt, i at FETtransistoren
bliver varm. Det fremgår af databladet at transistoren kan tåle at blive 150 grader varm,
derfor fremstilles ikke en praktisk løsning på problemet. Her følger teoretiske løsningsforslag på
problemer med effektdelen:
En løsning på 1 er at forstærke spændingen før den sættes ind på gate, derved mindskes den indre
modstand og effekten der afsættes i FET. For at mindske effektafsættelsen ved skift (2) kan
periodetiden nedsættes. Dette resulterer i færre skift og dermed mindre effekt afsat i transistoren.
Side 55 af 113

6.0 Seriel kommunikation
Seriel kommunikation
Vi vil i dette kapitel beskæftige os med at udvikle det software til både PC og MCU, som skal stå
for kommunikation mellem de to enheder. Vi har valgt at benytte seriel kommunikation, da det er
godt understøttet af både PC og MCU, desuden er det en simpel og veldokumenteret
kommunikationsform.
Inden vi påbegynder udviklingen vil vi præcisere de krav, som er opstillet i afsnit 2.6.1:
1. Det elektroniske system skal over forbindelsen til PC’en kunne:
a. Formidle dets status og rumtemperatur.
b. Modtage ønsket temperaturindstilling.
c. Modtage tidsramme for natsænkning
For softwaren til seriel kommunikation kan vi fra ovenstående præcisere følgende krav:
6.1 Analysefasen
2. Softwaren både til PC og MCU skal være i stand til både at sende og modtage data
serielt.
3. Dette skal kunne ske asynkront med at PC og MCU udfører andre opgaver, dvs.
den serielle software ikke må være afhængig af brugerprogrammet.
4. Softwaren skal kunne formidle data gennem forbindelsen uden fejl, men den skal
ikke kunne garantere, at der ikke kan opstå fejl, hvorfor klienter af de
transmitterede data, selv må vurdere dataenes gyldighed.
Vores system består af en MCU forbundet gennem en seriel forbindelse til en PC. Endvidere skal
der både på PC’en og MCU’en være et interface, kaldet en API 10 , til de applikationer, som kører på
systemet og skal benytte seriel kommunikation. Denne består af de funktioner, som applikationerne
kan kalde for at bruge seriel kommunikation.
Hver af disse elementer vil blive beskrevet i analysefasen, først beskrives seriel kommunikation
generelt, hvorefter der kigges på PC’ens hardware til håndtering af seriel kommunikation og
hvilken software, der skal fungere som API. Herefter beskrives ligeledes hardware og software til
seriel kommunikation på MCU’en.
6.1.1 Seriel kommunikation
Ved seriel kommunikation sendes eller modtages en bit ad gangen, f.eks. fra et modem til en
computer. I hver ende af forbindelsen bliver disse bit samlet i grupper af typisk 8 bit (en byte) og
sendes derefter videre til den enhed, som skal behandle dataene. Vi vil i dette afsnit koncentrere os
om de data, som sendes over forbindelsen, mens vi i senere afsnit vil se hvordan de bruges af
henholdsvis en PC og MCU.
En seriel forbindelse kan oprettes med kun to ledere, en til stel og en til signaler, men da det ofte er
ønskværdigt at kunne sende og modtage på samme tid, bruges der oftest tre ledere: En til stel
(forkortet GND), en til at sende (forkortet TxD) og en til at modtage (forkortet RxD). TxD- og
10 API: Applikation Programming Interface.
Side 55 af 113

Seriel kommunikation
RxD-lederne krydser hinanden i forbindelsen, sådan, at den ene endes sendeledning er forbundet
med den anden endes modtageledning. En sådan forbindelse, som kan sende og modtage på samme
tid, kaldes for en Full-Duplex forbindelse, mens en forbindelse som kun kan kommunikere en vej
ad gangen siges at være Half-Duplex.
RS-232 standarden
RS-232 er den mest udbredte standard for seriel kommunikation, hvorfor vi har valgt at benytte
denne. Standarden beskriver hvordan data, der sendes på forbindelsen skal fortolkes og hvordan
benene på de forskellige stik skal forbindes. Følgende er de vigtigste karakteristika behandlet, for
mere information henvises til [Peacock].
Signaler der sendes over forbindelsen opfattes som et binært 1,
hvis spændingen i lederen er mellem –3V til -15V og som et
binært 0 hvis spændingen ligger mellem 3V til 15V. Det
udefinerede område mellem –3V og 3V sikrer, at svage signaler
med lille spænding ikke forveksles.
Figur 6.1 – Skitse af D9-stik.
PC og MCU forbindes med et kabel med 9 forbindelser med et D9-stik (se fig. 6.1), dvs. D9 har 9
benforbindelser. På fig. 6.2, ses en oversigt over de forskellige forbindelser.
D-Type.
9 pin Nr.
Forkortelser Fulde navn Funktion
Pin 3 TxD Transmit data Seriel data output
Pin 2 RxD Receive data Seriel data input
Pin 7 RTS Request to send Angiver at modemet er klar til at bytte data
Pin 8 CTS Clear to send Når modemet modtager et signal fra modemet i den
anden ende går denne aktiv
Pin 6 DSR Data set ready Fortæller UART at den er klar til at etablere
forbindelse
Pin 5 SG Signal ground Fortæller at modemet er klar til at etablere
forbindelse
Pin 1 CD Carrier detect Informere modemet at UART er klar til at bytte data
Pin 4 DTR Data terminal
ready
Går aktiv, når modemet får signal fra telefonlinien
Pin 9 RI Ring indicator Modemet signalerer at det modtager et opkald.
Figur 6.2 – Figur som viser signaler og deres respektive benplaceringer og funktioner på et D9--stik.
Som det kan ses indeholder RS-232 standarden flere forbindelser end omtalt i afsnit 6.1 Disse
ekstra forbindelser kan bruges til at sende en række styresignaler, men de er ikke nødvendige for at
gennemføre seriel kommunikation. I stedet for at lade disse benforbindelser være udefinerede 11 ,
forbindes de som vist på fig. 6.3, hvilket sikrer, at PC’en ”tror”, at der er en forbindelse 12 , et kabel
der forbinder to enheder på denne måde kaldes et null-modem.
11 Dvs. de ikke er forbundet til noget.
12 Dette har relevans, hvis man vil teste porten fra et terminalprogram eller ligende. Men ikke for det software, som vi
udvikler til at styre kommunikationen.
Side 56 af 113

Seriel kommunikation
Baud-rate
For at kommunikere over forbindelsen skal
der specificeres en hastighed. Denne betegnes
baud–rate (udtales bo), og den specificerer hvor
mange bits, der sendes over forbindelsen pr.
sek. Det vil sige, at hvis forbindelsen er sat op
til f.eks. 110 baud, vil det tage 1/110s at sende
en bit. Typiske baud - rates ved
kommunikation med MCU’er er: 110, 150,
300, 1200, 2400, 4800 og 9600 baud. Figur 6.3 – Tilslutning af benforbindelser på D9, når
ekstra styresignaler ikke ønskes benyttes[Peacock].
Start-, stop- og databit
Når en enhed sender en karakter (typisk 8 bit) sender den først en start-bit, som fortæller
modtageren, at der følger data. Ligeledes efter transmission af dataene sendes, der en stop-bit for at
markere afslutningen på transmissionen (se fig. 6.4.). Startbitten er binært 0, og stop bitten er binært
1. Normalt udgør databittene 8 bit,
men det er muligt med andre
konfigurationer, ligesom det er muligt
at ændre antallet af stop-bits til 2.
Figur 6.4 – Transmission af en byte m. start- og stopbit. Hver
firkant tager 1/Baud-rate sekunder at sende. [Peacock].
Paritet
RS-232 standarden giver også mulighed for brug af op til tre paritetsbit. Disse bit beskriver om
den sendte karakter har et lige eller ulige antal binære 1 taller. Hermed er der mulighed for at
detektere om, der er opstået fejl i transmissionen. Fejl kan opstå som følge af elektronisk støj, eller
hvis kablet er så langt, at spændingsfaldet er tilstrækkeligt til at forstyrre signalet.
Opsætning af forbindelse
Vi har valgt at bruge en meget simpel opsætning uden paritet, hvilket medfører, at der ikke er
mulighed for detektion af fejl opstået pga. af støj i lederne. Derfor må softwaren, som bruger
dataene, selv vurdere hvorvidt dataene er sandsynlige og evt. bede om en retransmission. Endvidere
har vi valgt en baud rate på 9600 baud, fordi den valgte MCU kan genere netop denne baud-rate
uden brug af timerenhed. Alt i alt ser vores opsætning ud som følger:
6.1.2 PC-UART
- 9600 baud
- 8 databit
- Ingen paritet
- Én start og én stop bit
Processoren i PC'en kommunikerer ikke direkte gennem den serielle forbindelse, dette sker i stedet
ved hjælp af en UART 13 , som er en chip monteret på bundkortet i computeren 14 . Denne chip
kontrolleres af processoren gennem en række af registre, som er placeret i det specielle område af
hukommelsen som Intel kompatible processorer bruger til kommunikation med perifere enheder
[Intel]. I alt har UART’en 8 af disse registre (oversigt på fig. 6.5), men vi vil her kun gennemgå de
for os relevante, yderligere information kan hentes i databladet for en TLC16450 [Texas].
13 Universal Asynchronous Receiver Transmitter
14 Eller evt. som en integreret del af bundkortets øvrige kredse.
Side 57 af 113

Seriel kommunikation
Register nr. Beskrivelse
0 Transmitter/Receive-buffer / Divisor latch low byte
1 Interrupt enable register / Divisor latch high byte
2 Interrupt identifikation register/ FIFO control register
3 Line control register
4 Modem control register
5 Line status register
6 Modem status register
7 Scratch register
Figur 6.5 – Oversigt over UART’ens registre.
UART’ens placering i hukommelsen kan variere fra system til system, men det er fast standard at
adressen på register nr. 0 (jvf. fig. 6.5) kan læses i BIOS dataområde på adresse 0000:0400h 15 . Den
adresse, der læses her, vil vi efterfølgende kalde for kommunikationsportens basisadresse. De andre
af UART’ens registre har adresserne basisadresse+register nr. Der opnås adgang til disse registre
ved brug af funktionerne inportb (adresse) og outportb (adresse, data) som findes i headerfilen
dos.h, disse to funktioner giver adgang til det før omtalte input-/outputområde i processorens
adresserum. Følgende beskrives de væsentligste af UART’ens registre.
Register 0: Transmitter-/receivebuffer
Dette register er i virkeligheden to fysiske adskilte registre. Hvis der læses fra registret, læses den
byte, som er modtaget gennem den serielle forbindelse, og hvis der skrives til registret vil den byte
der skrives sendes gennem den serielle forbindelse. Da de to registre er fysisk adskilte, kan der både
modtages og sendes data samtidigt. I det øjeblik der skrives til dette register, vil UART’en
påbegynde at sende den skrevne byte gennem forbindelsen.
Register 1: Interrupt enable
Dette register bestemmer hvornår UART’en skal generere et interrupt 16 . Et binært 1 i bit 0 bevirker,
at UART’en genererer et interrupt, hver gang den har modtaget en byte data.
Register 0 og 1: Divisor latch
De to registre har til sammen en anden funktion når bit 7 i register 3 sættes til 1. Når denne bit er 1
kan der til register 0 og 1 skrives den 16 bits værdi, som bruges til at genere den ønskede baud-rate.
Dette sker i samarbejde med en ekstern oscillerende krystal, som giver UART’en et signal med en
fast frekvens. Denne frekvens deles med det tal der skrives i register 0 og 1. Herved generes
UART’ens arbejdsfrekvens og dermed også baud-raten. For kommunikation med 9600 baud skal
register 0 indeholde 0Ch og register 1 skal indeholde 00h.
Det skal bemærkes, at i det øjeblik bit 7 i register 3 sættes til 1 bliver data sendt til register 0 og 1
omdirigeret til et internt register i UART’en, der er altså igen tale om et fysisk separat register.
15 ’h’ angiver at tallet er angivet i det hexadecimale talsystem.
16 Interrupts diskuteres i afsnit 1.1.3
Side 58 af 113

Register 3: Line control
Dette register bestemmer hvilket
format de serielle data skal have.
Bit 0 og bit 1 bestemmer hvor
mange databit der skal sendes ad
gangen. I vores tilfælde sættes
begge bits til 1 for at opnå 8
databits.
Bit 2 bestemmer antallet af stop
bits, som i vores tilfælde er 1
svarende til at bitten sættes til 1.
Seriel kommunikation
Bit nr. Funktion
7 1: Register 0&1 giver adgang til baud-rate registret.
0: Register 0&1 fungerer normalt.
6 Ingen betydning her.
5,4,3 Paritetskontrol (0,0,0 svarer til ingen paritetskontrol)
2 1: 2 stop bit
0: 1 stop bit
1,0 Antal databit (1,1 giver 8 databit)
Figur 6.6 – Oversigt over Line Control registret.
Bit 3,4,5 bestemmer hvordan paritet skal fortolkes, vi sætter alle bittene til 0, hvorved paritet ikke
bruges.
Desuden, som før omtalt, bestemmer bit 7 om register 0 og 1 fungerer normalt, eller om skrive
instruktioner til dem resulterer i en ændring af baud-raten (Register oversigt på fig. 6.6).
Register 5: Line status
Dette register indeholder information om status på forbindelsen. Interessant for os er bit 0, som
angiver hvorvidt der er data klar i register 0 eller ej. Når der læses fra register 0, sættes bit 0 i
register 5 automatisk til 0. Denne bit kontrolleres derfor for et binært 1, inden man læser den
modtagene byte fra register 0.
6.1.3 PC-Interruptsystemet
Hvis processoren i en PC hele tiden skulle kontrollere om der er en nyt data tilgængelig fra
UART’en, vil en substantiel del processorens ressourcer bruges på denne opgave. For at undgå dette
benyttes interrupts. I dette afsnit forklares hvad interrupts er og hvordan de benyttes i Intelarkitekturen
17 .
Interrupts giver eksterne enheder mulighed for at signalere til processoren, at en eller anden
begivenhed er indtruffet. Når processoren modtager dette signal vil den afslutte den igangværende
instruktion, gemme værdierne af de interne registre i hukommelsen, og fortsætte programudførelsen
fra et sted i hukommelsen, hvor der er placeret software til behandling af denne type begivenhed.
Når softwaren har afsluttet sin behandling giver den signal til processoren om at interruptet er
afsluttet, hvorved processoren henter indholdet af sine registre tilbage og fortsætter
programudførelsen fra det sted hvor interruptet indtraf.
17 Det var Intel som oprindeligt udviklede 8051 serien af microcontrollere.
Side 59 af 113

Seriel kommunikation
Intel kompatible processorer (80x86) har 256 mulige
interruptkilder, men det er kun 16 af dem, som bruges med
ekstern hardware. Den eksterne hardware er ikke direkte
forbundet til processoren, som kun har et ben til interrupt
identifikation, men går i stedet igennem en PIC 18 -kreds. Når
PIC-kredsen modtager et interrupt signal fra en enhed
signalerer den et interrupt til processoren. Når processoren
modtager dette signal afslutter den igangværende instruktion,
hvorefter den signalerer til PIC-kredsen, at den er klar til at
behandle interruptet. Herefter placerer PIC-kredsen nummeret
på interruptkilden (se figur 6.7) på processorens databus.
Processoren læser dette nummer og bestemmer på baggrund
heraf hvor i hukommelsen den skal fortsætte
programudførelsen.
Vi er interesseret i interrupt nr. 4, fordi det via UART’en kan
genere interrupts når der modtages en ny databyte gennem
kommunikationsport 1. Desuden er vi interesseret i interrupt nr.
Interrupt nr. Interruptkilde
0 System timer
1 Tastatur
2
3 Seriel porte 2 og 4
4 Seriel porte 1 og 3
5 Lydkort
6 Floppy disk
7 Parallel porten
8 Realtidsur
9
10
11
12 Mus
13 Matematisk processor
14 Hard-disk
15
Figur 6.7 – Oversigt over de forskellige
hardware interrupts.
0, som generer et interrupt for hver 55ms, da dette interrupt kan bruges til med jævne mellemrum at
kontrollere om brugerprgrammet ønsker at sende data serielt.
PIC-kredsen 19
Som navnet antyder skal denne kreds programmeres. Dette sker, som ved UART’en, gennem en
række registre i processorens I/O-område. Det er muligt at specificere hvilke interrupts kredsen skal
reagere på. Det vil sige, at kredsen kun sender et interruptsignal til processoren hvis den angivne
interruptkilde er specificeret til at generere et interrupt. Dette gøres ved at skrive til registret på
adresse 0021h, hvor bit 0-7 angiver om interrupt 0-7 skal signaleres til processoren. På denne måde
er det muligt at slå specifikke interruptkilder til og fra efter behov.
PIC-kredsen skal desuden have besked når processoren har udført et interrupt, herved nulstilles
interruptet i kredsen og den er klar til at modtage et nyt interrupt fra denne kilde. Nulstilling sker
ved at sende værdien 20h til adresse 0020h.
Interrupt-vektorer
For at processoren ved hvor i hukommelsen den skal finde det software, som skal behandle
interruptet, ligger der fra adresse 0000:0000h til 0000:04ff en tabel med 256 adresser, en til hver af
de 256 mulige interrupts. Hver af disse adresser kaldes for en interrupt-vektor. Når et interrupt
startes læser processoren på interruptets vektor hvor i hukommelsen den kan finde den ønskede
software-rutine.
For at bruge et interrupt må der derfor skrives i denne tabel hvor softwaren, kaldet for en Interrupt
Service Rutine (ISR), er placeret. Dette gøres med kommandoen setvect (Vektor nr., adresse) fra
headerfilen dos.h. For at efterlade systemet intakt efter sit program er udført, er det en god ide at
gemme adressen på den gamle ISR, inden man overskriver den med sin egen ISR-adresse. Når så
ens program afsluttes bruges setvect til at genindsætte den gamle ISR. Indholdet af en vektor læses
med kommandoen getvect (vektor nr.).
18 PIC: Programmable Interrupt Controller
19 I vireligheden styres de 16 interrupts af to forbundne PIC-kredse, men da de to interrupts som har vores interesse
begge af styret af den første kreds. Vil vi i dette afsnit ikke diskutere brug af interrupt 9-15.
Side 60 af 113

6.1.4 MCU-UART
Seriel kommunikation
MCU-systemet har ligesom PC’en en UART, men i MCU-systemet er denne en del af selve
MCU’en og ikke en periferier enhed. Selvom UART’en er en integreret del af MCU’en kan den
køre parallelt med de andre funktioner i MCU’en. Følgende vil de forskellige kontrolregistre på
MCU’en blive gennemgået og det vil blive forklaret hvordan MCU’en generer sin baud-raten 20 .
SBUF registret
SBUF (Seriel buffer) registret svarer til register 0 på PC’en, dvs. den er buffer både for sidst
modtagende byte og for den byte der sendes og ligeledes som ved PC’en påbegyndes transmission i
det øjeblik der skrives til SBUF registret.
SCON registret
SCON (seriel control) registret styrer
seriel portens konfiguration. (Register
oversigt fig. 6.8) Specielt bestemmer
registret hvilken type forbindelse der
skal oprettes. Da vi har valgt at bruge 8
databit (jvf. 6.1.1) er der kun en
mulighed, nemlig mode 1.
De to interruptbits TI, RI har også
interesse, da vi her kan se om
UART’en har genereret et interrupt
fordi den enten har sendt eller
modtaget en byte.
Endvidere skal det huskes at bit 4 skal
sættes før UART’en kan begynde at
modtage data fra den serielle
forbindelse.
Bit nr. Funktion
7,6 Vælger type af forbindelse:
0,0: Synkroniseret forbindelse (mode 0)
0,1: 8 databit med variabel baud-rate (mode 1)
1,0: 9 databit med fast baud-rate (mode 2)
1,1: 9 databit med variabel baud-rate (mode 3)
5 Bruges til kommunikation mellem flere microcontrollere
4 Receiver enable. Denne bit sættes for at kunne modtage data
3,2 Niende bit ved 9 databit. (en bit til både sende- og modtage
bufferen
1 Sende interruptflag. Bliver 1 når sendebufferen (SBUF) er
tømt. (TI)
0 Modtage interruptflag. Bliver 1 når modtagebufferen
(SBUF) er fyldt. (RI)
Figur 6.8 – Oversigt over SCON- registret.
Baud-rate generation
I mode 1 kan baud-raten generes ved brug af MCU’ens timer/counter 21 1. Timer/counter 1 tæller
antallet af clock-frekvensen og hver gang den har talt 65535 perioder vil alle bittene i tæller
registeret gå fra 1 til 0, dette kaldes et overløb og perioden mellem hver overløb svarer til
1/(baudrate). Afhængig af hvordan timer/counter 1 sættes op, kan der opnås baud-rates mellem 110
og 62500 baud.
Hvis MCU’en drives af en krystal på nøjagtig 12mHz er det imidlertid muligt at genere baud-rates
på henholdsvis 4800 baud og 9600 baud direkte ud fra clock-frekvensen. Dette sker uden brug af
timer/counter 0, hvorfor denne metode er at foretrække, da timer/counter hermed kan bruges til
andre opgaver. Baud-rate generation på denne måde vælges ved at sætte bit 7 i ADCON (A/D
Converter Control) registret, og baud-raten vælges til 9600 baud ved at sætte bit 7 i PCON (Port
Control) registret. De to nævnte registres resterende bit har ingen funktion i forbindelse med seriel
kommunikation
20 For yderligere uddybning omkring MCU'ens UART henvises til [Siemens]
21 Timer/counter 1 er en anden periferier enhed i MCU’en. JVF “MCU-software”
Side 61 af 113

6.1.5 MCU-interruptsystemet
Seriel kommunikation
Interruptsystemet på MCU'en styres af en række registre i MCU’en, vigtigst er IEN0 og IEN1
(Interrupt Enable 0/1), hvor det vælges hvilke interrupts, der skal være aktiverede. I vores tilfælde
skal bit 4 i IEN0 sættes for at aktivere interrupts for seriel-porten. Det serielle interrupt har sin
interrupt-vektor på adresse 0023h.
På MCU’en vil der genereres et serielt interrupt, hvis der enten er sendt eller modtaget en byte.
Der er ikke som på PC’en mulighed for selv at specificere ved hvilke hændelser UART’en skal
genere et interrupt (jvf. afsnit 1.1.2 ”register 1”). Men interruptrutinen kan undersøge dette ved at
læse bittene TI og RI fra SCON registret (jvf. figur 1.8) Endvidere skal de to nævnte bit slettes
inden interrupt service rutinen forlades, da interruptsystemet udløser interrupt i det øjeblik det
konstateres at enten TI eller RI går fra 0 til 1, hvilket ikke kan ske hvis de i forvejen er sat til 1.
6.1.6 Buffer og API
Ved hjælp af UART og interrupts kan vi nu sende og modtage data på både PC og MCU, men for,
at det skal være bekvemt for brugersoftwaren at kommunikere gennem den serielle forbindelse, skal
vi have udviklet vores API, dvs. de funktioner, som brugerprogrammet skal kalde for at bruge det
serielle interface. Desuden skal vi sørge for, at de data der modtages ikke går tabt, hvis ikke
brugersoftwaren når at læse data fra seriel porten inden den næste byte modtages. Der skal altså
udvikles en buffer mekanisme, der kan opbevare dataene midlertidigt og desuden skal denne
mekanisme være let for brugersoftwaren at anvende. Herved undgås, at brugersoftwaren behøver at
bekymre sig om detaljerne ved seriel kommunikation.
For at imødekomme dette vil vi anvende en cirkulær FIFO 22 -
buffer. Denne muliggør at bufferen har en konstant størrelse og,
at det først ankomne element hentes ud først. Denne bufferform
kræver et array, 2 pointere og en statusvariabel. Et eksempel kan
ses på fig. 6.9.
Eksemplet viser en cirkulær buffer på 9 lagerenheder.
Firstpointer peger på det første element i bufferen og Lastpointer
peger på den første ledige plads i bufferen. Statusvariablen er 4
svarende til, at bufferen indeholder 4 elementer (de prikkede
kasser). Hvis der skal hentes data fra bufferen udlæses værdien på
position 1, firstpointer inkrementeres med 1 og statusvariablen
dekrementeres med en og bliver 3.
Hvis der skal gemmes data i bufferen gemmes det på
position 5 og både lastpointer og Statusvariablen
inkrementeres begge med 1, hvorved lastpointer igen peger på
den første ledige plads i bufferen.
8
7
6
5
4
3
2
1
0
Statusvariabel
4
Lastpointer
Firstpointer
Figur 6.9 – Cirkulær buffer med 9
elementer, pointere og statusvariabel.
Når bufferen er tom vil firstpointer og lastpointer pege på samme position og statusvariablen vil
være 0 svarende til, at bufferen er tom. Når en af pointerne inkrementeres til at pege på det 9’ende
element, wrapper pointeren, dvs. den bringes til at pege på position 0 i stedet for. I det tilfælde at
lastpointer ”overhaler” firstpointer dvs. bufferen fyldes, må der ikke kunne skrives mere i bufferen.
22 First In/First Out
Side 62 af 113

Seriel kommunikation
Derfor skal statusvariablen kontrolleres inden der skrives i bufferen, så det ikke er muligt at
overskrive data.
6.2 Design af Seriel interface
Målet for det serielle interface er at skabe en kommunikationsvej mellem to programmer, der er
placeret på hver sin platform, henholdsvis PC og MCU. På fig. 6.10 ses de enkelte komponenter i
dette system og sammenhængene imellem dem. I dette afsnit vil vi kigge nærmere på hvordan de
enkelte softwarekomponenter skal programmeres, og hvordan de enkelte komponenter kan bringes
til at virke sammen.
6.2.1 Design af PC-software
PC MCU
Forbindelse oplevet
af bruger software
Bruger
Software
API
Interrupts
PC-UART
Seriel forbindelse
Bruger
Software
API
Interrupts
MCU-UART
Softwareniveau
Hardwareniveau
Figur 6.10 – Opstilling af de enkelte komponenter, som deltager i udførelsen
af den serielle kommunikation mellem de to brugerprogrammer.
Vi vil her diskutere designet af softwaren til det serielle interface på PC’en. Som det ses på fig.
6.10, er der 3 elementer (UART, Interrupts og API), som skal bringes til at virke sammen. Da der
både er tale om hardware- og softwareelementer skal interfacet dels sætte hardwaren op med de
ønskede indstillinger og dels indeholde de rutiner som skal behandle de data, som modtages og skal
sendes.
Opsætning af UART
Først konfigureres PC’ens UART. Dette indebærer at UART’ens basisadresse findes ved at læse
på adresse 0000:0400h i hukommelsen. Herefter bruges basisadressen til at programmere
UART’ens registre med de ønskede værdier (jvf. 6.1.2).
Design af cirkulær buffer
Da bufferen tillige er grænseflade til brugerprogrammet, er det ønskværdigt at det er designet på
en sådan måde, at brugerprogrammet enkelt kan betjene sig af den, uden at brugerprogrammet
behøver at vide noget om seriel kommunikation. Herfor bruges C++’s mulighed for
Side 63 af 113

Seriel kommunikation
programmering med klasser, som giver mulighed at udvikle en sådan grænseflade til
brugerprogrammet 23 . Det skal bemærkes at der faktisk indgår to separate buffere i interfacet, både
en modtage- og en sendebuffer.
Vi vil lade bufferens grænseflade bestå af følgende funktioner, som også udgør API’en for den
serielle kommunikation:
Status () – Returnerer antallet af elementer i bufferen.
Post (Dataelement) – Gemmer et dataelement i bufferen.
Retrieve (Dataelement) – Returnerer et dataelement i bufferen.
De tre funktioner skitseret ved hjælp af pseudokode i bilag ”pseudokode”.
Som før nævnt skal der bruges to buffere i interfacet, en til at holde modtagende data og en til at
holde de data der skal sendes. Disse to buffere skabes i C++ udfra de ovenfor beskrevne klasse, der
fungerer som en skabelon. Kalder vi dem for Modtag og Send, kan de beskrevne funktioner i
klassen benyttes ved f.eks. Modtag.status(), som returnerer status for modtagebufferen eller f.eks.
Send.post(Data), som gemmer data i sendebufferen.
Interrupt Service Rutiner
Vi vil oprette et interrupt, som hver gang der modtages data på seriel-porten, sørger for at lagre
denne information i modtage-bufferen. Hertil bruges interrupt nr. 4 (jvf. 6.1.3). Desuden vil vi
oprette et interrupt som med jævne mellemrum kontrollerer om brugerprogrammet har skrevet i
sende-bufferen, og hvis dette er tilfældet, viderebringe dataene til seriel porten. Hertil bruges
system-timer interruptkilden (nr. 1), som genererer et interrupt for hver 55ms. ISR for modtage
interruptet kan ses som pseudokode i bilag ”pseudo-kode”. De to ISR’er skal selvfølgelig initieres
med Setvect() og der skal skrives til PIC-kredsens kontrolregister for at aktivere de ønskede
interrupts (jvf. afsnit 1.1.3).
6.2.2 Design af MCU-software
Følgende behandler vi designet af det serielle interface til MCU. Som ved PC er det de tre
elementer UART, Interrupts og API, som skal bringes til at virke sammen. Vi vælger på MCU’en
kun at bruge buffer til at modtage data serielt, hvorimod dataene sendes serielt direkte uden brug af
buffer. Dette gør interfacet simplere at programmere, og det sparer hukommelse til sende-bufferen.
Til MCU’en programmeres der i C, da C++ ikke er egnet til små 8-bit computere bl.a. pga. et
større hukommelsesforbrug. Herfor kan der ikke programmeres med klasser, som ved PC-interfacet.
Opsætning af UART
Som det første konfigureres MCU’ens UART ved at sætte de ønskede bit jvf. 6.1.4.
Design af cirkulær buffer
Designet af den cirkulære buffer følger så vidt muligt det samme design som PC-Bufferen (afsnit
6.2.1), men da vi ikke kan arbejde med klasser, programmeres bufferen i stedet som globale
variable og funktioner, som derfor kan kaldes overalt i programmet. Selve koden i funktionerne er
den samme som ved PC-bufferen og pseudokoden herfra kan genbruges.
23 Vi vil I denne rapport ikke omtale det objekt orienterede paradigme nærmere.
Side 64 af 113

Seriel kommunikation
Transmision af data
Transmission af data sker som før nævnt direkte uden brug af buffer, der skal derfor heller ikke
bruges et interrupt til at undersøge om der er data i bufferen, som skal sendes. Før vi kan sende en
byte serielt, må vi først undersøge om UART’en er klar til at sende, dvs. den sidst sendte byte er
færdigsendt. Dette er imidlertid et problem da, der ikke i MCU’ens UART er en bit som angiver
dette. Dette problem løses ved at bruge det interrupt, som genereres når en byte er sendt af
UART’en. Vi lader dette interrupt sætte et flag, dvs. en global variabel, som sendefunktionen skal
vente på er sat før den må sende en ny byte til UART’en. Dette flag slettes så af sendefunktionen
når den nye byte er sendt. Pseudokode for sendefunktionen og det serielle interrupt kan ses i bilag
”pseudokode”.
Modtagelse af data
Når det serielle interrupt aktiveres ved at sætte bit 4 i MCU’ens IEN0-registret (jvf. 6.1.5)
genereres både interrupts når der modtages en byte og når den sidste bit i SBUF er sendt. Derfor
skal interrupt service rutinen selv finde ud af hvorfor interruptet indtraf. Dette gør den ved at læse i
SCON registret hvor to bit angiver hvilken af de to årsager, som er grund til interruptet. Hvis
interruptet skyldes at den sidste bit i sendebufferen er sendt, skal rutinen (som beskrevet ovenfor)
sætte SFLAG, så der kan sendes mere data. Hvis interruptet skyldes, at der er modtaget en byte,
skal denne gemmes i bufferen. Koden kan ses som pseudokode i bilag ”pseudokode”.
Som det kan ses af pseudokoden er funktionen til at gemme i bufferen en del af selve interruptet,
hvorimod det på PC’en var et funktionskald til bufferklassen. Dette skyldes at MCU’en ikke har en
sende buffer, hvorfor gemme på buffer funktionen kun skal kaldes et sted; ved modtagelse af data.
Der er herfor ikke brug for at programmere det som en funktion.
6.2.3 Sammenfatning af design
Ved det beskrevne design har vi opnået at kombinere de tre elementer UART, interrupts og buffer
i en simpel API, der kun består af tre funktioner. Dette gør det let for et brugerprogram at anvende
seriel kommunikation. Vi har i vid udstrækning brugt interrupts for at gøre interfacet så uafhængigt
som muligt. Vi kunne have valgt at fokusere mere på at designe et mere generisk interface, dvs. et
interface som let kan bruges i andre sammenhænge, men vi har konsekvent valgt at designe det med
så lidt funktionalitet som muligt. Dette skyldes at prioriteterne har været hurtig udviklingstid og
overskuelighed.
6.3 Implementation og test
Implementation er sket løbende som prototyping (jvf. ”Metodeafsnit”) og har ikke budt på store
overraskelser. Der har dog været et par problemer med det simulationsprogrammet som er brugt
under implementationen til MCU’en. Det viste sig, at simulationsprogrammets timing er en smule
unøjagtig i forhold til den virkelige kreds.
Softwaren er testet for ved at sende data mellem MCU og Computer. Det har vist sig, at der ikke er
opstår fejl på forbindelsen som følge af støj. Hermed er krav 1 og 3 (jvf. Afsnit 1.0) overholdt og vi
behøver ikke, i den øvrige software at tage højde for dette 24 .
24 Så længe der er tale om et afgrænset projekt.
Side 65 af 113

Seriel kommunikation
Da interfacet hovedsageligt er interruptstyret imødekommes krav 2 (jvf. Afsnit 1.0), som siger at
systemet skal kunne udføre andre opgaver simultant med det serielle interface. Dog er MCU’ens
sende funktion ikke interruptstyret, hvorfor det kaldende program kan komme til at vente op til
maksimalt 105 mikrosekunder på, at der sendes en byte serielt, da dette svarer til tiden, som det
tager for at sende 8 databit, star- og stopbit. Dette vil ske hvis brugerprogrammet kalder
sendefunktion umiddelbart to gange lige efter hinanden. Men det forventes ikke, at dette vil være
anledning til problemer, da mange af MCU’ens funktioner kan køre helt uafhængigt af CPU’en
(F.eks. Analog til digital konverteren). Desuden er en pause på 105 mikrosekunder negligeabelt i
forhold til et reguleringsprogram, som skal regulere til et system med en responstid på ca. 850
sekunder (jvf. 2.4.1).
6.4 Fortolkning af data sendt gennem forbindelsen
Vi kan på nuværende tidspunkt sende og modtage data serielt mellem MCU og PC. For at kunne
benytte dette, må vi specificere hvordan henholdsvis PC og MCU skal fortolke disse data. For at
specificere dette må vi først analysere hvilke kommandoer og data, der er brug for at formidle
mellem de to enheder.
MCU’en har kun behov for at kende den temperatur, som brugeren ønsker rummet skal have, for
at kunne udføre den ønskede regulering. PC’en derimod skal kunne modtage alle væsentlige
parametre fra MCU’en, såsom målte temperaturer og effekt, så brugeren på sin skærm kan se hvad
temperaturen i rummet er og hvilken effekt, som løber gennem radiatoren. Desuden behøver PC’en
at fortælle MCU’en hvornår natsænkning skal påbegynde eller afsluttes.
Disse behov er opsat i følgende tabel (fig. 6.11), som viser hvem der initierer kommunikationen,
hvorfor og hvilket svar der forventes.
Ordre Initiator Beskrivelse Yderligere data Svar
1 MCU Anmod om ønsket
indetemperatur
Ønsket indetemperatur
2 PC Ny ønsket indetemperatur Ønsket
fra bruger
indetemperatur
3 PC Anmod om temperaturer
Indetemperatur,
og effekt
udetemperatur, effekt
4 PC Påbegynd natsænkning Ønsket
nattemperatur
5 PC Afslut natsænkning Ønsket
temperatur
Fig. 6.11 – Viser hvem der initierer kommunikationen, hvorfor, hvilke data der efterfølger ordren og hvilket svar
initiatoren forventer.
Kommunikationen realiseres på den måde, at initiatoren sender ordrenummeret som første byte, og
evt. data i efterfølgende bytes. Modtageren svarer så ved at gentage ordrenummeret som første byte
hvorefter der følger svardata. Ved at gentage ordrenummeret sikres det, at MCU og PC kan fortolke
hinandens ordre, selvom de begge har anmodet om data samtidigt. Da de ellers ikke i et sådan
tilfælde kan vide om det data de har modtaget, er en ordre, eller om det svaret på sidste anmodning.
Side 66 af 113

Seriel kommunikation
Som eksempel forestiller vi os at PC’en ønsker at modtage nye værdier af temperaturer og effekt
fra MCU’en. Den sender værdien 3, og modtager kort efter: 3, indetemperatur, udetemperatur,
effekt. Som fire bytes.
Hermed har vi specificeret hvordan de data, som sendes gennem den serielle forbindelse skal
fortolkes og hvilke kommandoer det skal være muligt at bruge mellem de to enheder.
Side 67 af 113

7.0 MCU-software
MCU-software
I dette kapitel vil vi koncentrere os om, at udvikle det software til SBC’en, som sætter denne i
stand til at udføre reguleringen af radiatoren på baggrund af de ordrer, som modtages fra brugeren
gennem det serielle interface.
Først vil vi beskrive brugen af de enkelte perifere enheder i MCU'en, som vi vil gøre brug af.
Disse er: Analog til digital konverteren (ADC), som vi skal bruge til at måle temperaturer med.
Timer 2, som skal bruges til at regulere effekten med, vha. puls-bredde-modulation (PBM). Timer
0, som kan generere tidsbestemte interrupts, så reguleringen kan udføres med jævne mellemrum.
SBC'ens UART til seriel kommunikation bruges, men denne er indgående blevet beskrevet i
kapitlet om seriel kommunikation. Desuden analyseres det hvordan vi kan arbejde med decimaltal
på SBC'en, som ikke indeholder en matematisk hjælpeprocessor.
Herefter diskuteres det design som skal bringe ovenstående enheder til at virke sammen på
SBC'en. Til sidst diskuteres implementations- og testfasen.
På microcontrolleren, bruges programmeringsproget C i stedet for C++, som vi bruger til
udvikling af PC-software (jvf. x.2.2).
7.1 Brug af periferi-enheder
Følgende gennemgås de forskellige periferier enheder i MCU’en og de programmeringsteknikker
som skal benyttes, for at MCU’en kan regulere radiatoren. For yderligere information om de enkelte
periferi-enheder henvises bilag ”mcu-detal” og databogen for MCU’en [Siemens].
7.1.1 Analog til digital konvertering
For at kunne benytte det resultat som, de to temperaturfølere giver, skal signalerne første
konverteres til digitale signaler. På MCU’en er der indbygget en Analog til Digital
Konverteringskreds (ADC). Denne har 6 multiplexede indgange, AN0-AN5, dvs. den kan skifte
imellem, at konvertere signalet fra 6 forskellige ben. Resultatet af konverteringen er en 8 bit værdi,
dvs. et tal mellem 0-255, som er proportional med spændingen på inputbenet (0-5V). Ved at stille
multitrimmerne (jvf. ”Hardware”) i temperaturmålekredsen sådan, at spændingen er 0V ved 10
grader og 5V ved 60 grader opnås en nøjagtighed på 0,20 grader.
Da vi skal måle både inde- og udetemperaturen, vælger vi at sætte ADC’en op således, at den
udfører kontinuerlige konverteringer af indetemperaturen. Dvs. softwaren hele tiden kan læse den
sidst konverterede indetemperatur i ADDAT-registret (Adc DATa). Hvis softwaren skal bruge en
ny udetemperatur kalder den en funktion som afbryder ADC’ens målinger af indetemperatur og
gennemfører en enkelt måling af udetemperaturen, hvorefter den igen sætter ADC’en op til at
udføre kontinuerlige målinger af indetemperaturen.
Fordelen ved hele tiden, at udføre kontinuerlige målinger af indetemperaturen er, at den sidste
konvertering altid kan læses i ADDAT, hvorfor softwaren ikke behøver at vente de ca. 15
mikrosekunder, som en konvertering tager.
7.1.2 Puls bredde modulation
SBC’en skal styre effekten af radiatoren, til dette benyttes Puls-Bredde-Modulation (PBM). Det vil
i dette afsnit blive forklaret hvad PBM er, og hvordan MCU’en bruger timer 2 til dannelse af PBM.
Side 68 af 113

MCU-software
Ved at variere et signal mellem to spændingsniveauer er det muligt, gennemsnitligt set, at generere
alle mulige spændinger imellem de to yderpunkter. Dette er princippet bag PBM. Hvis for eksempel
der på en given udgang skiftes mellem lige lange perioder på henholdsvis 0 og 5V, opnås et signal
med en gennemsnitlig spænding på 2.5V.
Det er altså muligt at danne et signal med en vilkårlig spænding ved at variere spændingen mellem
0 og maksspændingen i lige lange perioder, hvor spændingen holdes høj i en procentdel af perioden,
svarende til den procentdel af maksspændingen, der ønskes på udgangen. Det skal dog hele tiden
holdes i mente, at de komponenter der drives af denne spænding skal kunne operere ved denne
pulserende spænding uden at blive overbelastede eller generere forstyrrelser pga. f.eks.
selvinduktion.
Til brug ved effektregulering af radiatoren, kræves der en større spænding en MCU’en kan levere
på sine udgange (0-5V), derfor bruges udgangene til at styre en større spænding vha. effekttrinnet,
som er beskrevet i afsnittet om hardwaren. Ved at styre dette effekttrin er det muligt at generere alle
spændingsniveauer, som ligger inde for spændingsfaldet over effekttrinnet.
For at generere PBM bruges MCU’ens interne timer 2. Denne timer har nogle tilhørende registre,
der giver mulighed for opsætning af timerens virkemåde og pulsens bredde. Der er i alt 12 registre
på hver 8 bit tilknyttet timer 2, disse giver mulighed for at generere op til fire uafhængige pulser,
som hver er gennemført til et ben på MCU’en.
En timer er en tids tæller, der når den er aktiveret, tæller antallet af machine-cycles. Dette foregår,
for timer 2’s vedkommende, i et 16 bit register. Timer 2 sættes op til at begynde forfra ved
overflow, dvs. når timeren har talt til maksimum. Derudover skrives der til et 16-bit
sammenligningsregister, som hele tiden sammenlignes med indholdet af timer 2, når de to registre
er ens, bliver signalet på udgangen binært højt, svarende til, at der på udgangen på MCU’en er en
spænding på 5V. Når så timer 2 har talt til 65535 (16-bits maksimum), sættes udgangen automatisk
igen til binært 0. Den gennemsnitlige udgangsspænding varieres altså ved at ændre på værdien i
sammenligningsregistret.
Opsætningen af timer 2 styres af to registre T2CON (Timer 2 CONtrol) og CCEN
(Compare/Capture Enable). Opsætningen af disse er beskrevet i bilag ”mcu-detal”
Software til PBM
Vi ønsker at tilføre radiatoren en effekt på mellem 0-50W (Jvf. ”regulering”), da radiatoren har en
resistans på 37.2Ω (jvf. bilag: ”fysisk model”), betyder det, at den ønskede spænding kan beregnes
ved formlen:
U = 37.
2Ω⋅
P
(7.1)
Da vi maksimalt ønsker en effekt på 50W, skal effektrinnet forsynes med et spændingsfald på
43.1V, hvorved det vha. PBM bliver muligt at generere alle ønskelige effekter mellem 0-50W.
Fort at anvende spændingen, beregnet i formel 1.1, til at generere pulser med skal den udtrykkes
som antallet af machine-cycles ud af en hel periode (65536 cycles), hvori signalet skal være højt.
Dette gøres ved at skalere formel 1.1. med forholdet mellem spændingsspændet og periodelængden
(65536/43.1=1519.6). Dermed kan vi beregne hvor mange mikrosekunder i hver periode, udgangen
skal være høj:
Højperiode = 1519.
6⋅
37.
2Ω⋅
P
Side 69 af 113
(7.2)

MCU-software
Det tal, der skal skrives til CC1-registret (Compare/Capture 1) 25 , er hele perioden(65536)
substraheret med højperioden. Dette er fordi, at signalet først bliver højt i det øjeblik at CC1 er lig
med timerregistret. CC1 Udregnes altså ved følgende formel:
CC1 = 65536 −1519.
6⋅
37.
2Ω⋅
P
Da udregningen af denne formel, er en meget beregningstung opgave for MCU’en at udføre pga.
kvadratrodsudledningen. Har vi i stedet for at gennemføre den på MCU’en, valgt for hvert hele
effekttrin at beregne værdierne på forhånd. Disse forudberegnede værdier er så lagt i en tabel,
placeret i ROM-kredsen, som bruges til opslag når der ændres på effekten. Unøjagtigheden som
skyldes afrundingen til nærmeste hele effekttrin, betyder pga. den kontinuerlige regulering, ikke
andet end, at effekten, typisk vil stå og skifte mellem to forskellige værdier, når den har opnået den
ønskede temperatur.
Der er programmeret en funktion, som når den kaldes med den ønskede effekt, slår denne effekt op
i tabellen og ændrer CC1-registret, sådan at den passer med den nye effekt. Denne funktion er
skitseret med pseudokode i bilag ”MCU-pseudokode”.
7.1.3 Timer 0
Da reguleringsalgoritmen bruger tiden i sine udregninger, er det vigtigt, at den kaldes med faste
intervaller. Til dette formål benyttes Timer 0 og interrupts.
Vi vælger at køre reguleringsmekanismen for hver 10’ende sekund. Da timer 0 vil generere et
interrupt for hver 65536 mikrosekunder. Skal timer 0’s ISR tælle interrupts op til de 10 sekunder er
gået, den skal altså i alt tælle (10.000.000/65.536)µs= 152.6 interrupts. De 0,6 opnås ved, at ISR
ved interrupt nr. 152 skriver (1-0,6)·65536≅26214 i timerens tæller register. Perioden til næste
interrupt bliver da forkortet, så det passer med, at næste interrupt generes præcist på det 10’ende
sekund (på nær afrundingsfejlen). På det 153’ende interrupt sætter ISR så et flag, som signalerer til
hovedrutinen, at det nu er tid til at køre reguleringsfunktionen. Dette flag slettes så af
reguleringsfunktionen, når den køres.
7.1.4 Beregninger med decimaltal
Den i afsnittet ”regulering” opstillede reguleringsalgoritme indebærer beregninger med decimaltal,
hvilket stiller meget store krav til datakraft, fordi decimaltal, i forhold til integertal, dels kræver
meget hukommelse og mange beregninger. Derfor har vi valgt ikke direkte at benytte decimaltal i
MCU-softwaren, selvom C-sproget indeholder mulighed for at benytte dem 26 . Vi vil i dette afsnit
gennemgå den programmeringsteknik som vi bruger for alligevel at kunne lave beregninger med
tilstrækkelig præcision til at kunne udføre beregningerne dikteret af reguleringsalgoritmen.
Hvis vi i titalssystemet begrænser os til at udføre regneoperationer på integertal vil summen af
f.eks. tallene 4,7 og 5,9 give 9, men hvis vi forestiller os, at tallene før beregningen skaleres med en
25 Dette register er det valgte sammenligningsregister.
26 Desuden er vi ved forespørgsel i nyhedsgruppen comp.arch.embedded blevet frarådt at bruge float-typer på en så
begrænset MCU.
Side 70 af 113
(7.3)

MCU-software
faktor 10, bliver resultatet 106. Reduceres dette tal igen med faktoren 10 fås integertallet 10, derved
er fejlen, i forhold til den tidligere beregningen, reduceret til en afrundingsfejl.
Antallet af cifre efter kommaet, som skal have indflydelse på beregningen bestemmes af
skaleringsfaktoren. Øges skaleringsfaktoren til f.eks. 1000 vil de tre mestbetydende cifre efter
kommaet have indflydelse på udregningen.
En ligende tankegang kan bruges til beregninger på microcontrolleren. De temperaturer,
reguleringsalgoritmen arbejder på er tal beskrevet ved en byte, dvs. mellem 0-255, hvis vi skalerer
disse værdier med 256 27 , hvilket svarer til at flytte bittene 8 pladser til højre, opnår vi en
nøjagtighed på 1/256=0.004. Dette tal er nu udtrykt ved 2 bytes (16-bits), hvorfor vi ikke kan øge
nøjagtigheden mere, da der yderligere skal være båndbredde til at udføre regneoperationer på disse
tal. F.eks. hvis vi skal multiplicere to 16-bit værdier vil resultatet skulle udtrykkes ved 32-bit,
hvilket er den største datatype, som understøttes af C-sproget. Desuden er en nøjagtighed på 0.004
tilstrækkelige sammenlignet med vores målenøjagtighed på 0.20 grader (jvf. 7.1.1).
Hvis to af disse tal multipliceres, skal man huske på, at produktet af de to bytes (en fra hver faktor)
med information om decimalttalsværdien i resultatet fylder 16 bits. Derfor er det nødvendig at
afrunde resultatet, ved at dividere med 256, inden der regnes videre med resultatet, så tallene er
kompatible. Samme tankegang er gældende ved division, dog skal resultatet her multipliceres med
256 i stedet.
Det skal bemærkes at selvom mængden af beregninger er betydeligt reducerede ved ovenstående
metode, er reguleringsalgoritmen stadig en beregningstung opgave for MCU’en, da den sættes til at
beregne på 32-bit datatyper, selvom det kun er en 8-bits processor.
7.2 Sammensætning af software
Vi er nu kommet til det punkt hvor den egentlige software
til
MCU’en skal designes. Denne består af tre dele: Selve
reguleringsalgoritmen, kommunikationssoftwaren
(beskrevet i
kapitel x.0) og den software som skal fortolke den
serielle
kommunikation. Disse ”rene” softwarekomponenter
er
afhængige af den foroven-beskrevne opsætning
af hardware og
hjælpefunktioner, som f.eks. funktionen til at variere effekten.
Desuden anvendes også opsætningen af UART’en,
Effektsom
beskrevet i afsnit x.2.2. Forholdet mellem
regulering
disse softwarekomponenter og hardwaren er
skitseret på fig. 7.1.
Overordnet kører MCU-softwaren i en uendelig
løkke, som
først kontroller om der er kommet nye
ordre
fra PC’en, er dette tilfældet kaldes en funktion
Temperatur-
målere
Regulering
Protokol- fortolkning
Seriel- kommunikation
Opsætning af hardware
Figur 7.1 – Viser sammenhængen mellem MCUsoftwaren
og den underliggende hardware.
27 256 er et ”rundt” tal i det binære talsystem, hvorfor MCU’en hurtigt kan gange med dette tal, ved at flyttes bittene til
højre.
Side 71 af 113
RS-232

MCU-software
som fortolker og reagerer på ordren. Dernæst kontrolleres det om timer 0’s ISR har signaleret, at det
er tid til at køre reguleringen. Herefter gentages løkken, og der kontrolleres
igen for nye ordrer fra
PC’en.
7.2.1
Integration af det serielle interface
Det serielle interface er integreret som beskrevet i kapitlet om seriel kommunikation.
Dvs. at de
andre
softwarekomponenter benytter seriel kommunikation vha. den beskrevne API.
7.2.2
Integration af protokollen for seriel kommunikation
Protokollen er integreret sådan, at der i hver gennemløb af den uendelige løkke, kontrolleres
hvorvidt bufferen indeholder dataelementer. Hvis dette er tilfældet læses det første dataelement,
som angiver hvilken kommando, der er tale om. På baggrund af kommandoen forgrenes der til det
kode som skal fortolke denne kommando.
Hvis f.eks. PC’en sender kommandoen 1 (jvf. x.4), som angiver, at PC’en følgende sender en ny
ønsket temperatur, afventer MCU’en ankomsten af den næste byte, som når den ankommer skrives
til den variabel som indeholder den temperatur, som der reguleres efter. Hvis kommandoen fra
PC’en derimod er 3, svarende til at PC’en ønsker temperaturer og effekt sendt til den, Gentager
MCU’en kommandoen og sender de krævede
variable. Pseudokode for protokol-fortolkningen kan
ses i bilaget ”Pseudo til MCU-SW”.
Når MCU’en bliver tændt eller genstartet sender den en gang kommandoen 1, som beder PC’en
om en ønsket rumtemperatur. Modtages denne ikke påbegynder
MCU’en reguleringsfunktionen
med
de faste værdier som variablerne deklareres med.
7.2.3
Integration af reguleringsfunktionen
På MCU’en repræsenteres temperaturen ikke ved Celsius-skalaen, men i stedet som det tal mellem
0-255, som ADC’en måler. Dermed undgås det, at måleværdierne fra ADC’en skal konverteres
til
Celsius-grader i MCU’en, men det stiller det krav til PC-softwaren, at skal omregne mellem
MCU’ens temperaturskala og Celsius’s.
Tallene brugt på MCU omregnes til Celsius-skalaen ved at dividere dem med 5,1, som er forholdet
mellem antallet af mulige temperaturværdier (255) og temperaturspændet fra 10-60 grader
Celsius
(50), hertil adderes så 10, som er nulpunktet for ADC’ens konvertering (jvf. 7.1.1).
Det er dog stadigt nødvendigt at bruge den teknik, som er beskrevet i afsnit 7.1.4 ved videre
beregning med disse tal, fordi der i reguleringsalgoritmen indgår konstanter, der er decimaltal og
som
ikke kan opnå en tilstrækkelig nøjagtighed ved at skalere dem med 5.1.
Selve reguleringsfunktionen kaldes først i det øjeblik, at timer 0 ISR-funktionen
har sat det flag,
som angiver, at der er gået 10 sekunder. Reguleringsfunktionen kaldes da med
temperaturparametrene indetemperatur, udetemperatur og ønsket temperatur. Disse skaleres, som
beskrevet i afsnit 1.1.4, med 256 inden selve udregningerne finder sted. Alle udregninger udføres på
normalvis, dog med den forskel, at alle
konstanterne i reguleringsalgoritmen, også er skalerede med
256 (jvf. ”pseudokode til reg.kap”).
Efter endt regulering slettes flaget fra timer 0, og funktionen til opsætning af PBM kaldes med den
nye
effekt.
Side 72 af 113

7.3 Implementation og test
MCU-software
Implementationen er foregået delvist på den egentlige SBC og delvist vha. af et simulatorprogram,
som simulerer MCU’en. Ved test på SBC’en blev der til kommunikation
brugt et terminalprogram
og
senere i processen anvendtes den egentlige brugerflade.
.
sendes vha. af
II 28 Det blev hurtigt klart at protokollen skulle udvides med en række ordrer til brug ved fejlfinding
Som f.eks. en ordre der returner om MCU’ens reguleringsfunktion tror, at vinduet er åbent eller
lukket, eller om den er i gang med at teste dette. Desuden blev det klart, at de valgte ordrekoder
(Jvf. 6.4) var upraktiske, hvorfor de blev adderet med 100, hvorved ordrene kunne
bogstavtasterne på pc’ens tastatur. Dvs. i stedet for ordrekoderne 0,1..4,5 brugtes
100,101,…104,105, som i ASC -koder svarer til bogstaverne D,E,F,G,H,J, som umiddelbart kan
sendes
fra et terminalprogram.
Selve reguleringsfunktionen fungerede tilfredsstillende og nøjagtigheden af beregningerne viste
sig tilstrækkelig. Reguleringsfunktionen er som før beskrevet meget beregningstung. Vha.
simulatorprogrammet kan det ses, at selve reguleringsfunktionen i værste tilfælde tager ca. 25
millisekunder at udføre. Dette er på ingen måde nok til at være problematisk, og det tyder derfor på,
at reguleringsfunktionen
uden problemer kunne have været implementeret med brug af floating
point
datatyper.
Vi gør her opmærksom på at softwaren til MCU’en ikke opfylde kravspecifikationens punkt 2c:
2. Det elektroniske system skal over forbindelsen
til PC’en kunne:
c.
Modtage tidsramme for natsænkning
Dette skyldes, at det har vist sig upraktisk at skulle programmere et sæt af funktioner på MCU’en
som kan virke som 24 timers ur. Problemet kan løses ved at tilføje en speciel realtidskreds
til
SBC’en, som holder styr på tiden, eller som vi har valgt: at bruge pc’en realtidsur.
Vores løsning betyder dog at SBC’en bliver afhængig af forbindelsen til PC’en for at kunne udføre
natsænkning, og derfor kan den ikke leve helt op til vores
definition på ET, som kræver, at det
embeddede
system kan udføre sine opgaver autonomt.
Test er sket løbende under udviklingen af softwaren. Hver gang der er blevet tilføjet funktionalitet
til programmet, er denne blevet testet og evt. ændringer foretaget inden påbegyndelse af
implementation af flere programdele. Desuden er det endelige
software testet i forbindelse med PC-
softwaren,
hvilket er beskrevet i kapitlet om test af løsning.
28 American Standard Code for Information Interchange: Den mest anvendte for fortolkning af bogstaver, tal og tegn på
computere.
Side 73 af 113

8.0 PC-Software
PC-Software
Softwaren på PC'en skal tjene som et interface mellem brugeren og radiatorreguleringen på
MCU'en. Til dette formål udvikles der en brugerflade der gennem en protokol (Jvf. 6.4) skal kunne
samvirke med den serielle kommunikation. Ligeledes skal der jvf. 7.3 udvikles et ur der fra PC’em
kan udføre natsænkning.
8.1 Brugerflade
Vi vælger at konstruere et eksempel på en brugerflade, der er rettet imod den virkelige løsning,
men dog så begrænset, at den passer i proportion med resten af projektafgrænsningen. Da vi gerne
vil have, at den enkelte bruger selv skal kunne ændre på radiatorens indstillinger, kræves en måde
hvorpå en programeringsmæssigt uuddannet kan ændre på reguleringen, så denne passer bedre til
brugeren. Derudover vil vi have, at brugeren skal kunne følge med i hvordan systemet har kørt.
Dette kan gøres ved hjælp af en brugerflade, der skal omsætte dele af programmeringssproget til
letforståeligt dansk, og den anden vej.
8.1.1 Analyse af brugerflade
Brugerfladen skal kunne opsamle data fra brugeren og præsentere disse og andre data på skærmen
således, at brugeren hele tiden kan følge med i den øjeblikkelige situation. Ligeledes skal
brugerfladen også kunne præsentere vigtige data i form af grafer således, at det skaber overblik. I
forbindelse med natsænkning vælger vi desuden at indsætte et ur der udfra computernes ur giver
klokken og datoen (se fig. 8.1).
Klokkeslet
Tid
Dato
De data brugeren skal kunne påvirke er:
Brugerflade
Opsamling af
data fra
bruger
Graf
Figur 8.1 - Topdown over brugerfladen.
− Den ønskede temperatur i dagtimerne
− Den ønskede temperatur i nattetimerne
− Hvornår natsænkning skal starte og slutte
Side 74 af 113
Præsentering
af data til
bruger
Visning af
dataværdier

PC-Software
Det er vigtigt, at disse påvirkninger ikke resulterer i, at systemet bryder sammen, for at undgå dette
skal der laves en form for sikkerhed, der sørger for, at de input der kommer fra brugeren er
realistiske. Dette vil ikke være relevant ved den fysiske model, men ved en virkelig løsning er det
vigtigt at beskytte systemet mod en ukyndig bruger. Vi vælger at opsætte grænserne for
indtastningerne udfra den fysiske models begrænsninger, hvilket vil sige, at der sættes grænser for
bl.a. indetemperaturen, tiden osv.
Præsentationen af data skal opbygges således, at brugeren skal kunne følge med i tilstandene i den
fysiske model. For størst mulig overskuelighed skal både dataene og tiden konstant være til stede
påskærmen, idet dette vil lette brugerens valg. For at gøre en grafpræsentation overskuelig i forhold
til den fysiske model vælger vi at vise grafer over en time. Dette tidsrum vil i en virkelig løsning
skulle forlænges betydeligt til evt. et døgn for virkelig at skabe overskuelighed, men dette er for
langt et tidsrum at operere over i den fysiske model. Som relevant data at vise grafer over, udvælges
indetemperaturen og effekten.
8.1.2 Design af brugerflade
For at gøre programmet
overskueligt for brugeren, er det
udadtil opbygget af en menu, som
ved valg med piletasterne kan gå
over til indtastnings-muligheder,
og så tilbage til menuen. Den ene
af valgene fører brugeren ind i en
undermenu, med et nyt sæt af
forskellige valg (se fig. 8.2).
Dette er imidlertid kun det
brugeren ser, hvorimod den
egentlige programmering er lidt
anderledes. Selve
programopbygningen vil dog kun
blive beskrevet kortfattet her, idet
brugerfladen som tidligere nævnt,
Hovedmenu
Dagtemp Natsænkning Timeforløb Afslut
Nattemperatur
Natsænkning
start
Natsænkning
slut
Tilbage til
hovedmenu
Figur 8.2 - Brugerfladen således som det opleves fra brugerens side.
kun er ment som et eksempel på hvorledes de nødvendige muligheder kan samles i et funktionelt
program.
Der blev fra start besluttet at lægge så meget af programmet ud på funktioner, således at
programmet ville være opbygget af mange små moduler. Dette gør det nemmere at overskue,
samtidig med, at det er nemt at ændre/opdatere programmet, da man i de fleste tilfælde kan nøjes
med at lave ændringer i de enkelte undermoduler. For at give brugerfladen en mere autentisk
opbygning i forhold til en virkelig løsning blev der benytte grafik. Dette medvirker til at give
brugerfladen et mere præsentabelt ydre.
Brugerfladen konstrueres således, at det kan kaldes i et hovedprogram som et enkelt funktionskald.
Dette betyder, at brugerfladen bør opbygges således, at programmet ikke går fast et sted og derved
standser hele hoved programmet. Dette er imidlertid vanskeligt at opnå i brugerfladen, idet
programmet automatisk standser når det venter på indtastning af data. Dette giver dog ikke store
problemer idet der på PC’en ikke ligger vigtige programdele, som f.eks. reguleringen, der ikke må
stoppes. I værste fald standses dataopsamlingen til grafen, hvilket ingen indflydelse har på
forholdene i den fysiske model.
Side 75 af 113

PC-Software
Uret konstrueres således, at det henter datoen og tiden direkte fra computerens realtids-ur. Datoen
kan benyttes direkte, mens den tid der hentes er værdien af en timer der tæller op fra midnat af.
Denne værdi skal altså divideres med antal tik, som timeren generer pr. sekund for at give antal
sekunder siden midnat. Derudfra beregnes tiden i timer, minutter og sekunder og kan derved
benyttes til at bestemme natsænkning. Dette gøres ved at undersøge når timer og minutter stemmer
overens med natsænkningsstarten og når det er tilfældet sendes nattemperaturen som den ønskede
temperatur. Når natsænkningsslutningen stemmer overens med tidspunktet sendes den oprindelige
ønskede indetemperatur. Dermed benytter natsænkningen reguleringens oprindelig funktioner.
Graffunktionen opbygges på samme vis som registreringen af åbnet og lukket vindue ved at
værdierne gemmes i en tabel. Når der opsamles en ny måling rykkes alle værdierne en plads, den
ældste værdi forsvinder ud af tabellen og den nye værdi lægges ind på den tomme plads.
8.1.3 Implementation og test af brugerfladen
For at lette programmeringen af grafikken, blev der benyttet det grafiske dos-interface, som er en
del af Borland 29 compiler systemet. Dette er en ældre og primitiv måde at programmere grafik på,
hvor højeste opløsning er VGA 30 . Dette giver ringe muligheder for at konstruere en virkeligt
præsentabelt brugerflade, men til gengæld er det en let og hurtig mulighed for
grafikprogrammering. Det viste sig under testen af brugerfladen at kan "gå ned" ved uheldige
kombinationer at fejltastninger, hvilket havde været yderst uhensigtsmæssigt, hvis der havde været
tale om et virkeligt produkt. Vi vælger dog ikke at bruge tid på at udbedre fejlen, da det kun er
projektgruppen selv der skal benytte programmet.
8.2 Protokol for PC-Software
Selve PC-softwaren er opbygget som en uendelige løkke der kun kan afbrydes fra brugerfladen. I
hvert gennemløb undersøges der om der er data i bufferen. PC'en kan, jvf. 6.4, udfra det første
element i dataene, se hvilke type data der er tale om. Inden løkken påbegyndes sender PC'en
kommandoen 3 og anmoder dermed om at få tilsendt temperaturer og effekten fra SBC'en, hvorefter
der ventes indtil der ankommer data. Derefter påbegyndes løkken, hvor der først modtages data fra
SBC'en. Hvis denne sender kommandoen 1 returnerer PC'en den ønskede indetemperatur og hvis
den sender kommandoen 3 modtager PC'en temperaturer og effekten.
Hvis brugeren fra brugerfladen ændre en ønskede indetemperatur fra brugerfladen sender PC'en
kommandoen 2, samt den nye ønskede indetemperatur. Protokollen er opbygget på samme vis som
protokollen på SBC’en og for psudokode henvises til bilag 8 for SBC’ens protokol.
8.3 Implementation af PC-software
Implementationen af PC-softwaren blev udført ved at den serielle kommunikation blev opsat først
og testet med SBC’en, og først derefter blev brugerfladen implementeret. Under implementationen
29 Denne kan downloades frit fra Borlands hjemmeside.
30 Højeste opløsning i VGA er 640 x 480 pixels i 16 farver.
Side 76 af 113

PC-Software
af PC-softwaren blev protokollen udvidet, jvf. 7.3, således at den kom til at stemme overens med
ændringerne i SBC’ens protokol.
Side 77 af 113

9.0 Test af løsning
Test af løsning
Efter at alle løsningsdelene er blevet samlet til en færdig løsning skal denne testes for at undersøge
om den samlet lever op til kravene (jvf. 2.5.2). Den færdige løsning består, som tidligere beskrevet,
af på den ene side hardwaren med MCU-softwaren, bestående af seriel kommunikation og
reguleringsalgoritmerne og på den anden side PC-softwaren, ligeledes med seriel kommunikation
og med brugerfladen. Alle underdelene er hver for sig blevet testet og er blevet fundet funktionelle.
Derefter er delene blev sat samme del for del til en større og større helhed og undervejs testet så
godt som muligt. Der færdige løsning er altså blevet testet på forskellig vis med tilfredsstillende
resultater, hvilket er beskrevet i løsningsdelenes implementation og test afsnit. Disse tests er
imidlertid udelukkende blevet baserede på rene tekniske prøver og for at undersøge om løsningen
virkelige opfylder de i problemanalysen specificerede krave skal den testes i den fysiske model.
9.1 Ændringer som følge af tests
Først blev der udført en række løbende tests hvorunder der blev opdaget en række mindre fejl. Det
blev opdaget at der i de stabile tilstande optræder udsving i temperaturen som ikke umiddelbart
burde være der. I de perioder hvor der er effekt på radiatoren og der reguleres kan der være en
række forskellige årsager til udsvingene. Den matematiske model har jvf. 3.5 en større forstærkning
end den fysiske model og derfor skal termostatfunktionen hele tiden regulere ind for at opnå den
ønskede temperatur. Denne effekt modvirkes jvf. 5.3 tildels af at der bliver afsat en smule effekt i
transistoren således at radiatoren får lidt mindre effekt end beregnet. Selve reguleringen køres kun
hver 10. sekund og dette kan ligeledes give udsving i temperaturen idet de korrektioner som der
foretages har indvirkning i alle 10 sekunder før der igen korrigeres og derved kan temperaturen nå
at ændre sig så meget at der skal korrigeres modsat. Endelig er alle tidsforsinkende elementer i den
fysiske model blevet elimineret i den matematiske model, hvilket kan give udsving i temperaturen
idet der f.eks. stadig finder opvarmning sted lidt efter reguleringen har slukket for radiatoren.
Når der er slukket for radiatoren ses udsvingene stadig, men dog svagere. Idet der er slukket for
radiatoren kan udsvingene nu ikke skyldes de førnævnte problemer, men må i stedet skyldes
hardware. Problemet blev undersøgt og det viste sig at selve støjen stammer fra de tre
spændingsregulatorer. Støjen kommer fordi at der er blevet brugt kondensatorer der er viklede, dette
giver en induktiv virkning. Dette kunne afhjælpes med at skifte disse kondensatorer ud med tental
kondensatorer. Problemet indvirker ligeledes på udsvingene der ses ved effekt på radiatoren.
Det viste sig også at tiden for opvarmningstesten på 100 sekunder var et for lille tidsrum til at
testen kunne give et stabilt resultat. Tiden blev derfor sat op til 200 sekunder, hvilket gav den
ønskede virkning. Ligeledes viste det sig at registreringen af temperaturstigning ved lukning af
vindue var sat til et for lille spring, idet der som tidligere nævnt er udsving i den målte temperatur,
hvilket gav mange fejlregistreringer. For at afhjælpe dette blev den temperaturforskel hvormed
vindueslukning registreredes sat op til 1 °C.
9.2 Udførelse af testen
Testen blev udført med følgende opstilling (se bilag *.*) og består af følgende elementer:
− Opvarmningstest og stabilisering
− Ændring af dagtemperatur og stabilisering
Side 78 af 113

Test af løsning
− Åbning og lukning af vindue
− Åbning af vindue efterfulgt af lukning og umiddelbar åbning igen
− Natsænkning start og slut
Vi valgte at lave de forskellige testdele direkte efter hinanden som en lang test, da vi så ved
overgangen fra en test til en anden fik testet nogle af tingene en ekstra gang. Derfor er
testresultaterne også i form af en lang graf. Vi har opdelt grafen i de forskellige deltest og de
mellemopvarmninger, der har været nødvendige for at kunne fortsætte med den næste deltest (se fig
9.1)
Figur 9.1 - Graf over forsøgsresultaterne fra testforsøget.
0-1820 sekunder
Forsøget starter, jvf. 4.x, med en opvarmningstest der varer de først 200 sekunder. Der registers
korrekt lukket vindue og reguleringen træder i funktion og bringer temperaturen op på den ønskede
temperatur på 45 °C, Derefter lader vi den regulere i ca. 900 sek. for at sikre at den regulere korrekt
hvilket den gør når der ses bort fra de føromtalte udsving(jvf. 9.1).
1820-3600 sekunder
Derefter ændres den ønskede dagtemperatur til 35 °C og der ventes igen på en stabil tilstand, som
får lov til at køre i ca. 900 sek. Reguleringen sørger for at temperaturen korrekt sænkes til den nye
ønskede temperatur og holder denne.
3600-5600 Sekunder
For at forberede test af åbning og lukning af vinduet, sættes den ønskede dagtemperatur til 45 °C
og reguleringen sørger for at denne opnås og holdes.
5600-6080 sekunder
Vinduet åbnes og 50 sek. senere registreres at vinduet er åbent. 90 sek. senere lukkes vinduet og
derefter går der endnu 70 sek. før reguleringen som ønsket starter opvarmningstesten. 200 sek.
senere konkluderer testen så korrekt at vinduet er lukket og den lader igen indetemperatur stige
imod den ønskede temperatur.
Side 79 af 113

Test af løsning
6080-7720 sekunder
Vinduet åbnes igen og efter 30 sek. registreres dette, og indetemperatur falder efterhånden ned til
udetemperatur. Nedkølingen er noget ujævn, hvilket kan skyldes at når inde og ude temperaturen
nærmer sig hinanden, vil indetemperaturen ved åbent vindue være mere følsom overfor ændringer i
udetemperaturen, så som folk, der går forbi, et ekstra vindpust fra en dør der åbner og lignende.
Vinduet lukkes herefter og på trods af udsvingene fremkalder dette 100 sek. senere korrekt en
opvarmningstest. Så snart denne går i gang åbnes vinduet igen for at undersøge om
opvarmningstesten også kan falde ud til åbent vindue. Dette sker korrekt 200 sek. senere og
temperaturen falder igen til en stabil tilstand.
7720-8950 sekunder
Efter et kort stykke tid, startes, pga. en temperaturstigning, endnu en test, og også denne falder
rigtigt ud til åbent vindue. Da stigningen ikke var fremprovokeret af os, men af ukendte årsager
viser det at opvarmningstesten opfylder sin funktion.
7950-8950 sekunder
For at forberede test af natsænkning, lukkes vinduet igen og indetemperatur stiger til 45 °C og
stabilisere sig.
8950-11150 sekunder
Natsænkningen er på forhånd sat til at begynde ved 8950 sekunder og til at køre over 1200
sekunder. Natsænkningen går i gang på det rigtige tidspunkt, og sænker indetemperaturen korrekt til
30°C hvor den så holdes. Som den er sat til, slår natsænkningen fra efter 1200 sek. og
indetemperaturen hæves igen til 45°C og derefter afsluttes testen.
9.3 Teknisk delkonklusion
De opstillede krav (jvf. 2.5.2) vil i det følgende blive behandlet en for en og der vil blive vurderet
om hvorvidt løsningen lever op til dem.
Først krav:
1. Det elektroniske system skal autonomt kunne overvåge temperaturen og på baggrund heraf
styre en radiator. Herunder:
a. Systemet skal kunne registrere om hvorvidt vinduet er åbent eller lukket på baggrund
af temperatur.
b. Systemet skal kunne udføre natsænkning.
c. Systemet skal kunne fungere som en termostat således, at en ønsket indetemperatur
opretholdes.
Kravet om at løsningen skal kunne overvåge temperaturen er, jvf. 5.3, opfyldt, idet der
implementeres 2 temperature sensorer i forbindelse med hardwaren. Overvågningen sker autonomt
idet MCU'en selv kan udføre temperaturmålingerne uden indblanding udefra.
Styringen af radiatoren er blevet testet og det ses at systemet er i stand til udfra temperaturen
korrekt at vurdere om vinduet er åbent eller lukket. Der kan registreres åbning af vindue som følge
af temperaturfald og lukning af vindue som følge af temperaturstigning. Systemet er istand til at
vurdere om temperaturstigningen virkelig skyldes vindueslukning eller anden påvirkning. Ligeledes
Side 80 af 113

Test af løsning
ses det at der udføres natsænkning på tilfredsstillende vis. Termostatfunktionen fungerer, dog med
mindre komplikationer, hvilket giver en vis ustabilitet under stabil tilstand. Denne ustabilitet
medfører at der fremkommer mindre temperatursvingninger der dog ikke er signifikante.
Andet krav:
2. Det elektroniske system skal ud over forbindelsen til PC’en kunne:
a. Formidle dets status og rumtemperatur.
b. Modtage ønsket temperaturindstilling.
c. Modtage tidsramme for natsænkning.
Det kan konkluderes at det er lykkedes på tilfredsstillende vis at oprette en forbindelse mellem
PC'en og MCU'en. Over denne forbindelse sendes der fra MCU'en temperaturer, radiatoreffekt og
vinduestilstand og fra PC'en sendes den ønskede indetemperatur og det kan dermed konkluderes at
krav 2.a og 2.b er opfyldt. Det er jvf. 7.3 imidlertid ikke lykkedes at køre natsænkningen fra
MCU'en og den er derfor blevet flyttet over på PC'en. Dette betyder at det elektroniske system ikke
modtager tidsramme for natsænkningen, men istedet sendes nattemperaturen som ny ønsket
indetemperatur. Dermed kan natsænkningen ikke udføres autonomt, hvilket gør at det ikke er
lykkedes at gøre det elektroniske system til en "stand-alone" enhed.
Tredje krav:
3. PC-softwaren skal kunne opsamle information fra det elektroniske system og
præsentere disse til brugeren samt formidle brugerens ordrer til det elektroniske system,
hvor de danner grundlag for reguleringen.
Det er lykkedes at skabe software til PC'en der er istand til at opsamle data fra MCU'en og
præsentere disse på skærmen på forskellig vis og ligeledes kan opsamle data fra brugeren og
videresende disse til MCU'en. Dermed er krav 3. opfyldt.
Fjerde krav:
4. Produktet skal konstrueres således at det fungerer under kontrollerede forhold i en
forsøgsopstilling med en elektrisk radiator, men skal ligeledes konstrueres på en sådan
vis, at det uden alvorlige komplikationer skal kunne implementeres i en virkelig bolig.
Udfra de ovenforstående konklusioner ses det at det elektroniske system fungerer tilfredsstillede i
den fysiske model. Det må dog ligeledes konkluderes at løsningen ikke umiddelbart kan
implementeres i en virkelig bolig idet den matematiske model som reguleringen er bygget på
baggrund af, kun gælder i den fysiske model. Hvis der udvikles en matematisk model på baggrund
af en virkelig bolig er der dog ikke noget i vejen for at løsningen skulle kunne implementeres deri.
Krav 4. er altså tildels opfyldt.
Side 81 af 113

10.0 Teknologi vurdering
Teknologi vurdering
Vi vil i dette kapitel gennemføre en teknologivurdering af ET og i den forbindelse vil vi
koncentrere os om to seperate analysefelter:
− Det intelligente hus og dets bruger
− Udviklingen af det danske IT samfund
Vi søger ikke at give en tilbundsgående analyse af disse to analysefelter, men vil hovedsageligt
benytte eksempler, som er vores bud på felternes status og udvikling.
I analysen af det ”Det intelligente hus og dets bruger” vil vi arbejde videre med de forestillinger
omkring det intelligente hus, som vi udviklede i problemanalysen (jvf. 2.4), men med fokus på
brugeren i stedet for på teknikken.
Da ET endnu er en ny trend i den teknologiske udvikling, mener vi, at det er for tidligt at give en
konkret vurdering af dens samspil med samfundet. Derfor vil vi i stedet kigge på de bredere
perspektiver i den danske udvikling mod et IT samfund. Dette mener vi er relevant fordi ET
”trenden” unægtelig er en del af denne og derfor i vid udstrækning sammenlignelig hermed.
10.1 Det intelligente hus og dets bruger
I forbindelse med det intelligente hus og dets bruger kunne det være interessant at kigge på hvorfra
ideerne og initiativerne omkring det intelligente hus stammer fra. Det kunne med andre ord være
interessant at analysere om det er brugeren der kræver denne teknologi eller om det er industrien,
som prøver at påvirke markedet på en sådan måde at der skabes efterspørgsel efter denne teknologi.
For nyligt fik 50 familier i Ballerup installeret køleskabe med indbyggede skærme i
køleskabsdøren[Nordhagen]. Skærmen kan bruges som web-portal og giver derfor mulighed for at
trække på internettets ressourcer fra køkkenet, f.eks. kan den bruges til opslag af forskellige
madopskrifter eller til at kontrollere bustiderne. Disse køleskabe er sponsoreret af en række
virksomheder bl.a. Ericsson og Tele Danmark. Hele ordningen er ment som et forsøg, der skal give
producenterne mulighed for at afprøve den nye teknologi på forbrugerne, så erfaringerne kan bruges
til at modne producenternes produkter inden påbegyndelse af en storstilet markedsføring. Dette
tyder på, at producenterne har et produkt de gerne vil af med, men de er nød til først at finde et
passende marked til det. Dette gøres gennem forsøgsordninger som den ovenbeskrevne, men disse
ordninger, som påkalder sig medieopmærksomhed, forstærker også forbrugernes interesse og
forbereder dem på fremtidens produktvalg.
Et andet tegn på, at der ikke er tale om market pull, dvs. markedet for produktet skabes af
forbrugernes ideer og initiativer, er den nuværende udbredelse af systemer til intelligent styring i
huse. Der findes i dag færdige systemer til intelligent styring af lys og varme m.m., f.eks. kan
nævnes Intelligent House Control 31 (IHC), som er udviklet af det danske firma LK [LK]. Men da
priserne for disse systemer ligger ca. 50% over priserne for almindelige installationer [Hvidfeldt],
finder de ikke stor udbredelse, fordi aftagerne ikke er overbeviste om at disse systemer er kan tjene
sig selv hjem i form af komfort og ressourcebesparelser.
Det er vores opfattelse, at den almindelige danske forbruger endnu ikke er villig til at investere i
produkter af denne type som leder udviklingen hen imod det intelligente hus. Vi mener dog, at de
initiativer producenterne iværksætter i samspil med folks generelle stigende IT bevidsthed vil skabe
et stort marked for disse teknologier i fremtiden. Specielt tror vi, at udviklingen vil accelerere når
31 Dette system er i Danmark installeret i et omfang af flere tusinde parcelhuse [Hvidfeldt]
Side 78 af 113

Teknologi vurdering
priserne på intelligente applikationer når et leje, som ikke er markant højere en priserne på
konventionelle installationer.
Der er dog et område hvor brugen af intelligente applikationer i hjemmet er nået længere end i den
brede danske befolkning. Det drejer sig om produkter som kan hjælpe handicappede med en række
opgaver såsom åbning af døre og vinduer eller automatisk tænd og sluk af lys. Grunden til at
integrationen af intelligente produkter synes at gå lettere når det drejer sig om handicappede,
skyldes, at der på dette område er større tradition og behov for at tilpasse omgivelserne til
brugeren. Desuden er brugergruppen af handicappede mere bevidste om hjælpemidlernes
brugsværdi. En undersøgelse foretaget af center for tilgængelighed har sammenlignet to
bofællesskaber for unge med fysisk funktionsnedsættelse, hvoraf det ene i bredt omfang har
installeret intelligente hjælpemidler. Konklusionen på undersøgelsen er, at de intelligente produkter
giver beboerne større handlefrihed og større livskvalitet [Hvidtfeldt]. Undersøgelsen påpeger i
øvrigt, at beboerne i bofællesskabet med de intelligente produkter, gerne så mere intelligens i
produkterne. F.eks. påpeger de at stemmestyring som en mulig forbedring af det nuværende system,
som betjenes med en fjernbetjening.
Et andet interessant aspekt i forholdet mellem brugeren og det intelligente hus er de forventninger
brugeren har til dette intelligente hus. Argumentationen for det intelligente hus, som den ofte
fremkommer i medierne er, at den kan spare tid for forbrugeren og øge forbrugerens komfort, samt
spare ressourcer.
Argumentet omkring tidsbesparelse, mener vi, dog er noget vagt idet den tid det tager at slukke
kontakter og regulere på termostater nærmest er negligeabel. Dog kan man forestille sig, at ”det
intelligente hus” i fremtiden kan blive så intelligent, at argumentet om tidsbesparelse bliver
væsentligt. F.eks. hvis huset i fremtiden selv kan administrere dagligdags indkøb.
Det intelligente hus, mener vi, kan bidrage til brugerens komfort. Hvis for eksempel et sommerhus
selv overvåger ejerens kalender over internettet og automatisk sætter varme på hvis ejeren har
skrevet i kalenderen at han/hun tager i sommerhus i weekenden. Hvis det intelligente hus skal øge
brugernes komfort er det dog et krav at det skal kunne skelne imellem de enkelte beboere og deres
ønsker for at undgå at blive et irritationsmoment snarere end en hjælp, fordi det intelligente hus går
fejl af brugernes ønsker.
Endeligt, mener vi, at argumentet omkring ressourcebesparelse er det mest holdbare, da f.eks.
automatisk lysstyring eller et varmestyringssystem vil kunne spare energi (jvf. afsnit 2.1.7).
Vi ser i det intelligente hus en fare i, at det kan medvirke til at folk lettere kan lade sig isolere i
deres hjem. Dette kan de fordi det intelligente hus og udbredelsen af internettet gør, at det ikke er
nødvendigt at forlade huset for at gå på arbejde, handle eller underholde sig.
Man kan frygte er der sker en ligende udvikling som den der skete da boligmassen ændrede sig fra
lejlighedskomplekser til parcelhuse i 60’erne og 70’erne. Det medførte dengang at familierne blev
”kernefamilier” som i højere omfang befandt sig i hjemmet end før denne udvikling hvor der var
mere social kontakt pga. de trangere kår i boligkomplekserne. En ændring af hjemmet kan altså føre
til en ændret social adfærd.
Omvendt kunne det også tænkes at det intelligente hus af førnævnte årsager, kunne frigive så
meget tid til brugen at denne har mere tid til at engagere sig socialt. Højst sandsynligt vil vi i
fremtiden se begge muligheder.
10.2 Udviklingen af det danske IT samfund
Side 79 af 113

Teknologi vurdering
Vi vil under denne gennemgang af det danske IT samfund ikke gøre nærmere rede for hvad et IT
samfund er, men blot definere det som: Et samfund hvori informationsteknologi i vid udstrækning
er integreret både blandt private og hos det offentlige.
Vi vil ved hjælp af SWOT-analysens betragte det danske samfund som en samlet organisme der
forsøger sig at tilpasse sig i forhold til dets omgivelser, dvs. det internationale samfund. Vi vil med
dette analyseværktøj først give et situationsbillede af det danske IT samfund, hvorefter vi vil
beskrive mulige strategier til at formindske fundne svagheder og strategier til stadig udvikling af
styrker.
På baggrund af denne analyse forventer vi at kunne vurdere hvilke parametre en markedsoperatør i
det danske IT samfund, bør være opmærksom på, samt hvilke strategier, der kan styrke den danske
IT udvikling og hermed også integrationen af embeddede systemer.
10.2.1 Situationsbillede af det danske IT-samfund
Følgende beskrives en række af styrker, svagheder, muligheder og trusler, som vi ser dem i det
danske samfund nu. Slutteligt opstilles en SWOT-matrice, som giver et samlet overblik over de
behandlede emner.
Styrker i det danske IT samfund:
Danmark er et rigt land med en sund økonomi, dette er en styrke for udviklingen mod et stærkere
IT samfund, fordi denne udvikling kræver investeringer fra såvel private som offentlige
institutioner. F.eks. kræver det store infrastrukturelle investeringer at opretholde en tilpas
båndbredde i datatransmissionsnetværket til at sikre, at både virksomheder, private og offentlige
myndigheder kan kommunikere med tilstrækkelige hastigheder.
Det høje danske uddannelsesniveau er en anden styrke, som sikrer at danskere generelt har let ved
at bruge den nye teknik og dens muligheder. Desuden sikrer det høje uddannelsesniveau, at
Danmark kan producere bytteværdi, dvs. viden og egentlige produkter, som vi kan udveksle med
andre lande og derved øge vores egen know-how og mængden af arbejdsmidler.
Svagheder i det danske IT samfund:
En svaghed ved det danske IT samfund er den gruppe af befolkningen, som ikke
uddannelsesmæssigt, interessemæssigt eller økonomisk kan deltage på lige vilkår med resten af
befolkningen i denne udviklingsproces. Faren består i at yderligere polarisering mellem den gruppe
der forstår at udnytte IT og den der ikke gør, kan skabe sociale skel mellem de to forskellige
grupper.
En anden svaghed i det danske IT samfund er det begyndende problem med manglende
kvalificeret arbejdskraft. I det øjeblik IT stillinger står ledige sænkes udviklingstempoet af det
danske IT samfund og vi begynder at miste terræn til andre nationer.
Muligheder i det danske IT samfund:
Styrkerne i det danske IT samfund sikrer at vi har mulighed for at være aktive aktører på
internationalt plan, fordi vi producerer viden og teknologiske produkter, som kan afsættes på det
internationale marked.
Fordi Danmark allerede er nået så langt med udviklingen af IT samfundet som vi er, giver det os
mulighed for politisk at påvirke både det internationale samfund, samt de lande som aktivt følger
udviklingen i Danmark for at lære af os.
Side 80 af 113

Teknologi vurdering
Endvidere er der gode muligheder for at IT samfundet kan bidrage til en styrkelse af demokratiet i
Danmark. Udbredelsen af internettet gør, at der opstår flere forummer for politisk diskussion og det
styrker den danske tradition om ytringsfrihed, fordi det giver enkeltmand mulighed for let og frit at
publicere egne ideer og deltage i diskussioner.
Trusler mod det danske IT samfund:
Man kan forstille sig, at Danmark i fremtiden er for lille en enhed, til at kunne bevare sin integritet
som et selvstændigt samfund, fordi den teknologiske udvikling vil bidrage til en så kraftigt
liberalisering af den internationale økonomi. I en meget liberal international økonomi vil den
samlede danske økonomi kun være en meget lille brik, som ikke længere beskyttes af national
protektionisme.
Som før nævnt vil mangel på kvalificeret arbejdskraft kunne svække det danske IT samfund. En
trussel er herfor vores fortsatte evne til at producere denne arbejdskraft. For at kunne producere
denne må optagelsen til de IT kompetencegivende uddannelser øges i en tid hvor
ungdomsårgangene i forvejen er små. Desuden vælger mange unge med danske IT uddannelser i
dag at søge arbejde i udlandet, hvilket følgelig bidrager negativt til det danske arbejdsmarked.
På figur 10.1 er de
ovenbehandlede emner placeret i
SWOT-matricen for at give et
samlet overblik. De i denne
analyse behandlede emner, udgør
selvfølgelig kun en lille del af den
samlede mængde parametre som
har indflydelse på udviklingen af
det danske IT samfund. På trods
af identificerede svgaheder er det
klart, at Danmark sammenlignet
med andre lande, er nået langt i
udviklingen mod IT samfundet.
Styrker
Stærk økonomi.
Godt uddannelsesniveau.
Muligheder
Eksport af viden og produkter.
Politisk indflydelse.
Styrkelse af demokratiet.
10.2.2 Strategier til styrkelse af det danske IT samfund
Svagheder
Sociale skel.
Mangel på IT arbejdskraft.
Trusler
Danmark er for lille et land.
Mangel på IT arbejdskraft.
Figur 10.1 – SWOT matricen opstillet for det danske IT samfund
Vi vil i dette afsnit prøve at opstille strategier, som kan afhjælpe de problemer som blev
identificeret i sidste afsnit, samt styrke de fundne styrker og muligheder yderligere. Disse opstilles i
en udbygget SWOT-matrice (se figur 10.2), hvor strategierne samles under overskrifter som f.eks.
Maxi-Mini, alt efter hvordan strategierne forventes at indvirke på det par af styrker, svagheder,
muligheder eller trusler, som strategien forbinder (jvf. figur 10.2). F.eks. vil en Maxi-Maxi strategi
på en gang forsøge at maksimere både organisationens styrker og muligheder.
Vi vil under beskrivelsen af hver af vores foreslåede strategier endvidere forsøge at vurdere
hvorvidt der i det danske samfund er kræfter, som forsøger sig med denne strategi for at styrke IT
samfundet, heriblandt er det klart at folketinget og dermed det offentlige spiller en stor rolle.
Side 81 af 113

Eksterne muligheder
Eksport af viden og produkter
Politisk indflydelse
Styrkelse af demokratiet
Eksterne trusler
Danmark et for lille land
Mangel på IT arbejdskraft
Teknologi vurdering
Interne styrker
Stærk økonomi.
Godt uddannelsesniveau.
Maxi-Maxi strategier
Økonomiske investeringer i
uddannelse, forskning og
infrastruktur.
Maxi-Mini strategier
Indgå i transnationale politiske
fællesskaber.
Interne svagheder
Sociale skel.
Mangel på IT arbejdskraft.
Mini-Maxi strategier
Iværksættelse af bred
efteruddannelse, samt
tilpasning af eksisterende
uddannelser.
Mini-Mini strategier
Figur 10.2 - De vha. SWOT-analysen fundne strategier til styrkelse af det danske IT
samfund.
Tilpasse arbejdsmarkedet
således, at det er attraktivt for
højtuddannet arbejdskraft.
Maxi-Maxi strategi
Som eksempel på en Maxi-Maxi strategi har vi foreslået investeringer i uddannelse, forskning og
infrastruktur. F.eks. vil investeringer i elektronisk infrastruktur, forøge brugernes muligheder for at
anvende den nye teknologi, idet en øget båndbredde f.eks. vil kunne realisere digitalt TV.
Som et eksempel på en anvendelse af denne strategi kan det fremhæves, at folketinget netop har
bevilget 50 mio. kroner til oprettelse af et institut for forskning i energi fra vindmøller [JP], dette
sker bl.a. for at styrke den danske vindmølleindustri og derved styrke den danske eksport.
Maxi-Mini strategi
Hvis Danmark vil minimere truslen af at være et "lille land", må vi sørge for at indgå i en række
samarbejder med andre lande, som sigter på at sikre national stabilitet og vækst. Som et eksempel
på et sådant samarbejde kan Danmarks medlemsskab af f.eks. OECD 32 nævnes.
Mini-Maxi strategi
Et middel til at minimere de skel i befolkningen som skyldes, at ikke alle mestrer den nye
informations teknologi er efterudannelse. Efteruddannelse kan både medvirke til at give ukyndige
bassale IT kundskaber og til omskoling af folk, så de kan varetage nye arbejdsopgaver i IT
samfundet. Regeringen har eksempelvis ydet støtte til ”PC-kørekort”, som netop er en uddannelse
som giver eleven et basalt kendskab til brug af informationsteknologi.
Mini-Mini strategi
For at undgå mangel på kvalificeret arbejdskraft pga. for få nyuddannede og fraflytning af højt
uddannede til udlandet, må både folketinget og det private erhvervsliv aktiv søge at gøre det danske
arbejdsmarked til et attraktivt arbejdsmarked for arbejdssøgende i IT branchen. For at sikre fortsat
social retfærdighed må denne udvikling selvfølgelig rettes mod hele arbejdsmarkedet og ikke kun
den del hvor der er mangel på arbejdskraft.
32 OECD: Organisation for European Economy and Development.
Side 82 af 113

Teknologi vurdering
Et eksempel på anvendelse af denne strategi er det faktum, at private virksomheder i dag i større
omfang tilbyder deres medarbejdere aktie-optioner i virksomheden, som en del af lønnen
[Ingeniøren].
Hvis den her gennemførte analyse af mulige strategier til styrkelse af det danske IT samfund skal
sammenholdes med embedded technology, kan det fremføres at vores Maxi-Maxi strategi kan
bruges i forbindelse med ET. Hvis f.eks. der investeres i ET systemer, som kan lette
administrationsarbejdet i f.eks. forskningssektoren, vil der blive frigjordt ressourcer, som kan
anvendes til en styrkning af forskningsindsatsen. Denne styrkelse resulterer i, at Danmark vil få
bedre muligheder for at afsætte viden og produkter på det internationale marked.
10.3 Afrunding på teknologivurderingen
I det første analysefelt: ”det intelligente hus”, vurderede vi at, vi i øjeblikket befinder os i en fase
hvor erhvervslivet modner forskellige produkter til det intelligente hus. Når den fase er afsluttet
forventer vi, at se en forøget markedsføring af disse produkter, da vi mener, at producenterne selv
må ud og påvirke markedet for at skabe en stor efterspørgsel blandt forbrugerne.
Vi diskuterede hvilke fordele forbrugeren forventer sig af det intelligente hus og vurderede, at det
umiddelbart ikke nu er muligt at indfri disse forventninger, men at udviklingen med tiden kan
modne teknologien tilstrækkeligt dertil.
Endvidere pointerede vi, at en udvidelse af hjemmets muligheder vil kunne føre til en ændret
social adfærd, som kan bevæge sig i en positiv- og/eller negativ retning.
Ved brug af SWOT-analysen gav vi en beskrivelse af det danske IT samfunds styrker, svagheder,
muligheder og trusler, og herunder vurderede vi, at Danmark, sammenlignet med andre lande, er
godt i gang med udviklingen frem mod IT samfundet.
Desuden foreslog vi forskellige strategier, som efter vores vurdering, kan bidrage til styrke det
danske IT samfund yderligere, samt samtidig minimere dets svagheder. Herefter eksemplificerede
vi hvordan der kan være sammenhæng mellem de foreslåede strategier og brugen af embedded
technology.
Side 83 af 113

11.0 Konklusion
Konklusion
I konklusionen vil de enkelte underdele af rapporten (jvf. III) som er analyse, løsning og vurdering
blive behandlet hver for sig. Derefter samles disse i en endelig konklusion på projektet.
Analyse
Gennem den proaktive problemanalyse blev det klart at der var et muligt marked for embedded
technology herunder automatisk radiatorstyring. På baggrund blev der opstillet en række krav til en
embedded automatisk radiatorstyring hvorefter disse krav blev tilpasset til et omfang der var
passende for dette studieprojekt.
Under modelleringen lykkedes det at opstille en brugbar matematisk model for et afgrænset fysisk
system. Dette gav os et grundlag for forståelse af systemets opførsel.
Løsning
Den i modelleringen opnåede forståelse af systemet satte, sammen med de fysiske forsøg, os istand
til at udvikle en reguleringsalgoritme, der med inde og ude temperaturen som input er i stand til at
regulerer efter en bestemt temperatur og detekterer vinduets tilstand.
For at kunne implementere denne reguleringsalgoritme blev der designet en single board computer
samt temperaturmålere, kredsløb til effekt og spændings regulering.
Desuden lykkedes det at bruge seriel kommunikation til at forbinde single board computeren og en
PC, hvorved en bruger kunne kommunikere med det embedded system. Endvidere gav vi et
eksempel på en interaktiv brugerflade, hvorfra en bruger kunne påvirke reguleringen.
Vurdering
Resten af konklusionen tilgår mandag.
Side 79 af 113

12.0 Litteraturliste
Konklusion
Litteraturlisten er opbygges således, at forfatteren er anført med efternavnet først. I tilfælde af at
der ikke er anført en egentlig forfatter benyttes den instans der har stået for kilden som forfatter.
Derefter anføres kildens udgivelse år i parentes og kildens titel i kursiv. Så følger udgave, oplag,
forlag og ISBN-nummer. Ved internet kilder angives efter titlen http-adresse, samt download dato.
Der refereres efter det først ord og listen er opstillet i alfabetisk orden.
Auken, Svend (2000) Energi 21 - Regeringens energihandlingsplan 1996, 2. oplag,
ISBN: 87-7844-057-2
Blomberg (2000) Blomberg, http://www.blomberg.dk, 18. Marts 2000
Boligministeriet (1995) Bygningsreglement, Bygge og Boligstyrelsen, ISBN: 87-90247-01-9
Both, Erik & Christiansen, Gunnar (1995) Termodynamik, 3. oplag, Den private Ingeniørfond,
ISBN: 87-7381-056-8
Christensen, Kaj og Petersen, B. Howald (1987) Fjernvarme, Polyteknisk Forlag,
ISBN: 87-502-0649-4
Dansk Standardiseringsråd (1983) Dansk Standart i Bygningsreglement 82, 1. udgave
Dyck-Madsen, Søren (2000) Handlingsplan for Energibesparelser – Et forslag til principper og
indsatsområder, http://www.ecocouncil.dk/, 16. Februar 2000
Finansministeriet (1999) Evaluering af grønne afgifter og erhvervene 1999, ISBN: 87-7856-233-3
Haugen, Finn (1994) Regulering av dynamiske systemer, Tapir, ISBN: 82-519-1433-7
Hvidtfeldt, Peter (2000) Det tænkende hus, Jyllandsposten, Viden Om, 28. februar 2000
Hørup Sørensen, Henning (1996) Ventilations Ståbi, 2. udgave, Jydsk Centraltrykkeri A/S,
ISBN: 87-571-1982-1
Intel (1986) 80386 databook, version 003, Intel Corp.
Koffman, Eliot B. (1995) Turbo Pascal, 5. udgave, Addison Wesley Publishing Company Inc.,
ISBN: 0-201-51219-4
Miljø- og energiministeriet '98 (1998) Redegørelse om Dansk energipolitik 1998
http://www.ens.dk/pub/epr98.htm, 16. februar 2000
Miljø- og energiministeriet '99 (1999) Redegørelse om Dansk energipolitik 1999
http://www.ens.dk/pub/epr99.htm, 16. februar 2000
Nordhaugen, Poul (2000) På nettet via køleskabet, Jyllandsposten, Erhverv og Økonomi, 12. marts
2000-05-16
Side 80 af 113

Konklusion
Peacock (2000) Beyondlogic, http://www.beyondlogic.org, 2. februar 2000.
Poulsen, Henrik og Paulsen, Otto (1996) Standardsystemer for større brugerinstallationer, 1.
oplag, 1. udgave, Dansk Teknologisk Institut, ISBN: 87-77756-451-0
Rambøll (2000) Rambøll, http://www.ramboll.dk/energy/dk/fjernvarme.htm, 2. Marts 2000
Siemens (1991) Microcomputer Components - SAB80515 / SAB80C515 Family, ed. 5.93, Siemens.
Statens Byggeforskningsinstitut (1980) Indeklimaets påvirkninger, ISBN: 87-563-0303-3
Strandgaard Andersen, Erik mfl. (1998) DATABOG fysik kemi, 10. udgave, 2. oplag, F&K
forlaget, ISBN: 87-872-2959-5
Svith, Flemming (2000) Når maskinerne erobre internettet, Jyllandsposten, 7. februar 2000
Teknologisk Institut (1980) Varmeregulering i parcelhuse
Texas (1996) Datablad for TL16C550A, Texas Instruments.
Valbjørn, Ole (2000) Indeklimaproblemer, ISBN: 87-563-0880-9
Side 81 af 113

1 Bilag nr. 1: Laplace
Funktioner :
T(t) - Indetemperaturen som funktion af tiden
U(t) - Udetemperaturen som funktion af tiden
R(t) - Radiatoreffekten som funktion af tiden
Konklusion
Differentialligningen for systemet opstilles på baggrund af 2.3.4:
d(
T(
t)
⋅C
luft
T(
t)
+ U(
t)
+ ⋅(
C
2
dt
vindue
+ C
vægge
Ligningen for systemet i arbejdspunktet er:
0 = R(
0)
+ A
vindue
)
= R(
t)
+ A
vindue
x.1
U ( 0)
− T ( 0)
⋅
R + R
overgang
x.2
vindue
+ A
U(
t)
−T
( t)
⋅
R + R
vægge
vindue
vindue
overgang
+ A
U ( 0)
− T ( 0)
⋅
R + R
overgang
vægge
U(
t)
−T
( t)
⋅
R + R
De to ovenstående ligninger x.1 og x.2 substraters og giver dermed arbejdspunktsligningen:
vægge
overgang
∆T&
( t)
+ ∆U&
( t)
⎛ A
A ⎞
vindue
vægge
∆T&
( t)
⋅C
luft +
⋅(
Cvindue
+ Cvægge
) = ∆R(
t)
+ ⎜
+
⎟ ⋅(
∆T
( t)
− ∆U
( t))
2
⎜ Rvindue
Rovergang
Rvindue
R ⎟
⎝ +
+ overgang ⎠
x.3
Da Udetemperaturen regnes konstant elimineres ∆U(t) i x.3:
∆T&
( t)
⎛ A
A ⎞
vindue
vægge
∆T&
( t)
⋅C
luft + ⋅ ( Cvindue
+ Cvægge
) = ∆R(
t)
+ ⎜
+
⎟ ⋅ ∆T
( t)
2
⎜ Rvindue
Rovergang
Rvindue
R ⎟
⎝ +
+ overgang ⎠
x.4
Arbejdspunktsligningen laplacetransformeres:
⎛
s⎜
∆ T ( s)
⋅C
luft
⎝
∆T
( s)
⎞ ⎛ Avindue
+ ⋅ ( Cvindue
+ Cvægge
) ⎟ = ∆R(
s)
+ ⎜
2
⎠ ⎜
⎝ Rvindue
+ Rovergang
x.5
A ⎞
vægge
+
⎟ ⋅ ∆T
( s)
Rvindue
+ R ⎟
overgang ⎠
Der løses for overføringsfunktionen:
∆T
( s)
=
∆R(
s)
⎛
s⎜C
⎝
luft
1
+ C
2
vindue
1
+ C
2
vægge
1
⎞
) ⎟ +
⎠ R
x.6
vindue
Side 82 af 113
A
vindue
+ R
overgang
+
R
vindue
A
vægge
+ R
overgang

Der indsættes konstanter:
Rvindue = kvindue / ∆xvindue = 0.004 / 0.17 = 0.024
Rvægge = kvægge / ∆xvægge = 0.05 / 0.039 = 1.28
Avindue = 0.034
Avægge = 1.48
Cluft = cluft ⋅ mluft = 1.00 ⋅ 164 = 164
Cvindue = cvindue ⋅ mvindue = 1.5 ⋅ 160 = 240
Cvægge = cvægge ⋅ mvægge = 1.2 ⋅ 1500 = 1800
Rovergang = 0.17
∆T
( s)
=
∆R(
s)
s ⋅
Konklusion
1
1184
+
∆T
( s)
0.
836
=
∆R(
s)
s ⋅ 990 + 1
1.
195
Side 83 af 113
⇔

1.1 Bilag nr. 2: Fysmod
Datablad: Fysiske model
Konklusion
Data for de materialer vi bruger i vores model[strandgaard]: Ved 0° og 101,3kPa ∼ 1 amt.
Væggene (flamingo).
Varmekonduktivitet (λ) = 0,039 [W/m⋅K]
Specifik varmekapacitet 33 (c) = 1,2 [J/(kg⋅°C]
Vinduet (plexiglas).
Varmekonduktivitet (λ) = 0,17 [W/m⋅K]
Specifik varmekapacitet = 1,5 [J/(kg⋅°C]
Luft.
Specifik varmekapacitet (c) = 1,0 [J/(kg⋅°C]
Fysiske konstanter:
Kasse overflade-areal indvendig.
1,48m 2
Vinduets areal.
0,034m 2
Luftens masse (indvendig).
164,02g
Tykkelsen af væggene (flamingo).
0,05m
Tykkelsen af vinduet (plexiglas).
0,005m
33 Denne værdi er oplyst af Thermisol der markedsfører flamingoen i Danmark
Side 84 af 113
Fig. Bilag1: Billede af vores fysiske model.

Radiator resistans:
Rradiator=37.2Ω
Vægten af væggene.
1,5kg
Vægten af vinduet.
160g
Konklusion
Opbygning af den fysiske model.
Den fysiske model er opbygget af flamingo, hvori der er indsat et vindue af plexiglas. Vinduet er
monteret med hængsler, således at vinduet kan åbnes og lukkes. For at vinduet kan lukkes, således
at den er fuldstændig tæt er der monteret en stykke træ til at spænde vinduet fast med.
Væggene er limet sammen. Vinduet er først fast sat til en træ-plade, som er limet fast til selve
kassen. Kassens låg er skåret skrå, for at tætne kassen bedre.
Side 85 af 113

2 Bilag nr. 3: Forsøgsbeskrivelser
1. Forsøg
Konklusion
Formål:
Formålet med dette forsøg, er at give et billede af, hvordan temperaturen i et rum opfører sig med
tiden, under forskellige forhold. Dette billede skal så sammenlignes med et teoretisk billede fra
vores matematiske model.
Opstilling:
Forsøget er opstillet som vist i fig. Bilag2, hvor radiatoren ligger på en træplade i midten af
kassen.
Derudover sidder der 3 temperatursensore i kassen(se fig bilag1). Den 1. Sidder 3cm under vinduet
midt for, den anden sidder midt i rummet ca.2 cm under loftet og den tredje sidder midt i rummet ca
15 cm under loftet. Disse er koblet til en datalogger. Til sidst ligger der et termometer lige ved siden
af kassen(højre side når man kigger på vinduessiden udefra).
Kassen er opbygget som kan ses i fig. bilag1. Som Amperemeter, og voltmeter er brugt to
multimetre af typen METEX M-3800 og strømforsyningen er af typen 2422-529
Som termometre bruger vi 3 termometre af typen CI-650A TEMPERATURE SENSOR som er
tilkoblet en datalogger af typen SCIENCE WORKSHOP r 750 INTERFACE MODEL CI7500 samt
et termometer af typen QUARTS DIGI-THERMO (A40) til måling af udetemperatur. Som elektrisk
varmekilde, har vi bygget en ”radiator” bestående af en træramme omviklet med 5.1 meter
kantaltråd af 0,5mm tykkelse. De to ender er gennem krokodillenæb sat til strømforsyningen. Selve
kassen er sat op på 4 mindre stykker flamingo(af samme type) for at undgå berøring mellem kasse
og underlag.
Udførelse:
Vi startede med at foretage vores først aflæsning af termometrene, samtidig med at vi satte
spænding over radiatoren. Denne satte vi til 34,4V (målt på voltmeteret), og vi målte 1,02 A på
amperemeteret. Dataloggeren logger en måling pr. 10.sek. og udetemperaturen aflæses jævnligt
igennem forsøget så udetemperaturen kunne holdes konstant. Da temperaturen efter 5000 sek.
nogenlunde havde stabiliseret sig, slog vi strømforsyningen fra radiatoren, og aflæste temperaturen
indtil temperaturen igen havde stabiliseret sig.
Resultat:
Disse to forsøg gav os følgende resultater (se discbilag forsøg1_1 og forsøg1_2) Graferne over
resultaterne kan ses på fig. 3.4 og 3.5 .
Fejlkilder:
Ved videre brug af dette forsøg, skal der tages hensyn til at der er nogle usikkerheder/fejlkilder i
forsøget. De første af dem er ved bygning af kassen:
Limen brugt til samling af vægge og gulv på kassen, kender vi ikke massefylde, varmekapacitet
eller varmeledningskoefficient på. Målene på kassen antager at lågets top sænkes helt ned i plan
med væggenes top, dette passer dog ikke helt i praksis, dvs. at lidt af låget(mellem 5 og 20 mm )
stikker udenfor, hvorved randforholdende ændres lidt. Derudover skal det huskes at da låget er
bygget så det kiler sig fast, vil det ikke sidde helt tæt til væggene i hele lågets tykkelse. Endvidere
er der også huller til termometrene, da disse stikkes ind igennem loft og vægge udefra, og utæthed
Side 86 af 113

Konklusion
ved vinduet samt ujævnheder i materialet. Derudover er der nogle fejlkilder i selve målingen af
forsøget. Vi har kunne se at termometrene er noget uenige om temperaturen(+- op til næsten 2
grader celsius), samt en usikkerhed i måleapparaterne(usammenhæng mellem effekt målt via
modstand og spændingsmåling og effekt målt via spænding og strømmålinger.
2. Forsøg
Formål:
Formålet med dette forsøg, er som i 1. forsøg at give et billede af, hvordan temperaturen i et rum
opfører sig med tiden, denne gang dog ved åbning af vinduet efter temperatur stabilisering med
konstant effekt på radiatoren. Dette har til formål at undersøge om det kan aflæses direkte på
temperaturen om vinduet er åbent eller lukket.
Opstilling:
Forsøget er opstillet som i 1. Forsøg.
Udførelse:
Vi startede igen med at vi foretage vores først aflæsning af termometrene, samtidig med at vi satte
spænding over radiatoren. Denne satte vi til 33,5V(målt med voltmeter) og amperemeteret viste
1,07 A. Vi aflæste så termometrene hver 10. sek. Da temperaturen efter ca.7500 sek.. nogenlunde
havde stabiliseret sig, åbnede vi vinduet og afventede igen en stabil tilstand. Under hele forsøget
holdt vi ”ude” temperaturen i laboratoriet konstant.
Resultat:
Dette forsøg gav os følende resultater (se discbilag forsøg2). For graf over resultaterne se fig. 4.2.
Fejlkilder:
Fejlkilderne er de samme som ved forsøg 1.
3. Forsøg
Formål:
Formålet med dette forsøg, er som i 1. forsøg at give et billede af, hvordan temperaturen i et rum
opfører sig med tiden, denne gang ved lukning af vinduet efter temperatur stabilisering med slukket
radiatoren. Dette har til formål at undersøge om det kan aflæses direkte på temperaturen om vinduet
er åbent eller lukket.
Opstilling:
Forsøget er opstillet som i 1. Forsøg.
Udførelse:
Efter først at have forvarmet forsøgsrummet slukkede vi for radiatoren og åbnede vinduet. Under
den efterfølgende nedkøling aflæste vi termometrene hver 10.sek. Da temperaturen efter 4400 sek.
nogenlunde havde stabiliseret sig, lukkede vi vinduet igen og aflæste så videre i noget så vi igen
opnåede en stabil tilstand. Under hele forsøget holdt vi ”ude” temperaturen i laboratoriet konstant.
Side 87 af 113

Konklusion
Resultat:
Dette forsøg gav os følende resultater
(se discbilag forsøg3). For graf over resultaterne se fig. 4.3.
Fejlkilder:
Fejlkilderne er de samme som ved forsøg 1.
4. Forsøg
Formål:
Formålet med dette forsøg, er at undersøge størrelsen af fænomenet, om at væggene vil holde på
en del varme og at man derfor selv efter en umiddelbar stabilisering af temperaturen i et rum med
åbent vindue, vil kunne se på temperaturen at vinduet lukkes.
Opstilling:
Forsøget er opstillet med en datalogger af typen ECO-LOG ECL-4 stående på et bord i en afstand
af ca. 1 meter fra vinduet og i samme højde som bunden af denne. Dette forsøg er lavet i et
tilfældigt rum.
Udførelse:
Med lukket radiator åbnedes vinduet i et opvarmet rum. Temperaturen aflæstes af en datalogger
hver 10. Sek. Indtil en relativ stabil temperatur var opnået. Derefter lukkedes vinduet igen, stadig
med dataloggeren kørende som før. Efter noget tid afsluttedes forsøget.
Resultat:
Dette forsøg gav os følende resultater (se discbilag forsøg4). For graf over resultaterne se fig. 4.4
Fejlkilder:
Der kan være en usikkerhed i måleinstrumentet, dog regnes denne for ubetydelig. Den største fejl
ligger nok i dårlig isolering ud til varmere rum i bygningen, hvilket kan have holdt rummet varmere
end ville være sket med kun væggene som faktore. Dog er denne ”fejl” tættere på det
gennemsnitlige tilfælde end et totalt isoleret (i forhold til andre rum) rum. Den sidste fejlkilde er at
komputeren som dataloggeren var selvfølgelig sat til og producerer også varme.
Side 88 af 113

3 Bilag nr. 4: Regulering
Termostatmodul:
Konklusion
1: difference temperatur = ønsket temperatur - indetemperatur
2: difference effekt = difference temperatur * 50
3: reel effekt = teoretisk effekt + difference effekt
4: hvis reel effekt > 50 så
5: reel effekt = 50
6: hvis reel effekt < 0 så
7: reel effekt = 0
Modul til registrering af åbning:
1: fra j=1 til j=119 gør
2: tabelplads j = tabelplads j+1
3: tabelplads 120 = indetemperatur
4: difference temperatur = tabelplads 120 – tabelplads 1
5: hvis difference temperatur < -5 så
6: vindue = åbent
Opvarmningstest:
1: testtemp = effekt * 0.0913 + udetemperatur
2: temperaturforskel = testtemp-indetemperatur
3: hvis temperaturforskel < -2 og temperaturforskel > 2 så
4: vindue = åbent
5: initialiser tabel til indetemperatur
Side 89 af 113

4 Computermodel:
Konklusion
1: Q = Indetemperatur * Samlet_Varmekapacitet
2: fra 0 til sluttid gør
3: udskriv: Indetemperatur og tid
4: Q=Q+Radiatoreffekt+Tab_fra_Vægge_og_Vindue
5: Indetemperatur=Q/Samlet_Varmekapacitet
6: udskriv: Tab_fra_Vægge og Tab_fra_Vindue
Simulering af åbning og lukning af vindue:
1: hvis tid = åbningstid så
2: vinduesisolans = lille
3: hvis tid >= lukningstid og tid

5 Bilag nr. 5: Diagram for SBC
Konklusion
Side 91 af 113

6 Bilag nr. 6: Diagram for det analoge print
Konklusion
Side 93 af 113

Litteraturliste
Bilag nr. 7: Seriel kommunikation - Pseudokode for udvalgte funktioner
Funktioner til buffer
Funktion: status()
1: returner (Statusvariabel)
Funktion: post (Dataelement)
1: hvis Statusvariabel>=Max_antal så returner 0 //Bufferen er overfyldt og der
returneres med fejlkode (0)
2: Vektor_med_dataelementer [lastpointer]=Dataelement //Gem data i bufferen
3: Statusvariabel= Statusvariabel +1; //Forøg statusvariabel
4: lastpointer= lastpointer +1 //Peg på næste frie plads
5: hvis lastpointer>(Max_antal-1) så lastpointer=0 //Wrapper pointeren?
6: returner (1) //Data gemt alt OK.
Funktion: retrieve (Dataelement)
1: hvis Antalelementer(Max_antal-1) så firstpointer=0 //Wrapper pointeren?
6: returner (1) //Data hentet returner OK
Funktioner til PC ISR
Funktion: Serielt_ISR()
1: hvis DataKlarBitten er sat så Modtag.post(Data_Fra_UART) //NB:Hvis bufferen er fyldt,
mistets data!
2: outportb (0x20,0x20); //Signaler til PIC at interruptet
Funktion: Sende_ISR()
er afsluttet
1: Så længe Sende.status()>0 så //Er der data at sende?
2: Vent til SendeKlarBitten er sat //Vent til UART er klar
3: Sende.retrieve(Data) //Læs data fra bufferen
4: outportb(basisadresse,data ) //Send data til
UART
5: outportb (0x20,0x20); //Signaler til PIC at interruptet
Bufferimplementation på MCU
Funktion: Post(data)
1: så længe SFLAG=0 så vent
er afsluttet
2: SBUF=data //Skriv data til UART
3: SFLAG=0 //Slet ”klar til at sende” flaget
Side 80 af 113

Funktioner til MCU ISR
Funktion:Serielt_ISR()
1: hvis interrupt skyldes sendt byte så:
Litteraturliste
2: SFLAG=1 //Sæt flag, så der kan sendes
3: TI=0 //Nulstil interrupt
4: hvis interruptet skyldes modtaget byte så:
5: hvis Statusvariabel>=Max_antal) så returner (0) //ER bufferen overfyldt?
6: Vektor_med_dataelementer [lastpointer]=SBUF //Gem data i bufferen
7: Statusvariabel=Statusvariabel+1 //Forøg status
8: lastpointer=lastpointer+1 //Peg på næste frie plads
9: hvis lastpointer>(Max_antal-1) så lastpointer=0 //Wrapper pointeren?
10: RI=0 //Nulstil interrupt
Side 81 af 113

7 Bilag nr. 8: MCU-pseudokode
Pseudokode for effekt-beregning:
Litteraturliste
Funktion: PBM(effekt)
1: hvis effekt>50 så effekt=50
//Undgå fencepost errors
2: CCH1=effekthigh[effekt] //Slå HI-byte op i
ROM-tabel
3: CCL1=effektlow[effekt] //Slå LO-byte op i
ROM-tabel
Pseudokode for protokol-fortolkningen:
1:hvis Antal_Elementer_I_Modtagebuffer > 0 så //Er der modtaget data?
2: Byte=Hent()
//Hent første element i buffer
3: hvis Byte =1 eller 2 så //Hvis ordre nr. er
1 eller 2
4: Vent til Modtagelse_Af_Næste_Byte
5: Ny_Ønsket_temperatur=hent() //Ny
reguleringstemperatur
6: hvis Byte=3 så
//Hvis ordre nr. er 3
7: post(3)
//Gentag ordre
8: post(indetemp)
//Send ønskede data
9: post(udetemp)
10: post(effekt)
Side 82 af 113

Bilag nr. 9: MCU-detaljer
Litteraturliste
Dette bilag indeholder yderligere detaljer omkring de enkelte periferi-enheder som bruges af
softwaren på MCU’en.
Analog til digital konverteren:
ADC’en styres af ADCON (ADC control) registret, som indeholder 3 bit, der bestemmer hvilket
ben signalet skal konverteres fra, en bit der bestemmer hvorvidt konverteringen skal ske løbende
eller kun foretages én gang og endelig en bit der angiver om ADC’en er i gang med en konvertering
eller ej. Efter opsætning af ADCON startes konvertering, ved at skrive til DAPR-registretet
(digital/analog converter program register), der desuden kan bruges til at justere
referencespændingen, hvilket vi ikke har gjort brug af. Ca. 15 mikrosekunder efter der er skrevet til
DAPR-registret, kan resultatet aflæses i ADDAT-Registret (ADC DATa).
Brug af timer 2 til PBM:
T2CON:
T2CON styrer den generelle opsætning af timer
2. Bit 0&1 bruges til at sætte timer 2 op som timer.
Bit 2&3 styrer hvornår timer 2 begynder at tælle
forfra, i vores tilfælde sættes den op til automatisk
at begynde forfra når den har nået maksimum.
Bit 4 sættes til 0, hvorved timer 2 automatisk
skifter output-signalet til højt, når timer 2 er lig
med sammenligningsregistret.
Bit 7 sættes til 1, hvilket bevirker at timeren
tæller en op for hver anden machine-cycle. Herved
opnås længere perioder og færre spændingsskift.
Figur 1.1 – Oversigt over T2CONregistret
Side 83 af 113
Bit nr. Funktion
7 Timer frekvens.
0: OSC/12
1: OSC/24
6 Ingen funktion ved PBM
5 Ingen funktion ved PBM
4 Sammeligningsfunktion
0: Mode 0 - Standard PBM
1: Mode 1 – SW kontrolleret PBM
2,3 Reload kilde:
0, 0 og 0, 1: Reload ikke aktiv.
1, 0: Reload ved timer 2 overflow.
1, 1: Reload ved neg. Kant på P1.5.
1,0 Timer 2 funktion:
0, 0: Timer 2 stoppet.
0, 1: Timer funktion, freq. Bestemt af bit 7.
1, 0: Tæller, med P1.7 som input.
1, 1: Gated timer.

CCEN:
CCEN bestemmer hvordan de 4
sammenligningsregistre skal bruges. Da vi kun
skal bruge én puls, benytter vi kun
sammenligningsregister CC1 (Compare/Capture
1), som har udgang på ben 1 på port nr. 1 (kaldet
P1.1).
CC1 aktiveres ved at sætte bit 3, og slette bit 2.
Herved bruges CC1-registret nu som
sammenligningsregister. Hver gang CC1 er lig
med timerregistret sættes ben P1.1 højt og hver
gang timeren starter forfra sættes benet til 0.
Figur 1.1 – Oversigt over CCENregistret
Litteraturliste
Bit nr. Funktion
7, 6 Styrer sammenligner-register CC3.
0, 0: Afbrudt.
0, 1: Capture på positiv kant af P1.3.
1, 0: Sammenligner aktiv.
1, 1: Capture på skriv til CCL3
5, 4 Styrer sammenligner-register CC2.
0, 0: Afbrudt.
0, 1: Capture på positiv kan af P1.2.
1, 0: Sammenligner aktiv.
1, 1: Capture på skriv til CCL2
3, 2 Styrer sammenligner-register CC1.
0, 0: Afbrudt.
0, 1: Capture på positiv kan af P1.1.
1, 0: Sammenligner aktiv.
1, 1: Capture på skriv til CCL1
1, 0 Styrer sammenligner-register CCR.
0, 0: Afbrudt.
0, 1: Capture på positiv kan af P1.0.
1, 0: Sammenligner aktiv.
1, 1: Capture på skriv til CCL0.
Timer 0:
Timer 0 kontrolleres af TMOD-registret (Timer MODe) og TCON-registret (Timer CONtrol). Det
første vælger mellem forskellige mulige funktionsmetoder, i vores tilfælde konfigureres timer 0,
som en 16-bit timer, som inkrementeres med en i hver machine-cycle, dvs. 1.000.000 gange i
sekundet. Timeren startes ved at sætte TR0 (Timer 0 Run) bitten i TCON-registret. Herefter vil
timer 0 generere et interrupt hver gang timerregistret wrapper, dvs. når værdien ændrer sig fra
FFFFh til 0000h
Side 84 af 113

Litteraturliste
Side 85 af 113