Edge Intelligence for Smart Cities: FPGA and TinyML Infrastructure

Last Updated May 24, 2026

FPGA TinyML smart cities represent a new architectural model for urban digital infrastructure. Instead of sending every signal to centralized cloud platforms, cities can increasingly process information locally, where data are generated, decisions must be made quickly, and infrastructure must continue operating under physical, bandwidth, energy, privacy, and governance constraints.

Smart-city systems are often described through sensors, dashboards, analytics platforms, connected infrastructure, and automated optimization. But the deeper question is architectural: where should intelligence live? Should traffic signals, water systems, environmental monitors, street lighting, transit infrastructure, and grid devices depend primarily on remote cloud processing, or should more decision-making capacity be distributed across embedded systems at the edge?

FPGA TinyML smart cities answer that question by combining three related ideas. First, embedded systems provide dedicated computation inside physical infrastructure. Second, TinyML enables machine-learning inference on ultra-low-power devices. Third, field-programmable gate arrays, or FPGAs, provide configurable hardware acceleration for deterministic, parallel, low-latency workloads. Together, these technologies make it possible to place intelligence closer to the physical systems that need it.

The objective is not simply automation. It is resilient, accountable, and scalable intelligence that can operate reliably under the operational constraints of real cities: network outages, limited power budgets, sensor noise, harsh environments, public accountability, security requirements, long equipment lifecycles, and the need for traceable updates. Edge computing is therefore more than a performance optimization. It is a structural redesign of how urban systems collect, interpret, and respond to information.

This article examines FPGA TinyML smart cities as a serious embedded-and-edge systems architecture. It focuses on why cloud-only models are insufficient for many public infrastructure contexts, how FPGAs and TinyML strengthen local intelligence, why governance must be built into device fleets, and how cities can design edge infrastructure that is not merely “smart,” but resilient, auditable, secure, and publicly accountable.

FPGA TinyML Smart Cities as an Architectural Shift

FPGA TinyML smart cities represent a shift from centralized observation to distributed intelligence. In earlier smart-city visions, sensors often functioned as data collectors. They measured air quality, traffic volume, energy use, water pressure, noise levels, pedestrian movement, or equipment condition, then transmitted those signals to centralized databases or cloud platforms for analysis. This model works well for long-term analytics, planning dashboards, historical reporting, and cross-system optimization.

But it is not sufficient for every urban infrastructure problem. Many public systems operate in real time. A traffic signal cannot wait for a remote analytics platform to decide whether an emergency vehicle is approaching. A pump controller cannot depend on a cloud round trip to detect mechanical anomaly. A bridge-monitoring system cannot always stream raw vibration data continuously. A water-quality device may need to detect contamination locally when connectivity is degraded. A transit-safety system may need deterministic response in milliseconds.

The edge changes this architecture. Edge systems process information near the point of generation. They reduce latency, lower bandwidth use, preserve privacy by avoiding unnecessary raw-data transmission, and improve resilience during network disruption. In public infrastructure, those advantages are not merely technical. They shape safety, continuity, governance, and trust.

FPGAs and TinyML extend this edge model. TinyML allows machine-learning models to operate on extremely constrained devices. FPGAs allow engineers to accelerate specific workloads in configurable hardware. Together, they support embedded intelligence that is small, efficient, fast, and adaptable. The result is a city architecture in which intelligence is not trapped in a remote cloud. It is distributed across the physical systems that make urban life function.

This distributed model requires discipline. Public infrastructure cannot be treated like a consumer gadget ecosystem. Devices may remain in the field for years or decades. They must be maintainable, updateable, secure, auditable, and resilient. A city that deploys thousands of edge-AI nodes without lifecycle governance may create a new form of technical debt: invisible, distributed, hard to inspect, and difficult to repair.

FPGA TinyML smart cities therefore should not be understood as a race to automate everything. They are an argument for placing computation responsibly: close enough to the physical world to be useful, but governed well enough to remain trustworthy.

Back to top ↑

Embedded Systems in Urban Infrastructure

An embedded system is a specialized computing system designed to perform a dedicated function within a larger mechanical, electrical, or cyber-physical system. Unlike general-purpose computers, embedded systems operate under constraints of reliability, determinism, energy efficiency, cost, environmental durability, and long-term maintainability.

Modern cities already depend on embedded systems. They are present in traffic signal controllers, transit signaling, water meters, pump stations, power-grid monitoring devices, street lighting, building-management systems, parking systems, environmental sensors, surveillance equipment, elevators, emergency communications, wastewater treatment, and public safety infrastructure. These systems often operate continuously in physical environments where failures can produce immediate real-world consequences.

The embedded nature of these devices matters because they sit at the boundary between digital logic and physical action. A software update may change how a traffic signal behaves. A sensor calibration error may affect air-quality reporting. A failed controller may disrupt water pressure. A misconfigured edge model may produce false alarms or missed detections. An unpatched device may become a cyber risk. Embedded systems do not merely compute; they participate in urban operations.

For this reason, urban embedded systems must be designed around several requirements:

• Reliability: devices must operate consistently under field conditions.
• Determinism: safety-relevant systems often need predictable timing behavior.
• Energy efficiency: many devices operate under strict power budgets or remote deployment constraints.
• Maintainability: infrastructure must support updates, diagnostics, and repair over long lifecycles.
• Security: devices must resist unauthorized access, tampering, and unsafe updates.
• Auditability: public systems need logs, version control, and traceable decisions.
• Interoperability: devices must communicate with broader infrastructure systems.

Embedded systems are therefore not peripheral to smart cities. They are the operational backbone. The quality of urban digital infrastructure depends on the quality of the embedded systems beneath it.

Urban resilience begins with these devices. If they are fragile, opaque, or ungoverned, the city becomes fragile at scale.

Back to top ↑

Why the Cloud Alone Is Insufficient

Centralized cloud platforms are powerful. They support large-scale storage, systemwide analytics, historical modeling, cross-domain dashboards, simulation, machine-learning training, long-term optimization, and integration across agencies. Cloud infrastructure is essential for many smart-city functions.

But cloud systems cannot replace local decision-making where latency, uptime, safety, privacy, and bandwidth constraints are critical. In FPGA TinyML smart cities, the edge of the network is where many operational decisions must occur.

Exclusive reliance on cloud processing introduces several structural limitations:

• Latency: round-trip communication can be too slow for real-time infrastructure control.
• Bandwidth: high-sensor environments can generate more raw data than networks can efficiently transmit.
• Connectivity dependence: cloud-only systems degrade when networks are congested, damaged, or unavailable.
• Privacy exposure: transmitting raw video, audio, mobility, or household data can increase surveillance risk.
• Systemic concentration: centralized platforms can become single points of failure or control.
• Cost: continuous data transmission and cloud inference can create high operating expenses.
• Governance complexity: data crossing jurisdictions, vendors, agencies, and platforms complicates accountability.

Critical infrastructure systems cannot depend entirely on remote processing. A bridge sensor should not need to stream every vibration signal to a distant data center before detecting a structural anomaly. A street intersection should not rely entirely on cloud availability for pedestrian safety. A water-pump station should be capable of local protective behavior when network connectivity fails. A building energy system should be able to respond locally to occupancy and demand conditions.

Edge computing is therefore not simply an efficiency improvement. It is an architectural necessity for resilient infrastructure. The cloud remains important, but it should be complemented by local intelligence, regional aggregation, and robust governance across the full compute continuum.

The strongest smart-city architectures are not cloud-only and not edge-only. They place each task where it belongs.

Back to top ↑

The Edge-Fog-Cloud Continuum

Urban infrastructure computing should be understood as a continuum. At one end are tiny embedded devices: sensors, microcontrollers, signal processors, FPGA accelerators, and low-power inference nodes. In the middle are local gateways, roadside units, substations, building controllers, pump-station controllers, and regional fog nodes. At the other end are cloud platforms that support large-scale storage, training, analysis, coordination, and planning.

Each layer has a different role. The edge performs immediate sensing, filtering, control, and inference. Fog or local gateway systems aggregate nearby data, coordinate multiple devices, cache information, and provide local resilience. Cloud systems support long-term learning, cross-system analysis, model training, fleet management, and strategic planning.

This continuum helps avoid a false binary. Edge computing does not eliminate the cloud. It reduces unnecessary dependence on it. Cloud systems remain valuable for training models, analyzing historical trends, coordinating fleets, managing updates, and supporting policy decisions. But when real-time responsiveness, privacy, energy efficiency, or continuity matter, local computation is often necessary.

A resilient architecture asks three questions for every function:

• How quickly must the system respond?
• What happens if connectivity is unavailable?
• What data should remain local for privacy, bandwidth, or operational reasons?

Those questions determine whether computation belongs on a sensor, microcontroller, FPGA, local gateway, regional node, or cloud platform.

Back to top ↑

The Role of FPGAs in Urban Edge Infrastructure

Field-programmable gate arrays are configurable hardware devices that allow engineers to implement custom digital logic after manufacturing. Unlike general-purpose processors, which execute instruction streams through fixed architectures, FPGAs can be configured to perform many operations in parallel. This makes them well suited to workloads where low latency, deterministic timing, energy efficiency, and custom data paths matter.

FPGAs are especially relevant for infrastructure because public systems often require predictable behavior. A general-purpose processor may be flexible, but it may not always provide the timing determinism needed for some control or signal-processing tasks. A GPU may provide high throughput, but it may be too power-hungry or physically unsuitable for small edge deployments. An FPGA can provide tailored acceleration for specific workloads while remaining reconfigurable over time.

Key architectural advantages include:

• Deterministic low-latency processing: useful for safety-relevant infrastructure workloads.
• Parallel computation: multiple operations can occur simultaneously in hardware.
• Energy efficiency: custom data paths can reduce unnecessary computation.
• Hardware-level customization: logic can be designed around the workload rather than forcing the workload onto a fixed processor.
• Post-deployment reconfigurability: logic can be updated without replacing physical hardware.
• Long lifecycle adaptability: infrastructure can evolve as requirements change.

In smart-city contexts, FPGAs can support real-time video processing, sensor fusion, signal filtering, cryptographic acceleration, low-latency anomaly detection, traffic-flow computation, grid-monitoring logic, and edge inference acceleration. They can be integrated into roadside units, substations, transit systems, water infrastructure, environmental monitoring stations, and industrial control gateways.

The reconfigurable nature of FPGAs is particularly important for long-lived infrastructure. Cities cannot replace field hardware every time a model changes, a sensor is added, or an algorithm is improved. FPGA-based systems can support controlled updates, provided that configuration management, verification, rollback, and security are built into the lifecycle.

That last condition is essential. Reconfigurable hardware is powerful, but it must be governed. If logic updates are not versioned, verified, signed, audited, and documented, FPGA flexibility can become operational risk. The benefit of adaptability depends on disciplined engineering management.

Back to top ↑

TinyML and On-Device Urban Intelligence

TinyML refers to machine-learning inference on ultra-low-power embedded devices, often microcontrollers or highly constrained edge hardware. Instead of sending raw sensor data to centralized platforms, TinyML allows devices to classify, detect, estimate, or flag events locally.

This matters for cities because urban systems generate enormous volumes of data. Cameras, microphones, air-quality sensors, vibration sensors, flow meters, electricity meters, traffic loops, weather stations, occupancy sensors, and structural monitors can produce continuous streams. Sending all raw data to the cloud is often unnecessary, expensive, intrusive, and fragile. In many cases, the system only needs to transmit summaries, alerts, anomalies, or verified events.

Within FPGA TinyML smart cities, local inference can support:

• air-quality anomaly detection;
• acoustic event recognition;
• predictive maintenance for pumps, motors, transformers, escalators, and elevators;
• structural monitoring for bridges, tunnels, and transit systems;
• traffic-flow and pedestrian-safety detection;
• energy-use pattern recognition;
• water-leak detection;
• flood and drainage early warning;
• occupancy-based building controls;
• event-based environmental monitoring.

TinyML strengthens privacy because raw data do not always need to leave the device. A camera-based system, for example, may detect a vehicle count or safety event without storing or transmitting identifiable video. An acoustic system may classify environmental sound categories without uploading continuous audio. A building sensor may infer occupancy patterns without sending raw movement data.

TinyML also supports operational resilience. If connectivity fails, a local model can continue making basic inferences. If bandwidth is limited, devices can prioritize event-based communication. If power is constrained, low-power inference can extend battery life or reduce energy costs.

But TinyML also creates governance challenges. Models deployed across thousands of devices must be versioned, tested, monitored, updated, and retired. Drift must be detected. False positives and false negatives must be understood. Devices must be secured. Logs must be preserved where appropriate. Human review must be built into high-stakes contexts. Public agencies must know which model is running where, why, and under what authority.

TinyML makes intelligence small enough to live everywhere. Governance determines whether that intelligence remains accountable.

Back to top ↑

Architectural Stack for FPGA TinyML Smart Cities

A resilient FPGA TinyML smart-city architecture can be conceptualized as a layered system. Each layer performs a distinct role, and each introduces its own risks.

1. Sensor layer: environmental, operational, visual, acoustic, electrical, mechanical, and mobility data collection.
2. Embedded compute layer: microcontrollers, digital signal processors, FPGA accelerators, and local controllers.
3. TinyML inference layer: on-device classification, anomaly detection, event recognition, and predictive maintenance inference.
4. Control and actuation layer: local responses such as signal changes, alerts, pump adjustments, lighting changes, or safety interventions.
5. Network layer: secure communication of summarized, event-based, or periodic data.
6. Edge gateway layer: aggregation, buffering, coordination, protocol conversion, and local failover.
7. Cloud and analytics layer: model training, historical analytics, fleet monitoring, long-term optimization, and reporting.
8. Governance and audit layer: model documentation, configuration management, logging, update control, security review, procurement rules, and public accountability.

The final layer is often overlooked in technical discussions, yet it is essential for public infrastructure. A city cannot responsibly operate intelligent embedded systems without knowing which models, firmware, bitstreams, configurations, sensors, and decision rules are active in the field.

The architecture is only as strong as the relationships among its layers. A fast model is not enough. A secure network is not enough. A configurable FPGA is not enough. Public infrastructure needs the full stack: hardware, software, data, security, operations, governance, and institutional accountability.

Back to top ↑

A Mathematical Lens: Latency, Energy, and Reliability

The case for edge intelligence can be made intuitively, but it can also be expressed through simple systems relationships. For a cloud-dependent sensing system, total response time can be approximated as:

For an edge-inference system, the response time can be reduced:

The energy tradeoff can also be expressed simply. Continuous raw-data transmission may consume more energy than local inference plus event-based communication:

Reliability can be framed through service continuity. If a system depends on both local device availability and network availability, the remote pathway may fail when either component fails. If basic inference can occur locally, the system can continue partial operation even when the network is unavailable.

These equations are simplified, but they clarify the architectural point. Edge intelligence reduces latency, can reduce energy spent on communication, and can improve service continuity by lowering dependence on remote systems for local decisions.

Back to top ↑

Infrastructure Applications

FPGA TinyML smart-city architectures can be applied across multiple urban infrastructure domains. The strongest use cases share several features: real-time requirements, high data volume, privacy sensitivity, energy constraints, physical safety implications, or the need for continued operation during network outages.

Adaptive Traffic and Intersection Safety

Traffic systems require local responsiveness. Edge devices can classify vehicle presence, pedestrian movement, cyclists, emergency vehicles, congestion patterns, or near-miss events. TinyML can support low-power detection; FPGAs can accelerate video or sensor fusion where deterministic timing matters. Local inference reduces the need to transmit raw video and can maintain basic operation when cloud connectivity is unavailable.

Water Distribution and Pump Monitoring

Water systems depend on pumps, valves, pressure sensors, flow meters, and quality monitoring. Edge models can detect leaks, pressure anomalies, pump vibration patterns, or abnormal energy use. FPGA acceleration can support high-frequency signal processing, while TinyML can classify local events and transmit alerts rather than continuous raw data.

Electrical Grid Monitoring

Distribution grids increasingly need local intelligence for fault detection, transformer monitoring, demand response, and renewable integration. FPGAs can support deterministic signal processing and protection logic, while TinyML can classify equipment anomalies or demand patterns at the edge.

Environmental Monitoring Networks

Air quality, heat, noise, flooding, and pollution sensors can generate continuous streams across a city. Local inference can identify anomalies, trigger alerts, and reduce bandwidth by transmitting summaries or events. This is especially useful where environmental justice requires fine-grained neighborhood monitoring without creating unnecessary privacy risks.

Public Transit and Structural Monitoring

Bridges, tunnels, rail systems, stations, and transit vehicles can use vibration sensors, acoustic sensors, temperature data, and visual systems to detect stress or maintenance needs. Edge inference can flag unusual patterns early, while FPGA acceleration can support real-time signal processing under constrained conditions.

Buildings, Lighting, and Energy Efficiency

Smart buildings and lighting systems can use local inference for occupancy-aware controls, energy optimization, fault detection, and safety alerts. Processing data locally can reduce privacy risks associated with transmitting raw occupancy or activity data.

The common principle is clear: use local intelligence where physical systems require fast, private, efficient, or resilient decisions. Use cloud systems where coordination, training, large-scale analytics, and long-term planning are needed. The architecture should fit the operational reality of the infrastructure.

Back to top ↑

The Governance Layer: From Smart to Accountable

Technological sophistication alone does not make infrastructure trustworthy. Systems deployed in public environments must be transparent, traceable, secure, and accountable. This is especially true when intelligent systems influence safety, mobility, utility service, enforcement, public space, or resource allocation.

For FPGA TinyML smart cities, governance must cover both software and hardware configuration. TinyML systems require model versioning, dataset documentation, validation metrics, inference logging, drift monitoring, update procedures, and rollback capabilities. FPGA systems require bitstream version control, firmware signing, reconfiguration verification, hardware inventory, timing validation, and audit trails for logic updates.

Smart infrastructure should therefore be:

• Traceable: decisions, alerts, updates, and configuration changes should be logged where appropriate.
• Reproducible: model versions, training data, validation metrics, and deployment settings should be documented.
• Inspectable: firmware, FPGA configurations, and update histories should be available to authorized reviewers.
• Governed: system behavior should align with public policy, legal requirements, safety rules, and transparency standards.
• Contestable: affected people should have pathways to challenge harmful or erroneous automated decisions.
• Maintainable: agencies must be able to update, repair, replace, and retire systems without losing institutional control.

For TinyML device fleets, governance practices include:

• tracking model versions across deployed devices;
• documenting training datasets and intended use;
• logging inference decisions and system responses where appropriate;
• monitoring model drift and performance degradation;
• maintaining rollback capabilities;
• requiring human review for high-stakes decisions;
• documenting update pipelines and approval authority.

For FPGA-based infrastructure, governance requires:

• configuration version control;
• verification of reprogramming cycles;
• secure bitstream and firmware distribution;
• hardware inventory and lifecycle tracking;
• timing and safety validation after updates;
• audit trails for logic changes;
• separation of test, staging, and production deployments.

Without governance, embedded intelligence becomes opaque automation. Opaque automation erodes institutional trust, especially when deployed across public infrastructure. The goal is not only to make cities smart. It is to make intelligence accountable.

Back to top ↑

Security, Privacy, and Public Trust

FPGA TinyML smart-city systems create new security and privacy responsibilities. Edge devices may be physically accessible, widely distributed, resource-constrained, and connected to critical systems. They may process video, audio, mobility signals, utility data, environmental measurements, or operational telemetry. If poorly governed, they can become attack surfaces or surveillance infrastructure.

Security must therefore be designed across the lifecycle. Devices should support secure boot, signed firmware, encrypted communication, authenticated updates, least-privilege access, physical tamper resistance where appropriate, network segmentation, monitoring, and incident response. FPGA configurations should be protected from unauthorized modification. TinyML models should be protected from unapproved replacement or manipulation.

Privacy requires data minimization. One of the strongest arguments for edge inference is that raw sensitive data do not always need to leave the device. A system can count vehicles without storing identifiable video. It can detect acoustic anomalies without transmitting continuous audio. It can identify building occupancy patterns without sending raw movement data to third parties. But local processing does not automatically guarantee privacy. Governance must define what is collected, what is retained, what is transmitted, who can access it, and how long it is stored.

Public trust depends on several principles:

• Purpose limitation: data and inference should be used for clearly defined public purposes.
• Data minimization: systems should collect and transmit only what is necessary.
• Transparency: public agencies should explain where intelligent systems are deployed and what they do.
• Security by design: device fleets should not rely on after-the-fact patching alone.
• Independent review: high-impact systems should be auditable by qualified reviewers.
• Equity analysis: systems should be evaluated for uneven impacts across neighborhoods and communities.

Smart-city infrastructure is not only a technical system. It is a public institution operating through hardware and software. Its legitimacy depends on whether people can trust the systems embedded around them.

Back to top ↑

Hardware-Software Co-Design for Long-Lived Infrastructure

FPGA TinyML systems require hardware-software co-design. A model is not deployed into abstraction. It runs on physical hardware with memory limits, power constraints, sensor interfaces, timing requirements, and environmental conditions. The model architecture, quantization strategy, signal-processing pipeline, FPGA logic, microcontroller firmware, communication protocol, and update process must be designed together.

Co-design becomes especially important in cities because infrastructure lifecycles are long. A consumer device may be replaced after a few years. A municipal system may remain deployed for a decade or more. That means the architecture must support maintainability, modularity, and gradual evolution.

Key co-design questions include:

• Which tasks require deterministic hardware acceleration?
• Which tasks can run efficiently on a microcontroller?
• Which features should be extracted locally before inference?
• How much memory is available for model weights and intermediate tensors?
• How will models be quantized, validated, and updated?
• How will FPGA bitstreams be versioned and verified?
• How will devices operate when disconnected?
• What logs are needed for auditability without creating excessive privacy risk?
• How can the system be tested before citywide deployment?

A robust co-design approach may separate responsibilities. The FPGA handles deterministic preprocessing, signal filtering, sensor fusion, encryption acceleration, or real-time logic. The microcontroller runs a compact model for inference. The edge gateway coordinates multiple devices and applies policy rules. The cloud trains models, analyzes fleet performance, and supports long-term planning. Governance spans all layers.

This division of labor should be explicit. When responsibilities are unclear, systems become difficult to test, maintain, and audit. Infrastructure intelligence should be architected, not improvised.

Back to top ↑

Engineering Workflows for Edge-AI Infrastructure

Engineering FPGA TinyML smart-city systems requires disciplined workflows that combine embedded development, machine learning, hardware verification, cybersecurity, operations, and public governance. A responsible workflow should move through staged design rather than direct deployment from prototype to infrastructure.

This workflow recognizes that technical performance is necessary but not sufficient. A citywide edge-AI system must also be safe, explainable enough for its context, maintainable, secure, and aligned with public purpose.

The engineering standard should be higher for public infrastructure than for demonstration prototypes. A demo proves possibility. Infrastructure requires reliability.

Back to top ↑

GitHub Repository

The companion repository for this article can support reproducible embedded-and-edge systems workflows, TinyML benchmarking, FPGA configuration examples, edge-latency analysis, device-governance templates, and synthetic smart-city sensor datasets.

Back to top ↑

Designing for Long-Term Urban Resilience

Smart cities are not defined by the quantity of sensors deployed or the volume of data collected. They are defined by the integrity of the systems connecting hardware, software, analytics, governance, infrastructure, and public purpose.

FPGAs provide deterministic and adaptable computing for infrastructure-scale workloads. TinyML enables distributed intelligence directly at the device level. Edge computing reduces systemic dependence on centralized processing. Cloud platforms support training, fleet coordination, long-term analytics, and strategic planning. The strongest urban architectures use all of these layers in the right places.

Yet technological capability alone does not guarantee resilience. A city can deploy thousands of sensors and still be fragile if devices are insecure, models are undocumented, updates are untraceable, privacy rules are weak, or agencies cannot maintain the systems they procure. Intelligence without governance can become a form of infrastructural opacity.

Long-term urban sustainability depends on coherent system design: architectures that integrate performance, security, transparency, auditability, maintainability, and adaptability across decades of infrastructure evolution. Cities that build digital infrastructure with these principles in mind will not merely become “smart.”

They will become more resilient, more accountable, and better prepared to govern intelligence in the physical systems on which public life depends.

Back to top ↑

Related articles

• Embedded & Edge Systems
• Artificial Intelligence Systems
• Intelligent Infrastructure Systems
• Data Systems & Analytics
• Environmental Monitoring Systems

Further reading

• NIST. Fog Computing Conceptual Model.
• MLCommons. MLPerf Inference: Tiny.
• MLCommons. MLPerf Tiny Deep Learning Benchmarks for Embedded Devices.
• Warden, P. and Situnayake, D. TinyML: Machine Learning with TensorFlow Lite on Arduino and Ultra-Low-Power Microcontrollers.
• ITU-T Focus Group on Smart Sustainable Cities.
• ITU. Smart Sustainable Cities and Key Performance Indicators resources.

Back to top ↑

References

• Banbury, C. et al. (2021). MLPerf Tiny Benchmark.
• Iorga, M., Feldman, L., Barton, R., Martin, M.J., Goren, N.S. and Mahmoudi, C. (2018). Fog Computing Conceptual Model. NIST Special Publication 500-325.
• ITU. ITU-T Focus Group on Smart Sustainable Cities.
• ITU. Smart Sustainable Cities and Key Performance Indicators resources.
• MLCommons. MLPerf Inference: Tiny.
• MLCommons. MLPerf Tiny Deep Learning Benchmarks for Embedded Devices.
• Warden, P. and Situnayake, D. (2019). TinyML: Machine Learning with TensorFlow Lite on Arduino and Ultra-Low-Power Microcontrollers. O’Reilly Media.

Back to top ↑