Architecture Design and Evaluation 3-4

Overview of the Class (Architecture Design and Evaluation, 3rd/4th Session)

This lecture focuses on the Architecture Design Exercise (ADD) using a smart IoT healthcare case study. The goal is to help students understand:

• ADD-based architecture design
• How to evaluate and iterate an architecture

---

Case Study: IoT Healthcare Stress Estimation Using “Jeans” Sensors

Scenario

• A healthcare system uses IoT wearable sensors (“JeansMEMS”) to generate body activity and biometric-like signals.
• Goal: estimate the user’s stress level from sensor data and (within course scope) show stress levels / update displayed estimates.

---

Sensor / Product Capabilities (as described in the subtitles)

The wearable (JeansMEMS) can generate:

• Gait/gesture-related blink data
  • blink direction
  • blink count
  • blink speed
  • blink strings
• Body activity data
• Posture deviations
• Head/face or walking detection
• Accelerations
• Sensory-noise detections
• Battery level / device status

Stress estimation uses known relationships between heart rate and stress level. While logic-based stress estimation models from other teams/prior work exist (based on heart-rate sensors), the course aims to estimate stress using the wearable’s other signals as well.

---

Core System Functionality in Scope

The system has two main use cases (others are explicitly out of scope for this exercise):

1. Initiate measurements and recommend recovery actions
   • Mentioned, but later excluded from detailed scope in this class.
2. Show stress levels and update the stress-level estimation models
   • Treated as in-scope.
   • The model update is treated as a black-box and is not modifiable at runtime.

---

User Interaction Model

• Users can:
  • start measurements
  • request to show stress levels
• The exercise limits attention to the in-scope use cases.
• Recovery recommendation logic and other flows are not developed in this class.

---

Machine Learning Approach & “Black-Box” Constraint

• The system uses machine learning-based estimation models to map wearable sensor data → stress level.
• During training, the model learns from:
  • heart-rate-based stress labels (from training-time inference/ground truth)
  • wearable features such as body activity and gaze/blink-related data

Architectural Constraint

• The stress estimation model is treated as a black-box.
• Runtime model update is out of scope (no modifying/reconfiguring the ML model while running).

---

Key Architecture Drivers / Constraints (Two Iterations)

Iteration 1: Core Functionality

This iteration emphasizes two functional drivers:

• Start measurement
• Display / update stress levels

The stress estimation ML model is treated as given and not modifiable internally.

---

Iteration 2: Modifiability Requirements (QR Series)

The system must support evolution in two directions:

• QR1: add new user types / new sensor device types
• QR2: add new data processing methods

Challenge

• If one data component changes, the changes should not cascade unnecessarily across the entire system.

Additional Consideration

• Sensor connectivity may be unstable (Bluetooth/cellular/Wi‑Fi).
• The architecture must tolerate temporary wireless disconnects while still handling already-received data correctly.

---

Architectural Reference: Microsoft Azure IoT Reference Architecture

The lecture proposes using the Microsoft Azure IoT reference architecture as a starting point for fast iterations.

Layered Subdivision

1. Sensor / data ingestion layer
   • Generates sensor data
   • Includes external wearable + smartphone/cloud connectivity
2. Processing / streaming layer
   • Where stress estimation happens
3. Action layer
   • Would produce business-level actions (e.g., recovery recommendations)
   • Explicitly noted as out of scope for this session

Mapping to the Healthcare System

• Wearable + smartphone provide a path to the cloud/internet
• Inside the architecture:
  • a data collector
  • a streaming data processing component that performs ML-based stress inference
• A web UI displays current stress levels

---

Proposed Architecture Components (As Described)

JeansMEMS / Smartphone Integration

• JeansMEMS → smartphone via Bluetooth
• Smartphone → cloud/internet via connectivity

Inside the System

• ML stress estimator
  • treated as black-box (given model)
• Data processing wrapper/component
  • receives sensor data
  • calls the black-box estimator
  • outputs the current stress level
• Healthcare web interface
  • displays current stress estimates

First-Iteration End-to-End Goal

• Satisfy the two functional use cases while keeping modifiability in mind for later.

---

Second Iteration Solution Strategy: Publish/Subscribe (Pub-Sub) for Modifiability

To reduce tight coupling and support adding new elements, the class introduces the Publish/Subscribe (pub-sub) architecture style.

How Pub-Sub Works

• Subscribers register interest (topics) with brokers
• Publishers send data with a topic identifier
• Brokers forward messages only to interested subscribers

Why This Supports Modifiability

• Loose coupling: publishers don’t need to know which subscribers exist
• Changes in one part (e.g., publisher side) do not necessarily propagate to subscribers
• Easier addition of new publishers/subscribers or processing modules with less disruption

Exercise Directive

Students are asked to:

• apply pub-sub to their models to address QR1/QR2
• update end-to-end interactions and responsibilities among components after refining design models

---

In-Class Deliverables / Exercises

Exercise 1 (2nd Iteration)

• Apply publish/subscribe to satisfy modifiability quality drivers (QR1 & QR2)
• Update:
  • roles/components in current design models
  • interactions/responsibilities of elements
• Verify that QR1/QR2 are actually satisfied after applying pub-sub

Exercise 2 (3rd Iteration)

After refining the second iteration, students produce updated design models for the third iteration.

The third iteration focuses on:

• Architecture quality attributes
  • QR series includes availability
  • FR series includes constraints (availability and constraints are mentioned)
• Add 1–2 additional quality attributes perspectives (examples suggested: performance, modifiability, security)
• Define new scenarios for evaluation

Emphasis: the third iteration is less about choosing the same reference architecture and more about improving the design for new scenarios.

---

Main Speakers / Sources (From the Subtitles)

• Course instructor / lecturer (not named in the subtitles)
• Microsoft Azure IoT Reference Architecture (named external source)
• JeansMEMS / Jeans (Japanese company wearable product; named external device/data source)