System Architecture

Architectural Goals and Quality

For Heureka, the two most important quality goals are modifiability and performance. The system should be flexible enough to allow maintenance and further development in a cost effective manner. At the same time performance should be good enough to allow simulation on large amounts of data. To a certain extent, these goals are contradictable.

In addition to this, testability is an important quality aspect. As many parts as possible should be possible to test automatically, e.g. with unit testing tools such as NUnit. This sometimes means that sub functions must be made public so that they can be tested from external code. Over time, this goal has been proven more important than originally expected. This means that this goal has not always been met in the existing code, for instance many classes has a lot of dependencies on other classes making them harder to test.*

Other quality goals are less important:

• Security. There are no specific security requirements. The system will use security functions available in the database and operating system.
• Availability. The system is a single user application, so availability is not considered in the architecture.
• Portability. Portability is not required.

Logical View

Forest model and Calculations

The key entity in Heureka is the Treatment Unit, that represents a stand, i.e. an area restricted in space, with the same type of forest. A Treatment Unit is the smallest unit treatments are applied for. Each treatment unit contains one or more predictions units. A prediction unit represents a plot or a cell inside the treatment unit. Each prediction unit contains trees. Trees have different states, identifying if the tree object represents a sapling, a tree, is dead and so forth. Each of these entities handle different time periods.

Treatments are simulated in Heureka with different type of treatment models such as regeneration, fertilization, cleaning, thinning, and final felling.

Growth and yield models calculates tree related values such as volume, basal area growth, height, age, and bark thickness. With help of the growth models, a treatment unit can grow, i.e. the state in a future time period can be calculated.

Result models are used to calculate different types on results. Based on the state of a treatment unit in a given time period, different types of results can be calculated, such as cost and revenue of treatments, amount of biomass in the living forest, or amount of litter added to the ground. A result model may also produce a result based on the results in other result models (e.g. the recreation model uses input from the dead wood model).

Simulation models or frameworks, allows treatment programs to be calculated for a treatment unit. A simulation model utilizes the growth and yield models, the treatment models, and sometimes also result models, to simulate different alternatives for managing a treatment unit. When growth prognosis and treatments has been simulated for a number of periods, the treatment unit (together with its prediction units and their trees and saplings) contains information about the forest state in all periods that were included in the simulation. The results can be saved in a treatment program, which contains results for all periods with the desired result models.

An optimization model is used to create a plan. A plan consists of a selection of treatment programs (one for each treatment unit in the plan), that gives the best result according to the optimization model. An optimization model is defined using the results from the result models. Any variable produced by a result model can be used in an optimization model. Optimization models differs from other models in Heureka, these are the only models that are defined by the user (all other models are programmed into the system).

Treatment units may be classified in forest domains. A user may define a forest domain, based on variables from the result models. The forest domain is then used to configure a simulation model.

Data Import

A TreatmentUnit can be created from a NFI plot. In this case, aTreatmentUnit and a PredictionUnit is created for each NFI plot (if the NFI plot is splitted a TreatmentUnit and a PredictionUnit is created for each part of the plot).

Similarly FMPP data can be imported into Heureka (not shown in figure).

Another option is to import a stand register. From StandObjects in the stand register, TreatmentUnits can be simulated. In this case, trees or saplings are created for the TreatmentUnit, based on stand level variables in the StandObject. The simulation process is stochastic, meaning that the result will be slightly different each time if repeated several times for the same StandObject.

It is also possible to get data to Heureka by making a sample design, choosing StandObjects to be inventoried, and then to make a field inventory using Ivent, to get real plot data and inventoried trees and from that data create TreatmentUnits.

The last option to get data into Heureka is to manually enter data using StandWise (not shown in figure).

All forest data is stored in a relational database.

Projects

A Project contains ControlCategories and ForestDomains. Each ForestDomain refers to a ControlCategory, and each ControlCategory contains a number of ControlTables, each of which contains user settings for a model or a group of related models in the system.

Also, a Project contains the TreatmentUnits that the user is working with (the TreatmentUnits are actually kept in an AnalysisArea, not shown in the figure).

A Project may also contain other items, such as optimization models (not shown in the figure).

The project information is saved as files in the file system.