Whole House HVAC Software Architecture & Systems Modeling
Published at 11/25/2024
Overview
This project represents the complete Software Engineering specification and architecture for an intelligent, whole-house environmental monitoring and HVAC control system, developed as the capstone project for CSCI441: Software Engineering at Fort Hays State University.
While traditional thermostats measure simple dry-bulb air temperature at a single location, real human thermal comfort and building science depend heavily on psychrometrics (humidity, enthalpy, dew point, air density) and active ventilation balance (ERVs/HRVs, exhaust fans, and pressure differentials).
Rather than jumping directly to ad-hoc code, this project executed a rigorous, textbook software engineering lifecycle: from formal customer requirements and Use Case Point effort estimation to PlantUML conceptual domain modeling, system sequence diagrams, and object-oriented class specifications.
CSCI441 Final Engineering Specification (48 Pages)
Interactive Document Viewer • Fort Hays State University
1. Requirements Engineering & Effort Estimation
The specification decomposed the distributed ecosystem into six decoupled sub-problems:
- Sensor Nodes: Distributed STM32/ESP32 boards measuring multi-point environmental metrics.
- Control Nodes: Failsafe relay and hardware controllers interfacing physical HVAC equipment.
- Network & Message Bus: Lightweight, event-driven MQTT communication topology.
- Data Processor: Node.js microservice computing derived psychrometric metrics on the fly.
- Time-Series Storage: InfluxDB for long-term thermodynamic historical logging.
- User Interface: Home Assistant for dynamic web/mobile controls and Grafana for longitudinal analytics.
Use Case Point (UCP) Estimation
To forecast engineering effort before implementation, I applied formal Use Case Point analysis:
UCP = UUCP * TCF * ECF
(Where Unadjusted Use Case Points are scaled by the Technical Complexity Factor and Environmental Complexity Factor).
- Unadjusted Actor Weight (UAW): 14 points (3 Simple, 4 Average, 1 Complex actor).
- Unadjusted Use Case Weight (UUCW): 45 points across 7 formal use cases (UC-1 through UC-7).
- Technical Complexity Factor (TCF): Calculated across 13 technical factors (T1 distributed systems, T8 portability, T5 code reusability) yielding a TCF of 0.90.
- Environmental Complexity Factor (ECF): Assessed across 8 team/developer capability factors yielding 1.19.
- Final Result: 63 Use Case Points, establishing a structured baseline for scheduling, sprints, and Gantt milestones.
2. Domain Analysis & Conceptual Modeling
In Section 6 of the report, the system domain was modeled using formal UML stereotypes (Boundary, Control, and Entity) in PlantUML to establish clean architectural boundaries:
- Boundary Classes:
SystemThresholdInterface,SystemModeInterface,StatusDisplay, andDataReviewDisplayseparating presentation from internal state. - Control Classes:
SystemControllerresponsible for local threshold evaluation, equipment sequencing, and cold-start fallback states. - Entity Classes:
SensorReader,SensorController,MessageDistributor(Mosquitto),DataProcessor, andLongTermStorage(InfluxDB).
Full Traceability Matrices mapped every functional and non-functional requirement directly to its implementing domain concepts and use case workflows, ensuring zero requirement drift.
3. Interaction & Sequence Diagrams
To prevent race conditions and unhandled network partitions, interaction diagrams modeled real-time messaging across low-level buses and high-level TCP streams:
- Hardware Interconnects: Sensor breakouts communicating with STM32 microcontrollers over SPI and I2C buses.
- Event-Driven Publish/Subscribe: Microcontrollers publish periodic heartbeats and raw telemetry over Ethernet via MQTT.
- High Cohesion Delegation: Microcontrollers are responsible strictly for fast, low-overhead ADC sampling and SPI sensor reads. All computationally heavy floating-point thermodynamics math is offloaded to the Node.js Data Processor running in Docker on host hardware.
4. Object-Oriented Physics & Class Specification
The core computation engine in Node.js was specified via formal class diagrams:
PsyCalc & Value Classes
To prevent unit conversion errors (the classic “Mars Climate Orbiter” pitfall), all thermodynamic properties are wrapped in a strictly typed Value class:
- Encapsulation: Automatically maintains raw floating-point values, display rounding, unit strings (e.g., Pa vs. kPa, °F vs. °C), and Home Assistant metadata symbols.
- ASHRAE Thermodynamic Modeling: Implemented non-linear saturation vapor pressure formulations (ANSI/ASHRAE 41.6-2021) for both liquid water and solid ice regimes, calculating derived enthalpy, humidity ratio, and air density in real time upon packet arrival.
5. Architectural Outcomes & Deliverables
The project delivered a working, containerized vertical slice:
- Dockerized Microservices:
docker-composetopology packaging Eclipse Mosquitto, Node.js Data Processor, Home Assistant, and InfluxDB. - Hardware Firmware: C++ firmware on STM32 with W5500 SPI Ethernet and SD-card plain-text configuration parser.
- Verification: Integration test suite verifying that synthetic sensor packets trigger valid psychrometric transformations with median-filtering to reject sensor noise outliers.
The complete report stands as an example of structured systems architecture, demonstrating how complex multi-node IoT and control problems are modeled, estimated, and proven before deployment.