Berekening van CO2 voetafdruk doorheen een productieketen
Mathias Lantsoght
Promotor: prof. dr. ir. Koen De Bosschere Begeleiders: Reinhart De Lille, dr. ir. Michiel Ronsse,
dr. Jonas Maebe
Masterproef ingediend tot het behalen van de academische graad van Master in de toegepaste informatica
Vakgroep Elektronica en informatiesystemen Voorzitter: prof. dr. ir. Jan Van Campenhout Faculteit Ingenieurswetenschappen Academiejaar 2009-2010
Inhoudstafel
‐ I ‐
Inhoudstafel
1 INLEIDING ............................................................................................................................................. 1
1.1 PROBLEEMBESCHRIJVING .............................................................................................................................. 1
1.2 DOELSTELLING ........................................................................................................................................... 2
1.3 ROLVERDELING ........................................................................................................................................... 2
2 LEVENSCYCLUSANALYSE ........................................................................................................................ 4
2.1 ALGEMEEN ................................................................................................................................................ 4
2.2 BESCHIKBARE STANDAARDEN ........................................................................................................................ 5
2.3 METHODOLOGISCHE PROBLEMEN .................................................................................................................. 6
2.3.1 Bij te houden waarden ...................................................................................................................... 6
2.3.2 Allocatie ............................................................................................................................................. 6
2.3.3 Systeemgrenzen ................................................................................................................................ 8
3 DATAMODEL ....................................................................................................................................... 10
3.1 OVERZICHT .............................................................................................................................................. 10
3.2 ER DIAGRAM ........................................................................................................................................... 10
3.3 ENTITEITEN .............................................................................................................................................. 12
3.4 PROBLEEMBESPREKING .............................................................................................................................. 12
3.4.1 Relaties ............................................................................................................................................ 12
3.4.2 Bijhouden van hoeveelheden .......................................................................................................... 13
3.5 TABELLEN EN ATTRIBUTEN .......................................................................................................................... 15
4 BESPREKING WEBAPPLICATIE .............................................................................................................. 17
4.1 GEBRUIKERS EN BEVEILIGING ....................................................................................................................... 17
4.2 OPBOUWEN PROCESMODEL ........................................................................................................................ 18
4.2.1 Aanmaken eindproduct ................................................................................................................... 18
4.2.2 Processtap toevoegen ..................................................................................................................... 19
4.2.3 Interface producent leverancier ...................................................................................................... 21
4.3 DATA CAPTATIE ........................................................................................................................................ 22
4.3.1 Input/output .................................................................................................................................... 22
4.3.2 Transport ......................................................................................................................................... 23
4.3.3 Verwerkingsproces .......................................................................................................................... 24
4.3.4 Afvalverwerking .............................................................................................................................. 25
4.4 BEREKENINGEN ........................................................................................................................................ 29
4.5 GRAFISCHE ELEMENTEN ............................................................................................................................. 31
Inhoudstafel
‐ II ‐
4.5.1 Master page .................................................................................................................................... 31
4.5.2 Treeview .......................................................................................................................................... 31
5 BESLUIT ............................................................................................................................................... 32
6 REFERENTIES ....................................................................................................................................... 33
Hoofdstuk 1: Inleiding
‐ 1 ‐
1 Inleiding
1.1 Probleembeschrijving
In de voedings‐ en veevoedingsindustrie is het kunnen berekenen en weergeven van een CO2‐
voetafdruk een hot topic geworden. Veel bedrijven zijn dan ook geneigd inspanningen te leveren om
deze voetafdruk naar beneden te brengen. Om de CO2‐voetafdruk te kunnen verlagen moet deze in
de eerste plaats natuurlijk berekend kunnen worden. Het berekenen van een CO2‐voetafdruk vormt
eigenlijk een onderdeel van een LCA of levenscyclusanalyse. Voor het kunnen uitvoeren van een
dergelijke LCA is er in de laatste jaren al heel wat software ontwikkeld.
In de eerste plaats is er nood aan veel data om de milieu‐impact te kunnen berekenen. Daarom zijn
reeds verschillende projecten gestart waar data al dan niet tegen betaling kan geraadpleegd en
gebruikt worden. Deze datasets zijn vaak specifiek gericht op een bepaalde sector. Enkele
voorbeelden zijn: Gemis (agriculturele sector) en EcoInvent (algemeen). Daarnaast zijn er ook een
aantal programma’s beschikbaar waarin LCA’s kunnen gemodelleerd worden zoals GaBi en SimaPro.
Het grote voordeel van deze programma’s is dat ze heel gebruiksvriendelijk zijn door een sterke
grafische ondersteuning. Deze programma’s hebben naast een hoge kostprijs als nadeel dat ze
allemaal gericht zijn op één gebruiker die het volledige proces ingeeft en de daaraan gekoppelde
data. Door deze werkwijze kan een gebruiker dus enkel zijn eigen processen in kaart brengen. In de
voedingssector of bij de productie van elektronische componenten worden de eindproducten veelal
geproduceerd uit ingrediënten of halffabricaten die aangekocht worden. De producent heeft meestal
geen kennis van welke stappen uitgevoerd worden om deze tussenproducten te bekomen en kan
daar dus geen model of data van ingeven.
Bij de bestaande software wordt ook niet altijd rekening gehouden met afvalverwerking. Deze stap
levert nochtans vaak een significante bijdrage aan de globale voetafdruk en moet volgens algemene
standaarden altijd meegerekend worden. Verder is ook niet gekend hoe de bestaande software
omgaat met methodologische problemen zoals de verdeling van een CO2‐voetafdruk over
eindproduct en nevenproducten.
Om de hiervoor vermelde problemen op te lossen werd geopteerd voor het ontwerpen van een
eigen webapplicatie. Deze applicatie moet dienst doen als een proof of concept om aan te tonen dat
het ook mogelijk is om een CO2‐voetafdruk doorheen een volledige productieketen te modelleren en
berekenen. De focus ligt op een goede interface tussen producent en leverancier, zodat een
Hoofdstuk 1: Inleiding
‐ 2 ‐
productieproces kan opgebouwd worden door meerdere verschillende partijen. Hierbij is elke partij
verantwoordelijk is voor zijn deel van het volledige productieproces.
1.2 Doelstelling
Om een CO2‐voetafdruk doorheen een productieketen te kunnen berekenen, zou de te ontwerpen
applicatie over drie grote functionaliteiten moeten beschikken.
In de eerste plaats moet het mogelijk zijn om een levenscyclusanalyse te modelleren. Door het
levensverloop van een product op te splitsen in basisstappen, wordt het mogelijk om alle stappen die
een impact hebben op het milieu te visualiseren en deze in kaart te brengen. Door het toevoegen of
verwijderen van een paar basisstappen kunnen de systeemgrenzen van de LCA ook snel aangepast
worden.
Ten tweede moet de applicatie aan de hand van het opgestelde model en de opgegeven data voor de
verschillende basisstappen de totale impact van alle stappen samen kunnen berekenen. Er moet
hierbij ook aandacht besteed worden aan het allocatieprobleem dat optreedt wanneer meerdere
eindproducten bekomen worden. Wanneer parameters gewijzigd worden, moeten de uitstoten ook
makkelijk herberekend kunnen worden. Verder zou de invloed van wijzigende systeemgrenzen op de
milieu‐impact ook moeten kunnen gecontroleerd worden.
Een laatste functionaliteit moet voor een vlotte interactie zorgen tussen producent en leverancier.
De applicatie is erop gericht om twee of meerdere partijen samen een procesmodel te laten
opstellen. Er moet dan ook gezorgd worden dat er duidelijkheid is omtrent wie over welk deel van
het productieproces verantwoordelijk is.
1.3 Rolverdeling
Voor de ontwikkeling van de applicatie wordt centraal vertrokken vanuit een rol als producent. De
producent moet de mogelijkheid hebben om zijn productieproces op te bouwen uit basisstappen en
moet data kunnen koppelen aan deze basisstappen. Voor de grondstoffen van het productieproces
die aan de producent geleverd worden, kan de producent opdracht geven aan zijn leveranciers om
de gevraagde data in te geven. Hierbij heeft de leverancier de keuze tussen twee mogelijkheden.
Enerzijds kan hij opteren om rechtstreeks data in te geven van zijn geleverde grondstoffen.
Anderzijds kan hij op zijn beurt een procesmodel opbouwen voor zijn geleverd product met vooraf
gedefinieerde basisstappen. Voor elke van deze basisstappen kan de producent vervolgens gegevens
Hoofdstuk 1: Inleiding
ingeven waarover hij wel kennis heeft en wordt de voetafdruk voor hem berekend. Op deze manier
wordt de dataverzameling een gedeelde opdracht en wordt alle data ook door de meest geschikte
partij ingegeven. Een schematische weergaven van de applicatie en de rolverdeling is weergegeven in
Figuur 1.
Figuur 1: Schematische weergave van de rollen en data‐invoer
‐ 3 ‐
Hoofdstuk 2: Levenscyclusanalyse
‐ 4 ‐
2 Levenscyclusanalyse
2.1 Algemeen
In een levenscyclusanalyse (LCA) wordt een analyse gemaakt van de impact die een product heeft op
zijn omgeving doorheen alle fasen van zijn bestaan. Er wordt dus niet alleen gekeken naar het
productieproces, maar ook de impact bij verdere stappen zoals transport, opslag, consumptie en
afbraak of recyclage van het product nadat het zijn nut heeft bewezen. Onder de term milieu‐impact
kunnen veel begrippen verstaan worden. Meestal wordt eerst naar de uitstoot van broeikasgassen
(greenhouse gases of GHG’s) gekeken, maar zaken zoals biodiversiteit en toxiciteit horen ook thuis in
een LCA. Het meest klassieke voorbeeld is waarschijnlijk de vergelijkende LCA studie tussen het
gebruik van plastic of glazen flessen. Bij het opstellen van een dergelijke LCA zijn zeer veel
parameters die gekozen moeten worden en die dan ook een significante invloed hebben op het
eindresultaat. Dit heeft tot gevolg dat bepaalde parameters zo gekozen kunnen worden met de
bedoeling een “beter” resultaat te bekomen terwijl toch een perfect onderbouwde LCA uitgevoerd is.
Het is als buitenstaander dan ook aangeraden om in de eerste plaats te kijken door wie de LCA is
uitgevoerd.
Bij het analyseren van een product komt veel kijken en je kan in de analyse ook zeer ver gaan. Bij het
uitvoeren van een LCA voor een eenvoudig product zoals brood is het evident om te kijken naar het
bakproces. Uiteraard zijn voor het maken van brood een aantal ingrediënten nodig zoals bloem, gist,
zout, ... Voor sommige van deze ingrediënten kan ook een productieproces gemodelleerd worden.
Zo wordt bloem bekomen door het vermalen van tarwe. De energie die voor dit proces nodig is,
moet dus ook opgenomen worden in de voetafdruk van brood. Als nu nog verder in de keten
gekeken wordt, kunnen nog een aantal processen gevonden worden die in rekening gebracht
moeten worden. Zo worden mest‐ en sproeistoffen gebruikt voor het optimaliseren van de
tarweopbrengst en landbouwmachines om het land te bewerken. Deze stappen kunnen dus ook aan
het productieproces toegevoegd worden. In een radicale aanpak kan nu zelf nog verder gegaan
worden. Om het land te bewerken is een landbouwmachine nodig, dus deze moet ook eerst
geproduceerd worden. De emissies die hierbij vrijkomen kunnen dan (gedeeltelijk) ook meegerekend
worden in het productieproces van brood. Dit voorbeeld geeft meteen twee problemen aan.
Enerzijds moeten systeemgrenzen vastgelegd worden om duidelijk te maken met welke stappen wel
Hoofdstuk 2: Levenscyclusanalyse
‐ 5 ‐
en met welke geen rekening gehouden moet worden. Anderzijds wordt het bij een uitgebreide
analyse zeer moeilijk en tijdrovend om aan alle benodigde data te komen.
Door constant evoluerende technieken en wijzigende parameters verliest een dergelijke studie in de
tijd ook aan waarde. Het is daarom ook noodzakelijk om na verloop van tijd de gebruikte data
opnieuw te controleren en indien nodig aan te passen om zo de studie up‐to‐date te houden.
2.2 Beschikbare standaarden
Voor het maken van een LCA zijn een aantal standaarden beschikbaar die een goede uitgangspositie
vormen en daarom ook best gevolgd kunnen worden.
In de eerste plaats zijn er de ISO standaarden. ISO 14040 (Environmental management ‐ LCA ‐
Principles and framework) en ISO 14044 (Environmental management ‐ LCA ‐ Requirements and
guidelines) geven een overzicht en mogelijke werkwijze om een correcte LCA uit te voeren (ISO,
2006). Deze standaarden beschrijven zeer algemeen de zaken die noodzakelijk zijn in een LCA, zonder
op details in te gaan. Zo kunnen de verschillende sectoren zelf kiezen hoe ze de richtlijnen willen
implementeren.
Op basis van deze standaard is de meer recenter verschenen PAS 2050 (Publicly Available
Specification) methodologie gebaseerd. Deze standaard werd gesponsord door de Carbon Trust en
de UK Department for Environment, Food and Rural Affairs. Hij werd voor het eerst gepubliceerd
door de British Standard Institution in oktober 2008 (PAS 2050, 2008). De PAS 2050 standaard
beschrijft in de eerste plaats de emissie van broeikasgassen en hoe deze emissie het best in rekening
gebracht wordt. Om dit te verwezenlijken wordt eerst een procesmodel opgemaakt. Dit is het in
kaart brengen van alle stappen in de verschillende levensfasen van een product (productie,
transport, afvalverwerking, ...). Hierbij worden systeemgrenzen getrokken die bepalen welke stappen
in rekening moeten worden gebracht voor het bepalen van de CO2‐voetafdruk en welke niet.
Uiteindelijk wordt getoond hoe de CO2‐voetafdruk berekend kan worden. De standaard kan dus
eerder aanzien worden als een specificatie van de ISO normen aangezien broeikasgasemissies slechts
een onderdeel zijn van een volledige LCA. Het grote voordeel van deze standaard is dat hij in
tegenstelling tot de ISO normen wel publiekelijk beschikbaar is.
Een derde bron van informatie zijn de aanwijzingen van Blonk Milieuadvies. Deze organisatie gaat uit
van bepaalde standaarden die algemeen gedefinieerd zijn en geeft voorbeelden en aanwijzingen
Hoofdstuk 2: Levenscyclusanalyse
‐ 6 ‐
voor specifieke problemen die in bepaalde sectoren kunnen voorkomen. De aanwijzingen zijn dus
vooral praktijkgericht en toegespitst op de agrarische sector (Blonk, 2009).
Voor het ontwerpen van de webapplicatie werd geopteerd om vooral de PAS 2050 richtlijnen te
volgen. Deze geven stapsgewijs aan hoe een LCA kan opgesteld worden. Voor specifieke problemen
zoals allocatie werd ook de aanwijzingen van Blonk gebruikt.
2.3 Methodologische problemen
2.3.1 Bij te houden waarden
Zoals eerder vermeld werd voor de applicatie geopteerd om te kijken naar broeikasgasemissies.
Onder broeikasgasemissies worden alle gassen gerekend die in de atmosfeer voorkomen en een
bijdrage leveren aan het broeikasgaseffect. Hoewel er veel gassen zijn die tot deze groepering
behoren is het enkel relevant om naar de antropogene gassen te kijken. In deze categorie zijn er
slechts drie gassen (CO2, CH4 en N2O) die een significante bijdrage leveren aan het broeikasgaseffect.
Er werd dan ook gekozen om enkel de emissies van deze gassen bij te houden en de berekeningen
van de totale voetafdrukken ook enkel voor deze gassen te doen.
De totale emissie aan CO2 of de CO2‐voetafdruk (carbon footprint), kan ook op analoge wijze
berekend worden voor de andere gassen. Aangezien CO2 meestal de grootste impact heeft wordt
deze in de eerste plaats berekend. Vaak wordt een CO2‐voetafdruk ook uitgedrukt in CO2‐
equivalenten. Dit houdt in dat de impact van alle broeikasgassen samen wordt uitgedrukt als de
hoeveelheid CO2 die eenzelfde impact zou hebben. Naast het bijhouden van de afzonderlijke
waarden is het dus ook gewenst dat de applicatie een totale CO2‐voetafdruk kan weergeven
uitgedrukt in CO2‐equivalenten.
2.3.2 Allocatie
Een probleem dat zich voordoet bij het maken van een LCA of het berekenen van een CO2‐voetafdruk
is wanneer uit een proces meerdere eindproducten komen. Veelal gaat het om een eindproduct
waarvoor het proces in eerste instantie was opgericht en een aantal nevenproducten (co‐producten).
Bij het allocatieprobleem dringt zich de vraag op in welke mate de CO2‐voetafdruk van het volledige
productieproces verdeeld kan worden over de verschillende eindproducten. In de energiesector waar
LCA’s veelal worden uitgevoerd in het teken van hernieuwbare energie, wordt de CO2‐voetafdruk
meestal verdeeld over de verschillende uitgaande producten op basis van hun energetische waarde.
Hoofdstuk 2: Levenscyclusanalyse
‐ 7 ‐
In andere sectoren is deze verdeling vaak niet gewenst en wordt geopteerd om de allocatie te doen
op basis van gewicht of economische waarde.
Illustratief voorbeeld: Sojaolie is wereldwijd de meest geconsumeerde plantaardige olie en wordt
uit sojabonen geëxtraheerd. Bij extractie van 1 ton soja kan ongeveer 180 kg sojaolie gewonnen
worden. Het nevenproduct dat hierbij ontstaat is sojameel (ook wel sojaschroot genoemd) en kan
perfect als veevoeder gebruikt worden. In Tabel 1 wordt voor 1 ton soja de allocatie op basis van
gewicht vergeleken met de economische en energetische allocatie. Merk op dat bij het weergeven
van de percentages economische en energetische allocatie er ook rekening gehouden wordt met de
gewichtsverdeling. Zo is de economische waarde van bvb sojameel niet € 117, maar 117 €/ton x
820kg. (Dalgaard et al., 2008; California Environmental Protection Agency, 2009)
Tabel 1: Verschillende allocatiemethodes voor 1 ton soja
Allocatie Sojameel Sojaolie
Gewicht 820 kg 82 % 180 kg 18%
Economisch 117 (€ / ton) 65 % 296 (€ / ton) 35 %
Energetisch 10,0 (GJ / ton) 55 % 37,5 (GJ / ton) 45 %
Bij het berekenen van een CO2‐voetafdruk voor de productie van sojaolie zal de emissie aan CO2 dus
bijna twee keer hoger zijn als economische allocatie gekozen wordt in plaats van allocatie op basis
van gewicht. De voetafdruk is nog eens 29% hoger als energetische allocatie gekozen wordt in plaats
van economische.
Omdat de CO2‐voetafdruk zeer sterk afhankelijk is van de gebruikte allocatiemethode moet deze ook
altijd vermeld worden bij het berekenen van een dergelijke voetafdruk. In de geraadpleegde
standaarden worden trouwens ook aanwijzingen gegeven voor het allocatieprobleem:
ISO 14044 (3 mogelijkheden)
‐ Opsplitsen van het proces naar kleinere processen waarbij geen coproductie plaats vindt
(vermijden van allocatie).
‐ Uitbreiden van het productiesysteem door meerdere functies en alternatieve productie toe te
voegen zodat de coproducten een onderdeel van het totale model worden.
Hoofdstuk 2: Levenscyclusanalyse
‐ 8 ‐
‐ Verdelen van de milieulast over de nevenproducten op basis van een fysieke of een andere
verklarende variabele (bvb massa, energie‐inhoud, economische waarde, ...)
PAS 2050
‐ PAS 2050 volgt de ISO richtlijnen met uitzondering van de derde methode. Bij de verdeling van
de milieulast over de nevenproducten doet PAS 2050 dit enkel op basis van economische
allocatie.
Blonk milieuadvies
‐ Blonk kiest voor economische allocatie, maar enkel op basis van gemiddelde prijzen van vrij
verhandelbare producten. Voor het berekenen van de gemiddelde prijs wordt een periode van
5 jaar voorgesteld.
Om de emissies volgens verschillende allocatiemethodes met elkaar te kunnen vergelijken, zal in de
ontworpen webapplicatie bij het opslaan van eind‐ of nevenproducten aan de gebruiker de
mogelijkheid gegeven worden om de relatieve economische en energetische waarden bij te houden.
Zo kan bij het berekenen van een voetafdruk de emissies voor verschillende allocatiemethodes met
elkaar vergeleken worden.
2.3.3 Systeemgrenzen
Doordat de stappen gedurende de verschillende levensfases van een product gemodelleerd kunnen
worden, kunnen de systeemgrenzen volledig naar zelfbelieven gekozen worden. Voor de
webapplicatie gaan we ons in de eerste plaats richten op een sector zoals de voeding waarbij voor
het produceren van eindproducten verschillende partijen een bijdrage moeten leveren. Volgens de
richtlijnen van Blonk Milieuadvies moet in de agrarische sector met de volgende stappen rekening
gehouden worden.
‐ Productie zaaizaad
‐ Gebruik machines voor zaaien, oogsten, landbewerking
‐ Gebruik van meststoffen (voornamelijk NO2 uitstoot)
‐ Emissies van de gewassen zelf (vb. methaan uit rijst)
‐ Emissies van vee (voornamelijk methaan)
Hoofdstuk 2: Levenscyclusanalyse
‐ 9 ‐
‐ Land use en Land use change (LULUC)
‐ Verbranding van energiedragers voor warmte, elektriciteit of transport
Kapitaalgoederen (fabriek, machines,...) worden niet in rekening gebracht.
Hoofdstuk 3: Datamodel
3 Datamodel
3.1 Overzicht
Voor het maken van de applicatie werd geopteerd om dit te doen aan de hand van een dynamische
website. De voorkeur gaat uit naar een website in ASP.NET omdat hierbij gemakkelijk gebruik
gemaakt kan worden van voorgeïnstalleerde functionaliteiten zoals gridviews of SQL‐connecties.
Voor het opslaan van alle datagegevens zoals de ingegeven procesmodellen of de broeikasgas
emissies werd een SQL Server Database aangemaakt. Deze kan met behulp van ADO.NET en SQL
commando’s vlot geraadpleegd worden via de site.
De eerste grote functionaliteit die in de website aanwezig is, is de mogelijkheid voor het opstellen
van een levenscyclus. Hiervoor werden alle processtappen gegroepeerd in 4 categorieën
(Input/output, Transport, Verwerkingsproces en Afvalverwerking). Om de bespreking van de inhoud
en werking van de website te verduidelijken zal gewerkt worden met een eenvoudig voorbeeld
waarin brood gemaakt wordt. Een overzicht van alle processtappen die doorlopen worden, is in
Figuur 2 weergegeven.
Figuur 2: LCA van brood bakken
3.2 ER diagram
Voor het samenstellen van de databank werd eerst een entity relationship diagram (ER diagram)
opgesteld. Hierin worden de onderlinge relaties tussen de verschillende entiteiten weergegeven en
kunnen de benodigde tabellen achteraf eenvoudig opgemaakt worden. Bij het opstellen van de
‐ 10 ‐
Hoofdstuk 3: Datamodel
database werd eerst een korte beschrijving gemaakt van welke gegevens allemaal aanwezig moet
zijn in de databank.
De belangrijkste gegevens die in deze beschrijving voorkomen zijn het eindproduct, procesmodel en
de processtappen. Voor het eindproduct willen we een procesmodel kunnen opstellen. Dit
procesmodel bestaat uit een aantal processtappen die van een verschillend type kunnen zijn en
afhankelijk van dit type moet data worden opgeslagen van verschillende gegevens waaruit achteraf
een CO2‐voetafdruk berekend kan worden. Aan elke stap is overigens ook een leverancier
verbonden. Dit moet later de mogelijkheid bieden aan een leverancier om data in te vullen voor de
stappen waarvoor hij of zij verantwoordelijk is. Verder moeten ook de relaties tussen de stappen
onderling bijgehouden worden en moet getracht worden om zoveel mogelijk data herbruikbaar te
maken. Dit laatste manifesteert zich door bvb een processtap uit het ene procesmodel ook in een
ander procesmodel bruikbaar te maken. Aan de hand van deze beschrijving werd het volgende ER
diagram voorgesteld.
Figuur 3: Het ER diagram
‐ 11 ‐
Hoofdstuk 3: Datamodel
‐ 12 ‐
3.3 Entiteiten
Eindproduct: Het eindproduct is het product waarvoor een procesmodel wordt opgesteld. Het
eindproduct is normaal ook de laatste stap in het procesmodel en de berekeningen zijn ook op dit
product afgestemd.
Procesmodel: Aan elk eindproduct is een procesmodel verbonden. Dit model beschrijft alle relaties
tussen de verschillende processtappen.
Processtap: De processtappen zijn de basisblokken waaruit een procesmodel is opgebouwd. De
stappen worden onderverdeeld in 4 klassen (Input/output, Transport, Verwerkingsproces en
Afvalverwerking).
Stapwaarde: In de stapwaarde wordt alle data van een bepaalde processtap opgeslagen (bvb voor
een stap van het type transport moeten de afgelegde afstand en transportmethode opgegeven
worden). Door stapwaarden van een processtap en de processtap zelf gescheiden te houden, zorgen
we er enerzijds voor dat een processtap ook gebruikt kan worden in een ander model en kunnen
verschillende leveranciers data opgeven voor eenzelfde stap.
Voor de verschillende types stappen worden verschillende waardes bijgehouden. In de tabel met de
stapwaarden wordt hier echter geen onderscheid in gemaakt. Hierdoor blijven in de tabel
proceswaarde altijd een groot deel van de velden leeg. (bvb voor een stap van het type
verwerkingsproces is het veld met de waarde ‘afgelegde afstand’ leeg).
Leverancier: De leverancier is de persoon die verantwoordelijk is voor het ingeven van de data bij
een bepaalde processtap. Merk op dat de leverancier ook de producent zelf kan zijn. Dit is normaal
gezien het gaval op het einde van de productieketen waar het eindproduct bekomen wordt.
3.4 Probleembespreking
3.4.1 Relaties
Bij het ER diagram kunnen een aantal opmerkingen gemaakt worden. In de eerste plaats is er de 1 : 1
relatie tussen Eindproduct en Procesmodel. Hoewel het normaal aangeraden is om twee identiteiten
met een 1 : 1 relatie samen te nemen, is toch verkozen om dit hier niet te doen. De reden hiervoor is
omdat naar de toekomst toe geopteerd kan worden om eenzelfde procesmodel te gebruiken voor
Hoofdstuk 3: Datamodel
verschillende gelijkaardige eindproducten en er dus een 1 : N relatie bekomen wordt tussen
respectievelijk het procesmodel en het eindproduct.
Een tweede verduidelijking moet gemaakt worden bij de M : N relatie van en naar Processtap. Een
procesmodel is opgebouwd uit een aantal processtappen. Dit is zichtbaar aan de 1 : N relatie tussen
procesmodel en processtap. De processtappen die bij een model horen, worden echter in een
bepaalde volgorde doorlopen, zoals in Figuur 2 weergegeven is. Om deze volgorde bij te houden, is
dus een M : N relatie nodig van en naar processtap. Op tabelniveau is een dergelijke M : N relatie
echter niet bruikbaar en moet ze vervangen worden door een 1 : M en 1 : N relatie. Hiervoor wordt
een extra tabel aangemaakt waarbij de primaire sleutels van beide tabellen opgeslagen worden als
vreemde sleutels in de nieuw aangemaakte tabel. Voor elke relatie tussen twee stappen wordt hun
ID dus opgeslagen in de nieuw aangemaakte tabel. De nieuwe relatie die zo bekomen wordt, wordt
grafisch voorgesteld zoals links in Figuur 4 is weergegeven.
Een nadeel bij deze werkwijze is dat voor iedere processtap het overeenkomstige procesmodel moet
worden bijgehouden. Dit zorgt er voor dat het niet mogelijk is om een bestaande stap te
hergebruiken in een ander procesmodel. Om dit te verhelpen werden de relaties lichtjes gewijzigd.
Wanneer de tabel met de processtappen en die met de relaties tussen de processtappen van positie
verwisseld worden (zie Figuur 4 rechts), wordt de processtap onafhankelijk van het overeenkomstige
procesmodel. Dit komt omdat het procesmodel nu niet meer opgeslagen wordt bij de processtap,
maar bij de relaties tussen de processtappen. Aan de hand van deze relaties kan het volledige
procesmodel nu ook opnieuw geconstrueerd worden.
Figuur 4: Klassieke vorige/volgende relatie en Herwerkte vorige/volgende relatie
3.4.2 Bijhouden van hoeveelheden
In Figuur 2 worden de verschillende stappen (en hun onderlinge relaties) voor de productie van
brood getoond. Een belangrijke parameter die hierbij echter nog niet is weergegeven zijn de
hoeveelheden (massa’s) van de gebruikte grondstoffen. Voor het later kunnen berekenen van de
‐ 13 ‐
Hoofdstuk 3: Datamodel
CO2‐voetafdruk is het echter noodzakelijk om te weten hoeveel bloem en gist er nodig is voor het
bakken van een bepaalde hoeveelheid brood. Om deze informatie op te slaan werden twee
alternatieven met elkaar vergeleken.
De eerste methode is deze beschreven in Guide to PAS 2050. Hier wordt alles berekend in functie van
een vaste hoeveelheid eindproduct (typisch 1 ton). Bij elke processtap wordt opgeslagen hoeveel ton
van deze stap nodig is om 1 ton eindproduct te bekomen. In elke stap wordt eerst de CO2 berekend
voor 1 ton van deze stap. Dit kan zowel de verwerking van 1 ton product zijn als het transport of de
productie. Vervolgens wordt de CO2‐emissie vermenigvuldigd met het aantal ton dat van deze stap
nodig is om 1 ton eindproduct te bekomen. De bijdrage van elke stap aan de totale CO2‐uitstoot
wordt dus telkens berekend en opgeslagen in functie van 1 ton eindproduct.
Bij de tweede methode die zelf werd voorgesteld, wordt opnieuw uitgegaan van 1 ton eindproduct
en wordt ook eerst uitgerekend wat de CO2‐uitstoot is voor 1 ton van elke stap. Deze waarde wordt
echter integraal opgeslagen en niet eerst vermenigvuldigd met hoeveel ton van deze stap nodig is
om 1 ton eindproduct te bekomen. Om de juiste impact van elke stap te weten, wordt een relatieve
verhouding bijgehouden bij de relatie tussen twee opeenvolgende stappen. Deze verhouding slaat
dus telkens op hoeveel ton van de vorige stap nodig is voor 1 ton van de volgende stap. Deze
methode wordt geïllustreerd in Figuur 5.
Voor het produceren van 1 ton gist wordt 200kg CO2 uitgestoten. Deze waarde wordt dan ook
opgeslagen in de stap Gist. Voor het bakken van brood is echter slechts 0,1 ton gist nodig. Deze
informatie wordt opgeslagen bij de relatie tussen de stappen Gist en Bakken. De emissies van gist
voor het maken van 1 ton brood worden dus herleid tot 20kg. Dit is ook de waarde die gebruikt moet
worden bij het berekenen van de totale CO2‐voetafdruk voor het maken van 1 ton brood.
Figuur 5: Illustratie van de relatieve verhouding
‐ 14 ‐
Hoofdstuk 3: Datamodel
‐ 15 ‐
Het nadeel bij deze methode is dat telkens alle stappen moeten afgelopen worden om te weten wat
de invloed is van 1 specifieke stap ten opzichte van 1 ton eindproduct. Het voordeel is dan echter dat
de stappen onderling makkelijker met elkaar vergeleken kunnen worden.
Het is de bedoeling van de website dat de data door verschillende partijen te laten invullen.
Aangezien van elke partijen enkel verondersteld wordt om zijn eigen productieproces te kennen, kan
van een leverancier niet verwacht worden dat hij weet hoeveel van zijn geleverd product nodig is
voor het maken van 1 ton eindproduct. Hij weet echter wel de verhoudingen tussen de verschillende
stappen van zijn eigen proces. Deze methode maakt het dus een stuk gemakkelijker om data
onafhankelijk van de het eindproduct in te vullen en daarom werd deze methode gekozen voor het
opstellen van de databank.
3.5 Tabellen en attributen
In Figuur 6 wordt een overzicht getoond van alle tabellen met hun onderlinge relaties en de
attributen die bijgehouden worden in elk van deze tabellen. Zoals eerder vermeld werd procesmodel
en eindproduct gescheiden gehouden zodat later een 1:N relatie tussen deze twee entiteiten kan
aangemaakt worden en de functionaliteit van de applicatie zo kan uitgebreid worden. Bemerk ook
dat de tabel procesmodel een attribuut laatste_stap_ID bevat, wat een verwijzing is naar de laatste
stap in de productieketen. Dit is niet noodzakelijk de laatste stap in het procesmodel, maar wel het
centrale product waarop de berekeningen zijn afgestemd.
Zoals voorheen vermeld wordt er geen onderscheid gemaakt tussen de verschillende types stappen
voor het opslaan van de data. Het type zelf wordt bijgehouden in de tabel processtap. Hieraan
kunnen dan een aantal tabellen met stapwaardes verbonden worden. Dit biedt het voordeel dat
grondstoffen van verschillende leveranciers vergeleken kunnen worden binnen hetzelfde
procesmodel. Bij de stapwaardes staan alle attributen die bijgehouden kunnen worden. Deze
verschillen voor elk type van processtap. In Figuur 6 wordt getoond welke waardes bij welk type van
stap horen. De eerste waardes zijn algemene gegevens en worden voor alle types stappen
opgeslagen.
In de tabel leverancier worden de gegevens van de verschillende leveranciers bijgehouden. Bij de
stapwaarde wordt via de vreemde sleutel leverancier_ID telkens bijgehouden welke persoon
verantwoordelijk is voor deze stap.
Hoofdstuk 3: Datamodel
Figuur 6: Overzicht van de gebruikte tabellen en attributen
‐ 16 ‐
Hoofdstuk 4: Bespreking webapplicatie
‐ 17 ‐
4 Bespreking webapplicatie
4.1 Gebruikers en beveiliging
Om toegang te krijgen tot de website moet eerst worden ingelogd. Hiervoor wordt gebruik gemaakt
van een standaard login in ASP.NET. Er wordt een onderscheid gemaakt tussen twee types
gebruikers. Voor dit onderscheid werden twee verschillende rollen aangemaakt waaraan een
gebruiker kan voldoen. Enerzijds is er het type producent. De producent wordt beschouwd als de
administrator en beheerder van de website. Hij heeft totale controle. Hij beschikt ook over de
mogelijkheid om nieuwe gebruikers aan te maken zodat deze toegang tot de website krijgen.
Gegevens van aangemaakte gebruikers worden beveiligd in een automatisch gegenereerde databank
opgeslagen. Verder heeft ook enkel de producent de mogelijkheid om nieuwe eindproducten te
definiëren en daar data aan te koppelen.
Het tweede type gebruikers zijn de leveranciers. Leveranciers kunnen zich aanmelden op de website
en komen dan in een voor hen gereserveerd deel van de site terecht. Hier kunnen zij de gegevens
van hun geleverde producten invullen of het productieproces van hun geleverd product modelleren.
Om delen van de website af te schermen voor ongewenste gebruikers werden drie folders
aangemaakt. Deze zijn genaamd Producent, Leverancier en Anoniem. Zoals de naam al doet
vermoeden zijn de pagina’s die zich in de folder Producent bevinden enkel toegankelijk voor de
producent. De folder Leverancier is voor beide type gebruikers toegankelijk. Deze methode van
werken zorgt er voor dat alle pagina’s toegankelijk zijn voor het juiste type gebruikers en een pagina
nooit dubbel opgeslagen moet worden. De restricties op de toegankelijkheid worden bekomen door
aan de verschillende folders toegangsregels toe te voegen die bepalen welke rollen toegang krijgen
tot welke folders. De folder Anoniem is noodzakelijk om gebruikers eerst de mogelijkheid te geven
zich te identificeren. Deze folder is uiteraard voor iedereen toegankelijk. Indien een gebruiker een
pagina wil bekijken waar hij geen bevoegdheid voor heeft wordt hij automatisch doorverwezen naar
de Login pagina waar hij zich (opnieuw) moet identificeren.
Een overzicht van de folders met de webpagina’s die zich hierin bevinden is in Tabel 2 weergegeven.
Hoofdstuk 4: Bespreking webapplicatie
‐ 18 ‐
Tabel 2: Overzicht van de folders en hun pagina’s
Producent Leverancier Anoniem
Home Leverancier Login ProducentOverzicht LeverancierOverzicht CreateUser Stapgegevens Stapgegevens2 DataInputOutput DataVerwerkingsproces DataTransport DataAfvalRecyclage
Resultaat
4.2 Opbouwen procesmodel
4.2.1 Aanmaken eindproduct
Voor het opbouwen van een procesmodel, moet eerst een nieuw eindproduct aangemaakt worden.
Op de homepagina voor gebruikers van het type producent worden alle reeds aangemaakte
producten weergegeven. De producent kan hier echter ook kiezen om een nieuw eindproduct aan te
maken. Hierbij wordt de naam van het eindproduct opgevraagd via een webformulier. Wanneer de
verzend knop wordt aangeklikt, vind er een postback plaats van de webpagina en worden de
volgende functies uitgevoerd:
insertEindproduct: Aan de tabel eindproduct wordt een nieuwe element toegevoegd. Het
eindproduct krijgt de opgegeven naam en een uniek ID wordt automatisch gegenereerd. Aangezien
er nog geen procesmodel aan dit eindproduct gekoppeld kan worden, blijft deze waarde voorlopig
nog leeg.
insertModel: Analoog als bij insertEindproduct wordt een nieuw element toegevoegd aan de tabel
procesmodel. Hierbij krijgt het nieuwe model dezelfde naam als het eindproduct, maar met de
extensie “_model” erbij. Ook hier is er één waarde die nog niet kan ingevuld worden, namelijk deze
van de laatste_stap_ID, aangezien de corresponderende stap nog niet is aangemaakt.
insertProcesstap: De laatste stap van het procesmodel wordt aangemaakt. Deze stap is van het type
“Input/output” en krijgt dezelfde naam als het eerder aangemaakte eindproduct. Net als bij de
andere tabellen, wordt er bij het toevoegen van de gegevens automatisch een uniek ID aangemaakt.
Hoofdstuk 4: Bespreking webapplicatie
‐ 19 ‐
getLeverancier: Uit de tabel leverancier wordt het unieke ID van de producent opgehaald die op dit
moment is aangemeld. Hoewel dit meestal om dezelfde gebruiker gaat, werd deze functie toch
toegevoegd zodat indien gewenst verschillende gebruikers zich als producent kunnen aanmelden en
nieuwe eindproducten kunnen aanmaken.
insertWaarde: Ten slotte wordt een element toegevoegd waar de stapwaarden voor de net
aangemaakte processtap kunnen ingevuld worden. Standaard wordt de economische en
energetische allocatie op 100% geplaatst en worden de emissies die bij deze stap horen op 0 gezet.
De fysische gegevens van het product worden blanco gelaten, maar kunnen net als alle andere
parameters later gewijzigd worden.
updateEindproduct en updateModel: Uiteindelijk wordt nogmaals een connectie met de tabel
eindproduct en procesmodel gemaakt om de data die oorspronkelijk niet kon ingevuld worden
(model_ID en laatste_stap_ID) nu aan te vullen.
Wanneer de nieuwe entiteiten aangemaakt zijn, wordt de dataconnectie gesloten en wordt de
gebruiker doorverwezen naar de overzichtspagina. Hier kan de gebruiker door de verschillende
processtappen (indien deze aangemaakt zijn) navigeren, waarbij hij telkens de details kan zien van de
huidig geselecteerde stap. Verder kan hij ook nieuwe stappen toevoegen aan de huidig geselecteerde
stap en zo kan het volledige procesmodel opgebouwd worden.
4.2.2 Processtap toevoegen
Voor het toevoegen van een processtap wordt een onderscheid gemaakt tussen het toevoegen van
een vorige en een volgende stap aan de huidig geselecteerde processtap. Hoewel beide bewerkingen
zeer analoog zijn, is het eenvoudiger en overzichtelijker om de twee gescheiden te houden.
Wanneer gekozen wordt om een nieuwe stap toe te voegen wordt aan de gebruiker de mogelijkheid
gegeven om een volledig nieuwe stap aan te maken, of om een reeds bestaande stap te kiezen. Dit is
in Figuur 7 weergegeven. Op de linkerkant kan een nieuwe stap gedefinieerd worden, terwijl op de
rechterkant een keuzelijst staat van mogelijke stappen die toegevoegd kunnen worden.
Hoofdstuk 4: Bespreking webapplicatie
Figuur 7: Processtap toevoegen
Opgelegde restricties
Bij het opbouwen van een procesmodel zijn restricties opgelegd aan de types processtappen die met
elkaar gecombineerd kunnen worden. Dit is in de eerste plaats bedoeld om de gebruiker te sturen bij
het maken van het procesmodel en zorgt er voor dat het model overzichtelijk blijft. Door deze
beperkingen kunnen de verhoudingen die tussen de stappen plaats vinden ook makkelijk
bijgehouden worden. Zo hoeft men bvb bij de relatie tussen stappen van het type transport en
input/output niet te vragen wat de relatieve verhouding is. Deze is in dit geval namelijk altijd gelijk
aan 1.
De combinaties die toegelaten zijn worden opgeslagen in een extra tabel. Door het opnemen van
deze tabel in de achterliggende SQL‐commando’s worden deze restricties doorgevoerd op de
webpagina. In Figuur 8 zijn de combinaties weergegeven die toegelaten worden. Merk op dat voor
en na een stap van het type transport altijd een stap van het type input/output moet staan. Stappen
van het type verwerkingsproces kunnen elkaar wel opvolgen zonder dat hiertussen een stap van het
type input/output moet gedefinieerd zijn.
Figuur 8: Toegelaten combinaties van processtappen
‐ 20 ‐
Hoofdstuk 4: Bespreking webapplicatie
‐ 21 ‐
Relaties bijhouden
Bij het toevoegen van een nieuwe processtap aan een procesmodel, wordt een nieuw element
toegevoegd aan de tabellen Processtap en Stapwaarde. Net zoals bij het aanmaken van een nieuw
eindproduct, wordt de uitstoot van broeikasgassen standaard op 0 gezet en wordt als leverancier de
gebruiker gekozen die op dat moment is aangemeld. Voor het opslaan van de relatie tussen de twee
stappen, wordt in de tabel Stap_stap de unieke ID’s van beide stappen opgeslagen. Hierbij wordt ook
het overeenkomstig model en de relatieve verhouding tussen beide stappen opgeslagen. Standaard
wordt deze verhouding op 1 gezet. Afhankelijk van welke staptypes verbonden zijn kan deze later al
dan niet nog aangepast worden.
De verbindingen tussen de verschillende stappen van een procesmodel worden dus bijgehouden
door telkens een koppel van stappen op te slaan die met elkaar verbonden zijn. In de tabel
Procesmodel kan de laatste stap van de keten terug gevonden worden. Door vervolgens alle koppels
te nemen waarvan deze laatste stap deel uit maakt, kan het procesmodel uitgebreid worden. Door
dit voor elke processtap te doen, kan het volledige model in kaart gebracht worden.
Probleembespreking
Bij het gebruik van deze werkmethode ontstaat wel de mogelijkheid om oneindige lussen te vormen.
Dit gebeurt wanneer bij een aantal opeenvolgende stappen de laatste terug naar de eerst verwijst.
Bij het definiëren van een nieuwe stap kan dit probleem niet optreden. Wanneer echter bij de reeds
bestaande stappen een stap wordt gekozen die wat hoger in de keten voorkomt, is de kans op het
maken van zo’n oneindige lus vrij reëel.
Om de gebruiker te beschermen tegen dergelijke ongewenste lussen, werd aan de keuzelijst van
bestaande stappen de restrictie opgelegd dat hier geen stappen mogen voorkomen die reeds in het
huidige procesmodel voorkomen. Op deze manier is iedere stap uniek en kunnen dus geen oneindige
lussen gevormd worden. Deze restrictie brengt echter ook een beperking met zich mee. Wanneer
eenzelfde grondstof op verschillende plaatsen in het productieproces wordt toegevoegd, moet voor
elk van deze stappen een aparte processtap worden aangemaakt en moeten de bijhorende
parameters dus ook meermaals worden ingevuld.
4.2.3 Interface producent leverancier
Het opbouwen van een procesmodel wordt in de eerste plaats gedaan door de producent. Deze zal
typisch de processtappen van zijn productieproces modelleren tot aan het inkopen van zijn
grondstoffen. Bij het ingeven van deze grondstoffen heeft de producent de mogelijkheid om een
Hoofdstuk 4: Bespreking webapplicatie
‐ 22 ‐
bestaande leverancier uit de lijst van gebruikers te kiezen en wordt deze aan de grondstof
gekoppeld.
Wanneer een leverancier inlogt op de site zal deze een overzichtslijst krijgen van alle producten die
aan hem gekoppeld zijn. Op dit moment heeft de leverancier de keuze uit twee methodes om zijn
data in te geven. Indien hij de totale emissies kent voor het produceren van zijn grondstof, kan hij
deze rechtstreeks ingeven. Wanneer hij echter niet over dergelijke data beschikt kan hij net als de
producent zijn productieproces modelleren. Door het opgeven van waardes waar hij wel over
beschikt zoals elektriciteitsverbruik, hoeveelheid afval, transportmethode,... worden aan de hand van
gemiddelde waardes de emissies voor hem uitgerekend. Op de site is ook een beveiliging ingevoerd
zodat de leverancier wel het volledige procesmodel kan bekijken, maar enkel de processtappen die
aan hem gekoppeld zijn kan wijzigen.
Voor lange productieketens kan de leverancier net als de producent zijn proces modelleren tot bij de
aanschaf van zijn grondstoffen. De leverancier kan zo het deelproces modelleren waar hij
verantwoordelijk voor is en deze taak vervolgens doorgeven aan de leverancier van zijn eigen
grondstoffen door deze aan het systeem toe te voegen. De nieuwe leverancier krijgt op zijn beurt de
keuze om rechtstreeks de emissies van zijn product in te vullen of het proces verder modelleren. Dit
proces kan herhaald worden tot de basisgrondstoffen die niet meer verder gemodelleerd kunnen
worden.
4.3 Data captatie
Zoals voorheen vermeld, wordt er bij het aanmaken van een nieuwe processtap ook automatisch een
bijhorende relatie aangemaakt die de connectie tussen de nieuwe en de vorige stap bijhoudt en
wordt een element toegevoegd aan de tabel Stapwaarde, waarin de datagegevens van de processtap
opgeslagen worden. Voor het ingeven van deze gegevens werden vier webpagina’s gemaakt (één
voor elk type processtap) zodat zowel een producent of leverancier via een webformulier
gemakkelijk deze data kan ingeven.
4.3.1 Input/output
De processtappen van het type input/output worden op twee verschillende manieren gebruikt.
Enerzijds worden ze voor en na een stap van het type transport of verwerkingsproces geplaatst. In dit
geval leveren deze stappen geen bijdrage aan de totale CO2‐emissie, maar is hun functie louter om
meer overzicht te brengen in het procesmodel. Zo kan ook een mooi overzicht verkregen worden van
Hoofdstuk 4: Bespreking webapplicatie
‐ 23 ‐
de verwerkingsprocessen waarbij de in‐ en uitgaande producten met hun corresponderende
massahoeveelheden getoond worden.
In tweede instantie worden stappen van het type input/output gebruikt als zuivere grondstoffen
waar geen stappen aan vooraf gaan. In dit geval is er wel een bepaalde CO2‐emissie verbonden met
deze stap. Dit kan beschouwd worden als de emissies die vrijkomen bij het produceren van dit
product. Typisch gaat het hier om ruwe grondstoffen zoals landbouwproducten.
De gegevens die worden opgevraagd voor processtappen van het type input/output zijn o.a. fysische
eigenschappen van het product (water‐, eiwit‐, vetgehalte,...). Dit kan naar de toekomst toe ook
belangrijk zijn om producten te vergelijken of allocatie te doen op basis van een andere fysische
eigenschap. Voor producten die uit een verwerkingsproces komen is het ook belangrijk om
procentueel de relatieve economische en energetische waarde op te geven ten opzichte van alle
uitgaande producten. Deze gegevens worden later gebruikt bij de berekeningen om de CO2‐emissie
van de eindproducten volgens corresponderende allocatiemethodes te kunnen vergelijken. Voor
processtappen die gebruikt worden als input voor een verwerkingsproces of die een ruwe grondstof
voorstellen, worden deze relatieve economische en energetische waardes op 100% geplaatst.
Het bijhouden van de broeikasgasemissies voor stappen van het type input/output kan op twee
manieren gebeuren. Dit is afhankelijk van de methode waarop dit type stap gebruikt wordt. Indien de
stap als ruwe grondstof gemodelleerd wordt, kan de gebruiker rechtstreeks de broeikasgasemissies
ingeven die vrijkomen bij het produceren van dit product.
Indien een processtap als in‐ of uitgaande stap gebruikt wordt en dus enkel nog een
overzichtsgevende functie heeft, wordt geen rekening gehouden met de eventueel ingegeven
emissies. Zo kan een stap die eerst als ruwe grondstof gebruikt werd, omgezet worden naar een
overzichtsstap door het productieproces van deze stap te modelleren en toe te voegen. Bij deze
stappen wordt wel een sommatie bijgehouden van de emissies van alle voorgaande stappen. Zo kan
later naast de emissies van het eindproduct ook de emissies van de tussentijdse stappen getoond
worden.
4.3.2 Transport
Bij een processtap van het type transport worden alle gegevens opgevraagd voor het berekenen van
de emissies die vrijkomen wanneer 1 ton product getransporteerd wordt. Bij een transportstap
wordt uiteraard niet altijd precies 1 ton product vervoerd, daarom worden de gegevens opgevraagd
per uitgevoerde trip. Tijdens het opslaan van deze gegevens in de databank, wordt meteen ook de
Hoofdstuk 4: Bespreking webapplicatie
totale emissie berekend voor deze trip. Hiervoor wordt gebruik gemaakt van de gemiddelde uitstoot
per ton en per km volgens verschillende transportmethodes. Verder wordt ook nog rekening
gehouden met het al dan niet benutten van het transportmiddel tijdens de terugreis. Een overzicht
van de opgevraagde data en achterliggende bewerkingen wordt getoond in Figuur 9.
Figuur 9: Datacaptatie en emissies berekenen voor een transportstap
Bij het berekenen van de emissies voor een transportstap, wordt een onderscheid gemaakt tussen de
heen‐ en terugreis. Voor het berekenen van de totale emissies per ton getransporteerd product,
volstaat het om de emissies van de heen en terugreis op te tellen en deze som te delen door het
aantal ton product dat per trip vervoerd wordt.
Heenreis: afstand x emissies per ton en per km x (volume ingenomen door product / 100)
Terugreis: afstand x emissies per ton en per km x (volume ingenomen door product / 100) x
(1 ‐ (transportvolume benut op terugreis / 100))
Deze berekening kan verder vereenvoudigd worden, tot de bewerking die in Figuur 9 getoond wordt.
4.3.3 Verwerkingsproces
Bij het uitvoeren van een verwerkingsproces wordt vooral gekeken naar het energieverbruik. Alle
opgevraagde data is opnieuw gebaseerd op de verwerking tot één ton uitgaand product. Indien er
‐ 24 ‐
Hoofdstuk 4: Bespreking webapplicatie
meerdere uitgaande producten zijn, moet de ingegeven data gebaseerd zijn op één ton van het
uitgaande product dat verder in de keten wordt gebruikt.
We onderscheiden twee vormen van energieverbruik. De eerste gegevens die opgevraagd worden,
zijn die van het elektriciteitsverbruik. De CO2‐emissie per kWh kan sterk verschillend zijn per land,
want deze waarde is lager naarmate een groter percentage van de elektriciteitsproductie afkomstig
is van kerncentrales of hernieuwbare energiebronnen.
De tweede vorm van energie komt uit klassieke energiedragers zoals olie en aardgas en is vooral
belangrijk bij grotere productie‐eenheden. Opnieuw wordt hier voor het berekenen van de emissies
standaard gegevens gebruikt die de emissies weergeven per megajoule (MJ) vrijgekomen energie. In
Figuur 10 is een schematische weergave te zien van de achterliggende berekeningen.
Figuur 10: Datacaptatie en emissies berekenen voor een verwerkingsproces
4.3.4 Afvalverwerking
Het laatste type processtap is dat van de afvalverwerking. Zoals in de toegelaten stapcombinaties (zie
Figuur 8) is weergegeven kan dit type processtap enkel volgen op een stap van het type
verwerkingsproces. Bijgevolg zal nooit een andere stap volgen op een afvalverwerkingstap. Om de
berekeningen eenvoudiger en sneller te maken is bewust voor deze benadering gekozen. Deze
aanpak zorgt er wel voor dat geen transportstap aan de afvalverwerking kan voorafgaan, om dit te
‐ 25 ‐
Hoofdstuk 4: Bespreking webapplicatie
‐ 26 ‐
verhelpen is ervoor gekozen om eventueel transport ook op te slaan in de afvalverwerkingstap. Voor
het berekenen van de emissies veroorzaakt door de afvalverwerking (en het eventueel bijhorende
transport), wordt een onderscheid gemaakt tussen vast afval en afvalwater.
Afvalwater
Hoewel de emissies voor afvalwater sterk kunnen verschillen, werd toch getracht een benaderende
waarde te zoeken. Hiervoor wordt rekening gehouden met de COD (chemical oxygen demand), die
weergeeft hoeveel gram zuurstof nodig is om al het organisch materiaal in 1L water te oxideren.
Verder wordt ook een onderscheid gemaakt tussen aerobe en anaerobe waterzuivering. Bij anaerobe
waterzuivering wordt de opgevangen CH4 uiteraard niet meegeteld als broeikasgas. Om deze
besparing in rekening te brengen wordt voorgesteld om de CO2‐emissie die vrijkomt bij verbranding
van dit opgevangen gas te bepalen en deze emissie af te trekken van de totale emissie voor
afvalverwerking.
Vast afval
Om de emissies van het vast afval te berekenen, worden opnieuw gemiddelde waardes gebruikt voor
het storten of verbranden van organisch materiaal. Een parameter die een belangrijke richtlijn is voor
het bepalen van de emissies is het watergehalte van de input producten. Hoewel hier nu nog geen
rekening mee wordt gehouden, kan dit bij het optimaliseren van de tool gebruikt worden om een
nauwkeurigere berekening van de emissies te bekomen.
Transport
Voor het berekenen van de emissies voor transport van afval wordt een vereenvoudigde versie
gebruikt van de berekeningen die in de normale transportstap gebruikt worden. Deze
vereenvoudigingen kunnen doorgevoerd worden omdat hier verondersteld mag worden dat er bij
het transport van afval geen andere producten mee worden vervoerd en dat er geen gebruik
gemaakt wordt van het transportmiddel bij terugkeer.
Bij een afvalverwerkingstap moet er dus met drie processen rekening gehouden worden om de
totale CO2‐emissie te bepalen. Om deze stap net als alle andere stappen in het procesmodel te
kunnen afstemmen op een verwerking van 1 ton, moet een kleine kunstgreep worden uitgevoerd.
Hoofdstuk 4: Bespreking webapplicatie
Eerst worden de emissies van alle deelprocessen afzonderlijk uitgerekend. Vervolgens worden deze
allemaal opgeteld om zo de totale CO2‐emissie van de afvalverwerkingstap te bekomen. Om de
berekeningen nu af te stemmen op 1 ton, wordt de som berekend van het aantal kubieke meter
afvalwater met het aantal ton vast afval. Door de totale CO2‐emissie te delen door deze som
bekomen we de CO2‐emissie voor de verwerking van een mengsel van 1 ton afval waarbij de
verhouding tussen vast en vloeibaar afval hetzelfde blijft.
Illustratief voorbeeld: Voor het produceren van 1 ton eindproduct ontstaat er bij het
verwerkingsproces 0,2 m³ afvalwater en 0,3 ton vast afval. De verhouding tussen het verwerkings‐
proces en de afvalverwerkingstap wordt dus op 0,5 geplaatst (de som van het afvalwater en het vast
afval). Voor de berekening van de CO2‐emissies wordt verondersteld dat het om een mengsel van 1
ton afval gaat met dezelfde verhouding als het oorspronkelijk mengsel of dus 0,4m³ afvalwater en 0,6
ton vast afval. Dit is schematisch weergegeven in Figuur 11.
Figuur 11: Voorbeeld van de berekeningen voor de afvalverwerkingstap
In Figuur 12 wordt het formulier getoond waarmee de gegevens worden opgevraagd voor een
afvalverwerkingstap. Daarnaast zijn de bewerkingen die achter de schermen uitgevoerd worden om
de emissies van een afvalverwerkingstap te berekenen schematisch weergegeven. De groene lijnen
stellen de bewerkingen voor om de verwerkingsemissies van het opgegeven afval te berekenen. De
blauwe lijnen zijn de bewerkingen om het afval om te zetten naar een mengsel van 1 ton.
‐ 27 ‐
Hoofdstuk 4: Bespreking webapplicatie
Figuur 12: Datacaptatie en emissies berekenen voor een afvalverwerkingstap
Hoofdstuk 4: Bespreking webapplicatie
4.4 Berekeningen
Bij het ingeven van de data per processtap wordt meteen per processtap uitgerekend wat de
emissies van deze stap zijn en dit telkens gebaseerd op 1 ton product. We willen echter in de eerste
plaats weten wat de emissies zijn voor het produceren van een eindproduct. Voor de berekeningen
doorheen een productieproces uit te voeren, werden 2 functies aangemaakt.
De eerste is bedoeld voor het uitrekenen van de totale emissies bij het productieproces van een
specifiek product. Dit kan het eindproduct zijn, waarvoor het procesmodel is opgesteld, maar ook
een tussenproduct uit de productieketen. Voor de berekening wordt vertrokken van het opgegeven
product en wordt de keten achterwaarts doorlopen. Voor elke processtap moeten de eventuele
emissies bij de totale uitstoot opgeteld worden en moet uiteraard ook rekening gehouden worden
met de verhoudingen tussen de stappen. Het opgesteld algoritme wordt voor elke stap herhaald en
bestaat uit enkele deelprocessen zoals hieronder weergegeven.
De emissies worden opgeslagen in de variabele GHG. De variabele Stap is het uniek ID van de huidige
processtap, verhouding staat voor de relatieve verhouding tussen de huidige stap en zijn volgende
stap en type is het type van de huidige stap.
double [ ] berekenstap (double [ ] GHG, int stap, double verhouding, str ing type )
1) Controleer het type van de huidige processtap en zijn voorgaande stappen. Als de processtap
niet van het type input/output is, of wel van het type input/output is, maar geen voorgaande
stappen heeft, worden de emissies van deze stap opgeteld bij de totale emissies in de
variabele GHG. Hierbij wordt de hoeveelheid uiteraard gecorrigeerd door de emissies te
vermenigvuldigen met de verhouding.
2) Omdat altijd achterwaarts gerekend wordt vertrekkende van een opgegeven stap, kunnen
stappen van het type afvalverwerking nooit opgenomen worden. Daarom wordt bij stappen
van het type verwerkingsproces gecontroleerd of er ook een afvalverwerkingstap aan
verbonden is. Indien dit het geval is, wordt van deze afvalverwerkingstap, net zoals van de
huidige stap de emissies opgeteld.
3) Van de huidige processtap worden al de voorgaande stappen opgezocht. Tegelijkertijd wordt
ook het type van deze stappen opgezocht en hun verhouding met de huidige stap. Het
algoritme wordt nu opnieuw gestart met de gegevens van deze vorige stap. De variabele GHG
blijft wel dezelfde en de nieuwe verhouding wordt bepaald door de huidige waarde van
‐ 29 ‐
Hoofdstuk 4: Bespreking webapplicatie
verhouding te vermenigvuldigen met de nieuw opgezochte waarde. Dit is noodzakelijk omdat
een verhouding in de productieketen van toepassing is op alle onderliggende processtappen.
De gebruikte berekening is dus een recursief algoritme en zal vertrekkende van de opgegeven stap
alle voorgaande stappen doorlopen zoals in een boomstructuur. Dit zorgt er dus voor dat enkel
neerwaartse vertakkingen doorzocht worden.
Illustratief voorbeeld: In Figuur 13 is een deel van het procesmodel gegeven voor de productie van
brood. Wanneer het algoritme gebruikt wordt om de totale emissies te berekenen van de processtap
Brood, wordt met alle voorgaande stappen rekening gehouden. De stappen afval, co‐product en
transport zijn geen voorgaande stappen en worden dus niet doorlopen. Zoals in stap 2 van het
algoritme wordt uitgelegd, wordt speciaal gecontroleerd voor stappen van het type afvalverwerking.
De emissies van de stap Afval zullen dus wel opgeteld worden tijdens de verwerkingsstap Bakken.
Wat de verhoudingen betreft, voor het bakken van 1 ton brood is opgegeven dat er 0,1 ton gist nodig
is. Deze verhouding van 0,1 slaat ook op alle stappen die voorafgaan aan Gist. De emissies voor het
transport van gist moeten dus ook gebaseerd zijn op het vervoeren van 0,1 ton gist. Hiermee houdt
het recursief algoritme rekening door de nieuwe verhouding telkens te vermenigvuldigen met de
reeds bestaande verhouding. De verhouding 1 tussen de stappen Transport gist en Gist moet dus
eigenlijk geïnterpreteerd worden als, al het gist dat voor het bakproces gebruikt wordt, moet 1 maal
getransporteerd worden.
Figuur 13: Toepassing van het gebruikte algoritme
Het tweede gebruikte algoritme is vrij analoog aan het eerste, maar houdt met twee extra
parameters rekening. Deze zijn de relatieve energetische waarde en de relatieve economische
‐ 30 ‐
Hoofdstuk 4: Bespreking webapplicatie
waarde. Deze twee waardes worden op een volledig analoge manier bijgehouden en gebruikt als de
variabele verhouding in het eerste algoritme.
Aan de hand van dit algoritme kunnen de emissies van de verschillende broeikasgassen dus berekend
worden voor allocatie op basis van economische en energetische waarde. Bij het aanmaken van een
stap van het type input/output, wordt deze allocatie altijd standaard op 100 gezet. Bij het ingeven
van de stapwaarden kunnen deze waarden gewijzigd worden.
4.5 Grafische elementen
4.5.1 Master pagina
Voor het opbouwen van de website werd gebruik gemaakt van een master pagina. Dit zorgt voor een
consistente lay‐out en vermijd het meervoudig schrijven van code die op de verschillende pagina’s
terug komt.
De master pagina bestaat uit een kolom op de linkerkant die opgebouwd is uit twee delen (zie Figuur
14). In het eerste deel worden de login gegevens weergegeven alsook de groep waartoe de gebruiker
behoort (leverancier of producent). Het tweede deel bestaat uit een aantal links om vlot doorheen
de verschillende functionaliteiten van de website te kunnen navigeren. Hier worden ook de
verschillende eindproducten weergegeven die al aangemaakt zijn.
Figuur 14: Master page
‐ 31 ‐
Hoofdstuk 4: Bespreking webapplicatie
4.5.2 Treeview
Bij het bekijken van de verschillende processtappen in een procesmodel wordt telkens de huidige
stap getoond met zijn voorgaande en volgende stappen. Door op de voorgaande of volgende stap te
klikken kan door de keten genavigeerd worden. Bij lange productieprocessen wordt dit vrij
omslachtig. Daarom werd gekozen om een eenvoudige visualisatie van de productieketen te maken
aan de hand van een treeview. De treeview start bij het eindproduct en bouwt een boomdiagram op
van alle voorgaande stappen. Dit is een snelle methode om een overzicht te krijgen van het
productieproces en laat zo toe snel doorheen het model te navigeren. Het nadeel aan deze methode
is dat enkel vorige stappen getoond kunnen worden. Zo zullen nevenproducten of afvalverwerking‐
stappen typisch niet zichtbaar zijn. Om aan de gebruiker toch duidelijk te maken dat deze stappen er
zijn, wordt naast de naam van de processtap ook getoond hoeveel stappen vertrekkende uit de
huidige stap niet op het overzicht gegeven zijn.
Naast de stapnamen kan in de treeview ook de CO2‐uitstoot afgelezen worden van de voorgaande
stappen. Deze uitstoot is weergegeven in functie van 1 ton eindproduct en niet in functie van 1 ton
van de corresponderende stap, zoals de data wel opgeslagen wordt. Door al deze emissies op te
tellen wordt de totale emissie bekomen voor het maken van 1 ton eindproduct.
In Figuur 15 is de treeview gegeven om brood te bakken. Bij de processtappen ‘bakken’ en ‘transport
gist’ wordt telkens aangeduid dat er nog een volgende stap is die echter niet op de treeview kan
worden weergegeven. Voor de productie van brood wordt in totaal 964kg CO2‐uitgestoten. Merk op
dat in dit voorbeeld de totale emissie niet gelijk is aan de som van de onderliggende stappen. Dit
komt door de afvalverwerkingstap die aan de stap ‘bakken’ gekoppeld is, maar die niet weergegeven
wordt. De emissie van deze stap wordt echter wel mee in rekening gebracht.
Figuur 15: Voorbeeld van de treeview
‐ 31 ‐
Hoofdstuk 5: Besluit
5 Besluit
Hoewel er reeds een aantal tools bestaan voor het modelleren en berekenen van een
levenscyclusanalyse, is deze applicatie toch uniek in zijn soort. Door het specifiek te richten op
productieketens waarbij verschillende groepen verantwoordelijk zijn voor de deelprocessen wordt
het collecteren van data een gedeelde taak, terwijl het model toch één coherent geheel vormt.
Bij de ontwikkeling werd de focus gelegd op emissies van broeikasgassen, maar mits kleine
aanpassingen kunnen andere milieuaspecten ook in rekening gebracht worden. Bij het opstellen van
het achterliggende datamodel zijn bepaalde keuzes gemaakt voor het bijhouden van de gegevens.
Hierbij werd vooral rekening gehouden met een goede verdeling tussen producent en leverancier en
de herbruikbaarheid van processtappen. Hoewel bepaalde entiteiten strikt gezien overbodig zijn en
het model een stuk moeilijker maken, werd toch bewust gekozen om deze te houden. Deze
entiteiten laten immers toe om eventueel later bepaalde uitbreidingen van het systeem makkelijk
door te voeren.
Het opbouwen van een procesmodel kan zowel door de producent als de leverancier eenvoudig
gedaan worden door processtappen toe te voegen. Hierbij wordt gezorgd voor een vlotte
samenwerking tussen de verschillende gebruikers zodat elke persoon het deel van het volledige
proces kan modelleren waar hij of zij verantwoordelijk voor is.
Het ingeven van de data wordt gedaan aan de hand van standaard webformulieren. Alle ingegeven
waarden worden opgeslagen zodat bij wijzigingen van parameters alle emissies herberekend kunnen
worden.
Voor het visualiseren van het procesmodel werd een overzichtspagina gemaakt waar telkens de
details van de huidig geselecteerde stap bekeken kunnen worden. Om bij grotere procesmodellen
toch vlot doorheen de processtappen te kunnen navigeren, werd een boomstructuur toegevoegd.
Hierbij wordt ook de CO2‐emissie van de corresponderende stap getoond.
Finaal werd voor het berekenen van de emissies doorheen de volledige keten een recursief algoritme
ontwikkeld dat de stappen van achter naar voor doorloopt en hun bijdrage optelt. Dit wordt
standaard gedaan zonder rekening te houden met allocatie van nevenproducten. Deze berekeningen
kunnen echter herhaald worden om de emissies te bepalen op basis van economische of
energetische allocatie.
‐ 32 ‐
Hoofdstuk Fout! Verwijzingsbron niet gevonden.: Referenties
6 Referenties
Blonk, Towards a tool for assessing carbon footprints of animal feed (2009)
California Environmental Protection Agency (CEPA), Detailed California‐GREET Pathway for Biodiesel
(Esterified Soyoil) from Midwest Soybeans (2009)
Dalgaard, R., Schmidt, J., & Halberg, N., LCA of soybean meal, International Journal of life cycle
assessment , 240‐254 (2008).
ISO (International Standard Organisation), ISO 14040 Environmental management ‐ Life cycle
assessment ‐ Principles and framework (2006)
PAS 2050 (Publicly Available Specification), British Standard Insitution. Opgehaald van:
http://shop.bsigroup.com/en/Browse‐by‐Sector/Energy‐‐Utilities/PAS‐2050/ (2008)
‐ 33 ‐