Why Smart City projects are challenging for even the experts and what we can do about it?

Hyperconnected City | Image Credits: Pixabay / Tumisu

Introduction

The Internet of Things (IoT) is the next BIG thing on this planet and will impact our lives in the way we do business, communicate, consume and share. IoT brings many exciting opportunities like Smart Cities, Smart Health, Smart Homes and so on.

One of the main application areas of IoT Deployment is in Smart Cities projects. With Smart City initiatives in various parts of the world, IoT deployment is getting a lot of push. However, there are inherent issues in such deployment, in terms of the following — lack of security by design, issues with scale, compliance to IoT standards, e.g., standards related to low-power utilization, integration and manageability issues due to multi-vendor environments, and so on.

In this article, I’ll focus mainly on the interoperability and usability aspects of using IoT devices in smart city projects.

A tale of mismatched interfaces (and software)

I’m a Mac user. With that comes the challenge of being able to connect to the projector in one go, or at least within a few minutes. Most of these problems can be attributed to the projector not being able to detect the computer input due to a supported resolution mismatch. And of course, there are projectors out there in the wild which refuse to support anything more than a VGA (640x480) or XGA (1024x768) input. This itself is a strong enough case for not putting too much text on the slides in case you need to use VGA/XGA resolution for slides that were created for a Full HD (1080p or 1920x1080) resolution.

So, I was invited for a guest lecture focusing on IoT security, and this is the exact sequence of events which happened while trying to project my slides:

1. I try to connect my Mac to VGA input using a Thunderbolt to VGA adapter. Nothing happens.
2. I ask if there is an HDMI cable available and if the projector supports it. It didn’t. And even if it did there was no interface available to do so from the podium.
3. After playing with various settings related to display which included bringing down the resolution in vain, I ask if they have a spare laptop that I could use. I was given a Windows laptop. The looks of it said it was at least 5–6 years old.
4. Now for the knowledge of non-Mac users, there is a nice presentation application called Keynote in Mac which many people use to create slides. I happen to have these slides in Keynote format as I reused slides from another person in my standards group. I thought I can handle this. Within a jiffy, I converted the Keynote slides into PowerPoint slides, put it in a USB drive and copied it to the new spare Windows laptop. By this time, I was eating into the time provided for my presentation and I was at 5 minutes mark.
5. You must be thinking, that’s it; this is the end of the ordeal. However, this was not the case. I tried to open the PowerPoint file and was greeted with nasty errors of formatting elements not supported. Turns out the Windows laptop was running PowerPoint 2007. Yes, that’s right. This was a very old version of Powerpoint which was not compatible with my slides.
6. At this point in time, I was running out of ideas and then I had an “aha” moment.
7. I exported my slides as PDF and viola this worked flawlessly on the old laptop and then everything went smoothly.

PDF Format supports much longer backward compatibility and it saved the day.

I’m almost sure I’m not the only one who faced this situation. Anyone who needs to use his/her laptop (especially the Mac or the latest Windows ones too) in a meeting/conference/training once in a while faces this issue.

Learning from this ordeal

There are few takeaways from this entire fiasco which resulted in everything working out finally at the end:

1. Old devices are going to be around. People just don’t and can’t throw away old devices.
2. People or organizations who own old devices don’t always subscribe to the new way of thinking or embrace the latest technologies.
3. “Quality is conformance to requirements” [Philip B. Crosby, 1994]. Quality is a relative term and the definition differs in different contexts.

How does it apply to Smart Cities and what can we do about it?

What you just read is a typical example of what can go wrong when we have multiple hardware interfaces, software, and hardware of different make and model coming in the picture.

Sounds like the exact problem we are trying to take care of in Smart Cities?

Here are a few of the problems we are dealing with in any smart city project, which anyone can relate to:

1. There are IoT devices, gateways, controllers, servers, etc., being used by different vendors. Even different versions of the device or software from the same vendor differ drastically in features.
2. Backward compatibility is not always the norm.
3. Such devices may have support for different protocols, different power levels, different interfaces, and so on.
4. Many of the devices don’t have in-built security, upgradeability, and manageability. It’s easy to work with a few hundred of such devices but once we talk about scale, it’s almost impossible to manage and maintain them over the course of their life.
5. Vendors and suppliers in a typical smart city project keep going out of business once in a while. Hence, we are left with devices which nobody knows how to support, or nobody is ready to support for an optimum cost.

By now, you’d have realized that one of the main reasons for the existence of most of these issues is that there is no common standard to which all the vendors must comply. If that’s not the case, how do we expect to unify everything?

An example of how standards can act as unifying force

There are many unifying standards out there that are so ubiquitous that they have become part of our life. For example, we connect our wireless devices every day to a wireless hotspot at home or in the office. We have more or less stopped caring about what’s going on behind the scene unless we run into issues. This simplicity in connectivity is brought to us by the WiFi standard (IEEE 802.11).

There is a whole list of standards under the 802.11 umbrella, but that’s something we are not worried about unless we are configuring our routers or troubleshooting an issue. I suggest you look at the 802.11 Timelines maintained by IEEE at grouper.ieee.org/groups/802/11/Reports/802.11_Timelines.htm if you are interested.

Moreover, every device manufacturer has to comply with the WiFi standard. Not complying with this standard is not an option anymore.

This example of 802.11 shows how a standard well-done can unify and enforce compliance.

A strong case for a unifying standard for Smart Cities

An analogous standard that can unify various interfaces of Smart City is not present in this point in time. A lot of work is being done to develop standards focused on Smart Cities in major standard bodies like IEEE and IETF. I’m part of two such standards myself — IEEE P1931.1 (ROOF) where I participate actively and IEEE P1451–99 (IoT Harmonization) where I’m trying to be a little more active in participation.

We would like the standard for a smart city to take care of at least the following requirements at a high level:

1. Interoperability
2. Security
3. Usability
4. Scalability

An IoT Middleware like ROOF (Realtime Onsite Operations Facilitation) can help solve these issues

ROOF is an IEEE Standard in progress and is being worked on under IEEE P1931.1.

ROOF is a federated networking and computational paradigm for the Internet of Things (IoT) that is always available for Realtime Onsite Operations Facilitation (ROOF) and solves some of the pressing problems of IoT deployments today: Interoperability, Scalability and Security for the constrained devices of IoT while allowing the innovation in building the IoT applications.

Figure: A Middleware for IoT, e.g., ROOF, can take care of most of the issues faced by constrained devices.

In this figure, we see the IoT Middleware as the layer which does various types of transformation, normalization, filtering, applying rules, and so on. We also see that this layer provides connectivity to the IoT devices (not all the IoT devices may be capable to connect to the outside world). In reality, the middleware can do much more than this. For example, the middleware layer can also work as the layer for “indirection” where operations that can’t be done in the IoT devices can be delegated to this layer.

This layer can be implemented as a layer in the hardware or in the software, the latter being more powerful and versatile.

Please note, ideally, the middleware layer should be one hop away but there may be other layers between the IoT devices and the middleware.

The ROOF will be implemented as a software platform on various devices that proxy the “Things” and their IoT services to the rest of the world including but not limited to mobile phones, home routers, gateways, personal computers, servers and other computing platforms as appropriate.

This is a Global Standard, well supported by IEEE, and emerging from a multi-trillion dollar IoT Industry, giving immense advantage for local industry and community that is building and benefiting from IoT and academic institutions in research and development.

What an IoT Middleware like ROOF can do?

ROOF can help to meet those challenges mentioned above by providing:

1. Guidelines, Policies, and Standards for IoT Devices (at national and international level)
2. Best practices for IoT deployment for various use cases
3. Scalable, Secure and Lightweight IoT platform specification
4. IoT platform and topology architecture specification for building intelligent systems that can cater to different use cases

IoT Middleware and the Model for IoT

Figure: The Model of IoT with an IoT Middleware like ROOF as the Mediation Service

In this model of IoT, the “Things” can sense and send the data from the change in their environment to the mediation services. For example, things can send details about the change in environmental temperature, humidity, acidity, etc.

The Mediation Service is not a mandatory layer. However, it is required in most of the time so that it can “normalize” different protocols (analogous to the languages spoken by humans) from various IoT devices to something the upper layers can understand. In effect, this layer simplifies the management of the IoT devices by giving a consolidated view of the IoT devices to upper layers. Thus, one doesn’t have to worry about so many device versions, types, and standards. This layer also builds Context for the IoT environment which is the most important pre-requisite to create workflows and real-life applications. For example, what do we do when the temperature rises above the threshold? The mediation layer is solely responsible for bringing down the complexity of the IoT world in terms of interoperability, security, usability, and scalability.

The Cloud layer is mainly responsible for data storage, analytics, and related applications. We can use analytics, machine learning (ML) and artificial intelligence (AI) based applications in this layer to find a lot of insights from the IoT network. This will be an essential element of working with any big IoT deployment, for example in a Smart City project. This layer also exposes application programming interfaces (APIs) to create unique and interesting applications.

Finally, one can use the APIs exposed by the Cloud to create applications that give insights into the IoT network and do certain operations. Few examples of such applications are — dashboards for monitoring and health reports, workflows for querying all the devices of few devices, applications for applying software/firmware patches to the devices, applications for changing the state of the devices (e.g., in a smart home or for traffic lights) and so on. There are numerous applications one can think of.

Please note, this is a reference model that represents how an end-to-end IoT network system looks like. In reality, there may be more layers and more complexity may be added to solve challenges of protocols, federated architecture, type of devices, hardware interfaces, and so on.

Open Source Implementation

Given the potential of IoT Middleware like ROOF as the base technology for building the Smart Cities worldwide, having an open-source implementation will enable many individuals, startups and other businesses to implement Roof based application driving the Smart City ecosystem. This requires wider industry, academic and government support.

Special Thanks

I’d like to thank Syam Madanapalli for the excellent figures he has created as part of our IEEE P1931.1 working group activities. That took off one thing from my mind while writing this article.

Originally published at https://www.linkedin.com.