SNUG 2013 CTOC Bluetooth Travel Time Trial SH1 / SH76 Napier, November 2013

Outline of This Presentation This presentation is to intended to give you an overview of how CTOC are planning to use AraFlow Bluetooth tracking to provide travel-time and incident alerts for SH1 & SH76/74.

History When I volunteered to do this presentation, AraFlow had installed Phase One of the Bluetooth Travel Time System, and intended to have Phase Two installed and operational by the time SNUG came around. Since then, a lot has happened, and AraFlow have discovered how difficult it is to get Temporary Traffic Management providers in Christchurch, and how difficult Orion can be when trying to arrange lots of small connections to their network. And I’ve discovered how inflexible and out-of-date some of the NZTA VMS standards are!

Bluetooth - Background Bluetooth ‘sniffing’ has been around for a while, and we now have a situation whereby there are multiple providers in NZ. For our purposes, we considered two providers, Beca with BlipTrack, and AraFlow with their system.

Bluetooth – The Suppliers – Beca & BlipTrack The Beca solution had a number of Pro’s & Con’s Pro’s – Tried & Proven International Solution The power of Beca Transport consultants behind it to churn the data Con’s – Purchase price high for technology that will date quickly Recurrent costs from Beca despite CTOC owning the asset Lease options were designed around short-term, small-scale deployment, so worked out very expensive to be usable on a large enough scale No examples of data being directly used to operate EJT (Electronic Journey Time) systems or incident alerts.

Bluetooth – The Suppliers – AraFlow The AraFlow solution had a number of Pro’s & Con’s Pro’s – Local solution from an innovative technology manufacturer with a known reputation (HMI Industries) AraFlow are traffic consultants with an ITS emphasis HMI have experience with manufacturing & maintaining VMS signs, and the systems required to make them operate The entire AraFlow system can be leased as a service, removing large capital outlays and Asset Management requirements Con’s – A new solution, with little deployment history Some technical risk due to the requirement to ‘stitch-together’ several disconnected, but existing HMI products.

AraFlow Bluetooth Unit

The Solution – Phase One Phase One was to get an idea of how many Bluetooth units would be ‘sniffed’, and whether the AraFlow systems would be able to provide the information we required. The AraFlow business model is a lease-only model, which has the benefit of reducing risk for CTOC, giving a provider of data that we can send ‘public’ enquiries to, and the benefit of reduced costs and shorter time commitments. We opted to run Phase One for 12 months, to get an idea of the hit-rate, and usability of the system. As this was for trial purposes, we only installed sensors at each end of the route. This reduces the accuracy of travel time (as we don’t know about vehicles going off-route etc) but kept the trial costs down.

Phase One – The Results Current Travel Time by direction ‘Heat Map’

Phase One – The Results The results we got from Phase One were very encouraging. We could see individual hits from each sensor, and were obtaining several hundred hits an hour during peak times. We also saw (as expected) that while many vehicles were sniffed at one end or the other, a significant percentage of vehicles didn’t make the trip from one end of the route to the other, or didn’t make the journey directly.

Phase One – The Results

Speed

Phase One – The Results Travel Time

Phase One – The Results CSV Export

Phase One – The Results – Aggregated Data

Phase Two – SH1 / SH76 Phase Two involved the installation of Bluetooth Sensors along SH1 & SH76, with the intention of providing real-time EJT on 3x VMS’s, and presenting travel times & 6 VMS’s on TransportFor Christchurch.

Phase Two – Planning In addition to EJT and heat-mapping, we also require the AraFlow system to produce alerts for suspected incidents along these routes. This is achieved by the system calculating the current travel time, and comparing this with historical data for the time of day. This is to reduce the need for an operator to constantly monitor the data back from the system. Where VMS are fitted they must be easily readable, and nationally consistent. They must also have the ability to have the EJT’s overridden by incident messages, which CTOC operators must be able to load. And they must be able to run for up to 10 hours on battery power in the event of a power failure (not that that would ever happen ).

Phase Two – VMS Requirements In order to ensure quick deployment, and cost efficiencies, we wanted to use a standard HMI VMS. This would also provide known hardware, to standard consistent dimensions, as used elsewhere in NZ. We settled on the HMI ‘Type D’ VMS, similar to that used by NZTA & AT in Auckland. We went through a ‘straw-poll’ with staff around the office to quiz them on all the issues that they dislike with VMS boards, as Chch currently has a lot of VMS’s installed at SCIRT sites. The main theme that we got was that scrolling (or flashing) messages were hard to read, especially for older people, or those with reduced vision. Another issue people have is where a board primarily displays one message, but sometimes displays another that is almost the same to look at. This requires reading the sign every time you see it, to work out what the message is this time.

Phase Two – VMS Solution To meet these criteria, we decided that 4 lines should be displayed for EJT, with the destination being the same for that sign every day. As the destinations would always be consistent, we expect that drivers will always look at the same line each time they pass the sign. This would allow us to have 4 lines of text (ie 4 destinations), and use proportional font to allow longer place names. And for event messaging, we could change to three lines of text, with larger font, and wider gaps between rows. This would be instantly recognisable as a different message, and attract more attention. Unfortunately four lines doesn’t meet the NZTA VMS standard. This produced some issues for us, but eventually we got acceptance that ‘as a trial’ we could use 4 lines of text for the EJT.

Phase Two – VMS Solution The next problem we had to consider was the structure of the incident messages. We eventually agreed on a format of – Line 1 – Event Type Line 2 – Location Line 3 – What to do We summarise this as What, Where, So What? Unfortunately, again, these messages wouldn’t fit on the HMI Type D signs if complying with the NZTA VMS event messaging standards. We managed to work around this issue by meeting the NZTA standard for trailer-mounted VMS’s, and used the argument that this was simply a trailer-mounted type VMS on a permanent pole…

Phase Two – VMS Solution – EJT Display VMS Signs displaying 4 line EJT As you can see, the proportional font is still quite clear, but allows a greater gap between the place name and the travel time There are also no readability issues with the four lines of text, and being a static destination display, there are no scrolling screens to deal with.

Phase Two – VMS Solution – Incident Messaging VMS Signs showing incident messaging The larger font and bigger gaps make the incident message easier to read, and also have quite a distinctly different look from the EJT display This also shows another issue, in that we have to abbreviate some of our place names. We are still working at getting full acceptance of some of our abbreviations.

Creating An Incident Message What Where So What? Set Duration Post Message

Phase Two As I mentioned earlier, we experienced delays which have resulted in the system not being fully installed yet. So unfortunately I can’t show you anything yet. But, I’m really looking forward to getting this extra tool in the tool-box, and am looking forward to receiving customer feedback on the VMS’s, and the virtual VMS’s on the website.

Bluetooth – The Suppliers – AraFlow The AraFlow solution had a number of Pro’s & Con’s Pro’s – Local solution from an innovative technology manufacturer with a known reputation (HMI Industries) AraFlow are traffic consultants with an ITS emphasis HMI have experience with manufacturing & maintaining VMS signs, and the systems required to make them operate The entire AraFlow system can be leased as a service, removing large capital outlays and Asset Management requirements Con’s – A new solution, with little deployment history Some technical risk due to the requirement to ‘stitch-together’ several disconnected, but existing HMI products. I’m excited that I’ve been involved with the development of this system, and have seen it grow beyond the ‘cons’ above to almost a working system!

Thank You - Questions