The SRI prototype system focused on improving the effectiveness of traditional enforcement activities conducted at weigh/inspection stations by moving compliance checks to the roadside. A major element of the SRI prototype is a mobile application that was developed for truck drivers. This application provides a mechanism for drivers to enter their license number, vehicle identification number (VIN), USDOT number, and license plate number, as well as a photo of their specific vehicle. The application then provides audio and visual cues notifying the driver to either pull into the weigh station for further inspection or to bypass the static scale.
The SRI prototype was field tested at two locations: in Grass Lake, Michigan from August 17-18, 2015 and in West Friendship, Maryland from August 19-21, 2015. In Michigan, tests were performed via cellular, while in Maryland tests were performed via DSRC and via cellular (the hardware in Maryland included both a DSRC-enabled onboard unit (OBU) in the vehicle and a roadside unit (RSU)).
In general, the results of the performance testing showed:
- The SRI was able to provide current information in a timely fashion, or as available from integrated data sources, to meet SRI prototype application requirements.
- The SRI satisfactorily and accurately accomplished automated weight screening and notifications.
- The SRI adequately demonstrated multiple internal and external interfaces for systems (ASPEN, SAFER, iyeCitation, truck parking information sources, and Arada) and users that are secure and compliant with regulations.
The development, deployment, and testing of the prototype SRI system provided the team with a number of challenges. In working through these challenges, key lessons learned included the following:
- Utilize the mobile application (app) software to provide the backend address for the message destination. The software written to exchange data between a mobile device and an OBU via Bluetooth was fairly rigid in its implementation and required events to occur in a defined order, which was not always consistent with real-world usage. The OBU software also relied on the RSU to provide the backend IPv6 address for the message destination, and in some cases the RSU did not release the address. In the future the mobile app software should provide the backend address.
- Have CV hardware available at the development location for testing. In the future it would be extremely beneficial to have the connected vehicle hardware at the development location. This would provide a quicker turnaround of unit and integration testing. Having to travel to a test bed, or train another person at the test bed on the application and relay errors found, took considerable time and expense.
- Select a mobile platform that widely reaches the SRI user base. For the mobile application, the team had two choices for platforms: Apple and Android. The team chose Android for SRI because it seemed to be the best choice at the time. Since the mobile application was developed, the development team observed that during visits to both weigh stations the officers were using iPhones. The SRI user base at those weigh stations were disappointed that the application would not be available for their devices. Also, the majority of Motor Carriers seemed to use iPhones. This combined with advances in Apple's ecosystem has made the team re-evaluate the choice of Android for mobile platforms for future projects. Apple has not relaxed its requirements for deployment of mobile apps to the Apple store at this writing. What it has done is introduce an app called “TestFlight” which allows for app developers to quickly invite users to test apps, bypassing the rigid Apple App Store approval process. This puts the platform on par with Android for ease of deployment during the development phase.
- Account for GPS drift and utilize GPS position fixes from multiple onsite devices when configuring a geofenced area. Not all mobile devices are equal when it comes to GPS antennae; some devices experience GPS drift when standing still or in motion. When mapping geofences for the application the research team identified a need to expand the geofence wider than initially anticipated to account for inaccurate GPS positioning. Another lesson learned from the geofence mapping is that it is important to take GPS position fixes from multiple onsite devices when selecting the latitude and longitude for each point of the geo-fence. Relying on Google Maps or Google Earth does not always line up 100 percent accurately with the actual GPS locations. Choice of a robust mobile platform can also reduce this issue.
- Do not rely on outside devices and services for timestamps. During the course of development, the research team realized that the timestamps coming from outside devices and services did not always sync up against the SRI system times, leading to inaccurate feed associations, failures in data capturing, and failures in weight reporting. These errors were alleviated by eliminating the reliance on the times provided by the outside devices and services. Had the SRI research team known that there would be so much time variation among outside devices and services, there would have been a decision not to rely on those sources for timestamps. Instead, the team would have chosen to generate system times based on when the SRI Web Services were called.
- Make the application responsive to ensure its user base is not being excluded from future products being built. The freedom to use any device to access the SRI and the information it delivers can drive the addition of other products, components, and use cases for the application. Quick access using mobile smartphones, and an even a more mobile work station for officers using tablets to relay information to other end users, is possible thanks to the implementation of responsive web design. This technology should not be an addition but a requirement for future projects.