# Usage, Forecasting Horizon and Detection Intervals

## Usage & Forecasting Horizon¶

It is important to clearly communicate when forecasts need to be made and to what horizon they will relate. TIM needs information on both aspects in order to build the most appropriate models. The user can communicate the time of forecasting using the Cron notation and the forecasting horizon using the relative time notation. By default, TIM will understand the forecasting horizon to consist of all samples between the time defined as ‘predictionFrom’ and the time defined as ‘predictionTo’.

## Detection Intervals¶

Similar to the Usage setting for forecasting, there is Detection Intervals setting for anomaly detection. Using the Cron notation, user can specify what parts of day or week the detection model will be used. Again, it can help to build more appropriate models or reduce model building time. By default, detection intervals are set to all samples.

## Examples¶

The following examples might clarify this topic.

### Example 1 – Electricity Consumption¶

In this example, the data has a sampling rate of one hour. Every day at 08:20, a dispatcher wants to forecast the electricity consumption for the next day (i.e. for 24 hours from 00:00 to 23:00).

Usage | Prediction from | Prediction to |
---|---|---|

* 8 20 * | Day+1 | Day+1 |

### Example 2 – System imbalance¶

This exemplary dataset has a sampling rate of 15 minutes. Every hour from 05:50 to 15:50 a trader wants to forecast the system imbalance during the next 2 hours. This results in 8 forecasts, starting with 06:00.

Usage | Prediction from | Prediction to |
---|---|---|

* 5-15 50 * | QuarterHour+1 | QuarterHour+8 |

### Example 3 – Full scale forecasting¶

The data in this example has a sampling rate of one hour. Every hour from 06:00 to 16:00, the expected electricity load during the following 10 days needs to be predicted, future samples within the same day included.

Usage | Prediction from | Prediction to |
---|---|---|

* 6-16 0 * | Sample+1 | Day+10 |

### Example 4 – Solar production¶

This example deals with data with a sampling rate of 15 minutes. Every hour a forecast has to be made of the production of photovoltaic plant (a solar system; PV_prod) starting 3 hours ahead until the end of the day, two days ahead.

Usage | Prediction from | Prediction to |
---|---|---|

* * 0 * | Hour+3 | Day+2 |

### Example 5 - Anomaly detection¶

Data has sampling rate 24 samples per day. Every day from 8:00 to 16:00 (day starts with 00:00) dispatcher wants to detect possible target deviation. The latest record of target is supposed to be always available until the time of detection, otherwise it could not be evaluated. There are two predictors – P1 is available up until the end of the precedeing day and P2 has last value available with a delay of 2 hours. P1 is updated every day at 8:00 and P2 each hour.

Detection Intervals |
---|

* 8-16 0 0 |

## Where to set this in TIM connector and API¶

### Forecasting¶

```
modelBuilding:
configuration:
usage:
usageTime:
- type: Day
value: "Mo-Fr"
- type: Hour
value: "8-16"
- type: Minute
value: "0"
predictionFrom:
baseUnit: Sample
offset: 1
predictionTo:
baseUnit: Day
offset: 2
```

### Anomaly Detection¶

```
modelBuilding:
configuration:
detectionIntervals:
- type: Day
value: "*"
- type: Hour
value: "6-18"
- type: Minute
value: "0"
```

## Where to set this in TIM Studio¶

## Default values¶

### Forecasting¶

Default usageTime is set to 08:20:00; in the Cron notation represented as * 8 20 0. Default predictionFrom and predictionTo are both D+1, representing all samples in the following day.

### Anomaly Detection¶

Default value of detectionIntervals is set to all samples; in the Cron notation represented as * * * *.

## Lower sampling rates¶

For datasets that are sampled monthly or less frequently, the only valid base unit is Sample, because Days, Hours and Minutes do not make sense in this case. The whole part of when the forecast is made is ignored.