DEGREE PROJECT, IN DATATEKNIK , SECOND LEVEL STOCKHOLM, SWEDEN 2015
Schemaläggning av hissar vid prioritetsanrop
EN STUDIE I HANTERING AV
PRIORITETSANROP AV HISSAR PÅ SVENSKA SJUKHUS STYRDA AV NEAREST CAR
ALGORITHM
ELIN CLEMMEDSSON, CHRISTOFFER RÖDÖÖ
KTH ROYAL INSTITUTE OF TECHNOLOGY
Examensarbete inom datalogi, grundnivå, DD143X
Schemaläggning av hissar med prioritetsanrop
Handledare: Jeanette Hellgren Kotaleski Examinator: Örjan Ekeberg
May 8, 2015
Referat
I vårt moderna samhälle är tid viktigt. Teknik används på otaliga sätt för att ta oss snabbare från punkt A till punkt B. Syftet med denna rapport är att undersöka om man, på ett effektivt och givande sätt, kan implementera möjligheten för sjukhuspersonal att begära prioritet på ett hissanrop. Ett ordinarie hissystem har simulerats med en implementation av Nearest Car Algorithm, en algoritm som beräknar den bäst lämpade vagnen att svara på ett specifikt anrop utifrån distans mellan anropsvåning och vagn samt färdriktning. På denna algoritm har olika sätt att hantera prioritetsanrop gjorts för att se hur dessa påverkar trans- porttiden för både personer med prioritet och ordinarie pas- sagerare i hissen. Detta för att kunna bestämma om någon av dessa algoritmer är lämpliga att använda i praktiken.
Genomsnittstiden för prioritetsanrop visas vara väsentligt lägre i alla testade algoritmer och att de ordinarie anropen inte påverkas särskilt mycket. Dock konstateras att mer ge- nomgående tester bör utföras för att kunna dra en konkret slutsats om implementeringens effektivitet.
Abstract
In our modern society, time is important. Technology is used in countless ways to faster get us from one point to another. The purpose of this report is to inquire whether there is a way to implement an option for personnel at Swedish hospitals to claim priority on an elevator call, and to do this in an efficient way. An ordinary elevator sys- tem has been simulated with an implementation of Near- est Car algorithm, an algorithm which calculates the most suitable elevator car to serve a specific call considering the distance between the call floor and the car and the direc- tion. Along with this algorithm, different ways to handle priority calls has been implemented to see how they affect the mean transport time for both passengers with priority and regular passengers in the elevator. This has been made to decide if any of these algorithms are suitable for using in practice. It is established that the mean time for pri- ority calls are substantially lower in all tested algorithms and that the ordinary calls mean time are not affected very much. However, it is stated that more thorough tests are required before a conclusion can be made about the imple- mentations effectivity.
Innehåll
1 Inledning 1
1.1 Syfte . . . 1
1.2 Problemformulering . . . 2
1.3 Ordförklaring . . . 2
1.3.1 Definition . . . 2
2 Bakgrund 3 2.1 Att anropa och välja mål . . . 3
2.1.1 Anrop följt av våningsval . . . 3
2.1.2 Anrop med målriktning följt av våningsval . . . 4
2.1.3 Anrop genom våningsval . . . 4
2.2 Multipla vagnar i samma schakt . . . 4
2.3 Fast utgångspunkt . . . 4
2.4 Zonsystem . . . 4
2.5 Tidsanpassat system . . . 5
2.6 The elevator algorithm . . . 5
2.7 Nearest Car Algorithm . . . 5
3 Metod 7 3.1 Litteraturstudie . . . 7
3.2 Testning . . . 7
3.2.1 Algoritm för simulering av ordinarie hisstrafik . . . 7
3.2.2 Algoritmer för prioritetsanrop . . . 8
3.2.3 Testfall . . . 9
3.2.4 Simulering . . . 9
3.2.5 Simuleringsmjukvara . . . 9
3.2.6 Tidmätning . . . 11
3.2.7 Testmiljö . . . 12
4 Resultat 13 4.1 Testresultat . . . 13
4.1.1 Närmaste vagn . . . 13
4.1.2 Närmaste vagn med specifik färdriktning . . . 14
4.1.3 Minst lastad vagn . . . 15 4.1.4 Vagn endast för prioritetsanrop . . . 16 4.2 Analys . . . 16
5 Diskussion 17
5.1 Problem och brister . . . 17 5.2 Svårigheter och förbättringar . . . 18 5.3 Slutsats . . . 18
Litteratur 21
Kapitel 1
Inledning
Hissar har sedan 1800-talet använts för att vertikalt transportera människor och gods [1]. På 1800-talet var hissar ofta ångdrivna och användes främst till att trans- portera gods i fabriker och gruvor. Trots hissens användning inom industrin förknip- pades den med stora säkerhetsrisker och var inte vanlig i andra sammanhang. En vändning skedde år 1853, då uppfinnaren Elisha Ortis presenterade en godshiss ut- rustad med en säkerhetsanordning vilken gjorde att vagnen inte föll om det bärande repet skulle brista [2]. Denna säkerhetsanordning skapade en växande tillförlitlighet bland allmänheten. Den tyske uppfinnaren Werner von Siemens byggde år 1880 den första elektriska hissen [2].
Genom åren har hisstekniken utvecklats. Till denna utveckling har både pro- grammering och konstruktion bidragit [3]. Denna utveckling är viktig eller nödvän- dig inom flera områden. Ett av dessa områden är sjukvården. På sjukhus används hissar för transport av personal, patienter och utrustning. Med detta hjälpmedel kan man spara tid och energi. Inom vården är tid en viktig aspekt, då människors hälsa är i fokus.
Vi vill med denna rapport undersöka hur man på ett effektivt sätt kan ge sjuk- huspersonal möjligheten att begära prioritet på ett hissanrop för att snabbare kunna ta sig till önskad våning. Samtidigt som detta möjliggörs vill vi även ta reda på hur den övriga hissdriften påverkas. Rapporten kommer att fokusera på svenska sjuk- hus. Ämnesvalet är intressant då det varken behövs mycket tid eller resurser för att implementera hantering av prioritetsanrop i hissar på svenska sjukhus om resulta- tet visas vara positivt. Inte heller behövs ombyggnationer eller liknande i ett redan existerande hissystem.
1.1 Syfte
Syftet med denna studie är att undersöka olika sätt att implementera möjligheten att göra prioritetsanrop på hissar på svenska sjukhus. Detta för att ta reda på om det går att finna en effektiv lösning för att möjliggöra prioritetbegäran till specifika hissanrop. Med effektivitet menas i denna rapport att förkorta väntetid
KAPITEL 1. INLEDNING
samt transporttid vid användning av hissar. Detta gäller både vid prioritetsanrop och ordinarie anrop. En bra algoritm för prioritetsanrop kommer således att i så liten mån som möjligt påverka de ordinarie passagerarna samtidigt som sjukhuspersonal på ett snabbt sätt kan nå sitt mål.
1.2 Problemformulering
• Kan sjukhuspersonal på ett effektivt sätt begära prioritet på hissanrop?
• Vilken algoritm för hantering av prioritetsanrop skapar minst fördröjning av ordinarie hisstrafik och effektiviserar personals anrop i ett system där Nearest car algorithm används och prioritetsanrop möjliggjorts?
1.3 Ordförklaring
Hiss Ett schakt med en eller flera vagnar Schakt Utrymmet en vagn färdas i
Vagn Transportenheten passageraren använder sig av
Hissystem Flera hissar i anslutning till varandra vilka styrs tillsammans av en dator Passagerare En person som använder eller ska använda en hiss
Start Våningen där anropet till hissen gjorts Mål Passagerarens önskade våning att nå
Anrop Signal från passagerare att denne vill använda hissen
Väntetid Tiden från passagerarens anrop till dess att vagnen når startvåningen Transporttid Tiden från att passageraren äntrat vagnen till dess att målet är nått
1.3.1 Definition
“An elevator is a hoisting or lowering mechanism, designed to carry passengers or goods (freight), and is equipped with a car and platform that typically moves in fixed guides and serves two or more landings.” [2]
Svensk översättning: En hiss är en lyftande eller sänkande mekanism, konstruerad för att bära passagerare eller varor (gods), och är utrustad med en vagn och en plattform som normalt rör sig i fixerad riktning mellan två eller flera stopp.
Kapitel 2
Bakgrund
Förr var hissar inte programmerade till att vara effektiva utan endast följa kom- mandon i form av knapptryckningar. Till en början följde hissar anrop som lades på en kö i den ordning de skett. Effektiviteten har med åren ökat och det finns idag många olika sätt att konstruera en hiss eller ett hissystem [3][4][5]. Konstruktioner och algoritmer skiljer sig i effektivitet beroende på olika faktorer. Dessa faktorer kan till exempel vara hur hög byggnaden är, hur många som använder hissarna och hur ofta hissarna används. Till exempel kan hissanvändningen i ett kontorshus skilja från hissanvändningen i ett bostadshus. På morgonen i ett bostadshus tar personer hissen till bottenplan för att gå till jobbet, men på morgonen i ett kontorshus tar personer hissen uppåt från bottenvåningen när de kommer till sitt arbete. På grund av detta kan olika konstruktioner och algoritmer vara olika effektiva i olika situ- ationer, tider och byggnader. I följande avsnitt kommer olika konstruktioner och algoritmer att beskrivas för att ge läsaren perspektiv i ämnet.
2.1 Att anropa och välja mål
Det finns flera olika sätt att anropa en vagn och välja mål. I ett hissystem med flera schakt bredvid varandra kan anrop och målval göras på olika sätt [5]. De sätt vilka funnits relevanta för denna rapport är beskrivna i avsnitten nedan.
2.1.1 Anrop följt av våningsval
Passageraren trycker på en knapp för att anropa en vagn och väljer mål inne i vagnen genom att på en knappsats trycka på den knapp som representerar passagerarens mål. Vid detta anropssätt har den styrande datorn få variabler att ta hänsyn till, vilket kan resultera i att en icke optimal vagn skickas att svara på anropet. Med fler variabler kan ett mer understött beslut tas och i och med detta ökar chansen att den optimala vagnen väljes.
KAPITEL 2. BAKGRUND
2.1.2 Anrop med målriktning följt av våningsval
Passageraren anropar en vagn genom att välja hurvida denne vill åka uppåt eller nedåt. Det specifika målvalet sker inne i vagnen. På översta våningen finns endast en riktningsknapp nedåt och på bottenvåningen finns endast en riktningsknapp uppåt.
Den styrande datorn kan då skicka en vagn på väg i rätt riktning att svara på anropet.
2.1.3 Anrop genom våningsval
Anropet sker genom att passageraren väljer mål på en knappsats. Det vill säga, passageraren anropar hissen genom att välja vilken våning denne vill nå redan i hallen. På detta vis ges fler variabler till den styrande datorn vilka kan tas hänsyn till när anropet ska fördelas till en vagn.
2.2 Multipla vagnar i samma schakt
I konstruktionen med multipla vagnar i samma schakt finns det två eller fler vagnar i ett schakt. Detta skapar situationen att vagnarna ej kan röra sig förbi varandra.
Lösningen till detta vid två vagnar innebär att våningarna delas in i en övre och en nedre zon där vagnarna följer specifika regler [4]:
1. Passageraren väljer mål vid anropet likt kapitel 2.1.
2. Den övre vagnen svarar endast på anrop som har start eller mål på något plan i den övre zonen.
3. Den undre vagnen rör sig endast i den undre zonen, samt kan röra sig nedanför bottenplan för att låta den övre vagnen nå bottenvåningen. Detta medför att den undre vagnen endast svarar på anrop som har både start och mål i den nedre zonen.
4. För att undvika krockar och dödlägen rör sig vagnarna aldrig mot varandra samtidigt.
2.3 Fast utgångspunkt
En vagn är tilldelad en våning som utgångspunkt. Vagnen rör sig till denna våning när den inte använts inom en fördefinierad tidsperiod. Utgångspunkten väljes med fördel på den våning där flest anrop registreras.
2.4 Zonsystem
Denna teori vilar på att, i ett hissystem med n schakt och n vagnar, olika vag- nar tilldelas ett antal varandra intilliggande våningar och svarar endast på anrop
2.5. TIDSANPASSAT SYSTEM
från dessa. Våningarna en vagn tilldelats kallas dess zon. I byggnader där många anrop sker från bottenvåningen ingår med fördel bottenvåningen i alla vagnars zo- ner [6][7]. Detta möjliggör att utgångspunkten för vagnarna anpassas till någon av de respektive zonerna för att öka effektiviteten genom att minska väntetiden [8].
Ett zonsystem har också nackdelar. Systemet fungerar bäst då anropen är jämnt utspridda i byggnaden. När många passagerare anländer till samma zon samtidigt förlorar systemet effektivitet.
2.5 Tidsanpassat system
Behovet av en hiss kan variera under en tidsperiod; exempelvis dygn, helger, somrar och helgdagar. I till exempel ett kontorshus kan behovet av hissen vara störst på entréplan på morgonen och vid resterande våningar på eftermiddagen. Detta kan tas i bedömning för att effektivisera ett hissystem [9]. På ett sjukhus kan det antas att vissa hissar används mer under kontorstider men olika mycket under resten av dygnet, beroende på om det till exempel är helg(dag) eller inte.
2.6 The elevator algorithm
The elevator algorithm, även kallad Collective operation, är en hissalgoritm som kräver att anrop med målriktning följt av våningsval, beskrivet i kapitel 2.1.2, är implementerat. En vagn svarar på anrop gjorda i vagnens färdriktning så länge det finns anrop att svara på. När inga fler anrop finns byter vagnen riktning och svarar på anrop gjorda åt motsatt håll. Detta fortgår tills dess att det inte finns anrop att svara på. I detta fall stannar vagnen på våningen där den senast betjänade passageraren nått sitt mål. En variation på denna algoritm är att en vagn utan anrop att svara på åker till en förbestämd utgångspunkt (se kapitel 2.3) [10][11].
Denna algoritm är inte optimal då det ofta resulterar i att flera vagnar når samma våning samtidigt vilket i sin tur resulterar i att endast en vagn hanterar anropet och resterande vagnar förlorar tid och energi [8].
2.7 Nearest Car Algorithm
Även algoritmen Nearest Car Algorithm, kräver tekniken i kapitel 2.1.2. Algoritmen räknar ut ett värde V för varje hiss för att därefter tilldela ett anrop till en speci- fik vagn beroende av värdet V. Variablerna i denna algoritm är vagnens riktning, passagerarens start och mål samt vagnens position. Det finns fyra olika fall vilka beskrivs nedan [6][7]. Vagnen med högst värde bedöms vara bäst lämpad att bli tilldelad anropet. I ekvationerna nedan är
N = antalvåningar − 1 (2.1)
KAPITEL 2. BAKGRUND
och
d = |antalvåningar − passagerarens startvåning| (2.2) I det första fallet gäller scenariot då vagnen är i rörelse mot passageraren och pas- sagerarens mål är beläget bortom passageraren relativt vagnen. Detta innebär att vagnen kan ta passageraren till dess mål utan att byta riktning. I detta fall beräknas värdet av:
V = (N + 2) − d (2.3)
I det andra scenariot är vagnen i rörelse mot passageraren men passagerarens mål ligger, sett från passageraren, bortom vagnen. Vagnen måste byta riktning efter att passageraren har äntrat vagnen för att nå målet. Värdet beräknas av:
V = (N + 1) − d (2.4)
Det tredje scenariot gäller då vagnen är stillastående och inte har något anrop att betjäna:
V = N − d (2.5)
Det sista scenariot gäller då vagnen är på väg bort från passageraren:
V = 1 (2.6)
Kapitel 3
Metod
3.1 Litteraturstudie
För en ökad förståelse i detta ämne har en litteraturstudie utförts. Det studerade materialet är rapporter, patent och böcker inom området. Den djupare förståelsen behövs för att finna bättre lösningar på problemet och sålla relevant från irrele- vant information. Litteraturstudien inleds med en kort beskrivning av hissars och hissystems utveckling som följs av beskrivningar av några vanligt förekommande algoritmer för att ge läsaren en uppfattning om olika sätt att kontrollera hissar.
Trots att rapporten kommer att fokusera på de enklare algoritmerna tas även mer avancerade algoritmer upp i bakgrunden för att ge läsaren en idé om hur dessa enkla- re algoritmer har utvecklats samt hur de testade algoritmerna för prioritetsanrop skulle fungera i mer avancerade system.
3.2 Testning
För att testa olika algoritmers effektivitet görs en simulering av ett hissystem på ett sjukhus. Den grundläggande idén var att använda ett redan existerande program för att simulera hisstrafik och därefter implementera hantering av prioritetsanrop.
Dock konstaterades tidigt i litteraturstudien att ett program specifikt framtaget för detta syfte bör användas. Anledningen till detta var att det var svårt att hitta program vars algoritm fanns tydligt beskriven och som även kunde anpassas för att göra tester på de specifika sätt detta arbete kräver.
Anledningen till att ett hissystem med flera vagnar i samma schakt inte valts för testning är att det anses vara ovanligare och inte idealiskt för lägre byggnader utan mer anpassat för skyskrapor eller liknande.
3.2.1 Algoritm för simulering av ordinarie hisstrafik
I testerna kommer algoritmen Nearest Car Algorithm, beskriven i kapitel 2.7, att användas för att simulera hisstrafik för de ordinarie passagerarna. Detta för att
KAPITEL 3. METOD
bedömningen gjorts att denna algoritm ligger bra till grund för vidare utveckling och att algoritmen i fråga låg på en bra kunskapsnivå gällande programmering. Denna algoritm bedöms dessutom kunna ge en uppfattning om hur de testade algoritmerna för prioritetsanrop fungerar i andra implementeringar av hissystem.
3.2.2 Algoritmer för prioritetsanrop
Efter litteraturstudien har olika sätt att behandla prioritetsanrop tagits fram. Dessa kommer att testas likvärdigt vid simulering. Algoritmerna i detta kapitel är de algoritmer vilka har valts ut för testning.
Närmaste vagn
I denna algoritm kommer den vagn som är närmast våningen där prioritetsanropet skett att avbryta pågående färd och direkt betjäna prioritetsanropet. Om fler än en vagn står på samma ställe och är aktuella att betjäna anropet väljes den först upptäckta vagnen i algoritmen. Om passagerare befinner sig i vagnen går de av när vagnen stannat på en våning och registrerar därefter ett nytt anrop vid behov.
Närmaste vagn med specifik färdriktning
Denna idé bygger på att samtidigt som man kan betjäna ett prioritetsanrop kan man även transportera passagerare åt rätt riktning. Om ett prioritetsanrop sker på våning x kommer inte en vagn som är på väg bort från våning x att vända, utan närmaste stillastående vagn eller vagn i rörelse mot våning x kommer att betjäna anropet istället. På detta vis ökar vi chansen för att de redan ombordstigna passagerarna kommer till rätt våning. Detta sker på bekostnad av prioritetsanropens effektivitet. Effektiviteten minskar då färre vagnar kommer att ha samma riktning som prioritetsanropet och därmed vara inaktuella för hantering av detta.
Minst lastad vagn
Hissar kan känna av hur tungt lastad en vagn är för att undvika övervikt och riskerna det medför. Denna algoritm vilar på att varje vagns vikt läses av för att känna av om passagerare befinner sig i vagnen eller ej, och kan därefter välja en tom vagn eller en vagn med lägst vikt att svara på prioritetsanropet. På detta vis ökar chansen att en vagn med så få passagerare i som möjligt väljes. Genom att använda denna algoritm kan ordinarie passagerares restider påverkas mindre av implementeringen av prioritetsanrop.
Vagn endast för prioritetsanrop
Alla utom en vagn sköter den vanliga hissdriften, medan en specifik vagn endast svarar på prioritetsanrop. Med denna lösning kommer passagerarna aldrig att be- höva blandas in i prioritetsanropen eller hamna på en icke önskad våning. Detta på
3.2. TESTNING
bekostnad av att den ordinarie hissdriften sker med en vagn mindre. Om prioritets- anrop sker då vagnen är upptagen kommer anropen betjänas enligt först in-först ut-metoden.
3.2.3 Testfall
Testerna kommer att generera en ny passagerare var femte sekund och fördela ut dem på våningarna enligt tabell 3.1 nedan. Varje passagerare har två procents san- nolikhet att vara en prioritetspassagerare och kommer då att placeras på slumpad våning. Detta för att personals och patienters eller besökares rörelsemönster troligt- vis skiljer sig från varandra. Personal på ett sjukhus rör sig oftare mellan våningarna istället för in och ut ur byggnaden, medan besökare och patienter oftare tar sig från bottenvåningen till önskad våning och sedan ner igen. Plan 1 och 2 har lägre procent av ordinarie anrop eftersom de ligger så pass nära bottenvåningen och uppfattning- en är att personer är mer benägna att ta trapporna mellan bottenplan och dessa våningar. Samma tankesätt har motiverat procentsättningen på plan 3 och 4.
Både ordinarie- och prioritetspassagerarnas mål är slumpade. Detta för att stres- sa algoritmerna och simulera ett värsta fall. På grund av detta kan en tydligare indikation fås på hur bra dessa algoritmer skulle fungera i praktiken.
En vagn rör sig med en hastighet av en halv våning per sekund och håller dörrarna öppna i två sekunder när den stannat på en våning och passagerare ska ta sig in i eller ut ur vagnen.
Varje test pågår till dess att 1 000 passagerare har nått sitt mål. Därefter ex- porteras rådata för dessa passagerare. Även medelvärde på restiden för ordinare samt prioritetsanrop samt dess antal beräknas och exporteras. Totalt görs fem tes- ter för varje algoritm beskriven i kapitel 3.2.1 för att minska slumpens påverkan på resultatet.
Ett basfall testas med proceduren nämnd ovan men utan hantering av priori- tetsanrop. Detta för att få data att jämföra testresultaten med.
3.2.4 Simulering
Simuleringen sker i en fiktiv byggnad med elva våningar inkluderat bottenvåningen och fyra schakt med en vagn vardera. Detta på grund av att bedömningen gjorts att detta scenario är förekommande på svenska sjukhus.
3.2.5 Simuleringsmjukvara
Programmet består av sju huvudklasser och fyra klasser vilka ersätter de metoder som hanterar fördelningen av prioritetsanrop.
SimulationStart är den klass som startar simuleringen. Main, update och render - metoden hittas i denna klass.
BuildingController representerar datorn som styr hissystemet. BuildingControl- ler beräknar närmaste vagn med Nearest Car Algorithm och fördelar ut anrop till
KAPITEL 3. METOD
Våning Procent av ordinarie anrop
10 6 %
9 6 %
8 6 %
7 6 %
6 6 %
5 6 %
4 5 %
3 5 %
2 2 %
1 2 %
BV 50 %
Tabell 3.1. Simuleringens fördelning av ordinarie anrop över våningar
vagnarna. BuildingController har kontroll över var varje vagn befinner sig samt vag- narnas riktning. Klassen innehåller de två metoderna newNormalCall och newPri- orityCall. Dessa metoder är de som förändras mellan varje testad algoritm för pri- oritetshantering.
Floor representerar varje våning i byggnaden. Varje Floor har en lista med an- vändare och skapar Calls från våningen baserat på vart användarna ska och beroende på om knapparna på våningsplanet är aktiverade eller ej.
Elevator är en virtuell instans av en vagn och dess schakt. Elevator hanterar passagerare i vagnen och tar emot anrop som fördelats till vagnen av BuildingCon- troller. Den skickar även tillbaka anrop och passagerare vagnen ej längre kan ta hand om till BuildingController för vidare fördelning.
Calls syfte är att lagra informationen tillhörande ett anrop som sedan fördelas till en hiss. I Call lagras våning, riktning och hurvida ett anrop har prioritet eller inte.
I Person sparas information om passagerare. De har en vikt, start, mål, indike- ring på om de har prioritet eller inte samt en tidräknare.
Nedan följer de fyra klasser som ärver av BuildingController och ersätter de metoder som fördelar ordinarie samt prioritetsanrop:
PrioSpecialCar är klassen som fördelar anrop där en Elevator är dedikerad till prioritetsanrop. Detta blir i praktiken en personalhiss eller dylikt. Ordinare anrop fördelas via Nearest Car Algorithm till de övriga hissarna.
PrioLeastWeight fördelar prioritetsanrop till den hiss som har minst totalvikt oavsett distans från anropet. I övrigt fördelas anropen som ovan.
PrioNearestCar ger prioritetsanrop till den hiss som befinner sig närmast vå- ningen anropet kommer ifrån. I övrigt fördelas de ordinarie anropen som ovan.
PrioNearestDirectionCar hanterar prioritesanrop likt avsnittet ovan. Dock med ändringen att den närmsta vagn med riktning mot prioritetsanropet väljes. Upp-
3.2. TESTNING
fyller ingen vagn detta kriterie väntar algoritmen till dess att någon vagn vänder.
Ordniarie anrop fördelas som ovan.
Programmet har följande egenskaper: Ett anrop fördelas av BuildingController beroende av typ till den mest lämpade vagnen baserat på algoritmen Nearest Car Algorithm alternativt algoritm för prioritetsanrop. En vagn kommer att röra sig till våningen där anropet skett, låta passageraren gå ombord och sedan åka till passa- gerarens mål. Om vagnen tilldelas fler ordinarie anrop under denna tid kommer den stanna på våningar där anropet och vagnen har samma riktning. Övriga ordinarie anrop hanteras senare. Om en vagn är tilldelad två anrop från samma våning, men åt olika riktningar kommer hissen vid första stoppet på våningen endast att plocka upp passagerare som ska åt samma håll som vagnen för att senare hantera anropet åt motsatt håll. En passagerare kommer alltid att gå ombord på första vagn i rätt riktning som stannar på dess våning.
Hanterar vagnen ett prioritetsanrop ignoreras alla anrop fram till dess att prio- ritetsfärden är avslutad.
När en passagerare lämnar hissen på sin önskade våning läggs den till i en lista med passagerare som slutfört sin resa. Om en person läggs till på en våning där ett anrop åt personens riktning ej har gjorts skapas ett Call av Floor -klassen. Om en person läggs till på en våning där ett anrop åt rätt håll redan gjorts görs inget nytt anrop. Detta är implementerat för att simulera verkligheten. I verkligheten kommer inte alla personer som vill använda hissen samtidigt att göra ett anrop per person.
En vagn blir tilldelad ett anrop av BuildingController, som mottagit det från Floor och beräknar med hjälp av Elevator en kostnad för varje vagn och fördelar ut anropet till den bäst lämpade. En vagn kommer endast att stanna på våningar där någon i vagnen ska gå av eller där ett anrop fördelat till vagnen i fråga har gjorts.
Vid prioritetsanrop kommer eventuella ordinarie passagerare att tvingas lämna vagnen så snart vagnen har stannat för att sedan registrera nya anrop från aktuell våning såvida de inte nått sitt mål.
3.2.6 Tidmätning
För varje Person sparas starttid och sluttid i millisekunder med hjälp av den in- byggda javametoden System.currentTimeMillis(). Med dessa räknas sedan den to- tala transporttiden ut. Vid slutförd simulering har två filer exporterats. Den ena av dessa filer är en kommaseparerad fil som innehåller relevant information om varje person Person. Den andra filen är en textfil som innehållandes det totala medelvärdet för restid per Person samt antal och medelvärde för ordinarie samt prioritetsanrop.
KAPITEL 3. METOD
3.2.7 Testmiljö
Simuleringarna är utförda på följande system:
CPU Intel Core2 Quad CPU Q9550 @ 2.83GHz × 4
Minne 3.8 GiB
Operativsystem Ubuntu 12.04 x64 Språk Java OpenJDK 1.6.0_35
Tabell 3.2. Specifikationer för testmiljö
Kapitel 4
Resultat
4.1 Testresultat
4.1.1 Närmaste vagn
Figur 4.1. Genomsnittliga transporttider vid ordinarie- och prioritetsanrop samt genomsnittlig referenstid utan prioritetshantering vid test av algoritmen Närmaste vagn
Figur 4.1 visar att transporttiden för en person med prioritetsanrop är nästan hälften av transporttiden för ordinarie personer. Vi ser även att tiden för ordinarie anrop inte ökar nämnvärt från referensfallet utan prioritetsanrop.
KAPITEL 4. RESULTAT
4.1.2 Närmaste vagn med specifik färdriktning
Figur 4.2. Genomsnittliga transporttider vid ordinarie- och prioritetsanrop samt genomsnittlig referenstid utan prioritetshantering vid test av algoritmen Närmaste vagn med specifik färdriktning
I testet med tillägget att anropet fördelas till närmaste vagn med färdriktning mot den våning där prioritetsanropet skett ser vi en högre genomsnittstid för pri- oritetsanrop. Vi ser även att genomsnittstiden för ordinarie anrop ligger omkring referenstiden.
4.1. TESTRESULTAT
4.1.3 Minst lastad vagn
Figur 4.3. Genomsnittliga transporttider vid ordinarie- och prioritetsanrop samt genomsnittlig referenstid utan prioritetshantering vid test av algoritmen Minst lastad vagn
Till skillnad från testfallet Närmaste vagn ser vi här att genomsnittstiden fluk- tuerar mer och att tiden för ordinarie personer även här ligger omkring 30 sekunder, men att tiden för prioritetsanrop är något högre än i de tidigare testerna.
KAPITEL 4. RESULTAT
4.1.4 Vagn endast för prioritetsanrop
Figur 4.4. Genomsnittliga transporttider vid ordinarie- och prioritetsanrop samt genomsnittlig referenstid utan prioritetshantering vid test av algoritmen Vagn endast för prioritetsanrop
I detta testfall varierar genomsnittstiden för ordinarie personer mer än i tidigare testfall och är i varje testfall högre än referenstiden. Tiden för prioritetspersoner är även här lägre än referensfallet men visar högre snittider än föregående tester.
4.2 Analys
I resultaten ser vi att genomsnittstiden för personer med prioritet blir kortare än referenstiden i samtliga fall. Tiden för ordinarie personer varierar mer, men är i flera fall nära referenstiden.
Kapitel 5
Diskussion
Efter att vi begrundat resultaten från testerna kan flertalet diskussioner lyftas. Vi ser att testerna skulle kunna göras fler gånger och med fler passagerare för att få ett mer rättvisande resultat som kan ge oss en tydligare indikation på genomsnittstiden.
Detta skulle göra att en mer definitiv slutsats kan dras angående effektiviteten vid implementering av prioritetshantering. Att testerna är gjorda med en väldigt hög genomströmning av passagerare kan också spela en roll i hur resultaten ser ut.
Resultaten förvånade då genomsnittstiden för de ordinarie passagerarna inte ökade vilket från början misstänkts. Det visades tendenser till att den ordinarie genomsnittstiden minskades vid användning av prioritet. Detta kopplar vi till fak- tumet att grundalgoritmen Nearest Car Algorithm inte är effektiv i alla situationer.
Det noterades under simuleringarna att vagnar ibland fastnade högt upp i byggna- den. Detta då grundalgoritmens ekvation har svårt att hantera anrop som sker från bottenvåningen när vagnar står stilla högst upp i byggnaden. I det nyss nämnda fallet beräknas V=1 enligt ekvation 2.5, vilket är detsamma som det statiska värdet för ekvation 2.6. Det krävdes att någon passagerare från de övre våningarna gjorde ett anrop neråt och att ingen vagn i rörelse var i närheten för att de åter skulle kunna betjäna anrop.
5.1 Problem och brister
En viktig sak att poängtera i tidsåtgången för prioritetsanrop och varför de i vissa fall visade på halva genomsnittstiden gentemot de ordinarie är att prioritetsanro- pen generellt sett har dels kortare färdvägar och dels kortare avstånd mellan an- ropsvåning och vagn. Ett prioritetsanrop har lika stor möjlighet att fördelas på alla våningar, till skillnad från de ordinarie som fördelats enligt tabell 3.1. Detta leder till att ett prioritetsanrop med större sannolikhet placeras i mitten av huset. Där är det större sannolikhet att en vagn befinner sig i närheten. Det ger även en kortare resväg i snitt då det är färre våningar i vardera riktning. De ordinarie anropen som primärt kommer från bottenvåningen har mindre sannolikhet att en vagn befinner sig i närheten. Deras resväg blir även statistiskt sett längre.
KAPITEL 5. DISKUSSION
Implementeringen av hissimuleringen var inte helt perfekt. Några defekter i ko- den finns fortfarande men ansågs hända så pass sällan att det inte skulle påverka slutresultaten nämnvärt. En sak som noterades var att ett anrop inte fördelades till en hiss trots att knappen på våningen tändes. Detta löste sig per automatik så snart en vagn stannade på berörd våning av att en passagerare nått sitt mål. Vår uppskattning är att det skedde mindre än en gång på 1 000 passagerare. Det kan finnas ytterligare buggar som ej noterats.
Ett problem vi ser i en verklig implementering av prioritetsanropshantering är passagerares förvirring då en vagn plötsligt kan vända och passagerare behöver lämna hissen vid nästa våningsstopp. Det är också viktigt att begrunda tiden det tar för passagerarna att ta sig ur hissen trots att de inte nått sitt mål.
Värt att notera är att vår implementering av algoritmen alltid valde den i algo- ritmen först upptäckta vagn om två eller fler vagnar var lika lämpade att hantera anropet.
5.2 Svårigheter och förbättringar
I framtiden kan de testade algoritmerna kombineras för bättre resultat. Algoritmen för att välja närmaste vagn kan kombineras med algoritmen för att välja vagnen med minst vikt. Detta skulle till exempel kunna innebära att om det finns två vagnar som båda har samma avstånd till prioritetsanropet kommer den vagn med minst vikt att väljas för att gynna de ordinarie passagerarna. Detta kan då gynna priori- tetspersoner utan att påverka de ordinarie passagerarna negativt. Vidare skulle en fast utgångspunkt på bottenplan kunna införas för att undvika problemet med att vagnar ibland fastnat på de högre våningsplanen i byggnaden.
Vi vill också belysa faktumet att slumpen spelar en stor roll i dessa tester.
Då vi inte har någon data att basera tillströmningen av passagerare på har vi gjort antaganden. Dessa antaganden är vad som ansetts rimligt, men det finns en medvetenhet om att hisstrafiken på ett sjukhus är svår att förutspå. Även anropens mål slumpas vilket medför att antalet anrop från bottenvåningen inte kommer att överensstämma med antalet anrop tillbaka till bottenvåningen. Vad som inte tagits i beaktning är att personer som tar hissen från bottevåningen generellt sett kommer att ta hissen tillbaka till bottenvåningen. Även detta kan bidra till problematiken i att vagnar stannar på högsta våningen.
5.3 Slutsats
Tack vare att implementering av möjligheten att göra prioritetsanrop är så pass lätt att göra skulle detta även kunna appliceras på andra byggnader. Prioritetsanrop kan användas av till exempel ambulanspersonal på utryckning som med utrustning snabbt behöver nå fram till en skadad eller sjuk person.
På grund av orsaker nämnda i kapitel 5.2 väljer vi att inte se resultaten som en definitiv indikation på hur väl dessa implementeringar av prioritetshantering skulle
5.3. SLUTSATS
fungera, utan som en vägvisning. Vi konstaterar att resultaten, även i dess linda, kan ligga till grund för vidare forskning i detta ämne.
Litteratur
[1] Elevator Cabs, Entrances and Door Systems. url: http://www.columbiaelevator.
com/main/elevator-history/ (hämtad 2015-04-19).
[2] Neii.org. url: http://www.neii.org/presskit/pressmaster.cfm?link=8 (hämtad 2015-04-19).
[3] Thomas Beielstein, Claus-Peter Ewald och Sandor Markon. “Optimal elevator group control by evolution strategies”. I: Genetic and Evolutionary Compu- tation—GECCO 2003. Springer. 2003, s. 1963–1974.
[4] Satoshi Takahashi m. fl. “Simulation-based optimization of a controller for multi-car elevators using a genetic algorithm for noisy fitness function”. I:
Evolutionary Computation, 2003. CEC’03. The 2003 Congress on. Vol. 3.
IEEE. 2003, s. 1582–1587.
[5] Steven Edson Forsythe m. fl. Elevator destination protocol control with flexible user interface. US Patent 7,040,458. Maj 2006.
[6] Elevator scheduling. url: http://www.columbia.edu/~cs2035/courses/
ieor4405.S13/p14.pdf (hämtad 2015-04-19).
[7] G.C. Barney. Elevator Traffic Handbook: Theory and Practice. Taylor & Fran- cis, 2004. isbn: 9780203301333. url: http://books.google.se/books?id=
GteIiGQT1S4C.
[8] Daniel Nikovski och Matthew Brand. “Decision-Theoretic Group Elevator Scheduling.” I: ICAPS. Vol. 3. 2003, s. 9–13.
[9] Thomas Strang och Christian Bauer. “Context-aware elevator scheduling”.
I: Advanced Information Networking and Applications Workshops, 2007, AI- NAW’07. 21st International Conference on. Vol. 2. IEEE. 2007, s. 276–281.
[10] Marja-Liisa Siikonen. “Elevator traffic simulation”. I: Simulation 61.4 (1993), s. 257–267.
[11] Elevators and Escalator Mitsubishi Electric. url: http://www.mitsubishielectric.
com/elevator/overview/elevators/b_operations01.html (hämtad 2015-04-19).
