The current implementation of the TINE State server consists of a machine state repository. That is, it accepts transient change-of-state triggers, notifies the TINE Event Server of any change of state, maintains a running count of the duration of any given state (also with beam or in machine studies mode), and responds to queries as to the current machine state and current machine procedure.

In most respects, the TINE State server is a simple read-write server without any intermediate logic. It is nonetheless an important server in the control system, as any control system process or automation depending upon the current machine state must get this information from the state server. Similarly, the state counters maintained by the State Server make progress charts of operation history a fairly straightforward exercise.

Specific state changes are grouped into state 'procedures' which can be used to define machine 'profiles'. Making use of these definitions, it is then rather straightforward to obtain a general machine overview over any particular time duration. The time spent 'preparing' or 'operating' can be displayed, along with availability statistics (if the machine was not operating due to 'problems' then these problems should be reflected in critical alarm states, etc.).

As a case in point, consider the operation history of the DORIS machine below:

It is a fairly easy matter to archive the state counters for all of the allowed states of the machine and thus calculate the total time spent between any two time endpoints.

A somewhat more complicated case is the HERA machine, which is a proton-electron collider, and hence a composite of two machines:

By archiving the various state counters along with the alarm system state counters one can easily render machine availability. This is shown below in the case of the DESY2 accelerator:

Although straightforward to set up the database to provide all of this information, it is nonetheless a challenging task to 'get this right the first time', as any newly defined state must also be fed into the central archive system, etc.

Fortunately, an 'Operation History' database manager exists which allows the administrator to add or edit state and procedures as well as define operation profiles which are in turn composed of the states and procedures in the state server's database. The database manager also ensures that the central archiver is properly updated if necessary.