Access control to UFSC’s Refectory (RU)

http://noticias.ufsc.br/2017/05/modernizacao-do-acesso-ao-restaurante-universitario/

SystemComponents-v1_0

System description and requirements

  • Considering a turnstile controlled by a control board (e.g. Atlys board), users can employ their UFSC cards or their smart phones to have access to the refectory during lunch and dinner opening times.
  • To access the refectory, the users must have sufficient credit in their accounts (smart phone or UFSC card).
  • The users can top up their accounts in the help desk next door to the refectory, on-line through their smart phone app, or using the refectory’s website facility. The credits purchase will only be completed when an acknowledge message is received from the server.
  • The credit information is registered also on a web server (host computer) through a software implemented in C++ using an SQL database. This information is synchronized from time to time with the smart phone and with the UFSC card. However, only the credits available in the smart phone, or in the UFSC card can be considered as true credits to be used for payment. The information available on the web server may be updated, and in the reports it is important to add a warning as, for instance: “last synch with smart phone took place at …”.
  • The web server allows the users to see their transactions history using their smart phones app, or any Internet browser.
  • The amount of people in the refectory at any time is also available on the web server.
  • At the refectory’s entrance, users can employ their UFSC cards or their smart phone app to unlock the turnstile. The user’s ID, date, hour, and the debited amount are stored in the control board and, in case there is enough credit, the turnstile is unlocked. This information is also stored in the control board.
  • At the refectory’s exit, the users must use again the smart phone or the UFSC card, in order to keep the control board data structure updated.
  • The system implemented on the control board has to be designed for on-line and off-line operation modes. Both, the smart phone and the UFSC card, hold the user’s credit information. The control board subtracts the refectory’s entrance fee, and stores this information back to the UFSC card. If the smart phone app has been used, in this case the control board does not need to subtract the refectory’s fee, as it is done by the app itself, before sending the unlock command. It is important to notice that there are two separate credits (smart phone and UFSC card, and the user can employ them in separate.
  • The control board software has to:
    1. receive a user’s demand (from a smart phone or UFSC card);
    2. store all received information in a local data structure;
    3. check if an unlock command has been received (user has sufficient credit);
    4. unlock the turnstile (in case an unlock command has been received);
    5. synchronize with the host computer from time to time.
  • Before implementing the fingerprint reading component, when the app is started it may just ask for the user’s registration number (login, matricula). This information can be used by the app to query the server (host computer) for updated data (e.g. credits, transactions history, …).
  • The smart phone app will send the unlock signal to the control board only if:
    1. The finger print read belongs to the smart phone’s owner;
    2. The user has enough credit;
  • The smart phone can be connected to the control board and to the host computer using an Internet protocol.
  • The control board is embedded in the turnstile, and it is connected using a local interface such as RS-232C.
  • The connection between the control board and the host computer can also be done through an Internet protocol.
  • Smart phone development environment requirements:
    1. The app should be developed using Qt for android or IOS.
    2. There is a tutorial on Qt’s website, which can be used to understand the development flow. This is one of the tasks to be concluded by the first deadline on May 9th.
    3. The app should be developed using the IDE Qt Creator.
    4. The app should be developed using the QtWidgets mode, instead of QtQuick. In the QtWidgets mode all the programming is done is C++. In the QtQuick mode, the programming is in QML and JavaScript.

Smart phone (app) functionalities:

  • Total of people in the refectory (real time information);
  • Top up the refectory account;
  • Get access to the refectory (during opening hours only);
  • Use of finger print access to identify the smart phone’s owner (person who bought the refectory credits);

Control board functionalities:

  • Store users using data structures (e.g. tree, queue, …);
  • Unlock the turnstile for authorized users;
  • Send data to host computer;

Host computer functionalities:

  • SQL database of users and purchases;
  • Web reports;
  • The software can be implemented in C++, or using other languages as Python.

Development methodology

  • Each team should be between 2 and 4 members;
  • A team should provide a full solution for the problem;
  • The teams must organize themselves in order to distributed tasks and responsibilities among their members (e.g. project management; host computer software development; smart phone software development; Leon3 software development; test and validation; …).
  • Each team should have a slack account, which will be used for all project’s discussions and decisions.
  • The teams should use github for their source code version control and sharing.
  • The project’s documentation should be available on-line, using google docs tools.
  • All members of a team must have the full knowledge of all implemented modules, even if they were responsible for just one of the modules.
  • The teams should respect the deadlines. There are 5 delivery dates, one each two weeks, according to the time table presented next.

Schedule

Deadline Delivery
09/05
  • Product tree
  • Work breakdown structure (WBS)
  • Requirements
  • Detailed schedule
  • Use case diagram (preliminary)
  • Classes diagram (preliminary)
  • Working example of app written in C++ for smart phones
06/06
  • Product tree (revision)
  • Work breakdown structure (WBS) (revision)
  • Detailed schedule (revision
  • Use case diagram (revision)
  • Classes diagram (revision)
  • Test plan
  • User interface design (app and host computer)
  • Database design and implementation in SQL/C++
  • Data structure definition and implementation targeting Leon3
  • Definition and working example of communications link between all modules
20/06
  • Smart phone app working version
  • Leon3 software working version
  • Host computer software working version
04/07
  • Use case diagram
  • Classes diagram
  • Sequence diagram
  • Test plan execution (according to the requirements)
  • Performance analysis
  • Source code (documented)
  • User manual
  • Full working system demonstration

 

Students’ teams & solutions: