What it takes to be a Smart City?

With all the buzz around Smart City Solutions and having been an Architect for the Smart City Solutions for some time, I thought of penning some solutions around Smart Cities. I am going to start with its Solution Architecture in this article and the next one. Post that will take few Use Cases around the various aspects of Smart City solution in the subsequent articles.

So what makes a city smart?

“Smart City uses technology to enhance quality, wellbeing and safety of citizens. It provides means to engage more effectively and actively with its citizens and enterprises. And lastly, it helps city authorities to reduce costs and resource consumption for their cities.”

This definition should cover most of the scenarios of a smart city.

With that let me dive directly into Solution Architecture and give an overview of its various components. For the sake of brevity and to make it understandable to a larger audience, I have kept it simplistic.

I will start from the bottom most block - Integration. Bottoms – Up approach.

This block will interface with Applications and Sensors primarily.

Applications have been broadly divided into two categories, Internal City Applications and External City Applications:

Internal City Applications are those which cities use for their operations. Examples would be Public Works - used for planning, executing and monitoring of public works (next time a road is being dug out in your neighborhood, you know where the work has originated), Building Management – used for planning, approval and monitoring of the buildings, water management – used for operations, maintenance and billing of water supply in a city. Land Records Management – used for maintaining lands records in a city as the name suggests.

External City Applications – They are the applications which are outside the purview of the city authorities. Examples would be weather feeds, news feeds, applications running in enterprises (example finance application), billing applications of electricity boards, in case they are private.

The Integration Layer should be flexible to accommodate the various mechanisms that the Interfacing Applications understand to communicate. Just to make this point more understandable, if there are two applications, one written in Java and other written in Microsoft .Net. If they need to share data amongst themselves, there needs to be a mechanism for that. The mechanism could be web services, queue based level integration (most of the financial world uses this), database to database level integration, direct APIs calls, file based integration. If you dig deeper into these integrations, there are protocols like SOAP/ HTTP, JMS, JDBC etc. But I will hold on that for the sake of simplicity.

Sensors – As we are moving into the era of internet of things, sensors will be more pervasive. And it becomes very imperative for cities to put up and integrate with sensors such as cameras for surveillance, GPS tracking devices in buses, smart meters for measuring the energy and water consumptions in houses and buildings, temperature sensors, flow meters for measuring the rate of flow of waters inside the pipes that carry water for cities.

For integrating with sensors, the sensors would either send the data to their respective servers and the “Integration” Layer would need to interface with them in any of the mechanism mentioned in the above paragraph, or the Integration Layer can interface with the directly devices using various protocols such as Modbus, OPC, DNP3 (you have some names to impress in your meetings) etc. The latter scenario is a rare case, but the solution should be capable of handling that.

And the next article will be explaining the other solution blocks. Stay tuned till then.