Networks to run a smart city - I

First part of two-part column explaining the framework for smart cities in India

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 suggestions for the same myself. I am going to start with the solution architecture broken in two parts and post that will take a few use-cases around various aspects of smarter city in the coming series.

So what makes a city smart?  On this I will improvise the Wiki definition.

“Smart city uses Technology to enhance quality, well being and safety of citizens. It provides means to engage more effectively and actively with its citizens and the 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 smart city.

With that let me dive directly to the solution architecture and give an overview of the various components of it.

For the sake of brevity and to make it understandable to a larger audience, I have kept it simplistic. Below is the solution architecture for smart cities.

Starting from the bottom-most block– integration

This block will interface with applications and sensors primarily.  The reason for integration is to get the data from the applications and sensors, churn the data and present it for analysis and come out with actionable work. (The upper blocks  will be doing these jobs).

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 neighbor hood, 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.

– Externalcity applications 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 directly with the devices using various protocols such as Modbus, OPC, DNP3 etc. The latter scenario is a rare case, but the solution should be capable of handling that.

The next article will explain the other blocks.