DEV Community: Ricardo Gomez-Ulmke

Rapid IoT Prototyping with the Bosch XDK110 and an Event Mesh

Ricardo Gomez-Ulmke — Mon, 05 Aug 2019 18:37:08 +0000

Many IoT projects start with a prototype. We test different sensors, their connectivity within their target surroundings, and the data transmission from device to IT apps. We also use various cloud services and tools to visualize and analyze the collected data to eventually build our business case.

Once we have understood our use cases and their business value, we are often faced with the problem of creating a robust and production-ready pilot version of the architecture and tooling, albeit small-scale initially. Assuming this pilot is successful, the next questions we will get is ”Can we now roll it out at scale?” or ”How long do you need to roll it out globally?”

In this article, we will explain our journey of creating a foundation based on the Solace Hybrid IoT Event Mesh concept that allows you to go from a small-scale prototype to a full-blown global roll-out of your project to any size or geographic reach without re-architecting or re-developing any of your applications.

The guiding principle of our project was to provide maximum agility and flexibility in these dimensions:

Geographical deployment across US and Europe
Various cloud and on-premise deployments such as AWS, Azure and edge gateways
Evolution and extension of the use case

We have joined forces with a number of leading technology providers such as Dell Boomi, Altair, and SL to show the agility to consume and produce events and messages wherever required. As the prototyping sensor kit we used the Bosch XDK110, a great “cross domain development kit” with sensors such as gyroscope, accelerometer, magnetometer, humidity, temperature, and light.

Using the XDK110, we can target a number of different use cases, from monitoring vibrations of appliances and machines, monitoring transport of fresh food, medicines and vaccines, and fragile cargo as well as environmental conditions in production processes such as industrial painting and coating for optimal temperature and humidity. Yawn …

How about we use the same platform instead to monitor slot cars racing around a race track, fully connected and in real time? Count laps, detect crashes, …?

Have a look at this video recorded by SL Corporation to see the race track in action:

Note: Big shout-out to Heather. How does she manage to drive two cars at the same time without crashing them? We cannot do that!

Let’s have a look at the system and its components.

The Solace Client Application for the Bosch XDK110

As mentioned before, we use the Bosch XDK110 as the sensor device. It comes with an Eclipse-based IDE and tons of sample code to base your own project on.

Based on the libraries provided, we developed our own device application with the following interfaces:

A JSON configuration file with initial connection parameters for WIFI, the Solace MQTT connection, etc.
A telemetry publisher to send selected sensor data at a configured interval
A number of subscribers to receive commands and configuration parameters and respond with status messages

By taking advantage of a key feature in Solace, namely the literally unlimited number of topics that can be used, we have created a topic hierarchy to allow for very selective updates to the devices, using wildcards and the event mesh for routing messages from producers to all registered subscribers.

For example, each device subscribes to:

Configuration messages just for itself using the following example topic string: UPDATE/iot-control/BCW/solacebooth/racetrack/device/{myDeviceId}/configuration
Configuration messages for all devices within the “BCW/solacebooth/racetrack” region: UPDATE/iot-control/BCW/solacebooth/racetrack/device/#/configuration
Configuration messages for all devices within the “BCW/solacebooth” region: UPDATE/iot-control/BCW/solacebooth/#/device/#/configuration

Each device publishes sensor data under the following topic:

CREATE/iot-event/BCW/solacebooth/racetrack/device/{deviceId}/metrics

The topic pattern we use is as follows:

{METHOD}/{base-topic}/{resource-categorization}/{resource}/{id}/{aspect}

with {resource-categorization} split into: {region}/{location}/{production-line}

So, we map the organizational deployment / ownership of the device directly into the topic hierarchy.

By using this topic taxonomy in the event mesh, we have completely removed the requirement of parsing message contents to determine routes with the benefits of saving compute time, increasing throughput, reducing maintenance costs, and improving the agility of the platform. It also allows for fine-grained access control of who can access an API and eventually allows us to create a complete governance model of our events, messages, and routes.

We also wanted to support the concept of re-purposing the same device for different use cases. Logic in the XDK application allows for it to be re-configured to:

Select which sensor data is sent – any combination of gyroscope, accelerometer, magnetometer, temperature, humidity, and light.
Select the sampling rate for the sensor data – between 1 per second and 100 per second.
Select the message stream rate – between 1 and 25 messages per second.

For example, in order to monitor our race track cars, we really only want the gyroscope data (x, y, z). But we need it at a higher sampling rate: 100 samples per second combined into 25 MQTT messages per second, so 4 samples in one message.

To monitor fragile cargo, you would rather need the accelerometer at a very high sampling rate to detect “rough handling”. For monitoring food and medicine transports, you may only be interested in humidity, light, and temperature,but most likely at lower sampling intervals of one to several minutes.

The following figure summarizes the XDK110 application interfaces:

The Reference Platform powered by the Hybrid IoT Event Mesh

Let’s have a closer look at the downstream systems and interactions that are part of the system. The following figure provides an overview:

The applications that need to consume the streaming sensor data here are:

Asset monitoring
Visual analytics
Streaming analytics
AI/ML modules

These are all the applications or services that subscribe to either selectively or all of the streaming sensor data sent by the devices. The devices themselves are also visible in the topic taxonomy, the tree structure that reflects the “resource categorization” hierarchy {region}/{location}/{production-line}. Using this hierarchy, the user or administrator can select exactly which devices to ingest data from by using topic wildcards in the subscription and close subscriptions for device data that is currently not required.

Now, in order to support the concept of re-purposing / re-configuring the devices “on-the-fly”, the following message sequence is executed:

The Command & Control service issues a configuration message to one or more XDK devices.
Each device responds with a Status message, indicating the successful (or not) mode switching.
The Asset Monitor and the Streaming Analytics service(s) both subscribe to the successful mode-switch status message and store this as the device’s context.
Now the Streaming Analytics engine receives streaming sensor data from the devices, checks the context of the device and now knows what models / thresholds to apply to the streaming data.

The following figure shows this context switching and monitoring in more detail for the Streaming Analytics engine and what happens to its output:

After a “device mode change” (success) message is received by the Streaming Analytics engine, it now applies the correct monitoring model and algorithms for the different use cases such as:

Detecting car crashes, counting laps, and determining the winner in the race track mode
Detecting rough handling / dropped packages for the fragile goods transport mode
Counting wash cycles and detecting a sub-optimal installation for a washing machine

Depending on the model, the streaming analytics engine then sends out alerts or notifications.

Alerts are then forwarded to a CRM & Service module (such as Salesforce), creating a ticket for an agent to take action whereas Notifications & Alerts can be used in the Dashboards as well as for Sales & Marketing and therefore closing the gap from the connected machine to pro-active maintenance and assistance (e.g. “Your washing machine is unbalanced. We can send an engineer to help you prolong its life span.”) as well as sales & marketing (e.g. “You now have completed 10 wash cycles. Isn’t it time for a top-up of your favorite washing powder?”).

The Hybrid IoT Event Mesh

In order to support these interactions across multiple deployment geographies, we set up an event mesh as shown in this picture:

We needed to satisfy the following requirements connecting various XDKs:

XDKs running in California, connecting to a broker in the US in AWS.
XDKs running across Europe, connecting to a broker deployed in Ireland AWS.
XDKs running in a single location with an unreliable connection to the internet. We therefore connected the XDKs to a local edge gateway broker deployed onto a Dell Edge Gateway which in turn is connected to the event mesh through the edge broker running in Ireland in AWS.

The actual applications and services such as CRM, Visualization, Analytics etc. are running in various locations in Europe, so we deployed a broker in AWS in Frankfurt and a broker in Azure in Paris.

The event mesh is created by configuring each of the bridges between brokers to forward subscriptions and data as per the interaction diagram discussed before. We now have a low- latency, seamless, and global data and event distribution platform that allows us to implement these pub/sub, streaming, and queuing interactions.

The next step was to onboard our technology partners to provide the dashboards, integration, and user applications for the platform. The following figure shows the various technologies and functions they fulfill, completing the picture:

In the next sections, we briefly go through each component.

Visualizing the Event Mesh with SL RTView

In order to monitor the message flow and connections within the event mesh itself, SL Corporation deployed a cloud-based monitoring system as you can see in the following screenshot:

This monitoring system collects information and statistics from the brokers via the Solace Element Management Protocol or SEMP. SEMP is a RESTful interface that allows remote configuration and monitoring of brokers. In order to monitor brokers behind a firewall, in our case the on-premise broker running on the Dell Edge Gateway, we installed a “collector” module on the gateway itself which opens a HTTP/S connection to the cloud system.

RTView visualizes the event mesh as a whole and provides drill down into a single instance of a broker to access details about message rates, connection statistics, and various other metrics.

The following screenshots shows a monitoring pane for MQTT connections of devices across the edge brokers and the message rates:

Real-Time IoT Data Visualization with SL RTView

SL RTView is a configurable and versatile tool for all kinds of data visualization. We used RTView to also implement a visualization of the real-time IoT event data published from the XDKs.

A real-time snapshot of the various sensor data from the XDK:

A time-series view of the XDK sensor data:

Visual Analytics with Altair Panopticon

Altair Panopticon is a streaming and visual analytics toolset. It enables users to program sophisticated business logic and data functions using a fully visual interface and publish dashboards to the web in minutes.

Panopticon can directly subscribe to Solace events and we created a set of visualization dashboards to monitor XDKs in various use cases.

Here we can see the XDK110 mounted on “slot trucks”:

In the next graph we can see a truck doing “normal” laps around the track. The gyro X and Y values are fairly low whilst the gyro Z values are more interesting. They show quite clearly how the truck races around the track, turning left and right.

It gets interesting when we observe a truck crashing off the track. In this case, the gyro X and Y values spike, as we can see in the following screenshot:

The Dell Boomi Solution Architecture

Dell Boomi provides unified iPaaS platform to create full-fledged business applications and integration solutions in a hybrid cloud environment. We have used the following modules:

Dell Boomi Flow & Integration to realize the Profile Management application and the logic to remotely control the XDKs
Dell Boomi Hub to manage the reference data for the XDKs – the device Ids and their respective categorization
Dell Boomi Integration to propagate Alerts into Salesforce Service Cloud

The following picture shows the Dell Boomi solution architecture:

Integration with Salesforce was implemented using Dell Boomi Integration. The following picture shows the flow definition for this integration:

And when the streaming analytics module detects a car crash, a service case is automatically created in Salesforce:

Additional Tooling

In order to decouple the development between the various teams and for testing and simulation purposes, we needed a few basic tools: an interactive MQTT pub/sub tool and event recording and playback tool.

There are many tools out there to send and receive MQTT messages. We have chosen MQTT Box.

You can configure one or many connections to a Solace broker directly in the tool. All you need is the host, port, username, and password:

After this, you can add publishers and subscribers. Here is a screenshot of a subscriber to the metrics as sent by the XDK:

Equally, you can use a publisher to send commands and configuration messages through the event mesh to one or many XDK devices.

In order to facilitate the development of analytics and dashboards, we have also developed a simple event recorder and player. This allowed us to provide our partners with recorded data sets that they can play back at their leisure to develop and test their applications.

Conclusion

The entire project was developed over a period of about two months. We started with the implementation of the XDK application and once we understood the data and interactions that we could implement there, we created the API specifications for our partners to start working on their parts.

However, as the project evolved, so did the ideas and requirements. By having the flexibility of the event brokers as the basis for all communication and interfaces, we incrementally refined the topic structure and event payloads as required without disrupting the on-going integration and development work.

Another area that evolved over time was the requirement of where various XDKs are located and need to connect. We started with a single broker “event mesh” and over the course of the project, we added the broker on the Dell Edge Gateway as well as multiple regional edge brokers such as Ireland and US. Towards the end of the project, we also needed to integrate a home-grown analytics application running in Azure in France. This was equally seamless; we installed a new broker in Azure and created the bridge between the central broker and the new broker to feed the selected event streams to the application.

In our view, this is really the key learning from this project. In order to incrementally build business and interaction logic and add new services to the platform, the concept of an event mesh using publish/subscribe with a clear topic taxonomy was key to success.

It is obviously important to address real-world business applications in every project. However, we also need to make it interesting and fun! That is why we chose the race track as the demo system, combining both.

We would also like to thank our partners for their invaluable and timely contributions to make this project a success. And a special thanks also to the Bosch team for sponsoring and supporting this particular part of the project.

What’s next?

As you may have gathered, we completely put aside two crucial aspects of an IoT platform: Device Management and Access Control. We are currently busy working on a management interface for the event mesh that can be used by a device management platform. When provisioning new device types and individual devices, the event mesh will be automatically configured to create the authorization and access control for the new devices on their respective edge brokers as well as the bridges to connect the new data streams.

In upcoming articles, we’ll describe the details of the various APIs and also make the XDK application available on GitHub.

Stay tuned!

The post Rapid IoT Prototyping with the Bosch XDK110 and an Event Mesh appeared first on Solace.

How to Ensure the Success of Connected Vehicle Initiatives

Ricardo Gomez-Ulmke — Mon, 24 Jun 2019 19:53:04 +0000

The impact of connected vehicle initiatives on the automotive industry can’t be overstated. A KPMG survey of auto executives found that 85% of executives agreed that the digital ecosystem of connected vehicles will generate higher revenues than the hardware of the car itself. To establish a leadership position in this fundamentally new market, car makers and those who provide supporting services need to understand the opportunities that exist, the challenges they face, and how to overcome them.

In this piece I’ll explain all three, starting with the fundamental building blocks, or steps along the path, on which custom value can be built.

The three kinds of information connected vehicles create and consume

Before looking at the ways to build connected vehicle value, let’s look at three kinds of information connected vehicles generate and consume.

Drive data. Connected vehicle systems can generate helpful information about not only the location and speed of the vehicle, but also the position of the accelerator, brake pedal, steering wheel, and turn signals, along with streaming data about fuel consumption, for example.
Diagnostics data. This includes periodic measurements taken to ascertain things like the battery charge status, fluid levels, and tire pressure, along with pressure and temperature readings from the engine, transmission and other systems.
Instructional data. This kind of information in connected vehicle scenarios flows the other way. The ability to send commands that affect the behavior of vehicles, such as remotely locking or unlocking the car, changing the color of LEDs, or displaying a vehicle-specific alert, offers tremendous value.

Building blocks of connected vehicle value

Now let’s look at how you can leverage those three kinds of information to build value for drivers.

The first building block of potential value in connected vehicle initiatives is offline, after-the-fact analytics and reporting. By that I mean collecting data from vehicles not in real-time from anywhere, but when they are parked at home, for example. The goal of such services is to look at everything that happened to the connected car, what was done about it, and what actions might have led to a better outcome.

The next level of value is achieved when you can implement real-time monitoring and interactions. By that I mean getting a real-time view of what’s happening with a given vehicle, and having the ability to improve outcomes this time by remotely controlling some aspect of the vehicle’s operation and/or alerting a 3rd party of a situation, such as a flat tire, in which a driver may need assistance.

The third step is to move beyond mere monitoring and into the realm of event-driven alerting and even the ability to predict problems before they occur. The power to predict and proactively address component degradation or failures before they affect the efficiency or operation of the vehicle gives vehicle makers a powerful way to keep customers happy. An example could be the prediction of a component failure within the next 100 miles, which triggers pro-active communication and assistance to replace/repair said component.

The fourth building block of connected vehicle value lies in the ability to federate information and events across an ecosystem of companies that provide services in areas such as entertainment, navigation, maintenance, breakdown assistance, insurance and more.

Creating the value framework

As with any transformational and innovation project, connected vehicle initiatives demand that you create a strategic roadmap that defines what will be done by which department to what end. In this case, a roadmap for the requisite cooperation between the hardware and software engineering teams working on the vehicle itself, the digital services division, the IT divisions delivering the applications, and the production and post-sales divisions.

This roadmap should clearly communicate the vision and strategy, the phases of the project, and the approach and goal of each phase. It’s equally important to understand where the value is generated in the journey of building a connected vehicle platform. The following figure shows such a value framework, combining value creation phases with business services and underlying IT building blocks.

This Connected Vehicle Initiative Value Framework example combines the four levels described earlier with increasing value delivered from left to right. Note also that as soon as the level Interactive is reached, information flow must become real-time and the vehicle must always be connected.

To augment our understanding of the various phases further, let me offer a set of simple questions each phase is trying to address:

Reactive : what happened and what can we do better next time?
Interactive : how can I remotely control the operations of a vehicle?
Predictive & Proactive : what is happening right now and what may happen next?
Federated : how can I federate data and events across the ecosystem to create the best possible outcomes for the vehicle owner/driver?

Overcoming infrastructure challenges

Connected vehicle initiatives present considerable challenges. You’re dealing with massive numbers of complex machines being operated at high speed and in close quarters by drivers of varying skill levels, on roadways of varying quality, and in all kinds of weather conditions.

Putting in place an infrastructure that can handle the efficient, event-driven, real-time data distribution it takes to add connected vehicle value to that chaos isn’t easy, but it is possible.

Vehicle

First, let’s look at the vehicle itself. The most obvious challenge is the number of cars you’ll want to connect, usually measured in the millions. The second challenge, then, is that many interactions with connected vehicles require low latency. If somebody tries to unlock their car door with the app on their phone, for example, their patience will be measured in seconds.

Complicating the need to connect many vehicles with low latency is the fact that because cars are frequently on the move, they experience varying levels of connectivity – including periods of complete disconnection. Your job is twofold: manage connections in such a way that you can a) send and receive low-latency communications to and from vehicles whenever possible, and b) deal with slow connections and disconnectedness in a way that ensures the eventual delivery of critical data, alerts and instructions.

The final challenge at the vehicle end of the equation is security. I’m not just talking about the security of the vehicle itself, but your ability to ensure the security and safety of drivers and passengers. This entails collecting and acting on important events in a timely manner, and making sure information about the location and operation of every vehicle is kept private. A fine-grained trust framework must be established for each type of information, and the owner of that data must have full control over the sharing of said data to ensure only authorized parties can see and process it.

Regional edge network

I refer to the network of edge nodes that vehicles connect to as a regional edge network. These edge nodes are geographically distributed and are placed as close as possible to the actual vehicles to minimize latency and connectivity issues. Each node manages a certain number of connections and aggregates connections within a region. A region could be U.S. Northeast, southern Germany, etc. These nodes aggregate connections and messages from a subset of the global vehicle fleet and are responsible for routing events, data and instructions to and from the IT applications and individual vehicles.

It’s essential that these nodes can handle millions of concurrent connections and the volume of messages that entails, and deal with the recurring connect and disconnect behavior caused by the mobile networks’ availability.

Let’s imagine a tunnel – vehicles lose connectivity when they enter the tunnel, and must instantly reconnect when they emerge. When you think about all the vehicles entering and exiting each tunnel, and the number of tunnels, this alone generates a lot of disconnect/reconnect behavior.

Application platforms

In a globally connected vehicle system, applications and services may be deployed within the edge network, datacenters and any number of public clouds. The regional edge nodes now need to be wired up to be able to distribute data and events to each of these applications, wherever they are deployed.

In my experience, as the platform evolves and value is created through its phases, applications are added, removed, duplicated and re-deployed as and where the need for efficiency and latency requires it. Hence, these wirings from edge nodes to applications must be able to handle the aggregation of potentially all messages and events from all vehicles, and do so dynamically – i.e., automatically routing data to wherever there is a consumer without the need to re-wire the entire infrastructure.

So the routing challenges move from individual vehicles to the ability to aggregate massive numbers of events and data, and route them globally to distributed applications deployed across hybrid cloud infrastructure that includes public cloud, private cloud and on-premises environments.

Ecosystem edge network

To achieve the highest level of value creation, the platform must also federate data and events across a network of service providers. This ecosystem is, by its nature, heterogeneous from a deployment model and technology perspective, which means it must support diverse APIs and protocols and integration with established SaaS providers. This introduces the need for edge nodes that are seamlessly interconnected to the application services regardless of deployment location.

However, this is not the main challenge. Our goal is to create value for the owner and driver of the vehicles, and this can only be achieved by creating a trust framework that balances the need to a) share data with complete transparency and b) respect individual privacy. Without a verifiable and auditable data flow combined with a detailed consent framework, trust cannot be established.

From a technology perspective, this requires the infrastructure to handle identities of not only vehicles, organizations, and individuals but also of data items. And access to each data item must be managed and controlled at scale – including granting of access as well as revoking of access, and reporting thereof. Of course, metering and billing records complement data federation to monetize external service provisions.

A great example of the complexity of data sharing is the ‘delivery to the trunk’ scenario. Here, a consumer chooses their car as the delivery address for their purchases. This implies a very tight control & access framework across the entire value chain of the process: the e-commerce company shares the car information with the delivery company that, in turn, shares it with the delivery driver. However, the driver may only have access to open the trunk when a) they are close to the car, e.g., within a geo-fence of 10m, and b) within the specified delivery time range. Access control here is dynamic, where authorization by the owner of the car is given only under certain ‘situational’ conditions.

The following figure summarizes the four swim lanes, the different requirements in each, and the need for end-to-end routing:

Developing valuable connected vehicle solutions

There are two key elements to developing connected vehicle solutions. The first is bridging the gap between the world of applications and the world of automobiles, i.e., building bridges between the two environments so information and events can flow seamlessly between vehicles and the applications and cloud services they increasingly rely on for connected vehicles services.

The second is putting in place the data distribution infrastructure that leverages that integration to efficiently route massive amounts of information to and from connected vehicles. Let’s take a closer look at each of these requirements.

Integrating the application and automotive landscapes

Connected vehicle programs need to integrate many components and layers ranging from the enterprise IT landscape to the IoT-based world of connected vehicles themselves. This includes the following kinds of systems, sensors and devices:

Business applications : maintenance, fleet management, insurance, maps
Integration : APIs and protocols, streaming APIs
Data infrastructure : reference data, time series data, streaming analytics, machine learning, location services
Management infrastructure : remote management, security and access, ID/entitlements, privacy
Connected vehicles : cars, buses, trucks, trains

Meeting the data distribution needs of connected vehicle programs

The data distribution infrastructure for large-scale connected vehicle deployments needs to meet the following four requirements:

It must be a flexible, self-learning system that intelligently routes information along the network path to ensure prompt, reliable delivery to its destination.
It must enable the easy integration of legacy and emerging technologies by supporting all kinds of communications protocols (e.g., AMQP, JMS, MQTT, REST and WebSocket) and link systems running in diverse cloud and on-premises computing environments.
It must facilitate the centralized deployment and management of hundreds or thousands of nodes to support massive scale, and do so with enterprise-grade performance, robustness and scalability.
The system must offer the required access and control of data flows to create the required trust as well as the auditing, metering and billing ‘hooks’ to monetize the offerings.

The only technology that meets these requirements is what I call a hybrid IoT event mesh – an infrastructure layer that enables a connected vehicle platform to evolve along the discussed value framework.

Summary

In this article I have defined a roadmap using a value framework to articulate how value, services, the ecosystem, and technology work hand-in-hand to create a successful connected vehicle initiative. I have broken it down into a set of infrastructure challenges within the four swim lanes: the vehicle, the regional edge network, the application platform, and the ecosystem edge network. I have offered an initial assessment of how a trust framework can be established to make people comfortable with the platform. Finally, I described how an event mesh is the ideal foundation for a connected vehicle platform.

When choosing the underlying technology for your connected vehicle initiative, consider the following questions:

Is it dynamic? Does it support dynamic routing so it can easily scale up and down, and adapt to outages?
Is it open? Does it support open APIs, communications protocols and integration capabilities?
Is it simple? Can you easily manage, scale and secure an event mesh consisting of hundreds or thousands of nodes?

If you can answer all three questions with an emphatic Yes! , you’re on the right path.

The post How to Ensure the Success of Connected Vehicle Initiatives appeared first on Solace.