Table 18 – Components to be tested.
4.3 Interface Once the unit was assembled and programmed, it was tested thoroughly as a whole to ensure that it performed the required functions set out in sections 1.3.1 and 1.6. These included accurate reading, encoding, transmission, and display of pulse, blood oxygen content, and fall detection.
The first function that was tested was that the unit RDU can receive and display numbers properly from the TSU. To ensure that blood pressure was being monitored accurately, the pulse oximeter was worn on one finger, while a traditional blood pressure cuff or similar is worn on the other arm, and the outputs of pulse were compared. The reading from the pulse oximeter must be accurate, and also output properly to the display on the RDU. The MCU was temporarily coded to display the outputs from the gyroscopes and accelerometers to the display, to further ensure the display was behaving accurately.
The second major function to test was whether the RDU can make decisions and implement its indicators properly. A test routine was created and run to make sure that all of the LEDs and the buzzer were correctly functioning. Then, a temporary routine was implemented to input conditions to the multicontroller that would normally indicate an emergency. Indicator issues to be tested included: low battery, unit charging, heart attack conditions, detection of a fall, user panic input, emergency services notification, and communication failure. For each of these, actual alert behavior had to match intended alert behavior, in terms of which LEDs come on and for how long, whether the buzzer sounds and for how long, and whether the LCD screen produces the correct message.
Final testing of the unit included having a person actually wear the unit as designed, and putting it through the different possible scenarios, within the limitations of a person’s ability. To test fall detection, a person lay down at a normal rate first to ensure that the system does not produce a false positive. They then bumped into a wall but remain upright, to ensure the system did not produce a false positive. They then simulated a fall on relatively hard ground, to make sure the system alerts. This was done twice- once with pressing the ‘reset’ button to make sure the system accepts this input, and once with no response, to ensure that the system then moved to emergency procedures. Simulating a heart attack can be difficult, but the system was tested to ensure proper heart rate monitoring by setting the LCD to display heart rate and then engaging in a variety of activities that are known to alter the heart rate, including running or meditation. The user’s name must be encoded into the device, followed by a software-simulated heart attack, to ensure that the system outputs the user’s name, heart rate, and appropriate emergency information, along with sending a signal to the user’s cell phone. To avoid actually contacting emergency services for a test, the number 888 was sent to the cell phone as proof. The system was then be powered off and back on, to make sure that it returns to normal standby behavior again.
Section 5. Administrative Content 5.1 Budget and Financial Discussion The budget consists of all the parts required for this project to make the TSU, RDU, and fall detection units. The generic budget for one of each of the main components is fully expandable up to as many as needed. The cost of each subsystem is in the following tables.