Sometimes communications devices are preprogrammed to accomplish communications tasks.

1.5.2 Programming PLCs

A programming device can be a handheld device, a desktop console, or a computer. Only when the program has been designed on the programming device and is ready is it transferred to the memory unit of the PLC.

Handheld programming devices will normally contains enough memory to allow the unit to retain programs while being carried from one place to another.

Desktop consoles are likely to have a visual display unit with a full keyboard and screen display.

Personal computers are widely used for programming PLCs. A major advantage of using a computer is that the program can be stored on the hard disk or a CD and copies easily made. The computer is connected to the PLC by Ethernet, RS-232, RS-485 or RS-422 cabling.

PLC manufacturers have programming software for their PLCs. For example, Mitsubishi has MELSOFT. Mitsubishi's iQ Works software is a suite of four MELSOFT software packages that enable intuitive programming and setup of an iQ Platform system, including system/network configuration, Q and FX Series programming, Q Motion Controller and Servo setup, GOT1000 HMI screen design. Simulators and additional configuration software have been integrated into the base software, and Label programming across the entire system has been implemented. MELSOFT Navigator is the heart of iQ Works integrating the other MELSOFT programs included with iQ Works. Functions such as system configuration design, batch parameter setting, system labels, and batch read all help to reduce the total cost of ownership (TCO). MELSOFT GX Works 2 is the PLC maintenance and programming software. It supports all MELSEC controllers from the compact PLCs of the MELSEC FX series to the modular PLCs including MELSEC System Q and uses a Windows based environment. It supports the programming methods (see Chapter 4) of instruction list (IL), ladder diagram (LD) and sequential function chart (SFC) languages. You can switch back and forth between IL and LD at will while you are working. You can program your own function blocks, and a wide range of utilities is available for configuring special functions. The package includes powerful editors and diagnostics functions for configuring MELSEC networks and hardware, and extensive testing and monitoring functions to help get applications up and running quickly and efficiently. It offers offline simulation for all PLC types and thus enables simulation of all devices and application responses for realistic testing.

As another illustration, Siemens has SIMATIC STEP 7. This fully complies with the international standard IEC 61131-3 for PLC programming languages. With STEP 7, programmers can select from among various programming languages. Besides LAD and FBD, STEP 7 Basis also includes the IL programming language. Other additional options are available for IEC 61131-3 programming languages such as ST, called SIMATIC S7-SCL, or SFC, called SIMATIC S7-Graph, which provides an efficient way to describe sequential control systems graphically. Features of the whole engineering system include system diagnostic capabilities, process diagnostic tools, PLC simulation, remote maintenance, and plant documentation. S7-PLCSIM is an optional package for STEP 7 that allows simulation of a SIMATIC S7 control platform and testing of a user program on a PC, enabling testing and refining prior to physical hardware installation. By testing early in a project's development, overall project quality can be improved. Installation and commissioning can thus be quicker and less expensive because program faults can be detected and corrected early on during development.

Likewise, Rockell Automation have RSLogix for the Allen-Bradley PLC-5 family of PLCs. The RSLogix™ family of IEC-1131-compliant ladder logic programming packages have flexible, easy-to-use editors, common look-and-feel, diagnostics and troubleshooting tools and powerful, time-saving features and functionality. This family of products has been developed to operate on Microsoft® Windows® operating systems. RSLogix™ 5 supports the Allen-Bradley PLC-5® family of programmable controllers.

1.4.3 Programming PLCs

A programming device can be a handheld device, a desktop console, or a computer. Only when the program has been designed on the programming device and is ready is it transferred to the memory unit of the PLC.

A handheld programming device normally contains enough memory to allow the unit to retain programs while being carried from one place to another.

Desktop consoles are likely to have a visual display unit with a full keyboard and screen display.

Personal computers are widely configured as program development workstations. Some PLCs only require the computer to have appropriate software; others require special communication cards to interface with the PLC. A major advantage of using a computer is that the program can be stored on the hard disk or a CD and copies can be easily made.

PLC manufacturers have programming software for their PLCs. For example, Mitsubishi has MELSOFT. The company's GX Developer supports all MELSEC controllers, from the compact PLCs of the MELSEC FX series to the modular PLCs, including the MELSEC System Q, and uses a Windows-based environment. It supports the programming methods (see Chapter 4) of IL, LD, and SFC languages. You can switch back and forth between IL and LD at will while you are working. You can program your own function blocks, and a wide range of utilities is available for configuring special function modules for the MELSEC System Q; there is no need to program special function modules, you just configure them. The package includes powerful editors and diagnostics functions for configuring MELSEC networks and hardware, and extensive testing and monitoring functions to help get applications up and running quickly and efficiently. It offers offline simulation for all PLC types and thus enables simulation of all devices and application responses for realistic testing.

As another illustration, Siemens has SIMATIC STEP 7. This fully complies with the international standard IEC 61131-3 for PLC programming languages. With STEP 7, programmers can select from among various programming languages. Besides LAD and FBD, STEP 7 Basis also includes the IL programming language. Other additional options are available for IEC 61131-3 programming languages such as ST, called SIMATIC S7-SCL, or SFC, called SIMATIC S7-Graph, which provides an efficient way to describe sequential control systems graphically. Features of the whole engineering system include system diagnostic capabilities, process diagnostic tools, PLC simulation, remote maintenance, and plant documentation. S7-PLCSIM is an optional package for STEP 7 that allows simulation of a SIMATIC S7 control platform and testing of a user program on a PC, enabling testing and refining prior to physical hardware installation. By testing early in a project's development, overall project quality can be improved. Installation and commissioning can thus be quicker and less expensive because program faults can be detected and corrected early on during development.

Likewise, Rockwell Automation manufactures RSLogix for the Allen-Bradley PLC-5 family of PLCs, OMRON has CX-One, and Telemecanique has ProWorx 32 for its Modicon range of PLCs.

Register Maps

It is very common to find some form of machine-readable documentation or list of device programming register maps. Such descriptions can be converted into Simics DML source code to automatically provide register map layouts, without any need to manually transcribe documentation into source code. Over the years, register layouts have been created from a wide variety of formats. Plaintext files, Excel sheets, custom XML document formats, IP-XACT specifications, SystemRDL programs, and even reference manuals in PDF have been used as a source for register lists.

Depending on the source format, sometimes all that are generated are offsets to registers, while other source formats contain enough information to add initial values, reset values, and bit fields to the registers. In some cases, it is possible to assign basic behavior to the registers as well, using DML templates expressing behaviors like read only, clear on write, or reserved for future use.

DML allows the modeler to split the declaration of register offsets and sizes from the definition of their behavior, and this is often exploited when generating DML from register lists. One bank declaration is used to hold all the register offsets and other generated information, and another one is used to add behavior to the registers that need to have their behavior modeled. In practice, it is often not necessary to deeply model the behavior of all registers, at least not initially.

7.8.1 Programmable logic controllers

A programmable logic controller (PLC) is a special form of microprocessor-based controller that uses a programmable memory to store instructions and is designed to be operated by engineers with perhaps a limited knowledge of computers and computing languages. Thus, the designers of the PLC have pre-programmed it so that the control program can be entered using a simple pictorial form of language called ladder programs. The term logic is used because programming is mainly concerned with implementing logic and switching operations, e.g. if A or B occurs switch on C, if A and B occurs switch on D. For example, it might be used to control the level of water in a tank by a sensor giving an input signal when the tank is empty and another sensor giving a signal when the tank is full. Thus when the tank-empty sensor gives an on input the controller gives an on output signal to open a valve to allow water into the tank. This output remains on until the tank-full sensor gives an input signal, the controller then switches off the output signal to the valve.

Input devices, e.g. sensors such as switches, and output devices in the system being controlled, e.g. motors, valves, etc., are connected to the PLC. The operator then enters a sequence of instructions, i.e. a program, into the memory of the PLC. The controller then monitors the inputs and outputs according to this program and carries out the control rules for which it has been programmed. Many PLCs also can be programmed to operate as PID controllers.

Typically a PLC system has five basic components. These are the processor unit, memory, the power supply unit, input/output interface section and the programming device. Figure 7.39 shows the basic arrangement.

The processor unit or central processing unit (CPU) is the unit containing the microprocessor and this interprets the input signals and carries out the control actions, according to the program stored in its memory, communicating the decisions as action signals to the outputs.

The power supply unit is needed to convert the mains a.c. voltage to the low d.c. voltage (5 V) necessary for the processor and the circuits in the input and output interface modules.

The programming device is used to enter the required program into the memory of the processor. The program is developed in the device and then transferred to the memory unit of the PLC.

The memory unit is where the program is stored that is to be used for the control actions to be exercised by the microprocessor.

The input and output sections are where the processor receives information from external devices and communicates information to external devices. The inputs might be from switches, temperature sensors, or flow sensors, etc. combined with appropriate signal processing elements. The outputs might be to motor starter coils, solenoid valves, etc.

Programs are entered into a PLC's memory using a program device which is usually not permanently connected to a particular PLC and can be moved from one controller to the next without disturbing operations. For the operation of the PLC it is not necessary for the programming device to be connected to the PLC since it transfers the program to the PLC memory. Programming devices can be a hand-held device, a desktop console or a computer. Hand-held systems incorporate a small keyboard and liquid crystal display, Figure 7.40 showing a typical form. Desktop devices are likely to have a visual display unit with a full keyboard and screen display. Personal computers are widely configured as program development workstations. Some PLCs only require the computer to have appropriate software, others special communication cards to interface with the PLC. A major advantage of using a computer is that the program can be stored on the hard disk or a floppy disk and copies easily made. The disadvantage is that the programming often tends to be not so user-friendly. Hand-held programming consoles normally contain enough memory to allow the unit to retain programs while being carried from one place to another. Only when the program has been designed on the programming device is it transferred to the memory unit of the PLC.

To give some indication of the ladder form of programming, consider the electrical circuit shown in Figure 7.41(a). The diagram shows the circuit for switching on or off an electric motor. We can redraw this diagram in a different way, using two vertical lines to represent the input power rails and stringing the rest of the circuit between them (Figure 7.41(b)). Both circuits have the switch in series with the motor and supplied with electrical power when the switch is closed. The circuit shown in Figure 7.41(b) is termed a ladder diagram. The power lines are like the vertical sides of a ladder with the horizontal circuit lines like the rungs of the ladder. The horizontal rungs show only the control portion of the circuit, in the case of Figure 7.41 it is just the switch in series with the motor. Drawing ladder diagrams is a means of writing programs that is used with PLCs.

Figure 7.42 shows the basic standard ladder program symbols that are used for input and output devices. Note that inputs are represented by just two symbols representing normally open or normally closed contacts. This applies whatever the form of the device connected to the input. The action of the input has to be designed to be equivalent to opening or closing a switch. Outputs are represented by just one symbol, regardless of the device connected to the output. To illustrate the drawing of the rung of a ladder diagram, consider a situation where the energising of an output device, e.g. a motor, depends on a sensor-signal processing arrangement being like a normally open start switch which on being activated is effectively closed, i.e. the input turns from a low signal to a high signal. Figure 7.43 shows the ladder diagram. Starting with the input, we have the normally open symbol || for the input contacts. There are no other input devices and the line terminates with the output, denoted by the symbol O. When the switch is closed, i.e. the input is high, the output of the motor is activated.

As an illustration of the use of a PLC system, consider its use to control the temperature of a domestic central heating system (Figure 7.44). The central heating boiler is to be thermostatically controlled and supply hot water to the radiator system in the house and also to a hot water tank to provide hot water from the taps in the house. Pump motors have to be switched on to direct the hot water from the boiler to either, or both, of the radiator and hot water systems according to whether the temperature sensors for the room temperature and the hot water tank indicate that the radiators or tank need heating. The entire system is to be controlled by a clock so that it only operates for certain hours of the day. Figure 7.45 shows a program that can be used. The boiler, output Y430, is switched on if X400 and X401 and either X402 or X403 are switched on. This means if the clock switched is on, the boiler temperature sensor gives an on input, and either the room temperature sensor or the water temperature sensors give on inputs. The motorised valve M1, output Y431, is switched on if the boiler, Y430, is on and if the room temperature sensor X402 gives an on input. The motorised valve M2, output Y432, is switched on if the boiler, Y430, is on and if the water temperature sensor gives an on input.

2.2 Candidate Microcontrollers for ‘Hard’ Tasks

Given that we need to choose a microcontroller family to handle the real-time parts of our system, let's first create a short list of rules for selecting this family:

Assemblers and compilers must be freely available, either from the manufacturer or as a result of open-source efforts such as gcc.

Device programming hardware must either be low-cost or simple enough to build at home using off-the-shelf parts.

Parts to be used must be available ex stock from major mail-order distributors such as Digi-Key, Newark, and others, with no minimum purchase requirements.

Device family must contain parts spanning the widest possible variety of ROM, RAM and peripheral requirements, with as much firmware and hardware design commonality as possible.

Ideally, the parts chosen should enable easy implementation of a slave SPI interface, but this isn't vital (and SPI is extremely simple to bit-bang, anyway).

There are three obvious targets that present themselves immediately: 8051, Microchip PIC®, and Atmel AVR®. The ancient 8051 is indubitably the world's best-known candidate for 8-bit applications, so we'll start by examining this family briefly. It's very inexpensive, available from an unparalleled number of sources (Atmel, Philips, Winbond, Cypress, and Dallas/Maxim are just a few of the vendors with standard 8051 parts; dozens more have 8051-cored ASICs and ASSPs), and the basic architecture is familiar to most embedded engineers. There are numerous high-quality tools and reference designs, and megabytes of sample sourcecode available.

The main reason I have chosen to avoid the 8051 family is because of the lack of standardization across manufacturers. No single manufacturer carries an 8051 variant to suit every single application need, and almost every manufacturer has added somewhat proprietary features to the core or peripherals. Because of the long history of this part, it is even common for a given manufacturer to have two or more completely different lines of 8051-cored parts, with different family trees, idiosyncrasies and programming hardware and software tools. Some 8051 sub-families require external programming hardware; some have in-system programming capabilities, many do not have flash memory, and in order to migrate from one variant to another may require investment in relatively expensive programming hardware. It's possible to avoid some of this nonstandardization by sticking to a set of “vanilla” 8051-cored parts that are implemented nearly identically across manufacturers, but this also means avoiding use of most of the 8051s with interesting nonstandard peripherals; LCD controllers, USB, on-chip A/D and D/A converters, expanded ROM or RAM, in-circuit programming, etc. It also means that, in a modular design where each microcontroller has minimal duties, you will likely be spending far too much on over-specified microcontrollers. For instance, you don't need kilobytes of RAM or ROM for a simple stepper motor controller!

As a secondary, but still relevant point, the 8051's architecture is positively archaic. The upside of this is that compiler vendors understand it very well, and commercial compilers for the 8051 are about as good as they're going to get. The downside is that even the best 8051 compiler (arguably, Keil's product) is unavoidably less efficient than good compilers targeted at more modern processors. Worse still, the only halfway decent open-source C compiler for the 8051 (sdcc) is exactly that—only halfway decent. And writing and maintaining large volumes of 8051 assembly language is irritating. It's an entirely justifiable effort if you're making large volumes of something or have another good reason to pick that architecture, but if you're trying to follow the path of least resistance to build a low-volume system with the minimum possible personnel resources, other microcontrollers are a better investment.

In my opinion, therefore, 8051 variants are a great choice when you have a specific application in mind, and you are looking for a one-chip solution. Because of the anarchic differences between different vendors’ sub-families, and the fact that no single vendor carries completely code-compatible parts to suit every application, I feel that 8051 isn't such a good choice for modular applications where you anticipate the need to use many tiny microcontrollers in a single project. The workload required to keep code mobile amongst different 8051 variants with disparate peripherals is quite significant. If, however, you are experienced with the 8051, there is no reason why you can't apply that knowledge to the techniques in this book.

For the projects you will find here, I have chosen to use the Atmel AVR series of microcontrollers. These parts are all flash-based; the family offers a reasonably wide range of functionality, and the instruction set is easy-to-learn and to a large degree common amongst family members. Under most circumstances, AVRs are programmable in-system or in an external socket using a simple-to-manufacture parallel port cable. The official STK500 development board, should you wish to acquire it, is cheap ($79 is the current list price) and fully-featured. A functional Windows IDE and assembler are free from Atmel, a port of gcc is also available and supported by Atmel, and there are freeware assemblers and other tools for UNIX-based operating systems as well as Windows.

Another ubiquitous microcontroller family, commonly used in low-volume and hobbyist applications, is the Microchip PIC. This family meets essentially all of the requirements in the preceding list. I have not chosen to use it, however, simply because it is slightly harder to learn and use than AVR. (By the way, I base that comment on my own experience in learning the two cores, as well as commentary I have read from neophytes asking for help and advice. This is, however, one of those potentially controversial topics I warned about in the introduction. I'm certainly not condemning the PIC as a hard-to-use maverick, I'm simply pointing out that many people seem to find the AVR family easier to use). One other downside to the PIC family is that the “official” entry-level development kit (PICstart Plus) is more expensive than the STK500—almost three times the price, in fact—and it's nowhere near as flexible, being simply a dumb chip-burner with no prototyping functionality at all.

There are a couple of other reasonably popular microcontroller families that we could have considered, and you may wish to investigate them yourself. The Texas Instruments MSP430 family, for example, is a very interesting range of parts. It combines a 16-bit RISC core (some variants have a bonus hardware multiplier) with various useful peripherals, at an attractive price point. The parts are flash-based and support JTAG debugging using an inexpensive parallel-port or USB-based wiggler; a most useful feature. The downsides to the MSP430 are prototyping issues due to the small packages used, and also interfacing problems arise due to the fact that they are 3.3V parts. However, if you're trying to cut down your power budget, or you're looking for a high-performance core that's inexpensive and well-supported by a major vendor, MSP430 is a good choice.

Another micro that is worth at least a quick look is the range of 8-bit devices from Rabbit Semiconductor, http://rabbitsemiconductor.com/. These parts are derived from the ZiLOG Z-180, so depending on your background you might not have too much of a learning curve. They are firmly targeted at connected applications; Rabbit supplies a free TCP/IP stack and provides several evaluation boards and fairly low-cost, end-application-integratable CPU modules, some of which have Ethernet onboard. They even have a Wi-Fi kit, although it's rather expensive. The main downsides to Rabbit are the small size of the company, which argues against long-term availability (however, they have been around for several years and seem to enjoy good popularity in the hobbyist market), and the fact that their free “Dynamic C” compiler is horribly nonstandard; it's tedious and most inelegant to port code into or out of a Rabbit design. There is an ANSI C compiler available, but it is buyware. Arguments in favor of Rabbit are low entry cost (all the basic tools are free and the development hardware is reasonably priced), ease of low-volume manufacture (since Rabbit supplies the chips ready-to-run, already soldered down to a board, if you wish), and a rich feature set (large flash memory, large RAM, fairly simple programming with a C-like language as well as assembly language, and a lot of ready-to-use application-specific code, particularly in the realm of TCP/IP networking protocols). Possibly the most compelling argument for Rabbit, however, is the fact that you can migrate from one-time prototype production directly to low-volume manufacturing (a few hundred pieces a year, perhaps) without any need to redesign.

3.14.2.4 Communication Technologies for Medical Applications

Wireless biomedical telemetry is used in hospitals, clinics, homes, ambulances, and other healthcare institutions. This telemetry is typically part of an external biomedical monitoring and diagnostic system, a body-worn device, or an implantable medical device designed to gather data, administer therapy, and possibly provide therapy adjustment for the patient. These devices exchange data with a system designed for medical professional use, or with the patient. Typically, biomedical telemetry is administered, or prescribed for use by a healthcare professional.

Originally the term wireless telemetry was defined as the transmission and measurement of data from remote sources by radio. This definition has expanded to include telecommand that involves the control/reprogramming of devices, and additionally, has expanded beyond radio to include infrared and ultrasonic communications.

Current wireless biomedical telemetry systems can be very sophisticated, are primarily radio-based, and can be divided into the following three general classes of devices:

Healthcare facility-based wireless (i.e., EKG and pulse oximetry transmitters that allow a patient’s mobility about most of one hospital floor while being continuously monitored).

Implanted and body-worn telemetry systems that are part of portable therapeutic and monitoring systems can be controlled and read by both healthcare professionals with physician-programming devices and by patients with handheld devices. These can be used both in health care facilities and in home use environments.

Personal health assistant devices. These can be blood glucose monitors, pulse rate, blood pressure monitors, or weight scales. These can be nonprescribed consumer electronics. Use of these types of devices in healthcare management systems is becoming more prevalent.

Wired biomedical telemetry systems, typically hospital-based and connected to the hospital computer network, are quite common. While not covered here, it is worth noting that these systems can automatically measure blood pressure, heart rate, arterial oxygen saturation levels, respiration rate, and allow manual data input for managing hospitalized patients. Wireless systems allow patient mobility to the bathroom, exercise, and allow for general patient case of mobility and comfort. They can also provide increased patient safety due to the continuous monitoring aspect of wireless telemetry.

Wireless biomedical telemetry systems are regulated by both the United States of America Federal Communications Commission (FCC) and the FDA. The FCC defines the RFs allowed for use in transmitting biomedical data, and the power levels allowed. The FDA defines electromagnetic interference (EMI) immunity and safety requirements of therapeutic devices and the associated telemetry interaction at the system level. The frequencies and power levels are important parameters when designing a biomedical telemetry system. The number of users and their power levels, along with man-made noise, can cause significant interference to certain frequency bands. This is one reason why the FCC has created protected frequency bands specifically for biomedical telemetry. These include the wireless medical telemetry system (WMTS) for in-hospital use and the medical implant communications service (MICS) for implantable use. Nonlife critical telemetry often uses the nonprotected industrial, scientific and medical (ISM) bands. The medical portion of the ISM band is related to radio diathermy and other noncommunications use of RF. There are many industrial, commercial, scientific, and home uses of the ISM band, which can lead to significant noise and interference levels on the bands (i.e., cordless phones, WiFi, Bluetooth).

Hospital-based wireless EKG telemetry systems are ubiquitous. Currently manufactured systems utilize the WMTS frequency band. The following paragraph is an excerpt from the FCC WMTS website that describes the creation of this frequency band quite well:

Prior to the establishment of the WMTS, medical telemetry devices generally could be operated on an unlicensed basis on vacant television channels 7–13 (174–216 MHz) and 14–46 (470–668 MHz) or on a licensed but secondary basis to private land mobile radio operations in the 450- to 470-MHz frequency band. This meant that wireless medical telemetry operations had to accept interference from the primary users of these frequency bands, i.e., the television broadcasters and private land mobile radio licensees. Further, if a wireless medical telemetry operation caused interference to television or private land mobile radio transmissions, the user of the wireless medical telemetry equipment would be responsible for rectifying the problem, even if that meant shutting down the medical telemetry operation.

The FCC was concerned that certain regulatory developments, including the advent of digital television (DTV) service, would result in more intensive use of these frequencies by the primary services, subjecting wireless medical telemetry operations to greater interference than before and perhaps precluding such operations entirely in many instances. To ensure that wireless medical telemetry devices can operate free of harmful interference, the FCC decided to establish the WMTS, in a Report and Order released on June 12, 2000 (FCC 2006).

The impetus for change occurred in mid-2000, following an incident at Baylor University Medical Center where a HDTV broadcast interrupted medical telemetry in part of the hospital for a short time (Baker 2002). This incident led to WMTS being created by the FCC, and older systems being phased out via attrition. Frequency assignment to channels in the WMTS band are still handled by a frequency coordinator to ensure that multiple uses of the frequency band within the hospital do not interfere with each other.

On the implantable side of wireless biomedical telemetry óne of the earliest uses of implantable telemetry involved the control of the pacing rate of implantable cardiac pacemakers. Originally, the control of the first pacemakers involved piercing the skin of the patient with a custom-sharpened screwdriver to adjust a small potentiometer encased in a waterproof silicone rubber seal. Much to the patients’ delight, a simple inductively coupled 160–190-kHz two-way telemetry system replaced the screwdriver and allowed painless adjustment of the pacemaker’s pacing rate. This telemetry system, which operates over a short range of just a few inches, was originally used by Medtronic Inc., beginning in the 1960s. Many medical implant manufacturers are still using these short-range inductively coupled systems.

Implantable telemetry systems currently in use today are evolving into longer-range telemetry, which includes the use of the MICS band from 402 to 405 MHz (nearly worldwide allocation), the 902–928-MHz ISM bands in the United States, and the 433 and 868 MHz bands in Europe.

The MICS band is an ultra-low-power band designed to be shared between weather balloons (Meteorological Aids) and medical implantable devices. This band provides licensing by rule, and protection against interference from nonlicensed interferers. The ISM bands allow the use of higher power levels, but must share the use of the frequency bands with other devices operating with much more efficient antennas and much higher power than implanted battery-operated systems. Due to body losses and limited battery power, implanted transmitters are typically the weakest link in the telemetry link and require a quiet, protected frequency band to operate consistently and effectively. The FCC created MICS to provide this.

For external to external and body-worn to external medical telemetry communications that are intended to operate outside healthcare facilities, the options are more limited. Primarily FCC Part 15 and the ISM bands provide the frequency solutions. Using these frequency bands is complicated by the different international radio regulations that have different frequencies and power levels between the United States and Europe. This makes a common worldwide solution very difficult. Different products often need to be designed for different countries.

The future of wireless biomedical telemetry will require systems that operate on common worldwide frequency bands to accommodate travelers. Better use of frequency spectrum and avoidance of interferers will also be necessary as wireless devices proliferate. Clear channel access protocol, and listen-before-talk protocols along with cognitive radio concepts and automatic frequency agility can be utilized to mitigate interference and channel-loading concerns.

Integrity

Although valued for their potential to facilitate information sharing horizontally across multiple care providers (internal and external to a specific medical facility) and longitudinally over years, EHRs are susceptible to easy alteration if safeguards are not implemented. It is essential that access control principles be applied consistently to ensure that information is reported by appropriate personnel (individually identifiable) and that information updates be time-sampled to support nonrepudiation and a kind of information “chain of custody.” Likewise, change control principles must be adhered to so that the sequence of interventions and events can be understood easily and patient care can be monitored and adjusted as needed. Effective implementation of access and change/configuration control mechanisms means that all health information sources within the facility’s ecosystem must be validated. Many of these information sources are wireless.

Clinician convenience and intensive scheduling demands can combine to create an environment in which data integrity cannot be ensured and receives only intermittent scrutiny. Record integrity is compromised, for example, when clinician notes are cloned (copied-and-pasted) from one patient to another or from one patient screening report to another, when dictation errors are accepted without validation, or when template documentation is inadequate for describing the patient condition. In addition to nonmalicious errors, inadequate data integrity can promote health care fraud and abuse.24

Wired connectivity is bolstered and augmented—even sometimes replaced—in medical facilities by the use of WAPs. This results in significant savings in plant upgrades, network infrastructure design flexibility, and clinician and patient information mobility. WAPs enable easy communication among facility guests, patients, and clinicians. WAPs also introduce complexity and uncertainty when wireless devices are allowed access to network connections without preregistration.

Given organizational budgetary constraints and the primary focus on building medical staff capacity, rather than IT staff, segmenting network traffic can reduce the risk of message and signal integrity, in a MITM or identity spoofing attack. By isolating guest and other occasional (i.e., not preregistered) devices to their own, separate network, opportunity for compromise of the facility’s protected assets is reduced. Different network segments need firewall separation with activity traceable to individual devices and incidents. The US DHS recommends whitelisting processes, machines, individuals, and data packages that are permissible. Devices that receive, transmit, and/or store patient information should connect through a hardened network connection. Robust access control policies that are well enforced help ensure that machines, individuals, or processes are not allowed privileged access without explicit challenge/response vetting.

The consequences of integrity compromise of wireless medical devices vary according to the specific use case scenario, as indicated in the following examples:

Patient-focused active medical devices like insulin pumps can be instructed to deny, modify, or deliver treatment. Treatment may include substance administration (e.g., medication, nutrition, oxygen), mechanical intervention (e.g., automatic defibrillation, life support). Loss of integrity in device programming can result in medication delivery errors (too much, too little, wrong medication).

Patient-focused passive medical devices vary from orthopedic implants to monitoring instruments (e.g., blood pressure and other vital statistics tracking).

Clinician-focused active medical devices can be used to perform remote surgery or give the clinician real-time information about the patient’s condition. Lack of integrity in the messages or work orders sent can result in patient harm.

Process-focused active medical devices can be instructed to scan medication barcodes, track patient drug allergies, adjust inventory management systems, control medication and organic material safety (e.g., temperature control to protect and preserve blood samples and banks, tissue samples, and organs for transplant).25

San Diego–based Independent Security Evaluators performed white hat exercises to test hypothetical attacks against hospital devices, processes, and EHRs. Carried out under conditions that mimicked actual medical facility operational environments, the exercises highlighted common susceptibilities that allowed the test threat agent to:

Manipulate a passive medical device from outside the network by performing an authentication bypass attack and causing the patient monitor to transmit false information and act erratically;

Control medicine administration and other workflow processes from a hospital lobby kiosk (that was not on a segregated network) by taking over barcode scanning equipment and causing patient and treatment mismatch;

Compromise the EHR system to issue improper treatment work orders by launching a cross-site scripting attack that allowed modification of administrator settings, authorized user changes, and then manipulation of patient records; and

Identify and compromise medical dispensary devices and inventory control systems.26

Project Program

mikroC Pro for PIC

The mikroC Pro for PIC program is named MIKROC-LED1.C, and the program listing is given in Figure 5.5. At the beginning of the program, PORTC pins are configured as outputs by setting TRISC = 0. Then, an endless for loop is formed, and the LEDs are turned ON alternately in an anticlockwise manner to give the chasing effect. The program checks continuously so that when LED 7 is turned ON the next LED to be turned ON is LED 0.

Figure 5.5. mikroC Pro for PIC Program Listing.

The program is compiled using the mikroC compiler. Project settings should be configured to an 8-MHz clock, XT crystal mode, and WDT OFF. The HEX file (MIKROC-LED1.HEX) should be loaded to the PIC18F45K22 microcontroller using an in-circuit debugger, a programming device, or the EasyPIC V7 development board.

When using the mikroC Pro for PIC compiler, the configuration fuses can be modified from the Edit Project window that is entered by clicking Project → Edit Project.

MPLAB XC8

The MPLAB XC8 program is named XC8-LED1.C, and the program listing is given in Figure 5.6. The program is basically the same as in Figure 5.5, except that here a 1-s delay is created using the basic XC8 __delay_ms function in a loop as it is not possible to create large delays using the __delay_ms function. Function Delay_Seconds creates delay in seconds where the amount of delay is specified by the argument of the function. Note also that the header file <xc.h> must be included at the beginning of the program. Also, the MPLAB IDE must be configured for the PIC18F45K22 type microcontroller and In-Circuit Debugger (ICD) 3 device (hardware tool). The ICD 3 device should be connected to the ICD socket on the EasyPIC V7 development board (top middle part, labeled as EXT ICD). The generated code can then be loaded to the target microcontroller using the MPLAB IDE (see Chapter 5 for more details).

Figure 5.6. MPLAB XC8 Program Listing.

When using the MPLAB XC8 compiler, the configuration fuses can be modified by specifying the “#pragma config” statements at the beginning of the program. It is important to note that different PIC microcontrollers have different sets of configuration fuses. Appendix A gives a list of the valid configuration fuses for the PIC18F45K22 microcontroller.

11.6 Chapter summary

All input and output is accomplished by using devices. There are many types of device, and each device has its own set of registers which are used to control the device. The programmer must understand the operation of the device and the use of each register in order to use the device at a low level. Computer system manufacturers usually can provide documentation providing the necessary information for low-level programming. The quality of the documentation can vary greatly, and a general understanding of various types of devices can help in deciphering poor or incomplete documentation.

There are two major tasks where programming devices at the register level is required: operating system drivers and very small embedded systems. Operating systems provide an abstract view of each device and this allows programmers to use them more easily. However, someone must write that driver, and that person must have intimate knowledge of the device. On very small systems, there may not be a driver available. In that case, the device must be accessed directly. Even when an operating system provides a driver, sometimes it is necessary or desirable for the programmer to access the device directly. For example, some devices may provide modes of operation or capabilities that are not supported by the operating system driver. Linux provides a mechanism which allows the programmer to map a physical device into the program's memory space, and thereby gain access to the raw device registers.

Pulse modulation is a group of methods for generating analog signals using digital equipment. Pulse modulation is commonly used in control systems to regulate the power sent to motors and other devices. Pulse modulation techniques can have very low power loss compared to other methods of controlling analog devices, and the circuitry required is relatively simple.

The cycle frequency must be programmed to match the application. Typically, 10 Hz is adequate for controlling an electric heating element, while 120 Hz would be more appropriate for controlling an incandescent light bulb. Large electric motors may be controlled with a cycle frequency as low as 100 Hz, while smaller motors may need frequencies around 10,000 Hz. It can take some experimentation to find the best frequency for any given application.

Most modern computer systems have some type of Universal Asynchronous Receiver/Transmitter. These are serial communications devices, and are meant to provide communications with other systems using RS-232 (most commonly) or some other standard serial protocol. Modern systems often have a large number of other devices as well. Each device may need it's own clock source, to drive it at the correct frequency for its operation. The clock sources for all of the devices are often controlled by yet another device: the clock manager.

Although two systems may have different UARTs, these devices perform the same basic functions. The specifics about how they are programmed will vary from one system to another. However, there is always enough similarity between devices of the same class that a programmer who is familiar with one specific device can easily learn to program another similar device. The more experience a programmer has, the less time it takes to learn how to control a new device.

2.1.4 FPGA Device Overview

Since field programmable gate array (FPGA) devices are the focus of this book, we will now consider FPGA architectures in more detail. FPGA or field programmable gate array devices were introduced in 1985 by Xilinx. FPGAs were developed to address the gap between CPLD and Application-Specific Integrated Circuits (ASIC) sevices. These new components provided a reduced-cost logic platform with the densities and I/O capabilities of gate arrays and the programmable nature of CPLDs. They supported faster time to market, enhanced design flexibility and simplified design debug, all prerequisites of rapid system prototyping and development.

FPGAs are manufactured by multiple manufacturers utilizing several different technologies. Each manufacturer offers different device “families” with common features, voltages and low-level device (IC) geometries. Each device family differs in the details of device architecture, device programming technology, internal signal routing, power, capacity, voltage, I/O support, and packaging. This broad range of implementation is due to strong competition between manufacturers, and a desire to differentiate products by targeting specific applications requiring different features and architectures, such as increased on-board memory or specific I/O support. Despite these differences, there are also significant design architecture, feature and development process similarities between the broad ranges of offered devices. Table 2.4 provides a listing of typical FPGA characteristics.

Table 2.4.

Manufacturers have refined their offerings with fine-tuned architectures and function sets that target specific applications and functional categories. In many cases new features were added as technology advanced. Many of these features were not of interest to the broad market, so further component variations occurred. Feature differences include device granularity, I/O interface support, resource mix (logic versus register), logic capacity, operational speed and power consumption.

Most FPGA manufacturers offer two main FPGA family categories: performance-optimized and cost-optimized. Within these families, the devices have a range of I/O and logic capabilities. Some families and devices will have a higher ratio of logic-to-I/O and are referred to as logic-centric. Other devices will have relatively more I/O than logic and are referred to as I/O-centric. Figure 2.9 illustrates the relationships between these categories. These categories are methods of clarifying the relative amount and cost of available resources.

With this competitive environment and evolution brought about by technology advancements, FPGA resources have continued to increase in density, complexity, speed, and I/O count as well as architecturally, by adding larger, more versatile blocks of embedded RAM, embedded hard and soft processor cores, dedicated hardware multipliers and high-speed communication capabilities. These larger device sizes, with more architectural enhancements along with advanced FPGA design tool integration, extensive hardware description language (HDL) usage and the availability of more intellectual property (IP), addressed later in this book, are allowing design teams to implement increasingly complex designs within shorter schedules.

The current high-end FPGA families feature millions of equivalent gates of functionality and high-speed interfaces capable of supporting a very broad range of engineering solutions including nontraditional applications. These high-end FPGA components are capable of implementing complex functionality which in the past would only have been practical with ASICs or extensive discrete-component board designs.