IoT Welcomes Existing Products

With proper care and connections, existing devices can be integrated into the Internet of Things without the expense of acquiring expensive new systems. The example of retrofitting buses into a transportation systems serves to illustrate what is possible at reasonable cost.

 

by Gil Ben-Dov and Richard Jahnke, Total Phase 

A new motorized vehicle today, whether a car, bus, truck, or heavy duty vehicle, is a “connected vehicle”.  While the decision to purchase is a complex algorithm specific to your company, the purchase choice will be designed for the “Internet of Things” (IoT), therefore interoperability, connectivity and reliability are given.  That doesn’t mean your existing fleet needs to be left behind.

There is an additional level of complexity when your fleet contains assets that are still productive, reliable, not fully depreciated or near end-of-life.  It’s not generally fiscally prudent to retire those assets or take large write-downs as you replace your fleet to modernize, but waiting until assets come off the balance sheet for a gradual replacement can result in an excessively long time to receive full project benefits. This type of project is not linear, e.g. a 50% IoT enabled fleet yields less than 50% of the total benefit; therefore, fast project completion is essential to your business.

A solution that enables a retrofit your fleet with IoT capabilities offers advantages versus a partial or complete evolution of your fleet:

  • Lowest investment
  • Fastest time to project completion
  • Simpler transition to fully IOT enabled
  • Supports a multi-vendor fleet approach
  • Better ROI

 

We recently outfitted a city bus to report location and engine parameters to a central system.  The incremental cost to outfit an existing bus was more than offset by the savings in maintenance and increase in reliability.

Many, if not most electronically controlled systems rely on sensors and actuators to perform their required function. In all instances within a system, signals and data travel over a protocol either serially such as USB, I2C, CAN, RS232/485 or in a parallel manner for simple on/off sensors or actuators. Having the ability to “sniff” and capture any or all of these data streams and reprocess the data via an Internet-connected device adds new life and value to existing infrastructures (Figure 1).

 

RTC12 TSTW TotalPhase Fig1

 

Figure 1: Interconnectivity can be more than a vehicle

Today we’re all familiar with a range of connected devices, from a simple garage door opener or programmable thermostat to the Google Driverless Car or military drone. What all these applications have in common now is a dependence on human interaction or very careful preprogramming. There simply are not enough connected sensors, communicating in a common language, for these devices to be truly autonomous today but step by technological step and week by week we see the gaps being filled.

Because the “things” will all be communicating over the Internet, a review of how the Internet operates will aid in understanding the current limitations in terms of real-time operation for an IoT.  The Open Systems Interconnection (OSI) standard commonly referred to as TCP/IP is the multi-layer model used by the Internet. While each layer supports different protocols only the most commonly used ones are referenced. At the lowest level is the link layer. This is where protocols for Ethernet, Wi-Fi and PPP(modems) exist . Next is the transport layer where IP address (IPV4, IPV6, etc.) decoding takes place. Next up is the transport layer, typically TCP where packets are sent, received, error checked and retransmitted if required. TCP is also in charge of specifying the size, direction, rate and traffic congestion control aspects. There is ongoing discussion as to whether UDP, where packet receipt confirmation is not embedded, would be faster than TCP in an IoT application but TCP has a higher level of security and reliability and if only a small amount of data is required and packet confirmation is written into the data exchange then UDP may actually be slower. The top layer is the application layer where HTTP among other protocols resides and through which multiple packets may be exchanged between client and server as described by the preceding layers.  This entire suite of protocol exchange software is known as the network stack.

For any device to be networkable it requires hardware (PHY layer) running an OS that implements a network stack with associated connection hardware and an IP address. A network stack is available on all modern OS versions (Linux, Android, Win, Mac). The IP address is more problematic because even with IPV6 capability it can change on every boot or reconnect cycle. Fixed IP addresses have some cost associated so efficient reuse of addresses via DHCP will continue for some time. Therefore we need to make a distinction between a network enabled device (containing only the network stack with associated PHY layer and a variable IP address) and a network aware device.

Network awareness requires at a minimum that a device register its current IP address with a “home” database located at a fixed IP address or more efficiently to pass along a unique identifier of itself on every network transaction so that other devices on the network can always access it.  Network awareness can be further expanded to include context awareness where not only the IP address but also the capabilities of each device are recorded such that multiple devices will know and can share the capabilities of all devices on the network. In an IoT environment the “thing” may have to perform the functions of both client, to receive and act on commands or as a server to upload captured data for historical or analytical purpose as well as for device-to-device command and control.

 

A Real-World Example

Now let’s review a real world example of a mobile IoT network and the engineering process that brought it to life in 2012. The client was a public transport department in a large city. They requested a comparison between their existing proprietary RF-enabled vehicle-monitoring system and an Internet-enabled system.  The test vehicle came straight from the fleet and only 1 day with the bus and senior engineer was allowed to determine its systems and connections. Discovered was an On-Board-Diagnostic (OBD) system running CAN/J1939 that provided engine, transmission and chassis data in standard values, a passenger counting system that provided a door number and quantities of boarding and alighting passengers as an RS485 data stream 100ms after a door closure and a suitable power connection. Other systems that could have been interfaced but were not required for the evaluation included digital signage via RS232, a 6-camera video recorder, a fare box with RS232 output, on-board video providing bus location and local advertizing to passengers, a control and monitoring system for vehicle lights and doors, and of course the desktop sized custom unit with radio interfaces to be compared against.

The prototype platform selected was a BeagleBoard XM. It’s a low cost, open source SBC sporting a 1GHz ARM Cortex-A8 with 4 USB and 1 RS232 ports in conjunction with the standard Linux kernel and Angstrom OS download for the board. Borrowed cell phones enabled by Verizon, ATT and T-Mobile and driving around the city while observing signal strength pointed to Verizon and a modem selection. Janus Communications supplies a range of FCC-approved modems for a range of carriers from GPRS through 4G. A 3G model with built-in GPS was selected. The CAN interface was the most difficult to source. There was neither the time nor budget to write a CAN software stack and off the shelf sources were expensive and unavailable for the ARM architecture.

However, Total Phase offers a range of serial (CAN, USB, I2C etc.) bus analysis tools in compact low cost packages. These products can both read and/or write data on a serial bus and are supported by full GUI-based software as well as C++ library binaries. When first implemented the supplied binaries were found to be compiled for X86. A call to customer service resolved the issue. They supplied a BeagleBoard with a GCC tool-chain and recompiled their library natively on the platform of choice and provided a download the next day.  A DC-DC converter from RECOM Power and a small LiPo battery with charger circuit (MCP73213) supply the juice for running and a final data upload after the main power is switched off. An RS485 to USB converter from FTDI supported the passenger counter. The individual hardware elements were mounted on a perf-board and packaged in an 8x10x2 inch industrial enclosure.

Now what about the network awareness mentioned previously? This is where Galixsys Networks comes in. They provide a platform-agnostic software framework with built-in network awareness for up to 4 billion devices. Each device is uniquely tracked on every network transaction. Commands and data are exchanged through service calls using a binary-over-HTTP method via standard CGI-BIN. Predefined services include send-file, get-file, ping-server and direct up/down loads to a database. User defined services pass a unique value that will trigger any imaginable code to run.  Voila, a turnkey IoT network is available in a commercial package.

The controlling software is reasonably straightforward. At the system level udev rules insure consistent boot enumeration of USB and serial port usage. Modem connection and receipt of an IP address from the carrier are accomplished through a Point-to-Point (PPP) options file and a chat script. Other methods for Ethernet, Wi-Fi or Bluetooth are well documented in books, on the Internet or by device manufacturers. Simple C code loops, running as background threads, gather the CAN, GPS and passenger count data and maintain the current data in shared memory files. Then everything is wrapped in about 700 lines of shell script that launch the processes, insure everything is running correctly and upload a data packet every 6 seconds. This shell script launches automatically after boot-up. In a mobile cell connected scenario the rate and type of data uploaded is a balance between the essential needs of the system and the cost of data charged by the provider.

Now where did the data packet go and how was it presented? A server leased from SingleHop with open source MySQL database, OpenLayers mapping, Dygraph charting, a Galixsys binary and a DNS name from Go-Daddy filled the bill. A single Galixsys system call uploaded the packet and stored it in associated fields of the database. HTML code allowed specific users to login with a password and select a bus to view. Then they selected real-time or historical pages of location mapping, speed over ground, passenger count or engine health data. Over/under limits were selected for each dataset and an SMS message could be sent if values were exceeded. An automatic software update feature was added and after a week of field trials the system was delivered and installed on the bus with two “Y” cables to tap into CAN and RS485 serial data and 4 discreet connections for door position and power. The bus was returned to service within a few hours (Figure 2).

 

RTC12 TSTW TotalPhase Fig2

 

Figure 2: Galixsys’ Andromeda architecture delivers IoT to existing systems

 

The real-world evaluation continued for six months while more users were added to the website interface and additional engine parameters remotely added to the monitored data. The success of the evaluation can best be summed up by a comment made by the general manager of the division. He said, “ We’ve spent 6 years and millions of dollars developing a system and you guys have made it obsolete in 4 months just to show us your technology.”  Whether you can afford to replace your entire fleet or not, consider a retrofit to deliver faster results with lower cost.

Total Phase, Sunnyvale, CA. (408) 850-6500. www.totalphase.com

Galixsys Networks, Allen, TX. (972) 800-1301. www.galixsysnetworks.com

RECOM Power, Brooklyn, NY. (718) 855-9710. www.recom-power.com

Single Hop, Chicago, IL. (312) 386-6210. www.singlehop.com