The smartest city in the world

In my last post, I explained how the OMG’s Data Distribution Service standard provides the ideal data-sharing platform for Internet of Things and Industrial Internet applications. In this post, considering that it is time for summer vacations, I decided to take you on a voyage in the smartest city of the world: Nice, France.

Besides being placed on the heart of the beautiful Côte d’Azur (a.k.a the French Riviera) between Monaco and Cannes, Nice has recently gained media attention thanks to a series of innovative projects aimed at preserving the environment and improving the quality of life through creative use of technology. In particular, Connected Boulevard, the project I’ll describe in this post, targets and enhances city management capabilities.

To give you some context, Nice attracts approximately 10 million visitors a year and in 2013 it was named as one of the best European destinations. To continue to attract visitors and improve the living experience of its citizens, the city launched the Connected Boulevard project as a way to develop an open and extensible platform that could be used to manage and optimize all aspects of city management, such as parking and traffic, street lighting, waste disposal, and environmental quality. DDS (specifically PrismTech‘s Vortex platform) was used at the core of the Connected Boulevard platform for making relevant data ubiquitously available. But before telling you how DDS was used, let me explain the architecture of the system.

Connected Boulevard architecture

The Connected Boulevard architecture designed by the ThinkGlobal Team aims at maximizing extensibility and minimizing maintenance costs. As for any long-lived system, the main cost comes from the system maintenance as opposed to its initial development. In smart city applications, one of the main sources of maintenance costs is the replacement of batteries. Thus, to reduce the operating costs and maximize the battery lifespan, the Connected Boulevard project took a decision that was in contrast with the trend promoted by the many supporters of smart devices and edge computing. The sensors used throughout the Connected Boulevard project are quite “dumb.” In most cases, they simply measure physical properties such as temperature and humidity, magnetic field intensity, and luminosity. These measurements are then collected and elaborated by sophisticated algorithms within a cloud, where the data is then “understood” and acted upon. For instance, the variation of magnetic field is used to detect parked cars; temperature and humidity are used to decide when to activate sprinklers; luminosity, sometime used in conjunction with motion detection, is used to control street lighting.

As shown in the figure below, sensors use low power protocols to communicate with aggregators that are installed throughout the roads. The aggregators, powered by the power line, use DDS to share the collected data. Through DDS, collected data is made available wherever required. Recall that DDS is equipped with a dynamic discovery protocol that matches new interests dynamically and establishes appropriate communication paths. Consumers of this sensor data include applications running on an infrastructure that perform analytics.

These applications use DDS’s caching features to maintain in-memory, a window of data over which they perform real-time analytics. The result of analytics is shared through DDS with applications that have to decide what to do, as well as with other applications that are interested in receiving it – such as the mobile applications including the Nice City Pass, used to check free parking places as well as to reserve them. As an example, if a parking place is occupied by a car and that parking place is not paid for, a notification is sent to the traffic police to ensure that the violating car is fined. Finally, it is important to remark that all data is collected, owned, and managed by the city of Nice.

Measurable benefits

Nice’s Connected Boulevard has been operating for nearly two years and – besides being a very cool project from a technology perspective – it has had a measurable positive impact on the city. After its initial installation, traffic congestion was reduced by 30 percent, parking income improved by 35 percent, and air pollution reduced by 25 percent. In addition, the forecasted saving on street lighting is 20-80 percent, depending on the type of roads and their lighting constraints.

In conclusion, regardless of the hype and the fad that at times is glazed around the Internet of Things and Industrial Internet, the reality is that these systems are being built and are delivering measurable benefits. In addition, DDS is a standard that has proven its applicability and value on key Internet of Things and Industrial Internet applications, of which the Nice smart city infrastructure is one example.

Building the Internet of Things with DDS

The real value of the () and the () is ubiquitous information availability and consequently the decisions that can be made from it. The importance of ubiquitous data availability has significantly elevated attention on standards-based data sharing technologies. In this post, I’ll analyze the data sharing requirement characteristics of IoT/I2 systems and describe how the Object Management Group (OMG) Data Distribution Service (DDS) standard ideally addresses them.

Data sharing in IoT/I2

Data sharing patterns within IoT/I2 systems can be classified as follows:

Device-2-Device. This communication pattern is prevalent on edge systems where devices or traditional computing systems need to efficiently share data, such as plants, vehicles, mobile devices, etc. Device-2-Device data sharing is facilitated by broker-less peer-to-peer infrastructures that simplify deployment, foster fault-tolerant, and provide performance-sensitive applications with low latency and high throughput.

Device-2-. Individual devices and subsystems interact with cloud services and applications for mediating data sharing as well as for data collection and analytics. The Device-2-Cloud communication can have wildly different needs depending on the application and the kind of data being shared. For instance, a remote surgery application has far more stringent temporal requirements than a application. On the other hand, the smart city application may have more stringent requirements with respect to efficient network and energy management of the device. Thus depending on the use case, Device-2-Cloud communication has to be able to support high-throughput and low-latency data exchanges as well as operation over bandwidth constrained links. Support for intermittent connectivity and variable latency link is also quite important.

Cloud-2-Cloud. Although few systems are currently being deployed to span across multiple instances or multiple IaaS regions (such as deploying across EC2 EU and U.S. regions), it will be increasingly important to be able to easily and efficiently exchange data across cloud “domains.” In this case, the data sharing technology needs to support smart routing to ensure that the best path is always taken to distribute data, provide high throughput, and deliver low per-message overhead.

Besides the data sharing patterns identified above, there are crosscutting concerns that a data distribution technology needs to properly address, such as platform independence – for example, the ability to run on embedded, mobile, enterprise and cloud apps, and security.

The (DDS)

The DDS is an OMG standard for seamless, ubiquitous, efficient, timely, and secure data sharing – independent from the hardware and the software platform. DDS defines a wire protocol that allows for multiple vendor implementations to interoperate as well as an API that eases application porting across vendor products. The standard requires the implementation to be fully distributed and broker-less, meaning that the DDS application can communicate without any mediation, yet when useful, DDS communication can be transparently brokered.

The basic abstraction at the foundation of DDS is that of a Topic. A Topic captures the information to be shared along with the Quality of Service associated with it. This way it is possible to control the functional and non-functional properties of data sharing. DDS provides a rich set of QoS policies that control local resource usage, network utilization, traffic differentiation, and data availability for late joiners. In DDS the production of data is performed through Data Writers while the data consumption is through Data Readers. For a given Topic, Data Readers can further refine the information received through content and temporal filters. DDS is also equipped with a dynamic discovery service that allows the application to dynamically discover the information available in the system and match the relevant sources. Finally, the DDS Security standard provides an extensible framework for dealing with authentication, encryption, and access control.

Applying DDS to IoT and I2

Among the standards identified as relevant by the Industrial Internet Consortium for IoT and I2 systems, DDS is the one that stands out with respect to the breath and depth of coverage of IoT/I2 data sharing requirements. Let’s see what DDS has that make it so special.

Device-2-Device. DDS provides a very efficient and scalable platform for Device-2-Device communication. DDS implementation can be scaled down to deeply embedded devices or up to high-end machines. A top-performing DDS implementation, such as PrismTech‘s intelligent data sharing platform, Vortex, which can offer latency as low as ~30 usec on Gbps Ethernet networks and point-to-point throughput of several million messages per second. DDS features a binary and efficient wire-protocol that makes it a viable solution also for Device-2-Device communication in network-constrained environments. The broker-less and peer-to-peer nature of DDS makes it an ideal choice for Device-2-Device communication. The ability to transparently broker DDS communication – especially when devices communicate through multicast – eases the integration of subsystems into IoT and I2 systems.

Device-2-Cloud. DDS supports multiple transport protocols, such as UDP/IP and TCP/IP, and when available can also take advantage of multicast. UDP/IP support is extremely useful in applications that deal with interactive, soft real-time data in situations when TCP/IP introduces either too much overhead or head-of-line blocking issues. For deployment that can’t take advantage of UDP/IP, DDS alleviates the problems introduced by TCP/IP vis-á-vis head-of-line blocking. This is done through its support for traffic differentiation and prioritization along with selective down-sampling. Independent of the transport used, DDS supports three different kinds of reliability: best effort, last value reliability, and reliability. Of these three, only the latter behaves like “TCP/IP reliability.” The others allow DDS to drop samples to ensure that stale data does not delay new data.

The efficient wire-protocol, in combination with the rich transport and reliability semantics support, make DDS an excellent choice for sharing both periodic data, such as telemetry, as well as data requiring high reliability. In addition, the built-in support for content filtering ensures that data is only sent if there are consumers that share the same interest and whose filter matches the data being produced.

Cloud-2-Cloud. The high throughput and low latency that can be delivered by DDS makes it a perfect choice for data sharing across the big pipes connecting various data centers.

In summary, DDS is the standard that ideally addresses most of the requirements of IoT/I2 systems. DDS-based platforms, such as PrismTech’s Vortex, provide device solutions for mobile, embedded, web, enterprise, and cloud applications along with cloud messaging implementations. DDS-based solutions are currently deployed today in smart cities, smart grids, smart transportation, finance, and healthcare environments.

If you want learn more about DDS check out this tutorial or the many educational slides freely available on SlideShare.