Berekening van CO2 voetafdruk doorheen een...

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


‐ 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


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


‐ 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


‐ 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.


‐ 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.


‐ 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)


‐ 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 ‐


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 ‐


‐ 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


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 ‐


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 ‐


‐ 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.


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.


‐ 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.


‐ 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.


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 ‐


‐ 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


‐ 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


‐ 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


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 ‐


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 ‐


‐ 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.


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 ‐


Figuur 12: Datacaptatie en emissies berekenen voor een afvalverwerkingstap


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 ‐


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 ‐


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 ‐


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 ‐

Berekening van CO2 voetafdruk doorheen een...

Documents

Transcript of Berekening van CO2 voetafdruk doorheen een...