TABLE C2 SYSTEM DEFINITION

System Development System Editing Archiving

KCL-ECO Modules, or system blocks, typically represent manufacturing processes, but can also represent distribution blocks, life cycle stages (i.e., a generic 'use' stage), etc.

Modules are placed on graphical flow sheet from pull-down menu or by clicking tool bar button. Transportation and material flows are associated with arrows (i.e., links) between modules. Associated with each module is a Specify Module card. Here, the module name, inputs and outputs are specified. Module notes (e.g., description of process with references) and input/output equations are entered in subsequent details cards accessed though active buttons on the Specify Module card.

One equation within one Specify Module card must be assigned a reference equation (i.e., functional flow) in the form, 'variable = constant.'

Using the mouse, process blocks can be highlighted to view and edit details, or to delete process.

System arrows can also be highlighted and edited or deleted using the mouse.

New process variables (e.g., inputs/outputs) can be added to variables list from Specify Module card, or from menu options.

Modules and modes of conveyance can be saved to a user-defined library for use in new systems.

Modules and linked systems can also be copied to a clip board from one system and pasted into a new system using common key- strokes or menu commands. All links and flow names are maintained.

LCAiT System blocks represent either process or transportation steps.

Blocks are placed on the graphical worksheet from a pull-down menu.

Each block has a Card which allows the user to define the system. Process Cards define: 1) emissions, wastes and resources resulting from or used in the process; 2) energy carriers and consumption; and 3) resource flows between system blocks. Links must be established before resource flows can be defined. Transportation Cards defined the mode, distance, and utility of transport.

Arrows between blocks represent material flows. Activation of one system block defines the reference flow.

Using the mouse, process blocks can be highlighted to view and edit details, or to delete process.

System arrows can also be highlighted and deleted using the mouse. A warning message is posted if this operation is performed, asking if the user wants to continue.

To calculate an inventory, the system must be compiled. If the system is over-defined, or under-defined, an error messages is posted, with no guidance as to where a problem exists.

A sequence of saving, exporting, and importing allows systems to be used in part or in whole as inputs into separate life cycles. Inventory profiles of saved and exported systems can be imported as the details of a single process block in a newly developed system (reference flow must be 1 kg and the system can not include recycling).

Recalculation of this imported subsystem is not required.

Single process blocks and entire system flows can also be imported into a new flow sheet and recalculated with the newly developed system.

3

TABLE C2 - SYSTEM DEFINITION (Continued)

System Development System Editing Archiving

PEMS System blocks represent materials, processes, energy, waste management options, and external flows.

System blocks are placed on graphical worksheet from pull-down menu.

Transport of either energy or materials is associated with flow arrows (i.e., links) between blocks.

Associated with each block are Object Properties cards in which inputs, outputs, and burdens are specified by the user, as well as a descriptive information in a supporting Information card. An arrow between system blocks is used to define the system's functional flow.

System blocks and arrows can be highlighted and edited/deleted using the mouse. When a block is deleted, all connections to and from the block are also deleted.

To calculate an inventory, the system must be compiled. If the system is under-defined, an error messages is posted, and the process block(s) which is not adequately defined is visually identified in the graphical flow diagram.

Archiving materials, processes, and systems is supported by the software. See User-Defined Data for more details.

Use of saved system in more complex product life cycles is possible through an import option offered in the File menu of the graphical interface.

SimaPro Boxes, or working templates, are used to develop the system to be evaluated.

Assembly boxes (i.e., SimaPro's version of manufacturing process units) are developed by specifying material/assembly inputs and the processes in which these inputs are manipulated. Transport and energy requirements are included as processes.

Emissions for these specified materials/assemblies and processes are contained and drawn from the supporting database to calculate the inventory. Life Cycle boxes complete the life cycle of the system by specifying use and disposal scenarios. Disassembly and Reuse boxes also exist which can be combined within Disposal Scenario boxes, to model end-of-life options and practices.

All boxes and databases can be accessed and edited at any time within the program. From menu options any box can be opened and accessed.

Previously defined and saved assemblies can be used in any other systems (i.e., as Materials/ Assemblies in new Assembly boxes).

Within the set of five databases, the user can also define complex scenarios, allowing for their continual use.

Links between processes within the Processes database are possible.

TABLE C2 - SYSTEM DEFINITION (Continued)

System Development System Editing Archiving

TEAM In TEAM version 1.15, the creation of and access to objects of the LCA system (i.e., Articles, Modules and Nodes) is accomplished from the Project window. The details of each object are contained in supporting window templates. Using menu options or active buttons on the tool bar, the user defines systems and sub-systems in a nested, hierarchical fashion. At the inner-most level of every system/sub-system are defined Atomic Nodes, in which the user defined all inputs and outputs. Atomic Nodes can be derived from Modules contained in either the DEAM or user- defined database ('derived'). Changes to underlying Modules data will change all derived nodes. A free Atomic Node allows the user to specify/detail all inputs and outputs via an Atomic Node window. All sub-systems must be specified and compiled from the lowest level to the highest. Flows between systems and underlying sub-systems can then be defined.

Designating a Node or Module as a transport Node/Module is possible.

Version 2.0 was not made available for this evaluation. However, this newest version of the software allows the user to define System and Atomic Nodes as blocks on a graphical interface. When doubled-clicked, the details of a system node are revealed in supporting graphical worksheets. As with version 1.15, the life cycle must be defined from the lowest level to the highest level. Material flows are defined by connecting an arrow between blocks. The details of Atomic Nodes are specified in Atomic Node windows (as described above).

Functional flows are defined for every Atomic Node (an Article and corresponding flow is activated with a ), as well as within the system Consistency check. This feature of TEAM allows inventory propagation from anywhere within the life cycle.

From the Project window, all objects (Articles, Modules and Nodes) can be accessed and edited by the user.

Articles can be added and Modules can be created/defined from anywhere within the program (i.e., Project window or supporting windows).

Nodes derived from Modules will be changed when the supporting Module is changed.

Articles and Modules can not be deleted if they are linked to the system being developed; an error message is offered if users attempts to perform this function. Functional flows and connections between objects can be changed at any time. Each system/sub-system can be checked for consistency (e.g., functional flows, links etc.). If the system is inconsistent, an error messages is posted and the location of the problem is stated.

An Atomic Module can be derived from an Ecobalance which represents the inflows and outflows of that Ecobalance. This Module can then be used to derive Nodes in other developed systems. 'Tracking' information records the Modules origin and date of creation.

Though only one project can be used at a time, and only one Project can be defined by a given database, on Import/Export function allows the movement/transfer of Articles, Modules, and Nodes between projects.

5