Program Development

Previous page: How weaving nodes handle traffic To Main Page To Header Page for this section Index of terms used on this site Next page: Safe berthings at stops
Logic is a systematic method which enables you to, in a convincing way, arrive at the wrong conclusion.

FlyWay is SwedeTrack System´s own solution to the urban public transportation problem

Anfang he FLYWAY® system is meant to be wholly automatic, but there is always the possibility for the supervising personnel and (under certain conditions) the travelers to take charge of individual vehicles whenever necessary. Automation implies a high degree of computer control. The programs themselves, as well as the information exchanges between computerized units are very complex, and difficult to make bugfree. This means that a lot of safety precautions also have to be included in the system.

This is a very technical page, meant to be read by technicians and programmers. Many specifications are as of this writing not finalized yet, so this description will likely undergo some changes.

Contents of this page:

  1. Distributed Programming
  2. General, concerning FLYWAY
  3. Central system control
  4. Vehicles
  5. Stations
  6. Nodes
  7. Regional supervision, guidance and service
  8. Parking areas
  9. Production facilities
  10. Installation machinery
  11. Maintenance workshops
  12. Reclamation facilities
SwedeTrack System´s chief mechanic for the construction of the FLYWAY® system

1. Distributed Programming

Figure 1:1
The programming of a system as complex as FLYWAY® relies on:
  1. Distributed program functions
  2. Standby-computers, ready to take over
  3. Backup functions in other computers in case of program or communications failures
  4. Reliable, high-capacity communications
  5. A backup communication system
  6. Reliable communication protocols
  7. Scaleability for future and continuous expansions
The description on this page takes a long view, looking 15 - 20 years into the future. Program development will, as in most cases, proceed from relatively uncomplicated but safe functions, toward more complicated, with increased functionality. The primary goal is, of course, to get a safe and functional system up and running as soon as feasible. This would:
  • enhance public acceptance of the system
  • provide experience for further development
  • generate needed income that would finance this further development
  • serve as inspiration for others.

2. General, concerning FLYWAY

On many pages on this website, we have talked about the node computers being responsible for traffic areas, as well as handling the shunting of cars. These are, of course, different tasks, and need to be sorted out properly.

FLYWAY® uses the Point-Synchronous traffic system, which could superficially be illustrated as in figure 2:1. The asynchronous traffic control is used only in more or less isolated parts of the beam network, where there are shunts, stations and the like. These areas are depicted by yellow in the figure, and beamcars enter into these areas as soon as they pass the "last" weaving nodes. While they are in these yellow areas, the beamcars control themselves, while, of course, adhering to speed limits and such other limitations that apply. They are also under some supervision from the local regional computer.

Outside of these areas, the beamcars move under synchronous control, which means that they run in individual time slots alloted to them by the upcoming node computer.

This is not as easy as it may sound, however; setting proper borders between syncronous and asyncronous areas and handling the traffic in station areas is a complex task. How FlyWay is implemented in this regard is sorted out on the page about the FLYWAY Guidance System.

Node areas can be quite complex, as shown in figure 2:2. Many shunts close together makes it necessary at times to control several shunts from one node computer. This also means that several areas under synchronous control could border each other, and beamcars would pass from one booking point to another, between shunts. Since the nodes are in charge of either controling or monitoring the cars as they move through shunts and stop at station berths, they need to control the whole area under their jurisdiction.

Figure 2:1
Figure 2:2
But beamcars need to be in constant contact with a network computer also when travelling in areas with asynchronous traffic. Thus, for every beam segment in the network, there has to be a stationary computer, responsible for this contact. Since the network would thus be divided into regions, it is logical to refer to these computers as regional computers, and that´s what we will do on this page.

3. Central System Control

Program modules are needed for:
  1. Central control and supervision of common functions
  2. Gathering traffic statistics
  3. Providing information for traffic analysis and simulations
  4. Providing traffic prognostications, based on gathered statistics
  5. Providing information for passengers
  6. Handling bookings of vehicles
  7. Administration of personel
  8. Other tasks.

4. Vehicles

Program modules are needed for:
  1. Communication with nodes, for traffic regulation purposes, using the Bluetooth protocol and/or surface wave antennas to/from beam-mounted waveguides. A mode would be kept in reserve for data communications in an emergency situation, using Fast GSM to/from the vehicles.

  2. Navigation through the network, using on-board or node-provided routing tables.

  3. Maintaining proper speed, distance to other vehicles and ascertain vehicle position in the network.

  4. Continuous reporting of position, absolute and relative speed to the node computer.

  5. Providing general and individual information to travelers.

  6. Registration of identities of passengers.
  1. Registration of passenger identity in each seat, providing individual service by loudspeaker and monitor images. This identity is temporarily stored in the vehicle, and serves also to forestall violence and sabotage activities, and facilitates the return of forgotten items in the car. Vehicles for transportation of goods would (lika ordinary passenger cabins) use readers for handling av smart cards, capable of identifying the transporter, departure & destination points, type of goods, etc.

  2. Equipment monitoring and control, with the task of checking and controling on-board equipment, and report malfunctions and take appropriate actions. The equipment needing such control would include doors, elevator, swivel direction, locks, weight of load, distribution of load, shunting wheels, the climate in passenger cabins, temperature and vibrations in motors and bearings, state of charging of batteries etc.

  3. Functional monitoring, for the purpose of booking time at maintenance workshops whenever needed, informing the node, taking travelers to nearest stop if the situation is acute, and keeping passengers informed. Also activating surveillance cameras, if motivated.

  4. Handling of emergency situations from outside the vehicle, such as pushing a faulty vehicle up ahead to a suitable place (as directed by the node), engaging and running on batteries when power fails, automatic or manual handling of the elevator and doors to enabling passengers to get off, etc.

5. Stations

Program modules are needed for:
  1. Keeping track of how berths are being used and which vehicles land where at what time. Keeping passengers informed of such movements by way of monitors.
  1. Enabling passengers to book vehicles, using a suitable passenger interface.

  2. Reporting the local traffic situation to nearby nodes, and forwarding requests for vehicles.

6. Nodes

Program modules are needed for:
  1. Regulation of traffic flow through all shunts (i.e. divergence nodes and weaving nodes), with the primary task of supervising the flow of vehicles to the rear of weaving nodes, in regard to distances and speed as vehicles approach a weaving point, and either supervise or monitor a correct choice of beam at a divergence node. It should be noted that vehicle length can vary, and that permitted speed can vary along the path, leading to vehicles occasionally getting closer to, or further away from, each other.
  1. Handling this function for a neighboring node as well, should this node computer or its communications fail. This means that every node computer also has all relevant parameters for all its topologial neighbor nodes.

  2. Continous communication with all beam vehicles within the node´s area of responsibility. These functions should also be possible to handle temporarily for a neighboring node, should that node´s computer fail in one way or another.

  3. Regulation of the traffic load within its area of responsibility, using the OSPF-protocol.

7. Regional Supervision, Guidance and Service

Program modules are needed for:
  1. Supervision of power supply and communications flow. Connecting emergency power if needed.
  2. Monitoring of every vehicle in the area.
  1. Monitoring of the beam network within the area, and re-routes vehicles when disturbances occur.
  2. Passenger servicing; providing an interface for live human personal to answer questions and handling awkward traffic situations.

8. Parking Areas

Program modules are needed for:
  1. Keeping an inventory of all vehicles in place, and their scheduled comings and goings.
  1. Keeping surveillance, with the aid of cameras and sensors.

  2. Order blocking vehicles to move, so that certain desired vehicles can be accessed.

9. Production Facilities

Program modules are needed for:
  1. Materiel flow processes, with the task of supervising all flows of raw materials and components to production facilities, and all flows of manufactured system parts.
  1. Registration of all requisitions for system parts, and orders the raw material and och components required.
  2. Administration of invoices, inventory of parts and payments of bills.
  3. Manufacturing supervision, which includes supervision of robots for manufacturing and assembly.

10. Installation Machinery

Program modules are needed for:
  1. Running automatic machinery with the task of providing optimal service to the operators in all kinds of work with the beam network, such as building, altering or disassembling. The equipment would be needed for work on beams indoors, in tunnels, on bridges, attached to buildings and on pole supports. This equipment would also be needed for work at stations and depots, manufacturing plants, maintenance workshops and at reclamation facilities.

    In difficult terrain, it should be possible to erect pole-supported beams more or less automatically from previous pole, without the need for access roads, as shown to the right.

11. Maintenance Workshops

Program modules are needed for:
  1. Processing orders for maintenance work in vehicles, issued by the vehicles themselves. Processing orders for maintenance work from stations and vehicle parking areas.
  1. Fetching required replament parts from automatically run warehouses, Controlling robots for dismantling and assembly. Ordering and loading of vehicles for transport of required parts to and from workshops, warehouses and places on the network where maintenance, extension or dismantling work is being done.

12. Reclamation Facilities

Program modules are needed for:
    To top of Page
  1. Reclamation processing, or the recycling of spent equipment, with the task of receiving discarded or surplus system parts from maintenance workshops. These items will be taken apart, and the parts could then either be re-used or the material reclaimed for other uses. Sorting, storage and transportation of rest products.

Copyright © 2004, SwedeTrack System.
Last Updated: 2007-01-17
Webmaster
This site is maintained by Johnson Consulting