Kravspecifikation för utvald funktionalitet

Innan någon implementation påbörjades, skulle en kravspecifikation för varje funktion att skrivas. Att skapa kravspecifikationer har många fördelar, framförallt är den till för att precisera problemformuleringen. En kravspecifikation ska försöka ge alla inblandade en klar bild över projektmålet.

Kravspecifikationen ska innehålla information om funktionalitetens format (hur den ska implementeras), funktion (vad den utför) och övrig information som kan vara av intresse för funktionaliteten i fråga. En kravspecifikation ska stödjas med motsvarande prototyper och/eller pseudokod. För att skapa tydliga kravspecifikationer skapades en mall, som används i bilaga A, B och C.

De nya funktionerna som valdes att implementeras och analyseras beskrivs nedan.

Para ihop omatchande rapporter m.h.a. annat data än vad som används för tillfället

Leveranser sker regelbundet, oftast under kvällstid. Hur ofta en tankbil levererar beror på hur mycket anläggningen förbrukar. När en påfyllning påbörjat, rapporterar både pejlen och Hoyer in denna information till SiteInfo. Informationen angående tiden för leverans som pejlen ger ska stämma överens med vad Hoyer rapporterat in. SiteInfo är systemet som har till uppgift att försöka para ihop de två rapporterna, dock är inte alltid så att båda rapporter kommer in samtidigt. I det nuvarande systemet måste personalen själva para ihop leveranser som inte kommit in samtidigt. Därför ska en funktion skapas som kan para ihop två rapporter m.h.a. annan data som finns tillgängligt. Den data som tänkts användas för att para ihop rapporterna är volymen och temperaturen. Temperaturen av drivmedlet som levereras dokumenteras inte för tillfället, därför kommer denna funktion ta reda på om volymen, chaufför och om

tankbilsnummret stämmer överens. Temperaturen i cisternerna är ett mått som Preem AB inte har för tillfället – om temperaturen erhålls kan matchningen göras mer noggrant genom att beräkna vad temperaturen bör bli då en leverans har skett.

28 Figur 5.1: Två rapporter som skiljer sig i tid men stämmer överens i både volym och temperatur (om 8000 liter av

8 graders drivmedel blandas med 5000 liter 7 graders drivmedel kommer sluttemperaturen bli ~7,6 grader (termodynamikens nollte huvudsats))

Figuren nedan visar hur problemet tänkts lösas om temperaturen även var angiven i leverantörsrapporten.

Figur 5.2: Grafisk presentation över lösningsförslaget för matchning av rapporter

Ta reda på cisternernas dödvolymnivå

En sugledning i en cistern når inte ända ner i botten av cisternen, för att den inte ska suga upp vatten och orenheter till kunder. Den volym som sugledningen inte når kallas för dödvolym. Sugledningarna i cisternerna kan skilja sig i längden dessutom är informationen angående hur långt sugledningen är ifrån botten av cisternen inte fastställt. Längden kan ändras vid servicen av cisternerna samt arbete med sugledningen. Positionen av sugledningen kan alltså ändras då den vidrörs. Funktionen som ska utvecklas ska ta reda på ett mer korrekt teoretiskt värde för när cisternerna når dödvolym. Målet är att skapa en lista som innehåller förhållandet mellan cisternerna och deras dödvolym.

29 Denna funktion fungerar endast om cisternen har nått dödvolym vid något tillfälle, detta för att det är endast vid de tillfällena transaktionsavböjelser kan bero på dödvolym. Om en cistern inte nått dödvolym kan inga slutsatser angående när den når dödvolym dras. För att avgöra om en cistern inte nått dödvolym tas det lägsta historiska värdet för volymen för den cisternen och jämförs med det teoretiska värdet för dödvolym – om värdena skiljer sig åt för mycket (2-5%) kan slutsatsen om att cisternen aldrig nått dödvolym dras.

Figur 5.3: Grafisk presentation över lösningsförslaget för att hitta dödvolym

Lösningsförslaget kan demonstreras genom att utreda en anläggning – i detta fall nummer 46507 där det totalt finns 4 cisterner. Enligt nivåförändrings historik är den lägsta nivån som mäts för cistern 1, 86,7 mm. (se figur 5.4). Information angående nivåförändring rapporteras från mcdMonitorII varje gång nivån i en cistern ändras – från 17:22 den 8 augusti 2014 till 06:01 den 9 augusti 2014 ändras inte nivån förrens en leverans mottagits (se figur 5.4). Tillfällen sådana som denna är av intresse då detta tillfälle möjligen innebär att cisternen nått dödvolym. Om nivån inte skiljer sig så mycket från den teoretiska dödvolymen och inte har ändrats tills cisternen fått en leverans är möjligheten ännu större. Genom att analysera transaktionshistoriken vid detta tillfälle kan man ytterliga styrka om att denna nivå är dödvolym. Detta görs genom att bevaka om något köp inträffat under det tillfället.

30

Figur 5.4: Nivåförändrings historik för anläggningen 46507 cistern 1 (De små nivåökningarna kan bero på

drivmedlet som befinner sig i sugledningen faller tillbaka till cisternen)

Genom att analysera transaktionshistoriken för anläggning 46507 cistern 1 (figur 5.5), ser vi att under tiden då nivån inte ändras har en hel del köp skett och inte lyckats (inget drivmedel finns kvar i cisternen eller att endast lite drivmedel pumpats ut). Denna cistern är även inte sammankopplad med andra cisterner, utifrån ovanstående resultat kan vi dra slutsatsen om att dödvolym för denna cistern nås vid 86,7 mm.

31 Figur 5.5: Transaktionhistorik för anläggning 46507 cistern 1

I exemplet ovan utreddes en cistern som inte var sammankopplad med andra cisterner. Om cisternen var sammankopplad ställs ännu ett krav för att kunna försäkra om dödvolym har nått. Kravet är att drivmedelsnivån för de sammankopplade cisternerna måste vara detsamma, däremot kan sugledningarna befinna sig på olika platser.

Optimera leveransplaneringen

Cisternerna brukar fyllas på med jämna mellan rum, detta kan ha en negativ påverkan då vissa cisterner aldrig utnyttjar sin kapacitet – se figur c1 för att få en överblick över hur det kan se ut. För att utnyttja kapaciteten behövs bättre planering angående när en leverans ska ske till en viss cistern – se figur c2 för att få en överblick över hur det önskas att se ut. Denna funktionalitet beror på funktionaliteten “Ta reda på en cisterns dödvolym” – detta eftersom att lösningsförslaget som tagits fram (se bilaga C) beror på det nya värdet för dödvolym som beräknas av funktionaliteten “Ta reda på en cisterns dödvolym”.

32 Figur 5.6: Grafisk presentation över lösningsförslaget för optimering av leveransplaneringen