← Back to case studies Scientific instrument software case

Semiconductor research instrument control and data-acquisition software: reliability engineering for a Windows upper-computer system

An anonymized Sinovanta case covering a Qt/C++ Windows application, multi-device Modbus temperature control, industrial-camera acquisition and storage, SQLite records, verified device writes, and repeatable installer delivery.

Engagement
Existing-system audit and targeted software upgrade
Scope
Windows software, device communication, industrial camera, data storage, and packaging
Platform
Windows 10/11 x64, Qt 5.12, C++/MSVC, Modbus RTU, and SQLite
Evidence version
1.0.3.20260728 customer-test installer
01

Project context

The existing upper-computer application coordinated ten temperature controllers, shutter devices, an industrial camera, process scripts, and experiment records. Field diagnostics identified discontinuous temperature records, silent camera-storage gaps and preview delay, writes that appeared successful without changing the target device, a Ramp Rate value shown before hardware readback, and inconsistent temperature scaling.

02

Engineering objective

Retain proven device integrations while isolating the highest-risk paths: make control writes traceable, synchronize device parameters in both directions, recover acquisition and storage when frames stop, keep units consistent, produce a repeatable Release installer, and define the remaining customer-hardware acceptance work.

Reliability work across the control and data path

The upgrade treated serial communication, camera acquisition, persistence, user-interface state, and packaging as one observable chain. Each change was tied to a failure mode and a checkable result.

  1. 01

    Baseline and evidence capture

    Freeze the source and installer baseline, review logs and SQLite records, identify device boundaries, and separate observed field faults from assumptions.

  2. 02

    Serial acquisition and parameter readback

    Keep high-frequency PV/SP polling stable while reading Ramp Rate register 0x0023 on a low-frequency schedule, one controller every three seconds.

  3. 03

    Verified device control

    Accept a write only after the exact Modbus 0x06 response matches the slave, register, and value and the target SP is read back; retry or report failure otherwise.

  4. 04

    Camera-pipeline recovery

    Monitor raw-frame arrival and persistence independently, reopen acquisition after a three-second stall, and reschedule storage when frames arrive but no image is saved.

  5. 05

    Data and unit consistency

    Use a single temperature-unit path, remove the legacy factor-of-ten mismatch, preserve real capture timestamps, and keep diagnostics available for later review.

  6. 06

    Release and acceptance control

    Build the x64 Release package, audit runtime dependencies, record file versions and SHA-256 values, retain rollback material, and issue a hardware acceptance checklist.

03

Controlled deliverables

Targeted source patch
A 12-file patch covering Ramp Rate readback, verified writes, camera recovery, persistence scheduling, and temperature-unit consistency.
Customer-test installer
Version 1.0.3.20260728 for Windows x64 with the Qt runtime, SQLite driver, camera SDK, device configuration, and VC Runtime.
Architecture and code review
A review of the existing application structure, communication paths, data handling, and prioritized P0/P1 risks.
Build and package record
Release build output, dependency inventory, version metadata, package counts, and SHA-256 checksums.
Field acceptance checklist
Device-side readback, repeated write verification, camera endurance, reconnection, storage continuity, and unit-consistency checks.
04

Engineering evidence

The evidence below identifies the artifact, test scope, and limitation. It is not a substitute for customer-hardware acceptance.

Architecture review

83 C++ source and header files; approximately 36,200 physical lines reviewed.

The review identified concrete P0/P1 risks and ownership boundaries. It is a static engineering review, not software certification.

Previous-release field diagnosis

Median camera-frame interval about 125 ms; 99% at or below 130 ms; one 562.921-second gap and one 17.306-second gap; 1,486 saved images with no consecutive duplicates.

These measurements establish the prior fault baseline. They do not prove version 1.0.3 endurance.

Release build

Build passed; executable size 1,727,488 bytes; SHA-256 CB4A11624F97BABC892399DF0975059408AA62CA4502622BBEE84D058D2FD5FD.

This confirms a reproducible build artifact and the inspected static assertions only.

Installer audit

78 staged files totaling 66,292,772 bytes; zero Qt Debug DLLs; required Qt, SQLite, camera-SDK, VC Runtime, and device files present.

The installer SHA-256 is 6908988BF48670AC25A9F004BC77070960AE55D19D35AB51212EBDD64B4321A9. The package is unsigned.

05

Validation status

  • Static assertions passed for the Ramp Rate read path, verified write/readback flow, acquisition watchdog, storage watchdog, and removal of the legacy temperature scaling.
  • CTest exited successfully but reported that no tests were found; this is not functional-test evidence.
  • ProductVersion, FileVersion, package contents, required runtime dependencies, and SHA-256 values were checked.
  • Version 1.0.3 had not been installed or run on the customer instrument at the evidence date; device-side and endurance acceptance remains pending.
06

Scope and limitations

The published result is a customer-test Windows installer plus source, build, package, and static-review evidence. It does not claim completed site acceptance, production signing, certified measurement accuracy, uninterrupted long-duration camera storage, or verified operation on every controller and camera combination. Final acceptance requires real Ramp Rate readback, device-panel agreement for repeated writes, at least a two-hour camera run without unexplained gaps, disconnect and reconnect recovery, and temperature-unit checks on the target instrument.

Discuss scientific instrument software

Provide the instrument topology, device protocols, camera model, data-retention rules, operating sequence, existing source or executable, deployment environment, and acceptance criteria.

Submit your requirements →