Robotic surgeries are on the rise all over the world.  In addition to the aging population, one of the major driving factors in the US is that outpatient centers are starting to go robotic, which is helping to fuel a 25 percent annual increase in robotic surgeries, according to a report by Becker’s ASC Review.   Venturebeat reports that U.K. startup Cambridge Medical Robotics has raised $20.3M in series A funding for robot-assisted surgery technology development.  The rise in robotic surgery comes as no surprise because patients often experience less scarring, less recovery time, and less pain. These benefits obviously represent a big step forward in care, but do come at a cost.  Becker’s also reports (in a 2013 study) that robotic prostatectomy costs an average of $2,118 to $2,274 USD more per case than a standard laparoscopic prostatectomy, which creates pressures on the highly watched medical reimbursement regime.   Insurance reimbursements can easily become the long pole in the tent in terms of how quickly robotic surgery can be adopted and what kind of return on investments hospitals, equipment makers, software developers, and investors can achieve.  

Outside the important reimbursement story, there are also high level system architecture issues to grapple with.  Robotic designs today commonly employ a master and slave architecture with a communication or network hub connecting them.   The master and slave can be physically near or far. They can be in the same operating theater, apart by several meters, or even worlds away.  

Equipment Architecture

When a robot is used, a rich Surgeon-Machine-Interface (SMI) provides critical real-time accurate feedback.  Improved levels of dexterity offered by the robot, as well as improved vision made possible by HD cameras and monitors, make it easier to navigate and see anatomical structures like never before.  Also, being part of a machine, vision and movement are completely calibrated in space with movement having much finer resolution than a human can achieve.   Of course, this is the whole idea—let machines and humans cooperate do what each does best.   One might say robots in the operating theatre is a formula for medical synergy.

Reliability, accuracy, fast boot times, safety, and security are also key considerations.  Surgical robotics are commonly used in critical situations, and offer procedures that sustain life—so they are certainly considered safety-critical.    Systems such as these that need a processing cores and associated Operating Systems (OSes)  are powerful enough to acquire, process, and interpret several parameters at once in real-time, while also providing a friendly, straight forward, and safe to use surgeon-to-machine interface (SMI). 

Breaking down the overall architecture of a typical high-end surgical robot on the console side, a simplified system block diagram generally looks something like the figure below.

On the console side, one common approach would be to leverage one processor as the Master Processor whose task is to manage the SMI and provide communication capabilities via a network hub.  This leaves the tasks of haptic processing (i.e. touch feedback) and video decompression, among others to other independent processors.  It is quite common to assign these tasks to processors in complete isolation to improve architecture risk profiles.  One consideration here of course would be cost.  Three (or more) different processors can drive up the cost in favor of risk.  However, another consideration being debated is the deployment of a virtual core or hypervisor running atop a single processor to handle other functions.   If hypervising is a potential consideration in your application, you may want to choose your partners wisely so that your embedded hardware, OSes, and hypervisors are well supported.  In an operating theatre, failure is not an option.

On the robot side, a system block diagram can look like this:

You can see a number of microprocessors offering video compression, communications processing, a master robotic processor and several Microcontrollers (MCUs) used to control servos and motors. 

The master robotic processor interfaces with a host of MCU’s equipped with analog interfaces, input multiplexers, ultra-low noise amplifiers, filters, and high-performance (16 to 24 bits) analog to digital converters arranged to convert various analog safety and servo signals into the digital domain to calculate appropriate patient treatment and surgeon feedback through the robot/comms processor.   Also, on the slave side of the system there is the video compression processor that provides digital video information and communicates through the robot/comms processor to the console side.  

A full spectrum of 32-bit processors on both the console and robot sides offer high levels of performance and integration.  Common processors for today’s robot designs tend to be higher end MPUs like the ARM Cortex-A8 or A9.  The most common processor suppliers are NXP, Texas Instruments, and Xilinx (as shown above). Intel often plays a part on the console side as well.  Peripheral support, such as integrated ethernet and USB, as well as the ability to seamlessly connect to a wireless module are key decision factors.  Most systems call for Ethernet support, but some designers are now developing with Wi-Fi, Cellular, or both.  This is means that the medical IoT is here. As with all IoT applications, security must be a fundamental part of the design, and that is especially true in medical for a variety of reasons. 

Rich, reliable, and safe SMI and display technologies can help eliminate surgeon error.  Many robotic surgery programs now leverage advanced Human-Machine-Interface (HMI) technologies such as Qt or HTML5, as well as touch screen and even video playback capabilities. 

In critical equipment, where every second literally counts, fast boot capability is another key requirement.  Video, haptic feedback, and SMI functions need to be up and ready within a few seconds of powering on.  Regardless of processors used, most so-called free open source operating systems fail to meet these criteria. 

Further key points:

1. BSP:  Seek a strong Board Support Package (BSP) starting with a platform comprised of proven hardware, proven software, and system support. 
2. Peripherals: Be mindful of the peripherals required, such as managing compliant Bluetooth Stacks or WiFi and Cellular communications. 
3. Security: Lock it down with appropriate security measures following the FDA’s guidance issued in January 2016 “Postmarket Management of Cybersecurity in Medical Devices”, and seriously consider FIPS 140-2 levels of encryption.
4. Partners: Look for HW and SW partners that provide you clean IP.  Open source SW is not typically clean and becomes onerous. 
5. Reliability: Look for an OS where each and every component (driver, application, file system, protocol stack, etc) can run in the safety of memory-protected user space, outside the kernel.
6. Cost:  Seek partners that will provide you with a lower total cost of ownership.  An OS which holds a certificate of conformance to IEC-62304 can help the medical device manufacturer eliminate the need for large teams managing the OS community (development & ongoing maintenance costs), and they’re assured of a medical pedigree reducing risks. 

When going robotic for surgical equipment, autonomous cars, flying drones, automated factories, or anything else it is most critical to ensure that the operations are safe, secure, and reliable.  As the world becomes more software-defined, those factors start with the operating system.  Chose one that has been proven in the real world, such as QNX.