Mobimation mobile to machine access solution

The Mobimation solution has so far been described in three blog posts:

• Enabler
• Device Hub
• Payment solution for Device Hub

This article elaborates on the potential of the overall solution.

But wait ! Do I see the word solution here before even beginning to talk about a problem?

Ok that´s how engineers often do it. Dive directly into the fun part without describing why. But no worries. There is a background idea with all this. Fortunately in this case the solution can really solve problems.

Here´s an attempt at formulating the problem:

• There is a lack of a uniform way of getting Internet access to physical equipment and sensors.
• Missing today is a distinct generic controller solution for quickly Internet enabling physical machinery and bring their functionality in the hands of a mobile user.
• Missing today is an easy way to set up remote sensing and control so that it can be reached from a mobile device.
• A lot of equipment exists out there today that lack any way of remote interaction but the user need to be physically present at the same location to operate it. Time is spent on travel and traffic jams and means cost for service personnel. Private consumers sometimes dream of a way to monitor something at home but have not yet seen any good solution.

This rests on the assumption that

1. There is an interest in the world of being able to remotely monitor and control stuff from a mobile phone if it were at all possible in an easy and affordable way.
2. Effortless connectivity means more services being developed (adoption) which stimulates a business growth. If developers can focus on endpoint function development (client and remote IO behavior) then this can save implementation time.

What got me going on this was realizing the power of mating small Wifi interface modules with a microcontroller on a small board. This combo becomes kind of disruptive in the sense of how things that up til now has been quite standalone can now be access enabled at lower cost than ever before.

One of the more iconic designs that inspire is the FlyPort module developed by the italian OpenPicus project. It simply mates a Microchip PIC processor with a Wifi module. OpenPicus have developed an IDE and ported freeRTOS to it. Another illustrative example is the Arduino based BlackWidow card by AsyncLabs. Both of these modules hints at an era to come of connected devices and you can begin prototyping such stuff now. Many such prototyping boards are based on open source designs which can be re-used in commercial solutions.

Wifi has a close relation to Internet Access and my tests proved that such a Wifi adapter combo can connect to a Wifi router using WPA2 encryption and from there reach an internet server within a few seconds after power on. That worked fine towards a 3G Wifi router, a nifty solution for deploying connectivity without a need for fixed network in areas where this is possible.

Combining this with physical interfacing to sensors and other IO, a uniform way of accessing such little modules from the Internet, and the power of mobile application dev platforms can be a great enabler for remote interaction.

The Mobimation solution consists of three parts:

1. Adapter module (Mobimation Enabler)
2. Device hub server (Mobimation Exchange)
3. Mobile application API (Mobimation API)

These three parts together is a powerful combination:

1. The adapter modules each interface to a case of real world physical sensing and control.
2. The hub server brings all those modules online and presents a uniform way to reach all sorts of physical interaction functionality out there.
3. The mobile application is the end user tool for interacting with an adapter module via hub servers. And an adapter module can represent a piece of equipment out there.

In (1) the actual IO controller firmware and physical interfacing customizes the adapter for a specific solution. I am working at an attempt at a generic firmware realization that work together with a mobile application to allow mapping of typical sensor and control tasks onto a user customizable interface. However I envision the majority of deployed solutions will be custom developed (app + adapter firmware) to optimally cater for the case at hand.

(2) can have more or less rich feature set but the main principle is a multithreaded server that

sits as a hub between modules and clients to pass data streams across. This can include payment gateway functionality as well.

In (3) it is possible to define API´s that encapsulate the connectivity details and allow quick access to the peer remote end adapter. Obvious platforms to look at covering is Android and iPhone. Even the millions of phones out there with simpler Java ME platforms are interesting since many consumers use these daily.

By making sure the adapter module (1) has a generic Internet connectivity part then all such modules can autonomously register with the hub server (2) for further access by clients (3).

Now envision 2300536 such distinct adapter units out there, each booted up and registered its online presence with a farm of load balanced device hub servers. This means suddenly a huge plethora of functionality online. The idea is of course not that each user would access each device, analogous to how each user would not access each web page in the world. But the uniform way of making resources available simplifies the implementation of the combination of (1) adapter module and (3) client application that look up and connect to each other via (2) the hub server.

In a commercial deployment the hub server also represents a place where a community of customers can build and where payment gateway solutions can be integrated.

Typically an adapter module (1) and client application (3) can be seen as an inseparable entity distinctly developed together to implement a remote service. The access infrastructure represented by the hub server (2) simplifies getting these two endpoints to talk to each other and thus makes it interesting for service developers.

• Easier to develop a solution and get it out to end users.
• More solutions developed grabs consumer interest.

A demonstrate-able prototype of this solution is under development.

I limited this to mobile client access, however the server hub can of course also be accessed by web services that interact with physical sensors and machinery.

Mobimation AB is looking for partners worldwide interesting in collaborating on the commercial realization and exploitation of this solution. People experienced in what specific interfacing needs exists. How a solution is best packaged in terms of hardware design. Production resources, sales, venture capital.