In-Vehicle Physical Infrastructure

Vehicle Equipment

The vehicle is the source and destination of most operational data in the system. It contains all sensor inputs and reacts to various event-based tasks determined by location or dispatch control.
The software that runs on the In-Vehicle logic Unit (IVU) controls all the vehicle interfaces and messaging related to the CAD/AVL system.

The MDT provides the display where the operator can control brightness, contrast, and the viewing angle to ensure optimal viewing in all lighting conditions. Color contrasting, shadowing, and text provide accessibility for the color blind. Audible clicks are provided from the MDT to indicate button depression.

Each type of message sent between the CAD/AVL and IVU has a configurable “time to live” duration (TTL) associated with it, and the system will periodically attempt to re-send a given message, until receipt is acknowledged, for the TTL duration.

Figure below provides a component diagram with vehicle connections.

There are important general concepts to understand related to the in-vehicle equipment.

• The system requires both power and ignition sense to start up. If either is disrupted, the system will fail to power up.
• The Communications Control Module (CCM) provides a key part of power management. The hardware contains a “watchdog” feature. This feature uses a “heartbeat” signal that multiple components on the IVU produce and send to the CCM. If any of these signals are missing, the CCM shuts down power to force BOTH the IVU and the MDT to reboot. Consequently, if you have an MDT that constantly reboots, it likely indicates an IVU issue rather than one with the MDT. Consequently, Avail includes the CCM in all installations.
  • The CCM also handles all Avail system interactions with the radio systems and handles optional VoIP communications.

How Vehicles Communicate on the Road

All vehicles communicate in real-time to the backend server equipment. Regardless of the method of communications, the system transfers the same data from the vehicles to the backend servers. In-vehicle actions initiate the communications process. There are two modules on the backend that are responsible for managing communications. They are the WiNG, and the “COMMS” server.

For a description of the COMMS server, see “Comms” Service, an Avail Developed MS Service.

For a description of the WiNG, see DDS WiNG, a Third-Party Product.

Specific actions prompt the vehicle to report its Global Positioning System (GPS) location along with other information to the back-end system. The following are the most common actions that cause these reports:

• Vehicle ignition changes state (on to off or off to on).
• The operator logs on to a specific run or block.
• A specified amount of time has elapsed since the last communication.
• The vehicle has traveled a specified distance since the last communication.
• The vehicle has exited a trigger box for a stop.
• The operator sends a message to Dispatch.
• The operator puts the vehicle in “Manual Mode,” “Out of Service,” or “Driver Off” state.
• The operator logs off.

GPS uses satellite communication to determine location. Vehicles can lose contact with these satellites in areas where objects block the sky, such as in garages. When vehicles lose contact with GPS satellites, the system reports the last known location of the vehicle until the vehicle sends an updated location.

Disruptions between the Vehicles and Comms Server Communications

Vehicles must be connected to the “COMMS” server when operators log on and log off. If connectivity is lost after an operator logs on, the system notifies a dispatcher of the vehicle’s status change while an icon change on the MDT notifies the operator.

Despite the loss of communication, vehicles continue most normal operations. Fixed route vehicles continue to update the farebox, destination sign and make ADA announcements. The system collects schedule adherence data and passenger counts. Vehicles store these data until the connectivity is restored. Paratransit vehicles continue to provide driving directions and display manifest data that are on the vehicle. The number of paratransit manifest pick-ups and drop-offs on the vehicle is configured as requested and is downloaded to the vehicle at log on. Vehicle communications is required to receive manifest updates.

Cellular Data Plans

myAvail supports using a cellular data plan from all major providers (e.g. Verizon, AT&T) for data communications. The cellular data plan can be set up in one of two ways:

• Cellular data as a direct Internet Protocol connection between the vehicle and the “COMMS” server. There is no interaction with the operator’s voice communications.
• Cellular data with voice over Internet Protocol (VoIP) that blends vehicle data communications with operator voice communications over the same cellular internet connection. However, voice communication is independent of the rest of the myAvail system.

How Vehicles Communicate on a WLAN

myAvail can communicate wirelessly with all vehicles. Each vehicle includes a Mobile Gateway Router (MGR) that can handle wireless communications for multiple devices in the vehicle, such as the In-Vehicle-logic Unit (IVU) devices and the DVR if compatible. This arrangement allows for wireless transfer of information between the backend system and the vehicles.

Information that you can schedule to transfer using the Vehicles Files tab in myAvail includes software updates, route/trip/timepoint data downloads, announcement downloads, and debug reporting uploads. The Bulk Download Server is located within the myAvail system and automatically processes these downloads. When a vehicle enters the coverage area of a myAvail wireless access point, it establishes a Wi-Fi network connection and alerts the Bulk Download Server. If information is scheduled for upload or download with the connected vehicle, the transfer happens automatically.

If an administrator publishes schedule changes but a vehicle has not downloaded these changes, the system uses the real-time cellular data channel to send schedule changes when an operator logs in to a block.