A RESPONSE TO: OPERATIONAL CONTROL, HARDWARE,

AND NETWORK ISSUES

by

William G. Turnbull

In a not wholly unfriendly submission, that was at least in part in response to my earlier paper (Some Thoughts on Operation and Control, William Turnbull, 3/27/01), Mr. Goltermann suggested (Operation, Control, Hardware and Network Issues, Kim Goltermann, 6/22/01) several operational choices that would have to be made in the pursuit of an optimal system. While I do not disagree in any fundamental sense with a need to make these (and other) choices, I do believe that some clarification might prove beneficial, particularly as it applies to the system I described.

I Hardware Independent Control Philosophy

Initially, Mr. Goltermann chides me, mildly, in that I failed in my stated purpose of being independent of specific hardware. For instance, he correctly stated that my proposal would exclude constant-frequency LSM’s. But isn’t this the way that large, complex systems are (or should be) developed. One develops an operational and control philosophy and then selects the hardware best suited for the task. Although much hardware is operationally neutral, I believe it would be essentially impossible to devise an operational philosophy that did not favor some types of hardware over others. It is, of course, an iterative task; suitable hardware needs to be identified. Nonetheless, I believe it imperative to keep the horse prominently in front of the cart – that is, a top-down system design.

As for the LSM’s, it is my opinion that this is no great loss. One of the most frequently cited advantages of these devices is that they provide an inherent control and eliminate the need for any friction-related equipment – electro-magnetic fields provide all the needed forces. Unfortunately, this is not completely true. One assumes that, whatever the means of propulsion, there will remain a requirement for emergency braking. While true that appropriately phasing an LSM can initiate braking action, as soon as any appreciable change in velocity is effected, the synchronism is lost, and concomitantly, so is the braking action. In addition, if power is lost, even momentarily, the synchronous control action is also lost. Thus some form of auxiliary braking action, position control, and means to start-up and re-establish synchronism are required. These capabilities are not inherent in constant-frequency LSM’s.

Moreover, while I have yet to see an objective cost comparison of LSM’s vs. any other means of propulsion, I have little doubt it would be significantly more expensive. (This, of course, is a view subject to challenge; it’s just that, to my knowledge, no one has done so.)

II Operational Choices

In his operational choices, Mr. Goltermann, correctly in my view, provides five reasons for choosing dynamic packeting; namely: the advantages of drafting, reduction in the number of entities to be controlled, the creation of gaps between packets to facilitate emergency braking, increased capacity, and to minimize the need for split-second merging. Any of these might be a reason to choose packeting; I believe the sum of these to be compelling.

Nonetheless, he has reservations; he suggests that minimizing waiting time might be more important. Let’s examine this. Within a given number of slots passing a given location, the probability of an available vacancy is identical whether the slots are bunched together or passing at a uniform rate. With packets, it is true that access to the system it only possible between packets. In my discussion, I posited packets passing at the rate of one every four seconds. Since the probability of a vacancy is identical, at maximum, potential users must wait an additional four seconds for entrance to the system. I do not view this as a serious infringement on flexibility.

He then turns to the manner of control. He contrasts two general approaches as "perfect pre-planned control" and "managed anarchy". I don’t quarrel with his distinction, but I do protest, again mildly, at the label he chooses for the latter - it is a bit pejorative. Nevertheless, I do believe that he accurately describes the limitations of the former method.

He suggests that some sort of combination is a practicable solution. But that is precisely what I advocated. In the system I described, entering vehicles are not allowed onto the system with no concern for whether there is a vacancy at the first merge. That is precisely the purpose of the quotas enforced on each packet by the entrance station. Moreover, having successfully transferred to a second line, the vehicle acquires a defacto priority over any subsequently entering vehicle that might also wish to transfer to the initial vehicle’s transfer to a new line. Thus, while not absolutely guaranteed, once allowed to enter the system, the probability that a vehicle will be shunted off can be made satisfactorily small.

In this connection, later in his discussion Mr. Goltermann contemplates as many as 100 merges in some statistical journey. It is not quite clear what is meant by a "merge", but if one accepts the common definition of leaving one line and joining another, or the possibility of two lines joining; I can not imagine anything like 100 in a typical (or even an exceptional) urban journey – more nearly 2 or 3 would seem more likely. For that matter, I confess to not being able to follow the statistical logic employed in the "Entry Delay and Network Utilization" section. Perhaps Mr. Goltermann will provide a more robust explanation. I understand the value of gaining or losing a slot (or possibly several), but I suggest that if one were not constrained to a specified and pre-determined number (as is required in the employment of constant-frequency LSM’s), the flexibility and thus the value of this procedure would be greatly enhanced.

We are also called upon to choose between in-vehicle control and a wayside master "brain". I believe Mr. Goltermann is absolutely correct in his concern for transmission reliability, not to mention the massive amounts of information required, in wayside control. It is essential not only from a reliability standpoint, but also with a view to expandability (scalability) that the required data that need be transmitted is kept to a minimum.

Having said this, I believe it highly unlikely that a successful control system can be wholly one or the other. The question then is where one places the emphasis. I come down on the side of placing as much intelligence in the vehicle as is practicable and safe. Space does not permit an exhaustive discussion of control philosophy in a short note, but one illustration may help provide justification for this view.

The principle and most important task of any control system is to prevent vehicles from colliding with one another. With central control, this requires knowing the location and velocity of every vehicle under its purview, calculating a future location, integrating this into a movement plan for the entire fleet, and then issuing and insuring compliance with whatever orders are provided to each vehicle.

In an in-vehicle system, to accomplish the same task it is only required to know the relative position and relative velocity of the vehicle that is, or is about to be, in front. This information can be easily and continuously acquired with some form of pulse-doppler device.

The appropriate calculations are easily done (requiring only minimal computing power, far less than found in a modern personal computer). The means to respond to control data would be essentially the same whether it originated in a central computer or locally,

Moreover, in coupled-packet operation, it is only the packet leader who requires this information (although all vehicles would be identically equipped) as the packet leader controls the entire packet in the same way the leading vehicle on a subway train control the entire train. The packet leader must also know its own position at all times in order to maintain a precise schedule. But here again is an advantage of packet operation, the precision of position is considerably relaxed. As the headway between packet might be in the order of 150 feet, an error of a few feet would not endanger the operation. Obviously the packet members have no fear of collision with one another as they are coupled together and operate as a unit.

Thus, in normal operation, it is only when vehicles are operating more or less individually such as appending to the packet, transferring between lines, and approaching the off-line exit station that these data are required. That is not to say they are unimportant, they are vital, and as Mr. Goltermann suggest some redundancy may be required.. These data are, however, acquired significantly more easily from onboard sensors. Accordingly, in abnormal operation requiring some emergency action, the appropriate information is acquired far more readily (more or less continuously) and thus, more likely than not, tend to minimize or prevent serious consequence.

Moreover, aside from appending to a packet, the need for this information is principally in off-line operations where a mishap is unlikely to affect any but local operations. In appending, the ability to achieve speeds significantly greater than system speed can (and should) be severely restricted. Thus a collision during this operation should not occasion significant disruption of service. Accordingly, I think Mr. Goltermann somewhat overstates the difficulty (and the consequence of failure) of on-board control.

III Brick Wall Criterion

As to the "brick-wall criterion", I believe Mr. Goltermann is quite right in suggesting that this may need reviewing. Certainly it can not be taken literally.

This, no doubt, should be the subject of another discussion. I can only add that aside from the additional space between packets mentioned earlier, another advantage is achieved with coupled packets. Assuming a sufficiently robust vehicle, if a packet is involved in a collision of some sort, the entire momentum of the several vehicles in the packet is brought to bear, thus rendering it much more likely to prevail.

IV Acknowledgement

In closing, I wish to thank Mr. Goltermann for accepting the invitation to discuss operation and control, I am confident it served and continues to serve a useful purpose. I would hope, also, that others might join-in.