Low-cost real-time data delivery for medical devices

Medotech’s Grindcare system provides relief from problems related to teeth grinding (bruxism). This is a type of hyperactivity in the jaw muscles that can cause severe dental problems as well as headaches and muscular pain. The Grindcare device measures the movement of facial muscles during sleep via an electrode placed on the temple. When grinding begins, it stimulates jaw muscles with a brief electric impulse, causing those muscles to relax and thereby stopping the action.

The treatment requires close supervision by a dentist, and this is best achieved if the care provider has access to historic data from a Grindcare unit. The care program can best be managed if this data can be accessed on a daily basis.

Security

Given the inherent sensitivity of any personal medical data, access to data in a device such as Grindcare must be strictly controlled. Medotech decided to use Nabto’s micro-server software, uNabto. It embedded a uNabto web server in the Grindcare device, and a secure plug-in program was installed in the dentist’s browser from which to access readings.

The system requires no specific configuration by the patient. The device powers up and can be controlled once Internet access is available. All communication is encrypted and both peers are cryptographically authenticated. As well as controlling the patient’s Grindcare device from an office PC, the dentist can also access the system over a smart phone using a dedicated Nabto ‘app’.

Offloading complexity

MCU developers often face remote-access challenges. The main problem typically lies in providing  ubiquitous and secure access to a sensitive system at an appropriate price. The user is looking for a technology that offers a smaller memory footprint, reduced bandwidth and low-power consumption on a low-cost 8-bit MCU, thereby offloading any heavy lifting to desktop and server class machines that can handle content rendering and the central network interface.

The uNabto web server seeks to reverse the client and server roles. Only such information as is absolutely necessary is stored locally on the device and exchanged with the client. As well as simplifying the software on the embedded device, this greatly simplifies configuration management as all rich content and business logic are stored in a central location.

The system exploits existing technologies from such fields as voice-over-Internet Protocol (VoIP). Three specific node types are:

• a client—a web browser with Nabto plugin, enabling handling of the custom nabto:// URL scheme;
• an embedded device containing the uNabto server software (denoted uNabto adapter in Figure 1); and
• a central Nabto base station.

A typical scenario (Figure 1) will then unfold as follows:

Device registration

The embedded device registers itself with the Nabto base station with its designated ID (e.g., gc-3471.medotech.com). A UDP-based awareness signal is periodically transmitted to the base station, serving two purposes, managing the presence of online devices in the base station; and keeping a channel open in the local firewall.

User request

The user activates an application on the device (e.g., through a bookmark or link on a portal) by requesting the appropriate URL—in this case: nabto://gc-3471.medotech.com/report.

The Nabto plugin contacts the Nabto base station (the device’s DNS hostname resolves to the base station).

The plugin retrieves an HTML device-driver bundle from the base station (if not already installed). The driver contains all ‘rich’ content (i.e., graphics, style sheets, layout templates, client side scripts) and descriptions of the services provided by the device in question.

The plugin initiates a handshake with the remote device.

Encrypted handshake

An encrypted handshake is mediated by the base station: cryptographic certificates are exchanged through the basestation and, if both peers authorize one other, encrypted details about each peer’s network configuration are exchanged (specifically, details about each peer’s NAT configuration are exchanged). This information is determined through a process similar to the STUN analysis known from VoIP applications.

If the network configuration allows it, the client may now communicate directly with the device. If UDP hole punching is not possible due to either peer’s NAT configuration, an end-to-end encrypted relay takes place through the base station instead.

Client/server communication

The plugin maps the user request (in this case, the “report” extracted from the URL) to an opcode as described in the HTML device driver and sends the request to the device.

The uNabto service code on the device receives the request and dispatches it along with decoded parameters to relevant system functionality.

The system computes a response that is encoded and sent back to the client. For the ‘report’ request, this is simply a sequence of integer three-tuples representing time, measured jaw activity and amplitude of the allied electric impulses.

Rendering of response

The browser plugin receives the data from the device and populates the appropriate response layout template from the HTML device driver. The template may reference other static content in the HTML device driver, rendering an HTML page with the final result (Figure 2, p. 16).

Simple integration and maintenance

The benefits from allowing the dentist to directly interact with the Grindcare device are obvious, particularly if compared with cumbersome manual examination. In addition, off-loading contents from resource-limited devices greatly simplifies maintenance and system development:

• The Medotech engineers may change the application layout or add new client scripts.
• They may add support for a new language if deploying in a new region.
• They may add optimized layout (e.g., for new mobile clients).
• All such changes take place in the centrally located HTML device driver bundle, without updating a single bit on the embedded device.

It is only necessary to update the device if the request/response model and/or the actual system software changes. However, the Nabto technology also simplifies remote firmware update as described later in the Cypherbridge uLoad case study.

The Nabto micro web server and base station can be implemented in a wide range of embedded devices on MCU platforms. System designers can license the Nabto web server code or acquire the code as an integrated part of an optional PIC Ethernet board. The Microchip-based module enables companies to design and prototype web-based systems such as remote medical, industrial and consumer applications.

Secure remote update for MCU

Security SDKs such as embedded uSSL and uSSH are well suited to secure FTP, SMTP and similar protocols. The classic desktop content model imposes significant compromises and cost impacts on embedded devices. So-called thin-clients typically are leans content servers and browsers that generally employ many of the same protocols as found on desktop PCs.

Industry experience has shown that such legacy-oriented embedded content servers fall somewhere in a spectrum ranging from price-performance impact for a 32-bit MCU at one end, to unrealistic for 16- and 8-bit MCUs.

The proliferation of MCU devices calls for a device management and firmware distribution package that is both secure and scalable. The Cypherbridge Systems uLoad product provides a comprehensive one that includes an in-chip boot loader, standalone downloader, secure image processing and a multi-point scalable distribution server.

Cypherbridge has integrated its security, connectivity and device management SDKs with Nabto technology, serving all market segments including 8-, 16- and 32-bit platforms. The uLoad product is offered in a range of integrated packages, including Unified Build, that co-exist with RTOS and TCP, file system, flash memory and network download support, and a standalone build with independent security, download and re-flash capability.

The Cypherbridge uLoad Standalone Build, Micro content server and Nabto device engine contain:

• Application: determined by the user.
• uServer: a micro content server for platform sensors, configuration and management, including command/response message handlers, async event notification and timers.
• uLoad: Cypherbridge’s standalone installer and secure boot-loader.
• LTP: the lightweight transport protocol.
• uCrypt: an integrated symmetric encryption and authentication.
• BSP Drivers: interfaces to MCU COM ports and flash memory.
• Nabto Device Engine: the Nabto transport interface and event dispatcher.
• I/O Channel: a flexible interface to interactive or machine-to-machine peer over Ethernet, simple TWSI, RS-232, SPI, BT or 802.11 Radio module, etc. standards.

These are just a couple of examples of the benefits of a Nabto content engine. Any trade-off analysis for an embedded content server should include:

• processor cycles, RAM and ROM memory required;
• footprint size for SDK instruction flash and RAM memory buffers;
• an ability to deliver parity with a desktop content experience without compromising the MCU-based system design cost;
• keeping bandwidth low to save cost especially for WAN radio links with a limited data plan, and to control RF calls on overall system power; and
• implementing a lightweight command/response engine well-suited to devices that have an aggressive power managed battery, or solar assisted and energy harvesting sources.

Nabto
Åbogade 15
8200 Aarhus N
Denmark
T:+45 8734 5513
W: www.nabto.com

Cypherbridge Systems LLC
7040 Avenida Encinas #104211
Carlsbad 92011
USA
T: +1 760 814 1575
W: www.cypherbridge.com