Controller - Hardware abstraction

Page / - last modified by stu115775 on 2025/01/30 12:17

Hardware abstraction

last modified by stu115775

on 2025/01/30 12:17

Table of Contents

Features

Interacting parts

The Hardwarecontrol should give an abstraction for controlling the Hardware which also makes sure some of the base rules apply.

Features

train tracking

block locking/crash avoidance

speed control: 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 following smaller interacting parts:

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 differentiation of bi-directional and uni-directional Elements is made to have simpler 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 fulfill the tasks/rules every connection (each-direction) has the following variables, where in and out 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 that writes each of these independent of the correspoding value in another input interface.