To evaluate the proposed HDC compression library described in Section “ByteHD: HDC Compression Library” we address a case study for anomaly detection in emergency lighting devices. The study considers a deployment of l devices installed in one or several neighboring buildings. These devices are designed to automatically switch on when the main power supply fails (e.g. during outages or blackouts), thereby providing sufficient illumination to maintain visibility, guide evacuation, and secure access to emergency exits. Hyperdimensional computing was employed to capture the normal operational patterns of the devices and, based on this learned behavior, to identify irregularities that could reveal malfunctions in individual units.

Dataset Description

Each emergency lighting device transmits two types of messages at different rates: 1) status, describing its current operating state, and 2) diagnosis, containing detailed self-diagnostic information. Data of both types were collected during two monitoring periods of 6 and 24 days, corresponding to the intervals between December 7 and 12, 2024 and between December 24, 2025 and January 16, 2025. The information collected from the l devices was combined into a unified dataset, where each entry corresponds to a pair of samples, one from the status data and one from the diagnostic data for a single device. This process resulted in a set \(\mathcal \) equal to 1820172 samples, each containing k=117 features, yielding a dataset of approximately 4.7 GB in size. To clean up the data space, a filtering procedure was applied that excluded variables with weak correlations to others or that contributed little information, and entries containing null values were removed. The resulting dataset was further used to generate synthetic data to assess the model. A total number of 7 datasets were thus generated, as shown in Table 2.

Real-World Dataset

Following the filtering procedure mentioned in Section “Dataset Description”, the resulting dataset, referred as DR, exhibits the characteristics summarized in Table 2. The table shows that a real-world dataset of \(S=564\) samples was ultimately considered, each with a number of \(k=34\) features and occupying a total size of 0.62 MB. Figure 5 presents the correlation matrix among the \(k\times k\) features for a single emergency lighting device, where red and blue indicate proportional and inversely proportional correlation, respectively, and gray indicates no apparent relationship. This analysis highlighted the features likely to influence the performance of the HDC model. Variables exhibiting strong correlations were selected for inclusion in the real-world dataset and for use in subsequent modeling.

Fig. 5The alternative text for this image may have been generated using AI.

Correlation matrix obtained for an emergency lighting device

The real-world dataset was split into two portions for the purposes of model development and evaluation. The larger portion, comprising p=80% of the samples, was allocated to train the HDC model by generating prototypical hypervectors that encapsulate the normal operational patterns of the devices, as described in Section “HDC Classification Pipeline”. The remaining 20% of the data was reserved for testing the model. In this framework, every training sample is treated as representative of normal behavior; anomalies are then identified by measuring the cosine similarity between the test hypervector sample and the corresponding prototypical hypervector. To maintain consistency across all devices, the same set of thresholds was applied, specifically \(T_u^+=\\).

Synthetic Datasets

As outlined in Section “Real-World Dataset”, all data collected from the lighting devices were considered as a normal behavior. In order to evaluate our HDC framework for the classification of anomalous samples, we have generated synthetic data from the original data by applying three different deviations \(\delta =\\), which produced three synthetic datasets \(DS_1\),\(DS_2\) and \(DS_3\), respectively, that were designed to examine the performance of the model across different levels of deviation, ranging from low to high. The characteristics of these datasets can be observed in Table 2. To generate these datasets, the following algorithm was used: for each variable in the dataset, the first 100 samples were taken from the real-world dataset and a selected deviation in \(\delta \) was applied to every value of each feature. The procedure was then repeated systematically, excluding one variable at a time, continuing until all variables were considered. Applying this for every deviation considered, three synthetic datasets were generated each of \(100 \times 34\) entries.

Hybrid Datasets

For the purpose of evaluating the model with both anomalous and non-anomalous entries, three hybrid datasets were also generated, \(DH_1\),\(DH_2\) and \(DH_3\), each incorporating anomalous entries with deviations of \(\delta =\\), respectively, in line with the synthetic datasets. The construction of these datasets was carried out by combining the real-world dataset with the corresponding synthetic dataset, where the number of synthetic entries incorporated was set to 10% of the total number of entries in the real-world dataset. The characteristics of these datasets are presented in Table 2.

Table 2 Datasets used in this study (Legend: NA: Not applies)Method

For the development of ByteHD, three hardware platforms were used to evaluate the compression library, ranging from high-performance hardware to a resource-constrained embedded device. These platforms are: 1) a laptop equipped with an 11th Gen Intel®  Core™ i5-11400H processor running at 2.70 GHz, 16 GB of RAM, and an NVIDIA RTX 3050 GPU with 4 GB of GDDR memory; 2) a Raspberry Pi 4 Model B (RPI) featuring a Broadcom BCM2711 SoC, quad-core Cortex-A72 (ARM v8) 64-bit processor operating at 1.8 GHz, and 4 GB of RAM; and 3) a RPI Pico 2, incorporating an ARM Cortex-M33 processor running at 150 MHz, along with 520 KB of on-chip SRAM.

The metrics collected during the evaluation include memory usage, training time, and classification accuracy of the HDC model. These metrics were selected to assess both the computational efficiency and predictive performance of the system across different hardware platforms. To allow a direct comparison between the original HDC algorithm and the proposed ByteHD implementation, all metrics were collected for both approaches.

A dedicated test suite was developed for the collection of these metrics and was executed consistently across all platforms to guarantee comparable results. This test suite involved the execution of algorithms with varying values of M and, correspondingly, b (reminds Fig. 3), and across the different datasets described in Table 2. Furthermore, training of the HDC model was carried out consistently using the same 80% of the entries from the dataset DR. Due to the limited library support in MicroPython on the RPI Pico 2, where libraries such as PymplerFootnote 1, used on the laptop and RPI are unavailable, memory usage had to be estimated using a custom algorithm. This algorithm was explicitly designed to reflect the memory usage of our HDC model, considering its specific data storage structures. The algorithm estimates the memory footprint of a Python dictionary by summing predefined base sizes for supported data types, with dynamic calculations for strings and byte arrays. It traverses the dictionary recursively, avoiding double counting via a record of visited objects, and adds a fixed per-entry overhead for each key–value pair. Nested dictionaries are processed in the same manner, yielding the cumulative estimated size in bytes.

Experimentation Results

As described in Section “Method”, each test conducted across the three hardware platforms yielded metrics for memory usage, training time, and classification accuracy of the HDC model. The detailed analysis of these metrics is presented in the following sections. For every test conducted, \(D=10,000\) except for the RPI Pico 2, where D must be reduced for space reasons.

Memory Usage

While memory usage is an important consideration in all computing systems, in embedded devices it becomes a critical constraint due to their limited resources. These memory limitations often prevent the deployment of HDC frameworks on such platforms. However, the memory-efficient design of ByteHD, through its compression mechanisms, may now allow HDC models to operate on resource-constrained hardware, presenting a viable solution for embedded applications.

A comparison was made between the memory usage of an HDC implementation without compression and the same implementation enhanced with ByteHD. The comparison is independent of the hardware platform, given that the data structures are identical and memory usage results are consistent across all tested platforms. As illustrated in Fig. 6, the original implementation requires nearly 8 times more memory than ByteHD. This is due to the compression mechanism, in which a single byte in ByteHD can store 8 values, compared to 1 value per byte in the uncompressed version.

Fig. 6The alternative text for this image may have been generated using AI.

Memory usage comparison between a uncompressed HDC implementation and ByteHD

Additionally, Table 3 presents specific results in which the RPI Pico 2 operated near its memory limits, as shown in Column 3, illustrating the capabilities achievable with the ByteHD implementation (remind that RPI Pico 2 has 520 KB of SRAM). The parameter values of D, M, and b were deliberately selected to create different hardware demanding testing scenarios, within which a balance was achieved between D and the maximization of M while maintaining high accuracy.

Table 3 Raspberry Pi Pico 2 results in terms of execution time and memory occupationExecution Time

For our experiments, time metrics were collected for PC and RPI platforms from two distinct processes: the computation of the \(M=[1,3336]\) level hypervectors and the training phase of the HDC model. The training tests were conducted with the dataset DR. Figure 7 presents two plots, each illustrating the results obtained for these time-related metrics. The graph on the left side compares the time taken by each platform during the computation of level hypervectors. As can be observed, the uncompressed implementations consistently require less time than the ByteHD implementations. This outcome is attributed to the additional processing overhead introduced by the compression operations required to store each newly generated level hypervector. The graph on the right side shows the time consumed during the training phase of the HDC model. A similar trend can be observed: uncompressed implementations outperform ByteHD in terms of execution time, primarily due to the additional compression and decompression steps involved in ByteHD’s operations.

Fig. 7The alternative text for this image may have been generated using AI.

Level hypervector computation (left) and training time (right) in PC/RPI platforms

Additionally, Table 3 provides a more detailed view of the time required for HDC level computation and model training, respectively, when running a ByteHD implementation on an embedded device such as the RPI Pico 2. As can be observed, the computation time increases when ByteHD is employed, in a manner consistent with the results obtained from tests conducted on the other platforms.

Fig. 8The alternative text for this image may have been generated using AI.

Accuracy obtained for RH dataset and for thresholds 0.85 (left) and 0.95 (right)

Fig. 9The alternative text for this image may have been generated using AI.

Evaluation on the dataset \(DS_1\): Classification accuracy with \(\delta =0.1\) and thresholds \(T_u^+=\\)

Fig. 10The alternative text for this image may have been generated using AI.

Evaluation on the dataset \(DS_2\): Classification accuracy with \(\delta =0.5\) and thresholds \(T_u^+=\\)

Fig. 11The alternative text for this image may have been generated using AI.

Evaluation on the dataset \(DS_3\): Classification accuracy with \(\delta =1.0\) and thresholds and thresholds \(T_u^+=\\)

ByteHD achieves a consistent reduction of approximately one order of magnitude in memory consumption compared to the original implementation. However, this benefit comes at the expense of a higher computational cost where ByteHD can require 15 to 30 times longer depending on the platform and if it is training or level hypervectors computation. These findings suggest that while ByteHD offers clear advantages in terms of memory reduction, its practical applicability is limited to scenarios where computational speed or training efficiency are not critical. However, since creating new level hypervectors and training on large datasets are typically infrequent operations, this overhead is unlikely to represent a major limitation in practice. On a larger scale, the memory efficiency gained through ByteHD is expected to outweigh the computational costs, making it a favorable option for deployment in resource-constrained environments.

Fig. 12The alternative text for this image may have been generated using AI.

Evaluation on the dataset \(DH_1\): Classification accuracy with \(\delta =0.1\) and thresholds and thresholds \(T_u^+=\\)

Fig. 13The alternative text for this image may have been generated using AI.

Evaluation on the dataset \(DH_2\): Classification accuracy with \(\delta =0.5\) and thresholds \(T_u^+=\\)

Fig. 14The alternative text for this image may have been generated using AI.

Evaluation on the dataset \(DH_3\): Classification accuracy with \(\delta =1.0\) and thresholds and thresholds \(T_u^+=\\)

Table 4 Raspberry Pi Pico 2 accuracyAccuracy

This metric evaluates the performance of the HDC model proposed in this work. Specifically, it measures the model’s ability to correctly determine whether a test sample represents an anomaly or not, thus providing an overall indication of how well the model performs. Intuitively, the larger the threshold the lower the accuracy will be due to a stronger restriction in similarity results. Note that a testing sample is evaluated as an anomaly if its similarity with respect to a class hypervector is below a certain threshold, and therefore, when the threshold increases, the probability of similarity decreases. For all experiments we use a fixed hypervector dimensionality of \(D=10,000\), a range of level hypervectors \(M=\)[1,3336], which corresponds to a number of b=[1,2500] as shown in Fig. 3, with the exception of the tests conducted on the RPI Pico 2, and the values of thresholds \(T_u^+=\\).

Real-World Dataset

The accuracy results of the HDC model obtained using the dataset DR are presented in Fig. 8. As can be observed, the model is capable of correctly classifying the data entries with a mean precision of approximately 90%. Only in the case of a threshold of 0.85 (plot on the left) does the model achieve a precision of 100% for \(b=1\), which can be attributed to the less demanding similarity requirement. This result also reflects the effect of having more level hypervectors, as greater granularity leads to improved classification performance. The use of real samples for testing may lead to the assumption that the model will achieve a precision approaching 100%. Contrary to this assumption, our findings indicate that such performance is obtained in a single specific scenario. This can be attributed to the fact that a prototypical hypervector will almost never be identical to a sample hypervector because of the various bundling operations required. These operations produce hypervectors that are similar, yet never exactly the same, resulting in certain cases falling marginally below the 0.85 threshold and, consequently, being classified as anomalies. This accounts for the fact that the plots in Fig. 8 are highly similar to one another.

Synthetic Datasets

The accuracy obtained for a deviation of \(\delta \)=0.1 on the dataset \(DS_1\) is shown in Fig. 9, which presents three plots corresponding to the similarity thresholds. With a threshold of 0.85 (plot above on the left side), the results indicate that the HDC model performs poorly in classifying synthetic entries across all implementations and platforms. This behavior is expected, as the low deviation results in synthetic entries closely resembling the real-world data on which the model was trained, leading to their misclassifications as non-anomalous.

The behavior observed at the 0.85 threshold (the first visible plot in the Fig. 9) is also evident at the 0.90 threshold, indicating that the synthetic entries continue to exhibit a high similarity to the real-world data. In contrast, with a threshold of 0.95 (plot on the second row), an improvement in classification accuracy can be observed. This result is explained by the fact that, although the synthetic entries remain highly similar to the real ones, the subtle differences are sufficient to prevent them from meeting the higher similarity requirement imposed by the 0.95 threshold, leading the model to classify them as anomalies. Although with a 0.95 threshold the HDC model performs better, there is a fluctuation in the results. These observed fluctuations are caused by the strict similarity requirements imposed by the high threshold value. When a very high threshold is applied, such as 0.95, the similarity demanded between the new entry and the training data becomes very high. Consequently, many synthetic entries, despite being highly similar to the real data, fail to meet this strict condition by a small margin and are classified as anomalies. Furthermore, when the parameter b changes, even slightly, the similarity of certain entries may also vary, allowing them to either exceed or fall short of the threshold. This explains why entries that had previously received a certain classification may now receive a different one, resulting in the observed fluctuations. For each graph in Fig. 9, it can be observed that the different implementations do not produce perfectly aligned results. This behavior is explained by the inherent randomness involved in the generation of the hypervectors. Although all tests execute the same code, the random nature of hypervectors creation prevents the results from matching exactly across implementations.

The results obtained for a deviation of \(\delta \)=0.5 corresponding to dataset \(DS_2\) are presented in Fig. 10, which, as previously, includes three graphs corresponding to the different similarity thresholds. Although the accuracy achieved for a threshold of 0.85 is slightly higher than that observed for a deviation of 0.1, the results remain similar, indicating that although the synthetic entries deviate from the original entries, it is still not sufficiently distinct to fall below the lower threshold. When examining the results for the 0.90 threshold, an increase in accuracy of approximately 20% can be observed, reflecting the clearer distinction introduced by a deviation of 0.5 compared to the lower deviation of 0.1. Finally, for the 0.95 threshold, this shows not only an improvement in accuracy, but also a stabilization in the results. This behavior is attributable to the synthetic entries differing from the data on which the model was trained, allowing the model to classify them more reliably as anomalies.

The final tests conducted using synthetic data employed the dataset \(DS_3\). The results obtained are presented in Fig. 11, which shows three graphs corresponding to the different similarity thresholds considered. Although these exhibit similar behavior to the tests with the dataset \(DS_2\), they also show an increase in accuracy performance of approximately 20%, clearly indicating that the greater the difference in the data, the better the performance of the model.

Hybrid Datasets

As in the case of synthetic datasets, the hybrid datasets are also divided into three distinct subsets, each characterized by a deviation from the original data of \(\delta =\\), respectively. As a result, the outcomes are presented individually for each dataset. In these evaluations, the HDC model is trained and tested without prior knowledge of the nature of the entries and will classify them solely based on their similarity to the class hypervector.

Figure 12 presents the results of the HDC model evaluated using the dataset \(DH_1\). Consistent with previous experiments, the results are classified according to the three threshold values \(T_u^+=\\). For the 0.85 threshold (plot above on the left), the model demonstrates a highly stable accuracy across all scenarios, with an average performance of approximately 84%, except in the case where \(b=1\), where accuracy increases to approximately 94%. This phenomenon is attributable to the fact that a greater number of level hypervectors enhance the representational capacity of the model, thus improving its overall performance. At the 0.90 threshold (plot above on the right), the model maintains a similar stable accuracy, with minimal fluctuations and an average precision of around 84%. In contrast to the previous case, no pronounced spike is observed at \(b=1\), which can be explained by the more strict similarity requirement imposed by the higher threshold. Consequently, similarity values that would have passed at 0.85 may now fall marginally below the threshold. In the case of the 0.95 threshold (plot below) , the model shows an increase in precision of approximately 5%; however, this improvement is accompanied by reduced stability. The observed instability is largely attributable to the randomness inherent in the generation of hypervectors, compounded by the stricter similarity restriction. Even slight variations in b can result in small changes in similarity scores, potentially shifting data points from meeting to failing the threshold requirement (or vice versa), thus producing the observed fluctuations.

Moreover, the increase in precision under the 0.95 threshold can be explained by the fact that certain anomalous data entries, which were previously misclassified as non-anomalous, now fail to meet the similarity criterion. As a result, they are correctly identified as anomalous, thus contributing to the overall improvement in accuracy.

For the subsequent tests conducted using the hybrid dataset \(DH_2\), the results are shown in Fig. 13. All these three graphs present a high degree of similarity to those obtained with a 0.1 deviation, though exhibit slightly reduced stability due to the randomness inherent in the generation of hypervectors. The most prominent difference appears at the 0.95 threshold, where a slight increase in accuracy is observed.

The final set of tests using hybrid datasets was carried out with the dataset \(DH_3\). The corresponding results are illustrated in Fig. 14. As in previous evaluations, the resulting graphs closely resemble those obtained with 0.1 and 0.5 deviations, although with a slight improvement in accuracy at the 0.85 threshold and a more pronounced increase of approximately 5% at thresholds 0.90 and 0.95. These findings indicate that, although a greater deviation introduces variability, the overall performance of the model remains robust. This suggests that, when an appropriate similarity threshold is selected and the data quality is maintained, the model demonstrates consistent efficacy across a range of scenarios.

Accuracy on a RPI Pico 2

A practical implementation of ByteHD on an embedded platform was carried out using the RPI Pico 2. The results for various configurations that stress the device resources are presented in Table 4, based on the tests conducted with the hybrid datasets. As shown, performance varies according to the configuration of D and M/b, highlighting the importance of selecting appropriate parameter values. The embedded system designer has the responsibility to identify the optimal configuration based on the specific resource constraints of the target device to maximize the accuracy of the model. As observed in previous experiments, the value of M/b has a clear influence on performance results, and, as demonstrated by the results obtained on the RPI Pico 2, D also has a significant impact on accuracy. The results further demonstrate that, under these configurations, which may not necessarily be optimal, the model deployed on this embedded device is capable of achieving accuracies of approximately 85%. When considering the three thresholds jointly, the configuration with \(D=2000\) and \(M=74\) provides the most balanced and consistent performance. Although the highest accuracy of 85.44% is achieved with \(D=1000\) and \(M=74\) at a threshold of 85, the average accuracy across all thresholds is superior when using \(D=2000\) and \(M=74\). In particular, this configuration yields accuracies of 85.28% at threshold 85, 83.35% at threshold 90, and 69.76% at threshold 95. These results suggest that the dimension of the hypervector, D, has a greater influence on accuracy than the number of level hypervectors, M.