Technology
The edge AI stack: from signal to decision, inside the system you already run.
RETONAI combines embedded compute, firmware, edge AI and cybersecurity to add intelligence to existing cameras, sensors, machines and industrial infrastructure.
Architecture at a glance
Six layers, one system.
Every retrofit passes through the same six layers, from the equipment you already own to the decision it can now make. Each layer is engineered with the constraints of the next in mind.
- 01
Existing system
Cameras, sensors, machines and controllers already in service.
- CCTV
- PLC
- sensors
- field machinery
- 02
Interfaces & sensing
Video, digital, analogue and industrial interfaces, plus added sensors.
- MIPI CSI
- Ethernet
- RS-485
- CAN
- Modbus
- 03
Edge compute
Right-sized compute for the workload: MCU, MPU, NPU, GPU or FPGA.
- MCU
- SoC
- NPU
- GPU
- FPGA
- 04
Firmware & runtime
Embedded Linux or RTOS, BSP and drivers that keep the platform maintainable.
- Embedded Linux
- RTOS
- BSP
- drivers
- OTA
- 05
AI & decision
Computer vision, ML and anomaly detection running on the device.
- computer vision
- TinyML
- quantisation
- sensor fusion
- 06
Deployment & lifecycle
Security, telemetry, updates and monitoring across the fleet.
- secure boot
- signed OTA
- telemetry
- recovery
View technical architecture details
Existing System
Installed cameras, controllers, sensors and machinery — the starting point for the retrofit.
Assess condition, interfaces, and remaining lifecycle to see what the system can support.
Power · compatibility · documentation · lifecycle
A documented baseline of what exists and what it can carry.
Assembly progress: 17%
Engineering pillars
Four disciplines, engineered as one.
The stack above is delivered by four engineering disciplines that RETONAI runs as a single accountable team, from silicon to software.
Hardware & Compute
- MCU
- MPU
- SoC
- FPGA
- NPU
- GPU
- PCB
Compute and electronics are selected according to workload, latency, power, thermal and lifecycle requirements.
Firmware & Runtime
- Embedded Linux
- RTOS
- BSP
- Drivers
- OTA
Firmware connects physical hardware, sensing, communications and AI into a maintainable embedded platform.
AI & Intelligence
- Computer vision
- ML
- TinyML
- Quantisation
- Sensor fusion
Models are adapted for real-world memory, latency, power and offline-operation constraints.
Security & Lifecycle
- Root of trust
- Secure boot
- Device identity
- Signed OTA
Security is engineered across hardware, firmware, AI assets, communications and device lifecycle.
Platform selection
How we choose the right compute platform
Platform selection is driven by system constraints rather than by a preferred processor or accelerator. Seven questions decide the platform before any part number is chosen.
| Constraint | Engineering question |
|---|---|
| Latency | How quickly must the system respond, from sensor to action? |
| Power | What continuous and peak power budget is available? |
| Thermals | Is passive or active cooling possible inside the enclosure? |
| Memory | Can the model and runtime fit locally? |
| Connectivity | Must the system operate offline? |
| Lifecycle | How long must components remain supportable? |
| Cost | What retrofit cost is commercially viable at fleet volume? |
These constraints determine whether an MCU, MPU, NPU, GPU, FPGA or hybrid architecture is appropriate.
Compare MCU, NPU, GPU and FPGA approaches
| Platform | Strength | Constraint | Typical use |
|---|---|---|---|
| MCU | Lowest power and unit cost; deterministic control loops. | Small models only; limited memory and no operating system. | Threshold and anomaly tasks, sensor interfaces, control. |
| MPU / SoC | Embedded Linux, connectivity, storage and moderate inference in one platform. | Power and heat rise with load; needs a maintained BSP. | Gateways, cameras with light vision, hybrid retrofits. |
| NPU / AI accelerator | Efficient fixed-model inference per watt. | Operator and model-format support must be checked before the architecture is fixed. | On-device detection on cameras and sensors. |
| GPU module | Heavier or evolving models; high-throughput vision. | Highest power and heat; enclosure, cooling and cost. | Multi-stream vision, workloads that change often. |
| FPGA | Deterministic pipelines with hard latency limits; custom interfaces. | Development effort and toolchain dependence. | Fixed signal pipelines, acceleration with tight timing. |
| Hybrid (MCU + Linux module) | Control stays deterministic while inference runs beside it. | Two platforms to maintain and update. | Most retrofits of controllers and machines. |
No platform is universally better. We profile the workload on candidate hardware and choose from the measured evidence.
What we measure for each constraint
Latency
Time from signal to response.
The longest response time the application can accept, and how much variation it tolerates.
We time the full path from sensor input to system action on the real hardware.
Model size, accuracy, processor choice and power.
Power
Energy the system can draw, continuously and at peak.
The continuous and peak power the platform must stay within.
Bench measurement of the real workload on the target hardware.
Compute performance, heat, and battery or supply size.
Memory
Everything has to fit in the memory on board.
Model size, runtime footprint and working memory available on the device.
Measured memory use under real workload conditions.
Model accuracy, caching, and room for other tasks.
Thermals
Heat the enclosure can shed without slowing down.
The highest sustained temperature allowed inside the enclosure.
Continuous-load soak test inside the real enclosure.
Sustained performance, enclosure design and cooling cost.
Lifecycle
Years the platform must stay supportable.
How many years parts and updates must remain available.
Manufacturer lifecycle data checked against the fleet's service life.
Component choice, unit cost and long-term maintenance risk.
Cost
Economics that hold up at fleet scale.
The per-unit cost ceiling at the expected volume, often set in S$ for Singapore programmes.
Bill-of-materials costing checked against supplier quotes at volume.
Compute capability, feature scope and margin at scale.
Platforms and silicon we work with
PLATFORM-INDEPENDENT ENGINEERING
Product names and logos are trademarks of their respective owners. They are shown to identify technologies used or evaluated in our engineering work and do not imply partnership, endorsement, distribution or reseller status.
We do not design around a preferred vendor. We select around the system that must succeed.
Security architecture
Security through every layer
Security is designed in from the first decision, not bolted on at the end. Threat modelling comes first; the nine resulting controls fall into four concerns.
Trust
The device proves who it is.
- Hardware root of trust
- Device identity
- Protected key storage
Integrity
Only verified software boots and installs.
- Secure boot
- Signed firmware
- Secure OTA
Protection
Data, models and processes stay contained.
- Runtime hardening
- AI model and data protection
- Interface protection
Resilience
The fleet detects, recovers and stays supportable.
- Monitoring
- Recovery
- Lifecycle assurance
Explore all security controls
Threat Modelling
We map what could go wrong before anything is built.
Covers layers: System → Deploy
Weak points that only show up after deployment.
A structured threat review of hardware, firmware, data and network paths during design.
Design review against the written threat model before build sign-off.
Reviewed again whenever the architecture or the deployment changes.
Interface Protection
Only the ports, protocols and connections the retrofit needs stay open.
Covers layers: I/O → Compute
Someone tampering with sensors or injecting false signals through an exposed connection.
Exposed ports and protocols limited to what is required; physical interfaces authenticated where possible.
Interface inventory and access testing against the design.
Exposure reviewed at every hardware revision.
Root of Trust
The device only starts software it can verify.
Covers layers: Compute → Runtime
A tampered boot chain running unauthorised firmware.
Hardware root of trust and verified boot on the chosen compute platform.
Boot-chain validation on the target hardware.
Re-validated on every hardware or bootloader change.
Device Identity & Keys
Every device carries its own identity and protected keys.
Covers layers: Compute → Deploy
Cloned or impersonated devices inside the fleet.
Unique per-device identity and protected key storage from provisioning onward.
Identity and key-handling audit before fleet rollout.
Key rotation and revocation maintained for the life of the fleet.
Runtime Hardening
Software runs with the minimum access it needs.
Covers layers: Runtime → AI
A compromised process reaching further than it should.
Least-privilege execution and isolated workloads in firmware and runtime.
Configuration review and privilege-escalation testing.
Hardening baseline reapplied after every runtime or model update.
Data & Model Protection
Sensor data and AI models stay encrypted, on the device and in transit.
Covers layers: I/O → Deploy
Exposure of sensor data, model weights or local communications.
Encryption at rest and in transit, limited to what actually needs to leave the device.
Data-flow review of what leaves the device and how it is protected.
Scope reassessed whenever the data flow changes.
Signed Updates
Firmware and model updates are verified before they install.
Covers layers: Runtime → Deploy
Unauthorised or corrupted updates reaching a fielded device.
Cryptographically signed update packages, checked before installation.
Signing and rejection tests with deliberately invalid packages.
Signing keys and update pipeline maintained for the life of the programme.
Monitoring & Recovery
Abnormal behaviour is detected and the device can restore itself.
Covers layers: AI → Deploy
A failed update or compromised device going unnoticed in the field.
Runtime monitoring with a fallback to the last known-good state.
Fault-injection testing of the monitoring and recovery path.
Monitoring reviewed against real fleet telemetry once deployed.
Lifecycle Assurance
Components and dependencies are tracked for the life of the fleet.
Covers layers: System → Deploy
Unsupported parts or unpatched vulnerabilities building up over the years.
Dependency and component tracking against vulnerability disclosures and end-of-life dates.
Periodic vulnerability and lifecycle review of the component register.
Register maintained on a fixed schedule for the life of the fleet.
From the first interface to the final update, every trust boundary is designed on purpose.
Validation
How we prove the system works
We validate the complete system on the target hardware, not just the AI model, and every published result carries its test conditions.
- 01
Assess
Baseline the existing system, its interfaces and its constraints.
- 02
Prototype
Build the compute, firmware and model on a representative unit.
- 03
Measure
Test on the target hardware, inside the real enclosure.
- Accuracy
- Latency
- Power / thermal
- Memory
- Recovery
- 04
Secure
Verify boot, identity, updates and hardening before rollout.
- 05
Deploy
Pilot on representative units, then scale with updates and monitoring.
Also measured: false positives · false negatives · throughput · availability · boot and recovery time · network and storage requirements.
Full evidence domains and proof record
Target evidence
Performance Envelope
Speed, power, memory and heat, measured on the real device under real load.
End-to-end latency
The full path from sensor to action, not just the model.
Power consumption
Real continuous and peak draw, not the chip datasheet.
Memory utilisation
Actual footprint with the real runtime and model.
Thermal behaviour
Sustained temperature inside the real enclosure.
Model Behaviour
How accurate the AI is on data that looks like the real environment, including false alarms and misses.
Accuracy on representative data
Measured on data that resembles the deployment, not a curated benchmark.
False-positive rate
How often the system flags something that is not there.
False-negative rate
How often it misses something it should have caught.
Operational Readiness
How fast the device recovers, and the network and storage it truly needs.
Boot and recovery time
Time back to service after a restart or a failed update.
Network requirements
The bandwidth and connectivity the device really needs.
Storage requirements
Space for models, logs and staged updates over time.
Assurance & Lifecycle
Security test results, part availability, and how long the platform stays supported.
Security-test results
Results from the security design, validated on this deployment.
Component availability
Confirmed supply for the fleet's volume and service life.
Projected platform lifecycle
Years of expected support before parts reach end-of-life.
Every published result includes
Result status
Published after target validation
A result only means something when the hardware, conditions, dataset, method and limitations are published beside it. Until target testing is complete, we publish no illustrative numbers.
Representative applications
Where the stack goes to work
Three representative retrofits show the same six layers applied to different equipment. Maturity is labelled; none is a completed customer deployment.
Existing video systems
- CCTV camera
- Edge compute
- Local vision AI
- Alert / event
Industrial equipment
- Sensor / PLC
- Edge gateway
- Anomaly detection
- Operational action
Edge AI retrofit →Embedded firmware →Embedded cybersecurity →
Agriculture
- Camera / sensors
- Edge AI
- Crop and environmental intelligence
Explore all five applications layer by layer
Five real-world applications. One engineering method. Pick an application, then step through the six layers that turn a raw signal into a decision.
Video Security
Retrofit intelligence into existing camera infrastructure.
Existing System
We start with what is already installed and find out what it can support.
Check condition, interfaces and remaining service life.
Missing documentation, ageing connectors, mixed hardware versions.
Available interfaces, spare compute and power.
- Security across every layer
- Signed updates
- Recovery
- Observability
- Lifecycle support
Illustrative signal path for the selected scenario — not a record of an actual customer deployment.
Inside the RETONAI R&D lab
Four live investigations in edge vision, bioacoustics, agriculture and cyber-physical security. Results are published once validated on target systems.
GreenShield AI
On-device vision to guide fertiliser and pesticide dosing for smallholder farms.
Can on-device vision give reliable, field-specific dosing guidance across varied crops and soils?
Smallholder plots with variable light, crop density and connectivity.
Guidance accuracy against agronomist-reviewed ground truth on representative plots.
Proof of concept in development.
Bioacoustic Signal Decoding
Edge audio that turns barking and other animal sounds into welfare signals.
Can on-device audio models reliably decode vocalisations into interpretable behavioural signals?
Farms and households with variable background noise.
Classification agreement with expert-reviewed audio samples.
Proof of concept in development.
Edge Video Intelligence
On-device detection for the cameras you already have, cabling and workflows untouched.
Can existing camera fleets gain reliable on-device detection without new cabling or workflows?
Installed analogue and IP cameras in varied lighting.
Detection consistency across representative footage and installed hardware.
Proof of concept in development.
Cyber-physical Anomaly Detection
Matching network activity with sensor and controller behaviour to spot suspicious commands early.
Can correlating network traffic with physical telemetry reliably surface suspicious commands and equipment risk?
Industrial control networks mixing legacy and modern equipment.
Correlation accuracy against known-good and deliberately anomalous scenarios.
Proof of concept in development.
These projects are active RETONAI research and development initiatives. Descriptions indicate intended research direction and do not represent validated performance, commercial availability or completed field deployment.
Frequently asked questions
What is an edge AI retrofit?
Engineering work that adds on-device AI to equipment already in service: added sensing where needed, right-sized compute, integrated firmware, a model validated on that hardware and the security controls a connected device needs. The existing asset keeps doing its job.
Why run AI at the edge instead of in the cloud?
Latency, privacy, bandwidth and resilience. On-device inference decides in milliseconds without a network round-trip, keeps raw video or sensor data on site, needs far less bandwidth, and keeps working when connectivity does not.
What is RETONAI?
RETONAI PTE. LTD. is a Singapore electronics R&D and cybersecurity software company. We retrofit the cameras, sensors, controllers and machines you already operate with on-device AI and device security, working as one team from silicon to software.
What is an NPU and why does it matter for edge AI?
An NPU (neural processing unit) is a processor built specifically to run neural networks efficiently. It matters at the edge because it executes models locally at low power and low latency — no cloud round-trip — which is what makes adding AI to existing devices practical. We build on platforms such as NVIDIA Jetson and NPU/TPU-class accelerators.
NPU or GPU for on-device inference — which is right?
NPUs usually win for fixed, power-constrained on-device inference; GPUs suit workloads that change often or need heavy general-purpose parallelism. In retrofit work the decision comes down to power, latency, unit cost, and the shape of the model — we profile the workload first and pick the target hardware from the evidence.
Can AI run on the processor already inside my system?
Sometimes. If the existing controller has spare compute and the workload is small, inference can run there. More often the existing processor handles I/O and control while a small added compute module handles inference — we assess this during feasibility rather than assuming either answer.
When does a retrofit need new hardware?
When the existing system has no spare compute, no viable interface for the required sensing, or a power/thermal budget that cannot support the workload. We size the smallest addition that meets the requirement rather than defaulting to new hardware.
How do you select between MCU, NPU, GPU, and FPGA?
From the workload backward: model size and type, required latency, power and thermal budget, unit cost at fleet scale, and how fixed or changeable the workload is. FPGAs suit fixed, deterministic pipelines; NPUs suit efficient fixed-model inference; GPUs suit heavier or evolving models; MCUs suit small, simple models with tight power budgets.
How are firmware and AI models updated securely?
Through signed update packages verified against a device identity and root of trust before installation, with a recovery path if an update fails. The specific mechanism depends on the compute platform and connectivity available.
Can raw video or audio remain on the device?
On-device architecture can keep raw video, audio, or sensor data local while transmitting only approved events or metadata. The final data flow depends on the system architecture and operational requirements.
How do you validate performance on real field data?
We test on the target hardware under representative operating conditions — not only in a development environment — and measure accuracy, false-positive/negative rates, latency, and power on that hardware before recommending scale.
What happens when a component becomes obsolete?
We select components with projected lifecycle availability in mind and document alternates during architecture design, so a fleet already in the field has a defined upgrade or substitution path rather than an unplanned redesign.
How do you recover a device after an interrupted update?
Through a fallback boot path that reverts to the last known-good firmware and model if an update does not complete or verify correctly, so a failed update does not leave a fielded device inoperable.
Have existing hardware that needs intelligence?
Tell us what hardware, interfaces and constraints you are working with. We can help evaluate whether an edge AI retrofit is technically practical.
Assess your system →Your next breakthrough may already be installed.
Please share your current operations. We will assess their potential and provide a straightforward engineering perspective.
hello@retonai.comWe use the information you submit to assess and respond to your enquiry. Please read our Data Protection Notice.
By submitting, you acknowledge our Data Protection Notice and agree to our Terms of Use.
Last updated