Do-It-Yourself M2M Challenges

By Brian Vezza

Following up on my last blog post, I’d like to explore the concept of do-it-yourself (DIY) M2M. 

For companies just starting M2M projects, a DIY approach can look attractive.  This holds true for both companies building devices with M2M functionality and for those deploying devices and M2M services. But here’s the challenge, to borrow a quote, “you don’t know what you don’t know” -- meaning you don’t know all the pitfalls you may face. 

M2M sounds deceptively simple.   Take a device, connect it, and send data to another machine.  That can’t be too difficult, right?  We do this every day with our iPads, laptops, and cell phones. Unfortunately those are all “human” devices as opposed to embedded devices.  It took many years and focused efforts to make connecting to iTunes so easy.  The typical embedded device wasn’t designed to connect from day 1, and that’s where the challenges come into play. 

Okay, so connectivity is a challenge and I described this in detail in my last post.  But what else do we need to be concerned about? 

Often teams start with the hardware.  That may not be too difficult because design teams work with hardware all the time, although it can be tricky depending on the device and requirements.  Embedded software is somewhat obscure, but there are people who know this very well, so that can be handled without too many challenges with the right people and the right expertise.

Another point of concern is that connectivity leads to many other requirements and these are often underappreciated.  As soon as you connect an embedded device, a string of requirements come into play.  How will the device be managed?  The devices may be deployed far from the IT department or in hard to reach locations, so don’t plan on a truck roll to plug in and troubleshoot.  What protocols will be used?  Some M2M protocols are more common, but others are just emerging.  Sourcing components and then developing and integrating the software can be interesting.  Security is a must have.  What about the cloud, upgrades, etc.?  Will there be some mission-critical aspects which require additional reliability or performance?  Don’t forget about the second “M” as that’s important too.  You can’t have M2M without it!

Then there’s the whole reason you want M2M in the first place.  This varies, but is typically to either monitor or control an aspect of your operating environment.  This generates data that can be analyzed to provide “situational awareness” which will be applied to your specific situation.  Of course, you’ll probably want to do this at scale and add new devices over time.

All in all this leads to any number of pitfalls that can slow down your product or project, increasing risk and expenses, and reducing value.  DIY M2M requires a broad range of expertise.  Companies have expertise in many areas, but will almost always be missing a few areas and may not recognize it until deep into their project when it can be expensive to adjust.  As mentioned above, the DIY approach and challenges apply to both building products and operational concerns when implementing solutions.  These can be significant and I’ll continue to explore this in future posts.  There has to be a better way…

 

For additional information from Wind River, visit http://www.facebook.com/WindRiverSystems.

Comments

[Shane]

I will go for it provided the ecionmocs is atleast the same as present. Some incovenience I can take it up like some interruptions etc for the sake of environment protection.But if the cost is going to be higher then I am not interested. There are several things which I can forego like using an air con etc to help the environment at the present. So it boils down to dollars.