ENTERPRISE Drafmu Transprtatin Pled Fund Study TPF-5 (231) Real-Time Integratin f Arrw Bard Messages int Traveler Infrmatin Systems MODEL CONCEPT OF OPERATIONS February 2017 Prepared by
Acknwledgements This dcument was prepared fr the ENTERPRISE Transprtatin Pled Fund TPF-5(231) prgram (enterprise.prg.rg/). The main purpse f ENTERPRISE is t use the pled resurces f its members and the United States federal gvernment frm Nrth America t develp, evaluate, and deply Intelligent Transprtatin Systems (ITS). Prject Champin Cry Jhnsn, Minnesta Department f Transprtatin, was the ENTERPRISE Prject Champin fr this effrt. The Prject Champin serves as the verall lead fr the prject. Prject Team Prject team members that prvided input t this Mdel Cncept f Operatins dcument included: Luke Biernbaum, Michigan DOT Kelly Braunig, Minnesta DOT Chris Brkes, Michigan DOT Kristi Ericksen, Kansas DOT Ry Hulli, Ontari Ministry f Transprtatin Cry Jhnsn, Minnesta DOT Sheila Jhnsn, Minnesta DOT Angie Kremer, Michigan DOT Jhn McCellan, Minnesta DOT Garrett Schreiner, Minnesta DOT Tim Simdynes, Iwa DOT Willy Srensn, Iwa DOT Sinclair Stlle, Iwa DOT Dave Tdy, Minnesta DOT Dug Tmlinsn, Pennsylvania DOT ENTERPRISE Members The ENTERPRISE Bard cnsists f a representative frm each f the fllwing member entities f the prgram. Gergia Department f Transprtatin Illinis Department f Transprtatin Iwa Department f Transprtatin Kansas Department f Transprtatin Michigan Department f Transprtatin Minnesta Department f Transprtatin Oklahma Department f Transprtatin Ontari Ministry f Transprtatin Pennsylvania Department f Transprtatin Texas Department f Transprtatin Transprt Canada USDOT Federal Highway Administratin ENTERPRISE Real-Time Integratin f Arrw Bard Messages int Traveler Infrmatin Systems i
Table f Cntents 1.0 Intrductin... 1 1.1 Backgrund Understanding the Challenge... 1 1.2 A Candidate Slutin... 1 1.3 The Visin... 1 1.4 Intent f This Prject... 2 1.5 Objective f This Dcument... 2 1.6 Cntext f this Dcument... 2 2.0 System Overview... 4 2.1 Arrw Bards... 4 2.2 Traveler Infrmatin Disseminatin Systems and Data Archives... 4 3.0 Stakehlders... 5 3.1 Primary Stakehlders... 5 3.2 Secndary Stakehlders... 6 4.0 Challenges... 7 5.0 Needs... 9 6.0 Operatinal Cncept... 19 6.1 Arrw Bard Reprting System Device Perspective... 19 6.2 Field Staff Perspective... 22 6.3 TMC Systems (ATMS, RCRS, and/r ther data prcessing systems) Perspective... 23 6.4 ATMS Operatr Staff Perspective... 25 6.5 RCRS Operatr Staff Perspective... 26 6.6 Archived Data Users Perspective... 27 7.0 Rles and Respnsibilities... 28 8.0 Scenaris... 30 8.1 Scenari 1: Arrw Bard Deplyment and Activatin... 30 8.2 Scenari 2: Arrw Bard Onging Reprting f Operatinal Status N Changes... 32 8.3 Scenari 3: Arrw Bard Onging Reprting f Operatinal Status Changes Identified... 33 8.4 Scenari 4: Arrw Bard De-activatin and Pwering Dwn... 34 8.5 Scenari 5: Nn-Real Time Data Use... 36 ENTERPRISE Real-Time Integratin f Arrw Bard Messages int Traveler Infrmatin Systems ii
1.0 Intrductin 1.1 Backgrund Understanding the Challenge Rad cnstructin and maintenance activities that require lane r shulder clsures are nt always reprted t peratins staff fr disseminatin t traveler infrmatin systems and the traveling public. The prvisin f cnstructin infrmatin t transprtatin management center (TMC) staff, particularly fr shrter duratin and/r mbile wrk znes, if any, can be challenging given the fast-changing and tempral nature f thse wrk znes. Details abut the timing f the lane clsures r the lcatin f the clsure in real time may vary with little ntice, but are needed fr psting specific messages fr the traveling public. Gathering and reprting infrmatin can be time cnsuming fr staff. When cnstructin infrmatin is knwn, TMC staff must ften manually enter it int Rad Cnditin Reprting Systems (RCRS). Likewise, assembling precise (i.e., detailed, timely, and accurate) infrmatin can be difficult and time cnsuming fr staff in the field wh have ther respnsibilities. Sme agencies require cntractrs t prvide realtime infrmatin frm the field with sme utilizing a specific smart phne applicatin fr this purpse, hwever getting this infrmatin n a cnsistent basis has remained a challenge. The current state f practice generally results in limited detailed infrmatin available fr agency use r traveler infrmatin. Lacking precise, cnsistent, and reliable details abut time and lcatin f wrk zne-related clsures, TMC staff can nly pst generic infrmatin t dynamic message signs (DMS) and traveler infrmatin disseminatin systems, if anything at all. Cnsequently, the traveling public ften has limited infrmatin abut lane clsures during r in advance f a trip. Additinally, agency practitiners desire mre detailed recrds n the start time, end time, and lcatin f lane clsures fr imprved pst wrk zne analysis f the transprtatin management plan (TMP) and perfrmance measurement. Given anticipated deplyment f cnnected vehicles, driver ntificatins f wrk znerelated lane clsures via in-vehicle displays ffer pprtunities fr increased safety, but als increases the need fr accurate infrmatin abut active lane clsures. 1.2 A Candidate Slutin Arrw bards are rutinely used in advance f active wrk znes t designate lane clsures in the field, and display the mst current infrmatin t appraching mtrists. Althugh n ff-the-shelf system currently autmatically integrates arrw bard statuses int traveler infrmatin mechanisms fr display t mtrists, available technlgy culd reprt the lcatin and peratin f Arrw Bards t TMC staff fr imprved traveler infrmatin disseminatin and perfrmance reprting, withut requiring significant time f agency staff in the field r at the TMC. 1.3 The Visin The visin f this prject is that in the near future, state and lcal DOTs will cmpetitively prcure systems t integrate Arrw Bard status infrmatin int existing and future traveler infrmatin systems. This visin will be recgnized by an initial set f agencies (the ENTERPRISE Pled Fund members) wrking tgether t define cmmn requirements fr systems t integrate Arrw Bard status infrmatin int traveler infrmatin systems that will enable Arrw Bard manufacturers and third party integratrs t develp systems t meet the needs f multiple agencies. ENTERPRISE Real-Time Integratin f Arrw Bard Messages int Traveler Infrmatin Systems 1
The primary benefits expected include: Imprved situatinal awareness by TMC peratrs f real-time lane clsures in the field; Detailed, cnsistent, and reliable real-time infrmatin abut lane clsures disseminated t travelers upstream f the clsure thrugh Dynamic Message Signs (DMS), traveler infrmatin mediums, and cnnected vehicle applicatins; Imprved prject management pprtunities, including the ability t verify cntractr wrk status t dcument lane clsure times fr use n lane rental prjects r enfrce restricted hurs r t crss check any lane clsure updates that are required f the cntractr; Increased archived data available fr evaluatin, perfrmance management, and research t better understand wrk zne mbility impacts and expsure fr reprting purpses, use fr future wrk zne planning effrts, analysis f TMPs, and fr perfrmance-based specificatins. Fundatinal cmmunicatin technlgy fr Arrw Bards t bradcast display status and lane clsure-related infrmatin t Cnnected and Autmated Vehicles. Depending n the amunt f manual invlvement by field staff, a secndary benefit f this system is the ptential fr faster respnse time in the field fr maintenance needs, including times when the Arrw Bard was hit by a passing vehicle r blwn ut f place by strng winds, given ntificatins t field staff f system functinality. The reprting f Arrw Bard usage may als imprve quality f the device, i.e., the system can reprt if the arrw bard is level and plumb, the lcatin can be mre readily verified by field persnnel. 1.4 Intent f This Prject The verall intent f the ENTERPRISE Integrating Active Wrk Zne Ntificatins int Traveler Infrmatin Disseminatin Mechanisms (Phase I) prject is fr multiple states t cllabrate t fllw a systems engineering prcess t develp an ITS slutin that integrates active wrk zne ntificatins regarding lane clsures frm Arrw Bards int agency traveler infrmatin disseminatin systems. During this prcess, the prject team identified a fcus n integrating real-time infrmatin frm Arrw Bards in the field; therefre, the Mdel Cn Ops dcument has been titled t reflect this fcus: Real- Time Integratin f Arrw Bard Messages int Traveler Infrmatin Systems: Mdel Cncept f Operatins. 1.5 Objective f This Dcument This mdel cncept f peratins (CnOps) presents an verview f the current system, identifies the relevant stakehlders, translates current challenges int specific needs, utlines an peratinal cncept, suggests likely rles and respnsibilities, and describes scenaris fr integrating active wrk zne lane clsure infrmatin frm Arrw Bards int agency traveler infrmatin disseminatin systems. 1.6 Cntext f this Dcument This dcument will serve as a fundatin fr the develpment f system requirements, which will cmplete Phase I activities. Existing requirements fr ITS devices r systems culd serve as examples t encurage standardized implementatin. Natinal-level requirements fr ITS cmmunicatins with the TMC, such as thse defined by the Natinal Transprtatin Cmmunicatins fr ITS Prtcl (NTCIP) 1203 fr DMS r 1207 fr ramp metering, might be adapted fr the develpment f requirements fr this ENTERPRISE Real-Time Integratin f Arrw Bard Messages int Traveler Infrmatin Systems 2
cncept as it pertains t Arrw Bards. Thus, as with all stages f the systems engineering prcess, nging stakehlder input and supprt is essential fr the successful develpment f a useful system that effectively addresses user needs. Phase II will subsequently evaluate existing system integratin deplyments and/r use these system engineering dcuments t supprt the deplyment, crdinatin, r evaluatin f deplyments f this technlgy. The purpse f Phase II will be t facilitate a deplyment f the Integrate Active Wrk Znes cncepts in ne r mre ENTERPRISE member states and evaluate the prcess, lessns learned and benefits. Specifically, the current plan is fr apprximately 5-10 Arrw Bard Reprting Systems t be deplyed in up t fur states fr apprximately six mnths; it shuld be nted that csts are smetimes higher fr pilt effrts f innvative technlgies than fr later, mre widespread deplyments. ENTERPRISE Real-Time Integratin f Arrw Bard Messages int Traveler Infrmatin Systems 3
2.0 System Overview The system f interest in this CnOps is cmprised f tw largely independent systems: 1) Arrw Bards and 2) traveler infrmatin disseminatin systems and data archives. This sectin prvides a brief descriptin f thse systems, as depicted in Figure 1. 2.1 Arrw Bards The Manual f Unifrm Traffic Cntrl Devices (MUTCD) includes recmmendatins fr the use f Arrw Bards t prvide warning and directinal infrmatin fr the traveling public thrugh a wrk zne with a lane r shulder clsure. As a pssible substitute, the MUTCD ntes that Prtable Dynamic Message Signs (PDMS) can als perfrm the rle f an Arrw Bard. Fr the purpses f this CnOps, references t Arrw Bards are inclusive f PDMS functining as an Arrw Bard, but nt PDMS perfrming ther functins. Arrw Bards are rutinely deplyed fr lane r shulder clsures n multi-lane radways. Arrw Bards are typically lcally perated, and are generally munted n either trailers r trucks; truckmunted Arrw Bards may be used fr mbile wrk znes. 2.2 Traveler Infrmatin Disseminatin Systems and Data Archives Traveler infrmatin disseminatin systems and data archives in this cntext cmprises the databases, rad cnditin reprting systems, and advanced traffic management systems used by transprtatin agencies t cllect, prcess, disseminate, and stre traffic data and infrmatin fr use by the traveling public and agency stakehlders. Specifically, this traveler infrmatin may be available via DMS, 511 phne r web, mbile apps, scial media, r as part f the cnnected vehicle envirnment. Incming data and psted infrmatin is frequently archived in a database fr sme perid f time fr later analysis, as needed. Figure 1: The systems f interest fr this CnOps include Prtable Arrw Bards, Rad Cnditin Reprting Systems, Advanced Traffic Management Systems, and traveler infrmatin disseminatin systems. ENTERPRISE Real-Time Integratin f Arrw Bard Messages int Traveler Infrmatin Systems 4
3.0 Stakehlders Fr this prject, stakehlders are defined as fllws: 3.1 Primary Stakehlders Primary stakehlders are direct end users f the eventual technlgy deplyed t integrate the infrmatin frm Arrw Bard Reprting Systems int traveler infrmatin disseminatin mechanisms. Additinally, these stakehlders are invlved in the develpment f the CnOps and Requirements, and will be influenced directly by the deplyment f Integrated Wrk Zne Ntificatin systems. Specific stakehlders described belw are mre gruped int fur mre general categries that are used thrughut this dcument: Transprtatin Management Center (TMC) staff, ITS vendrs and wners, field staff, and archived data users. TMC Staff Advanced Traffic Management System (ATMS) Operatr Staff. ATMS peratr staff are respnsible fr cntrlling the varius systems used t manage traffic. They are stakehlders t this prject because they ften are nt infrmed f temprary lane clsures and wuld benefit frm increased ntificatins f these lane clsures. They may react by psting messages n DMS upstream f the lane clsure, mnitring traffic cngestin upstream f the lane clsure, r by taking ther actins. Rad Cnditin Reprting System (RCRS) Operatr Staff. The department f transprtatin (DOT) staff members that are respnsible fr traveler infrmatin systems are stakehlders t this effrt because the systems they manage are intended t infrm travelers abut events impacting traffic, including lane clsures. While wrk zne activities are typically entered int RCRS t feed the varius traveler infrmatin disseminatin mediums, the wrk zne descriptins ften lack details abut temprary lane clsures. The systems deplyed as a result f this prject may create data and infrmatin that is autmatically inserted int RCRSs, r manually entered by a variety f staff respnsible fr creating traveler infrmatin. ITS Vendrs and Owners System Integratrs. These stakehlders include RCRS vendrs and ATMS vendrs, as well as any DOT staff, that will have a rle in mdifying the TMC systems per agency needs t accmmdate the new data cllectin, prcessing, and archiving requirements that supprt Arrw Bard Reprting System functinality. Equipment Owners. Equipment wners may be the DOT, wrk zne cntractrs, r ther vendrs wh facilitate the deplyment, and als verify and validate peratins f the Arrw Bard. They can assist with making the deplyment easy and simple fr ther users t perate, minimizing csts, and addressing security needs. Field Staff Arrw Bard Operatrs. Arrw Bard peratrs culd cnsist f either DOT staff, lcal agencies, utility cmpanies, r cntractrs and are identified as stakehlders because they are respnsible fr activating and maintaining Arrw Bards, and any field activities identified wuld be their respnsibility. ENTERPRISE Real-Time Integratin f Arrw Bard Messages int Traveler Infrmatin Systems 5
Wrk Zne Inspectrs. Wrk zne inspectrs are in the field and aware f the timing and lcatin f lane clsures in real time, versus the plans anticipated by the cntractr. These stakehlders culd verify lane clsures in ATMS r RCRS, r cnfirm generated email alerts, in rder t assist with calculating the lane rental fr the cntractr s perfrmance-based specificatins. Cnstructin Managers. Cnstructin managers are respnsible fr the verall wrk zne, but may als be respnsible fr several ther cnstructin sites and wuld benefit frm having alerts when nt n site. These stakehlders wuld need t receive real-time alerts when an Arrw Bard Reprting System is activated, as well as any status changes regarding display, lcatin, r being pwered dwn. Archived Data Users Wrk Zne Planners and Managers. Wrk zne planners and perfrmance management staff are stakehlders t this prject because they write specificatins, review the actual peratins f wrk znes, and cmpare actual peratins t what was planned in the Wrk Zne TMP. The infrmatin abut the start/end time and lcatins f lane clsures will assist in this analyses. Traffic Operatins Grup, Cngestin and Perfrmance Managers, and Archived Data Users. These stakehlders fcus n minimizing cngestin and cnduct analyses and review f archived data available, including that frm prtable r temprary systems used in wrk znes. These stakehlders als develp new perfrmance requirements that might be applied t wrk znes t minimize cngestin. Additinal stakehlders within this grup include researchers, MPOs, cntractrs, cntract administratrs, and cntract inspectrs wh may als be interested in accessing and analyzing archived data. 3.2 Secndary Stakehlders Secndary stakehlders are end users that d nt interface directly with the system but will benefit frm the infrmatin that becmes available as a result f the system integratin. Travelers. Travelers and ther cnsumers f the infrmatin such as law enfrcement and freight carriers are identified as a stakehlder grup in this prject. While they will nt interface directly with the Arrw Bard Reprting System data cmmunicatins, they will be the recipients f infrmatin disseminated n either TMC cntrlled DMS r traveler infrmatin systems. Third Party Infrmatin Disseminatin Prviders. Private sectr infrmatin service prviders that access data feeds frm the DOTs and disseminate infrmatin using their wn systems (e.g., Waze, Ggle) are secndary stakehlders in that the data feed they access at the DOTs will mst likely be enhanced t include the additinal detail abut lane clsures. ENTERPRISE Real-Time Integratin f Arrw Bard Messages int Traveler Infrmatin Systems 6
4.0 Challenges Identificatin f relevant challenges facing the stakehlders described abve will facilitate the specified needs and prvide cntext fr any ptential cnstraints t cnsider when defining the needs. Table 1: Challenges Facing Stakehlders # Challenges Facing Stakehlders 1 Details abut the lcatin and timing f lane clsures is difficult and time cnsuming t assemble int traveler infrmatin systems, ften resulting in general messages describing wrk zne impacts. 2 Traffic Management Center (TMC) Staff ften are nt aware when lane clsures begin, and therefre are nt able t pst messages n upstream DMS r take ther actins. 3 The exact timing and lcatins f lane clsures are ften nt knwn in advance, and field persnnel perfrming the radwrk and clsing the lanes have many ther respnsibilities such that manually reprting a lane clsure is ften nt pssible. 4 Travelers lack detailed infrmatin, and are nly given general infrmatin because knwn infrmatin is nt accurate enugh. 5 N ff the shelf equipment r cmmunicatins technlgy is currently available t autmatically cmmunicate lane clsures t a central lcatin. 6 Detailed recrds f the lcatin, start and end time fr lane clsures is nt always recrded, and this can impact the ability t d pst wrk zne analysis f the TMP and perfrmance measures. An Overarching Challenge f Acceptable Levels f Autmatin An additinal challenge facing stakehlders that will deply Arrw Bard Reprting Systems will be the degree t which the Arrw Bard messages received by the RCRS and ATMS systems are autmatically inserted int the systems versus manual verificatin r acceptance f messages. There is n debate abut the need fr Arrw Bards t reprt autmatically withut field staff activatin, but agencies will likely differ in their cmfrt level f disseminating infrmatin withut human verificatin. A prescribed apprach fr autmated r manual acceptance f messages is nt included in this dcument in rder t prvide flexibility fr agencies t adpt practices that are cnsistent with their current systems and cmfrt levels. There are several tradeffs that are wrthy f cnsideratin, fr example: In a fully autmated system where the agency TMC Systems accept Arrw Bard messages even if n ne can prvide visual verificatin, either in-persn r via traffic camera, there is an increased likelihd f false reprts, hwever this apprach will likely accmplish an increased number f reprts f lane clsures disseminated t travelers with minimal peratr invlvement. Full autmatin als depends n the capabilities f each agency s individual ATMS and/r RCRS. Agencies may experience challenges with accurately linking detailed Arrw Bard messages with higher-level ATMS and/r RCRS reprts that d nt require s much detail, which might hinder autmated reprting. A system that requires manual verificatin r message apprval befre messages are disseminated t the public will have a decreased likelihd f false reprts, but will have an increased likelihd that limited staff availability (r staff fatigue frm receiving ntificatins that are nt relevant t that individual) wuld cause mre Arrw Bard messages t be neglected and nt be psted t ATMS, RCRS, and/r traveler infrmatin disseminatin systems at all. Fr instance, given that many lane clsures ccur as a part f night-time wrk znes and nt all TMCs perate 24 hurs, requiring manual interventin by TMC staff culd limit the prvisin f traveler infrmatin. ENTERPRISE Real-Time Integratin f Arrw Bard Messages int Traveler Infrmatin Systems 7
The initial intent f this CnOps was t prvide fr a fully autmated system that culd infrm ATMS, RCRS, and/r traveler infrmatin disseminatin systems f shulder r lane clsures, with minimal manual interventin in rder t nt place additinal respnsibilities n staff that are already busy. Hwever, it is expected that peratr and/r field staff verificatin will ccur during acceptance testing t validate and gain cnfidence in the Arrw Bard reprts. After acceptance testing, sme agencies may pt fr a fully autmated system, while thers may nt be cmfrtable r cnfident in the accuracy f the Arrw Bard messages and cntinue t require verificatin. Fr example, sme agencies may leverage available CCTV camera cverage f the areas where Arrw Bards are used, r may rutinely have staff in the field, e.g., inspectrs r district staff, wh culd verify the Arrw Bard messages, althugh this may nt be an ptin fr ther agencies. Agencies might als cnsider requiring manual interventin by TMC staff during business hurs, and utilizing a mre autmated Arrw Bard Reprting System during hurs when the TMC is clsed. Anticipated Cnnected Vehicle Challenges In a cnnected and autmated vehicle envirnment, it is likely that Arrw Bard display status regarding lane clsures wuld be a valuable data input. The system develped as a part f this CnOps wuld prvide a fundatinal technlgy that culd be readily adapted fr use by cnnected and autmated vehicles in the future. ENTERPRISE Real-Time Integratin f Arrw Bard Messages int Traveler Infrmatin Systems 8
5.0 Needs Three categries f Stakehlder Needs have been identified, and are presented in Table 2, Table 3, and Table 4 belw: End User Stakehlder Needs describe the needs f end users f the infrmatin t be prvided frm the Arrw Bard Reprting Systems in the field. These needs are identified t address the challenges described abve. Stakehlder Needs Regarding Receiving and Prcessing Arrw Bard Reprting System Messages describe the needs fr functins t be autmatically r manually perfrmed t make use f data received frm Arrw Bard Reprting Systems in the field in rder t meet the End User stakehlder needs. In ther wrds, the functinality f the Arrw Bard Reprting Systems t send messages will need t be accmpanied by additinal functins perfrmed by ther DOT TMC Systems (e.g., ATMS, RCRS) t make use f the messages sent. Needs Regarding Functinality at the Arrw Bard Reprting Systems describe the needs that wuld need t be addressed by either the Arrw Bard r a related prduct cnnected t the Arrw Bard. Table 2: End User Stakehlder Needs 1. End User Stakehlder Needs 1-1 Traveler Infrmatin managers need near real-time ntices f lane clsures t be autmatically ingested int the Rad Cnditin Reprting System (RCRS) in rder t be disseminated thrugh the varius traveler infrmatin mediums fed by the RCRS (e.g., phne, web, mbile apps, scial media). Ntes: - DOTs will apprach this in different ways, e.g., sme will require peratr verificatin f the event after acceptance testing, thers may nt. - Lane clsures reprted by Arrw Bards may be prcessed by the RCRS and snapped t an existing Rad Wrk Event already in the system (perhaps adding a new element t the Event fr the current lane clsure). 1-2 TMC Operatrs need near real-time ntices f lane clsures t be autmatically ingested int their ATMS sftware in rder fr manual and/r autmated cnsideratin f upstream DMS messages. Nte: - In situatins where an autmated ingest int the ATMS is nt pssible, peratrs may receive ntices t be manually entered (see Need 1-3). ENTERPRISE Real-Time Integratin f Arrw Bard Messages int Traveler Infrmatin Systems 9
1-3 Sme TMC Operatrs and ther DOT staff such as wrk zne inspectrs and cnstructin managers need real-time trigger alert r ntificatin capabilities (e.g., email, pager, existing system display) t keep abreast f lane clsure activities and ptentially assess whether further actin is needed. Ntes: - This need addresses DOTs wh d nt establish autmated reprting int either the RCRS r ATMS, r DOTs wh als wish fr additinal users t receive ntices f the lane clsures. - Nte that lane clsure data frm the field may nly include latitude/lngitude values as the lcatin descriptin (as the snap f the latitude/lngitude t a DOT perated highway might happen in the RCRS r ATMS sftware). Therefre, these alerts might nt be user friendly. - If the field device r a prcessed message generated frm the RCRS r ATMS is able t cnvert the latitude/lngitude t highway ID and milepst befre sending, this wuld mre apprpriately address this need. - Majr changes in data received between successive messages culd indicate a cmmunicatin r ther failure in the field that requires maintenance r culd indicate the end f the active lane clsure, e.g., increased device speed, missed receipt f anticipated messages, display status change. 1-4 Wrk zne planning staff need t be able t access infrmatin describing the lcatin, start, and end time f lane clsures assciated with wrk znes in rder t perfrm pst-analyses. Ntes: - Analyses f wrk zne impacts and cmparisns f Transprtatin Management Plans (TMPs) against actual impacts wuld typically nt require near real-time access, but rather access t recent data (e.g., querying a mnth f lane clsures, r querying a specific highway ID) fr pst-analysis. - Planning staff may need mre real-time infrmatin if changes in the field are required when the wrk zne is active. 1-5 Stakehlders receiving near real-time ntices f lane clsures need t nt receive repetitive ntificatins f the same lane clsure event. Ntes: - This filtering t avid peratr verlad wuld mst likely ccur within the RCRS r ATMS sftware. - Peridic update ntificatins fllwing a reprted majr peratinal status change are expected. ENTERPRISE Real-Time Integratin f Arrw Bard Messages int Traveler Infrmatin Systems 10
1-6 Stakehlders receiving near real-time ntices f lane clsures need cnfirmatin that the lane clsure is n lnger active, and t have the event end in the ATMS r RCRS. Ntes: - Arrw Bards will peridically send updated messages t indicate peratinal status t TMC stakehlders. - T indicate the lane clsure is n lnger active r terminate the event in ATMS r RCRS, ne f the fllwing will ccur: Arrw Bard will send an end message when turned ff prir t pwering dwn. The device cmmunicatin mechanism may remain n given the prvisin f a pwer surce, and als prvide lcatin and battery status when the Arrw Bard is inactive. Arrw Bard message will include rientatin f sign t indicate whether it is visible t passing mtrists, r in a dwn psitin that wuld indicate that the lane clsure is n lnger active and terminate the event. Arrw Bard message will include lcatin, such that the speed f the device can be calculated between the receipt f tw messages, which culd indicate it is traveling t fast t be part f a mbile wrk zne. System culd generate an autmatic message after several missed messages frm Arrw Bard fr field staff t cnfirm that the device has been turned ff and the event has ended, versus a cmmunicatin r pwer failure. 1-7 Stakehlders receiving near real-time ntices f lane clsures need t be presented with infrmatin describing: the radway where the clsure is ccurring, the lane clsure descriptin, directin f travel, and the number f lanes clsed. Ntes: - This infrmatin may be derived frm data received frm ne r mre Arrw Bards that is prcessed in the TMC befre being viewed by peratrs. - Arrw Bard data will include, at a minimum: Latitude and lngitude f the Arrw Bard sign (i.e., t indicate milepst, and derive speed f sign, if applicable, frm cnsecutive messages) If latitude and lngitude is nt precise enugh t ascertain directin, a cmpass reading r suitable alternative will be included Arrw Bard rientatin (i.e., visible t traffic r dwn) Arrw Bard status message (e.g., thse listed in the MUTCD: left r right flashing, sequential, r flashing duble arrw; left r right sequential chevrn; flashing cautin; r alternating diamnd cautin) Timestamp f transmissin Device ID - The number f lanes clsed will be autmatically determined based n the number f Arrw Bards reprting the same arrw directin frm near the same lcatin (i.e., ne Arrw Bard is needed t clse each lane). - The identificatin f multiple Arrw Bards reprting cautin mde will be interpreted as redundant, e.g., being used within a lane clsure where n additinal lane is clsed. ENTERPRISE Real-Time Integratin f Arrw Bard Messages int Traveler Infrmatin Systems 11
1-8 Stakehlders need t be ntified if the lane clsure is part f a mbile wrk zne and is in mtin alng the radway. Ntes: - The Arrw Bard itself wuld reprt status and psitin at a regular frequency. - The determinatin f whether it is a mbile wrk zne r nt wuld mst likely need t be derived by the RCRS r ATMS. - The pre-determined speed threshlds fr ascertaining a mbile wrk zne vs. traveling dwn the radway may vary by rad type (e.g., interstate, arterial) and lcatin (e.g., urban vs. rural). - It is pssible that a device attached t an Arrw Bard may classify it as a mbile wrk zne, but this feature wuld likely nt be available with all prducts. In rder t accmplish the abve End User Stakehlder Needs, a series f needs were derived fr functins t be perfrmed by varius systems r peratrs when receiving and prcessing Arrw Bard messages. These varius systems and peratrs are referred t as stakehlders in Table 3. Table 3: Stakehlder Needs Regarding Receiving and Prcessing Arrw Bard messages 2. Stakehlder Needs Regarding Receiving and Prcessing Arrw Bard Messages 2-1 Stakehlders need a mechanism t receive wireless cmmunicatins frm Arrw Bards and stre the messages/data that are transmitted. Ntes: - Data must arrive in a useful manner fr prcessing by the ATMS and/r RCRS (e.g., a text message received via phne wuld nt allw access by the ATMS r RCRS). - Data may be received by request, via a prxy server, and/r directly frm the Arrw Bard n its wn timing. 2-2 Stakehlders need a mechanism t autmatically prcess the Device ID received in the Arrw Bard message. Ntes: - Supprts Need 1-5 - The Device ID can be referenced in lgs fr the ATMS and RCRS t recgnize if this lane clsure reprt has already been received with a ntificatin prvided t peratrs, and fr cmparisn f new data t previusly received data and psted infrmatin. - The Device ID may be used t lk up the prduct type in rder t prcess an Arrw Bard status cde. - Device ID (with lkup table fr Device ID t include items such as manufacturer, mdel, and wner f the Arrw Bard) may be prcessed against a lkup table f devices in rder t determine the DOT shp it is assigned t. ENTERPRISE Real-Time Integratin f Arrw Bard Messages int Traveler Infrmatin Systems 12
2-3 Stakehlders need a mechanism t autmatically prcess the lcatin received as part f the Arrw Bard message. Ntes: - Supprts Need 1-7 - Arrw Bards may nly reprt latitude/lngitude, s the ATMS, RCRS, r ther system must be able t snap a latitude/lngitude t the apprpriate radway and milepst, and minimize situatins where an incrrect rad is identified t the extent pssible. - This is typically a functin perfrmed by RCRSs and ATMS (fr example, this is currently dne when RCRSs ingest law enfrcement CAD reprts). - If the DOT is planning t send lane clsure alerts t thers (beynd thse with ATMS r RCRS access) this same snap t a highway wuld need t be perfrmed. 2-4 Stakehlders need a mechanism t autmatically prcess the status f the Arrw Bard, as received in the message. Ntes: - Supprts Need 1-7 - Sme Arrw Bards may utput and send the status as a message describing the Arrw Bard display (e.g., Right Arrw ). - It is recgnized that if there is limited prcessing at the Arrw Bard befre the message is sent, this might simply include a status cde describing the Arrw Bard status selected by field peratrs (e.g., Optin A is selected n the dial which activates the left arrw display ). - Status ptins are expected t incrprate thse frm the MUTCD, and include: Right flashing arrw, sequential arrw, flashing duble arrw, r sequential chevrns Left flashing arrw, sequential arrw, flashing duble arrw, r sequential chevrns Flashing cautin r alternating diamnd cautin t indicate cautin within existing clsure area and shulder wrk Others in cmpliance with MUTCD Figure 6F-6 Errr Off r blank - If nly a status cde is sent frm the Arrw Bard, and if different vendrs use different status cdes, then the Device ID will be required t lk up the vendr and interpret the status cde. 2-5 Stakehlders need a mechanism t autmatically prcess the timestamp, as received in the message. Ntes: - Supprts Needs 1-5, 1-7 - The timestamp f the first message sent describing an Arrw Bard being activated wuld need t be assigned t Events entered int either the ATMS r RCRS as the Event Start Time. ENTERPRISE Real-Time Integratin f Arrw Bard Messages int Traveler Infrmatin Systems 13
2-6 Stakehlders need a mechanism t autmatically prcess received data t determine the directin f travel (describing the directin the Arrw Bard is facing). Ntes: - Supprts Need 1-7 - The system may need t prcess the data received regarding the Arrw Bard status frm the status cde (e.g., right lane clsed) in additin t the latitude/lngitude data with sufficient accuracy, cmpass reading, and/r a suitable alternative t determine the directin f travel. - Alternatively, Arrw Bard functinality culd determine directin f travel, allwing the ATMS, RCRS, r ther system t validate the directin f travel. 2-7 Stakehlders need a mechanism t autmatically maintain a histry f messages sent frm each Arrw Bard Device ID, in rder t determine if this is a newly activated device r a recurring message received fr an active Arrw Bard. Ntes: - Supprts Need 1-5 - This is t enable the ATMS r RCRS t recgnize an already lgged lane clsure and nt repetitively ntify peratrs. - The message exchange prtcl and standard culd include a field t indicate that this is an update message. - In lieu f an indicatin it is an update message, Device ID, lcatin, and status f display culd be used t derive if it is a new deplyment r update. 2-8 Stakehlders need a mechanism t autmatically determine if an Arrw Bard is invlved in a mbile Wrk Zne. Ntes: - Supprts Need 1-8 - The system will calculate speed based n received latitude/lngitude and device timestamp infrmatin frm tw messages - If speed is calculated as slwer than the typical lcal traffic speed fr the rad type (e.g., interstate, arterial) and lcatin (e.g., urban vs. rural), the device will be assumed t be invlved in a mbile wrk zne - This wuld likely be a functin f the ATMS r RCRS 2-9 Stakehlders need a mechanism t autmatically determine when an Arrw Bard has been mved t a new lcatin, and peratrs shuld be ntified that it may n lnger be displaying in the same lcatin and rientatin, as riginally placed. Ntes: - Supprts Need 1-6 - This is fr situatins where the Arrw Bard may have been mved frm the riginal lcatin, either ff the rad/shulder and is n lnger visible t drivers r t a new functining lcatin. - This needs t accmmdate fr the ptential t receive variatins in latitude/lngitude data describing the lcatin when in fact n mvement has ccurred. ENTERPRISE Real-Time Integratin f Arrw Bard Messages int Traveler Infrmatin Systems 14
2-10 Stakehlders need a mechanism t autmatically determine when an Arrw Bard reprt is n lnger active. Ntes: - This is t enable peratrs r systems t remve messages abut lane clsures frm upstream DMS r traveler infrmatin disseminatin systems. - Supprts Need 1-6 and 3-10. - Arrw Bard will be determined t be n lnger active given the fllwing: Arrw Bard sign in a dwn psitin. The calculated speed f the device is t fast fr the device t be active as part f a mbile wrk zne. Arrw Bard transmits a message indicating a blank display status. Receipt f a message frm the device cmmunicatin mechanism assembled as part f the shutdwn, ntifying that the device is turned ff. In lieu f a turned ff message, the system will assume the Arrw Bard is n lnger active after several missed messages. - Optinal: The system may generate an autmatic message after several missed messages frm the Arrw Bard Reprting System fr field staff t investigate a maintenance need (i.e., cmmunicatin r pwer failure), r cnfirm that the device has been turned ff and the event has ended. - Optinal: The device cmmunicatin mechanism may remain n given the prvisin f a pwer surce, and als prvide lcatin and battery status when the Arrw Bard is inactive. 2-11 Stakehlders need Arrw Bard messages t be archived t a query-based database t enable Wrk Zne management staff access t specific details and statistics abut lane clsures. Ntes: - This is related t enabling the data generated by the Arrw Bard t be accessed and used by individuals respnsible fr wrk zne perfrmance and planning fr future wrk znes. 2-12 Stakehlders need a mechanism t autmatically add a timestamp fr when Arrw Bard messages are received. Ntes: - This is in additin t the timestamp created at the device in rder t determine latency using archived data fr pst analysis. ENTERPRISE Real-Time Integratin f Arrw Bard Messages int Traveler Infrmatin Systems 15
Table 4 describes the stakehlder needs fr functins t be perfrmed by the Arrw Bards. Table 4: Stakehlder Needs Regarding Functinality at the Arrw Bards 3. Stakehlder Needs Regarding Functinality at the Arrw Bards 3-1 Stakehlders need the Integratin f Active Wrk Zne Ntificatins t be fully autmated, with n reliance n field persnnel t activate r enter infrmatin, beynd what they currently d t turn n and cnfigure the Arrw Bard. Ntes: - Wrk zne staff time is ccupied with wrk zne and safety related actins. - Dependence n field staff intrduces ptential fr the ntices t nt be sent fr each lane clsure. 3-2 Stakehlders need an initial message t be available upn the Arrw Bard being activated, with data describing the Arrw Bard activatin. Ntes: - This wuld be an initial message describing a newly activated device - May be transmitted autmatically t a prxy server r in respnse t a ping frm the central system. - As an example, cellular mdems culd be used t cnnect and send data. - Culd include a handshake cnfirmatin 3-3 Stakehlders need peridic messages t be available indicating the cntinued status f the Arrw Bard device. Ntes: - The Arrw Bard device may autmatically send the messages t a prxy server r the system (i.e., ATMS, RCRS, r bth) may pull messages frm the device. - This will allw TMC staff r an RCRS t validate that the Arrw Bard is still actively displaying the message. - This wuld invlve the receiving system(s) t maintain a histry f transmissins t track and determine if smething has changed. - Message transmissin frequency will vary based n wrk zne duratin and type: Initial default frequency will be every 5 minutes, at a minimum. Transmissin frequency may be reduced fr a lnger, statinary deplyment (e.g., hurly reprting after fur hurs f activatin). Transmissin frequency will be increased t every 10 secnds, at a minimum, when the system determines frm successive messages that the currently active Arrw Bard is mving at a speed reasnably assumed t be part f a mbile wrk zne. 3-4 Stakehlders need all messages sent frm Arrw Bards t include a device ID. Ntes: - Device ID may be assigned at the device cmmunicatins mechanism attached t the device. - This wuld be used t manage multiple messages received and maintain histry f which devices are lcated where. 3-5 Stakehlders need all messages created by Arrw Bards t include a timestamp. Ntes: This is the time that the data is assembled at the device ENTERPRISE Real-Time Integratin f Arrw Bard Messages int Traveler Infrmatin Systems 16
3-6 Stakehlders need all messages sent frm currently active Arrw Bards t include the display status f the device (status f device refers t what is displayed n the Arrw Bard). Ntes: - Given ptentially limited prcessing capabilities at the Arrw Bard, this may be a status cde describing the status selected by field peratrs (e.g., Optin A is selected n the dial is knwn t activate the left arrw display ). - Given prcessing capabilities at the Arrw Bard, the sent message may include a pre-defined descriptin (e.g., right arrw ). - Status ptins are expected t incrprate thse frm the MUTCD, and include: Right flashing arrw, sequential arrw, flashing duble arrw, r sequential chevrns Left flashing arrw, sequential arrw, flashing duble arrw, r sequential chevrns Flashing cautin r alternating diamnd cautin t indicate cautin within existing clsure area and shulder wrk Others in cmpliance with MUTCD Figure 6F-6. Errr Off r blank - Field persnnel typically select a setting n the Arrw Bard. - The status cdes fr Arrw Bards will likely differ by vendr, therefre the Device ID wuld be used t interpret any status cdes sent frm the Arrw Bard. - When a PDMS is used as an Arrw Bard, a different type f status cde r text descriptin may be sent frm the PDMS. 3-7 Stakehlders need all messages sent frm Arrw Bards t include the lcatin f the Arrw Bard described using a Gespatial descriptin. Ntes: - The Arrw Bard must include latitude/lngitude infrmatin in the message t enable central systems t determine radway and milepst. - The device cmmunicatin mechanism internal GPS culd prvide this data. 3-8 Stakehlders need all messages sent frm currently active Arrw Bards t have data fr determinatin f directin f travel. Ntes: - A cmpass reading wuld satisfy this requirement, but is nt a feature all Arrw Bards have. - In lieu f a cmpass reading, lcatin accuracy r a suitable alternative must be sufficient t determine directin f travel f the lane r shulder clsure, including a shulder clsure n a tw-lane radway. 3-9 Stakehlders need all messages sent frm Arrw Bards t include display rientatin. Ntes: - Orientatin f Arrw Bard display will indicate whether r nt it is visible t passing mtrists. Fr example, an arrw bard display may be in a dwn psitin r in anther rientatin psitin where the display is nt visible t passing mtrists, therefre indicating that the lane clsure is n lnger active. ENTERPRISE Real-Time Integratin f Arrw Bard Messages int Traveler Infrmatin Systems 17
3-10 Stakehlders need data frm the Arrw Bard t understand when it is n lnger active. Ntes: - Data must sufficiently infrm peratrs r systems t remve messages abut lane clsures frm upstream DMS r traveler infrmatin disseminatin systems. - Respecting Need 3-1, data will supprt an autmatic determinatin. - Supprts Need 1-6 and 2-10. - Understanding f Arrw Bard status will be made based n the fllwing: Per Need 3-9, Arrw Bard signs in a dwn psitin wuld indicate that the lane clsure is n lnger active. Given Need 3-7, the speed f the device can be calculated by the system, given the lcatin f the device in tw messages, t indicate it is traveling t fast t be active as part f a mbile wrk zne. The pre-determined speed threshlds fr ascertaining a mbile wrk zne vs. traveling dwn the radway may vary by rad type (e.g., interstate, arterial) and lcatin (e.g., urban vs. rural). Given Need 3-6, Arrw Bards that send a message abut ff r blank display status wuld indicate the lane clsure is n lnger active. When the Arrw Bard display is turned ff, the device cmmunicatin mechanism may assemble ne last message fr transmissin as part f the shutdwn, ntifying the Arrw Bard is turned ff. In lieu f a turned ff message, the system culd assume the Arrw Bard is n lnger active after several missed messages. The device cmmunicatin mechanism may remain n given the prvisin f a pwer surce, and als prvide lcatin and battery status when the Arrw Bard is inactive. Mre bradly, data may als indicate when an Arrw Bard is being placed ut f service. 3-11 In situatins where multiple Arrw Bards are activated fr a multiple lane and/r shulder clsure, Stakehlders need all Arrw Bards deplyed within a chesive wrk zne t transmit status messages. Ntes: - This allws TMC Systems receiving the messages t determine that multiple lanes are clsed (i.e., tw devices displaying left arrws wuld indicate the right tw lanes are clsed). - This wuld likely be determined by TMC Systems based n the lcatin and prximity f adjacent Arrw Bards n the same radway and facing the same directin. ENTERPRISE Real-Time Integratin f Arrw Bard Messages int Traveler Infrmatin Systems 18
6.0 Operatinal Cncept The peratinal cncept is presented belw t detail hw the new system will impact the rles and respnsibilities f field staff, ATMS peratr staff, and RCRS peratr staff. The changes experienced frm the perspective f equipped Arrw Bard devices and the TMC Systems, i.e., back-ffice data gathering and prcessing systems such as ATMS, RCRS, and/r ther systems, are als presented. While the majrity f cncepts presented belw describe actins using will statements, there are several instances where may is used. This is partially because this dcument is a mdel CnOps t be used by agencies wh will differ in the apprach t sme aspects, either based n systems used by their agency r their selected apprach t integrating f Arrw Bard reprts. One area where the apprach t integrating Arrw Bard reprts is likely t vary by agency is the extent t which each agency is cmfrtable with a fully (r near fully) autmated prcess f messages being cmmunicated frm the Arrw Bard and integrated int the RCRS and/r ATMS systems withut peratr verificatin. It is expected that agencies might initially adpt a prcess f manual apprval f messages, particularly during acceptance testing, but ver time, as cmfrt increases, they wuld transitin t accepting a mre autmated apprach. The autmated vs. manually verified synpsis represents a pssible cnflict in needs, where a pssible need t nt disseminate unverified infrmatin cnflicts with the need t increase the infrmatin delivery while nt increasing demand n existing staff. This cnflict is particularly pignant fr agencies that d nt have 24-hur TMC peratins with staff available t manually verify Arrw Bard messages frm ff-hur, night-time wrk znes that have lane clsures. 6.1 Arrw Bard Reprting System Device Perspective The Arrw Bard device is deplyed, tested, and activated in the field as in the current state (i.e., with n functinality t cmmunicate its status beynd lcally, t ncming traffic), with the exceptin that it is equipped with an Arrw Bard Reprting System. The Arrw Bard Reprting System will vary in design by manufacturers, but is likely t include a physical device that is either attached t the Arrw Bard r included as part f the Arrw Bard. The Arrw Bard Reprting System will invlve wireless cmmunicatins capabilities, which culd include a lcal, ne-way cmmunicatin bradcast (e.g., via DSRC r ther suitable cmmunicatin methd) t enable future cnnected vehicle applicatins, and a centrally lcated server t perfrm sme pst-prcessing f the data befre it is relayed t TMC Systems, which includes ATMS, RCRS, and/r ther related back-ffice data prcessing systems. The centrally lcated server culd be any f a variety f cnfiguratins, ranging frm vendr specific central servers supprting multiple states, t a state r lcal DOT perated server supprting multiple vendr Arrw Bards. Figure 2 illustrates examples f the pssible ptins fr Arrw Bard Reprting Systems functinality. ENTERPRISE Real-Time Integratin f Arrw Bard Messages int Traveler Infrmatin Systems 19
Figure 2: Illustratin f Pssible Optins fr Arrw Bard Reprting Systems The fllwing sectin defines the peratinal cncept frm the perspective f the entire Arrw Bard Reprting System (field device and central prcessing). 6.1.1 When an Arrw Bard device equipped with autmated reprting functinality (i.e., an Arrw Bard Reprting System) is activated by field persnnel, the Arrw Bard Reprting System will deliver r make available an initial message t reprt the Arrw Bard device ID, lcatin, directin f travel, display status, and rientatin. This message will be used by the TMC Systems, hwever a lcal, ne-way cmmunicatin bradcast f this infrmatin (e.g., via DSRC r ther suitable cmmunicatin methd) may als be desired fr use by field staff r t supprt cnnected vehicle applicatins (Needs 3-1, 3-2, 3-4, 3-5, 3-6, 3-7, 3-8, 3-9) 6.1.2 The Arrw Bard Reprting System cmmunicatins and data exchanges will either be directly t a DOT perated server r t a prxy server established between the Arrw Bard and the DOT TMC Systems. (Need 2-1) 6.1.3 As equipped Arrw Bard Reprting Systems cntinue t perate, they will peridically cllect and re-send all critical infrmatin t the DOT TMC Systems. (Needs 3-3, 3-4, 3-5, 3-6, 3-7, 3-8, 3-9) 6.1.4 With each message sent by the Arrw Bard Reprting System t the DOT TMC Systems, the Arrw Bard Reprting System will include a Device ID. (Need 3-4) ENTERPRISE Real-Time Integratin f Arrw Bard Messages int Traveler Infrmatin Systems 20
6.1.5 The Arrw Bard Reprting System will generate an Arrw Bard status message and include the status message with each message delivered t the TMC Systems. (Need 3-6) The status message will describe the current display f the Arrw Bard device, as ne f the fllwing ptins: Right flashing arrw, sequential arrw, flashing duble arrw, r sequential chevrns Left flashing arrw, sequential arrw, flashing duble arrw, r sequential chevrns Flashing cautin r alternating diamnd cautin t indicate cautin within existing clsure area and shulder wrk Others in cmpliance with MUTCD Figure 6F-6. Errr Off r blank 6.1.6 The Arrw Bard Reprting System will determine the lcatin f the Arrw Bard device and include the lcatin with each message delivered t the TMC Systems. The lcatin will include the latitude/lngitude f the Arrw Bard device, as a minimum. In additin, the lcatin may include a text descriptin f the lcatin (e.g., rad and mile pint, r nearest address). (Need 1-7, 3-7) 6.1.7 The Arrw Bard Reprting System will determine the directin f travel that the Arrw Bard device display is facing and include the directin f travel with each message delivered t the TMC Systems. (Nte: In the event that an Arrw Bard Reprting System is nt equipped t determine directin f travel, the TMC Systems will determine directin f travel.) (Need 1-7, 3-8) 6.1.8 The Arrw Bard Reprting System will determine the display rientatin f the Arrw Bard device and include the rientatin descriptin with each message delivered t the TMC Systems. The rientatin will describe whether the Arrw Bard device display is visible t mtrists, r in a dwn psitin, which may vary depending n the Arrw Bard manufacturer. (Need 3-9) 6.1.9 As field staff turn the Arrw Bard ff, the Arrw Bard Reprting System will send a message t the TMC Systems indicating that the message is n lnger active. If this functinality is nt pssible with the selected Arrw Bard Reprting System, alternate slutins (e.g., the central system inferring the system is turned ff after nt receiving an updated status) may be emplyed. The device cmmunicatin mechanism may remain n given the prvisin f a pwer surce, and als prvide lcatin and battery status when the Arrw Bard is inactive. (Needs 2-10, 3-4, 3-5, 3-6, 3-7, 3-8, 3-9, 3-10) 6.1.10 The Arrw Bard Reprting System may autmatically generate and send a message directly t field staff, ATMS peratr staff, and RCRS peratr staff when data is reprted by the Arrw Bard Reprting System, using a medium such as text message, pager, r email. The apprach t sending alerts t staff will likely be determined at each lcatin, and will need t identify a mechanism that enables specific individuals t receive ntices abut Arrw Bard device activatins f interest t them while nt being verwhelmed with ntices f Arrw Bards utside their jurisdictin. This functinality may als be perfrmed by the ATMS and/r RCRS perated by the agency. (Need 1-3) 6.1.11 The Arrw Bard Reprting System may generate system functinality status messages (e.g., errr cdes) t indicate when basic system functins are nt perfrming prperly. System ENTERPRISE Real-Time Integratin f Arrw Bard Messages int Traveler Infrmatin Systems 21