Industrial-grade reliability.
25% of the cost.
Multi-path control + predictive AI

The market PLCs cannot reach.

The standard for industrial control has been the PLC for four decades. Deterministic execution, hardware watchdogs, industrial-grade components — PLCs deliver high reliability and integrate cleanly with SCADA, MES, and ERP layers across heavy industry: petrochemical, automotive, semiconductor fabs.

But PLC-based systems carry a structural cost floor. Controllers start at around USD 1,000; a small 16-DI / 16-DO system runs €1,500–€3,000 in modules, power, and rack alone. Real on-site cost adds cabinets, terminal blocks, wiring, programming, HMI/SCADA licensing, engineering, and commissioning — typically USD 200–500 per point. Add redundancy or SIL-certified safety, and that doubles or triples. ROI works in heavy industry; it fails everywhere else.

Beyond cost, there's a functional mismatch. PLCs run on deterministic thresholds and pre-authored rules. They were never designed for multimodal decision-making fusing video and environmental data, time-series learning of fault precursors, or self-adaptive learning from operational data. The "data-driven intelligent operation" that defines modern distributed IoT — PLC architecture wasn't built for it.

So a vast automation gap forms. Greenhouse environmental management, cold-chain monitoring, freeze prevention in distributed warehouses, container-farm climate control — all still rely on manual oversight or single-node IoT that has surrendered reliability. The central question: can PLC-grade reliability be delivered at 25% of PLC cost?

Reliability as structure, not premium.

2.1 Multi-path redundancy

If unit cost is pushed below the point where individual node reliability can be guaranteed, how can system-level reliability still be assured? The conventional answer is "it cannot be." Most low-cost IoT systems either surrender reliability or push cost back up to recover it. We take a third path: concede node reliability, but secure system reliability through the mathematical probability structure of multi-path deployment.

Place 2–3 independent low-cost nodes at the same point. If single-node failure probability Q is 1%, system unavailability falls to Q² = 10⁻⁴ (2-path) or Q³ = 10⁻⁶ (3-path) — a difference of orders of magnitude. System reliability no longer depends on the absolute reliability of any single node; it depends on the probability structure of multi-deployment. With each additional node costing ~USD 10–20, even multi-path achieves PLC-grade or better availability at approximately 25% of PLC cost.

2.2 System self-compensation via predictive AI

Can the system itself compensate for the limitations of low-cost nodes? Our answer is predictive analytics in the central TMCC AI, working along two dimensions. At the infrastructure dimension, time-series reports from all multi-path nodes are continuously monitored to detect failure precursors and trigger preemptive replacement. At the domain dimension, environmental measurements and vision imagery are fused into multimodal analysis to detect anomalies in the operational target — livestock, logistics, equipment — before incidents occur.

2.3 Stateless transactional model — no broker, no NAT pain

Most distributed IoT systems lean on a broker (MQTT, AMQP) sitting between devices and the server. Brokers exist for a real reason: residential and industrial NATs make it hard to push commands inbound to a device. But brokers introduce their own problems — they become a single point of failure, they require persistent stateful sockets, and they add operational overhead (clustering, QoS levels, session management).

TMCS sidesteps the broker entirely. Every TMCD initiates communication outbound to TMCC over a stateless request-response cycle, identical in shape to a REST call. The device sends its current state; the server responds with the next command. Anywhere with internet access, the device can reach the server — without inbound port forwarding, without firewall holes, without a broker in the middle. NAT becomes a non-issue, not because we solved it, but because we never put ourselves on the wrong side of it.

The transactional design carries three further benefits that compound:

• Idempotent commands — the same "open vent" command sent twice produces the same result. Network retries are safe by construction; we never reason about exactly-once delivery.
• No persistent state to lose — there is no long-lived socket to drop, no session to resume, no broker queue to drain. Every transaction is complete in itself.
• Plug-and-play scaling — adding a new TMCD requires no server-side configuration. The board powers on, sends its first report, and TMCC enrols it. Removing one is equally trivial.

2.4 Per-cycle restart (auxiliary)

Each node performs a complete restart at every reporting cycle (~3 s boot + ~1 s report). Leveraging the fast cold-boot of ultra-light MCUs, software aging — memory leaks, stack corruption — is preempted at every cycle. This is an additional safety net and can be disabled in domains requiring real-time control; the multi-path layer alone absorbs node failure, so system availability is preserved either way.

2.5 The hypotheses we set out to test

2.6 What we built

The shape of the system.

3.1 Three principles

Principle 01 — Reliability is structural, not hardware-bound. Rather than improving the quality of individual nodes, multiple nodes are deployed at the same point, and software guarantees the reliability of the combination.

Principle 02 — Node failure is absorbed, not prevented. Every node performs a full restart at each reporting cycle. The deterministic ~3 s boot + ~1 s report converges within a 5 s+ reporting period; boot is not a loss of availability but a normal part of the cycle.

Principle 03 — No middleware tier. All TMCDs connect to TMCC outbound. Anywhere with internet access, deployment is immediate — without firewall configuration.

3.2 Overall structure

TMCC (TERACODE Multi-path Control Cloud) is the central server software that orchestrates all TMCDs. It carries two responsibilities of distinctly different character. The deterministic reliability layer handles report collection from multi-path nodes, statistically grounded majority voting, trusted-path selection, and instant failover on node fault. The AI intelligent-operations layer monitors multi-path time series to predict node failure in advance, and combines environmental measurement with imagery in multimodal decisions for domain autonomous operation. TMCC runs on a central Linux server, with a triple-redundant fanless SBC Local TMCC co-located on site as backup against WAN disconnect.

TMCC's deployment unit is a site. A single TMCC orchestrates a single site (e.g., 33 containers in Gangwon); the validated operating range of one site TMCC at this scale is 495 nodes. Multi-site integration is handled by an upper federation layer of site-level TMCCs. TMCS is therefore not "one server controlling every node nationwide"; it is a distributed structure of per-site TMCC + inter-site federation.

TMCD (TERACODE Multi-path Control Device) is an ultra-light MCU-based node deployed in the field. It comes in two families — sensing nodes and control nodes — but all share a common communication structure and firmware architecture.

3.3 Multi-path deployment

2-path configuration (default). Two TMCDs at the same point. If one stops reporting, TMCC immediately adopts the data from the remaining node.

3-path configuration (high reliability). Three TMCDs at the same point. TMCC performs majority voting across the three reports. Even if one node sends an outlier, the normal values from the other two are adopted.

Multi-path deployment does more than secure availability at the moment of failure — it allows the system to evolve during uninterrupted operation. A FOTA firmware update places a node in boot for ~3 seconds. In a single-node system, those 3 seconds are a system-level gap; in a multi-path system, the other nodes at the same point keep reporting and no system-level gap occurs. New algorithms, security patches, and feature improvements roll out across all nodes without operational interruption. Multi-path is both a reliability mechanism and an evolution mechanism.

3.4 Dual-server fallback

TMCS has two layers — node (TMCD) and server (TMCC). To handle WAN or central-server failure, a Local TMCC is co-located on site, but it is not a separate layer; it's a backup instance of the same TMCC software. In normal operation it stays idle, periodically syncing the latest policy and node-state snapshots from the central TMCC to maintain emergency-takeover readiness.

Stage 1 — Normal operation. All TMCDs report to the central TMCC. Local TMCC accepts no traffic and only performs background policy sync.

Stage 2 — Emergency takeover. On WAN disconnect or central TMCC unresponsiveness, all TMCDs immediately switch their connection target to the Local TMCC, which assumes the TMCC role using its synchronized policy. When WAN recovers, TMCDs return to the central TMCC and the Local TMCC reverts to idle.

Determinism below, intelligence above.

4.1 Two layers, two responsibilities

TMCC is where TMCS's intelligence concentrates, but that intelligence does not collapse into a single AI module.

① Deterministic reliability layer. Report collection from multi-path nodes; statistical majority voting for trusted-path selection; complete-failure detection and instant failover. This layer uses no AI; it operates by deterministic logic. In areas directly tied to availability and system reliability, deterministic guarantees take precedence.

② AI intelligent-operations layer. Continuous monitoring of multi-path time-series for early detection of node failure precursors (C3); multimodal decision-making fusing environmental measurement and imagery for domain autonomous operation (C4). This layer handles patterns that deterministic thresholds cannot define and constitutes TMCS's true differentiation.

The division is intentional. Reliability mechanisms guaranteeing availability must be deterministic; intelligent applications enhancing operational quality belong to AI. The two layers run in parallel on the same data pipeline.

4.2 Trusted-path selection

All TMCDs report state to TMCC at a configurable cycle. The Gangwon container farm uses 10 seconds. Trusted-path selection is deterministic statistical logic in three stages:

1. Availability filtering — only nodes whose report was received within the previous cycle are considered. Missing reports immediately classify a node as a failure candidate.
2. Majority voting — in 3-path, values are compared; if one deviates significantly, it is classified as anomalous and the majority value of the other two is adopted.
3. Continuity evaluation — among candidates that pass outlier filtering, the node with the most stable recent history is chosen as primary path, suppressing noise-driven misfailovers.

4.3 AI pre-failure prediction — the core AI application

Low-cost multi-path infrastructure provides the foundation for reliability, but gradual node degradation over time is unavoidable. Early-stage sensor drift, intermittent communication delay, and subtle distribution shifts cannot be detected by single-instant voting logic. This is where AI delivers decisive value.

The pre-failure prediction AI uses three categories of input:

• Multi-path comparative time series — temporal coherence of data simultaneously generated by 2–3 nodes at the same point. Detects patterns where one node drifts persistently from its peers.
• Report metadata time series — response delay, packet loss, retry frequency, boot-time variation, and other subtle signals from the communication layer.
• Environmental context — comparison with patterns of other nodes in the same environment, separating true node degradation from normal environmental variation.

The output is a per-node failure-risk score; when it crosses a threshold, the operator receives a preemptive replacement alert. At that moment the node is still operating normally, so system availability is unaffected; the operator simply replaces it on the next scheduled visit. The limitation of low-cost nodes is offset by system-level reliability — and AI estimates the lifetime of those low-cost nodes, maximizing operational efficiency.

4.4 Fault detection matrix

4.5 Local TMCC — the always-warm fallback

The central TMCC handles all TMCD traffic in normal operation, hosting AI inference and training, integrated control, long-term storage, and FOTA distribution. It runs on cloud or on-prem Linux servers and may be deployed within a closed network depending on site policy.

The Local TMCC is not a separate operational tier but a backup instance of the same software. In normal operation it accepts no TMCD traffic and stays idle, periodically syncing the latest policy, AI inference results, and node-state snapshots from the central TMCC. On WAN disconnect or unresponsiveness, Local TMCC immediately assumes the role of TMCC using the most recent synchronized policy, returning to idle on recovery. Local TMCC itself is operated as three fanless SBCs in triple-redundant configuration — eliminating any single point of failure even within the fallback asset.

4.6 Multimodal autonomous operation — Gangwon mealworm case

This is the AI intelligent-operations layer in its full applied form: multimodal decision-making fusing environmental measurement and imagery autonomously determines and deploys environmental control policy, currently in active operation at the Gangwon container-farm project (mealworm rearing). It demonstrates that TMCS operates not merely as an IoT control system but as an AI platform that produces its own field data and evolves its operations with that data.

// the gangwon site — operational

The 33 containers in Gangwon are operated as mealworm-rearing facilities. Every rearing tray inside every container has a TMCD-CAM installed, reporting tray imagery to TMCC every 10 seconds. The TMCC AI orchestrator analyzes imagery and environmental measurements jointly to perform three core autonomous functions:

1. Autonomous environmental control — Mealworm activity, density, and surface state (moisture, feed remaining) extracted from imagery are combined with environmental measurements (temperature, humidity, CO₂) to determine ventilation, climate, and irrigation policy automatically. Not threshold control but multimodal decision-making with image analysis directly fed into control policy.
2. Harvest-timing prediction — Per-tray time-series imagery estimates growth stage (larva size, activity changes, molt patterns) to predict the optimal harvest moment per tray. The operator receives a forward calendar and can stage labor and logistics in advance.
3. Abnormal-rearing automatic reporting — Rapid mortality, low activity, mold and contamination are detected from imagery; the operator receives per-tray alerts. 33 containers × N trays are monitored automatically 24/7, no manual inspection required.

// what distributed vision infrastructure makes possible

Traditional industrial vision systems demand cameras of several million won and a dedicated vision PC per camera. TMCS replaces both with USD ~20 MCU vision nodes and central TMCC AI inference. The result:

• All-line, all-point visual data — once the cost barrier falls, exhaustive monitoring becomes economical.
• Cross-domain reuse — the same TMCD-CAM hardware deploys without firmware change across heterogeneous domains. Only the AI model is swapped per domain.
• Self-accumulated operational data — many nodes × short cycle × long operation accumulate into datasets that themselves drive continuous improvement of domain-specialized AI models.

Cross-domain vision-AI applications. The Gangwon mealworm case is one domain's validation; the same infrastructure applies to others immediately:

• Smart farm / livestock — analysis of livestock activity, density, surface state, abnormal behavior. Pre-alerting of mortality precursors, early-stage disease spread, abnormal feed/water consumption patterns.
• Logistics / warehouse automation — real-time motion-pattern analysis of conveyors, packaging lines, stacked goods. Detection of jams, drift, falls, stacking errors before incidents occur.
• Pressure and fluid equipment — tracking external geometry, surface state, vibration of tanks, valves, pipes, gates. Early detection of leaks, deformation, cracking.
• Cold chain / food storage — monitoring stack state and condensation/frost patterns inside storage. Multimodal pre-alerting of quality degradation.

All applications share a common pattern: detect before incident, enable human intervention. Domains differ; the mechanism is identical.

The anatomy of a smart node.

5.1 Node taxonomy

TMCD is implemented on self-designed and self-manufactured PCBs equipped with an ultra-light MCU, classified into sensing and control families. Regardless of family or model, every TMCD shares the same communication structure, firmware architecture, and lifecycle management.

5.2 Hardware platform

5.3 The smart-node concept

Every TMCD is more than a sensor terminal or fixed-function actuator. Sensing or control alike, every TMCD is a smart node with equivalent compute. A 160 MHz MCU runs in every node, and every node executes an independent program on its own firmware.

This concept fundamentally distinguishes TMCS from conventional industrial IoT nodes. In typical industrial IoT, sensing nodes are dumb terminals and control nodes are fixed-function devices; firmware is decided at the factory and never changes in the field. Every TMCD is different: any node can be reflashed remotely via FOTA, and the node's role itself can be redefined by firmware swap.

• Role redefinition — same hardware shifts measurement algorithms or control logic via firmware. Threshold control becomes PID; standard measurement becomes domain-specific calibration.
• Per-site optimization — same TMCD model runs different firmware in different domains (smart farm, cold chain, building). Domain-optimal behavior without proliferating hardware SKUs.
• Stronger edge autonomy — local computation at the node enables on-site preprocessing, anomaly detection, and autonomous control logic.

Combined with multi-path deployment, the system can evolve without operational interruption. TMCS nodes are not "fixed-function components" but programmable distributed computers.

5.4 Industrial-grade sensing on entry-level cost

// tmcd-th — sensirion sht40

TMCD-TH adopts the Sensirion SHT40 — a Swiss part that has become a de facto standard in industrial and medical-grade T/H sensing, factory-calibrated at the time of shipment.

• Humidity accuracy ±1.8 %RH (typ.), temperature accuracy ±0.2 °C (typ.)
• Digital I²C interface — minimal noise impact
• Long-term drift < 0.25 %RH/year
• Standard adopted in industrial, medical, HVAC environments

By combining per-cycle complete restart and multi-path voting with SHT40-grade parts, TMCD-TH achieves entry-level cost (~USD 10 class) and industrial-grade measurement reliability simultaneously.

// tmcd-co2 — sensirion scd40

TMCD-CO2 adopts the Sensirion SCD40 — a single-chip-integrated NDIR sensor based on Sensirion's PASens® (photoacoustic) technology.

• CO₂ accuracy ±(50 ppm + 5%), 400–2000 ppm range
• Automatic Self-Calibration (ASC) for long-term stability
• Integrated T/H measurement
• Standard component in horticulture, livestock, indoor air-quality applications

We rejected the common trade-off of lowering sensor grade to reduce node cost. Instead, we integrate global-standard industrial- and medical-grade parts into entry-level price points. Because the measurements themselves are industrial-grade, multi-path voting transcends mere redundancy and operates as multi-validation of high-quality data.

5.5 TMCD-CAM — MCU-based vision sensor

TMCD-CAM integrates a camera module onto the same ultra-light MCU platform as other TMCD models. It is not an industrial machine-vision camera or an embedded GPU board — it is a self-designed PCB at ~USD 20 BoM. This single design changes the order of magnitude of industrial vision and integrates the vision modality across the entire TMCS architecture.

Multi-deployment of low-cost vision. ~USD 20 per camera is a decisive shift in an industrial vision market where single cameras have cost millions of won. TMCS deploys multiple low-cost vision sensors at one point rather than a single high-cost camera. Visual blind spots are covered by multi-perspective imaging; on a single-node failure, other vision nodes maintain the image stream.

Computational division. TMCD-CAM concentrates on collection and transmission; analysis runs on central TMCC. Without heavy inference at the node, USD 20 BoM becomes feasible, and AI models can be updated and replaced from TMCC alone — without firmware change. Domain shifts (mealworm → crops → cold chain) are supported on the same hardware.

5.6 Network multi-path — WiFi and RS485 in parallel

Multi-path is not just a node-level concept. The communication layer itself is subject to the same principle. Different field environments stress different network technologies — RS485 is robust against radio interference but requires wired buses; WiFi is wireless and flexible but degrades in dense industrial environments. TMCS supports both, simultaneously, in the same deployment.

Some TMCD models speak RS485 (TMCD-485 for inverters and serial industrial equipment), others speak WiFi (every WiFi-onboard sensor and vision node), and many sites mix them on the same TMCC. Both are bus-oriented in nature — multiple nodes coexist on the same medium without complex coordination — so the orchestration logic in TMCC treats them identically. From the server's perspective, a node is a node; the transport is an implementation detail of the field.

The practical consequence: a smart farm with metal-clad cold storage can run RS485 inside the chamber and WiFi outside, on the same TMCC, in the same deployment. Channel-level failures (a damaged RS485 wire, a downed AP) are confined to the nodes that depend on that specific medium — the rest of the system continues to report. Like every other layer in TMCS, network resilience is structural, not a configurable feature.

5.7 Zero-config plug-and-play

The core operating philosophy of TMCD is zero configuration. Nodes ship with WiFi credentials embedded in firmware, connect to the site AP the moment power is applied, and begin reporting to TMCC. No IP setup, device registration, or field-engineer intervention is required. TMCC auto-recognizes a new UID on first report and enrolls the node. Node replacement follows the same principle: remove the failed node, plug in the new one, and TMCC enrolls it into the multi-path pool of that point.

5.8 TMCP communication protocol

All data exchange between TMCD and TMCC uses TMCP (TERACODE Multi-path Control Protocol), defined as a 32-byte fixed-length binary structure carried over REST or socket transport.

Why multi-path works.

6.1 Availability model

TMCS reliability is grounded not in component MTBF specs but in the mathematical probability of multi-deployment. Availability A is defined as:

where MTBF is mean time between failures and MTTR is mean time to repair. System unavailability Q = 1 − A is the probability that the system is not operating correctly at an arbitrary moment. Node unavailability is denoted Q; nodes covering the same point are assumed statistically independent.

6.2 Multi-path configuration math

Quantitative comparison for individual node Q = 0.01 (1%) and the more conservative Q = 0.05 (5%):

Two facts emerge. First, multi-path itself reduces system unavailability by orders of magnitude as node count grows. Second, 2-of-3 voting shows higher unavailability than 1-of-N — the cost of consensus. Voting buys two advantages a simple-availability scheme cannot:

• Outlier defense — a single anomalous report is neutralized by the other two. 1-of-N has no basis to choose which value to trust.
• Silent-failure detection — nodes that respond but with wrong values are detected by majority decision. 1-of-N has no mechanism for this.

6.3 Versus traditional PLC

Cost-efficiency of reliability. TMCS 2-path achieves an unavailability matching a single industrial PLC (~10⁻⁴) at ~USD 20 of parts. Same reliability, an order-of-magnitude cost difference.

Economy of multi-path scaling. A redundant PLC doubles cost; TMCS adds a node for ~USD 10–20. TMCS 3-path (1-of-3) achieves 10⁻⁶-class unavailability at ~USD 30 — the same order as redundant PLC at one-hundred-thousandth the cost.

Different reliability dimensions. Raw availability does not capture all of TMCS's strengths. PLC systems lack defense against node outliers (sensor drift, noise); TMCS 3-path absorbs them through voting. PLCs accumulate software-aging defects; TMCS preempts them at every cycle through complete restart. Beyond that, TMCC AI detects failure precursors in multi-path time-series patterns and triggers preemptive replacement — adding a preventive availability dimension that reactive PLC systems cannot match.

6.4 Independence — the assumption behind the math

The mathematical advantage above requires that nodes covering the same point fail statistically independently. TMCS structurally secures independence through five design principles:

• Independent power — each node at the same point is supplied from a separate power line. A single surge cannot affect multiple nodes simultaneously.
• Physical separation — nodes are physically separated within the same point. Local impact, flooding, condensation, or heat are less likely to fail multiple nodes simultaneously.
• EMC certification — KC EMC immunity to ESD, surges, and radiated RF reduces EMI-induced common-mode failure.
• Multi-AP / multi-infrastructure — wireless communication is itself subject to the multi-path principle. Nodes at the same point connect to different WiFi APs.
• Cycle phase offset — nodes operate boot/report cycles offset from one another, so the probability of all nodes booting simultaneously is structurally low.

Complete independence is unattainable in any system. Residual common-mode possibilities are (a) site-wide power loss — mitigated by UPS and dual power distribution; (b) systemic defect in a specific firmware version — mitigated by phased FOTA rollout; (c) WAN failure — absorbed by Local TMCC fallback. Multi-path is applied consistently across nodes, APs, power, and servers — eliminating single points of failure across all layers.

6.5 Per-cycle self-healing in practice

TMCS adopts complete restart at every reporting cycle as a primary reliability mechanism — a preemptive response to embedded software aging. Where prior software-rejuvenation work uses checkpointing to minimize the restart gap, TMCS takes a different approach: restart itself is absorbed as a normal part of the cycle. Cold-boot is ~3 s; TMCC report exchange is ~1 s. Together they form one cycle. From the node's perspective every cycle is the deterministic pattern boot → report → restart-for-next-cycle; there is no separation between "operating" and "restarting." Cycle length is configurable to ≥ 5 s by site requirement; the Gangwon container farm uses 10 s.

6.6 Failure mode coverage

Why we don't use a broker.

The dominant pattern in distributed IoT today is a broker (MQTT, AMQP, or a cloud-vendor equivalent like AWS IoT Core) sitting between devices and the application layer. Brokers solve a real engineering problem — they shield devices from the chaos of NAT and intermittent connectivity by acting as a meeting point. But solving NAT this way creates new problems that are arguably worse.

7.1 The brokered architecture's hidden costs

• The broker becomes the single point of failure. If the broker is down, the entire fleet goes silent. Clustering brokers for HA is non-trivial — split-brain handling, session replication, queue durability all become operational concerns.
• Persistent stateful sockets. Every device maintains an always-on TCP connection. On flaky networks, reconnection storms can bring the broker down. Connection state must be tracked at scale.
• QoS and session management overhead. Exactly-once delivery semantics (QoS 2) requires four-way handshakes and message persistence. At fleet scale this becomes meaningful operational load.
• Vendor lock-in. Cloud broker services (AWS IoT, Azure IoT Hub) come with per-message pricing that scales linearly with fleet size — a structural cost that doesn't go away.

For mission-critical deployments where partial network failure is the norm rather than the exception, we view the brokered model as a structural step backward. TMCS treats NAT as a non-issue by reversing the direction of communication itself — devices initiate outbound, servers respond. There is nothing in the middle to fail, queue up, or charge per message.

7.2 Side-by-side comparison

7.3 When brokers still make sense

To be fair: brokers are excellent when devices need to subscribe to high-frequency event streams from each other, or when bidirectional async messaging is the dominant traffic pattern. Pub-sub messaging between many producers and many consumers is what MQTT was designed for, and TMCS makes no claim to replace it there.

But for distributed control — where the dominant pattern is "device reports state, server returns command" — the broker is unnecessary infrastructure. We removed it.

What 180 days of production showed.

8.1 The deployment

8.2 Operational results

// non-stop operation

Over 180 continuous operating days, system-level unplanned failover events totaled zero. Transient resets at individual nodes and momentary network drops were absorbed by multi-path structure and Local TMCC fallback at the system level, without affecting control continuity. Cumulative system availability across the deployment exceeded 99.99%, with typical end-to-end response time (TMCD report → TMCC decision → TMCD ack) under 150 ms across varied network conditions.

// periodic self-healing

All 495 nodes performed per-cycle complete restart normally throughout. At a 10-second cycle, each node performed approximately 1,555,200 self-resets over 6 months — and across all of them, no symptoms of cumulative software-aging defects were observed.

// fota remote update

Multiple firmware updates were performed remotely via central TMCC during operation. Bulk updates across all 495 nodes completed without site visit, with per-node sequential update preventing same-point nodes from being in restart simultaneously.

8.3 The cost story

The Gangwon project is a rare case with measured rather than estimated comparison values — the same client received a PLC-based design quote before TMCS was selected.

Same specification, same site, same client. The original PLC-based design used industrial PLC I/O modules and SCADA per container; redesigning the same function and the same availability target with TMCS realized the 89% reduction. The freed KRW 134M was redirected to additional containers and operational infrastructure.

The 89% reduction was not achieved by sacrificing availability. Unplanned failovers totaled zero across 180 days; TMCS 3-path achieves the same order (10⁻⁴ ~ 10⁻⁶) as a single PLC, while additionally providing outlier defense and silent-failure detection that PLC does not. Availability was held or improved while cost compressed to ~1/9.

What's certified, what's contained.

Security in industrial control isn't a checkbox; it's a posture made of choices. Here's an honest breakdown of where TMCS is today.

9.1 What's certified today

• KC EMC industrial certification — registration R-R-TRCD-TMCD-Sensor (issued 2026.01), test report GCL-EK2512-139, all items pass. This covers ESD immunity (±8 kV air discharge), surge immunity (±2 kV line-to-ground), and radiated RF immunity (80 MHz–6 GHz, 3 V/m) — the actual electromagnetic environment of an industrial site, not a lab.
• Closed-network operation — the Gangwon production deployment runs entirely inside a closed network. No TMCD has direct internet exposure; all field traffic terminates inside the customer's network perimeter.
• Outbound-only device communication — TMCDs never accept inbound connections. There is no port to scan, no service to exploit, no listener to compromise. The attack surface on a TMCD is structurally smaller than on any device that accepts inbound traffic.
• Signed FOTA — firmware updates are cryptographically signed and verified before flash. An attacker on the network cannot push arbitrary firmware to a node.

9.2 What's contained by architecture

Several risks that other IoT systems have to mitigate explicitly, TMCS contains by structural design:

• No broker = no broker compromise. There is no central message bus to attack, no shared topic namespace to leak across tenants, no QoS state to corrupt.
• No persistent socket = no session hijack. Every transaction is independent; there is no long-lived connection state for an attacker to take over.
• Stateless server = limited blast radius. Compromising one TMCD reveals only that node's identity; there is no shared session context that grants access to the fleet.
• Multi-path = single-node tampering is detected. Anomalous values from a tampered node are filtered by the same majority voting that filters sensor drift. Silent compromise of a single node degrades to silent compromise of one of three — and the AI predictive layer flags the anomaly.

One architecture, two markets.

The most important property of TMCS is that a single architecture reconfigures strategically to the requirements of the field — enabling simultaneous attack on two very different markets.

Market 01 — Economical alternative to PLC

In smart farms, cold chains, and food-processing environments where continuity of every sensing/control point is required, TMCDs are deployed in 2–3-path redundancy. The Gangwon project measured the validity of this configuration: a KRW 150M PLC-based quote compressed to KRW 16M of TMCS execution. Availability was maintained or improved while cost fell to ~1/9 of PLC.

TMCS is not a replacement for PLC in heavy industry. It is the economical alternative when site requirements do not demand PLC-grade determinism and certification — which is most distributed IoT environments.

Market 02 — A new market, created

The deeper value. Winter freeze prevention in warehouses, summer climate management in greenhouses — losses are not catastrophic when something fails, but uncorrected they accumulate economic damage. To date, automation cost outran benefit, and these areas remained manual. At ~USD 30 of materials, the equation changes.

This is the canonical structure of disruptive innovation. While incumbent solutions deliver excess performance at premium prices, TMCS attacks the incumbent low end and the unautomated frontier simultaneously. Both markets share the same node, the same TMCC, and the same firmware architecture — so learning in one market transfers directly to improvement in the other.

What we deliver, technically

Primary contributions are multi-path low-cost reliability, AI pre-failure prediction, and AI multimodal autonomous operation. Multi-path provides the structural foundation for PLC-grade availability at ~25% of PLC cost. AI prediction compensates for the limits of low-cost nodes through preemptive replacement guidance. Multimodal AI implements domain-level autonomous operation atop both. Two-tier direct-connect architecture, per-cycle self-healing, hierarchical fallback, and the smart-node platform are the structural enablers underneath. 495 nodes × 180 days × KRW 150M → 16M is the production-validated proof.

What's next.

TMCS v1.0 is in production. The roadmap below outlines what we are building on top of the validated foundation.

Near-term — model refinement & instrumentation

• AI model maturity — current predictive analytics operates at a baseline (statistical time-series anomaly detection + convolutional vision classification). Time-series Transformers, Isolation Forest-based multivariate detection, and domain-adaptive self-learning are in development.
• Operational instrumentation — finer-grained metrics on failover response time, node-failure counts, and Local TMCC transition events.
• Independence-assumption validation — empirical fitting from longer-term operational data: simultaneous-failure distributions, common-mode frequencies, confidence intervals.

Mid-term — domain expansion

• Cross-domain validation — cold chain, smart buildings, aquaculture deployments to follow the smart-farm baseline.
• Domain-adaptive transfer — same hardware, AI model swapped per domain (mealworm → strawberry → distribution).
• Federated learning across sites — preserving site-level data privacy while improving shared models.

Long-term — scale & security

• Single-site scaling — TMCC orchestration validated beyond a few thousand nodes.
• Reinforcement-learning policy derivation — environmental control policies trained directly from operational outcomes.

The team behind TMCS.

TERACODE Intelligence Inc. is a Seoul-based engineering company building distributed control systems for environments where conventional industrial automation has been priced out. We don't sell platforms or licenses — we build systems that go into the field and stay there. TMCS is our flagship technology.

Founder & engineering lead

TMCS reflects the design philosophy of our founder and CEO, J. Seo, formerly Senior Vice President and Head of the Software R&D Center at Samsung Electronics. Over 35 years he has built control and networking systems across factory automation, military-grade reliability protocols, and large-scale urban infrastructure, and he holds multiple registered patents in control networking and embedded fieldbus integration. The architectural choices that define TMCS — stateless transactional model, multi-path as a structural primitive, AI integrated into the reliability mechanism rather than bolted on — are the result of three decades of watching industrial systems fail in the ways industrial systems actually fail.

How we operate

We run lean by design. Our infrastructure runs on underclocked microcomputers and commodity boards; we turn off peripherals we don't need to reduce heat, power, and attack surface. We deploy with the customer's engineering team, not through a sales channel. When a board fails in Gangwon, we know about it before the operator does — and so does the AI that's predicting the next one.

Working with us

We're a small team and we take on a small number of deployments per year. If your environment is one where automation cost has historically outrun benefit — or where existing automation has been paid for in PLC margins that no longer make sense — we'd like to talk. The first conversation is technical, not commercial.