Skip to Content

Changes for page Project goals

Last modified by Alexander Schulz-Rosengarten on 2025/01/30 12:05
From version 13.1
edited by csp
on 2014/05/13 10:38
Change comment: added cleanup region in default_pass-sct
To version 8.1
edited by cbu
on 2014/05/12 19:29
Change comment: There is no comment for this version

Summary

Details

Page properties
Author
... ... @@ -1,1 +1,1 @@
1 -XWiki.csp
1 +XWiki.cbu
Content
... ... @@ -13,9 +13,9 @@
13 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 14  {{/info}}
15 15  
16 -== **Goals** ==
16 +
17 17  
18 -**The following goals should definitely be reached (if we get modules in Kieler):**
18 +**The following goals were defined:**
19 19  
20 20  * At least 5 trains can drive on the track at the same time
21 21  * A "cleanup" function for trains should drive all trains to their original position
... ... @@ -24,174 +24,75 @@
24 24  * All signals are working correctly
25 25  * Gates should close, when a train is coming, and open again afterwards
26 26  
27 -**In addition, the following optional goals might be reached, if there is enough time:**
27 +**Additionally the following optional goals were defined:**
28 28  
29 29  * Deadlock avoidance: Trains should never run into a deadlock
30 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 -)))
31 +* Trains should drive slowly at the points
34 34  
35 -== **Road Map:** ==
33 +
36 36  
37 -**
38 -**
35 +
39 39  
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
37 +=== Sample Pass for one Track ===
46 46  
47 -cw 34 Final presentation
48 -cw 35 Excursion to Miniatur Wunderland
49 -{{/code}}
50 -
51 -**
52 -**
53 -
54 -=== **Current work distribution: ** ===
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 -== **Implementation in short:** ==
93 -
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.
95 -
96 -== **Implementation in detail:** ==
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 -
104 104  {{code linenumbers="true"}}
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)'
40 +state Foo
41 +--> Gleissegment with contact(Segment,0)
42 +state Gleissegment {
43 + entry / req(next_Segment);
44 + entry / setSignal(prevSegment, red);
45 +
46 + inital state Entry
47 + --> Continue with contact(Segment,0) & perm_next_Segment
48 + --> Slowdown with contact(Segment,0);
49 +
50 + state Slowdown {
51 + entry / setSpeed(Segment,SLOW);
52 + } --> Waiting with contact(Segment,1)
119 119   --> Continue with perm_next_Segment;
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;
54 +
55 + state Waiting {
56 + entry / setSpeed(Segment,BRAKE);
57 + } --> Continue with perm_next_Segment;
58 +
59 + state Continue {
60 + entry / setSignal(Segment,green);
61 + entry / setSpeed(Segment,full);
62 + entry / setSpeed(nextSegment,full);
63 + entry / setSignal(nextSegment, red);
64 + entry / free(prevSegment)
65 + entry / setSpeed(prevSegment,OFF);
66 + }--> leave immediate;
67 +
68 + final state leave;
144 144  }
145 145  {{/code}}
146 146  
147 -Behaviour modeled in an SCChart (without deadlock prevention):
72 +=== Roadmap ===
148 148  
149 -[[image:attach:csp_default_pass.png]]
74 +{{code}}
75 +13.5. Präsentation Annahme: Wir bekommen Interface für Module
76 +27.5. Station-Station Controller + C-Interface
77 +17.6. Integrationstests
78 +24.6. Definierte Testfälle mit Stoppflag
79 +01.7. Fahrpläne
150 150  
151 -**Station-Station Modules**
81 +KW 34 Abschlusspräsentation
82 +KW 35 Exkursion Miniatur Wunderland
83 +{{/code}}
152 152  
153 -Input: train number, departure track, destination track, Cleanup flag, (mutex variables necessary?)
154 -Output: "real" destination track (alternative destination track)
85 +== Interfaces ==
155 155  
156 -Modules needed:
87 +=== C-Interface ===
157 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
89 +klar
168 168  
169 -
91 +=== Station-Station Module ===
170 170  
171 -**Example for track segment requests (with 2 trains):**
93 +Input: Zugnummer, Startgleis, Zielgleis, Cleanup, (Mutex Variablen?)
94 +Output: "Echtes" Zielgleis (Ausweichgleis?)
172 172  
173 -=== [[image:attach:nbw-mutex-sct.png]] ===
96 +== Organisation ==
174 174  
175 -**C-Interface**
176 -
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.
178 -
179 -
180 -
181 -**Test cases: **
182 -
183 -Our Implementation should pass the following simple tests:
184 -
185 -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.
186 -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.
187 -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.
188 -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.
189 -1. Cleanup
190 -
191 -
192 -
193 -== **Organization** ==
194 -
195 -Meetings: Every Wednesday at 4 pm.
196 -
197 -
98 +Regelmäßiges Treffen Mittwochs 16:00
Confluence.Code.ConfluencePageClass[0]
Id
... ... @@ -1,1 +1,1 @@
1 -9470784
1 +9470774
URL
... ... @@ -1,1 +1,1 @@
1 -https://rtsys.informatik.uni-kiel.de/confluence//wiki/spaces/SS14Railway/pages/9470784/Project goals
1 +https://rtsys.informatik.uni-kiel.de/confluence//wiki/spaces/SS14Railway/pages/9470774/Project goals