Index / TyreSense / IOTS

Case Study · 02 / 03

Optim / IOTS

Internal Optimisation Testing System: a multi-version internal platform that unified technician workflows, live test visibility, and long-term historical analysis across product lines.

Role
Solo · Internal platform
Context
TyreSense · Production testing
Status
Active long-running project family
Focus
Consistency, traceability, speed
01

The problem

Internal product testing and serialisation workflows were fragmented across manual steps, ad-hoc logs, and technician-by-technician process differences. Test execution, terminal output visibility, and historical result analysis were not unified in one place.

This made repeatability harder and slowed debugging, especially when multiple product types required different handling rules. Testing is only useful when it is consistent, traceable, and fast to interpret. A centralized testing system was needed to reduce friction and raise confidence in results.

02

What I built

Optim / IOTS evolved from early interface experimentation into a structured web-based system for operator login, guided testing flows, live status feedback, and long-term test history management. It combined technician authentication, product-aware workflows, real-time visibility, persistent logging, and export tooling.

  • Technician login & session context

    User login flow with operator/session context for accountability and cleaner analytics.

  • Guided product-aware workflows

    Structured product selection and test initiation with product-specific serial handling.

  • Live status + terminal stream

    Visual PASS/FAIL/UNKNOWN outcomes paired with raw terminal-style output for low-level troubleshooting.

  • Centralized test history

    Product-specific historical paths with daily and cumulative views for both granular and broad review.

  • Socket-based runtime visibility

    Real-time system communication for responsive interfaces during active test execution.

  • Export tooling

    Nested JSON test logs can be flattened to CSV for audits, spreadsheets, and reporting workflows.

03

Tech stack

Frontend: Browser-based UI with HTML, CSS, and JavaScript for login, test flow, and logs views.

Backend: Python 3, Flask, Flask-CORS, and Flask-SocketIO.

Data: JSON and JSONC-style config/registry files, product/date-structured history paths, and CSV reporting pipeline.

Hardware integration: pyserial for serial-connected test hardware, with product-specific serialisation behavior.

Runtime tooling: requests, cryptography, psutil, startup/watchdog scripts, and internal log conversion utilities.

04

Outcome

Guided, reusable flows improved consistency, while live feedback and centralized logs strengthened traceability and debugging. Teams can now run testing through a common process, inspect live state and raw output side-by-side, and export historical data quickly for deeper analysis.

The project became an active long-running internal platform family, evolving from early Optim interface builds into IOTS_ALT 1.0.x releases with continued refactoring and stack modernization. It is used in real internal technician and engineering workflows rather than as a one-off proof of concept.

Note · Some technical details remain confidential.