Projects & Applied Research

Factory AI Adoption: The Data Foundation Is the First Barrier — Using AI Itself to Tackle Legacy Equipment Protocol Challenges

Professional Article | Published 2026-10-15

Sole author and publisher (personal viewpoint article)

Diagnoses why so many manufacturing AI projects stall mid-way: the real bottleneck is not the algorithm but the collection of high-quality underlying data. The article argues for the correct sequence — build the data foundation first, then deploy upper-layer AI — and proposes a strategy of AI combined with self-developed edge computing boards for data reverse engineering: on-site packet capture, AI packet analysis and feature extraction, and automatic generation of protocol layers, so both legacy proprietary protocols and modern standards can be integrated without vendor documentation or mass machine replacement.

Read the full article · 繁體中文版

Professional Article | The Data Foundation of Factory AI Adoption

Professional Article | Published 2026-10-15

Sole author and publisher (personal viewpoint article)

Diagnoses why so many manufacturing AI projects stall mid-way: the real bottleneck is not the algorithm but the collection of high-quality underlying data. The article argues for the correct sequence — build the data foundation first, then deploy upper-layer AI — and proposes a strategy of AI combined with self-developed edge computing boards for data reverse engineering: on-site packet capture, AI-driven packet analysis and feature extraction, and automatic generation of protocol layers, so both legacy proprietary protocols and modern standards can be integrated without vendor documentation or mass machine replacement.

Origin and Problem Definition

Observing that manufacturing AI projects cluster around upper-layer applications (AI Agents, intelligent scheduling, quality prediction) and frequently stall, the article reframes the problem: the bottleneck is not the algorithm but whether underlying data can be fully captured, carries operational value, and stays free of noise or missing records. These three are the precondition for reliable model inputs.

Argument Structure and Strategy

The article develops through four movements — tracing the barrier, the cost of traditional remedies, the core strategy, and the correct sequence. Traditional remedies (requesting OEM protocol documents, custom drivers, replacing old hardware, adding sensors) are expensive and slow, and many legacy vendors have ceased support and refuse to release protocol specifications; the article therefore proposes edge packet capture combined with AI batch packet analysis and feature extraction to auto-generate protocol layers.

Practical Correspondence and Publication

The edge-capture and auto-generated-protocol strategy maps to the author's ongoing Industrial Edge Gateway (hardware + software + AI) project — an ESP32-S3 edge node board, a JSON protocol-description engine, and AI-generated protocol profiles and rules. The full text is also published in the site's Blog journal in both English and Traditional Chinese.

Source: Personal professional article, published 2026-10-15 | Full text in the site Blog journal (en / zh-TW)

AI Surface Defect Classification & Explainability

Applied AI Vision | 2026

Data pipeline, model training, explainability analysis and demo interface — independently delivered

A reproducible vision-classification build on an industrial surface-defect problem: constructed a data pipeline from a public industrial dataset, compared CNN and Transformer transfer learning under an identical protocol, validated model evidence against human annotations using Grad-CAM, and packaged the result into a live inference demo. The goal was to test whether "accurate is not enough — a line AI must explain its call" is workable in practice.

Problem framing and data pipeline

Six steel surface defect classes were used as the classification target; Pascal VOC annotations were parsed into class labels with a fixed-seed stratified split ensuring disjoint train/val/test sets, plus sample and bounding-box references as a baseline for later explainability comparison.

Model comparison and architecture observation

CNN and Transformer were compared under an identical split and training protocol; both reached 100% on the held-out set, indicating that for well-defined industrial defect classification, image features and pretrained representations are already sufficient. The real difference appeared in explainability — CNN heatmaps concentrate on the defect body while ViT attention spreads wider, reflecting how architecture affects how readable a model's evidence is, and what a line-selection decision must weigh beyond accuracy.

Explainability and scope boundary

Grad-CAM was used to visualize model evidence against human annotations, confirming that attended regions align with defect locations — a key requirement for line AI, where verdicts must be traceable for QA, process and customers, not just a score. Scope note: this is offline validation on a public dataset, not a production deployment; the dataset is limited in scale and scenario, and 100% accuracy reflects benchmark characteristics rather than mass-production performance.

Source: Personal development record (GitHub: ai-aoi) | NEU-DET public industrial surface-defect dataset

Wafer-to-Market Semiconductor Back-End Experience

Semiconductor Supply Chain & Commercialization Project | 2021

Funding and supply chain integration, test and packaging coordination, and sales

During the 2021 pandemic and chip shortage, sourced 16 SXX wafers through industry channels, coordinated funding and supply chain resources, and completed the workflow from wafer sourcing through testing, packaging and final verification to sales.

Source:

LINE Scan-to-Order SaaS (PickMy Order)

Independent Build | 2026

Product definition, system architecture, and development lead

A LINE scan-to-order and light-membership SaaS for offline stores, built around scan-to-order, loyalty points, and prepaid service cards — driven independently from product definition and full-stack development through automated testing (described generically; no project-specific details).

Source:

0→1 Digital Platform Build & Launch

Independent Build | 2026

End-to-end owner: architecture, development, testing, production launch

Took a multi-role service platform from architecture design and full-stack development through automated testing to production deployment on cloud infrastructure — completed end to end in personal time (described generically; no project-specific details).

Source:

AI Process & Engineering Parameter Optimization

Workplace Project Research | Changshu Jingyuan

Participated in engineering pull-force prediction and supported manufacturing AI applications through plant management.

Translated manufacturing and design problems into measurable parameters, prediction targets and validation workflows. Studied key pressing, paint fixtures, pogo-pin force, keycap pull force and laser-engraving parameter optimization.

Research Question & Method

The keycap pull-force project addressed hook-opening dimensions that relied on experience and tooling trials. It used material and historical force data to explore dimension prediction and parameter recommendations. The presentation records 20 modeling samples and 3 additional test samples: preliminary validation requiring more data across specifications and operating conditions.

Manufacturing Validation

The key-pressing case combined cylinder pressure, ejection time, pressing time and rubber hardness. Following model recommendations and offline testing, the team reported a metric increase from 200 to 1,113 pcs per operation. The original unit and limited scope are retained.

Benefits & Research Limitations

The pull-force project estimated RMB 104,800 per year across tooling modification, experimental labor and new-hire training. This is a scenario estimate, not realized savings, and is not added to the RMB 2M+ annual result in the resume. Further work includes tolerance recommendations, larger samples and continued offline validation.

Source: AI Project Optimization Summary, slides 20, 22, 62, 66–67, 71, 74 and 79–80. Named participation applies to the pull-force project; other cases summarize team reports.

Jingtek E-bike App & IoT Service System

Product Planning & Entrepreneurship Research | E-bike / IoT

Draws on product development and App / administration architecture planning during the co-founder / executive vice president role.

Explored integration of e-bike hardware communications, mobile applications and administration systems, extending product capabilities into online transactions, after-sales services and user communities.

App & Administration Planning

The presentation covers vehicle anomaly detection, nearby repair locations, shopping, wish lists and points redemption. Administration includes member, product and maintenance management, plus customer-behavior and sales analysis, considering product development and after-sales workflows together.

IoT & Business Model Research

Explored community features, test rides and maintenance services to support engagement, alongside online transactions and experience sharing. Rental concepts proposed GPS, anti-theft and geofencing requirements; hardware planning included communication compatibility and an OTA update library.

Scope of Experience

This case demonstrates system planning, hardware–software integration and business model research. The presentation provides no revenue, user-count or full-launch validation, so proposed features are not presented as realized commercial results. Its requirement to support over 60% of communication protocols is a different metric from the resume’s over 65% hardware compatibility result.

Source: Jingtek E_bike app system, slides 3 and 5–16. Personal responsibilities are contextualized by the entrepreneurship and App architecture experience in the September 15 resume.

Agentic Workflows & Manufacturing Governance

Continuing Study | Agentic Workflow

Studied Morris Fan’s lecture materials to explore workflow integration and governance for private enterprise AI agents.

Used The Practice and Challenges of Agentic Workflows as a study reference, focusing on manufacturing problem definition, data and tool integration, human review and traceable decision processes.

Architecture & Workflow Study

Reviewed the lecture’s data and tool layers, agent core, workflow orchestration and governance architecture. Explored turning operational needs into executable, observable tasks with clear boundaries for queries, tool actions and result verification.

Manufacturing Governance

Focused on human-in-the-loop review, tool permissions, evidence logs, exception handling and stop mechanisms. Considered irreversibility, production risk and data sensitivity, alongside task success rate, cost, latency and failure recovery.

Applications & Attribution

Equipment maintenance, quality knowledge, production scheduling, demand forecasting and supply-chain early warning are directions for further study. This is a review of lecture materials authored by Morris Fan; the lecture’s demonstration systems, code and results are not claimed as personal development or deployment outcomes.

Source: Morris Fan, The Practice and Challenges of Agentic Workflows, pages 4–13, 27–32, 73–82 and 84–91. Third-party study reference, not a personal publication.

Expertizing Engineering Know-how & AI-Assisted Technical Review

Knowledge Assetization | 2026

Independently executed: know-how extraction, expert role definition, review process design, and human–AI division-of-labour validation

Converted 10+ years of embedded power and motor-control experience (commutation truth tables, protection criteria, CAN/J1939 protocol design) into a packageable, distributable professional expert role, so the know-how no longer leaves with the individual; validated against real firmware a division of labour where “AI runs the standardized first-pass review, humans own risk adjudication” — the first AI pass surfaced 3 safety-critical defects.

Problem definition: turning experience into a portable asset

The starting point is the familiar concentration of senior technical judgment in one person, which resists transfer. Critical decision criteria live in the mind and in code comments; new engineers accumulate them through repeated questions and trial and error, and once the holder leaves, the experience cannot be regenerated. Conventional remedies — documentation and training — struggle to carry conditional professional intuition of the form “under what conditions should this judgment be made, and under what conditions must it never be done this way,” nor do they trigger on demand at the point of work. The alternative pursued here was to rewrite experience as executable rules packaged into a role that is summoned actively in the work context.

Extraction method: converting judgment criteria into executable rules

The substance of extraction is not enumerating technical terms, but four classes of executable rules: capability boundaries (which problems this role handles, and where the question must be handed back to a human); workflow (a fixed progression for any problem — establish boundaries, decompose layers, present option comparisons, then descend to parameter level); output conventions (conclusion first, comparison tables, parameters with units, risks annotated with their source); and prohibited actions (irreversible operations, personnel-safety thresholds, items that must be measured rather than inferred). Without all four, the role degrades into a question-answering bot rather than an asset that can carry judgment.

Division of labour: AI for standardized first-pass, humans for risk adjudication

Real firmware was used as the acceptance target. The division was designed so the AI executes a complete first-pass review under predefined rules and produces reproducible, objective findings, while the human judges severity, confirms the corrective approach and holds final release. The outcome validated the design: the defects the AI surfaced were largely of types verifiable by mechanical comparison or mathematical derivation (the mapping mismatch confirmed by bit-order line-by-line comparison, the direction error confirmed by field-vector angle derivation), while severity adjudication and solution trade-offs still required human ownership. This also reduced senior-engineer time, shifting senior effort from line-by-line checking to defining standards and final adjudication.

Quality discipline: refusing single-source conclusions, mutual proof by two paths

The most consequential practice established here is the rule that no single-source conclusion is accepted. Each technical finding had to be reproduced through two independent routes — line-by-line bit-order comparison and space field-vector angle derivation — and only agreement between them counted as settled. Verification scripts were also required to parse parameter tables directly from source code, with manual transcription prohibited; this actually caught a transcription error mid-exercise (an initial finding of 5 errors was corrected to 4 once parsed from source). The discipline aligns with established manufacturing quality practice: do not trust a single data point, confirm by reproducible method, and trace discrepancies to the root rather than adopting one side.

Risk grading and closure: making findings assignable

All findings were graded into safety-critical, high-risk and general-recommendation tiers based on whether personnel or line safety was involved, each mapped to a concrete corrective action and verification method, with items requiring hardware confirmation explicitly flagged together with the test procedure. This grading lets technical review output feed directly into an existing defect-management process instead of stopping at a list of suggestions, so closure speed depends on execution rather than on re-translation.

Scope and next steps

This is an individual implementation validated against the author’s own firmware projects; it has not yet been extended to parallel multi-project operation or cross-team reuse. Confirmed next directions include separating path- and environment-dependent private material from general reusable knowledge so the asset can operate in different environments; codifying mechanically repeatable checks (such as parameter-table versus document consistency) into automated checks that can be re-executed; and, once enough cases accumulate, evaluating whether this form of review expertise can be offered as external technical advisory work. All conclusions are personal measurement and analysis, not third-party verified.

Source: Personal implementation record (2026-10): role definition and review rules authored from scratch, validated against the author’s own embedded firmware projects; verification scripts and the review report can be re-executed to reproduce the conclusions.

E-Vehicle Controller Embedded Development

Ongoing Development | Embedded Systems

Personal Technical Research & Development (ongoing)

Building on 10+ years of embedded development experience, ongoing firmware and tooling development for an e-bike controller (three-phase BLDC motor control): motor control algorithms, migration of production-proven protection logic, communication protocol design, Windows tuning tools and AI-assisted diagnostics over logged operating data.

Motor Control & Firmware

Re-implemented production-proven control logic on a modern dual-core MCU with integrated CAN/BLE: three-phase BLDC commutation and SVPWM sinusoidal control, overcurrent / undervoltage / stall protection, and firmware-level electromagnetic braking (E-ABS) with regenerative energy recovery and safety management.

Protocols & Toolchain

Designed serial communication protocols and debug frames (controller–display–BMS) and built a Windows tuning tool covering parameter read/write, Hall calibration, live charts and diagnostic export, supporting motor matching and production calibration.

AI Applications

Exported operating data (current, speed, voltage, load state) as structured diagnostic packages; explored LLM-assisted fault diagnosis and motor-parameter self-learning as a bridge to IoT services and after-sales applications.

Source: Personal development records (GitHub)

E-Vehicle Battery Management System (BMS) Development

Ongoing Development | Battery Management

Personal Technical Research & Development (ongoing)

End-to-end design of a 36V (10S) lithium battery management system: analog front-end (AFE) selection, host MCU and CAN architecture, safety-gated regenerative braking with advance negotiation, and online terminal contact-resistance monitoring — with full schematic, pin-level wiring table and CAN protocol draft delivered.

Architecture & Hardware

BQ76930 AFE + STM32F103 (built-in bxCAN) + CAN transceiver: 10S cell sampling and balancing, charge/discharge MOS power stage, 42V-to-5V buck with integrated Bluetooth speaker; full schematic and pin-level connection table delivered.

Protocol & Regen Safety

Mapped the legacy RS232 battery protocol onto J1939-style CAN frames for controller integration; regenerative braking gated by a two-layer mechanism (safety admission + advance no-regen negotiation) with multi-level SOC/temperature/current thresholds, protecting both battery and controller lifespan across a two-phase rollout plan.

Reliability & Differentiating Features

Self-developed B+/P+ dual-point online contact-resistance monitoring that estimates power-loop contact resistance in real time with tiered alerts, catching outdoor plug corrosion and fretting degradation early; plus an anthropomorphic voice-prompt feature (battery / health / connection status, language and voice switchable via app).

Source: Personal development records (GitHub: ebikeBMS)

Industrial Edge Gateway (Hardware + Software + AI)

Ongoing Development | Industrial IoT

Personal Technical Research & Development (ongoing)

Born from a universal manufacturing pain point: legacy equipment (RS-232 proprietary-protocol meters, old PLCs) holds data that cannot be extracted, and vendor-based integration is costly with no guarantee of success. The direction of this project is a hardware-software-AI system that turns proprietary protocol integration from custom development into configuration — an in-house low-cost edge node board for physical access, a JSON protocol-description engine that parses any proprietary frame format with zero code changes, and AI that generates protocol profiles and alarm rules from packet samples and plain-language descriptions, connecting old machines to data platforms quickly and affordably.

Edge Node Hardware

In-house DIN-rail node board: ESP32-S3 host + CH438 multi-UART expansion, isolated RS-232 x4 / RS-485 x2 / CAN x1, 9-36V industrial input with surge protection, Ethernet/WiFi uplink to MQTT.

JSON Protocol Engine

No hard-coded protocols: frame header/length/checksum/field layout lives in one JSON profile, parsed by a streaming engine tolerant of arbitrary byte splits and bad frames — adding a device is a configuration change, not a code change; a local rule engine (debounced thresholds, deadband filtering) handles edge computing.

AI-Assisted Integration

AI generates protocol profiles and rules from packet captures and plain-language descriptions for human review, cutting protocol reverse-engineering from days to minutes; the run-time direction adds lightweight on-node anomaly detection.

Source: Personal development records (GitHub: edgenotepcb)

Smart Door Lock Product Definition & Selection (NPI)

Product Definition & Selection | Smart Lock

Requirement definition, solution selection and cost engineering — independently delivered (design phase, ongoing)

Targeting one hardware platform shared across three scenarios — home, apartment and small B&B — redefined the requirements for a full-featured smart door lock (WiFi / Bluetooth / key card / PIN / fingerprint / doorbell / App / smart-home ecosystem), and completed the ecosystem route decision, main-MCU and peripheral selection, the unit cost structure and mass-production cost engineering, plus the architecture plan for a hotel-grade complete system (lock + gateway + card encoder + management software); on top of existing Bluetooth lock assets, planned auto double-locking and tamper warning as differentiating features.

Requirement redefinition and solution selection

Reframed "WiFi home integration" as Matter compliance (Apple / Google / Amazon / SmartThings) and established BLE as a mandatory commissioning channel rather than an option. After comparing in-house development, commercial module and hybrid routes, settled on a two-tier architecture: ESP32-C6 (WiFi 6 + BLE 5.3 + 802.15.4, Matter-native) as the main MCU, with a low-power co-processor (450 nA deep sleep) handling always-on standby and touch wake. Completed unified peripheral selection (card reader, semiconductor fingerprint, 6068 standard lock body, voice prompt, isolated motor drive). Hardware reserves Aliro (phone-wallet tap-to-unlock) capability, settled once and rolled out in software phases.

Cost engineering and three-scenario configuration

Built the unit cost structure, breaking it into eight cost blocks and identifying the credential layer (card reader, fingerprint and other identity factors) as the dominant cost item and negotiation focus, then used that to set tiered cost targets and an RFQ strategy for volume production. The key architectural decision is one board, many configurations — home / apartment / B&B run on direct WiFi with no gateway required, while hotels use BLE reporting plus a PoE gateway for centralized management (one gateway serving multiple doors); hardware differences reduce to lock-body grade, door sensor and enclosure material, so all three scenarios share one PCB and one firmware.

Hotel-grade system and differentiating features

Planned the complete hotel-grade system — lock, gateway, card encoder, housekeeping management software and installation/delivery as one architecture — with optimized gateway coverage and a lightweight system as the source of cost advantage, supported by an RFQ list and a technical risk register (including key-component supply and price locking). Also planned auto double-locking with tamper warning: scheduled or sensed escalation to double lock with tiered response (physical hardening before alarm), four sensing paths with two-path cross-validation to cut false alarms, mapped to Matter's native lock states and DoorForcedOpen alarm code.

Source: Personal development record (smart lock selection plan v1.0 / feature addendum v1.1) | Reused existing Bluetooth lock project assets