Quelltext der Seite Operationeller Einsatz von Talsim-NG/en

<languages/>
<div class="mw-translate-fuzzy">
If TALSIM-NG is to be used in operational mode, some preliminary work is required. This becomes clear in the following process flow:
</div> 

Eine alternative Möglichkeit ist, Talsim-NG innerhalb eines bestehenden operativen Frameworks (wie z.B. [[Special:MyLanguage/Delft-FEWS|Delft-FEWS]]), welches die Aufgaben des Pre- und Postprocessings übernimmt, einzusetzen.

==Preprocessing==

TALSIM-NG itself is not designed to retrieve measuring sensors. As a rule, established tools are already available for this purpose. From TALSIM-NG's point of view, the process sequence begins with the interface to a data supplier (control system, control software, etc.). The design of the interface varies from case to case and requires precise coordination. The aim is to provide the required data in a timely manner. It is irrelevant whether the data request is started by TALSIM-NG or whether data is to be accumulated and reacted to by TALSIM-NG in a time-controlled manner. In the end, current measurement data is available in a time-defined or variable rhythm. The interface is part of the preprocessing, which is operated by a separate tool in the TALSIM-NG product family, the TaskServer.

If the current data are read out via interface, they are usually archived in the own time series management. The next step is to check the accumulated data. A check will always be necessary if unchecked raw data are read in. The type and range of checks have to be determined in each individual case and are defined in so-called tasks. The TaskServer reads these tasks and implements them. Behind this, there is a kind of scripting language that describes what exactly has to be implemented. These tasks are saved in files and are configured for the specific case.
Checks can take place at different depths:

* 1st order test:  basic test of a time series in itself
:- Min-, Max values
:- Allowed gradients
* 2st order test: extended test with derived values
:- Correlation to other measured values/ confidence intervals
:- hydrological tests
* 3st order test: 
:- Rule tree with transfer functions
:- Neural networks to determine substitute values

Picture

In the case of a 2nd or 3rd order examination, the focus of the work is on providing the examination rules. 

Like all other process steps, the results of the test can also be stored in report form, e.g. as PDF.


<span id="Prognosen"></span>
== Forecasts==

The type of forecasts depends on the respective application. In case of a pure rainfall-runoff modelling it is obvious to provide expected precipitation. The principle process is comparable to the interface for data transfer.


==Simulation==

A preconfigured data set must be available for the simulation. Although changes to the data set are possible at any time via the graphical user interface of TALSIM NG, a distinction is made between the production data set, which is used for sharp operation, and any number of derivatives or variants thereof. 

Basically, no user input is required for a simulation. However, it is in principle possible to release certain parameters which have to be set before the simulation starts. These editable parameters are called Hot Spots. In this way, even an extremely complicated system can be reduced to a simple input of a few values without the risk of unwanted effects due to incorrect input.


== Postprocessing ==

The TaskServer takes over the postprocessing. This step includes the compilation of the most important results, the export of result charts in other formats or a graphical representation of the recommendations for action. 


<span id="Datentransfer_zurück_zu_einem_Leitsystem"></span>
== Data transfer back to a control system ==

If necessary, data can also be returned to the data supplier from TALSIM NG. 


<span id="Gesamtsteuerung_des_Ablaufs"></span>
== Overall control of the sequence ==

The overall control of the process is handled by the so-called jobService. Together with the time control system talsimCronos can operate both event and time controll. The entire process has a modular structure, i.e. it is defined in detail which sub-processes are required and in which order they should run. Thus, it is also conceivable that only one pre- and postprocessing takes place, or pre- and postprocessing run in a different time cycle than simulations.