Enabling Connectivity

LONDON — Sept 16, 2010 — Recently, I was asked to present at London’s Future World Symposium, a conference focused on connected, smart and electronically enabled devices and experiences. My presentation, entitled “Enabling Connectivity,” is also the topic of this story.



Mike Hall, principal software architect in the Windows Embedded Business at Microsoft

It would be very easy to focus my presentation purely on the topic of connectivity, but connectivity is really only one part of having a smart, connected, electronically enabled device. In forthcoming posts I will address other issues such as software trends, the user experience and cloud computing infrastructure; in this post I will focus on connectivity.

The connectivity story wouldn’t be complete without a short hop into the TARDIS to look at where the computing and connectivity story started. Interestingly, there’s a blog post written by Andrew Coates called Standing on the shoulders of giants that compares the evolution of software with changes to plumbing technology from caveman times to modern day. This in many respects mirrors the transition from mainframe computing to smart, connected devices.

Mainframes to Devices

It’s hard to imagine that just 50 years ago the cutting edge of computing technology was the mainframe computer — a small number of people queued up with punch cards to get access to limited computing resources in fixed locations. The minicomputer was somewhat similar to the mainframe — it’s true that more people had access to computing power then, but still in fixed locations with limited networking capabilities.

By the 1980s, access to computing technology was becoming very widespread thanks to desktop PCs (and thankfully no more punch cards or paper tape!). However, connectivity was still limited to the enterprise space or limited dial-up options. During the 1990s we really started to see widespread connectivity between people, computers and the Web. Computing as an experience was still tied to a physical location — a home or work office.

The ability to break out of a fixed computing location came with the introduction of Wi-Fi and laptop/netbook computing. Wi-Fi is simply an extension of an existing LAN infrastructure, though, which means users are constantly jumping from one island of connectivity to another, and in many cases are locked out of being able to connect by needing to pay for access.

The computing devices of the past were human-machine interaction devices. We are now seeing the next iteration of growth: both devices and connectivity are being driven by device-to-device (machine-to-machine or M2M) communication as opposed to human-device-cloud communication.

Demand for computational power and connectivity is increasingly driven by M2M communication. These are not general-purpose computing devices, but are fixed-function computing devices that are increasingly remote, mobile and movable.

Connectivity Challenges

Embedded device developers face a range of choices when figuring out which connectivity modules and operating system platforms to develop against. For M2M solution developers, this creates huge development and integration challenges if a device is to connect to the enterprise or cloud. Also, given the specific and often exacting requirements stipulated by cellular operators, this often results in developers pretty much building a custom solution for each geography and dealing with the integration issues it creates in the back end.

When you add on top of this the sheer time-to-market delay involved in custom development, and then the often lengthier delay caused by the testing and certification procedures that cellular operators need to go through to ensure that they can at least anticipate the behavior of a device on their network, it’s not a surprise that a lot of OEMs and enterprise customers have historically given up because the whole process was too hard, too long and too expensive.

The good news is that in the last couple of years there has been a huge upsurge in interest in the connected devices space. Operators are increasingly looking to M2M as a major driver of new revenue streams (particularly with the advent of 4G). In addition, there’s more willingness and flexibility to develop new commercial structures that are needed to enable the development of solutions and operators. M2M service providers are also investing in services and billing layers to enhance their ability to manage connected devices. There’s still much to do to make connectivity another component that solution developers can add to their toolbox, and even more to do to realize the full potential of connected device solutions with this basic foundational element in place.

Let’s assume that we’ve solved the basic issue of getting connected. Our sparkling new embedded device now has a data pipe to the cloud and can communicate with other devices and cloud-hosted Web services.

There are other issues within the device that now need to be addressed. Some of these relate to silicon trends — specifically the move from single-core to multicore and how our code is going to take advantage of available processing power. There are also software trends to consider when building smart and connected devices, such as the move from low-level assembler through C/C++ to higher-level languages. In addition, the user experience both for the device shell and applications should be taken into consideration, together with cloud-computing capabilities.

If you’re interested in learning more, please check out my full Future World presentation. Otherwise, stay tuned for more on connectivity, later this year.

Mike Hall is a principal software architect in the Windows Embedded Business at Microsoft, working with Windows Embedded Compact and Windows Embedded Standard.

Mike has over 30 years of industry experience and has been working at Microsoft for over 15 years — originally in Developer Support, focusing on C/C++, MFC, COM, device driver development, Win32, MASM, and Windows CE operating system development, and then as a systems engineer in the Embedded Devices Group before taking on his current software architect role. Mike also pens a blog covering Windows Embedded developments that can be found

here

.