Entwicklung einer Software auf Empinia-Basis für die Abfallverwaltung eines Batterieherstellers

Entwicklung einer Software auf Empinia-Basis für die
Abfallverwaltung eines Batterieherstellers

Stefan Simroth, Andreas Taube, Matthias Mäusbacher, Volker Wohlgemuth
HTW Berlin, Fachbereich 2, Betriebliche Umweltinformatik
Wilhelminenhofstraße 75A, 12459 Berlin
stefan.simroth@student.htw-berlin.de
andreas.taube@student.htw-berlin.de
matthias.maeusbacher@htw-berlin.de
volker.wohlgemuth@htw-berlin.de

Zusammenfassung
Die neue Gesetzeslage erfordert von Unternehmen, die gefährlichen Abfall produzieren, die elektronische Register-
führung, sowie den elektronischen Nachweis an die Behörden. Um dies zu ermöglichen, als auch die Arbeit des Ab-
fallbeauftragten zu erleichtern und die verursachungsgerechte Zuordnung von Abfällen zu erreichen, wird eine Ab-
fallverwaltungssoftware entwickelt. Die Verwendung des Anwendungsrahmenwerkes Empinia fördert die Entwick-
lung und ermöglicht ein Fokussieren auf die Problemstellung der Anwendungsdomäne und das Domänenmodell.
Gleichzeitig wird mit dieser Entwicklung eine Referenzanwendung für Empinia geschaffen, die dessen Verwendung
als fachspezifische Entwicklungsplattform exemplarisch darstellt. Darüber hinaus sollen gemeinsame Daten zwi-
schen dem in Umberto erstellten Stoffstrommodell und der Abfallverwaltungssoftware automatisiert synchronisiert
werden.

1 Einführung
Die Entsorgung von Abfällen in der Bundesrepublik Deutschland wurde durch das Gesetz zur Vereinfa-
chung der abfallrechtlichen Überwachung und die Nachweisverordnung ab dem 1. Februar 2007 grund-
sätzlich neu geregelt. 1 In der zweiten Phase dieser Verordnung, welche ab dem 1. April 2010 in Kraft tritt,
wird das elektronische Abfallnachweisverfahren (eANV) verbindlich vorgeschrieben. Ab diesem Datum
müssen Abfallerzeuger, Abfallbeförderer und Abfallentsorger ihre Kommunikation untereinander, die
Entsorgung gefährlicher Abfälle (vorher „überwachungsbedürftige Abfälle“) betreffend, elektronisch ab-
wickeln. Die zu jedem Abfall gehörenden Nachweisscheine (Entsorgungsnachweis, Begleitscheine) müs-
sen dann mit einer elektronischen Signatur versehen werden und über eine zentrale Koordinierungsstelle
(ZKS-Abfall) an die zuständige Behörde übermittelt werden. 2
Aufgrund dieser Tatsache stehen immer mehr kleine und mittlere Unternehmen (KMU) vor der Heraus-
forderung, diese gesetzlichen Regelungen einzuhalten. In der Regel müssen die betrieblichen Prozesse
angepasst, personelle Zuständigkeiten festgelegt und alle nachweispflichtigen Informationen, wie bei-

1
Vgl. Gesetz zur Vereinfachung der abfallrechtlichen Überwachung und NachwV (2006)
2
Vgl. Knäpple (2007)

2 Stefan Simroth, Andreas Taube, Matthias Mäusbacher, Volker Wohlgemuth

spielsweise die Art und Menge eines Abfalls digital erfasst werden. Erst mit der digitalen Erfassung ist die
Grundvoraussetzung geschaffen eine nachweispflichtige Transaktion an die ZKS durchzuführen. 3
Um diesen Anforderungen gerecht zu werden, wurde das hier beschriebene Kooperationsprojekt zwischen
der BAE Batterien GmbH und der Hochschule für Technik und Wirtschaft Berlin (HTW) initiiert.
Ziel und Bestreben dieses Projektes ist es, die BAE Batterien GmbH bei ihrer gesetzlichen Nachweis-
pflicht mittels einer softwaretechnischen Lösung zu unterstützen.

1.1 Ausgangssituation
Bei der BAE Batterien GmbH fallen sowohl gefährliche Abfälle (Bleirückstände, Schwermetalle, etc.) als
auch ungefährliche Abfälle (Verpackung, Metalle, etc.) an. Zuständig für deren Verwaltung ist der Abfall-
beauftragte. Er ist dafür verantwortlich, alle Abfälle zu erfassen, zu entsorgen und deren Verbleib nach-
zuweisen.
Abfälle werden nach ihrer Abfallart unterschieden und je nach Art in einem eigens vorgesehenen Behälter
aufbewahrt. Wenn die Abfallbehälter voll sind, hat der Abfallbeauftragte die Aufgabe diese Behälter ab-
zuholen, zu erfassen und in einem Lager zu sammeln. Für die Erfassung der Abfälle ist es notwendig, den
Abfall vorher zu wiegen, wobei die Art des Abfalls, die angefallene Menge und die Anfallstelle dokumen-
tiert werden müssen.
Sind genügend Abfälle im Lager vorhanden oder der erlaubte Lagerhöchstbestand erreicht, muss der Ab-
fallbeauftragte die Entsorgung veranlassen. Dazu müssen die Abfälle zu einem Entsorgungs-unternehmen
transportiert werden. Dies kann durch ein Beförderungsunternehmen erfolgen oder, wie in der Praxis häu-
fig der Fall, durch das Entsorgungsunternehmen selbst. Es ist möglich, dass bei der Beförderung des Ab-
falls mehrere Beförderungsunternehmen involviert sind, sodass durchaus eine Beförderungskette entstehen
kann. Wichtig ist, dass der Abfallbeauftragte den Begleit- beziehungsweise Übernahmeschein zu unter-
zeichnen und dessen Durchschlag entgegenzunehmen hat. Der Begleitschein liegt dem Abfall auf dem
gesamten Entsorgungsweg bei und besteht aus sechs farblich unterschiedlichen Durchschriften, welche als
Beleg für eine ordnungsgemäße Entsorgung gelten.
Die Datenerfassung erfolgt derzeit noch handschriftlich und durch manuelle Übertragung in Microsoft
Excel. Die Abfallbilanz, die einmal jährlich als Nachweis an die Behörde übermittelt werden muss, wird
ebenso manuell mittels Microsoft Excel erstellt.
Eine Problematik stellt sich derzeit bei der Prozesszuordnung der Abfälle dar. Dadurch, dass in einem Be-
hälter durchaus der Abfall von mehreren Produktionsschritten gesammelt sein kann, lässt sich im nachhi-
nein eine verursachungsgerechte Zuordnung nicht mehr reproduzieren. Der entsprechende Abfallanteil
jedes Prozessschrittes (Herkunft) wird nicht vermerkt.
Außerdem ist anzumerken, dass in einem weiteren BAE-Projekt 4 derzeitig ein Stoffstrommodell mit Hilfe
der Software Umberto modelliert wird. Das Stoffstrommodell soll dann in Zukunft mit den erfassten Ab-
falldaten versorgt werden.

1.2 Ziele
Das Hauptziel des hier beschriebenen Projektes ist die Entwicklung einer fachspezifischen Anwendung,
mit deren Hilfe eine systematische Erfassung und Archivierung der Abfalldaten ermöglicht wird. Des wei-
teren soll das gesetzlich vorgeschriebene elektronische Abfallnachweisverfahren (eANV) mit Hilfe dieser

3
Vgl. Klein (2007)
4
Vgl. Erdelt, Hoffmann, Witte (2009)

Entwicklung einer Software auf Empinia-Basis für die Abfallverwaltung eines Batterieherstellers 3

Anwendung umgesetzt werden. Die Vision ist eine automatisierte Übertragung der nachweispflichtigen
Abfalldaten an die ZKS-Abfall zu ermöglichen.
Zusätzlich zur Erfassung der Abfälle soll die Anwendung eine verursachungsgerechte Zuordnung der Ab-
fallherkünfte bereitstellen. Es soll somit möglich sein, eine prozentuale oder absolute Aufteilung einer Ab-
fallerfassung vorzunehmen. Darüber hinaus soll die Anwendung es ermöglichen, einen erfassten Abfall als
entsorgt zu markieren. Dies ist der Fall, wenn beispielsweise ein oder mehrere Behälter von einem Beför-
derungsunternehmen abgeholt wurden. Hierbei ist zwischen Lagerbestand, Bestand entsorgter Abfälle und
dem Gesamtbestand zu unterschieden.
Ein weiteres Ziel ist die Anbindung an das Stoffstrommodell, um Abfallmengen und Abfallarten automati-
siert an das Umberto-Stoffstrommodell zu übertragen, als auch Daten zur Abfallherkunft (Prozesse) in die
Abfallverwaltungssoftware zu übernehmen.
Des weiteren soll die Erstellung der jährlichen Abfallbilanz und Abfallstatistiken ermöglicht werden.

2 Konzept und Implementierung
Die Konzeption und Implementierung der Abfallverwaltungssoftware ist auf Basis des Anwendungsrah-
menwerkes Empinia umgesetzt. Dies war zum Einen eine Vorgabe für die Durchführung des Projektes.
Zum Anderen bringt die technische Umsetzung mit Empinia für die Entwickler und Kunden einige Vortei-
le mit sich. Zu diesen gehört unter anderem die gute Erweiterbarkeit, vereinfachte Wartung und übersich-
tliche und strukturierte Anwendungsarchitektur. Letzteres ist oft ein bestimmender Faktor, wenn es um
den Erfolg eines Softwareprojektes geht, da meistens die Anforderungen an die Software zu Beginn der
Entwicklung nicht in aller Fülle und nötigen Ausführlichkeit feststehen, sondern erst im Laufe der Ent-
wicklung konkretisiert werden. 5 Die Systemarchitektur von Empinia wird im folgenden Abschnitt näher
erläutert und auf wichtige Grundkonzepte eingegangen.
Empinia wurde im Rahmen des vom BMBF 6 geförderten Projektes Emporer 7 von der HTW Berlin und
deren Kooperationspartnern entwickelt. Die entwickelte Anwendung zur Abfallverwaltung stellt diesbe-
züglich eine Referenzanwendung für Empinia dar. Bei der Entwicklung der Abfallverwaltungssoftware ist
außerdem der Frage nachgegangen worden, wie eine solche fachspezifische Anwendung mit Empinia
technisch umgesetzt werden kann. Eine Antwort hierzu wird im Folgenden anhand eines Lösungsweges
gegeben.

2.1 Empinia
Empinia ist ein Anwendungsrahmenwerk (engl. application framework), geschrieben in C# unter Ver-
wendung des Microsoft .NET Framework. Grundlegend für derartige Rahmenwerke ist, dass sie die Archi-
tektur der Anwendung maßgeblich bestimmen. 8 „Es definiert die Struktur im Großen, seine Unterteilung
in Klassen und Objekte, die jeweiligen zentralen Zuständigkeiten, die Zusammenarbeit der Klassen und
Objekte sowie den Kontrollfluss. [...] Das Framework enthält die Entwurfsentscheidungen, die in seinem
Anwendungsbereich allgemein anzufinden sind. Frameworks betonen damit die Entwurfswiederverwen-
dung gegenüber der Codewiederverwendung [...].” 9 „Da zudem die Entwürfe der Anwendungen so sehr
vom Framework abhängen, sind sie gegenüber Änderungen der Frameworkschnittstellen besonders emp-
findlich. Während ein Framework sich entwickelt, müssen die Anwendungen sich mitentwickeln. Dies

5
Vgl. Beck 2005
6
Abk. f. Bundesministerium für Bildung und Forschung
7
http://www.emporer.net (Letzter Abruf 22.09.2009)
8
Vgl. Gamma et al. 2004, S. 37
9
Ebd., S. 37


macht lose Kopplung umso wichtiger, da andernfalls selbst eine kleine Änderung des Frameworks größere
Auswirkungen zur Folge hat.“ 10
Bei einer Klassenbibliothek wendet ein Entwickler die zur Verfügung gestellten Klassen und Methoden
an, indem er die notwendigen Objekte erzeugt und entweder direkt oder über deren Schnittstellen benutzt.
Im Gegensatz dazu stehen Frameworks, wie Empinia, die sich dadurch charakterisieren, dass die von ei-
nem Entwickler definierten Methoden um das Framework zuzuschneiden, eher vom Framework selbst
aufgerufen werden, als vom Code des Entwicklers. Damit spielt das Framework oft die Rolle des Haupt-
programms bei der Koordination und Ablaufsteuerung der Aktivitäten der Anwendung. Diese Umkehrung
der Steuerung (engl. Inversion of Control, „IoC“) gibt Frameworks die Fähigkeit, als erweiterbare Skelette
zu fungieren. Die Methoden, die von einem Entwickler definiert werden, maßschneidern die generischen
Algorithmen des Frameworks für die spezielle Anwendung. 11 Diese Anpassung, das „Maßschneidern“,
sowie die Bekanntmachung von Client-Funktionalität, erfolgt dabei mittels Konfiguration, im Falle von
Empinia durch Deklaration in einer XML-Datei und .NET Metadaten, den Attributen. Das Rahmenwerk
liest diese Konfiguration beim Start aus und stellt diese Erweiterungen anderen Komponenten über eine
zentrale Erweiterungsregistrierung zur Disposition. Die „hot spots“ für Erweiterungen sind dabei definier-
te Erweiterungspunkte, ebenso in XML oder mit Attributen, welche aus reiner Konfiguration oder einer
implementierenden Klasse bestehen können, oder beidem. Das hier verwendete Entwurfsmuster ist die
„Strategie“. 12 Somit kann durch die Verwendung von Empinia eine sehr lose Kopplung erreicht werden.
Zugleich ist es aber auch möglich, die Konsistenz der darauf aufbauenden Anwendung zu garantieren,
indem festgelegt wird, welche wichtigen Komponenten vorhanden sein müssen und welche optionalen
oder austauschbaren Komponenten nicht. Dies geschieht in den anwendungsspezifischen Komponenten,
der Abfallverwaltung-Anwendung, in der obersten Schicht, der Anwendungsschicht, die Abbildung 1
zeigt.

Abbildung 1: Empinia Systemarchitektur (nach Jahr et al. 2009
und nach Schnackenbeck et al. 2007)

10
Ebd., S. 38
11
Vgl. Johnson and Foote 1988 (sinngemäß übersetzt)
12
Vgl. Gamma et al. 2004


Eine verbreitete Technik, um komplizierte Anwendungen auseinanderzubrechen, ist die der Schichten.
Eine Schicht in einem System liegt dabei auf einer anderen Schicht. In diesem Schema benutzt die höchste
Schicht alle Dienste der darunterliegenden Schichten, wohingegen die unteren Schichten die darüberlie-
genden nicht kennen. Eine Schicht kann als ein kohärentes Ganzes verstanden werden, welches nicht viel
von anderen Schichten wissen muss. Abhängigkeiten sind innerhalb einer Schicht minimiert. 13 Schichten
bestehen wiederum aus ein oder mehreren Komponenten. Die Komponenten innerhalb einer Schicht soll-
ten auch untereinander so wenig wie möglich gekoppelt sein. Durch die Abhängigkeiten der Komponenten
untereinander ergibt sich abermals eine Art Schichtung, die gut geplant sein muss. Die Abhängigkeiten
(engl. dependencies) müssen bei .NET explizit deklariert werden. Kann eine Abhängigkeit nicht aufgelöst
werden, so kann eine Assembly nicht verwendet werden, auch wenn diese die andere Assembly nur in be-
stimmten Fällen braucht. Die .NET Common Language Runtime (CLR) bricht die Ausführung des Prog-
ramms dann ab. Ebenso unmöglich ist es, sogenannte Ringabhängigkeiten zu definieren, das heißt dass
zwei Assemblies sich gegenseitig referenzieren und dadurch bedingen. Die erweiterbare und lose gekop-
pelte Architektur von Empinia ermöglicht es Entwicklern, das Problem der Abhängigkeiten besser unter
Kontrolle zu bekommen und aufzulösen. Besonders zur Funktionalität und Granularität von Plugins und
Komponenten existieren bereits Richtlinien und Empfehlungen. 14
Um nun Empinia für die eigene Anwendungsentwicklung zu benutzen, ist es zunächst nötig, eine ausführ-
bare Datei zu erstellen, um die Laufzeitumgebung von Empinia, die in Abbildung 1 dargestellte Runtime,
zu starten. Dies schließt auch die grafische Oberfläche mit ein, wenn gewünscht. So kann mittels einer
Produkt-Konfiguration Empinia mit seinem Zeichen versehen werden. Außerdem läßt sich darüber auch
der Funktionsumfang bestimmen, das heißt das Framework maßschneidern. Überdies bringt Empinia auch
die nötigen NAnt Erstellungsskripte mit sich, sodass eine sehr flexible Erstellung der Anwendung mit den
benötigten Plugins ermöglicht wird. Die Erstellungsskripte eignen sich auch sehr gut zur Integration in
sogenannte Continious Integration Systeme.
Sind diese wenigen grundsätzlichen Schritte zur Anwendungsentwicklung mit Empinia erledigt, kann sehr
schnell bereits auf das Domänenmodell fokussiert werden.

2.2 Domänenmodell
Ein Domänenmodell, also das fachspezifische Modell eines Anwendungsgebiets, besteht im Kern aus En-
titäten mit ihren Eigenschaften und den Beziehungen der Entitäten untereinander. Für die Erstellung eines
Domänenmodells mit Empinia kann teilweise auf Code-Generierung gesetzt werden. Dafür wird für jede
Entität eine sogenannte Domain Entity Defintion benötigt. Dies ist im Grunde eine XML-Datei, welche die
abstrakte Beschreibung der Entität mit ihren Eigenschaften und Beziehungen enthält. Mittels des in Empi-
nia enthaltenen Domain Code Generator wird dann C#-Quellcode erstellt. Dabei werden partielle Klassen
generiert, die es dem Entwickler ermöglichen, weiteren Code den Entitäten hinzuzufügen, ohne diesen zu
verlieren, wenn der Code neu generiert wird. Ebenso können bereits in der XML-Definition der Entitäten
die Validierungsregeln für zulässige Werte der Eigenschaften untergebracht werden, wenn eine Bibliothek
wie beispielsweise der NHibernate Validator genutzt wird.
Der Speicherort der Entitäten wird in der Empinia.DomainModel-Erweiterung ebenso abstrahiert, wie die
durch diese Arbeit neu hinzugekommene Abstraktion des Datenzugriffs. Für den Datenzugriff wird das
domänengetriebene Entwurfsmuster Repository 15 verwendet. Die visuelle Darstellung des Domänenmo-
dells in einer baumartigen Struktur übernimmt eine ebenso neu hinzugekommene Komponente, der Do-

13
Vgl. Fowler 2002, S. 17
14
Vgl. Denz und Schnackenbeck 2008, Whitepaper
15
Vgl. Evans (2004)


main Navigator. Dieser erlaubt auch den schnellen Zugriff auf die sogenannten CRUD-Operationen 16 . Für
eine möglichst generische Verwendung von CRUD-Operationen wurden die beiden genannten abstrahie-
renden Komponenten, der Speicherort und der Datenzugriff, in dieser Arbeit verknüpft.

2.3 Persistenz
Damit das erstellte Domänenmodell auch mitsamt den Entitäten in einer Datenbank abgespeichert werden
kann, ist ein Persistenz-Plugin nötig. Ein solches wurde zusammen mit den oben beschriebenen gundle-
genden Komponenten für Domänenmodelle bereits in einer früheren Arbeit erstellt. 17 In dieser Arbeit
wurde das Persistenz-Plugin lediglich benutzt.
Die bei der Persistenz zum Einsatz kommende Technologie ist vor allem das Object Relation Mapping
(ORM). Dabei wird das ORM-Framework NHibernate eingesetzt. Für dieses ist es nötig, die eigenen Enti-
täten in einer XML-Datei zu deklarieren, wobei die zu speichernden Eigenschaften und Beziehungen die
wichtigste Konfiguration darstellt. Darüber hinaus können noch feinere Einstellungen vorgenommen wer-
den.
Ebenso kann mit NHibernate über die Deklaration der Entitäten mit ihren Eigenschaften und Beziehungen
auch das Datenbankschema erstellt werden. Als Datenbanksysteme können derzeit Firebird und SQLite
genutzt werden.

2.4 Implementierung der grafischen Oberfläche
Das Framework Empinia erleichtert die Entwicklung von komplexen grafischen Oberflächen. So werden
gängige Konzepte unterstützt, wie die der Ansichten (engl. Views) und der Perspektiven (Anordnung der
Ansichten und Menüs). Die schon vorhandene grafische Oberfläche von Empinia kann angepasst werden,
um die anwendungs- und fachspezifischen Ansichten darzustellen. Diese müssen in zumindest einer Pers-
pektive angeordnet werden, welche beim Start geladen wird. Für die Abfallverwaltungssoftware ist eine
solche Perspektive konfiguriert, die eine Startseite zeigt. Von dieser Startseite kann zu einer tabellarischen
Übersicht navigiert werden, der Dialog zur Abfalldatenerfassung angezeigt werden oder die Berichterstel-
lung initiiert werden. Das Kernstück der Abfallverwaltungssoftware ist der in Abbildung 2 gezeigte Dia-
log. Da auch Empinia schon Funktionalität in Bezug auf Behandlung von Dialogen mitbringt, kann bei der
Entwicklung auf den eigentlichen Inhalt und das Aussehen des Dialoges fokussiert werden.
Im Falle der Abfalldatenerfassung, spielt die Abfallherkunft oder auch Quelle beziehungsweise der Ent-
stehungsort für die verursachungsgerechte Zuordnung eine entscheidende Rolle. Eine Zuordnung kann,
bezogen auf das Nettogewicht des Abfalls, entweder absolut oder prozentual erfolgen, wie aus Abbildung
2 ersichtlich wird. Ein deutliches Gewicht wurde auf die Benutzungsfreundlichkeit (engl. Usability) des
Dialoges gelegt. So sind die Grundsätze der Dialoggestaltung 18 beachtet worden. Dazu gehört unter ande-
rem die Aufgabenangemessenheit, deren erste Empfehlung besagt, dass „der Dialog [...] dem Benutzer nur
solche Informationen anzeigen [sollte], die im Zusammenhang mit der Erledigung der Arbeitsaufgabe ste-
hen.“ 19 Außerdem wichtig ist die Fehlertoleranz, sodass es mit minimalem Aufwand möglich ist, in dem
Dialog zur Abfalldatenerfassung eine Korrektur vorzunehmen. 20 Des weiteren ist der Dialog so gestaltet,
dass dieser keine ungültigen Eingaben zulässt.

16
Create, Read, Update, Delete – in Anlehnung an die SQL-Kommandos – Insert, Select, Update, Delete
17
Vgl. Denz, Busse und Page (2008)
18
Vgl. EN ISO 9241-10
19
Ebd., S. 5
20
Vgl. ebd., S. 10


Abbildung 2: Dialog "Neuen Abfall erfassen" (eigener Entwurf)

Aus den erfassten Abfalldaten sollen schließlich automatisiert verschiedene Berichte erstellt werden, die
für externe Anspruchsgruppen als auch für interne Zwecke verwendet werden können. Der folgende Ab-
schnitt beschreibt die Umsetzung der Berichterstellung.

2.5 Berichterstellung
Die Berichterstellungskomponente dient zur Auswertung der erfassten Abfalldatenbasis. Mit ihrer Hilfe
können einzelne Berichte (engl. Reports) erstellt, angezeigt sowie gedruckt und in das Microsoft Excel-
und PDF-Format exportiert werden. Ein Beispiel dafür ist die jährlich benötigte Abfallbilanz oder eine
monatliche Abfallstatistik, sowie beliebige weitere Auswertungen von Daten die in Form von Tabellen
oder Diagrammen visualisiert werden.
Technisch gesehen basiert diese Komponente auf den Microsoft .NET Report Viewer Windows Forms
Controls. Zur Verwendung muss der Report Viewer mit einer Client-Berichtsdefinitionsdatei (RDLC) und
einer Datenquelle (DataTable) konfiguriert werden. Die RDLC-Datei entspricht einer lokalen Berichtvor-
lage, die das Aussehen beziehungsweise die Aggregation der anzuzeigenden Daten definiert. Die Daten-
quelle wird üblicherweise über eine Datenbankabfrage gefüllt und enthält somit die einzelnen Entitäten,
die in dem Bericht angezeigt werden sollen.
In Empinia erfolgt die Konfiguration einzelner Berichte über einen Erweiterungspunkt. Die Konfiguration
beinhaltet vor allem die Verknüpfung der RDLC-Datei mit der gewünschten Komponente zur Anzeige, in
diesem Fall dem Microsoft Report Viewer. Zur Nutzung steht in Empinia ein Dienst bereit, der Report
Service, welcher die Konfiguration mit der Datenquelle zusammenbringt und den Bericht in einer neuen
Ansicht darstellt.


3 Integration mit Umberto
Die Synchronisation mit dem in einem weiteren, gleichzeitigen BAE-Projekt 21 erstellten Stoffstrommodell
und damit eine softwaretechnische Integration mit der Software Umberto 5 ist Teil der prototypischen
Entwicklung. Im Folgenden wird der konzeptionelle Entwurf dargestellt.
Ziel der Integration soll der automatisierte Austausch von Daten sein, um unzumutbare und fehleranfällige
Arbeit zu vermeiden. Zu den austauschbaren Daten gehören zum Einen die Abfalldaten aus der Abfall-
verwaltungssoftware für das Stoffstrommodell. Diese fehlen derzeit im Modell, sollen aber aufgenommen
und auch aktuell gehalten werden. Außer der Menge an Abfall können dem Modell auch die Abfallarten in
Form von Materialien bereitgestellt werden, sodass diese in den Flüssen verwendet werden können. Zum
Anderen benötigt die Abfallverwaltungssoftware mögliche Herkunftsorte für Abfall, welche die Prozesse
darstellen. Diese sind in den Transitionen modelliert und können für die verursachungsgerechte Zuord-
nung in der Abfallverwaltungssoftware verwendet werden.
Die Daten, die in dem ursprünglichen Umberto-Stoffstrommodell enthalten sind, sind Realdaten und die
darauf basierenden Koeffizienten müssen und dürfen nicht geändert werden. Somit muss an dieser Stelle
nicht eingegriffen werden. Dennoch muss der Abfall integriert werden. Das folgende, einfache Beispiel
soll das Grundproblem illustrieren.

Beispiel: S1 → T1 → S2
→ S3

S1 = Rohstoff (100%)
S2 = Abfall (20%) Abbildung 3: Beispiel (eigener Entwurf)
S3 = Produkt (80%)

Auf das obige Beispiel bezogen bedeutet dies: Aus den Materialbuchungen im SAP-System, den Realda-
ten, geht hervor, dass für die Produktion von einem Stück Produkt S3 ein Stück Rohstoff S1 gebraucht
wird. Der entscheidende Punkt hierbei ist, dass in Stück gerechnet wird und nicht in Kilogramm, wie sonst
üblich in Umberto. Tatsächlich würden aus 1 kg Rohstoff 0,8 kg Produkte entstehen. Diese Tatsache wird
jedoch ignoriert, da sie in diesem Fall irrelevant ist. In der Transition steht für diese beiden ein Koeffizient
mit dem Wert 1.
Die Menge des nun hinzukommenden Abfalls ist in der Regel davon abhängig, wie viel produziert bzw.
verbraucht wurde. In diesem Fall 20% des erzeugten Produkts (es wird immer noch von 1-1 ausgegangen).
Um den Koeffizienten für den Abfall zu bestimmen, muss lediglich die Menge des Abfalls in Relation zu
den erzeugten Produkten gesetzt werden. Bei Fertigprodukten ist die Menge bekannt, da diese in einem
Materialfluss steht. Bei Zwischenprodukten ist die Menge noch nicht bekannt. Also muss zunächst das
Modell einmal ohne Abfälle durchgerechnet werden, um alle Mengen zu erhalten. Daraus erhält man die
Menge der erzeugten Produkte (beziehungsweise aller Materialflüsse) und die Menge des angefallenen
Abfalls und kann den Koeffizienten für den Abfall bestimmen. Es muss auch noch nicht einmal der Mate-
rialfluss gesetzt werden, da dieser von Umberto berechnet wird.
Durch das Hinzufügen von zusätzlicher Masse, in Form von Abfall, stimmt die Massenbilanz nicht mehr,
da mehr Output erzeugt wird, als Input hineingeht. Das wird aber ebenfalls ignoriert. Zum Einen werden
die Fertigprodukte nur in Stück bewertet, zum Anderen stehen nicht für alle Materialien Gewichte zur
Verfügung. Da am Ende auf Stück Produkte skaliert wird, spielt eine Massenunausgewogenheit keine Rol-
le. Ein Flussdiagramm zu dem Vorgehen zeigt die Abbildung 4.

21
Vgl. Erdelt, Hoffmann, Witte (2009)


Original -Modell
kopieren

Kopie-Modell
berechnen

Transition Tx ,
Verbindung Vx ,
Solange Abfall für Kopie -Modell
Referenzfluss R und Ja Nein
Periode vorhanden berechnen
Koeffizient K R
identifizieren

Koeffizient Kx berechnen :
Kx = (Abfallmenge / R) * KR

Kopie -Modell : Abfall-Material und
Koeffizient Kx in Transition Tx
eintragen , als Ziel die an die
identifizierte Verbindung Vx
angeschlossene Stelle einstellen

Abbildung 4: Flussdiagramm (eigener Entwurf)

Auf den in Abbildung 4 dargestellten Untersuchungszeitraum, die Periode, muss insbesondere hingewie-
sen werden. Stimmt nämlich die Umberto-Periode nicht mit dem Erfassungszeitraum des Abfalls überein,
muss dies in der Berechnung des Koeffizienten berücksichtigt werden.
Die technische Umsetzung für die Kommunikation wird über die Microsoft COM-Schnittstellen realisiert,
die Umberto bereits mitbringt. Für die Nutzung dieser Schnittstellen hat die ifu Hamburg GmbH freundli-
cherweise eine C#-Wrapper-Bibliothek mit einem entsprechenden Dienst für die Integration in Empinia
bereitgestellt.

4 Zusammenfassung und Ausblick
Zusammenfassend lässt sich sagen, dass mit Hilfe dieser Anwendung die grundsätzlich Voraussetzung
dafür geschaffen wurde, um das Abfallaufkommen bei der BAE Batterien GmbH zu verwalten. Obwohl es
sich hierbei um eine prototypische Umsetzung handelt, in der noch nicht alle Anforderungen vollständig
umgesetzt wurden, wird zum jetzigen Zeitpunkt eine systematische Erfassung unterstützt. Basierend auf
dieser Datenbasis kann mit Hilfe der Berichterstellungskomponente das Abfallaufkommen ausgewertet
und in Form einer jährlichen Abfallbilanz an den Gesetzgeber derzeitig noch analog übermittelt werden.
Anhand des Konzeptes für die Abfallherkunft wurde die Grundlage geschaffen, eine verursachungsgerech-
te Zuordnung des Abfalls vorzunehmen. Mittel- bis langfristig gesehen kann somit das Abfallaufkommen
einzelner Anfallstellen ausgewertet, analysiert und gegebenfalls optimiert werden. Dadurch wird das Ab-
fallaufkommen reduziert und eine Verringerung der Kosten durch erhöhte Materialeffizienz angestrebt.
Die Integration mit Umberto – welche derzeitig noch nicht implementiert ist – soll in Zukunft die realen
Abfalldaten mit in die Stoffstromanalyse integrieren. Einerseits soll somit eine Validierung der Modell-
rechnung anhand der Ist-Daten erfolgen. Darüber hinaus sollen die Materialien im Modell mit den Abfall-


daten synchronisiert, danach jedes Material anhand seiner Herkunft einer oder mehreren Transitionen zu-
geordnet und schließlich die entsprechenden Koeffizienten berechnet werden. Durch die Automatisierung
dieser Arbeit wird die Fehleranfälligkeit genommen und das Modell kann dennoch ohne großen Arbeits-
aufwand aktuell gehalten werden.
Empinia bietet eine gute Voraussetzung, um die Anwendung in Zukunft individuell den Anforderungen
anzupassen, denn mit Hilfe des Plugin-Mechanismus kann auf relativ einfachem Wege die Funktionalität
der Abfallverwaltungssoftware erweitert werden. So muss zum Beispiel noch das elektronische Abfall-
nachweisverfahren (eANV) umgesetzt werden, damit eine automatisierte Übertragung an die ZKS erfol-
gen kann. Die gesetzlichen Vorlagen bezüglich der Nachweispflicht wären dann vollständig erfüllt.
Ein weiterer Punkt ist der noch nicht vollständig abgedeckte Arbeitsablauf des Abfallbeauftragten in der
Software. So kann beispielsweise ein erfasster Abfall derzeitig nicht als entsorgt markiert werden. Folg-
lich ist eine Unterscheidung zwischen dem Lagerbestand und dem Bestand der entsorgten Abfälle noch
nicht möglich. Allerdings erscheint dies als gut lösbar durch das elektronische Nachweisverfahren, da hier
eindeutig ersichtlicht wird, wann der Abfall bei einem Entsorger angekommen ist und somit als entsorgt
gelten kann.
Des weiteren birgt der Einsatz mobiler Datenerfassung und Abgleich mit der Abfallverwaltungssoftware
und der Datenbasis ein großes Potenzial zur weiteren Arbeitserleichterung und größeren Effektivität des
Abfallbeauftragten.

Danksagung
Das Forschungsprojekt wird vom Bundesministerium für Bildung und Forschung (BMBF) gefördert.
Die Verfasser danken für die Unterstützung.

Literatur
Balzert, H. (1999): Lehrbuch der Objektmodellierung. Spektrum, Akad. Verl., Heidelberg, Berlin.
Beck, K. (2005): Extreme Programming Explained, Second Edition. Addison-Wesley, Boston.
Busse T., Denz N., Page B. (2008): A Plugin-Based Framework for Domain Models and Persistence in
Environmental Management Information Systems. In: EnviroInfo 2008 Conference Proceedings,
Shaker, Aachen, S. 593-602.
Cwalina, K., Abrams, B. (2007): Richtlinien für das Framework-Design: Konventionen, Ausdrücke und
Muster für wiederverwendbare .NET-Bibliotheken, Addison-Wesley.
Denz N., Schnackenbeck T. (2008): Functionality and Granularity of Plugins and Components, Whitepa-
per
Erdelt J., Hoffmann B., Witte S. (2009): Durchführung einer ökonomischen und ökologischen IST-
Analyse bei einem Batteriehersteller. In: 2. BUIS-Tage Konferenzband.
Evans E. (2004): Domain-driven design: tackling complexity in the heart of software. Addison-Wesley
Longman, Amsterdam; 1. Auflage.
Fowler, M. (2002): Patterns of Enterprise Application Architecture, Addison-Wesley.
Gamma, E., Helm, R., Johnson, R., Vlissides, J. (2004): Entwurfsmuster: Elemente wiederverwendbarer
objektorientierter Software. Addison-Wesley.
Gesetz zur Vereinfachung der abfallrechtlichen Überwachung – vom 15. Juli 2006. BGBl I, Seite 1619
Griffel, F. (1998): Componentware - Konzepte und Techniken eines Softwareparadigmas. d-punkt, Hei-
delberg.


Jahr P., Schiemann L., Panic D., Mäusbacher M., Schnackenbeck T., Wohlgemuth V. (2009): Entwick-
lung von Produktionssystem-Komponenten zur Stoffstromsimulation auf Basis des Open-Source-
Frameworks Empinia. In: Simulation in den Umwelt und Geowissenschaften
Johnson, R., Foote B. (1988): Designing Reusable Classes. In: Journal of Object-Oriented Programming,
June/July 1988, Volume 1, Number 2, S. 22-35
Klein U. (2007): Reform der abfallrechtlichen Überwachung. Müll und Abfall 39 (5), S. 240 – 244
Knäpple H. J. (2007): Die neue Nachweisverordnung. Müll und Abfall 39(1), S. 25 – 28
NachwV – Verordnung über die Nachweisführung bei der Entsorgung von Abfällen – vom 20.10.2006.
BGBl I, Seite 2298
Richter, J. (2006): Microsoft .NET Framework-Programmierung in C#: Expertenwissen zur CLR und dem
.NET Framework 2.0, 2. Auflage, Microsoft Press.
Schnackenbeck, T., Panic, D., Wohlgemuth, V. (2007): Eine offene Anwendungsarchitektur als Funda-
ment eines Methodenbaukastens für betriebliche Umweltinformationssysteme. In: Simulation in den
Umwelt- und Geowissenschaften, Shaker, Aachen, S. 49-59.
Wohlgemuth, V. (2005): Komponentenbasierte Unterstützung von Methoden der Modellbildung und Si-
mulation im Einsatzkontext des betrieblichen Umweltschutzes, Shaker, Aachen.

Entwicklung einer Software auf Empinia-Basis für die Abfallverwaltung eines Batterieherstellers

Recommandé

Recommandé

Contenu connexe

En vedette

En vedette (20)

Entwicklung einer Software auf Empinia-Basis für die Abfallverwaltung eines Batterieherstellers