feature article
Subscribe Now

Mentor Spackles Over Cracks in the Cloud

Embedded IoT Framework Fills Software Holes

“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.

featured blogs
May 29, 2020
Each industry has its own standards and requirements that components must meet in order to be considered usable for that industry. There are some tests that are common between industries, such as outgassing, but more often than not there are going to be different requirements...
May 29, 2020
[From the last episode: We reviewed our tour of IoT and cloud computing.] We'€™ve talked about conventional computing, so now we'€™re going to look at a new computing application that'€™s taking the industry by storm: machine learning. We did a quick overview a long tim...
May 29, 2020
AI is all around us, but what is it exactly? For curious minds, this series of blogs explores the fundamental building blocks of AI, which together build the AI solutions we see today and that will enable the products we will enjoy tomorrow. This blog throws light on Supervis...
May 27, 2020
Could life evolve on ice worlds, ocean worlds, ocean worlds covered in ice, halo worlds that are tidally locked with their sun, and rogue worlds without a sun? If so, what sort of life might it be?...

Featured Video

DesignWare 112G Ethernet PHY IP Insertion Loss Capabilities

Sponsored by Synopsys

This video shows the performance results of the Synopsys 112G PHY receiver to varying amounts of channel insertion loss. The IP meets the standards requirements. With leading power, performance, and area, the IP is available in a range of FinFET processes for high-performance.

Click here for more information

Featured Paper

Actuator Design Trends for Functional Safety Systems in Electric and Autonomous Vehicles

Sponsored by Texas Instruments

Four automotive trends – connected, autonomous, shared and electric, also known as CASE – are driving some of the most exciting automotive developments right now. This white paper focuses on the impact of CASE trends on electrically actuated systems and how designers can meet the needs of evolving functional safety systems.

Click here to download the whitepaper