“A man’s reach should exceed his grasp, or what’s a heaven for?” – Robert Browning

We’re a long way from the clouds. Well, unless you’re an astronaut, in which case, you’re a long way above them. But for us earthbound engineers, “the cloud” can be a very long reach.

The Azure sky, as it were, seems so approachable at first. Amazon Web Services, IBM Watson, Google Cloud Platform, and the various and multitudinous cloud providers all make it seem so easy. Just connect your IoT device and you’re on your way – right?

Eh, not so fast. There’s many a slip ‘twixt cup and lip in the connected-cloud business. It’s a bit tougher than just adding Ethernet (or Wi-Fi, or Bluetooth, or Thread, or ZigBee, et al.) to your IoT gizmo and expecting it to magically talk to similar devices all over the globe. The physical connection is the easy part. It’s all that messy software that makes it problematic.

But don’t the cloud providers already handle all that software? Don’t they provide SDKs for their cloud services? Indeed, they do. And, while that’s sweet and considerate of them, it’s a long way from a complete solution.

The fact is, cloud providers’ SDKs stop far short of what you need to get your devices up and running. The SDKs are generic on purpose, and they don’t include anything hardware-specific or OS-specific. Amazon isn’t interested in providing low-level drivers for your Internet-enabled steam whistle, or that cloud-connected thermostat your friend is developing. Their responsibility stops somewhere in the stratosphere, nearer to their cloud resources than to your earthly system details. There’s quite a bit of airspace between the two that needs bridging.

That’s where Mentor comes in. The big embedded-systems company has seen its customers struggle to forge cloud connections and took pity on them, so it now offers the “Mentor Embedded IoT Framework” (necessarily abbreviated MEIF) to fill in that skybridge to the clouds. It brings abstract cloud connectivity closer to the ground.

It’s not a panacea, and it’s not entirely universal. But it’s real code that solves real problems. Right now, MEIF works on exactly two operating systems and connects with two cloud providers. Specifically, it runs on either Mentor’s Nucleus RTOS or the company’s Embedded Linux. At the other end, MEIF is compatible with Microsoft Azure or Amazon Web Services. If you’re connecting one of those operating systems to one of those cloud providers, MEIF will likely save you a lot of effort. If not, Mentor says wait and see what other endpoints MEIF will support in the future. (MindSphere would be a good first guess, given that Mentor is now owned by Siemens.)

What exactly does MEIF do that the cloud providers don’t already do? The company’s General Manager, Scot Morrison, uses the example of over-the-air (OTA) software updates. Cloud SDKs nominally support OTA updates, but only to the point of APIs. Those make great hooks for implementing file downloads, verification, and onboarding, but they don’t do any actual work. It’s a bit like handing someone a dictionary and saying, “Here are all the words you need. Get started.”

A cloud SDK might facilitate generic file downloads, but not software updates specifically. It probably doesn’t know what type of files you’re downloading, where they should be stored, or how they should be authenticated. Is it a security patch? A Docker container? Is it an urgent update that should be applied immediately, or one that can be postponed until the next reboot?

The SDK certainly isn’t equipped to handle the vagaries of flashing memory, keeping backup copies, or what to do in case of a failed update. These are all system-specific functions that Amazon, Azure, and the others can’t be expected to handle. Yet those are precisely the functions that can soak up a lot of developers’ time. System health and diagnostic monitoring are also examples of where cloud SDKs provide a smattering of help, but MEIF provides real code.

Mentor’s software doesn’t replace the cloud providers’ SDKs – just the opposite, in fact. The Microsoft/Amazon code is incorporated into MEIF, which means it changes whenever the SDKs change. If Azure adds new features, MEIF adds them shortly thereafter.

The idea is not to hide each SDK’s feature set, but rather to highlight it. MEIF doesn’t try to abstract away the differences between cloud SDKs through any kind of intermediate layer or (worse) by inserting its own APIs. The two editions of MEIF (one for Azure, one for Amazon) really are two different products, tuned for their respective cloud’s features and operations.

MEIF can theoretically run on just about any microprocessor or microcontroller. It’s provided in library form, along with source code. Morrison says the code occupies “a couple hundred kilobytes,” so figure on about 256KB of ROM or RAM. It’s not particularly taxing, performance-wise, so a Cortex-M4 device (like NXP’s Kinetis K70, as an example) should do the job.

The price? “Talk to your Mentor sales agent,” councils Morrison. MEIF ain’t free, but neither is it royalty-bearing. There’s a one-time license fee to cover your entire project, then annual maintenance payments for updates and support. In short, it’s licensed like most other Mentor software.

It’s a safe bet that most IoT developers don’t have any experience writing, testing, or certifying cloud software. None of us do – that’s the nature of the beast. Which is what makes Mentor’s MEIF all the more valuable. It’s not just a time-saver; it’s a sanity-saver. Sure, it costs money and takes up a couple-hundred KB of your code space, but could you do any better without it? If connecting your gizmo to the public cloud is really what you want to do, then this is one of the necessary steps on the stairway to heaven.