D-UPPSATS
GIS och logistik vid
optimering av transporter inom Socialförvaltningen
2003:21
ERIK EDBERG JESSICA RÖNNLUND
TEKNOLOGIE MAGISTEREXAMEN
Institutionen för Samhällsbyggnadsteknik Avdelningen för Geografisk informationsteknik
Vetenskaplig handledare: Mikael Segerlund
GIS och logistik vid optimering av transporter inom Socialförvaltningen
Erik Edberg
Jessica Rönnlund
Förord
Detta examensarbete är det slutliga momentet för GIT-magisterutbildningen 160 p vid Luleå tekniska universitet. Examensarbetet omfattar två 10 poängsarbeten och har utförts på uppdrag av Stadsbyggnadskontoret på Luleå kommun under våren 2003.
Vår handledare har varit Anna Lundqvist, MBK och GIS-samordnare på Stadsbyggnadskontoret, Luleå kommun.
Vi vill också tacka vår examinator Mikael Segerlund och Luleå kommun samt de programvaruföretag som bidragit med utvärderingslicenser till examensarbetet.
Luleå den 3 juni 2003
Erik Edberg Jessica Rönnlund
Sammanfattning
Denna rapport behandlar ett examensarbete som genomförts på Luleå kommun.
Socialförvaltningen på Luleå kommun ansvarar för leverans av mat och varor till
personer som behöver hjälp med detta. Socialförvaltningen behöver ett verktyg med GIS- och logistikfunktioner för att planera och följa upp transporterna.
Idag finns ingen befintlig utvärderingsmall som kan användas för att jämföra olika programvarors funktionalitet. Det vore önskvärt att en sådan generell mall fanns tillgänglig för att anpassas till den aktuella verksamheten när behov uppstår.
Examensarbetets syfte är att utforma en generell utvärderingsmall som efter anpassning kan användas vid jämförelse av olika ruttoptimeringsprogram.
En generell utvärderingsmall utformas. För att kontrollera utvärderingsmallen anpassas den till Socialförvaltningens krav och används i test av två utvalda programvaror med funktioner för ruttoptimering.
En kravspecifikation som skall kunna ligga till grund för en upphandling av programvara med funktioner för ruttoptimering utformas med den anpassade utvärderingsmallen som grund.
Test av program gjordes med en utvärderingsmall som anpassats utifrån den generella mallen. Det kunde konstateras att utvärderingsmallen var tillräckligt omfattande för Socialförvaltningens krav. För att bättre kunna bedöma den generella utvärderingsmallen bör den testas inom fler verksamhetsområden.
Abstract
This report is about a thesis project that has been performed at Luleå commune. The social service at Luleå commune has the responsibility to deliver food and groceries to citizens that are in need of such services. The social service needs a tool with GIS and logistic functions for planning and follow up of the transports.
Today there is no existing evaluation model that can be used to compare the functions of different programs. It would be desirable to have a general model that can be used to adapt for specific activity when the need arise.
The purpose of the thesis project is to develop a general evaluation model that can be adapted and used for comparison of different route optimizing programs.
A general evaluation model is developed. To control the model it is adapted to the social service requirements and used to test two selected programs with route optimizing functions.
A document containing specifications of requirements that can be used as basis for purchase of programs with route optimizing functions is developed. It is developed with the adapted evaluation model as basis.
The testing of the programs performance was preformed by adjusting the general evaluation model. This design was advanced enough to correspond to the social service demands. For a better evaluation of the model it should be tested in different activities.
Innehållsförteckning
1 Inledning ... 7
1.1 Bakgrund... 7
1.2 Syfte ... 7
1.3 Problemställning ... 7
1.4 Mål ... 7
1.5 Avgränsning... 7
2 Metod ... 8
3 Problem vid optimering av transporter i allmänhet ... 9
4 Användning av GIS vid transportoptimering... 10
4.1 Nätverksanalys... 10
4.2 Ruttoptimering ... 10
5 Lösningar på markanden... 11
5.1 Andra kommuners lösningar... 11
5.2 Transportföretags lösningar ... 11
5.3 Några programvaror inom området ... 12
5.3.1 ArcLogistics Route ... 12
5.3.2 FetchPlanner ... 12
5.3.3 GeoMedia Transportation Analyst... 13
5.3.4 Route LogiX Professional och Plan LogiX ... 13
5.3.5 TransCAD ... 13
5.3.6 TransWare StreetWise ... 13
6 Utformning av generell utvärderingsmall... 14
6.1 Parametrar ... 14
6.1.1 Program... 16
6.1.2 Ruttoptimering ... 17
6.1.3 Kartstöd... 20
7 Anpassning av utvärderingsmallen utifrån Socialförvaltningens behov ... 21
7.1 Anpassad utvärderingsmall... 21
7.1.1 ”Skall-krav” ... 21
7.1.2 Poängsättning och viktning... 22
7.2 Framtagande av kravspecifikation som kan användas vid upphandling... 28
8 Utvärdering av GIS-programvara med logistikfunktioner... 29
8.1 Val av verktyg... 29
8.2 Test... 29
8.2.1 TransCAD ... 29
8.2.2 Plan LogiX ... 31
9 Diskussion... 33
9.1 Generell utvärderingsmall... 33
9.2 Anpassad utvärderingsmall... 34
9.2.1 ”Skall-krav” ... 34
9.2.2 Poängsättning... 34
9.2.3 Viktning ... 34
9.2.4 Om varm mat ersätts med kall mat ... 35
9.3 Test och resultat ... 35
9.3.1 TransCAD ... 35
9.3.2 Plan LogiX ... 36
10 Slutsats ... 37
11 Referenser ... 38
Litteratur ... 38
Interna dokument ... 38
Personliga kontakter... 38
Internet ... 38
Bilagor... 39
Bilaga A Generell utvärderingsmall ... 39
Bilaga B Anpassad utvärderingsmall med ”skall-krav”, poängdefinitioner och vikter 44 Bilaga C Kravspecifikation... 48
Bilaga D Testresultat... 53
1 Inledning 1.1 Bakgrund
Inom Socialförvaltningen i Luleå kommun pågår en översyn av transporter av varor och mat till personer som beviljats sådana insatser. Uppdraget innebär att hitta mindre kostsamma transportlösningar än vad som gäller i dagsläget. Som ett led i detta uppdrag vill Socialförvaltningen med hjälp av GIS försöka ta fram optimala körrutter för
transporterna. Detta projekt är en vidareutveckling av det tidigare genomförda CtgIT- projektet ”Användning av GIS vid optimering av transporter inom Socialförvaltningen”.
Transporterna utförs idag av en entreprenör som kommunen anlitat och kommunen har ingen kontroll över hur transporterna planeras och genomförs. Varje år betalas en avgift för tjänsten. Då fakturan inte är specificerad på ett sådant sätt att det klart och tydligt framgår vad avgiften baserats på, har kommunen ingen möjlighet att avgöra om kostnaden för mat- och varutransporter är rimlig.
I dagsläget levereras varm mat, kall mat och varor enligt olika rutiner. Den varma maten ställer stora krav på transportplaneringen, medan den kalla maten och varorna inte är lika krävande vid hanteringen. Det pågår en utredning kring måltiderna och ett beslut skall tas om varm mat fortsättningsvis skall ersättas med kall mat. [6]
1.2 Syfte
Socialförvaltningen vill använda GIS och logistikfunktioner i översynen av transporter, enligt uppdraget ovan. Önskvärt är att i förlängningen få tillgång till ett verksamhetsstöd som underlättar kontinuerlig planering och uppföljning av transporterna.
1.3 Problemställning
Det finns idag ingen generell utvärderingsmall som kan användas vid test av
programvaror med funktionalitet för ruttoptimering. Önskvärt är att en sådan mall finns tillgänglig och kan anpassas till en verksamhets speciella krav när programvaror avsedda för ruttoptimering ska testas. Detta skulle leda till att det går att undvika att samma arbete måste upprepas när nya programvaror ska testas och nya verksamheter är intresserade av att underlätta transportplaneringen.
1.4 Mål
Utforma en utvärderingsmall med generella krav för ett verktyg som skall användas vid transportoptimering.
1.5 Avgränsning
Den generella utvärderingsmallen omfattar endast ruttplanering från ett antal depåer till ett antal mottagare. Övriga analyser som exempelvis trafikflödesanalyser eller att hitta bästa vägen för att passera samtliga länkar i ett nätverk behandlas ej. Positionering av fordon med hjälp av GPS behandlas ej heller i denna rapport. Ingen hänsyn tas till vilken kvalité som krävs på data.
2 Metod
För att få idéer och material till en generell utvärderingsmall kontaktas ett antal kommuner och transportföretag via telefon. Dessa tillfrågas om hur de använder GIS i optimering av transporter. Kommunerna väljs utifrån folkmängd, rekommendationer och utifrån uppenbara GIS-kunskaper som annonseras på kommunernas webbsidor.
Transportföretagen väljs utifrån rekommendationer och sökningar på Internet.
Även företag som tillverkar GIS-programvaror kontaktas med förfrågningar om vilka programlösningar de har för att lösa det aktuella problemet. Företagen väljs utifrån rekommendationer från användare av företagets programvaror, sökning på Internet samt om företagen är stora och kända GIS-programvarutillverkare.
Utifrån den information som inhämtas vid telefonkontakter med kommuner,
transportföretag och programvarutillverkare väljs ett antal program ut. Dessa program provkörs för att ge information om vad som bör ingå i en generell utvärderingsmall för transportplanering.
Från tidigare genomförda projekt på Luleå kommun erhålls erfarenheter om vilka krav som kan ställas utifrån planering av mattransporter.
En generell utvärderingsmall innehållande ett antal påståenden i punktform utformas. De olika punkterna klassificeras i olika grupper beroende på vilket område de berör.
För att testa den generella utvärderingsmallen anpassas denna till Socialförvaltningens behov. Den anpassade utvärderingsmallen viktas och poängsätts för att ge olika parametrar rättvisa jämförelsevillkor och i förlängningen kunna resultera i rättvisa jämförelser av programvaror. Därefter används den anpassade mallen i test och utvärdering av olika programvaror.
De dataprogram som testas mot den anpassade utvärderingsmallen väljs ut genom att det finns tillgång till utvärderingslicenser av dessa samt att de vid första anblick verkar innehålla önskad funktionalitet. Innan testet genomförs kontrolleras att programmet verkar innehålla önskad funktionalitet samt för att inhämta kunskap om hur programmet fungerar.
En kravspecifikation som skall kunna ligga till grund för en eventuell framtida upphandling av GIS-programvara tas fram utifrån Socialförvaltningens krav. Den anpassade utvärderingsmallen ligger till grund för denna kravspecifikation.
3 Problem vid optimering av transporter i allmänhet
Optimering av transporter kommer in under begreppet logistik. Logistik kan förklaras med ett företags strävan att leverera rätt vara, i rätt kvantitet, på rätt plats, vid rätt tidpunkt och till lägst kostnad.
EU har gett ett direktiv för hur transporterna skall behandlas utifrån ett miljöperspektiv.
Transporterna genererar buller, skapar trängsel och leder till utsläpp av koldioxid (CO2) och andra farliga ämnen. Koldioxiden är ett hot mot klimatet på jorden då det kan leda till ökad växthuseffekt. Ökad onaturlig växthuseffekt är ett globalt miljöproblem som bland annat tros kunna leda till höjd medeltemperatur på jorden, stigande havsnivå och extrema väderförhållanden.
Det är av stort intresse miljömässigt att minska koldioxidutsläppen. Ett sätt att angripa detta på är att optimera transporterna så att exempelvis bilarna inte åker onödigt långa sträckor och därmed förbränner onödigt mycket bränsle. Förutom att förbränning av bränslet släpper ut koldioxid så kostar det också pengar. Med hjälp av Geografiska Informationssystem (GIS) kan transporterna optimeras så trängsel, koldioxidutsläpp och bränslekostnader minimeras. [2]
Problem vid optimering av transporter med GIS kan vara att de data som används som utgångspunkt vid planeringen är osäkert. Ofta måste antaganden göras i brist på
tillförlitliga data. Det kan också vara svårt att få tag i aktuella data som uppdateras i den takt som förändringar sker i vägnätet. Detta ger i slutändan resultat som inte bedöms som säkra. [4]
Nationella vägdatabasen (NVDB) produceras av Vägverket och skall samla alla vägar i Sverige i en rikstäckande vägdatabas. Tanken är att bygga upp en informationsstruktur som gör det möjligt att använda geografiska data inom många olika verksamheter som har anknytning till vägar. Ett problem med NVDB idag är att täckningsgraden inte är fullständig över hela Sverige. Även Navigation Technologies (NavTech) producerar vägdata över Sverige. NavTechs databas är den som idag håller högst kvalitet och störst täckningsgrad och därmed kan vara lämpligt underlag vid transportoptimering.
Geometrin har en noggrannhet som kan jämföras med Lantmäteriets Fastighetskartans vägnät. Exempel på intressanta attribut som finns i NavTechs data är enkelriktning, hastighet, svängrestriktioner. [3]
Många av GIS-programvarorna som är vanliga i Sverige idag har inte alla funktioner för att mata in den mängd parametrar som behövs. Detta gör att det blir mycket manuellt arbete och därmed inte tillräckligt lönsamt. [4]
4 Användning av GIS vid transportoptimering 4.1 Nätverksanalys
Nätverksanalyser innebär att studier av olika typer av flöden görs i exempelvis ett vägnät.
Kraven för att en nätverksanalys skall kunna genomföras är att vägnätsdatat har en topologisk uppbyggnad där alla enskilda linjesegment är ihopkopplade med varandra på ett riktigt sätt. För varje linjesegment anges de olika egenskaperna som exempelvis längd, vägbeläggning och hastighetsbegränsning.
Med hjälp av nätverksanalyser kan den kortaste alternativt den snabbaste vägen mellan två punkter bestämmas. Analyser kan också göras av hur långt exempelvis ett
utryckningsfordon som startar på en viss punkt hinner på en bestämd tid. Det går att planera en rutt där ett antal bestämda platser skall besökas och därefter den bästa vägen tillbaka till utgångspunkten skall beräknas. Denna nätverksanalysmetod brukar kallas
”traveling-salesman”-analys. [1]
Andra typer av tänkbara analyser är trafikbelastning på olika vägar i nätverket eller att planera exempelvis postutdelning där samtliga länkar i ett nätverk skall passeras.
4.2 Ruttoptimering
Ruttoptimering är vanligt när transporter skall planeras och är ett komplext problem då antalet parametrar som ligger tillgrund för beräkningarna är många och komplexiteten kan sägas öka exponentiellt med antalet parametrar. [3]
För att effektivisera optimeringsarbetet kan avancerade dataprogram användas. Förutom dataprogram behövs också data för att information i form av optimala körrutter skall kunna skapas.
Fördelar som kan vinnas genom ruttoptimering är exempelvis kortare körväg, mindre koldioxidutsläpp, mindre bensinkostnader, kortare arbetstid samt mindre slitage på bilarna eller behov av färre bilar tack vare effektivare nyttjande.
För att kunna göra ruttoptimering krävs ett uppdaterat adressregister, aktuella kartor, störningsinformation och information om normala trafikstockningar. Beräkningarna görs baserat på geografiska data och de teoretiska hastigheterna för vägarna. [2]
5 Lösningar på markanden 5.1 Andra kommuners lösningar
Många kommuner har upphandlat transporttjänster av företag. Det kan vara en anledning till att kommunerna i så liten utsträckning använder GIS i optimering av transporter.
Kommunerna har för lite transporter för att se möjlighet till betydande besparingar och vinster. De som har någon form av transportplanering har det huvudsakligen inom skolskjutsar, busslinjesträckningar, färdtjänst, räddningstjänst och sophantering. Det har framkommit att vissa kommuner har planer på att börja undersöka hur de kan använda GIS vid transportoptimering så snart NVDB blir färdigställd inom kommunen. Brist på vägdata med nätverkstopologi har här bromsat utvecklingen.
Att antalet invånare inte alltid är en indikator på hur långt en kommun kommit i GIS- användandet är Falkenberg med sina knappt 40 000 invånare bevis på. Falkenbergs kommun håller på att utarbeta ett system för transportplanering, för mjuka förvaltningars transporter, där de använder Cartesias programvara Solen. Solen är i grunden ett program utvecklat ur MapInfo. [8]
I Kristianstad används Intergraphs Geomedia WebMap för att tillhandahålla Internetkartor. Med dessa kan privatpersoner söka bästa vägen beroende på om
trafikanten är gångare, cyklist eller bilist. Användaren har möjlighet att ange startadress, måladress och en eller flera adresser som skall ingå i rutten. [12]
Kontakterna med kommunernas GIS-ansvariga resulterade i uppslag att gå vidare med även om ingen konkret lösning på planering av distributionen av mat och varor i Luleå kommun omedelbart hittades.
5.2 Transportföretags lösningar
Några av de transportföretag som kontaktats använder GIS och logistik i sin transportplanering. Här handlar det dock mest om positionering av fordon och flottstyrning, så kallad fleet management. Nedan följer exempel på två olika sådana lösningar.
Bland transportföretagen som kontaktades var det främst Adena Picko’s som var
intressanta. Detta företag finns över hela Sverige och har runt 450 fordon varav 80 fordon finns i Stockholmsområdet och dessa utför mer än 1000 budtransporter varje dag. I Stockholm har de ett datasystem där de från kontoret bland annat kan övervaka hur snabbt bilarna åker och vilken temperatur värmda och kylda transporter håller.
Datasystemet tar hänsyn till vilken storlek och typ ett fordon har vid planeringen.
Programvaran heter TransWare StreetWise och har utvecklats genom ett samarbete mellan B&M Systemutveckling AB i Uppsala och TransWare. [9]
Ett taxiföretag som använder GIS i stor utsträckning i verksamheten är Taxi Stor & Liten Gästrikland i Gävle. De har sedan november 2002 använt ett system där deras 70 taxibilar i Gästrikland positioneras med GPS. Kommunikationen mellan bilarna och
beställningscentralen sker via ett eget radionät och positionering av varje bil utförs varannan sekund.
Kartunderlaget består av en detaljerad tätortskarta som ligger ovanpå en mindre
detaljerad karta som täcker områden utanför tätorten. Företaget har delat in kartan i olika zoner och programmet visar vilka bilar som befinner sig inom varje zon. Bilarna
symboliseras på olika sätt beroende på om de är lediga, snart lediga, på rast eller är upptagna. När en beställning tas emot matas adressen för kunden in och programmet söker efter bilar inom zonen. Om det inte finns någon bil inom zonen vid tidpunkten görs sökningar i kringliggande zoner tills en ledig bil hittas. Föraren bekräftar om han eller hon vill ha körningen och om detta är fallet kommer beställarens adress upp på kartan i bilen. Bilarna är också utrustade med larm och när detta aktiveras visar
beställningscentralens dataskärmar den larmande bilens position och följer endast denna så hjälp kan dirigeras rätt. Företagen som skapat systemet är Holmedal Data AB som står för mjukvaran och Structab som tillhandahåller hårdvaran. Andra taxiföretag är
intresserade av systemet men i dagsläget så är det förutom Taxi Stor & Liten endast ett taxiföretag i Borås som använder det fullt ut. [7]
5.3 Några programvaror inom området
Här presenteras ett urval av de programvaror som finns på marknaden idag som används vid transportoptimering inom olika verksamheter. Programmen redovisas utan någon form av inbördes rangordning.
5.3.1 ArcLogistics Route
Environmental Systems Research Institute (ESRI) är ett amerikanskt företag som utvecklar GIS programvaror för många ändamål. ArcLogistics Route är en programvara för transportplanering. Den skiljer sig från ArcView Network Analyst genom att erbjuda mer avancerade färdiga analysfunktioner där Network Analyst fungerar som ett enklare optimeringsverktyg. Ett problem med ArcLogistics Route är att det är anpassat för amerikanska förhållanden både när det gäller den geografiska informationen och tid, datum och längdenhet. Data i form av geografisk information måste för att kunna hanteras av ArcLogistics ha enheten decimalgrader. Detta gör att det inte går att hantera data i koordinatsystemet RT90 med enheten meter, utan måste istället vara exempelvis i koordinatsystemet WGS84. För att vägnätet skall kunna hanteras måste det också finnas ett antal obligatoriska attribut. [3]
5.3.2 FetchPlanner
FetchPlanner utvecklas av B&M Systemutveckling AB i Sverige och är ett program för planering, uppföljning och kvalitetssäkring för olika typer av transporter inom
avfallshantering. Deras program används av flera transportföretag i Sverige. [13]
Programmet använder ruttoptimering för att beräkna bästa vägen för fordonen och företaget har föreslagit att programmets användargränssnitt eventuellt kan förenklas, för att passa kommunens specifika problem. Kartdatat som kan användas i programmet är MapInfo Tabfiles men hjälp med konvertering från andra dataformat går att ordna. [10]
5.3.3 GeoMedia Transportation Analyst
Intergraph utvecklar programfamiljen GeoMedia. GeoMedia Transportation Analyst är ett tillägg till GeoMedia alternativt GeoMedia Professional. GeoMedia Transportation Analyst har huvudsakligen funktioner kopplade till dynamisk segmentering och det visade sig under examensarbetet att funktioner för ruttoptimering saknades.
5.3.4 Route LogiX Professional och Plan LogiX
Dessa program är tillverkade av DPS och är utvecklade under samarbete med
transportföretag. Programmen är anpassade för svenska förhållanden med svenska som språk och medföljande Sverigekarta. Route LogiX Professional är det enklare
programmet av dem båda och används av ca 3000 användare i Sverige. Route LogiX är ett lämpligt program om transporter ska ske över större ytor och stopp på ett antal orter ska göras. Plan LogiX klarar av mer avancerade ruttoptimeringar och används av ca 30 företag i Sverige. [11] Plan LogiX beskrivs närmare i kapitel 9.3.2.
5.3.5 TransCAD
TransCAD utvecklas av Caliper Corporation och har fått stor spridning vad det gäller användning i USA. I Sverige finns detta program ännu bara på universitet och högskolor.
Programmet hanterar trafik- och transportplanering och själva ruttoptimeringen är endast en liten del av programmets funktionalitet. Möjlighet finns att göra avancerad
ruttplanering med många inparametrar. [5] Mer om programmets funktionalitet för ruttoptimering kan läsas i kapitel 9.3.1.
5.3.6 TransWare StreetWise
StreetWise är ett trafikledningssystem som med hjälp av GPS-mottagare kan kontrollera fordonens position. Trafikledaren kan skicka en körorder till föraren i fordonet som tar emot den på fordonsdatorn. Trafikledaren ser detaljer om varje bil så som order och position. Positionen visas på karta och trafikledaren kan enkelt ge närmaste bil en ny order. Detta program är anpassat för transportplanering, där översikt över och dirigering av fordonsflottan är målet och där nya uppdrag kommer in löpande. Programmet är flexibelt och går att anpassa till olika verksamheter genom att flertal moduler med olika funktionalitet för ruttoptimering. [14]
6 Utformning av generell utvärderingsmall
En generell utvärderingsmall utformades som skall kunna användas till att utvärdera program med GIS- och logistikfunktioner. Hänsyn har tagits till ruttoptimering och ruttplanering i allmänhet när det gäller tranporter med ett antal depåer och ett antal mottagare. Här behandlades inte det specifika fallet som Socialförvaltningens transporter av mat och varor innebär. En målsättning med mallen var att den skall ställa krav på alla parametrar som är aktuella vid denna typ av ruttoptimering. Denna mall skall sedan utvärderas genom att först anpassas till det specifika fallet och därefter användas vid test av de valda programmen
Parametrarna i den generella utvärderingsmallen viktades och poängsattes inte eftersom denna skulle hållas så generell som möjligt. Poängsättning och viktning är beroende av verksamheten i övrigt och är något som måste tas hänsyn till när den generella
utvärderingsmallen sedan anpassas till en specifik verksamhet.
Den generella utvärderingsmallen kan ses som en förteckning över parametrar som kan användas när en anpassad utvärderingsmall skall skapas. Inte förrän efter poängsättning och viktning kan den ligga till grund för själva programutvärderingen.
6.1 Parametrar
Parametrarna som utgör den generella utvärderingsmallen baserades på befintliga funktioner i program, matvarors krav på transporter, kontakt med programvaruföretag samt egna idéer. De parametrar som utformades grupperades i tre grupper: program, ruttoptimering och kartstöd. Inom grupperna sorterades parametrarna så att de som har liknande funktioner klumpades ihop. Detta gav en bättre översikt över parametrarna så det blev lättare att upptäcka om något saknades. Grupperna med parametrar visas i figur 6.1.
Figur 6.1: De parametrar som ingår i den generella utvärderningsmallen visas här samlade under respektive grupp.
En kort beskrivning ges här av varje parameter i den generella utvärderingsmallen. Den generella utvärderingsmallen som utformades bifogas som bilaga A.
6.1.1 Program
Denna grupp tar upp allmänna krav som ställs på applikationen.
Operativsystem
De krav som programmet ställer på typ av operativsystem, ex. Windows, Linux, Unix.
Teknisk plattform
De krav som programmet ställer på typ av dator, ex. PC och Macintosh.
Antal samtidiga användare
Hur många användare som samtidigt kan utnyttja programmet.
Dataformat som stöds
Vilka dataformat som kan hanteras av programmet. Utifrån denna parameter utformas speciella parametrar för de dataformat som är intressanta för verksamheten. ”Stöder ESRI shapefiles” och ”Stöder MapInfo tabfiles” är exempel på anpassade parametrar.
Språk
Vilket språk som menyer mm i programgränssnittet har, ex svenska eller engelska.
Användargränssnitt
Hur användaren kommunicerar med programmet, ex Windows-standard med mus- och tangentbordsbaserad kontroll eller kommandobaserat. Användargränssnittet kan vara mer eller mindre lättanvänt och graden av detta kan vara svårt att bedöma då det beror på användarens tidigare erfarenheter.
Lokalinstallation
Programmet installeras lokalt på användarens dator.
Serverinstallation
Programmet installeras centralt på en server som sedan nås över ett nätverk från användarens datorer.
Webbserverinstallation
Programmet installeras på en webbserver och nås över ett nätverk genom en webbläsare.
Dokumentation och manualer
Hur lättanvänd och välutvecklad programmets dokumentation och manualer är samt vilket språk som används i dessa.
Hjälpfunktion i programmet
Hur lättanvänd och välutvecklad programmets hjälpfunktion är samt vilket språk som används i denna.
Support
Hur lättillgänglig supporten är för programmet och på vilka språk denna kan erbjudas.
Utbildning
Om utbildning finns tillgänglig i Sverige för programmet.
6.1.2 Ruttoptimering
Denna grupp tar upp de krav som ställs på ruttoptimeringsfunktionen.
Nätverkstopologi (länkar och noder)
Om programmet kan hantera data med nätverkstopologi (länkar och noder) och använda detta vid ruttoptimeringen.
Inlärningströskel
Hur svårt det är att komma igång och arbeta med det nya programmet.
Arbetsinsats vid ruttoptimering
Hur mycket arbete användaren måste lägga ner innan ett färdigt resultat kan fås. Hur många och hur komplicerade arbetssteg som ligger bakom resultatet. Detta omfattar inte redigering av indata så att det går att använda som underlag.
Svarstid vid ruttoptimering
Hur snabbt själva ruttoptimeringen utförs av programmet. Här ingår inte alla arbetssteg utan endast programmets arbetstid för att utföra själva ruttoptimeringen när alla indata och eventuellt nödvändiga tabeller redan är skapade. Detta är naturligtvis helt beroende på vilken hårdvara som används men om testet görs på samma dator för alla program så kan en rättvis bedömning göras.
Balansering
Om programmet fördelar uppgifterna som ska utföras så jämnt som möjligt på alla tillgängliga fordon.
Optimera rutt utifrån kortaste körsträcka
Rutterna kan optimeras för att minimera körsträckan.
Optimera rutt utifrån kortaste körtid
Rutterna kan optimeras för att minimera körtiden.
Beräkning av körsträcka
Beräkning kan göras av hur lång körsträcka fordonen får på rutterna.
Beräkning av körtid
Beräkning kan göras av hur lång körtid fordonen får på rutterna.
Beräkning av antal fordon
Beräkning kan göras av hur många fordon som behövs för att klara av rutterna inom givna tidsramar.
Start- och slutpunkt
Start- och slutpunkt behöver inte alltid vara samma plats.
Stopptid
Det går att ställa in hur lång tid stoppen tar vid mottagarna.
Individuell stopptid
Det går att ställa in olika stopptider vid varje stoppunkt.
Maxtid för rutt
Den maximala tiden som en rutt får ta att åka.
Spara rutter
Det går att spara de rutter som skapats för användning vid ett senare tillfälle.
Redigera rutter
Det går att göra ändringar i rutter manuellt om mindre förändringar är önskvärda.
Öppna/Ladda rutter
Sparade rutter kan öppnas och användas igen.
Körorder för rutt/rutt i tabellform
När en rutt skapats kan en beskrivande körorder eller tabell för denna visas. Denna innehåller information om hur rutten ska köras och tid eller avstånd mellan stoppunkter.
En depå
Endast en depå kan ingå i ruttoptimeringen.
Flera depåer
Flera depåer kan ingå i ruttoptimeringen.
Tidsfönster för depå
Ett eller flera tidsfönster kan ställas in där depåns öppettider anges.
Redigera depåer
Depåer kan läggas till, tas bort och egenskaper kan förändras. Gränssnitt finns för att redigera datat inne i programmet. (Om detta inte är fallet måste nya data läsas in efter att först ha redigerats utanför programmet.)
Stoppunkter
Hur många stoppunkter som kan hanteras vid varje optimeringstillfälle.
Mängd som ska levereras till varje stoppunkt
Antal varor som ska levereras till mottagaren vid varje stoppunkt.
Tidsfönster för stoppunkter
Mellan vilka tider varor kan mottagas vid stoppunkterna.
Redigera stoppunkter
Stoppunkter kan läggas till, tas bort och egenskaper kan förändras. Gränssnitt finns för att redigera datat inne i programmet. (Om detta inte är fallet måste nya data läsas in efter att först ha redigerats utanför programmet.)
Ett fordon
Ruttplanering kan endast ske med ett fordon åt gången.
Flera fordon
Ruttplanering kan ske för flera fordon samtidigt. Eventuell begränsning av antalet fordon kan förekomma.
Olika typer av fordon
Olika typer av fordon kan definieras och tilldelas unika egenskaper. Dessa kan sedan, automatiskt eller manuellt, väljas för att leverera vissa typer av varor.
Arbetstid för förare
De tider då föraren är tillgänglig kan anges och tas med i optimeringen.
Driftkostnad
Driftkostnad för fordonet kan anges och därur kan kostnaden för rutten räknas ut, ex kostnad/tid, kostnad/sträcka.
Lastkapacitet
Hur mycket ett fordon rymmer av en viss typ av vara.
Hastighet för fordon på olika typer av vägar
Vilken hastighet ett visst fordon i snitt håller på en viss typ av väg, ex stadstrafik 20 km/h.
Varuegenskaper
Varutypens egenskaper så som krav på leveranstid och krav på fordon, ex varm mat ska levereras inom en timme och tar upp en viss volym i fordonet.
Flera dagar samtidigt
Ruttplaneringen kan göras för flera dagar samtidigt, ex för en hel vecka.
Flera varutyper samtidigt
Ruttplaneringen kan göras för flera olika varutyper samtidigt, ex varm mat, kall mat och varor.
Förbjudna vägar
Vägar kan manuellt på ett enkelt sätt förbjudas om dessa på grund av tillfälliga trafikstörningar inte får användas till transporter, ex vid vägarbete.
Svängrestriktioner
Fördröjningseffekt i korsningar beroende på vänstersväng, högersväng, korsande av huvudled med mera kan tas med i ruttplaneringen.
Trafikflödespåverkan
Hänsyn kan tas till hastighetsnedsättande effekt beroende på trafikflödet vid olika tidpunkter, ex 50 % av hastigheten mellan 16.00 och 17.00.
Undvik platser
Vägar som går i närheten av platser där fordonen helst inte ska passera kan manuellt, på ett enkelt sätt, markeras och undvikas, ex en skola där så lite trafik som möjligt ska passera eller en vattentäckt som gifttransporter bör undvika.
Utskrift av karta
Kartan som visas på skärmen kan skrivas ut.
Utskrift av körorder
Körordern som skapats kan skrivas ut.
Utskrift av tabell
Rutten i tabellform kan skrivas ut.
6.1.3 Kartstöd
Denna grupp tar upp de krav som ställs på kartstödet som är kopplat till ruttoptimeringen.
Visa karta
En karta kan visas på skärmen och denna kan visa stoppunkter och depåer samt vägnätet som ska användas vid transporterna.
Visa rutt på karta
Rutterna som optimerats för fordonen kan visas på kartan.
Zooma in
Inzoomning kan göras stegvis eller via markering i kartan.
Zooma till rutt
En vald rutt kan zoomas in endast genom en knapptryckning, inte samma som att använda zooma in och göra detta manuellt över rutten.
Zooma till full extent
Zoomning kan göras till kartans fulla omfattning.
Zooma ut
Utzoomning kan göras stegvis eller via markering i kartan.
Föregående kartbild
Föregående kartbild kan tas fram igen.
Panorera
Användaren kan förflytta sig i kartan för att se kringliggande områden.
Visa koordinater för muspekaren
Koordinater för muspekarens position i kartan kan visas.
Visa kartskala/måttstock
Kartan är utrustad med måttstock eller kartans skala visas.
Användarstyrd skala
Användaren kan själv ange önskad skala alternativt välja mellan några fasta skalor.
Informationsverktyg
Information kan fås om exempelvis depåer och stoppunkter genom att användaren klickar på dessa i kartan.
Sökverktyg
Användaren kan söka efter en plats på kartan genom att skriva in exempelvis en adress.
7 Anpassning av utvärderingsmallen utifrån Socialförvaltningens behov
7.1 Anpassad utvärderingsmall
Den anpassade utvärderingsmallen utformades utifrån den generella utvärderingsmallen för att svara mot Socialförvaltningens krav på mat- och varutransporter. Endast de parametrar som var av vikt för den speciella tillämpningen togs med.
Resultatet bestod i ett antal parametrar som kan vara mer eller mindre uppfyllda. För varje parameter gjordes poängsättning av uppfyllnadsgrad, och viktning utifrån hur viktig en parameter är jämfört med andra parametrar.
Den anpassade utvärderingsmallen som utformats med ”skall-krav”, poängdefinitioner och vikter bifogas i bilaga B.
7.1.1 ”Skall-krav”
Några av parametrarna, ”skall-kraven”, är viktigare än andra och måste alltid vara uppfyllda. ”Skall-kraven” är minimikrav för grundläggande funktioner som måste uppfyllas för att programmet ska vara användbart för socialförvaltningen. Om dessa inte uppfylls är programmet inte av intresse och kan direkt gallras bort från testprogrammen.
Här beskrivs parametrarna som klassats som ”skall-krav”.
Optimera rutt utifrån kortaste körtid
En optimering skall kunna göras så att den väg som ger kortast körtid tas fram.
Beräkning av körsträcka
Beräkning av körsträcka skall kunna göras för att kunna kontrollera hur mycket sträckan kostar att köra.
Beräkning av körtid
Beräkning av körtid skall kunna göras för att ge möjlighet att kontrollera hur lång tid en sträcka tar att köra.
Visa rutt på karta
Rutter skall kunna visas i kartfönster i programmet.
Körorder för rutt/rutt i tabellform
En körorder för rutter skall kunna skapas för att presenteras i programmet. Denna skall innehålla nödvändig information för att föraren skall förstå hur rutten ska köras.
7.1.2 Poängsättning och viktning
Utifrån hur bra en parameter uppfylls gavs olika betyg på en skala noll till fyra. Noll hade betydelsen att funktionen inte fanns tillgänglig, alternativt inte uppfyllde
Socialförvaltningens lägsta krav, och fyra stod för att funktionen var mycket väl godkänd.
Nivåerna ett till tre användes i vissa fall för att åskådliggöra uppfyllnadsgrad där emellan.
Om en parameter bara kan vara sann eller falsk står noll för att funktionen inte finns och fyra för att den finns. För varje parameter definierades vad de olika poängnivåerna motsvarade i funktionalitet.
Vikningen gjordes i tre nivåer där poängen som tilldelats programmet för en viss parameter multiplicerades med den aktuella vikten. Nivåerna var:
· ett: liten betydelse
· två: medelstor betydelse
· tre: stor betydelse
Här följer en definition för poängnivåerna samt motivation för viktning för varje parameter som valts ut att ingå i den anpassade utvärderingsmallen.
Program Operativsystem
Eftersom Windows är det vanligaste operativsystemet på kommunen har denna parameter poängsatts enligt följande:
0: programmet är inte Windowskompatibelt.
4: programmet är Windowskompatibelt.
Parametern har viktats högt (3) på grund av att den är en elementär förutsättning för att systemet ska fungera.
Teknisk plattform
Eftersom PC är den vanligaste tekniska plattformen på kommunen har denna parameter poängsats enligt följande:
0: programmet är inte PC-kompatibelt (exempelvis Macintosh).
4: programmet är PC-kompatibelt.
Parametern har viktats högt (3) på grund av att den är en elementär förutsättning för att systemet ska fungera.
Antal samtidiga användare
Socialförvaltningen har inga speciella krav på antal användare så därför har parametern tilldelats följande poängskala:
3: endast en användare i taget tillåts.
4: programmet tillåter flera användare.
Av samma skäl har parametern viktats lågt (1).
Stöder ESRI Shapefiles; Stöder MapInfo Tab; Stöder NVDB; Stöder Excel; Stöder Access
0: formatet stöds inte av programmet.
4: formatet stöds av programmet.
Kommunen använder idag ESRI Shapefiles och därför har stöd för detta format viktats högt (3). Eftersom MapInfo är ett vanligt förekommande GIS-program har denna parameter tagits med, den är däremot inte så viktig och har därmed viktats lågt (1). På grund av kommunens planer att använda NVDB när denna blir klar för Luleå så har denna parameter viktats högt (3). Vid import av stoppunkter och depåer till programmet är det önskvärt att exempelvis Excel kan användas. Detta på grund av att data om de personer som får mat kan exporteras till detta format. Parametern har viktats högt (3) på grund av detta. I framtiden kan det tänkas att datahämtning önskas ske från databasfiler som exempelvis Access. Denna parameter har viktats lågt eftersom det är osäkert om den kommer att ha betydelse i framtiden.
Språk
De alternativ som ges är:
0: obegripligt språk.
2: begripligt språk men ej svenska.
4: svenska.
Då språket ofta är en förutsättning för att programmet ska kunna användas har denna parameter viktats högt (3).
Användargränssnitt De alternativ som ges är:
1: kommandobaserat användargränssnitt.
4: Windows-standard med menyer och knappar.
Användargränssnittet har stor betydelse för hur lättarbetat programmet är och har viktats högt (3).
Lokal installation; Serverinstallation 0: installationstypen är inte möjlig.
4: installationstypen är möjlig.
Viktas lågt (1) då det inte spelar så stor roll hur installationen sker bara programmet fungerar som det är tänkt.
Dokumentation och manualer; Hjälpfunktion i programmet Dessa parameter har fem nivåer:
0: saknas.
1: bristfällig.
2: acceptabel.
3: bra med begripligt språk men ej svensk.
4: bra svensk.
Dokument och manualer är en viktigt och parametern viktas högt (3) för att användaren ska få ut så mycket som möjligt av programmet. Det är bra om hjälpfunktion finns men inte jätteviktigt, därav vikten (2).
Support
Som alternativ ges:
0: obegriplig.
1: begriplig men ej svensk (exempelvis engelska, norska, danska).
4: svensk. Parametern viktas högt (3) då det är viktigt att kunna få hjälp om problem uppstår.
Utbildning i Sverige
0: utbildning saknas i Sverige.
4: utbildning finns i Sverige.
När det är ett helt nytt program för användarna är det viktigt att det finns möjlighet till utbildning, därav hög viktning (3).
Ruttoptimering
Nätverkstopologi (länkar och noder)
0: programmet kan inte hantera nätverkstopologi.
4: programmet kan hantera nätverkstopologi.
Denna parameter skulle kunna vara ett ”skall-krav”, men då det inte framkommit under examensarbetets gång ifall andra likvärdiga lösningar finns för att optimera rutter valdes att istället vikta parametern högt (3).
Inlärningströskel
Denna parameter har getts två alternativ 1: hög tröskel.
4: låg tröskel.
Då det är väldigt personligt hur inlärningströskeln upplevs så är det svårt att ge en objektiv mer nyanserad poängskala än detta. Parametern har stor betydelse för hur programmet tas emot av användarna och har viktats högt (3).
Arbetsinsats vid ruttoptimering
1: hög arbetsinsats (omfattande arbete med många och komplicerade operationer).
4: låg arbetsinsats (få och enkla operationer för att komma fram till resultatet).
Parametern har stor betydelse för hur programmet tas emot av användarna och har viktats högt (3).
Svarstid vid ruttoptimering
Denna parameter har delats upp i alternativen:
0: mer än 15 min.
1: 5-15 min 2: 31 s-5 min 3: 11-30 s 4: 0-10 s
Detta bedöms dock inte ha så stor betydelse för verksamheten och har viktats lågt (1).
Balansering
0: balansering av arbetsbelastning på samtliga fordon utförs ej.
4: balansering utförs av arbetsbelastning på samtliga fordon.
Denna parameter har viktats högt (3) då det är viktigt för ruttoptimeringen att arbetsbelastningen blir jämnt fördelad över fordonen.
Optimera rutt utifrån kortaste körsträcka 0: funktionen finns inte.
4: funktionen finns.
Det är bra om det går att göra detta men det är inte nödvändigt och parametern har viktats medelhögt (2).
Beräkning av antal fordon 0: detta är inte möjligt.
4: detta kan göras.
Då detta är ett av Socialförvaltningens mål med programmet har det viktats högt (3).
Start- och slutpunkt
0: startpunkten måste alltid vara densamma som slutpunkten 4: start- och slutpunkt kan vara olika platser.
Denna parameter är viktig (3) för att kunna göra verklighetstrogna analyser eftersom rutten inte alltid behöver avslutas vid depån.
Individuella stopptider
0: individuella stopptider kan inte ställas in.
4: individuella stopptider kan ställas in.
Det är möjligt att utifrån önskade individuella stopptider beräkna ett medelvärde.
Medelvärdet används sedan som stopptid vid stoppunkterna och medför att hålltiderna vid stoppunkterna för rutten inte stämmer men totaltiden blir riktig. Eftersom det finns en metod att kringgå individuella stopptider viktas denna parameter medelhögt (2) trots dess höga betydelse.
Stopptid
0: stopptid kan inte ställas in.
4: stopptid kan ställas in.
Det är viktigt att stopptiden kan anges för att rutten ska bli verklighetstrogen och parametern viktas högt (3).
Maxtid för rutt
0: maximal tid för rutt kan inte anges.
4: maximal tid för rutt kan anges.
Då mattransporter är hårt styrda av tidsbegränsningar viktas denna parameter högt (3).
Spara rutter/öppna sparade rutter 0: rutter kan inte sparas.
4: rutter kan sparas för senare bruk.
Parametern har viktats högt (3) eftersom det är arbetsbesparande att kunna återanvända tidigare rutter.
Redigera rutter
0: rutter kan inte redigeras manuellt.
4: rutter kan redigeras manuellt.
Parametern har viktats högt (3) eftersom det är bra att kunna gå in och göra manuella ändringar.
Flera depåer (ev. begränsning)
Då de antal depåer som finns idag är sex stycken så bör programmet kunna hantera fler än sex depåer och därav poängsättningen.
0: antalet depåer som kan hanteras i ruttoptimeringen är färre än sex stycken.
2: sex till nio depåer kan hanteras.
3: tio till fjorton depåer kan hanteras.
4: femton eller fler depåer kan hanteras.
Viktas högt (3) då det idag finns flera depåer som används och det kan komma att förändras i framtiden.
Tidsfönster för depå
0: tidsfönster för depå kan inte anges.
4: tidsfönster kan anges.
Om detta inte kan anges tilldelas noll (0) poäng. Viktas högt (3) då det är viktigt att kunna ange inom vilka tider varor kan hämtas från depåerna.
Redigera depåer
0: depåers egenskaper kan inte redigeras.
4: egenskaperna kan redigeras manuellt i programmet.
Viktas högt (3) då depåernas egenskaper kan komma att ändras och det är önskvärt att kunna redigera manuellt i programmet.
Stoppunkter (ev. begränsning)
Då antalet stoppunkter idag är kring 300 bör detta överskridas därav poängsättningen.
0: noll till nio stoppunkter kan hanteras.
1: tio till 99 stoppunkter kan hanteras.
2: 100 till 399 stoppunkter kan hanteras.
3: 400-499 stoppunkter kan hanteras.
4: fler än 500 stoppunkter kan hanteras.
Viktas högt (3) då detta är en grundläggande förutsättning för problemet.
Mängd som ska levereras till varje stoppunkt 0: mängd kan inte anges.
4: mängd som skall levereras kan anges.
Viktas högt (3) då det är viktigt att kunna ange detta för att veta hur många stopp ett fordon klarar av innan det måste fyllas på igen.
Tidsfönster för stoppunkter 0: tidsfönster kan inte anges.
4: tidsfönster kan anges.
Viktas högt (3) då det är viktigt att kunna ange inom vilka tider varor kan tas emot vid en stoppunkt.
Redigera stoppunkter
0: stoppunkters egenskaper kan inte redigeras.
4: stoppunkters egenskaper kan redigeras manuellt i programmet.
Viktas högt (3) då stoppunkternas egenskap kommer att behöva ändras ofta och det är önskvärt att göra detta manuellt i programmet.
Flera fordon
Då antalet fordon idag är kring sex stycken så bör detta antal kunna hanteras.
0: programmet kan inte hantera flera fordon samtidigt.
1: programmet kan hantera upp till fem fordon samtidigt.
3: programmet kan hantera sex till nio fordon samtidigt.
4: programmet kan hantera tio eller fler bilar samtidigt.
Viktas medelhögt (2) då detta har betydelse för mängden arbete som måste genomföras för optimering men inte är avgörande för att få ut ett resultat.
Lastkapacitet
0: lastkapacitet för fordon kan inte anges.
4: lastkapacitet för fordonen kan anges.
Viktas högt (3) då detta är viktigt för optimeringsarbetet ska ge goda resultat.
Hastighet för fordon på olika typer av vägar
0: varierande hastighet beroende på fordon och vägtyp kan inte anges.
4: varierande hastighet beroende på fordon och vägtyp kan anges.
Viktas medelhögt då detta förenklar optimeringsarbetet och kan öka tillförlitligheten i resultatet.
Varuegenskaper
0: varors krav på transporttid och lastkapacitet per enhet kan inte anges.
4: varors krav på transporttid och lastkapacitet per enhet kan anges.
Viktas lågt (1) då det inte direkt avgörande för om optimering kan göras.
Flera dagar samtidig
0: det går endast att planera för ett tillfälle i taget.
4: flera dagars planering kan göras samtidigt.
Viktas lågt (1) då planering dag för dag är acceptabelt.
Flera varutyper samtidigt
0: det går endast att planera för en varutyp i taget.
4: flera varutyper kan planeras samtidigt.
Viktas lågt (1) då det är acceptabelt att planera varornas transporter individuellt.
Förbjudna vägar
0: vägar kan inte förbjudas.
4: vägar kan förbjudas.
Viktas lågt (1) då detta inte är en avgörande funktion för optimeringen.
Utskrift av karta; Utskrift av tabell/körorder 0: funktionaliteten saknas.
4: funktionaliteten finns.
Funktionerna är av stor betydelse när det gäller att utnyttja ruttoptimeringen som skapats och har viktats högt (3).
Kartstöd
Zooma in och zooma ut 0: funktionaliteten saknas.
4: funktionaliteten finns.
Denna funktion är önskvärd för att få ut så mycket som möjligt av kartstödet och viktas medelhögt (2).
Zooma till rutt; Zooma till full extent; Föregående kartbild 0: funktionaliteten saknas.
4: funktionaliteten finns.
Funktionerna är önskvärda men har ingen avgörande betydelse och har viktats lågt (1).
Panorera
0: funktionaliteten saknas.
4: funktionaliteten finns.
Denna funktion är önskvärd för att få ut så mycket som möjligt av kartstödet och viktas medelhögt (2).
Visa kartskala/måttstock; Visa koordinater för muspekaren; Användarstyrd skala 0: funktionaliteten saknas.
4: funktionaliteten finns.
Funktionerna är önskvärda men har ingen avgörande betydelse och har viktats lågt (1).
Informationsverktyg; Sökverktyg 0: funktionaliteten saknas.
4: funktionaliteten finns.
Funktionerna är önskvärda men har ingen avgörande betydelse och har viktats lågt (1).
7.2 Framtagande av kravspecifikation som kan användas vid upphandling
Kravspecifikationen utformades med den anpassade utvärderingsmallen som grund och är tänkt att kunna ligga som grund till en eventuell upphandling av en programvara.
Kravspecifikationen tar upp bakgrunden till applikationsbehovet och beskriver den önskade applikationens funktionalitet. Beskrivningen av applikationen delades upp i bakgrund, omfattning, förutsättningar, allmänna krav, ruttoptimering och utbildning.
Ruttoptimering beskriver de krav som ställs på programmets hantering av stoppunkter, depåer, leveranstyper, fordon, vägdata och funktioner för ruttoptimeringen. Här ingår också kartstöd, export av data och eventuella övriga funktioner som den potentiella leverantören vill framhäva.
Kravspecifikationen som framtagits bifogas i bilaga C.
8 Utvärdering av GIS-programvara med logistikfunktioner
8.1 Val av verktyg
De programvaror som valdes ut för att testas var TransCAD (Caliper Corporation) och Plan LogiX (DPS). Dessa programvaror valdes på grund av att det fanns tillgång till utvärderingslicenser av dessa programvaror samt att de har haft funktioner för trafikanalyser. Tillgång fanns också till Route LogiX Professional (DPS) men detta program ansågs inte hålla tillräckligt hög nivå funktionsmässigt för att vara värt att testa.
GeoMedia Transportation Analyst (Intergraph) var ett av programmen som från början skulle testas men detta program visade sig sakna funktioner för ruttoptimering och behandlade endast trafikanalyser som hade samband med dynamisk segmentering. Även FetchPlanner (B&M Systemutveckling AB) var från början tänkt att ingå i testet, men på grund av specialiseringen på sophämtning kunde inte Socialförvaltningens nytta av programmet testas.
8.2 Test
8.2.1 TransCAD
Det första programmet som genomgick testet var TransCAD version 4.0. TransCAD kräver vägdata i form av noder och länkar. Innan ruttoptimering kan ske måste vägdatat nätverksbildas. Detta innebär att ett virtuellt nätverk skapas utifrån det egentliga datat.
Varje länk bildar en sträcka i varje riktning längs länken. Detta förklaras närmare i figur 8.1.
Figur 8.1: För att kunna bestämma flödesriktning och begränsa flöden av till exempel trafik genom enkelriktningar krävs att data har nätverkstopologi. Då har varje länk två flödesriktningar och om länken är enkelriktad ”förbjuds” den ena riktningen så att flöde endast kan ske i en riktning. Exempelvis en länk där flödet endast får ske från nod A till nod B ”förbjuds” flödet från nod B till nod A. I bilden är flödet tillåtet i båda riktningar.
Depåer och stoppunkter skall finnas lagrade i ett punktskikt och skall innehålla egenskaper såsom exempelvis tidsfönster och stopptider.
Vid ruttoptimering skapas först en ”routing matrix” som är en tabell där avstånd eller restid mellan samtliga depåer och stoppunkter. Därefter skapas en fordonstabell där användaren anger vilka fordon som finns tillgängliga vid varje depå samt fordonens egenskaper såsom exempelvis lastkapacitet. TransCAD kan utifrån indatat optimera rutterna och visa dem på kartan. Figur 8.2 ger en bild av användargränssnittet i TransCAD och visar hur rutterna symboliseras i kartan.
Figur 8.2: Användargränssnittet i TransCAD. Här visas två depåer ”Free Port Depot” och ”The Docks”.
Ett antal stoppunkter besöks i rutterna som symboliseras med olika färger och pilarna visar hur rutterna löper.
Testgenomförande
Till att börja med gjordes ett test utifrån de exempeldata som levererats med TransCAD.
Detta gav en möjlighet att snabbt få en överblick över de funktioner som fanns
tillgängliga för ruttoptimeringen. Därefter undersöktes hur data som finns på kommunen med vägnät och adresspunkter fungerade i miljön. Vägnätet i shapeformat lästes in,
konverterades till TransCADs Geographic file och därefter kunde ett virtuellt nätverk skapas. Även punktskikten med depåer och stoppunkter gick bra att läsa in i programmet.
Problemen dök upp när det var dags att ställa in alla olika inparametrar till
ruttoptimeringen. Datat med stoppunkter måste anpassas för att ruttoptimering ska kunna göras. Attributen måste anges med rätt datatyp och antagligen måste adresserna
struktureras så att det blir flera tabeller uppdelade på typ av matleveranser. TransCAD kan inte hantera flera tidsfönster samtidigt som exempelvis lunchleverans och
middagsleverans i samma optimeringsomgång. Då det inte fanns tid att anpassa indatat under examensarbetet kunde ingen test med kommunens data genomföras. En annan sak som ställer till problem är att det skall definieras fordon för varje depå. Om det istället är önskvärt att ange hur många bilar som finns tillgängliga, och i optimeringen använda dessa på bästa sätt genom att fördela dessa på rutterna, klarar inte programmet av detta.
Testresultaten som baserats på tillrättalagda data som levererats tillsammans med TransCAD redovisas i bilaga D.
8.2.2 Plan LogiX
Det andra programmet som testades var Plan LogiX version 4.20. Med programmet följer två vägkartor en över hela Sverige med låg detaljrikedom och en över södra Sverige med lite högre detaljeringsgrad. Det går också att använda vägdata från NavTech tillsammans med programmet. Företaget som har tillverkat programmet rekommenderar att NavTechs data används vid ruttoptimering. En rasterkarta kan också ingå men denna används bara som bakgrund och har inget med optimeringen att göra.
När programmet startas ska först en ”Workarea” skapas och de data som ska bilda vägnätet väljs ut. Gränssnittet i programmet är enkelt med stora knappar vars funktioner också återfinns i menyerna. Egenskaperna som ska ställas in för fordon, varor och depåer finns samlade under samma knapp och är lätta att hitta.
Även Plan LogiX använder en matris i ruttoptimeringen och denna kan skapas utifrån kortaste körsträcka alternativt kortast körtid mellan olika punkter. Inställningar kan göras så att hänsyn tas till önskad hastighet på olika typer av vägar. Programmet skapar en egen standardmatris men i vissa fall kan det vara bra att göra en egen matris. En funktion finns för att testa om en ny matris behöver definieras och om detta är fallet görs det med hjälp av en snabbguide som ingår i programmet. De data som ligger till grund för matrisen är depåer och orderdata (stoppunkter) samt vägkarta.
Stoppunkterna kan läggas till i programmet genom att adressen skrivs in och
stoppunkterna skapas en i taget efter varandra. Detta sker genom bakvänd geokodning med så kallade gazetteer (Geokodning är när användaren har ett objekt och tillför en lägesangivelse och gazetteer används när användaren har en lägesangivelse och vill skapa ett objekt). Det finns också en importfunktion där punkterna skapas utifrån exempelvis ett Excel-dokument eller en Accessdatabas som importeras till programmet. Här gäller det att datat är strukturerat på ett bestämt sätt för att det ska kunna läsas in. Figur 8.3 ger en bild av användargränssnittet i programmet.
Figur 8.3: Användargränssnittet i Plan LogiX. Rutten visas på kartan och fordonet ska i detta fall besöka två stoppunkter och därefter återvända till depån.
Testgenomförande
De stoppunkter som fanns tillgängliga från kommunen i ESRI-shapefiles gick inte att importera i programmet och det fanns inte några detaljerade data över Luleå kommun.
Under testets genomförande användes istället NavTechs data över Gotland. Detta är data som innehåller information ner på gatunivå inom Visby samt landsvägar utanför. Försök gjordes att importera stoppunkter från en Excel-fil men detta lyckades inte, troligen beroende på att filen inte uppfyllde kraven på hur datat ska vara utformat.
Ett antal stoppunkter och depåer skapades och placerades ut på kartan över Gotland för att användas i ruttoptimering. Ett fordon skapas med egenskaper för lastkapacitet. Depåer skapas med möjlighet att definiera två tidsfönster, exempelvis öppettider för för- och eftermiddag. För att skapa en rutt väljs vilken depå som rutten ska starta vid och vilket fordon som ska köra rutten. Sedan lades stoppunkterna in i rutten genom att klicka på dessa i kartan och en optimering av rutten kunde göras.
Funktioner finns för att planera för flera fordon eller rutter samtidigt. När rutterna skapats fanns det möjlighet att redigera dem i efterhand, rita ut en i taget på kartan och skapa en körorder.
9 Diskussion
9.1 Generell utvärderingsmall
Den generella utvärderingsmallen anpassades till Socialförvaltningens krav för att kunna testas. För att få ett säkrare mått på hur bra mallen är skulle den kunna testas i flera verksamheter än endast mat- och varutransporter som nu var fallet. Exempel på andra verksamheter där mallen skulle kunna nyttjas är färdtjänst, sophantering, skolskjutsar, budbilar och taxi.
Genom att testa mallen utifrån den anpassning som gjorts kan parametrar som saknas och borde finnas med i den generella mallen upptäckas. Det är däremot svårt att säga att en parameter som finns med i den generella mallen är onödig då den kanske bara är överflödig i det specifika fallet. För att säkerställa att alla parametrar är relevanta måste test göras inom samtliga verksamhetsområden där den generella utvärderingsmallen skall kunna ligga till grund för test av program.
När det första programmet testades saknade vi en parameter i utvärderingsmallen. Denna parameter var ”grad av arbetsinsats vid ruttoptimering” och omfattade inte anpassning av själva datat som skulle användas vid ruttoptimeringen, utan de steg som omfattade ruttoptimeringen i sig. En sådan parameter anges lämpligen inte i tidsangivelser eftersom olika användare arbetar olika snabbt, utan istället i grad av arbetsinsats. Vi föreslår en gradering för poängsättningen av typen 1-hög arbetsinsats och 4-låg arbetsinsats. Med låg arbetsinsats menar vi här få arbetssteg som är lätta att utföra för att komma fram till ett resultat. Med hög arbetsinsats menar vi omfattande arbete i många och komplicerade steg för att nå slutmålet.
Inlärningströskel är också något som har betydelse för hur ett program upplevs. Denna varierar mellan olika användare med olika tidigare erfarenhet och inlärningsförmåga.
Inlärningströskeln är ett hinder i början för den nye användaren medan det inte hindrar den användare som kommit över tröskeln och har lärt sig hur programmet fungerar.
Inlärningströskeln är svår att bedöma eftersom det är olika hur olika personer uppfattar situationen att lära sig ett nytt program.
Efter studier av data anpassat till ruttoptimering fick vi nya uppslag till rimliga
parametrar i den generella utvärderingsmallen. Den information som finns i datat måste kunna hanteras av programmet för att vara till någon nytta och det ledde till följande tänkbara tillägg till den generella utvärderingsmallen. Programmet ska kunna ta hänsyn till: förbjuden genomfart, tillåtna fordonstyper (varuleveranser, bussar, taxi, personbilar osv.), maxvikt för fordon, maxhöjd för fordon, väghållare, differentierad körhastighet, normalt trafikflöde och normala trafikstockningar. Parametrar som kostnad och konverteringsmöjligheter för dataformat är något som också bör ingå i
utvärderingsmallen. Mallen har dock inte kompletterats med detta då tiden för examensarbetet inte räckt till.
9.2 Anpassad utvärderingsmall
Det är viktigt med förankring av den anpassade utvärderingsmallen och
kravspecifikationen hos dem som skall använda programmet i sin verksamhet. Detta kan göras genom att dessa personer får vara med redan i starten och lämna önskemål och synpunkter som sedan kan ligga till grund för det fortsatta arbetet.
9.2.1 ”Skall-krav”
Det gäller att vara försiktig när ”skall-krav” bestäms så att det inte blir en för stor
begränsning när det är dags att utvärdera ett program. Om detta är fallet kan det hända att ett potentiellt program utesluts i ett tidigt stadium utan att det har fått chansen att visa sina förtjänster.
9.2.2 Poängsättning
Poängsättningen av uppfyllnadsgrad för den anpassade utvärderingsmallen var svår. Det gäller att utforma skalan så den visar hur bra en parameter uppfylls. Hur många
poängnivåer som skall användas är en fråga som dyker upp skalan skall utformas.
Svårigheten är att hitta en skala som klarar av att urskilja programfunktionalitetens variationer men som samtidigt inte är så detaljerad att det blir svårt att avgöra vart ett visst programs funktionalitet hör hemma. Från början hade vi tänkt ha följande skala:
· 0: ”funktionaliteten finns inte”
· 1: ”funktionaliteten finns”
Utöver denna skulle vi ha en skala som var 0-5 där en parameter kunde anta olika värden utifrån hur hög uppfyllnadsgraden var. Detta förslag övergavs dock eftersom vissa parametrar på detta sätt som mest kunde skrapa ihop 1 poäng då andra hade möjlighet att få hela 5 poäng. Därav blev skalan istället:
· 0: ”funktionaliteten finns inte”
· 5: ”funktionaliteten finns”
där endast dessa värden kunde antas.
Under tiden som poängskalorna definierades och varje parameter tilldelades
uppfyllnadskrav för olika poäng framgick att en av poängnivåerna aldrig användes då det var svårt att definiera kraven så detaljerat. Betygskalan gjordes om till att endast omfatta nivåerna 0-4 istället för 0-5.
9.2.3 Viktning
Frågor som måste ställas när det är dags att vikta utvärderingsmallen är hur många nivåer viktningen skall göras i och hur stora vikter som skall användas. Används för få nivåer blir det svårt att särskilja parametrarnas betydelse. Om istället för många nivåer används blir det svårt att hålla reda på hur viktiga alla parametrarna är i förhållande till varandra.
Det bestämdes att tre nivåer skulle användas:
· 1: ”parametern har liten betydelse”
· 2: ”medelstor betydelse”
· 3: ”stor betydelse”
Vikterna speglar den personliga värderingen av hur viktigt det är att viss funktionalitet finns och när det är över 50 parametrar som skall vägas in så kan det bli svårt att hålla isär alla så de får en rättvis viktning. Tre nivåer kändes ändå ganska rimligt att hantera.
Vi har funderat på att ha en större skillnad på viktningen så att det ger större utslag för skillnader mellan olika parametrars betydelse. Vi bestämde oss dock för att detta inte hade så stor betydelse då vi ser utvärderingsmallen som ett sätt att få en visuell överblick i hur olika program förhåller sig till varandra. Att förstärka viktningsskillnaden ger större utslag för olikheter mellan program. Detta kan förtydliga resultatet men också förvilla genom att visa på större skillnader än vad det egentligen är. Det gäller att inte stirra sig blind på totalsumman då denna ändras väldigt mycket beroende på vilka vikter och poängskalor som används. Om viktsättningen ändras kan det helt plötsligt skifta vilket program som i testet fått den högsta totalpoängen. Ett säkrare sätt att jämföra
programmen är att titta på deras funktionalitet parameter för parameter.
9.2.4 Om varm mat ersätts med kall mat
Förslag finns på att varm mat skall ersättas helt av kall mat. Detta skulle innebära en avsevärd besparing och förenkling av transporterna. Kraven på ett planeringsprogram skulle däremot inte förändras. Detta beror på att det är indatat till programmet som förändras och inte själva funktionerna. Exempelvis blir tidsfönstren vidare men de finns fortfarande kvar som en begränsning för mellan vilka tider depåer har öppet och
mottagare kan få maten och varorna levererad. Begränsningen av hur länge bilarna får vara ute och köra på varje slinga finns fortfarande kvar men de har möjlighet att köra längre tid om lasten inte längre består av varm mat utan kall mat och varor.
9.3 Test och resultat
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
