Case Study: Location-Aware Public Transit Drives Custom I/O Controller Card Development



Challenges included J1708 serial protocol, multi-vendor subsystems, balancing current and future requirements.

The modern public transport bus is more than what you might remember. There’s still a driver, money box, seats and a couple of doors. But there are also digital signs on the outside that change depending upon the daily route, electronic audible location annunciators calling out the stops, digital passive passenger counters, and security systems designed to protect passengers and the driver.

Plus, in an ever-connected and cloud-based M2M world, the modern location-aware bus interacts with passengers using GPS input and reports telemetry and data stats back to a computer-aided bus dispatch or depot location. This electronic wizardry requires multiple subsystems and vendors, several RF connection pipes (including analog voice), and myriad software and protocols—all interconnected on industrial vehicle LANs such as CAN 2.0b running J1939 and the mature serial 2-wire SAE J1708 standard.

In this article we’ll describe the technical rationale for how intelligent transportation systems (ITS) integrator Avail Technologies spec’d out two unique I/O cards from rugged supplier Connect Tech.

Sub-System Architecture
One card (PCI Card) uses a PCI bus to plug onto a rugged but standard fanless PC located in the in-vehicle unit (IVU). The I/O and protocols on the card are anything but standard. The other card (RCU Card), located in the aptly named radio controller unit box, has more specialized digital I/O but interfaces with analog radio and PA equipment. At their simplest, both Connect Tech cards have to deal with inherently “dirty” vehicle power and industrial temperatures, plus the non-trivial nuances of already-deployed legacy hardware and software such as the J1708 vehicle network.

fig_1
Figure 1: The modern public transit bus is loaded with interconnected, intelligent subsystems. The black line represents the SAE J1708 2-wire electrical bus, or the updated CAN 2.0b network running J1939 protocols. (Courtesy: Avail Technologies.)

As shown in Figure 1, the transport bus consists of multiple subsystems, all interconnected via backbone networks joined by the serial J1708 and/or CAN 2.0b with J1939 protocol. The vehicle contains two separate J1708 networks: one for the drive train functions (engine, transmission, etc.) and one for the ITS subsystems shown here. From the upper left of the diagram in Figure 1 and moving counter-clockwise:

Automated Next Stop Annunciation: GPS-based location input triggers audible announcements for next stop and other announcements such as sporting events, festivals or public safety. The on-board internal signage is changed to reflect location.

GPS-Triggered Headsign Change: Front-of-bus signage (and other exterior signs) change to reflect bus route. Detours and route changes are automatically reflected based upon GPS input but under computerized dispatch control. Special event information can be remotely transmitted and updated.

Security Camera System: Standalone system locally records and may transmit audio/video, depending upon RF WAN such as cellular or access to Wi-Fi hotspots at fuel depot or other location.

ControlPoint Automatic Passenger Counter (APC): Collects and broadcasts real-time statistics about passengers boarding/leaving the bus in compliance with local transit authority and Federal Transit Administration regulations.

Single Point of Login: This sub-system eases the driver’s login workload by avoiding having to log into each sub-system individually. Upon start of day, driver enters employee and route information into the onboard mobile data computer (MDC), which authenticates all systems resident on the J1708 and/or CAN network(s). Information in regards to the driver’s daily work assignment, vehicle location and passenger load is also relayed to operations personnel.

Vector 9000: Installed near the driver to provide HMI GUI for control and monitoring of all onboard systems. Includes cellular communications for WAN dispatch and emergency data transmission, this is also where the driver logs onto the systems through interface to the single-point-of-login subsystem using a single workload ID. All the subsystems configure and sync up to the bus’s route remotely via the driver’s action.

Inputs/Vehicle Health: Discrete inputs from various on-board sensors or mechanical attributes, analog and digital inputs, and voltages mux together onto the J1708 and/or J1939 CAN. These inputs directly feed the IVU. Drive train information from engine controller, transmission, automatic brakes and so on is available via CAN/J1939 to the PCI Card on the IVU. Discrete inputs such as vehicle doors status, wheelchair lift/deploy, stop request, lift request are fed to the IVU via the integrated digital I/O (DIO) module. Vehicle voltages, battery back-up and ignition status are monitored and reported from the RCU.

In Vehicle Unit (IVU): This is the main controller for the Vector 9000 driver HMI. The Connect Tech PCI Card resides here, installed into a rugged, fanless PC motherboard running Windows Embedded Standard 7. The IVU interfaces with all onboard systems at least via serial J1708 LAN for status and/or health monitoring. Wi-Fi bulk connectivity added to motherboard for video, location and other large data transfers.

Communications and Radio Controller Unit: Two-way radios, audio files and bulk communications are transmitted wirelessly to the vehicle. RCU box is mounted near the driver and contains Connect Tech RCU Card with interfaces to multiple onboard digital and analog sensors, audio switching for radio channels and PA input/output, and other I/O such as ignition, odometer, and more. RCU also handles graceful bring-up/shut down of several real-time embedded onboard systems.

IVU Dissected: PCI Card
The IVU is the primary controller responsible for overseeing all of the ITS subsystems on the vehicle and also needs to accept chassis I/O inputs from the drive train engine control unit (ECU), transmission, automatic brakes and other body control modules.

fig_2
Figure 2: The Connect Tech-designed “PCI Card” provides J1708 and CAN J1939 interfaces, along with three (3) Multi-Tech module sites for future expansion I/O such as Wi-Fi, cellular, Bluetooth, and so on.

The central hub to all the interfaced systems, the IVU houses an industrial, fanless Intel Atom-based PC motherboard with two PCI slots that is capable of operation from -30°C to +80°C. One slot currently houses the vehicle’s bulk data wireless LAN; the other slot is for the PCI Card we’ll describe in a moment. The IVU runs a componentized Windows Embedded Standard 7 with drivers to common UART interfaces, plus a storage function is handled by a flash-based solid-state drive (SSD) for event recording. The IVU monitors chassis voltages such as the ignition position, battery, and brake lights. As well, the IVU is cognizant of the bus’s door position(s), wheel chair lift, and other onboard electro-mechanical functions. The IVU tracks these inputs, plus J1708 LAN messages and wirelessly sends an alert to the computer-aided dispatch (CAD) should levels fall outside certain thresholds. Needless to say, the combination of native sensor voltages, custom I/O, serial J1708, plus CAN 2.0b J1939 protocols made designing the IVU hardware and software challenging.

Connect Tech was chosen by Avail partly because no off-the-shelf PCI card had the requisite I/O functions. In addition to the existing subsystem interfaces described above, Avail is planning for future ITS systems with interfaces such as wireless LAN, Bluetooth or cellular. So the PCI Card also needed to allow for features expansion via three Multi-Tech module sites (Figure 2).

Figure 3 shows the block diagram of the PCI Card. The serial module I/O connector blocks are the Multi-Tech sites: one CAN controller node is for the current implementation during the market’s transition from serial J1708 to CAN J1939, while the other two CAN ports are for future system upgrades.

fig_3
Figure 3: PCI Card block diagram. Note the PCI interface implemented in an FPGA, where J1708 and J1939 protocols are handled as well. The CAN controllers are based upon a Microchip PIC32.

An Actel ProASIC3 FPGA acts as glue logic, computation and protocol implementation. It was used primarily because there are no off-the-shelf J1708 controllers on the market (only PHY transceivers). More importantly, J1708 bus timing is difficult to get right so Connect Tech had to create FPGA IP to accurately deal with the protocol and bus timing.

The FPGA also implements PCI 2.2 and the J1939 protocol, realized via off-the-shelf CAN 2.0b controllers resident in a Microchip PIC32. The PCI Card mechanically is a standard 4.2 x 6.6 inch size, and uses industrial temperature components that exceed Avail’s operating range (refer back to Figure 2). The J1708 and J1939 interfaces use a shared Micro-D connector, while the other Micro-D houses the remaining two CAN interfaces mounted on a custom front panel/bracket designed for IVU box mounting.

Because of these unique vehicle interfaces, Connect Tech was required to write all the firmware and create Windows drivers for the PCI Card. The board can be programmed, debugged and tested via JTAG running across the edge connector.

We mentioned above how vehicle power is inherently dirty in a truly harsh multi-season environment. This is due to alternator voltage variations, reduced battery output at low temperatures, unpredictable electrical loads, and the occasional abrupt ignition off/on cycle. Connect Tech designed all the I/O to be galvanically isolated from DC and/or ground loops, and floating grounds. The J1939/CAN and J1708 interfaces are galvanically isolated on the PCI Card; low speed and higher voltage I/O signals use phototransistor optocouplers.
Additionally, Multi-Tech modules—although not today installed—can draw up to 1.75V (peak) from a 5V supply. Accommodating nearly 30W in future expansion, plus existing component current draw, lead Connect Tech to design for a variety of card input voltages: 3.3/5/12VDC. For 12VDC input, an HDD-style power connector was considered.

fig_4
Figure 4: Radio Controller Unit Card block diagram.

The IVU also contains an integrated design that delivers isolated digital I/O channels that assist with health monitoring. 16 channels of isolated input and 16 channels of isolated output are included in this DIO function whose interface is provided by a 68-pin connector.

Radio Controller Unit; RCU Card
The Radio Control Unit houses the card of the same name and is a separate box from the IVU to allow flexible vehicle mounting locations. In one of Avail’s customer installations, the RCU is located in the Radio Equipment Box behind the driver, but it could just as well be mounted under the dashboard near the driver’s two-way radio. Since transit authorities often use different model year busses or even different bus manufacturers, the standalone RCU can be installed wherever it fits best with access to bus signals.

Primarily the RCU card provides the interface to all of the bus’s radios: voice, low-rate data and bulk data. It provides channel steering which provides input to radio(s) to change the channels; automatic gain control for microphone audio input conditioning; digital potentiometers for additional audio conditioning, and switching relays to change audio source or destination (for example: the driver using the mic for onboard PA to passengers versus talking to dispatch).

But for flexibility to install the RCU in as many future vehicles as possible, the RCU also functions as an I/O hub (Figure 4). Avail Technologies wanted Connect Tech to maximize the RCU Card’s I/O handling to standard and proprietary transit industry interfaces, so the RCU also accepts A/D inputs, CAN, I2C, SPI, RS-232, RS-485, GPIO and more. Not all of these are implemented in the diagram shown in Figure 1 and go unused for now.

fig_5
Figure 5: RCU Card. Note the PIC32 with myriad I/O, and the three DPDT relays for audio switch control.

Most of these signals are realized and controlled via a Microchip PIC32 to assist with smart control capabilities. Like the PCI Card, signals are optoisolated to control against power anomalies. As well, the RCU participates in the vehicle health monitoring shown in Figure 1 and can either switch to a battery back-up, or alert the digital IVU and Vector 9000 Mobile Data Computer to perform graceful OS and processor shutdown if needed to avoid over/under-voltage damage.

For its part, Connect Tech designed the card to meet all of these requirements (Figure 5). CAN and UART controllers are in the PIC32 and control a single CAN 2.0b with J1939 protocol that is also optoisolated. There are two RS-232 interfaces. Changes can easily be made to accommodate RS-422 or RS-485 for alternate vehicle installations. There are 36 GPIO lines (some optoisolated), and six 10-bit A/D channels.

The RCU uses three DPDT relays to handle the analog audio switching described above. There are also analog gain circuits for audio signal conditioning. To make the RCU box as easily installed as possible, the RCU Card requires only a single 12VDC input (nominal), though it can function from a droopy 10.6V to a max of 16V. Connect Tech designed the RCU with DC/DC converters to provide all onboard lower digital voltages.

Intelligent Transportation, Realized
What’s most striking about the two custom cards designed for Avail Technologies’ ITS systems is not the sexiness of the technologies used; rather, the cards implement mature and unexciting I/O like RS-232, CAN, SPI and GPIO. But the design elegance is making these cards work with myriad real-world transit vehicle interfaces. Creating FPGA IP that implements the difficult SAE J1708 protocol and bus timing was non-trivial, as was coding the PIC32 to talk CAN’s J1939. Galvanically isolating many of the signals to protect the boards (and their higher order box-level systems) demonstrates practical knowledge of functioning, legacy systems.

Of course, as public transit buses further evolve with future location-based services, onboard contextual advertising, rider app integration and whatever other technology might become available next year, Avail Technologies’ systems are already capable of future upgrades. This is partly due to the thoughtful expansion capabilities built onto the Connect Tech PCI and RCU Cards.


bown_billBill Brown is the Lead Project Engineer on the Avail Next Generation In-Vehicle system. He received a Bachelor of Science in Electrical Engineering from the University of Akron. Mr. Bown has more than 20 years of hardware engineering experience and continues to focus his attentions on Avail’s next generation of in-vehicle solutions.

dietrich_patrickPatrick Dietrich is the embedded R&D lead at Connect Tech. He received a bachelor of science in Engineering from the University of Guelph in Canada, is an IEEE member, a licensed Professional Engineer, and an active member in
various embedded consortia technical committees.

Share and Enjoy:
  • Digg
  • Sphinn
  • del.icio.us
  • Facebook
  • Mixx
  • Google

Tags: