Skip to content

archive case study

ChemView

An industrial HMI and digital twin prototype for chemical process monitoring, interlocks, and operator control.

Role fit

Industrial SystemsUX

Quick technical review

The case study in four points.

Full methodology

Problem

Operator consoles are harder to review when telemetry, controls, logs, and safety logic are split across separate views.

Architecture

All plant state lives in a server-side engine (Next.js route handlers): physics on a one-second tick, safety interlocks, deterministic Modbus frames from a documented register map, rule alarms and an audit trail. The browser only renders snapshots…

Read complete note

All plant state lives in a server-side engine (Next.js route handlers): physics on a one-second tick, safety interlocks, deterministic Modbus frames from a documented register map, rule alarms and an audit trail. The browser only renders snapshots streamed over Server-Sent Events and sends commands, so a refresh or a second tab shows the same plant. Telemetry, alerts and the audit trail persist to Firestore when configured, otherwise to a bounded in-memory store, and are served as history and CSV export.

Results

Moves the simulation, interlocks and alarms from the browser to a server engine that streams snapshots over Server-Sent Events.

Verification path

Start with the README screenshot and docs/architecture.md before reviewing implementation details.

Summaries reuse the project’s documented evidence. Review the complete case study for evaluation boundaries.

Evidence-led visual review

Explore the actual work.

Concept art, dated captures and repository figures are identified separately.

ChemView Process Simulator conceptual editorial research illustration

Portfolio illustration

Original portfolio illustration. Diagrams are conceptual; verified methods and results appear in the linked case study. This is not an application screenshot.

Project proof

Verified external evidence

Last verified 2026-10-07

Problem and approach

Problem

Operator consoles are harder to review when telemetry, controls, logs, and safety logic are split across separate views.

Architecture

All plant state lives in a server-side engine (Next.js route handlers): physics on a one-second tick, safety interlocks, deterministic Modbus frames from a documented register map, rule alarms and an audit trail. The browser only renders snapshots streamed over Server-Sent Events and sends commands, so a refresh or a second tab shows the same plant. Telemetry, alerts and the audit trail persist to Firestore when configured, otherwise to a bounded in-memory store, and are served as history and CSV export.

Workflow logic

Interlocks are enforced on the server: the mixer cannot start with the discharge valve open, the valve cannot move while the rotor spins, and E-STOP always wins and is never rate limited. A denied command returns the operator-facing reason. Safety alarms are deterministic and raised on the tick the condition appears; optional Gemini commentary (Genkit) is layered on top near a limit, rate limited, time-boxed to 8 seconds, schema-validated and silently dropped on failure, so it never gates a safety decision.

Why it matters

ChemView stays in the archive as proof that the portfolio also includes stateful operator systems, not only analytics pages, and that an LLM can be added to one without being allowed to decide anything safety-relevant.

Architecture and analysis

  • Strengthens the portfolio on industrial UX, state modeling, and HMI-style front-end execution.
  • Demonstrates how operational controls and telemetry can share one cohesive interface.
  • Supports the archive as operator-system proof rather than as a warehouse analytics project.

Testing and validation

  • Mixing tank telemetry and control simulation
  • Trend charts, communication logs, and interlock modeling
  • Deterministic rule alarms first, optional Gemini commentary second, with guards tested against a mocked model
  • Vitest suite covering physics determinism, every interlock, Modbus frame encoding, stores, history/CSV parsing and the rate limiter; typecheck, lint, tests and build in CI

Operational value

  • Moves the simulation, interlocks and alarms from the browser to a server engine that streams snapshots over Server-Sent Events.
  • Enforces mixer, valve and E-STOP interlocks server-side, with a stated reason on every denied command.
  • Persists telemetry, alerts and the audit trail, and serves history and CSV export endpoints.

How to inspect

  • Start with the README screenshot and docs/architecture.md before reviewing implementation details.
  • Read it as operator-system proof, not as a PLC integration claim: the Modbus layer is a deterministic simulation, not a network client, and the API has no authentication.
  • Treat it as complementary archive depth to the core analytics and data-science projects.

Related case studies

All projects