The Hardwarecontrol should give an abstraction for controlling the Hardware which also makes sure some of the base rules apply.Tasks/Rules the Hardwarecontrol should manage:
Features
- train tracking
- block locking/crash avoidance
- speed control: slow down(/speed up?)/driveing and parking in a segment
- same speed policy (same speed on all tracks beneath a train)
- automatic signal management
- automatic point branching
...
Interacting parts
The railway is split up into the track into following smaller interacting parts to achive this:
| Segment |
|---|
...
| /Station | 1 Track, 2 Contacts, 1 Signal |
|---|
...
| Segment_bid/Station_bid (bi-directional) |
|---|
...
| 1 Track, 2 Contacts, 2 Signals |
...
| Track |
|---|
...
| 1 Track |
...
| Track_bid |
|---|
...
| 1 Track |
...
| Point_in |
|---|
...
| 1 Point with 2 incoming and 1 outgoing tracks |
...
| Point_out |
|---|
...
| 1 Point with 1 incoming and 2 outgoing tracks |
...
| Point_bid |
|---|
...
| 1 Point, 2 to 1 bi-directional point |
...
| Cross_in |
|---|
...
| 1 Track, 2 Points, has 2 incoming, 1 outgoing and 1 bi-directional track where incoming trains get on the main track and outgoing come from the side track |
...
| Cross_out |
|---|
...
| 1 Track, 2 Points, has 1 incoming, 2 outgoing and 1 bi-directional track where outgoing trains come from the main track and incoming go to the side track |
...
The differenciation differentiation of bi-directional and uni-directional Elements is done made to have simpler Parts parts for the unidirectional parts. The "Station" is actually a Segment mostly in a Station and has the property to guarantee a tick boundry between variables in different interfaces, to prevent immediate loops in interface loops.
With these we can model the railway system by connecting these parts in terms of mapping input and output values according to the connections. To fullfill fulfill the tasks/rules every connection (unieach-directionaldirection) has the following variables, where in and out descibes describes if it's an input/output of the previous part in travel direction:
...
| input | bool | incoming_blocked | (bidirectional only) if true: there should not be any lock requests to prevent a Deadlock by two trains comeing infront of each other |
|---|---|---|---|
| input | bool | lock_request_pending | (bidirectional only) if true: there is a lockrequest waiting to get a lock |
| output | bool | send_lock_request | (bidirectional only) if true: the waiting lock request is actually requested. This is used together with the previous ones to allow faster lock assignment, since otherwise a Track_bid would only pass a lockrequest every other tick to have no more than one lock going thru it. |
output | int | requestLockFor | id of the track to request the lock for |
...
-1: get any next lock |
...
output | int | requestLockTrain | when requestLockFor!=0 the id of the incoming train |
|---|---|---|---|
| input |
...
| bool | Locked |
|---|
...
| the next part is locked and expects an incoming train, lock is |
...
| released when train reaches the next track |
...
| input | bool | Branched |
|---|
...
| the connection to the next "part"(save track) is branched (to set the signal) | |
| input |
...
| bool | PullSpeed |
|---|
...
| the speed to synchronize to have one speed for all used tracks |
...
These should be written in order to have a dependency cycle free model and there has to be a part in each cycle wich that writes each of these in order and first read afterwardsindependent of the correspoding value in another input interface.