Case Study: Building an IoT-Enabled Remote Coffee Service Kiosk

One of the common challenges that medium-sized coffee chain Brew & Bean Co. encountered during its journey is how to promote its brand at locations with a lot of foot traffic and limited space, such as lobbies of office buildings, corridors of universities, and waiting rooms in hospitals, without incurring many costs of the full-service store.

Their traditional vending machines offered poor quality coffee and a subpar brand experience. NovaTech Solutions was engaged to design, develop, and deploy "BeanLink," a premium, self-service espresso kiosk powered by a comprehensive Internet of Things (IoT) architecture.

This case study details the entire lifecycle of the BeanLink project, from initial requirements gathering and hardware selection to firmware development, cloud integration, and the operational insights gained post-deployment.

As a result, there was a decrease in operational downtime by 40%, rise in average transaction value by 25% from normal vending and installation of 150 vending kiosks across three states within a period of six months.

Brew & Bean Co. had a simple business model involving expert baristas and a cozy café environment. Their plans for expansion, however, called for a solution that could:

• Maintain Product Quality: Deliver espresso-based drinks (lattes, cappuccinos, Americanos) that met their brand standards, using fresh milk and beans.
• Operate Autonomously: Function without a full-time on-site attendant.
• Provide Real-time Insights: Offer live data on sales, inventory, machine health, and consumer preferences.
• Ensure Product Quality: Serve espresso-based beverages (lattes, cappuccinos, Americanos) that are consistent with their brand by utilizing fresh milk and beans.
• Be Remotely Manageable: Allow for over-the-air (OTA) updates, remote diagnostics, and dynamic pricing or menu changes.

Instead of conventional vending machines, Brew & Bean chose to develop their own equipment. These machines were considered "black boxes" since they offered little if any data, were not reliable, and had poor usability.

The architecture was designed around a layered IoT framework, ensuring modularity and scalability.

3.1. The Edge Layer (The Kiosk Hardware)

The physical kiosk included the unique component that contains the equipment for coffee manufacturing and the computing systems.

Primary Controller:

A robust industrial-grade SBC, specifically Raspberry Pi Compute Module 4 (CM4) on a custom carrier board. It suits perfectly because of the perfect combination of power efficiency, processing powers as well as GPIO utilities for interfacing with the necessary sensors and a huge community that can support this SBC in various issues.

Microcontroller Unit (MCU):

The ESP32 microcontroller was employed as a supporting controller responsible for real-time and low-level control of the electromechanical elements of the machine (e.g. pumps, valves, and grinders).

This separation of duties is essential because while the MCU handles the timing of the brewing process at the millisecond level, the single board computer controls the application, user interface, and network communication.

Sensor Suite:

A dense array of sensors provided the system's "senses":

• Temperature & Humidity: DS18B20 waterproof probes in the boiler and milk fridge, and a DHT22 for ambient conditions.
• Pressure: Solid-state pressure transducers to monitor water pump pressure for optimal espresso extraction.
• Level Sensors: Ultrasonic sensors in the water tank, coffee bean hopper, and waste bin to track inventory and waste levels.
• Flow Meters: Hall-effect flow sensors to precisely measure water volume for each recipe.
• Power Monitoring: A dedicated energy monitoring chip (e.g., INA219) to track overall and per-component power draw, enabling predictive failure analysis.
• Door & Tamper Sensors: Magnetic reed switches on all access panels for security.

User Interface:

An intuitive ordering experience, similar to that of a smartphone, was provided by a 24-inch projected capacitive touchscreen. An LCD of smaller size provided the payment module with transaction feedback.

Connectivity:

The first WAN link was a 4G/LTE cellular modem that allowed the kiosk to operate from any standard power outlet without relying on the sometimes unreliable Wi-Fi connection of the host venue. There is also an Ethernet port on the unit for wired installations.

3.2. The Network Layer (Communication)

Dependable and safe communication was crucial. The system employed two different protocols:

Internal (Machine-to-machine):

The SBC communicated with the ESP32 via a fast UART serial bus utilizing a simple custom-built binary protocol. This resulted in low latency for the commands that required quick response.

External (Kiosk-to-cloud):

The SBC communicated with the cloud platform only through MQTT (Message Queuing Telemetry Transport) using TLS 1.2. MQTT was selected for its simplicity and publishing/subscribing approach that is very useful when the connection is not constant and bandwidth usage is effective. Each kiosk was given a unique client ID and X.509 certificate to authenticate itself.

Data Channels:

• Telemetry: Every 5 seconds the sensor information was published in the kiosks/{id}/telemetry channel.
• Events: The important events (for example, drink_dispensed, error_pump_failure, low_milk_warning) were published in kiosks/{id}/events with the high QoS level.
• Commands: The commands (for example, start_cleaning_cycle, update_menu, set_price) were sent from the cloud to kiosks/{id}/commands. The kiosk subscribed to this channel and sent an acknowledgment message after execution.

3.3. The Cloud Layer (The Backend Platform)

The system's brain was the cloud, built on Amazon Web Services (AWS) for scalability and managed services.

IoT Core:

The MQTT broker managed devices' registry, authentication, and message routing.

Device Shadow:

The Device Shadow of AWS IoT Core kept a virtual version of kiosks' state. This means that operators could check the desired and reported state of their machines (e.g., "Desired Mode: CLEANING" and "Reported Mode: IDLE").

Data Storage:

Telemetry data was collected in Amazon Timestream, the time series database, for the processing of historical trends in performance analysis. Events data was transferred to Amazon DynamoDB for getting transactional lookups quickly (retrieving the details of a particular transaction).

Business Logic:

The backend logic was based on a set of serverless functions (AWS Lambda), which were activated by either IoT Core triggers or API calls. Thus, when a transaction_complete event arrived, a Lambda function would read the sales database in Amazon RDS (PostgreSQL).

Operator Dashboard:

The Brew & Bean operations team has benefitted from utilizing React software to get a visual representation of the kiosks. The software provided information on operational conditions, sales data for the day, inventory, as well as alerts. It utilized the RESTful API (Amazon API Gateway) to connect with the cloud.

The project followed an iterative, Agile methodology.

Phase 1: Proof of Concept

The first phase concerned the de-risking of the project. A "Franken-kiosk" was designed on a lab bench, using commercial components.

The intention was to demonstrate the basic communication and control loop: Cloud Command -> SBC -> MCU -> Actuator -> Sensor -> MCU -> SBC -> Cloud Telemetry. This phase confirmed the appropriateness of the hardware choices and MQTT architecture.

Phase 2: Firmware & Software Development

Parallel workstreams commenced:

Firmware (C++ on ESP32):

Focused on developing the core brewing logic. State machines were written for each drink recipe, managing grinders, pumps, and valves with precise timing loops. A robust error-handling system was implemented to catch anomalies (e.g., a pump drawing too much current, indicating a blockage) and halt operations safely.

Edge Application (Python on SBC):

The main application was developed using Python and the Qt framework for the UI. It managed the user interface flow, communicated with the cloud via the AWS IoT SDK, and sent high-level commands to the ESP32.

Cloud Backend:

Terraform (Infrastructure as Code) was used to set up the cloud infrastructure. The functional Lambda functions, API endpoints, and database schema were created and tested.

UI/UX Design:

At the same time, designers were developing the touchscreen interface with focus on speed and clarity of design. The prominent features were pleasing images of food, and the ordering process taking three taps.

Phase 3: Integration and Rigorous Testing

This was the most challenging phase. The full system was integrated into a pre-production kiosk.

Unit Testing:

Each software module was tested in isolation.

Integration Testing:

The interplay between the SBC, MCU, and cloud was tested under various conditions.

System Testing:

End-to-end tests were run, simulating hundreds of real-world transactions, including different payment methods (credit card, mobile wallet), drink customizations, and error scenarios.

Fault Injection Testing:

Engineers intentionally induced failures in the testing process by disconnecting sensors, blocking granulators, and creating network issues, so as to measure the resilience and error-reporting performance of the setup.

Soak Testing:

The kiosk was operated for a continuous period of 72 hours in order to identify various other concerns including memory leaks, heating issues, and stability problems with devices in the long run.

Phase 4: Pilot Deployment and Iteration (Month 8)

Ten kiosks were deployed to a mix of corporate offices and a university campus. This pilot phase was crucial for gathering real-world feedback. Key findings included:

• The temperature detection device of the milk cooling system was inferior; it was substituted with a higher quality sensor.
• The users noted the touchscreen controls were very small; hence, the user interface was modified for better ergonomics.
• Using remote diagnostics, it was discovered that a specific pump was malfunctioning; therefore, the manufacturer was changed.

Phase 5: Mass Production and Rollout (Month 9)

With lessons learned from the pilot, the manufacturing process was finalized.

Hardening was made to the software image, with the creation of a streamlined provisioning process.

On the first activation, each kiosk would automatically register within AWS IoT Core, then request the needed certificates and finally download its initial configuration, which implements a zero-touch provisioning model allowing for swift and secure deployment performed by non-technical personnel operating in the field.

Challenge 1: Real-time Performance vs. Cost

If all processing were carried out in the cloud, it would cause too much latency in the brewing process.

Solution:

The distributed architecture was designed so that the local SBC and MCU solve all the real-time problems, with the cloud being responsible for management, data aggregation, and issuing non-real-time commands.

Challenge 2: Network Reliability

Cellular networks in basements or metal-framed buildings could be intermittent.

Solution:

The edge application was designed to operate fully offline. It would queue telemetry and transaction data locally and sync with the cloud upon reconnection. The Device Shadow ensured that any missed commands were delivered once the connection was restored.

Challenge 3: Secure Payment Processing

Integrating our custom software with a payment terminal was a huge challenge in terms of PCI-DSS (Payment Card Industry Data Security Standard).

Our Solution:

We made use of a reliable and secure payment terminal that was capable of processing card data internally while our system only received a one-time token indicating whether or not the transactions were authorized, therefore protecting sensitive payment card data from coming into contact with our system.

The deployment of the BeanLink system yielded significant, quantifiable results for Brew & Bean Co.:

Operational Efficiency:

Predicted maintenance helped reduce downtime by 40%, as the system was capable of identifying a likely failure up to 48 hours in advance by tracking the pump's electric current intensity, so that during the scheduled maintenance the technician will be able to change it in advance.

Inventory Management:

Food wastage due to spoilage is decreased by 60%. As the system is capable of forecasting milk consumption based on previous data on the consumption and demand in a certain location, it is able to warn the customer if there is a chance of running out of the product before it happens instead of serving bad milk.

Increased Revenue:

Average transaction value increased by 25% over traditional vending. The intuitive UI and high-quality product encouraged users to add extras (e.g., an extra shot, flavor syrup) more frequently. Dynamic pricing, managed from the central dashboard, allowed for time-of-day promotions.

Data-Driven Decision-Making:

The operations team was able to glean from the analyzed data that oat milk is the leading alternative milk in college locations but is practically nonexistent in hospital locations. This enabled them to adjust the menus to suit each individual location thus ensuring inventory optimization and waste reduction.

Scaling:

The zero-touch provisioning and centralized management approach meant that scaling from 10 kiosks to 150 kiosks required zero workforce increase in the software development team.

The BeanLink project demonstrates the transformative power of a well-architected IoT solution in the traditional retail space.

Thanks to the layered design, effective communication, and dedication to data-driven processes, NovaTech Solutions achieved the enterprise of creating a system that goes beyond just a "smart vending machine." The team realized a true edge computing device that operates on its own, communicates independently, and keeps on learning over time.

The groundwork has been done, and the development process is underway. Currently, the team is working on implementing computer vision to allow automatic customer identification and provide personalized ordering solutions without any cashiers being involved.

The data pipeline is also being prepared for advanced machine learning models to predict demand at a hyper-local level and further optimize the entire supply chain, from coffee bean roasting to on-site delivery. The BeanLink system is not just a product; it is a continuously evolving platform.