The software architecture defines the modular structure of the
BrewMaster Pro 3000βs embedded control system. The architecture
follows a layered approach with clear separation of concerns:
safety-critical functions are isolated in dedicated modules, control
algorithms are encapsulated for reusability, and user interface logic
is decoupled from core brewing operations. This modular design enables
independent testing, facilitates maintenance, and provides clear
interfaces between components.
The architecture emphasizes fail-safe design principles. The Safety
Monitor Module operates with the highest priority and can override all
other subsystems. Module dependencies are carefully managed to prevent
circular references and ensure deterministic behavior. The following
diagram shows the architectural modules and their relationships:
Module handling all user interactions including button debouncing, LED
status indicators, and display updates. Interfaces with the Brew
Controller to send user commands (strength selection, start/stop).
Module managing the brewing process state machine. States: IDLE,
HEATING, BREWING, COMPLETE, ERROR. Controls pump and valve timing
based on selected strength. Waits for temperature ready signal before
initiating brew cycle. Monitors safety status continuously.
The safety layer contains modules with the highest execution priority,
performing continuous safety monitoring and enforcing fail-safe
shutdown procedures.
Driver for PWM output generation. Controls the heating element via
variable duty cycle (0β100%) at 1 kHz switching frequency. Supports
soft-start ramp to prevent inrush current.
Driver for the SPI bus peripheral. Provides communication with the
front-panel display controller (OLED) for status and menu rendering.
Operates at 4 MHz with DMA for frame-buffer transfers.
The sequence diagrams below show how the architectural components
interact at runtime. Participants map directly to the components
defined in the Static View.
The diagrams are generated by needsequence, which traverses the startup_calls
/ shutdown_calls links defined on each component need. Each seq_msg (SEQSTART_01)
need in the chain represents one message; odd hops are participants,
even hops are messages.
On power-on the system initialises hardware, validates initial sensor
readings, then brings all control modules online in dependency order
before signalling readiness to the user.
The sequence message needs (SEQSTART_01βSEQSTART_10) are
defined below. COMP_UI_MODULE is the starting participant.
If the Safety Monitor detects an over-temperature condition it issues
an EMERGENCY_STOP command on INTF_SAFETY_CMD to all controlled
subsystems. All modules must respond within 100 ms.
The sequence message needs (SEQSHTDWN_01βSEQSHTDWN_06) are
defined below. COMP_ADC_DRV is the starting participant (it is the
source of the over-temperature sensor reading).