I think I’ve just seen the future of embedded systems and the “things” that form the Internet of Things (IoT). From what I can tell, it’s going to be a virtualized future that contains a cornucopia of containers. If only I knew more about virtualization in general, and containers in particular, I could rule the world.

Just speaking of the future caused the Days of Future Passed album, which was released by The Moody Blues in 1967, to pop into (what I laughingly call) my mind. This album’s fusion of orchestral and rock elements caused it to be cited as one of the first examples of progressive rock. Comprising a suite of songs about the life of everyday man, Days of Future Passed was only moderately successful when it was released, but it eventually came to be recognized by many, including Rolling Stone, as being among the most important albums of 1967. I mean… come on… Nights in White Satin… need I say more? (If you wish to refresh your mind, here’s a handy-dandy link to the album on YouTube).

I fear I’ve been “hoist with my own petard,” as the Bard would have it, where this phrase’s meaning is that a bomb-maker is lifted (“hoist”) off the ground with his own bomb (a “petard” is a small explosive device), and indicates an ironic reversal, or poetic justice. The reason I say this — and I can’t believe I am saying it — is that I’ve been out-geeked.

As I noted in a recent blog (see Don’t Speak Geek!), “Even if you are the geekiest of geeks or the nerdiest of nerds, speaking in the patois of the geek is not recommended. I can’t tell you how often I’ve seen peoples’ eyes glaze over when I’m talking to them… and things are even worse when I’m speaking geek.”

The reason I mention this here is that I was just chatting with Fred Rivard, who is the CEO of MicroEJ (pronounced “Micro Edge”). As you may recall, I’m a hardware design engineer by trade and my knowledge of software is “fluffy around the edges” and “flaky on top” at best, so it’s unfortunate that most of what Fred told me was software centric, with the result that I now know how my non-technical friends feel when I’m regaling them with tortuous tales of my techno-weenie derring-do.

All of which leads us to the “weasel words” (remember that “Eagles may soar, but weasels rarely get sucked into jet engines”). I’m sure you’ve heard people use the expression “The blind leading the blind.” As is represented in the painting of the same name by Pieter Bruegel, this idiom and metaphor (I never metaphor I didn’t like) is used to describe a situation where a person who knows nothing is getting advice and help from another person who knows almost nothing. Well, buckle up and strap yourself in, because I’m the person who knows almost nothing and I’m about to describe something about which I have little clue. “Oh joy,” I hear you say, but don’t give way to despair — let’s both of us just regard this as being a brave adventure and part of life’s rich tapestry.

Just to set the stage, as it were, let’s start with Android, which is an operating system (OS) that’s based on a modified version of the Linux kernel and other open-source software, and that’s predominantly used in mobile devices like smartphones and tablet computers.

Have you ever wondered how an Android application (“app” for short) is created? I know I haven’t (until now). I’m familiar with creating apps for the microcontroller units (MCUs) I use in my hobby projects, where these MCUs include the Arduino Uno, Seedunio XIAO, and Teensy 3.6, for example. In this case, I write my program (the app) in C/C++, select a target MCU, and then use the compiler in the Arduino’s integrated development environment (IDE) to convert this into machine code in the form of the binary executable that will run on the MCU I selected. The elephant in the room here is that, if I subsequently decide to employ a different type of MCU, I cannot employ the same binary executable file. Instead, I am obliged to recompile my original program for my new target platform.

Now think about how things work with an Android device. Suppose I have a collection of Android smartphones and tablets sitting on the table in front of me. Further suppose that each device has been created by a different manufacturer and is powered by a different processor. The point is that I can pick up any of these devices, go to Google Play (which is the equivalent of the Apps Store on Apple’s iOS devices), and download and run an app without thinking about it (ironically, not thinking about things is one of the things I do best).

Think about this for a moment — the exact same app will work on any Android device without recompilation. How can this be? In fact, the application source files are compiled into Java byte code, which is an intermediate code between source code and machine code. This byte code is subsequently executed by a Java Virtual Machine (JVM) that has been custom created for, and resides on, the target platform. Of course, this means that someone has to port the JVM to each of the target machines, but once this is done, all of the machines can run any apps that are created in this way.

Now, this is where things start to get interesting for embedded system and IoT developers because MicroEJ shares the same virtualization technology as Android. Having said this, “footprint is money” in the embedded and IoT worlds with respect to any demands on the size of the memory and the power of the processor. This is why MicroEJ’s virtualization is 1,000 times smaller than Android, thereby allowing it to run on $1 MCUs. Apart from anything else, all of this makes it possible for existing Android developers to effortlessly build apps for cost-effective embedded/IoT devices.

Another way to think about this is that embedded/IoT devices are everywhere, but there are no standard applications platforms. MicroEJ gets around this by allowing you to compile your application one time and to then deploy it across multiple platforms with different MCUs from different vendors.

This is the point where “containers” come into the picture. One way to think about a container is as a package containing an app’s binary executable along with all of its configuration files and libraries and any dependencies required for the app to run.

In the case of the folks at MicroEJ, they’ve created a 32-bit virtual processor unit (VPU) called the MEJ32 with its own unique instruction set architecture (ISA). This ISA is ideally suited for embedded/IoT systems because it’s been tailored and optimized to run on various embedded systems processors, including ARM Cortex-M, ARM Cortex-A, Renesas RX and V850, MIPS32, Infineon TriCore, and Tensilica Xtensa.

Next up the hierarchy we have the MicroEJ Virtual Execution Environment (VEE), which is a standard, safe, and secure on-device platform capable of running on any type of processor, including MCUs, MPUs, and System-on-Chip (SoC) devices. The way to think about this is that MICROEJ VEE acts as a software container that runs on any OS/RTOS commonly used in embedded systems (FreeRTOS, QP/C, ucOS, ThreadX, mBed OS, Mbed OS, VxWorks, PikeOS, Integrity, Linux…) and can also run without OS/RTOS (bare metal) or with a proprietary OS/RTOS (Phew!).

The downside is that the MicroEJ VEE has to be ported to each platform on which you wish to run MicroEJ apps. The upside is that the guys and gals at MicroEJ have already ported this VEE to a vast number of popular platforms. Even better, in the case of obscure or proprietary platforms, they’ve created the infrastructure that allows you to quickly and easily (relatively speaking) port the VEE yourself.

Now, this is where we need to focus a bit because we haven’t finished with containers. To be honest, this is where I got a bit confused because it took me some time to realize that — much like the kid in The Sixth Sense movie — I now see containers everywhere. There are actually two incarnations of the MicroEJ VEE: the MicroEJ VEE Virtual Device and the MicroEJ Embedded Runtime. Both of these are containers that run on their respective platforms. The MicroEJ VEE Virtual Device runs on your host computer where it acts as a digital twin of your future project. Meanwhile, the MicroEJ Embedded Runtime is the incarnation that’s tailored to run on your target hardware.

The MicroEJ VEE Virtual Device acts as a simulator allowing you to develop your embedded software applications on your regular PC/desktop machine while the real-world electronics platform is being designed. The Virtual Device simulates code execution along with all peripherals such as displays, connectivity, sensors, and any hardware-specific features of your system. Applications developed on the Virtual Device will execute the same without any change on the real device, allowing you to “write once and then run and deploy anywhere.”

The thing to note here is that, when you create a MicroEJ app, that app is itself a container that embraces the app’s binary executable (compiled to run on the MicroEJ VEE) along with all of its configuration files and libraries and any dependencies required for the app to run.

Another way of looking at this is that you have two containers. The first contains the MicroEJ VEE, which someone else already ported to the target platform and which acts as a super-sophisticated hardware abstraction layer (HAL), while the second contains your app. The VEE runs on the physical MCU, while your app runs on the virtual machine (VM) in the VEE.

I know, I know… if you are a hardware bod like your humble narrator, then it takes a lot of effort to wrap your brain around this sort of thing. The easiest way is to take a step back and simply accept that you can compile an app one time and then run it on multiple platforms. (What I haven’t talked about, and what I’m not going to talk about, are some of the more esoteric aspects of all this, such as the fact that containers can contain containers, and that they can be swapped out dynamically, and that… I bet you’re glad I’m not going to talk about any of this.)

When you think about it, this decoupling of the hardware from the applications has many applications (no pun intended). For example, it allows you to leverage new hardware innovations like faster, more capable processors from different manufacturers whilst maintaining the same software executable. This also has benefits in these dire and desperate days of supply chain disruptions because it facilitates your ability to migrate from a currently unavailable processor to an alternative part from a different vendor.

Now, this all sounds wonderful, but is it real or is it just wishful thinking? Well, on the one hand, after calling around, I was surprised to discover that a lot of my embedded developer friends were totally unaware of MicroEJ’s existence. On the other hand, I was excited to discover that when I explained things to them and introduced them to the MicroEJ website, they started to bounce off the walls in enthusiasm. And then I was surprised all over again to discover that there are already more than 100 million MicroEJ-ready devices on the market, with more joining them on a daily basis.

Since I am a bear of little brain and I’m easily lead astray, I reached out to Jean Baptiste “Jeb” Su, who is Principal Analyst and Tech Futurist at Atherton Research (Jeb is also the author of the TechPulse 360 column on the Business of Innovation at Forbes.com). Atherton Research is a global technology consulting and intelligence firm, advising organizations with their go-to-market strategies, market insights, competitive analysis, content strategy, marketing, and sales acceleration. When I asked Jeb for his thoughts on MicroEJ, he spake as follows:

MicroEJ’s virtualization technology is a game-changer for the semiconductor industry. It totally abstracts the underlying hardware (processors, micro-controllers, memory…) from the application layer. This decoupling of the hardware from the software significantly accelerates product development, which can now be done in parallel and almost entirely using a software simulator. Another benefit is that an application written for a particular processor/micro-controller will work on any other that has the MicroEJ VEE container following Java’s famous mantra of “write once, run anywhere.” Finally, an added benefit of the virtualization of the hardware stack is that manufacturers can now swap the underlying chips without having to modify the software stack, thus offering a perfect mitigation solution for the current chip shortage.

Wow, that’s just what I said, but it means more and sounds better when it comes from someone like Jeb. As far as I’m concerned, the bottom line is that, just like Android disrupted the smartphone and tablet industries, MicroEJ is in the process of disrupting the embedded/IoT industries. As always, we certainly live in exciting times. What say you? Do you have any thoughts you’d care to share?