PRE2020 3 Group4: Difference between revisions

From Control Systems Technology Group
Jump to navigation Jump to search
Line 55: Line 55:
== Planning ==
== Planning ==


{| class="wikitable"
{| border=1 style="border-collapse: collapse; width: 80%; height: 14em;"
! Weeks
! Weeks
! Task 1
! Task 1

Revision as of 17:48, 12 February 2021

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

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

References