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

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?

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.

Highways Agency

The first thing that caught my eye (other than Bristol it's self) was the recent development with the Highways Agency and UTMC. With the HA actually putting money in to the business of UTMC I foresee a stronger link between local and unitary and the trunk road network. In the past the goal has sometimes been to get traffic off of their roads and on to each others, often with difficult consequences! What remains to be seen is how involved they become. UTMC is partly about standards, but it is also partly about a philosophy and a common purpose. Indeed I have even taken to re-interpreting Urban Traffic to mean Unified Transport. Think for a second about how one can get around. Walk, Bike, Motorbike, Car, Van, Truck, Arctic, Bus, Coach, Light Rail and Heavy Rail. My worry is that UTMC's already heavy bias on "Urban Traffic" will just become "Traffic" and forget that our green and pleasant land isn't very urban and there is more to transport than cars. Overall I feel it is a positive move and will move UTMC forward in the next few years in a way which hasn't happened since its inception over 10 years ago.

Freeflow

The final area I wanted to cover is the very exciting development of Freeflow. Nick Knowles of Kizoom gave a great presentation about the subject, but perhaps to the wrong audience! The main thrust of Freeflow and his presentation is about opening up UTMC to a wider technology audience. Whilst there may be "open standards" and "open technologies" the current state of UTMC is far from open. The non technical ones you  might not know but UTMC is primarily based on CORBA. CORBA was a little understood protocol in the 70's and 80's and even less so now. Freeflow allows data to be exchanged using XML, the internet's language, which will open up the market to many more players. Whilst you may think Cloud Amber and our competitors have a vested interest in keeping UTMC closed I like to think I am different. Anyone interested in how business based on intellectual property can use different business models should read the excellent book by Christopher G Pike called Virtual Monopoly (http://www.virtualmonopoly.net/). I believe innovation is the key to success, not building barriers in ivory towers. As a result this is an important step in UTMC's history, it will allow further innovation, further integration and hopefully and ultimately bring more business to the industry.

One question begs to be answered though, when will traffic signal controllers be open?

Is there anything you would like to see discussed?

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!

I have been thinking how the traffic world would benefit from Windows Azure, or any cloud based operating system for that matter. For those of you not at the bleeding edge of these things, cloud computing is a computing paradigm in which tasks are assigned to a combination of connections, software and services accessed over a network. This network of servers and connections is collectively known as "the cloud." Computing at the scale of the cloud allows users to access supercomputer-level power. Using a thin client or other access point, like an iPhone, BlackBerry or laptop, users can reach into the cloud for resources as they need them. For this reason, cloud computing has also been described as "on-demand computing."

This vast processing power is made possible though distributed, large-scale cluster computing, often in concert with server virtualisation software, and parallel processing. Cloud computing can be contrasted with the traditional desktop computing model, where the resources of a single desktop computer are used to complete tasks, and an expansion of the client/server model.

This is where I see it has some real benefits. Cloud computing is often used to sort through enormous amounts of data. In fact, Google has an initial edge in cloud computing precisely because of its need to produce instant, accurate results for millions of incoming search inquires every day, parsing through the terabytes of Internet data cached on its servers. Google's approach has been to design and manufacture hundreds of thousands of its own servers from commodity components, connecting relatively inexpensive processors in parallel to create an immensely powerful, scalable system. Google Apps, Maps and Gmail are all based in the cloud.

In many ways, however, cloud computing is simply a buzzword used to repackage grid computing and utility computing, both of which have existed for decades. Like grid computing, cloud computing requires the use of software that can divide and distribute components of a program to thousands of computers. New advances in processors, virtualisation technology, disk storage, broadband Internet access and fast, inexpensive servers have all combined to make cloud computing a compelling paradigm.

Using the cloud approach our Argonaut product can easily be incorporated in to a Silverlight based control utilising business and data services through the cloud. This would mean a complete reversal of a traditional cost model where customers can be billed based upon server utilisation, processing power used or bandwidth consumed. As a result, cloud computing has the potential to upend the UTMC industry entirely, as applications are purchased, licensed and run over the network instead of a user's desktop.

Is the industry ready? I'm not so sure.

I am working with Oxfordshire in creating a one way interface in to modelling systems so their models can benefit from all of the RTPI, AVL, ANPR and SCOOT data available in their system. This is pretty exciting stuff and I am looking forward to taking the node level data set and making sure the model is updated with accurate and reliable data.

The really exciting stuff is probably going to happen in the new year where we can start exchanging data in both directions, in real time! To this end at the UTMC conference in December we are going to get together some interested parties and start putting together an interface to achieve the integration.

Exciting stuff for us techy geeks and should prove very useful for the end user as well!

It was a positive session with everyone contributing their experience and expertise. There are 2 key outputs from the session I am particularly excited about. The first key output is raw vehicle registration numbers (VRNs) and secondly the format is in eXtensible Mark-up Language or XML. I offered my services to help hone the ideas and concepts coming out from the meeting and honing this in to a document / UML for wider circulation.

With these two innovations it will now be simpler and easier to integrate ANPR in to our UTMC system in a unified and coherent fashion. Guess what, dates are in ISO 8601 as well!

It looks like UTMC is going the same way with a formalised membership for organisations. In principle I support this, there is a ambitious business plan and I hope it does well. However there is a sticking point, the price. £1,800 is a lot of money to ask a small company to cough up. Sure for the large margin multi nationals that dominate UTMC it is mere chicken feed but for a small growing company, it is money that would otherwise be spent on furthering the product.

Fortunately there is the opportunity to give feedback before the final decision is made. I intend to put forward the concept of a sliding scale of membership dependant on the size of company. This would mean the large multi 'large margin' nationals can pay a more representative slice of their revenue to be part of the industry, whilst small business can continue to invest all monies in their product and future. I urge all to do the same.

By the way, the closing deadline for comments is 10 October 2008.