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.