Smart Roadside Initiative: Final Report

Smart Roadside Initiative Final Report www.its.dot.gov/index.htm Final Report — September 2015 FHWA-JPO-16-258 Produced under the under the “Technical Support and Assistance for the Federal Highway Administration’s Office of Operations” contract U.S. Department of Transportation Federal Highway Administration Research and Innovative Technologies Administration Federal Motor Carrier Safety Administration Notice This document is disseminated under the sponsorship of the Department of Transportation in the interest of information exchange. The United States Government assumes no liability for its contents or use thereof. The U.S. Government is not endorsing any manufacturers, products, or services cited herein and any trade name that may appear in the work has been included only because it is essential to the contents of the work. Note: Unless otherwise indicated, the source for all photographs and graphic images in this report is Leidos. 1. Report No. Technical Report Documentation Form FHWA-JPO-16-258 2. Government Accession No. 4. Title and Subtitle 3. Recipient’s Catalog No. 5. Report Date Smart Roadside Initiative – Final Report September 2015 6. Performing Organization Code 7. Authors 8. Performing Organization Report No. 9. Performing Organization Name and Address 10. Work Unit No. (TRAIS) Leidos: Ron Schaefer, Diane Newton, Jim Cassady, Chuckerin Black, Robert Roth, Dan Stock Leidos 11251 Roger Bacon Dr. Reston, VA 20190 0262 11. Contract or Grant No. DTFH61-12-D-00045, TO 11001 12. Sponsoring Agency Name and Address 13. Type of Report and Period Covered United States Department of Transportation Federal Highway Administration 1200 New Jersey Ave., SE Washington, DC 20590 14. Sponsoring Agency Code FHWA 15. Supplementary Notes 16. Abstract This is the Final Report for the Smart Roadside Initiative (SRI) prototype system deployment project. The SRI prototype was implemented at weigh stations in Grass Lake, Michigan and West Friendship, Maryland. The prototype was developed to integrate with existing technologies already available at the weigh stations to provide one common system user interface for law enforcement officers to use. The Final Report summarizes what was deployed at each weigh station, in the commercial vehicle via a smartphone, and the ability to view the SRI user interface at any location using a smartphone. The report provides the results of the unit and acceptance testing and the lessons learned for future deployments. 17. Key Words Smart Roadside Initiative, Concept of Operations, ConOps, System Design, Truck Smart Parking System, System Requirements 19. Security Classify. (of this report) Unclassified 18. Distribution Statement No restrictions 20. Security Classify. (of this page) Unclassified 21. No of Pages 83 22. Price N/A TABLE OF CONTENTS Chapter 1. Introduction ..................................................................................................... 1 Chapter 2. Project Background ....................................................................................... 4 Chapter 3. SRI Prototype Description and Development Summary ........................... 6 USER NEEDS ......................................................................................................................................... 6 SRI PROTOTYPE DESCRIPTION AND COMPONENTS ................................................................................ 7 DESIGN RATIONALE................................................................................................................................ 9 SRI PROTOTYPE CAPABILITIES .............................................................................................................12 New Capabilities ......................................................................................................................... 12 Enhanced Capabilities ................................................................................................................ 12 AS-BUILT SRI PROTOTYPE DESIGN ......................................................................................................13 Service-Oriented Architecture ....................................................................................................13 Core Functionality ....................................................................................................................... 13 Data Exchanges ......................................................................................................................... 14 Data Management ...................................................................................................................... 14 Security .......................................................................................................................................14 SRI Mobile Website .................................................................................................................... 15 SRI Mobile Application (Mobile App).......................................................................................... 16 Chapter 4. Test Site Descriptions ..................................................................................19 EAST GRASS LAKE WEIGH STATION, MI ............................................................................................... 19 Sensors .......................................................................................................................................22 Existing Systems/Software .........................................................................................................23 Points of Integration for SRI Prototype ...................................................................................... 23 WEST FRIENDSHIP WEIGH STATION, MD .............................................................................................. 24 Sensors .......................................................................................................................................26 Existing Systems/Software .........................................................................................................26 Integration to SRI Prototype .......................................................................................................26 Chapter 5. Summary of Stakeholder Involvement ......................................................29 STAKEHOLDER INVOLVEMENT – PLANNING AND DESIGN ........................................................................29 Enforcement Community User Needs Workshop .....................................................................29 Motor Carrier User Needs and Preferences Gathering............................................................. 29 Industry ConOps Walkthrough ...................................................................................................30 Commercial Vehicle Driver Focus Group .................................................................................. 30 System Requirements Review ...................................................................................................31 System Architecture Document Review .................................................................................... 31 System Design Document Traceability Review .........................................................................32 System Design Document Walk Through ................................................................................. 32 Site Visits.....................................................................................................................................32 U.S. Department of Transportation Intelligent Transportation Systems Joint Program Office Smart Roadside Initiative – Final Report | ii Chapter 6. Prototype Test Summary .............................................................................34 TEST APPROACH..................................................................................................................................34 SUMMARY OF TEST RESULTS ...............................................................................................................36 Unit and Integration Testing........................................................................................................36 Security, Performance, and System Testing ..............................................................................37 Acceptance Testing .................................................................................................................... 39 TESTING LESSONS LEARNED................................................................................................................ 40 DSRC and Bluetooth .................................................................................................................. 40 Connected Vehicle Development............................................................................................... 41 Mobile Platform Selection...........................................................................................................41 GPS Drift and Geofencing ..........................................................................................................41 System vs. Device Data Generation .......................................................................................... 42 Large Scale JavaScript Applications.......................................................................................... 42 The Responsive Web ................................................................................................................. 43 Vendor Participation in Government Projects............................................................................43 Chapter 7. Conclusions and Recommendations ........................................................44 PROJECT CONCLUSIONS ...................................................................................................................... 44 RECOMMENDATIONS ............................................................................................................................ 44 Appendix A. Traceability Matrices .......................................................................................46 Appendix B. Testing Results................................................................................................58 U.S. Department of Transportation Intelligent Transportation Systems Joint Program Office Smart Roadside Initiative – Final Report | iii LIST OF TABLES Table 1. SRI Traceability Matrix - System Requirements (e) ..................................................49 Table 2. SRI Traceability Matrix - Application Requirements (a).............................................51 Table 3. SRI Traceability Matrix - Performance Requirements (p) .........................................54 Table 4. SRI Traceability Matrix - Security Requirements (s) .................................................56 Table 5. SRI Traceability Matrix - Interface Requirements (i) .................................................56 Table 6. Unit Testing Summary................................................................................................58 Table 7. Unit Testing Summary - Additional Maryland Elements (DSRC, LPR) .....................59 Table 8. Integration Test Summary..........................................................................................60 Table 9. Integration Test Summary - Additional Maryland Elements (DSRC, LPR) ...............61 Table 10. Michigan Performance Test Results ........................................................................62 Table 11. Michigan Security Test Results ................................................................................63 Table 12. Maryland Performance Testing Results .................................................................64 Table 13. Maryland Security Test Results ...............................................................................65 Table 14. Michigan System Testing Items ...............................................................................66 Table 15. Michigan System Test Criteria .................................................................................67 Table 16. Michigan System Test Criteria – Application Requirements (a) .............................. 68 Table 17. Michigan System Test Criteria – Interface Requirements (i)...................................69 Table 18. Maryland System Test Items ...................................................................................70 Table 19. Maryand System Test Criteria .................................................................................71 Table 20. Maryand System Test Criteria - Application Requirements (a) ............................... 72 Table 21. Maryand System Test Criteria - Interface Requirements (i) ....................................73 Table 22. Michigan Acceptance Test Items - Driver ................................................................74 Table 23. Michigan Acceptance Test Items – Enforcement Officer ........................................74 Table 24. Michigan Acceptance Test Items – Michigan Only..................................................76 Table 25. Maryland Acceptance Test Items - Driver................................................................76 Table 26. Maryland Acceptance Test Items – Enforcement Officer ........................................77 Table 27. Maryland Acceptance Test Items – Maryland Only .................................................78 U.S. Department of Transportation Intelligent Transportation Systems Joint Program Office Smart Roadside Initiative – Final Report | iv LIST OF FIGURES Figure 1. SRI High-Level Perspective Framework ...................................................................8 Figure 2. SRI High-Level Perspective Framework (Updated) .................................................. 9 Figure 3. SRI Cloud Computing (Updated) .............................................................................10 Figure 4. Interconnectivity of the SRI Information Aggregation System ................................. 11 Figure 5. Arada OBU Unit........................................................................................................14 Figure 6. SRI Website on PC/Monitor .....................................................................................15 Figure 7. SRI Mobile Website..................................................................................................16 Figure 8. SRI Mobile Application .............................................................................................17 Figure 9. SRI Mobile App Instructions and Results ................................................................18 Figure 10. RSU Antenna and Unit ...........................................................................................18 Figure 11. Michigan Grass Lake Weigh Station SRI Configuration ........................................19 Figure 12. East Grass Lake Weigh Station Communication Diagram ...................................20 Figure 13. Mettler-Toledo Ramp and Static Scale Data .........................................................21 Figure 14. SAFER Data Lookup..............................................................................................22 Figure 15. Maryland West Friendship Weigh Station SRI Prototype Configuration...............24 Figure 16. West Friendship Weigh Station Communication Diagram ....................................25 Figure 17. SRI LPR Images ....................................................................................................27 Figure 18. USDOT SRI Truck ..................................................................................................35 Figure 19. Proposed SRI Functional Architecture – DSRC Solution ......................................46 Figure 20. Proposed SRI Functional Architecture – Cellular Solution ....................................47 U.S. Department of Transportation Intelligent Transportation Systems Joint Program Office Smart Roadside Initiative – Final Report | v Acronym List API ASN CAN CDL CDLIS CMV COM ConOps CVISN CVO CVSA DashCon DB DMV DOC DOP DSRC E-Screening FHWA FMCSA FMCSR IEEE iFrame ISS ITS J2735 LEIN LPR MICJIN NLETS OBU OSADP PC RFID RSE RSU R-WS Application Programming Interface Abstract Syntax Notation Controller Area Network Commercial Driver’s License Commercial Drivers’ License Information System Commercial Motor Vehicle Component Object Model Concept of Operations Commercial Vehicle Information Systems and Networks Commercial Vehicle Operations Commercial Vehicle Safety Alliance SRI Enforcement PC User Interface Database (State) Department of Motor Vehicles Draft Operational Constraint Draft Operational Policy Dedicated Short Range Communications Electronic Screening Federal Highway Administration Federal Motor Carrier Safety Administration Federal Motor Carrier Safety Regulations Institute of Electrical and Electronics Engineers Inline Frame Element used in HTML Inspection Selection System Intelligent Transportation Systems SAE Standard DSRC Message Set Law Enforcement Information Network License Plate Reader Michigan Criminal Justice Information Network National Law Enforcement Telecommunications System On-board unit USDOT’s Open Source Application Development Portal Personal Computer Radio Frequency Identification Roadside equipment Roadside Unit RESTful Web Services U.S. Department of Transportation Intelligent Transportation Systems Joint Program Office Smart Roadside Initiative – Final Report | vi SAE SAFER SDC SIAS SRI SyRS TSPS UI UID UN USDOT USDOT-R VIN VWS WIM WRI XML Society of Automotive Engineers Safety and Fitness Electronic Records SRI Dashcon SRI Information System Aggregation System Smart Roadside Initiative System Requirements Specifications Truck Smart Parking Service SRI User Interface Universal Identifier User Need United States Department of Transportation USDOT Reader Vehicle Identification Number Virtual Weigh Station Weigh In Motion Wireless Roadside Inspection Extensible Mark-up Language U.S. Department of Transportation Intelligent Transportation Systems Joint Program Office Smart Roadside Initiative – Final Report | vii Chapter 1. Introduction This report summarizes the dev elopment, installation, deployment and testing in the execution of the Smart Roadside Initiative (SRI) prototype project, which was funded by the United States Department of Tr ansportation (USDOT) Intelligent Transportation System (ITS) Joint Program Office (JPO). This report was prepared by Leidos, the prime contractor for the project and known throughout the report as “the development team.” The SRI Vision was for commercial vehicles, motor carriers, enforcement resources, highway facilities, intermodal facilities, toll facilities, and other nodes on the transportation system to collect data for their own purposes and share the data seamlessly with the relevant parties, in order to improve motor carrier safety, security, operational efficiency, and freight mobility. The project goals were to: • • Build, install, and test prototype of Smart Roadside Application(s). Enable data exchange between vehicle and roadside infrastructures which connect to authoritative databases for information and relevant data. The keys to successful testing of the SRI prototype were as follows: • • • Interoperable technologies. Information sharing between vehicle-roadside-freight facility systems. Leveraging current technology investments and existing partnerships. The project began with a multi-phased planning and design approach following the Institute of Electrical and Electronics Engineers (IEEE) standards and processes; the project tasks and key deliverables are outlined below: • • • • • Task 1 - Project and System Engineering Management o Project Management Plan o System Engineering Management Plan o Communications Management Plan Task 2 - Application Analysis and Assessment of Deployed Systems Task 3 - Application Analysis and Assessment of Research Projects Task 4 - Concept of Operations Task 5: o Design a Prototype of Smart Roadside Applications  System Requirements U.S. Department of Transportation Intelligent Transportation Systems Joint Program Office Smart Roadside Initiative – Draft Final Report | 1 Chapter 1. Introduction •  System Architecture  Component Level Design o Develop, Test and Deploy Prototype(s) of SRI applications o Prepare final documentation Task 6 - Stakeholder Outreach When it began in late 2010, the initial concept of the project was to design, build, and deploy a combination of new hardware and software for one test site, i.e., a single interstate weigh station. The research and deliverables provided in tasks 2 and 3 and work done in support of the task 4 Concept of Operations provided strong indications to the development team that a hardware solution was not the right direction for this project. Vendors in the industry were quickly addressing the commercial motor vehicle (CMV) enforcement needs independent of government research, and were providing solutions very rapidly in the market. Despite this development, one problem that became apparent was that there was no integration among any of these vendors products, thereby requiring enforcement officers to have multiple system monitors on their desks in the weigh stations plus having to login separately for each system. It is with this problem in mind that the development team, with the cooperation and support of project sponsors at USDOT, moved forward with the requirements definition and prototype design. In agreement with USDOT, the project team shifted direction from primarily a hardware solution to a software integration system. The system design was changed to accommodate the new approach and discussions began with multiple vendors with hopes of integrating their software into the SRI prototype. The vendor discussions were difficult at best, primarily because the vendors felt their own solution already satisfied the new design of the SRI prototype system and that SRI could hurt their place in the market. The discussions continued for months and some of the key players ultimately refused to participate. Despite this challenge, the development team continued to design and build a SRI framework that would allow for future integration of most any technology deployed at a weigh station. The team was successful in building integrations with a weigh-in-motion (WIM) manufacturer, a license plate reader vendor, the Truck Smart Parking System, smartphone applications, and FMCSA back office systems. These particular integration efforts provided the means to meet the goals of the SRI project. As to the attempt to integrate with external systems, only one was not completed: the integration/incorporation of the mainline WIM located at the West Friendship, Maryland, weigh station. That particular WIM was very old and was not able to connect to multiple systems at the same time. The stakeholders were not in favor of removing the existing communications lines for that mainline WIM to accommodate the SRI prototype test. Another extensive effort in the SRI project was the identification of the prototype test sites. During the course of the project, the development team worked closely with USDOT to identify candidate locations. This included many weigh stations in multiple States, all of which were researched and visited to identify which sites would benefit from using the SRI system. These States included Michigan, Maryland, Colorado, Kentucky and North Carolina. Site visits and stakeholder interviews with Kentucky and North Carolina indicated that there was little need for a system like SRI, since each State had its own internal version of SRI. Colorado agreed to participate, and offered a un ique opportunity to integrate to a Statedeveloped revenue system, but later dropped out due to the timing of a major rewrite of that U.S. Department of Transportation Intelligent Transportation Systems Joint Program Office Smart Roadside Initiative – Final Report | 2 Chapter 1. Introduction same revenue system. The final two locations selected for the SRI deployments were the weigh stations at Grass Lake, Michigan, and West Friendship, Maryland. As planned in the new design approach, SRI successfully leveraged stakeholders’ current technology investments in order to augment existing programs while supporting new activities. The quantitative findings regarding the performance of the SRI Prototype are being developed by an independent contractor and will be published by the USDOT separate from this document. The following are the initial performance metrics that have been identified by the evaluation team: • • • • • Increased Productive Inspections Time Increased Inspection Efficiency Increased Safety User Acceptance Increased Revenue In addition, readers should reference the USDOT’s Open Source Application Development Portal (OSADP)1 which will contain all the source code from the SRI prototype. The lessons learned and conclusions presented later in this document tie more directly to specific prototype test results. In addition, this document describes the extensive role of the stakeholder community throughout the duration of the project. The remainder of this document is organized as follows: 1 • Project Background (Section 2) • Prototype Description and Development Summary (Section 3) provides a hi ghlevel overview of the el ements of the SRI prototype; this section is high-level as the more detailed architecture and design documents contain the detailed parameters for the overall prototype and each component of the prototype. • Test Site Description (Section 4) provides specific details regarding the prototype’s installation, configuration and integration at the two weigh station locations: Grass Lake, MI and West Friendship, MD. • Summary of S takeholder Involvement (Section 5) provides a des cription of al l users and stakeholders involved in the test and how their input and feedback impacted the project. • Prototype Test Summary (Section 6) describes all aspects of the S RI prototype testing and includes the development team’s analysis and findings for the DSRC mobile test. • Conclusions and Recommendations (Section 7) summarize the lessons learned from the project and provide the development team’s recommendations regarding potential enhancements and ex pansion of the SRI concept and technologies. http://www.itsforge.net/ U.S. Department of Transportation Intelligent Transportation Systems Joint Program Office Smart Roadside Initiative – Final Report | 3 Chapter 2. Project Background The Smart Roadside Initiative began a few years ago when a representative cross-section of the CMV community attended the 2008 Smart Roadside Workshop. The participants at the workshop agreed that CMV safety, security, and mobility systems should be linked into a coordinated and comprehensive roadside program. Smart Roadside is now an approved mode-specific item in the USDOT Intelligent Transportation Systems (ITS) Strategic Research Plan, 2010-2014. While the original scope for the goals of Smart Roadside Initiative (SRI) was broad, aspects of that vision are being advanced through the USDOT’s connected vehicle initiative. The primary focus of the SRI remains constant: improve the effectiveness of traditional enforcement activities conducted at weigh/inspection stations by moving compliance checks to the roadside. In doing so, enforcement is better able to focus limited resources on vehicles requiring more extensive measurements and inspection. Forecasts of truck travel demand made by the American Trucking Association and t he Federal Highway Administration (FHWA) point to significant increases in the short and medium term; the importance of removing legally loaded and operating vehicles from enforcement queues cannot be overstated. SRI is part of the USDOT’s connected vehicle initiative. Connected vehicle technology can change our transportation system as we know it by enabling safe, interoperable, networked, wireless communications among vehicles, infrastructure and passengers’ personal communication devices. Connected vehicle technology will enable cars, trucks, buses and other vehicles to “talk” to each other with in-vehicle or aftermarket devices that continuously share important safety and mobility information. This wireless communication will be able to talk to roadside weigh/inspection stations as well. A key component of the USDOT connected vehicle initiative is to use wireless communications to facilitate the high-speed transfer of data and to support: • Safety applications that enable a vehicle to have 360 degree awareness and can inform the operator of hazards and situations he or she cannot see; • Mobility applications that will improve overall transportation system performance by accessing pertinent information from thousands of anonymous vehicles through a connected, data-rich travel environment; and • Traveler information applications that provide travelers with real-time information, including CMV-specific information, about congestion and travel conditions to enable more informed decisionmaking. Within the overall connected vehicle initiative, the SRI represents the subset of CMV applications focused on roadside enforcement. Work is also being performed in the USDOT on vehicle-tovehicle (V2V) active safety applications for CMVs under the Connected Commercial Vehicle Integrated Truck and Retrofit Safety Device projects and an advanced freight traveler information application under the Freight Advanced Traveler Information System (FRATIS) project. The SRI program was planned to operate in a t elecommunication-rich environment that facilitates data sharing among these component applications to enable real-time information sharing at the roadside – vehicle to roadside, vehicle to vehicle, and roadside to driver – and be fully interoperable with the other programs within the connected vehicle initiative. The expected benefit of SRI was to expand the sources and types of information available at the roadside to improve CMV safety and enhance mobility. U.S. Department of Transportation Intelligent Transportation Systems Joint Program Office Smart Roadside Initiative – Draft Final Report | 4 Chapter 2. Project Background The current CMV environment consists of numerous Federal, State, regional, and pr ivate-sector programs that use a combination of manual, semi-automatic, and advanced technologies to support safety, mobility, and security. The effectiveness of these programs will be greatly improved by the SRI concept as relevant and appropriate data is shared among the current systems and they become integrated in a collaborative fashion. The ideal Smart Roadside “system,” when fully deployed, will improve the safety, mobility, and efficiency of truck movement and operations on the roadway by facilitating: • The integration of external systems that enhance the exchange of information for CMV operations to support roadside operations (i.e., the integration of roadside applications with these external information systems that provide information on CMV safety history and credentials status); • Access to information at roadside, including information that will enable the identification of the driver and vehicle as well as the motor carrier; and • The deployment of supporting infrastructure at strategic points along CMV routes to support the exchange of information. U.S. Department of Transportation Intelligent Transportation Systems Joint Program Office Smart Roadside Initiative – Final Report | 5 Chapter 3. SRI Prototype Description and Development Summary User Needs Throughout the project, the development team worked with key stakeholders from the law enforcement and trucking industry communities to identify gaps in user processes and data exchanges that a prototype SRI system might improve. Once identified, the changes were prioritized. The process for prioritizing potential SRI applications was to identify existing technologies and systems that: • Address core functional objectives of the SRI; • Have been deployed successfully; • Are used or are likely to be used in the marketplace; • Can be integrated to deliver enhanced SRI functionality; and • Comply with the national Intelligent Transportation System (ITS) architecture. The objective was to integrate and augment technologies to address both enforcement and industry user needs. With this general prioritization framework in place, the development team sought input from the user community regarding the needs and concerns from which the priorities could be formulated. Identifying, developing, and prioritizing user needs and potential applications involved extensive stakeholder input. This input was developed through a series of meetings, and through focus groups, interviews and surveys of motor carriers, enforcement officials, technologists and others. These efforts are detailed in Section 5 of this document. For State motor carrier safety enforcement users responsible for ensuring carrier, vehicle, and driver compliance with safety regulations, the needs and concerns identified include operating under limited staff and budget and the desire for user (inspector) friendliness. The general conclusion was that more automation was necessary and that systems should require less user training, have improved human interface(s) and ease-of-use, and provide more accurate and current data to increase utilization and value. In addition to these general needs, enforcement users indicated that the system should: • Accommodate visual inspections and manual data entry; • Provide WIM measurements that enable enforcement personnel to identify and flag vehicles for additional weight checks using a static scale; • Provide dimension measurements that enable enforcement personnel to identify and flag vehicles for additional size measurements; • Provide parallel feeds of data for both enforcement and carrier systems concurrently and in real-time; • Provide flexibility to “interrogate” vehicles in both fixed and ad-hoc locations; • Make inspection results available at locations down-stream; U.S. Department of Transportation Intelligent Transportation Systems Joint Program Office Smart Roadside Initiative – Draft Final Report | 6 Chapter 3. SRI Prototype Description and Development Summary • Maintain accurate, up-to-date, and reliable data that can support evidentiary needs for use in legal proceedings; • Provide a means to ensure that data is uncorrupted, verifiable, and secure; • Be user-friendly, easy to use, understandable, and beneficial to the roadside inspector; and • Be integrated into existing work flows and work processes. For potential motor carrier users, which include motor carrier management personnel and drivers who could rely on SRI as a means to convey data essential to conducting screening and inspections and who may use it to access parking data or other services, the needs and concerns include data privacy, security, transparent access, enforcement uniformity, and consideration of cost impacts (especially for smaller carriers). In addition to these general needs, carriers also stipulated that the prototype system should: • Use transponders for identification purposes only, and that these not be tied to personal information; • Notify them of “automatic” and any other inspections in real-time, and use these inspections to update their CSA scores; • Require minimal additional equipment to be installed in vehicles and limit driver distraction; • Contribute to the minimization of delays; • Leverage existing technologies whenever possible; and • Use technology that provides a rapid return on investment (ROI). Based upon this input, and analysis of pre-defined SRI technical and operational characteristics, the research team formulated a set of user needs which were documented in the SRI Concept of Operations, the most recent update/publication of which is from September 2015. SRI Prototype Description and Components The “SRI system”2 is not a discrete system, but rather a prototype that demonstrates the integration of tools, methods, and standards that together have the potential to transform the way CMV operators, safety enforcement personnel and other authorized users access, apply, and manage information. Per the final SRI Concept of Operations, the SRI prototype effectively accomplished the following three things: • • • 2 Streamlined the methods and mechanisms used to locate and access information, thereby accelerating and improving the accuracy of decision making processes; Provided a means to electronically identify commercial vehicles at highway speeds and to manage the exchange of information between vehicles and infrastructure-based systems; and Enabled the delivery of a broad variety of applications that enhance safety and mobility. The term “SRI system” is used throughout this document for simplicity. U.S. Department of Transportation Intelligent Transportation Systems Joint Program Office Smart Roadside Initiative – Final Report | 7 Chapter 3. SRI Prototype Description and Development Summary When conceptualized in the Concept of Operations, the application of the SRI prototype system was depicted below in Figure 1. By contrast, Figure 2 shows what was actually implemented at both deployed sites. Appendix A contains the SRI prototype traceability matrix, which traces the system design components back to the system requirements and user needs. Figure 1. SRI High-Level Perspective Framework U.S. Department of Transportation Intelligent Transportation Systems Joint Program Office Smart Roadside Initiative – Final Report | 8 Chapter 3. SRI Prototype Description and Development Summary Figure 2. SRI High-Level Perspective Framework (Updated) Design Rationale Since multiple systems (Federal, State, and commercial) have to be accessed for CMV screening, a cloud computing approach was chosen. Cloud computing is the use of computing resources (hardware and software) that are delivered as a service over a network. The name comes from the use of a cloud-shaped symbol as an abstraction for the complex infrastructure it contains in system diagrams. Cloud computing allows for a central location of services that can be offered for multiple clients at multiple locations. RESTful (Representational State Transfer) Web Services are used to provide access to the SRI System’s Cloud computing platform. REST-style architectures consist of clients and servers. Clients initiate requests to servers; servers process requests and return appropriate responses, usually in the form of an extensible markup language (XML) document. Requests and responses are built around the transfer of representations of resources. A resource can be essentially any coherent and meaningful concept that may be addressed. A representation of a r esource is typically an XML or a Javascript Object Notation (JSON) document that captures the current or intended state of a resource. The SRI cloud computing is depicted below in Figure 3. U.S. Department of Transportation Intelligent Transportation Systems Joint Program Office Smart Roadside Initiative – Final Report | 9 Chapter 3. SRI Prototype Description and Development Summary Figure 3. SRI Cloud Computing (Updated) A web application for this prototype was chosen instead of a thick client approach. Due to the number of systems accessed and the proprietary nature of the applications, a thick client was deemed to be too costly and too restrictive. To alleviate the complexity, multiple thin clients were written to access local data from the systems and were transmitted using the web service framework provided by SRI. In the Mettler-Toledo scale application, the vendor was able to write to the web services themselves. The data provided to the web services was then viewable via a web browser and logon credentials. A collection of Comet servlets were used to provide real time data pushes to the browser when new data was received. Since SRI was changed from being a thick client to a web application, the goal of having the system available on multiple platforms was still accomplished. The end user just needed to have a system with a modern browser (i.e. Chrome or Firefox) and Internet connectivity. The foundational element of the SRI system is the establishment of open standards-based connectivity through the use of RESTful web services to the variety of systems that are currently in place at the Federal, State, and local levels, referenced as R-WS in Figure 4, which is discussed below in the As-built SRI Prototype Design section. This connectivity is essential to the timely information exchange that underpins the SRI system. One of the key reasons for this is to enable system users the flexibility to implement components/modules of the system suited to the needs of the user and to enable previous automated tools to be integrated into the SRI system. U.S. Department of Transportation Intelligent Transportation Systems Joint Program Office Smart Roadside Initiative – Final Report | 10 Chapter 3. SRI Prototype Description and Development Summary Figure 4. Interconnectivity of the SRI Information Aggregation System The second major element is the mechanism by which users access information. This information, which is used to facilitate a broad range of operational and policy decisions, must be presented to users in a concise, consolidated fashion. These user interfaces are intended to be single points of access that use standardized information access mechanisms, although presentation formats are user-customizable. The third major element is the communications link between the moving CMV and the rest of the SRI network. The ultimate goal is to provide for electronic identification of the vehicle, carrier, and driver, and to allow for the information exchanges necessary to support a variety of location-based services. The system must be “technology agnostic,” meaning that it must accommodate any communications channel that provides the requisite performance, reliability, and information security. The common characteristic for all three major elements is a focus on enhancing the user experience by streamlining access to information, improving decision making, and providing a m eans for delivering new capabilities. An overarching element of this vision is that SRI fit into and supports an information exchange environment that allows for the rapid movement of what are potentially very large data sets. This is essential not only to meet the performance requirements inherent in the delivery of the capabilities envisioned for CMV operations, but also to ensure that it leverages technology that may also be used for V2V safety applications. This extends beyond the simple ability to use any such technologies to promote the development and adoption of methods and mechanisms that ensure SRI functions do no t compromise the low-latency data exchanges necessary to support those safety functions. U.S. Department of Transportation Intelligent Transportation Systems Joint Program Office Smart Roadside Initiative – Final Report | 11 Chapter 3. SRI Prototype Description and Development Summary SRI Prototype Capabilities New Capabilities New capabilities tested through the SRI Prototype Test include the following: • • • • • • Enhanced exchange of i nformation at r oadside (via vehicle-to-infrastructure, V2I, communication) at mainline speeds to support credential reporting; Utilization of unique identifiers for drivers, vehicles, and motor carriers who participate in the system that can be ex changed at m ainline speeds (for the pur poses of the S RI prototype, these identifiers were the dr ivers’ license number (driver), vehicle identification number, VIN (vehicle), and USDOT number (motor carrier)); Common protocols and communications standards for the exchange of information; Interoperable applications; Temporal targets for measuring the speed of data exchanges occurring between the vehicle and roadside equipment; and Supplying information to motor carriers and drivers about motor carrier services in realtime (e.g., truck parking). Enhanced Capabilities The integration of multiple systems through the SRI enterprise-level application significantly enhances the exchange of data between the roadside and external systems. As a result of this integration through SRI, the law enforcement community is able to exchange information regarding motor carrier, driver, and vehicle safety conditions, company and v ehicle safety history, and compliance with credentialing requirements with external systems on a near real-time basis. The additional data sources also provide substantially enhanced visibility into driver and vehicle performance and significantly expand the total number of data points included in State and Federal motor carrier safety history and credential databases. Finally, the use of SRI applications on secondary roads and fixed facility by-pass routes can enhance size and weight enforcement and reduce damage to road systems. By-pass route instrumentation is an effective deterrent to trucks exiting mainline facilities in order to bypass weigh stations. Not only does instrumentation on by-pass routes reduce damage, but it also assists in enforcing weight limits on these routes. Therefore, where appropriate at future prototype sites, data from these devices can be integrated into SRI. It is important to articulate that the new and enhanced capabilities of the SRI system benefit both the enforcement and motor carrier communities. The previous section articulated providing information to motor carriers and drivers about motor carrier services in real-time (e.g., truck parking) as a new capability. The SRI prototype examined truck parking detection and notification systems and pilots currently in development and integrated them into the system design where deemed feasible based on the maturity of these developments. The Smart Roadside Initiative System Requirements Specifications (October 16, 2012 and updated September 2015) and the Smart Roadside Initiative System Design Document (March 2013 and updated September 2015) detail the SRI System Context, System Modes and States, Major System Capabilities, Major System Conditions (Operational Policies), Major System Constraints, User Classes and their interactions, assumptions and dependencies, and the operational scenarios for the prototype system. The following provides an overview of the SRI prototype components, information exchanges, and test scenarios. U.S. Department of Transportation Intelligent Transportation Systems Joint Program Office Smart Roadside Initiative – Final Report | 12 Chapter 3. SRI Prototype Description and Development Summary As-built SRI Prototype Design At the hear t of the S RI prototype is the S RI Information Aggregation System (SIAS). This component contains the web services and other communications interfaces which integrates to external sensors and systems to collect, verify and present the gathered information such as license plate, truck weight, USDOT number, and dr iver information to the r elevant information users including law enforcement officers and truck drivers. Figure 4 depicts its relationship to the other SRI prototype components. 3 Note that the red items are the c omponents developed by Leidos under contract to USDOT; gray items are existing systems and connections. Service-Oriented Architecture A service-oriented architecture (SOA) is the architectural pattern in which application components provide services to other components via a communications protocol, typically over a network, in this case; the Internet. The principles of service-orientation are independent of any vendor, product, or technology. For example, the web service protocol for the reporting of CMV weight is ambiguous enough for WIM provider, Mettler Toledo, to use for both static scale reporting and weigh in motion reporting. It is also generic enough for other vendors to use if they chose to be a part of the Smart Roadside Initiative. The sign-up process would expose the weight reporting web service protocol, structure, and assignment of credentials to send the web service data. Core Functionality SIAS functionality includes: 3 • Dynamic web interface that displays CMV information to officers in real time, • The collection of CMV weight information from Mettler Toledo WIM and static scales, • The storage of CMV weight information on the SRI database for 24 hours, • The collection of license plate images and data from ELSAG (vendor), • The storage of license plate data on the SRI database for 24 hours, • The storage of license plate images on the SRI App Server for 24 hours, • The collection of CMV credential information from SRI Mobile, • The storage of CMV credential information on the SRI database for 24 hours, • The exchange of Aspen data to iyeCitation for reduction in data entry, • The automatic retrieval of SAFER information via SRI Mobile credentials, • The manual retrieval process for SAFER data, • The development of a mobile application for storing and providing CMV and Driver related credentials automatically to weigh station, SRI Prototype System Integration and Test Plan, Leidos, May 2015. U.S. Department of Transportation Intelligent Transportation Systems Joint Program Office Smart Roadside Initiative – Final Report | 13 Chapter 3. SRI Prototype Description and Development Summary • The notification of Pass/Fail weight status from weigh station to mobile application, • The development of a m obile website to allow officers to view SRI on either a tablet or smartphone wherever Internet connectivity is available. Data Exchanges SIAS communications includes: • HTTP(S) protocol for accessing of SRI Web Services. • HTTP(S) protocol for accessing TSPS (Truck Smart Parking System) Web Services • HTTP protocol for accessing SAFER Web Servlet • FireBird ODBC protocol for accessing Aspen DB. • DLL for accessing iyeCitation COM objects • Directory watcher for ELSAG LPR software. When new data files are deposited, the application sends the information to SRI via the SRI Web Services • Bluetooth protocol for sending CMV and Driver related credentials to an On Board Unit (OBU) (see Figure 5) Bluetooth protocol for receiving weight status from OBU Digital Short Range Communication (DSRC) protocol for exchange of data b etween OBU and R oad Side Unit (RSU) • • In essence, the SIAS collects, synthesizes, and formats information from site, State, Federal, and carrier systems to facilitate jurisdiction-dependent enforcement decisions that improve inspection efficiency and lowers false positives. Figure 5. Arada OBU Unit Data Management SRI is dependent on outside systems and services to operate at full capacity. E xternal system access is key for maximum web application functionality. However, all of the external systems are not reliant upon each other. If one of the systems goes down, the others will still continue to function. The SRI system is capable of functioning even if one of the external systems becomes unavailable, although with a more limited feature set. Data is stored from external systems on the SRI system for a maximum of 24 hours. An hourly script wipes data sensitive information from tables for any data older than 24 hours. This will keep from data tracking as well as limit the exposure to PI data. Security The SIAS controls user accounts with login and password credentials for customizable business rules, notification filters, and other configuration settings that are relevant to enforcement sites and their jurisdictions. The implementation utilizes standard security measures such as a secure socket layer (SSL) for encryption, which is the defacto industry standard for secure internet U.S. Department of Transportation Intelligent Transportation Systems Joint Program Office Smart Roadside Initiative – Final Report | 14 Chapter 3. SRI Prototype Description and Development Summary communications. The access system was implemented with different privileges, including one for system administrators. SRI Mobile Website The SRI prototype has a dynamic web user interface that utilizes a web responsive framework. This framework allows for the presentation layer to respond differently for different types of clients based upon the resolution of the display device making the request. So the web application will look and behave differently based upon the device viewing it. On a personal computer (PC) with a high resolution monitor, SRI is full featured with all of the components viewable on one screen. An example of the desktop website, as deployed in the West Friendship, MD weigh station is depicted in Figure 6. Figure 6. SRI Website on PC/Monitor On a tablet or a smartphone that same uniform resource locator (URL) will be scaled back to utilize the smaller real estate that lower resolution provides. With a responsive framework, the UI adapts for many different resolutions and screen sizes.With the Mobile Website, officers can utilize Smart Roadside from any mobile device of their choosing. As long as Internet connectivity is available on the mobile device, Smart Roadside can be used. This frees up commanding officers to view the goings on of the weigh station without having to be present at the weigh station. Log in and subsequent screens are presented in Figure 7: U.S. Department of Transportation Intelligent Transportation Systems Joint Program Office Smart Roadside Initiative – Final Report | 15 Chapter 3. SRI Prototype Description and Development Summary Figure 7. SRI Mobile Website SRI Mobile Application (Mobile App) The SRI prototype includes a m obile application for truck drivers that provides audio and visual cues notifying the driver to either pull into the weigh station for further inspection or to bypass the static scale. While stationary the driver can also access the Truck Smart Parking System to locate available truck parking spaces. This application provides a mechanism for drivers to enter their license number, VIN, USDOT number, and license plate number, as well as a photo of their specific vehicle. In addition, this application provides the communication back to the driver regarding their weigh station instructions. The mobile application interfaces with the SRI core services. The mobile application for the truck driver includes: • Fields for the driver to enter their relevant information (when opening the mobile application for the first time). • Provides the result of the Mettler-Toledo weight assessment (pass or fail) to the driver via a visual red light/green light screen plus audio via cellular communication. • Provides truck parking information (using the Truck Smart Parking Service, TSPS), which is automatically pulled up for the driver when leaving a geofence around the weigh station. This geofence is defined by the SRI prototype. Figure 8 presents images for the drivers’ entry of information and truck parking. Figure 9 presents the instructions and results of the weight assessment; all instructions and results were also verbally communicated to the driver in accordance with FMCSA safety requirements. U.S. Department of Transportation Intelligent Transportation Systems Joint Program Office Smart Roadside Initiative – Final Report | 16 Chapter 3. SRI Prototype Description and Development Summary Figure 8. SRI Mobile Application U.S. Department of Transportation Intelligent Transportation Systems Joint Program Office Smart Roadside Initiative – Final Report | 17 Chapter 3. SRI Prototype Description and Development Summary Figure 9. SRI Mobile App Instructions and Results A DSRC version of the mobile application was also tested in the Maryland pilot. In that scenario there is a backend server that received the data from a roadside unit (RSU) and request MettlerToledo weight assessment from the SRI Web Services. The response was processed by the backend server, converted into a J2735 compliant message using SAE J2735-Nov 2009 (J2735_200911) and sent to the RSU. The RSU then broadcasts that message to the on-board unit (OBU) via dedicated short-range communication (DSRC), and the OBU sends the message to the mobile application via Bluetooth. The RSU used is one of the mobile trailer units from the USDOT’s Saxton Transportation Operations Laboratory (STOL). For future implementations a similar RSU can be used at any location and still provide the same communications back to the OBU. F igure 10 depicts the antenna and unit, as installed at the West Friendship weigh station. Figure 10. RSU Antenna and Unit U.S. Department of Transportation Intelligent Transportation Systems Joint Program Office Smart Roadside Initiative – Final Report | 18 Chapter 4. Test Site Descriptions Chapter 4. Test Site Descriptions Two test sites were chosen for the prototype, one weigh station in Michigan and one in Maryland. Both locations have Internet connectivity which makes access to the cloud system possible. This allows for exchanges to occur between the all of the various systems introduced by Leidos and all of the vendor systems available on the Internet. The following presents summaries of the sites in terms of location, hardware and software and connectivity. East Grass Lake Weigh Station, MI The Grass Lake Weigh Station is located on Eastbound Interstate 94: Latitude: 42 17 36 N, Longitude: 84 10 41 W. An overview of of the weigh station and location of geofences and relevant sensors is shown in Figure 11. Leidos/Google Maps Figure 11. Michigan Grass Lake Weigh Station SRI Configuration In Figure 12, the SRI System is deployed to the East Grass Lake Weigh Station in Michigan. This weigh station lacks an LPR reader, which reduces the amount of external interfaces that SRI can integrate with. The site also does not have DSRC support, which makes testing the SRI Mobile App Bluetooth impossible. However, the site does have Aspen and iyeCitation, so the Aspen to iyeCitation Client was tested there. U.S. Department of Transportation Intelligent Transportation Systems Joint Program Office Smart Roadside Initiative – Final Report | 19 Chapter 4. Test Site Descriptions Figure 12. East Grass Lake Weigh Station Communication Diagram The SRI prototype in Michigan utilized interconnectivity via internet and cellular communications. The SIAS interfaced with Mettler-Toledo to exchange weight information from both the ramp WIM and the static scale at the station. The SIAS also interfaced to SAFER to exchange carrier data, Aspen, and a third-party electronic ticketing system from LexusNexus called iyeCitation to enter and exchange inspection data. The SRI prototype included a m obile application for truck drivers. This application provided a mechanism for drivers to enter their license number, VIN, USDOT number, and l icense plate number, as well as a photo of their specific vehicle. In addition, this application provided the communication back to the driver regarding their weigh station instructions. The mobile application interfaced with the SIAS to collect data from the SRI Mobile app for presentation to law enforcement users via the SRI Dashboard. The SRI Dashboard contains each source of information available to the user, in the case of the Michigan prototype, this included: • Mettler-Toledo Ramp WIM, • Mettler-Toledo Static Scale (Note: Figure 13 presents the display of both ramp and static scale data), U.S. Department of Transportation Intelligent Transportation Systems Joint Program Office Smart Roadside Initiative – Final Report | 20 Chapter 4. Test Site Descriptions Figure 13. Mettler-Toledo Ramp and Static Scale Data • SRI mobile website, • SAFER lookup results (based on USDOT number that is either manually entered by the user or that is received automatically from the SRI mobile application), • A field to allow the user to enter the vehicle USDOT number (if not available via the SRI mobile application or SAFER), • An embedded panel to provide access into the MICJIN portal, and • A button to facilitate the population of iyeCitation with Aspen data (i.e., the means by which the SIAS accesses the inspection data from Aspen and pre-populates the electronic ticket in iyeCitation). Figure 14 displays the SAFER lookup screens after the user has entered the USDOT number (on the mobile SRI mobile website). U.S. Department of Transportation Intelligent Transportation Systems Joint Program Office Smart Roadside Initiative – Final Report | 21 Chapter 4. Test Site Descriptions Figure 14. SAFER Data Lookup The SRI mobile application for the truck driver included: • Fields for the driver to enter their relevant information (when opening the mobile application for the first time). • Provided the result of the Mettler-Toledo weight assessment (pass or fail) to the driver via a visual red light/green light screen via cellular communication. • Provided truck parking information (using the Truck Smart Parking Service, TSPS), which is automatically displayed for the driver while traveling before or after the weigh station. These actions are invoked via multiple geo-fences defined by the SRI prototype. Sensors • • Mettler-Toledo Ramp Weigh-in-motion scale (WIM), model: MT 4 load cell WIM Mettler-Toledo Static Scale (at Station), model: MT 7541 with PDX U.S. Department of Transportation Intelligent Transportation Systems Joint Program Office Smart Roadside Initiative – Final Report | 22 Chapter 4. Test Site Descriptions Existing Systems/Software • • • • • • Aspen SAFER (Truck/carrier lookup using USDOT number) HTML 5 compliant browser (Firefox) – MI uses IE 8 but can use whatever required I-94 Truck parking pilot (Truck Smart Parking Service, TSPS, www.trucksmartparkingservices.com) MICJIN Portal – provides single sign on to CDLIS, NLETS, Talon, and MI internal systems Internet connectivity: o Internet connectivity provided by Verizon o Grass Lake Port 443 and 80 are available o Mettler-Toledo needs separate Internet connection for their software Points of Integration for SRI Prototype • • • • Mettler-Toledo Ramp WIM o Mettler developed application program interface (API) connection to SRI; Leidos developed Web Services integration to SRI o Internet connectivity o API: RESTful Web services, https Mettler-Toledo Static Scale o Mettler developed API connection to SRI; Leidos developed Web Services integration to SRI o Internet connectivity o API Details: RESTful Web Services, https Michigan Criminal Justice Information Network (MICJIN) portal, which facilitates access to: o Law Enforcement Information Network (LEIN) o TALON v 2.08.20 – MI DMV o National Law Enforcement Telecommunications System (NLETS) o No details needed for the integration with the SRI prototype – SRI user interface included an embedded panel which opened the MICJIN portal. TSPS o • TSPS RESTful web services Aspen o Software was resident on all officer’s laptops, Leidos developed code to retrieve data from Aspen to pre-populate iyeCitation client o Connection details:  Firebird connection to local database U.S. Department of Transportation Intelligent Transportation Systems Joint Program Office Smart Roadside Initiative – Final Report | 23 Chapter 4. Test Site Descriptions .net connection open database connectivity (ODBC) from local database to executable  • • LexusNexus iyeCitation (electronic ticketing) o LexusNexus provided available file template and import process o Common object module communication from executable to iyeCitation SAFER o Software was resident on the officer’s test laptop, Leidos developed code to retrieve data from Aspen to pre-populate iyeCitation client o Internet connectivity was provided through the weigh station’s local area network o Web servlet West Friendship Weigh Station, MD The Maryland test site is located in West Friendship, I-70 Westbound and Route 40 (West of Maryland 32, Exit 80, mile marker 79). An overview of the weigh station and location of geofences and relevant sensors is shown in Figure 15. Leidos/Google Maps Figure 15. Maryland West Friendship Weigh Station SRI Prototype Configuration In Figure 16, the SRI System is deployed at the West Friendship Weigh Station in Maryland. This station provides the most robust use of the system with access to both the Mettler Toledo scales as well as the ELSAG License Plate Readers. Add the integration and support for both the SRI Mobile App Cellular and Bluetooth this makes it the test location with the most comprehensive external interfaces. U.S. Department of Transportation Intelligent Transportation Systems Joint Program Office Smart Roadside Initiative – Final Report | 24 Chapter 4. Test Site Descriptions Figure 16. West Friendship Weigh Station Communication Diagram The SRI prototype in Maryland utilized interconnectivity via internet and cellular communications, but also includes a DSRC protocol to facilitate the communication between the vehicle and the roadside. As depicted in Figure 16 the SRI J2735 Translator was developed to convert BER encocoded J2735 messages to a format compliant with SRI Web Services. It also converted the web service response into a BER encoded J2735 message and sent it back to the RSU. As in Michigan, the SIAS interfaces with Mettler-Toledo to exchange weight information from both the static scale at the station and the ramp weigh-in-motion (WIM). The Maryland prototype also interfaces to a third party LPR from ELSAG. The SIAS exchanges carrier data with SAFER. The SRI prototype includes a mobile application 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. In a ddition, this application provides the communication back to the driver regarding weigh station instructions – in Maryland, two tests were performed, one via DSRC and the second test via cellular as in Michigan. Therefore, the hardware in Maryland included both a D SRC-enabled OBU in the vehicle and a roadside unit (RSU). The OBU communicates to the SRI Mobile app via Bluetooth. As in Michigan, the mobile application interfaces with the SIAS; data from the SIAS is configured for presentation to law enforcement users via the SRI Dashboard. The SRI Dashboard contains each source of information available to the user, in the case of the Maryland prototype, this includes: U.S. Department of Transportation Intelligent Transportation Systems Joint Program Office Smart Roadside Initiative – Final Report | 25 Chapter 4. Test Site Descriptions • Mettler-Toledo Ramp WIM • Mettler-Toledo Static Scale • ELSAG LPR • SRI mobile application • SAFER lookup results (based on USDOT number that is either entered by the user or that is received from the SRI mobile application) • A field to allow the user to enter the vehicle USDOT number (if not available via the SRI mobile application or SAFER) The mobile application for the truck driver includes: • Fields for the driver to enter their relevant information (when opening the mobile application for the first time) • The result of the Mettler-Toledo weight assessment (pass or fail) via a visual red light/green light screen via cellular communication Sensors • Main line WIM – Cardinal Scale integrated with Drivewyze. (Equipment would not accept multiple communication connections) • Ramp WIM – Mettler-Toledo (upgrade completed just prior to pilot) • Static Scale – Mettler-Toledo (upgrade completed just prior to pilot) • Mobile LPR – Mobile Plate Hunter 900 (ELSAG) Existing Systems/Software • Maryland’s Electronic citation system • Aspen • HTML 5 compliant browser (Firefox) • Drivewyze • SAFER • Query Central (out of service carrier information) • FMCSA Inspection Selection System (ISS) • NLETS • Automated Hauling Permit System (AHPS) Bentley v 020604 • CDLIS Integration to SRI Prototype • Ramp WIM – Mettler Toledo load cell (equipment upgraded for pilot): o Mettler developed API connection to SRI; Leidos developed Web Services integration to SRI U.S. Department of Transportation Intelligent Transportation Systems Joint Program Office Smart Roadside Initiative – Final Report | 26 Chapter 4. Test Site Descriptions • • o Internet connectivity o API Details: RESTful Web Services, https Static scale – Mettler Toledo multi-platform load cell o Mettler developed API connection to SRI; Leidos developed Web Services integration to SRI o Internet connectivity o API Details: RESTful Web Services, https ESLAG LPR: o ELSAG hardware; a new stationary camera was installed for this test o Connectivity – Internet connectivity was provided through the weigh stations local area network. Note, LPR images, as available through SRI are presented in Figure 17. Figure 17. SRI LPR Images • • DSRC network (See Michigan Site Summary) o 1 mobile RSU was transported to the test site o DSRC + backhaul network to access SRI web services Aspen: o • No existing connectivity to Maryland electronic citation system SAFER U.S. Department of Transportation Intelligent Transportation Systems Joint Program Office Smart Roadside Initiative – Final Report | 27 Chapter 4. Test Site Descriptions o Access via internet connection o Connection details:  Web servlet U.S. Department of Transportation Intelligent Transportation Systems Joint Program Office Smart Roadside Initiative – Final Report | 28 Chapter 5. Summary of Stakeholder Involvement From the outset of the project, the development team sought input from stakeholders representing motor carrier safety and weight enforcement agencies and associations, motor carriers and motor carrier industry associations, technology companies and associations, as well as frequent review and guidance from the project sponsors. The purpose was to develop SRI to meet the needs of users and others interacting with the system by developing a sound Concept of Operations (ConOps) and realizing the concept by fielding and testing a prototype system that leverages and integrates existing technologies and systems. The process involved a series of presentations to stakeholders to gather information, walk through proposed concepts, capabilities and s ystem elements and designs to obtain stakeholder acceptance. These sessions are summarized below. Stakeholder Involvement – Planning and Design Enforcement Community User Needs Workshop In April 2011 at the CVSA Spring Meeting in Chicago, Illinois, an E nforcement Community User Needs Workshop was conducted. The overall goal of the workshop was to determine enforcement user needs for the Smart Roadside Initiative and to identify issues and concerns. Four overview presentations were delivered to start the workshop, and then attendees were asked to participate in one of three facilitated break-out discussion groups. Each breakout session was facilitated by a member of the SRI Team and included representatives from each of the stakeholder groups participating in the workshop. The questions asked of the attendees focused on enforcement procedures and processes; technologies, hardware, data sources, and systems used to conduct inspections; perceived issues and short comings of current activities; and desired improvements. Motor Carrier User Needs and Preferences Gathering Motor carrier industry perspectives were garnered through the following methods: • Interviews were conducted at the February 2011 Technology and Maintenance Council meeting in Tampa, Florida. The SRI Team was able to conduct detailed interviews with 25 TMC participants. Each interview lasted between 10 a nd 15 m inutes, on av erage. Respondents were asked a variety of demographic questions, followed by a brief technology utilization survey, and an i n-depth discussion of the four core SRI applications: UID, WRI, VWS/ e-Permitting, and truck parking. • An Industry Executive Focus Group was conducted in Atlanta, Georgia, in March 2011. SRI Team member ATRI conducted a foc us group of hi gh-level industry executives in Atlanta in March 2011. Thirteen industry representatives attended a one-hour discussion on SRI and the four core applications. The executives represented a variety of firms ranging in size from roughly 100 pow er units to over 10,000. The for mat was an open discussion that was led by ATRI researchers who explained the various SRI applications U.S. Department of Transportation Intelligent Transportation Systems Joint Program Office Smart Roadside Initiative – Draft Final Report | 29 Chapter 5. Summary of Stakeholder Involvement and the as sociated technologies that would potentially be used to implement the applications. • A driver survey was conducted at the Mid-America Trucking Show held in Louisville, Kentucky, in March-April 2011. Thi s event provided an i mportant opportunity to s olicit feedback from commercial vehicle drivers on SRI technologies, needs and requirements, and overall opinions on the SRI program. A paper survey was provided to attendees who were willing to participate, and the survey team collected 130 responses. Industry ConOps Walkthrough On April 20, 2012, a virtual focus group of trucking industry technology and maintenance executives was conducted to present elements of the SRI Concept of Operations (ConOps). There were 18 participants as well as 3 representatives from the American Trucking Associations on the call, and the session lasted 90 minutes. The participants were employed by the organizations listed below. The comments provided by employees were not official company statements, nor did they constitute official company approval or disapproval of the SRI concept. • ABF • American Trucking Associations • Bose • Cummins • FedEx Freight • Florida Trucking Association • Intermec Technologies • JBT • McLeod Software • MHC Truck Leasing • Ozark Motor Lines • PeopleNet • Southeastern Freight Lines • Transport America The meeting began with a brief introduction to SRI which included a review of the SRI vision and objectives. After a short overview of the purpose of the ConOps and the ConOps walkthrough, the attendees discussed content, providing their feedback on the Operational Scenarios, Operational Assumptions, and Operational Constraints Commercial Vehicle Driver Focus Group On April 23, 2012, a virtual focus group of truck drivers was held to review elements of the Smart Roadside Initiative ConOps. A total of six drivers attended the virtual focus group, which lasted one hour. The drivers were employed by large truck fleets (ABF, Conway, UPS, Wal-Mart, YRC). The comments provided by employees are not official company statements, nor do they constitute official company approval or disapproval of the SRI concept. Due to time constraints and the area U.S. Department of Transportation Intelligent Transportation Systems Joint Program Office Smart Roadside Initiative – Final Report | 30 Chapter 5. Summary of Stakeholder Involvement of expertise of the audience, only the five ConOps operational scenarios were discussed and driver feedback obtained. System Requirements Review On October 2, 2012, the development team presented a S ystem Requirements Review to the following stakeholders: • Gary Capps, Oak Ridge National Laboratory (ORNL); • Mark Savage, Colorado State Police (CSP); • Braxton Vick, Woody Lawless, and Lee Long, Southeastern Freight Lines; John Sullivan, Reliable Carriers; • • Mike Nichols, Intermic; • • • • • Rita Goulet, Ontario Ministry of Transportation (MOT); • Pierre Bolduc and Glen McDonald, Ozark Motor Lines; • Brent Hilton and Mike Jeffress, Maverick; • Brooks Snider, Colorado Port of Entry (POE); • • Mark Mitchell, Cloud Software ITLC; Ronald Szapacs, TMC; Matt Hanson, Caltrans; Mark Bell and Jonathon Sabean, Transport Canada; • Rick McDonough, New York State (NYS) DOT; • • Kevin Otto, Cummins; Randy Coplin, Michigan State Police; Barry Pekilis TC; Chris Flanigan, Kate Hartman, Randy Butler, Jeff Loftus, Tom Kearney, Greg Davies, and Walt Fehr, USDOT. The objective of the meeting was to review of top level capabilities and conduct a detailed review of each individual requirement in terms of wording, metrics, testing method, etc. System Architecture Document Review On October 2, 2012, the development team presented a S ystem Requirements Review to the following stakeholders: • • • • • • • • Gary Capps, ORNL; Braxton Vick, Woody Lawless, Lee Long, Southeastern Freight Lines; Mike Nichols, Intermic; Rita Goulet, MOT Ontario; Pierre Bolduc, Transport Canada; Glen McDonald, Ozark Motor Lines; Brent Hilton, Mike Jeffress, Maverick; Brooks Snider, Colorado POE; • • • • • • • • Randy Coplin, Michigan State Police; Barry Pekilis, TC; Mark Savage, CSP; John Sullivan, Reliable Carriers; Mark Mitchell, Cloud Software ITLC; Ronald Szapacs, TMC; Matt Hanson, Caltrans; Mark Bell, Jonathon Sabean, Transport Canada; U.S. Department of Transportation Intelligent Transportation Systems Joint Program Office Smart Roadside Initiative – Final Report | 31 Chapter 5. Summary of Stakeholder Involvement • • • • Rick McDonough, NYS DOT; Kevin Otto, Cummins; Chris Flanigan, Kate Hartman, Randy Butler, Jeff Loftus, Tom Kearney, Greg Davis and Walt Fehr, USDOT. Peggy Fisher,TireStamp; The meeting approach/objective was a review of conceptual and functional architecture to determine: • • • • Consistency with SRI objectives Clear definition of elements Correct definition and use of terminology Complete identification and documentation of all connections System Design Document Traceability Review On December 17, 2013, the development team conducted a System Design Document Traceability Review with FHWA that addressed the following: • • • • • • Basic operations Reliability – system availability Operational performance e.g. comm speed, user interface performance Some security issues to be addressed after prototype, such as vendor provided userid and password for SRI web service access, and whether SSL was sufficient site security. Address orphan user needs from ConOps (see Top Level notes) Possible conflict with 3rd party solution providers in business rule usage. System Design Document Walk Through On March 20, 2013 this was conducted with representatives from motor carriers, commercial vehicle enforcement and associations and governmental sponsors. The walk though covered the following: • • • Review of data structure Use case realizations System interfaces Site Visits In addition, the Team conducted site visits to Missouri, Kentucky, North Carolina, and New Mexico, four States that are currently deploying some SRI-like applications. Two other site visits to Colorado and North Dakota were also conducted, but those sites were using very limited technologies. The research team used these site visits to gain an understanding of State deployment challenges and system operations. U.S. Department of Transportation Intelligent Transportation Systems Joint Program Office Smart Roadside Initiative – Final Report | 32 Chapter 5. Summary of Stakeholder Involvement The series of meetings, reviews, walkthroughs and site visits resulted in a Concept of Operations and System Design acceptable to motor carriers, commercial vehicle drivers, and commercial vehicle enforcement officials. U.S. Department of Transportation Intelligent Transportation Systems Joint Program Office Smart Roadside Initiative – Final Report | 33 Chapter 6. Prototype Test Summary Test Approach The testing of the SRI prototype in the laboratory/development environment included the following levels: • Unit testing: o Tests an individual unit, such as a method (function) in a class, with all dependencies mocked up.  o • This testing was performed by the Leidos development team in the development setting (not in the field). It was approved by the development team leader. SRI prototype unit testing included:  Test each node of the SRI prototype individually  Test integration of all nodes together. Integration testing: o o o Focused on a slice of functionality in a system. This tested many methods and may interact with dependencies like Databases or Web Services. As with unit testing, this testing was performed by the Leidos development team with assistance from developers from external systems (Aspen, iyeCitation, TSPS, and Mettler-Toledo) as required in the development setting (not in the field). SRI prototype integration testing tested connectivity to each node (data retrieval, data posting/display). Performance, system, and acceptance testing was conducted in the field. Field testing in Grass Lake, Michigan was conducted on August 17-18, 2015. Field testing in West Friendship, Maryland was conducted on August 19-21, 2015. The goals of these tests were: • Performance testing: o o • Focused on determining how a system performed in terms of responsiveness and stability under a particular workload. It also served to investigate, measure, validate, or verify other quality attributes of the system, such as scalability, reliability and resource usage. For the SRI prototype, this testing was conducted by the development team in the field and allowed the performance of the SRI prototype to be evaluated against the documented performance and security requirements. System testing: o Conducted on a complete, integrated system to evaluate the system's compliance with its specified system requirements.  This test was conducted by the development team in the field and allowed the performance of the SRI prototype to be evaluated against the remaining system requirements: system (e), application (a), interface (i) U.S. Department of Transportation Intelligent Transportation Systems Joint Program Office Smart Roadside Initiative – Draft Final Report | 34 Chapter 6. Prototype Test Summary o • System testing relied on the operational scenarios as defined in the SRI ConOps document. Acceptance testing: o Conducted to determine if the requirements of a specification or contract are met.  For the SRI prototype, the development team providing on-site training to actual end users (law enforcement and motor carriers), as identified below. Following this, the users interacted with the SRI prototype during the test period. The SRI prototype entered into acceptance testing after all defects were corrected following system testing. It was imperative that SRI prototype testing activities presented minimal impact to normal operations at the weigh stations. The SRI prototype user interface and mobile application used the real flow of information but did not divert or interrupt the normal workflow of the weigh stations. For the evaluation and verification of vehicle weight, the SRI prototype utilized the business rules within the Mettler-Toledo system. On the vehicle side, only truck drivers who agreed to participate in testing the SRI mobile application were required to download the SRI mobile application, enter their information, and receive roadside signals. The research team primarily conducted testing with on-site law enforcement staff, who participated in the acceptance testing and execution of the operational scenarios. In Maryland, USDOT staff (Walton Fehr) also participated as the “owner” of the USDOT’s SRI Truck (“Silver”). Research team personnel and their roles are as follows: • Ron Schaefer (RS): test recorder • Chuckerin Black (CB): lead developer of SRI UI (Cellular) • Jim Cassady (JC): lead developer of S RI DSRC • Diane Newton (DN): recorder and driver of test vehicle Michigan State Police were on site during field testing. The officers were on hand specifically to participate in acceptance testing with respect to the AspeniyeCitation integration. They also received installation and user instructions with respect to the SRI UI. Figure 18. USDOT SRI Truck Officer Mark Brown was also heavily involved in executing scenario testing (system testing). Other participants included: • Sgt. Rick Azleton • Ofc. Mark Brown (M. Brown) • Sgt. Brett Black Maryland State Police were also on site during their field testing to receive user instructions and assist as necessary during system testing. Participants included: • Corporal Anthony • Tfc Hudaon • S/Tpr Hite • Tfc Derr • S/Tpr Jefferies • Tfc Hobbs U.S. Department of Transportation Intelligent Transportation Systems Joint Program Office Smart Roadside Initiative – Final Report | 35 Chapter 6. Prototype Test Summary • CVSI Seifert • CVSI Brown • Cadet Diagle Summary of Test Results Appendix A presents tables for the Unit, Integration, Performance, Security, System, and Acceptance testing process and results. Each table contains the testing requirements, verification methods, test date and tester, and brief results and notations. These are summarized in the following sections. Unit and Integration Testing Unit testing focused on testing: • • • • Internet connectivity Connectivity from each external item (Mettler-Toledo, SAFER, Aspen, iyeCitation, ELSAG, etc.) Server issues Security The items tested were: • • • • • • • Mettler Toledo Ramp WIM Mettler Toledo Static Scale • • TSPS Application SAFER, Aspen, LexusNexus iyeCitation SRI User Interface (UI) SRI Mobile Truck Feed SRI Security Arada on-board unit (OBU) and Roadside Unit (RSU) – DSRC (Additional MD element) • Arada on-board unit (same unit) and SRI Mobile Application – Bluetooth (Additional MD element) • ELSAG LPR (Additional MD element) SRI Mobile Application Unit tests included such elements as: • • • • • • Assuring that data is posted to the web service Data is saved to appropriate database(s) Data can be retrieved from external databases via web service and displayed via user interface Notifications are generated and received regarding geofence entry/exit Verify secure connectivity to mobile applications and onboard computers. System security is upheld. U.S. Department of Transportation Intelligent Transportation Systems Joint Program Office Smart Roadside Initiative – Final Report | 36 Chapter 6. Prototype Test Summary Results: The Unit testing was performed primarily in April 2015. The result of the Unit testing is that all elements PASSED. For Integration testing, the same foci and elements were tested as were examined during the Unit testing, but they performed within context of the integrated SRI System. Testing was designed to assess system component performance based on outcomes such as whether the many elements worked together to generate a desired result; e.g., pass/fail (green light/red light) being is displayed from Mettler-Toledo data. Results: The Integration testing was performed primarily in April, July and August of 2015. The result of the Integration testing is that all elements PASSED. Security, Performance, and System Testing The security, performance and system testing either directly tested or demonstrated the SRI systems’ ability to meet requirements. Key security elements tested focused on whether the SRI system would: • • Protect personal data from unauthorized access; • • Protect proprietary information from unauthorized access; and Protect proprietary information, and government and commercial systems from unauthorized access; Provide read access and read/write access to authenticated users. Results: The determinations were by inspection or direct testing of system response to true or false log-ins. SRI met security requirements for recognizing authorized access to system(s) and data and protecting system(s) and data from unauthorized access. Performance and systems testing evaluated the performance of the overall SRI prototype with respect to the following system functions: • • • System uptime/availability; Data gathering, exchange, data archiving and access via multiple interfaces; and Communications. Key elements focused on during the Performance and System testing included: • • • • • Did the system operate without interruption as designed? Was two-way communication properly established and maintained between SRI and test vehicles? Did data exchanges occur as designed and in a timely fashion? Were exchanges properly logged by the system? Did the SRI screening functions and notifications work as designed? SRI System functions were tested according to the following protocols: U.S. Department of Transportation Intelligent Transportation Systems Joint Program Office Smart Roadside Initiative – Final Report | 37 Chapter 6. Prototype Test Summary • Compliant CMV – Internet and Cellular Communications “Green Light”: CMV passes over a WIM ramp and receives a “green light” indicating no further weight verification check is required. • Non-Compliant CMV – Internet and Cellular Communications “Red Light”: CMV passes over a WIM ramp and receives a “red light” indicating WIM weight thresholds were exceeded. The CMV then proceeds to a static scale for additional weight verification (Not tested in Michigan). • Data Exchange between ASPEN and iyeCitation: The officer accesses the SRI transfer module which pulls the ASPEN report generated for the weight violation and pushes common data elements to iyeCitation. • Enforcement officer Smartphone scenario: An enforcement officer is located outside of the weigh station (in his patrol vehicle) and uses his Smartphone to access the SRI user interface. He is able to screen vehicles that have passed through the weigh station as he would if he were using the user interface on a desktop computer. • Real-Time Truck Parking Information System: A CMV driver uses a Smartphone to access the SRI mobile application and generate a geo-coded message seeking information on truck parking facility locations and availability. A third party service provider generates a return message identifying locations and availability to the SRI mobile application. • Compliant CMV – DSRC “Green Light” (Maryland Only): CMV passes over a WIM ramp and receives a “green light” indicating no additional weight verification check is required. • Non-Compliant CMV – DSRC “Red Light” (Maryland Only): CMV passes over a WIM ramp and receives a “red light” indicating WIM weight thresholds were exceeded. The CMV then proceeds to a static scale for additional weight verification. Results: The results of the testing show: • SRI was able to provide current information in a timely fashion, or as available from integrated data sources, to meet SRI prototype application requirements. • SRI was able to maintain an overall 99.99% system availability in a 24-hour period, the only downtime being some minimal outages (less than one minute) during times where system was being re-deployed. • SRI was able to exchange data with external systems within 1 second for 99% of the time and was able to exchange data with the CMV (or proxy automobile) within 1 second for 99% of the time. The exception was for the Maryland pilot, where there was difficulty in maintaining adequate DSRC connectivity. • • SRI logged data transactions per design. • SRI satisfactorily and accurately accomplished automated weight screening and notifications. 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 (especially important with regard to safety regulations per driver distraction while interacting with system). U.S. Department of Transportation Intelligent Transportation Systems Joint Program Office Smart Roadside Initiative – Final Report | 38 Chapter 6. Prototype Test Summary Maryland DSRC issue and suggested corrective action: In the Maryland pilot the DSRC was tested using DSRC-enabled OBU in the vehicle communicating to the SRI Mobile app via Bluetooth and a roadside unit (RSU). Several technical issues prevented reliable communications between SRI and vehicle. These include: • The OBU did not release the IP address received previously from the RSU, and the OBU did not rejoin the RSU when it got back in range. Arada addressed this issue after the pilot test. • Request was sent to wrong RSU. The btrxclient needs to be modified to accept the backend IPv6 address from the Android application instead of getting that from the WSA that the RSU sends. This would have mitigated some of the testing frustration when testing occurred within range of multiple RSUs. It is also a more robust approach, allowing any application to take advantage of the software written instead of only being able to use it for a single application per RSU. This would be a joint effort between Arada and Leidos to define the protocol for providing the IPv6 address • SRI Mobile didn’t read the response from the Bluetooth socket. More testing needs to be conducted to figure out why the mobile app did not always read the response btrxclient wrote to the Bluetooth socket. • The Bluetooth on the OBU had issues seeing some Android devices even when Bluetooth was enabled and discoverable. • No response was received from backend service at the OBU. This happened in two ways: 1) backend never received the request and 2) backend response was not received by OBU. • The distance at which the OBU joined with the RSU and sends that message SRI Mobile was too short. The vehicle was already in the exit ramp to the weigh station before SRI informed the driver the weigh station was there. The time from the Approaching Weigh Station screen to driving over the WIM was a few seconds. Acceptance Testing Once system issues were addressed as a result of system testing, user interaction with the SRI system was tested. Enforcement official and participating truck drivers were trained in advance about how to use of the SRI Dashboard (Enforcement) and the mobile applications (CMV drivers and Enforcement). Below are the user-SRI interactions conducted by the participants and validated by the test team: Drivers • • • Enter information into mobile application. Receive weigh station instruction via red light/green light. View truck parking information (Michigan and Maryland). Enforcement Officers • • • The officer logs into the SRI user interface successfully. The officer views the Mettler- Toledo Ramp WIM data presented on the SRI UI. The officer views the Mettler-Toledo static scale data presented on SRI UI. U.S. Department of Transportation Intelligent Transportation Systems Joint Program Office Smart Roadside Initiative – Final Report | 39 Chapter 6. Prototype Test Summary • • • • • • • • • • • • • The officer views data from SRI mobile application on SRI UI. The officer selects a truck from the truck feed and view complete data available. The officer enters the vehicle’s USDOT number on SRI UI. SAFER Company Data module populates if USDOT number is available from the SRI mobile application If the officer enters the USDOT number, the SAFER Company Data module populates. The officer views SAFER US Crash data within a separate module. The officer views SAFER US Safety Rating within a separate module. The officer views SAFER US Inspections within a separate module. The officer launches MiCJIN portal from the SRI UI (Michigan only). The officer logs in to MICJIN portal when it is accessed from the SRI UI (Michigan only). When executed, iyeCitation electronic ticket is pre-populated with saved Aspen data (Michigan only). LPR window appears in SRI UI (Maryland only). LPR data appears in SRI UI (Maryland only). Results: The Acceptance tests successfully demonstrated the system capabilities as used by the participants. There were some issues that occurred during the testing in Michigan: • The Truck Parking application showed only three locations appearing regardless of direction traveled. This was caused by a TSPS coding change that was later resolved. • If the user selected finish, park or print on Mettler-Toledo interface, information was not populating SRI UI in the weigh station (this has been resolved). • Users were unable to log into the MICJIN portal when attempting to access it from the SRI UI due to no MI VPN available on SRI laptop at the weight station. • Due to security, a separate computer (not the laptop running SRI UI) was used to demonstrate the execution of iyeCitation, in which an electronic ticket was pre-populated with saved Aspen data. Testing Lessons Learned 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 were learned, as follows: DSRC and Bluetooth DSRC is a reliable and efficient way of exchanging information between vehicles, and between vehicles and the roadside. The use of DSCR in this project was mostly successful but suffered from some implementation issues. U.S. Department of Transportation Intelligent Transportation Systems Joint Program Office Smart Roadside Initiative – Final Report | 40 Chapter 6. Prototype Test Summary The software written to exchange data between a mobile device and an On Board Unit via Bluetooth was fairly rigid in its implementation and required events to occur in a defined order, which is not always consistent with real-world usage. If an error occurred, the software often needed to be restarted. Issues were also observed with inconsistent communication between the mobile device and the OBU. The OBU software also relied on the Road Side Unit (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. The last issue observed in testing was an underlying error in the OBU firmware that made testing difficult. In summary, the technology will work for CMV weigh station bypass, but improvements need to be made in the OBU software for smooth operation. Connected Vehicle Development 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. Mobile Platform Selection 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, given two primary factors: 1. The only way to di stribute the software to pho nes for this project was the u se of the platform stores. Apple has a very rigid distribution model at the ti me of this decision which didn't allow for easy mobile software deployments necessary for development. With Android, however, the di stribution model through the pl atform store was less restrictive and allowed for much easier and rapid deployments. 2. The other factor in determining the pl atform choice was the tal ent pool of the development team. Only one developer on the team had experience with writing an Apple application. The rest of the team had limited Android experience, but they were all well versed in Java, which is the primary development language for the Android platform. 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. GPS Drift and Geofencing When developing a mobile application that is dependent on GPS location data, care must be taken to allow for inaccurate GPS signals. As noted above, not all mobile devices are equal when it U.S. Department of Transportation Intelligent Transportation Systems Joint Program Office Smart Roadside Initiative – Final Report | 41 Chapter 6. Prototype Test Summary comes to GPS antennae; some devices experience GPS drift when standing still or in motion. This means the GPS position will move even when the mobile device is not moving, or the position will not be completely accurate; e.g., the GPS position may report a device location is off the road when it is in fact in the middle of the lane. 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 geofence. 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. System vs. Device Data Generation The SRI System is an aggregate system relying on outside devices and services to feed the system. All of these feeds are time-sensitive in nature. The data that is received from these feeds have to appear on the screen in near real time or with a v ery minor delay (seconds). During the course of development, the research team realized that the timestamps coming from these outside devices and services did not always sync up against the SRI system times, even though all devices were synced to Internet Time. A time difference of a few seconds would have serious consequences when trying to associate data as CMVs pull in to the weigh stations at ramp speeds. This led to inaccurate feed associations, failures in data capturing, and failures in weight reporting. This was compounded even more when the SRI Mobile app was released to the Google Play Store. Almost all of the times reported from the outside Android devices had times that were not in sync with the SRI system. Some times were off by hours. Trying to manage all of the devices times would be impossible. This error was alleviated by eliminating the reliance on the times provided by the outside devices and services. Those outside times were still reported to the SRI Web Services, but now the SRI system was generating its own timestamps when the SRI Web Services were called. Those SRIgenerated times were then used to associate data. As a result, SRI only used the times it generated for calculation or association. Had the SRI research team known that there would be so much time variation among outside devices and services, there would have been a d ecision 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. Large Scale JavaScript Applications The rise of JavaScript applications came from the idea of keeping logic work on the client machine and having servers do more of what their name actually represents: “serve” any required data. This is especially true when applications have a large user base that will constantly drive servers to or, worse, over their limits. But what about a smaller scope of users such as would be involved with the Smart Roadside Initiative development and testing? Would there be benefits in using JavaScript as the main workhorse when the server’s resource aren’t being maximized? This is a question of scalability and how ready SRI is to serve a growing number of users without the immediate requirement of additional hardware. This idea brings JavaScript frameworks into the spotlight, and with it the competition of different organizations to develop a product that will attract developers and fuel the future development cycle of applications made for the web. With so many choices, the research team selected Google’s AngularJS, which is a JavaScript framework for U.S. Department of Transportation Intelligent Transportation Systems Joint Program Office Smart Roadside Initiative – Final Report | 42 Chapter 6. Prototype Test Summary building web applications with HTML, JavaScript, and CSS. AngularJS allowed the research team to develop faster and smarter while also making it possible to create a more robust application such as the dashboard for screening trucks while keeping the code highly maintainable and easily reusable. Complex interactions between different sensors at a weigh station, such as collecting data from devices such as weigh-in-motion scales, a license plate reader, and a wireless mobile device—all from multiple vehicles—seems daunting. But AngularJS provided a framework that made it much more efficient for code developers to separate build modules and inject them as a dependency wherever they were needed in the application. The Responsive Web Every day a new device enters the market, and with it the challenge of ensuring its user base are not excluded from products being built. But with the Smart Roadside Initiative, the users can use the application on a standard resolution on a personal computer at their location. The reason it was made responsive is that, when building applications, it is desirable not only to look ahead, but also to fuel the progress of the endeavor as a whole. The freedom to use any device to access 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 more mobile work station for officers using tablets to relay information to other end user, is possible thanks to the implementation of responsive web design. This technology should not be an addition but a requirement for future projects. Vendor Participation in Government Projects It became very apparent that numerous vendors in the SRI space were very concerned about controlling their future and protecting their investments. They were not interested in the government developing a system that could hurt their financial future. SRI was never intended to encroach into their space, but many vendors believed it would. Future such projects must take into consideration that if it appears the government is trying to solve a problem that the vendors have a solution for already, then the government should try to work with them to make sure their system handles whatever problem the government is trying to solve. U.S. Department of Transportation Intelligent Transportation Systems Joint Program Office Smart Roadside Initiative – Final Report | 43 Chapter 7. Conclusions and Recommendations Identifying and documenting lessons learned and opportunities for expansion and improvement are a critical final step in the prototype process. This section provides documentation to the successes and challenges encountered during the test. Second, it helps understand opportunities that may be explored going forward. The conclusions in this section are from the perspective of the research team and do not include either the qualitative or quantitative analysis or conclusions from the independent USDOT-funded impact assessment of the prototype. Project Conclusions Overall, a project like SRI must delicately balance the varying needs of both the government and private sector stakeholders. The walkthrough process revealed the difference in thought between the industry/driver community and the enforcement community. By nature, it is common for these communities to inherently hold opposing opinions, and SRI was no ex ception with respect to the objectives of SRI and the operation/functions of the prototype. The prototype effort sought to satisfy both sides by offering each unique benefits; however, the development effort focused more on the enforcement user as opposed to the driver. This is not to say the driver was ignored – the mobile app and truck parking were definitely the touch points for that user. The initial vision for SRI had sought to continue the communication to the driver’s back office and management systems but we could not find a cooperative carrier that was willing to participate given their concerns of protecting their customer information and drivers. On the testing side, the deployment tests at both sites concluded that the SRI design, which was intended to consolidate existing weigh station technologies into one system and user interface, was successful. The integration of the SRI Mobile app for the drivers was also successful. The testing of the DSRC Bluetooth connectivity had some issues but ultimately was resolved. The goals set out for the project were met by deploying the SRI integrated framework as designed. Recommendations One of the core final products of this project was the technology framework designed and developed to support the multitude of integration points with the technologies available in a weigh station. The test proved that integrating each of the technologies could be done primarily using web services and in a cloud environment with very quick response time. The mobile application for the drivers also proved successful and is a viable option in the current market. All of the source code is available on the USDOT Open Source Application Development Portal to be downloaded for future use. The structure of the system will require very little modification should another State decide to implement SRI if the current integration services are similar to what was used during the pilots; i.e. U.S. Department of Transportation Intelligent Transportation Systems Joint Program Office Smart Roadside Initiative – Draft Final Report | 44 Chapter 7. Conclusions and Recommendations Mettler Toledo, ELSAG, etc. If a new technology or integration point is required then some additional coding will be required. States can choose to do this work themselves or hire a consulting firm to do the work. SRI does not replace the products currently in the market; it provides the means to integrate the existing technologies into one user interface. This is unique in the market today and there is a very economical way to install and use SRI given the way it was developed. Commercially, any IT company can download the SRI code and begin to market and sell its installation services to the states. U.S. Department of Transportation Intelligent Transportation Systems Joint Program Office Smart Roadside Initiative – Final Report | 45 Appendix A. Traceability Matrices A.1 SRI Prototype Traceability Matrices In introducing the final SRI prototype traceability matrix, we must first present the proposed architecture for both the DSRC and Cellular solutions. The figures below were included in the original SRI Concept of Operations from May 2012. In Figure 19, the vehicle communicates to SRI via DSRC. In Figure 20, the vehicle communicates to SRI via a cellular network. DSCR requires a fixed roadside device to communicate with the vehicle. The roadside device was located at the West Friendship, Maryland weigh station. In the figures, the items are numbered sequentially, starting with #1, which indicates the triggering of the inspection process by the passing of a device in the CMV. Figure 19. Proposed SRI Functional Architecture – DSRC Solution U.S. Department of Transportation Intelligent Transportation Systems Joint Program Office Smart Roadside Initiative – Draft Final Report | 46 Chapter 7. Conclusions and Recommendations Figure 20. Proposed SRI Functional Architecture – Cellular Solution The sections below summarize what was actually deployed with the final prototype design, while still referencing the original concept diagrams shown above. The bullets are numbered to correspond to the numbered elements within the original architecture figures. These sections are included to document how the riginal architectures changed in the final deployment of the SRI prototype. A.1.1 Updated Process Flow for DSRC 1) Commercial Motor Vehicle (CMV) is equipped with an Android phone with the SRI Mobile App Bluetooth installed. It communicates the credential information to the On Board Unit (OBU) via Bluetooth. The OBU communicates the data to the Road Side Unit (RSU) via DSRC once the OBU is within range of the RSU. The RSU then communicates the data to the SRI J2735 Translator via UDP over IPV6. The SRI Translator communicates the data to the Truck Feed SRI Web Services over TCPIP via the Internet. 2a) Local weigh station systems identify the weight of the vehicle, and captures License Plate image and data if available. U.S. Department of Transportation Intelligent Transportation Systems Joint Program Office Smart Roadside Initiative – Final Report | 47 Chapter 7. Conclusions and Recommendations 2b) Look up Company Snapshot data utilizing the SAFER SRI Web Service. The DOT number will be supplied by the SRI Mobile App Bluetooth credentials. 3) SRI issues pass/fail messages based up weight or random stops. 4) SRI Mobile App Bluetooth receives message from SRI regarding pass/fail based upon weight or random stops. 5a) Law enforcement uses Aspen to log inspection. 5b) Law enforcement uses Aspen 2 iyeCitation to transfer logged inspection information to iyeCitation for citation violation. 6) Carrier is notified of the event via ticket issued. 7) SRI Mobile App Bluetooth receives upcoming truck parking stops via the Truck Smart Parking Services (TSPS). A.1.2 Updated Process Flow for Cellular 1) Commercial Motor Vehicle (CMV) is equipped with an Android phone with the SRI Mobile App installed. I t communicates the credential information to the Truck Feed S RI Web Services over TCPIP via the Internet. 2a) Local weigh station systems identify the weight of the vehicle, and captures License Plate image and data if available. 2b) Look up Company Snapshot data utilizing the SAFER SRI Web Service. The DOT number will be supplied by the SRI Mobile App Bluetooth credentials. 3) SRI issues pass/fail messages based up weight or random stops. 4) SRI Mobile App Bluetooth receives message from SRI regarding pass/fail based upon weight or random stops. 5a) Law enforcement uses Aspen to log inspection. 5b) Law enforcement uses Aspen 2 iyeCitation to transfer logged inspection information to iyeCitation for citation violation. 6) Carrier is notified of the event via ticket issued. 7) SRI Mobile App Bluetooth receives upcoming truck parking stops via the Truck Smart Parking Services (TSPS). U.S. Department of Transportation Intelligent Transportation Systems Joint Program Office Smart Roadside Initiative – Final Report | 48 Chapter 7. Conclusions and Recommendations A.1.3 Final SRI Traceability Matrix The Final SRI Traceability Matrix is presented below in Tables 1 through 5. This matrix references the System Architecture diagrams (from the original SRI Concept of Operations) presented in earlier in this Appendix. The “Cellular” and/or “DSRC” distinction and as sociated numbers, refer to the numbered elements on either the Cellular or DSRC diagrams, and as ultimately deployed (and described in Section A.1.1 and A.1.2). Table 1. SRI Traceability Matrix - System Requirements (e) Req ID e.001 e.002 e.003 e.004 e.005 e.006 e.007 e.008 e.009 e.009.1 e.010 e.011 e.012 Requirement SRI shall be designed to operate in conjunction with and not interfere with existing systems. SRI shall monitor roadside equipment. SRI shall monitor external system availability. SRI shall provide continuous system health 2 availability information. The SRI Prototype System shall be deployed and tested at a fixed facility on the Interstate System. The SRI Prototype System shall be deployed and tested in a mobile environment on selected secondary routes. The SRI prototype shall use the USDOT number as the unique identifier for the carrier. The SRI prototype shall use the VIN number as the unique identifier for the CMV. The SRI prototype shall use the CDL number as the unique identifier for the CMV driver. The SRI prototype shall use the drivers’ license number or appropriate identifier for drivers operating CMVs that do not require a CDL. The SRI prototype shall verify that all information originates from an authoritative source. Both interstate and intrastate vehicles/carriers shall be able to use the SRI prototype. SRI shall collect, store, maintain and provide real-time on-line interactive access to historical vehicle, driver and carrier safety data at the weigh station. Michigan and/or Maryland or Future Demonstration1 Source Verification Method System Architecture UN14 Inspect Cellular - 1, 2a, 2b, 6, 7 MI, MD DOP01 Inspect DSRC-1 MI, MD DOP01 Inspect 2a, 2b, 6, 7 MI, MD DOP01 Inspect All MI, MD DOP03 Demonstrate DSRC -All MI, MD DOP03 Demonstrate Cellular -All F DOP04 Inspect Both - 1, 4 MI, MD DOP04 Inspect Both -1, 4 MI, MD DOP04 UN12 Inspect Both -1, 4 MI, MD DOP04 UN12 Inspect Both -1, 4 F DOP05 Inspect Both -1, 4 F UN 08 Demonstrate All F UN 08 Demonstrate All MI, MD U.S. Department of Transportation Intelligent Transportation Systems Joint Program Office Smart Roadside Initiative – Final Report | 49 Chapter 7. Conclusions and Recommendations Req ID Requirement Source Verification Method System Architecture Michigan and/or Maryland or Future Demonstration1 e.013 SRI shall provide capability to securely log the passing of each vehicle, the information UN 08 Inspect Both - 3 MI, MD passed to the roadside system, and the information passed back to the vehicle from the roadside system. e.014 SRI shall provide an interface to all commercial drivers that is compliant with DOC01 Demonstrate Both - 3 MI, MD existing safety regulations. 1 Colorado replaced by Maryland (MD) 2 Dependent on weigh station hours of operation. SRI prototype system will provide continuous availability when station is open. 3 Historical data from SAFER; information collected by SRI prototype stored for 23h, 59m. U.S. Department of Transportation Intelligent Transportation Systems Joint Program Office Smart Roadside Initiative – Final Report | 50 Chapter 7. Conclusions and Recommendations Table 2. SRI Traceability Matrix - Application Requirements (a) Req ID a.001 a.002 a.002.1 a.002.2 a.002.3 a.002.4 a.002.5 a.002.6 a.002.7 a.002.8 a.003 a.003.1 a.004 a.004.1 a.004.2 a.004.3 Requirement SRI shall be consistent with the ITS National Architecture and associated standards such as the CVISN National Architecture. SRI shall provide an interface and processing modules for truck parking applications. SRI shall provide information about the availability of truck parking spaces. SRI shall provide current parking availability information at a specific facility. SRI shall provide predicted future parking availability information at a specific facility. SRI shall provide 24x7 access to truck parking information.2 SRI shall provide a graphical interface to stationary (i.e., dispatcher/ operator/driver/traffic analyst/other) users. SRI shall provide a user interfaces to nonstationary drivers when integrated in-vehicle display systems exist. SRI shall allow a stationary user to submit requests for automated truck parking information. SRI shall allow a user to receive the results of an automated request for truck parking information. SRI shall provide an interface and processing modules for enforcement screening applications. SRI shall provide the ability for roadside systems to integrate roadside systems data and make it available to Roadside System SRI user applications. SRI shall provide a processing capability that automates the roadside inspection tasks. The SRI system shall determine if a CMV complies with jurisdictional licensing requirements. The SRI system shall determine if a driver complies with jurisdictional licensing requirements. The SRI system shall determine if a driver complies with HOS requirements. Source Verification Method System Architecture Michigan and/or Maryland or Future Demonstration1 UN08 Analyze ALL MI, MD UN10 Demonstrate Both - 7 MI UN10 Demonstrate Both - 7 MI UN10 Demonstrate Both - 7 MI UN10 Demonstrate Both - 7 F UN10 Demonstrate Both - 7 MI UN05 Demonstrate Both - 7 MI UN07 Demonstrate Both - 7 F UN05 Demonstrate Both - 7, 6 MI UN05 Demonstrate Both - 7 MI UN10 Demonstrate Both - 3 MI, MD UN09 Analyze Both - 3 MI, MD T007 Analyze Both - 3 (SRI Decision Engine), 5a, 5b F T002 Test Both - 3, 2b F T002 Test Both - 3, 2b F T007 Test Both - 3, 2b F U.S. Department of Transportation Intelligent Transportation Systems Joint Program Office Smart Roadside Initiative – Final Report | 51 Chapter 7. Conclusions and Recommendations Req ID a.004.4 a.004.5 a.004.6 a.004.7 a.004.8 a.004.9 a.004.10 a.004.11 a.004.12 a.004.13 a.005 a.005.1 a.005.2 a.005.3 a.005.4 a.005.5 Requirement The SRI system shall determine if a CMV complies with jurisdictional size requirements. The SRI system shall determine if a CMV complies with designated safety requirements. The SRI system shall determine if a CMV complies with weight requirements. The SRI system shall determine if a CMV has a legally issued permit to exceed the legal limits for size and/or weight at the current location of the CMV. SRI shall provide the data necessary to document inspection events and outcomes. SRI shall formulate alarms for user notification via the user interface(s). SRI shall automatically identify to the enforcement personnel approaching vehicles that have been flagged as potentially needing maintenance or to be put out of service due to violation of designated vehicle, driver and/or carrier safety regulations. The SRI prototype shall obtain vehiclebased maintenance data from the vehicle CAN BUS where available. SRI shall provide vehicle-based maintenance data obtained from the vehicle to the carrier. SRI shall provide driver-based safety information obtained from the vehicle to the carrier. SRI shall provide an interface for Tier 1 users. SRI shall provide an interface for CMV Enforcement Officers and supervisors to enter data. SRI shall provide an interface for CMV Enforcement Officers and supervisors to execute processes. SRI shall provide an interface for CMV Enforcement Officers and supervisors to receive information and alerts. SRI shall provide an interface for CMV drivers to receive information. and alerts. SRI shall provide an interface for motor carriers to view information and receive alerts. Michigan and/or Maryland or Future Demonstration1 Source Verification Method System Architecture T006 Test Both - 3, 2a, 2b F T002 Test Both - 3, 2b F T006 Test Both - 3, 2b F T002 Test Both - 3, 2b F UN10 Analyze Both - 3 MI, MD UN05 Test Both - 3, 4 F UN11 Demonstrate Both - 3 F UN04 Demonstrate Both - 3, 4 F UN05 Demonstrate Both - 6 F UN05 Demonstrate Both - 6 F UN10 Demonstrate Both - 3, 4, 5, 6 MI, MD UN10 Demonstrate Both - 5a, 5b MI, MD UN10 Demonstrate Both - 5a, 5b MI, MD UN10 Demonstrate UN10 Demonstrate Both - 4 MI, MD UN10 Demonstrate Both - 6 F Both - 3 MI, MD U.S. Department of Transportation Intelligent Transportation Systems Joint Program Office Smart Roadside Initiative – Final Report | 52 Chapter 7. Conclusions and Recommendations Req ID a.006 a.007 a.007.1 a.007.2 a.007.3 Requirement SRI shall conduct the analytical and data fusion functions necessary to evaluate CMV, carrier, and driver compliance. SRI shall comply with nationwide interoperability standards currently used for the USDOT V2X Program. SRI shall comply with SAE STD J2735. SRI shall comply with the relevant sections of IEEE 1609 (including Architecture, Resource Manager, Security Services, Networking Services, Multi-Channel Operations, overthe-air data exchange protocol for ITS) and the version updates available at the time of design. SRI shall comply with SAE J1929. SRI shall comply with IEEE Standard 802.11p. SRI shall provide vehicle system information a.008 that is used by SRI to users. SRI shall provide designated vehicle system a.008.1 information to the driver through the driver application. SRI shall provide applicable vehicle system a.008.2 information to the carrier through the carrier application. SRI shall be consistent with the ITS National a.001 Architecture and associated standards such as the CVISN National Architecture. SRI shall provide an interface and a.002 processing modules for truck parking applications. 1 Colorado replaced by Maryland (MD). 2 Depending on availability of TSPS application. a.007.4 Source Verification Method System Architecture Michigan and/or Maryland or Future Demonstration1 UN10 Analyze Both - 6, 7 F UN09 Inspect MD DOP06 UN014 Both - 3 (SRI Decision Engine) Inspect All MD DOP06 UN014 Inspect All MD Inspect All F Inspect All MD Demonstrate All F UN09 UN14 Demonstrate Both - 4, 6 F UN09 Demonstrate Both -4 F UN09 Analyze Both -6 MI, MD UN09 Demonstrate Both -6 MI DOP06 UN014 DOP06 UN014 DOP06 UN014 U.S. Department of Transportation Intelligent Transportation Systems Joint Program Office Smart Roadside Initiative – Final Report | 53 Chapter 7. Conclusions and Recommendations Table 3. SRI Traceability Matrix - Performance Requirements (p) Req ID p.001 p.001.1 p.001.2 p.001.3 p.001.4 p.002 p.002.1 p.002.2 p.003 p.003.1 p.003.2 p.004 p.005 p.006 p.007 Requirement SRI shall provide current information in a timely fashion, or as available from integrated data sources, to meet SRI prototype application requirements. SRI shall be able to exchange data with external systems within 2 seconds, 99% of the time. SRI shall be able to exchange data with Roadside Equipment within 2 seconds, 99% of the time. SRI shall be able to exchange data with CMV within 2 seconds, 99% of the time. SRI data exchanges shall be time stamped when the exchange was completed. SRI shall provide the capability to establish two-way communications with each properly equipped vehicle approaching the weigh station. SRI shall maintain two-way communications with each properly equipped vehicle as it passes through the weigh station. SRI shall maintain two-way communications with each properly equipped vehicle as it exits the weigh station. The SRI system shall be able to maintain an overall 99% in a 24 hour period system availability. The SRI Prototype will log each system outage with the date, GMTtime, length (in minutes), and cause of the outage. The SRI Prototype will identify the user responsible for system outages that occur as a result of system breach or tampering. SRI shall be able to communicate "Pass/Need to stop" instructions to a driver in time for compliance with the instruction. SRI shall be designed to accommodate multiple users with different user needs and requirements. SRI shall provide sanitized data to external systems for public use.2 SRI shall provide an initial automated inspection capability that will expedite and supplement the existing visual and manual inspection processes. Source Verification Method System Architecture Michigan and/or Maryland or Future Demonstration1 P001 Test All MI, MD Test Both - 2a, 2b, 6, 7 MI, MD Test DSRC-1 MI, MD Test Both - 4 MI, MD P002 Test All MI, MD UN08 Demonstrate Both - 4 MI, MD UN08 Demonstrate Both - 4 MI, MD UN08 Demonstrate Both - 4 F UN05 Inspect All MI, MD P003 Inspect All MI, MD P003 Test All F UN07 Test All MI, MD P005 Demonstrate All MI,MD UN03 Inspect Both - 4 F UN010 Analyze All F P002 UN05 UN11 P002 UN05 UN11 P002 UN05 UN11 U.S. Department of Transportation Intelligent Transportation Systems Joint Program Office Smart Roadside Initiative – Final Report | 54 Chapter 7. Conclusions and Recommendations Req ID Requirement Source Verification Method System Architecture Michigan and/or Maryland or Future Demonstration1 Both - 3 (SRI SRI shall make a decision as to whether to UN010 Test Decision MI, MD allow each vehicle to pass or require them to Engine) stop for a check. SRI shall include a manual override function UN11 Demonstrate Both - 3 F p.007.2 for the automatically generated decision for vehicles to pull in for safety inspection. SRI shall issue Randomly generated pull-in UN10 Test Both - 1 F p.007.3 for safety inspection signals. SRI shall issue Manually generated pull-in UN10 Test Both - 1 F p.007.4 for safety inspection signals. SRI shall issue Automatically generated pullUN10 Test Both - 1 F p.007.5 in for safety inspection signals. SRI shall perform checks on Both - 1, SRI Vehicle/Carrier/Driver Safety Information T002 Analyze Decision F p.007.6 when making the "Pass/Need To Stop" Engine determination. Both - 1, SRI SRI shall perform checks on Vehicle Decision F T002 Analyze p.007.7 Credentials when making the "Pass/Need Engine To Stop" determination. Both - 1, SRI SRI shall perform checks on Driver and T002 Analyze Decision F p.007.8 Carrier Credentials/Status when making the Engine "Pass/Need To Stop" determination. Both - 1, SRI SRI shall perform checks on Vehicle Size Decision MI, MD T006 Analyze p.007.9 and Weight Information when making the Engine "Pass/Need To Stop" determination.3 1 Colorado replaced by Maryland (MD). 2 Sanitized data refers to data that has had proprietary or sensitive information removed. 3 SRI prototype only performed checks on vehicle weights (checks meaning data collected was verified by a decision engine – in this case, Mettler-Toledo. p.007.1 U.S. Department of Transportation Intelligent Transportation Systems Joint Program Office Smart Roadside Initiative – Final Report | 55 Chapter 7. Conclusions and Recommendations Table 4. SRI Traceability Matrix - Security Requirements (s) Req ID Requirement SRI shall protect personal data from unauthorized access. SRI shall protect proprietary information s.002 from unauthorized access. SRI shall protect proprietary systems from s.003 unauthorized access. SRI shall provide read access and s.004 read/write access to authorized users. SRI shall provide read access and s.005 read/write access to authenticated users. 1 Colorado replaced by Maryland (MD). s.001 Source Verification Method System Architecture Michigan and/or Maryland or Future Demonstration1 UN06 Inspect All MI, MD UN06 Inspect All MI, MD UN06 Inspect DOP09 Test DOP09 Test Both - 2a, 2b, 6, 7 Both - 3, 4,5a, 5b Both - 3, 4,5a, 5b MI, MD MI, MD MI, MD Table 5. SRI Traceability Matrix - Interface Requirements (i) Req ID i.001 i.001.1 i.002 i.002.1 i.003 i.003.1 i.004 Verification Method System Architecture Michigan and/or Maryland or Future Demonstration1 T001 UN01 UN02 Demonstrate Both - 4 MD DOP 02 Analyze Both - 4 MI, MD T002 UN02 Inspect DSRC-1 F DOP 02 Inspect DSRC-1 MD T003 UN02 Demonstrate DSRC-1 2a MD DOP 02 Inspect DSRC-1 F T003 UN02 Demonstrate Both - 1, 6 F Requirement Source SRI shall be designed to receive vehicle, and operator information from through vehicle OBU.2 SRI shall exchange vehicle, owner and operator information with appropriate state and federal systems (i.e.,from Aspen and Query Centralto iyeCitation). SRI shall receive vehicle safety performance data and designated vehicle, carrier and driver information from SRIcapable Roadside Unit (RSU) Equipment (RSE). Vehicle safety performance data and vehicle, carrier and driver information should be conformant to standards SAE J2735 and IEEE P1609. SRI shall receive size and weight information from SRI-capable Roadside Unit Equipment (RSERSU). Telemetry and sensor output data shall comply with SAE J2735. SRI shall send information received from external back office systems to SRI-capable Roadside Unit Equipment (RSE RSU). U.S. Department of Transportation Intelligent Transportation Systems Joint Program Office Smart Roadside Initiative – Final Report | 56 Chapter 7. Conclusions and Recommendations Req ID Requirement SRI data exchanges between external back office systems and RSEs shall be formatted for compliance with these systems. SRI shall access external, authoritative information sources in a manner that i.005 ensures all relevant information is reliable, secure, and up-to-date. SRI shall access and provide current i.005.1 information in real-time or as available from integrated data sources. SRI shall access from authoritative data i.005.2 sources the information necessary to validate vehicle size and weight information. SRI shall interface with truck parking i.006 systems. SRI shall provide designated collected data i.007 to back office external systems (systems TBD Aspen,iyeCitation). SRI shall receive designated data from back i.008 office external systems (systems TBD SAFER). SRI shall send data from sensors and the i.008.1 CAN BUS in SAE J2735 compliant format. SRI shall provide a driver interface that is i.009 compliant with driver safety regulations. SRI shall include trailing equipment i.010 identification pulled by uniquely identifiable CMV power units. SRI shall conform to SAE J1939 to support i.010.1 communications to/from CAN for tractor/trailer combinations. SRI information exchanges shall be compliant with appropriate communications protocols, such as SAE J2735, P1609 for DSRC, Cellular Digital Packet Data for i.011 CMRS, and XML/SOAP RESTful web services for cellular and Abstract Syntax Notation (ASN.1) for DSRC Ethernet connections. SRI shall facilitate the real-time exchange of i.012 truck parking information. SRI shall exchange receive data with i.012.1 parking systems to support truck parking functionality. 1 Colorado replaced by Maryland (MD) 2 OBU bluetooth to mobile app. i.004.1 Source Verification Method System Architecture Michigan and/or Maryland or Future Demonstration1 DOP 02 Inspect Both - 1, 6 F T004 Analyze Both - 2a, 2b MI, MD T004 Analyze All MI, MD T004 Inspect Both - 2a, 2b MI, MD T007 Demonstrate Both - 7 MI UN03 Demonstrate Both - 2b MI, MD UN04 Demonstrate Both - 2b MI, MD UN04 Inspect Both - 2a, 4 F UN07 Demonstrate Both - 4 MI, MD UN13 Inspect Both - 4 F DOP02 Demonstrate Both - 4 F DOP10 Inspect All MD UN011 Analyze Both - 7 MI UN04 Analyze Both - 7 MI U.S. Department of Transportation Intelligent Transportation Systems Joint Program Office Smart Roadside Initiative – Final Report | 57 Appendix B. Testing Results Unit and Integration Testing Table 6. Unit Testing Summary Item to Test Test Description • Write test app that posts to Test Date Responsibility Result 4/27/15 CB Pass 4/27/15 CB Pass 4/24/15 CB Pass 4/24/15 CB Pass 7/3/15 CB Pass 7/3/15 CB Pass web services • Verify posts get to web Mettler Toledo Ramp WIM services • Verify data is saved to • • • • Mettler Toledo Static Scale • • • • TSPS Application • • • • SAFER • • • Aspen LexusNexus iyeCitation • • • • database Verify that data can be retrieved via web services Verify that data is displayed to user interface Write test app that posts to web services Verify posts get to web services Verify data is saved to database Verify that data can be retrieved via web services Verify that data is displayed to user interface Write test app that performs an HTTP GET to TSPS web services Verify that data is returned Verify that data is displayed to user interface Write test app that performs an HTTP GET to web services Verify posts get to web services Verify data is saved to database Verify that data can be retrieved via web services Verify that data is displayed to user interface Write test app that pulls data from Aspen database interface Write test app that sends data to iyeCitation Verify that data is displayed to user U.S. Department of Transportation Intelligent Transportation Systems Joint Program Office Smart Roadside Initiative – Draft Final Report | 58 Appendix B. Testing Results Item to Test SRI User Interface (UI) Test Description • Write test app that • • SRI Mobile Truck Feed • • • • • • SRI Mobile Application • • • • • SRI Security • Test Date Responsibility Result 8/12/15 CB Pass 4/24/15 CB Pass 4/24/15 CB Pass 3/26/15 CB Pass encapsulates all other unit tests to verify integration Write test app that posts to web services Verify posts get to web services Verify data is saved to database Verify that data can be retrieved via web services Verify that data is displayed to user interface Write test page that posts to web services Verify posts get to web services Verify data is saved to database Verify that data can be retrieved via web services Verify that data is displayed to user interface Verify that application sends web service notification when vehicle enters geofence Verify SSL connection on secure sections (dashboard) Verify log-in page re-direct for non-authenticated requests to secure sections Verify valid user ID, password to establish authenticated session Table 7. Unit Testing Summary - Additional Maryland Elements (DSRC, LPR) Item to Test Arada on-board unit (OBU) and Roadside Unit (RSU) – DSRC Arada on-board unit and SRI Mobile Application - DSRC Test Description • Verify test programs for OBU and RSU (written by Arada) Test Date Responsibility Result 8/5/2015 JVC Pass 8/5/2015 JVC Pass • Verify SRI mobile application pairs to Arada OBU via Bluetooth Verify data is received by • Leidos server for translation (SRI J2735 Translator) • Verify posts get to web services • Verify that application sends web service notification when vehicle enters geofence U.S. Department of Transportation Intelligent Transportation Systems Joint Program Office Smart Roadside Initiative – Final Report | 59 Appendix B. Testing Results Item to Test Test Description • Write test app that watches LPR • ELSAG LPR • • • • directory for new image and text files Verify image and text files are being saved to LPR directory Verify posts get to web services Verify data is saved to database Verify that data can be retrieved via web services Verify that data is displayed to user interface Test Date Responsibility Result 8/17/2015 CB Pass Test Date 4/27/15 8/17/15 4/27/15 8/17/15 Responsibility CB – EGL CB - WFS CB – EGL CB - WFS Result 7/23/15 8/19/15 CB – EGL CB - WFS Pass 7/23/15 CB Pass 7/23/15 CB Pass 8/20/15 CB Pass 7/23/15 8/19/15 CB – EGL CB - WFS Pass 7/23/15 8/19/15 CB – EGL CB - WFS Pass Table 8. Integration Test Summary Item to Test Mettler-Toledo WIM • Verify receipt of web service Test Description Mettler-Toledo Static • • • SAFER • • • posts Verify receipt of web service posts Verify company snapshot servlet is returning valid company information Post company snapshot to web services Verify data is saved to database Verify that data can be retrieved via web services Verify that data is displayed to user interface Pull data from Aspen database Aspen • LexusNexus iyeCitation • Post data to iyeCitation • Verify data is displayed in SRI User Interface (UI) iyeCitation • Verify integration Pass Pass • Write test app that posts to web services • Verify posts get to web SRI Mobile Truck Feed services • Verify data is saved to • • SRI Mobile Application • • database Verify that data can be retrieved via web services Verify that data is displayed to user interface Write test page that posts to web services Verify posts get to web services U.S. Department of Transportation Intelligent Transportation Systems Joint Program Office Smart Roadside Initiative – Final Report | 60 Appendix B. Testing Results Item to Test Test Description • Verify data is saved to Test Date Responsibility 4/27/15 CB Result database • Verify that data can be retrieved via web services • Verify that data is displayed to user interface • Verify that application sends • • SRI Security • • TSPS Application SRI Mobile Application • • • web service notification when vehicle enters geofence Verify SSL connection on secure sections (dashboard) Verify log-in page re-direct for non-authenticated requests to secure sections Verify valid user ID, password to establish authenticated session Get data from TSPS web services Verify that data is returned Verify that data is displayed to user interface Verify pass/fail (green light/red light) displayed from MettlerToledo data 7/23/15 8/19/15 7/23/15 8/19/15 Pass CB – EGL CB - WFS Pass CB – EGL CB - WFS Pass Table 9. Integration Test Summary - Additional Maryland Elements (DSRC, LPR) Item to Test Arada on-board unit (OBU) and Roadside Unit (RSU) – DSRC Arada on-board unit and SRI Mobile Application – DSRC ELSAG LRP Test Description • Integration of SRI web service to OBU verified by Arada • Verify pass/fail (green light/red • • • • • light) displayed from MettlerToledo data Verify posts get to web services Verify data is saved to database Verify image files are saved to the web directory Verify that data can be retrieved via web services Verify that data is displayed to user interface Test Date Responsibility Result 8/20/2015 JVC Pass 8/20/2015 JVC Pass 8/20/15 CB Pass U.S. Department of Transportation Intelligent Transportation Systems Joint Program Office Smart Roadside Initiative – Final Report | 61 Appendix B. Testing Results B.1.2 Performance and Security Testing Table 10. Michigan Performance Test Results Req ID p.001 p.001.1 p.001.3 p.001.4 p.002 p.002.1 p.003 p.003.1 p.004 p.005 p.007.1 p.007.9 Requirement SRI shall provide current information in a timely fashion, or as available from integrated data sources, to meet SRI prototype application requirements. SRI shall be able to exchange data with external systems within 5 seconds, 99% of the time SRI shall be able to exchange data with CMV within 5 seconds, 99% of the time. SRI data exchanges shall be time stamped when the exchange was completed. SRI shall provide the capability to establish two-way communications with each properly equipped vehicle approaching the weigh station. SRI shall maintain two-way communications with each properly equipped vehicle as it passes through the weigh station. The SRI system shall be able to maintain an overall 99.99% in a 24hour period system availability. The SRI Prototype will log each system outage with the date, time, length (in minutes), and cause of the outage. SRI shall be able to communicate "Pass/Need to stop" instructions to a driver in time for compliance with the instruction. SRI shall be designed to accommodate multiple users with different user needs and requirements. SRI shall make a decision as to whether to allow each vehicle to pass or require them to stop for a check. SRI shall perform checks on Vehicle Weight Information when making the "Pass/Need To Stop" determination. Source Verification Method P001 Test Test Date Notes Test 8/17/15 External system = Mettler-Toledo Test 8/17/15 Rental car not CMV P002 Test 8/17/15 UN08 Demonstrate 8/17/15 UN08 Demonstrate 8/17/15 P002 UN05 UN11 P002 UN05 UN11 UN05 Inspect 8/17/15 There were some minimal outages (less than one minute) during times where system was being re-deployed P003 Inspect 8/17/15 Available in Glassfish App Server logs UN07 Test 8/17/15 P005 Demonstrate 8/17/15 UN010 Test 8/17/15 T006 Analyze 8/17/15 MD testing/install was being conducted concurrent with MI scenario testing. (Mettler-Toledo decision engine, with SRI interpretation of result data integrated from Mettler-Toledo U.S. Department of Transportation Intelligent Transportation Systems Joint Program Office Smart Roadside Initiative – Final Report | 62 Appendix B. Testing Results Table 11. Michigan Security Test Results Req ID s.001 s.002 s.003 Requirement SRI shall protect personal data from unauthorized access. SRI shall protect proprietary information from unauthorized access. SRI shall protect proprietary systems from unauthorized access. Source Verification Method Test Date Performed By UN06 Inspect 8/17/15 RS UN06 Inspect 8/17/15 RS UN06 Inspect 8/17/15 RS s.004 SRI shall provide read access and read/write access to authorized users. DOP09 Test 8/17/15 Write = entering USDOT number for SAFER lookup RS s.005 SRI shall provide read access and read/write access to authenticated users. DOP09 Test 8/17/15 RS U.S. Department of Transportation Intelligent Transportation Systems Joint Program Office Smart Roadside Initiative – Final Report | 63 Appendix B. Testing Results Table 12. Maryland Performance Testing Results Req ID p.001 p.001.1 p.001.2 p.001.3 Requirement SRI shall provide current information in a timely fashion, or as available from integrated data sources, to meet SRI prototype application requirements. SRI shall be able to exchange data with external systems within 5 seconds, 99% of the time SRI shall be able to exchange data with Roadside Equipment within 5 seconds, 99% of the time. SRI shall be able to exchange data with CMV within 5 seconds, 99% of the time. SRI data exchanges shall be time stamped when the exchange was completed. SRI shall provide the capability to establish two-way communications with each p.002 properly equipped vehicle approaching the weigh station. SRI shall maintain two-way communications p.002.1 with each properly equipped vehicle as it passes through the weigh station. The SRI system shall be able to maintain p.003 an overall 99.99% in a 24- hour period system availability. The SRI Prototype will log each system p.003.1 outage with the date, time, length (in minutes), and cause of the outage. SRI shall be able to communicate p.004 "Pass/Need to stop" instructions to a driver in time for compliance with the instruction. p.001.4 p.005 SRI shall be designed to accommodate multiple users with different user needs and requirements. Source Verification Method Test Date Performed By P001 Test 8/21/15 CB, JC, RS Test 8/21/15 CB, JC, RS Test 8/21/15 CB, JC, RS Test 8/21/15 CB, JC, RS P002 Test 8/21/15 CB, JC, RS UN08 Demonstrate 8/21/15 CB, JC, RS UN08 Demonstrate 8/21/15 CB, JC, RS UN05 Inspect 8/21/15 CB, JC, RS P003 Inspect 8/21/15 CB, JC, RS UN07 Test 8/21/15 CB, JC, RS 8/21/15 CB, JC, RS (see MI explanation – had system open via multiple devices by multiple users in multiple locations) P002 UN05 UN11 P002 UN05 UN11 P002 UN05 UN11 P005 Demonstrate U.S. Department of Transportation Intelligent Transportation Systems Joint Program Office Smart Roadside Initiative – Final Report | 64 Appendix B. Testing Results Req ID p.007.1 p.007.6 Requirement SRI shall make a decision as to whether to allow each vehicle to pass or require them to stop for a check. SRI shall perform checks on Vehicle/Carrier/Driver Safety Information when making the "Pass/Need To Stop" determination. Source Verification Method Test Date Performed By UN010 Test 8/21/15 CB, JC, RS T002 Analyze NO Only weight was checked and verified Only weight was checked and verified p.007.7 SRI shall perform checks on Vehicle Credentials when making the "Pass/Need To Stop" determination. T002 Analyze NO p.007.9 SRI shall perform checks on Vehicle Weight Information when making the "Pass/Need To Stop" determination. T006 Analyze 8/21/15 CB, JC, RS Table 13. Maryland Security Test Results Req ID s.001 s.002 s.003 s.004 s.005 Requirement SRI shall protect personal data from unauthorized access. SRI shall protect proprietary information from unauthorized access. SRI shall protect proprietary systems from unauthorized access. SRI shall provide read access and read/write access to authorized users. SRI shall provide read access and read/write access to authenticated users. Source Verification Method Test Date Performed By UN06 Inspect 8/21/15 CB, JC, RS UN06 Inspect 8/21/15 CB, JC, RS UN06 Inspect 8/21/15 CB, JC, RS DOP09 Test 8/21/15 CB, JC, RS DOP09 Test 8/21/15 CB, JC, RS U.S. Department of Transportation Intelligent Transportation Systems Joint Program Office Smart Roadside Initiative – Final Report | 65 Appendix B. Testing Results B.1.3 System and Acceptance Testing Table 14. Michigan System Testing Items Item to Test Compliant CMV – Internet and Cellular Communications “Green Light” Compliant CMV – Internet and Cellular Communications “Red Light” Compliant CMV – Internet and Cellular Communications “Red Light” and Illegal Bypass Data Exchange between ASPEN and iyeCitation Real-Time Truck Parking Information System Enforcement officer smart phone scenario Test Description CMV passes over a WIM ramp and receives a “green light” indicating no further weight verification check is required. CMV passes over a WIM ramp and receives a “red light” indicating WIM weight thresholds were exceeded. The CMV then proceeds to a static scale for additional weight verification. CMV passes over a WIM ramp and receives a “red light” indicating additional weight verification is required. The CMV does not proceed to a static scale but ignores the signal and returns to the mainline. An enforcement officer determines that a CMV will be given an overweight citation. The officer accesses the SRI UI and Prototype System which pulls the ASPEN report generated for the weight violation and pushes common data elements to iyeCitation. A CMV driver uses a Smartphone to access the SRI mobile application and generate a geo-coded message seeking information on truck parking facility locations and availability. A third party service provider generates a return message identifying locations and availability to the SRI mobile application. An enforcement officer is located outside of the weigh station (in his patrol vehicle) and uses his Smartphone to access the SRI user interface. He is able to screen vehicles that have passed through the weigh station as he would if he were using the user interface on a desktop computer. Test Date 8/17/15 Responsibility RS 8/18/15 12:09 p.m. RS and M. Brown (MSP) DID NOT TEST Cannot simulate without participating CMV 8/17/15 M. Brown (MSP) 8/17/15 RS 8/17/15 RS and M. Brown (MSP) U.S. Department of Transportation Intelligent Transportation Systems Joint Program Office Smart Roadside Initiative – Final Report | 66 Appendix B. Testing Results Table 15. Michigan System Test Criteria Req ID e.001 e.003 e.004 e.005 e.007 e.008 e.009 e.012 e.013 e.014 Requirement SRI shall be designed to operate in conjunction with and not interfere with existing systems. SRI shall monitor external system availability. Source UN14 Verification Method Inspect Test Date 8/17/15 DOP01 Inspect 8/17/15 SRI shall provide continuous system health availability information.(dependent on weigh station hours of operation – may need to delete The SRI Prototype System shall be deployed and tested at a fixed facility on the Interstate System. The SRI prototype shall use the USDOT number as the unique identifier for the carrier. The SRI prototype shall use the VIN number as the unique identifier for the CMV. The SRI prototype shall use the CDL number as the unique identifier for the CMV driver. SRI shall collect, store, and provide real-time on-line interactive access to historical vehicle, driver and carrier safety data at the weigh station. (for security reasons, information stored by SRI will be discarded after 23 hours. SRI shall provide capability to securely log the passing of each vehicle, the information passed to the roadside system, and the information passed back to the vehicle from the roadside system. SRI shall provide an interface to all commercial drivers that is compliant with existing safety regulations. DOP01 Inspect 8/17/15 DOP03 Demonstrate 8/17/15 RS, If external systems are unavailable, SRI does not show any information. RS, e.003 was met. Check on Glassfish notification RS DOP04 Inspect 8/17/15 RS DOP04 Inspect 8/17/15 RS DOP04 UN12 UN 08 Inspect 8/17/15 RS Demonstrate 8/17/15 RS UN 08 Inspect 8/17/15 RS DOC01 Demonstrate 8/17/15 RS (rental car only – no participating CMV drivers in MI) Performed By RS U.S. Department of Transportation Intelligent Transportation Systems Joint Program Office Smart Roadside Initiative – Final Report | 67 Appendix B. Testing Results Table 16. Michigan System Test Criteria – Application Requirements (a) Req ID a.001 a.002 a.002.1 a.002.2 a.002.4 a.002.5 Requirement SRI shall be consistent with the ITS National Architecture and associated standards such as the CVISN National Architecture. SRI shall provide an interface and processing modules for truck parking applications. SRI shall provide information about the availability of truck parking spaces. SRI shall provide current parking availability information at a specific facility. SRI shall provide 24x7 access to truck parking information (depending on availability of TSPS application SRI shall provide a graphical interface to stationary (i.e., dispatcher/operator/driver/traffic analyst/other) users. Source Verification Method Test Date Performed By UN08 Analyze TBD UN10 Demonstrate 8/17/15 RS UN10 Demonstrate 8/14/15 RS UN10 Demonstrate 8/14/15 RS UN10 Demonstrate 8/17/15 RS UN05 Demonstrate 8/17/15 RS RS (not verified as this action is conducted within the TSPS application) RS (not verified as this action is conducted within the TSPS application) a.002.7 SRI shall allow a stationary user to submit requests for automated truck parking information. UN05 Demonstrate 8/14/15 a.002.8 SRI shall allow a user to receive the results of an automated request for truck parking information. UN05 Demonstrate 8/14/15 UN10 Demonstrate 8/17/15 RS UN09 Analyze 8/17/15 RS UN10 Analyze 8/17/15 RS UN10 Demonstrate 8/17/15 SRI shall provide an interface for CMV Enforcement Officers and supervisors to enter data. UN10 Demonstrate 8/17/15 SRI shall provide an interface for CMV Enforcement Officers and supervisors to execute processes. UN10 Demonstrate 8/17/15 RS RS (USDOT number manually enteres for SAFER lookup) RS and M. Brown with MSP (Aspen to iyeCitation integration) a.003 a.003.1 a.004.8 a.005 a.005.1 a.005.2 SRI shall provide an interface and processing modules for enforcement screening applications. SRI shall provide the ability for roadside systems to integrate roadside systems data and make it available to Roadside System SRI user applications. SRI shall provide the data necessary to document inspection events and outcomes. SRI shall provide an interface for Tier 1 users. U.S. Department of Transportation Intelligent Transportation Systems Joint Program Office Smart Roadside Initiative – Final Report | 68 Appendix B. Testing Results Req ID a.005.3 a.005.4 Requirement SRI shall provide an interface for CMV Enforcement Officers and supervisors to receive information and alerts. SRI shall provide an interface for CMV drivers to receive information. Source UN10 Verification Method Demonstrate Test Date 8/17/15 Performed By RS UN10 Demonstrate 8/17/15 RS (no participating drivers in MI, simulated with rental car/ test smart phone) Table 17. Michigan System Test Criteria – Interface Requirements (i) Req ID i.001.1 i.005 i.005.1 i.005.2 i.006 i.007 i.008 i.009 i.012 i.012.1 Requirement SRI shall exchange vehicle, owner and operator information from Aspen to iyeCitation). SRI shall access external, authoritative information sources in a manner that ensures all relevant information is reliable, secure, and up-to-date. SRI shall access and provide current information in real-time or as available from integrated data sources. SRI shall access from authoritative data sources the information necessary to validate vehicle weight information. SRI shall interface with truck parking systems. SRI shall provide designated collected data to back office external systems (Aspen,iyeCitation). SRI shall receive designated data from back office external systems (SAFER). SRI shall provide a driver interface that is compliant with driver safety regulations. SRI shall facilitate the real-time exchange of truck parking information. SRI shall receive data with parking systems to support truck parking functionality. Source Verification Method Test Date Performed By DOP 02 Analyze 8/17/15 RS and M. Brown, MSP T004 Analyze 8/17/15 RS T004 Analyze 8/17/15 RS (MettlerToledo, Aspen, SAFER iyeTech) T004 Inspect 8/17/15 RS (MettlerToledo) T007 Demonstrate 8/17/15 UN03 Demonstrate 8/17/15 UN04 Demonstrate 8/17/15 RS UN07 Demonstrate 8/17/15 RS UN011 Analyze 8/14/15 RS UN04 Analyze 8/14/15 RS RS (TSPS) RS and M.Brown (MSP) U.S. Department of Transportation Intelligent Transportation Systems Joint Program Office Smart Roadside Initiative – Final Report | 69 Appendix B. Testing Results Table 18. Maryland System Test Items Item to Test Test Description Test Date Compliant CMV – Internet and Cellular Communications “Green Light” CMV passes over a WIM ramp and receives a “green light” indicating no further weight verification check is required. 8/21/15 Compliant CMV – Internet and Cellular Communications “Red Light” CMV passes over a WIM ramp and receives a “red light” indicating WIM weight thresholds were exceeded. The CMV then proceeds to a static scale for additional weight verification. 8/21/15 Compliant CMV – Internet and Cellular Communications “Red Light” and Illegal Bypass Compliant CMV – DSRC “Green Light” Non-Compliant CMV – DSRC “Red Light” Non-Compliant CMV – DSRC “Red Light” and Illegal Bypass Enforcement officer smart phone scenario CMV passes over a WIM ramp and receives a “red light” indicating additional weight verification is required. The CMV does not proceed to a static scale but ignores the signal and returns to the mainline. CMV passes over a WIM ramp and receives a “green light” indicating no additional weight verification check is required. CMV passes over a WIM ramp and receives a “red light” indicating WIM weight thresholds were exceeded. The CMV then proceeds to a static scale for additional weight verification. CMV passes over a WIM ramp and receives a “red light” indicating additional weight verification is required. The CMV does not proceed to a static scale but ignores the signal and returns to the mainline. An enforcement officer is located outside of the weigh station (in his patrol vehicle) and uses his Smartphone to access the SRI user interface. He is able to screen vehicles that have passed through the weigh station as he would if he were using the user interface on a desktop computer. NO 8/21/15 Responsibility CB, JC, RS (tested both via rental vehicle and USDOT commercial vehicle ‘Silver’) CB, JC, RS (tested both via rental vehicle and USDOT commercial vehicle ‘Silver’) Could not simulate this with USDOT commercial vehicle CB, JC, RS (tested in rental vehicle) 8/21/15 CB, JC, RS (tested in rental vehicle) No Could not simulate this with USDOT commercial vehicle 8/21/15 CB, JC, RS U.S. Department of Transportation Intelligent Transportation Systems Joint Program Office Smart Roadside Initiative – Final Report | 70 Appendix B. Testing Results Table 19. Maryand System Test Criteria Req ID e.001 e.002 e.003 e.004 e.005 e.007 e.008 e.009 e.012 e.013 e.014 Requirement SRI shall be designed to operate in conjunction with and not interfere with existing systems. SRI shall monitor roadside equipment. SRI shall monitor external system availability. SRI shall provide continuous system health availability information.(dependent on weigh station hours of operation The SRI Prototype System shall be deployed and tested at a fixed facility on the Interstate System. The SRI prototype shall use the USDOT number as the unique identifier for the carrier. The SRI prototype shall use the VIN number as the unique identifier for the CMV. The SRI prototype shall use the CDL number as the unique identifier for the CMV driver. SRI shall collect, store, and provide real-time on-line interactive access to historical vehicle, driver and carrier safety data at the weigh station. (for security reasons, information stored by SRI will be discarded after 23 hours. SRI shall provide capability to securely log the passing of each vehicle, the information passed to the roadside system, and the information passed back to the vehicle from the roadside system. SRI shall provide an interface to all commercial drivers that is compliant with existing safety regulations. Source Verification Method Test Date Performed By UN14 Inspect 8/21/15 CB, JC, RS DOP01 DOP01 Inspect inspect 8/21/15 8/21/15 DOP01 Inspect TBD CB, JC, RS CB, JC, RS Check available Glassfish logs DOP03 Demonstrate 8/21/15 CB, JC, RS DOP04 Inspect 8/21/15 CB, JC, RS DOP04 Inspect 8/21/15 CB, JC, RS DOP04 UN12 Inspect 8/21/15 CB, JC, RS UN 08 Demonstrate 8/21/15 CB, JC, RS UN 08 Inspect 8/21/15 CB, JC, RS DOC01 Demonstrate 8/21/15 CB, JC, RS U.S. Department of Transportation Intelligent Transportation Systems Joint Program Office Smart Roadside Initiative – Final Report | 71 Appendix B. Testing Results Table 20. Maryand System Test Criteria - Application Requirements (a) Req ID a.001 a.003 a.003.1 a.004.8 a.005 Requirement SRI shall be consistent with the ITS National Architecture and associated standards such as the CVISN National Architecture. SRI shall provide an interface and processing modules for enforcement screening applications. SRI shall provide the ability for roadside systems to integrate roadside systems data and make it available to Roadside System SRI user applications. SRI shall provide the data necessary to document inspection events and outcomes. SRI shall provide an interface for Tier 1 users. Source Verification Method Test Date Performed By UN08 Analyze UN10 Demonstrate 8/21/15 CB, JC, RS (Mettler Toledo) UN09 Demonstrate 8/21/15 CB, JC, RS (LPR) UN10 Demonstrate 8/21/15 CB, JC, RS UN10 Demonstrate 8/21/15 CB, JC, RS CB, JC, RS (USDOT number manually entered for SAFER lookup) Michigan only – did not integrate to an electronic ticketing system in MD CB a.005.1 SRI shall provide an interface for CMV Enforcement Officers and supervisors to enter data. UN10 Demonstrate 8/21/15 a.005.2 SRI shall provide an interface for CMV Enforcement Officers and supervisors to execute processes. UN10 Demonstrate NO UN10 Demonstrate 8/21/15 CB, JC, RS UN10 Demonstrate 8/21/15 CB, JC, RS DOP06 UN014 Inspect 8/21/15 CB, JC, RS a.005.3 a.005.4 a.007 SRI shall provide an interface for CMV Enforcement Officers and supervisors to receive information and alerts. SRI shall provide an interface for CMV drivers to receive information. SRI shall comply with nationwide interoperability standards currently used for the USDOT V2X Program. a.007.1 SRI shall comply with SAE STD J2735. DOP06 UN014 Inspect 8/21/15 JC a.007.2 SRI shall comply with the relevant sections of IEEE 1609 (including Architecture, Resource Manager, Security Services, Networking Services, Multi-Channel Operations, over-theair data exchange protocol for ITS) and the version updates available at the time of design. DOP06 UN014 Inspect 8/21/15 JC (Arada) a.007.4 SRI shall comply with IEEE Standard 802.11p. DOP06 UN014 Inspect 8/21/15 JC 1 To be verified with Arada U.S. Department of Transportation Intelligent Transportation Systems Joint Program Office Smart Roadside Initiative – Final Report | 72 Appendix B. Testing Results Table 21. Maryand System Test Criteria - Interface Requirements (i) Req ID i.001 i.002.1 i.003 Requirement SRI shall be designed to receive vehicle, and operator information through vehicle OBU (OBU Bluetooth to mobile application for presentation to driver) Vehicle information should be conformant to standards SAE J2735 and IEEE P1609. SRI shall receive weight information from SRIcapable Roadside Unit, RSU). Verification Method Test Date Performed By T001 UN01 UN02 Demonstrate 8/21/15 JC (in rental car only1) DOP 02 Inspect 8/21/15 T003 UN02 Demonstrate 8/21/15 Source JC (in rental car only) JC (in rental car only) – weight information is only received by the SRI UI from MettlerToledo. SRI RSU provides pass/fail results to OBU. i.005 SRI shall access external, authoritative information sources in a manner that ensures T004 Analyze 8/21/15 CB, JC, RS all relevant information is reliable, secure, and up-to-date. i.005.1 SRI shall access and provide current T004 Analyze 8/21/15 CB, JC, RS information in real-time or as available from integrated data sources. i.005.2 SRI shall access from authoritative data T004 Inspect 8/21/15 CB, JC, RS sources the information necessary to validate vehicle weight information. i.007 SRI shall provide designated collected data to Michigan back office external systems UN03 Demonstrate NO only (Aspen,eyiyeCitation). i.008 SRI shall receive designated data from back UN04 Demonstrate 8/21/15 CB, JC, RS office external systems (SAFER). i.009 SRI shall provide a driver interface that is UN07 Demonstrate 8/21/15 CB, JC, RS compliant with driver safety regulations. i.011 SRI information exchanges shall be compliant with appropriate communications protocols, such as SAE J2735, P1609 for DSRC, DOP10 Inspect 8/21/15 CB, JC, RS RESTful web services for cellular and Abstract Syntax Notation (ASN.1) for DSRC. 1 This initial testing took place at Turner-Fairbank Highway Research Center in a rental car. Testing with the SRI truck was not completely successful. U.S. Department of Transportation Intelligent Transportation Systems Joint Program Office Smart Roadside Initiative – Final Report | 73 Appendix B. Testing Results Table 22. Michigan Acceptance Test Items - Driver Item to Test Test Description Enter information into mobile application • • • • • License number x VIN # x USDOT # x License Plate # x Photo (optional) x Receive weigh station instruction via red light/green light • Please follow roadside signs • Red light (pull in) • Green light (bypass) View truck parking information (MICHIGAN only) • Truck parking application (TSPS) automatically launches when exiting a defined geofence Test Date DSRC Communication Cellular Communication Weigh station Access Mobile Access Responsibility 8/17/15 - RS N/A N/A - 8/17/15 - RS N/A N/A - N/A Issues noted on 8/17 with only three locations appearing regardless of direction traveled 8/17/15 - RS N/A Table 23. Michigan Acceptance Test Items – Enforcement Officer Item to Test Successful log-in to SRI user interface Mettler- Toledo Ramp WIM data is presented on SRI UI Mettler-Toledo static scale data is presented on SRI UI • User credentials are entered and accepted by the SRI UI and the application launches Test Date DSRC Communication Cellular Communication Weigh station Access Mobile Access Responsibility 8/17/15 - RS yes yes - • Captured Time, Gross Weight, Axles, Status, Sequence Number, Reason. 8/17/15 - RS yes yes - yes Issue noted on 8/17/15 that was resolved on 8/18: if user selected finish, park or print on MT interface, information was not populating SRI UI in the WS Test Description • Captured Time, Gross Weight, Axles, Status, Sequence Number, Reason. 8/17/15 - RS yes U.S. Department of Transportation Intelligent Transportation Systems Joint Program Office Smart Roadside Initiative – Final Report | 74 Appendix B. Testing Results Item to Test Data from SRI mobile application is presented on SRI UI Select a truck from the truck feed and view complete data available USDOT number can be entered on SRI UI SAFER Company Data module populates if USDOT number is available from the SRI mobile application SAFER Company Data module populates if user enters USDOT number Test Date DSRC Communication Cellular Communication Weigh station Access Mobile Access Responsibility 8/17/15 - RS yes yes - • Yes or no 8/17/15 - RS yes yes - • Yes or no 8/17/15 - RS yes yes - 8/17/15 - RS yes yes - 8/17/15 - RS yes yes - Test Description • • • • • License number x VIN # x USDOT # x License Plate # x Photo (optional) x • Company Name, DBA Name, Physical Address, Mailing Address, Status, US DOT Number, MC/MX, MCS 150, MCS 150 Mileage, Phone, Email, DOT Status, Entity Type, Power Units • Company Name, DBA Name, Physical Address, Mailing Address, Status, US DOT Number, MC/MX, MCS 150, MCS 150 Mileage, Phone, Email, DOT Status, Entity Type, Power Units US Crash data from SAFER • Fatal, Injury, Tow, Total 8/17/15 - RS yes yes SAFER US Safety Rating is presented • Review Date, Rating Date, Type, Rating 8/17/15 - RS yes yes SAFER US Inspections is presented • Driver, Hazardous Materials, Intermodal Equipment Provider, Vehicle 8/17/15 - RS yes yes Not within a separate module – separate box within SRI UI Not within a separate module – separate box within SRI UI Not within a separate module – separate box within SRI UI U.S. Department of Transportation Intelligent Transportation Systems Joint Program Office Smart Roadside Initiative – Draft Final Report | 75 Appendix B. Testing Results Table 24. Michigan Acceptance Test Items – Michigan Only Item to Test Launch MiCJIN portal from SRI UI (MICHIGAN only) Log in to MICJIN portal when accessed from SRI UI When executed, iyeCitation electronic ticket is prepopulated with saved Aspen data (MICHIGAN only) Test Date DSRC Communication Cellular Communication Weigh station Access Mobile Access Responsibility 8/17/15 - RS and M.Brown (MSP) yes - - - No MI VPN available on SRI laptop at WS. - Separate computer was used for this test (not the laptop running SRI UI) due to security. Test Description • Portal successfully opens and log-in screen appears • Log in credentials can be entered, and credentials are accepted • Electronic ticket in iyeCitation opens with draggable modules pre-populated from Aspen • For Vehicle - License Plate #, Plate State, Make, Type, Vehicle Year • For Driver – First Name, Last Name, Driver’s License #, Driver’s License State 8/17/15 8/17/15 - - - no - yes Table 25. Maryland Acceptance Test Items - Driver Item to Test Test Description Enter information into mobile application • • • • • License number VIN # USDOT # License Plate # Photo (optional) Receive weigh station instruction via red light/green light • Please follow roadside signs • Red light (pull in) • Green light (bypass) Test Date 8/21/15 8/21/15 DSRC Communication • License number x • VIN # x • USDOT # x • License Plate #x Rental car only not CMV Cellular Communication • License number x • VIN # x • USDOT # x • License Plate #x • Photo (optional) x Type of access Responsibility N/A RS, CB, JC yes N/A RS, CB, JC U.S. Department of Transportation Intelligent Transportation Systems Joint Program Office Smart Roadside Initiative – Final Report | 76 Appendix B. Testing Results Table 26. Maryland Acceptance Test Items – Enforcement Officer Test Description Test Date DSRC Communication Cellular Communication Weigh station Access Mobile Access Responsibility • User credentials are entered and accepted by the SRI UI and the application launches 8/21/15 - yes yes yes RS, CB, JC • Captured Time, Gross Weight, Axles, Status, Sequence Number, Reason. 8/21/15 - yes yes yes RS, CB, JC • Captured Time, Gross Weight, Axles, Status, Sequence Number, Reason. 8/21/15 - yes yes yes RS, CB, JC • • • • • 8/21/15 - yes yes yes RS, CB, JC • Yes or no 8/21/15 - yes yes yes RS, CB, JC • Yes or no 8/21/15 - yes yes yes RS, CB, JC 8/21/15 - yes yes yes RS, CB, JC 8/21/15 - yes yes yes RS, CB, JC Item to Test Successful log-in to SRI user interface Mettler- Toledo Ramp WIM data is presented on SRI UI Mettler-Toledo static scale data is presented on SRI UI Data from SRI mobile application is presented on SRI UI Select a truck from the truck feed and view complete data available USDOT number can be entered on SRI UI SAFER Company Data module populates if USDOT number is available from the SRI mobile application SAFER Company Data module populates if user enters USDOT number License number VIN # USDOT # License Plate # Photo (optional) • Company Name, DBA Name, Physical Address, Mailing Address, Status, US DOT Number, MC/MX, MCS 150, MCS 150 Mileage, Phone, Email, DOT Status, Entity Type, Power Units • Company Name, DBA Name, Physical Address, Mailing Address, Status, US DOT Number, MC/MX, MCS 150, MCS 150 Mileage, Phone, Email, DOT Status, Entity Type, Power Units U.S. Department of Transportation Intelligent Transportation Systems Joint Program Office Smart Roadside Initiative – Final Report | 77 Appendix B. Testing Results Item to Test SAFER US Crash data from SAFER is presented within a separate module SAFER US Safety Rating is presented within a separate module SAFER US Inspections is presented within a separate module Test Date DSRC Communication Cellular Communication Weigh station Access Mobile Access Responsibility • Fatal, Injury, Tow, Total 8/21/15 - yes yes yes RS, CB, JC • Review Date, Rating Date, Type, Rating 8/21/15 - Yes yes yes RS, CB, JC • Driver, Hazardous Materials, Intermodal Equipment Provider, Vehicle 8/21/15 - yes Yes yes RS, CB, JC Test Description Table 27. Maryland Acceptance Test Items – Maryland Only Item to Test LPR window appears in SRI UI LPR data appears in SRI UI Test Description • Photo • License plate number • Date/Timestamp Test Date DSRC Communication Cellular Communication Weigh station Access Mobile Access Responsibility 8/21/15 - yes yes yes RS, CB, JC 8/21/15 - yes yes yes RS, CB, JC U.S. Department of Transportation Intelligent Transportation Systems Joint Program Office Smart Roadside Initiative – Final Report | 78 U.S. Department of Transportation ITS Joint Program Office-HOIT 1200 New Jersey Avenue, SE Washington, DC 20590 Toll-Free “Help Line” 866-367-7487 www.its.dot.gov FHWA-JPO-16-258