Bern RTOS: Espresso Machine Requirements
Authors
- Stefan Lüthi
License
This work is licensed under a Creative Commons Attribution 4.0 International License.
Introduction
Purpose
This document specifies and tracks the status of the requirements for the espresso machine demonstrator hard- and firmware.
Intended Audience
This document provides students and other interested parties a set of features that are implemented in hardware and in the Rust demo firmware. There will be only one hardware prototype and no further revisions are planned.
Product Scope
The espresso machine is a demonstration application of the Bern RTOS project. The emphasis is on showing off real-time features on a real-world problem.
Acronyms
| RTD | Resistance Temperature Detector |
Overall Description
Product Perspective
A thermostat based two-point controller is even today frequently used in espresso machine designs. This controller type lacks accuracy and repeatability when pulling espresso shots. In this demonstration application the aim is first to upgrade an existing espresso machine by replacing its electronics and electric components, and secondly to implement a control and monitor firmware using the Bern RTOS. The application must be easy to understand in order to showcase the real-time capabilities of the RTOS.
The components of the demo application are shown in the figure below.
Espresso machine firmware components
The aim is to use preexisting libraries for drivers, network stack and graphics to reduce development effort. A library written in C can be used, if it provides a more functionality than its Rust alternative, or if there is no Rust library.
For this demonstration application a Racilio Silvia single-boiler espresso machine will be used. The figure below shows the fluid components after modification providing an overview of the actuators and sensors.
Espresso machine fluid diagram (overpressure valve omitted)
The Rancilio Silvia controls the brewing temperature based on thermostats without any electronics. The following sensors will be added for the electronic controller:
- Temperature sensors
- Pressure sensor
- Flow meter
Product Functions
The espresso machine provides features to:
- Brew coffee
- Display brewing profile (temperature, pressure, time)
- Log machine state to a server over a local network
User Personas
-
Coffee Drinker: The goal of a coffee drinker is to get a good and easy to make coffee in the morning. They expect simple control elements and feedback of the brew.
-
Manufacturer: Companies producing espresso machines want feedback on how their machines are used to improve on future products.
-
Student: Students can use the espresso machine hardware to develop their own firmware. They expect a thorough documentation and enough flexibility to implement their own project ideas.
Operating Environment
The first iteration of the hardware is based on an STM32F7 microcontroller board from the Bern University of Applied Sciences. The espresso machine will be used solely in the lab and exhibitions.
User Documentation
The espresso machine documentation consists of:
- Hardware and firmware documentation with details about the hardware structure and use of the Bern RTOS.
- Hardware design documents
Assumptions and Dependencies
Sensors
It is assumed that the following sensor are accurately enough for a consistent brew:
- RTD temperature sensor on the outside of the boiler (perhaps a temperature can be placed in the brew chamber)
- Flow meter can detect small steps in water flow and is not affected by jitter created by the vibration pump
- Pressure sensor can be placed at brew head to measure the relevant water pressure
Bern RTOS
The Bern RTOS must provide all the necessary features to develop this real-time application and should not introduce bugs to the system.
HAL
This demonstration is focused on the application of Bern RTOS. It is assumed that the Rust HAL already include most of the hardware support used in this project.
Requirements
Functional Requirements
The functional requirements specify what the espresso machine is supposed to do. Each requirement has a user story and a priority. The stories state what the user expects in the end product, that implies hardware capabilities and feature set of the Rust firmware.
Requirements
| ID | Title | User Story | Priority | Status |
|---|---|---|---|---|
| F001 | Repeatability | As a coffee drinker, I want to pull espresso shots with repeatable temperature profiles. | high | done |
| F002 | Temperature | As a coffee drinker, I want to set the target water temperature, so that I can adjust the machine to my coffee beans. | high | done |
| F003 | Steam | As a coffee drinker, I want to put the machine in steam mode, so that I can steam milk. | medium | planned |
| F004 | Pressure | As a coffee drinker, I want to adjust the brew pressure, so that I can experiment with novel brewing techniques. | low | planned |
| F005 | Brew Information | As a coffee drinker, I want to know water temperature and brew pressure, so that I know if I need to adjust my preparation method. | high | done |
| F006 | Temperature Accuracy | As a manufacturer, I want to temperature controller to achieve +/- 3°C accuracy (without water flow), so that the machine delivers repeatable results. | medium | done |
| F007 | User Analytics | As a manufacturer, I want to log machine usage and state to a server, so that I can improve the espresso machine design. | medium | done |
| F008 | Eco Mode | As a manufacturer, I want the machine to turn off when its not used for more than 20 min. | medium | planned |
| F009 | Debug Information | As a student, I want the machine to provide as much internal information as possible, so that I can debug my application easily. | low | done |
Questions
| Question | Answer |
|---|
Out of Scope
Non-functional Requirements
The non-functional requirements specify how the espresso machine is supposed to be. These quality attribute apply to all components of the system. They have no definition of done, as non-functional requirements apply for every release.
The priority refers to the importance for the project that the requirement is met. All non-functional requirements should be met, but if two are contradicting the one with higher priority will be preferred.
Requirements
| ID | Title | User Story | Priority |
|---|---|---|---|
| N001 | Rancilio Silvia | As a manufacturer, I want the control electronics to use a Racilio Silvia espresso machine as base, because its interiors are well documented and spare parts are available. | high |
| N002 | Stability | As a manufacturer, I want the machine to run stable with less than 1 system fault per 80h operating hours. | high |
| N003 | Microcontroller | As a student, I want the machine to be compatible with the STM32F7 module form the Bern University of Applied Sciences, so that I can develop an RTOS based application for the machine. | high |
| N004 | Microprocessor | As a student, I want the machine to be compatible with the STM32MP1 module from the Bern University of Applied Sciences, so that I can develop an embedded linux application for the machine. | low |
| N005 | Switches | As a student, I want the machine to provide easy to use UI elements (e.g. push buttons), to that I can program an application without the use of complex software. | medium |
| N006 | Documentation | As a student, I want access to all hardware and software design documents, so that I can develop my own application for the machine | high |
Questions
| Question | Answer |
|---|---|
| What is a system fault? | In a system fault the machine does not behave as required. The fault can only be resolved with a system reset (power cycle). |
Out of Scope
- Embedded Linux/Android will not be part of the project, but the hardware will be compatible with a microprocessor module.
Changelog
Requirement changes of the espresso machine demonstrator will be tracked in this document. See Commits in GitLab for details.
v1.1 (2022-08-03)
New Requirements
- None
Modifications
- Update requirement states
v1.0 (2021-10-27)
New Requirements
- All requirements
Modifications
- None