feature article
Subscribe to EE Journal Daily Newsletter
9 + 3 =

Let’s Get (a) Physical

RoweBots’ MedicalOS Does Just What is Says on the Box

“UNIX is basically a simple operating system, but you have to be a genius to understand the simplicity.” — Dennis Ritchie

You can turn a sailboat around faster than a battleship, and a minnow changes course quicker than a whale. Small-fry RTOS company RoweBots has made a sharp pivot and set its compass toward bright horizons in the medical-devices field.

If you’ve heard of RoweBots at all, it’s likely because of Amelia’s interview a few months ago, or by way of Unison OS, an early POSIX-compliant RTOS intended for small embedded systems. The little Canadian/German company has been around for 30-odd years, never growing beyond a few dozen employees. It’s definitely a small fish in a big pond, but a happy fish nonetheless. Its customers are happy, too, which is more important.

But like any lifeform, success comes from specialization, and RoweBots has decided that a generic, Linux-like RTOS for “whatever” wasn’t going to get the company to its next stage of evolution. It was time to narrow the corporate focus and concentrate on a few specific product areas. Thus did Unison split into WearableOS, ConsumerOS, VehicleOS, and MedicalOS. No prizes for guessing which product niches the company decided to inhabit.

You could argue that some of the value in any operating system, large or small, is the time it saves you in developing applications to sit atop said OS. It’s not just a technology solution that makes the clocks tick and the interrupts interrupt; it’s a time-saver. The more familiar the OS, the better. And the more prepackaged it is, the better. Do-it-all OSen that come with myriad optional components are nice in concept, but a big waste of time when you’re focused on a single chore. Why spend time discarding the vehicle-related software components – interesting as they are – when you’re developing a medical device? Sure hope I didn’t pay extra for all that superfluous code.

That’s why Kim Rowe, CEO of RoweBots (get it?) thinks MedicalOS will be a great time-saver for those developing small, embeddable (in the medical sense) devices. It’s not the right OS for CAT scanners, but a good choice for concussion-logging crash helmets. In fact, one RoweBots customer has developed just that: a football helmet that senses and logs blows to the head using accelerometers, microcontrollers, and nonvolatile storage.

What makes an RTOS medical-specific, apart from leaving out the automotive, satellite, rack server, and industrial robotics features? Small size, low power consumption, and preconfigured device drivers, says Rowe. Wearable devices are physically small, and always battery-powered, so a full-fledged OS wastes storage space, CPU cycles, and energy. Better to use an RTOS that was designed from the outset for limited resources, and specifically for the resources one might find in a wearable medical device. No more, no less.

MedicalOS also comes with a ready-made batch of device drivers for relevant peripherals, like the aforementioned accelerometers as well as sensors you’re likely to see in medical (but not industrial or automotive) applications. Naturally, developers can add their own devices drivers, too, just as with any OS. But if a half-dozen of your favorites are already preconfigured, why not save the time?

RoweBots hasn’t strayed far from its Unison roots with MedicalOS. It’s still a Unix-like RTOS with most of the functions and APIs that a programmer would expect. “Think of it as Embedded Linux… for MCUs.” Says Rowe. It’s not an all-singing, all-dancing embedded Linux, but it’s close enough that Linux programmers will feel immediately at home.

The “…for MCUs” part is important, because MedicalOS (and its other market-specific brethren) runs on some really small MCUs, not just the higher-end devices. Chips like the Renesas M16C family, Microchip’s PIC24, Xilinx MicroBlaze, and NXP’s Cortex-M3 parts are all supported right out of the box.

For all its small size, MedicalOS doesn’t skimp on modern networking features (if you want them). Exciting buzzwords like SNMP, MQTT, IPv6, 6loWPAN, RESTful, and others all make the features list. ARM’s recently announced Platform Security Architecture also made the cut. Finally, cloud services like AWS, Azure, and Watson are available, too.

What’s the price for all this? It depends. Rowe describes his company’s pricing as “flexible.” There could be an upfront licensing fee; there might be royalties; there might be both. Since many of RoweBots’ customers are small firms without eight-figure R&D budgets, the company offers a number of payment schemes. Bigger users tend to prefer a one-time license fee and never worry about unit volumes after that. Startups want to conserve precious capital, so they opt for the back-loaded royalty-bearing model. Just about any payment structure is fine, and RoweBots understands that some customers will never generate any significant revenue at all. In fact, they plan for it. Your first 99 units are free, no matter what.  Now that’s a medical plan everyone can agree on.  

One thought on “Let’s Get (a) Physical”

Leave a Reply

featured blogs
Dec 11, 2017
This is a continuation of A Cadence Carol... before reading this post, be sure to have read the first four installments! Stave I: Moore’s Ghost, Part I and Part II Stave II: The First of the Three Spirits, Part I and Part II * * * * * Awaking in the middle of a prodigiou...
Dec 11, 2017
This time of year is typically set aside for preparation, and this year is no different. We spent November working on a couple of major upgrades to prepare for releases in 2018, one with the way we handle quotes in My Samtec, and the other with how we handle the checkout expe...
Nov 16, 2017
“Mommy, Daddy … Why is the sky blue?” As you scramble for an answer that lies somewhere between a discussion of refraction in gasses and “Oh, look—a doggie!” you already know the response to whatever you say will be a horrifyingly sincere “B...
Nov 07, 2017
Given that the industry is beginning to reach the limits of what can physically and economically be achieved through further shrinkage of process geometries, reducing feature size and increasing transistor counts is no longer achieving the same result it once did. Instead the...