Hardware-Encrypted System for Storage of Collected Data Based on Reconfigurable Architecture

Abstract

This submission is focused on the implementation of a system that acquires data from various types of sensors and securely stores them after encryption on a chip with a reconfigurable architecture. The system has the unique capability of encrypting the input data with a single secret cryptographic key, which is stored only inside the hardware of the system itself, so the key remains unrecognizable upon completion of the system synthesis for any unauthorized user. Being stored as a part of the whole system architecture, the cryptographic key cannot be attained. It is not stored separately on the system RAM or any other supported memory, making the collected data fully protected. The reported work shows a data acquisition system which measures temperature with a high level of precision, transforms it to degrees Celsius, stores the collected data, and transfers them via serial interface when requested. Before storage, the data are encrypted with a 256-bit key, applying the AES algorithm. The data which are stored in the system memory and sent as UART packets towards the main computer do not include the cryptographic key in the data stream, so it is impossible for it to be retrieved from them. We show the flexibility of such kinds of data acquisition systems for sensing different types of signals, emphasizing secure storage and transferring, including data from meteorological sensors or highly confidential or biometrical data.

1. Introduction

Data acquisition and storage processes play crucial roles in the advancement of scientific research, providing basic datasets upon which hypotheses are tested and conclusions are drawn. They are also an essential part of different engineering applications used inside critical environmental and biometrical systems. For example, some researchers are focusing on ensuring secure data collection in biosensor networks used for applications such as health monitoring, where sensitive physiological data are collected from various parts of the body through biosensors [1].

In the context of a data acquisition system, the importance of accurate and reliable data cannot be overstated, as it directly influences the quality of analysis and the validity of results. A well-designed data acquisition system not only facilitates the efficient collection of data from various sources but also ensures that these data are processed and stored in a manner that maintains their integrity and security. For example, the development of wearable technologies focused on the secure and reliable collection and analysis of electrodermal activity data represents a significant area of ongoing research [2].

Therefore, the development and optimization of data acquisition systems is becoming essential in improving the reproducibility and reliability of scientific findings or conclusions, as researchers increasingly rely on complex datasets to drive innovation and inform decision-making.

The aim of this study is to propose a system solution for data acquisition based on flexible architecture, focusing on its enhanced data security and storage capabilities. This study poses the following research questions:

• Does the integration of single-key data encryption enhance the security of data acquisition systems?
• Does the use of a synthesized architecture enhance the flexibility and reconfigurability of data acquisition systems?

For research purposes, the system is designed to be modular and fully reconfigurable, while providing all the required essential features. Its implementation is based on a defined architecture, utilizing the FPGA target chip which allows real-time operations on the collected data and complex manipulations with minimal delay. Authors used their previous experience from designing a temperature-sensing DAQ [3], implemented on FPGA. Here, we measure ambient temperature at a relatively low frequency using a high-precision analog sensor. But this system can be used for the measurement of a wide range of environmental and biometric data, in places where the measurements could be dangerous for an operator or for security-focused applications. The data are saved in encrypted form and the device can be easily adjusted for use with non-volatile memory without concerns about data safety.

2. Related Works

In this section, a search is performed regarding other studies that present data acquisition systems and security-focused implementations with an emphasis on flexibility and reconfigurability, as the research questions posed in the paper.

Enormous research efforts have been focused on contemporary data acquisition system designs tailored to different application areas, from the measurement of meteorological data and specific chemical or industrial parameters to biometric data used for studying a person’s physical and mental state. For example, authors [4] have dealt with the construction of a data acquisition monitoring system in mechatronics to collect and process data with several temperature and pressure sensors, aiming for a high level of accuracy and data processing. Being a traditional DAQ, this application pays special attention to the reliability of the system for long-term monitoring. In the same context, a cost-effective DAQ system was developed to monitor and analyze the performance of stand-alone photovoltaic (PV) systems [5]. The system continuously collects and displays key electrical parameters such as voltage, current, and power, and also enables the real-time visualization of PV panel characteristics and the estimation of solar radiation.

Many other implementations use sensor networks or sensor arrays. Researchers in [6] demonstrate a parallel data acquisition method based on a single bus sensor to properly synchronize temperature gradient data from a multi-sensor array. They achieved a very low time for the parallel distributed data acquisition of 150 temperature sensors. Currently, many research teams are concentrated on application-specific DAQs over FPGA programmable logic devices, to allow for easy and no-cost redesigning of the system, adding and/or changing functionality [7,8]. Such an approach is currently prospective, as the system design itself remains platform- and target-device-independent. For example, the author presents a real-time data acquisition system that utilizes a Spartan 6 FPGA and a LabVIEW-based GUI to monitor voltage, current, and temperature signals [9]. The system converts analog sensor inputs to digital signals via an ADC, processes them through a system-on-chip architecture written in Verilog, and transmits the data to a PC using an RS-232 serial interface. The acquired data are visualized numerically and graphically on the PC and can be stored for future analysis, maintenance, or reference.

Recent studies highlight the growing role of FPGA-based architectures in both high-speed data acquisition and intelligent signal processing, demonstrating their effectiveness in ensuring real-time performance and reliability across diverse applications—from general-purpose sensing systems [10] to healthcare-focused signal classification using CNN accelerators [11]. In [10], the authors present a high-speed data acquisition system implemented on an FPGA using VHDL, designed to handle rapid input signal changes without data loss. The architecture integrates an 80 MSPS ADC, optimized DMA for uninterrupted data transfer, and DDR3 SDRAM for storing digitized data. The results confirm the reliability of real-time acquisition and storage, demonstrating the FPGA’s effectiveness in ensuring accurate and lossless high-speed data collection.

The other research [11] proposes a novel FPGA-based solution for classifying aggregated ExG signals (ECG, EEG, EMG) using a 1D convolutional neural network (CNN) accelerator. Implemented on the Xilinx Zynq xc7z045 platform, the proposed design achieves a 1.14× speed improvement compared to other FPGA implementations on the same hardware. Its optimized pipeline architecture and high classification accuracy make it highly suitable for real-time processing in wearable healthcare devices.

The research work [12] presents an FPGA-based data acquisition system that uses an outside 16-channel, 14-bit ADC to measure multiple analog signals simultaneously at a frequency of 50 MSPS. It also performs complex signal processing, but unlike our proposed design, does not feature encryption. It is also confirmed that with a AMD Kintex UltraScale FPGA, it is possible to perform measurements on all ADC channels.

A critical research challenge is the investigation of secure data collection and storage mechanisms applying FPGA-based architectures, given their potential for high-performance, low-power, and reconfigurable security solutions. The study in [13] investigates the power efficiency of AES encryption and decryption on various FPGA platforms, highlighting a key security concern—high energy consumption. Through an experimental comparison across five FPGAs and multiple frequencies, the Kintex-7 Low Voltage FPGA at 1.6G Hz demonstrated the best performance, reducing on-chip power use by over 20% compared to the Artix-7. The findings support the use of optimized FPGA architectures like Kintex-7 LV for implementing secure and energy-efficient AES encryption in hardware-based security systems.

Some groups have addressed IoT security challenges by proposing an FPGA-based design that combines AES-128 encryption with Dynamic Partial Reconfiguration (DPR) to optimize resource usage [14]. By enabling the same hardware to perform both encryption and decryption through reconfigurable logic, the system reduces the hardware area by up to 33% and energy consumption by 43.75%. Implemented on a ZC702 board, the design demonstrates an efficient and low-power cryptographic solution suitable for securing IoT devices.

In complex system-on-a-chip designs, security challenges are addressed by integrating machine learning algorithms and cryptographic systems to mitigate multithreading errors and malfunctions [15]. The proposed architecture ensures security at three levels: data integrity, authentication, and encryption/decryption using SHA-256 and AES algorithms. The hardware–software integration is achieved through a Verilog-based hybrid deep learning design, which is quality-checked using the LINT tool and interfaced with a Zynq processor via the Software Development Kit (SDK) for verifying secure data transfer.

3. System Components

In this section, the different modules of the proposed solution are discussed and their working principles are explained.

For our system design, a set of hardware resources was used. A Digilent Basys3 [16] development board was utilized, featuring cost-optimized AMD Artix-7 35T FPGA chip [17]. The chip offers the advantages of a modern FPGA reconfigurable architecture manufactured with a 28 nm technology process. It operates at 100M Hz frequency and provides sufficient resources of any kind (logic blocks, memory, I/O blocks, clock sources, etc.) inside its architecture. The device collects and stores the input measured data on its SRAM resource memory, as part of the FPGA. When a computer is connected, it can establish communication over the USB interface and retrieve data in UART format.

The designed FPGA-based architecture includes several modules performing the required dedicated tasks, as shown in Figure 1.

3.1. Data Acquisition Module

The data acquisition module collects data and constructs a package for further processing. The conversion of analog input data from the sensor in digital format is performed by the integrated Artix-7 FPGA chip ADC, which provides 12-bit accuracy and a sampling rate of up to 1 Msps (mega samples per second). The 100M Hz clock frequency ensures a sufficient number of clock cycles per reading to process the incoming analog data even at the highest possible frequency. In the actual implementation, the measured unit is temperature and new packages are formed at an interval in the order of seconds, but there is capacity to support a much higher frequency (conversion capability up to thousandths of the degree Celsius, if required). The module also tracks the current time in a format, known as Unix timestamp (seconds since 1 January 1970). The initial time is set by the operator of the device using the buttons and switches on the development board while receiving feedback from the four seven-segment indicators available.

Data collection is performed periodically, and at each measurement a corresponding package is constructed. The content of the package includes 32 bits for the timestamp followed by 32 bits for the measured value, making a total of 64 bits—Figure 2. Thus, the data lengths are convenient for processing with a computer when they are retrieved.

3.2. Encryption Module

Data security is an increasingly important feature in today’s world of cyber threats. The AES algorithm is a symmetric cryptographic algorithm with excellent security for the current state of technology and has become the standard in various applications, including banking, secure communications and web security. It is also well supported in software and is an essential part of the OpenSSL library version 3.2.4 [18]. The algorithm relies on the mathematical concepts of matrix multiplication, bitwise operations and Galois fields of the type GF (2⁸).

In the current implementation, the encryption algorithm employs a conveyer principle. That way, it benefits from the advantages of the FPGA chip. The frequency of encryption that is achieved is very high. It can be calculated in the following way. An encrypted package in AES has a length of 128 bits. Since the design can encrypt one package every clock cycle, the throughput of the implementation in bits per second would be 128 bits x 100 million Hz clock = 12.8 billion bits per second = 12.8 Gb/s.

Something important to note is that the length of a package from the data generation module is 64 bits, while the length of the AES encryption package is 128 bits. This issue is resolved by adding a buffer in the AES wrapper module that has a length of 128 bits. Encryption is performed once two packages of data have been generated, filling exactly its length. The wrapper module itself instantiates the AES implementation module internally and provides an interface that other modules in the design can use. That way, there is a completely reusable general-purpose AES implementation module that takes a stream of inputs continuously and produces encrypted data after a fixed delay and a purpose-specific wrapper for that module that passes new data to it and signals the next module in the design when the encrypted data are on the output. Since data are transferred in parallel from the data collection module to the AES wrapper module, there is no risk of misaligned packages.

The cryptographic key length in the AES algorithm can be 128, 192, or 256 bits. The actual implementation provides a VHDL generic construct that can be set to either of these values before synthesis, with the default value being 256 bits, making it very versatile. The cryptographic key is stored in a block of RAM memory from the internal resources of the FPGA. It is not configurable while the device is working and is initialized on startup with a value from the code. If the key needs to be changed, a new synthesis of the design must be run.

The AES algorithm can be described as two distinct procedures. The first one is the generation of the key schedule. It is an iterative application of operations, starting with the value of the initially set cryptographic key. These operations are repeated a number of times, depending on the length of the key. This procedure is performed only once during initialization and since the cryptographic key cannot be changed while the device is working, it is never performed twice or more. The second procedure is the encryption itself. It is also iterative and each iteration takes the 128-bit state from the previous one and produces the next state based on it and the corresponding part of the key schedule. The number of states that are produced can be 10, 12 or 14 depending on the key length [19]. Because of the conveyer principle in the implementation on every clock cycle, all of the states need to be read and written and all of the key rounds need to be read simultaneously, as shown in Figure 3. This causes a large amount of resources to be used, potential timing issues and an inability to use RAM for both the states and the key schedule. Because of that, optimizations are implemented for the design to meet timing requirements.

3.3. Storage Module

The encrypted data are stored on the block RAM memory integrated in the FPGA chip. On the Artix-7 35T FPGA chip, applied here, the total amount of block RAM is 1.8 Mb, while the amount of memory in a single block is 36 Kb. There are multiple ways in which a block of RAM can be instantiated. The size of read and write operations of the memory can be between 1 and 72 bits, and each block of memory can be either used as one or split in two separate 18 Kb blocks. Multiple blocks can be cascaded so they can work as a larger block, and different structures like FIFO can be implemented just using the integrated logic of the RAM blocks. All of these features make the RAM memory very versatile and adaptable to different applications.

In this specific case, the RAM memory is used in SDP mode, which allows simultaneous access to two ports, one for reading and one for writing. This mode is chosen because it offers the best flexibility of implementation. Essentially, the application of the RAM is similar to FIFO, but unlike the FIFO structure that can be instantiated, when a read is performed, data are not lost. This is especially important for data security because, with FIFO, someone with malicious intent could retrieve all the information. Even if the data are meaningless to them due to encryption, they could still cause data loss without a way to recover it.

In the implementation, an encrypted package with a length of 128 bits is expected on the input. When a read signal is received, the oldest saved package that is not retrieved already is read and passed to the output. Both the read and the write lengths are 36 bits, of which 32 bits contain meaningful data. That way, reading or writing a 128-bit package to memory takes exactly four clock cycles to complete.

The realization of a structure similar to FIFO is performed with a register that stores the current read and write address. As is shown in Figure 4, when FIFO is implemented using SDP RAM memory, the address for reading is always the address after the previous read. In the implementation, there is a buffer that is incremented every time a read is performed and passed directly to the read_address for the next reading operation. The signals displayed in Figure 4 are the signals of a module for low level access to the RAM memory, where read_addr and do_read are signals that are directly passed to the RAM instance, while curr_read_address is a buffer.

3.4. Communication Module

The device needs to implement facilities for receiving commands and sending data to a computer application. That task is performed by the module for two-way UART communication. UART communication is performed over a USB interface. From the standpoint of the FPGA chip, Rx input and Tx output lines are visible. The conversion of the data stream between UART and the USB protocol is performed by the dedicated FTDI 2232HQ chip, which supports the USB 2.0 standard with speeds of up to 480 Mb/s and can transfer UART data with up to 12 Mbaud baud rate. In this implementation, a baud rate of 115,200 is used.

The communication between the DAQ module and the computer application that collects data is organized in the following way. The device acts like a server and does not actively initiate any actions over the connection. The computer application controls communication with commands that are also defined on the module. When the application attempts to retrieve data from the device, it sends a single byte command to it and the requested data are sent back through the connection. When it is received successfully, a confirmation is sent to the device that data transfer has been successful with another one-byte-long command.

In both directions, the UART communication is configured to have eight data bits, one parity bit and one stop bit. As the standard specifies, the start bit is always a ‘0’, the parity bit is determined by the data bits, being ‘1’ when the number of ‘1’s is odd and ‘0’ otherwise, and the idle bits are always ‘1’s.

To handle incoming commands in the UART module, a state machine is implemented with predefined command codes. Its sub-modules include a module that sends 128 bits of data and a module that receives a single byte. A FIFO structure is implemented in case the design needs to be modified to receive a larger amount of data from the computer.

When a one-byte command is received in the UART controller module, a request is sent to the storage module. When the read is ready, the storage module signals the UART module and passes a newly read 128-bit package with encrypted data. When a new package is ready to be sent, the UART module serializes it and passes it over the UART communication. After that, confirmation is expected from the other side of the communication. If no confirmation is received, nothing is done. In the case where a command for repetition of the data is received, the same package is resent, and confirmation is awaited again. If confirmation is received, the module moves to a state where it can accept a new request for data.

3.5. Application for Communication from the Computer Side

For retrieval of the data collected by the device, a separate Linux computer application is developed. Its purposes are to send commands to the device and to receive, decrypt and store data permanently. This is a console application, which makes it suitable to be used inside scripts if more complicated features need to be implemented. The language in which it is written is the C programming language, using some Linux-specific functionalities. It can offer good performance on any device that uses Linux OS and utilizes only one thread, despite performing various asynchronous operations.

The application listens simultaneously to standard input, UART communication and timer events. This is achieved by using the ‘epoll’ Linux functionality that allows multiple file descriptors to be tracked and actions to be performed when an event is detected. Overall, the application has an event-based architecture.

The application expects to receive encrypted data. For that reason, it needs to have a decryption mechanism. Unlike in the FPGA, here, the mechanism is not implemented. Instead, the implementation in the OpenSSL library is used. When the application is executed, a file with the same encryption key that is set on the device is passed as an argument.

There are three CLI commands defined in the application. The command “fetch” sends a request for just one entry in the FPGA device. If an entry is received, the data are decrypted, displayed in a human-readable form and stored in a CSV file. One package received from the device should contain two consecutive measurements. Another command that is defined is the command “fetch all”. This command sends a request to the device just like the first one. Unlike it, however, once a package is received, another request is sent immediately and that continues until no response is received from the device. To determine that all the data saved on the device is retrieved, a timer event is used that creates a read event on a file descriptor once a certain time has passed. That way, with the sending of each request, a timer event after one second is scheduled. If a package is received before the timer expires, the timer is stopped. If no data are received before the timer event, a message is displayed, indicating that all packages on the device are retrieved and in the case of a “fetch all” command, the sending of requests to the device is stopped. The last command is “terminate”. It is used to terminate the application’s execution, freeing all used resources.

With this computer application, the full functionality of the device can be utilized. Although most of the required data processing is performed on the FPGA, the application stores everything that is received in a CSV file, where the date and time is in a format that can be easily sorted and the temperature is in °C with three digits after the decimal point, converted from thousandths of the degree. The CSV file can be exported directly to software like Excel and a graph of the data can be easily built.

4. Simulations and Experimental Results

In this section, RTL-level simulations of the different modules and results from the experimental setup are presented. The RTL results demonstrate that the design works as intended in simulations and provide a good visualization of the modules’ working principle. The experimental results confirm that the prototype functions properly on the actual hardware.

4.1. Data Collection Module

Here, we present some results from the simulation of the prototyped system’s modules that present its main functionalities. Figure 5 shows simulation data of the conversion function. The simulation passes through all possible 12-bit values from the ADC to the input and displays what the output would be. The algorithm for conversion is linear interpolation and, as displayed in the simulation results, it accurately converts the received data to thousandths of the degree. The ADC is implemented directly into the design as an IP to represent the physical structure of the ADC as part of the FPGA architecture.

4.2. AES Encryption Module

The AES encryption module has two main parts. The first one is the wrapper, which is used as an application-specific interface for the second part, which is the algorithm’s implementation.

Figure 6 presents simulation results from the encryption. First, 64-bit measurements are passed to the data encryption module. The encryption, however, is performed only when every second package is received. That way, the 128-bit encryption package is populated with two 64-bit packages with collected data. In the simulation, it can be seen that there are two different values on the data_to_save signal for the two different sets of data that are passed (all zeroes and “00” to “0F” in hexadecimal). Every time a new data package is encrypted, the signal onew_data is inverted to signal that there is new data to the memory module.

In Figure 7, the generation of the round key is demonstrated. When compared with the key schedule, produced by the OpenSSL library, and given the same encryption key, the result is exactly the same. The encryption result in Figure 6 matches the one produced by OpenSSL, too. The results of the OpenSSL library used for comparison are shown in Figure 8.

4.3. Memory Storage Module

In Figure 9, the data that is found in the data_to_save signal is written to memory. This simulation shows only the way of signaling that there is new package to write.

In the simulation in Figure 10, a read operation is performed in which the same data package written in Figure 9 is read. The result can be seen in the data_read signal, and the read_ready signal is inverted when the read operation is ready. Before the point displayed in the simulation, the signal read_request needs to have been inverted to initiate the read operation. As can be seen from the simulation time on top, the time of the read is after the time of the write.

4.4. UART Communication Module

Figure 11 depicts how the two-way communication works. For that purpose, some of the sub-modules of which the UART communication module on FPGA is built are used to simulate the computer side. A state machine is implemented inside the testbench which sends commands for data retrieval, expects to receive data, and sends confirmation indefinitely. On the FPGA side, the UART controller module is used as it is, but the memory module is simulated by providing constant output data and signaling that new data are read from memory immediately after a read request is sent.

This simulation can be viewed as a timing diagram for the UART communication and serves as a depiction of the working principle of the communication. The codes of the commands can be seen in the pc_byte_send signal (circled in Figure 11: commands d2 for data confirmation and 72 for a request). The same data from the tx_send_data signal can be observed to be received in the pc_byte_rcv signal. The communication can also be seen in the Tx and Rx signals in UART format.

4.5. Implementation Results

Timing closure, resource usage and frequency are important aspects of every design. The chip used for the prototype is XC7A35T with a clock frequency of 100M Hz.

The timing requirements are met by the design, as shown in Figure 12. After implementation, the device utilization report—Figure 13—confirms that all types of resources needed to implement the actual design are far below the chip limitations (from 12% for the FF to 51% for the block RAM).

4.6. Results of the Computer Application’s Execution

Figure 14 demonstrates the CLI application with the command for running it and the execution of the internal command “fetch”. The way of executing the application is by passing the path to the device file inside the “/dev” directory and a file where the encryption key is written as plain text in hexadecimal format. A package is received and displayed in an encrypted and in a human-readable way.

The collected data are stored in CSV file format generated by the computer application during data retrieval. The timestamp is in an easy-to-sort format and the temperature has an accuracy of three digits after the decimal point.

The diagram in Figure 15 shows the data collected in a 25 min period at an interval of 10 s. It can be observed that there is a spike in the reading. This spike was caused on purpose by touching the sensor and affecting it with body temperature. The diagram was created by directly importing the file generated by the application into the applied software.

The focus in this article is not on the accuracy or methodology of readings but on the data processing and convenience of use in the DAQ system. For that reason, no accuracy estimation is provided.

5. Discussion

This section addresses the research questions formulated in the earlier part of the study, focusing on the impact of integrating single-key encryption within a synthesized FPGA-based architecture for secure data acquisition.

Research Question 1: Does the integration of single-key data encryption enhance the security of data acquisition systems?

In [14], both encryption and decryption with AES-128 are implemented and there is a focus on efficiency, using advanced FPGA features like DPR (dynamic partial reconfiguration). The proposed solution in this paper also features an implementation of encryption with the AES algorithm, but the key is 256-bit and the focus is on performance and efficient pipelining.

The device implements a hardware encryption mechanism using the AES algorithm, which encrypts the data streams in real time with high speed and a minimal delay. After encryption, encrypted data are stored in the on-board SRAM memory of the FPGA and maintained until restart of the system. Data retrieval from the FPGA device is performed using a purpose-built computer application that handles communication decryption and long-term storage of data. The encryption 256-bit key remains secret for all unauthorized users as it is part of the overall architecture of the device. It is impossible to extract the key from the overall architecture.

Research Question 2: Does the use of a synthesized architecture enhance the flexibility and re-configurability of data acquisition systems?

The reconfigurability and flexibility of an FPGA-based design are commonly used in many studies [7,8,9,10,11,12,13,14]. In [12], a high frequency of sampling at 50 MSPS is achieved with an outside ADC, which is higher than the 1 MSPS in the proposed design achieved using embedded ADC in the FPGA. Similar to the articles mentioned, in the proposed design, an FPGA-based architecture is used but there is a stronger focus on security.

The system implements data encryption with a single key as part of the synthesized architecture, as well as data processing and computer communication that form flexible and easily reconfigurable data acquisition functionality. All modules of the system are defined using HDL, so it allows further unlimited and no-cost redesign and adjustment of their functionality, different from that described in this sample application. For communication with the designed system, a separate Linux application is developed that arranges the data transfer to/from the main computer over a USB interface.

Since the included modules are easily software redefined, any physical unit that can be represented as an analog voltage at the output of the corresponding sensor can be measured and processed at frequencies of up to 1M Hz with minimal changes to the design.

The FPGA device acquires output voltage from an external analog sensor for which a subsequent conversion is implemented. Input data are converted to digital with the built-in ADC. This digital value is then calculated to a corresponding unit of measurement, based on specific manufacturers’ look-up tables of the sensor, which reflects the nonlinearity of the output value. Then, the acquired data from the measurement and the timestamp together are encrypted with a specific key and method. Finally, all data are sent via UART as a stream to be stored on the on-chip RAM and extracted on request to the main computer for further processing and analysis.

In terms of performance, there are limitations in the different modules. Regarding the frequency of measurements, the following restrictions are present: (1) The ADC max frequency is 1M Hz for our system implementation. It limits the rate of measurement from one sensor. If the design is modified to measure readings from multiple sensors, however, a higher frequency of data collection might be achieved. (2) The throughput of the AES algorithm is one 128-bit package or two measurement packages per clock cycle at a frequency of 100M Hz. (3) It also takes four clock cycles to write a measured reading to RAM. This restriction can be removed by writing into multiple RAM blocks simultaneously. However, it is not needed in the current design. (4) The UART communication in the current design is set to 115,200 baud, which means that thousands of measurements can be transferred per second. This frequency is high enough for low-frequency measurements. The maximum allowed frequency for the UART over USB interface, using the FTDI FT 2232 HQ chip, is 12 Mbaud, which would still be lower than the 1M Hz frequency of data collection, but with the RAM storage, data can be collected at a rate that is higher than the rate of transmission.

6. Conclusions

In this article, a device is developed that collects, saves and protects data. It also keeps the acquired data while powered on. The benefits of the FPGA architecture that is chosen are real-time processing, low energy consumption and excellent data security. The low energy consumption can be of use if the device is powered by a battery.

The FPGA implementation facilitates security, reliability and performance that would be hard to reach with a more typical architecture, utilizing a microcontroller. The AES implementation offers a very high speed that cannot be a bottleneck in the design.

All modules in the device are implemented in a flexible way and modifications like removing functionality or adding a new one are relatively easy to achieve. The Linux application that has been developed is well integrated with the FPGA device and is made in a way that could prevent some issues with communication. It is possible to run more than one instance of the application at the same time.

A possible addition to the current design would be a way to save data in a non-volatile way. Since data are collected in an encrypted manner, access to the non-volatile memory would not be sufficient to obtain access to the encrypted information. Another addition could be the connection of multiple sensors. The integrated ADC in the FPGA provides excellent functionality for multiplexing between analog signals and even the possibility of reading bipolar signals.

The platform that has been developed can be applied in its current state or as a part of a larger FPGA project. It also offers large potential for continued development. There are plenty of free resources left after the implementation of this design on the Artix-7 35T chip and more features can be added.