5 Principles of operation

The simulator as a whole is a complicated piece of software with many interacting objects. Even though details of the internal functions are hidden away behind a graphical user interface, it may be required to have a minimum understanding of the simulator's operating principles.

The basic principle of the simulator is quite simple: a simulation consists of a set of simulation objects. Each object contains:

• internal state variables.
• methods to change the internal state.
• methods to interact with other simulation objects.

For efficiency reasons some simulation objects handle and update all modules that are of the same type³. Hence, these simulation objects contain additionally:

• modules, all of same type. Modules are similar to simulation objects as they contain
  • internal states
  • methods to to change its state, and to interact with its parent simulation object and other modules.
• methods to interact with modules.

The methods to change the internal state of objects or modules are event-driven. There are principally two types of events:

1. During the simulation is running (after Simulation / Start or Simulation / Continue have been selected) the simulator calls cyclically the update method of each simulation object (see Fig. 10).The update method may then call various methods with parameters of other simulation objects and modules. The time step between two cycles is determined by the sampling-time which can be set in Simulation / Parameters.

2. Object methods are asynchronously called through graphical user interfaces (dialog boxes, control-panel etc.).
3. external calls of methods (parameter settings, etc.)

Figure 10: Simplified functioning of simulator: Simulator calls the update method of simulation objects. Some simulation objects contain a set of modules which are all of the same type. Because modules of the same type have the same functionality, very efficiently numeric- array oriented updates are possible.

All (relevant) simulation objects and modules can be listed and inspected with the object browser: Select Edit / Browse.... As it can be seen in the lists, simulation objects as well as modules have unique identifications (IDs). The naming scheme for simulation objects is:

family name . category . type name

The naming scheme for modules is composed of the parent simulation object ID plus a serial number:

family name . category . type name / serial number

5.1 Simulation objects, modules and their functions

This section gives an overview of the functions of simulation objects and modules and their relation to other objects, see Figure 11.

Figure 11: Simulation objects and their basic relations. Note that the users, carrier and track-elements are container objects for several modules.

users

make trips with the transportation system by giving trip orders with destination to the user management and entering the carrier. There is currently just one user-type: the test-driver, making one random trip after the other.

carriers

(vehicles), transport users along the track. They receive orders from the carrier management to let board a specific user. Carriers also control , together with the current track-element, the distance to other carriers and so called ``ghost carriers'' on parallel branches in conflict zones.

The vehicle-follower control algorithm is currently more optimized for simulation speed rather than for precise/optimized motion control. This means the following differences compared with a realistic control system: (i) there are no jerk-limits (in neither direction); (ii) speed changes of the first vehicle in a vehicle chain is almost instantly and fully propagated through the chain, which results in a reduced ride comfort; Differences (i) and (ii) result in a slightly higher line capacity of the simulated system compared with a real system.However additional time headway, necessary for jerk adaptation and be simulated by increasing the brake actuation time, which is one parameter of carriers.

Speed-limits, maximum comfort/emergency/safet acceleration are respected. All parameters can be modified via Add multiple bottom or control-panels.

track-elements

are capable of guiding carriers along a predefined path. The instructions whether to diverge the carrier in a specific branch, to halt it or to load/unload it, are obtained from the track-management and passed on to the carrier when it enters the specific track element. The track-elements are organized in track clusters (currently all the net is one cluster). Each track cluster is controlled by one track-management and may contain one or more of the following track elements:

• lines, curves or flexible line that guide and control the carrier.

• diverges, where one line splits into multiple lines.

• merges, where multiple lines merge to one line.

• stops, where people or freight gets loaded or unloaded. Stops are also organizing the halt position of carriers, and tell them where to load, to unload, to wait and when to start again. The stop does all that, dependent on which berths users are waiting.

user managements:

provide a costumer friendly interface between user and the transportation system (this interface is currently not visible). User managements receive orders from the users and organizes carriers for this trip by giving orders to the carrier management. User managements would be operated by service providers (in the current version there is just one user managements).

carrier managements:

handle the logistic control of a carrier fleet (in the current version there is just one carrier management). They allocate a carrier from the carrier fleet they control and give orders to the track management. They also optimize the redistribution of empty vehicles. Carrier managements would be operated by transport providers.

track managements:

handle the logistic control of a track cluster (in the current version there is just one cluster). Track managements receive orders from the carrier managements on where to route the carriers. They estimate the path with the shortest trip time from origin to destination and give branch and halt instructions to all track-elements involved. Track managements would be operated by infrastructure providers.

5.2 Logistics and tasks

All managements together (see Fig. 11) perform the logistics of the network by exchanging information among each other, but also with the physical world (track-elements, carriers, users).

Apart from standard administrative operations, the managements currently optimize only the trip-time: They route the vehicle to its destinations on a path that has the shortest expected trip-time. If a branch is blocked, the vehicle is deviated, which will trigger a rerouting. Empty vehicles will be ``intelligently'' routes to the nearest stop with a higher user-demand.

If there is are no passengers at a stop, empty vehicles are send into the network. An empty vehicle is branched into a stop if there are waiting passengers at this moment. There is currently no predictive resource allocation--not for vehicles and neither for the network. This means traffic congestion can occur if the network has a bottleneck.

The organization of the entire logistic is based on the creation, exchange,and execution of tasks: If a management wants to get a service performed by a target (another or the same management or physical module), it must send an order. When the target receives the order, it will create a task for this order. The task inside the target will create one or several actions (or create orders for other managements and/or modules) which are necessary to fulfill the task. The task persist in the target until it is terminated, failed or explicitly killed. In either way the task will report the results to the entity which created the order.

Tasks are the instrument to control the network globally on large time scales. They are the bases for doing distributed, parallel computing in the system's heterogeneous computer network. Note that tasks are a inherent feature of most operating systems. The concept of tasks used in the simulator has been designed to fulfill the special requirements of the transportation network, including physical objects and a multi-level management. In later versions the simulation objects (in particular the management objects) could run on different processors, using the task mechanism of the respective operating system.

The task page of each control-panel shows task ID, status, the order ID and the object/module which created. Modules have usually only one task at a time, management units must handle many tasks simultaneously.

5.3 Local vehicle control

Before explaining the simulated system, a few words to the general PRT control-problem. A controller for short time head-ways needs to meet simultaneously criteria for safety, string stability, comfort and speed transitions.

The safety criteria can be expressed by means of the minimum safety distance $d_{\mbox{\small S}}$ between vehicles that is required to avoid a collision between two consecutive vehicles. In general, $d_{\mbox{\small S}}$ is proportional to the difference between the squared velocities of follower and lead-vehicle. In many control schemes, the level of safety is given by the safety factor $K_{\mbox{\small S}}$ when the actually achievable distance is $K_{\mbox{\small S}}\cdot d_{\mbox{\small S}}$ .

String stability means that a speed change of a vehicle in the string decreases in magnitude when propagating through the following vehicles.

The comfort criteria sets usually limits to the maximum allowed manver accelerations and jerks.

Speed transitions do occur during various vehicle manvers, such as approaching, following, merging, diverging, stopping or velocity changes. It is obviously required to guarantee all the above criteria during all possible speed transitions. One specific transition criteria is the ``fixed end-point speed transition''(FEPST) criterion:all vehicles in the string must be at the lower safe speed at a fixed point of the track, not just the first vehicle.

The optimization criteria for lateral-controller is usually to maximize the line capacity or to minimize head-ways. The theoretical limits of carrying capacity and safety-level are generally set by the adopted vehicle spacing policy. The relevant policies are the constant time headway policy and constant safety policy. Constant time headway offers a constant, speed independent carrying capacity, while the safety factor drops below unity as velocity increases. Constant safety spacing guarantees a $K_{\mbox{\small S}}\geq 1$ . But for higher velocities, the carrying capacity drops below the one of the constant time headway spacing.

Now we introduce the necessary parameters and math: If vehicle $n-1$ has a maximum failure deceleration of $a_{F}$ and the following vehicle $n$ can guarantee an emergency deceleration of $\ae$ by applying the emergency brake after time $T_{E}$ then vehicle $n$ is in a safe state if $d_{n}(t)>d_{\mbox{\small S}}(v_{n}(t),v_{n-1}(t))$ with

$$d_{\mbox{\small S}}(v_{n},v_{n-1})= T_{E}v_{n}+\frac{1}{2}\left( \frac{v_{n}^2}{\ae }-\frac{v_{n-1}^2}{a_{F}}\right).$$ (1)

Parameters $\ae$ , $a_{F}$ , $T_{E}$ , vehicle length $\ell$ and the nominal line velocity $V_{\mbox{\small L}}$ do ultimately determine the line capacity $C$ in vehicles per hour, with

$$C=\cfrac{1}{% \frac{d_{\mbox{\small S}}(V_{\mbox{\small L}},V_{\mbox{\small L}})+\ell}{V_{\mbox{\small L}}} +T_{E}}\times 3600.$$

The nominal line velocity $V_{\mbox{\small L}}$ can be determined individually for each section of the network at the "Section Tab" of the control-panel of the corresponding track-element. In the general case if $a_{F}<\infty$ the plot of the line-capacity over the line-speed results in a curve with zero capacity at $V_{\mbox{\small L}}=0$ , zero capacity if $V_{\mbox{\small L}}\rightarrow\infty$ and a maximum capacity at

$$v_{\mbox{opt}}=\sqrt{\cfrac{2\ell}{\frac{1}{\ae }-\frac{1}{a_{F}}}}.$$

The comfort criteria is introduced by limiting the acceleration $a_{n}(t)$ of each vehicle $n$ at the comfort acceleration $a_{C}$ . If we want to avoid collisions by braking only at at the comfort rate we must respect the minimum comfort distance $d_{\mbox{\small C}}(\cdot,\cdot)$ with

$$d_{\mbox{\small C}}(v_{n},v_{n-1})= T_{E}v_{n}+\frac{1}{2a_{C}}\left( v_{n}^2-v_{n-1}^2\right)$$ (2)

The simulator can do both, constant safety and constant time headway. In fact, constant time headway is a special case of a constant safety, when $\ae =a_{F}$ . The controller of the simulator does simply guarantee that the distance is at all times and for all vehicles grater than both, $d_{\mbox{\small S}}(v_{n},v_{n-1})$ and $d_{\mbox{\small C}}(v_{n},v_{n-1})$ . If there is no vehicle in front, the vehicle will accelerate to the given nominal line velocity, which is a property of the section of the current track element.

Attention: at merge points you have to make sure that the legs of the merge element are at least as long as $d_{\mbox{\small C}}(V_{\mbox{\small L}},V_{\mbox{\small L}})$ , otherwise vehicle won't have the chance to line up properly and crashes may occur.

All accelerations and the brake actuation time should be modified during the ``add multiple'' operation, when adding the carriers to the network. The parameters of individual vehicles can be modified through their control-panel.

The nominal line velocity can be modified for each section at the Sections-tab of the control-panel of each track-element. Section 4.4 explains how to do this.

There is also the possibility to introduce a comfort jerk $j_{C}$ : simply add to the brake actuation time the term $2\frac{a_{C}}{j_{C}}$ . This will add enough time-headway so that the acceleration can adapt at comfort jerk rate in the worst case scenario.