CellPulse

CellPulse is a small but credible industrial portfolio project built to demonstrate a realistic machine monitoring and control flow. The idea is to simulate a production-cell environment where one or more machines report telemetry to a central backend, and a dashboard shows their live status, uptime, alarms, and event history.

The project is intentionally scoped as an MVP, but it is designed to feel like a real industrial software stack:

• a REST API for fleet and machine-level telemetry
• a simulated agent that sends heartbeat data
• a React dashboard that visualizes the current state
• MariaDB persistence with EF Core migrations
• structured logging with NLog

What the demo shows

• Machine fleet overview
• Online/offline state
• Uptime and last-seen timestamps
• Alarm counters
• Recent event history
• Start, stop, and reset-alarm actions
• Heartbeat telemetry arriving from a separate agent process

Solution structure

• CellPulse.Api
  • ASP.NET Core REST API
  • Controllers, services, repositories, data context, DTOs, models, migrations
  • Persists machine snapshots, events, and heartbeat data
• CellPulse.Agent
  • Simulated Worker Service
  • Sends heartbeat telemetry to the API on an interval
  • Represents a “machine-side” process in the demo
• CellPulse.Web
  • React + TypeScript frontend
  • Industrial-style dashboard UI
  • Shows fleet status, telemetry, and event log

Domain model

The backend models a simplified industrial machine with:

• Idle
• Running
• Warning
• Alarm
• Stopped

The current MVP treats machines as rows in the database. That makes it easy to simulate multiple cells while keeping the implementation small and believable.

Backend behavior

The API is responsible for:

• returning the current fleet snapshot
• returning a single machine status
• returning recent machine events
• receiving heartbeat telemetry from the agent
• applying machine actions such as start, stop, and alarm reset
• persisting everything to MariaDB through EF Core

The service layer owns the transition rules so the controllers stay thin. Invalid actions return 400 Bad Request instead of silently accepting bad input.

Heartbeat flow

The demo uses a split architecture:

1. CellPulse.Agent generates a heartbeat every few seconds.
2. The agent sends the payload to POST /api/heartbeat.
3. CellPulse.Api stores the heartbeat and updates the machine snapshot.
4. CellPulse.Web reads the latest fleet and machine data from the API.

This gives the project a more realistic “machine reports into control system” feeling than a backend that invents all data internally.

Main API endpoints

Machine endpoints:

• GET /api/machine/fleet
• GET /api/machine/status?machineCode=CELL-01
• GET /api/machine/dashboard?machineCode=CELL-01
• GET /api/machine/events?machineCode=CELL-01&take=20
• POST /api/machine/start?machineCode=CELL-01
• POST /api/machine/stop?machineCode=CELL-01
• POST /api/machine/reset-alarm?machineCode=CELL-01

Heartbeat endpoint:

• POST /api/heartbeat

Data storage

The backend uses MariaDB via EF Core and stores:

• machine snapshots
• machine events
• heartbeat history

The schema is managed through migrations, so the database can be recreated and evolved in a controlled way.

Logging

The API uses NLog and writes logs to files inside the backend output folder. The intent is to make the project feel closer to a real industrial service where errors and transitions are auditable.

Frontend

The React frontend is built as an industrial control panel style dashboard. It focuses on:

• clear fleet visibility
• status emphasis
• timestamped telemetry
• readable event history
• a compact but polished “operations room” feel

The frontend uses Vite and proxies API calls to the local backend during development.

Running locally

Prerequisites

• .NET 10 SDK
• Node.js
• MariaDB running locally

Database

The API expects a MariaDb connection string in CellPulse.Api/appsettings.json. If it is missing, the application fails fast instead of starting with a fallback connection string.

Start the backend

From the solution root:

dotnet run --project .\CellPulse.Api\CellPulse.Api.csproj

In development, Swagger is enabled automatically.

Start the agent

dotnet run --project .\CellPulse.Agent\CellPulse.Agent.csproj

Start the frontend

cd .\CellPulse.Web
npm install
npm run dev

Then open:

• http://localhost:5173/

Development notes

• The project is intentionally small and demo-friendly.
• Machines are currently simulated as database rows.
• The agent is a fake telemetry source for the MVP, but the architecture leaves room for a real edge service later.
• The frontend is already wired to show heartbeat data once the API and agent are running.

Future ideas

• real machine-side agent
• offline detection with threshold-based last-seen checks
• trend charts for cycle time and alarms
• maintenance mode
• user authentication
• live updates via SignalR or WebSockets
• OPC UA or MQTT integration

Project goal

The goal is not to build a huge platform. The goal is to create a polished, believable industrial software demo that makes sense in a job application and shows practical backend, frontend, and integration skills.