I testerna har vi i största möjliga mån använt tillrättalagda data som följt med
programmen. Detta för att bespara oss stora arbetsinsatser med att anpassa kommunens data så det passar att använda i programmen. I startskedet kan det med vissa program innebära mycket jobb för att anpassa datat så det går att använda vid ruttoptimeringen.
Som vid all GIS-användning gäller att dåliga data in i processen ger dåligt resultat.
9.3.1 TransCAD
Problemet med testet av TransCAD var att vi inte har kunnat testa alla funktioner på grund av att datat inte har varit anpassat till programmet. Testet har genomförts med tillrättalagda exempeldata som levererats tillsammans med programmet. Några av parametrarna i utvärderingsmallen har ansetts som fullvärdiga utan att vi i praktiken har testat dem utan vi har gjort antagande utifrån vad som har gått att använda som
inparametrar i vissa funktioner.
Programmet är ganska lättarbetat när de grundläggande arbetsstegen är inlärda och det intryck vi har fått av programmet är att det har god kapacitet för ruttoptimering. Beroende på hur mycket arbete som användaren är villig att lägga ner på anpassning av data, och att
all optimering inte går att göra samtidigt utan måste göras dag för dag och varutyp för varutyp, kan detta vara ett program som är möjligt att använda i verksamheten. Den stora nackdelen är att det inte är etablerat i Sverige och att det därför blir svårt med support och utbildning. Det kan också kännas som att programmet är en onödig investering då det är så stort och den del som kommunen kan vara intresserade av är så liten. Det finns inte heller några användningsområden utöver trafik- och transportanalyser.
9.3.2 Plan LogiX
En klar nackdel med Plan LogiX är att det inte kan importera geografiska data från ESRI-shapefiles, MapInfo tab eller något annat ”vanligt” GIS-format. Detta beror troligen på att företaget som tillverkar programmet är inriktat på logistik och kartfunktionerna kommer i andra hand. Det går dock att få sina data konverterat av företaget så det går att använda i programmet. Det saknas också möjligheter att göra geografiska analyser och
bakgrundsdatat är statiskt när det väl tagits in i programmet.
När det gäller logistikfunktioner så finns det många parametrar som kan ställas in och med liten erfarenhet av logistikprogram så kan det upplevas en aning svårt. De verkar dock uppfylla många av de krav som vi ställt på programmet. Ur den bedömning vi gjort av programmet kan det dock inte beräkna hur många fordon som behövs för att
genomföra transporterna för en dag och vad vi förstod så gjordes ingen balansering av rutterna. Det går att ha ett stort antal stoppunkter och optimera så att flera rutter fördelar dessa mellan sig.
För att kommunen ska kunna använda sina data med stoppunkter måste det göras om så import till programmet blir möjlig. Det krävs också att vägkartan innehåller de adresser som stoppunkterna representerar för att dessa ska kunna tilldelas ett läge på kartan. De kartor som levereras med programmet har inte tillräcklig detaljeringsgrad över Luleå så annat data måste användas.
Programmet känns logiskt upplagt och det är inte alltför krångligt att komma fram till ett resultat. När användaren väl arbetat in rutinerna borde det inte vara några problem att använda programmet.
10 Slutsats
· Utifrån de tester som gjorts kan konstateras att den generella mallen är möjlig att anpassa och därefter går att använda till jämförande test av programvaror med funktionalitet för ruttoptimering.
· Den generella utvärderingsmallen bör inte viktas, poängsättas eller ges ”skall-krav” eftersom den då inte längre är tillräckligt generell för att kunna användas i olikartade verksamheter.
· För att kunna göra en korrekt bedömning av vilken nytta en viss verksamhet skulle ha av mallen måste användaren vara väl insatt i verksamheten och vara medveten om vilka krav som kan ställas på ett planeringsverktyg.
· Under examensarbetet testades den generella mallen endast i en verksamhet där transporter av mat och varor utförs. För att få en bättre kontroll på om den är tillräckligt omfattande bör den testas inom ett flertal verksamhetsområden.
· Det är svårt att vikta och poängsätta en utvärderingsmall så att slutsumman av alla parametrar visar vilket program som är bäst. Det är säkrast att istället jämföra programmen parameter för parameter.
· För att kunna jämföra programmen med hjälp av den anpassade mallen måste användaren först sätta sig in i hur programmet fungerar.
· Utifrån samråd med ansvariga på Socialförvaltningen så har slutsatsen dragits att behovet finns av ett verktyg som är mer anpassat än de som testats under
examensarbetet. De testade programmen är generella och detta leder till stora risker för att göra misstag under alla olika planeringssteg.
11 Referenser Litteratur
[1] Eklund Lars, m fl. Geografisk informationsbehandling – metoder och tillämpningar.
Byggforskningsrådet ULI. Central Tryckeriet, Borås, 2002.
[2] Nilsson Åke. Transport & Logistik – att handla med utlandet. Gleerups Förlag. Duo Grafiska AB, 2002. 132 sidor.
[3] Öhman Jeanette. GIS inom transportbranschen. Examensarbete vid Kungliga Tekniska Högskolan. 2000.
Interna dokument
[4] Användning av GIS vid optimering av transporter inom Socialförvaltningen.
Stadsbyggnadskontoret, Luleå kommun. 2002.
Personliga kontakter
[5] Berggård Glenn, Trafikteknik, Luleå tekniska universitet 030321 [6] Bucht Ingegerd, Utredare Socialförvaltningen, Luleå kommun 030423 [7] Carlsson Magnus, VD Taxi Stor & Liten Gästrikland 030402
[8] Liljedahl Anita, GIS-samordnare, Falkenbergs kommun 030326 [9] Lennartsson Peter, Adena Picko’s 030401
[10] Mauritzson Lars, B&M Systemutveckling AB 030515 [11] Rickne Thomas, Commercial Director, DPS Sverige 030403
[12] Roosvall Torgny, Teknikavdelningen, Kristianstad kommun 030327
Internet
[13] http://www.bmsystem.se B&M Systemutveckling AB, 030415
[14] http://www.transware.se/Pressrealeser/TransWare%20AB%20PR0101-2.htm TransWare, 030408
Bilagor
Bilaga A Generell utvärderingsmall
Program
Allmänna krav som kan ställas på applikationen:
Operativsystem Teknisk plattform
Antal samtidiga användare Dataformat som stöds Språk
Användargränssnitt Lokal installation Serverinstallation Webbserverinstallation Dokumentation och manualer Hjälpfunktion i programmet Support
Utbildning
Ruttplanering
Hänsyn kan tas till följande parametrar:
Nätverkstopologi (länkar och noder) Inlärningströskel
Arbetsinsats vid ruttoptimering Svarstid vid ruttoptimering
Balansering (jämn fördelning av rutter på hela fordonsflottan) Optimera rutt utifrån kortaste körsträcka
Optimera rutt utifrån kortaste körtid Beräkning av körsträcka
Beräkning av körtid
Beräkning av antal fordon som behövs Start- och slutpunkt
Körorder för rutt/rutt i tabellform En depå
Flera depåer (ev. begränsning) Tidsfönster för depå
Redigera depåer
Stoppunkter (ev. begränsning) per rutt Mängd som ska levereras till varje stoppunkt Tidsfönster för stoppunkter
Redigera stoppunkter Ett fordon
Flera fordon
Olika typer av fordon Arbetstid för förare Driftkostnad Lastkapacitet
Hastighet för fordon på olika typer av vägar Varuegenskaper
Flera dagar samtidigt
Flera varutyper samtidigt Förbjudna vägar
Svängrestriktioner Trafikflödespåverkan Undvik platser Utskrift av karta Utskrift av körorder Utskrift av tabell
Kartstöd
Funktionalitet som kan finnas i kartan:
Visa karta
Visa rutt på karta Zooma in
Zooma till rutt Zooma till full extent Zooma ut
Föregående kartbild Panorera
Visa koordinater för muspekaren Visa kartskala/måttstock
Användarstyrd skala Informationsverktyg Sökverktyg
Bilaga B Anpassad utvärderingsmall med ”skall-krav”,
poängdefinitioner och vikter
Bilaga C Kravspecifikation
Kravspecifikation
Ruttoptimering
Bakgrund
Luleå kommuns Socialförvaltning transporterar mat till äldreboenden och mat och varor till enskilda som har beviljats sådana insatser. I samband med planering och uppföljning av dessa transporter har Socialförvaltningen behov av ett system för att beräkna optimala transportrutter. Systemet ska innehålla både GIS- och logistikfunktioner och kunna användas som stöd både vid planering och uppföljning av transporterna.
Omfattning
Kravspecifikationen omfattar ett system för planering och optimering av transporter samt utbildning i hanteringen av systemet.
Förutsättningar
Mat och varor levereras med bilar från ett flertal tillagningskök respektive affärer till olika mottagare. I dagsläget rör det sig om ca 200 mottagare i Luleå kommun. För de olika typerna av leveranser, varm mat, kall mat och varor, finns det olika krav avseende maximal transporttid, lastkapacitet, leveranstider och leveransdagar. De olika
stoppunkterna (mottagarna) kan ha olika behov av stopptid, d v s den tid stoppet för avlastning tar, i och med att både servicebehovet och mängden som levereras kan variera.
Allmänna krav
1. Programmet ska fungera i kommunens IT-miljö.
2. Språket i programmet, manualer, dokumentation och hjälpfunktioner bör vara svenska, men engelska kan accepteras.
3. Användargränssnittet ska vara lättanvänt och bör likna Windows-gränssnittet.
4. Dokumentation och användarmanualer ska finnas.
5. Hjälpfunktion i programmet ska finnas.
6. Supportavtal ska kunna tecknas.
Ruttoptimering
Nedan beskrivs ett antal krav som systemet ska uppfylla samt ett antal önskemål som användarna har på systemet. Beskriv i vilken omfattning som systemet uppfyller dessa önskemål.
Stoppunkter
1. Beskriv hur lagring/import av stoppunkter, med tillhörande attributinformation, ska ske och om denna information lagras inom systemet, om informationen importeras vid optimeringstillfället eller om detta löses på något annat sätt. I vilket/vilka format kan informationen lagras alternativ importeras.
2. I dagsläget lagras information om mottagare och vilken typ av leverans som avses, inkl adress i en Excel-fil. Från denna fil skapas sedan en shape-fil, där koordinaterna för adressen lagts till. Dessa format bör kunna användas av systemet.
3. Stoppunkter ska kunna läggas till, redigeras och tas bort. Detta kan eventuellt lösas genom att uppdaterade data importeras till programmet på nytt.
4. Individuell stopptid för stoppunkterna ska kunna läggas in och systemet ska ta hänsyn till denna vid optimeringen.
5. Tidsintervall (tidsfönster) för när olika typer av leveranser får ske till olika mottagare ska kunna ställas in.
6. Hur stor mängd som ska levereras till varje stoppunkt ska kunna anges.
7. Systemet bör kunna hantera minst 500 mottagare. Ange eventuell begränsning i antalet stoppunkter.
Depåer
8. Beskriv hur lagring/import av depåer ska ske (se stoppunkter).
9. Depåer ska kunna läggas till, redigeras och tas bort. Detta kan eventuellt lösas genom att uppdaterat data importeras till programmet på nytt.
10. Öppettider (tidsfönster) för depå ska kunna anges.
11. Optimeringssystemet ska kunna ta hänsyn till flera depåer, d v s tillagningskök respektive affärer, vid optimeringen. I dagsläget handlar det om runt tio olika depåer i Luleå kommun men detta kan komma att ändras. Ange eventuell begränsning i antalet depåer.
Leveranstyper
12. Systemet ska kunna optimera rutter för olika typer av leveranser, med olika krav.
13. Olika varors behov bör kunna matas in så att det vid ruttplaneringen bara är att välja vilken vara som ska levereras.
Fordon
14. Vilka fordon som finns tillgängliga och vilken lastkapacitet dessa har samt vilken genomsnittlig hastighet de håller på olika typer av vägar ska kunna anges.
Vägdata
15. Programmet ska kunna använda kommunens vägdata, lagrade i ESRI shape-filer, med nätverkstopologi (noder och länkar) för ruttoptimeringen, d v s optimeringen av transporterna. Systemet bör även kunna använda data från Vägverkets
Nationella Vägdatabas, NVDB. Ange i vilka format vägdata kan användas.
16. Om vägarbeten eller dylikt hindrar fordonens framfart bör vägar kunna förbjudas tillfälligt genom ett enkelt ingrepp.
Ruttoptimering
17. Det ska gå att optimera rutterna utifrån snabbaste körväg och kortaste körväg.
18. Planering ska kunna göras med flera fordon samtidigt.
19. Rutter ska kunna sparas undan och tas fram igen vid ett senare tillfälle.
20. Rutter ska kunna redigeras manuellt om någon förändring i optimerad rutt behöver göras.
21. Rutter ska kunna visas på en karta.
22. Rutter i tabellform alternativt körorder för rutt ska kunna visas.
23. Karta, tabell och körorder ska kunna skrivas ut.
24. Balansering av belastningen på fordon så att alla tilldelas ungefär lika mycket leveranser bör kunna göras.
25. Beräkning av hur många fordon som behövs för att klara leveranserna bör kunna göras.
26. Beräkning av körtid och körsträcka för rutt ska kunna göras.
27. Önskemål finns att det ska gå att hantera planering för flera dagar samtidigt.
28. Önskemål finns att det ska gå att hantera planering av flera typer av varor med olika behov samtidigt.
29. Maximal tillåten tid för en rutt ska kunna anges.
30. Startpunkt och slutpunkt för rutt ska inte behöva vara på samma ställe.
Kartstöd
31. Systemet ska ha ett kartstöd för presentation av de optimerade rutterna. Kartan ska bestå av en bakgrundskarta för orientering, samt vägnätet. Depåer och stoppunkter ska även de visas på kartan. Följande funktioner ska finnas för karthanteringen:
32. Zoomning (in, ut, till full omfattning, till föregående och till rutt).
33. Panorering
34. Någon form av skalangivelse ska finnas för kartan och användaren ska även kunna styra vilken skala kartan ska visas i.
35. Informationssökning genom att klicka i kartan och få information om depåer och stoppunkter.
36. Sökning i kartan genom att skriva in adress.
Export av data
37. Data, i form av färdiga rutter på en karta, körscheman eller information om stoppunkterna, ska kunna exporteras för analys eller presentation i annat system.
Beskriv på vilka sätt och i vilka format dataexport kan ske.
Övriga funktioner
38. Beskriv vilka övriga funktioner som systemet tillhandahåller.
Utbildning
Utbildning för hantering av systemet ska ge kommunens användare tillräcklig kunskap för att använda programmet i verksamheten. Beskriv utbildningens utformning och omfattning.