Multidynamic, multilayered, multidimensional aspects in an emission inventory system

1
Multi-dynamic, multi-layered, multi-dimensional
aspects in an emission inventory system

• Heinrich Humer, Gerald Schimak, Peter Kutschera
• ARC seibersdorf research (IT)
• Wilfried Winiwarter, Rudi Orthofer
• ARC systems research

2
Overview

• Emission inventory in general
• Special IT problems in these tasks
• Scenario Management
• Multi dimensional analysis
• Application service providing (ASP) concept,
  multi organization platform
• 100 Generation from Case-Tool as a general goal

3
Emission inventory in general
4
General tasks of calculation are relatively simple

• Input Data
• Questionnaire
• Statistics
• Emission Factors
• Temporal Resolution
• Spatial Resolution
• Models
• emiCO activityX emifactCO
• Results
• Point / Line / Area Emission for SO2, Nox, NMVOC,
  CO, CO2 and PM10

5
SNAP CodeSelected Nomenclature for sources of
Air Pollution
6
Approaches for estimation

• Bottom up
• Summing up point sources and results of
  questionnaires, measurements and statistics to
  emission results for
• counting units
• local governmental units
• districts
• countries

• Top down
• Dividing global amounts (disaggregation) to the
  subunits using statistical information.
• No detail information is available
• Example
• Varnish by population

7
Mulit-layered dimension
8
Special IT problems in these tasks I

• Data have to be collected from several primary
  data sources
• Periodic updates with different periods necessary
• Syntax- and semantic problems
• Management problem
• Quality assurance (quality and completeness)
• Goal
• Wide range of simple import facilities of data
• Support of basic data acquisition / preparation
  tools (Excel, flat files, )

9
Special IT problems in these tasks II

• Everything is changing over time (multi dynamics)
• The set of input data might change over time
• Also models can change
• Data and algorithms might change
• Goal
• We need a tool for long term observation, highly
  configurable
• We need a minimum set of common conventions

10
Special IT problems in these tasks III

• Experts in using inventories for decision making
  are not always also experts in operating data
  management systems
• Desktop data analysis tools are not suitable for
  long term data management
• Mixing between data and User Interface
• Professional support for database and basic
  algorithms
• Goal
• Outsourcing operation of database and basic
  support of application

11
Everything is changing and multi-dynamic
12
Scenarios and Groups

• Data groups
• Logical associated set of input and model data
  (data domain)
• A group can consist of table slices or of several
  database tables
• A group has a name and description and can be
  modified in versions
• Scenario
• A scenario represents for a special question and
  includes a set of selected versions of data
  groups.
• Scenarios have names and description.
• All modifications are logged automatically

13
Scenario manager

• Allows comparison of data records of different
  situations
• Different years
• Different political strategies
• Different models
• Quality assurance for scenario evaluation
• Project management tool
• Version management
• Not a dumb duplication of data !!
• No database administrator needed !!

14
Architecture of database tables
Version managed
Parameter lists, constants
Historical tables
OBJECT_ID SZM_VERSION_REF CREATED_DATE ....
C_ Tables
.... ..... VAILD_FROM VALID_TO
Valid/Actual version(s) are derived from
reference date of the scenario
Valid version is associated in scenario
manager. Versions are organization specific.
Calculation algorithms(Simulator) Version managed
Scenario specific results
Reports, dimensions
OBJECT_ID SZENARIO_REF CREATED_DATE ....
Formulas
15
Reporting in different Dimensions
16
Software Architectur Three Tier Architecture

• Database-Tier
• Oracle RDBMS 9i
• Data model Multi organization support, Version
  management, Historical trend analyses without
  copying ALL data.
• Application-Server
• Access through Web-Services (SOAP) and WebAccess
• Client
• Java programs, activated by Java Webstart
• CASE-Tool
• Oracle Designer 2000 XML-Generators

17
System Architecture
Oracle Designer 2000
Repository
Configuration is generated
.xml
Navigator / Browser Web access for
data Administration Questionnaires Upload of data
Database Oracle 9i
Tomcat Web-Server
Multi organization supportVersion management
Web services, SOAP
18
Login at the application server

• Java Web Start for automatic software
  distribution
• Supporting of different clients with different
  characteristics (ASP concept)
• Platform independent
• Distributed computing

19
Scenario browser

• Switching scenarios
• Configuring scenarios
• Browsing input data
• Importing and exporting of data
• Filtering and editing
• 100 generic browser controlled by repository in
  the CASE tool (XML-Description of data model)

20
Configuring within a standard CASE tool

• CASE tool as a backbone repository of generic and
  specific structures
• End users see only configured GUIs
• Definition of data representations (Subsets,
  languages)
• Generation of XML-Description for user interface
  layout for each supported organization
• Automatic distribution of XML-definitions

21
Data access for Office Application through Web
Access
22
Point Sources
23
Line Sources
24
Area Sources
25
Special area of interest
26
Conclusion

• Multi organizational platform and multi dynamic
  problem solution
• Each organization has the advantage to have an
  individual modeling platform, but there is also
  the possibility to join these datasets in order
  to perform cross-border evaluations
• ASP solution
• advantage of this architecture is the possibility
  to outsource the maintenance of hardware and
  software.
• Efforts in developing new functionality,
  improvements in algorithms and modeling methods
  can be made centrally and the costs can be shared
  between several institutions.
• Common software architecture for emission
  inventories