Process Control Cloud Lab — Simulink to InfluxDB & Grafana on AWS

Problem

In a university process-dynamics course, students run PID and MPC models in Simulink on their own laptops. The results stayed on those laptops: the instructor could not see a run unless it was screenshotted, two students’ tunings could not be compared, and nothing survived the end of the lab session.

The course also has one real rig — a pump, level and flow loop on a Siemens S7-1500 — that students could only reach from inside the lab. The goal was a central place for every run, simulated or real, without exposing the lab PLC or any server to the internet, on a university budget.

My role & scope

I built the platform and wrote the documentation for it, working with the professor who runs the course:

• Pilot server on AWS, then the sizing and cost plan for the full class
• The MATLAB/Simulink write path into InfluxDB
• Student access: VPN keys, access rules, device naming and the pilot test
• Grafana dashboards, the PostgreSQL archive and the backup scripts
• Phase 2 Simulink models (Single Level, Single Flow, Cascade, MPC) and their test plan
• Runbooks in English and Thai, and a teaching deck for the class

Scale: 120 students planned, 5 pilot testers, 4 control models, 4 dashboards plus a comparison view.

Approach

Student laptop × 120                 AWS (one EC2 instance, Docker Compose)
Simulink model ──1 Hz──► buffer 5–10 s ──► Tailscale tunnel ──► InfluxDB ──► Grafana
       │                                     (WireGuard)            │
       └── USE_OPC = 1 ──► OPC UA ──► S7-1500 rig                   ├──► PostgreSQL archive (every 10 min)
                                                                     └──► S3 backup + volume snapshots

Zero public surface

The security group lets in one UDP port for the VPN and nothing else. InfluxDB, Grafana and SSH listen only on the tunnel interface. Students, instructors and admins are separated by tags in the VPN access rules: students can write data and view dashboards; instructors can build dashboards; only two admins can log in to the server.

Write path from Simulink

A MATLAB helper buffers 5–10 seconds of samples and sends them as one InfluxDB line-protocol request, with retries and exponential backoff. Buffering cuts the load at peak from 120 HTTP requests a second to 24. Every point carries a student tag, so one bucket holds the whole class and each dashboard can be filtered to one person.

Student access to the real PLC

The PLC sits behind a small Linux box in the lab that routes the lab subnet into the VPN. The access rule for students opens the PLC’s single address only, not the whole lab network, and it is a separate rule so it can be deleted at the end of term. Each student joins with their student ID as the device name — otherwise 120 machines show up as DESKTOP-xxxx with no owner. The rule was tested from a machine that had never joined the network: the admin’s own laptop passes every test and proves nothing.

One model, simulation or plant

Each Simulink model has a USE_OPC switch: 0 runs against the plant model, 1 reads and writes the real PLC over OPC UA. Both modes log to the same measurement with a _SIM suffix on the student tag, so a dashboard puts the simulated and the real response of the same controller side by side. The Single-loop and Cascade dashboards are generated by a script from the MPC dashboard, so all three look and behave the same.

Sizing before spending

The pilot ran on a small instance; the plan for the full class is a 4 vCPU / 16 GB Graviton instance in the Bangkok region, upgraded in place because both are arm64. The recommendation is on-demand for the first semester, then a savings plan sized from measured load. The plan also flagged a VPN licensing trap before it happened: with per-seat pricing, 120 student devices could cost more than seven times the server.

Data you can trust

InfluxDB keeps raw data for 180 days and a 1-minute downsample for three years. A Python job copies every point into PostgreSQL with (student, time) as the primary key, so running the copy twice updates rows instead of duplicating them; fields it does not know yet go into a JSON column instead of being dropped. A second job compares both sides every six hours. Nightly volume snapshots and a weekly InfluxDB backup to S3 come with a restore-test script.

Delivery

• Phase 0 (June–July 2026): pilot server with InfluxDB and Grafana behind the VPN; Simulink to InfluxDB verified end to end; 14-slide teaching deck and workflow diagram; key-generation script, access rules and a self-service portal prototype; pilot test with 5 users.
• Phase 1 plan (August 2026): architecture, cost comparison and setup runbooks for the full class.
• Phase 2 (October 2026): four models rebuilt to one pattern; a test gate before any model touches the rig — compile in both modes, switch modes with the model open, a 3,000-second simulation run and tuning metrics; one site day on the rig per model; handover package of models, dashboard files, archive scripts and a bilingual test report.
• A companion web app (FastAPI + React) for the same data: fits a first-order-plus-dead-time model to a step response and gives Ziegler-Nichols, Cohen-Coon and IMC tunings with a PDF report per student.

Result

• One place for every student run, simulated or real, instead of screenshots
• Students compare the simulated and the real response of their own controller in one dashboard
• The lab PLC reachable for class work without opening the lab network to the internet
• A costed, documented plan the department can approve and the next admin can rebuild from

Skills used

AWS (EC2, EBS snapshots, S3, IAM, CloudWatch, Budgets) · Tailscale VPN, subnet routing and access rules · InfluxDB 2 and Flux · Grafana dashboards as code · PostgreSQL · Docker Compose · MATLAB / Simulink with OPC UA · PID, cascade and MPC loops · Python · FastAPI and React · writing runbooks in English and Thai.