|
|
|
# Overview
|
|
|
|
Classes of the "time" package allow management of the simulation time in FAME.
|
|
|
|
|
|
|
|
* [TimeStamp](TimeStamp) a point in simulation time
|
|
|
|
* [TimeSpan](TimeSpan) time duration - delta between two points in time
|
|
|
|
* [TimePeriod](TimePeriod) period of time - starting & ending at specific simulation times
|
|
|
|
* [TimeOfDay](TimeOfDay) a time duration relative to the start of a day
|
|
|
|
|
|
|
|
# Goals & Non-Goals
|
|
|
|
All agents are obliged to use FAME's Time classes to represent time within the simulation context.
|
|
|
|
|
|
|
|
Time classes are successfully implemented when each TimeStamp has a unique simulation time representation and are cross-simulation consistent.
|
|
|
|
|
|
|
|
The time classes are not intended to represent wall-time or tick-time events.
|
|
|
|
|
|
|
|
# Current Solution
|
|
|
|
In current AMIRIS simulation time is an "int" bound by definition to a certain real-time hour, i.e. "AMIRIS-time = 0" is the first hour of the year 2006. A fixed time interval between ticks is assumed: hours. Time
|
|
|
|
differences are represented as int as well. If an agent needs a certain time, an int comparison is used. For time intervals, modulo operations are used.
|
|
|
|
|
|
|
|
# Proposed Solution
|
|
|
|
Use class TimeStamp to represent simulated time. TimeStamp has a formatted output that allows an easy conversion to corresponding real-world time. TimeStamps have a unique representation of simulated times based on a variable of type **long**. The value 0 of this variable represents the first second in the year 2000. Simulation time assumes: 365 days per year, 24 hours per day and 730 hours per month. This is not
|
|
|
|
true for real-world time, due to leap-years, summer / winter time and uneven month durations.
|
|
|
|
|
|
|
|
TimeStamps can be "shifted" to represent future or past TimeStamps using TimeSpan-objects. TimeSpans can be constructed based on simulation time Intervals. Intervals represent typical simulation time intervals, e.g. days, hours, weeks, etc.
|
|
|
|
|
|
|
|
TimeStamp know of their special simulation time representation: e.g. if they are "the beginning / end of a day, hour, minute, week, month,...)"
|
|
|
|
|
|
|
|
# Alternative Solutions
|
|
|
|
An external DateTime library was considered as basis for simulation time. It was decided not to use "uneven" real-time, as this hampers the transfer of data from different years due to different year lenghts and summer / winter time transitions.
|
|
|
|
|
|
|
|
# Cross-Team Impact
|
|
|
|
<table>
|
|
|
|
<colgroup>
|
|
|
|
<col style="width: 42%" />
|
|
|
|
<col style="width: 57%" />
|
|
|
|
</colgroup>
|
|
|
|
<thead>
|
|
|
|
<tr class="header">
|
|
|
|
<th>Impactor</th>
|
|
|
|
<th>Answers</th>
|
|
|
|
</tr>
|
|
|
|
</thead>
|
|
|
|
<tbody>
|
|
|
|
<tr class="odd">
|
|
|
|
<td>What maintenance effort to keep element running?</td>
|
|
|
|
<td>very low - defined once</td>
|
|
|
|
</tr>
|
|
|
|
<tr class="even">
|
|
|
|
<td>What latency caused to the system?</td>
|
|
|
|
<td>very low - primitive type "long" needs 8 Byte → fast</td>
|
|
|
|
</tr>
|
|
|
|
<tr class="odd">
|
|
|
|
<td>Tightly coupled to</td>
|
|
|
|
<td>all Agents; Scheduler</td>
|
|
|
|
</tr>
|
|
|
|
<tr class="even">
|
|
|
|
<td>Negative consequences?</td>
|
|
|
|
<td>no 1:1 transfer between real-time and simulated time possible</td>
|
|
|
|
</tr>
|
|
|
|
</tbody>
|
|
|
|
</table>
|
|
|
|
|
|
|
|
Discussion
|
|
|
|
========== |
|
|
\ No newline at end of file |
