Future Readiness in the Context of Smart City Systems – Part 3 of 3

As we discovered in our 2 last articles, future readiness implies 3 main challenges:

Part 1 of 3 – Future readiness in hardware (devices, sensors and controls)
Part 2 of 3 – Future readiness in network connectivity
Part 3 of 3 – Future readiness in software

Today we are discovering a little more about Future readiness in software.

Future readiness in software

Scalability

With the growing number of connected objects available for cities to collect data on many levels, from energy consumption to mobility or environmental quality indicators, a Smart City management system that allows to manage all these data inputs can quickly become complex. Yet, these systems need to present a set of features that cities, no matter their size, would like to benefit from. We are starting to see more and more larger groups of counties, municipalities, townships, that get together in order to share a Smart City platform that can scale hundreds of thousands of smart devices to control and monitor while allowing each of them to securely administer their own territory.

The energy metering of lights is typically poled every 15 minutes. Imagine a city with a few thousand lights. The Smart city system chosen to control lights will require a special system architecture that can not only handle that level of data traffic flow, but also deal with efficiency and responsiveness for data storage and retrieval, analytics of time-series, etc. If such is the case, a thorough analysis of the overall system’s architecture is strongly recommended, in collaboration with your IT department, in order to ensure that the proper performance and security policies can be accommodated. Systems implementation on enterprise-scale cloud infrastructure such as Microsoft Azure is a good example of such technology platform that can support your project. Nevertheless, the most evolved systems out there can both support the cloud or the on-premise installation model.

Support for Future Applications

Since the smart city market is so new and developing so rapidly, it is hard to predict which applications and use cases will appear and become important in the future. It is therefore essential that the software be flexible enough to accommodate these, through open, secure and well documented APIs.

APIs also help in getting your system to work and exchange data with software systems of other verticals, which is crucial for achieving smart city objectives such as inter-departmental collaboration, energy efficiency, remote infrastructure management, and public security and well-being.

Importantly, the software platform also needs to be flexible enough to accommodate various types of data, e.g. coming from current and future sensors in various data formats.

It should also provide a framework to define new use cases, new application types, data formats, define carriers and protocols, rules, and filters, create ad-hoc queries, etc. These adaptations should be fairly easy to do without coding or requesting a customized version of the software.

Easy Updates

In the popular SaaS model, you are always using the latest version of the software, because you are accessing it on the cloud. But cloud hosting creates other challenges, so not every city considers it right for them. Whether you go for a public cloud, private cloud, or an on-premise solution, it should be easy to update your software, and the vendor should be committed to continuous improvement in that area.

Security

With cybercrime growing and more and more data points being created, it is crucial to protect sensitive information. While security is important for every element of the system, it is especially true for software.

System security is a vast topic, so this article will mention just a few key points to consider for the software layer of smart city system:

The system should encrypt data and commands at multiple points (e.g. gateways communicating to the server, the server communicating to the nodes through the gateways, the nodes communicating to the gateways);
The system should use sophisticated methods to authenticate authorized users (e.g., IP address restrictions, domain-specific restrictions or two-factor authentication);
The system should require authentication not just on login, but whenever an important action is being taken;
If external systems are in play, the APIs should use the same stringent security rules derived from the business rules of the system, i.e.: User rights;
The system should store as little personal or proprietary data as possible – often this means none at all.