time. But where does the responsibility of the OS stop and that of the application start? While an application can have a device driver built into it and talk directly to the hardware, porting to new hardware becomes a challenge as the device evolves and newer hardware is employed. Therefore, it is recommended that most, if not all, devices in the system be managed by the OS in order to ensure future portability.
Regulations and patient privacy The need for portability includes wireless devices like a GSM radio or an 802.11 wireless interface for connectivity. Others include Bluetooth and ZigBee, where these links must also be secure and provide patient privacy. Even in the device itself, it’s imperative that only doctors who are authorized to see a patient actually see the data of that patient. Disallowing unauthor- ized access is also a critical requirement of any device. Are the records secure, even for the technician who works on the equip- ment? Are there any modes where this data is not secure? True Health Insurance Portability and Accountability Act (HIPPA) compliance is making sure that the security of information is paramount. Security inside the database of patient records is as well.
Figure 1 | Distributing your application across multiple operating systems as in this Asymmetric Multicore Processing (AMP) example can relieve risk.
where the unit is unplugged in the middle of a session. Had the system taken either one of these use cases into account, the system would have stored the data locally, allowing for a transfer after the session was re-established, thus minimizing the risk to the patient of a possible retest.
The application relied on the USB controller’s flawless operation to prevent data loss. If the application had been broken down into several sections, data loss might have been avoided. With an architecture where data collection and data transmission are not interrelated, even if the link goes down, the data is still stored in the device, so when it recovers it can pick up where it left off and not lose any data. A write to a buffer before the transmission to the host, which would occur in the background, is one way to avoid lost data in this type of scenario.
If a software workaround to detect the USB bus suspension is used, the workaround can take the SoC pins out of USB mode and make them GPIO pins so that the host can detect a reset condition and force a re-enumeration of the device. The USB software would then resubmit the buffers, and the transmission would resume. The end result is that the data would not be lost, just delayed while the workaround took place.
Portability considerations An OS manages the system’s resources both in hardware and software. The most basic management is that of memory and
www.embedded-computing.com
Conclusion Medical devices are a special breed that will touch all of us in some way. We need to take extra care when designing these systems to ensure that the device does what it is intended to do. Does it make sense to use an RTOS or a GPOS to meet the requirements of determinism, size, boot time, power opti- mization, and the breadth of middleware available? Finally, to minimize risk we need to make sure that all regulations with both HIPPA and the FDA are followed.
Stephen Olsen has over 20 years of embedded software experience with his past 15 years spent at Mentor Graphics. Stephen is currently technical marketing engineer for Mentor Embedded, Mentor’s embedded software division. During his tenure at Mentor, he has co-chaired VSIA’s Hardware dependent Software (HdS) design working
group, worked on the MRAPI specification for the Multicore Association, and authored several papers on system design and power management. Stephen has worked in consulting, system architecture, embedded software, and IP. He holds a BS in Physics from Humboldt State University in California.
Mentor Embedded
Stephen_Olsen@mentor.com www.mentor.com
ECD in 2D: See an overview of Mentor Embedded. Use your smartphone, scan this code, watch a video:
http://bit.ly/eQoq4P
Embedded Computing Design April 2011 | 19
Page 1 |
Page 2 |
Page 3 |
Page 4 |
Page 5 |
Page 6 |
Page 7 |
Page 8 |
Page 9 |
Page 10 |
Page 11 |
Page 12 |
Page 13 |
Page 14 |
Page 15 |
Page 16 |
Page 17 |
Page 18 |
Page 19 |
Page 20 |
Page 21 |
Page 22 |
Page 23 |
Page 24 |
Page 25 |
Page 26 |
Page 27 |
Page 28 |
Page 29 |
Page 30 |
Page 31 |
Page 32 |
Page 33 |
Page 34 |
Page 35 |
Page 36 |
Page 37 |
Page 38 |
Page 39 |
Page 40 |
Page 41 |
Page 42 |
Page 43 |
Page 44 |
Page 45 |
Page 46 |
Page 47 |
Page 48 |
Page 49 |
Page 50 |
Page 51 |
Page 52 |
Page 53 |
Page 54