Wiki source code of Project goals

Version 10.1 by cbu on 2014/05/12 21:22
Show last authors
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
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.
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
16
17
18 **The following goals should definitely be reached (if we get modules in Kieler):**
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
27 **In addition, the following optional goals might be reached, if there is enough time:**
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
31 * (((
32 Trains should drive slowly at the points
33 )))
34
35 **Road Map:**
36
37 {{code}}
38 13.5. Presentation
39 27.5. Station-Station Controller + C-Interface
40 17.6. Integrationstesting
41 24.6. Defined testcases with stopflag
42 01.7. Schedules for trains are working
43
44 cw 34 Final presentation
45 cw 35 Excursion to Miniatur Wunderland
46 {{/code}}
47
48 **
49 **
50
51 **Current work distribution: **
52
53 **
54 **
55
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
92 **
93 **
94
95 **Implementation in short:**
96
97 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 an 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 exists of all train stations, and additionally, if one train with a low priority exists 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.
98
99 === **Implementation in detail:** ===
100
101 **Basic Track:**
102
103 The behaviours of a basic track is described as follows:
104
105 **Sample Pass for one Track (in pseudocode)**
106
107 {{code linenumbers="true"}}
108 state Foo
109 --> Gleissegment with contact(Segment,0)
110 state Gleissegment {
111 entry / req(next_Segment);
112 entry / setSignal(prevSegment, red);
113
114 inital state Entry
115 --> Continue with contact(Segment,0) & perm_next_Segment
116 --> Slowdown with contact(Segment,0);
117
118 state Slowdown {
119 entry / setSpeed(Segment,SLOW);
120 } --> Waiting with contact(Segment,1)
121 --> Continue with perm_next_Segment;
122
123 state Waiting {
124 entry / setSpeed(Segment,BRAKE);
125 } --> Continue with perm_next_Segment;
126
127 state Continue {
128 entry / setSignal(Segment,green);
129 entry / setSpeed(Segment,full);
130 entry / setSpeed(nextSegment,full);
131 entry / setSignal(nextSegment, red);
132 entry / free(prevSegment)
133 entry / setSpeed(prevSegment,OFF);
134 }--> leave immediate;
135
136 final state leave;
137 }
138 {{/code}}
139
140 Behaviour modeled in an SCChart (without deadlock prevention):
141
142 [[image:attach:csp_default_pass.png]]
143
144 **Station-Station Modules**
145
146 Input: Zugnummer, Startgleis, Zielgleis, Cleanup, (Mutex Variablen?)
147 Output: "Echtes" Zielgleis (Ausweichgleis?)
148
149 Modules needed:
150
151 * KH-KH
152 * KH-KH (other way round)
153 * KH-IC
154 * IC-KH
155 * KH-OC
156 * OC-KH
157 * IC-IC
158 * IC-OC
159 * OC-IC
160 * OC-OC
161
162
163
164 **Example for track segment requests (with 2 trains):**
165
166 === [[image:attach:nbw-mutex-sct.png]] ===
167
168 === C-Interface ===
169
170 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.
171
172
173
174 **Test cases: **
175
176 Our Implementation should pass the following simple tests:
177
178 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.
179 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.
180 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.
181 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.
182 1. Cleanup
183
184
185
186 == Organization ==
187
188 Meetings: Every Wednesday at 4 pm.
189
190

Navigation

Quick Links

KIELER on GitHub
RTSYS Homepage