Trailerhjælper - VBN - Aalborg Universitet

Trailerhjælper
- Et lystjek- og bakkemanøvre koncept
Produkt- og designpsykologi
5. semester, projekgruppe 571
Efter˚ar 2008, Aalborg Universitet

Titel:
Trailerhjælper
Semestertema:
Instrumentering af interaktive syste-
mer
Projektperiode:
P5, efter˚ar 2008
Projektgruppe:
Produkt- og designpsykologi
Gruppe 571
Projekt forfattere:
B. Stefania Holmgeirsdottir
Michael Hejslet Justesen
Martin Rask Larsen
Thomas Schmidt-Nielsen
Daniel Kim Skovsgaard
Vejleder:
Flemming Christensen
Antal kopier:
7
Antal sider:
Report: 109
Appendix: 29
udført den:
16. December, 2008
Department of Electronic Systems
Fredrik Bajers Vej 7B
DK-9220 Aalborg st
Phone: 9635 8600
http://es.aau.dk/
Synopsis:
Projektet adresserer problemstillingerne med
fejl i lys-signaleringen p˚a trailere samt kollision
mellem bil og trailer, n˚ar der bakkes med denne.
Der er konstateret generelle problemer p˚a oven-
nævnte og fejl p˚a 28 af 100 trailere. Som løsning
p˚a problemstillingerne er der designet et sys-
tem best˚aende af et mellemstykke til monter-
ing mellem bilens og trailerens anhængerstik.
Mellemstykket indeholder et elektronisk kredsløb
som m˚aler p˚a outputs fra bilen og inputs fra
traileren. Fejl og anden information sendes til en
mobiletelefon, hvorp˚a informationer videreformi-
dles til brugeren visuelt og auditivt. Herefter
testes interfacetet som vurderedes værende uden
problemer. Det lykkedes ikke at færdigudvikle
kollisions-delen og overførsel af data til mobil-
telefon, under dette projekt.

Forord
Denne rapport er udarbejdet som en del af et semesterprojekt p˚a Institut for Elektroniske
Systemer p˚a Aalborg Universitet. Projektgruppen best˚ar af fem studerende, p˚a 5. semester,
p˚a linjen Produkt- og Designpsykologi.
Vi vil gerne takke de frivillige, p˚a Aalborg Universitet, for at have været behjælpelige som
testpersoner. Desuden vil vi takke Thule Trailers A/S for deres hjælp med levering af led-
ningsnet med videre samt deres gæstfrihed under besøget.
B. Stefanie Holmgeirsdottir Michael Hejslet Justesen
Martin Rask Larsen Thomas Schmidt-Nielsen
Daniel Kim Skovsgaard
Indholdet af denne rapport er frit tilgængeligt, men offentliggørelse af rapporten og dens
indhold m˚a kun ske med samtykke fra projektgruppe 571.
Department of Electronic Systems
Aalborg University
Ultimo december 2008
I

Læsevejledning
Læsevejledning
Læseren af denne rapport forventes, at have et basalt kendskab til kredsløbsteori, m˚aleteknik,
programmering og perceptionspsykologi.
Rapporten er opbgygget, s˚aledes at ordlisten er at finde umiddelbart inden kildehenvis-
ningerne, som er skrevet efter Harvard-metoden, bagerst i rapporten. Ord der er defineret
i ordlisten er markeret med fed og referencer til kapitler og afsnit i rapporten er markeret
med kursiv.
Strukturen af udviklingsprocessen og rapporten er illustreret p˚a Figur 1.
Problemets
omfang
Lys på
traileren
At bakke
med trailer
Problemanalyse
Målgruppe
&
interaktion
Trailerhjælper
Verificering
af systemer
funktions
test /
accepttest
funktions
test /
accepttest
Produktkravspecifikation
Integration
Test
Konceptanalyse
Test af Trailerhjælper
Grænseflader
målesystem
Grænseflader
formidlingssystem
systemanalyse
Målesystemets
indhold
Formidlingssystemets
indhold
Koncepttest
Funktionstest
/ accepttest
system
Diskusion
Design
Kravspecifikation
Målesystem
Kravspecifikationformidlingssystemet
Konklusion
Figur 1: Udviklingsprocessen og rapportstruktur
III
Afslutning
Design af
målesystem
Design af
formidlingssystemet
Perspektivering
systemdesign
systemkonstruering

Indhold
1 Introduktion 1
I Problemanalyse 3
2 Problemets omfang 5
2.1 Interviews . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.2 Observation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.3 Thule Trailers A/S . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.4 Delkonklusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
3 Lys p˚a traileren 9
3.1 Hvilke ˚arsager resulterer i defekt p˚a trailerens lys-signalering . . . . . . . . . 9
3.2 Problemstillinger for brugeren . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
3.3 Delkonklusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
4 At bakke med trailer 13
4.1 Bakkemanøvren . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
4.2 Hjælp under bakke-manøvren . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
4.3 Delkonklusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
5 M˚algruppe og interaktion 19
5.1 M˚algruppen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
5.2 Interaktion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
5.3 Anskaffelse af system . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
5.4 Delkonklusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
6 Trailerhjælper 25
6.1 Konkretisering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
7 Produkt-kravspecifikation 29
7.1 Produkt-kravspecifikation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
7.2 Afgrænsning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
II Design 33
8 Konceptanalyse 35
8.1 Use cases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
8.2 Krav og videre forløb . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
9 Analyse af m˚alesystem 42
IV

9.1 Grænsefladen til traileren . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
9.2 Grænsefladen til bil . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
9.3 Grænsefladen til formidlingssystemet . . . . . . . . . . . . . . . . . . . . . . . 47
9.4 M˚alesystemets indhold . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
9.5 Kravspecifikation for m˚alesystemet . . . . . . . . . . . . . . . . . . . . . . . . 56
10 Design af m˚alesystem 57
10.1 Vinkelm˚aler modul . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
10.2 Effektm˚aler modul . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
10.3 Differens-effektm˚aler modul . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
10.4 Spændingsniveau-m˚aler modul . . . . . . . . . . . . . . . . . . . . . . . . . . 69
10.5 Gumstix-software modul . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
11 Konstruktion af m˚alesystem 75
11.1 Praktiske funktioner . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
11.2 Det samlede kredsløbsdiagram . . . . . . . . . . . . . . . . . . . . . . . . . . 77
11.3 Placeringsdiagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
11.4 modulverificering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
12 Verificering af m˚alesystem 79
13 Analyse af formidlingssystem 80
13.1 Grænsefladen til m˚alesystemet . . . . . . . . . . . . . . . . . . . . . . . . . . 80
13.2 Brugergrænsefladen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
13.3 Formidlingssystemets indhold . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
13.4 Kravspecifikation for formidlingssystemet . . . . . . . . . . . . . . . . . . . . 87
14 Design af formidlingssystem 88
14.1 Design af brugergrænseflade . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
14.2 Programmering af brugerflade . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
14.3 Datah˚andtering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
14.4 I/O . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
15 Verificering af formidlingssystemet 95
16 Verificering af Trailerhjælper 96
III Test 97
17 Koncepttest 98
17.1 Form˚al . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
17.2 Opstilling af test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
17.3 Design af test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
17.4 Udførelse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
17.5 Dataopsamling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
17.6 Delkonklusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
V

IV Afslutning 107
Konklusion 108
Perspektivering 108
18 Ordliste 110
Bibliography 110
Appendiks 111
A Spørgeskema og besvarelser 113
A.1 Svar fra interviewene . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
B Tilkobling af trailer 114
B.1 Tilkobling af trailer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114
C Eksisterende løsninger 115
C.1 Eksisterende løsninger . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115
D M˚alejournal for spændingsniveau-m˚aler 117
E M˚alejournal for effektm˚aling 119
F Accepttest for m˚alesystem 122
G Accepttest for formidlingssystemet 125
H Accepttest af Trailerhjælper 126
I Koncepttest 128
I.1 Introduktion til testpersonen . . . . . . . . . . . . . . . . . . . . . . . . . . . 128
I.2 Interview af testperson . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129
I.3 Besvarelser af ˚abne spørgsm˚al . . . . . . . . . . . . . . . . . . . . . . . . . . . 129
J Kildekode 132
J.1 Kildekode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132
K Kredsløbsdiagram 139
Indholdsliste af bilag p˚a vedlagte cd 141
VI

KAPITEL 1
Introduktion
Projektgruppen observerede, under en køretur, flere biler med tilkoblede trailere, hvor lysene
p˚a en eller anden vis var defekte. Føreren af projektgruppens bil var tilbageholdende, n˚ar
trailerne med de defekte lys kørte foran, og der var en vis usikkerhed i, om det var sikkert
at overhale. Denne tilbageholdenhed er m˚aske et enkeltst˚aende tilfælde af usikkerhed for
føreren af projektgruppens bil, men hvis det er et generelt billede for bilister kørende bagved
en trailer med defekte lys, er der grund til videre undersøgelse.
Usikkerheden kan skyldes en erfaring om, at der er blevet observeret en form for defekt
p˚a lys-signaleringen p˚a den forankørende bils tilkoblede trailer. Situationen kan forekomme
specielt ubehagelig hvis det er en stor trailer, som trækkes af den forankørende bil, s˚a
bilen ikke kan ses. Her er den bagvedkørende bilist nødsaget til at stole p˚a, at samtlige
lys p˚a traileren virker som de skal. En af de mest alvorlige fejl, som kan opst˚a i denne
situation, er hvis bremselyset ikke fungerer. Dermed bliver den bagvedkørende ikke advaret
om opbremsningen og resulterer i, at personens tid til at reagere forkortes. En anden alvorlig
fejl er, hvis blinklyset p˚a traileren viser modsat retning af den ønskede. Hvis en bilist vil
overhale en forankørende bil med trailer, og traileren blinker til højre, og den bagvedkørende
trækker ud i venstre spor for at passere, kan det g˚a grueligt galt. De to ovenfor beskrevne
eksempler er langt fra sjældent forekommende hændelser. Med jævne mellemrum rapporterer
pressen om nøjagtig disse situationer [Jensen, 2008].
Hvorfor opst˚ar situationer som ovennævnte? Glemmer bilister, der skal ud og køre med
trailer, at tjekke lysene eller ligger der andet bag? Hvis det skyldes, at bilisterne glemmer
eller ikke gider at tjekke lysene p˚a traileren, er de s˚a klar over hvilke konsekvenser ukorrekt
visning af lys kan have? Hvis bilisterne tjekker lysene, er de s˚a klar over hvordan dette
skal gøres korrekt, s˚a samtlige lys er tjekket. Udover lys-signaleringen er der ogs˚a andre
problemstillinger forbundet med kørsel med trailer.
I Danmark og specielt i Jylland er antallet af husstande med egen trailer steget med næsten
det dobbelte i løbet af de sidste ti ˚ar [Danmarks Statistik, 2005]. I weekenderne valfarter
trailerejere til genbrugspladser med haveaffaldet, hvor bilisten eventuelt skal bakke hen til
aflæssningsomr˚adet. Dette kan i nogle tilfælde give bilisten præstationsangst og ubehag, da
bilisten befinder sig i en situation hvor denne kan forvolde b˚ade materielle og personskader.
De fleste trailerejere vil p˚a et tidspunkt komme i en situation hvor en bakke-manøvre er
nødvendig at udføre. Hvad er det, der gør det s˚a svært at udføre en s˚adan manøvre, at folk
panikker eller hægter traileren af? I dette projekt vil følgende problemer adresseres:
• At bakke med trailere
• At sikre korrekt lys-signalering p˚a trailere
1

Del I
Problemanalyse
3

Del 1: Indledning
De to problemer der vil blive adresseret i dette projekt skal analyseres. Det er m˚alet, efter
rapportens første del, at kunne beskrive en idé til et produkt der potentielt kan løse prob-
lemet. N˚ar problemets omfang er fastsl˚aet, vil de to problemstillinger analyseres individuelt.
I første kapitel vil lyset p˚a traileren blive analyseret med henblik p˚a, at finde ud af hvad der
for˚arsager, at lyset p˚a trailere ofte ikke virker korrekt. M˚alet er, at finde frem til hvad der
kan afhjælpe bilister med at tjekke lysene p˚a trailere inden anvendelse.
I andet kapitel, vil der forsøges at komme med svar p˚a, hvad der kræves for at foretage en
bakke-manøvre, og dernæst hvilke løsninger der potentielt kan aflaste føreren i situationen.
I sidste kapitel vil m˚algruppen og interaktion analyseres. Hvilke muligheder findes der, ud
fra de to foreg˚aende analyser, for at videregive brugbare informationer, s˚aledes at brugeren
nemmere kan tjekke lyset og manøvrere problemfrit med traileren.
N˚ar konklusionerne p˚a analyserne er taget, kan en idé til en potentiel løsning beskrives,
hvilket vil afslutte denne problemanalyse.
4

KAPITEL 2
Problemets omfang
Antallet af trailere, p˚a de danske veje, er steget med næsten det dobbelte fra ˚aret 1994 til
2004 [Danmarks Statistik, 2005], hvor 70% af dem befinder sig vest for Storebælt [Danmarks
Statistik, 2006]. Derfor blev to genbrugspladser udvalgt som scenarie for interviews af bilister
med trailere. P˚a de to genbrugspladser, genbrugspladsen i Aalborg og genbrugspladsen i
Middelfart, blev i alt 30 personer interviewet med henblik p˚a at afdække bilisternes vaner og
færdigheder, hvad bakning med trailer og lys-tjek ang˚ar. Derefter blev 100 tilfældige biler
med p˚asat trailere observeret, med det form˚al at f˚a tal p˚a hvor stor en del af trailerne havde
fejl p˚a lys-signaleringen. Efterfølgende blev der taget kontakt til Thule Trailers A/S for at
f˚a deres vurdering af problemets omfang.
2.1 Interviews
De 30 personer der blev interviewet var fordelt mellem 19 mænd og 11 kvinder i alderen fra 28
˚ar til 81 ˚ar. Et komplet skema over spørgsm˚al personerne blev stillet under interviewene kan
ses i Appendiks A, hvor spørgsm˚al 1 og 2 er metadata om de personer der blev interviewet.
De r˚a data af svarene kan ses i Appendiks A.1, og i procenter fordeler svarene sig som
følgende:
Har du bakket med en trailer eller campingvogn?
• 90% svarede ja
• 10% svarede nej
Hvor ofte bruger du en trailer?
• 60% en til to gange om m˚aneden
• 17% ugentligt
• 23% sjældent
Hvor ofte bakker du med en trailer?
• 53% bakker med traileren en til to gange om m˚aneden
• 17% bakker med den ugentligt
• 30% bakker kun sjældent med trailer
Hvor ofte tjekker du om alle lys virker p˚a traileren?
5

• 60% svarede at de tjekker alle lys hver gang traileren anvendes
• 40% de resterende er fordelt ligeligt p˚a svarene “nogle gange” og “sjældent”
P˚a en skala fra 1-5, hvor god er du til at bakke med trailer?
• 23% svarede at de er meget d˚arlige til at bakke med trailer
• 23% svarede at de er meget gode til det
• 20% svarede midt i mellem
• 20% svarede at de var lidt bedre end midt i mellem
• 14% svarede at de ikke var meget d˚arlige, men bare d˚arlige
Hvordan har du det med at bakke med en trailer?
• 57% af personerne synes det er let at bakke med trailere
• 43% synes det er svært
Har du eller bekendte oplevet problemer med at bakke med en trailer, som har
resulteret i materielle skader?
• 47% svarede ja
• 53% svarede nej
Fordelingen ovenfor viser, at der er en stor del brugere har problemer med at bakke med
trailer, p˚a trods af at dens hyppige anvendelse. Mange af de adspurgte forklarede, at det er
svært at tænke modsat, det vil sige at hvis traileren ønskes drejet mod venstre skal rattet
drejes mod højre. Nogle var ogs˚a bange for at lave materielle skader p˚a bilen, for˚arsaget
af hvis traileren kommer for langt ud til siden og rammer bilen. I spørgsm˚al 6, hvor 40%
brugere svarede, at de ikke tjekker om alle lys p˚a traileren virker hver gang traileren skal
bruges, fik mulighed for at begrunde hvorfor dette ikke er tilfældet. Svarene var fordelt p˚a
fire udsagn:
• Det er p˚a grund af dovenskab
• Det er for besværligt at tjekke
• En fejl ville ikke afholde dem ikke fra at køre med traileren
• Forventer at lysene p˚a traileren virker som de skal
P˚a trods af at 60% af de personer der blev interviewet svarede, at de altid tjekker lysene
inden de kører, antyder resultaterne af observationen noget andet.
6

2.2 Observation
Som opfølgning p˚a interviewene og som del i dokumentation p˚a problemstillingen blev i alt
100 biler med p˚asatte trailere observeret. Form˚alet var at finde ud af hvor mange trailere,
hvis lys ikke virkede korrekt, forlod genbrugspladsen. Bilerne blev observeret forlade gen-
brugspladsen ud til et t-kryds, hvor de enten skulle dreje mod højre eller venstre. Hvis
obeservatørerne observerede en fejl blev dette noteret, men n˚ar der var tvivl, blev traileren
markeret som værende uden fejl. Tvivlen kunne opst˚a n˚ar lysene p˚a traileren lyste svagt,
stærk sol der begrænsede lysets synlighed, eller hvis traileren var beskidt. Desuden blev
bilister der hverken bremsede eller blinkede i krydset krydset af for værende uden fejl.
Der blev i alt noteret at 28% af trailerne, kørte med defekt lys p˚a traileren. Dette blev
konstateret ved fx, at blinklysene p˚a bilen var aktiveret mod højre, men lysene p˚a traileren
blinkede mod venstre. Desuden blev der observeret, at 11% af bilerne slet ikke blinkede, n˚ar
de kom hen til krydset, det vil sige hverken trailererens eller bilens blinklys blev aktiveret.
Da interviewene og observationerne var overst˚aet, blev de ansatte p˚a begge genbrugspladser
adspurgt om, hvad de har oplevet af problematikker med trailere, som folk kører med p˚a
genbrugspladsen. Dette begrundet med at de anses for at have indsigt i hvad der kan g˚a galt,
grundet de mange timer de befinder sig p˚a pladsen. De fortalte at nogle af de mennesker,
der tager traileren af for at vende den, i stedet for at bakke med den, glemmer at sætte
trailerstikket til, n˚ar de har hægtet traileren fast p˚a bilen igen. De forklarede ogs˚a at der
med cirka 14 dages mellemrum sker materielle skader p˚a biler og trailere p˚a genbrugsplad-
sen. Oftest er det n˚ar folk bakker med trailer, hvor de enten bakker ind i andre biler eller
bakker for skarpt, s˚a bilen og traileren kolliderer. Dette er det generelle billede p˚a begge
genbrugspladser.
Resultaterne fra observationerne viser, at 28% kører med forkert eller manglende visning af
lys p˚a trailerne. Dette stemmer overens med resultaterne fra interviewene, da kun halvdelen
af de adspurgte bilister fortalte, at lysene altid tjekkes inden traileren bliver taget i brug.
En af de mulige konsekvenser, af at køre med forkert belysning, er fx det tidligere nævnte
eksempel, se Introduktion Kapitel 1 p˚a side 1, hvor bilisten blinkede til venstre, men traileren
blinkede til højre, og en overhalende bil kolliderede med den forankørende bil med trailer.
2.3 Thule Trailers A/S
Der blev rettet henvendelse til Thule Trailers A/S, hvorefter der blev arrangeret et møde
med Henrik Egelund, som er R&D manager hos Thule Trailers. Henrik Egelund forsynede
med estimerede produktionstal samt øvrige informationer om trailere produceret af Thule
Trailers. Han fortalte, at Thule Trailers sidder p˚a cirka 40% af trailer-markedet i Dan-
mark, hvor omkring halvdelen af de cirka 30.000 produceret ˚arligt er fritids-trailere. Henrik
Egelund nævnte nogle problemstillinger med lysene p˚a trailere, som fx at lysene i trailerne
best˚ar af glødepærer, som generelt er skrøbelige overfor fugt og vibrationer. Dermed kan der
opst˚a problemer med glødepærerne allerede under transporten til de forskellige leverandører,
hvorfor det er nødvendigt at brugeren tjekker funktionaliteten hyppigt.
7

2.4 Delkonklusion
Der m˚a konstateres at der er en stor del af trailer-brugerne, der b˚ade har problemer med
at bakke med trailer og sikre korrekt fungerende lys p˚a traileren. Der kan kokluderes, at
problemstillingerne findes, men der vides ikke om de 28% observerede er en generel tendens.
Hvis resultaterne holdes op mod det reelle antal fritids-trailere i Danmark, vil det svare
til at der hvert ˚ar sættes cirka 4000 trailere p˚a gaden, der alle ender med at køre med
defekt lys. Dette eksempel er blot ud fra produktionstallene fra Thule Trailers, s˚a der m˚a
antages at tallet er væsentlig højere hvis øvrige trailerproducenters produktionstal tages med
i beregningen. For at kigge p˚a det større billede, m˚a der nævnes at, “778.000 er antallet af
trailere i Danmark. Hvis de alle var ude at køre, ville hver tredje personbil have en trailer
p˚a krogen” [Danmarks Statistik, 2008]. Hvis der igen antages, at tallene fra observationen
kan overføres til det reelle antal trailere kørende i Danmark, vil det sige at 217.840 trailere
kører med defekt lys. Hvis disse antagelser er korrekte, er der god grund til at analysere
problemerne yderligere, og forh˚abentlig dermed finde frem til en potentiel løsning.
8

KAPITEL 3
Lys p˚a traileren
Umiddelbart kan der være to grunde til, at der observeres trailere med defekt lys-signalering.
Den ene kan være fordi, at brugerne ikke tjekker lysene inden de anvender traileren, af
forskellige ˚arsager, og den anden kan være fordi, at der opst˚ar fejl eller defekter p˚a traileren
uden brugerens indvirken.
3.1 Hvilke ˚arsager resulterer i defekt p˚a trailerens lys-
signalering
Nedenfor opstilles ˚arsager til det defekte lys og en forklaring for denne ˚arsag gives. Disse
forklaringer tager udgangspunkt i brugernes forklaringer fra interviewet og bliver opdelt i
kategorier.
Defekt opst˚aet under kørsel
Det kan ikke udelukkes, at en defekt p˚a trailerens lys opst˚ar efter bilisten begiver sig ud
p˚a vejene. Fejlen vil ofte først blive observeret under næste tilkobling af traileren, eller hvis
anden part gør opmærksom p˚a den.
Brugeren ved det, men kører alligevel
Hvis defekten p˚a lysene ikke opst˚ar under kørsel, m˚a grunden være mangelfuldt lystjek fra
brugerens side. Dog er der et andet tilfælde, hvor alt lys kan være tjekket, men hvor defekt
lys stadig observeres. Det er tilfældet, hvor bilisten er bevidst om defekten, men vælger at
køre alligevel. Dette er et tilfælde som nogle af de adspurgte bilister, p˚a genbrugspladsen,
forklarede med at hvis vedkommende skulle bruge traileren p˚a et givent tidspunkt, ville den
blive anvendt p˚a trods af en eventuel fejl. Hvorfor brugerne vælger, at køre med traileren
p˚a trods af fejl, kan være tegn p˚a at de mulige konsekvenser ikke er tydeliggjort for dem.
Oplysningskampagner eller produkter der netop gør dette, kunne potentielt være en løsning
p˚a netop dette problem.
Halvt tjek
I Appendiks B.1 kan en vejledning findes, til hvordan en trailer p˚amonteres korrekt. Dog kan
der foretages mange forskellige forkortede variationer af tjekket, som ikke er fuldt tilstrække-
9

lige for at sikre en korrekt virkende trailer. Disse versioner er fundet frem til ud fra projek-
tgruppens overvejelser, om hvordan dette kan foretages.
En m˚ade er at starte bilen og tænde katastrofeblinket, inden bilisten stiger ud af bilen for
at koble traileren p˚a. Imens traileren bliver koblet p˚a, kan bilisten se om det aktiverede lys
virker. Efterfølgende kan føreren køre, i god tro at lyset p˚a traileren virker korrekt. Hvis
lys-tjekket laves p˚a denne m˚ade er bremselyset ikke tjekket, og der vides ikke om der blinkes
i den rigtige retning, hvilket er to af de potentielt mest farlige defekter.
Intet tjek
Udfra interviewene var brugernes forklaring p˚a, hvorfor de ikke tjekker lyset p˚a bilen, at de
antager at lysene p˚a traileren er korrekt fungerende. Hvis brugerne blev gjort opmærksomme
p˚a eventuelle fejl p˚a traileren eller konsekvenserne deraf, kunne det m˚aske øge sandsynlighe-
den for at brugeren foretog lys-tjekket.
Fejl og fejlenes oprindelse
Viser det sig at noget af lyset er defekt, skal der foretages fejlfinding. Herunder er de fleste
mulige fejl opridset, efterfulgt af forskellige m˚ader hvorp˚a disse fejl kan være opst˚aet. Fejlene
er erfaringer indsamlet af projektgruppen, om hvad der kan opst˚a af fejl p˚a lysene p˚a trailere.
Blinklys virker modsat
• Feder eller not i stikket er ødelagt og dermed er stikket blevet vendt forkert
Bremselys, blinklys, nummerpladelys og baglys virker ikke
En af følgende fejl er opst˚aet:
1. Ledninger fra stik til lygter er defekte
2. Trailerstik er defekt
3. Bilens stik er defekt
4. Pærer er defekte
Forkert virkning af lys
Disse kunne være:
• Nogle lys virker modsat
• Bag, bremse eller nummerplade-lyset blinker i stedet for blinklyset
10

• Bag, bremse eller nummerplade-lyset lyser i stedet i bremselyset
• Intet lys virker
Disse fejl kan skyldes, at der ikke er ordentlig forbindelse gennem stikket. Skidt, snavs eller
slitage medfører kortslutninger i stikket eller manglende forbindelse.
Et lys virker ikke
Hvis et lys ikke er fungerende, skal følgende opgaver udføres:
1. Tjek forbindelse til lygten
2. Skift pæren
Ovenst˚aende er de mest generelle fejl n˚ar nogle af lysene ikke fungerer korrekt. Herunder er
en kort oprids af de forskellige ting der hyppigst er ˚arsag til fejl p˚a trailere.
• Defekt pære
• Feder eller not i stikket er ødelagt og dermed er stikket vendt forkert
• Manglende forbindelse enten i bil, trailer eller stik
Trailerføreren skal dermed udbedre minimum et af ovenst˚aende punkter, for at trailerens lys
fungerer korrekt igen. Indtil videre kendes proceduren for lystjek og ydeligere vides hvilke
fejl kan opst˚a, hvad de er for˚arsaget af, og til sidst hvad der skal gøres for at udbedre fejlen.
Hvis en løsning til problemet med lys-signalering skal laves, skal ˚arsagen til hvorfor brugerne
ikke tjekker lysene p˚a traileren, haves in mente.
3.2 Problemstillinger for brugeren
Som tidligere nævnt, kan en guide til hvordan en trailer skal tilkobles findes i Appendiks B.1.
For at tjekke lysene er de nedenst˚aende vejledende punkter udarbejdet af projektgruppen,
udfra en brugerh˚andbog fra Thule Trailers [Thule trailers, 2008].
1. Lyset tændes og baglys, nummerpladelys og eventuelle positionslys p˚a siden af traileren
kontrolleres
2. Venstre- og højre blinklys aktiveres og kontrolleres
3. Bremselys aktiveres af føreren og en anden person kontrollerer
Det er p˚akrævet, for at kunne overholde punkt nummer tre, at være mere end en person.
Det er besværligt for brugeren at gøre selv og ville kræve rekvisitter. Det kan være, at dette
p˚avirker brugeren til ikke at gøre sig besværet og tjekke de øvrige lys, n˚ar vedkommende
ved at bremselyset alligevel ikke kan blive tjekket. Som tidligere nævnt er der ogs˚a andre
formodninger om hvorfor bilister ikke tjekker lysene p˚a traileren inden der køres, som fx
dovenskab, hvorfor en løsning p˚a problemet angiveligt m˚a fjerne besværet ved at tjekke
lysene.
11

3.3 Delkonklusion
Hvis en løsning skal laves, er der mange punkter fra dette og forrige kapitel, som burde
tages med i overvejelserne. Løsningen skal generelt fjerne besværet fra brugeren, ved at
lysene bliver tjekket inden brugeren kører med traileren. Desuden kunne det være en idé,
hvis løsningen gav brugeren en indikation om, hvor et opst˚aet problem befinder sig, for at
brugeren ikke skal til at lede efter en eventuel sprungen pære. Endvidere er problematikken
med, at brugeren skal have en anden person til at tjekke bremselysene ogs˚a relevant. En
komplet løsning kunne tjekke bremselyset for brugeren, for at den ovenst˚aende situation
undg˚aes. En formidling mellem brugeren og løsningen vil nødvendigvis være tilstede, for at
de ovenst˚aende informationer n˚ar brugeren, hvilket vil blive analyseret senere i denne del.
12

KAPITEL 4
At bakke med trailer
Afsnittet indeholder først en analyse af selve bakkemanøvren for at vide hvilke faktorer der
spiller ind under en s˚adan. Disse faktorers indflydelse vil dernæst blive vægtet i forhold til
et muligt system til hjælp under bakning. Desuden bliver der set nærmere p˚a systemer med
forskellige form˚al, som kan være til hjælp.
4.1 Bakkemanøvren
Først analyseres en bakkemanøvre uden trailer for at blive bekendt med eventuelle forudsæt-
ninger, der kan gøre det lettere eller vanskeligere for førerne at bakke med trailer. Dernæst
analyseres bilens og trailerens størrelser, da det er erfaret, af projektgruppen, havende stor
betydning for sværhedsgraden af bakkemanøvren. Til sidst vil alle disse medvirkende fak-
torer blive involveret i en analyse af selve bakkemanøvren med trailer.
Forudsætninger
Under en ganske almindelig bakke-manøvre med bil vil det være modsatte ende af bilen,
der skal for˚arsage en svingning end under fremadrettet kørsel. Dette resulterer i, at der over
kortere afstand kan foretages skarpere sving, dog skal der holdes øje med den styrende ende
af bilen, da denne vil svinge kraftigt ud.
Ovenst˚aende eksempel er ikke nødvendigvis gavnligt for føreren af en bil med trailer, som
skal foretage en bakke-manøvre. Det kan være en fordel, da de skarpere sving betyder, at
der kan rettes op p˚a store udsving med traileren. Oftest vil det dog formegentlig være en
ulempe, da de kontante reaktioner fra bilen, p˚a sm˚a-korregeringer fra rattet, nødvendigvis
ikke er i overensstemmelse med brugerens hensigt.
M˚aden hvorp˚a bilens forskellige spejle bliver benyttet i en bakke-situation kan være meget
individuel. Skal der bakkes ligeud over længere afstand vil nogle førere være tilbøjelige til
at benytte side- eller bakspejl. Under mere krævende bakke-manøvrer ser nogle bilister sig
blot over skulderen, se Figur 4.1 p˚a næste side.
Med trailer tilkoblet kan føreren blive nødsaget til at benytte andre spejle eller udsyns-
muligheder end denne normalt gør, hvilket kan forlænge reaktionstider og nedsætte forst˚aelsen
for situationen. Inden selve bakke-manøvren analyseres vil der blive set p˚a forskelle p˚a biler
og trailere imellem.
13

Figur 4.1: Førerens udsyn gennem bilens bagrude under en bakke-manøvre
Dimensioner for bil og trailer
En forst˚aelse, for hvilken indflydelse størrelsen af bil og trailer kan have, er vigtig i denne
sammenhæng. En bakkemanøvre med en lille trailer kræver kun sm˚a korrektioner p˚a rattet
før traileren laver udsving. Med en stor trailer vil de samme sm˚a korrektioner have en mindre
effekt p˚a trailerens retning. Der er dog flere dimensioner som skal tages med i betragtning.
De væsentligste kan ses p˚a Figur 4.2.
A O
a
Figur 4.2: Illustration af bil og trailers dimensioner
Vinklen A er hvor meget bilen kan dreje p˚a forhjulene. Jo større vinkel A er, desto skarpere
kan der drejes med traileren, og der kan rettes op igen fra situationer hvor traileren og bilen
er “knækket” meget sammen. Afstanden a er mellem bilens for- og baghjul. Er afstanden
stor, vil bilen tage længere tid om at svinge ud. Afstanden b er mellem bilens baghjul og til
trækkrogen. Hvis denne afstand er lille vil traileren ikke s˚a hurtigt komme ud i store vinkler.
Afstanden c er mellem trækkrogen og trailerens hjul. Køres der med en stor trailer, hvor
denne afstand er stor, vil traileren ikke s˚a hurtigt svinge ud til en side, se Figur 4.3 p˚a næste
side. I baggrunden, illustreret med gr˚alige toner, ses hvilket udsving trailerne vil foretage
hvis begge biler drejer lige meget p˚a rattet og bakker en lige stor distance.
14
b
c

Figur 4.3: Hvordan dimensionerne p˚a bil og trailer indvirker p˚a køreegenskaberne
Bakke-manøvren fra A til B
Det foreg˚aende beskriver hvordan forholdene er mellem bil og trailer, og hvilken effekt
størrelserne af de to kan have under en makkemanøvre. Der er dog flere problematiske
aspekter, der m˚a tydeliggøres. Et af disse er, at n˚ar rattet drejes til højre, svinger traileren
til venstre. Dette kræver et overblik, da dimensionerne af bil og trailer samt forskellen p˚a
tid til kollision mellem disse, skal holdes under kontrol. Dermed, hvis der skal bakkes fra et
sted A til et sted B, skal bilisten forholde sig til bilens og trailerens størrelser, og deres udsv-
ingshastighed, samt have et mentalt overblik over ruten der skal køres samt hvilken retning
rattet skal drejes i, for at m˚alet n˚aes. P˚a Figur 4.4 p˚a den følgende side er der illustreret,
hvordan en bakkemanøvre fra A til B skal foretages, i dette tilfælde en bil med p˚asat trailer
der skal bakkes ind i en garage.
Forhjulene p˚a bilen er røde, og deres oplagte rute for at bakke traileren ind i indkørslen er
vist med de mørkerøde markeringer. Baghjulene er bl˚a og den linje disse vil følge er ligeledes
markeret med bl˚a. Trailerens hjul og ruten disse følger er gr˚a.
Hvis der afviges fra anvisningen p˚a figuren, skal der rettes op igen eller startpositionen skal
indtages og bakkemanøvren m˚a p˚abegyndes forfra.
4.2 Hjælp under bakke-manøvren
Der kan udarbejdes idéer til mange forskellige systemer, der har til form˚al at assistere
brugeren i at bakke med trailer. I det følgende, er tre forskellige idéer udarbejdet, hvor
graden af assistance varierer systemerne imellem. Disse er udarbejdet med det form˚al, at f˚a
indsigt i hvad en potentiel løsning skal indeholde af assistance, for at denne med fordel og
15

Figur 4.4: Hjulenes rute for en bakke-manøvre med trailer. Anvisning af retning p˚a rattet
uden besvær kan anvendes af brugeren.
Kollisionsalarmen
Dette system har til form˚al at forhindre føreren i at forvolde skade p˚a bilen og traileren, ved
at de to kolliderer. Systemet skal informere føreren om at stoppe, n˚ar denne er ved at lave
skade p˚a bilen, fordi bil og trailer kolliderer.
Hvis et s˚adant system skal udarbejdes, skal vinklen mellem bil og trailer kendes. Desuden
skal der tages hensyn til hvor hurtigt bilisten bakker, hvilket har en indflydelse p˚a, hvorn˚ar
informationen om mulig kollision skal gives til brugeren. Denne tid er bestemt af, hvor
hurtigt en person kan percipere informationen fra systemet, om at der nu skal trykkes p˚a
bremsen. Lad det for eksempel være to sekunder. Hvis personen bakker med 1 km/t, s˚a kan
informationen formidles senere end hvis der bakkes med 5 km/t. Afhængigt af hvor meget
føreren har drejet p˚a rattet, vil hastigheden hvormed traileren svinger ud til siden variere.
Denne effekt kan beskrives som vinkelhastighed. Skulle systemet yderligere kunne registrere
om personen er ved at øge eller sænke vinkelhastigheden, er information om vinkelaccelera-
tion nødvendig. Systemet skal registrere om brugeren bakker hurtigt uden at rette op, eller
ønsker at bakke skarpt rundt til en side. Her vil det ikke være nok med en vinkelhastighed,
da den ikke nødvendigvis har n˚aet en ændring, der er stor nok til at udløse alarm. Men hvis
systemet kan se, at der er stor acceleration imod kollision, s˚a vil alarmen komme tidsnok til
at bilisten kan bremses før skaden sker. Dog m˚a øvrige faktorer overvejes. Eksempelvis bilens
16

eaktionstid, der har en indflydelse p˚a hvor lang tid der g˚ar, fra bilisten trykker p˚a bremsen
til at bilen stopper. Skal dette system udvikles, er det nødvendigt at kende dimensionerne
p˚a bil og trailer s˚aledes at nedenst˚aende kan beregnes:
• Maksimale vinkel inden kollision
• Vinkelhastighed
• Vinkelacceleration
Point of no return
Denne udgave griber ind noget tidligere end den forrige. Her skal vinklen, som afgør om
bilen og traileren stadig kan rettes op under et sving, kendes. Det vil sige, at hvis traileren
er kommet ud i en s˚adan vinkel, i forhold til bilen, at udsvinget ikke kan rettes op, s˚a er
denne vinkel overskredet. Dermed m˚a føreren stoppe manøvren, køre frem og udføre bakke-
manøvren forfra. For at kunne udvikle dette system, er det nødvendigt at kunne beregne
vinkel- hastighed og acceleration samt den maksimale vinkel inden kollision. Disse faktorer,
er de samme for b˚ade kollisonsalarm systemet og point of no return systemt
For at systemet kan beregne denne vinkel, skal systemet kende bilens og trailerens dimen-
sioner, se Dimensioner for bil og trailer, Afsnit 4.1. Nogle af de vigtigste faktorer, der har
en indflydelse under bakning med trailer, er listet her.
• Bilens akselafstand
• Dreje radius
• Afstand fra bag-aksel til krog
• Afstand fra krog til trailer-aksel
Udover disse punkter, er der flere faktorer der kan have indflydelse p˚a bakningen, som fx
underlag, bredde p˚a køretøjet, differentiale-opbygning med mere.
Dette system kan ikke blot undg˚a kollisionsskade mellem bil og trailer, men ogs˚a assistere
føreren til at manøvrere traileren uden brug af flere forsøg.
At bakke fra A til B
Det er tidligere blevet belyst, i bakkemanøvren fra A til B Afsnit 4.1, hvordan føreren kan
styre traileren p˚a plads. Systemet her skal kunne guide føreren ind p˚a den ønskede plads.
Her skal alts˚a følges nogle informationer som enten er visuelle eller p˚a anden m˚ade overgives
til føreren.
For at dette system skal fungere, skal bilens og trailerens position kendes i forhold til hinan-
den og omverdnen. Desuden skal stedet, der skal manøvreres hen til kendes. Desuden skal
systemet kende vinkel mellem bil og trailer, rattets eller hjulenes position samt dimensioner
17

og tekniske data for bil og trailer være kendt af systemet. Hvis ikke disse er kendte, er der
risiko for, at manøvren ikke bliver præcist nok udført, hvilket kan resultere i uheld.
Der kan laves en anden udgave hvor systemet ikke kender positionen i forhold til omverdenen,
men hvor punktet der skal bakkes til er afmærket p˚a anden m˚ade. Hermed skal systemet
ligeledes udregne en rute mellem to punkter. Problemerne opst˚ar, n˚ar denne rute skal rundt
om forhindringer.
Dette system er noget mere komplekst end de forrige og kræver et sammenspil mellem flere
mindre systemer. Brugeren f˚ar et system, som kan forsikre at s˚afremt de angivne informa-
tioner følges, vil der kunne bakkes mellem to angivne punkter p˚a en rute.
4.3 Delkonklusion
Faktorer der spiller ind n˚ar der skal bakkes med trailer er beskrevet, hvorfor det blev muligt
at udforme tre forskellige systemer, det med hver deres funktion kan afhjælpe brugeren i at
bakke med trailer.
De tre forskellige systemer, kollisionsalarmen, point of no return og bakke fra A til B, kan
vælges at udvikle videre p˚a. Der er fordele og ulemper ved alle tre systemer, og hvis tidspe-
rioden for dette semester tages med i overvejelserne, m˚a de ubekente faktorer begrænses.
Kollisionsalarm-systemet, som blot skal afværge sammenstød mellem bil og trailer, kræver
ikke at bilens og trailerens dimensioner kendes. Vinklen mellem bil og trailer skal derimod
kendes, og der skal sikres at denne aldrig bliver “nul”. Det vil sige, at det er nødvendigt at
kende bilens bremselængde i forhold til tid og hastighed.
Point of no return-systemet kræver mere information om trailer og bil, hvilket for˚arsager
at hvis ikke systemet er integreret i bilen, er b˚ade trailerens og bilens data ukendt. Dermed
skal brugeren indtaste disse data eller systemet skal anvende en tilnærmet gennemsnitsværdi.
Begge dele kan være uheldige, da fejl-indtastning fra brugeren kunne medføre forringet eller
ingen funktionalitet af systemet. Endvidere, hvis en gennemsnitsværdi anvendes, er der risiko
at alarmen ikke lyder præcist nok, hvilket kan medføre at denne lyder for tit eller at den
lyder for sent.
Bakke fra A til B-systemet er et kompliceret system at udvikle, idet der kræves viden om
de omkringliggende omgivelser samt ruteplanlægning, hvilket ikke menes værende muligt p˚a
dette semster. Desuden skal systemet være tilstrækkelig dynamisk, s˚aledes at der hele tiden
foretages korrigerende beregninger af ruten, hvis der blot afviges en smule fra den.
Der er besluttet at et af disse tre systemer skal udvikles sammen med lystjekket. Kollision-
salarmen vælges, da dette system potentielt kan danne grundlag for de øvrige to systemer.
Dermed menes der, at for at lave Bakke fra A til B-systemet, ville det være en klar fordel
at kende grænsen for hvorn˚ar der er risiko for kollision mellem bil og trailer.
18

KAPITEL 5
M˚algruppe og interaktion
I dette kapitel er m˚alet, at f˚a defineret hvad en potentiel løsning skal indeholde og hvem
brugeren er. Desuden at samle op p˚a hvilke fordele brugeren kan have, ved at en løsning
p˚a de to problemstillinger præsenteret i de to forrige kapitler bliver udarbejdet. Desuden
vil de mange forskellige interaktions-muligheder mellem brugeren og en potentiel løsning,
gennemg˚aes.
Den indledende idé, p˚a en potentiel løsning p˚a problemerne i de to tidligere kapitler, er at der
skal laves et fælles system der p˚a en eller anden m˚ade løser begge problemer. En interaktion
mellem systemet og brugeren skal forekomme, da lys-tjekket skal laves af systemet, men skal
informere brugeren om potentielle fejl, hvorefter brugeren skal reagere p˚a informationen.
Endvidere skal systemet informere brugeren om hvorn˚ar der er risiko for kollision mellem
bilen og traileren, s˚a brugeren bedre er i stand til at bakke med traileren uden at lave skade.
Dette system skal kunne anvendes af m˚algruppen, som vil blive defineret i det følgende.
5.1 M˚algruppen
Som tidligere nævnt, i Problemets omfang Afsnit 2.4, blev 30 personer interviewet p˚a gen-
brugspladsen i Aalborg og Middelfart. Dog vil et kommende system henvende sig til b˚ade
de erfarne trailer-brugere, men ogs˚a de bilister der m˚aske undg˚ar at køre med trailere.
M˚algruppen vil dermed være bred og best˚a af b˚ade mænd og kvinder i alle aldre, blot de
har et kørekort. Systemet skal kunne anvendes uanset hvilken bil brugeren har, og hvor
gammel denne end m˚atte være, for ikke at begrænse m˚algruppen. Fordelen, for brugeren,
ved brug af systemet, skal være:
• At besværet ved at tjekke lysene p˚a traileren inden kørsel skal være reduceret
• At brugeren bliver advaret, n˚ar der er risiko for kollision mellem bil og trailer
Udfra m˚algruppen skal der overvejes forskellige aspekter og problemstillinger med interak-
tionen mellem brugeren og systemet. Interaktionen skal kunne foreg˚a uanset køn, alder og
teknisk kundskab hvilket dermed kræver at stimuliene er simple og ikke kræver for megen
forudg˚aende læring.
5.2 Interaktion
Der er mange muligheder for hvordan systemet kan interagere med brugeren. Disse mulighed-
er vil i det følgende blive diskuteret, for at kunne foretage et kvalificeret valg, i forbindelse
19

med hvilke sanser systemet skal stimulere. Dette valg medfører forskellige konsekvenser
blandt andet vedrørende valg af apparat til formidling af informationerne. De forskellige
sanser der vil blive diskuteret er:
• Følesansen
• Smags- og lugtesansen
• Høresansen
• Synssansen
Følesansen
I dette tilfælde, hvor brugeren er føreren af en bil, kan der umiddelbart nævnes flere ulemper
ved at stimulere brugerens taktile sans. Føreren sidder nemlig allerede i et scenarie, hvor
den taktile sans i høj grad bliver stimuleret. De fire mest ˚abenlyse er vibrationerne i sædet
og berøring med rattet, gearstang og pedaler. Derfor kunne det være uhensigtsmæssigt at
g˚a ind og stimulere yderligere p˚a denne sans, da dette i værste fald kunne fjerne fokus fra
de øvrige taktile opgaver føreren skal udføre. Eksempelvis hvis systemet skal advare om, at
der er kollisionsmulighed mellem bil og trailer, og vibrerer for at informere føreren, kan der
være en vis usikkerhedsfaktor i afkodningen, da bilens egne vibrationer vil kunne have en
maskerende effekt. Desuden vil den informationsmetode næsten altid kræve en forudg˚aende
læring i afkodningen af signalerne. Hvordan skal signalet for fejl p˚a højre baglygte være. En
haptisk stimulus mellem et produkt og en bruger kan i mange tilfælde være kontraintuitiv.
En læringsproces skal foreg˚a, for at brugeren af systemet ved hvordan reaktionen skal være,
hvilket i dette tilfælde vil sige at træde p˚a bremsepedalen. At lave et system, som skal
stimulere brugeren taktilt og samtidig være instinktivt, kan dermed være svært at lave, hvis
en længere læringsprocess vil undg˚aes.
Smags- og lugtesansen
Nogle af de samme argumenter er ogs˚a gældende for smags- og lugtesansen, som ogs˚a kræver
en læringsprocess inden reaktionen der ønskes gives. For smagssansen er der yderligere nogle
problemer med at videregive informationen til brugeren uden direkte kontakt med smagsor-
ganet. Desuden kan der være maskerende effekter, som systemet ingen inflydelse kan have
p˚a, som fx hvis brugeren tygger tyggegummi eller spiser under kørsel. Derfor fravælges der at
arbejde p˚a løsninger, der stimulerer smagssansen. Hvad lugtesansen ang˚ar er der helt klart
ogs˚a problemer med at videregive informationer olfaktorisk. Hvis ikke stimulussen gives i en
kort afstand fra brugerens ansigt, tager denne tid at n˚a næsen, da den afhænger af luftcirku-
lationen i bilen. S˚a reaktionstiden kan blive potentiel høj ved anvendelse af denne sans, eller
det kan blive ubehageligt for brugeren hvis et apparat tæt p˚a brugerens ansigt udsender
en duft. Desuden er der, ligesom ved de øvrige sanser, risiko for maskering. Maskeringen
kan forekomme, hvis lugten af bil os eller brændt kobling n˚ar kabinen. Udover smagssansen
vælges der, ikke at stimulere brugerens lugtesans, under videregivelsen af informationer.
20

Høresansen
Ved auditiv stimulering er den umiddelbare fordel, at den kan registreres fra alle retninger.
En anden fordel ved auditiv stimulering er, at informationskilden ikke behøves at være i
fokus. Dog kan ulempen være at der, i lighed med taktil stimulering, kan ske en maskering
i kraft af anden støj som kan bevirke en fejlagtig eller manglende fortolkning. Det vil ek-
sempelvis kunne ske, hvis der er meget snak og/eller musik i bilen. Problemet vil formentlig
ikke være tilstede umiddelbart efter en tilkobling af traileren og inden kørsel med denne.
Et andet argument der taler for en auditiv stimulering, og som m˚aske kan kompensere for
maskeringsproblemet er, at det er en god kilde til at p˚akalde sig opmærksomhed, hvorfor
en auditiv stimulering er valgt til at videregive information om hvorn˚ar der er risiko for
kollision mellem bil og trailer. Dog skal der overvejes hvilken frekvens den auditive simulus
skal have, da nogle af de lavere frekvenser potentielt kan blive maskeret af bilstøjen.
Synssansen
I modsætning til en auditiv stimulering kræver visuel stimulering at informationskilden er
indenfor synsfeltet. Dog er fordelen ved visuel stimulering blandt andet, at informationen
potentielt kan ses, n˚ar brugeren har tid til det og i det tempo brugeren vil have det. Der
er mulighed for at bruge tydelige symboler og retningsanvisninger i tegn-form, s˚avel som
skriftlige meddelelser. Som tidligere nævnt er ulempen, at fokus skal være p˚a information-
skilden, for at den kan modtages, hvilket medfører nogle klare ulemper i forhold til blandt
andet trafiksikkerhed. En anden ulempe kunne m˚aske være, at ikke alle mennesker er lige
gode til symbolfortolkning. S˚afremt denne form for stimulering skulle bruges til at informere
om kollision, skal denne befinde sig i brugerens synsfelt eller at p˚a anden anden m˚ade spejles
ind i synsfeltet, s˚a stimulussen ikke bliver maskeret af andre synsindtryk. Derfor er visuel
stimulering fravalgt som informationskilde til mulig kollision mellem bil og trailer. Dog er
der en klar fordel at anvende denne under lys-tjekket, da der muligvis er færre maskerende
effekter. Hvis systemet skal formidle hvor der er problemer med lysene bag p˚a traileren kan
visuel information hjælpe brugeren til hurtigere at kunne identificere problemets placering.
Derfor er visuel stimulering valgt som primær informationskilde til identificering af fejl i
lys-systemet.
Valg og fravalg
En kort opsummering p˚a valg og fravalg truffet i dette kapitel er nødvendig, og vil derfor
blive listet i det følgende.
• Der er fravalgt at arbejde med løsninger der stimulerer brugeren haptisk
• Der er fravalgt at stimulere olfaktorisk eller smagssansen n˚ar der skal videregives
informationer
• Der er valgt at stimulere brugeren auditivt n˚ar information om mulig kollision mellem
bil og trailer skal videregives
21

• Der er valgt at stimulere brugeren visuelt for at informere brugeren om eventuelt
opst˚aet fejl p˚a trailerens lys
Der er nu valgt, at brugeren auditive og visuelle sans skal stimuleres, n˚ar systemet skal
videregive informationer. Dog er der ikke valgt, i hvilken grad brugeren skal stimuleres.
Selvom auditive informationer er valgt som primær kilde, til oplysning om kollision, kan
det være en fordel at supplere med visuel information, n˚ar denne alligevel er valgt til at
identificere fejl i lysene p˚a traileren. Der skal den informationen primært gives visuelt, men
igen kan det kun anses som en fordel at supplere med auditiv information. P˚a nuværende
tidspunkt er ovenst˚aende valg truffet, og der kan derfor kigges nærmere p˚a hvordan systemet
skal erhverves af brugeren, hvilket kan have en indflydelse p˚a hvordan systemet skal opbygges.
5.3 Anskaffelse af system
Der er forskellige muligheder for hvordan systemer, som det kommende løsningsforslag, kan
erhverves af brugeren. Den ene mulighed er, at det kan købes som en tilføjelse til en allerede
købt bil eller trailer, hvilket ved sige hos en forhandler af autotilbehør- og reservedele. En
anden mulighed er at det bliver integreret i bilen og bliver solgt som ekstraudstyr sammen
med bilen. En sidste løsning er at systemet bliver koblet p˚a traileren og bliver solgt som
ekstraudstyr sammen med denne. I det følgende vil fordele og ulemper ved de forskellige
muligheder bliver beskrevet. De to ovenst˚aende muligheder hvor systemet bliver koblet p˚a
traileren eller bilen, vil blive refereret til som et integreret system, og løskøbs-muligheden
hvor brugeren selv skal montere systemet, bliver refereret til som et løskøbs-system.
Integreret system
Der er klare fordele ved at lave et system der er integreret i enten bil eller trailer, hvilket
medfører at brugeren ikke skal montere eller installere noget selv. Jo mere brugeren skal
gøre selv, des større er sandsynligheden for at der opst˚ar fejl i montering eller installering,
hvilket potentielt kan resultere i at produktet svigter eller kun fungerer delvist. Et integreret
system fungerer alts˚a uden brugerens indblanding, hvilket bevirker at produktet kan være
under bil- eller trailerproducentens garanti.
Hvis valgene fra forrige afsnit tages i betragtning er der en klar fordel ved at integrere
systemet i bilen. Hvis dette var tilfældet, kunne bilens højtalere anvendes til at videregive
informationer om risiko for kollision mellem bil og trailer. Dermed kunne flere højtalere
anvendes og en eventuel retning, for hvilken side kollisionen er ved at forekomme, kan angives.
Hvis systemet bliver koblet p˚a traileren, vil mulighederne for at formidle informationer til
brugeren reduceres, medmindre der vælges at anvende et produkt der har til form˚al har at
videregive informationer fra systemet til brugeren.
22

Løskøbs-system
Fordelen ved at systemet kan akkvireres som løskøb er, at det kan bruges af alle, uanset
bilens mærke eller alder. Her er det nødvendigt, ligesom i ovenst˚aende tilfælde ved tilkobling
i trailerens el-net, at bruge et eksisterende produkt til at formidle informationerne med, hvis
der b˚ade skal stimuleres visuelt og auditivt. Desuden kan løskøbs-systemet ved lys-tjek kun
m˚ale om der er fejl i de signaler bilen leverer til bilens anhængerstik. Det er dermed ikke
muligt at specificere hvor fejlen befinder sig i bilens el-net.
Der er tidligere i dette kapitel foretaget valg omkring hvilke sanser, informationen for lys-tjek
og risiko for kollision, skal stimuleres. Der blev valgt at stimulere brugeren b˚ade auditivt og
visuelt. Da det integrerede system vanskeliggør at stimulere visuelt, men letkøbs-systemet
begrænser kvaliteten p˚a den auditive stimulus, er det nødvendigt at undersøge hvilke pro-
dukter der potentielt kan anvendes til formidling af b˚ade auditive og visuelle stimuli, hvis
de skal tilpasses allerede eksisterende produkter.
Interaktive produkter
Der skal alts˚a findes et mellemprodukt, der kan komunikere med brugeren, uanset om der
vælges at udvikle et integreret system eller et løskøbs-system. Dette vil gøres i det følgende.
Der findes mange produkter der kan interagere med brugeren, men hvilke produkter hvorp˚a
der kan implementeres et system, sætter nogle krav til det eksisterende produkt. Hvis et
eksisterende produkt skal anvendes til formidling af auditive og visuelle informationer, sæt-
ter det nogle krav til produktet. Der skal kunne overføres og installeres et system eller
program til produktet, ligesom programmer kan overføres og installeres p˚a en computer.
Udover eventuelle krav til produktet, vil det være hensigtsmæssigt at designe systemet til et
eksisterende produkt, der hyppigt bliver anvendt af m˚algruppen. Scenariet for denne hyp-
pige anvendelse af produktet m˚a nødvendigvis inkludere bilen. Umiddelbart kan der nævnes
tre produkter som ligger i den kategori:
• GPS (Global Positioning System)
• PDA (Personal Digital Assistant)
• Mobiltelefon
Der er fordele og ulemper ved disse tre eksistrerende produkter, hvilke skal analyseres inden
et endeligt valg, om hvilket produkt systemet skal designes til, kan tages. 32% af de danske
hjem har anskaffet sig en GPS [Pedersen, 2008]. Umiddelbart kan der siges, at en GPS enhed
allerede fungerer som tilbehør til bilen, s˚a den er formentlig altid i aktiveret i bilen, n˚ar en
ukendt rute skal køres efter. Dette kan samtidig være en ulempe, hvis denne enhed kun er
aktiveret n˚ar den skal udføre sin primære opgave. Dette vil betyde, at brugeren skal aktivere
den hver gang en trailer p˚asættes.
Der har mobiltelefonen en fordel p˚a flere m˚ader. 95% af de danske hjem ejer en mobiltelefon
[Informationscenter for Miljø og sundhed, 2008], s˚a markedet for mobiltelefoner m˚a være
betydeligt større end GPS-enheder. Begge enheder kræver interaktion af brugeren, og p˚a
23

egge kan der installeres ny software. Dermed er der umiddelbart ingen forhindring i at
udvikle systemet til de tre enheder, hvorforbeslutningen om hvilket produkt der vælges at
udvikle til, kunne tages p˚a basis af markedsstørrelse.
N˚ar disse produkter i forvejen findes, ses der ingen grund til at udvikle et nyt produkt med
samme form˚al, hvorfor mobiltelefonen hermed vælges som mellemprodukt p˚a grund af dens
udbredelse i de danske hjem.
5.4 Delkonklusion
I dette kapitel er m˚algruppen defineret, samt interaktionen mellem brugeren og et kommende
system er valgt, hvilket gør det muligt at fortsætte udviklingen. M˚algruppen er valgt som
bred, best˚aende af mænd og kvinder med kørekort i alle aldre, der ved brug af systemet
vil blive stimuleret auditivt samt visuelt. Disse stimuli vil blive gjort mere specifikke under
designet af systemet. Dog skal potentiel maskering af b˚aden den visuelle og auditive stimulus
tages i betragtning n˚ar disse skal udvikles. Til sidst blev der besluttet at systemet skal
interagere med brugeren ved hjælp af en mobiltelefon. I det følgende vil en konkretisering af
systemet udarbejdes. Desuden vil muligheder, for hvordan systemet skal kommunikere med
mobiltelefonen, blive undersøgt.
24

KAPITEL 6
Trailerhjælper
I dette kapitel vil der undersøges om der i forvejen findes systemer, med samme form˚al, der
kan supplere med idéer til hvordan den videre udvikling kan foreg˚a. Form˚alet er i denne
sammenhæng at reducere besvær brugeren eventuelt m˚atte have ved at tjekke lysene p˚a
traileren, samt at advare brugeren om risiko for kollision mellem bil og trailer. Efterfølgende
vil en konkretisering af det tiltænkte system udarbejdes, s˚a en endelig designproces kan
p˚abegyndes. Systemet som tænkes udviklet vil i det efterfølgende blive refereret til som
Trailerhjælperen.
Eksisterende produkter
En undersøgelse af eksisterende produkter p˚a markedet blev udarbejdet, for at kunne es-
timere hvorvidt der i forvejen findes lignende systemer, se Appndiks C. Konklusionen blev,
at der allerede findes systemer, der kan tjekke om lysene p˚a traileren fungerer. Disse syste-
mer har tilfælles, at de er integreret i bilen. Hvad ang˚ar sammenknæk mellem bil og trailer,
eksisterer der ikke lignende produkter p˚a markedet. Inspiration fra disse eksisterende syste-
mer, er ikke at hente, da disse som tidligere nævnt alle er integreret i bilen. I M˚algruppe og
interaktion, afsnit 5.4, blev der valgt at systemet der tænkes lavet, skal kunne akkvireres af
alle uanset biltype og bilens alder hvorfor et løskøbs-system er at foretrække.
Integrering af systemet
Indtil videre er det blevet bestemt hvad systemet skal kunne, men ikke hvor det skal im-
plementeres. N˚ar bilen skal kobles sammen med en trailer, skal føreren sætte trailerstikket
i bilens anhængerstik. Af hensigtsmæssige ˚arsager, er der valgt at systemet skal kobles p˚a
mellem trailerstikket og stikd˚asen. Dette er illustreret p˚a Figur 6.1 p˚a næste side.
Trailerstikkene kan variere mellem 7-polets stik og 13-polets stik afhængigt af trailerens
størrelse. Henrik Egelund, se Sektion 2.3 p˚a side 7, estimerer at Thule Trailers ˚arligt pro-
ducerer 30.000 trailere. Af disse trailere er blot 50 udstyret med 13-polet stik. Dermed er
andelen af trailere med 7-polet stik, udfra Thule Trailers produktion, væsentlig større, hvor-
for der vælges at udvikle systemet s˚a det kan integreres med et 7-polet stik. Hvis brugere
med biler udstyret med en stikd˚ase til 13-polets stik ønsker at anvende det tiltænkte system,
kan en adapter købes som forbinder 7-polets trailerstik med 13-polet stikd˚ase eller omvendt.
Det tænkes at mellemstykket skal have et hanstik indbygget i den ene ende og et hunstik
indbygget i anden ende. Størrelsen p˚a mellemstykket tænkes at stemme overens med trail-
25

Figur 6.1: systemet placeres mellem bilens og trailerens stik og en cylindrisk beholder i samme
størrelse vil være preferabelt
erstikket. Længden af mellemstykket vil forsøges at holdes s˚a kort som muligt, men kommer
til at afhænge af størrelsen af indholdet. Mellemstykket skal kunne registrere aktivering af
lysene p˚a traileren samt kommunikere med brugerens mobiltelefon. Desuden skal systemet
kunne m˚ale afstanden mellem bilens bagende og traileren, og sende et signal til mobiltelefo-
nen om at der er risiko for kollision. Hvordan dette signal skal sendes til mobilenheden, vil
i det følgende blive evalueret.
Overførsel af signal
Der er valgt at systemet skal sende informationer til brugerens mobiltelefon, hvilket umid-
delbart kan gøres p˚a flere m˚ader, hvis signalet skal sendes tr˚adløst. Dette kan foreg˚a via
en FM-forbindelse, hvor signalet sendes via en bestemt frekvens. Dette vil blot kræve at
brugeren tænder for radioen i bilen, og finder den p˚agældende frekvens. Dermed kan lyden
høres i bilens højtalere, dog kun via 2-kanaler. Der kan dog være problemstillinger ved at
anvende denne metode for at videregive tr˚adløse signaler p˚a, da informationsmængden kan
blive begrænset til kun værende auditiv. Tidligere, i Valg og fravalg Afsnit 5.2, blev der valgt
at brugeren skal stimuleres b˚ade visuelt samt auditivt, hvorfor anvendelse af FM-signaler
kan besværliggøre udviklingen af de visuelle stimuli, da disse ikke kan sendes til brugerens
mobiltelefon.
En mobiltelefonen kan danne flere typer af tr˚adløse data-forbindelser. De mest gængse er da-
ta over GPRS, Bluetooth og WiFi. Det er dog ikke alle telefoner, der har WiFi-modul, og data
over GPRS vil i de fleste tilfælde koste brugeren penge for dataforbruget. Bluetooth-moduler
er efterh˚anden ved at være standard i de fleste nyere mobiltelefoner, og er derfor det opti-
male valg, af de tre forbindelstyper. Derved kræves der, for at kunne anvende det kommende
system, at brugerens mobiltelefon er udstyret med Bluetooth-modul. Hvis informationerne
vælges at sendes via Bluetooth, er der ingen begrænsning p˚a, om informationerne bliver
videregivet auditivt eller visuelt. Kvaliteten af den auditive information falder, da bilens
højtalere ikke kan anvendes. Dog er fordelen stor ved at anvende Bluetooth-teknologien, da
informationerne kan videregives visuelt og auditivt, og en interaktionen mellem brugeren og
systemet bliver centreret omkring mobiltelefonen. Derfor vælges Bluetooth til at videregive
signalerne mellem systemet og brugerens mobiltelefon.
26

6.1 Konkretisering
Der er besluttet, at lave en prototype der kan kommunikere med en mobiltelefon via Blue-
tooth. Brugeren vil skulle montere mellemstykket mellem bilens anhængerstik og trailer-
stikket. N˚ar dette er gjort er brugerens opgave blot at tænde for Bluetooth-forbindelsen p˚a
mobiltelefonen, hvor trailerens lys kan tjekkes inde fra førersædet ved hjælp af mobiltelefo-
nen. En illustration af de overordnede beslutninger er vist p˚a Figur 6.2.
Vinkelmåler
Mellemstykket
Figur 6.2: Systemet best˚ar af tre konkrete komponenter
Lystjekket tænkes p˚abegyndt umiddelbart efter systemet har f˚aet strøm fra bilen og er
startet op. Dog kan bremselyset og blinklyset først tjekkes n˚ar disse bliver aktiveret af
brugeren. N˚ar systemet har tjekket hvorvidt der er strøm ud til lysene p˚a traileren, tænkes
der at brugeren skal have visuel feedback om at lysene er i orden. Endvidere skal dette
informeres om, n˚ar brugeren har aktiveret bremse- og blinklysene. N˚ar der vælges at ikke at
“p˚atvinge” brugeren til at aktivere bremse- og blinklys, kan brugeren selv bestemme hvorn˚ar
disse aktiveres. Under kørsel vil den visuelle feedback være tilstede og notificere brugeren
hvis der sker ændringer p˚a lysenes funktionalitet. Det tænkes endvidere at der skal være
mulighed for yderligere informationer, hvis brugeren ønsker det, p˚a mobiltelefonens display.
Det vil sige, at hvis højre blinklys bliver defekt, kan brugeren b˚ade se det p˚a et billede p˚a
skærmen, men ogs˚a finde tekst med en forklaring af hvad der kan være galt.
Der tænkes at systemet skal give brugeren en auditiv alarm, n˚ar der er risiko for kollision
mellem bil og trailer, se Figur 6.3 p˚a den følgende side.
27

Figur 6.3: Illustrering af alarmeringsomr˚ade for kollision mellem bil og trailer. Alarmen starter
blødt op og intensiveres indtil sidste chance for at undg˚a kollision.
Denne funktion tænkes at skulle aktiveres af brugeren inden bakning. Der skal derfor tages
hensyn til dette n˚ar interfacet til mobiltelefonen skal udarbejdes. N˚ar denne alarmerende lyd
skal udvikles, skal der tages hensyn til brugerens reaktionstid. Der skal være en tilstrækkelig
buffer, s˚a brugeren kan n˚a at percipere lyden samt reagere p˚a denne, uden at traileren
kolliderer med bilens bagende.
Systemets funktioner og virkem˚ader er hermed beskrevet, p˚a et overordnet niveau. Næste
skridt er at f˚a disse beskrivelser omformet til konkrete krav som produktet kan udvikles
100%
100%
efter. Disse krav vil i det følgende blive udarbejdet og listet.
28
0%
0%

7.1 Produkt-kravspecifikation
KAPITEL 7
Produkt-kravspecifikation
Denne kravspecifikation er lavet ud fra den netop overst˚aede problemanalyse og vil gælde
for det overordnede produkt, som blev beskrevet i Konkretisering, Afsnit 6.1. Kravspecifika-
tionen er primært til internt brug og indeholder kun de, for nærværende system, relevante
punkter og vil derfor ikke tage punkter som eksempelvis producenter og leverandører op.
Form˚alet med denne er, at f˚a de fremkomne delkonklusioner listet og omformuleret til krav
s˚aledes disse kan designes efter.
Problemformulering
Form˚alet med systemet er at løse problemerne:
• Hvordan gøres det mindre besværlig for brugeren at lave lystjek p˚a en trailer og min-
imere brugerfejl ved lystjek?
• Hvordan minimeres risikoen for at brugeren for˚arsager en kollision mellem bil og trailer
i forbindelse med en bakkemanøvre?
M˚algruppe
Produktet henvender sig til alle med kørekort, uanset køn, alder og tekniske kundskaber.
Det kræves at brugeren har kendskab til betjening og anvendelse af mobiltelefoner. Der tages
ikke højde for nogen former for handikap der kan p˚avirke brug af produktet.
29

Krav
Krav til Trailerhjælper-systemet
Krav til system
Krav 1: Der m˚a ikke foretages konstruktionsmæssige ændringer i bil eller
trailer
Krav 2: Hele systemet skal implementeres mellem bilens stik og trailerens
stik
Krav 3: Systemet skal kunne indkapsles, s˚a det kan modst˚a vand og snavs
Krav 4: En mobiltelefon skal anvendes til at videregive informationer til
brugeren
Krav 5: Signalet mellem mobiltelefon og resten af systemet skal foreg˚a via
Bluetooth
Krav 6: Systemet skal fungere til alle gængse mobiltelefoner med Bluetooth
Krav til lystjek
Krav 7: Lystjekket skal være aktivt, s˚a længe systemet modtager strøm
fra bilen
Krav 8: Lystjekket skal laves ved m˚aling p˚a bil og trailers el-net
Krav 9: En defekt i bil og trailers el-net, samt en indikation om hvor denne
fejl er, skal videreformidles til brugeren ved hjælp af mobiltelefonen.
Krav 10: Systemet skal opdatere informationen om defekter i el-nettet og
gøre informationen tilgængelig for brugeren s˚a længe systemet er
aktivt.
Krav 11: Information om Lystjek skal formidles til brugeren visuelt, via
illustration og en skriftlig forklaring
Krav til kollisionsalarm
Krav 12: Systemet skal bestemme afstanden til en kollision mellem bil og
traileren
Krav 13: Systemet skal forudsige hvorn˚ar en kollision mellem bil og traileren
vil indtræffe. Eftersom tiden er proportional med afstanden til en
kollision, kan denne tid findes ud fra hastigheden og accelrationen
p˚a ændringen af afstanden til en kollision
Krav 14: Information om afstanden til en kollision mellem bil og trailer skal
gøres tilgængelig for brugeren via mobiltelefonen
Krav 15: Brugeren skal notificeres om fare for kollision ved hjælp af en
auditiv alarm, som skal afspilles gennem mobiltelefonens højtaler
Krav 16: Alarmen om fare for kollision skal gives tids nok til at en kollision
kan undg˚aes
Tabel 7.1: Tabel med kravspecifikation for det samlede Trailerhjælper-system
Disse krav blev udledt af problemanalyse afsnittet og er de krav som systemet skal overholde
for at kunne løse den problemformuleringen. Verificeringen af disse krav vil blive udført ved
hjælp af en acceptest som kan findes i Appendiks H.
30

7.2 Afgrænsning
• Der vil ikke blive kigget nærmere p˚a bilens ledningsnet, hvorfor bilens el-net betragtes
som en ´´black-box”
• Der vil i projektet ikke blive taget højde for afvigelser fra det typiske ledningsnet
for en trailer. Dette er delvist bestemet af standarden for det 7-polede stik, men der
vurderes at der kan forekomme afvigelser, som kan kan have indflydelse p˚a systemets
funktioner. Hvorvidt disse afvigelser forekommer ved brugeren, der selv har modificeret
udformningen af ledningsnettet, eller om producenten af trailen ligeledes afviger fra
defacto-standarderne p˚a omr˚adet, vides ikke.
• Der vil i projektet ikke blive taget stilling til, hvorvidt kollisionsalarmen reelt fungerer
ud fra reaktionstider med mere. Da testen som vil kunne afdække dette har mange vari-
able eksempelvis førerens reaktionstid, bilens reaktionstid, trailerens størrelse, bilens
størrelse, underlag, hastighed og mange andre. Derfor kan det i realiteten være at
traileren knækker ud og rammer bilen p˚a 1,5 sekunder mens der kræves 2 sekunder
fra alarmen lyder til det kan garanteres at bilen holder stille.
• Der vil ikke garanteres, at kollision mellem bil og trailer ikke forekommer, hvis bilisten
kører uforsvarligt.
31

Del II
Design
33

Del 2: Indledning
Efter den netop overst˚aede problemanalyse og kravspecifikation, hvor det kommende pro-
dukt overordnet blev beskrevet, kan der nu fortsættes med en fordybelse i, hvilket indhold
produktet bør have. Dermed vil der, i del 2, analyseres hvad indholdet af produktet bør være
og hvordan det tænkes udviklet. Denne proces vil forekomme for hele produktet, fra sys-
temet der skal registrere funktionaliteten af lysene til og med brugergrænsefladen. Form˚alet
med denne del er, at f˚a udviklet produktet for at muliggøre eventuelle tests af dette, for at
konkludere hvorvidt produktet skal igennem flere iterationer for at blive funktionelt.
34

KAPITEL 8
Konceptanalyse
Ud fra den overordnede produkt-kravspecifikation skal der nu udvikles et system, som over-
holder kravene i denne. Første led i den forest˚aende udvikling vil være en yderligere analyse,
som ligger p˚a et mere teknisk niveau. Denne vil have til form˚al, at fastlægge hvilke metoder
der er hensigtsmæssige at udvikle efter. Efter systemanalysen bør alle systemets tekniske
detaljer dermed kendes.
M˚aden hvorp˚a der er valgt at gennemføre systemanalysen, er hovedsageligt ved hjælp af
use cases. Use casene bruges her til at afdække de mulige benyttelses-mønstre for systemet,
for at finde frem til krav til indholdet af systemet. Efter use casene er gennemg˚aet bør
funktionalitetskravene til systemet kunne opstilles, hvorefter der kan dannes et overblik
over, hvad indholdet af systemet skal være. Ligeledes bør der kunne afgøres, hvilke mindre
systemer Trailerhjælperen kan deles op i.
8.1 Use cases
I dette afsnit vil et use case diagram indledningsvis blive udarbejdet som et led i systemets
designfase. Use case diagrammet vil være et overordnet diagram, som kun indeholder f˚a
funktioner. Dette vil senere blive gjort mere detaljeret. Det er nødvendigt, at vide hvilke
inputs og outputs systemet skal kunne levere og tage imod, for senere at kunne designe
et system, som kan dette. Diagrammet skal give indblik i samspillet mellem brugeren og
systemet, samt hvilke funktioner systemet skal udføre. Faktorerne der har indflydelse, i
denne sammenhæng, er brugeren, traileren og bilen. Use case diagrammet er illustreret p˚a
Figur 8.1, hvor faktorerne der spiller ind, er placeret udenfor systemt.
Tjek signal
fra bil
Tjek forbindelse
gennem trailer
Vinkelmåler
Trailerhjælper
Brugerflade
for lystjek
Brugerflade
for vinkel status
Figur 8.1: Use case diagram for Trailerhjælper
35
Bruger

I disse fem forskellige funktioner, hvor systemet skal kunne interagere med de op til systemet
grænsende faktorer, skal der analyseres hvilke informationer, der skal kunne h˚andteres og
videregives af systemet.
Herunder vil de fem tilfælde blive gennemg˚aet enkeltvis. Disse opdeles i normal- og und-
tagelsesscenarier, hvor normalscenariet beskriver det p˚agældende tilfældes tiltænkte funk-
tion i en benyttelses-situation. Undtagelsesscenariet er en beskrivelse af, hvilke afvigelser og
undtagelser der kan forekomme.
8.1.1 Brugerflade for Lystjek
M˚alsætning: Give brugeren mulighed for at interagere med systemet n˚ar lystjekket er initieret
S˚afremt lystjekket forløber uden problemer foreg˚ar dette som illustreret, i normalscenariet,
Tabel 8.1.
Der kan umiddelbart opst˚a fejl tre steder:
• I den tr˚aløse forbindelse
• I stikkene mellem bil og trailer
• En defekt i bilen og/eller p˚a traileren
Hvis der skulle opst˚a fejl et af disse steder, under forløbet, skal systemet registrere dette
som beskrevet i undtagelsesscenariet i figuren.
Brugerflade for lystjek
Normalscenarie Undtagelsesscenarie
N˚ar systemet modtager strøm fra bilens
anhængerstik, aktiveres lystjekket
Positions-, nummerplade- og baglys
tjekkes tjekkes og brugeren f˚ar informationer
om disse fungerer korrekt
N˚ar brugeren aktiverer bremse- og
blink- og t˚agelys modtager brugeren informationer
om at disse lys fungerer
Der er ikke forbindelse til systemet
Der er en eller flere forbindelser i stikket
p˚a bilen der ikke virker
Et eller flere lys p˚a traileren virker ikke
Stikket er ikke p˚amonteret korrekt
Tabel 8.1: Funktionen: Brugerflade for lystjek, oprinder fra use case-diagrammet. I venstre kolonne
beskrives hvorledes funktionen gennemføres uden fejl. I højre kolonne er alle de mulige fejl, der kan
opst˚a under funktionen, listet
Ud over de nævnte fejlmeldinger, som sker p˚a bruger-siden af systemet, kan der muligvis
findes flere fejl, hvis der kigges nærmere p˚a hvad der sker i bilen og traileren.
36

8.1.2 Tjek signal fra bilen
M˚alsætning: N˚ar lystjekket aktiveres, skal systemet tjekke om der modtages de ønskede sig-
naler fra bilens stik
S˚afremt alle forbindelser, gennem bilen og stikket, fungerer korrekt vil der kunne konstateres,
at alt virker n˚ar normalscenariet i Figur 8.2 er gennemløbet.
Tjek signal fra bil
Normalscenarie Undtagelsesscenarie
Systemet tjekker om der modtages signal
til kørelysene og sender resultatet til
mobiltelefonen. Kørelyset er positions-,
t˚age og nummerpladelyset
- M˚alesystemet afventer bremsesignal.
N˚ar signalet til bremselyset modtages,
sendes resultatet til mobiltelefonen
M˚alesystemet afventer signal til højre
blinklys. N˚ar signalet modtages, sendes
resultatet til mobiltelefonen
M˚alesystemet afventer signal til venstre
blinklys. N˚ar signalet modtages, sendes
resultatet til mobiltelefonen
M˚alesystemet modtager intet signal til
kørelysene
M˚alesystemet modtager et forkert signal
M˚alesystemet modtager ikke et givent
signal, eksempelvis for højre kørelys
Tabel 8.2: Funktionen: Tjek signal fra bilen, oprinder fra use case-diagrammet. I venstre kolonne
beskrives hvorledes funktionen gennemføres uden fejl. I højre kolonne er samtlige fejl, der kan opst˚a
under funktionen, listet
8.1.3 Tjek forbindelse gennem trailer
M˚alsætning: N˚ar lystjekket aktiveres, skal systemet tjekke om de aktiverede lys p˚a traileren
fungerer korrekt
S˚afremt alle forbindelser gennem traileren og stikket fungerer korrekt, vil der kunne kon-
stateres at alt virker n˚ar normalscenariet i Figur 8.3 er gennemløbet.
37

Tjek forbindelse gennem trailer
Normalscenarie Undtagelsesscenarie
M˚alesystemet tjekker at de kørelysene
p˚a traileren lyser og sender resultatet
til mobiltelefonen
N˚ar bremselyset lyser, sender
m˚alesystemet resultatet til mobiltelefonen
N˚ar højre blinklys blinker, sender
m˚alesystemet resultatet til mobiltelefonen
N˚ar venstre blinklys blinker, sender
m˚alesystemet resultatet til mobiltelefonen
M˚alesystemet modtager intet signal til
kørelysene
M˚alesystemet modtager et forkert signal
M˚alesystemet modtager ikke et givent
signal, eksempelvis for højre kørelys
Tabel 8.3: Funktionen: Tjek signal gennem trailer, oprinder fra use case-diagrammet. Venstre
kolonne beskriver hvorledes funktionen gennemføres uden fejl. I højre kolonne er samtlige fejl, der
kan opst˚a under funktionen, listet.
8.1.4 Brugerflade for vinkel status
M˚alsætning: Giver brugeren mulighed for aktivere kollisions-alarmen, der alarmerer brugeren
hvis der er risiko for at bil og trailer kolliderer
Hvis systemet fungerer korrekt vil kollisions-alarmen fungere som illustreret i normalsce-
nariet p˚a Figur 8.4, og fejl som kan opst˚a mellem mobiltelefon og m˚alesystem, kan ses i
undtagelsesscenariet i samme figur.
38

Brugerflade for vinkelstatus
Normalscenarie Undtagelsesscenarie
Bakketilstand aktiveres Intet signal fra m˚alesystemet
Brugerfladen modtager vinkelstatus og
vinkelaaceleration fra m˚alesystem
Brugerfladen genererer et output til
brugeren om trailerens vinkel i forhold
til bilen
Hvis der opn˚aes en vinkel, hvor en
fortsat ændring vil resultere i en kollision
mellem bil og trailer, alarmeres
brugeren om situationen, tidsnok til at
brugeren kan n˚a at reagere
Bakketilstand deaktiveres
Tabel 8.4: Funktionen: Brugerflade for vinkelstatus, oprinder fra use case-diagrammet. Venstre
kolonne beskriver hvorledes funktionen gennemføres uden fejl. I højre kolonne er samtlige fejl, der
kan opst˚a under funktionen listet
8.1.5 Vinkelm˚aler
M˚alsætning: M˚alesystemet genererer et signal om trailerens vinkeltilstand
M˚alingen bliver foretaget kontinuerligt, s˚a selv sm˚a ændringer i vinklen opfanges. Fejl som
kan opst˚a mellem vinkelm˚alingen og m˚alesystemet, er illustreret i Figur 8.5 under und-
tagelsesscenariet.
Vinkelm˚aler
Normalscenarie Undtagelsesscenarie
Vinkelm˚aling p˚abegyndes Intet signal om vinkelm˚aling
Vinkel-accelerationsberegningen
p˚abegyndes
M˚alesystemet sender vinklen til brugerfladen
M˚alesystemet sender informationen om
eventuel kollisionsfare til brugerfladen
Forkert signal om vinkelm˚alingen
Tabel 8.5: Funktionen: Vinkelm˚aler, oprinder fra use case-diagrammet. Venstre kolonne beskriver
hvorledes funktionen gennemføres uden fejl. I højre kolonne er samtlige fejl, der kan opst˚a under
funktionen listet
Efter disse scenarier er bearbejdede, kendes informations-flowet i systemet. Det vides s˚aledes
hvorn˚ar der skal informationer ind, og hvorn˚ar systemet skal levere informationer. Yderligere
er de informationer, brugeren skal modtage til dels beskrevet. Denne proces vil fortsætte
under udviklingen af brugerfladen.
39

Med det kendskab der netop er opn˚aet, til den forest˚aende produktudvikling, kan det være
hensigtsmæssigt at opdele og opbygge denne efter nogle specifikke retningslinjer.
8.2 Krav og videre forløb
Dette afsnit har til form˚al, at sikre at den efterfølgende udvikling sker ud fra den netop
overst˚aede analyse, og samtidig at forsøge at opdele udviklingsprocessen i nogle processer,
som kan forløbe enten kontinuertligt eller sideløbende s˚aledes at et optimalt forløb sikres,
s˚a vidt muligt.
8.2.1 Krav til udviklingen
N˚ar der er valgt at udvikle Trailerhjælper ud fra de gennemg˚aede use-cases, og for at sikre at
disse bliver opfyldt, vil der i dette afsnit blive opstillet funktionskrav til systemet. Disse krav
er udelukkende dannet p˚a baggrund af de opstillede use cases. Kravene til disse funktioner,
som Trailerhjælper skal opbygges efter, er beskrevet i det følgende.
1. Systemet skal indeholde en interaktiv brugerflade
2. Systemet skal kunne afgøre om bilens anhængerstik leverer de korrekte signaler
3. Systemet skal kunne afgøre om traileren returnerer de korrekte signaler
4. Systemet skal kunne afgøre hvorvidt lysene, p˚a en p˚amonteret trailer, er funktions-
dygtige
5. Systemet skal, i forbindelse med bakning, kunne m˚ale vinklen mellem bil og den
p˚amonterede trailer
6. Systemet skal, i forbindelse med bakning, kunne m˚ale med hvilken hastighed vinklen,
mellem bil og den p˚amonterede trailer, ændrer sig samt afgøre hvilken effekt denne
har for hvorn˚ar bil og trailer kolliderer
7. Systemet skal i alle situationer give brugeren en tilbagemelding p˚a systemets proces.
Opst˚ar der fejl i systemet, skal brugeren have melding om denne samt et løsningsforslag
for udbedring af fejlen.
8.2.2 Konceptoversigt og opdeling
Det er nødvendigt, at systemet indeholder de elementer, der kan varetage funktionerne, der
er opstillet i forhold til funktionskravene og use casene beskrevet tidligere. Overordnet kan
systemet opdeles i to dele, et formidlingsystem og et m˚alesystem. Formidlingssystemet skal
varetage al interaktion med brugeren, og m˚alesystemet skal foretage de nødvendige m˚alinger
og videregive informationen til formidlingssystemet. Et overordnet blokdiagram af systemet
er illustreret p˚a Figur 8.2.
40

Tjek signal
fra bil
Tjek forbindelse
gennem trailer
Målesystem
Vinkelmåler
Trailerhjælper
Brugerflade
for lystjek
Formidlingssystem
Brugerflade
for vinkel status
Figur 8.2: Overordnet blokdiagram for Trailerhjælper
Bruger
I de følgende to kapitler vil først m˚alesystemet og dernæst formidlingsystemet blive analy-
seret, med henblik p˚a at finde input/output-relationer(I/O) for at kunne opstille en endelig
kravspecifikation for systemerne. Disse input/output-relationer er nødvendige, for at sikre
at Trailerhjælpers forskellige systemer, kan fungere i sammenspil med hinanden. Det kunne
derfor være hensigtsmæssigt at opdele systemet i de to følgende systemer.
• Fomidlingsystemet
• M˚alesystemet
M˚alesystemet og formidlingssystemet skal analyseres yderligere, før disse kan udvikles op-
timalt. P˚a nuværende tidspunkt bør enhver detalje afdækkes inden det egentlige design
fastlægges. Use casene har ikke afdækket samtlige aspekter, som der p˚a nuværende tid-
punkt bør erhverves viden om. Systemets fysiske grænseflader kan analyseres yderligere.
Her tænkes blandt andet placering, miljø, strøm der er til r˚adighed, muligheder for indhold i
m˚alesystemet og muligheder for vinkelm˚aling samt andre aspekter. Til sidst bør de afklarede
detaljer udspecificeres i en kravspecifikationer for systemerne.
Der er mange m˚ader at foretage en analyse som denne p˚a. Her vælges der, at analysere
systemernes grænseflader. Først for m˚alesystemet, som vil blive udviklet herefter, og derefter
følger udviklingen af formidlingssystemet.
41

KAPITEL 9
Analyse af m˚alesystem
I analysen af m˚alesystemet, hvilket det næste kapitel vil omhandle, vil der forsøges at afk-
lare alle aspekter, vedrørende grænsefladerne, uden at tage stilling til det konkrete indhold
i systemerne. Se eventuelt Figur 1 for et overblik over udviklingsprocessen. Fundamentale
beslutninger skal træffes i afsnittet, hvilket ikke kan undlades at tage, inden det konkrete de-
sign. Dette værende eksempelvis valg af microcomputer-platform og programmeringssprog.
For at kunne designe m˚alesystemet, er det nødvendigt at f˚a fastlagt, hvilke grænseflad-
er m˚alesystemet skal interagere med blandt andet for at kunne f˚a opstillet input/output-
relationer. M˚alesystemet skal hente informationer om de elektriske signaler, der løber fra
bilens anhængerstik og gennem traileren. Derfor har m˚alesystemet en grænseflade i forhold
til bilen samt en grænseflade i forhold til traileren. Ydermere skal m˚alesystemet kunne kom-
munikere via Bluetooth med formidlingssystemet, hvilket giver en tredje grænseflade. Et
blokdiagram af systemet er illustrereret p˚a Figur 9.1.
Tjek signal
fra bil
Tjek forbindelse
gennem trailer
Trailerhjælper
2 3
1
Målesystem
Vinkelmåler
Brugerflade
for lystjek
Formidlingssystem
Brugerflade
for vinkel status
Figur 9.1: M˚alesystemets tre grænseflader
De kommende afsnit vil behandle de tre grænseflader, der er illustreret, for at kunne kon-
kludere hvordan systemet skal designes.
9.1 Grænsefladen til traileren
I dette afsnit vil der analyseres, hvordan det er muligt at m˚ale om lyset p˚a traileren fungerer
korrekt. For at kunne definere hvilke I/O-relationer der er p˚a en trailer, er det nødvendigt
at vide hvordan kredsløbet i en trailer er udformet, og hvordan det er samlet i trailerstikket.
P˚a Figur 9.2 og Figur 9.3 er de to standardiserede 7-polet og 13-polet trailerstik, i henhold til
ISO standarden 1724-2003, illustreret. Standarden 1724 er den 4. udgave af standarden. Den
42

1. udgave udkom som 1724-1975, hvilket vil sige i ˚aret 1975. Det 7-polede stik, og dermed
ogs˚a m˚aden at føre kablerne gennem traileren p˚a, har alts˚a været standard siden 1975.
6
6
5
5
1
1
7
7
4
2
2
3
7
6 7
4
5
6
4
8
18
1
3
9
910
2
11
10
2
513
3 1211
13 12
7-Polet stik
1 7-Polet – Blinklys, stik venstre
2 – Fri / tågebaglys
3 1 – Stel Blinklys, venstre
4 2 – Blinklys, Fri / tågebaglys højre
5 3 – Baglygte, Stel positionslys og Nr.plade lys - (Højre side)
6 4 – Bremselys Blinklys, højre
7 5 – Baglygte, positionslys og Nr.plade lys - (Venstre (Højre side)
6 – Bremselys
7 – Baglygte, positionslys og Nr.plade lys - (Venstre side)
Figur 9.2: Illustration af 7-polet stik og en forbindelsesoversigt
13-Polet stik
1 13-Polet – Blinklys, stikvenstre
2 – Fri / tågebaglys
3 1 – Stel Blinklys, (for polerne venstre1-8)
4 2 – Blinklys, Fri / tågebaglys højre
5 3 – Baglygte, Stel (for polerne positionslys 1-8) og Nr.plade lys - (Højre side)
6 4 – Bremselys Blinklys, højre
7 5 – Baglygte, positionslys og Nr.plade lys - (Venstre (Højre side)
8 6 – Baklys Bremselys
9 7 – Strømforsyning Baglygte, positionslys (konstant og Nr.plade +) lys - (Venstre side)
10 8 – Baklys Ladeledning (tændingsstyret +)
11 9 – Strømforsyning Fri
(konstant +)
12 10 – Fri Ladeledning (tændingsstyret +)
13 11 – Stel Fri (for polerne 9-12)
12 – Fri
13 – Stel (for polerne 9-12)
Pol 1
Som tidligere beskrevet, i Del 1 Integrering af systemet Sektion 6 p˚a side 25, er der beslut-
Blinklys
Pol 1
Positionslys
tet, at systemet skal være kompatibelt til flest mulige trailere, hvorfor der blev valgt at
Pol 7
Baglygte
Blinklys
Positionslys
tage udgangspunkt i standarden for 7-polet stik. Den trailermodel det er bestemt at tage
Nr. plade
Pol 7
Baglygte
Bremselys,
Nr. plade
Venstre
symmetrisk placeret antal pærer i højre- ogPol venstre 6 kørelys. Derfor tages der ikke højde
Bremselys, Bremselys, Højre Venstre
for trailere, hvis ledningsnet ikke er opbyggetPol s˚aledes. 6 Dog er der ikke, fra projektgruppen,
Nr.
Bremselys,
plade
Højre
Pol 5
Baglygte
Nr. plade
fungerende med m˚alesystemet.
Pol 5
Positionslys
Baglygte
Blinklys
P˚a Figur 9.4 er ledningsnettet til en trailer illustreret. Pol 4 Ud fra diagrammet Positionslys er det muligt, at
Tågelys
Blinklys
analysere hvordan der kan m˚ales, om lysene Pol p˚a Pol
2
4traileren
er fungerende eller defekte.
Tågelys
Pol 2
2
2
3
4
1
1
7
7
3
Figur 9.3: Illustration af 13-polet stik og en forbindelsesoversigt
Som det fremg˚ar af figurerne er polerne fra 1-7 i stikkene forbundet til de samme funktioner.
Dette bevirker at m˚alesystemet vil kunne benyttes til b˚ade 13-polet og 7-polet stik, hvis der
monteres en adapter.
udgangspunkt i, er en trailer, der har et blinklys til hver side, et t˚agelys, to bremselys og
erfaret kendskab til eksisterende fritids-trailere, med 7-polet stik, som ikke tænkes være
6
6
5
43
7-Polet stik
1 7-Polet – Interval stiksignal
som aktiveres i perioder
2 – Signal aktiveret i perioder
3 1 – Stel Interval signal som aktiveres i perioder
4 2 – Interval Signal aktiveret signal som i perioder aktiveres i perioder
5 3 – Konstant Stel signal til parallelkoblede pærere
6 4 – Signal Interval aktiveret signal som aktiveres i perioder i perioder
Pol 3
Pol 3

1
7
4
6
5
Pol 1
Pol 7
Pol 6
Pol 5
Pol 4
Pol 2
7-Polet stik
Tågelys
Positionslys
Baglygte
Nr. plade
Bremselys, Venstre
Bremselys, Højre
Nr. plade
Baglygte
Positionslys
Blinklys
Blinklys
De 1 pære – Interval der benyttes signal som til aktiveres en fritids-trailer i perioder findes med 2 forskellige lysstyrker. De pære der
2 – Signal aktiveret i perioder
bruges 3 – Stel til baglys, nummerpladelys og positionslys har en effekt p˚a 5 W ved 12 V, og dem
der 4 benyttes – Interval til signal bremselys, som aktiveres blinklys i perioder og t˚agelys har en effekt p˚a 21 W ved 12 V.
5 – Konstant signal til parallelkoblede pærere
De fleste 6 – Signal glødepærer aktiveret som best˚ar aktiveres af en i spole perioder af wolfram-tr˚ad, der er placeret i en gasfyldt glasbe-
7 – Konstant signal til parallelkoblede pærere
holder. Denne opbygning gør at glødepæren fungerer som en lille spole. Spolen vil resultere
Pol 3
Figur 9.4: Illustration af el-nettet og dets forbindelser til lyset p˚a traileren
P˚a figuren sidder P ol1 og P ol4, som er blinklysene, i en seriekobling med P ol3 som er
stel. P ol2 er t˚agelyset og sidder ligeledes i seriekobling med stel. De resterende poler,
P ol5, P ol6 og P ol7, sidder i parallelkobling og fører alle til stel. Fra P ol5 og P ol7 trækkes
ledninger hen langs begge sider af traileren. Baglygte, nummerpladelygte og eventuelt posi-
tionslys forbindes i hver side af traileren. Ledningsnettet fra P ol5 og P ol7 er dermed sym-
metrisk opbygget. Fra P ol6 trækkes to ledninger til bremselysene, der er placeret sammen
med kørelyset i højre og venstre side af traileren.
9.1.1 Pærer
i induktans i kredsløbet, hvilket vil introducere en tidskonstant p˚a hvor hurtigt strømmen
gennem kredsløbet kan ændre sig, da en spole modarbejder ændring i strømmen. Dette be-
tyder, at spolen vil forsøge at trække en strøm ud af et eventuelt tilsluttet kredsløb, n˚ar
pæren afbrydes af bilen. Derfor er det nødvendigt at beskytte indgangen p˚a det tilsluttede
kredsløb, mod denne effekt fx, ved hjælp af en høj ingangsimpedans.
9.1.2 Impedanser
Det er nødvendigt at undersøge ingangsimpedansen p˚a traileren, for at m˚alesystemet kan de-
signes til at interface med traileren. Dette er nødvendigt for at kunne minimere p˚avirkningen
44

p˚a traileren, fra modulerne der skal interface med traileren. Informationen om impedansen,
for de forskellige koblinger af pærer p˚a traileren, skal sørge for at m˚alesystemet bliver de-
signet, s˚a det kan m˚ale signalet, der løber gennem traileren, uden at for meget af signalet g˚ar
tabt. For at minimere signaltabet skal spændingsdelingen der forekommer, n˚ar m˚alesystemet
bliver koblet til traileren, være designet s˚a kun en meget lille del af spændingsfaldet ligger
over m˚alesystemet. Spændingsdelingen vil desuden designes, s˚a langt den meste ligger over
pærerne p˚a traileren hvilket betyder, at der ikke sker noget betydeligt fald i lys-intensitet
fra trailerens lys.
Impedansen for de forskellige koblinger i traileren bliver beregnet i det følgende. Pærernes
effekt er bestemt udfra de defacto standarder ⋆ der benyttes for pærer til fritids-trailere. I det
følgende benyttes følgende indexer: Zin for ingangsimpedans, P for effekt, U for spændingen
og I for strømmen.
Impedanserne for blinklys og t˚agelys, P ol1, P ol4 og P ol2, best˚ar af kobling med kun én 21
Watt pære, se Figur 9.4
P = U · I ⇒ (9.1)
I = 21W
12V
⇒ I = 1, 75A (9.2)
Zin = U
I ⇒ Zin = 12V
= 6, 86Ω (9.3)
1.75
Med Formlen 9.10 er impedansen udregnet for baglys, numerpladelys og positionslys, P ol5 og P ol7,
denne kobling har tre 5 W pærer i parallel. Beregningen bliver lavet for én trailer med po-
sitionslys og for én trailer uden.
P = U · I ⇒ (9.4)
I = 15W
12V
⇒ I = 1, 25A (9.5)
Zin = 12V
1, 25 ⇒ Zin = 9.60Ω (9.6)
P = U · I ⇒ (9.7)
I = 10W
12V
⇒ I = 0, 83A (9.8)
Zin = 12V
1, 25 ⇒ Zin = 14, 45Ω (9.9)
(9.10)
Formlen 9.14 beregner impedansen for bremselyset, P ol6 denne kobling har to 21 W pærer
i parallel. P ol6
P = U · I → (9.11)
I = 42W
12V
→ I = 3, 50A (9.12)
Zin =
12V
3, 50A → Zin = 3, 43Ω (9.13)
45

Input/output Krav
Input spænding
Input Impedans:
12 V
P ol1, P ol2 og P ol4
6,86 Ω
P ol5 og P ol7 med 3 kørelys 9,60 Ω
P ol5 og P ol7 med 2 kørelys 14,45 Ω
P ol6
3,430Ω
Tabel 9.1: Input/output-relationer for trailer
(9.14)
Grænsefladen mellem m˚alesystemet og traileren er nu defineret. I Tabel 9.1 er de relevante
værdier for trailerens I/O beskrevet. Disse værdier er nødvendige, for at kunne designe et
m˚alesystemet, der har en minimal p˚avirkning p˚a trailerns lys-net.
9.2 Grænsefladen til bil
Bilens anhængerstik er tilkoblet bilens el-net, som ikke nødvendigvis er identisk fra bil til
bil, hvorfor dette betragtes som en “black-box”, der blot leverer de nødvendige signaler til
at drive en trailer. Det er derfor nødvendigt, at det tilkoblede m˚alesystem p˚avirker bilens
el-net mindst muligt, da det ikke er klart hvor forsvarligt det er at belaste bilens el-net.
Derudover kan det ikke forventes at bilen leverer nøjagtig 12 V forsyning til trailerstikket.
Normalt vil bilens el-net være forsynet med en generator og et bly-syre batteri. Spænding,
der bliver leveret fra bly-syre batteri, kan variere alt efter temperatur og hvor opladt det er.
Ifølge [Perez, 1993] kan spændingen variere fra under 10 V, ved næsten afladet, til omkring
16 V ved fuld opladet tilstand. Dette gør at det i praksis ikke er sikkert, at der bliver leveret
12 V i trailerstikket hvorfor det er nødvendigt at m˚alesystemet kan h˚andtere den usikkerhed.
Bilens anhængerstik, med de 7-poler, har seks forskellige outputs til de forskellige typer af
lys-signalering, som er illustreret p˚a Figur 9.2. N˚ar blinklysene aktiveres, giver P ol1 og P ol4
et pulsbredde-moduleret signal (PWM) p˚a cirka 12 V med en dutycycle p˚a cirka 50%. P ol2
aktiveres n˚ar t˚agelyset tændes og polen leverer cirka 12 V indtil t˚agelyset slukkes igen. P ol3
er stel. P ol5 og P ol7 leverer cirka 12 V, s˚a længe bilens kørelys er aktivt. P ol6 leverer cirka
12 V n˚ar bremsen p˚a bilen er aktiv. Dette medfører følgende I/O-relationer, se Tabel 11.1.
Input/output Krav
output P ol1 og P ol4 cirka 12 V PWM signal p˚a 50% dutycycle
output P ol2 cirka 12 V ved aktiv t˚agelys
output P ol3 stel
output P ol5 og P ol7 cirka 12 V
output P ol6 cirka 12 V ved aktiv bremse
Tabel 9.2: Input/Output-relationer for bilen
46

9.3 Grænsefladen til formidlingssystemet
Som tidligere beskrevet, i Del 1 Overførsel af signal 6, skal informationer mellem systemet
og mobiltelefon overføres via Bluetooth. Bluetooth er en digital overførsels-protokol, hvilket
bevirker at det kun er muligt at sende digitale signaler over protokollen. Derfor er det
nødvendigt, at digitalisere den information der skal sendes til formidlingssystemet. Ud over
at dataen skal digitaliseres, er det ogs˚a nødvendigt, at bestemme hvilken form dataen skal
være p˚a, n˚ar den skal sendes over Bluetooth-forbindelsen, og hvilken type af forbindelse der
skal operettes.
Hvordan forbindelsen mellem to enheder etableres, og data sendes, kan variere. Der er
specielt forskel p˚a de forskellige operativ-systemers m˚ader at h˚andtere Bluetooth p˚a, lige-
som der er forskel p˚a, hvordan forskellige programmer kan interagere med denne, afhængigt
af hvordan de er lavet og i hvilket programmeringssprog. Eksempelvis kan der etableres en
forbindelse, som systemet ser som en “gammeldags” serielkabel-forbindelse, og som er enkel
og nem at g˚a til. En s˚adan forbindelse har til gengæld sine begrænsninger ved søgning og au-
tomatisk etablering af forbindelse til vilk˚arlige enheder. En anden m˚ade at skabe forbindelse
p˚a, er som det kendes fra nyere Linux-distributioner, Mac OS og MS Windows, hvor der
kan etableres forbindelse til vilk˚arlige Bluetooth-enheder, og hvor der er mulighed for au-
tomatisk detektering af bestemte typer af enheder. Dette kendes fx fra Bluetooth-headset til
mobiltelefoner. Bluetooth-forbindelsen er derfor meget fleksibel og kan tilpasses til de fleste
behov i forhold til data, der skal transmitteres tr˚adløst.
Med baggrund i dette er det muligt, at opstille krav til grænsefladen til formidlingssystemet,
som kan ses i Tabel 9.3.
Input/output Krav
Input data digital datastrøm
Input protokol Bluetooth
Tabel 9.3: Input/output-relationer for grænsefladen til formidlingssystemet
9.4 M˚alesystemets indhold
N˚ar grænsefladerne udadtil er defineret, er det muligt at kigge indad, og se p˚a hvilke opgaver
m˚alesystemet skal løse, og hvordan dette skal ske. Indledningsvis vælges der at beslutte
hvilken platform funktionerne skal løses p˚a, da dette kan have indflydelse p˚a senere valg.
N˚ar platformen er bestemt, kan m˚alesystemets funktioner nærmere bestemmes. De bliver
her opdelt i fire funktioner:
1. Tjek forbindelse gennem trailer
2. Tjek signal fra bil
3. Vinkelm˚aler
4. Tr˚adløs kommunikation med formidlingssystemet.
47

De tre første punkter stammer fra use-casene og som konklusion af analysen af grænsefladen
til formidlingssystemet, er det sidste fremkommet, da det er bestemt, at der skal overføres
data via Bluetooth.
Som afslutning p˚a m˚alesystemets indhold vil det være naturligt at se nærmere p˚a de cases,
som m˚alesystemet skal sende til formidlingssystemet.
9.4.1 Platform
For at mindske kompleksiteten i forbindelse med at lave iterationer p˚a en prototype af
m˚alesystemet, er det at foretrække at basere systemet p˚a en platform med høj fleksibilitet.
N˚ar m˚alesystemet skal foretage m˚alinger p˚a traileren, skal systemet kunne h˚andtere analoge
signaler, eftersom anhængerstik og traileren er analoge systemer. N˚ar m˚alesystemet registr-
erer et korrekt signal, eller mangel derp˚a, er det nødvendigt at konvertere denne m˚aling til et
digitalt signal. Dette er nødvendigt, da grænsefladen til formidlingssystmet kun kan h˚andtere
digitale signaler. Derfor er det oplagt at benytte en microcomputer-platform, hvilket har
forest˚aende egenskaber. Platformen giver mulighed for at lave et sekventielt system, hvor
overføringsfunktionen kan ændres via software. Dermed muliggøres det, at lave ændringer
i systemets funktionalitet, uden at skulle ændre i hardwaren. Dette kan være en fordel da
eventuelle fejl i funktionaliteten kan ændres, uden at foretage en fysisk ændring p˚a enheden.
Til prototypen er der valgt at bruge en platform ved navn Gumstix. Denne platform er op-
bygget omkring en lille Linux computer, der kan udbygges med forskellige tilføjelsesmoduler,
alt efter hvilken funktionalitet systemet p˚akræver. Da Gumstixen i teorien er en fuld funk-
tions dygtig Linux computer, er der ingen begrænsninger i forhold til, hvilken software der
kan afvikles, s˚a længe at det fungerer under Linux og ikke kræver højere systemkrafter
end umstixen kan levere. Derfor er det muligt, at benytte et programmeringsprog med højt
abstraktionsniveau, s˚asom Java, C, C++ eller Python, til at udføre databehandling med.
Ud over diverse former for software, understøtter Gumstix-platformen ogs˚a næsten samtlige
former for I/O ⋆ -relationer via udvidelseskort. Der er derfor mulighed for analog til digital
konvertering, betegnet ADC ⋆ , digital I/O og overførsel af data via de mest gængse tr˚adløse
standarder. En anden fordel ved Gumstix-platformen er, at den er en kompakt løsning, der
omtrent er p˚a størrelse med en pakke tyggegummi, hvoraf navnet kommer. Disse funktion-
aliteter og specifikationer gør Gumstix-platformen til en fleksibel og modificerbar løsning til
udvikling af en prototype af m˚alesystemet.
Modellen, der er blevet gjort tilgængelig under dette projekt, er Verdex pro XM4-bt mother-
board, med Audiostix2 lydkort der skal fungere som I/O kort ⋆ . Motherboardet har indbygget
mulighed for Bluetooth-forbindelse og er udstyret med et Audiostix2 lydkort, som er baseret
p˚a UCB1400-kredsen fra Philips. UCB1400 har en 20 bit digital stereo lyd ind- og udgang,
4 x 10 bit ADC porte og 10 x digitale TTL ⋆ kompatible I/O forbindelser [Philips Semicon-
ductors, 2002].
Verdex pro XM4-bt motherboardet med Audiostix2 har alle de funktionaliteter, som micro-
computerplatformen til m˚alesystemet kræver, hvorfor der er besluttet at benytte Verdex
pro XM4-bt motherboard med Audiostix2, hvilket giver følgende I/O krav til grænsefladen
48

mellem Gumstix-platformen og de tilknyttede moduler. Se Tabel 9.4, hvor kravene til den
digitale og analoge I/O er hentet fra databladet til UCB1400 [Philips Semiconductors, 2002].
Input/output Krav
Tr˚adløs kommunikation Bluetooth
Analog input-spænding 7.5 V for Full scale
Analog input-impedans 77 kΩ
Digital input Høj 2 V - 5,5 V
Digital input Lav -0,5 V - 0,8 V
Digital Output Høj Min 0.85 DVDD
Digital Output Lav Max 0.4 V
Tabel 9.4: Input/output-relationer for Gumstix
M˚alesystemets funktioner skal derfor opbygges, s˚a de kan fungere i samspil med
Gumstix-platformen.
49

9.4.2 Tjek forbindelse gennem trailer
Funktionen tjekker, om trailerens lys er funktionelle, og overfører resultatet til mobiltelefo-
nen. Som diagrammet over el-nettet illustrerer i Figur 9.4 p˚a side 44, er der to forskellige
koblinger, som lysene er forbundet over. Kobling med en pære og koblinger med flere pærer
i parallelforbindelse. Brydes forbindelsen i koblinger med en pære, eventuelt ved at en pære
bliver defekt, kan dette m˚ales som manglende forbindelse, hvilket betyder at der ikke løber
nogen strøm igennem kredsløbet. I koblinger med pærer i parallel vil der stadig løbe en
strøm, s˚a længe at der er minimum én funktionsdygtig pære. Derfor er det ikke nok, at vide
om der løber en strøm, men det er ogs˚a nødvendigt at m˚ale, om koblingerne trækker den
rigtige effekt. Da højre- og venstre kørelys trækker den samme effekt, da de indeholder det
samme antal pærer, kan disse to effekter sammenlignes, med henblik p˚a at bestemme om der
er fejl i disse. Denne sammenligning kan foreg˚a ved at beregne differentialet af de to effekter.
Hvis det er nul, er der det samme antal pærer, der virker i begge kørelys. En negativ værdi
kan betyde at der er et problem i venstre side, og en positiv værdi kan betyde at der er et
problem i højre side.
Dette giver tre forskellige funktionskrav til lystjekket p˚a traileren, for at kunne bestemme
om lyset p˚a traileren virker. For at bestemme om koblingerne med en enkelt pære virker, er
det dermed nødvendigt at vide, om der løber en strøm. I koblinger, hvor pærerne sidder i
parrallel, er det nødvendigt at vide, hvor meget strøm der løber. Desuden er det nødvendigt,
at effekten der trækkes i de to kørelys, skal kunne trækkes fra hinanden.
Ved 12 V er de effekter, der bliver trukket i de forskellige koblinger:
Bremselys: 21 W · 2 = 42W
T˚agelys, højre blinklys, venstre blinklys: 21 W · 1 = 21W
Højre kørelys, venstre kørelys: 5 W · 3 = 15W eller 5 W · 2 = 10W
Som tidligere bestemt, i Del 1 Produkt-kravspecifikation Sektion 7.1 p˚a side 29, skal der ikke
laves indgreb i trailerens el-net for at m˚ale om lysene virker. M˚alingen skal derfor foreg˚a
mellem bilens- og trailerens stik, hvor signalerne skal omsættes til analoge spændinger, eller
et TTL signal, for at Gumstixen kan h˚andtere de m˚alte data.
Dette giver følgende krav til lystjek for trailer:
• Kunne registrere om trailerns lysforbindelser trækker den rigtige effekt
• Overføre resultatet til TTL- eller ADC-indgangen p˚a Gumstixen
9.4.3 Tjek signal fra bil
N˚ar I/O-relationerne er fastlagte, kan en analyse af, hvordan m˚alesystemet skal h˚andtere
disse inputs p˚abegyndes. Dette er blandt andet væsentligt i henhold til at komme frem til
nogle krav til tjek af bilens output-signaler, s˚aledes at det sikres at disse signaler er korrekte.
Herefter kan der undersøges, om disse stemmer overens med trailerens signaler.
50

M˚alesystemet skal kunne registrere, om signalerne i bilens anhængerstik er korrekte. Fire
ud af seks signaler kan aktiveres og deaktiveres af brugeren. Se Tabel 9.1 for nærmere
beskrivelse. Disse er t˚agelys, bremselys og blinklys til højre og venstre. Dette kræver, at
brugeren tager en aktiv del i, at verificere disse signaler, da det kun er muligt at m˚ale p˚a
signalet, n˚ar det er aktivt. Det vil sige, at for at m˚alesystemet kan udføre et lystjek, skal
brugeren aktivere bremselyset og begge blinklys. Under lystjekket udelades der, at tjekke
t˚agelyset da det aldrig er lovpligtigt, at dette er aktivt, hvorimod det er ulovligt at køre med
t˚age lys, n˚ar det ikke er d˚arlig sigtbarhed, ifølge færdselslovens § 33, stk. 5. Derfor er det
nødvendigt, at gøre brugeren opmærksom p˚a dette, hvis t˚agelyset skulle være aktivt under
lystjekket. De resterende signaler er højre- og venstre kørelys, som er aktivt s˚a snart der er
strøm p˚a systemet og kontrolleres uden involvering fra brugeren.
I grænsefladen til bilen beskrives der, at bilens signalspændinger kan svinge fra 10 V - 16
V, hvorfor der ikke forventes at m˚ale lyssignaler over 10 V. Dette vil sige, at grænsen for
hvorn˚ar der m˚ales et signal fra bilen, skal sættes til under 10 V. M˚alesystemet skal kunne
verificere, om signalerne i bilens anhængerstik er korrekte ved blot at m˚ale, om der bliver
p˚atrykt en stor nok spænding fra de seks forskellige lyssignaler til trailerstikkets stel. Da det
kun er vigtigt, om der er p˚atrykt en spænding eller ikke, kan der laves en binær m˚aling p˚a
signalerne i trailerstikket, hvorfor de digitale TTL indgange p˚a Gumstixen kan benyttes.
Udover problemstillingen om anhængerstikket leverer et signal, kan der forekomme proble-
mer med beskadiget feder eller not i stikket, som dermed kan vendes 180 ◦ . Dette betyder at
signalerne bytter plads. Denne problemstilling er illustreret i Tabel 9.5.
Venstre blinklys → Højre blinklys
T˚agebaglys → Højre kørelys
Stel → Bremselys
Højre blinklys → Venstre blinklys
Højre kørelys → T˚agebaglys
Bremselys → Stel
Venstre kørelys → Venstre kørelys
Tabel 9.5: Signalskift hvis trailerstikket bliver vendt 180 ◦ i bilens anhængerstik
Dette giver to problematikker i forhold til m˚alesystemet. Den første er, at hvis m˚alesystemet
skal bruge bilens anhængerstik som spændingsforsyning, til kredsløbet er det problematisk
at stel og bremselyset bytter plads. Den anden problemstilling er, hvordan m˚alesystemet kan
verificere at stikket ikke er vendt forkert. En metode der kan bruges, er at sørge for at m˚ale
om t˚agebaglyset er slukket, samtidig med at begge kørelys er tændt. Dette kan kun være
tilfældet, hvis trailerstikket vender rigtigt, hvorfor m˚alesystemet kan verificere at stikket er
vendt korrekt.
Dette giver følgende krav til tjek af bilens trailersignaler:
• Kunne registrere om bilens enkelte signaler til traileren, har spænding i nærheden af
10 V.
• Kunne registrere om t˚agelyset er slukket, samtidig med at begge kørelys er tændt.
• Overføre resulatet til m˚alesystemets TTL indgange.
51

9.4.4 Vinkelm˚aler
Denne funktion har til form˚al at gøre det muligt for Gumstixen, at m˚ale vinklen mellem
bil og trailer. Kredsløbet skal fungere ved, at den fysiske vinkel skal transducers til et elek-
trisk signal. Der er flere tilgange til denne problemstilling. To overordnede metoder til en
løsning kunne være en mekanisk løsning, eller en løsning der beregner vinklen ud fra afs-
tandsm˚alinger.
En mekanisk løsning kunne fx bygge p˚a strain-gauge eller et dreje-potmeter. Fælles for disse
løsninger er, at de vil være s˚arbare over for rystelser, snavs og slid. Grunden til dette er, at
vinklen mellem bilen og traileren har centrum omkring trækkuglen, og det er derfor forde-
lagtigt, at transduceren skal kobles fast, s˚a der kan m˚ales omkring dette sted. Dette betyder,
at transduceren kommer til at sidde tæt p˚a vejbanen, hvorfor den nemt kan blive udsat for
vand og snavs. En anden problematik er, at traileren kan bevæge sig i tre dimensioner i
forhold til bilen. Fra side til side, op og ned og traileren kan ændre den vandrette vinkel i
forhold til bilen. Dette giver nogle designmæssige udfordringer hvis vinklen skal kunne m˚ales
præcist.
En løsning, der bygger p˚a afstandsm˚aling kunne laves, med to afstansm˚alere der fx bruger
infrarød eller ultralyd til at bestemme afstanden til et objekt. Ved at tage forskellen p˚a to af-
stande, i hver sin side af traileren, er det muligt at beregne vinklen. En s˚adan løsning vil være
mindre s˚arbar overfor rystelser, end en mekanisk løsning, da den kan laves uden bevægelige
dele. Dog vil der stadig være problemer med vand og snavs. Dette kan dog løses, i en vis
grad, da det ikke er nødvendigt at m˚ale direkte p˚a trækkuglen, kan denne løsning placeres,
s˚a den er bedre beskyttet mod snavs end den mekaniske. Trailerens bevægelses-muligheder
har ikke længere s˚a stor betydning, s˚a længe der er en flade, som afstandsm˚alingen kan laves
p˚a. Selvom der kan være stor forskel p˚a, hvordan bilens bagende er udformet, fra model til
model, er der en god chance for at det er muligt, at lave en løsning der rammer en flade,
hvorp˚a det er muligt at lave en afstands-m˚aling.
M˚alet med dette delelement er, at transducere vinklen mellem trailer og bil, til et signal der
kan behandles af Gumstix-platformen. For at Gumstixen kan behandle signalet fra trans-
duseren, skal dette enten være et digitalt logisk TTL signal eller et analog indenfor ADC’ens
niveau.
Ud over at vinklen skal m˚ales ønskes det ogs˚a at det er muligt at bestemme vinkelhastigheden
og vinkelaccelerationen. Funktionen skal m˚ale hvor meget vinklen ændrer sig over tid. Denne
funktion kan afledes ved at m˚ale vinklens ændring over tid, hvilket vil sige ∆vinkel
∆tid , og
accelrationen kan afledes ved at m˚ale delta hastighed over delta tid. Da vinklen og tiden i
forvejen er kendte variable for Gumstixen, i henhold til at vinklen skal bruges i en anden
funktion, og at Gumstix-systemet, som andre computere, har funktioner for tid, vil det være
oplagt at lave m˚aling af vinkelhastighed som en software-funktion.
For at systemet kan n˚a at alarmere brugeren inden kollision er det nødvendigt, at foretage
disse m˚alinger med en frekvens, der sørger for at en fare for kollision bliver m˚alt, før en
kollision sker. N˚ar der forekommer en situation hvor der er fare for kollision, skal systemet
og brugeren kunne n˚a at reagere p˚a faren. Denne proces kan deles op i fire dele.
52

1. Systemet registrerer, at der er fare for kollision
2. Systemet formidler en alarm til brugeren
3. Brugeren perciperer alarmen
4. Brugeren reagerer p˚a alarmen
Overst˚aende scenarie giver to reaktionstider, der skal minimeres. Den første er systemets
reaktionstid, som kan minimeres ved at formindske tiden mellem hver m˚aling og minimere
tiden, der g˚ar fra en vinkel m˚ales til at en alarm kan udløses.
Den anden er brugerens reaktionstid, som systemet ikke har mulighed for at p˚avirke, p˚a andre
m˚ader end med alarmen. Reaktionstiden for et menneske, med en forventet stimulus ligger
mellem 140 ms - 160 ms [Kosinski, 2008]. For at minimere chancen for at der sker en kollision
mellem bil og trailer, skal den samlede reaktionstid være s˚a lav som muligt. Da brugerens
reaktionstid i bedste fald vil være 140 ms, vil det være en fordel hvis systemet ikke bidrager
til en væsentlig forøgelse af denne tid. Det bestemmes derfor at systemets reaktionstid skal
være minimum 20 gange mindre end brugerens reaktionstid, hvilket antages værende lavt
nok til at det ikke har nogen nævneværdig betydning.
Det vil sige, at der minimum skal foretages en valid m˚aling hver
140 ms
20
= 7 ms, hvilket
svarer til en frekvens p˚a 142 m˚alinger i sekundet. Udover frekvensen p˚a m˚alingen af vinklen,
er det ogs˚a nødvendigt, at de enkelte m˚alinger har en vis nøjagtighed, hvis systemet skal
kunne bestemme, hvorn˚ar der er fare for kollision. Det antages at en opløsning med trin a
2 ◦ og nøjagtighed p˚a ± 2 ◦ vil være et fornuftigt valg.
Disse overvejelser kan opsummeres i følgende krav til vinkelm˚aleren:
• Kunne transducere en afstandsm˚aling til et digitalt signal p˚a TTL-niveau eller et
analogt signal p˚a ADC niveau
• Vinkelm˚aleren skal kunne producere en valid vinkelm˚aling og vinkelhastighed 142
gange per sekund
• Vinkelm˚alern skal kunne m˚ale en vinkel med en opløsning p˚a trin a 2 ◦ og nøjagtighed
p˚a ± 2 ◦
9.4.5 Tr˚adløs kommunikation
Den tr˚adløse kommunikation fra m˚alesystemet skal foreg˚a over Bluetooth protokolen. Verdex
pro XM4-bt motherboardet er forsynet med en Bluetooth-sender, som kan tilg˚aes via Gum-
stixens operativsystem. Det er derved muligt, at oprette en dataforbindelse tr˚adløst mellem
m˚alesystemet og mobiltelefonen. Bluetooth-chippen, der bliver benyttet p˚a Verdex pro XM4-
bt, er PBA31308 fra Infineon Technologies [Infineon Technologies AG, 2007]. Det er muligt
at sende data over Bluetooth-forbindelsen serielt med hastigheder op til 921600 bps.
53

9.4.6 Cases til formidlingssystemet
Med det kendskab, der er opn˚aet omkring bilen, traileren og vinkelm˚alingen, samt brug af de
tidligere opstillede use cases, kan samtlige cases, som Gumstixen skal sende til mobiltelefonen
nu opstilles. Dette gøres i form af figurer, som ligner use case-figurerne. Se Tabel 9.6, 9.7 og
9.8. Cases til mobiltelefonen best˚ar af samtlige m˚alinger, som m˚alesystemet kan registrere for
de enkelte grænseflader. Nogle af disse har to niveauer: virker, virker ikke, imens kørelysene
kan have tre niveauer, nemlig en, to, eller tre defekte pærer. Disse informationer sendes
til mobiltelefonen, som efterfølgende skal formidle disse til brugeren. I undtagelsesscenariet
er der blevet tilføjet nogle underpunkter, som er den information brugeren f˚ar, hvis en
fejlmelding opst˚ar.
Tjek signal fra bil
Undtagelsesscenarie Cases til mobiltelefon
M˚alesystemet modtager intet signal til kørelysene
- Brugeren bliver bedt om at tjekke stikforbindelserne
mellem bil og trailer
M˚alesystemet modtager et forkert signal
- Brugeren bliver bedt om at tjekke stikforbindelserne
mellem bil og trailer
M˚alesystemet modtager ikke et givent signal, eksempelvis
for højre kørelys
- Brugeren bliver informeret om at et givent
signal ikke registreres og denne bedes tjekke
forbindelsene fra m˚alesystemet og gennem
bilen
Venstre blinklys
T˚agebaglys
Højre blinklys
Baglys, nummerpladeog
positionslys i højre side
Bremselys
Baglys,nummerpladeog
positionslys i venstre
side
Tabel 9.6: Cases som m˚alesystemet registrerer fra bilen og videresender til mobiltelefonen
I Tabel 9.6 er der illustreret hvordan m˚alesystemet afprøver signalerne fra bilen og sender
deres tilstand til mobiltelefonen. M˚alesystemet afprøver alts˚a her alle 7 forbindelser gennem
stiket.
N˚ar forbindelsen skal tjekkes gennem traileren, se Tabel 9.7, skal alle 7 forbindelser igen
afprøves p˚a trailer-siden af m˚aleenheden. Herudover har kørelysene, i højre og venstre side,
tre pærer tilkoblet, hvorfor der skal registreres hvor mange pærer der er defekte.
I Tabel 9.8 er der illustreret, at der skal kontinuerligt sendes data om strøm af vinkler,
vinkelhastigheder og vinkelaccelerationer til mobiltelefonen. Disse skal bearbejdes af mobil-
telefonen s˚aledes at brugeren f˚ar den nødvendige information.
54

Tjek forbindelse gennem trailer
Undtagelsesscenarie Cases til mobiltelefon
M˚alesystemet modtager intet signal til
kørelysene
- Brugeren bliver bedt om at tjekke stikforbindelserne
mellem bil og trailer
M˚alesystemet modtager et forkert signal
- Brugeren bliver bedt om at tjekke stikforbindelserne
mellem bil og trailer
M˚alesystemet modtager ikke et givent signal,
eksempelvis for højre kørelys
- Brugeren bliver informeret om at
et givent signal ikke registreres og
denne bedes tjekke forbindelsene fra
m˚alesystemet og gennem traileren
Venstre blinklys
T˚agebaglys
Højre blinklys
Baglys,nummerplade og positionslys,
højre side virker
- 1 pære virker ikke
- 2 pærer virker ikke
- 3 pærer virker ikke
Bremselys virker
- 1 pære virker ikke
- 2 pærer virker ikke
Baglys,nummerplade og positionslys,
venstre side virker
- 1 pære virker ikke
- 2 pære virker ikke
- 3 pærer virker ikke
Tabel 9.7: Cases som m˚alesystemet registrerer fra vinkelm˚alerenheden og videresender til mobiltelefonen
Vinkelm˚aler
Undtagelsesscenarie Cases til mobiltelefon
Intet signal om vinkelm˚aling
- Brugeren f˚ar en fejlmeddelelse om, at
der ikke modtages noget signal om vinklen
Forkert signal om vinkelm˚alingen
- Brugeren f˚ar en fejlmeddelelse om at apparaturet
muligvis ikke er placeret korrekt
Værdi for Vinkel mellem bil og
trailer
Værdi for Vinkelhastigheden
Værdi for Vinkelaccelerationen
Tabel 9.8: Cases som m˚alesystemet registrerer fra vinkelm˚alerenheden og videresender til mobiltelefonen
55

9.5 Kravspecifikation for m˚alesystemet
M˚alesystemets grænseflader er blevet defineret, og herudfra er indholdet af dette blevet
fastlagt. M˚alesystemet kan s˚aledes bygges p˚a en Gumstix, da denne lever op til den ønskede
form˚aen. Herp˚a skal der kunne trækkes p˚a forskellige funktioner, hvilke har til form˚al, at
h˚andtere de I/O-relationer m˚alesystemet registrerer. For at disse konklusioner skal kunne
virkeliggøres i et design, opstilles herunder krav som skal resultere i det ovenfor beskrevne
systems udvikling.
Krav til m˚alesystemt
Krav M1: M˚alesystemet skal kunne m˚ale om spændingen over pol 1,2,4,5,6,7
p˚a trailerens stikd˚ase overstiger 10 V i forhold til stel (ben 3)
Krav M2: M˚alesystemet skal kunne m˚ale hvor stor en effekt, der trækkes
fra pol 6 (bremselys) til stel (pol 3), s˚aledes at systemet kan
bestemme, om der trækkes 42 W, 21 W eller 0 W.
Krav M3: M˚alesystemet skal kunne m˚ale forskellen p˚a, hvor meget effekt der
trækkes fra henholdsvis ben 5 til stel (pol 3) og pol 7 til stel (pol 3)
med en nøjagtighed, s˚aledes at der kan skelnes mellem et forbrug
med forskel p˚a 0, 5 W, 10 W og 15 W p˚a et af kørelysene
Krav M4: M˚alesystemet skal kunne m˚ale vinklen mellem bil og trailer minimum
142 gange per sekund med en opløsning p˚a 2 ◦ og en
nøjagtighed p˚a ± 2 ◦
Krav M5: M˚alesystemet skal kunne beregne hvor meget vinklen ændrer sig
over tid minimum 142 gange per sekund
Krav M6: Formidlingssystemet skal kunne tilg˚a information om lystjek og
vinkel p˚a m˚alesystemet via Bluetooth
Krav M7: M˚alesystemet skal omsætte dataen fra lys-signalering til cases,
som videresendes til formidlingssystemet
Krav M8: Platformen skal være Gumstix: Verdex pro XM4-bt motherboard,
med Audiostix2 lydkort
Krav M9: Systemet skal fungere med 7-polet stik b˚ade fra bil og trailer
Tabel 9.9: Tabel med kravspecifikation for det samlede Trailerhjælper-system
For at teste om m˚alesystemet overholder de opstillede krav, er der lavet en accepttest, som
kan findes i Appendiks F. Ud fra den opstillede kravspecifikation, er produktet klar til at
design-fasen.
56

KAPITEL 10
Design af m˚alesystem
Efter m˚alesystemet er blevet analyseret og kravspecifikationen opstillet, er det muligt at
designe de enkelte moduler, teste dem og samle dem i et komplet m˚alesystem. De dele der
skal designes er:
• Vinkelm˚aler: Afstandsm˚aler til registrering af vinkel mellem bil og trailer
• Tjek signal fra bil: Gennem en spændingsniveau-m˚aler der kan registrere, om der er
modtaget signal fra alle polerne i bilens anhængerstik.
• Tjek forbindelse gennem trailer: Gennem en effektm˚aler der kan registrere, n˚ar der
er én eller flere af trailerens pærer i bremse-, blink og t˚agelyset, er defekte og gennem
en differens-effektm˚aler n˚ar højre og venstre køre-, nummerplade og positionslys skal
sammenlignes.
• Software til Gumstixen: Som kan h˚andtere input-relationerne fra bil og trailer, samt
for vinkelm˚aleren beregne vinkelhastigheden og vinkelaccelerationen og videresende
signalerne via Bluetooth.
De tre øverste moduler er der tidligere stiftet bekendskab til under use casene, se Use cases
8.1. Det nederste modul er fremkommet under forrige afsnit, og der er valgt at tage denne
med som et separat modul. Dette er placeret nederst, da det er nødvendigt at de ovenst˚aende
moduler designes først, s˚a modulernes output bliver kompatibelt, med softwaren der skal
designes. Herefter digitaliseres signalerne og sendes til mobiltelefonen.
I dette kapitel vælges der at dele modulerne op p˚a følgende m˚ade:
• Vinkelm˚aler modul
• Effektm˚aler modul
• Differensm˚aler modul
• Spændingsniveau-m˚aler modul
• Gumstix-software modul
Denne opdeling resulterer i følgende illustration af, hvordan m˚alesystemet kan opbygges, se
Figur 10.1.
57

Bil
Trailer
Vinkelmåler
Spændingsmåling
Gumstix
Differenseffektmåler
ADC/TTL
Effektmåling
Software Bluetooth
Formidlingssystem
Figur 10.1: Ilustration af hvilke moduler og forbindelser m˚alesystemet indeholder
10.1 Vinkelm˚aler modul
Som tidligere beskrevet i Kapitel 9 skal vinkelm˚aleren designes s˚a vinklen bestemmes ved
lave en afstandsm˚aling mellem bil og trailer for derefter omregne resultatet fra m˚alingen til
en vinkel.
En m˚ade hvorp˚a denne vinkel kan beregnes, er ved at holde to afstandsm˚alinger op imod
hinanden og beregne vinklen ud fra forskellenen i de to længder, grunden til det er en fordel
at bruge to m˚alinger frem for en, er at det ikke er nødvendigt at lave kalibrering af hvilken
vinkel, systemet har til at starte med. En anden fordel ved at bruge to afstandsm˚alinger,
er at hvis m˚alingerne bliver foretaget p˚a hver sin side af omdrejningspunktet for vinklen, i
dette tilfælde trækkrogen, vil afstandsændring der m˚ales fordobles, i forhold til en m˚aling
med kun en afstand, og der vil derfor være en øget præcision for m˚aling af vinklen. Det
vælges derfor at bruge en løsning med to afstandm˚aler.
For at kunne beregne denne vinkel er det nødvendigt at m˚ale afstanden fra to fikserede
punkter og ind p˚a en flade hvor afstanden, ændrer sig proportionalt med vinklen mellem
bil og trailer. S˚adanne to afstande er afbillede p˚a Figur 10.2 markeret som A og B. I dette
tilfælde er afstandssensorene fastgjort p˚a traileren og m˚aler afstanden ind til bilens bagende
afstanden mellem sensorne er markeret som afstanden C p˚a figuren.
Figur 10.2: Ilustration af hvilke afstands m˚aling der skal foretages for at beregne vinklen mellem
Bil og trailer
For at beregne vinklen er det nødvendigt at kende afstanden A, B og C. Ud fra trigonometrien
B
58
A
C

kan vinklen findes som:
V inkel = 90 − tan −1 (
A − B
) (10.1)
C
Til afstandssensor er det valgt at benytte GP2D12 fra Sharp, denne sensor benytter infrarød
lys til at bestemme afstanden, og leverer et analogt output proportionalt med afstanden.
Sensoren kan m˚ale afstande p˚a 10 cm - 80 cm, p˚a afstanden 10 cm er outputet p˚a cirka
2,5 V og ved en afstand p˚a 80 cm er outputtet cirka 0,4 V. Det analoge output i forhold
til afstanden kan ses p˚a Figur 10.4 p˚a den følgende side. Da spændings outputtet varierer
med over 2 V, er det ikke nødvendigt at forstærke udgangssignalet, da denne variation i
spænding giver over 270 forskellige ADC værdier med en 10 bit ADC´er der kører 7,5 V
fullscale, som antages at være rigeligt til at bestemme hvorn˚ar bil og trailer er lige ved
at kollidere. Sensoren skal derfor kun forsynes med en 5 V spændings-forsyning og kobles
direkte p˚a en af Gumstixens ADC indgange.
Figur 10.3: Et eksempel p˚a hvordan vinkelm˚aleren kan monteres
59

Figur 10.4: Sharp GP2D12 graf over spændings output i forhold til afstanden
Databladet for Sharp GP2D12 kan findes i Bilag I p˚a den vedlagte CD
Omregningen af de analoge outputværdier fra afstandsm˚alerne sker p˚a Gumstixen. Det
vil sige at p˚a Gumstixen omregnes signalet til afstande. Herefter til vinkler og til vinkel-
hastighed og til sidst til vinkelacceleration som alle sendes til formidlingssystemet. Mere
herom i Gumstix-software modulet.
10.2 Effektm˚aler modul
Som tidligere beskrevet har dette modul til form˚al, at kunne afgøre om der afsættes effekt i
trailerens lys eller ej, i og med at der afsættes henholdsvis 21 W og 5 W ved 12 V i pærerne.
Hvis diagrammet for trailerens el-net tages i betragtning se Figur 9.4 p˚a side 44, er der som
tidligere nævnt forskel p˚a hvordan pærerne er forbundet. I de tilfælde hvor der kun sidder
en pære i en kobling, vil effekten kun ændre sig én gang n˚ar pæreren sprænger, alts˚a g˚a fra
et effektforbrug p˚a eksempelvis 21 W til intet effektforbrug. Derfor vil det være oplagt at
benytte en TTL indgang p˚a Gumstixen, hvor nul betyder intet effektforbrug og fem V er
n˚ar pæren lyser.
Eftersom der stadig vil afsættes en effekt i de resterende pærer. N˚ar en pære sprænger, skal
60

effektm˚aleren, der m˚aler p˚a en kobling hvor pærerne sidder i parallel, designes anderledes
end den førnævnte. Derudover er det et krav at formidlingssystemet skal kunne illustrere
hvor p˚a traileren fejlen er opst˚aet og yderligere hvor mange pærer der er defekte. Eftersom
dette vil kræve én TTL indgang per pære, vil en bedre løsning være til denne type m˚alinger
at designe kredsløbet til Gumstixens ADC-indgange i stedet, se Afsnit 9.4.1 for information
om TTL og ADC.
Der tages først udgangspunkt i at designe et m˚alekredsløb til at m˚ale hvor meget effekt der
afsættes over trailerens bremselys, hvilket best˚ar af to parallelforbundne 21 W glødepære.
For at kunne bestemme om pæren er funktionsdygtig er det nødvendigt at kende strømmen
der løber gennem kredsen. En m˚ade at m˚ale dette p˚a er at sætte en kendt modstand i serie
med glødepærerne, og derved lave en spændingsdeling mellem modstanden og glødepærerne.
Kredsløbet kan ses i Figur 10.5. Herefter er det muligt at bestemme strømmen gennem
kredsen, ved at m˚ale spændingsfaldet over den kendte modstand og via ohm’s lov udregne
strømmen.
BIL_BATT
- +
12V
R_EM
Figur 10.5: Viser et simplicificeret udsnit af bilen og trailerens kredsløb, med en m˚alemodstand sat
imellem bilens positive spændingsforsyning og to af trailerens glødepærer
Som det fremg˚ar af 10.5 er m˚alemodstanden indsat p˚a den positive spændingsforsyning.
Dette er grundet i, at alle pærer p˚a traileren har fælles stel se Figur 9.4 p˚a side 44, og det vil
derfor ikke være muligt, at definere hvilken pære er defekt og i hvilken side. Fordelen ved at
indsætte modstanden efter pæren, alts˚a imellem stel forbindelsen mellem bil og trailer, vil
være at der ikke løber en strøm gennem modstanden, n˚ar pæren er defekt. Dette er dog kun
tilfældet hvis det er én pære der sidder i forbindelsen, eller hvis alle pærer i en parallelkobling
er defekte, ellers virker kredsen som beskrevet ved den forrige kreds. Det er p˚a baggrund
at denne viden, besluttet at designe m˚alekredsløbet s˚a det tager udgangspunkt i koblingen
illustreret i figur 10.5.
Ved 12 V har bremselysene en indgangsimpedans som udregnet i Tabel 9.1 p˚a side 46 p˚a
3,43 Ω. Det ønskes at m˚alingen af strømmen skal have en minimal p˚avirkning af kredsen.
M˚alemodstanden skal derfor være meget mindre end glødepærernes indgangsimpedansen for
at mindske effekttab deri. Det bestemmes at bruge en effektmodstand p˚a 0,05 Ω. Ved at
benytte spændingsdelings-formlen kan spændingsfaldet over den valgte effektm˚alemodstand
beregnes, se Formel 10.2. Hvor Vk er spændingsfaldet, V er forsyningsspændingen, Rk er
m˚alemodstanden og summen af Rn er summen af modstandene. I Formel 10.5 er beteg-
nelserne til at Vmaalemodstand er spændingsfaldet over effektmodstande, Vbil er forysningsspændin-
P1
1
2
1
2
P2
gen fra bilen, Rmaalemodstand og Rbremselys modstandene i kre dsløbet.
61

Vk = V · Rk
Rn
Rmaalemodstand
Vmaalemodstand = Vbil ·
Rmaalemodstand + Rbremselys
Vmaalemodstand = 12 V ·
Ibremselys =
Ibremselys =
⇒
(10.2)
0, 05 Ω
= 0, 172 V (10.3)
0, 05 Ω + 3, 429 Ω
Vbil
Rmaalemodstand + Rbremselys
12 V
= 3, 449 A (10.4)
0, 05 Ω + 3, 429 Ω
Pmaalemodstand = Vmaalemodstand · Ibremselys ⇒
Pmaalemodstand = 0, 172 V · 3, 449 A = 0, 593 W (10.5)
Spændingsfaldet p˚a 0,172V vil give et signaltab p˚a 0,172V
12V
⇒
· 100 = 1.433% hvilket anses for
at være ganske acceptabelt. Effekten der bliver afsat i m˚alemodstanden bliver 0,593W den
valgte effektmodstand er godkendt op til 3W og kan derfor andvendes til kredsløbet.
Spændingsfaldet over m˚alemodstanden skal herefter behandles s˚a antallet af pærer der er
funktionsdygtige bliver formidlet til Gumstixen. Til registrering af antallet af funktions-
dygtige bremselys, om nogen, er det valgt at benytte analog m˚aling via Gumstixen ADC
indgange. Dette begrundes ved, at n˚ar pærerne sprænger en efter en, ændrer spændingsfaldet
over effektmodstanden sig gradvist eftersom strømmen der løber igennem den bliver mindre.
For at finde spændingsfaldet hen over effektmodstanden, er det nødvendigt at lave en kreds
der tager de to spændingspotentialer, før og efter modstanden, for efterfølgende at sammen-
ligne de spændinger. Til dette er det valgt at benytte en operationsforstærker (OPAMP),
hvis egenskab blandt andet er at tage to indgangssignaler, sammenligne dem og forstærke
signalforskellen. For at give indblik i hvad en OPAMP er, vil der kort blive beskrevet hvordan
OPAMP
en ideelle OPAMP fungerer. N˚ar der interfaces med en OPAMP skal følgende tages i betragt-
ning. OPAMP’en kan betragtes som en spændingsstyret spændingskilde, hvor OPAMP’ens
• I praksis bruger vi dog en model der er lidt mere
detaljeret.
udgangsspændingen afhænger af VIN .
Figur 10.6: Illustrerer funktionsprincippet i en operationsforstærker
MM 3: OPAMPS 10
62

Forstærkningen kan styres ved at vælge modstande og lave tilbagekobling p˚a henholdsvis
ind- og udgang af OPAMP’en. Ønskes der fx en -20 gange forstærkning monteres R1 og R2
som p˚a Figur 10.7 i en inverterende kobling. Eftersom forstærkningen afhænger af forholdet
mellem de to modstande er − R1
R2 = forstærkningen gældende.
V_IN+
V_IN-
R2
3
2
4
11
VDD
R1
ICA
1
TLC274P
GND
Figur 10.7: Viser en TLC274P operationsforstærker med en inverterende tilbagekobling
Operationsforstærkeren der er valgt, er en TLC274P databladet findes i Bilag I p˚a den ved-
lagte CDog er valgt udfra at den kan g˚a rail-to-rail hvilket betyder at indgangsspændingen
kan g˚a helt ud til forsyningsspændingen. Fordelen ved rail-to-rail er, at operationsforstærk-
eren ikke opfører sig uhensigtsmæssigt, hvis den f˚ar 0 V p˚a indgangen, eksempelvis n˚ar brem-
selyset ikke er aktivt. Eftersom det kan give problemer n˚ar spændingen p˚a ingangssignalet
nærmer sig eller g˚ar over spændingen for spændingsforsygningen til operationsforstærkeren,
er det valgt at lave en spændingsdeling af spændingsfaldet over effektmodstanden for at
sænke indgangssignalet, se Figur 10.8. Som det fremg˚ar af figuren er det valgt at halvere
den oprindelige spænding m˚alt over effektmodstanden. Det er valgt at bruge 10 kΩs mod-
stande for at de ikke leder for meget strøm væk fra den oprindelige kreds, figur 10.5, og
dermed skabe et for stort signal tab ud til pæren.
STEL
10k
10k
BIL_POL6
R_EM1
0.05
0.05
TLC274P
Figur 10.8: Viser bremselysets operationsforstærkerkobling 9k
med spændingsdeling 3 IC5Aaf
indgangssignalet
R38
1
2
STEL
TL084P
Spændingsdelingen resulterer i en halvering af det m˚alte signal ind i operationsforstærkeren,
BIL_POL1
R4
R1
1k
R42
STEL
R_EM4
STEL
10k 10k
1k
R2 R3
R43
R39
3
2
R5
TRAILER_POL6
STEL_POL3
PHS
221k
1
2
IC2A
1
PVS
1
2
R40
63
STEL R41
9k 221k
TRAILER_POL1
PVBLINK
1
2
N$29
STEL
R44 R48
9k 1k
R_
0.0

hvilket betyder at hvor der før var en spændingsforskel p˚a 172 mV er den halveret til 86
mV og da der er to pærer giver det et spændingsfald p˚a 43 mV pr pære. Det ønskes at
flytte ADC niveauet p˚a Gumstixen minimum 10 trin pr tilstand og eftersom de 7,5 V er
7,5 V
fordelt over 10bit svarer ét ADC trin til 210 = 7, 324 mV . S˚a for at f˚a Gumstixen til
at ændre sig de 10 trin pr tilstand, skal spændingen p˚a udgangen af operationsforstærkeren
ændre sig med 73,24 mV for hver pære der sprænger. Dette betyder kredsløbet skal have
en forstærkning p˚a
være to gange.
73,24 mV
43 mV
= 1, 7. Det vælges derfor at forstærkningen af ingangssignalet
For at kunne dimensionere kredsløbet det nødvendigt udlede en formel for forstærkning
i dette kredsløb. kredsløbet best˚ar af to spændingsdelinger der halverer signalet. Spænd-
ingsdelingen mellem R1 og R4 halverer spændingen før m˚alemodstanden og bruges som
reference punkt for forstærninigen. Dette vil foresage at outputtet vil have et DC-offset p˚a
Bil P ol6
2 .Spændingsdelingen mellem R2 og R3 halverer spændingen efter m˚alemodstanden.
Denne spænding bliver brugt som indgangssignal p˚a den inverterende indgang af Op-ampen.
Forstærkningen gennem en inverterende kobling er givet ved forholdet mellem den mod-
stand indgangen ser ud i, i forhold til indgangssignalet, og modstanden i tilbagekoblingen.
Da koblingen derudover vil invertere signalet vil outputte have modsat fortegn af inputtet.
I dette tilfælde er tilbagekoblingsmodstanden R5, og indgangsmodstanden kan ses som R2
og R3 i parralell. Med disse betraktninger kan en formel for kredsløbet opstilles:
Vout = − R5
·
R2||R3
T railer P ol6 Bil P ol6
−
2
2
(10.6)
R1, R2, R3 og R4 sættes til 10 kΩ hvorefter modstandsværdien for R5 kan findes via (10.7).
Da der ikke ønskes en negativ spænding p˚a udgangen skal forstærkningen være -2:
A = − R5
⇒ −2 =
R2||R3
R5
10 kΩ·10 kΩ
10 kΩ+10 kΩ
⇒ R5 = 10 kΩ (10.7)
M˚alekredsløbet for bremselyset er nu designet til at levere det rette input til Gumstixens
ADC-niveau. Ved TTL er det ikke muligt at lave helt samme kredsløb eftersom input til
Gumstixens TTL-indgange i følge Tabel 9.4 p˚a side 49 skal være mellem -0,3 V og 0,8 V for
at være lav og mellem 2 V og 5,5 V for at være høj. Rummet derimellem, alts˚a fra 0,8 V -
2 V, er et bufferrum for at undg˚a m˚alefejl p˚a TTL indgangene ved fx støj p˚a signalet.
M˚alekredsen til TTL vil ogs˚a være baseret p˚a en kendt m˚alemodstand, der sidder i serie
med glødepæren.
For at kunne designe et kredsløb der kan opfylde TTL indgangens krav, vil det være smart
at konstruere en kreds der fungerer som en kontakt. Kredsen skal alts˚a være bistabil ved
to spændinger, som i dette tilfælde kunne være ved 0 V og 3 V. Denne bistabile kreds vil
ændre tilstand p˚a udgangen n˚ar den bliver aktiveret [Sedra and Smith, 2004]. Bistabilitet
kan opn˚aes ved at lave en ikke inverterende kobling med hysterese se Figur 10.10. Der er
64

dog kredse der er konstrueret til netop dette, s˚akaldte komparator-kredse. Disse komparator-
kredse er designet til s˚adan et system og vil derfor blive anvendt.
Eftersom koblingen har en tilbagekobling til komparatorens positive input, vil referencepunk-
tet V+ ændres β gange afhængigt at spændingsdelingen mellem R1 og R2 dette betyder at
β =
R1
R1+R1 . For at kunne beregne spændingspotentialet for V+ benyttes superpositionsprincippet
til at udregne de forskellige spændingstilskud til V+. Dette resultere i Formelen
10.8:
V+ = Vin ·
For den ideelle komparator er det gældende at:
V+ > V− → Vo = VoMAX
V+ < V− → Vo = −VoMAX
R2
R1 + R2 + Vout
R1
·
R1 + R2
(10.8)
For at kunne overføre princippet fra Figur 10.10 p˚a næste side til at m˚ale over effektmod-
standen, skal stel, der er koblet foran modstand R1, erstattes med en referencespænding og
derefter hæve det inverterende referencepunkt s˚a det i stedet for stel bliver spændingen efter
effektmodstand, se Figur 10.11. Ydermere er det nødvendigt at have en spændingsdeling
mellem R1 og R3 der trækker referencespændingen lidt ned, for at det er muligt for det
inverterende spændingsniveau at blive højere end referencespændingen n˚ar pæren sprænger.
Eftersom spændingsfaldet over effektmodstanden kun er 90 mV, er det ikke meget refer-
encespændingen m˚a sænkes, hvilket betyder at R3 skal være meget større end R1. R3 kan
eventuelt sættes til 1 MΩ hvorefter R1 kan beregnes ud fra dette. Foruden at sænke refer-
encespændingen skal niveauet for hvorn˚ar komperatoren g˚ar høj, ogs˚a sænkes. Dette gøres
for at sikre at den g˚ar høj. M˚aden hvorp˚a dette gøres er ved at bestemme hysteresen som er
illustret p˚a Figur 10.9
Vo
∆Vhys
Figur 10.9: Illustartion af hysterese
Der sættes to spændingsdelinger ind for at undg˚a fejludslag p˚a udgangen af komperatoren,
opst˚aet ved at indgangssignalerne inteferere med komperatorens forsygningsspænding. ∆Vin
65
∆Vo
Vi

R1 R2
V+
Figur 10.10: Viser en tilbagekoblet operationsforstærker, der i kobling opn˚ar bistalilitet.
+
-
R_EM
Vin
1
2
d Settings\Martin Rask Larsen\Skrivebord\SVN-05\Personal\Rask\bistabil.sch (Sheet: 1/1)
R3
R1
Rask Larsen\Dokumenter\eagle\New_Project\untitled.sch
V+
5
4
R2
2
Vo
Figur 10.11: Viser en bistabil operationsforstærker kobling
ændres proportionalt med referensespændingerne fra effektmodstanden, hvilket har indfly-
delse p˚a hvilken hysterese der skal være. 4% tolerance ved worstcase hvilket er en spænd-
ingsforskel p˚a
6 V ·4
100
= 240 mV , det betyder at vi f˚ar problemer med at vide om det er pæren
der reelt er sprunget eller om det er tolerancen i modstandende der spiller ind
Efter forgæves forsøg med at f˚a en komperatoren med diskrete komponenter at blive stabil
nok vælges det at benytte en IC-kreds der er designet til form˚alet. Valget af IC kreds falder
p˚a INA139 Current Shunt Monitor fra Texas Instruments som kan konvertere et differentiale
input af to spændinger til en strøm p˚a udgangen. Strømmen gennem udgangen kan s˚a via en
modstand konveteres til spænding som kan bruges til at f˚a TTL indgangen til at g˚a lav eller
høj alt efter om der løber en strøm. Hvordan Koblingen skal laves kan ses p˚a Figur 10.12 p˚a
næste side for denne kobling kan outputtet givet ved:
IR EM5 · R EM5 · RT 1
Vout = ⇒
1 kΩ
(10.9)
Vout · 1 kΩ
RT 1 =
IR EM5 · R EM5
(10.10)
66
Vo

BIL_POL6
10k
0.05
R2
0.05
R_EM3
10k
R37
VCC_POL6
VCC_5v
IC9
5
2
TRAILER_POL6
INA139
10-12-2008 17:15:58 f=0.70 C:\Documents and Settings\Martin Rask Larsen\Skrivebord\SVN-05\P
STEL
30k1
RT1
100k
TL084P
0.05
VCC_5v
BIL_POL1 R_EM5 TRAILER_POL1
BIL_POL2 R_EM4 TRAILER_POL2
Figur 10.12: Kobling med INA139 til TTL
For at f˚a TTL indgangen til at g˚a høj skal spændingen p˚a indgangen være mellem 2 V og
5,5 V skal de 1,8 A der løber gennem den 0.05 Ω m˚alestand omdandes til en mellem 2 V
og 5,5 V for at være sikkre p˚a at TTLbenet g˚ar højt sættes Vout til 4 V. RT1 kan derved
udregnes med Formel 10.11.
RT 1 =
10.3 Differens-effektm˚aler modul
IN+
IN-
4
V+
OUT
1
GND
3
13
R5
ADC4
4 V · 1 kΩ
⇒ RT 1 = 44, 4 kΩ (10.11)
1, 8 A · 0, 05 Ω
For at kunne sammenligne to effektm˚alinger, og derved gøre det muligt kun at bruge én
ADC til at m˚ale om der er en defekt i kørelyset, er det nødvendigt at designe et kredsløb
der har denne funktion.
Denne funkunalitet kan leveres fra en differensforstærker som forstærker forskellen mellem
to spændinger op. En differensforstærker er bygget op omkring OPAMP, og er koblet med
en inveterende og en ikke inveterende forstærkningskobling se Figur 10.13.
Figur 10.13: Diferensforstærker kobling
Hvis R18 = R16 og R17 = R15 kan forstærkningen som differensforstærkeren leverer skrives
som:
Kilde: [Irawin and Nelms, 2008]
Vout = R16
· (V2 − V1) + VGND
R15
15/12/08 20.45 f=1.50 /Users/Michael/Desktop/AAU/PDP5/smartsvn/Personal/Rask/Eagle/deff.sch (Sheet: 1/1)
IC6
(10.12)
Hvor VGND er et virtuelt stel der bruges til DC at offsette udgangssignalet til at svinge
omkring det virtuelle stel i stededet for omkring 0 V. Dette gøres da ADC indgangen kun
67
5
2
IN+
IN-
4
V+
OUT
1
GND
3
INA139
STEL
RT2

kan m˚ale fra 0 V -7,5 V og det derfor er nødvendigt at hæve udgangen op at svinge om et
punkt inden for ADC omr˚adet. Det vælges at VGND skal sættes til 2,5 V da det kan gøres
med en spændingsdeling af den 5 V forsynings spænding.
De to effekter der skal sammenlignes, er de to siders kørelys, som hver trækker enten 10 eller
15 Watt, alt efter om der er positionslys monteret p˚a traileren. Disse to effekter skal m˚ales
efter samme princip som der er brugt til at m˚ale effekten bremmselyset trækker.
Rmaalemodstand
Vmaalemodstand = Vbil ·
Rmaalemodstand + Rkorelys
Vmaalemodstand 15 W = 12 V ·
Vmaalemodstand 10 W = 12 V ·
⇒
0, 05 Ω
= 0, 062 V
0, 05 Ω + 9, 60 Ω
(10.13)
0, 05 Ω
= 0, 034 V
0, 05 Ω + 14, 45 Ω
(10.14)
(10.15)
For at bestemme hvilken forstærkning kredsløbet skal have udføres samme beregning som
ved bremselyset dog med en 5 W pære. Da signalet bliver halveret kommer spændings faldet
for en pære til at være 34 mV/4 = 8, 5 mV . S˚a for at f˚a Gumstixen til at ændre sig de 10
trin pr tilstand, skal spændingen p˚a udgangen af differensforstærker ændre sig med 73,24
mV for hver pære der bliver defekt. Dette betyder kredsløbet skal have en forstærkning p˚a
73,24 mV
8,5 mV
= 8, 6. Det vælges derfor at forstærkningen af indgangs signalet være ni gange.
Det samlet kredsløb kommer til at best˚a af to effektm˚aler efter samme design som den til
bremselyset der forstærker signalet to gang og en differensforstærker der forstærker kred-
sløbet med 4,5 gange. For at en den forstærkningen vælges det at R17 og R15 skal være 10
kΩ. Dette gør at R18 og R16 skal være 45 kΩ for at f˚a en 4,5 gangs forstærkning. Kredsløbs
diagramet kan ses p˚a Figur 10.14.
Figur 10.14: Kredsløbs diagram af differens-effektm˚aler
15/12/08 20.53 f=1.50 /Users/Michael/Desktop/AAU/PDP5/smartsvn/Personal/Rask/Eagle/korelys.sch (Sheet: 1/1)
68

10.4 Spændingsniveau-m˚aler modul
Dette modul har til form˚al at bestemme at om der kan m˚ales en spænding i bilens trailerstik.
Ideelt set skal bilen forsyne trailerns pære med en 12 V forsyningsspænding men spænding
kan variere en del i praksis da denne afhænger af bilens batteri. Det kan der for ikke forventes
at der er præsis 12 v tilstæde i stikket men det skulle gerne ligge deromkring. Niveau
m˚alingen skal foretages p˚a pol: 1,2,4,5,6 p˚a trailerstikket og i forhold til pol 3 som er stel
i trailerstikket. Det er ikke nødvendigt at lave en m˚aling p˚a pol 7 da denne fungere som
forsyning til m˚alesystemet og det derfor ikke vil være muligt at starte systemet hvis der ikke
tilstrækkelig spænding p˚a denne.
Til at m˚ale om der er en spænding har gumsixen to muligheder: ADC eller TTL. Da der kun
er 4 ADC’er tilgængelig og det kun er nødvendigt med information om der er nok spænding
eller ej, er det nærliggende at vælge TTL ingangen. Det vil sige at kredsløbet skal fungere
p˚a den m˚ade at et signal p˚a 10 V - 16 V i anhængerstikket p˚a en p˚agælende pol skal f˚a en
TTL indgang til at g˚a høj.
For at TTL indgangen opfatter en spænding som høj skal den ligge mellem 2 V - 5,5 V. For
at sikre at en spænding p˚a 10 V bliver angivet som høj sættes grænsen for skiftet ved 9,5 V.
Kredsløbet skal sørge for at alle spændinger p˚a under 9,5 V bliver opfattet som lav hvilket
at signalet skal være under 2 V. Den simpleste m˚ade et s˚adan kredsløb kan laves p˚a er ved
at lave en spændings deling mellem to modstande. For at beskytte Gumstixens indgange
vælges der at p˚amontere en TTL buffer og en 1 KΩ efter spændingsdelingen.
Via spændingsdelingformlen kan modstands værdierne udregnes ud fra forholdet mellem
dem. Der vælges at R1 skal være p˚a 8,27 kΩ R2
R1
Vout = Vin
R1 + R2
8, 27 kΩ
⇒ 2 V = 9, 5 V
⇒ R2 = 31kΩ (10.16)
8, 27 kΩ + R2
Dette kredsløb er illusteret p˚a Figur 10.15 p˚a den følgende side. TTL bufferens eneste funk-
tion er at virke som et sikring mellem trailerstikket og Gumstixen indgang, som buffer er
IC-kredsen 74LS241N som har 8 TTL buffer indbygget som er delt op 4 og 4 der hver for sig
kan enables. Denne funktionalitet benyttes ikke og enable-benene sættes til stel s˚a kredsen
altid er aktiv. Den 1 KΩ’s modstand der sider lige før TTL indgangen sørger for at der ikke
kan løbe en stor strøm ind i Gumstixen hvis TTL indgangen bliver sat til at fungere som en
udgang.
69

Figur 10.15: Krædsløb til m˚aling af spændings niveauver i bilens trailerstik
10.5 Gumstix-software modul
Dette afsnit vil indeholde en analyse af hvordan Gumstixsoftwaren skal designes. Selve
udførslen af designet vil blive udeladt da dette ved dette projekts afslutning ikke er blevet
udført.
10.5.1 Input til program
Der er inputs fra to forskellige moduler. Dette er fra lystjekket og fra vinkelm˚aleren. Et
diagram over softwaren kan ses p˚a Figur 10.16
Software
Vinkel
Vinkel
data
Håndter
data
ADC/TTL Input data og
Output
Bluetooth
definer
Lystjeck
data
hvad skal
formidles
Lystjeck
data
smartsvn/Personal/Michael/eagle/Trailerhjæper/maalesystemmed_klip_til_raport.sch (Sheet: 1/1)
Input fra lystjek
Figur 10.16: Diagram over moduler i softwaren til Gumstix
Tidligere, i Sektion 9.4.6 p˚a side 54, blev der analyseret frem til at der er en række cases
som bliver sendt fra Gumstixen til mobiltelefonen. Disse cases skal, nu hvor designet af
m˚alesystemet er p˚a plads, revideres. Lystjek har ti forskellige inputs:
• Fem binære værdier der bestemmer om anhængerstikket virker
70

• Tre binære værdier der bestemmer om t˚agelys og blinklys virker
• To ADC værdier der bestemer om bremselys og kørelys virker
Da ADC-værdierne indeholder en 10 bit værdi er det nødvendigt at bestemme ved hvilke
værdier skellet ligger for de forskellige defekter. ADC-værdien for bremselyset har tre udfald:
to pærer-, en pære- , nul pærer der virker. Kørelyset har 7 udfald enten virker alle 6 pærer
eller der kan være 1, 2 eller 3 pære der ikke virker i en af siderne. Disse 10 udfald er listet i
Tabel 10.1 med tilhørende ADC-værdier sammen med værdien for tilstandsskift, de brugte
m˚alinger er taget fra M˚alejournal for effektm˚aling som kan findes i Appendiks E p˚a side 119
og kan regnes til ADC-værdi ved MaalingiV
7,5 V/1024
= ADC vaerdi i decimaltal. Værdien for skiftet
sættes midt mellem de to tilstande, da dette vil give mest mulig plads til m˚alefejl. Det vil
sige at hvis der er 20 værdier imellem to tilstande sættes skellet mellem de to tilstande til
en værdien til halvdelen (10).
Tilstand M˚aling V ADC-værdi i Værdi for skift
decimaltal af tilstand
Bremselys 2 pærer 6,11 V 834 844
Bremselys 1 pære 5,95 812 823
Bremselys 0 pærer 5,79 790 801
værdi ugyldig 791
3 pære venstre, 0 pærer højre 2,935 V 400 410
3 pære venstre, 1 pære højre 2,802 V 382 391
3 pære venstre, 2 pærer højre 2,649 V 361 371
3 pære venstre, 3 pærer højre 2,519 V 343 352
2 pære venstre, 3 pærer højre 2,395 V 326 334
1 pære venstre, 3 pærer højre 2,244 V 306 316
0 pære venstre, 3 pærer højre 2,107 V 287 296
værdi ugyldig 286
Input fra vinkelm˚aler
Vinkelm˚aleren har to inputs:
Tabel 10.1: Tabel over tilstands skift for kørelys og bremselys
• ADC-værdien som er proportional med afstanden til fra trailer til bilen p˚a højre side
• ADC-værdien som er proportional med afstanden til fra trailer til bilen p˚a venstre side
Disse værdier er ikke kendte, da vinkelm˚aleren er ikke er blevet testet indenfor den afsatte
tid.
10.5.2 Program proces
For at programmet kan fungere, bliver data inputtet til programmet, programmet laver en
databehandling og outputter data. Dette kan opdeles i fem overordnet processer:
1. En proces inputter data
71

2. En proces outputter data
3. En proces der danner cases ud fra m˚alingerne p˚a trailer og bilens el-net.
4. En proces beregner vinklen, vinkelhastigheden og vinkelaccelerationen.
5. En proces det samler informationen fra de to ovenst˚aende, formatérer informationen
og transmitterer denne over Bluetooth.
Behandling af input fra lystjek
Inputtet fra lystjek skal konverteres til en case som skal være en del af informationen i den
streng der skal sendes over Bluetooth. Det vælges at casen skal indeholde binære værdier
for hver defekt der er mulig i systemet, hvor 1 repræsenterer statuskode ikke opfyldt og et
0 repræsenterer sand statuskode. Det vil sige, at hvis venstre blinklys er defekt vil værdien
svarende til venstre blinklys i casen sættes til 0. De mulige defekter er listet i Tabel 10.2.
Nr i case Input signal statuskode
1 TTL0 0 Anhængerstik. ingen Spænding i højre blink
2 TTL1 0 Anhængerstik. ingen Spænding i t˚agebaglys
3 TTL2 0 Anhængerstik. ingen Spænding i venstre vlinklys
4 TTL3 0 Anhængerstik. ingen Spænding i højre kørelys
5 TTL4 0 Anhængerstik. ingen Spænding i bremselys
6 TTL5 0 Pære højre blinklys defekt
7 TTL6 0 Pære venstre blinklys defekt
8 TTL7 0 Pære T˚agebaglys defekt
9 ADC3 844-823 ingen defekt i Kørelys
10 ADC3 822-801 Bremselys 1 pære defekt
11 ADC3 800-791 Bremselys 2 pærer defekte
12 ADC2 410-391 3 pærer defekte højre
13 ADC2 390-371 2 pærer defekte højre
14 ADC2 370-352 1 pære defekt højre
15 ADC2 352-334 ingen defekt i Kørelys
16 ADC2 333-316 1 pære defekt venstre
17 ADC2 315-296 2 pærer defekte venstre
18 ADC2 295-286 3 pærer defekte venstre
Tabel 10.2: Input til lystjek-cases
Med baggrund i Tabel 10.2, er det nu muligt at opstille en case for et fungerende el-net eller
en case for en hver defekt, der kan m˚ales p˚a el-nettet. Det vi sige, at hvis en pære i højre
side sprænger bliver strengen der skal sendes til formidlingssystemet: 11111111011110111.
Derfor bliver nummer 9 og nummer 14 sat til nul.
Behandling af input fra vinkelm˚aleren
De to ADC-værdier fra afstandsm˚alerne skal regnes over i en vinkel hvorefter vinkelhastighed
og vinkelacceleration skal beregnes. Det er nødvendigt at sende disse tre m˚alinger med en
frekvens med 142 m˚alinger pr sek. for at kunne beregne vinkelhastigheden og vinkelaccel-
rationen, er mere end en m˚aling nødvendigt. Vinkel, vinkelhastighed og vinkelacceleration
kan beregnes ud fra følgende formler:
72

Vinklen kan regnes som: V inkel = 90 − tan−1 ( A−B
C ) Hvor A = afstand højre, B = afstand
venstre og C = afstand mellem de to sensorer.
Vinkelhastigheden kan findes som: V inklenhastigheden = ∆vinkel
∆tid
Vinkelaccelerationen kan findes som: V inkelaccelration =
∆V inklenhastigheden
∆tid
Det kan kræve tre ADC-m˚alinger før disse tre værdier kan beregnes, da der skal m˚ales to
hastigheder før en accelerations-m˚aling udføres. Dette bevirker at sample ADC-m˚alingerne
med tre gange den hastighed som data skal sendes med hvilket vil sige at samplings-
frekvensen skal være 142 · 3 = 426 sampels/sek. For at regne samples over i afstand, s˚a
nøjagtigt som muligt, er det nødvendigt at foretage kalibrerings-m˚alinger, da de to Sharp af-
standsm˚alere ikke er helt lineærer. Dette kan ses p˚a Figur 10.4 p˚a side 60. Da disse m˚alinger
af tidsnød ikke er blevet foretager, vil de aktuelle værdier ikke blive gennemg˚aet.
Formatér information til en streng
Strengen der skal sendes videre til formidlingssystemet skal indeholde date fra lystjek og data
fra vinkelm˚alingen. Derudover ønskes det ogs˚a at strengen bliver forsynet med tidskode, som
er klokken med ms, som kan bruges til at korrigere for eventuelle pakketab.
Det vælges at information i strengen skal være kommasepareret og rækkefælgen skal være
tid,lyscase,vinkel,hastighed,acceleration et eksempel p˚a s˚adan en streng kunne være:
”122343512,11111111011110111,15,2,3”.
En illustration af hvordan disse tre processer kan inkorporeres i et program. Flowet kan ses
p˚a Figur 10.17 p˚a den følgende side
Med denne analyse er det nu muligt at konstruere en program kode til Gumstixsoftwaren.
Denne programkode er ikke konstrueret ved projektets afslutning og vil derfor ikke blive
behandlet yderligere.
73

[system aktiveres]
Lys case dannes ud fra aktuelle
ADC og TTL værdier
Lys case skrives til databuffer
ADC værdier fra begge
afstandsmåler læses
Vinkel beregnes og
skrives til databuffer
Vinkelhastighed beregnes
og skrives til databuffer
Vinkelacceleration beregnes
og skrives til databuffer
Databuffer formateres til en kommaseparet streng
og sendes ud til bluetooth modulet
Indhold i databuffer slettes
Figur 10.17: Sekvensdiagram for Gumstix-software
74

KAPITEL 11
Konstruktion af m˚alesystem
Som udgangspunkt er de forskellige delelementer til opbygning af m˚alesystemet blevet beskrevet.
Det vil her blive sammensat i ét kredsløbsdiagram, for at skabe et samlet overblik. Yder-
mere vil der blive udarbejdet et diagram der viser hvordan kredsløbet vil blive placeres rent
konstruktionsmæssigt.
11.1 Praktiske funktioner
For at levere spænding til m˚alesystemet og sørge for, at det er funktionsdygtigt fra n˚ar det
kobles til bilen, er P ol7 valgt som primær spændings- og strømkilde. P ol7 er uafhængig
af, hvordan anhængerstikket vendes i stikd˚asen, og kredsen vil derfor være funktionsdygtig
n˚ar der sættes tænding p˚a bilen. Der kan dog opst˚a et problem ved at systemet, ideelt
set, ikke altid kan være sikret stel, eftersom P ol6 og P ol3 skifter plads hvis stikket vendes
180 o i stikd˚asen. Dette kan løses ved, at sætte en brokoblet ensretter ind i kredsen se Figur
11.1. Ensretteren har til form˚al at levere VCC p˚a den ene udgang og stel p˚a den anden,
uafhængigt af om polerne skifter plads. Dette nye stel benyttes for hele kredsløbet. Ulempen
ved at benytte en s˚adan ensretter, er at spændingsfaldet over dioderne vil hæve stel med
omkring 0,7 V over det oprindelige stel. Datablad for ensretteren, RB154, kan findes i Bilag I
p˚a den vedlagte CD. Dette har dog ingen betydning for kredsløbet, eftersom der ikke er nogle
komponenter i kredsløbet der kræver spændingsforsyning over 8 V.
Pol_6
Pol_3
VCC
Stel
Figur 11.1: Viser en brokoblet ensretter, opbygget af fire dioder
Derforuden skal Gumstixen have forsyningsspænding, hvilket er valgt til at være 5 V forsyn-
ing. Til at generere en konstant 5 V forsyningsspænding benyttes en spændingsregulator,
mere specifikt en L7805CT. Datablad kan findes i Bilag I p˚a den vedlagte CD. Disse 5 V vil
ogs˚a benyttes til at generere de 2,5 V, som ifølge Sektion ?? p˚a side ?? skal benyttes til at
hæve spændingsniveauet i diferensforstærkeren. Dette gøres ved at lave en spændingsdeling
af de 5 V med to 10kΩ modstande, se Figur 11.2. For at gøre spændingsdelingen mere stabil,
75

4P
EL
5v
IN+
IN-
4
V+
POL2
OUT
1
ADC3
GND
3
INA139
og undg˚a at trække for meget strøm gennem den, benyttes en bufferkreds. Bufferkredsen
er en TLC271P. Datablad findes i Bilag I p˚a den vedlagte CDog har direkte tilbagekobling
hvilket giver 1 gangs forstækning. VGND bliver derfor et 2,5 V spændingsniveau.
V_GND
STEL
20
GND
TLC271P 2
6
CX2 IC3P IC8P CX1
CX3
5 3
C1
IC1 10
10uF
10K
10k
STEL
IC4
7805T
VI
1
Figur 11.2: Viser m˚alekredsløbets spændingsforsyning, IC7A hvor stel til hele kredsløbet 1.0k udvindes, samt
en 5 30k9 8k27
TTL2
BIL_POL1 V forsyningsspænding
2
A1 Y1
18 R25 1.0k
R1 R40
4
A2 Y2
16
6
TTL1
A3 Y3
14
1.0k R26
8
30k9 8k27
A4 Y4
12
TTL0
BIL_POL2
R27 1.0k
Det er af konstruktionsmæssige R10 R39 ˚arsager, valgt at 1sætte
G en LED (L52SRC) til P ol7 indgange TTL3
R28
for at give en visuel30k9 indikation 8k27af,
at der er spænding74LS244N til systemet. Modstanden R31 er regnet
BIL_POL4
STEL
ud fra de typisk værdier R20 fraR38 datablad. Se Bilag I p˚a den vedlagte CD. Dioden benytter 20
mA ved 1,85 V. Det 30k9 resultere 8k27 i at det skal ligge 5V − 1, 85V = 3, 15V over modstanden, det
BIL_POL5
IC7B
vil ifølge Ohms lov 1.0k
R21 betyde at R36 R31 = 11
A1 Y1
9
13
TTL4
A2 Y2
7 R29
15
30k9 8k27
A3 Y3
5
BIL_POL6
17
A4 Y4
3
R22 R14
19
G
74LS244N
ADC1 DIST_1
1
3,15V
20mA → R31 = 157, 5Ω.
Af sikkerhedsmæssige ˚arsager, i forhold til Gumstixen, er der sat bufferkredse ind før den
oprindelige TTL-indgang p˚a Gumstixen. Den sikres imod at brænde TTL-indgangene af
p˚a Gumstixen hvis noget skulle g˚a galt. Dermed er det blot bufferkredsen der skal skiftes.
STEL
STEL
STEL
STEL
STEL
Bufferkredsen der er valgt, er en 74HCT244N hvilket STEL g˚ar høj p˚a udgangen n˚ar der p˚atrykkes 2
for p˚a udgangen. For at begrænse den strøm der kan trækkes ud af kredsen er der sat GP2D12 en 1
kΩ modstand før TTL-indgangen, denne modstand sikrer derudover at Gumstixen ikke kan
VCC_5v
ADC2 DIST_2
tage skade hvis dens TTL-inputs bliver konfigureret til et output ved en fejl. 1
STEL
STEL
2
5
Ydermere er der monteret en elektrolyt kondensator IN+ C1,
3
3 Figur 11.2 for at minimere risikoen
2
for, at Gumstixen mister spænding f˚a ustabil IN- spændingsforsyning. Derudover vil den GP2D12 ogs˚a
RT2
100k
1 8
7 4
VCC_5v
R19
R24
VCC_5v
GND VCC
10 20
GND VCC
konstant. Kondensatoren vil efter opladning holde spændingen konstant og virke som et
BIL_POL4 R_EM6 TRAILER_POL4
batteri, der aflader hvis spændingen fra spændingsregulatoren ikke kan levere nok strøm
0.05
et kort øjeblik. Derudover er der sat afkoblingskondensatorer CX1, CX2 og CX3 p˚a hver
INA139
BIL_STEL
RT3
100k
0.157k
VCC_POL6
TRAILER_STEL
en spænding over 2 V p˚a indgangen. Den f˚ar 5 V spændingsforsyning, hvilket den ˚abner 3
IC2
4
V+
stabilisere kredsløbet, ved at bidrage til at spændingen og strømmen til kredsløbet holdes
spændingsforsyning ved 74HCT244N og TLC274P for at sortere støj fra samt stabilisere
spændingsniveauet. Kredsløbets delelementer er nu klar til at blive sammensat i et samlet
kredsløbsdiagram
76
OUT
1
GND
R31
LED1
3
B1
VO
2
4
11
DIST_IN
STEL
VCC_5v
DIST_IN
STEL
VCC_5v

11.2 Det samlede kredsløbsdiagram
Det samlede kredsløbsdiagram kan findes i Appendiks K p˚a side 141.
11.3 Placeringsdiagram
For at give et overblik over hvordan kredsløbet komponentmæssigt er opbygget, er der
blevet udarbejdet et diagram med placeringen af de væsenligste komponenter. Alle diskrete
komponenter i form af modstande og kondensatorer er udeladt fra diagrammet. Placeringerne
kan se p˚a følgende Figur 11.3.
ADC
Output_Trailer
74HCT274N
8 6 4 2 0
9 7 5 3 1
3 6 5 7 4 2 1
TLC274P
RB1
54
L780
5CT
TLC274P
1 2 4 7 5 6 3
74HCT274N
Input_Bil
TLC2
71P
1 3 5 7 9
0 3 4 6 8
TrimPot
Figur 11.3: Placeringsdiagram for kredsløbet til m˚alesystemet
TTL
INA139
Effektmodstand
De to ADC og TTL sokler er fladkabel-connectorpins, er placeret i udkandten af boardet, for
at gøre tilgangen med fladkabel og m˚aleinstrumenter nemmere. I Tabel 11.1 kan ses hvordan
de forskellige pins er forbundet. Der er p˚amonteret skruesokler til henholdsvis Input Trailer
og Output Bil hvilke er placeret s˚a der er nem tilgang for udefrakommende ledninger, samt
at ledningerne ikke overlapper de forskellige IC-kredse der skal monteres p˚a printet
TTL Funktion ADC Funktion
Pin 0 Bil input - Højre blink Pin 0 Afstandsm˚aler 1
Pin 1 Bil input - T˚agelys Pin 1 Afstandsm˚aler 1
Pin 2 Bil input - Venstre Blink Pin 2 Bremselys
Pin 3 Bil input - Højre kørelys Pin 3 Kørelys
Pin 4 Bil input - Bremselys Pin 4 N/C
Pin 5 Effekt m˚aling - Højre blink Pin 5 N/C
Pin 6 Effekt m˚aling - Venstre blink Pin 6 N/C
Pin 7 Effekt m˚aling - T˚agelys Pin 7 N/C
Pin 8 N/C ⋆ Pin 8 N/C
Pin 9 N/C Pin 9 N/C
Tabel 11.1: Input/Output relationer for bilen
77

11.4 modulverificering
Der er foretaget m˚alinger p˚a det færdige kredsløb for tre af de gennemg˚aede moduler.
Dette er effektm˚aler-, differens-effektm˚aler- og spændignsniveau-m˚aler modulet. M˚alingerne
er foretaget for at verificere hvert moduls funktionsdygtighed.
M˚alejournalen for effektm˚alingen og differens-effektm˚aleren kan findes i Appendiks E p˚a
side 119. Denne beskriver hvordan effektm˚aleren og differens-effektm˚aleren er blevet testet.
Resultaterne tyder p˚a at forstærkningen p˚a de konstruerede kredsløb generelt er lidt højere
end de forventede udregnede værdier. Dette kan skyldes at de ideelle forstærkningsbereg-
ninger ikke stemmer helt overnes med virkeligheden. Forskellen mellem beregning og m˚alingen
giver ikke umiddelbart problemer da denne er i en størrelsesorden der er h˚andterbar. Gumstix-
softwaren skal blot justeres ind efter disse tal, da ADC-værdierne svarende til de forskellige
tilstande bliver rykket lidt.
M˚alejournalen for spændingsniveau-m˚aler modulet kan findes i Appendiks D p˚a side 117.
Denne beskriver hvordan spændignsniveau-m˚aleren er blevet testet. Resultaterene af m˚alingerne
viser det konstruerede kredsløb ikke overholder der opstillede krav, da kun TTL 3 skifter til
høj ved en signalspænding p˚a 10 V i anhængerstikket. Alle TTL-m˚alinger er dog høje ved
12 V, hvilket vil sige at skiftet fra lav til høj ikke forekommer ved den ønskede spænding
i forhold til kravet. Det vil sige at spændingen over bilens batteri ikke m˚a falde ret meget
under 12 V for at m˚alesystemet vil melde til formidlingssystemet at der er en mulig fejl i
anhængerstikket.
78

KAPITEL 12
Verificering af m˚alesystem
For at verificere hvorvidt m˚alesystemet overholder de opstillede krav, er en accepttest blevet
udført, som kan findes i Appendiks F p˚a side 122. Resultatet fra denne test konkluderer
at kravene for at vinkelm˚aler modulet og Gumstixen virker, ikke kan testes, da disse ikke
er funktionsdygtige ved projektets afslutning. Dette bevirker at m˚alesystemet derved ikke
opfylder disse krav. I Tabel 12.1 er de krav kan eftervises opstillet.
Krav til m˚alesystemt
Krav Beskrivelse Opfyldt?
Krav M1: M˚alesystemet skal kunne m˚ale om spændingen over pol 1,2,4,5,6,7
p˚a bilens anhængerstik overstiger 10 V i forhold til stel (ben 3)
Krav M2: M˚alesystemet skal kunne m˚ale hvor stor en effekt, der trækkes fra
pol 6 (bremselys) til stel (pol 3), s˚aledes at systemet kan deter-
minere, om der trækkes 42 W, 21 W eller 0 W.
Krav M3: M˚alesystemet skal kunne m˚ale forskellen p˚a, hvor stor en effekt
der trækkes fra henholdsvis pol 5 til stel (pol 3) og pol 7 til stel
(pol 3) med en nøjagtighed, s˚aledes at der kan skelnes mellem en
effekt forskel p˚a 0, 5 W, 10 W og 15 W p˚a et af kørelysene
Krav M8: Platformen skal være Gumstix: Verdex pro XM4-bt motherboard,
med Audiostix2 lydkort
Krav M9: Systemet skal fungere med 7-polet stik b˚ade fra bil og trailer
Tabel 12.1: Tabel med kravspecifikation for det samlede Trailerhjælper-system
Det kan derved verificeres at kraven M2, M3, M8 og M9 er opfyldt og at krav M1 ikke er
op fyld, da skiftet først sker ved 12 V ifølge m˚alingen, foretaget i Appendiks D p˚a side 117.
Dette bevirker at spændingsniveau-m˚aler modulet skal redesignes for at modulet kan m˚ale
en spænding p˚a 10 V for kunne overholde kravene.
Alt i alt fungerer lystjekket i m˚alesystemet som det skal, hvis et par sm˚a-ændringer foretages.
Denne del været prioriteret højt i forhold til eksempelvis vinkelm˚alermodulet, som er en del
af kollisionsalarmen. Vinkelm˚aler modulet er designet og implementeret i kredsløbet, men
er endnu ikke blevet testet. Grunden til at vinkelm˚aler modulet ikke er blevet færdigt, er
primært p˚a grund af problemer med Gumstixen.
79

KAPITEL 13
Analyse af formidlingssystem
For at kunne designe fomidlingssystmet er det nødvendigt at f˚a fastlagt hvilke grænseflader
der støder op mod dette. Informationerne der skal formidles, er som tidligere nævnt lystjekket
og vinklen mellem bil og trailer. Disse er valgt formidlet visuelt og auditivt. Formidlingssys-
temet er i sin helhed en mobiltelefon og informationerne bliver overført via Bluetooth. For
at dette kan lade sig gøre, skal der programmeres et stykke software, som kan h˚andtere data
fra m˚alingssystemet og formidle dataen gennem brugerfladen. Først vil grænsefladerne blive
analyseret og derefter vil softwaren til formidlingssystemet blive gennemg˚aet. Et blokdia-
gram af systemet er illustreret p˚a Figur 13.1.
Software
Højtaler
Målesystem Bluetooth
Input
Bruger
Skærm
Figur 13.1: Brugerfladens grænseflader
13.1 Grænsefladen til m˚alesystemet
Grænsefladen til m˚alesystemet er som tidligernævnt i Sektion 9.3 p˚a side 47 dataforbindelse
over en Bluetooth protokolen. M˚alesystemet sender over Bluetooth-forbindelsen en streng
med en frekvens p˚a 142 pr sek. P˚a bagrund af dette kan input/output krav til grænsefladen
til m˚alesystemet opstilles se Tabel 13.1.
Input/output Krav
Input data data streng
Input frekvens 142 pr sek.
Input protokol Bluetooth
Tabel 13.1: Input/output Grænsefladen til m˚alesystemet
80

13.2 Brugergrænsefladen
Det vides fra produktkravspecifikationen, at der skal formidles information til brugeren
om lysenes tilstand, og hvis der er en defekt skal dennes placering indikeres visuelt og et
eventuelt løsningforslag skal gives ved hjælp af tekst. Efter analysen af traileren vides der
hvordan trailerens lys er placeret, og dermed hvor fejlene kan opst˚a.
Der er valgt, at informationerne skal videregives auditivt og visuelt til brugeren via mo-
biltelefon, hvorfor det ville være hensigtsmæssigt at overveje brugerens egenskaber til at
høre, se og fortolke inden grænsefladen designes. Dermed bør lyden designes s˚a den ligger
indenfor det hørbare omr˚ade. Den visuelle information bør designes, s˚a denne m˚ade kan ses
af brugeren, men ogs˚a s˚a den kan fortolkes. Her menes der udfra psykologiske teorier om
hvordan billeder kan formidles. I de følgende afsnit vil disse emner analyseres nærmere for
at danne grundlag for hvordan designet af brugerfladen skal fremkomme.
13.2.1 Perception af lyd
Mange faktorer spiller ind, n˚ar der er tale om perception af lyd. Udover det hørbare omr˚ade,
skal der ogs˚a overvejes hvor højt lyden skal afspilles samt om denne skal være en kontinuerlig
lyd i samme frekvens, om frekvensen skal være faldende, stigende eller blot varierende samt
om lyden skal præsenteres i impulser. Lydens form˚al m˚a holdes in mente, hvilket er at
alarmere brugeren om potentiel kollision mellem brugeres bil og trailer, hvorfor vigtigheden
i en hurtig forst˚aelse og respons af lyden er essentiel. Derfor m˚a det anses som en mulig
forsinkende faktor, hvis lyden til brugeren vælges som en verbal information. Da lyden skal
repræsentere en kollisionsalarm, er denne valgt værende nonverbal.
Det hørbare omr˚ade ligger mellem cirka 20 Hz og 20 kHz, dog høres der bedst i omr˚adet
mellem 1 kHz til cirka 4 kHz [Department of Elecronic Systems, 2008], hvorfor dette m˚a
overvejende være de bedste frekvenser at designe lyden efter. N˚ar der her skal designes
en alarmtone, m˚a intensiteten af denne ogs˚a overvejes. Intensiteten af normal tale mellem
personer ligger p˚a cirka 60 dB, hvor lyden af en kørende bil ligger p˚a 70 dB, udenfor bilen.
Tærsklen for hvorn˚ar intensiteten af lyde bliver s˚a høj, at de er smertefulde for lytteren at
høre p˚a, ligger p˚a omkring 130 dB, hvorfor intensiteten af kollisions alarmen ikke m˚a være s˚a
høj. Der findes retningslinjer for hvilke kriterier en alarm bør overholde. Disse vil, i forkortet
udgave, blive præsenteret.
1. Alarmen bør kunne høres over anden baggrundsstøj, hvorfor alarmen burde blive de-
signet med en intensitet der ligger 15 dB over baggrundsstøjen, hvilket for at sikre
detektering typisk kræver en differens p˚a omkring 30 dB mellem baggrundsstøj og
alarm.
2. Intensiteten af alarmen bør ikke ligge over tærsklen for mulig høreskade, som ligger p˚a
85-90 dB ved vedvarende hørelse, hvis dette kan undg˚aes.
3. Idealistisk bør alarmen ikke have en forskrækkende effekt.
4. Alarmen bør ikke medføre reduceret perceptuel forst˚aelse af andre signaler.
81

5. Alarmen bør være informativ
[Wickens, Lee, Liu and Becker, 2004, side 98-99]
N˚ar lyden designes, vil der forsøges at overholde disse punkter, s˚a kollisionsalarmen bliver
s˚a optimal som muligt. Dog er der flere problematikker vedrørende maskering, som der bør
tages under overvejelse.
Maskering
Der findes flere former for maskering. Nogle af disse er
• Komplet maskering
• Delvis maskering
• Bagud- og fremadrettet maskering
• Interaural maskering
Ikke alle former for maskering, som fx interaural maskering, er nødvendigvis relevante
i forhold til kollisionsalarmen. Der vil kun blive afspillet én alarmtone, men denne kan
maskeres af lyde udenfor bilen samt lyde inde i førerkabinen. Et eksempel p˚a maskering kan
være:
• Lyden af et tikkende ur i en bil maskeres af
• En ambulance sirene p˚a lang afstand som maskeres af
• Motor, vindstøj m.v. som maskeres af
• Lyden fra et volumiøst HiFi anlæg
Komplet maskering forekommer n˚ar tilstedeværelsen af en lyd (A) gør en anden lyd (B)
ikke hørbar [Poulsen, 2005]. N˚ar kollisionsalarmen lyder kan denne maskering eksempelvis
forekomme, hvis en ambulance kører forbi, og lyden dermed ikke bliver perciperet at brugeren.
De udenst˚aende faktorer er usikre og mange, og afhænger delvist af hvilke scenarier bilisten
kører med traileren i. Disse udenst˚aende faktorer bør holdes in mente, n˚ar lyden designes,
men kan umiddelbart ikke tages komplet højde for, under designet.
Delvis maskering refererer til en situation, hvor lyd A influerer p˚a perceptionen af lyd B,
men hvor lyd B stadig er hørbar. Denne form for maskering kan afhænge af hvor stor
intensitet lyd B har [Poulsen, 2005]. Eksempelvis kan en bilradio, indstillet til en bestemt
volumen, høres bedre under stop ved lyskryds end under motorvejskørsel. Under designet
af kollisionsalarmen m˚a der sikres, at de umiddelbare tilgængelige lyde i førerkabinen ikke
overstiger intensiteten af alarmen, for at sikre at denne kan høres.
N˚ar en lyd A bliver præsenteret umiddelbart inden en lyd B, uden at overlappe, har lyd
A en inflydelse p˚a hørbarheden af lyd B. Denne form for maskering kaldes fremmedrettet
maskering. Den omvendte situation, hvor lyd A præsenteres umiddelbart efter lyd B, og lyd
B maskeres kaldes bagudrettet maskering [Poulsen, 2005]. Det er ikke muligt, at designe
82

udfra disse former for maskering, da stimulussen bliver præsenteret via en mobiltelefon. Der
er ingen sikkerhed for, at brugeren eller en passager ikke tænder for bilradioen umiddelbart
inden kollisionsalarmen lyder.
Der er ingen tvivl om, at de maskerende effekter, i form af stimuli p˚a multiple modaliteter,
kan være mange i bilscenariet. Dog skal der holdes in mente, at det primært er de lyde inde
i førerkabinen som fx snak fra bagsædet eller bilradioen, der skal overdøves. men der er ogs˚a
andre faktorer der har en indflydelse p˚a, om brugeren kan kan holde opmærksomhed p˚a
lyden. Dette afhænger blandt andet af hvordan lyden designes.
13.2.2 Perception af visuelle indtryk
Ligesom ved audioperception er der mange faktorer der skal overvejes, n˚ar der brugeren skal
stimuleres visuelt. Her er der tale om et display p˚a en mobiltelefon, der skal indikere fejl
p˚a trailerens lys. N˚ar denne formidling skal præsenteres, skal der overvejes at designe efter
Gestalt-principperne, hvis der skal anvendes figurer, samt semiotiske teorier, hvis der skal
anvendes ikoner.
Gestalt-principperne beskriver hvordan figurer kan perciperes forskelligt. N˚ar information-
erne, om fejl p˚a traileren, skal videregives bliver dette gjort med et billede af en trailer, hvor
de steder hvor lysene ikke virker er markeret. N˚ar billedet af traileren skal designes, bør
følgende aspekter af Gestalt holdes in mente:
• Lukkethed
• Figur og grund
• Nærhed
Lukkethed referer til, at figuren skal være lukket, fx en fuldendt cirkel og ikke en halv, for at
billedet perciperes som en helhed. Billedet af traileren bør derfor være komplet, s˚a der ikke
kan opst˚a tvivl om hvad billedet skal forestille. Desuden skal figur-grund relationen være
tydelig. Dermed menes der, at der skal være stor kontrast mellem billedet og baggrunden,
eventuelt med forskel i farve, s˚a billedet bliver tydeliggjort. Nærhed refererer m˚aske mere
til placeringen af symbolerne der har til form˚al, at indikere hvilke lys p˚a traileren der er
defekte eller fungerende, eller andre knapper hvis disse vælges at implementere. Et billede
med 10 firkanter, der er spredt tilfældigt, har ingen nærhed. Nærhed er tilstede hvis disse 10
firkanter samles fx i en større firkant. Selvom disse ikke er i direkte berøring med hinanden
vil disse perciperes som en helhed. Dermed bør der overvejes, n˚ar den visuelle brugerflade
skal designes, at gruppere symbolerne s˚a de, der har relation til hinanden, ikke ligger for
spredt p˚a mobiltelefonens display. Disse symboler, eller semiotiske tegn, skal ogs˚a overvejes
inden designet af brugerfladen, for at sikre den ønskede forst˚aelse fra brugeren. Endvidere
m˚a det anses som en vigtighed, hvis brugeren skal have visuelle informationer i form af tekst,
om hvordan fejlene p˚a trailerens lys kan udbedres, at disse er velformulerede og præcise.
83

13.2.3 Brugeren
N˚ar brugerinterfacet skal udvikles, er der valgt at denne skal fungere som en formidlingsflade
med minimal interaktion. Dog er der en grænse for, hvor minimal interaktionen m˚a være,
før brugeren bliver i tvivl om systemet kører eller fungerer korrekt. N˚ar systemet udfører
lystjekket m˚a det derfor anses vigtigt, at brugeren ikke skal vente for længe p˚a informationen
om fejl p˚a lysene, eller om lysene har fuld funktionalitet. Hvis systemet ikke kan udvikles,
s˚a ventetiden ikke er mere end et par sekunder, bør der overvejes at illustrere status for
systemet. Hermed menes der, at n˚ar systemet er igang med at lave lystjekket, kommer der
fx visuel feedback til brugeren om systemets igangværende proces. Dette kunne eventuelt
integreres med den visuelle formidling af fejlens placering.
84

13.3 Formidlingssystemets indhold
Nu er grænsefladerne, samt krav der skal tages højde for n˚ar der skal kommunikeres ind og
ud af systemet defineret. Nu vil fokus blive rettet mod indholdet af formidlingssystemet. Da
der allerede er valgt, at dette skal være en mobiltelefon, er det eneste, der skal tages højde
for, hvordan softwaren p˚a denne mobiltelefon skal konstrueres samt valg vedrørerende dette.
13.3.1 Softwareplatform
Der er forskelle p˚a de mange forskellige programmeringssprog. Hvis programmet skal kunne
anvendes af alle mobiltelefoner, er det oplagt at vælge Java, da der i dette sprog, i teorien,
kun behøves at udvikle ét program, som kan køre p˚a alle platforme. Forskellen mellem
Java og fx C-programmering er, at C skal kompileres til den specifikke platform. Java kører
ovenp˚a et miljø, ogs˚a kaldt en “virtuel machine” (VM), som sørger for at “oversætte” koden
til maskinen. Dette miljø bevirker, at det ikke er nødvendigt at kompilere koden, hvorfor der
blot behøves at lave én udgave af programmet. Hvis Java vælges anvendt til at programmere
i, kræver dette at styresystemet, i dette tilfælde mobiltelefonen, har denne VM installeret. P˚a
computere skal installationen af denne VM ofte foretages af brugeren, men p˚a mobiltelefoner
er denne installation ofte foretaget af producenten. I dette tilfælde er det en komprimeret
udgave af en VM, kaldet Java Micro Edition (Java ME). Den fungerer som en normal Java
VM, men er begrænset i sine muligheder. Begrænsningen ligger blandt andet i at Java VM,
som er installeret p˚a computere, indeholder flere fuktioner end Java ME. Der vælges for det
kommende program, at dette skal udvikles i Java, da dette vurderes som en fordel da et af
kravene til programmet er, at dette skal kunne køre p˚a s˚a mange mobiltelefoner som muligt.
13.3.2 Applikation
N˚ar programmet startes p˚a mobiltelefonen skal der oprettes forbindelse til m˚alesystemet
automatisk. N˚ar programmet er tilsluttet m˚alesystmet skal programmet modtager og fortolke
de strenge, der bliver sendt fra m˚alesystemet. M˚alesystemet sender en ny streng 142 gange
pr sek. Da det ikke er hensigtsmæssigt at opdatere mobiltelefonens skærm 142 gange pr.
sek er det nødvendigt at lave en filtrering af inputtet der skal sørge for at brugerfladen kun
opdageres n˚ar der er ny information til brugeren.
Datainputtet fra m˚ale systemet indeholder fem elementer som er kommasepareret. Disse
fem elementer er tid, lystjek-cases, vinkel, hastighed og acceleration. Tiden skal bruges til
at bestemme om der er et eventuelt pakketab i overførelsen af data.
Lystjek-case skal bruges til illustrere eventuelle fejl i el-nettet p˚a bil og trailer overfor
brugeren. Denne værdi skal dekodes i forhold til statuskoderne i Tabel 10.2 p˚a side 72,
n˚ar statuskoden er dekodet skal tjekkes om det der vises p˚a brugerfladen svare til de ak-
tuelle statuskoder. For at information p˚a brugerfladen skal give brugeren den bedst mulige
forst˚aelse af eventuelle deffekter er det nødvendigt at køre statuskoderne gennem et filtre
s˚adan det kun er det nødvendige information der bliver leveret til brugeren. Dette giver ogs˚a
85

mulighed for at give brugeren yderligere information i form at hjælp og r˚ad til at løse en
eventuel problemstilling.
Vinkel, hastighed og acceleration skal bruges til at advare brugeren om kollisionsfare, for
at alarmen kan gives i rette tid er det nødvendigt at designe en algoritme der sørger for at
alarmen bliver udløst p˚a rette tidspunkt, hvilke elementer denne algoritme skal indeholde
er fx: tider for f˚a bilen til at stoppe, brugerens reaktions tid, systemets reaktionstid, bil
og trailers størrelse, informationen Vinkel, hastighed og acceleration. Dette er formeltlig
hovdeparten af hvad algoritmen skal indeholde selvom der kan være flere problemstillinger
hvis problemet analyseres nærmere.
Behandling af data giver derved tre krav til applikationen, som skal indeholde de følgende
funktioner:
• En funktion der oversætter en lystjek-case til den information og hjælp der er nødvendig
for at brugeren kan rette fejlen.
• En funktion der sørger for at brugerfladen kun bliver opdateret n˚ar ny information er
tilgængelig
• En funktion der beregner hvorn˚ar brugeren skal have en alarm om kollisionsfare.
Med baggrund i disse betragtninger for at applikationen skal kunne h˚andtere data fra
m˚alesystemet, behandle og formidle disse, vil det være fordelagtigt at benytte sig af den
klassiske 3-deling: I/O, Kontrol og GUI. P˚a Figur 13.2 er der illustreret, hvordan denne
applikation derved kan indeles.
Bluetooth
Software
Vinkel
data Håndter
I/O
Lystjeck
data
data og
definer
hvad skal
formidles
Vinkel
data
GUI
Lystjeck
data
Figur 13.2: Brugerfladens grænseflader
86
Højtaler
Input
Skærm

13.4 Kravspecifikation for formidlingssystemet
Formidlingssystemets grænseflader er blevet defineret og herudfra er indholdet af dette blevet
fastlagt. Brugerfladen skal s˚aledes programmeres i Java, da dette lever op til kravene. Pro-
grammet skal kunne h˚andtere dataen fra m˚alesystemet, og levere forskellige outputs til
brugergrænsefladen. For at de valg og konklusioner, taget i dette kapitel, skal kunne virke-
liggøres i et design, vil der i det følgende opstilles krav, som skal muliggøre videreudvikling
af systemet. Kravene er opstillet i en kravspecifikation, se Tabel 13.2, og indeholder samtlige
valg, og dermed krav, der er taget i dette kapitel samt opsummerede krav fra del 1.
Krav til formidlingssystemet
Krav F1 Informationer fra m˚alesystemet skal overføres til formidlingssystemet
via Bluetooth
Krav F2 N˚ar programmet initieres p˚a mobiltelefonen skal Bluetoothforbindelsen
til m˚alesystemet oprettes automatisk
Krav F3 Brugeren skal informeres auditivt om potentiel kollision mellem
bil og trailer
Krav F4 Kollisionsalarmen m˚a ikke maskeres af faktorer inde i førerkabinen
Krav F5 Intensiteten af alarmen m˚a ikke ligge over grænsen for mulig
høreskade
Krav F6 Kollisions alarmen skal være i det hørbare omr˚ade og er derfor
valg liggende mellem 1-4 kHz
Krav F7 Alarmen m˚a ikke have en forskrækkende effekt p˚a brugeren
Krav F8 Alarmen m˚a ikke medføre reduceret perceptuel forst˚aelse af andre
signaler
Krav F9 Kollisionsalarmen skal være informativ
Krav F10 Alarmen m˚a ikke være en koninuerlig lyd, men skal gives i impulser
og være intensiverende i hastighed
Krav F11 Lystjekket skal formidles til brugeren ved hjælp af b˚ade en figur,
symboler og tekst
Krav F12 Lystjekket skal formidles visuelt med høj kontrast mellem figur og
grund
Krav F13 Formidlingssystemet skal programmeres i Java
Krav F14 Formidlingssystemet skal indeholde en funktion der oversætter en
lyscasen til den information og hjælp der er nødvendig for at
brugeren kan rette fejlen
Krav F15 Formidlingssystemet skal indeholde en funktion der sørger for at
brugerfladen kun bliver opdateret n˚ar ny information er tilgængelig
Krav F16 Formidlingssystemet skal indeholde en funktion der beregner
hvorn˚ar brugeren skal have en alarm om kollisions fare
Tabel 13.2: Tabel med kravspecifikation for Formidlingssystemet
87

KAPITEL 14
Design af formidlingssystem
Efter kravene er blevet specifiserede, i analysen af formidlingssystemet, er det nu muligt at
designe denne del af systemet. Der vil nu blive gennemg˚aet hvordan en applikation laves.
De to systemer, m˚alesystemet og formidlingssystemet, er som tidligere nævnt lavet seperat.
M˚alesystemet er lavet fra bil og trailer til kredsløb, og derefter til Gumstix. Formidlingsys-
temet er udfra samme præncip lavet fra brugerfladen til data h˚andtering og til sidst Bluetooth-
kommunikation. Derfor vil applikationen blive præsenteret i samme rækkefælge. Først bruger-
grænsefladen, derefter datah˚andtering og til sidst kommunikation via Bluetooth.
14.1 Design af brugergrænseflade
Softwaren der skal konstrueres til formidlingssystemet, skal som tidligere nævnt h˚andtere
vinkeldata samt cases om lys fra m˚alesystemet. Formidlingen skal forekomme brugeren let
forst˚aelig og uden videre forsinkelser, s˚a brugeren ved hvad systemets igangværende proces
er. I det følgende vil brugerinterfacet blive udarbejdet, i forhold til de retningslinjer givet i
Analyse af brugergrænsefladen 13.2.
14.1.1 Lystjekket
Det første der vil blive anvendt, n˚ar systemet starter op er lystjekket, hvorfor dette bør starte
automatisk og være det første brugeren f˚ar informationer om fra systemet. Alt det der kan
forg˚a autonomt, bør ske autonomt, for at undg˚a for meget interaktion, og derved besvær
for brugeren. Dermed skal de lys p˚a traileren, der lyser konstant, tjekkes s˚a snart systemet
starter op, uden brugerens involvering, hvorefter systemet skal informere brugeren om de
lys, der ikke blev tjekket ved opstart. De lys der ikke tjekkes ved opstart, er de to blinklys
og bremselys. Disse kan ikke tjekkes automatisk, da disse kræver en manuel aktivering fra
brugerens side, for at systemet kan registrere forbindelsen.
N˚ar lysene tjekkes, er der valgt at illustrere dette, ved hjælp af et billede af en trailer,
hvor symboler placeres i hvert hjørne af traileren samt ved trailerstikket. Der er valgt tre
symboler til at informere brugeren om lysene p˚a traileren. Et advarsels-symbol er valgt til
at indikere at lysene ikke er testet, et v-tegn er valgt til at indikere at lysene er i orden og et
kryds er valgt til at indikere fejl. N˚ar systemet starter op, er der valgt at dette skal indikeres
ved at placere advarsels-symbolerne de fem steder p˚a traileren, hvorefter de lys der tjekkes
automatisk, ændres til v-tegn n˚ar systemet har konstateret, at disse er korrekt fungerende.
De lys der ikke bliver tjekket ved systemets opstart, modtager brugeren informationer om
at aktivere. Dette vil blive informeret om ved hjælp af tekst, som er valgt formuleret:
88

• Bremselyset har ikke været aktiveret. Aktivér dette ved at træde p˚a bremsen.
• Det venstre blinklys har ikke været aktiveret. Aktivér dette ved at blinke til venstre.
• Det højre blinklys har ikke været aktiveret. Aktivér dette ved at blinke til højre.
I samme øjeblik disse aktiveres vil status ændres, og nu informere om de virker eller ej.
En blanding af tekst og billede vil være det optimale, da der er valgt b˚ade at formidle
position af fejlene, typer af fejl og eventuelt et forslag om hvordan fejlen kan løses. En
tekst alene tænkes, at kunne give forvirring om placering af fejl, og et billede alene kan
give problemer med at formidle typen af fejl samt en eventuel løsning. Derfor er der valgt
et billede suppleret med tekst, for muligt at sikre forst˚aelse. Endvidere er der valgt, at
kontrasten mellem figuren af traileren og baggrunden skal være stor, og symbolerne valgt i
forskellige farver. Baggrundsfarven er valgt som sort og billedet af traileren er valgt i hvide og
gr˚a-tonede farver. De tre symboler er valgt henholdsvis i farven gul, grøn og rød og teksten
er valgt værende hvid. Disse valg er taget p˚a basis af, at overholde figur og grund-princippet
om at søge en s˚a høj kontrast som muligt for bedre forst˚aelse. En illustration af ovenst˚aende
valg kan ses p˚a Figur 14.1, hvor blinklysene og bremselyset mangler at blive aktiveret af
brugeren.
Figur 14.1: Illustration af brugerinterfacet
Der er valgt at lave forklarende tekst, som supplement, til symbol-placeringen for alle mulige
cases. Dermed er brugeren aldrig i tvivl om hvad det specifikt er for et lys der ikke er
funktionelt, p˚a trods af at der er færre symboler end lys p˚a traileren. Der er valgt kun at
placere symboler de fem steder, for at brugeren lettere kan lokalisere hvor fejlen befinder sig
p˚a traileren. Hvis samtlige lys skulle markeres med symbol ville der potentielt kunne være 9
symboler p˚a skærmen simultant, hvilket er vurderet for meget i forhold til at skabe nærhed
omkring trailerens for- og bagende. Hvis symbolerne skal have en vis størrelse i forhold til
skærmen, s˚a disse kan ses af hele m˚algruppen, og samtidig illustrere placeringen af fejl, for
brugeren, menes dette være det mest hensigtsmæssige valg.
89

14.1.2 Kollisionsalarmen
Ud fra de retningslinjer præsenteret i Analyse af brugergrænsefladen 13.2, er der valgt at
finde en alarmtone der matcher kriterierne. Der findes i forvejen mange alarmtoner p˚a
markedet, som brugeren er bekendt med, hvorfor det ikke menes nødvendigt at udvikle
en til specifikt dette form˚al.
Kollisionsalarm-funktionen skal aktiveres og deaktiveres, af brugeren, hvorfor der vælges at
lave en funktions-knap med dette form˚al. Der er valgt, at kollisionsalarmen bør lyde n˚ar
der approksimativt er 2 sekunder til kollision mellem bil og trailer. Dermed har brugeren
tid til at reagere p˚a alarmen, efter denne er perciperet. Der er valgt at give brugeren en
advarselslyd inden alarmtonen. Denne skal præsenteres i impulser, som skal øges des tættere
bil og trailer kommer p˚a hinanden. N˚ar der approksimativt er 2 sekunder inden kollision,
slukkes advarselslyden og alarmen g˚ar i gang, hvor brugeren kun har kort tid til at reagere,
s˚a kollision ikke hænder.
14.2 Programmering af brugerflade
Den grafiske brugerflade er bygget op af tre elementer.
• Et baggrundsbillede
• Tre forskellige symboler
• En tekststreng
I programmeringen er der lavet en Form, hvor et “image item” bliver lagt p˚a. Dette image
item kan kun tage elementer af typen “immutable”, som betyder at de ikke kan ændres
p˚a. Da det er nødvendigt, at bygge brugerfladen op af flere elementer og at ændre p˚a disse
løbende, skal der findes en løsning p˚a dette. Den valgte metode er, at konstruere dette
immutable element ud fra en række mutable delelementer. Det vil sige at for at generere
brugerfladen, hentes et baggrundsbillede ind hvorefter symbolerne og tekststreng lægges p˚a.
Efterfølgende laves dette om til ét element, der er immutable, som derefter kan lægges ind i
den form. Dette indebærer at hver gang der sker en lille ændring i brugerfladen, skal proce-
duren starte igen. P˚a Figur 14.2 er der illustreret hvordan dette sker. Hele processen sker i
klassen ImageTools.java, se Appendiks J.1.3, under pakken trailer.tools. Der skal tilføjes, at
baggrundsbilledet bliver hentet ind i klassen TrailerGUI.java p˚a linje 88. Kildekoden er at
finde i Appendiks J.1.1. Koden der laver det mutable image item om til immutable image
item, og returenerer det, er at finde p˚a linje 105 og 107 i klassen ImageTolls.java.
90

Figur 14.2: De enkelte mutable delelementer bliver lagt sammen til et immutabel billede, som
derefter bliver placeret i form
14.3 Datah˚andtering
Nu er metoden og koden for at f˚a elementer frem p˚a skærmen beskrevet. Der vil nu blive
set p˚a, hvordan billeder der skal vises p˚a skærmen, bliver genereret. Her sker første afvigelse
fra hvordan applikationen i sidste ende kommer til at blive konstrueret. Der er indsat en
stub i forhold til input fra Bluetooth. Denne stub er ikke fjernet af to grunde. For det
første er der ikke konstrueret kommunikation med Bluetooth. For det andet er der valgt, at
teste m˚alesystemet og brugerinterfacet separat, hvorfor interfacet blot skal laves s˚a det er
test-bart.
For at kunne simulere en proces, til en testperson, er der valgt at lave nogle animationsblokke.
Det vil sige, at symbolerne p˚a displayet vil ændre status ét ad gangen. En animationsblok
vil blive startet ud fra et input, der fortæller hvilken type fejl, der er p˚a traileren. Her er
indsat en “stub” og typen af fejl er genereret af et tastetryk, helt specifikt et menupunkt,
p˚a mobiltelefonen. Fejlbeskeden er alts˚a ikke generet af I/O via Bluetooth, som det vil være
p˚a den fulde version. Konkret betyder dette, at n˚ar der fx trykkes p˚a et menupunkt, vil en
fejlsituation svarende til menupunktet blive vist p˚a skærmen.
Animationsblokken tager nogle trin, hvor der vises et symbol og skrives noget tekst til en
91

vektor. Hvert trins “forsinkelse” kan defineres, og der kan dermed gives en illusion om, at
systemet “tygger p˚a”/bearbejder en fejl. Definitionen af animationsblokken ligger i klassen
AnimationBlock.java, se Appendiks J.1.2,under pakken trailer.tools. Anvendelsen af anima-
tionsblokkene sker i klassen TrailerGUI.java, se Appendiks J.1.1. I det følgende er der givet
et eksempel p˚a en animationsblok.
1 private void showAnimation2 ( ) {
2 // r e s e t t i n g images
3 imageTypes = new int [ ] {1 , 1 , 1 , 1 , 1 , 1 } ;
4
5 // t e l l i n g which images s h o u l d be updated and when
6 animation = new AnimationBlock [ ] {
7 new AnimationBlock ( 1 , 0000 , 2 , null ) ,
8 new AnimationBlock ( 2 , 0000 , 2 , null ) ,
9 new AnimationBlock ( 3 , 0000 , 2 , null ) ,
10 new AnimationBlock ( 4 , 0000 , 2 , null ) ,
11 //new AnimationBlock (5 , 1000 , 2 , n u l l ) ,
12 new AnimationBlock ( 5 , 1000 , 2 , ” Alt l y s f u n g e r e r k o r r e k t ” )
13 } ;
14 Thread t = new Thread ( this ) ;
15
16 // s t a r t i n g animation t h r e a d
17 t . s t a r t ( ) ;
18 }
P˚a linje 3 nulstilles symbolerne. Dette gøres hovedsageligt med henblik p˚a forsøget. Under
forsøget skal systemet kunne starte fra en vilk˚arlig fejlbesked, og fungere som om det er
første gang systemet tjekker lyset, uden at programmet skal starte forfra hver gang. Dette
gøres for at simulere systemets bearbejdning af de forskellige lys p˚a samme tid. Ellers kunne
det ske, at blot ét lys ændres fra “ok” til “fejl”, hvilket ikke er hensigtsmæssigt.
P˚a linje 6 genereres der et objekt af typen AnimationBlock. Dette objekt tager placering,
forsinkelse, type af symbol og den tekst der skal tilføjes brugerfladen, som argumenter.
Placeringen af symbolerne er ved stikket og et i hvert hjørne af traileren, og er forklaret i
Sektion 14.1.1 i dette kapitel. Argumentet forsinkelse er defineret i tusindedele sekunder, s˚a
for et sekunds forsinkelse, skal der skrives 1000. Argumentet symbol er af type er 1,2 eller
3. Henholdsvis ikke testet, ok og fejl. Tekststrengen er den fejlbesked, der skal tilføjes den
vektor, som bliver lagt sammen med de andre delelementer, som nævnt tidligere. Koden der
lægger alle disse elementer sammen kan ses i det følgende.
1 private void i n i t i a l i z e I m a g e ( Vector t e x t ) {
2 t r a i l e r I m g I t e m = new ImageItem (
3 null ,
4 ImageTools . createTrailerWithImages ( t r a i l e r I m g , imageTypes , d i s p l a y . numAlphaLevels ( ) >=
5 ImageItem .LAYOUT DEFAULT,
6 null
7 ) ;
Metoden tager en vektor af tekststrenge som argument. Metoden genererer et nyt ImageItem,
92

som bliver navngivet trailerImgItem. Første null er en label, som ikke skal bruges. Herefter
afvikles den statiske funktion createTrailerWithImages med argumenterne baggrundsbillede,
symboler, om den understøtter transparente billeder, en vektor og koordinatsættet for placer-
ing af tekst. Herefter defineres hvordan det image der returneres, skal placeres p˚a ImageItem.
Sidste null er alternativt label, som heller ikke skal bruges.
14.4 I/O
Som tidligere nævnt blev der indsat en stub i datah˚andteringen til at simulere I/O-relationerne.
Under en udviklingsface kan det være yderst hensigtsmæssigt, at indsætte disse stubs for
at konstruere de enkelte moduler hver for sig. I denne applikation blev stubben ikke fjer-
net, da der opstod problemer med Bluetooth forbindelsen. Da kravet om at programmet til
formidlingssystemet, her en mobiltelefon, skulle kunne køres p˚a alle platforme, faldt valget
naturligt p˚a Java. Dog m˚a der, udfra erfaring, konstateres at anvendelse af Java ikke er
ideel, n˚ar en mobiltelefon skal anvendes n˚ar der skal tilg˚aes hardware som Bluetooth. De
funktioner der ligger i Java ME virker nemlig ikke p˚a alle platforme.
Under udviklingen var der to platforme til r˚adighed, b˚ade til “troubleshooting” og sikre at
kravet om funktionalitet p˚a flere platforme, som minimum delvist kunne testes og opfyldes.
Først blev der forsøgt at lave nogle sm˚a testprogrammer. En server og en sender. Serveren
blev valgt til at være p˚a Gumstix i m˚alesystemet, og blev i udviklingsfasen simuleret af en
PC. Sender skulle køre p˚a en mobiltelefon og automatisk finde en bestemt Mac-adresse og
tilkoble sig denne. Derefter skulle server, efter registrering af en tilkoblet sender, sende en
prædefineret besked i form af en streng der indeholdte fx “test1”. Det var ikke muligt for
projektgruppen, p˚a den afsatte tid, at f˚a denne test-applikation til at fungere.
Der blev fundet et program, med stor lighed, udviklet af afdelingen for Mobile Devices p˚a
AAU. Programmet er udviklet til kommunikation mellem mobiltelefon og et Opensensor
Board via Bluetooth. Et Opensensor Board kan sammenlignes med Gumstix, da de begge
kører med en begrænset udgave af Linux. Dette program virkede til dels. P˚a mobiltelefon-
erne med platformen Symbian kunne applikationen starte op og begynde at søge efter den
prædefinere Mac-adresse, men kom ikke længere. Server-enden i dette program er specifikt
lavet til Opensensor boards, og det blev ikke muligt, inden for den afsatte tid, at lave det
om til at køre p˚a Gumstix eller Windows.
Det vil sandsynligvis blive nødvendigt at programmere specifikt til enkelte mobiltelefon-
modeller. Hvis det er tilfældet vil andre programmerings-sprog nok være mere fordelagtige.
H˚andtering af fx Bluetooth p˚a symbian kan konstrueres hurtigt og nemt med Python. Et an-
det problem Python kan hjælpe med, er styring af profiler. Med Java er det ikke umiddelbart
muligt at styre profiler og fx fjerne lydløs. Alarmlyden for kollisionsalarmen vil ikke virke
hvis brugeren har sat den p˚a lydløs. Med Python er det muligt at styre Symbian telefoner
fuldstændigt.
93

Til sidst blev der forsøgt at udvikle en basal test-applikation. Denne havde kun et enkelt
form˚al, at søge efter Bluetooth-enheder i nærheden. I følge dokumentation fundet p˚a in-
ternettet skulle de funktioner der blev anvendt, virke p˚a de fleste platforme. Der m˚atte
konstateres, at funktionerne kun fungerede p˚a Symbian.
Systemets nuværende struktur kan ses p˚a følgende UML-diagram 14.3
trailer.io
Software
trailer.tools
AnimationBlock
AnimationBlock(int, long, int,
String)
getPosition()
getDelay()
getImageType()
getText()
ImageTools
createTrailerWithImages(Ima
ge, int[], boolean, Vector, int,
int)
trailer.gui
TrailerGui
TrailerGUI()
destroyApp(boolean)
pauseApp()
startApp()
initializeTrailerApp()
commandAction(Command,
Displayable)
run()
showAnimation1()
showAnimation2()
showAnimation3()
showAnimation4()
showAnimation5()
showAnimation6()
initializeImage(Vector)
Figur 14.3: UML-diagram for formidlingssystemet ved projektets afslutning
94

KAPITEL 15
Verificering af formidlingssystemet
Der foreligger nu et formidlingssystem, som er blevet udviklet efter de tidligere opstillede
krav. For at be- eller afkræfte om dette overholder de opstillede krav, er der blevet udført
en accepttest for dette system. Accepttesten kan ses i Appendiks G p˚a side 125. Af testen
fremg˚ar der, at de indledende formelle krav kun delvist er overholdt. Dette værende valg af
udviklingsplatform, overførsels-protokol for signaler fra m˚alesystem til mobiltelefonen med
flere. Test to, omhandlende krav F2, om programmet ved initiering automatisk opretter
forbindelse til m˚aleenheden, er ikke overholdt. Der er ikke opstillet yderligere tests for krav
F4 til F10, da disse krav omhandler den auditive advarsel ved kollisionsalarmen. Dette
auditive signal er ikke valgt endnu og kan derfor ikke testes.
Formidlingssystemet overholder p˚a dette tidspunkt langt fra alle de opstillede krav. Som det
ogs˚a fremg˚ar af testsene med mere, er vægten ikke blevet lagt p˚a at færdiggøre kollisionsalarm-
delen. Denne mangler en del arbejde endnu, men kan relativt let implementeres i næste
prototype.
Vægten er derimod blevet lagt p˚a lystjek-delen af formidlingssystemet. Denne del er stort set
færdigudviklet for denne prototype. Under test-delen vil der blive foretaget en koncepttest
som blandt andet afklarer hvorvidt lystjekket er accepttabelt af brugeren.
Alt i alt m˚a det desværre konstateres at formidlingssystemet er ikke helt færdigudviklet til
brug i prototypen. Dette er ikke p˚a grund af at udviklingen er g˚aet i en forkert retning, men
m˚alene er blot ikke blevet n˚aet, p˚a grund af for mange uforudsete problemer. Her er der tale
om Gumstixen og mere specifikt at understøtte Java og Bluetooth p˚a samme tid. Det blev
valgt at orientere formidlingssystemet mod at kunne foretage en senere koncepttest. Dette
er en væsentlig grund til at kravene ikke er overholdt. Konklusionen p˚a dette design er at
lystjekdelen af formidlingssystemet er dog blevet klar, i s˚adan en form at forst˚aeligheden af
dette kan testes i en koncepttest.
95

KAPITEL 16
Verificering af Trailerhjælper
I dette kapitel skal der afgøres, om denne prototype kan accepteres som helhed. Dette gøres
udfra en samlet accepttest. Accepttesten skal udformes p˚a bagrund af produkt-kravspecifikationen,
som kan ses i Kapitel 7 p˚a side 29. Dette vil dog ikke blive gjort. Selve acceptest-skabelonen
er dog udfærdiget, og kan ses i Appendiks H p˚a side 126, og er derved klar til brug, i en
senere iteration af Trailerhjælper.
Da hverken m˚alesystemet eller formidlingsystemet er blevet accepteret i nuværende tilstand,
vil det heller ikke være muligt, at verificere Trailerhjælper. Dette kræver s˚aledes, at de
underliggende systemer fungerer, som tilsigtet før der kan afgøres om selve produktet, med
de yderligere krav der m˚atte være til dette, kan verificeres.
Den primære ˚arsag til at begge systemer ikke fungerer korrekt er Gumstixen. Der er i dette
projekt blevet arbejdet med m˚alesystemet og med formidlingssystemet. For begge disse
systemer gælder det, at der er blevet arbejdet hen mod at disse skulle levere eller modtage
signaler fra Gumstixen, som derved er blevet flaskehalsen.
Det blev valgt at ændre udviklingen af formidlingssystemet, s˚a tilgang til Gumstixen kunne
undg˚aes, og formidlingssystemet i stedet kunne styres fra en laptop. Derved blev det muligt
at teste p˚a dette. Denne ændring i udviklingen er naturligvis medvirkende til, at formidlingssys-
temet ikke længere overholder de opstillede krav.
Hvis der kun tages højde for krav, der ikke vedrører Gumstixen, er dette meget tæt p˚a at
overholde de opstillede krav. Der er nogle f˚a detaljer, som skal ændres, men selve kredsløbet
kan modtage og videreformidle de ønskede signaler.
Trailerhjælper lever, af ovenst˚aende grunde, s˚aledes ikke op til kravene eller forventningerne
til systemet ved verificeringen af dette.
96

Del III
Test
97

17.1 Form˚al
KAPITEL 17
Koncepttest
Der er besluttet, at lave en test p˚a produktet, i dets nuværende stand. Testen vil ikke blive
udført, som et empirisk forsøg, men blot et “Prof of concept”, da udviklingen fortsætter
sideløbende med testen. Form˚alet er, at f˚a testpersonernes input om konceptet i sin helhed,
samt at finde ud af om brugergrænsefladen skal igennem en iteration mere, for at formidlin-
gen til brugeren bliver som ønsket. Der er valgt, at teste p˚a cirka seks testpersoner som har
et kørekort, da dette vurderes som et passende antal at f˚a data om p˚a denne første itera-
tion. Da forbindelsen mellem m˚alesystemet og formidlingssystemet ikke er færdig-udviklet,
vælges der at simulere denne forbindelse. Dette vil blive nærmere forklaret i et senere afsnit
om opstillingen.
Der er valgt at udføre denne test i et scenarie, der ligger s˚a tæt p˚a et virkeligt scenarie som
muligt. Der tænkes at udarbejde nogle opgaver der har til form˚al, at give testpersonen et
overblik over forskellen mellem et manuelt lystjek og det alternative lystjek som systemet
leverer. Desuden vil form˚alet med opgaverne være, at visualisere eventuelle problematikker
med videregivelsen af informationer gennem brugerfladen, for netop at kunne konkludere
om der skal itereres p˚a brugergrænsefladen. Der tænkes, at interviewe testpersonen løbende,
for at stille spørgsm˚al ved eventuelle problemer testpersonen m˚atte have under udførelsen
af opgaverne, samt f˚a deres subjektive mening om konceptet.
17.2 Opstilling af test
Der er valgt, at have fire personer til udføre testen. Disse er
• En observatør, som ogs˚a vil fungere som notat-tager
• To operatører, som skal sørge for de tekniske detaljer
• En forsøgsleder
Observatør tænkes, at have til opgave at observere testpersonen under forsøget. Desuden
skal observatøren notere, hvordan testpersonerne udfører opgaverne, samt notere svarene fra
interviewene.
En af operatørerne skal styre mobiltelefonen, der tænkes anvendt, fra en laptop. Mobiltele-
fonen vil have applikationen for formidlingssystemet installeret samt en klient, der giver
mulighed for, at operatøren kan fjernstyre mobiltelefonen via Bluetooth ved hjælp af en
98

laptop. Laptoppen vil have serveren installeret, hvorfor denne kan have fuld kontrol over
mobiltelefonen.
Forsøgslederen vil under denne test have til opgave, at varetage al kommunikation med
testpersonen, b˚ade at stille opgaver samt interviewe.
En bil tænkes anvendt under forsøget, med en p˚asat trailer. For at undg˚a at lave indgreb i
trailerens ledningsnet, og kunne simulere fejl, vil der blive trukket et nyt ledningsnet, som
tænkes skjult under trailerens pressening. Bagklappen p˚a traileren vil blive sl˚aet ned, s˚a
trailerens lygter ikke er synlige. Alternative lygter, som har tænd/sluk-knap p˚am˚anteret, s˚a
de enkelte lygter kan tændes og slukkes manuelt, vil blive monteret p˚a en træ-konstruktion
der er tilpasset trailerens størrelse. Derefter vil konstruktionen p˚amonteres trailerens lad, og
dækket til af presseningen, s˚a kun lygterne er synlige, se Figur 17.1. Den anden ekperime-
nator skal under testen, tænde og slukke disse p˚asatte lygter, n˚ar nødvendigt.
Figur 17.1: Bil med p˚asat trailer, hvor trailerens lygter er skjulte og konstruktionen er p˚asat
Dermed skal der blot trækkes strøm fra bilens anhængerstik, for at disse alternative lys kan
tændes og slukkes manuelt. Dette tænkes gjort af forsøgslederen under forsøget.
Der er valgt et mellemstykke, der skal simulere kredsløbet og Gumstix, som skal placeres
mellem bilens anhængerstik og trailertstikket. Dette er konstrueret som en kasse, med direkte
genneløb af strømmen og p˚asat diode, s˚a brugeren kan se n˚ar dette er aktiveret, se Figur 17.2
p˚a næste side.
99

Figur 17.2: Mellemstykket med tilsat strøm fra bilens anhængerstik og mobiltelefonen der skal
anvendes
Dermed skal der brug for følgende ting under opstillingen:
• En bil
• En trailer
• En mobiltelefon
• En laptop
• Et indsatsstykke mellem mellem bil og trailer
• Et sæt lygter til traileren
17.3 Design af test
Der tænkes at n˚ar testpersonen ankommer til testscenariet, som er valgt udendørs i en bil
med p˚asat trailer, vil denne f˚a en kort introduktion, af forsøgslederen, til hvordan testen
tænkes at forløbe. Denne er udarbejdet, og kan ses i Appendiks I.1. Testpersonen vil blive
bedt om at “tænke højt” under hele testen, hvilket vil sige at fortælle højt hvad vedkommende
tænker, gør og muligvis har problemer med. Derefter tiltænkes der, at testpersonen skal
gennemføre et manuelt lystjek uden hjælp fra forsøgslederen, som testpersonen plejer at
foretage dette. Dette inkluderer at koble trailerstikket i bilens anhængerstik. Efterfølgende vil
testpersonen blive stillet tre verbale spørgsm˚al omhandlende dette tjek. Samtlige spørgsm˚al,
som testpersonen vil blive stillet under testen, er udarbejdet og er at finde i Appendiks I.2.1.
N˚ar spørgsm˚alene er besvarede tænkes der, at samme procedure skal udføres med systemet.
100

Testpersonen f˚ar leveret mobiltelefonen og mellemstykket, og skal koble dette mellem trail-
erstikket og bilens anhængerstik, hvor systemet efterfølgende automatisk tjekker og kon-
staterer, at lysene er korrekt fungerende og sender informationen til brugergrænsefladen.
Efterfølgende vil de samme tre spørgsm˚al, som blev stillet efter det manuelle tjek, blive
stillet testpersonen omhandlende dette tjek.
Derefter vil opgaverne, omhandlende systemet og dets funktionalitet, stilles hvor testperso-
nen tænkes at udføre disse. Scenariet testpersonen skal forestille sig at befinde sig i er, at
testpersonen lige har monteret mellemstykket, sætter sig ind i bilen og systemet foretager
lystjekket. En billede vises p˚a displayet med symbolerne om potentiel fejl, hvor testpersonens
opgave er, at tjekke om fejl-beskeden stemmer overens med trailerens lys, og forklare hvordan
dette kunne løses ud fra løsningsforslaget givet med tekst p˚a displayet. Hvis testpersonen
ikke kan tolke informationerne p˚a brugergrænsefladen, er der besluttet, at forsøgslederen kan
give testpersonen stikord til hvad der forsøges at formidle. Dog skal forsøgslederens hjælp
være begrænset, for at have s˚a lidt indflydelse p˚a resultaterne som muligt. Opgaverne med
forklaring vil blive givet i randomiseret rækkefølge og lyder som følgende:
1. Bremselysene har ikke været aktiveret. Aktivér dette ved at træde p˚a bremsen.
2. Det venstre blinklys har ikke været aktiveret. Aktivér dette ved at blinke til venstre.
3. Det højre blinklys har ikke været aktiveret. Aktivér dette ved at blinke til højre.
4. Alt lys fungerer korrekt
5. Højre blinklys virker ikke
6. Venstre side: Et lys virker ikke (enten positions- køre- eller nummerpladelys)
7. Et bremselys virker ikke
8. Løs forbindelse i stik. Tag stikket ud og sæt det i igen.
N˚ar der ikke ikke der st˚ar hvad testpersonen skal gøre, er det meningen at testpersonen skal
stige ud af bilen og konstatere om problemet er korrekt konstateret af systemet.
N˚ar opgaverne er fuldført af testpersonen tænkes der, at de resterende spørgsm˚al som ve-
drører konceptet og brugerinterfacet bliver stillet, og testen afsluttes med at testpersonen
takkes for deltagelse i testen.
17.4 Udførelse
Umiddelbart blev der valgt, at seks til otte testpersoner skulle udføre testen. Der blev valgt,
at lave et pilotforsøg med en enkelt testperson, hvor der efterfølgende blev udført tests p˚a
fem yderligere personer. Da pilottesten blev udført uden problemer, var der ikke grund til
ændringer af hverken udførelsen af testen eller opstillingen.
N˚ar testpersonen ankom til det opstillede scenarie, blev de modtaget af forsøgslederen, der
læste introduktionen op for testpersonen. Introduktionen er at finde i Appendiks I.1 Under
hele testen, skulle testpersonerne “tænke højt”, hvilket vil sige, at de skulle snakke om det
101

de foretog sig og havde problemer med. Som det første skulle testpersonen koble traileren til
bilen og udføre et manuelt lystjek p˚a traileren, uden hjælp, som de plejer at gøre det inden
anvendelse af trailere. Efterfølgende blev testpersonen stillet to til tre spørgsm˚al:
1 Hvordan synes du det gik med at tjekke lysene manuelt? (Meget godt/Godt/Okay/
D˚arligt/Meget d˚arligt)
2 Fik du tjekket alle lysene under dette tjek? (Ja/Nej)
2.1 Hvis nej, er der noget du ville have gjort anderledes? (Ja/Nej)(Hvis ja, hvad skulle
det være?)
Efterfølgende blev testpersonerne introduceret til systemet, som en alternativ m˚ade at fore-
tage lystjek af trailer p˚a. De blev givet mellemstykket og skulle placere det mellem bilens
anhængerstik og trailerstikket. Derefter skulle de sætte sig ind i bilen, og tjekke status for
lystjekket p˚a mobiltelefonen. N˚ar dette godkendte, at samtlige forbindelser mellem bil og
trailer var fungerende, blev testpersonerne stillet yderligere to spørgsm˚al:
3 Hvordan synes du det gik med at tjekke lysene med systemet (Meget godt/Godt/Okay/
D˚arligt/Meget d˚arligt)
4 Hvordan vurderer du lystjekkene i forhold til hinanden? Her menes der tid og sværheds-
grad (˚Abent spørgsm˚al)
Da spørgsm˚alene var blevet besvaret, blev testpersonen introduceret til de fem randomiserede
opgaver, og blev bedt om at løse disse. N˚ar testpersonerne var færdige med at løse de fem
opgaver, blev de som sidste del af testen bedt om at besvare yderligere spørgsm˚al:
5 Hvad synes du om konceptet, at gøre det mindre besværligt for brugeren at tjekke
lysene p˚a traileren? (D˚arlig idé/Okay/God idé)
6 Du lavede b˚ade lystjekket manuelt og ved brug af systemet, hvilket synes du var
mest besværligt? (1. Systemet er meget mere besværligt/2. Systemet er lidt mere
besværligt/3. Ingen forskel p˚a de to/4. Manuelt er lidt mere besværligt/5. Manuelt er
meget mere besværligt)
7 Vi observerede, at der var lidt problemer med (jævnfør noter), vil du forklare hva der
var ˚arsagen til problemet? (˚Abent spørgsm˚al)
8 Ville du bruge systemet hvis du havde det til r˚adighed? (Ja/Nej efterfulgt af kommen-
tar)
9 Hvis du skulle ændre p˚a noget ved systemet eller interfacet, hvad ville du s˚a ændre
p˚a? (˚Abent spørgsm˚al)
Efter disse spørgsm˚al var besvaret, blev testpersonerne takket for deres deltagelse og esko-
rteret tilbage til deres respektive opholdssteder.
102

17.5 Dataopsamling
Besvarelserne er listet i en tabel, uden de tre ˚abne spørgsm˚al, se Tabel 17.1. Besvarelserne
af de ˚abne spørgsm˚al er at finde i Appendiks I.3. Tabellen viser de direkte besvarelser af
spørgsm˚alene, men der var mange kommentarer som supplerede spørgsm˚alene, som ikke
kommer til syne i tabellen.
Pilot Testperson 1 Testperson 2 Testperson 3 Testperson 4 Testperson 5
Spm. 1 Okay Okay Godt Okay Godt Godt
Spm. 2 Nej Nej Nej Nej Ja Nej
Spm. 2.1 Nej Nej Nej Ja Nej Ja
Spm. 3 Meget godt Okay Okay Meget godt Meget godt Godt
Spm. 4
Spm. 5 God idé God idé God idé God idé God idé God idé
Spm. 6 4 2 4 5 5 5
Spm. 7
Spm. 8 Ja Ja Nej Ja Ja Ja
Spm. 9
Tabel 17.1: Besvarelserne p˚a spørgsm˚al stillet under testen
Desuden kan der konstateres udfra de udtalelser testpersonerne kom med under testen, at
f˚a af dem har kendskab til lys p˚a trailere. Da der blev spurgt, om testpersonerne fik tjekket
samtlige lys under det manuelle tjek (spørgsm˚al 2), blev der svaret følgende:
• Nej, jeg glemte at tjekke bremselyset, hvilket jeg aldrig gør
• To af testpersonerne svarede nej, jeg glemte at tjekke baklysene
Testpersonen som svarede, at vedkommende aldrig tjekker bremselyset, virkede ikke til at
være klar over dette, før forsøgslederen gjorde opmærksom p˚a det efter testen var overst˚aet.
Testpersonen forklarede at der altid var en anden person til stede, n˚ar vedkommende skulle
køre med traileren.
N˚ar to af testpersonerne svarede at baklysene ikke blev tjekket, vurderes dette at skyldes
manglende viden omkring trailere og deres lys, da der kræves 13-polet stik for at indikere
baklysene. Disse er oftest kun at finde p˚a større p˚ahængskøretøjer som fx hestetrailere og
campingvogne. De to øvrige testpersoner, der svarede at de ikke fik tjekket alle lysene, glemte
blot at teste bremselysene hvilket de mente var nødvendigt at huske, hvorfor de ville gøre
dette anderledes til en anden gang.
Til spørgsm˚al nummer fire, hvordan de vurderer tjekkene i forhold til hinanden, var der
stor enighed om at det er mindre besværligt med systemet. Der var blot en ud af de seks
testpersoner der svarede, at vedkommende synses det er mindre besværligt at foretage et
manuelt tjek. Den testperson der fortrækker det manuelle lystjek, synes det gik meget godt
at foretage lystjekket med systemet, hvilket dataen ogs˚a viser, men det manuelle tjek forløb
ikke liges˚a. Testpersonen satte katastrofeblinket p˚a, og konstaterede derved at lysene p˚a
traileren var korrekt fungerende. Hvis dette er testpersonens sædvanlige lystjek procedure
der kommer til syne, kan der argumenteres for at det manuelle lystjek er nemmere, bare ikke
fyldestgørende i forhold til dansk lovgivning.
Der var ikke mange tilfælde af opst˚aede problemer under lystjekkene, hvorfor i de to tilfælde
spørgsm˚al 7 blev stillet, lød spørgsm˚alene og besvarelserne som følgende:
103

Observation: Der blev observeret problemer med aktiveringen af blinklys og bremselys
• Testpersonen forklarede at der opstod tvivl om hvad “aktiveringen” betød. Vidste ikke
at formuleringen betød at testpersone skulle blinke til venstre og højre samt træde p˚a
bremsepedalen.
Observation: Der blev observeret problemer med, at testpersonen forsøgte at trykke p˚a
knapperne p˚a mobiltelefonen. I dette tilfælde er mobiltelefonen udstyret med en touch-
skærm, som testpersonen kørte fingrene hen over flere gange.
• Testpersonen er ikke vandt til at betjene touch-mobiltelefoner og troede, at en s˚adan
var valgt at teste med var fordi at der skulle interageres haptisk.
Testpersonerne kom med flere nyttige beskrivelser af, hvordan de mente at systemet kunne
forbedres. Forbedrelserne er listet i det følgende:
• Beskrivelserne, af fejlenes placering og status for lystjekket, kan formuleres bedre som
fx “blink til venstre/højre” og “træd p˚a bremsen”.
• Teksten skal beskrive flere løsningsforslag til de givne situationer.
• Fire at testpersonerne foreslog, at det ville være hensigtsmæssigt hvis formidlingssys-
temet i stedet var en GPS eller PDA, da denne m˚aske har større sandsynlighed for at
være synlig i bilen.
• To af testpersonerne forslog at supplere det visuelle med en bip-lyd n˚ar der forekommer
ændringer p˚a skærmen. Det vil sige, at n˚ar en fejl detekteres og skærm-billedet ændres,
skal der komme en lyd, for at blikket bliver vendt mod skærmen.
Interfacet vil blive rettet til i form af problembeskrivelserne, da det er essentielt, at brugeren
forst˚ar informationerne der forsøges at formidles. Der vil ogs˚a overvejes hvorvidt der skal
tilføjes løsningsforslag til de mulige fejl-scenarier, men dog vil dette kræve en analyse af
hvor mange forslag, der er nødvendige for at sikre, at et af disse bliver fortolket. Forslaget
om at supplere den visuelle information med en bip-lyd, er et forslag der ikke er baseret
p˚a fejl-fortolkning fra brugerens side, men et forslag om forbedring, hvorfor vigtigheden og
konsekvenser af ændringen m˚a overvejes.
17.6 Delkonklusion
Form˚alet med testen m˚a anses for at være opfyldt, da testpersonernes holdning til systemet
er kommet til kende, samt eventuelle problemer vedrørende brugerinterfacet er synliggjort.
Konceptet vurderes værende bæredygtigt til videre udvikling af dette, eventuelt med sm˚a
ændringer. Eksempelvis skal teksten, der formidler hvordan problemer under lystjekket, være
kort og præcis, og skal eventuelt igennem en iteration mere. Endvidere er der ingen tvivl
om, at testpersonernes holdninger til at brugergrænsefladen er via mobiltelefonen, ikke er
overraskende. Formidlingssystemet er blevet udvikledet s˚aledes, at dette kan anvendes med
en GPS, PDA eller andre interaktionsflader, som har indbygget Bluetooth, da mobiltelefonen
blot blev valgt udfra antallet af mobiltelefoner i de danske hjem.
104

Hvad ang˚ar testpersonernes forslag om en bip-lyd, for at indikere ændring i status, kunne
dette sagtens implementeres i formidlingssystemet. Dette vurderes værende et godt forslag,
og vil overvejes n˚ar næste iteration af formidlingssystemet p˚abegyndes. Hvis denne lyd
blev implementeret, kunne det for˚arsage, at n˚ar systemet detekterer en fejl under kørsel,
bliver brugeren gjort opmærksom p˚a denne fejl med lyden, hvorfor detekteringen muligvis
kan forekomme tidligere. Dog skal der i dette tilfælde forsøges, at udvikle lyden s˚aledes, at
denne ikke fjerner brugerens visuelle fokus fra vejene. Hvis formidlingssystemet kun ændrer
det visuelle billede, n˚ar en fejl opst˚ar, kan der g˚a længere tid før brugeren ser billedet
da opmærksomheden ikke bliver ført over p˚a mobiltelefonen. Problemstillingen med, at en
auditiv stimulus potentielt kan fjerne visuel fokus, vil skulle analyseres under næste iteration,
hvis dette blev valgt at anvende. Dette er dog fravalgt i dette tilfælde, da der ikke var synlige
problemer, for testpersonerne at forst˚a formidlingen p˚a interfacet, hvorfor dette vurderes
tilfredsstillende i forhold til form˚alet med interfacet.
105

106

Del IV
Afslutning
107

Konklusion
Indledningsvis m˚a der konstateres, at m˚alet projektgruppen har sat ikke er n˚aet, hvilket
skyldes flere faktorer. Dog er der erhvervet viden omkring en problemstilling, der ikke var
tydeliggjort inden dette projekts start, samt indsamlet ny viden om emner som fx kred-
sløbsteori, m˚aleteknik, Java-programmering og problemløsning generelt.
Velvidende om, at problemets omfang ikke er analyseret p˚a et generelt plan, skønnes der
at problemet med fejl-signalering p˚a trailerens lys, er for stort, s˚a længe der er risiko for
ulykker med potentielt tab af liv som følgevirkning. Derfor vurderes det, af projektgruppen,
som yderst vigtigt at finde en løsning der medfører at fejlagtig lys-signalering p˚a trailere
ikke observeres s˚a ofte i gadebilledet, som det gør nu.
Løsningsforslaget, der blev stillet projektgruppen, er et produkt der potentielt kunne have
denne effekt, men der m˚a konstateres, at hvis dette skulle forsøgt udført, efter dette semesters
lærinsproces, er der flere ting der ville vælges at gøres anderledes. Konceptet med Java er,
at det er platformsuafhængigt. Dog er det begrænset til almene og basale funktioner og har
problemer med at f˚a direkte hardware adgang til fx Bluetooth. Det har derfor ikke været
muligt, at f˚a en Bluetooth-forbindelse etableret mellem mobiltelefonen og Gumstixen.
Det var svært at finde ud af, hvordan Gumstixen kunne køre med Java og Bluetooth samtidig,
og den særdeles mangelfulde dokumentation, for Gumstixen, gjorde det svært at udvikle
til platformen. Det var muligt at f˚a etableret en serielport-forbindelse til Gumstixen via
Bluetooth og læse TTL portene. Dog gjorde den særdeles mangelfulde dokumentation, at
det ikke var muligt at f˚a Java og Bluetooth til at fungere samtidig. Hver for sig er b˚ade
interfacet p˚a mobiltelefonen og m˚alesystemet fuldt funktionelt.
M˚alesystemet er udviklet, s˚a det ikke kræver indgreb i el-systmet eller eksterne strømforsyning.
Der er derudover lavet tiltag for at minimere p˚avirkningen af lysintensiteten fra traileren. Det
blev derfor besluttet, at begrænse signaltabet, ved at benytte meget sm˚a m˚alemodstande.
Dette gav nogle problemer ved design af kredsløb da fx modstandenes tolerancer pludselig
havde stor indvirkning. Løsningen p˚a dette problem var, at indsætte en IC-kreds specifikt
designet til form˚alet.
Der er yderligere problemer med m˚alesystemet, eksempelvis hvis samme antal kørelys i hver
sin side af traileren sprænger samtidigt, kan dette ikke m˚ales af systemet. Bortset fra disse
sidste mangler, vedrørende lystjekket, er det lykkedes at teste trailerens lys ved hjælp af et
relativt simpelt kredsløb.
Med hensyn til interfacet og konceptet, var der generelt positiv respons fra testpersonerne.
Testpersonerne gav udtryk for at mobiltelefonen ikke var det optimale produkt at benytte
som formidlingssystem under kørsel. Hvorvidt dette bør erstattes af en GPS, PDA eller
lignende bør der foretages flere analyser om.
108

Perspektivering
Denne perspektivering vil beskæftige sig med Trailerhjælpers fremtid. Dels vil der blive set
p˚a hvad næste skridt for produktet kan være, og dels vil det blive diskuteret om produktet,
med den nuværende viden, overhovedet skønnes at have en fremtid.
Trailerhjælper systemet er ved dette projekts afslutning kun delvist funktionsdygtigt og
vitale elementer i forhold til kommunikationen er ikke blevet gennemarbejdet. Det er der-
for ikke muligt at teste hvorvidt konceptet, Trailerhjælper, fungere i praksis i en realistisk
brugssituration. En s˚adan test vil kræve at systemet bliver færdigudviklet og konstrueret i
en funktionsdygtig prototype.
Resultaterne fra koncepttesten, som er en simulering af lystjekket, i Trailerhjælper, tyder p˚a
at den del af konceptet vil fungere i en endelig prototype. Det vides ikke om de tanker der
er blevet gjordt om kollisions alarmen vil kunne overføres til paksis. Med baggrund i den
betragtning, at designprocessen ikke er n˚aet s˚a langt, er det ikke muligt at forkaste dele af
det koncept trailerhjælper systemet er bygget p˚a. En viderudvikling vil være nødvendig for
at projektgruppen kan tilegne sig mere information om hvorvidt konceptet vil kunne funger
i en endelig løsning.
Det bliver ogs˚a indikeret gennem koncepttesten at en løsning der benytter en GPS monteret
i bilen, m˚aske vil være en bedre løsning i brugssiturationen. En yderlig analyse af GPS
platform kunne derfor være relavant i en videre udvikling.
109

ADC Analog til digital konverter
KAPITEL 18
Ordliste
Defacto standard Standardisering der fremkommer ved at producenter gør noget p˚a samme
m˚ade
I/O Input/output, bruges til at forklare forholdet mellem hvad der tilsluttes som input og
hvilket output et kredsløb skal levere.
I/O kort Kredsløb der kan h˚andtere Input og Output af elektriske signaler
TTL Transistor-Transistor logik, dette er en standart kommunikation mellem logiske kredse.
N/C Not connected
110

Litteratur
Danmarks Statistik [2005], ‘Hver sjette familie har en trailer’,
http://www.dst.dk/pukora/epub/Nyt/2005/NR125.pdf.
Danmarks Statistik [2006], ‘Trailere et udpræget vestdansk fænomen’,
http://www.dst.dk/pukora/epub/Nyt/2006/NR129.pdf.
Danmarks Statistik [2008], ‘Vidste du at ...’, http://www.dst.dk/Statistik/ags/Vidstedu.aspx.
Department of Elecronic Systems [2008], ‘Fakta om lyd’,
http://es.aau.dk/sections/acoustics/research/projects/genevirkninger af lavfrekvent
stoej/fakta om lyd/.
Infineon Technologies AG [2007], PBA31308, BlueMoon Universal Platform. Databladet er
downloaded 10/12-2008.
Informationscenter for Miljø og sundhed [2008], ‘Hvor bliver de gamle mobiltelefoner af?’,
http://www.miljoeogsundhed.dk/DEFAULT.aspx?node¯4975.
Irawin, J. D. and Nelms, R. M. [2008], Basic Engineering Circuit Analysis, 9. edn, Wiley.
Jensen, J. R. [2008], ‘Fejl p˚a trailer førte til uheld’,
http://www.tv2bornholm.dk/moduler/nyheder/news.asp?id=37278.
Kosinski, R. J. [2008], ‘A literature review on reaction time’,
http://biology.clemson.edu/bpc/bp/Lab/110/reaction.htm.
Pedersen, K. [2008], ‘Hver tredje danske familie bruger gps-navigation’,
http://www.comon.dk/news/hver.tredje.danske.familie.bruger.gps-
navigation 35925.html.
Perez, R. [1993], ‘Lead-acid battery state of charge vs. voltage’,
http://www.arttec.net/Solar Mower/4 Electrical/Battery Charging.pdf.
Philips Semiconductors [2002], UCB1400, Audio codec with touch screen controller and power
management monitor. Databladet er downloaded 29/10-2008.
Poulsen, T. [2005], ‘Acoustic communication, hearing and speech’.
Sedra, A. S. and Smith, K. C. [2004], Microelectronic Circuits, 5. edn, Pearson Prentice Hall.
Thule trailers [2008], Brugerh˚andbog.
Wickens, C., Lee, J., Liu, Y. and Becker, S. G. [2004], An Introduction to human factors
engineering, 2. edn, Pearson Prentice Hall.
111

Appendiks
112

A.1 Svar fra interviewene
BILAGA
Spørgeskema og besvarelser
En tabel over svarene, givet under interviewene er illustreret i det følgende.
Spørgsm˚als nummer Antal forskellige svar
Spørgsm˚al 1 Mænd = 19
Kvinder = 11
Spørgsm˚al 2 30-40˚ar = 10
40-50˚ar = 6
50+ ˚ar = 14
Spørgsm˚al 3 Ja = 27
Nej = 3
Spørgsm˚al 4 Ugentligt = 5
M˚anedligt = 18
Sjældnere = 7
Spørgsm˚al 5 Ugentligt = 5
M˚anedligt = 16
Sjældnere = 9
Spørgsm˚al 6 Hver gang = 18
Nogen gange = 6
Sjældent = 6
Spørgsm˚al 7 1 = 7
2 = 4
3 = 6
4 = 6
5 = 7
Spørgsm˚al 8 Let = 17
Svært = 13
Spørgsm˚al 9 Ja = 14
Nej = 16
Tabel A.1: Besvarelser fra interviewene
113

B.1 Tilkobling af trailer
BILAGB
Tilkobling af trailer
Brenderup er en trailerproducent med 50 ˚ars erfaring, og p˚a deres hjemmeside, er ne-
denst˚aende retningslinjer fundet [Thule trailers, 2008].
1. Traileren kobles p˚a bilens anhængertræk.
2. Har traileren sikkerhedswire, fastgøres denne. Det er vigtigt, at sikkerhedswiren g˚ar i
lige linje fra traileren til anhængertrækket.
3. Forbind det elektriske system ved at sætte trailerens el-stik i trækkets stikd˚ase.
4. Kontrollér, at traileren er korrekt koblet p˚a bilen. Dette kan kontrolleres ved at løfte
i trailerens trækvange.
5. Kontrollér, at trailerens lygter virker korrekt.
6. Kontrollér, at lasten er jævnt fordelt og eventuelt fastspændt.
114

C.1 Eksisterende løsninger
BILAGC
Eksisterende løsninger
Figur C.1: TrueHitch er en hjælp n˚ar der skal bakkes præcist hen under en anhænger
Dette Aggregat kan ses i bagruden og dermed kan føreren se og denne rammer midtfor.
Afstanden styres ved at en stang sættes til at ramme bagsmækken p˚a bilen n˚ar denne er
ovenfor anhængertrækket. N˚ar stangen rammer lyser den del som ses gennem bagruden op.
Ønsker føreren et mere højteknologisk aggregat som hjælp n˚ar der skal bakkes til kan et
bakkekamera benyttes. Et eksempel p˚a en s˚adan kan ses i Figur C.2
Figur C.2: bakkekamera indbygget i nummerpladeholder og skærm til placering p˚a instrumentbræt
Dette kamera er indbygget i nummerpladeholderen og har en tr˚adløs forbindelse til en skærm
som placeres p˚a instrumentbrættet. Denne pakke kan let monteres og koster 140 dollars.
Et andet produkt som kan være til hjælp her er Waeco´s MagicWatch som best˚ar af 4 sm˚a
sensorer der placeres i kofangeren b˚ade for og bag, og som udsender en lyd i bilens højtalere
eller et billede p˚a en skærm. Sensorerne m˚aler afstanden til forhindringer omkring bilen og
advarer føreren hvis bilen kommer tæt p˚a. Dette produkt kan b˚ade hjælpe under tilkobling
115

af anhænger men ogs˚a under en bakkemanøvre hvor systemet kan forhindre at anhængeren
knækker helt om rammer bilen.
Ecs eletronics er en hollandsk virksomhed som kan leverer et system til næsten alle biltyper
som kan advare føreren hvis noget af lyset p˚a anhængeren skulle være defekt. I følge produ-
centen indeholder produktet følgende funktioner:
• Blinklysene p˚a anhængeren overv˚ages af 5C028 modulen. Hvis et af blinklysene er
defekt, lyder der en brummer samtidigt med blinklysene p˚a vognen. Kontroller blinkl-
ysene p˚a anhængeren.
• Bremselysene p˚a anhængeren overv˚ages af 5C028 modulen. Hvis alle bremselysene p˚a
anhængeren er defekte, vil der ved bremsning høres en brummer. Kontroller bremsel-
ysene p˚a anhængeren.
• Kabelsættet har en forberedelse s˚a ved en tilkoblet anhænger den eventuelt tilstede-
værende Park Distance Control D kan frakobles (afstandsm˚aling).
X
• En tilkoblet anhænger med en fungerende t˚agelygte vil bevirke at bilens t˚agelygte
frakobles.
INFO
Installationen m˚a kun udføres F af specialiserede værksteder. Installeringen er omfattende
og kræver forskellige indgreb bilens interiør med mere. I Figur C.3 ses hvordan det nye
ledningsnet skal ROUTING trækkes rundt i bilen.
H
I
B
C
J
C
H&I+M
J+L
K
B
X
A
© ECS Electronics B.V. Pag. 4 PE-032-BL / 270705NB
G
Figur C.3: Udpluk fra ecs-eletronics installeringsvejledning som viser hvor ledningsnettet skal
trækkes i bilen
I nyere high-end biler som Mercedes, BMW og Audi findes der i dag systemer som kan
informere føreren om alle tænkelige indstillinger og ændringer i bilens tilstand. Systemer
har forskellige navne DIS som st˚ar for “driver information system” eller hos BMW “di-
agnostics information system”, IDIS “intelligent driver information system” og p˚a dansk
førerinformationssystem. Gennem disse systemer er det muligt at f˚a information om hvorvidt
trailerens lys fungerer korrekt.
Ud over de nævnte produkter findes der flere avancerede produkter, specielt til camp-
ingvogne, som griber ind hvis bil og campingvogn er ved at komme i slinger og stabilisere
kørslen.
116
A
G
K
M
5C028
VXX09
L
D+F

BILAGD
M˚alejournal for spændingsniveau-m˚aler
Form˚alet med disse m˚alinger er at verificere, at kredsløbet for spændingsniveau-m˚alingen
fungerer efter hensigten.
Teorien bag m˚alingen
Kredsløbets funktion er at konvertere en analog spænding p˚a cirka 12 V til et TTL signal
p˚a 5 V. Hvis der er under 5 V spænding p˚a indgangen, skal outputtet være 0 V.
M˚aleprocedure
M˚alingen foretages ved at p˚atrykke indgangen en DC spænding og foretage en spænd-
ingsm˚aling p˚a udgangen af kredsløbet via et voltmeter. For at sikere, at kredsløbet ikke
oscillerer skal udgangssignalet desuden tjekkes med et oscilloskop. M˚aleopstillingen er illus-
treret p˚a Figur D.1, og skal udføres p˚a alle fem spændingsniveau-m˚alere.
Udstyrsliste
Spændings-
generator
Spændings-
forsyning
Spændingsniveau-måler
Oscilloskop
Voltmeter
Figur D.1: M˚aleopstilling for verificering af spændingsniveau-m˚aler
Udstyret, der er blevet brugt til at tage m˚alingerne med, er opstillet i Tabel D.1 p˚a næste
side.
117

M˚aleresultater
Apparat Fabrikant AAU nummer
Spændingsgenerator HQPower suply PS3020 43685
Oscilloskop Agilent 54621A 33847
Voltmeter Fluke 37 08520
Spændingsforsyning Hameg HM7042 33886
Tabel D.1: Apparater anvendt under m˚alingerne af analog output
Resultaterne fra m˚alingen kan findes i tabellen, hvor outputtet fra de fem TTL udgange er
listet ved tre forskellige p˚atrykte spændinger p˚a de fem forskellige indgange.
Input spænding 0 V 8 V 10 V 12 V 14 V
TTL0 0,61 V 0,94 1,12 5,03 5,03
TTL1 0,45 V 0,71 1,11 5,03 5,03
TTL2 0,62 V 0,76 1,11 5,03 5,03
TTL3 0,62 V 0,94 5,02 5,03 5,03
TTL4 0,61 V 0,81 1,09 5,03 5,03
Tabel D.2: M˚aleresultater til test af forstærkning og frekvensomr˚ade
118

BILAGE
M˚alejournal for effektm˚aling
Form˚alet med denne m˚aling er at verificere at effektm˚alings-kredsløbet fungerer efter hen-
sigten.
Teorien bag m˚alingen
Kredsløbet m˚aler spændings-faldet over seks effektm˚alings-modstande og leverer enten et
ADC output eller et TTL output. kredsløbet kan deles op i 3 forskellige overførings-funktioner,
den ene er overføring til TTL, og de to andre et to forskellige overførsler til en ADC værdi.
Spændingsfaldet over effektm˚alings-modstandende for begge blinklys og t˚agelyset skal kon-
verteres til en binær TTL værdi. Hvis der er et spændings-fald skal outputtet være 5 V og
outputtet skal være 0 V hvis der ikke er et spændings-fald.
Spændings-faldet over effektm˚alings-modstandende for bremselyset skal via kredsløbet kunne
outputte 3 forskellige spændings værdier alt efter om der er: en, to eller nul pære der virker.
Hvis spændings faldet er 0 mV skal outputtet være 5,650 V hvis spændingsfaldet er 90 mV
skal outputtet være 5,785 V og hvis spændingsfaldet er 180 mV skal outputtet være 5,930
V.
Spændingsfaldet over effektm˚alingsmodstande for venstre- og højre kørelys skal via kred-
sløbet outputte 7 forskellige spændinger alt efter om der er en,to eller tre pære der defekte
i venstre- eller højere kørelys. De forventet 7 tilfælde kan ses i Tabel E.5 p˚a side 121.
Funktionsdygtige pære ∆V Venstre ∆V Højer Forventet output
3 pære venstre, 0 pære højre 60 mV 0 V 2,730 V
3 pære venstre, 1 pære højre 60 mV 20 mV 2,653 V
3 pære venstre, 2 pære højre 60 mV 40 mV 2,577 V
3 pære venstre, 3 pære højre 60 mV 60 mV 2,500 V
2 pære venstre, 3 pære højre 40 mV 60 mV 2,423 V
1 pære venstre, 3 pære højre 20 mV 60 mV 2,347 V
0 pære venstre, 3 pære højre 0 V 60 mV 2,270 V
Tabel E.1: forskellige tilstande effekt m˚alingen p˚a køre lyset kan antage
M˚aleprocedure
Det et DC spændingsfald p˚atrykkes en effektm˚alingsmodstande og spændings m˚aling p˚a
udgangen af kredsløbet via et volt meter. For at sikere sig at kredsløbet ikke osilere skal
119

udgangs signalet desuden tjekkes med et oscilloskope. M˚aleopstillingen kan ses p˚a Figur D.1
p˚a side 117 og skal udføres p˚a 5 kredsløb for samtlige tilstande.
Udstyrsliste
Spændings-
generator
M˚aleresultater
Spændings-
forsyning
Effektmåler
Oscilloskop
Voltmeter
Figur E.1: M˚aleopstilling for verificering af effektm˚aling
Apparat Fabrikant AAU nummer
Spændingsgenerator HQPower suply PS3020 43685
Oscilloskop Agilent 54621A 33847
Voltmeter Fluke 37 08520
Spændingsforsyning Hameg HM7042 33886
Tabel E.2: Apparater anvendt under m˚alingerne af Analog Output
Resultat fra test af effektm˚aling p˚a blinklys og t˚agelys
pære tilstand M˚alt output Forventet output
venstre blinklys Fungerende 5,03 V 5 V
Højer blinklys Fungerende 5 V
T˚agelys Fungerende 5 V
venstre blinklys Defekt 0,37 V 0 V
Højer blinklys Defekt 0 V
T˚agelys Defekt 0 V
Tabel E.3: Resultat tabel fra test af effektm˚aling p˚a blinklys og t˚agelys
Resultat fra test af effektm˚aling p˚a bremselys
120

Indgang ∆V indgang output
Stoplys med to fungerende pære 180 mV 6,11 V
Stoplys med en fungerende pære 90 mV 5,95 V
Stoplys med nul fungerende pære 0 mV 5,79 V
Tabel E.4: Resultat tabel fra test af effektm˚aling p˚a bremselyset
Resultat fra test af effektm˚aling kørelys
Funktionsdygtige pære ∆V Venstre ∆V Højer M˚alt output Forventet output
3 pære venstre, 0 pære højre 60 mV 0 V 2,935 V 2,730 V
3 pære venstre, 1 pære højre 60 mV 20 mV 2,802 V 2,653 V
3 pære venstre, 2 pære højre 60 mV 40 mV 2,649 V 2,577 V
3 pære venstre, 3 pære højre 60 mV 60 mV 2,519 V 2,500 V
2 pære venstre, 3 pære højre 40 mV 60 mV 2,395 V 2,423 V
1 pære venstre, 3 pære højre 20 mV 60 mV 2,244 V 2,347 V
0 pære venstre, 3 pære højre 0 V 60 mV 2,107 V 2,270 V
Tabel E.5: Resultat tabel fra test af effektm˚aling p˚a kørelys
121

Test 1:
BILAGF
Accepttest for m˚alesystem
M˚alesystemet kobles til anhænger stik hvor der p˚atrykkes en spænding p˚a 10 V p˚a pol
1,2,4,5,6,7. Hvis m˚alesystemet m˚aler en spænding disse 6 poler kan krav M1 verificeres.
Test af krav M1 Tjek
M˚ales en spænding p˚a pol 1
M˚ales en spænding p˚a pol 2
M˚ales en spænding p˚a pol 4
M˚ales en spænding p˚a pol 5
M˚ales en spænding p˚a pol 6
M˚ales en spænding p˚a pol 7
Tabel F.1: Resusltat fra test 1
M˚alesystemet overholder p˚a baggrund af denne test ikke krav M1
Test 2:
M˚alesystemet kobles til anhængerstikket og trailerstik. En spænding p˚a 12 V p˚atrykkes
mellem pol 6 og stel p˚a anhængerstikket. To 21 W pære tilkoblets parallelt mellem pol 6 og
stel p˚a trailerstikket. En effekt m˚aling foretages, hvis m˚alesystemet kan registere en ændring
hvis først en pære og dernæst begge pære fjernes er krav M2 eftervist.
Test af krav M2 Tjek
M˚ales der et effekt resultat for to pære?
Giver kun en pære et nyt resultat?
Giver nul pære et nyt resultat?
Tabel F.2: Resultat fra test 2
M˚alesystemet overholder p˚a baggrund af denne test krav M2
Test 3:
M˚alesystemet kobles til anhængerstikket og trailerstik. En spænding p˚a 12 V p˚atrykkes fra
pol 5 til stel og fra pol 7 til stel p˚a anhængerstikket. tre 5 W pære tilkoblets parallelt hen-
holdsvist mellem pol 5 og stel og pol 7 og stel p˚a trailerstikket. En effektforskels m˚aling fore-
122

tages. Med 6 pære kan effektforskels m˚aling antage 7 forskellige værdier, hvis m˚alesystemet
kan registrere disse 7 forskellige værdier er Krav M3 efterviset, hvilket ogs˚a verificere krav
M9 da m˚alesystemet skal være kompatibelt med anhængerstikket og trailerstik for at testen
kan udføres.
Test af krav M3 og krav M9 Tjek
M˚ales der et resultat for 0 pære mellem pol 5 og stel og 3 pære
mellem pol 7 og stel?
Nyt resultat for 1 pære mellem pol 5 og stel og 3 pære mellem pol
7 og stel?
Nyt resultat for 2 pære mellem pol 5 og stel og 3 pære mellem pol
7 og stel?
Nyt resultat for 3 pære mellem pol 5 og stel og 3 pære mellem pol
7 og stel?
Nyt resultat for 2 pære mellem pol 5 og stel og 2 pære mellem pol
7 og stel?
Nyt resultat for 2 pære mellem pol 5 og stel og 1 pære mellem pol
7 og stel?
Nyt resultat for 2 pære mellem pol 5 og stel og 0 pære mellem pol
7 og stel?
Tabel F.3: Resultat fra test 3
M˚alesystemet overholder p˚a baggrund af denne test krav M3 og krav M9
Test 4:
M˚alesystemet kobles til anhængerstikket og trailerstik. Vinkelm˚aleren p˚amonteres traileren.
og outputtet fra vinkelm˚aleren aflæses. For at krav M4 kan verificeres skal frekvensen af disse
m˚alinger være 142 og for at verificere krav M5 skal opløsning være p˚a 2 ◦ og en nøjagtighed
p˚a ± 2 ◦ . dette testes ved at m˚aling p˚a 30 ◦ og en m˚aling p˚a 32 ◦ .
Test af krav M4 og krav M5 Tjek
Er resultatet m˚alingen for ved 30 ◦ mellem 28 ◦ og 32 ◦ og bliver
der tager 142 m˚alinger pr sek.
Er resultatet m˚alingen for ved 32 ◦ mellem 30 ◦ og 34 ◦ og bliver
der tager 142 m˚alinger pr sek.
Tabel F.4: Resultat fra test 4
Krav M4 og krav M5 kan ikke verificeres da vinkelm˚aleren ikke er funkionsdygtig.
Test 5:
Formidlingssystemet kobles til m˚alesystemet via Bluetooth. Hvis Formidlingssystemet mod-
tager en case med information om lyssignalerne og information om den aktuelle vinkel og
vinkelhastighed. Denne test vil verificere krav M6 og krav M7
123

Test af krav M6 og krav M7 Tjek
Modtager formidlingssystemet information om lyssignalerne
Modtager formidlingssystemet information om den aktuelle vinkel
og vinkelhastighed
Tabel F.5: Resultat fra test 5
Krav M6 og Krav M7 kan ikke verificeres da den tr˚adløse komunikation ikke er funkions-
dygtig.
Test 6:
Konstater at det er blevet brugt Verdex pro XM4-bt motherboard, med Audiostix2 lydkort
som platform i m˚alesystemet. Denne test verificere krav M8
Test af krav M8 Tjek
Er Verdex pro XM4-bt motherboard brugt
Er Audiostix2 lydkort brugt
Tabel F.6: Resultat fra test 6
M˚alesystemet overholder p˚a baggrund af denne test Krav M8
124

Test 1:
BILAGG
Accepttest for formidlingssystemet
Til formidlingsystemet er der en række af formelle krav, s˚asom at programmet skal laves i
Java med mere. Disse krav vil der i denne første test blive taget stilling til, hvorvidt de er
overholdt.
Test af krav F1, F3, F11, F12, F13, F14, F15 og F16 Tjek
Anvendes Blue tooth til overførsel af signaler
Advares brugeren auditivt om kollisionsfarer
Er der figurer, symboler og tekst p˚a brugerfladen
Er kontrasten mellem figur og grund høj
Er programmet lavet i Java
Funktion som oversætter de modtagne cases til information til
brugeren.
Funktion som opdaterer brugerfladen n˚ar ny information er
tilgængelig.
Funktion som beregner hvorn˚ar brugeren skal advares om kollisionsfarer.
Tabel G.1: Resusltat fra test 1
Formidlingssystemet overholder p˚a baggrund af denne test kun krav F1, F11, F12 og F13.
Test 2:
M˚alesystemet sættes til mellem bilens og trailerens stik og der sættes strøm til. Ved initiering
af Trailerhjælper-programmet skal dette automatisk oprette forbindelse til til m˚alessystemet.
Hvis forbindelse opn˚aes vil et lystjek autmatisk blive startet og hermed vil krav F2 blive
verificeret.
Test af krav F2 Tjek
Startes lystjek automatisk ved programmets start
Tabel G.2: Resultat fra test 2
Formidlingssystemet overholder p˚a dette tidspunkt ikke krav F2
Krav F4 til F10 handler alle om det auditive signal ved kollisionsalarm-delen. P˚a dette
tidspunkt er der desværre endnu ikke valgt nogen specifik lyd og derfor kan disse tests ikke
udføres.
125

BILAGH
Accepttest af Trailerhjælper
Form˚alet med denne Accepttest er at verificere hvorvidt Trailerhjælper systemet overholder
der opstillet krav for systemet. Krav 3 vil ikke blive testet da det er et produktionsmessit
krav som ikke vil blive eftervist via den fremstillet prototype.
Test 1:
Montér trailerhjælper s˚adan at systemet er klar til at udføre lystjek og kollisionsalarm. Fra
at verificere krav 1 og krav 2 skal systemet ikke kræve konstruktionsmæssige ændringer i bil
eller trailer og systemet skal være monteres mellem bilens stik og trailerens stik.
Test 2:
Test af krav 1 og krav 2 Tjek
Kan systemet monteres uden konstruktionsmæssige ændringer i
bil eller trailer
Kan systemet monteres mellem bilens stik og trailerens stik
Tabel H.1: Resultat fra test 1
Montér Trailerhjælper s˚adan at systemet er klar til at udføre lystjek, Trailerhjælper pro-
grammet startes p˚a en mobiltelefon og en Bluetooth forbindelse mellem mobiltelefon og
m˚alesystemet oprettes. Hvis en visuelt illustration og en skriftlig forklaring af om trailerns
lys fremkommer p˚a skærmen, og denne illustration svare til virkeheden kan krav 4, 5, 7,
8, 10 verificeres. Efterfølgende fremprovokeres i fejl i elnettet hvis denne spicifike fejl bliver
indiceret p˚a mobilens skærm kan krav 9 verificeres. Testen afsluttes med at spænding fra
bilen afbrydes, hvis systemet stopper med at udføre lystjek kan krav 6 verificeres.
Test af krav 4, 5, 6, 7, 8, 10 Tjek
Kan en Bluetooth forbindelse mellem mobiltelefonen og
m˚alesystemet oprettes
Fremkommer en visuel illustration og en skriftlig forklaring af om
trailernes lys p˚a skærmen
Svare illustration lysene p˚a skærmen til den faktiske tilstand p˚a
traileren
F˚ar en ny fejl opdateret p˚a skærmen
Stopper lystjek n˚ar spændingen afbrydes
Tabel H.2: Resultat fra test 2
126

Test 3:
Montér Trailerhjælper s˚adan at systemet er klar til at give en kollisionsalarm. Kolision-
salarmen testes ved to bakkehastigheder for at tjekke om den afstand der gives ændre sig i
forholdt til hastigheden. Kolisions alarmen aktiveres p˚a mobiltelefonen og en fare for kollision
fremprovokeres. Krav 11 , 13, 14, 15 kan verificers hvis mobiltelefonen afspiller en alarm tids
nok til at kollisionen kan afværges. Hvis tiden for hvorn˚ar kollisions alarmen lyder tilpasser
sig til bakkehastigheden og vinkelaccelerationen, kan krav 12 verificeres.
Test af krav 11 , 12, 13, 14, 15 Tjek
Afspilles alarmen tidsnok til en kollision kan afværges
Afspilles alarmen tidligere ved en øget hastighed s˚adan at en kollision
stadig kan afværges
Er Information om afstanden til en kollision mellem bil og trailer
tilgængelig via mobiltelefonen
Tabel H.3: Resultat fra test 3
127

I.1 Introduktion til testpersonen
BILAGI
Koncepttest
Tak fordi du vil være med. Hele testen varer cirka 15 min. og til sidst er der lige nogle
spørgsm˚al du skal svare p˚a. Husk det er produktet vi tester og ikke dig s˚a sig endelig til hvis
du er i tvivl undervejs, og du kan til hver en tid afbryde testen hvis du føler dig utilpas med
situationen. Før du introduceres til produktet som testen egentlig omhandler vil vi gerne
have du lige foretager et lystjek p˚a denne trailer p˚a denne bil og tester om alle lysene virker.
Vi vil sætte tænding p˚a bilen n˚ar du er klar til at teste lysene. Du m˚a meget gerne tale højt
om hvad du foretager dig.
(Manuelt lystjek)
Produktet er en alternativ m˚ade at foretage lystjekket p˚a. Det best˚ar at denne boks som skal
sættes mellem bilens anhængerstik og trailerens stik. Boksen sender status for hver element
til mobiltelefonen.
Inden vi g˚ar i gang med opgaverne skal du lige montere boksen mellem bilens og trailerens
stik.
Du vil blive stillet nogle opgaver med dette produkt.
N˚ar lystjekket aktiveres udfører systemet automatisk status p˚a alle lysene og forbindelserne,
og om det virker kan ses p˚a skærmen.
Hvis systemet melder tilbage med en fejl skal du konstatere om der er fejl i stikket eller p˚a
hvilke lys der er fejl, og hvis muligt, rette denne fejl. Hvis du mener du har rettet fejlen vil
status p˚a dette sted, kort efter, ændres p˚a mobiltelefonen. Du m˚a stadig meget gerne tale
højt om hvad du foretager dig. Du skal nu foretage et lystjek
(Indlæringscase køres)
Systemet foretager løbende tests p˚a systemet, s˚a skulle der opst˚a fejl under køreturen kan
disse hurtigt ses og dermed rettes af føreren. Du vil nu blive udsat for nogle af de forskellige
situationer der kan opst˚a.
(Opgaverne gennemg˚aes)
Det var det. Her til slut har vi lige lidt spørgsm˚al som vi gerne vil have at du svarer p˚a.
(interview gennemføres)
128

I.2 Interview af testperson
N˚ar testpersonerne har udført opgaverne, vil der foretages et interview med form˚al at f˚a
testpersonernes tanker om konceptet og brugerfladen, s˚a disse eventuelt kan anvendes under
videreudviklingen af systemet. Hvis ikke brugerfladen formidler det tiltænkte, og brugeren
dermed f˚ar problemer med at anvende systemet, skal disse forklares s˚a designet af bruger-
fladen kan tages op til revision.
I.2.1 spørgsm˚al
Nu hvor du har lavet lystjekket kar vi lige nogle spørgsm˚al
• Hvordan synes du det gik med at tjekke lysene uden systemet? (D˚arligt/Okay/godt)
• Fik du tjekket alle lysene under dette tjek? (Ja/Nej)
• Er der noget du ville have gjort anderledes? (Ja/nej)
Nu hvor du har gennemført testen, kunne vi godt tænke os, at stille dig nogle spørgsm˚al om
testen men ogs˚a om konceptet.
• Hvordan synes du det gik med at tjekke lysene med systemet? (Meget godt/Godt/Okay/D˚arligt/Meget
d˚arligt)
• Hvordan vurderer du lystjekkene i forhold til hinanden? Her menes der tid og sværheds-
grad (Kommentar)
• Hvad synes du om konceptet, at gøre det mindre besværligt for brugeren at tjekke
lysene p˚a traileren? (D˚arlig idé/Okay/God idé)
• Du lavede b˚ade lys-tjekket uden og med systemet, hvilket synes du var mest besværligt?
(uden er meget besværligere/uden er lidt mere besværligt/Ingen forskel p˚a de to/Sys-
temet er lidt mere besværligt/Systemet er meget besværligere)
• Vi observerede at der var lidt problemer her, (jævnfør noter), vil du forklare hvad der
var ˚arsagen til problemet? (Kommentar)
• Ville du bruge systemet hvis du havde det til r˚adighed? (Kommentar)
• Hvis du skulle ændre p˚a noget ved systemet, hvad ville du s˚a ændre p˚a? (Kommentar)
I.3 Besvarelser af ˚abne spørgsm˚al
De tre ˚abne spørgsm˚al blev kommenteret p˚a, p˚a følgende m˚ader:
Spørgsm˚al 5: Hvordan vurderer du lystjekkene i forhold til hinanden? Her menes
der tid og sværhedsgrad.
129

Pilot: Til tider kunne det være svært at anvende systemet, da det kan være svært at finde
ud af hvordan problemerne løses, dog er det noget nemmere hvis man er alene og skal
foretage tjekket.
Testperson 1: Systemet skulle kunne opdatere noget hurtigere, s˚a synes det var en anelse mere
besværligt.
Testperson 2: Synes at systemet er lidt mere besværligt og tidskrævende, da tillid til systmet ikke
er der.
Testperson 3: Synes systemet var tidsbesparende, da tjekket er muligt at lave uden en anden person
tilstede.
Testperson 4: Det var nemmere, at foretage lystjekket med systemet, men informationerne p˚a dis-
playet var lidt forvirrende.
Testperson 5: Systemet er klart hurtigst
Spørgsm˚al 8: Vi observerede at der var lidt problemer her, vil du forklare hvad
der var ˚arsagen til problemet?
Pilot: Katastrofeblinket blev aktiveret for at tjekke om blinklysene fungerede korrekt. Test-
personen vidste ikke, at dette ikke tjekkede hvorvidt trailerstikket var vendt forkert.
Testperson 1: Ingen problemer observeret!
Testperson 2: Ingen problemer observeret!
Testperson 3: Katastrofeblinket blev aktiveret for at tjekke om blinklysene fungerede korrekt. Test-
personen vidste ikke, at dette ikke tjekkede hvorvidt trailerstikket var vendt forkert.
Testperson 4: Glemte at tjekke bremselysene, og forklarede at dette vist ikke var første gang hun
blemte de bremselysene.
Testperson 5: Katastrofeblinket blev tændte for at tjekke blinklysene, vidste ikke at stikket kunne
vendes forkert.
Spørgsm˚al 10: Hvis du skulle ændre ˚a noget ved systemet, hvad ville du s˚a ændre
p˚a?
Pilot: Til novicer kunne der være lidt bedre forlag om hvordan fejlene kunne udbedres samt
mere informationsgivende tekst p˚a displayet.
Testperson 1: Vil gerne have en lyd, der notificerer n˚ar der opst˚ar en fejl og at systemet opdaterer
hurtigere.
Testperson 2: Hurtigere opdatering
Testperson 3: Det ville være smart, at integrere systemet i en GPS i stedet, for mobiltelefonen.
Testperson 4: Kunne godt tænke sig, at PDA blev brugt til at formidle med, i stedet for mobil-
telefonen. Desuden ville det være en fordel hvis der var en stemme p˚a, ligesom p˚a en
GPS.
130

Testperson 5: Mobiltelefonen ligger i lommen, s˚a med en GPS eller skærm i bilen ville hjælpe rigtig
meget.
131

J.1 Kildekode
J.1.1 TrailerGUI.java
1 package t r a i l e r . g u i ;
2
3 import j a v a . i o . IOException ;
4 import j a v a . u t i l . Vector ;
5
6 import javax . m i c r o e d i t i o n . l c d u i . Command ;
7 import javax . m i c r o e d i t i o n . l c d u i . CommandListener ;
8 import javax . m i c r o e d i t i o n . l c d u i . D i s p l a y ;
9 import javax . m i c r o e d i t i o n . l c d u i . D i s p l a y a b l e ;
10 import javax . m i c r o e d i t i o n . l c d u i . Form ;
11 import javax . m i c r o e d i t i o n . l c d u i . Image ;
12 import javax . m i c r o e d i t i o n . l c d u i . ImageItem ;
13 import javax . m i c r o e d i t i o n . m i d l e t . MIDlet ;
14 import javax . m i c r o e d i t i o n . m i d l e t . MIDletStateChangeException ;
15
16 import t r a i l e r . t o o l s . ImageTools ;
17 import t r a i l e r . t o o l s . AnimationBlock ;
18
BILAGJ
Kildekode
19 public c l a s s TrailerGUI extends MIDlet implements Runnable , CommandListener {
20 private D i s p l a y d i s p l a y ;
21 private Form trailerGUIFrm ; // The main form
22 private Command exitCmd ; // Command to e x i t t h e MIDlet
23 // p r i v a t e Command errorOneCmd , errorTwoCmd , errorThreeCmd ; // e r r o r commands
24 private Command connectCmd1 ; // animation commands #1
25 private Command connectCmd2 ; // animation commands #2
26 private Command connectCmd3 ; // animation commands #3
27 private Command connectCmd4 ; // animation commands #4
28 private Command connectCmd5 ; // animation commands #5
29 private Command connectCmd6 ; // animation commands #6
30
31 private Image t r a i l e r I m g ;
32 private ImageItem t r a i l e r I m g I t e m ;
33
34 /∗∗
35 ∗ 1 = Not t e s t e d
36 ∗ 2 = OK
37 ∗ 3 = Error
38 ∗/
39 private int [ ] imageTypes = {1 , 1 , 1 , 1 , 1 , 1 } ; // i n i t i a l s t a t e o f images
40
41 private AnimationBlock [ ] animation ; // animation s c r i p t
42
43 public TrailerGUI ( ) {
44 d i s p l a y = D i s p l a y . g e t D i s p l a y ( t h i s ) ;
45 i n i t i a l i z e T r a i l e r A p p ( ) ;
46 }
47
48 protected void destroyApp ( boolean u n c o n d i t i o n a l ) throws MIDletStateChangeException {
49
132

50 }
51
52 protected void pauseApp ( ) {
53
54 }
55
56 protected void startApp ( ) throws MIDletStateChangeException {
57 d i s p l a y . s e t C u r r e n t ( trailerGUIFrm ) ;
58 }
59
60 /∗∗
61 ∗ I n i t i a l i z e s commands and form
62 ∗/
63 private void i n i t i a l i z e T r a i l e r A p p ( ) {
64 exitCmd = new Command( ” Exit ” ,
65 ” Exit t r a i l e r a p p l i c a t i o n ” ,
66 Command . EXIT ,
67 1 ) ;
68
69 connectCmd1 = new Command( ” S t a r t 1 ” , ” Forbind t i l t r a i l e r ” , Command .SCREEN, 2 ) ;
70 connectCmd2 = new Command( ”” , ” Forbind t i l t r a i l e r ” , Command .SCREEN, 2 ) ;
71 connectCmd3 = new Command( ” S t a r t 2 ” , ” Forbind t i l t r a i l e r ” , Command .SCREEN, 2 ) ;
72 connectCmd4 = new Command( ” S t a r t 3 ” , ” Forbind t i l t r a i l e r ” , Command .SCREEN, 2 ) ;
73 connectCmd5 = new Command( ” S t a r t 4 ” , ” Forbind t i l t r a i l e r ” , Command .SCREEN, 2 ) ;
74 connectCmd6 = new Command( ” S t a r t 5 ” , ” Forbind t i l t r a i l e r ” , Command .SCREEN, 2 ) ;
75
76 trailerGUIFrm = new Form ( ” T r a i l e r D i a g n o s t i c s ” ) ;
77
78 trailerGUIFrm . addCommand( connectCmd2 ) ;
79 trailerGUIFrm . addCommand( connectCmd1 ) ;
80 trailerGUIFrm . addCommand( connectCmd3 ) ;
81 trailerGUIFrm . addCommand( connectCmd4 ) ;
82 trailerGUIFrm . addCommand( connectCmd5 ) ;
83 trailerGUIFrm . addCommand( connectCmd6 ) ;
84 trailerGUIFrm . addCommand( exitCmd ) ;
85
86 trailerGUIFrm . setCommandListener ( t h i s ) ;
87 try {
88 t r a i l e r I m g = Image . c r e a t e I m a g e ( ”/ images /Gui7 . jpg ” ) ;
89
90 i n i t i a l i z e I m a g e ( null ) ;
91 trailerGUIFrm . append ( t r a i l e r I m g I t e m ) ;
92 } catch ( IOException e ) {
93 System . e r r . p r i n t l n ( ” Unable to l o c a t e or read image f i l e ” ) ;
94 }
95 }
96
97 public void commandAction (Command c , D i s p l a y a b l e d ) {
98 i f ( c . e q u a l s ( exitCmd ) ) {
99 try {
100 destroyApp ( true ) ;
101 n o t i f y D e s t r o y e d ( ) ;
102 } catch ( MIDletStateChangeException msce ) {
103 System . e r r . p r i n t l n ( ” Error e x i t i n g a p p l i c a t i o n : ” + msce . getMessage ( ) ) ;
104 }
105
106 } e l s e i f ( c . e q u a l s ( connectCmd1 ) ) {
107 showAnimation1 ( ) ;
108 } e l s e i f ( c . e q u a l s ( connectCmd2 ) ) {
109 showAnimation2 ( ) ;
110 } e l s e i f ( c . e q u a l s ( connectCmd3 ) ) {
111 showAnimation3 ( ) ;
112 } e l s e i f ( c . e q u a l s ( connectCmd4 ) ) {
113 showAnimation4 ( ) ;
114 } e l s e i f ( c . e q u a l s ( connectCmd5 ) ) {
115 showAnimation5 ( ) ;
116 } e l s e i f ( c . e q u a l s ( connectCmd6 ) ) {
133

117 showAnimation6 ( ) ;
118 }
119 }
120
121 public void run ( ) {
122 try {
123 int c u r r e n t P o s i t i o n = 0 ;
124 Vector t e x t = new Vector ( ) ;
125 while ( true ) {
126 i f ( c u r r e n t P o s i t i o n == animation . l e n g t h ) {
127 break ;
128 }
129
130 Thread . s l e e p ( animation [ c u r r e n t P o s i t i o n ] . getDelay ( ) ) ;
131 imageTypes [ animation [ c u r r e n t P o s i t i o n ] . g e t P o s i t i o n ( ) − 1 ] = animation [ c u r r e n t P o s i t i o n ] . getImageType (
132 i f ( animation [ c u r r e n t P o s i t i o n ] . getText ( ) != null ) {
133 t e x t . addElement ( animation [ c u r r e n t P o s i t i o n ] . getText ( ) ) ;
134 }
135 i n i t i a l i z e I m a g e ( t e x t . s i z e ( ) == 0 ? null : t e x t ) ;
136 trailerGUIFrm . d e l e t e ( 0 ) ;
137 trailerGUIFrm . append ( t r a i l e r I m g I t e m ) ;
138 c u r r e n t P o s i t i o n ++;
139 }
140 } catch ( Exception ex ) {
141
142 }
143 }
144
145 private void showAnimation1 ( ) {
146 // r e s e t t i n g images
147 imageTypes = new int [ ] {1 , 1 , 1 , 1 , 1 , 1 } ;
148
149 // t e l l i n g which images should be updated and when
150 animation = new AnimationBlock [ ] {
151 new AnimationBlock ( 1 , 2000 , 2 , null ) ,
152 new AnimationBlock ( 2 , 1000 , 2 , null ) ,
153 new AnimationBlock ( 3 , 1000 , 2 , null ) ,
154 new AnimationBlock ( 4 , 2000 , 1 , ” Højre b l i n k l y s har i k k e været a k t i v e r e t . A k t i v é r d e t t e ved at b l i n k e
155 //new AnimationBlock (4 , 0000 , 1 , ” ta ”) ,
156 //new AnimationBlock (5 , 1000 , 2 , n u l l ) ,
157 new AnimationBlock ( 5 , 2000 , 1 , ” Venstre b l i n k l y s har i k k e været a k t i v e r e t . A k t i v é r d e t t e ved at b l i n k e
158 new AnimationBlock ( 5 , 1000 , 1 , ” Bremselysene har i k k e været a k t i v e r e t . A k t i v é r d e t t e ved at træde p˚a
159 } ;
160 Thread t = new Thread ( t h i s ) ;
161
162 // s t a r t i n g animation thread
163 t . s t a r t ( ) ;
164 }
165 private void showAnimation2 ( ) {
166 // r e s e t t i n g images
167 imageTypes = new int [ ] {1 , 1 , 1 , 1 , 1 , 1 } ;
168
169 // t e l l i n g which images should be updated and when
170 animation = new AnimationBlock [ ] {
171 new AnimationBlock ( 1 , 0000 , 2 , null ) ,
172 new AnimationBlock ( 2 , 0000 , 2 , null ) ,
173 new AnimationBlock ( 3 , 0000 , 2 , null ) ,
174 new AnimationBlock ( 4 , 0000 , 2 , null ) ,
175 //new AnimationBlock (5 , 1000 , 2 , n u l l ) ,
176 new AnimationBlock ( 5 , 1000 , 2 , ” Alt l y s f u n g e r e r k o r r e k t ” )
177 } ;
178 Thread t = new Thread ( t h i s ) ;
179
180 // s t a r t i n g animation thread
181 t . s t a r t ( ) ;
182 }
183 private void showAnimation3 ( ) {
134

184 // r e s e t t i n g images
185 imageTypes = new int [ ] {1 , 1 , 1 , 1 , 1 , 1 } ;
186
187 // t e l l i n g which images should be updated and when
188 animation = new AnimationBlock [ ] {
189 new AnimationBlock ( 1 , 2000 , 2 , null ) ,
190 new AnimationBlock ( 2 , 1000 , 2 , null ) ,
191 new AnimationBlock ( 3 , 1000 , 2 , null ) ,
192 new AnimationBlock ( 4 , 2000 , 3 , ” Højre b l i n k l y s v i r k e r i k k e ” ) ,
193 //new AnimationBlock (5 , 1000 , 2 , n u l l ) ,
194 new AnimationBlock ( 5 , 1000 , 2 , null )
195 } ;
196 Thread t = new Thread ( t h i s ) ;
197
198 // s t a r t i n g animation thread
199 t . s t a r t ( ) ;
200 }
201 private void showAnimation4 ( ) {
202 // r e s e t t i n g images
203 imageTypes = new int [ ] {1 , 1 , 1 , 1 , 1 , 1 } ;
204
205 // t e l l i n g which images should be updated and when
206 animation = new AnimationBlock [ ] {
207 new AnimationBlock ( 1 , 2000 , 2 , null ) ,
208 new AnimationBlock ( 2 , 1000 , 2 , null ) ,
209 new AnimationBlock ( 3 , 1000 , 3 , ” Venstre s i d e : Et l y s v i r k e r i k k e ( enten p o s i t i o n s −,” ) ,
210 new AnimationBlock ( 3 , 0000 , 3 , ” køre− e l l e r nummerpladelys ) ” ) ,
211 new AnimationBlock ( 4 , 1000 , 2 , null ) ,
212 // new AnimationBlock (5 , 1000 , 2 , n u l l ) ,
213 new AnimationBlock ( 5 , 1000 , 3 , null )
214 } ;
215 Thread t = new Thread ( t h i s ) ;
216
217 // s t a r t i n g animation thread
218 t . s t a r t ( ) ;
219 }
220 private void showAnimation5 ( ) {
221 // r e s e t t i n g images
222 imageTypes = new int [ ] {1 , 1 , 1 , 1 , 1 , 1 } ;
223
224 // t e l l i n g which images should be updated and when
225 animation = new AnimationBlock [ ] {
226 new AnimationBlock ( 1 , 2000 , 2 , null ) ,
227 new AnimationBlock ( 2 , 1000 , 2 , null ) ,
228 new AnimationBlock ( 3 , 1000 , 2 , null ) ,
229 new AnimationBlock ( 4 , 2000 , 3 , ” Ét b r e m s e l y s v i r k e r i k k e ” ) ,
230 //new AnimationBlock (5 , 1000 , 2 , n u l l ) ,
231 new AnimationBlock ( 5 , 0500 , 3 , null )
232 } ;
233 Thread t = new Thread ( t h i s ) ;
234
235 // s t a r t i n g animation thread
236 t . s t a r t ( ) ;
237 }
238
239 private void showAnimation6 ( ) {
240 // r e s e t t i n g images
241 imageTypes = new int [ ] {1 , 1 , 1 , 1 , 1 , 1 } ;
242
243 // t e l l i n g which images should be updated and when
244 animation = new AnimationBlock [ ] {
245 new AnimationBlock ( 1 , 2000 , 3 , null ) ,
246 new AnimationBlock ( 2 , 1000 , 3 , null ) ,
247 new AnimationBlock ( 3 , 1000 , 3 , null ) ,
248 new AnimationBlock ( 4 , 1000 , 3 , ” Løs f o r b i n d e l s e i s t i k ” ) ,
249 // new AnimationBlock (5 , 1000 , 3 , n u l l ) ,
250 new AnimationBlock ( 5 , 1000 , 3 , ”Tag s t i k k e t ud og sæt det i i g e n ” )
135

251 } ;
252 Thread t = new Thread ( t h i s ) ;
253
254 // s t a r t i n g animation thread
255 t . s t a r t ( ) ;
256 }
257
258 private void i n i t i a l i z e I m a g e ( Vector t e x t ) {
259 t r a i l e r I m g I t e m = new ImageItem (
260 null ,
261 ImageTools . c r e a t e T r a i l e r W i t h I m a g e s ( t r a i l e r I m g , imageTypes , d i s p l a y . numAlphaLevels ( ) >= 2 , text , 12 , 3
262 ImageItem .LAYOUT DEFAULT,
263
264 null
265 ) ;
266 }
267 }
J.1.2 AnimationBlock.java
1 package t r a i l e r . t o o l s ;
2
3 public c l a s s AnimationBlock {
4 /∗∗
5 ∗ The p o s i t i o n o f t h e image to ”animate”
6 ∗ 1 : car
7 ∗ 2 : f r o n t r i g h t
8 ∗ 3 : f r o n t l e f t
9 ∗ 4 : back r i g h t
10 ∗ 5 : back middle
11 ∗ 6 : back l e f t
12 ∗/
13 private int p o s i t i o n ;
14
15 /∗∗
16 ∗ The d e l a y b e f o r e t h i s animation b l o c k i s to be executed − s e t in m i l i s e c o n d s
17 ∗/
18 private long d e l a y ;
19
20 /∗∗
21 ∗ The type o f image to show
22 ∗ 1 = Not t e s t e d
23 ∗ 2 = OK
24 ∗ 3 = Error
25 ∗/
26 private int imageType ;
27
28 /∗∗
29 ∗ The t e x t to show , i f at a l l − t h i s can be n u l l
30 ∗/
31 private S t r i n g t e x t ;
32
33 public AnimationBlock ( int p o s i t i o n , long delay , int imageType , S t r i n g t e x t ) {
34 t h i s . p o s i t i o n = p o s i t i o n ;
35 t h i s . d e l a y = d e l a y ;
36 t h i s . imageType = imageType ;
37 t h i s . t e x t = t e x t ;
38 }
39
40 public int g e t P o s i t i o n ( ) {
41 return p o s i t i o n ;
42 }
43
44 public long getDelay ( ) {
45 return d e l a y ;
46 }
136

47
48 public int getImageType ( ) {
49 return imageType ;
50 }
51
52 public S t r i n g getText ( ) {
53 return t e x t ;
54 }
55 }
J.1.3 ImageTools.java
1 package t r a i l e r . t o o l s ;
2
3 import j a v a . u t i l . Vector ;
4
5 import javax . m i c r o e d i t i o n . l c d u i . Font ;
6 import javax . m i c r o e d i t i o n . l c d u i . Graphics ;
7 import javax . m i c r o e d i t i o n . l c d u i . Image ;
8
9 public c l a s s ImageTools {
10 public s t a t i c f i n a l int ICON WIDTH = 4 8 ;
11 public s t a t i c f i n a l int ICON HEIGHT = 4 8 ;
12
13 public s t a t i c f i n a l int ICON Y PADDING = 6 ;
14
15 /∗∗
16 ∗
17 ∗ @param t r a i l e r I m a g e − t h e background image
18 ∗ @param imageTypes − an array o f s i z e 7 s p e c i f y i n g t h e icon type f o r each l o c a t i o n
19 ∗ @param width − t h e d e s i r e d width o f t h e f i n a l image
20 ∗ @param h e i g h t − t h e d e s i r e d h e i g h t o f t h e f i n a l image
21 ∗ @param supportsAlpha − i n d i c a t e s whether or not t h e phone s u p p o r t s alpha transparency
22 ∗ @return
23 ∗/
24 public s t a t i c Image c r e a t e T r a i l e r W i t h I m a g e s ( Image t r a i l e r I m a g e , int [ ] imageTypes , boolean supportsAl
25 int sourceWidth = t r a i l e r I m a g e . getWidth ( ) ;
26 int s o u r c e H e i g h t = t r a i l e r I m a g e . g e t H e i g h t ( ) ;
27
28 Image thumb = Image . c r e a t e I m a g e ( sourceWidth , s o u r c e H e i g h t ) ;
29 Graphics g = thumb . g e t G r a p h i c s ( ) ;
30
31 g . s e t C l i p ( 0 , 0 , sourceWidth , s o u r c e H e i g h t ) ;
32 g . drawImage ( t r a i l e r I m a g e , 0 , 0 , Graphics .LEFT | Graphics .TOP) ;
33
34 for ( int i = 0 ; i < 5 ; i ++) {
35 int x = 0 ;
36 int y = 0 ;
37 switch ( i ) {
38 case 0 :
39 x = 1 0 0 ;
40 y = 1 6 5 ;
41 break ;
42 case 1 :
43 x = 2 0 0 ;
44 y = 1 0 0 ;
45 break ;
46 case 2 :
47 x = 2 0 0 ;
48 y = 2 0 0 ;
49 break ;
50 case 3 :
51 x = 3 5 0 ;
52 y = 1 0 0 ;
53 break ;
54 // case 4 :
137

55 // x = 350;
56 // y = 165;
57 // break ;
58 case 4 :
59 x = 3 5 0 ;
60 y = 2 0 0 ;
61 break ;
62 }
63
64 y = y + ICON Y PADDING ;
65
66 g . s e t C l i p ( x , y , ICON WIDTH, ICON HEIGHT ) ;
67
68 try {
69 Image i c o n = null ;
70 switch ( imageTypes [ i ] ) {
71 case 1 : // i k k e t e s t e t
72 i c o n = Image . c r e a t e I m a g e ( ”/ images / warning 48 . png” ) ;
73 break ;
74 case 2 : // v i r k e r
75 i c o n = Image . c r e a t e I m a g e ( ”/ images / a c c e p t e d 4 8 . png” ) ;
76 break ;
77 case 3 : // f e j l
78 i c o n = Image . c r e a t e I m a g e ( ”/ images / c a n c e l 4 8 . png” ) ;
79 break ;
80 }
81
82 i f ( supportsAlpha ) {
83 int [ ] rgbData = new int [ICON WIDTH∗ICON HEIGHT ] ;
84 i c o n . getRGB ( rgbData , 0 , ICON WIDTH, 0 , 0 , ICON WIDTH, ICON HEIGHT ) ;
85
86 g . drawRGB( rgbData , 0 , ICON WIDTH, x , y , ICON WIDTH, ICON HEIGHT, true ) ;
87 } e l s e {
88 g . drawImage ( icon , x , y , Graphics .LEFT | Graphics .TOP) ;
89 }
90 } catch ( Exception ex ) {
91 System . e r r . p r i n t l n ( ” Error occured g e t t i n g i c o n [ ” + i + ” ] : ” + ex . getMessage ( ) ) ;
92 }
93 }
94
95 i f ( t e x t != null ) {
96 g . s e t C l i p ( 0 , 0 , sourceWidth , s o u r c e H e i g h t ) ;
97 Font f = Font . getFont ( Font . FONT STATIC TEXT, Font . STYLE PLAIN , Font . SIZE LARGE ) ;
98 g . setFont ( f ) ;
99 g . s e t C o l o r (0 x f f f f f f ) ;
100 for ( int i = 0 ; i < t e x t . s i z e ( ) ; i ++) {
101 g . drawString ( t e x t . elementAt ( i ) . t o S t r i n g ( ) , t e x t F i r s t X , t e x t F i r s t Y + ( i ∗ 1 6 ) , Graphics .LEFT | Graph
102 }
103 }
104
105 Image immutableThumb = Image . c r e a t e I m a g e ( thumb ) ;
106
107 return immutableThumb ;
108 }
109 }
138

139
BILAGK
Kredsløbsdiagram

140

Indholdsliste af bilag p˚a vedlagte CD
Bilag I - Datablade.
Bilag II - Java kode.
141