Naturalistic Driving Study: Technical Coordination and Quality Control (2014)

Below is the uncorrected machine-read text of this chapter, intended to provide our own search engines and external engines with highly rich, chapter-representative searchable text of each book. Because it is UNCORRECTED material, please consider the following text as a useful but insufficient proxy for the authoritative book pages.

22 C h a p t e r 2 human Subjects protections In the United States, the use of humans in research is covered by the Code of Federal Regulations (45 CFR 46). These regula- tions nominally apply to the Department of Health and Human Services, but several other departments and agencies have adopted the same regulations through a mechanism known as the Common Rule. The U.S. Department of Transportation is among those departments adopting the Common Rule. The backbone of 45 CFR 46 is the concept of informed consent, namely that participants must be informed of study details including protocols, risks, benefits, and the steps taken to ensure confidentiality of participant data. Participants must also be informed that their participation is volun- tary and that they may discontinue it at any time for any reason. Special protections are required for minors (chil- dren) who participate in research. Minors typically provide assent, as they are legally incapable of providing consent. Thus, in addition to the minor’s assent, his or her parent or legal guardian must also provide consent before the minor is allowed to participate. Summarizing, study personnel must obtain informed consent from each participant before enrolling him or her into the study. In the U.S., human sub- jects research is reviewed by Institutional Review Boards as described below. All human subjects research conducted under the SHRP 2 NDS projects was reviewed by several IRBs to ensure compli- ance with 45 CFR 46. After the site contractors were selected, a meeting was held at the Keck Center in Washington, D.C., on July 9, 2009, with IRB representatives from all sites invited (eight IRBs were represented at this meeting, including the Virginia Tech and NAS IRBs). All attendees had access to a draft consent form before the meeting. This form was nearly identical to one used in a pilot study conducted during the study design phase of the SHRP 2 NDS. The meeting began with a SHRP 2 NDS overview, followed by a VTTI overview of previous naturalistic driving studies and the IRB/human subjects issues encountered in those studies. This meeting resulted in several conclusions and recommendations: • The consent form was missing information and should be expanded. 44 Every person who reviewed the form added information but did not delete an equal amount of information from other areas. • The consent form was too long and should be simplified and shortened. Due to the inherent conflict with the first point, the group then came to consensus on the following recommendations: 44 An abbreviated information sheet should be prepared to highlight the key points of the consent form. 44 A brief video should be created to explain the key points of the study and of the consent form. 44 All consent materials (including the video and informa- tion sheet) should be available for review on the SHRP 2 Participant Portal website before the participant goes in for formal enrollment. 44 A frequently-asked-questions (FAQ) format should be used to organize the consent forms. • A consistent policy should be developed for handling data obtained from unconsented drivers of study vehicles. • A method should be developed for communicating con- cerns, issues, adverse events, and complaints across sites to SHRP 2 staff and Coordination Contractor staff in a timely fashion. • Consent forms should be as consistent as possible across sites, differing only in site-specific information and, as nec- essary, due to site-specific IRB requirements. • Participants should be strongly warned against crossing international borders (and other places where cameras are not allowed) in the study vehicle. • Site IRBs should have the option of signing a letter of reliance with the Virginia Tech IRB. 44 The Virginia Tech IRB agreed to this arrangement. Study Preparations

23 provided explicit permission for data to be captured whenever the vehicle was driven. Primary driver participants underwent a full suite of driver functional assessments, provided permis- sion for their identifiable and deidentified data to be used for research purposes, and were compensated for their partici- pation in the study. Either the primary driver or the vehicle’s owner/lessee (where these were different individuals) could independently withdraw the vehicle from the study. Secondary drivers were those who regularly drove the instru- mented vehicle of a primary driver. They were initially informed about the study by the primary driver and were given the opportunity to have their identifiable data included in the database by going through a consent process and filling in the demographic survey and driving history question- naire. These drivers received a small amount of compensa- tion for their role in the study. A waiver of consent was granted by the IRBs such that the DAS could collect data whenever the vehicle was driven, with the understanding that data collected from unconsented drivers would be expunged from the data set as soon as it was definitively determined that the driver within a particu- lar trip file was neither a consented primary nor a consented secondary driver. While secondary drivers or other nonconsented drivers could not withdraw the vehicle from the study, every effort was made to design the study so that others who drove the vehicle on a regular basis were neither encouraged nor discouraged from granting consent. They were merely given the opportunity to do so. Site-Specific Informed Consent The initial study design called for participants to enroll for either 1 or 2 years. The initially intended enrollment period was later made more flexible, allowing participants more enroll- ment period options and the opportunity to extend current enrollment periods beyond their originally planned dates of exit. With the two study enrollment periods, six sites, and four types of consent/assent/permission forms (i.e., adult primary participants, adult secondary participants, minor primary par- ticipants, and parental permission), there were initially 48 forms to review and reconcile, each 15–16 pages in length. The goal was to have the forms be identical except for site-specific infor- mation (local phone numbers, local principal investigator (PI), and IRB names and contact information). VTTI IRB personnel conducted a consistency check for each amendment across all forms. After the forms were reconciled and approved by the var- ious IRBs, they were saved in PDF format with a watermark to prevent tampering and placed on the SHRP 2 NDS Participant Portal website. Appendices J and K include the final consent forms related to primary drivers and secondary drivers, respec- tively. The Buffalo site is used in each example. The next several months were spent ironing out the details of the consent forms, research protocol, policies, and proce- dures to the satisfaction of the various IRBs. The Erie County, New York (CUBRC), and Durham, North Carolina (Westat), sites agreed to formally rely on the Virginia Tech IRB, while the other sites decided to retain local IRB control. The NAS IRB also decided that it would need to review all materials and amendments and to provide continuing review on an annual basis. The protocol underwent full board review at all sites due to the study’s high profile (given the thousands of participants located across the United States) and the plan to include minors. Materials were initially submitted to the Virginia Tech IRB on February 23, 2009, and went through three rounds of full board review before being granted approval on May 6, 2010. The approved materials were then sent to the NAS IRB and to the four site IRBs not relying on the Virginia Tech IRB. These submissions resulted in additional requests for changes, which resulted in four amendments to the Virginia Tech IRB protocol before any of the other four sites granted approval. These amendments were concerned with clarifying the pro- cesses by which secondary drivers would be recruited, specify- ing that data from unconsented drivers would be expunged, and modifying the Certificate of Confidentiality language per request from the National Institute of Mental Health (NIMH), as discussed further below. By October 14, 2010, the NAS and Virginia Tech IRBs had granted study approval, and NIMH had granted the Certificate of Confidentiality, thus allow- ing installations to begin at the Erie County, New York, and Durham, North Carolina, sites. The other four sites continued to respond to their IRBs’ concerns, resulting in an additional two amendments before all sites had approval (all sites were approved and recruiting participants by June 2011). These additional amendments clarified the withdrawal/dismissal protocol, expanded recruit- ment methods, allowed semiannual drawings for prizes for all enrolled participants (disallowed by the Seattle, Washington, site due to conflict with state law), and created a mechanism for including leased vehicles in the study. Categories of Participants Two types of participants were identified. Primary drivers were the main focus of the study. They (or, in the case of minors, their parents) owned, co-owned, or leased the vehicle to be instrumented, and they provided explicit permission for data to be captured whenever the vehicle was driven. Alternatively, if the primary participant did not own the vehicle to be instru- mented, he or she must have been the primary driver of that vehicle and have obtained the written permission of the vehi- cle’s owner or lessee. In this case, it was the vehicle owner who

24 research subject. The certificate covers the collection of sensi- tive research information for a defined time period; however, the personally identifiable information obtained about sub- jects enrolled while the certificate is in effect is protected in perpetuity. Compensation Scheme The initial compensation scheme was as follows (several mod- ifications to this scheme were implemented in later amend- ments, which are listed within the relevant consent/assent forms in Appendices J, K, and N with final compensation schemes described in later chapters of this report): • Primary drivers enrolled for 1 year were compensated at $300 per year, paid in three installments (increased to $500 per year beginning summer 2011). • Primary drivers enrolled for 2 years were compensated at $300 per year, $600 total (increased to $500 per year, $1,000 total beginning summer 2011). • Secondary drivers initially received no compensation. DaS Design and procurement The DAS design specifications were set forth as part of the Study Design project. During the final design phase, the selec- tion process for a contract manufacturer (CM) to build the printed circuit boards (PCBs) and carry out final assembly began. A parallel effort began to select vendors to manufacture the custom cables and custom plastics (primarily enclosures and mounts). Integrated system components such as cameras and the radar were purchased separately, as necessitated by design details. Design of the DAS The system-level design was done by the Coordination Con- tractor based on the specifications outlined in the Study Design project, as there was not a suitable off-the-shelf data collection system available. To comply with the requirements for the cat- egories of in-vehicle performance, ease of handling, and ease of installation, the DAS for the SHRP 2 NDS was a comprehensive custom design. The initial process included the following steps: • Develop a list of data elements to be collected in the SHRP 2 NDS, which minimally included 44 Multiple video views: 4▪ Forward roadway, driver’s face and upper torso, driver interactions with wheel and center stack, and the rear and right of the vehicle; 44 Occasional still photos of cabin (permanently blurred); Informed Consent Video As part of the site preparations, the Coordination Contrac- tor developed a brief video discussing and illustrating study details and informed consent procedures and implications. The video was about 10 minutes in duration and was avail- able for viewing on the SHRP 2 NDS Participant Portal web- site (http://www.shrp2nds.us/informed-consent.html). Each site was also provided with a copy on DVD for local use, and participants were encouraged to watch the video as part of the consent process. Given that the final consent forms were typi- cally 15–16 pages long, the video was seen as a way to make the consent process and study details easier to understand. One-Page Information Sheet One-page information sheets were developed in an additional effort to make the consent process and study details easier to understand. These sheets encapsulated the study description, vehicle instrumentation, risk, data security and confidential- ity, study procedures, and compensation aspects of the study. One of these “one pagers” was aimed at adult participants and a separate one was developed for minors, as it included information about the parental permission process. Both ver- sions were available on the SHRP 2 NDS Participant Portal website and are appended to this document in Appendices L and M, respectively. Minor Assent Confirmation As noted above, minors provided assent for their participa- tion. However, as it was possible that a minor could have been coerced into assenting, an important part of the minor assent process was to confirm—outside of the presence of the con- senting adult—that the teen’s assent was being freely offered without reservation. If not, then the would-be participant was politely dismissed in a way that deflected attention from the teen (i.e., the site manager indicated that there was an incompatibility between the vehicle and study equipment and offered the parent and teen nominal compensation for their inconvenience). Appendices N and O include the final assent and parental consent forms related to primary drivers and sec- ondary drivers. The Buffalo site is used in each example. Certificate of Confidentiality A Certificate of Confidentiality was secured from the NIMH for the SHRP 2 NDS for the duration of the data collection process. A Certificate of Confidentiality helps researchers pro- tect the privacy of participant information and data against compulsory legal demands (e.g., court orders and subpoenas) that seek the names or other identifying characteristics of a

25 experience to manufacture electronic boards and to build and fully test final electronic assemblies rather than selecting ven- dors with similar hard goods that met the design specifications. While the primary design of the main data collection unit (the NextGen main unit) was contracted to an external con- tractor, the remainder of the system and component design was carried out by Coordination Contractor personnel. The DAS incorporated six primary components: NextGen main unit, head unit, network box, radar, radar interface box (RIB), and solid-state data drive. The NextGen main unit was the computing source for the system, the electronics for which were encased in a rugged plastic enclosure with room for the solid-state drive. As shown in Figure 2.1, the NextGen was to be mounted in an out-of-the-way location in the vehicle—such that it would not take up too much space (e.g., mounted in the trunk on the underside of the rear parcel shelf)—but also in a manner which facilitated the maintenance and drive-swapping activities performed by site contractors, when necessary. Often, the location was under or behind the driver’s seat or in the trunk. The head unit was mounted to the windshield in the vicinity of the rear view mirror and featured a smaller subhead arm. The radar was mounted to the front license plate frame and was the most vulnerable component. The RIB was located under the hood of the vehicle and used Bluetooth technology to communicate with the NextGen. The network box was used to gather information from the vehicle network. Procurement Strategy As is standard practice for custom designs, vendors had to be selected for the construction of different components and for 44 Machine-vision-based applications: 4▪ Head pose monitor, and 4▪ Lane tracker; 44 Accelerometers (x, y, and z axes); 44 Rate sensors (x, y, and z axes); 44 GPS: 4▪ Latitude, longitude, elevation, time, velocity; 44 Forward radar: 4▪ X and Y positions, and 4▪ Xdot and Ydot velocities; 44 Illuminance sensor; 44 Passive cabin alcohol presence sensor; 44 Incident pushbutton: 4▪ Marks data and opens a 30-s audio recording channel; 44 Turn signals; 44 Vehicle network data (as available; examples listed below): 4▪ Accelerator, 4▪ Brake pedal activation, 4▪ Antilock braking system (ABS), 4▪ Gear position, 4▪ Steering wheel angle, 4▪ Speed, 4▪ Horn, 4▪ Seat belt information, and 4▪ Airbag deployment; • Define procedures required to change instrumentation midstudy; and • Assess trade-offs. Consequently, the procurement process focused on find- ing manufacturing partners that had the capabilities and Front Turn Signals Radar Interface Box Radar Unit PWR Bluetooth PWR DAS Main Unit OBD Connector Head Unit Sub-Head Unit GPRS Antenna Rear Camera Figure 2.1. Installed DAS schematic.

26 of the site contractor locations. These M2M communications were used to disseminate software upgrades to installed units, collect biweekly DAS function or health check reports, and transmit crash epochs to Coordination Contractor servers. A health check entails running predetermined algorithms on DAS systems and reporting out a confidence measure for each variable or functional category to indicate whether or not it is functioning properly and consistently. Results for each variable had to be interpreted holistically, with a deep understanding of DAS functionality in the context of other related variables to get a truer understanding of the nature of any particular problem detected. The health check and software upgrade capabilities permitted the research team to dynamically maintain and improve the DAS operations of the in-field fleet and maximize the efficiency of the integrated data collection systems. The transmission of high g-force epochs allowed for auto- matic crash notification (ACN) when algorithms indicated that a vehicle had potentially been in a collision. Each ACN epoch was verified via visual inspection, as the proportion of false alarms was relatively high. Validated ACNs facilitated the timely conduct of crash investigations, including inter- viewing participants while the incident was still fresh in the participant’s memory. Beginning with the Study Design project and continuing into the start of the SHRP 2 NDS, estimates were prepared to determine the required level of telemetry service that would yield the best value in terms of minimizing costs while main- taining sufficient service levels to support the telemetry activ- ities noted above. In the months preceding the first vehicle installation, the ordering process was initiated in earnest. Of the available options, the monthly 8-megabyte (MB) service per DAS was deemed to be the best value in terms of balancing system assembly. The primary selection was for a CM to pro- duce the PCB assemblies and to perform assembly and test procedures for individual system components along with the full system. An RFP was issued to select a viable CM. Vendor selection for the manufacture of custom cables and plastics was carried out using an invitation for bid (IFB). Evaluation of the responses from the IFB was based on price for the build of the system. Separate purchases were made for select commer- cially available products that were integrated into the system design (i.e., radar and cameras). A selection committee consisting of representatives from the Virginia Tech (VT) Purchasing Department, the Coor- dination Contractor, a National Research Council contract specialist, and SHRP 2 personnel reviewed and approved all procurement processes, solicitations, and vendor responses, and selected the winning bidders. The rigorous selection pro- cess met all SHRP 2, federal, and Virginia Tech guidelines for securing the build services and involved systematic financial and experience-based evaluations of respondents. The selection committee established the criteria and their relative weighting (listed in Table 2.1), and these were used throughout the selection process to evaluate the candidates. Final Vendor Selection The final scoring for the three candidates is provided in Table 2.2. Telemetry Service Integration and Procurement Each NextGen featured cellular machine-to-machine (M2M) modem technology that was configured for Verizon Commu- nications Inc.’s code division multiple access (CDMA) wireless network. This specific CDMA-based technology was selected based on the totality of cellular coverage availability at each Table 2.1. Selection Criteria Weighting Scale No. Criterion Maximum Point Value 1 Ability to meet delivery requirements 10 2 Services offered 10 3 Price of goods 35 4 Price of services 15 5 Prototype evaluation 20 6 Small, Women-owned and Minority-owned business (SWaM) use 10 Total 100 Table 2.2. Vendor Selection Criteria and Final Scores No. Criterion ACDIa Alternative B Alternative C 1 Ability to meet delivery requirements 8.2 8.3 8.3 2 Services offered 8.3 8.3 8.7 3 Price of goods 35.0 30.2 31.7 4 Price of services 20.0 18.4 15.9 5 Prototype evaluation 13 4.0 13 6 SWaM use 10 10.0 10 Total 94.4 79.1 87.5 a ACDI, American Computer Development, Inc., was selected based on the scoring performed by the selection committee. On completion of the selection process, an order was placed for the turnkey assembly of the DAS systems for the SHRP 2 NDS.

27 IRB issues were discussed at a high level, including current progress on attainment of the Certificate of Confidentiality from NIH. Finally, a discussion of custom software, including its purpose and a high-level introduction on to how to use it, was included. These meetings were important contributors to providing the necessary details and face-to-face communica- tions the site contractors needed to develop their sites into final study-ready form. A Coordination Contractor PI and TRB staff also visited each site a second time approximately 2 weeks ahead of that site’s first scheduled participant enrollment and DAS instal- lation. These visits took place from September 2010 to Febru- ary 2011. These visits were conducted to validate each site’s readiness to conduct all study operations in a safe and con- sistent fashion, and in a manner conducive to collecting high- quality data. This was accomplished by visual inspection of all study facilities in the context of a detailed site readiness checklist (Appendix P). The checklist encompassed the fol- lowing areas: general facilities (e.g., signage, parking, waiting areas), participant enrollment (e.g., privacy, secure storage for hardcopy documents), participant assessment (e.g., suf- ficient and safe space for the rapid pace walk, suitable space and equipment if enrolling two or more participants simul- taneously), and the garage/shop area (e.g., space sufficiency, suitable carbon dioxide exhaust/ventilation, accessible DAS storage). Each element on the checklist was either validated as approved or noted as an area for remediation before com- mencing data collection. Training To ensure consistent understanding of human subjects protec- tion structures and protocols across sites, each individual who expected to interact with a human participant (or might come into contact with personal information or items belonging to a participant) had to provide evidence of successful comple- tion of standard IRB training offered by various entities such as NIH, the Collaborative Institutional Training Initiative, or a university IRB training course. This applied to experimenters performing driver assessments, managers, installation techni- cians, and crash investigators. In addition to this general IRB training, the Coordination Contractor developed specialized IRB training for each of these groups of researchers based on knowledge gained and lessons learned during past naturalistic driving studies. The content of each training session was cus- tomized to the audience, but each session included some subset of the following topics tailored to naturalistic driving studies: • Professionalism; • Recruitment; • Informed consent; • Disqualification guidelines; cost and level of service. This level of service was determined based on the average packet size of software updates and antici- pated average volumes of incoming routine health check infor- mation and crash notifications. In addition, it is important to understand that total system bandwidth (i.e., 8 MB × the total number of enabled DAS units) was pooled across the entire fleet. Thus, DAS kits using more than their share of the total bandwidth in a particular month (e.g., due to trans- mitting an ACN epoch) could be absorbed within plan limits if several other units consumed less than their nominal share that same month. Data Collection Site Facilitation The Coordination Contractor was responsible for technical coordination of six data collection sites. The preparation activ- ities needed to support ongoing coordination efforts included assessing each site for readiness, training site contractor per- sonnel, and providing software tools to assist them in manag- ing their DAS kit inventory, participants, and vehicle fleets. The tools built for this purpose provided ongoing technical support for participant recruitment efforts; DAS installa- tion, maintenance, and deinstallation; and project oversight over the duration of the study. The Coordination Contrac- tor established a number of software support resources, all of which are discussed in greater detail later in this chap- ter. These included the following: a telephone and web-based “hotline” service to support site contractors with urgent instal- lation or assessment questions during active installations, web resources for both study partners and prospective participants, a web-based information-sharing tool or “wiki,” the study URL (www.drivingstudy.org), a portal for interested parties and active participants, and weekly conference calls. Readiness Visit and Checklist Site readiness was facilitated and validated by the Coordina- tion Contractor along with SHRP 2 staff primarily via two in- person visits. The first series of visits entailed participating in a kick-off meeting with the site contractor and Transportation Research Board (TRB) staff. These meetings took place over a period from June to December 2010 at each site contrac- tor’s location. At these meetings, a Coordination Contractor PI discussed the three-tiered recruitment strategy and plans for training site contractor personnel. The training discus- sion included required installation technician background and expected training outcomes. Required tools to equip a site were listed, including both custom tools that would be provided by the Coordination Contractor (e.g., DAS align- ment and calibration tools) as well as those standard shop tools that needed to be supplied by each site contractor, such as pliers, wrench sets, screw driver sets, and battery chargers.

28 protocols, risks, benefits, and compensation—then having him or her sign an informed consent document. In September 2010, a single 1-day enrollment training was provided to the site contractor personnel gathered in Blacksburg, Virginia, at the Coordination Contractor facility. All site contractor per- sonnel were required to complete this IRB training. Best prac- tices were shared with trainees in the following areas: privacy, record keeping, management of the consent process, partici- pant payments, the coordination of activities at installation, and management of difficult or otherwise delicate situations. Assessment All primary participants were assessed along a variety of func- tional dimensions important for driving, including cogni- tive, perceptual, and physical dimensions. In September 2010, training on exactly how to conduct these assessments was pro- vided to the site contractor personnel assembled in Blacks- burg, Virginia, in conjunction with the previously described enrollment training. During this portion of the training ses- sion, the protocols for conducting assessments using standard equipment and software were demonstrated to and practiced by trainees for on-site, in-person testing (e.g., vision tests), as well as filling in questionnaires, which could be conducted online at the enrollment site or at the participant’s home or other preferred loca tion. Following the classroom instruc- tion, an assessment practice session was conducted so that trainees could demonstrate competence, and so that any ques- tions could be identified and discussed with members of all the site contractors. Vehicle Installation In early fall 2010, hardware technicians representing each site contractor traveled to Blacksburg, Virginia, for vehicle installation/maintenance/deinstallation training at the Coor- dination Contractor facility. Multiple sessions were scheduled across several weeks to enrich the experience and balance the instructor/trainee/practice vehicle ratio. In each session, 3 days of training covering all aspects of the installation, mainte- nance, and deinstallation activities were provided. In all, four such training sessions were conducted to train all hardware technicians. Hardware technicians were also required to complete IRB training. Additionally, as described above, an introduction to IRB best practices was provided at the start of each hard- ware technician training session. Training included sessions on installation, troubleshooting, maintenance, and deinstal- lation, as well as data upload demonstrations. All portions of the training involved a lengthy hands-on practical session so that as hardware technicians were trained, they also dem- onstrated their new skills on a variety of different vehicle types. Figure 2.2 shows the hands-on learning experienced • Installation; • Driver assessment; • Adverse events; • Crash investigation; • Data retrieval; • Payment issues; and • Out-processing (deenrollment). Institutional Review Board and Special Situations Two special situations were identified early in the study prepa- ration phase. First, two of the six sites (Erie County, New York, and Seattle, Washington) are located very near the United States–Canadian border. Still and video image recording is for- bidden at such international border crossings, which would be a problem for instrumented vehicles whose onboard systems are continuously recording video images while the vehicle is running. Attempts to secure permission for study vehicles to pass freely across the border without being stopped or divulging the participant’s personally identifying information were unsuccessful. Therefore, screening protocols excluded all potential participants who planned to cross the border with an instrumented vehicle at any time. This requirement was reiter- ated verbally by site personnel and in the consent materials. A second anticipated special situation entailed participants in an instrumented vehicle encountering law enforcement or other officials due to, for example, a traffic stop or crash. Although the study equipment is unobtrusive, it was possible that an officer might notice and ask about it, thus possibly compromising participant anonymity as well as the measures put into place to protect participant data. To guard against this type of security violation, a letter was specially prepared for these situations, and participants were advised to keep it handy in the vehicle, for instance in the glove box, so that it could be presented to the authorities as needed. This letter incorporated the following features: • Description of the vehicle’s role in the study without divulg- ing the identity of the driver or any particular person as being enrolled in the study; • A portion of the vehicle’s license plate number to defini- tively link the vehicle to the letter; • A photo of the head unit to definitively link the vehicle to the study; and • Contact information for the site PI. Enrollment Participant enrollment is the process by which a potential par- ticipant or recruit is formally inducted as a participant into the study. There are several aspects to this process, but key is thoroughly informing the individual of all study-related

29 activity within a secure environment. MCS was designed to serve three primary functions: 1. Coordination Contractor support for coordination of site contractor activities; 2. Coordination Contractor monitoring of the SHRP 2 fleet; and 3. Site contractor management of their respective fleets. MCS users fell into one of three user groups, each with its own unique scope of information; access was controlled using role-based security protocols. Coordination Contractor and SHRP 2 staff members were able to view information on par- ticipants, vehicles, and components across all sites; however, these two user groups could not view personally identifying participant information. In contrast, site contractors were able to see the same categories of information, including per- sonally identifying information—but only those study ele- ments pertaining to their own sites. MCS was designed to support site contractor recruitment, installation, and maintenance activities; facilitate fleet manage- ment; and inform decisions regarding study coordination and oversight. It proved to be a vital tool in the conduct of daily study operations. It featured overall study status information and detailed information on any particular participant or fleet vehicle. Its many features facilitated efficient completion of the daily operational tasks of the study and allowed Coordination Contractor staff and site contractor staff alike to proactively monitor many key aspects of the study. A sample image from MCS is shown in Figure 2.3. Request Tracker System Request Tracker (RT) afforded the Coordination Contractor the means to track all study issues from inception to resolution, making certain that none were simply lost as may have been the case using conventional, non-tracking-based communica- tion media (e.g., phone or e-mail). Study issues encompassed problems related to components, installations, software devel- opment, and other emergent situations. The Coordination Contractor used this system to manage workflow among the Coordination Contractor staff, to prioritize maintenance items for site contractors, and to track and analyze systemic issues across the study. The site contractor users employed RT to alert the Coordination Contractor to DAS issues, to communicate difficulties and questions regarding maintenance activities, and to make requests for technical support, equipment, and logisti- cal assistance. Study personnel were able to access work items by means of an individualized dashboard view, pictured in Figure 2.4. Each issue was identified in the form of a ticket and placed into a work queue based upon which entity was deemed most by trainees during the 3-day session. Site managers were also provided a high-level version of the hands-on installation training session. Training for each site’s group of technicians was scheduled to be completed about 2 weeks before the start of installations at that site to maximize retention while still permitting time to perform practice installations and deinstallations. In addition, Coordination Contractor representatives traveled to each site contractor location for the first 3 days of actual installations of participant vehicles to guide or advise the newly trained hardware technicians as needed. Additionally, conference calls led by Coordination Contrac- tor technicians were conducted quarterly to provide updated information and training directly to installation technicians. Documentation of further training sessions was then uploaded to the SHRP 2 wiki website (Wiki.shrp2nds.us) to serve as a reference to installation as well as other project support staff. Software Support Resources The Coordination Contractor employed a number of custom software support resources to coordinate, oversee, and sup- port the daily operations of the study. As the study progressed and emerging needs were identified, enhancements were made to existing programs and new ones were developed in an effort to provide a more robust set of study management tools. Mission Control System The Coordination Contractor developed Mission Control Software (MCS), a password-protected, user-friendly, web- based interface to the operations database maintained by the Coordination Contractor. MCS facilitated real-time viewing of information pertaining to recruitment, installation activ- ity, component disposition, participant records, and vehicle Figure 2.2. Installer hands-on training.

30 installation issues. These queues were jointly monitored, and the issues contained within each were worked on by the site contractors; thus, the queues served as a way to communicate the specific work needs. An example of such a ticket might include a given vehicle needing a data drive swap or a specific secondary driver whose consent date had not yet been entered into MCS. Additionally, a number of queues were managed by appropriate to take responsibility for that particular work item. RT was structured on the basis of a series of queues, which were virtual containers of categorized tickets or issues that needed to be worked on by a user or users within a group of individuals slated to monitor a given queue. For the SHRP 2 NDS, there was a collection of specific site contractor queues to address administrative, assessment, or Figure 2.3. MCS screen capture. Figure 2.4. Request Tracker dashboard.

31 that allows designated users to modify the content of informa- tion. The wiki proved to be a dynamic, comprehensive source of information regarding individual vehicles makes and mod- els, recruitment, enrollment, assessment, participant manage- ment, and direction regarding vehicle eligibility, classification, and requisite installation procedures. The site contractor hard- ware technicians were not only encouraged to use the informa- tion available to them, but also to add contributions based on their own observations and experiences. The wiki also featured a mechanism for uploading images and documents. Coordination Contractor personnel issued a recurring e-mail called the “Wiki Digest.” This included hyperlinks to relevant wiki pages, summarized recent additions to this grow- ing body of knowledge, and highlighted other wiki elements. Drivingstudy.org A website, www.drivingstudy.org, shown in Figure 2.5, was developed as a recruiting tool for the SHRP 2 NDS. It served as the public face of the study, targeting potential recruits, existing participants, and the general public. In addition to providing a comprehensive introduction to the study, the site also included links to a web-based participant eligibility screener, informa- tion regarding compensation, participant assessment, and study confidentiality policies and measures taken to safeguard par- ticipant privacy. Informed consent documents and a detailed description of study equipment for the edification of prospec- tive participants were also featured. Information about the site contractor data collection sites (e.g., address, phone numbers, and driving directions) was featured on the home page. While this was a publicly accessible website, it also included a link to a password-protected section where participants could log in and fill in study questionnaires from home or any other convenient location. Provision of Site Contractors: Equipment and Other Tools The collection of a high-quality data set required the uniform administration of a consistent set of protocols at the six site contractor locations. To that end, all data collection equip- ment, installation fixtures and software, assessment equipment and software, and data ingestion equipment were centrally built, procured, and configured so that all sites collected and processed data in the same way as had been approved by the individual and collective IRBs. Each type of equipment, tool, or software will be discussed below within the context of its relevant functionality. DAS Equipment The provision of DAS kits to the site contractor sites involved a delicate balance between obtaining component elements from the Coordination Contractor. Site Contractors could post tickets to a general queue simply by sending an e-mail to the designated e-mail address. Eventually, most tickets were directed to more specific queues to be addressed by the most suitable personnel. Such queues included Computer Technical Support and Hardware Repairs. From the vantage point of his or her dashboard, a user could view a list of his or her tickets, take responsibility for a ticket, view all unowned tickets, gener- ate a ticket, monitor queues of which he or she was a member, or search for a specific ticket. RT was used as an issue identification mechanism, workflow prioritization and management system, and issue reporting tool. The ability to search for a ticket or group of tickets based on a number of variables or variable combinations supported the issue tracking and analysis functions of RT. The queries allowed the user to assemble a timeline of maintenance issues for a particular vehicle or component, or to survey a history of interactions with a particular participant. This function further lent itself to tracking and analysis of systemic study issues and guided the timely adjustment of policies on issues. Hotline RT, as noted above, was used as a means to report and man- age issues that arose during the study. However, some prob- lems were deemed so urgent that another mechanism was implemented to facilitate rapid response to these time-critical problems, typically installation-related problems experienced while a participant was waiting on his/her vehicle. To this end, a hotline telephone service was established. The Coordina- tion Contractor staff were available 8:00 a.m. to 8:00 p.m. daily, Eastern Daylight Time, Monday through Saturday to provide guidance and technical assistance to site contractor hardware technicians. The hotline—using Google Voice, a free technology—was set up such that calls to a central number could be forwarded to any one or more on-call members of Coordination Contractor staff. Any missed calls resulted in the generation of a transcript of the call being sent as a text message to the same designated staff. In addition, the system’s web-based user interface also displayed the same automati- cally generated transcript as well as an audio recording of the missed call’s voice message. Average resolution for a hotline call was 1 hour. Typical hotline situations included compo- nent status issues, technical support needs, installation and maintenance anomalies, and requests for database changes to facilitate installations and maintenance. Wiki Delivering a continual flow of up-to-date information was deemed a vital component in the conduct of the SHRP 2 NDS. The Coordination Contractor developed a wiki as one mecha- nism for addressing this need. A wiki is a web-based application

32 As described previously and shown in Figure 2.6, each DAS kit comprised six main components (NextGen main unit, head unit, radar, radar interface box (RIB), network box, solid-state drive) with associated cabling, a General Packet Radio Ser- vice (GPRS) antenna, and rear camera. Pictured in Figure 2.6, beginning in the top left corner and moving clockwise, are the NextGen, head unit, network box, RIB, and radar. The solid- state drive is not pictured. It is important to note that the build of these kits relied not only on the electronic components and cabling, but also on the plastic housings for the main compo- nents. Each DAS kit was bench tested by the equipment man- ufacturer to ensure the operability of the equipment before shipping. suppliers, building kits, and supporting the varying installation scheduling needs of sites. Table 2.3 indicates the full comple- ment of kits that were allocated to each site contractor data col- lection site. In addition, a 10% surplus of kits was purchased. Additional components were provisioned, which allocated an additional 5–7% to sites based on the quantity of any individual component available less those that were out for repairs. Not all DAS kits were initially available at the outset of the study, so distributions were made to each site as kits became available from the CM, keeping in mind the goal numbers indicated in Table 2.3. Throughout the study, weekly assessments of equipment supplies at sites were conducted, thus allowing strategic equip- ment reallocation to be performed as needed. Approximately 11 equipment redistribution exercises were implemented to transfer components among the site contractor sites. Additional parts were procured as study needs dictated. Figure 2.5. Drivingstudy.org. Table 2.3. Kit Projections by Site Contractor Data Collection Site Site Contractor Data Collection Site Nominal Quantity of Designated Kits Buffalo 450 Tampa 450 Seattle 450 Durham 300 Bloomington 150 State College 150 NextGen Head Unit Radar Interface Box Radar Network Box Figure 2.6. DAS kit.

33 rate, and the presence of alcohol in the cabin. In addition, the head unit included a button that the participant could press to open a 30-second audio channel so an event of inter- est could be described and to mark the data stream for later analysis. Installation Equipment and Software Custom vehicle management software was developed to facili- tate the installation, deinstallation, and midstudy maintenance of DAS units. This software suite was designed to provide the hardware technicians with a systematic way to proceed with the installation and confirm proper functioning of all DAS components as they were installed. All vehicle management software was resident on the desktop of each provisioned Dell Latitude E6400 laptop for hardware technicians, and information captured on it was stored on a local database installed on the laptop. After each installation, maintenance, or deinstallation activity, hardware technicians initiated a process to synchronize the local database, which included the metadata pertaining to all DAS-related activities, with the pri- mary database housed on VTTI servers. Automatic synchro- nizations were also performed overnight to ensure that all laptops were synchronized with database updates. Custom software used during vehicle installation was designed to capture information about the vehicle and install vehicle-specific software packages on the DAS. Hardware technicians confirmed the participant vehicle year, make, and model, and entered the vehicle identification number (VIN) and license plate information. Further, hardware technicians tested cold cranking amps and voltage of the vehicle battery to confirm that it maintained sufficient charge to operate the vehicle and the study equipment. Participants with vehicles that did not have sufficient battery life were notified that the installation could not proceed unless a new battery was installed and were provided with a gift card or reimbursement The NextGen main unit hosted the computing functions of the DAS kit and served to coordinate all sensor nodes, com- munications, and data storage on the 128-gigabyte (GB) solid- state drive. An asynchronous data collection model was applied so that each variable was recorded at its native frequency. All data streams were marked with a timestamp to facilitate syn- chronizing during analysis. During the installation process, software packages specific to the unique combination of vehicle year, make, and model were initialized to capture the available vehicle network data. This software allowed components to communicate vehicle- specific data variables such as brake actuation or turn signal use. The NextGen main unit was equipped with a cellular modem that allowed for routine M2M communications. Cabling provided hard-wired connections between the head unit and NextGen main unit as well as a power source. Additional cabling connected to the onboard diagnostics port (OBD-II) so that network data could be obtained from those vehicles, as available. The GPRS antenna and rear camera were both located on the rear package shelf or affixed to the rear window and were connected by cabling to the NextGen main unit. Radar data were communicated via Bluetooth wireless technology to the RIB, which significantly reduced the amount of time needed to perform the installation because cabling did not have to be run through the vehicle’s firewall. The head unit assembly (Figure 2.7) featured three cam- eras that captured video images of the forward roadway, the driver’s face, and the instrument cluster interactions. Figure 2.8 demonstrates the quad view of the video images. An additional camera in the head unit assembly periodically captured an image of the cabin intended to assist in the deter- mination of passenger presence, including possible indication of approximate age and gender. These still images were irretriev- ably blurred to protect the identity of unconsented passengers. Additional sensors housed in the head unit assembly measured ambient illuminance, acceleration in three dimensions, yaw Figure 2.7. Head unit assembly. Figure 2.8. Quad image of video views.

34 Driver Assessment Equipment and Software During the Study Design project, the importance of measuring driving-related functional capabilities was identified. A com- prehensive driver-testing suite was devised by study design per- sonnel and vetted by an external blue-ribbon committee with substantial expertise in the use and interpretation of driver assessment tests. Assessment details are fully discussed in Antin et al. (2011), and the protocol by which they were administered is found in Appendix A. In support of the assessment activity, the equipment and software discussed below were provisioned to the site contractor data collection sites. The provision of the equipment supported a consistent approach to data collection and the data variables across multiple site contractors and data collection sites. The Optec 6500P Vision Tester (pictured at far left in Fig- ure 2.10) was selected to measure a variety of visual abilities, to defray the cost of the replacement battery or compensate them for their time if they chose not to purchase a new bat- tery. This was done to forestall situations in which partici- pants might unfairly blame the installed system for a battery failure. Odometer readings and measurements of tire tread depth and pressure were recorded, and photographs of the vehicle were taken to document the vehicle’s condition before installation. A unique bar code was affixed to each main DAS compo- nent; the bar code was scanned into the software on instal- lation as well as deinstallation so that components would be accurately associated with the correct vehicle or location and tracked in the database. Once the equipment was connected, the NextGen main unit began initializing the installation package. During this process, if errors occurred, the hardware technician was notified to check a specific area. As prompted, the hardware technicians performed the designated actions to test the component functionality and calibrate the sensors as needed. Last, the participant was brought back to the vehicle so the technician could take images with the driver inside the vehicle (to aid the post hoc process in which each analyzed trip file is definitively associated with a consented driver) and conduct an inspection of the vehicle, verifying that no damage was caused by the installation process. Custom software was also used to guide the deinstallation process. By scanning the vehicle barcode, hardware techni- cians checked and confirmed that the proper vehicle record was retrieved from the database before conducting the deinstallation. Components were scanned during removal, and a reason for deinstallation was recorded in the software. Similarly, hardware technicians used custom software during midstudy visits when they conducted routine data drive swaps or other DAS maintenance. Use of the vehicle and component barcodes in conjunction with the main- tenance software allowed the Coordination Contractor to maintain accurate inventory records as components were replaced midstudy. In addition to capturing inventory changes, this software also imaged the solid-state drives with the appropriate and most up-to-date vehicle-specific soft- ware packages. In conjunction with the software suite described above, sev- eral hardware tools were provisioned to the site contractor sites to ensure DAS units were properly aligned and calibrated dur- ing installation. Specifically, a custom-built alignment panel (Figure 2.9) was used to center the radar and record measure- ments about the headlight alignment and pattern associated with a vehicle’s headlights. Custom-built laser alignment tools were designed, developed, and provisioned to ensure lateral alignment of the head unit and to measure the vehicle width for use with machine-vision programs. Additionally, a laser- based tool was used in conjunction with the alignment panel to calibrate the radar installation. Driver-side lateral alignment Vehicle alignment Laser alignment Forward camera height laser Figure 2.9. Alignment panel and driver-side lateral alignment laser apparatus with left- right-center laser spots. Figure 2.10. Driver assessment workstation.

35 this study. The infrastructure was projected to require the fol- lowing components: • A petabyte (PB)–scale file storage for video; • A 100-terabyte (TB)–scale database for parametric (sensor) data; • High-speed networking for data transfer from the site con- tractors to Coordination Contractor servers; • Multi-TB on-site storage at site contractor facilities to serve as temporary staging storage for collected data await- ing transfer; • A large computer cluster to process data received from the staging servers; • A bidirectional replicated database platform to allow com- ponent installations, maintenance, and deinstallations to occur without requiring a network connection; • A flexible workflow (state engine) to track each and every file collected from a vehicle; and • A database platform to support the various participant assessments. The total collected data has required approximately 1.5 PB of archival (tape) storage, 700 TB of parametric data, and over 1.2 PB of video storage, thus far. When the storage require- ments for the operational data (60 GB of database storage plus 8 TB of storage available at each of six remote site servers) are considered, the data storage requirements approach 3 PB of allocated storage space, and exceed 3 PB in raw storage capac- ity. The difference is due to the additional storage requirement to support Redundant Array of Independent Disk (RAID) configurations that provide data recovery methods for restor- ing data when disks fail. In addition to data storage, it was critical to provide net- work infrastructure to transfer data efficiently from the field sites to storage servers at the Coordination Contractor facility. The SHRP 2 study relied on a high-speed research network (Internet2) along with tuned transmission control protocol/ Internet protocol (TCP/IP) connections that facilitate sus- tained transfer rates in excess of 100 megabits per second. Once the study was under way and data drive (128 GB SSD) swaps reached a steady state, the Coordination Contractor received in excess of 2 TB of collected data on a daily basis. To handle the millions of files that have resulted from the SHRP 2 data collection effort, a flexible workflow (state) engine was established to track each file at every step in its path from the time it was retrieved from its data drive until it was loaded into its final resting place (archive, database, and/or file storage). With over 13,000 SHRP 2 components in the database, it was critical to be able to track each of them for inventory purposes—whether they were installed in a vehicle, removed from a vehicle, in a repair status, or in inventory at either a site or a Coordination Contractor facility. A barcode system was developed in which a component’s bar code was scanned including contrast sensitivity under a variety of lighting con- ditions, near and far static acuity, depth perception, color perception, and peripheral field of view. The Jamar Hand Dynamometer (pictured at bottom right in Figure 2.10) was used to measure participants’ grip strength and as a gross measure of overall upper-body strength. Select software packages and processes were administered on the assessment computer provisioned to the site con- tractor data collection sites. The Dell Optiplex 780 Mini- tower with touch screen monitor was used for this purpose. The computer was loaded with Driving Health Inventory (DHI) software and Conners’ Continuous Performance Test II (CPT II) Version 5. The DHI software featured several tests of visual-cognitive ability that were used in the study, includ- ing Useful Field of View (UFOV Subtest 2, divided attention), Trail Making Test, and Visualizing Missing Information. Administration of the CPT II software captured a measure of executive function and working memory as well as reac- tion time. Data Ingestion Equipment To transfer collected driving data efficiently from the site contractor data collection site to the SHRP 2 NDS database, a custom-built drive bay data ingestion apparatus and Dell PowerEdge 2900 staging server were provisioned at each data collection site. Data collection site personnel inserted solid- state data drives retrieved from study vehicles into the drive bay ingestion apparatus. An automated process transferred data from the solid-state drive to the staging server, using a series of checks and balances to ensure that all data were transferred. Once the transfer was completed, the status of the solid-state drive was reset, allowing site contractor staff to reuse the drive in another vehicle. Hardware/Software Infrastructure When conducting a study of any size, researchers must con- sider a variety of data storage and processing solutions. In the case of SHRP 2, those data storage concerns were magnified due to the distributed nature of the data collection effort (six site contractor locations across the United States, remotely located from the Coordination Contractor’s site) and the immense scale of the data to be collected. In addition, there were separate concerns for managing and storing the data required for day-to-day operations of the study, especially the data required by Project S07 to identify participants, their vehicles, any components installed in those vehicles, and par- ticipant assessment data. Preliminary planning revealed the need for a significant hardware and software infrastructure to meet the estimated data storage, data transfer, and data analysis requirements for

36 as the recruitment practices used to attract participants may determine to a large extent the nature of the interpretations that can be gleaned from any subsequent analysis of the col- lected data. The high-level goal for the sampling plan was to recruit an equal number of male and female licensed drivers across the full breadth of the driver age spectrum. It was also a goal to oversample the youngest and oldest drivers, as these are the most interesting drivers to study due to elevated crash risk. Participant screening. All participants had to pass the following eligibility criteria: 1. Is a licensed driver; 2. Drives at least 3 days per week; 3. Plans to keep vehicle for duration of anticipated study participation (i.e., 1 or 2 years for most participants); 4. Is competent to grant informed consent (or for minors, informed assent with consent granted by parent or guardian); 5. Has an eligible vehicle (note: eligible vehicles list grew as the study progressed); and 6. Has a suitable vehicle in terms of mechanical soundness and anticipated life, cleanliness/hygiene, and freedom from other concerns (e.g., leaks or presence of illegal materials). Participant selection factors. The sampling plan was based on participant age group and gender as well as whether or not the study vehicle was equipped with advanced vehicle technologies (e.g., brake assist or other collision avoidance and mitigation technologies). The initial sampling plan is shown in Table 2.4. It incorporated the aforementioned factors of age group, gen- der, and vehicle technology; in addition, it includes the number of DAS units allocated to each cell as well as the idea that some participants would be recruited to participate for 1 year, while others would be recruited for a 2-year duration. The objective of oversampling the youngest and oldest drivers was accom- plished in the design by creating a greater number of equal- cell-size age groups at the ends of the spectrum. Note that the design shown in Table 2.4 represents the initial studywide sam- pling plan; each data collection site was only responsible for a subset of the overall design proportional to its nominal DAS unit allocation, as indicated in Table 2.3. Site selection factors. Study sites were selected by a SHRP 2 Expert Task Group (ETG) formed for this purpose. The ETG used a two-stage process: first, a request for qualifications (RFQ) was released, and then, a request for proposal (RFP) was sent to contractors that passed the qualification stage. The RFQ was released a second time after the first release resulted in no qualified contractors in southern states. After the second release, the RFQ stage produced 11 qualified sites, three located in southern states. The RFP stage considered cost as well as site characteristics. Not all qualified contractors responded to the RFP. The RFP stage resulted in the selection of the final six sites (Antin et al. 2011). It should be noted that data col- lection site selection could not be based solely on a desire to as it was installed or deinstalled. Inventory management soft- ware could then track the location of a component within the database. Likewise, when shipping components in a box, the shipping box received a barcode, then each component was virtually scanned into the box as it was physically added to the box. Thus, when a box was received (unopened), the box barcode could be scanned to virtually receive all of the components inside. Remote Updates Another critical function of the database was to serve as a repository of the software files used to deliver software updates to one or more individual vehicles in the SHRP 2 fleet. When a single vehicle was targeted for a software update, the data- base table associated a specific update with the vehicle ID. The applications that supplied the update to the DAS’s file system generally operated within the installer or maintenance software, or Transerve. The DAS itself was programmed to look in a predetermined location for any software updates and apply them accordingly. Once applied, the database was updated to reflect the current versions of all software installed in the vehicle. Installer and Assessment Computing Efforts Each site contractor was provisioned with desktop(s), laptops, and a site server with 8 TB of storage. The desktops and lap- tops ran Windows 7 and had Microsoft Office and LogMeIn installed along with barcode scanning drivers, while the site server ran a Linux operating system. The laptops were also pro- visioned with Microsoft SQL Server 2008 R2 Express loaded with a subscription to the database as outlined in Chapter 3. The desktops were provisioned with the DHI (flash drive) dongle, CPT II software, and a touchscreen. Initial purchase and domain configuration were handled at the Coordina- tion Contractor facility before delivery to the site contractors, which allowed for consistent and reliable system builds across all SHRP 2 desktops and SHRP 2 laptops. The LogMeIn application turned out to be very beneficial as Coordination Contractor technicians were able to observe issues on the laptops and/or desktops in real time. System administrators at the Coordination Contractor worked with system administrators and network engineers at each site contractor location to configure wide-area network (WAN) access between the Coordination Contractor and the respective site contractor site. Sample and Recruiting Infrastructure Sample Design Sample design is a crucial aspect of any study involving human subjects. The selection and screening criteria chosen as well

37 Data collection sites were managed by the respective orga- nizations listed in Table 2.5. Call Center At the outset of the study, all recruitment activities were con- ducted and coordinated by the Virginia Tech Center for Survey have geographic diversity or dispersion. Instead, each site had to be supported by a qualified and vetted research organiza- tion that proposed to support a site at one or more particular locations, and only six such sites could be supported within the scope of the program. The final set of selected sites and how DAS units were allocated across them are illustrated in Figure 2.11. Table 2.4. Initial Studywide Sample Design Participants’ Gender and Age Range (years) Participants’ Age Groups Participate One Year Participate Two Years Total Participants [(2  One Year) + Two Years] DAS Units Vehicle-Years M 16–17 Minor teen 72 28 172 100 200 M 18–20 Adult teen 72 28 172 100 200 M 21–25 Young adult 72 28 172 100 200 M 26–35 Adult 72 28 172 100 200 M 36–50 Middle adult 72 28 172 100 200 M 51–65 Mature adult 72 28 172 100 200 M 66–75 Younger older 72 28 172 100 200 M 76+ Older older 72 28 172 100 200 F 16–17 Minor teen 72 28 172 100 200 F 18–20 Adult teen 72 28 172 100 200 F 21–25 Young adult 72 28 172 100 200 F 26–35 Adult 72 28 172 100 200 F 36–50 Middle adult 72 28 172 100 200 F 51–65 Mature adult 72 28 172 100 200 F 66–75 Younger older 72 28 172 100 200 F 76+ Older older 72 28 172 100 200 Any Advanced Vehicle Technology 0 350 350 350 700 Totals 1,152 798 3,102 1,950 3,900 Figure 2.11. Site locations and their nominal DAS allocations.

38 that the data gleaned from the use of these proprietary PIDs be stored in the database in a manner and resolution that would not permit their reverse engineering. The final list of eligible vehicles is featured in Appendix R. Note that recruit- ing obstacles ultimately necessitated an expansion of the list to include vehicles for which PIDs were not obtained; data were procured through custom-designed components to be described later in the report. administrative tools and processes In addition to MCS, RT, the SHRP 2 wiki, and the hotline, the Coordination Contractor coordinated a number of regu- lar conference calls to allow for dialogue between SHRP 2, partners, and contractors. Communication of study protocol, clarification of study-related issues, and reporting of metrics describing study health were all included in these meeting opportunities. Meetings A study of the scope of the SHRP 2 NDS by necessity involves multiple stakeholders and study partners. Regular communi- cation with SHRP 2 program managers, principal investiga- tors, and equipment hardware technicians was accomplished through a series of weekly and, in the case of installation tech- nicians, quarterly, conference calls hosted by the Coordination Contractor. Weekly Operations Team Conference Call The Coordination Contractor hosted a weekly operations team meeting, which included representatives from the Coordina- tion Contractor and the site contractor PIs and study man- agers as well as SHRP 2 staff, to exchange current information about study status, particular and general issues, and plans for upcoming events. Topics ranged from recruitment, vehicle data Research (VT CSR). A three-tier approach was planned for recruitment, with Tier 1 representing the most desired approach, Tier 2 the next most desired approach, and Tier 3 the fallback position if Tiers 1 and 2 proved less successful or efficient than desired. The Tier 1 approach used random cold- calling: numbers (procured by VT CSR management) within site boundaries were called at random. Tier 2 entailed focused random calling: numbers were prefiltered to include only those believed to own eligible vehicles. Tier 3 entailed using a wide variety of traditional recruiting efforts such as posting ads in local newspapers or other media, distributing flyers, and making personal appearances at a wide variety of venues. Regardless of the approach used, once on the phone, CSR staffers would engage interested parties in a brief discussion of study protocols and establish whether eligibility criteria were met. If interested and eligible, the recruit’s contact infor- mation was passed along to the Coordination Contractor, who processed the recruit’s vehicle information within the database (to facilitate proper DAS installation), then passed along that individual’s relevant information to the appropri- ate site contractor. The site contractor, based on its sample design needs at that time, would then contact the most desir- able recruits for scheduling of the participant enrollment and assessment and vehicle installation processes. Onboard Network Parameter IDs The initial slate of eligible vehicles (Appendix Q) was deter- mined by those vehicles for which various original equip- ment manufacturers (OEMs—i.e., the auto manufacturers) had agreed to provide certain parameter IDs (PIDs) for cer- tain vehicles. These PIDs permitted interpretation of the data generated by the vehicle’s onboard network. Some PIDs are standard and publicly available, while others are strictly pro- prietary. Each OEM that provided proprietary PIDs to the Coordination Contractor entered into a nondisclosure agree- ment to ensure that all of its proprietary PID information would remain private and secure. Furthermore, it is important Table 2.5. Data Collection Site Contractors Site Center Managing Organization(s) Nominal DAS Units Allocation (Percent of Total) Buffalo CUBRC, Inc., supported by CalSpan Corp. 450 (23%) Tampa CUBRC, Inc., supported by Center for Urban Transportation Research, University of South Florida 450 (23%) Seattle Battelle 450 (23%) Durham Westat 300 (15%) Bloomington Transportation Research Center, University of Indiana 150 (8%) State College Larson Institute, Pennsylvania State University 150 (8%) Total 1,950 (100%)

39 Quarterly Installer Technician Meetings The Coordination Contractor conducted a quarterly con- ference call for the installer technicians, affording the site contractor hardware technicians the opportunity to com- municate directly with software designers, hardware engi- neers, and other Coordination Contractor staff on whom they relied for hotline assistance. These meetings created a helpful dialogue essential to the advancement of study goals. Early calls focused on installation procedures and trouble- shooting for frequently encountered situations. As the vehi- cle fleet expanded, the conversations turned to finer points of vehicle classification and its implications for installation configurations. Conferences held later in the study focused on deinstallation protocols. Discussion of component scan- ning procedures was a constant due to the essential nature of inventory tracking and control. classification issues, installation schedules, and inventory man- agement to study closeout and equipment return. Weekly Conference Call The Coordination Contractor PIs hosted weekly conference calls with SHRP 2 staff. In addition to providing a forum for the discussion of various critical issues and the formulation of related policies, these meetings afforded study leaders the opportunity to discuss a wide range of study metrics pro- duced by the Coordination Contractor. These weekly metrics described progress with regard to recruitment, data inges- tion, processing and quality control analysis, and site contrac- tor progress in the areas of installations, deinstallations, and attendance to maintenance items. The Coordination Con- tractor documented action items for all parties and noted key decisions regarding study protocols and goals.