8 march 2009 1 data acquisition prototype: project & system requirements phoenix ambulatory...
DESCRIPTION
8 March Purpose and Scope of this Document l Specify system requirements for a prototype of a data acquisition device –Incorporate system requirements of eventual Phoenix ABPM, but… –Do not specify the Phoenix ABPM –Supplement Phoenix requirements with prototype- specific requirements l Incorporate results of sensor prototypes to-dateTRANSCRIPT
8 March 20098 March 2009 11
Data Acquisition Prototype:Data Acquisition Prototype: Project & System RequirementsProject & System Requirements
PhoenixPhoenixAmbulatory Blood Pressure Monitoring SystemAmbulatory Blood Pressure Monitoring System
© 2009 Christopher J. AdamsCopying and distribution of this document is permitted in any medium, provided this notice is preserved
Version 1.0Version 1.0
8 March 20098 March 2009 22
OutlineOutline Purpose and Scope of this DocumentPurpose and Scope of this Document Project VisionProject Vision System Vision & Scope System Vision & Scope (Business Requirements)(Business Requirements)
User RequirementsUser Requirements– Use CasesUse Cases– Algorithms Algorithms (Business Rules)(Business Rules)
System RequirementsSystem Requirements– Functional RequirementsFunctional Requirements– Major Nonfunctional RequirementsMajor Nonfunctional Requirements
AppendicesAppendices– Unresolved IssuesUnresolved Issues– Design Direction DetailsDesign Direction Details
8 March 20098 March 2009 33
Purpose and ScopePurpose and Scopeof this Documentof this Document
Specify system requirements for a prototype of a Specify system requirements for a prototype of a data acquisition devicedata acquisition device– Incorporate system requirements of eventual Phoenix Incorporate system requirements of eventual Phoenix
ABPM, but…ABPM, but…– Do not specify the Phoenix ABPMDo not specify the Phoenix ABPM– Supplement Phoenix requirements with prototype-Supplement Phoenix requirements with prototype-
specific requirementsspecific requirements Incorporate results of sensor prototypes to-dateIncorporate results of sensor prototypes to-date
8 March 20098 March 2009 44
Project VisionProject Vision Acquire community knowledge aboutAcquire community knowledge about
– Data acquisition devicesData acquisition devices– Hardware and software co-designHardware and software co-design– Partitioning systems into subsystemsPartitioning systems into subsystems– Allocating system requirements to subsystemsAllocating system requirements to subsystems– Embedded software Embedded software architecturearchitecture options options
(round robin, round robin w/ interrupts, …, RTOS)(round robin, round robin w/ interrupts, …, RTOS)– Hardware optionsHardware options
(gates, clocks, memory, MP, buses, DMA, interrupts, ports, …)(gates, clocks, memory, MP, buses, DMA, interrupts, ports, …)– Designing low-power devicesDesigning low-power devices– Acquiring hardware componentsAcquiring hardware components– Testing embedded softwareTesting embedded software
Document results so they can be reproducedDocument results so they can be reproduced
8 March 20098 March 2009 55
Project VisionProject Vision Architecture — basic technologyArchitecture — basic technology
– Hardware architectureHardware architecture– Hardware component selectionHardware component selection– Embedded software architectureEmbedded software architecture– Software language selectionSoftware language selection– Cross-platform development toolsCross-platform development tools
PrototypePrototype– Must build a device to evaluate interdependent design optionsMust build a device to evaluate interdependent design options– Learning is primaryLearning is primary– Expect subsequent evolutionExpect subsequent evolution– Willing to abandon device based on lessons learnedWilling to abandon device based on lessons learned
Computing device is primaryComputing device is primary– Sensing is secondarySensing is secondary– Acquired data may be simulatedAcquired data may be simulated
8 March 20098 March 2009 66
System VisionSystem Vision Data acquisition device Data acquisition device (next slides)(next slides) Embedded analytics Embedded analytics (next slides)(next slides) Embedded data storage Embedded data storage (next slides)(next slides) Device allows ambulation during useDevice allows ambulation during use
– At least carriableAt least carriable Electrically self-containedElectrically self-contained
– Does not rely on external power sourceDoes not rely on external power source Power-sensitive designPower-sensitive design
– Design for either:Design for either: Low power, orLow power, or Power measurementPower measurement
8 March 20098 March 2009 77
System VisionSystem Vision Data acquisition deviceData acquisition device
– Collects continuous analog signals from two sensorsCollects continuous analog signals from two sensors At least one is piezoelectric film sensorAt least one is piezoelectric film sensor
– Measurement Specialties SDT1-028KMeasurement Specialties SDT1-028K
– Collects from piezoelectric film sensorCollects from piezoelectric film sensor Up to Up to 4040 samples per cardiac cycle samples per cardiac cycle @ 200 beats per minute (maximum)@ 200 beats per minute (maximum)
– Converts analog signals to digital signalsConverts analog signals to digital signals– Collects discrete signals from wearer-pressable push-buttonCollects discrete signals from wearer-pressable push-button
Button downButton down Button upButton up
– Turns on and off a human-perceivable device-mounted lightTurns on and off a human-perceivable device-mounted light
133 samples per second
8 March 20098 March 2009 88
System VisionSystem Vision Embedded analyticsEmbedded analytics
– Identifies / marks peak of each continuous waveformIdentifies / marks peak of each continuous waveform VoltageVoltage
– Identifies / marks trough of each continuous waveformIdentifies / marks trough of each continuous waveform VoltageVoltage
– Calculates biometricsCalculates biometrics Heart rateHeart rate
– Beats per minuteBeats per minute Systolic blood pressureSystolic blood pressure
– mmHgmmHg Diastolic blood pressureDiastolic blood pressure
– mmHgmmHg– Performs calculations over 5 cardiac cycles every 30 minutesPerforms calculations over 5 cardiac cycles every 30 minutes– Translates different combinations of button-down and button-up Translates different combinations of button-down and button-up
signals into eventssignals into events
8 March 20098 March 2009 99
System VisionSystem Vision Embedded data storageEmbedded data storage
– Timestamps each acquired & calculated valueTimestamps each acquired & calculated value– Preserves three days of acquired & calculated dataPreserves three days of acquired & calculated data– Preserves all acquired valuesPreserves all acquired values
See “Data acquisition device”See “Data acquisition device”– Preserves all calculated valuesPreserves all calculated values
See “Embedded analytics”See “Embedded analytics”
8 March 20098 March 2009 1010
System VisionSystem VisionMajor Out-of-Scope CapabilitiesMajor Out-of-Scope Capabilities
Capacity for full 7 days of dataCapacity for full 7 days of data Patient alertsPatient alerts Localization outside of U.S.Localization outside of U.S.
– ProductionProduction– UseUse
Analog signal processingAnalog signal processing– As alternative to digital signal processingAs alternative to digital signal processing– Separate research topicSeparate research topic
HMI beyond simple light bulbHMI beyond simple light bulb– Will not display calculated valuesWill not display calculated values– Continued exclusion depends on analysis of power managementContinued exclusion depends on analysis of power management
8 March 20098 March 2009 1111
System ContextSystem Context
8 March 20098 March 2009 1212
Use CasesUse Cases Wearer signals the device to log an eventWearer signals the device to log an event
– Assures data-acquisition logic despite sensor failure Assures data-acquisition logic despite sensor failure Technician or wearer confirms device functionsTechnician or wearer confirms device functions Technician connects device to wearerTechnician connects device to wearer System collects dataSystem collects data Wearer restarts data collectionWearer restarts data collection Technician off-loads data from deviceTechnician off-loads data from device
8 March 20098 March 2009 1313
Use CasesUse CasesWearer Signals Device to Log EventWearer Signals Device to Log Event
1.1. Wearer pushes button (and holds until step 6)Wearer pushes button (and holds until step 6)2.2. System activates status lightSystem activates status light3.3. System logs button-downSystem logs button-down4.4. Wearer observes status lightWearer observes status light5.5. Wearer may pauseWearer may pause6.6. Wearer releases buttonWearer releases button7.7. System logs button-upSystem logs button-up8.8. System de-activates status lightSystem de-activates status light9.9. Wearer observes status lightWearer observes status light10.10. Wearer may pauseWearer may pause11.11. Wearer repeats sequence according to predefined codeWearer repeats sequence according to predefined code
8 March 20098 March 2009 1414
Use CasesUse CasesTechnician or Wearer Confirms Device FunctionsTechnician or Wearer Confirms Device Functions
1.1. User signals device-start eventUser signals device-start event2.2. System runs System runs diagnosticsdiagnostics3.3. System toggles the status light in a pattern System toggles the status light in a pattern
indicating successful start-upindicating successful start-up4.4. Technician observes status lightTechnician observes status light
8 March 20098 March 2009 1515
Use CasesUse CasesTechnician Connects Device to WearerTechnician Connects Device to Wearer
1.1. Technician starts deviceTechnician starts device– Signals device-start eventSignals device-start event– Use case “Wearer Signals Device to Log Event”Use case “Wearer Signals Device to Log Event”
2.2. Technician confirms device functionsTechnician confirms device functions– Signals run-diagnostics eventSignals run-diagnostics event– Use case “Wearer Signals Device to Log Event”Use case “Wearer Signals Device to Log Event”
3.3. Technician places and fastens device on wearerTechnician places and fastens device on wearer4.4. Wearer confirms device is comfortableWearer confirms device is comfortable5.5. Technician starts data acquisitionTechnician starts data acquisition
– Signals acquisition-start eventSignals acquisition-start event– Use case “Wearer Signals Device to Log Event”Use case “Wearer Signals Device to Log Event”
8 March 20098 March 2009 1616
Use CasesUse CasesSystem Collects DataSystem Collects Data
1.1. System waits for configured durationSystem waits for configured duration2.2. System activates status lightSystem activates status light3.3. Systems periodically reads data from each sensorSystems periodically reads data from each sensor
– Periodicity configured sensor-by-sensorPeriodicity configured sensor-by-sensor4.4. System timestamps and stores each readingSystem timestamps and stores each reading5.5. System continues reading data for configured durationSystem continues reading data for configured duration6.6. System calculates embedded analyticsSystem calculates embedded analytics7.7. System timestamps and stores each calculated valueSystem timestamps and stores each calculated value8.8. System deactivates status lightSystem deactivates status light9.9. Above sequence repeatsAbove sequence repeats
8 March 20098 March 2009 1717
Use CasesUse CasesWearer Confirms Device is WorkingWearer Confirms Device is Working
1.1. Wearer signals device-check eventWearer signals device-check event– Use case “Wearer Signals Device to Log Event”Use case “Wearer Signals Device to Log Event”
2.2. Wearer observes status light to confirm Wearer observes status light to confirm device functiondevice function
8 March 20098 March 2009 1818
Use CasesUse CasesWearer Restarts Data CollectionWearer Restarts Data Collection
1.1. Wearer places and fastens device on selfWearer places and fastens device on self2.2. Wearer signals acquisition-start eventWearer signals acquisition-start event
– Use case “Wearer Signals Device to Log Event”Use case “Wearer Signals Device to Log Event”
8 March 20098 March 2009 1919
Use CasesUse CasesTechnician Off-Loads Data from DeviceTechnician Off-Loads Data from Device
1.1. Technician connects device to Technician connects device to storage systemstorage system2.2. Technician signals download-initiation eventTechnician signals download-initiation event
– Use case “Wearer Signals Device to Log Event”Use case “Wearer Signals Device to Log Event”
3.3. System transforms data into transmission format and System transforms data into transmission format and transfers transformed data to file, while manipulating transfers transformed data to file, while manipulating status light to signal transfer progressingstatus light to signal transfer progressing
4.4. System signals completion of transfer with status lightSystem signals completion of transfer with status lightPost-condition:Post-condition:
• Off-loaded data is in a state in which it can be used by external Off-loaded data is in a state in which it can be used by external systemssystems
8 March 20098 March 2009 2020
AlgorithmsAlgorithms
Calculation of pressure waveCalculation of pressure wave Waveform peakWaveform peak Waveform troughWaveform trough Heart rateHeart rate Systolic blood pressureSystolic blood pressure Diastolic blood pressureDiastolic blood pressure
8 March 20098 March 2009 2121
Functional RequirementsFunctional Requirements Downloaded DataDownloaded Data
– ::=::= HeadHead
– Device IDDevice ID– ( Absolute base time )( Absolute base time )– Timestamp of download initiationTimestamp of download initiation
BodyBody– { Acquired/calculated Item }*{ Acquired/calculated Item }*
• Sensor ID/Data Source IDSensor ID/Data Source ID• Timestamp of acquisition/calculationTimestamp of acquisition/calculation• Information typeInformation type• ValueValue
TailTail– Timestamp of download completionTimestamp of download completion– End of data markerEnd of data marker
– If timestamps are relativeIf timestamps are relative then download must include absolute base timethen download must include absolute base time
8 March 20098 March 2009 2222
Functional RequirementsFunctional Requirements Acquired/calculated Acquired/calculated
information typeinformation type– Acquisition control eventAcquisition control event
Start deviceStart device Stop deviceStop device Start acquisitionStart acquisition Stop acquisitionStop acquisition Run diagnosticsRun diagnostics Test acquisitionTest acquisition
– Wearer eventWearer event– Acquired continuous valueAcquired continuous value
mVmV– Acquired discrete valueAcquired discrete value
On/off, down/up, yes/noOn/off, down/up, yes/no
Acquired/calculated Acquired/calculated information typeinformation type– Calculated valuesCalculated values
Pulse (heart rate)Pulse (heart rate)– Units: beats per minuteUnits: beats per minute– Range: 30–200 bpmRange: 30–200 bpm– Accuracy: Accuracy: 5%5%
Systolic blood pressureSystolic blood pressure– Units: mmHgUnits: mmHg– Range: 60–280 mmHgRange: 60–280 mmHg– Accuracy: Accuracy: 3 mmHg3 mmHg
Diastolic blood pressureDiastolic blood pressure– Units: mmHgUnits: mmHg– Range: 40–160 mmHgRange: 40–160 mmHg– Accuracy: Accuracy: 3 mmHg3 mmHg
8 March 20098 March 2009 2323
Major Nonfunctional RequirementsMajor Nonfunctional Requirements InterfacesInterfaces
– OutgoingOutgoing Downloaded dataDownloaded data
– Free and open formatFree and open format– Formal and concise formatFormal and concise format– Human legibleHuman legible– Presentable & workable as plain text file (e.g., editable with text editor)Presentable & workable as plain text file (e.g., editable with text editor)– Widely used format (e.g., industry standard)Widely used format (e.g., industry standard)– Primary options: XML, HL7Primary options: XML, HL7
• However, must understand impact of tagging the dataHowever, must understand impact of tagging the data– Physical ConnectorsPhysical Connectors
Device downloads data via a standard connectorDevice downloads data via a standard connector– Primary options: Secure Digital, USBPrimary options: Secure Digital, USB– Excluded option: RS232Excluded option: RS232
Physical ConstraintsPhysical Constraints– Wearer wears or carries device during operationWearer wears or carries device during operation
8 March 20098 March 2009 2424
Major Nonfunctional RequirementsMajor Nonfunctional Requirements Legal RequirementsLegal Requirements
– Licenses of created works are attributable to the authorsLicenses of created works are attributable to the authors– Free and open sourceFree and open source
Rationale — seeRationale — seehttp://www.phoenix.http://www.phoenix.tctc--ieeeieee.org/000_Background/Phoenix_.org/000_Background/Phoenix_OpenSourceOpenSource..htmhtm
– SoftwareSoftware All software created by the project is free and openAll software created by the project is free and open
– As defined by the Open Source InitiativeAs defined by the Open Source Initiative– http://www.http://www.opensourceopensource.org/docs/definition..org/docs/definition.phpphp
(version 1.9, 2006-07-24)(version 1.9, 2006-07-24) All software incorporated from third parties into the productAll software incorporated from third parties into the product
– Is freeIs free– May be freely redistributedMay be freely redistributed– May be bundled with free and open source software without impinging May be bundled with free and open source software without impinging
on rights of distribution under the open source definitionon rights of distribution under the open source definition
8 March 20098 March 2009 2525
Major Nonfunctional RequirementsMajor Nonfunctional Requirements Legal RequirementsLegal Requirements
– HardwareHardware All hardware designs shall be free — Free Hardware DesignAll hardware designs shall be free — Free Hardware Design
– Design can be freely copied, distributed, modified, and manufacturedDesign can be freely copied, distributed, modified, and manufactured– Does not imply:Does not imply:
• that the design cannot also be sold, orthat the design cannot also be sold, or• that any hardware implementation of the design will be free of costthat any hardware implementation of the design will be free of cost
– Ref: Open CollectorRef: Open Collector• http://www.http://www.opencollectoropencollector.org/.org/WhyfreeWhyfree/definitions.html/definitions.html
All hardware designs shall be open — Open Source HardwareAll hardware designs shall be open — Open Source Hardware– The interface to the hardware must be explicitly made publicThe interface to the hardware must be explicitly made public
• so the hardware can be used freelyso the hardware can be used freely– The design of the hardware must be made publicThe design of the hardware must be made public
• so that others can implement it and learn from itso that others can implement it and learn from it– The tools used to create the design should be freeThe tools used to create the design should be free
• so that others can develop and improve the designso that others can develop and improve the design– Ref: Open CollectorRef: Open Collector
• http://www.http://www.opencollectoropencollector.org/.org/WhyfreeWhyfree/open_hardware.html/open_hardware.html
8 March 20098 March 2009 2626
Major Nonfunctional RequirementsMajor Nonfunctional Requirements
Safety RequirementsSafety Requirements– Electro-Magnetic InterferenceElectro-Magnetic Interference
Device cannot electrically interfere with other electronic devicesDevice cannot electrically interfere with other electronic devices Ref: Ref: FCC Part 68FCC Part 68 For prototype, EMI resistance need be sufficient only to assure For prototype, EMI resistance need be sufficient only to assure
accurate readingsaccurate readings
8 March 20098 March 2009 2727
AppendixAppendixUnresolved IssuesUnresolved Issues
[Bob S] What are the frequency and [Bob S] What are the frequency and resolution requirements for:resolution requirements for:– HR?HR?– DBP?DBP?– SBP?SBP?
[Dick S] Background about power [Dick S] Background about power management circuitsmanagement circuits
[?] Interpretation of FCC Part 68 (EMI)[?] Interpretation of FCC Part 68 (EMI)
8 March 20098 March 2009 2828
AppendixAppendixDesign Direction DetailsDesign Direction Details
Analyze software architecture optionsAnalyze software architecture options– Round-robinRound-robin– Round-robin with interruptsRound-robin with interrupts– Function queue schedulingFunction queue scheduling– Real-time operating systemReal-time operating system
Analyze algorithmsAnalyze algorithms– Calculation of pressure wave (e.g., Chen method)Calculation of pressure wave (e.g., Chen method)– Waveform peakWaveform peak– Waveform troughWaveform trough– Heart rateHeart rate– Systolic blood pressureSystolic blood pressure– Diastolic blood pressureDiastolic blood pressure
8 March 20098 March 2009 2929
AppendixAppendixDesign Direction DetailsDesign Direction Details
Analyze software interface standardsAnalyze software interface standards– XML vs HL7 vs otherXML vs HL7 vs other
Analyze hardware connector standardsAnalyze hardware connector standards– USB vs Secure DigitalUSB vs Secure Digital
Define diagnosticsDefine diagnostics– Based on designBased on design
Select licenses (may affirm current direction)Select licenses (may affirm current direction)
8 March 20098 March 2009 3030
Design Direction DetailsDesign Direction DetailsCalculation of Pressure WaveCalculation of Pressure Wave
Chen et. al, US Patent No. 6,599,251Chen et. al, US Patent No. 6,599,251– Arterial pulse delay proportional to blood pressureArterial pulse delay proportional to blood pressure
P = a + b ln(T)P = a + b ln(T)– T = Time delay(milliseconds)T = Time delay(milliseconds)– a,b = constants depending ona,b = constants depending on
• nature of the subjectnature of the subject• signal detecting devicesignal detecting device
QuickTime™ and aTIFF (Uncompressed) decompressor
are needed to see this picture.
(Richard E. Klabunde, Ph.D, “Cardiovascular Physiology Concepts”, http://www.cvphysiology.com)