Figure 1: The NZTA's Strategic Vision for travel information delivery
RSS6296 New Zealand Transport Agency (NZTA) (formerly Transit New Zealand) has faced challenges in communicating effectively with road users, its customers, about highway-related events or incidents in a timely, accurate manner. Prior to 2007, Transit relied on a third-party organisation to collect and disseminate national road condition information. This often resulted in incomplete information being supplied to road users.
The NZ Transport Strategy, updated in 2008, emphasises the need to maximise the transport network's efficiency whilst providing access to good, reliable, timely travel information. A Strategic Vision was developed for delivery (Figure 1), fundamental to which are establishment of the Traffic Road Event Information System (TREIS) and replacement of the NZTA's existing traffic management software.
The new national TMS will not only drive the existing traffic management field devices in Auckland and Wellington but will be expandable to at least three other major urban areas. It will also provide support for a national system of Variable Message Signs (VMS) on vulnerable parts of the state highway network. Bidders needed to take into account present and future functionalities, including: CCTV (analogue control); VMS and lane control signals; moveable lane barrier operations; vehicle counts; ramp metering (signals); emergency telephones; a faults system; web interfaces and webcams; weather; and an incident management system. In future, the system will need to support: IP-based digital video transmission; advanced incident management; interfacing with SCATS for interchanges; tunnel management systems; wider incident detection management; vehicle recognition; weigh in motion; remote CCTV and VMS; traveller information including signs, radio, telephone and web; other dynamic lane management; and traffic management associated with toll roads.
A fully interactive process was used and as both parties were based outside NZ they were invited to visit for a period to get a full understanding of the project requirements. They gained a full understanding of the outputs required for Wellington and Auckland and discussed needs, risks and opportunities with operators and others. The onus was on the shortlisted parties to develop their own methodologies and implementation plans.
The evaluation team then visited nominated sites in Australia and the US where the systems could be seen in operation. At the conclusion of each visit, the parties were invited to make a three-hour presentation on the product, its use and how it would be adapted for use in NZ. A decision was then made on the preferred supplier; a contract with US-based5683 Transdyn, Inc. was signed in February 2009 and the expected outturn cost is NZ$6.9 million. The procurement and contract management components of TMS were provided by Resolve Group Ltd.
Within this strategy the ideal third-party information provider would have: an existing level of credibility with road users; a common vision regarding the provision of information to road users; and a willingness to share the risk and reward in the provision of such information. This was achieved by ensuring that the Agency is a 'wholesale' provider of transport information delivering directly via Web 2.0 to the public and third parties.
The Agency understands that road users require information at various stages of a journey via different media, availability of which can be dependent on geographical location, and it specialises in the capture, storage and verification of road event information. It does not have the time, funding, resources or expertise to develop the wide variety of communication channels required to satisfy customer requirements for personalised road condition information. The development of travel information service distribution channels is not part of its core business.
Therefore a more cost-effective solution was needed which could use the talents of the private sector whilst also delivering a level of free, easily accessible travel information to users. The InfoConnect Pilot initiative was developed as a potential mechanism to enable delivery of the Highway Information Strategy.
It was deployed in July 2008, a web 2.0-aware API (Application Programming Interface) which was accessible by a broad range of developers via an online portal.
The following factors were identified as critical: 40 or more developers/third parties register to use InfoConnect during the one-year pilot; 75 per cent of road users should when asked report an improved ability to make informed road user/travel decisions; and the website was to be available for use by developers/third parties 98 per cent of the time, 24/7. Both the interim (three-month) and final (less than 12 months) evaluations would include a review and if appropriate revision of these critical success factors.
The InfoConnect Pilot was assessed against the above factors, a business case was prepared and a decision was taken to proceed to InfoConnect Phase 2.
The agreed architecture for the InfoConnect technology solution to be implemented in Phase 2 will consist of an operational data store and the enterprise service bus. A Solutions Architecture Document provides detailed information regarding the role and operation of each of these components.
The web service APIs and feeds provide information sourced from systems internal to the NZTA. Phase 2 will transition existing APIs and web feeds already accessible via the InfoConnect website to the new architecture. The existing APIs and feeds are for: the Auckland Traffic website (accessed via REST or SOAP request) for traffic congestion, signs, camera list, and windspeed; TREIS (accessed via RSS or SOAP request) for events/incidents and general warnings for both of New Zealand's North and South islands; traffic webcams (video images accessed via HTTP request for Auckland, Wellington and Christchurch); and location referencing (accessed via SOAP request).
Independent developers use the InfoConnect services for applications which enable their customers to make direct, ad hoc requests to InfoConnect (for example, iPhone applications). The system has been designed for 400 concurrent users, providing for an average of 100 transactions per second, subject to acceptable variations due to file size or traffic volumes. The system will service an estimated peak demand of 400 transactions per second or 4,500 transactions per minute. A transaction is defined as a client request and response; Figure 2 shows the InfoConnect Phase 2 context diagram and this defines the boundaries and how it fits with other NZTA systems.
The InfoConnect initiative is an example of an innovative national approach towards provision of travel information to the New Zealand public. InfoConnect has adopted the principles of "Open Government Data" and enables the NZTA to cost effectively maximise the opportunity for businesses and developers to deliver travel information on many levels, from wide broadcast through to personal information services.
RSS
Deryk Whyte provides an overview of how the New Zealand Transport Agency's InfoConnect concept was developed.
Historically, theThe NZ Transport Strategy, updated in 2008, emphasises the need to maximise the transport network's efficiency whilst providing access to good, reliable, timely travel information. A Strategic Vision was developed for delivery (Figure 1), fundamental to which are establishment of the Traffic Road Event Information System (TREIS) and replacement of the NZTA's existing traffic management software.
TREIS
Vision delivery commenced with the development of TREIS. This enables the Agency to understand the current status of the entire state highway road network whilst also supporting the management of network maintenance contractors in clearing any events and incidents which occur. TREIS was rolled out nationally in 2007 and enabled real-time road condition information to be disseminated via the Agency's 'Highway Info' webpage and a 24/7 public freephone number.New management software
In 2008 NZTA commenced procurement of a new national Traffic Management Software (TMS) to replace a system originally installed in 2003. International expressions of interest were sought for supply, installation and a five-year support period. The aim was to use a fully supportable product which could handle a wide range of functions, and which had an open architecture and a proven track record.The new national TMS will not only drive the existing traffic management field devices in Auckland and Wellington but will be expandable to at least three other major urban areas. It will also provide support for a national system of Variable Message Signs (VMS) on vulnerable parts of the state highway network. Bidders needed to take into account present and future functionalities, including: CCTV (analogue control); VMS and lane control signals; moveable lane barrier operations; vehicle counts; ramp metering (signals); emergency telephones; a faults system; web interfaces and webcams; weather; and an incident management system. In future, the system will need to support: IP-based digital video transmission; advanced incident management; interfacing with SCATS for interchanges; tunnel management systems; wider incident detection management; vehicle recognition; weigh in motion; remote CCTV and VMS; traveller information including signs, radio, telephone and web; other dynamic lane management; and traffic management associated with toll roads.
Procurement process
Tender responses were evaluated on the basis of track record, relevant experience, and technical and management skills. Two parties were shortlisted for the second stage under a Brooks Law approach and a full request for tender was prepared for the five-year contract. This approach enabled NZTA to make a selection based on quality and then negotiate price. The pricing structure was set up to enable NZTA to reconsider elements that might have been deferrable should there be budget issues.A fully interactive process was used and as both parties were based outside NZ they were invited to visit for a period to get a full understanding of the project requirements. They gained a full understanding of the outputs required for Wellington and Auckland and discussed needs, risks and opportunities with operators and others. The onus was on the shortlisted parties to develop their own methodologies and implementation plans.
The evaluation team then visited nominated sites in Australia and the US where the systems could be seen in operation. At the conclusion of each visit, the parties were invited to make a three-hour presentation on the product, its use and how it would be adapted for use in NZ. A decision was then made on the preferred supplier; a contract with US-based
InfoConnect
As the success and credibility of the TREIS-sourced travel information grew, more and more third parties began to request direct access. This pushed development of an effective Highway Information Strategy. Specifically: this would enable the road user to have knowledge about the current condition of the state highway in the areas relating to his or her intended travel; the manner in which the information is delivered builds confidence in the usefulness of the information and its supplier(s); from this knowledge a number of options are provided for road users to consider in their travel plans; and this contributes significantly to improving road users' perceptions of the Agency's capability.Within this strategy the ideal third-party information provider would have: an existing level of credibility with road users; a common vision regarding the provision of information to road users; and a willingness to share the risk and reward in the provision of such information. This was achieved by ensuring that the Agency is a 'wholesale' provider of transport information delivering directly via Web 2.0 to the public and third parties.
The Agency understands that road users require information at various stages of a journey via different media, availability of which can be dependent on geographical location, and it specialises in the capture, storage and verification of road event information. It does not have the time, funding, resources or expertise to develop the wide variety of communication channels required to satisfy customer requirements for personalised road condition information. The development of travel information service distribution channels is not part of its core business.
Therefore a more cost-effective solution was needed which could use the talents of the private sector whilst also delivering a level of free, easily accessible travel information to users. The InfoConnect Pilot initiative was developed as a potential mechanism to enable delivery of the Highway Information Strategy.
InfoConnect pilot
The 12-month InfoConnect Pilot was intended to: meet the Agency's key objective, of "ensuring customers have access to appropriate information channels to obtain and act on information to result in behaviour change"; enable third parties and the internet developer community to access Traveller Information Services (TIS) data from the Agency so that they may share it with customers; support the rapid development of a wide range of applications and uses for TIS data, including possibilities where the data is combined with other data and services to create an even richer application for users, by disseminating documented data to third parties and developers; create opportunities for economic growth in this sector of the NZ economy; and increase the efficiency of the transport network and thus contribute to an increase in NZ productivity.It was deployed in July 2008, a web 2.0-aware API (Application Programming Interface) which was accessible by a broad range of developers via an online portal.
The following factors were identified as critical: 40 or more developers/third parties register to use InfoConnect during the one-year pilot; 75 per cent of road users should when asked report an improved ability to make informed road user/travel decisions; and the website was to be available for use by developers/third parties 98 per cent of the time, 24/7. Both the interim (three-month) and final (less than 12 months) evaluations would include a review and if appropriate revision of these critical success factors.
The InfoConnect Pilot was assessed against the above factors, a business case was prepared and a decision was taken to proceed to InfoConnect Phase 2.
InfoConnect Phase 2
The InfoConnect website is located on the NZTA website and provides developers with a central point of access, or portal, for all information regarding the available APIs and web feeds. It is also the entry point for registrations.The agreed architecture for the InfoConnect technology solution to be implemented in Phase 2 will consist of an operational data store and the enterprise service bus. A Solutions Architecture Document provides detailed information regarding the role and operation of each of these components.
The web service APIs and feeds provide information sourced from systems internal to the NZTA. Phase 2 will transition existing APIs and web feeds already accessible via the InfoConnect website to the new architecture. The existing APIs and feeds are for: the Auckland Traffic website (accessed via REST or SOAP request) for traffic congestion, signs, camera list, and windspeed; TREIS (accessed via RSS or SOAP request) for events/incidents and general warnings for both of New Zealand's North and South islands; traffic webcams (video images accessed via HTTP request for Auckland, Wellington and Christchurch); and location referencing (accessed via SOAP request).
InfoConnect users
The users of the InfoConnect system will be third-party organisations such as the AA or the MetService. They will use the API feeds from InfoConnect to provide NZTA road information on their own websites. This group of value-added service providers is expected to make regular, scheduled service requests to InfoConnect.Independent developers use the InfoConnect services for applications which enable their customers to make direct, ad hoc requests to InfoConnect (for example, iPhone applications). The system has been designed for 400 concurrent users, providing for an average of 100 transactions per second, subject to acceptable variations due to file size or traffic volumes. The system will service an estimated peak demand of 400 transactions per second or 4,500 transactions per minute. A transaction is defined as a client request and response; Figure 2 shows the InfoConnect Phase 2 context diagram and this defines the boundaries and how it fits with other NZTA systems.
The InfoConnect initiative is an example of an innovative national approach towards provision of travel information to the New Zealand public. InfoConnect has adopted the principles of "Open Government Data" and enables the NZTA to cost effectively maximise the opportunity for businesses and developers to deliver travel information on many levels, from wide broadcast through to personal information services.
RSS
