01 July 2011

Idox Transport was asked by the UDG on our thoughts for the future of UTMC. Here is our response.

Q1 Should the UTMC initiative continue? Why

Yes. There is value in an industry body focusing on getting value from implementing transport management systems in a UK environment.

Q2 Are there specific activities which a continuing UTMC initiative needs to undertake?

Yes. Idox Transport believes UTMC should focus operational and implementation best practice.

For example, the industry seems very fragmented in the way it manages journey times. This is in terms of monitoring, measuring and changing the way it goes about managing it. A series of workshops focusing on the collection, processing, management, reporting on this data could result in tangible benefits to journey times, thus providing a clear business case for systems and their expansion. I believe integration is a weak case for procuring a UTMC system, where as if UTMC could demonstrate a 15% reduction in journey times after a successful implementation, it is almost a ‘no brainer'.

Q3 Should the technical aspects of UTMC continue in essentially their current form? If not, please indicate what changes you believe are necessary.

I am glad you asked and our answer is absolutely not.

There are a few things technically which are really holding back UTMC. The first is CORBA and the second is the Common Database.

CORBA - Depending on exactly when one starts counting, CORBA is about 10-15 years old. During its lifetime, CORBA has moved from being a bleeding-edge technology for early adopters, to being a popular middleware, to being a niche technology that exists in relative obscurity. Anyone interested in UTMC and CORBA should read this article on the Rise and Fall of CORBA: http://queue.acm.org/detail.cfm?id=1142044

When speaking to companies outside of the UTMC world and mention CORBA, most don't know what it is and those that do ask if I am being serious. This technology is holding back integration, making interfaces far too complicated, each one is different and finally (and most worryingly) support and development for CORBA within the development industry as a whole has been almost stagnant for years. To highlight my point, we have 175 adaptors in the field and we have written them all except one. That was written by another UTMC supplier for a hardware manufacturer. Good for us, bad for the industry.

UTMC needs to ditch CORBA and move forward with XML & SOAP. More widely supported, understood, far easier to integrate and has much more investment within the IT industry in defining standards, tools and applications. Also, I know about free flow, but I have a slightly different dislike of that which I will come on to.

Common Database - The inherent design of "everything must go through a database" is severely limiting the scale of any UTMC system. Data should be processed and flow through systems using memory and processors, not disks and tables. I found this out to my cost back in 2001 when designing a real time schedule adherence system for Buses. Instead we re-developed the back end business processes avoiding all database interaction and managed to increase capacity from 200 buses to over 10,000.

Databases are storage and retrieval mechanisms for data, not conduits for real time information. UTMC should not have a definition for the common database, nor should implementers have to implement them. UTMC should define a series of data objects and interface mechanisms in which third parties can interface to. Much like RIG XML and CEN SIRI, thus avoiding the issue. Unfortunately Freeflow is not this but just defines a different mechanism to get data in to and out of the database.

Because of these limitations we have implemented ours very differently under the lid, however the through of a "standard" UTMC implementation for the HA's infrastructure makes me laugh.

Compliance - well UTMC is a broad and wide ranging standard which tries to encompass all of Urban Traffic. The whole point of the Department for Transport prime funded project was aimed at creating a set of protocols aimed at opening up the urban traffic market to further competition. This has resulted in creating an industry where there is a wider choose of suppliers and products in the market for ALL traffic management systems.

The real target was not for ANPR to talk to air quality systems but to break the quasi monopoly that existed in the urban traffic control (UTC) segment. The supplier which implements the control system still has a 100% monopoly on on-street controllers and other such equipment. Ok so that hasn't worked, but let's looks at UTMC database compliancy instead...

Given the fact the UK uses the Gregorian, connecting to a common database and using a date should be easy right? "Ah" I hear you cry, but there are many different formats for a date. Fair enough. "But surely there is a common standard for dates?" I hear you cry. Yes, infact there is and it is called ISO 8601. "Well then it is simple surely, a UTMC system should support ISO 8601?" Of course not, that would be too easy. Bizarrely, UTMC does define the use of a Julian date in the CORBA IDL. Is this format used for date formats in SQL strings? Of course not. Instead UTMC has this ridiculous situation where it is up to each and every independent supplier to use a Julian date for CORBA but dream up their own date formats for SQL. When integrating in to a system in the West Country, the incumbent supplier was not using ISO 8601 or indeed any other of the recognised date formats. Instead an vendor specific function had to be used within the SQL it's self in order to get it in to the common database! As a result we have 4 different versions of our "UTMC standard interface" in order to achieve integration. We did create a "UTMC Compliance Analyser" and offered to the industry as a free and open source validation tool. It is a shame this wasn't taken up and we are still left with the position where everyone claims they are compliant whist asserting all of their competitors are non-compliant. What is the point of a non-verifiable standard? Very little if you ask me.

The Standard - has been defined, used and implemented specifically for an individual authority and was implemented as such for years and years. Back in 2006, within months of operating, Idox Transport had linked our first system together. We did this in a fully UTMC compliant method using full UTMC protocols. The technical minded amongst you may wonder how this was done without somehow changing the standard, given its inherent limitations. With cleaver logic, software, security and permissions it is perfectly possible to do so each sub system, system, user and interface remains completely compliant, the database is fully compliant and no one is any the wiser! I have managed to achieve over 20 systems linked to date using this method.

To overcome this, at one of the first ANPR workshops I tried to convince the assembled nobility that when defining this standard we should consider the possibility that ANPR systems may be shared across county boundaries and perhaps we should define a identification regime which allowed for this to take place. I was quickly dismissed, ignored and then not even invited back to the next workshop! I did chuckle to myself when the very last version of the standard included some concession for this feature in a version 18 months later.

In summary - the standard is arcane, forgotten by the IT industry, inherently hard to integrate, slow, un-scalable, difficult to share data and failed to achieve its objectives in the beginning. It is supported by companies with deep rooted vested interests in keeping barriers to entry high, integration hard and the standard as loose and woolly as possible. Compliance is a joke and there is no will to change. There is a grown up traffic standard defined and used throughout Europe and it is called DatexII. If my customers were to define DatexII systems they would find a larger product set, competitively priced, widely supported with new innovative and easy to use integration. It doesn't define a database but well formed, understood data structures and interfaces in order to achieve simple and easy integration.

Q4 Should the non-technical aspects of UTMC continue in essentially their current form? If not, please indicate what changes you believe are necessary.

Yes, but more work shop orientated rather than a yearly large conference.

Q5 Are the identified Scenarios reasonable ones to consider? If not, please indicate why.

Yes. UTMC has to change otherwise it will become more and more irrelevant in today's cash strapped times.

Q6 Are Scenarios 1-5 prioritised sensibly? If not, please indicate why.


  • Option 1 is carrying on with the status quo with no change or innovation. 
  • Option 2 goes against the very reason it was set up. I also see little value in the IP it has created to date, especially given more advanced, encompassing and wider markets are available with European standards. 
  • Option 3 is our preferred option, with the technical elements removed, taken care of by European standards organisations and the UDG focusing on providing industry best practice. 
  • Option 4 is difficult to understand as it does not detail what would change. The merging of RTIG Inform and UTMC has always been the most obvious choice and may start the integration of public and private transport or Unified Transport Management Control (as we have always seen it as such). 
  • Option 5 is giving up and not accepting change.

We would prioritise the options as follows: 1. Option 3 (with caveats) 2. Option 4 3. Option 5 4. Option 1 & Option 2

Q7 Are there other scenarios that we should be considering? If so, which?

Yes, just the slightly revised option 3 above.

Q8 Is a professional secretariat necessary? Why?

Yes, but in a much reduced capacity. I see the role as facilitating discussions and workshops around best practice and best value.

Specific questions Q9 In a commercial model, who might pay and what would they pay for?

We would take no part in this model.

Q10 Is it feasible and desirable to take UTMC commercial? If so, please indicate whether this should be done by the UDG or by another party.

We do not believe so. The proposal goes against the very reason the UDG was set up. It will create another SCOOT where it is impossible for any new entries in to the market; the standard will stagnate even further and become very expensive for all concerned.

I also see little value in the IP it has created to date, especially given more advanced, encompassing and wider markets are available with European standards. The only reason for this is the lack of innovation, change and development of the standard since its first release. On a separate but related note, we were astonished to find that the UTMC body doesn't recognise or hold any information on this first release, even though the 10 year old case studies on the web site continue to extol it's virtues.

Q11 Which secretariat functions could be delivered through voluntary mechanisms? By whom?

I do not see how a voluntary system would work, other than a large organisation taking a lead role, such as a large local authority or Quango.

Q12 Which other organisations could UTMC feasibly be gifted to?

The merging of RTIG Inform and UTMC has always been the most obvious choice and may start the integration of public and private transport or Unified Transport Management Control (as we have always seen it as such).

Q13 Would another organisation be in a better position to raise external funding, or secure the necessary support services on a voluntary basis, than the UDG? If yes, which, and why?

We don't believe so.

Q14 If UTMC were gifted to another organisation, what should happen to the UDG?

It should be disbanded.

Q15 If UTMC closed down, for how long should the current Specification be kept available?

Web space is cheap so I see no reason for it to continue in a archived static state for 10 years. Idox Transport would be happy to host the archive or a mirror of the archive for the industry if this was not possible.