PRE2020 3 Group4
Group members
| Name | Student ID | Department | Email address |
|---|---|---|---|
| Mark den Besten | 1022231 | ? | ? |
| Yann van Eijk | 1454447 | Mechanical Engineering | j.h.m.v.eijk@student.tue.nl |
| Ilse Schuckman | 1239641 | ? | ? |
| Rik Schutte | 1005841 | ? | ? |
| Roel Wijands | 1235389 | ? | ? |
Problem statement
Every minute is crucial when providing aid to someone who has an out-of-hospital cardiac arrest (OHCA). The highest survival rates are achieved when the patients receive defibrillation as fast as possible. The time it takes for an ambulance to arrive, however, is usually too long to ensure good survival odds for the patient. In order to reduce the average time between an arrest and defibrillation, automatic external defibrillators (AEDs) are placed in public areas. These AEDs are placed in cabinets that are often locked, so they are protected from acts like vandalism. The people that can access them are usually the owner(s), their employees, and citizen responders. Citizen responders are people who have followed CPR and AED courses and are registered in a national database. When an OHCA occurs, nearby citizen responders are alerted via text message to the location of the closest AED and the place of the incident. They have an app on their phone which provides them with the code that unlocks the cabinet. However, because the situation is both stressful and extremely time-sensitive, the time and effort it takes to read and input a code correctly is unwanted. The aim of this project is to remove this process and thereby reduce the average time between an arrest and defibrillation.
Objectives
The main objective is to design a new locking system for a publicly placed AED. First, anyone with the right clearance has to be able to access the AED as fast as possible, without having to do any additional actions like filling in a code. Second, the AED must be protected from incidents like vandalism and should not be accessible to anyone that is not authorized to. To meet these requirements, the design will include an app on the smartphone of someone who should have access and a way to determine the distance between this person and the AED. When someone has the app and is physically close to the AED, the cabinet should be unlocked automatically without any other user input needed.
Users
There are two main users that have to interact with the AED locker.
Firstly, the first responders to an emergency, the so-called “burgerhulpverleners”. A first responder gets a notification on his cellphone and has to, as quickly as possible, get an AED to the victim that is having an emergency. An AED should get to the victim within 6 minutes, every second counts. A first responder should therefore have quick and easy access to the AED. Quickly, because lives are at stake. Easily, because in the heat of the moment a first responder might not think logically and slowly. The first responder should not have to think about getting a door unlocked.
Secondly, the owners and maintainers of the AED and its locker. To put an AED outside is voluntary. Therefore when an AED is damaged or lost it’s a loss for the owner. An AED should be sufficiently protected from malicious users. Right now a pin code is used for this. The maintainers also would like to keep their costs and maintenance low. So it should not cost a lot extra. Additionally, these owners already have a locker that functions well. They will not want to buy a new one before the old one is written off.
Additionally, there is the owner of the app and database of all the AEDs in the Netherlands, HarstslagNu. If we improve the interaction between the AED lockers and their app. It should be easy to implement. There should also be some new entry for their database, of what type of locker it is. Especially in the beginning when not all lockers are upgraded. The app should know what kind of locking system the locker uses.
User requirements
Brain damage can occur within 6 minutes of cardiac arrest. Considering the average response time for civilian first responders is between 5.5 and 7.5 minutes, every second counts. As such, the box housing the AED should open in no less than 15 seconds to ensure quick access.
To make it easy to open the box, it should not require any extra operations from the user. So, during an emergency, opening the app should not be required to open the box.
The users also require the AED to still be in the box. This involves creating a tamper-resilient box with a robust locking mechanism that keeps unwanted people out while maintaining ease of use for the certified users. Since it is connected to an online system, this framework also requires tight security such that people cannot falsely certify themselves and gain access to the AED.
In case of a bug in the app or the system malfunctioning, an alternative way of opening the box containing the AED needs to be present as well. This is also for users that do not wish to use the app, whether that is because of a lack of technological understanding or a desire to protect all their data. As such, the new way of opening the box needs to be an addition rather than a replacement.
When there is no active emergency, the lock should not open, even when certified users of the app walk past. This excludes maintenance. This is to prevent the box from randomly opening when users walk past it unknowingly.
When the AED has been removed from the box, it should be easy for the first responder to return the AED to the box and to close and lock the box. The box should not be locked when the AED is not present in it. This prevents the box from locking itself when the AED is not contained in it. This way the owner can perform the mandatory check-up of the AED.
For the owners, it is vital that the system is easy to be installed and requires very little maintenance. High levels of upkeep would be bothersome for the owners and would also disincentivize people from getting AEDs in the first place. While an initial installation has to be done, including the necessary wiring, further upkeep must be kept at a minimum. Since the AED needs to be tested once a year, the lock should also be tested once a year at minimum.
The price of this newly developed technology should be reduced to encourage buyers to implement this device on their AEDs. The cost for upkeep should also not be increased by more than 3 percent of the existing cost. This is due to the high cost of upkeep as is, and people might get deterred from installing an AED if the costs get even higher.
State of the Art
Cho, H., Ji, J., Chen, Z., Park, H., Lee, W. (2015). Measuring a Distance between Things with Improved Accuracy. Procedia Computer Science, 52, 1083-1088. Retrieved from: https://doi.org/10.1016/j.procs.2015.05.119 || A Bluetooth based design for measuring distance between objects using Bluetooth Low-Energy (BLE). The results showed that it is possible to attain an accuracy of 90% in a radius of 1.5 meter.
Drawil, N. M., Amar, H. M., Basir, O. A. (2013). GPS Localization Accuracy Classification: A Context-Based Approach. IEEE Transactions on Intelligent Transportation Systems, 14(1), 262-273. Retrieved from: https://ieeexplore.ieee.org/document/6295661 || A study that compares the pros and cons of different GPS localization methods.
Koster, R. W. (2013). Modern BLS, dispatch and AED concepts. Best practice & research. Clinical anaesthesiology, 27(3), 327–334. Retrieved from: https://doi.org/10.1016/j.bpa.2013.07.005 || A study that presents the current strategies for OHCAs. It concludes that AEDs are of critical importance when providing aid, especially before the arrival of an ambulance.
Mair, N., Mahmoud, Q. H. (2012). A collaborative Bluetooth-based approach to localization of mobile devices. 8th International Conference on Collaborative Computing: Networking, Applications and Worksharing (CollaborateCom), 363-371. Retrieved from: https://eudl.eu/doi/10.4108/icst.collaboratecom.2012.250437 || Another design based on Bluetooth to determine position. It uses the combined Bluetooth connections of multiple devices. The results also show that, while it is slower than GPS, Bluetooth localization is faster than Wi-Fi or cellular methods.
Planning
| Weeks | Task 1 | Task 2 | Task 3 | Task 4 | Milestones (end of the week) |
|---|---|---|---|---|---|
| Week 1 | Pick subject | Collect information | Make a planning | Update the wiki-page | Subject chosen |
| Week 2 | Work out the different types of connections | Decide on the framework of the app | Electrical design of the lock | Update the wiki-page | Design plan has been made |
| Week 3 | Bill of materials | Work out final design details | Begin working on the code | Update the wiki-page | None/week of progress |
| Week 4 | Make the prototype | Continue working on the app | Make a box for demonstration | Update the wiki-page | App and box are finished |
| Week 5 | Continue making the prototype | Make test plan and test prototype | Test individual parts | Update the wiki-page | Analysis of the prototype has been done |
| Week 6 | Improving on the prototype | Make final design | Make test plan and test final design | Update the wiki-page | Final design is finished |
| Week 7 | Begin filming the presentation | Edit the film for demonstration | Update the wiki-page | Film for demonstration is finsihed | |
| Week 8 | Peer review | Last preparations for demonstration | Finalize the wiki-page | Presentation/demonstration |
Work done per week
Week 1
| Name | Total [h] | Break-down |
|---|---|---|
| Mark den Besten | 7 | 3 hours of meeting, 1 hour for the starting lecture, and 3 hours for research and writing user part |
| Yann van Eijk | 7 | 3 hours of meeting, 1 hour for the starting lecture, and 3 hours for research and writing Approach, milestones and deliverables |
| Ilse Schuckman | 8,5 | 3 hours of meeting, 1 hour for the starting lecture, and 4,5 hours for research and writing Problem statements & objectives |
| Rik Schutte | 8 | 3 hours of meeting, 1 hour for the starting lecture, and 4 hours for research and writing user requirements |
| Roel Wijnands | 7 | 3 hours of meeting, 1 hour for the starting lecture, and 3 hours for research and checking references |
Week 2
| Name | Total [h] | Break-down |
|---|---|---|
| Mark den Besten | ||
| Yann van Eijk | ||
| Ilse Schuckman | ||
| Rik Schutte | ||
| Roel Wijnands |
Week 3
| Name | Total [h] | Break-down |
|---|---|---|
| Mark den Besten | ||
| Yann van Eijk | ||
| Ilse Schuckman | ||
| Rik Schutte | ||
| Roel Wijnands |
Week 4
| Name | Total [h] | Break-down |
|---|---|---|
| Mark den Besten | ||
| Yann van Eijk | ||
| Ilse Schuckman | ||
| Rik Schutte | ||
| Roel Wijnands |
Week 5
| Name | Total [h] | Break-down |
|---|---|---|
| Mark den Besten | ||
| Yann van Eijk | ||
| Ilse Schuckman | ||
| Rik Schutte | ||
| Roel Wijnands |
Week 6
| Name | Total [h] | Break-down |
|---|---|---|
| Mark den Besten | ||
| Yann van Eijk | ||
| Ilse Schuckman | ||
| Rik Schutte | ||
| Roel Wijnands |
Week 7
| Name | Total [h] | Break-down |
|---|---|---|
| Mark den Besten | ||
| Yann van Eijk | ||
| Ilse Schuckman | ||
| Rik Schutte | ||
| Roel Wijnands |
Week 8
| Name | Total [h] | Break-down |
|---|---|---|
| Mark den Besten | ||
| Yann van Eijk | ||
| Ilse Schuckman | ||
| Rik Schutte | ||
| Roel Wijnands |