Validering handlar om att säkerställa att modellen beter sig på samma sätt som det verkliga systemet inom ramen för de avgränsningar som gjorts eller de delar av systemet som modelleras. Då verifiering innebär att kontrollera att modellen byggts rätt, handlar validering om att säkerställa att rätt modell byggts.
I de flesta fall utgör simuleringsmodellen ett substitut för ett verkligt system, antin- gen befintligt eller framtida tilltänkt. För att nyttan med modellen ska bli så stor som möjligt inför en investering, produktionsomläggning eller vilket syfte som simuleringen har, är det av högsta vikt att modellen efterliknar verkligheten på ett önskvärt sätt. En icke valid modell går inte att använda som tillförlitligt beslutsun- derlag. Det är viktigt att ha i minnet att den kompletta modellen inte är valid, bara för att alla delmodeller är det och vice versa.
Oavsett om systemet är befintligt eller framtida går det att validera en modell. Validering av ett befintligt system kan dock i många fall vara betydligt lättare, då möjligheten finns att visuellt studera systemet.
En simuleringsmodell av ett komplext system varken kan, eller bör, vara en exakt bild av verkligheten. Det kostar alldeles för mycket, både tid och pengar, i förhål- lande till vad det ger. Huvudsaken är att modellen är tillräckligt bra för att uppfylla syftet. Det är även viktigt att vara medveten om att en modell som är valid för ett syfte, inte nödvändigtvis är giltig för ett annat. Därför måste syfte och mål vara klart i ett tidigt skede i simuleringsprojektet.
Validering delas, enligt Sargent (2000), upp i tre olika typer av processer. Alla processerna involverar simuleringsprojektgruppen på något sätt. Den första, och vanligaste, processen går ut på att projektgruppen själva beslutar om huruvida modellen är valid eller inte. Detta görs utifrån resultaten som de olika verkty- gen genererat. Beslutet kan vara mycket subjektivt. Andra alternativet kallas för ”oberoende verifiering och validering”. Då ligger beslutet om modellen är valid hos en tredje part, som är helt oberoende. Självklart är projektgruppen inblandad i arbetet med valideringen, men det är inte de som beslutar när modellen anses vara valid. Den tredje och mest ovanliga processen är att använda sig av ett poängsys-
tem för att bedöma modellen. Modellens olika delar får poäng efter hur valida de är och när hela övergripande modellen har fått ett visst antal poäng anses den vara valid. Detta har sina risker, som vi nämnt tidigare är inte modellen valid bara för att vissa delmodeller är det.
Law & Kelton (2000) beskriver sex olika verktyg som är användbara under valid- eringsprocessen. Dessa listas nedan, för att sedan beskrivas mer ingående:
• insamling av systemdata
• regelbunden kontakt med uppdragsgivaren • genomgång av konceptuell modell
• validering av statistiska indata • validering av utdata
• animering.
Utfallet från valideringen beskrivs i kapitel8.
3.7.1 Insamling av systemdata
Under simuleringsprojektet bör all tillgänglig information och kunskap om sys- temet beaktas. Det är viktigt att komma ihåg att en enda person inte kan ha den kunskap om hela systemet och alla dess delkomponenter som krävs för modell- bygget. Därför är det av högsta vikt att sakkunniga personer inom relevanta områ- den involveras för att modellen ska bli korrekt. Om systemet som ska modelleras finns i verkligheten i någon form finns mycket kunskap att hämta där. Det handlar framför allt om relevant data som kan samlas in. Det är då viktigt att modellbyg- garen klargjort hur den data som ska samlas in ska se ut. Det finns många felkällor vid hanteringen av data:
• den insamlade datan är inte relevant för syftet • den insamlade datan är i fel format
• den insamlade datan är behäftad med mät- eller avrundningsfel • den insamlade datan är förändrad på ett subjektivt sätt
• den insamlade datan innehåller motsägelsefulla enheter.
I vissa fall kan insamlade data hanteras enligt vedertagna teorier. Vi tänker oss återigen bankexemplet, kapitel3.4, där vi istället för att slumpa tidsmellanrummet mellan kundernas ankomster kunnat använda oss av en Poissonfördelning, givet att vi vet hur många personer som ankommit under en viss tidsperiod. Poisson- fördelningen avspeglar människors slumpmässiga beteende på ett väldigt bra sätt. Om det finns liknande simuleringsprojekt genomförda är det en god idé att ta del av dessa. Slutligen utgör modellbyggarens tidigare erfarenhet ett viktigt steg i valideringsprocessen. Det kan inte nog poängteras att kvaliteten på indata direkt påverkar relevansen i resultatet. Skräp in ger skräp ut!
3.7.2 Regelbunden kontakt med uppdragsgivaren
Det är oerhört viktigt att ha regelbunden kontakt med uppdragsgivaren. Det är fullt möjligt att den ursprungliga problemformuleringen visar sig vara felaktig en bit in i projektet. Om uppdragsgivaren är insatt i arbetet kan denne lätt formulera om problemformuleringen för att projektet ska nå sina mål. Oavsett hur stor och komplex modellen är, är den inte valid om det är fel problem som har lösts. Även uppdragsgivarens kunskap om systemet är till god hjälp för att nå en valid mod- ell. Genom att hålla uppdragsgivaren involverad erhålls även positiva bieffekter eftersom denne känner sig delaktig och därmed känner tillit till modellen.
3.7.3 Genomgång av konceptuell modell
En god förutsättning för ett lyckat resultat av modellbygget är att den konceptuella modellen är valid och trovärdig. Validering av den konceptuella modellen beskrivs mer utförligt i kapitel3.5.2.
3.7.4 Validering av statistiska indata
För att öka tillförlitligheten till modellen behöver olika delkomponenter valideras. Det handlar främst om känslighetsanalys och att kontrollera de statistiska fördel- ningar som antagits.
Att använda sig av känslighetsanalys under valideringsprocessen handlar om att avgöra vilka modellparametrar som har stor inverkan på modellen. Om en para-
meter har stor inverkan är det mycket viktigt att den hanteras på rätt sätt. Nedan listas några exempel på faktorer som kan testas genom känslighetsanalys:
• variation av värden på parametrar • val av fördelningsfunktion
• entiteternas detaljeringsnivå. Behöver entiteterna simuleras en och en, i till exempel ett produktionssystem, eller kan flera entiteter slås samman till en batch? Om inte kan simuleringsmodellen effektiviseras.
• detaljeringsnivå. En hög detaljeringsnivå kostar mycket datorkraft, vilken kanske inte alltid finns tillgänglig. Genom att förenkla systemet kan det be- hovet minskas. Frågan är då hur mycket det påverkar simuleringsmodellens resultat?
Om en täthetsfunktion har antagits till en viss mängd observerad data kan tillför- litligheten till fördelningen bestämmas genom att testa hur väl den passar datan.
3.7.5 Validering av utdata
Det kraftfullaste valideringsverktyget är att fastslå att simuleringsmodellens utda- ta ligger mycket nära vad som förväntas från det verkliga (framtida) systemet. Om så är fallet kan modellen anses vara valid.
Law & Kelton (2000) menar vidare att vissa statistiska test kan göras, men att andra test bör undvikas eftersom de inte ger ett statistiskt riktigt resultat. Hypo- tesprövning kan göras mellan modellen och det verkliga systemet, men frågeställ- ningen bör vara om det finns någon signifikant skillnad mellan dem?
Ett tredje sätt att validera utdata är genom ett så kallat Turingtest. Det går ut på att sakkunniga tillfrågas om de i en jämförelse mellan verkliga och simulerade utdata kan avgöra vilka som är vilka. Kan de inte det är modellen troligen valid. Om de däremot ser skillnader får de även förklara varför de såg dessa skillnader, i syfte att förbättra modellen.
3.7.6 Animering
Animeringen visar hur flödet är i modellen och används för att spåra felaktiga antaganden i modellen och för att stärka trovärdigheten hos simuleringsmodellen.