Checklist

1. Assessment of the responsiveness of the application in the context of the task / environment.

All critical parts of the tea preparation are handled using timers and threads to insure real-time performance.

2. Overall latency permitted between physical event and output (control output or display of data).

Almost all components are critical and require real-time operation. The only possibility for latency is the sleep function used to measure the tea brew time. Sleep was used because the expected duration would cause the timer function to overflow. Also, the tea brew time is in the order of minutes and a latency of even seconds does not affect the system.

3. What deadlines need to be met?

The most important deadlines for the project are:

• Logo design and social network profile set-up by the end of January, to allow for the project to gain enough traction in time for the final presentation.
• Hardware design completed and tested with test code by the end of February, to allow sufficient time for real-time implementation and integration between hardware, software, and mechanical.
• Enclosure specification submitted for manufacturing beginning of March, to allow enough time for the UoG mechanical workshop to manufacture everything, and to allow integration with the hardware and testing.
• Test code done by the end of February, to allow initial testing and debugging.
• GUI concept finalised by mid-February, to allow sufficient time for Qt development.

More detailed information can be found in the Gantt chart here.

4. What is the sampling rate?

The water temperature sensor is sampled at 0.5Hz.

5. Buffering of data: how many samples?

N/A.

6. How does the buffering impact on the realtime performance and how much latency is introduced?

N/A.

7. Post-processing of data and how that introduces latencies / processor load?

There is no post-processing of data.

8. How many channels?

None.

9. What bus protocol should be used (I2C, SPI, ...) and why?

1-Wire for DS18B20 temperature sensor.

10. Low level implementation: kernel or userspace and why?

Using userspace for the project was done because the implementation of C++ would be easier for all team members to understand the code.

11. Data flow from hardware to GUI to output with data formats, latency, processing and conversions.

The only sections which could introduce latency is the real-time display of the water temperature and the filling in the waiting screen. They are only for user feedback, however, and are not critical.

12. How many threads are needed and/or how can the load be distributed to allow a responsive application?

One thread is needed to dispense tea leaves to utilise the waiting time for water to be boiled in main thread.

13. How to implement the GUI? Permitted refresh rate and latency resulted from it.

Due to the lack of latency, it was deemed that no refresh rate is needed.

14. Structure of the software in classes, associated unit tests to turn it into reliable software

This is described in the Software Wiki page.

15. Team structure: which roles in a team of 3 and how equal contributions are guaranteed?

Please refer to the README in the Code section here. The roles were split according to the abilities and interests of the team members, but were kept flexible should one team member decide to contribute to another part of the project. The important thing which was followed was whether the Gantt chart deadlines were achieved.

16. How much time is allocated to hard, software and debugging and how is this interleaved?

The development of the hardware was prioritised right after the overall project concept was finalised. While the first hardware module was being designed, the member responsible for software used this time to familiarise themselves with the RPI environment. After this, software and hardware were developed and tested in parallel until all sub-modules were designed, after which point the focus was shifted to integrating all functions to fit the application, and to developing a GUI.

17. Which version control software is used? How are releases / milestones done and numbered?

The version controlled software for the project is GitHub.

18. What is the release strategy / publication / publicity? How is that measured and deemed to be successful?

Updates on the project were made public since after the project kick-off. Weekly posts regarding the current state and future tasks were used to generate an awareness for the product, and a final release event was scheduled for early April, although this was cancelled due to the Covid-19 outbreak. When the project is completed successfully, videos showcasing the product's capabilities will be made public on all social platform.

The Facebook posts managed to reach a wide audience, however the disruption to the project hindered its presentation. Similarly, although the Twitter posts got some retweets, more work needs to be done in the future when the project is completed.

19. Would users of social media or generally users would like it and share it?

Judging from the reactions to the posts and tweets, there is potential for the product to arouse interest and to attract users.

20. Measurement of success of the application in the context of the problem given and evaluation of it.

The product solves a problem in that it caters to a rather unrepresented demographic - the tea drinker, and it automates the most crucial parts of the process. Although our market research indicates that the majority of the UK population drinks tea regularly, there is no commercial product which offers such a level of automation and guaranteed consistency in tea preparation in a public setting.

Furthermore, the product can be used to further popularise tea drinking in various environments and to illustrate the health benefits of tea drinking, without having spend to much time on preparation.

21. Originality of the project, impact, usefulness and able to demonstrate realtime performance.

The project is original as no other product offers such level of automation of the tea process.

Furthermore, the project offers a good opportunity to showcase a real-time programming approach as all steps - water heating, leaf and water dispensing, and infusion, require real-time performance which guarantees the accuracy of the process.