Richard Thurbin on UTMC

I apologise in advance for this slight rant. Some things get under my nerves and this is one of them.

In 1997 when UTMC was established, local authorities were isolated islands whom rarely spoke to one another. With email, web and initiatives from local and central government, transport is now seen as an integrated multi modal network, all reliant on one another in order to get along. James and I both believe that UTMC should not just be Urban and Traffic but Unified and Transport. To this end we have brought many innovations and products to the market and we believe really moved the game on in a number of key areas, one of them being linking systems.

Back in 2006, within months of operating, Cloud Amber 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. Well, that's where our intelligence comes in to play. I am not going to divulge exactly how we do it as our competitors will then find something else to copy! However 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! Cloud Amber now have over 20 systems linked to date, including Poole Bournemouth, Dorset, Portsmouth, Southampton, Hampshire, Reading, Windsor and Maidenhead, Buckinghamshire... need I go on...

If anyone tells you linking UTMC systems cannot be done, or it is hard, or it takes a long time, or it is very expensive clearly needs to sharpen their pencil. Give me a call if you want to know more.

Cloud Amber's Current Linked Systems

A computer simulation, a computer model, or a computational model is a computer program, or network of computers, that attempts to simulate an abstract model of a particular system. Computer simulations have become a useful part of mathematical modelling of many natural systems in physics (computational physics), astrophysics, chemistry and biology, human systems in economics, psychology, and social science and in the process of engineering new technology, to gain insight into the operation of those.

Computer simulations vary from computer programs that run a few minutes, to network-based groups of computers running for hours, to ongoing simulations that run for days. The scale of events being simulated by computer simulations has far exceeded anything possible (or perhaps even imaginable) using the traditional paper-and-pencil mathematical modeling: over 10 years ago, a desert-battle simulation, of one force invading another, involved the modeling of 66,239 tanks, trucks and other vehicles on simulated terrain around Kuwait, using multiple supercomputers in the DoD High Performance Computer Modernization Program; a 1-billion-atom model of material deformation (2002); a 2.64-million-atom model of the complex maker of protein in all organisms, a ribosome, in 2005; and the Blue Brain project at EPFL (Switzerland), began in May 2005, to create the first computer simulation of the entire human brain, right down to the molecular level.

Transport

In a traffic environment, modelling is concerned with predicting and modelling the transport network, predicting flows, congestion and other parameters using a variety of fixed and configurable data sets and assumptions.

UTMC command and control systems concern themselves with managing the traffic on a minute by minute basis, making decisions based on the information available at the time.

UTMC sub-systems, such as UTC collect and process data and make second by second decisions about how best to optimise traffic flows, again based on the information available at that time.

If a change to the network should occur (a new street work, incident or event) these systems have limited knowledge in which to make appropriate changes to best manage the impact.

This blog describes how Modelling can be used in the context of a command and control system together with UTMC sub-systems to more effectively predict and therefore manage the impact of a change occurring on the network.

In Context

When UTMC is put within a broader context including modelling, we can see the relationships between the various layers in the management of transportation systems.

Modelling & UTMC

UTMC is a technical framework specification which has been evolving from inception in 1997. In the original specification, the standard defined the DB schema and IDL mappings used in the CORBA type connections. Fortunately this has now evolved in to a more universally recognised data standard.

The UTMC specification is now split down in to logical layers used within the system; the model, definition and implementations. UTMC Logical Model defines the data strictures, objects and interfaces available in a open language. There are IDL mappings, DB schemas and XSD definitions available which define the structure of the data and their interfaces, with the implementations of those manifested in CORBA Object Servers, Common Database Implementations and raw XML Data.

Data Sources

There are a number of data sources within a UTMC system which would be used in a modelling context.

The network definition sources are used to describe the static network, trunked, local and other networks dependant on the source road data.

Real time data sources can be used to view, correlate and interpret the current state of the network, but just as important is any historical count and flow data that may have been collected electronically or manually.

Other data sources describe the restrictions on the network, be them permanent, temporary planned and temporary unplanned changes. These sources are as diverse as bollard restrictions on a timer to snow closing or blocking roads across a wide area.

Data Sources Grouped

It is important that any UTMC and modelling systems can understand, interpret and use these data sources to their best effect to ensure an accurate and reliable prediction of future events.

We are currently generating a great deal of interest from our customers about modelling and integrating it in to our UTMC systems. I think in Q2 2010 we will be in a position to start a technical work group to define the interface specification between UTMC and Modelling. Hopefully we can get enough interest from the modellers to join in the party as well.

Would you like to be part of it? What would you like to see developed?

I was one of the few to battled through the sleet and snow to attend the joint UTMC/RTIG workshop hosted by Kent. Given the travel disruption that has been going on the last few months I am not surprised many decided to stay in their nice and warm office rather than risk getting stuck on the M20 or on Maidenhead platform indefinitely. Unfortunately some of the no-shows were speakers themselves which meant the agenda had to get re-gigged on the fly - old agenda.

The first part of the day focused on the Kent system which I very much enjoyed. There was a little too much emphasis on suppliers for my taste but that being said the content was relevant, focused, to the point and well structured. I think those of the audience not familiar with the subject matter would have gained a great amount from it. I will be interested to hear how the launch of the bus smart card goes and if their neighbouring authorities will adopt a similar scheme. Clearly Medway has the most to gain, however East Sussex also has strong links with Kent.

After lunch we all heard about how the Highways Agency is linking Kent together with their South Eastern Regional Control Centre in Godstone, Surrey. It is great to see this kind of initiative happening and can only be good for the UTMC industry. I was slightly perturbed by the inference that there was likely to be only one or two supplier for common databases with in the HA. Given the open nature of the industry and the standard I would hope that there could be more competition and opportunity for young guns like us, rather than automatically sticking with the same old same old establishment. Competition is good for the market, good for us and good for our customers. What is good though is the HA intend to develop the UTMC standard further to include ramp metering and other more trunk road based objects. I look forward to getting stuck in to those new objects shortly.

In one of the later presentations, there was a plea from one of the speakers to produce a RTPI object within the UTMC standard. I must admit I was quite taken aback by this, given the work the RTIG group have done over 10 years on RTIG XML and latterly CEN SIRI. If you ask me, CEN SIRI is perfect for all UTMC's RTPI needs and we should stick to that standard, rather than re-inventing another wheel.

Why is compliance important? Well UTMC is a broad and wide ranging standard which tries to encompass all of Urban Traffic. Way back in 1997 all the systems available used proprietary protocols and standards. Once a supplier was chosen, the authority was locked in to the products and services from the supplier without the opportunity to change or mix and mach without significant further investment. As a result the Department for Transport prime funded a research project aimed at creating a set of protocols aimed at opening up the urban traffic market to further competition. This has resulted in creating a 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 document (and subsequent revisions) that came out of all that effort defines a broad range of technical standards, data objects and interface specifications. It is however far from specific in a number of key areas, time being one of them (see What is the Date? blog entry). In addition there is no formal verification of the standard or any suppliers' adherence. When I first started interfacing with all of these systems I became very frustrated with the differences that existed with all of the implementations. To this end a "UTMC Compliance Analyser" was created 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.

Remember the real driver behind UTMC, the UTC monopoly? Well it still exists today. The supplier which implements the control system still has a 100% monopoly on on-street controllers and other such equipment. Yes UTMC allows you to add remote monitoring systems (RMS) using UTMC but when the fault management system the UTC supplier uses doesn't allow the input of faults through UTMC, therefore meaning all RMS faults can never be actioned, it kind of makes a mockery of the whole thing.

Of course I am trying to break through these ridiculous barriers and change the incumbent suppliers but the going is slow and tough. I just wish sometimes that the industry would not sit back on its "well we have standards" laurels and make sure the imitative is driven through in to the real world. I can only do so much, but if you start shouting too loudly, everyone ignores you!

Dates and calendars... they been around for a while. There are also many different types. We use the Gregorian calendar here in the western world. The Persian calendar is used in Iran and Afghanistan. The Islamic calendar is used by most non-Persian Muslims worldwide. The Chinese, Hebrew, Hindu, and Julian calendars are widely used for religious and/or social purposes. The Ethiopian calendar or Ethiopic calendar is the principal calendar used in Ethiopia and Eritrea. In Thailand, where the Thai solar calendar is used, the months and days have adopted the western standard, although the years are still based on the traditional Buddhist calendar.

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. Indeed there are. This picture shows the different date formats used throughout the world: 

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 Oracle function had to be used within the SQL it's self in order to get it in to the common database! Luckily the software we have enables this idiocy to be dealt with quickly and efficiently.

How this "open standard" can evolve over 10 or so years with the incumbent suppliers and not define a unified date format is ludicrous. Bring on ISO 8601 if you ask me.