Digital interface implementation architectures

in a computer system with object-oriented programming language. Embedded systems have limited RAM, and it is easy to overuse it with memory structures required for objects.

2.5 Digital interface design and implementation 37

Interface block with some LL-protocol

processing Filter/driver electronics

Complete interface protocol or only

LL-protocol processing

Interface subsystem HL-protocol

processing

HL-protocol processing if

required Interface

protocol processing

Figure 2.5: Four different interface implementation architectures for embedded systems.

register API is used to interface to the transceiver, the interface can be added to an existing embedded system without complete system redesign, and the processor core can be chosen quite freely. In some cases, generally regarding wireless technologies, the transceiver only implements the lower protocol layers. The transceiver manufacturer often provides software support for the higher layers (HL), but this support may be processor depended and/or design tool depended.

These may limit the designers freedom for processor selection, and may also limit future system modifications.

The third approach uses a dedicated chip with support for the selected interface by having a dedicated HW interface support block. Typically this means a microcontroller unit with interface peripheral unit that implements some low-level functionality of the desired interface.

Higher protocol layers are implemented in software using the main CPU. This approach enables small single-chip designs, and is often desirable for small mobile or battery-powered systems.

These kinds of chips usually emerge as the interface standard matures and becomes popular, especially for the wireless interfaces, which are more demanding to implement in single-chip fashion. The disadvantages of this approach are that the processor type is fixed and alternative chip suppliers may not exists. Also, for the more complex protocols the higher protocol layers implemented in software reduce significantly the resources available for the application SW. The fixed processor type means that peripheral needs, such as the A/D converter (ADC) resolution, number of ADC channels, and peripheral units for other interfaces, can’t be optimally filled and system clock rate is often fixed and thus can’t be optimized (leading to increased power consumption). If the designer is adding interface support to an existing embedded system then using this approach he may need to change the complete technology platform, including hardware, software, and development tools.

The fourth approach is the ideal version of the third approach, in which the interface func-tionality is implemented completely by a separate interface subsystem with minimal load to the main CPU. This kind of implementation is possible with either simple interfaces or mature standards in high volume production. Compared to the third approach, this approach does not load main CPU, and thus gives the software designer better control over the CPU use. It is rare to find these kinds of products for emerging and developing interface standards. It is also some-times difficult to classify a device between type three and four if the actual interface standard is simple, defining only the lower OSI-layer functionality, and requires additional non-standard protocol layers or device profiles to be implemented in SW.

In this Thesis all four approaches have been used in implementations. The first approach has been used to implement serial parallel interface (SPI) in SW to interface the measurement board to the radio board in the wireless BCG chair presented in Publication [P6] and in the networked sensors presented in Publication [P8]. The second approach has been the most used, as both the USB patient monitoring (Publications [P1], [P2]) and isolation work (Publication [P3]), and Zigbee/IEEE 802.15.4 radio work (Publications [P6], [P7], [P8]) have been done using interface

2.5 Digital interface design and implementation 39

transceivers. The third approach has been used in the alternative USB-microcontroller based system implemented for the USB patient monitoring work (Publication [P1]) and also during the development of the Zigbee network the Chipcon CC2430 integrated CPU and RF IC was evaluated. The fourth approach has been used in several RS-232 implementations, for sending debug messages to serial terminal (Publications [P1], [P3], [P6], [P7]), for Zigbee radio platform to PC interface (Publications [P6], [P7], [P8]), and when interfacing measurement sensors to WSN radio boards (Publication [P8]). Also, the CC2420 RF transceiver was interfaced via HW SPI to the radio board’s microcontroller (Publications [P6], [P7], [P8]).

Summary

The term digital interface was defined in this Chapter and the structure of a digital interface examined. Three main components in digital interface structure were identified, the physical interface, the application programming interface, and the communication protocol in between them, often implemented as a device driver SW stack. Digital interfaces can be single or multiple device interfaces of which the latter are more common. Object-oriented data modeling approach enables flexible development of complex data structures and message exchange mechanisms required for the higher protocol layers of digital interfaces. Four different basic architectures for digital interface implementation were identified, regardless of the nature of the interface medium. Cable based and wireless interfaces have some distinct features which were presented in detail along with the currently most used commercial digital interface standards.

The next Chapter focuses on medical devices, their definition and unique features, to under-stand the requirements set by them for digital interfaces.

Chapter 3

Medical devices

In general, a medical device can be anything from computerized medical equipment to simple wooden tongue depressors. The intended primary mode of action of a medical device on the human body is not metabolic, immunological, or pharmacological, as with the medicinal products [Che03]. This Chapter presents the regulations governing medical devices and the standards relevant to medical device and medical device interface design. Furthermore, important issues such as security and privacy, use of non-medical technology, and medical device networking are presented.

Medical devices are governed by regulation which aims at guaranteeing the patient and operator safety, and well as the effectiveness or performance of the device. Medical device standards are tools for the regulators and well as the implementers, which aid in achieving of safety, performance, and other technical goals. Security and privacy issues sometimes contradict the goals of safety and performance design. Despite, they have a key role and should also be taken into account in medical device design. Home healthcare systems will face non-medical devices and may be required to interoperate with non-medical systems. Also, for cost-effectiveness, the use of PC and consumer electronics technology should be expanded.

In this Thesis the European definition of medical device is used. The directive 2007/47/EC [EU.07], which amended the Council Directive 93/42/EEC [EU.93] concerning medical devices, defines a medical device as “any instrument, apparatus, appliance, software, material or other article, whether used alone or in combination, including the software intended by its manufac-turer to be used specifically for diagnostic and/or therapeutic purposes and necessary for its proper application, intended by the manufacturer to be used for human beings. Devices are to be used for the purpose of:

• diagnosis, prevention, monitoring, treatment or alleviation of disease,

• diagnosis, monitoring, treatment, alleviation of or compensation for an injury or handicap,

• investigation, replacement or modification of the anatomy or of a physiological process, 41

• control of conception,

and which does not achieve its principal intended action in or on the human body by phar-macological, immunological or metabolic means, but which may be assisted in its function by such means.” [EU.07, EU.93]. Other national/regional definitions exists, of which the U.S. Food and Drug Administrations (FDA) definition is the best known. In section 201(h) of the Federal Food Drug & Cosmetic (FD&C) Act it defines medical device as ”an instrument, apparatus, implement, machine, contrivance, implant, in vitro reagent, or other similar or related article, including a component part, or accessory which is:

• recognized in the official National Formulary, or the United States Pharmacopoeia, or any supplement to them,

• intended for use in the diagnosis of disease or other conditions, or in the cure, mitigation, treatment, or prevention of disease, in man or other animals, or

• intended to affect the structure or any function of the body of man or other animals, and which does not achieve any of its primary intended purposes through chemical action within or on the body of man or other animals and which is not dependent upon being metabolized for the achievement of any of its primary intended purposes.”

Medical devices range from cardiac pacemakers to syringes or from complex computer based systems to simple mechanical aids. Medical device industry can be subdivided roughly into four sectors: a) medical-electrical devices; b) non-electrical products; c) implantables; and d) diagnostic products [Alt03]. In this Thesis the use of modern digital interfaces in medical devices is studied, and the main focus is on monitoring devices implemented using embedded computer/microcomputer systems, e.g., in the medical-electrical device sector.

An accessory is not considered to be a medical device, except if it is intended to be used specifically with a parent medical device to enable the parent medical device to achieve its intended purpose [Che03]. In this case it should be subject to the same regulatory procedures as the medical device itself.

When talking about medical devices, the question of safety usually rises up. The definition of safety and approaches for achieving it are presented in Section 3.1. In general, all commercial electronic devices must conform to certain regulations and standards. Additional regulations must be met and standards taken into account when designing a medical device. As medical device field is so heterogeneous, the field of regulations governing it is also wide and complex.

These issues are discussed in the Section 3.2, which presents briefly how EU and US regulate medical devices. Standards are closely related to regulations, as discussed in Section 3.3. The Section also introduces the key standards for medical devices design, and then focuses on medical device interface standards which have been introduced to improve medical electrical device interoperability. Section 3.4 addresses the security and patient privacy issues related to medical

3.1 Medical device regulation and safety 43

electrical devices. Modern computerized medical devices often adopt technology from the PC and consumer electronics market. The motivation and reasoning, and problems related to it, are discussed in Section 3.4. Modern computer systems and applications employ communication networks in everyday use. Issues regarding medical device networking are briefly presented in Section 3.5.

3.1 Medical device regulation and safety

Medical devices are regulated by national, regional and world wide bodies to improve the health and safety of patients and medical staff by providing them with reliable and effective equipment.

To achieve this, regulations have been set on device design, manufacturing, documentation, marketing, sale, use, and disposal. In this Section, the medical device safety is first defined, and key players involving it identified. It is then shown how the safety of medical devices is achieved with the current regulatory systems. This is followed by a presentation of current EU and US medical device (pre-market) regulations.