Percepta: Lightweight DSP for Edge AI

• Percepta is defined as a fully software-based DSP architecture tailored for edge computing that processes streaming data close to the source while preserving privacy.
• Its modular pipeline harmonizes heterogeneous data sources using protocol conversion, time-window aggregation, and interpolation to meet stringent edge requirements.
• The system integrates AI model interfacing with real-time reward computation and logging, enabling continuous, adaptive decision-making in reinforcement learning scenarios.

Percepta is a lightweight, modular Data Stream Processing (DSP) system for the edge designed to make real-time AI inference practical on edge devices, with explicit support for Reinforcement Learning (RL). It is presented as a response to cloud-centric and general-purpose DSP systems in IoT and edge deployments where latency, bandwidth, privacy, heterogeneous devices, incomplete data, and continuous decision-making are central constraints. Its stated role is not merely stream processing, but a data provisioning layer for edge AI that can prepare, normalize, harmonize, encode, and store data while supporting reward computation and retraining workflows (Sousa et al., 2 Oct 2025).

1. Definition and design objectives

Percepta is defined as a fully software-based stream-processing architecture tailored to edge computing and edge AI. Its stated objectives are to process streaming data close to the source, reduce latency and bandwidth usage, preserve privacy through local processing, and provide reliable, correctly formatted, timely inputs for AI inference. A distinctive emphasis is support for RL, including computation of reward functions in real time from interactions with the environment and storage of inputs, decisions, and rewards for later analysis and retraining (Sousa et al., 2 Oct 2025).

The system is motivated by limitations attributed to cloud-centric solutions and to existing DSP systems when deployed in IoT environments. The paper identifies several operational problems associated with edge AI: data rate harmonization between multiple sources, protocol conversion, handling the loss of data, integration with AI models, and the requirement that downstream models receive consistent inputs even when devices differ in protocol, sampling rate, and reliability. Within that framing, Percepta is positioned as a practical infrastructure layer for continuous decision-making rather than one-off analytics (Sousa et al., 2 Oct 2025).

A plausible implication is that Percepta treats stream processing and inference support as a single operational problem. In that interpretation, its novelty lies less in isolated modules than in integrating ingestion, preprocessing, inference preparation, reward computation, and logging within one edge-oriented pipeline.

2. Modular architecture and internal organization

Percepta is organized as a pipeline of modules. The architecture separates source-specific logic from environment-specific logic and uses internal message queueing to decouple stages. The main modules are Receivers, Translators, Accumulator, Manager, Predictor, Encoder/Decoder, and Forwarders (Sousa et al., 2 Oct 2025).

Module	Stated role	Notable details
Receivers	One per data source	Adapt to MQTT, HTTP/S, AMQP, or others
Translators	Standardize source payloads	Extract relevant fields and send data to RabbitMQ
Accumulator	One per environment	Reads from the environment’s RabbitMQ queue
Manager	Windowed processing	Aggregates, prioritizes recent entries, computes statistics, imputes missing values
Predictor	AI-facing orchestration	Routes to models, validates decisions, computes rewards, stores data
Encoder/Decoder	Format conversion	Bridges standardized internal representation and model-specific format
Forwarders	External actuation	Deliver decisions or commands to the correct destination

The pipeline is summarized in the paper as: Source/API → Receiver → Translator → RabbitMQ queue → Accumulator → Manager → Encoder/Decoder → Predictor/AI Model → reward computation + logging → Forwarder → target device/system (Sousa et al., 2 Oct 2025). Receivers adapt to source protocols such as MQTT, HTTP/S, and AMQP, while Translators convert source-specific payloads into a standardized internal format and send formatted data to an internal RabbitMQ queue. The Accumulator operates per environment, reading from that queue and forwarding data to the environment-specific Manager.

The Manager is the central time-windowed processing component. It works on data within a time window, for example every 15 minutes, and aggregates, prioritizes recent entries, computes statistics, handles relationships between data sources, detects missing values, and imputes them using historical data. It then produces the finalized input for the AI model. The Predictor routes processed data to the right AI model, collects predictions or decisions, validates decisions, computes rewards, stores input data, model outputs, and rewards in a database, and sends decisions to Forwarders. Encoder/Decoder components translate between the standardized internal representation and environment- or model-specific formats, while Forwarders deliver the resulting commands to external systems such as smart lighting, HVAC, or security devices (Sousa et al., 2 Oct 2025).

This organization suggests a deliberate architectural decoupling: protocol adaptation, temporal harmonization, model interfacing, and actuation are treated as separate concerns, which the paper associates with extensibility and avoidance of monolithic pipelines.

3. Stream processing functions and data preparation

Percepta’s core processing functions are defined around the needs of heterogeneous edge data. The system is described as handling multiple communication protocols, different sampling rates, missing or incomplete data, and data rate harmonization across many devices and sources. These functions are primarily concentrated in the Receivers, Translators, and Manager modules (Sousa et al., 2 Oct 2025).

For heterogeneous protocols, the paper explicitly lists MQTT, AMQP, HTTP/S, and other device/API-specific methods. Receivers and Translators absorb protocol differences and convert source-specific payloads into a common internal form. For differing sampling rates, the Manager aligns data by time window and can aggregate or interpolate so that sources with different reporting intervals can be combined; the example given is one source reporting every 5 minutes and another every hour. For missing or incomplete data, the Manager detects missing values and imputes them using historical data or recent observations.

Data rate harmonization is described as ensuring that data from multiple sources arrives at the resolution required by the AI model, especially RL. The system aligns timestamps, aggregates streams, interpolates when needed, and standardizes time windows. Before inference, Percepta aggregates data, establishes relationships among data sources, normalizes values, encodes them into model-specific formats, and decodes outputs back into common form (Sousa et al., 2 Oct 2025).

The paper does not provide formal mathematical equations, algorithms, or detailed pseudocode for these operations. Instead, it presents an operational sequence: collect raw stream data in a time window, aggregate and prioritize samples, detect missing values, impute gaps using historical patterns, analyze relationships across sources, normalize and encode for the AI model, perform inference, validate decisions, compute rewards, log inputs, decisions, and rewards, and forward actions to devices (Sousa et al., 2 Oct 2025).

A plausible implication is that Percepta’s DSP model is intentionally stateful and temporally structured. Rather than processing each raw sample independently, it uses windowed consolidation to transform irregular sensor streams into stable control inputs.

4. Reinforcement learning support and continuous decision-making

Support for RL is presented as the central novelty of Percepta. The paper states that RL in edge settings requires a continuous loop in which an agent observes state, takes an action, receives a reward, and learns which actions lead to better outcomes. Percepta is designed to supply that loop operationally by providing timely state data, reward computation, logs for retraining, and feedback after actions are applied (Sousa et al., 2 Oct 2025).

Within this loop, the Predictor has a specific role. After model decisions are made, it validates the predicted action or decision, computes the corresponding reward, and stores the input, decisions, and rewards in a database. This makes the reward available immediately for validation and future learning. Storage for retraining is also explicit: Percepta logs input data, decisions or actions, and computed rewards so that they can later be used for analysis, retraining, and model improvement (Sousa et al., 2 Oct 2025).

The paper describes continuous decision-making as repeated cycles of collecting sensor or environment data, preparing model inputs, running inference, validating decisions, computing rewards, sending actions to devices, and logging for future learning. This repeated-cycle formulation distinguishes Percepta from systems oriented toward passive monitoring or post hoc analytics. It is intended for continuous control, especially where physical-world interaction is part of the learning problem (Sousa et al., 2 Oct 2025).

The architecture therefore embeds several RL-specific requirements directly into the stream-processing layer: reward function computation, model-specific encoding/decoding, real-time preparation of harmonized state, and persistent storage of trajectories relevant to retraining. This suggests that Percepta is designed not simply to host an RL model, but to provide the operational substrate needed for RL deployment outside laboratory settings.

5. Deployment modes, use case, and comparison with other systems

Percepta is described as deployable in edge, fog, or cloud environments through a modular, containerized architecture. The paper names Docker and Kubernetes as deployment mechanisms and states that each environment has independent processing threads and queues, preventing interference between deployments (Sousa et al., 2 Oct 2025).

The principal use case discussed is building energy management for EV optimization in the OPEVA project. In that setting, an RL model manages building energy consumption to support electric vehicle autonomy. Percepta integrates data from energy production sources, energy consumption sensors, EV charging data, third-party APIs for energy prices, and weather APIs for renewable forecasting. These inputs differ in protocols, formats, sampling rates, and semantics, while the control side includes actions such as turning devices on or off, adjusting loads, and managing HVAC and charging. At each interval, Percepta aggregates and corrects data, fills missing values, encodes data for the RL model, receives control commands, validates them, calculates rewards, stores everything, and forwards actions to the relevant endpoint (Sousa et al., 2 Oct 2025).

The paper contrasts Percepta with cloud-oriented frameworks such as Storm, Spark, and Flink. These systems are described as powerful and scalable, but not designed specifically for edge constraints, often assuming stronger infrastructure than is available at the edge and not natively providing RL-specific functions such as reward computation and data preparation for continuous control. It also mentions edge frameworks such as Edgent, AgileDART, EdgeWise, and STEAM, but states that they still lack several native capabilities attributed to Percepta, including RL inference support, reward calculation, encoding/decoding logic for AI models, data rate harmonization, protocol conversion, and gap filling (Sousa et al., 2 Oct 2025).

This comparison suggests that Percepta occupies a specialized niche between generic stream processing and operational edge AI. Its intended distinctiveness lies in combining stream ingestion, temporal harmonization, model interfacing, and RL feedback support within one architecture.

6. Evaluation status, stated contributions, and limitations

The paper attributes several advantages and contributions to Percepta: lightweight operation, modularity, edge suitability, multi-environment support, support for heterogeneous sources, real-time AI data provisioning, reward calculation for RL, missing data handling, retraining data storage, and flexible deployment on edge, fog, or cloud (Sousa et al., 2 Oct 2025).

At the same time, the reported evaluation status is limited. Percepta is described as already operational for testing purposes in both edge deployment and centralized deployment, but formal benchmarking is explicitly identified as future work. Planned evaluation includes network I/O performance under load, CPU, memory, and disk utilization, performance across different deployment strategies, and tests on diverse hardware. The paper therefore does not yet report full experimental results in the provided material (Sousa et al., 2 Oct 2025).

This absence of formal benchmarking is an important qualification. The published contribution is primarily architectural and operational: a DSP system tailored to edge AI, especially RL, that ingests heterogeneous data, harmonizes rates and protocols, cleans and fills gaps, prepares model-specific inputs, runs inference, computes rewards, logs data for retraining, and dispatches decisions to actuators. A plausible implication is that Percepta should be understood, at its current stage, as a deployment-oriented systems proposal whose significance depends on future empirical characterization of throughput, resource consumption, and robustness under realistic load.