Following the Bosch ConnectedWorld Day 1 keynotes, we broke out to two streams of sessions: business and technology. I’m at the technology track, where we heard from Jim Morrish of Machina Research on the market evolution from M2M to IoT. He had some great examples of how the early telematics/SCADA market evolved to M2M, and is now becoming the more complex and connected IoT market that includes far more than just industrial machines and applications: corporate IT systems, published data feeds, crowdsourced and social media data, and more. Instead of end-to-end connections between hundreds or thousands of like devices, solutions now need to include millions of heterogenous devices and data sources. These changing requirements ripple through the entire software stack: from communications infrastructure and device management to the applications development and operational environments. Being able to communicate, support devices and manage the data flow are the base functionality required, whereas the application development tools are where we’re seeing the competitive differentiators between solutions. In M2M, it was all about the devices and connectivity; in IoT, those are assumed to be offered as a standard platform, and the application developer is key to to creating flexible device-agnostic applications and providing deep integration to business processes.
The remainder of the track was led by the Bosch methodology and solution architecture team — Dr. Frank Puhlmann, Veronika Brandt and Steffen Gürtler — showing us the Bosch software suite for IoT and how the components within it are assembled into a solution. Puhlmann started out by defining the platform, which includes M2M, BPM and BRM; he stressed that a key differentiator for them is being able to have a tight integration between devices and business processes. He used the example of ACME Cleaners (cue Coyote and Roadrunner), an office cleaning company that has a fleet of robot cleaners. And yes, we had a robot cleaner in the presentation room. It’s a commodity cleaner (iRobot), but integrated with a variety of other devices and processes: motion detectors and scheduling software to determine when to run, but also linked to the customer service information such as contracts. He highlighted some of their partners’ hardware involved in the test solution, including a Cisco router and Vodafone SIM M2M, plus their own motion sensors. He also showed a smartphone app that can turn the cleaner on and off, return it to its dock, and even play sounds. He demonstrated a portal that they created, allowing ACME to monitor status and to control devices remotely, but also to process related contracts and invoices. We also saw the Vodaphone portal that can be used to monitor and control the SIM card connections for each device at a more technical level. The entire stack supporting this includes a UI integrator and forms engine connecting to BPM, BRM and M2M management, and including identity management for security. The development environment is model-based, including BPMN for process models, and tightly integrated with the device management.
Brandt and Gürtler then gave a deeper technical look at the ACME Cleaners scenario implementation. In general, the M2M layer interacts with the device events, capturing information that will be used by the higher-level layers, such as area covered by any individual robot cleaner, which may impact billing amounts. The BPM and BRM layers handle customer and device registration, and invoicing according to the billing rules.
The M2M architecture has a central registry of devices that includes information such as the properties of each device, a standardized container for accessing devices, event subscription and processing, and REST APIs. Pretty much any device with an IP address can be integrated into their architecture fairly easily, even more so it if has a REST API already; the ability to control any device will be specific to what functionality that the device exposes. The BPM suite provides a model-driven environment for creating process models, while Visual Rules provides decision tables and trees for modeling rules and decisions. Bringing these together allows for both process-to-device flows — controlling the device schedule, for example — and device-to-process such as sending maintenance requests, with a common identity management layer to control security and access.
Apologies for the graphics quality: the presentation slides aren’t available yet so I’m making do with some bad shots of the projected screen using my phone, and inserting using WordPress for Android which I apparently haven’t completely figured out.