System features

Provide new types of models and simulation algorithms

The system is supposed to provide a growing repository of types of simulation models and algorithms that may be specified and combined in order to perform simulation studies. A general solution for this task is hard to find, since existing simulation systems like INSEL, Stanet or CitySim are not interoperable per se. Therefore, in a first step, ad hoc solutions have to be implemented. However, if we want to develop a more flexible framework for combining simulation models in the future, at least we have to provide meta-information about the model types.

Ad hoc integration of INSEL weather data and simulations into SimStadt

Description and priority

Depending on the geographic location (and altitude?) of a given scenario, INSEL will generate stochastic weather data for a defined time span, e.g. 20 years, and resolution, e.g. hourly. A combined simulation model may use the very same data to compute a) the heat demand of buildings and b) the heat production of thermal collectors.

Stimulus/response sequences

1. Webservice request issued by another system part to create a stream of weather data according to a given scenario. Additional parameters may control which data to provide/omit.

Functional requirements

REQ-1: Use geographic location, seed for random generator, time span and resolution from the scenario description to generate global weather data.

REQ-2: Possibly shape the generation of weather data by parameters taking long time effects like climate change into account.

Ad hoc integration of Stanet simulations into SimStadt

Description and priority

Stanet shall be used to simulate the demand driven central or decentral generation, storage and distribution of heat.

Stimulus/response sequences

1. Modeling the heating network for one or more given scenes in a scenario, including the connections to buildings
   • either within Stanet by modeling the heating network "over" the corresponding 2D city map, and then exporting the network back into the 3D city model
   • or within the 3D city model, and then importing the heating network data into Stanet.
2. Import load curves for individual buildings
3. Triggering simulation over the given time span and time resolution
4. Export of simulation results
   • for combined animation of building demand, heat generation, and network flows within the 3D city model.
   • for statistical analysis.

Functional requirements

TBD

Modeling and simulation

Create an integrated city infrastructure model

Description and priority

Creating a so called integrated city infrastructure model (ICIM, see glossary) is a central task to be supported by the workbench. Some ICIMs aim to represent the reality at past moments in time as accurate as possible, while others will represent virtual (is if) "worlds". Several computations and simulations may be performed based on the structural data given by an ICIM. Priority is high.

Stimulus/response sequences

Interaction with the workbench is given by the following business process model:

Functional requirements

REQ-1.1: Create a new ICIM and define its region

REQ-1.2: Define quality of city model

REQ-1.3: Import CityGML data

REQ-1.4: Automatic repair of city model geometry data

REQ-1.5: Import / edit networks and installations

REQ-1.6: ...

Simulate heat demand in an integrated city infrastructure model

Description and priority

This is an example of a simulation that will be performed within the context of an ICIM Priority is high.

Stimulus/response sequences

Functional requirements

REQ-2.1: Define simulation parameters

REQ-2.2: Define simulation output data

REQ-2.3: Start, stop, pause and observe a chosen simulation run

Analyse simulation algorithms

Description and priority

TBD

Priority: High

Stimulus/response sequences

Functional requirements

Scenarios and data management

Validate and correct 3D geometry data of buildings

Description and priority

Simulation algorithms depend on specific data quality ...

Stimulus/response sequences

Functional requirements

Feature XY (template, copy before use)

Description and priority

Stimulus/response sequences

Functional requirements

Planning tool

Feature XY (template, copy before use)

Description and priority

Stimulus/response sequences

Functional requirements

REQ-0:

REQ-0:

Crowd sourcing

Feature XY (template, copy before use)

Description and priority

Stimulus/response sequences

Functional requirements

REQ-0:

REQ-0:

How to

This template illustrates organizing the functional requirements for the product by system features, the major services provided by the product. You may prefer to organize this section by use case, mode of operation, user class, object class, functional hierarchy, or combinations of these, whatever makes the most logical sense for your product.

Don’t really say “Feature XY.” State the feature name in just a few words.

Description and priority

Provide a short description of the feature and indicate whether it is of High, Medium, or Low priority. You could also include specific priority component ratings, such as benefit, penalty, cost, and risk (each rated on a relative scale from a low of 1 to a high of 9).

Stimulus/response sequences

List the sequences of user actions and system responses that stimulate the behavior defined for this feature. These will correspond to the dialog elements associated with use cases.

Functional requirements

Itemize the detailed functional requirements associated with this feature. These are the software capabilities that must be present in order for the user to carry out the services provided by the feature, or to execute the use case. Include how the product should respond to anticipated error conditions or invalid inputs. Requirements should be concise, complete, unambiguous, verifiable, and necessary. Use “TBD” as a placeholder to indicate when necessary information is not yet available.

Each requirement should be uniquely identified with a sequence number or a meaningful tag of some kind.