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
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
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.
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.
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
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
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
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 -
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
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
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
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
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.