Command Translator for
Medical Device Testing
Senior Design Dec05-05
Project Plan
Client
Guidant Corporation
Faculty Advisors
Professor John Lamont
Professor Ralph Patterson III
Team Members
Adam Guy, CprE
Justin Koob, CprE
Marc McKee, EE
Adam Mishler, CprE
REPORT DISCLAIMER NOTICE
DISCLAIMER: This document was developed as a part of the requirements of an electrical and computer engineering course at IowaStateUniversity, Ames, Iowa. This document does not constitute a professional engineering design or a professional land surveying document. Although the information is intended to be accurate, the associated students, faculty, and IowaStateUniversity make no claims, promises, or guarantees about the accuracy, completeness, quality, or adequacy of the information. The user of this document shall ensure that any such use does not violate any laws with regard to professional licensing and certification requirements. This use includes any work resulting from this student-prepared document that is required to be under the responsible charge of a licensed engineer or surveyor. This document is copyrighted by the students who produced this document and the associated faculty advisors. No part may be reproduced without the written permission of the senior design course coordinator.
March 28, 2005
1
Table of Contents
List of Figures
List of Tables
List of Definitions
1Section 1: Introductory Material
1.1Abstract
1.2Acknowledgement
1.3Problem Statement
1.3.1General Problem Statement
1.3.2General Solution Approach
1.4Operating Environment
1.5Intended Users and Intended Uses
1.5.1Intended Users
1.5.2Intended Uses
1.6Assumptions and Limitations
1.6.1Initial Assumptions List
1.6.2Initial Limitations List
1.7Expected End Product and Deliverables
2Section 2: Proposed Approach
2.1Functional Requirements
2.2Constraints Considerations
2.3Technology Considerations
2.4Technical Approach Considerations
2.5Testing Requirements Considerations
2.6Security Considerations
2.7Safety Considerations
2.8Intellectual Property Considerations
2.9Commercialization Considerations
2.10Possible Risks and Risk Management
2.11Project Proposed Milestones and Evaluation Criteria
2.12Project Tracking Procedures
3Section 3: Statement of Work
3.1Task No. 1 – Problem Definition
3.1.1Subtask No. 1a – Problem Identification
3.1.2Subtask No. 1b – Identification of end-user(s) and end-use(s)
3.1.3Subtask No. 1c – Identification of Project Constraints
3.2Task No. 2 – Technology Considerations and Selection
3.2.1Subtask No. 2a – Identification of Possible Technologies
3.2.2Subtask No. 2b – Further Technological Research
3.2.3Subtask No. 2c – Purchase Technological Components
3.3Task No. 3 – End Product Design
3.3.1Subtask No. 3a – Identification of Requirements
3.3.2Subtask No. 3b – Design Process
3.3.3Subtask No. 3c – Document Design Strategy/Approach
3.4Task No. 4 – End Product Prototype Implementation
3.4.1Subtask No. 4a – Develop Software
3.4.2Subtask No. 4b – Develop Hardware
3.5Task No. 5 – End Product Testing
3.5.1Subtask No. 5a – Test Planning
3.5.2Subtask No. 5b – Test Development
3.5.3Subtask No. 5c – Prototype Testing
3.5.4Subtask No. 5d – Evaluation of Test Results
3.5.5Subtask No. 5e – Testing Documentation
3.6Task No. 6 – End-product documentation
3.6.1Subtask No. 6a – User Manual
3.6.2Subtask No. 6b – Technical Instructions
3.6.3Subtask No. 6c – Other Required Documents
3.7Task No. 7 – End-product demonstration.
3.7.1Subtask No. 7a – Demonstration Planning
3.7.2Subtask No. 7b – Client/Faculty Advisor Demonstration
3.7.3Subtask No. 7c – Industrial Review Panel Demonstration
3.8Task No. 8 – Project Reporting
3.8.1Subtask No. 8a – Weekly Email Reporting
3.8.2Subtask No. 8b – Project Plan
3.8.3Subtask No. 8c – Project Poster
3.8.4Subtask No. 8d – Design Report
3.8.5Subtask No. 8e – Final Report
4Section 4: Estimated Resource and Schedule Requirement
4.1Personnel Effort Requirements
4.2Other Resource Requirements
4.3Financial Requirements
4.4Schedule
5Section 5: Closure Material
5.2Project Team Information
5.2.1Client Information
5.2.2Faculty Advisor Information
5.2.3Student Team information
5.3Closing Summary
5.4References
List of Figures
List of Tables
Table 1: Personnel Effort Requirements Estimate (hours)......
Table 2: Other Resource Requirements......
Table 3: Financial Requirements......
List of Definitions
SMU (source measurement unit)– Fully programmable instrumentcapable of measuring and sourcing both voltage and current simultaneously. Acts as four instruments in one, voltage source, current source, voltage measure, and current measure.
GPIB (general purpose instrumentation bus) – A bus developed to connect and control programmable instruments. Provides a standard interface as defined by the IEEE 488 standard for communication between instruments from different sources.
ESD (electrostatic discharge) – A potentially hazardous surge of electrical charge due to a voltage difference between objects.
FPGA (field programmable gate array) – An FPGA is a device that allows for customization through a hardware design language of the low level hardware elements.
IDE (integrated development environment) – A development environment in which software can be developed, usually includes advanced features including a debugger.
1
1Section 1: Introductory Material
The introductory section of this report presents the abstract, acknowledgements, problem statement, operating environment, intended users and intended uses, assumptions and limitations, and expected end product deliverables.
1.1Abstract
A pacemaker helps to control one of the most critical organs of the human body, the heart. Due to the level of importance of the pacemaker’s correct and accurate functionality, pacemakers are extensively tested using computer driven instrumentation. Furthermore, the software used to test pacemakers is subjected to rigorous testing and is granted certification through government agencies. A device will be created using a microcontroller or FPGA that will translate commands proprietary to the previously used instrumentation into commands that can be used with newer, enhanced instrumentation. This will allow Guidant to use existing, certified software programs with newer equipment while not having to totally re-certify all applications. This device will save time, resources, and facilitate the use of existing, reliable, certified test software.
1.2Acknowledgement
The team would like to thank the faculty advisors, Dr. John Lamont and Prof. Ralph Patterson for their assistance and direction throughout the project. The team is also grateful for the immense financial assistance and technical guidance from Max Cortner and Andrew Garnett of Guidant.
1.3Problem Statement
The following two sections outline the general solution approach.
1.3.1General Problem Statement
Guidant currently uses a Keithley 237 SMU (source measurement unit) that receives proprietary commands via a GPIB (general purpose instrumentation bus) bus. In the near future, Guidant may upgrade these source measurement units to a different, more capable model requiring newly formatted commands. In order to update the source measurement units, the testing software will need to be changed, essentially requiring extensive re-certification. A device will be designed that will, instead of requiring a change in the testing software, be fitted in-line with the software and instrumentation to translate the old commands into commands recognizable by newer instrumentation. This approach should minimize the client’s re-certification obligations by only requiring certification of the device itself, and not the original testing software.
1.3.2General Solution Approach
The device will be implemented using either an FPGA (field-programmable gate array) or a microcontroller. The device will have two separate GPIB interfaces, one to be connected to the computer, while the other is connected to the source measurement unit as shown in Figure 1.
Figure 1: General Block Diagram
1.4Operating Environment
Since the system will be used for testing pacemakers, the primary operating environment will be in an indoor lab setting. The system could be sensitive to ESD and should be kept in a controlled environment. The system should also be relatively durable, as it could be moved around.
1.5Intended Users and Intended Uses
The following two sections will detail the intended users and intended uses of the Command Translator for Medical Device Testing.
1.5.1Intended Users
The translator will be designed to meet specific requirements set forth by Guidant. The intended users of the device are Guidant test engineers, technicians, and anyone else that Guidant designates should be working with the testing equipment. The device is not proprietary to Guidant, however, and it is therefore conceivable that the device could be used by someone or some other company facing a similar situation.
1.5.2Intended Uses
The team anticipates that Guidant will use this tool to assist in the testing of their pacemakers. The translation device will be designed to translate commands specifically destined for the Keithley 237 source measurement unit (SMU). The device will be designed so that it is possible to easily reprogram it to translate any arbitrary command to be recognized by any sort of instrument utilizing a GPIB bus.
1.6Assumptions and Limitations
The following two sections detail the initial assumptions and limitations that the project will be designed around. These lists will be updated frequently to reflect design decisions.
1.6.1Initial Assumptions List
The initial assumptions are shown in the following list.
- While other equipment could be supported,the translator will be configured tomake translations originally destined for the Keithley SMU to another newer, more capable device
- Device will be used exclusively by Guidant Test Engineers
- Device will be easily connected between the SMU and computer
- Device will be implemented using an FPGA or microcontroller
- Any language (C, C++, assembly) can be used to initially program the device
- Guidant will provide all required technical specifications
- Guidant will provide all required equipment
1.6.2Initial Limitations List
The initial limitations are shown in the following list.
- The bus interface will be GPIB (IEEE 488)
- Commands to be translated will be intended for a Keithley SMU
- Must be sized to fit inside 19” testing rack
- Must run on 120 Volt AC
1.7Expected End Product and Deliverables
The main end product deliverables will be delivered to Guidant before the end of the project, December of 2005.
The expected deliverables will include a functional prototype which will be delivered to Guidant. This prototype will be extensively tested and will also include testing documentation to help Guidant in their certification process. Guidant will be provided with detailed design specifications. This information will be provided at a level from which Guidant can reproduce the device.
Any software that has been created for the device will also be included. This includes any software created to test the device, as well as embedded software driving the translator.
A design report to detail the entire project will be providedto Guidant with information that may aid in the certification process. The design report should also include information that will allow a qualified developer to modify the device to function with other instrumentation.
The test plan and resulting data analysis will be delivered to Guidant. By collecting data during the test period, the success of the project will be determined.This data will be presented to Guidant in a manner in an appropriate manner.
2Section 2: Proposed Approach
In order to maintain success throughout the project, it is necessary to define an approach from which to operate. The following section details the functional requirements and design considerations for the command translator project.
2.1Functional Requirements
The working design will have several requirements in order to function properly.
- Translate SMU data – The data received by the translator device must be accurately converted to that which is required by the SMU.
- GPIB compatible – I/O data must adhere to IEEE STD-488 (GPIB).
- Multiple addresses – The device must be able to correctly distinguish and communicate with multiple SMU’s at once.
- Two-way communication – The device must be able to send and receive data to/from the SMU. While the primary function of the interface is to translate and submit commands, it may also be required to receive information such as device status or a data dump.
- Selective processing – Some of the data being transmitted across the GPIB bus to the translator device but may not be intended for the SMU, but intended for another device. The translator device must choose to ignore and pass undesired information.
- Power supply – The device must be powered by a standard 120 Volt AC outlet.
2.2Constraints Considerations
The initial constraintsshown in the following list are based upon the assumptions and limitations found in sections 1.6.1 and 1.6.2 respectively.
- Size – The device will be required to fit in a 19” device rack.
- Attachment limitations – The data available for translation is pre-defined by both the testing software and the SMU.
- Connectivity– Connections from the device to the external hardware must be easily established.
- Bus – The device must utilize GPIB for connecting and controlling the devices.
- Power – Power requirements can be no higher than that supplied by a standard 120 Volt AC outlet.
2.3Technology Considerations
The primary technology considerations for the device will be either a FPGA (field-programmable gate array) or a microcontroller. These considerations are based primarily on cost and ease of programmability. Additional factors include cost and ease of modification. The SMU replacement model will also play a factor in the technology analysis. A power source of some type will be designed in order to power the translator device through a 120 Volt AC outlet.
If a microcontroller is chosen, software will be written in an appropriate language best fitting for the specific model.
2.4Technical Approach Considerations
The initial phase of the project design will require evaluation of the commands to be translated from the computer system to the SMU. This will provide a basis from which to research and choose the appropriate technology for implementation. The completion of the technology selection will allow for prototype development, programming, and testing.
2.5Testing Requirements Considerations
The device prototype will be thoroughly tested with the application software provided by Guidant in an environment similar to the setting of its intended use.
Testing of each of the requirements listed in Section 2.1 will guarantee proper functionality and translation. In the event that the prototype does not meet any of the testing specifications, error analysis will provide the source of the problem and potential solutions.
Unit and integration testing will be performed throughout the development phase of the project. The end product prototype will be first tested by the team. Following the initial testing, other students from the department will test the device, following up with the final testing by Guidant with team support.
2.6Security Considerations
Security is not a large area of concern, as the information required for the project design is in the public domain. The device is involved in testing and is not related to the design of Guidant’s end product. Security pertaining to the actual device itself is also not a huge concern. The device is not connected in any way to outside networks that could pose further security considerations.
2.7Safety Considerations
The device will be used in a laboratory setting and must adhere to any of the applicable safety guidelines. Nothing in the project requirements should cause any concern for safety issues, and the device will not be any more dangerous than basic consumer electronic devices.
2.8Intellectual Property Considerations
The device functionality will be basic data translation and not be considered intellectual property. The actual commands running through the device will be Guidant’s intellectual property, however, this will not be a factor in the functional design because this device is not connected to any sort of outside network which could pose further intellectual property consideration.
2.9Commercialization Considerations
The project is intended only for use in Guidant’s device testing process, so commercial avenues will not be pursued.
2.10 Possible Risks and Risk Management
Through the course of the design project, there may be several factors or risks upon which the project success might rely.
- Parts delay – Upon selecting and ordering components for use in the device prototype, it may be possible that there is a delay in obtaining them. This is a factor primarily outside of the team’s control, but will be based on the timing associated with the project. The parts must be ordered in a timely fashion and the schedule will allow for a small delay.
- Ineffective team/client communication –Both Guidant and the design group are subjected to outside factors not pertaining to the project, which may cause delays in project progression. Establishing a regular and informative method of contact between the design group and the client will be a key factor in overcoming this risk. In the even to of a communication delay from Guidant, the team will progress to the furthest extent possible in an effort to maintain on schedule.
- Loss of a team member – Circumstances might arise in which a team member may no longer be able to act as part of the team. A condition such as this highlights the importance of staying on schedule and proper documentation. Each team member will be involved in all aspects of the project in order to minimize the risk associated with team member loss. When individual work is assigned, a backup team member will be designated on each task to prevent a loss of work continuity.
- Unsuccessful approach – The assumptions, limitations, constraints, and design objectives provide a good indicator of the approach to be taken, but this approach may not guarantee successful results. Continuous review and monitoring of the approach taken will be conducted during the pursuit of each milestone and in the weekly reporting. Any indication of an unsuccessful approach will prompt a reconsideration of the design approach.
2.11 Project Proposed Milestones and Evaluation Criteria
The accomplishments from which to judge the project’s progress are identified below, along with a designated importance level:
Milestone 1:Project definition
Description: Identify problem scope and design objectives
Importance: High – 15%
Milestone 2: Technology research and selection
Description: Identify possible technology choices and choose the best one.
Importance: Medium – 10%
Milestone 3:Product design
Description: Formulate problem solution and design
Importance: High – 20%
Milestone 4: Implementation of design
Description: Build desired prototype using product design
Importance: High – 20%
Milestone 5:Prototype testing
Description: Administer functional testing and error correction of prototype
Importance: High – 15%
Milestone 6: Document development
Description: Create instructions and any additional documentation to accompany prototype.
Importance: Low – 5%
Milestone 7:Prototype demonstration
Description:Presentation of final product and demonstration to Guidant
Importance: High – 15%
It is essential to establish a set of factors in order to evaluate each of the milestones described above. Each of the importance percentages will be accompanied by a rank multiplier indicating the level of success and then totaled to obtain an overall percentage of success. The rank multipliers and their criteria are listed below.