This blog post contributed by John Samuel who focuses on the Internet of Things and M2M with IBM.

Most of you are probably asking yourself why I’ve got a picture of a cow in this article. Well, you’ll have to wait and see.

A few weeks ago at the IBM Impact conference the IBM Internet of Things (IoT) Cloud was announced. You can access the QuickStart alpha here. Since then I’ve received lots of queries from customers and IBMers alike who want to know the answer to this question: “This replaces IBM MessageSight, right?”

The answer is of course “No, it doesn’t.”

But that question does lead to another harder one to answer: “When do you use the IBM Internet of Things Cloud and when do you use the IBM MessageSight appliance?”

The default answer of “It depends” springs to mind, which doesn’t help very much, now does it?

Okay, let me start at the beginning, and then perhaps we’ll have an answer. The IBM IoT Cloud is available to try at no charge, so feel free to give it a go. It's an alpha at present but you can hook up a device and see that data interactively displayed. Neat and useful—I think you’ll agree.

Over time more functionality will be delivered in the cloud service, including a historian. This historian will allow you to store the device’s data for retrieval and inquiry at a later date rather than just displaying the data in real time. This all sounds very similar to the IBM MessageSight appliance, and you may have seen from my previous blog posts that you can connect up to a million devices to a MessageSight appliance to enable the device data to the enterprise. So on the surface it does appear that they are the similar tools for the same issue. The actual difference might be cultural or at least a buy-verses-build approach to a solution.

Currently the IBM MessageSight appliance has to be purchased from IBM. Once it is delivered the appliance has to be housed in a location, connected to devices and integrated into existing enterprise infrastructure like data stores or analytics engines.

I’ll use a few fictional scenarios to explain.

Let’s say a car rental company purchased an appliance to enable its minute-by-minute car sharing app to be newly deployed onto customers’ smartphones. They’d have to connect the appliance to the in-house data repositories to process the car booking requests received by the appliance from the smartphones and even the cars themselves. It is highly likely that this company would have existing data centers, IT infrastructure and experienced IT staff who know how to perform these vital tasks. So investing in an appliance to enable the data connectivity that can scale to millions of devices in moments makes sense.

Or, let’s say a dairy farmer had the sensors on his cows connected during milking. It would be unlikely that he’d have access to existing infrastructure or skilled IT experience. This is when the simplicity of a cloud solution would be of benefit—hence the IBM Internet of Things Cloud, which is a pay-as-you-go service. This rental approach would give the farmer the service he needs to connect to his herd’s monitoring sensors but without the initial capital expenditure of IT overheads. As it is a cloud service, the farmer can pay for what he uses. So if his herd increases or decreases, the costs would rise and fall in line with this fluctuation. Now you know why there is a picture of a cow at the top of this article.

This is just one reason why a company might choose to have the appliance housed in its data center over opting for the cloud service.

The IBM Internet of Things Cloud QuickStart is currently in alpha stage, but if you’d like to hear about newly deployed features and functions just register to receive updates. Then, when the historian is added, Mr. Farmer will be able to check Daisy’s current sensor readings with her previous milking parlor records.

Could you make use of the IBM IoT Cloud? If so please feel free to comment below, or you can follow me on LinkedIn and Twitter.

This blog post contributed by John Samuel who focuses on the Internet of Things and M2M with IBM.

If you’ve not seen part 1 of this blog, in which I discussed the possible benefits of a connected car for automobile makers, check it out here.

As we saw in part 1, a connected car is great for the manufacturer. But what about you, the consumer? In this post I want to show you how connected cars could help everyday drivers. When you buy your next car it could be a connected car, and you might very well get a smartphone app along with it.

Where is my car?

Imagine you’ve driven to a really busy car park at a supermarket. Maybe it is the Christmas rush, so you’ve not parked in your preferred area. As your mind might well be on other things, you forget to note down your car parking bay.

As you leave the shops you realize you have no idea where you parked your car. If the car is connected and you have the manufacturer’s app, the car would be able to tell your smartphone where it is, allowing the app to draw a walking map of how you can get back to it. No more lost car, and no more walking aimlessly around looking for your car.

Warm it up please

Right now how warm or cold is your car? If you can look out the window you might have an idea. Often you don’t have that luxury, though; if you are shopping or in an office you might not know what the weather is like.

Having a connected car and the associated app could solve this. By using the app you could see what the temperature of the car is, so as you leave you could start the car warming up if it is cold or cooling down if it is too hot. Then when you get into your car it is already at the temperature you like before you drive off. How cool is that? Sorry. I couldn’t resist the pun.

No more dead batteries

We’ve all seen or even done this—left the car’s lights on. If the lights are left on without the engine running, the battery gets drained and the car will not start when you need it to. With connected cars and smartphone apps, the car could tell you if something is wrong, allowing you to remotely turn the lights off, so you have no more dead batteries. Here’s a demo showing how this could work using IBM MessageSight.

Speaking of dead batteries, it is vitally important that any app that is produced for the connected car doesn’t run down the battery of your smartphone. This is why Message Queuing Telemetry Transport (MQTT) protocol is used by Facebook, among others—because of its extremely efficient battery usage.

The mobile weather station

I’ve spoken about the benefits to the car manufactures of predictive part failures, and above I outlined some benefits to you, the car owner. But connecting a car has other opportunities and indirect benefits. Cars are packed full of sensors; for example, you know the temperature outside the car as you drive along, and if it starts raining it automatically puts the wipers on. If you could feed that data, combined with your smartphone’s GPS, to a meteorological office, then they would have the ability to do micro weather analysis. If multiples of cars in an area have their wipers on it probably means it is raining. As vehicles enter or leave the raining area their wipers come on or go off, and this would allow the meteorological office to plot the size of the rain-affected area. Data like this is invaluable to them. The more weather stations they have, the better accuracy the can build into their prediction models, giving us better weather forecasting. Currently the meteorological offices might have thousands of static weather stations, but with connected cars and smartphones they could have millions of mobile weather stations. Getting the data from these mobile weather stations is where IBM MessageSight can help. It can connect one million devices or cars concurrently, so there’s plenty of scalability—just what the weather forecasters need.

What other possibilities can you imagine for the connected car? In my next blog post I promise not to be so car-focused, but until then if you have any comments please leave them here or connect with me on Twitter or LinkedIn.

This blog post contributed by John Samuel who focuses on the Internet of Things and M2M with IBM.

Well I don’t mean actually speak to you—that would be freaky. Imagine you’re driving along and the car starts speaking—that would put me off from driving slightly!

So what do I mean when I say “communicate with you”? You might be surprised to know that cars have a huge amount of data within them, but they do. Even if your car is 10 years old it probably has a fair amount of data. But when a car leaves the production plant the manufacturer no longer has access to this onboard data.

If the car could communicate, allowing the manufacturer to access its data, then maybe it could preempt part failures.

So let’s imagine a scenario

You‘re lucky enough to have a new car, and let’s say it comes with a four-year warranty. Fast forward three years and all of a sudden your car stops.

While waiting for the rescue truck to come you’ll probably use your smartphone to tweet or post on your social networks that you’ve broken down, naming your vehicle manufacturer. Now all your chums will know your car has let you down. This is bad news for the manufacturer, even though it might not be their fault. Maybe the car knew what was going wrong but it couldn’t tell you.

Replay the above scenario but this time with a connected car

Again you’re lucky enough to have a new car with a four-year warranty. Three years into this warranty the water pump starts to fail, but this time since the car is connected it is able to send a Message Queuing Telemetry Transport (MQTT) message with this vital data back to the manufacturer. The water pump issue is noticed, and since your car is still under warranty the after-sales service team contacts you to ask you to bring the car in for a minor repair. This isn’t urgent but needs correcting. So you don’t break down! And therefore you don’t tweet or post bad news; instead you tweet and post good things about the car and the maker.

Good news for the car company, right?

Well, yes it is. But it goes further. Maybe this water pump was designed to do 300,000 miles but it started to fail after 50,000. Maybe this is a one-off event? Or maybe this is a start of a trend. If so the after-sales team could put a watch on water pumps and notice a water pump failure trend starting.

The dreaded mass product recall

Currently car companies would have to do a mass product recall in a case like this. Car companies dread this because it really hurts sales and the pain can last many months. But if the car is connected they wouldn’t have to do this mass product recall. They could see which cars have defective water pumps from the data arriving from connected cars that sent in MQTT messages through IBM MessageSight. Rather than issue a product recall the company can reach out to the individual drivers and ask them to come in for a part replacement at no charge. Not only does this benefit the car maker and the driver who doesn’t break down, but it also helps the dealer network to schedule the repairs.

Only this week Volkswagen has issued a 2.5+ million car recall, and there are many more examples like this. This damaging news has been played out across the media.

Okay. You probably think the connected car is science fiction or years away like the driverless car. But no. This new IBM Technology is being used right now by car makers across the world as a way of connecting their vehicles so they can receive the data that is currently lost.

So maybe your next car will be a connected car? Many of us now have smartphones, and they are certainly useful in the event of car trouble, but connecting your car so that it can do predictive maintenance—now that could be even better.

You might be wondering what else is in it for you, the car customer. In my next blog post I’ll be telling you about a few of the possibilities that a connected car can bring to the car owner with a smartphone. In the mean time, please feel free to leave a comment here or on Twitter, or connect with me on LinkedIn.