Portfolio Deck

Back to site

Portfolio Deck8–10 minute engineering portfolio

01 · Executive Summary

Siri Chiu | Software Automation Engineer

Software Engineer at Advantech building server stress-test, thermal-control, device-observability, and QA tools in Golang/Python; AI assists only behind verifiable rules and human gates.

Workflow automationConnect equipment, schedulers, APIs, and engineering work with Golang and Python.
Observable platformsTurn IPMI/SNMP and execution state into metrics, logs, and alerts.
Controlled AI applicationsModels produce candidates; deterministic rules and people decide what can be written.

Primary | Software Automation / Platform　Secondary | AI Applications　Foundation | DSP / Firmware

Portrait of Siri Chiu

02 · Career & Ownership

From signal analysis to engineering workflow and platform automation

My ownership grew from research algorithms and product firmware to software systems spanning equipment and services.

  1. AdvantechSoftware Engineer

    Responsible for Golang/Python automation, server control, IPMI/SNMP integration, Prometheus/Grafana paths, and AI-assisted QA work.

  2. SentonsDSP / Firmware Engineer

    Responsible for MATLAB signal analysis, C# WPF calibration tooling, and C++ firmware work after validation.

  3. National Cheng Kung UniversityM.S., Biomedical Engineering

    Proposed and evaluated an ultrasound imaging method using SVD, background suppression, and structure enhancement.

Target: Software Automation/Platform first, AI application development second; DSP/Firmware supports device and physical-signal boundaries.

03 · Engineering Method

Sense → Model / Contract → Automate → Observe / Verify

Software automation is the main line. AI and DSP support it when a system must interpret unstructured content or physical signals.

  1. 01Sense

    Acquire BMC, SNMP, waveform, issue, and workflow state.

  2. 02Model / Contract

    Define power response, thermal profiles, test truth, and data semantics.

  3. 03Automate

    Execute through controllers, agents, collectors, and pipelines.

  4. 04Observe / Verify

    Retain metrics, logs, assertions, and human gates.

Main line | Software Automation: Adapters → Orchestration → Observability → Gated Action

Support | AI: candidate content and context · DSP/Firmware: signal, device, and product boundaries

04 · Automation Case

Target-Power Stress Testing: One Controller, Multiple Servers

Situation

Fixed burn-in percentages can create high load but do not ensure proximity to a target system wattage; multi-SUT state and long-run logs were also fragmented.

Task / Ownership

I designed the Golang controller/agent flow, pre-test power-response modeling, and telemetry review path. Success meant repeatable scheduling, state collection, and inspectable engineering data.

  1. Operator
  2. Go Controller
  3. Go Agents / SUT
  4. Telemetry & Logs
  5. Grafana

Action / Three Engineering Decisions

  1. Model component responses

    Pre-tests showed approximately linear CPU and saturating Memory/Ethernet behavior, so I did not assign every workload the same percentage.

  2. Buffer logs at each agent

    Agents retain execution records across temporary disconnects before returning them to the controller, reducing gaps in long tests.

  3. Keep AI out of diagnosis

    The model proposes chart observations for engineer review; power, thermal, fan, and throttling telemetry remains the review source.

Result / Deliverable

Delivered one-to-many scheduling, state return, target-power workload estimation, and retention of long-duration telemetry.

Evidence / Validation

Reviewed power, temperature, fan, frequency, and throttling time series in the actual Grafana dashboard.

Boundary Public evidence includes no target-power MAE or recovery test, so I do not claim precise target matching.

Case details and disclosure scope (opens in a new tab)
Grafana dashboard for stress-test power, temperature, fans, frequency, and throttling

05 · Automation Case

Server Thermal Control: From Weeks of Tuning to an Hours-Scale Workflow

Situation

Open-loop control can over-cool for long periods; repeated trial-and-error PID tuning could take weeks and was difficult to reproduce.

Task / Ownership

I owned the Golang host controller, steady-state profile method, parameter derivation, and non-zero integral reset after load dump. Parameters had to be reproducible and engineering-validated before BMC handoff.

  1. Environmental Chamber
  2. Host Controller
  3. SUT / BMC
  4. Workload / Fan

Action / Three Engineering Decisions

  1. Build profiles at equilibrium

    I defined steady state as dT/dt ≈ 0, then derived explainable parameters from profile slope and system gain.

  2. Do not let offline output control the product

    Candidate parameters require engineering validation before BMC delivery, preserving the product-control boundary.

  3. Use a non-zero reset after load dump

    I reset the integral term to a dynamically calculated safe base instead of zero to reduce RPM undershoot and oscillation risk.

Result / Deliverable

In the stated internal workflow, reduced a process that could take weeks to hours, established a parameter-handoff procedure, and gained patent-application experience in server thermal control.

Evidence / Validation

The equilibrium detection and data-recording flow is repeatable; engineers still inspect the profile and candidate parameters before delivery.

Boundary Weeks to hours applies to that specific workflow, not a cross-platform benchmark.

Method and safety boundary (opens in a new tab)
Equilibrium detection and data-recording flow for server thermal characterization

06 · Platform Case

Rack Observability: Normalize IPMI/SNMP at the Collector Boundary

Situation

Servers, switches, and PDUs expose different protocols, MIBs, and fields, forcing engineers to inspect separate equipment interfaces.

Task / Ownership

I implemented collection logic from Netgear, Cisco, and Raritan MIBs and normalized BMC/IPMI and SNMP data into Prometheus metrics.

  1. BMC / IPMI
  2. Vendor SNMP Adapters
  3. Collectors
  4. Prometheus
  5. Grafana / Alerts

Action / Three Engineering Decisions

  1. Preserve source semantics

    Metrics retain device class and source; similarly named fields from different equipment are not assumed to mean the same thing.

  2. Separate telemetry from control

    Read-only data follows the observability path; PDU power control requires separate authorization and audit.

  3. Isolate vendor differences in adapters

    Adding a vendor changes the boundary collector rather than the dashboard’s core data model.

Result / Deliverable

Delivered one Prometheus/Grafana observability path across server, switch, and PDU classes with threshold-alert support.

Evidence / Validation

Checked each device class and source against the documented collector → Prometheus → Grafana architecture.

Boundary I do not claim an unpublished polling SLA, deployment scale, or universal model compatibility.

Collector implementation and limits (opens in a new tab)
Architecture from IPMI and SNMP adapters through collectors to Prometheus and Grafana

07 · AI Application Case

AI Quality Pilot: Deterministic Rules Own PASS and Write Access

Situation

When an LLM executes, declares PASS, and edits a tracker, plausible language can be mistaken for a validated result.

Task / Ownership

I designed the public system contract and implemented the Python engine, case/evidence pipeline, four-axis truth model, Task/Knowledge Graphs, and issue/Wiki/PR gates.

  1. Hermes / LLM
  2. Candidate Content
  3. Deterministic Engine
  4. Evidence
  5. Write Gate / Human

Action / Three Engineering Decisions

  1. Separate four kinds of truth

    workflow_status, test_outcome, gate_status, and health_status evolve independently so one done state cannot conceal failure.

  2. Validate evidence, not only exit codes

    Evidence retains structured assertions, stdout/stderr, duration, contract hashes, and freshness.

  3. Keep human gates for irreversible action

    Commands use allowlists and shell=False; remote issue, Wiki, and PR writes pass deterministic gates.

Result / Deliverable

Delivered an MIT-licensed, repository-agnostic QA toolkit with inspectable state, evidence, local gates, and remote-write request artifacts.

Evidence / Validation

The public repository and architecture are reviewable; its matrix distinguishes Supported, Partial, and Planned capabilities.

Boundary Supported: contracts/evidence/local gates; Partial: MCP and repair handoff; Planned: broader remote integration.

Public architecture and capability matrix (opens in a new tab)
AI Quality Pilot architecture separating the LLM from deterministic evidence and write gates

08 · Supporting DSP / Firmware

DSP Productization: From Measured Waveform to C++ Firmware

Situation

Ultrasound-touch parameters change with materials, hardware, and environment; direct config editing hides the relationship among gestures, waveforms, and parameters.

Task / Ownership

I owned MATLAB signal analysis, the C# WPF device/calibration tool, and implementation of validated parameters or requested features in C++ firmware.

  1. Measured Waveform
  2. MATLAB Analysis
  3. C# WPF Calibration
  4. Engineer Validation
  5. C++ Firmware

Action / Three Engineering Decisions

  1. Retain time/frequency context first

    MATLAB time/frequency analysis, simulation, and linear/nonlinear filtering avoided reducing a waveform to one value.

  2. Let the tool propose candidate bands

    The WPF GUI combined gesture guidance, device communication, and waveform display so parameters could be reviewed in context.

  3. Move into firmware only after validation

    C++ delivered parameters after the product validation path; I do not claim a one-click optimum across materials.

Result / Deliverable

Established a reviewable signal-to-firmware handoff supporting product validation and production issue work.

Evidence / Validation

Waveform context, candidate parameters, and firmware handoff retained human review; product outcomes were collaborative.

Boundary Customers, product models, yield, and unpublished quantitative results are excluded.

DSP and firmware case (opens in a new tab)
Flow from measured ultrasound waveform and calibration to C++ firmware

09 · Supporting Products & Research

Additional Products and Research

Lightnews, Redmine, and biomedical imaging demonstrate complete delivery across content workflows, desktop tooling, and research algorithms.

Lightnews website showing articles and categories LightnewsContent curation required repeated RSS-to-CMS switching; I connected cleanup, Ollama summarization/translation, and WordPress drafts in n8n, delivering a browsable site and editable draft pipeline.Full STAR+ in A1 (opens in a new tab) Weekly planner view in Redmine Smart Companion Redmine Smart CompanionReframed scattered time entry as Plan → Track → Review → Log; delivered a React/Electron + FastAPI Windows desktop workflow.Full STAR+ in A2 (opens in a new tab) High-frequency ultrasound micro-flow and vascular-structure research images Biomedical ImagingApplied block-wise SVD, background suppression, and structure enhancement to micro-flow imaging; delivered a published method and research results.Full STAR+ in A3 (opens in a new tab)

10 · Skills × Project Evidence

Skill Tree Mapped to Project Evidence

Capabilities are grouped by engineering layer and linked to delivered work.

Backend / AutomationGolang · Python · FastAPI · REST

Stress-test controller/agents; thermal host controller; Redmine local service

Infrastructure / DataIPMI · SNMP · Prometheus · Grafana · Linux

Rack collectors; stress telemetry; self-hosted Lightnews workflow

AI / QAPytest · BDD · MCP · Ollama · n8n

AI Quality Pilot contracts/evidence/gates; reviewable Lightnews drafts

DSP / FirmwareMATLAB · C# WPF · C++ · SVD

Sentons calibration-to-firmware; high-frequency ultrasound research

11 · Role Fit

Software Automation / Platform | Problems I Can Own

I can own problems where devices, APIs, data, and validation remain fragmented across manual workflows.

  • Laboratory or engineering work still depends on manual execution, transcription, and review.
  • The team needs device protocols, service APIs, scheduling, and observability connected.
  • AI features require truth sources, validation, and safe write boundaries.

Collaboration | Define success conditions and control boundaries with domain experts first, then iterate through small, observable deliveries.

End-to-end ownership | Adapters → Orchestration → Observability → Gated Action

If these are the problems your team is solving, I would like to discuss them further.

QR code for Siri Chiu’s portfolio

A1 · Lightnews STAR+

Lightnews: A Local-LLM Technical Draft Pipeline

Situation

Technical-content curation required repeated switching among RSS, page cleanup, translation, summarization, images, and the CMS.

Task / Ownership

I designed a Linux-hosted workflow that produces consistent, human-reviewable Traditional Chinese drafts.

  1. RSS
  2. n8n Extraction
  3. Ollama
  4. Image Candidate
  5. WordPress Draft
  6. Editor

Action / Three Engineering Decisions

  1. Use n8n for orchestration

    RSS watching, extraction, HTML cleaning, branches, and CMS handoff stay inspectable as separate workflow steps.

  2. Keep text inference on a managed host

    Ollama generates summaries, translations, categories, and image keywords, reducing text sent to third-party LLM APIs.

  3. Default WordPress output to draft

    Editors decide source meaning, translation, image licensing, and publication; the model has no publish authority.

Result / Deliverable

Delivered a browsable Traditional Chinese technology-news site and reviewable draft pipeline.

Evidence / Validation

The public site capture shows articles, categories, and publication presentation.

Boundary Local applies only to text inference; RSS, Unsplash, and WordPress remain external boundaries.

Full case (opens in a new tab)
Lightnews website showing articles and categories

A2 · Redmine STAR+

Redmine Smart Companion: Plan → Track → Review → Log

Situation

In the observed context, one time entry could require roughly ten clicks and page changes, while weekly omissions were hard to inspect.

Task / Ownership

I redesigned Plan → Track → Review → Log and delivered the React/Electron UI, local FastAPI service, and Windows installer.

  1. React Planner
  2. Electron
  3. Local FastAPI
  4. Redmine API
  5. Review / Log

Action / Three Engineering Decisions

  1. Retain the Python backend

    This reused existing Redmine automation rather than rewriting all API logic for a desktop UI.

  2. Separate desktop lifecycle and service

    Electron manages UI/process lifecycle; PyInstaller packages the backend so users do not install Python.

  3. Separate local planning from remote writes

    Planning, tracking, and review do not imply that a Redmine record was written; the UI retains the submission boundary.

Result / Deliverable

Delivered a Windows planner/calendar/dashboard and Redmine time-entry workflow.

Evidence / Validation

The actual calendar UI demonstrates planning and review surfaces; public material documents Windows packaging.

Boundary I do not claim macOS/Linux release, fixed productivity gains, or unpublished remote-write test coverage.

Full case (opens in a new tab)
Weekly calendar interface in Redmine Smart Companion

A3 · Biomedical Imaging STAR+

HFUDCEI: Micro-Doppler Vascular-Structure Enhancement

Situation

Micro-flow in mouse organs and injured finger tendons required stronger tissue-clutter separation, background suppression, and curvilinear vessel enhancement.

Task / Ownership

I proposed the HFUDCEI imaging algorithm and evaluated it with animal and human research data.

  1. Ultrafast Ultrasound
  2. Block-wise SVD
  3. Background Suppression
  4. Vesselness
  5. Research Evaluation

Action / Three Engineering Decisions

  1. Separate signals with block-wise SVD

    Tissue/clutter components were separated from flow information to reduce tissue-motion interference.

  2. Suppress background before enhancing structure

    This avoided having Hessian/Frangi-style multiscale vesselness amplify residual noise.

  3. Combine comparison and follow-up evaluation

    I compared four mouse-kidney cases and examined tendon neovascularity presentation in human follow-up cases.

Result / Deliverable

Delivered and published a micro-Doppler method for vascular-tree visualization and finger-tendon neovascularity research.

Evidence / Validation

Public comparisons and the paper report CNR 20.76 dB and SNR 71.98 dB; ~35 μm refers only to visible vessel-structure diameter.

Boundary The human recovery relationship is preliminary research, not diagnostic or causal proof.

Research case and paper (opens in a new tab)
HFUDCEI image-quality and vessel-profile comparison results

A5 · Claim & Disclosure Notes

Claim and Disclosure Boundaries

Thermal workflow reduced from weeks to hours
Applies only to the described internal tuning workflow; it is not a cross-platform benchmark.
AI Quality Pilot close loop
The public version is a partial close loop; Supported, Partial, and Planned must remain distinct.
Approximately 35 μm
Means visibility of an approximately 35 μm-diameter vessel structure in the public research, not generic system resolution.
Corporate project results
Exclude customers, product models, hosts, accounts, topology, coefficients, thresholds, raw test data, and legal status.
Cases without public metrics
State delivered artifacts and observable capabilities only; do not infer scale, accuracy, savings, or deployment state.