Wiki source code of Project goals

Last modified by Alexander Schulz-Rosengarten on 2025/01/30 12:05

version	line-number	content
3.1	1	{{info title="DEADLINE 13.05."}}
	2	At the end of this summer term a railway controller modelled in SCCharts should exist that is able to //control// the model railway installation. What exactly //control// means is up to you!
	3
	4	Define your project goals! Therefore...
	5
	6	* Define the desired capabilities of your controller.
	7	* Devide your project in several subprojects. Organize the whole team in subteams and determine who is responsible for what.
	8	* Define interfaces between the subteams and/or components the subteams are responsible of.
	9	* Create a detailed roadmap with milestones for each subproject.
	10
4.1	11	You are going to present your plan in a short presentation (latex beamer preferred) in the following week, 13.05. 12:30. The presentation should last 30 min.
3.1	12
	13	Remember, you are going to present your controller at the end of the summer term! Getting this task done right is a very important step to succeed with your controller and this project!
	14	{{/info}}
	15
11.1	16	== Goals ==
3.1	17
9.1	18	The following goals should definitely be reached (if we get modules in Kieler):
8.1	19
	20	* At least 5 trains can drive on the track at the same time
	21	* A "cleanup" function for trains should drive all trains to their original position
	22	* Our test scenarios should work (see Test-Scenarios)
	23	* The trains slow down before braking
	24	* All signals are working correctly
	25	* Gates should close, when a train is coming, and open again afterwards
	26
9.1	27	In addition, the following optional goals might be reached, if there is enough time:
8.1	28
	29	* Deadlock avoidance: Trains should never run into a deadlock
	30	* Cleanup function: All Trains which are still on the track travel to their next destination and afterwards they take the shortest way home
9.1	31	* (((
	32	Trains should drive slowly at the points
	33	)))
8.1	34
11.1	35	== Road Map: ==
8.1	36
11.1	37	**
	38	**
	39
9.1	40	{{code}}
	41	13.5. Presentation
	42	27.5. Station-Station Controller + C-Interface
	43	17.6. Integrationstesting
	44	24.6. Defined testcases with stopflag
	45	01.7. Schedules for trains are working
8.1	46
9.1	47	cw 34 Final presentation
15.1	48	28.08 Excursion to Miniatur Wunderland
9.1	49	{{/code}}
5.1	50
9.1	51	**
	52	**
	53
11.1	54	=== Current work distribution: ===
9.1	55
10.1	56	\|=(((
	57	Task
	58	)))\|=(((
	59	Assigned Persons
	60	)))
	61	\|(((
	62	C-Inteface
	63	)))\|(((
	64	Alexander
	65	)))
	66	\|(((
	67	Mutual Exclusion
	68	)))\|(((
	69	Nis
	70	)))
	71	\|(((
	72	Station-to-Station
	73	)))\|(((
	74	Personal assignments
	75	)))
	76	\|(((
	77	Test Scenarios
	78	)))\|(((
	79	Expert-groups
	80	)))
	81	\|(((
	82	Deadlocks
	83	)))\|(((
	84	Carsten
	85	)))
	86	\|(((
	87	Integration
	88	)))\|(((
	89	Small groups, dynamic time schedule
	90	)))
	91
11.1	92	== Implementation in short: ==
10.1	93
13.1	94	The main idea is, that we have a universal model of the track segments. From these single track segments, track sections, that connect train stations are modeled and from those track sections, all final schedules for the trains should be build. On each track segment, there should be at most one train: In order to drive over a track, a train must request this track, and afterwards it must free it again (details below). If two trains request the same track section, the priority, which is derived from the train number, decides, which train gets the track section. A train must request all tracks until the next possibility to stop and wait in order to avoid collisions. If the train does not get all track segments, it must free them again in order to avoid deadlocks or delays of other trains. Deadlocks might occur at the exits of all train stations, and additionally, if one train with a low priority exits the Kicking-Horse-path while another train with a higher priority sends an entry-request. It remains to be seen, if additional deadlocks occur. Deadlocks can be resolved by using a superior Mutex-Controller.
9.1	95
11.1	96	== Implementation in detail: ==
9.1	97
	98	Basic Track:
	99
	100	The behaviours of a basic track is described as follows:
	101
	102	Sample Pass for one Track (in pseudocode)
	103
5.1	104	{{code linenumbers="true"}}
13.1	105	scchart Default_Pass {
	106	bool perm_next_Segment;
	107	initial state prev
	108	--> Gleissegment with 'contact(Segment,0)';
	109	state Gleissegment {
	110	entry / 'req(next_Segment)';
	111	entry / 'setSignal(prevSegment, red)';
	112	initial state Entry
	113	--> Continue with 'contact(Segment,0)' & perm_next_Segment
	114	--> Slowdown with 'contact(Segment,0)';
	115	state Slowdown {
	116	entry / 'setSpeed(Segment,SLOW)';
	117	}
	118	--> Waiting with 'contact(Segment,1)'
5.1	119	--> Continue with perm_next_Segment;
13.1	120	state Waiting {
	121	entry / 'setSpeed(Segment,BRAKE)';
	122	}
	123	--> Continue with perm_next_Segment;
	124	state Continue {
	125	entry / 'setSignal(Segment,green)';
	126	entry / 'setSpeed(Segment,full)';
	127	entry / 'setSpeed(nextSegment,full)';
	128	entry / 'setSignal(nextSegment, red)';
	129	}
	130	--> leave immediate;
	131	final state leave;
	132	region:
	133	initial state Entry
	134	--> cleanup with 'contact(Segment, 0)';
	135	state cleanup {
	136	entry / 'free(prevSegment)';
	137	entry / 'setSpeed(prevSegment,OFF)';
	138	}
	139	--> done immediate;
	140	final state done;
	141	}
	142	>-> next with 'contact(nextSegment, 0)';
	143	state next;
5.1	144	}
	145	{{/code}}
6.1	146
9.1	147	Behaviour modeled in an SCChart (without deadlock prevention):
6.1	148
9.1	149	[[image:attach:csp_default_pass.png]]
6.1	150
10.1	151	Station-Station Modules
7.1	152
11.1	153	Input: train number, departure track, destination track, Cleanup flag, (mutex variables necessary?)
	154	Output: "real" destination track (alternative destination track)
7.1	155
9.1	156	Modules needed:
	157
	158	* KH-KH
	159	* KH-KH (other way round)
	160	* KH-IC
	161	* IC-KH
	162	* KH-OC
	163	* OC-KH
	164	* IC-IC
	165	* IC-OC
	166	* OC-IC
	167	* OC-OC
	168
	169
	170
	171	Example for track segment requests (with 2 trains):
	172
	173	=== [[image:attach:nbw-mutex-sct.png]] ===
	174
11.1	175	C-Interface
7.1	176
14.1	177	The C-Interface wraps some general functions, in order to prevent long and ugly host-code statements within the SCCharts. It especially hides the railway pointer. In addition, the C-Interface provides a persistent environment during a macro step. To bring in some randomness, the time, which a train has to wait in a station, is controlled by the C-Interface. Therefore, trains have to notify the interface about their arrival and their departure.
7.1	178
14.1	179	[[Controller C Interface>>attach:controller.h]]
	180
9.1	181
7.1	182
9.1	183	Test cases:
7.1	184
9.1	185	Our Implementation should pass the following simple tests:
7.1	186
9.1	187	1. 3 trains travel from KH-Station to KH-Station in the main travel direction and 2 trains travel from KH-Station to KH-Station into the other direction. A possible problem might be the KH-Pass.
	188	1. 3 trains travel from IC-Station to IC-Station and 1 train travels from OC-Station via IC-Station to OC-Station. This test case tests the behavior of the IC_JCT.
	189	1. 3 trains travel from OC-Station to OC-Station and 1 train travels from IC-Station via OC-Station to IC-Station. This test case tests the behavior of the OC_JCT.
	190	1. 2 trains travel from IC-Station to IC-Station and 2 trains travel from OC-Station to OC-Station and 1 train travels from KH-Station via IC-Station to KH-Station. The problem here might arise from KIO_LN to IC_ST and from IC_ST to KIO_LN.
	191	1. Cleanup
	192
	193
	194
11.1	195	== Organization ==
9.1	196
	197	Meetings: Every Wednesday at 4 pm.
	198
	199