dataesr/scientific-paragraphs-categorization huggingface dataset:
Notably, the best performance is achieved   when employing a latent vector of size 16. Additionally, the impact of adding n layers between two layers of the reference architecture, each having the same size as the layer before, is shown in Figure  16b. It is obvious that n = 1 is the ideal value. After 2,000 epochs, the NMAE of the optimized model on the first and second test datasets are 6. 6 × 10 -3 and 4. 1 × 10 -3 respectively. Table  4  shows the performance of the network and the result of reconstructed ε p,l using 12 latent variables.
The first dataset is created using the FEM simulation with load applied in a single direction. Each simulation consists of 10,800 time steps. To create a single inputoutput data pair, a sequence of 61 time steps is selected and first 31 are allotted to the input and the remaining is the output. By selecting various combinations, a total of 9,000 input-output pairs are generated from one resulting a 360,000 input-output pair from 40 simulations. A second dataset is also created with loading cases, yielding 1,800,000 input-output pairs. The number of LSTM units used in both the encoder and decoder parts of the NN III is one of the most crucial hyper-parameters to optimize in this network. Because both input and output have the same shape, here we use the same number of LSTM units in both the encoder and decoder.
This design allows for a seamless flow of information and promotes consistency between the encoding and decoding processes. Figure  17  shows the relationship between the number of LSTM units and two key metrics, namely the NMAE and training time for the first dataset over 500 epochs. To achieve a balance between computational time and NMAE, the optimal number of LSTM units is 512. After 1,000 epochs, the NMAE of the optimized NN III (with 512 LSTM units) on the first and second test datasets (10% of total data) is 4. 56 × 10 -7 and 1. 10 × 10 -6 , respectively. In Figure  18 , the predictions of the latent vector z u using NN III are displayed. The NN model is trained with 1,000 epochs on the second dataset, and randomly selected data from the test dataset of the second dataset is used for plotting.
The plot shows 5 out of 50 latent variables that are randomly selected. The prediction using 512 LSTM units in the NN model is reasonably accurate. However, the prediction with 756 LSTM units matches well with the ground truth, as shown in Figure  18c. It is important to note that the predictions of the latent variables with 128 and 1024 LSTM units are not displayed in the plot. This is because the predicted latent variable has a poor match with the ground truth for 128 LSTM units and an excellent match for 1024 LSTM units. Figure  18  displays the prediction of the z u using NN III trained with 1,000 epochs on second dataset with 256, 512, and 756 LSTM units of randomly selected data from the test dataset of the second dataset. Randomly selected 5 out of 50 latent variables are displayed in the plot.
Using 512 LSTM units, the prediction is reasonably accurate. The prediction with 756 LSTM units matches well with ground truth, see Figure  18c. Note that the predictions of LV with 128 and 1024 LSTM units are not shown since the predicted LV has a poor and excellent match with the ground truth, respectively. Similarly, Figure  19  showcases the predictions of the variable z εp using NN III with the same configuration as before. Out of the 12 latent variables, four are chosen for plotting purposes that are varying with time. It is evident from the figure that using 756 LSTM units yields the best results. We analyze the robustness of the trained NN III of 756 LSTM units on unseen data with inputs different from the two training datasets on which it was trained. We use the same test configurations as in Section 4.
NN IV training and evaluation The reference NN (first guess) model used to train NN IV is displayed in Figure  21. In this architecture, the input displacement layer u t l of size [40 × 3] is encoded to a dense layer of size 1,600 using convolutional layers. The encoded layer is combined with the other input layers v t Γ and ω Γ t. The number of dense layers added between the output layer r t Γ and combined layer is one of the hyper-parameters we optimize in this section. After 1,000 iterations, the NMAE of the optimized NN IV on the first and second test datasets is 2. 4 × 10 -3 and 1. 02 × 10 -2 , respectively. The trained model is verified on the same test configurations as in Section 4. 2. 1. The performance of the trained NN IV for various test configurations is tabulated in Table  6.
Data generation Let us consider a spotweld domain as shown in Figure  23. The edges of bottom plates are clamped and the loading is applied on the edges of the top plate for 1. 5 ms. The integration time step is set to a constant value ∆t l = 5. 0 × 10 -5 ms, calculated based on  (2). The training dataset was constructed using a total of 60 simulation cases, using various loading magnitudes and directions. The minimum and maximum magnitudes of loading applied in each direction are listed in Table  7. These extreme values denote the approximate maximum and minimum load capacity of the material, respectively, before failure occurs. The first 22 simulations correspond to instances in which the loading is applied in a single direction, while the remaining simulation cases correspond to loading in two different directions simultaneously.
In this study, snapshots of the simulation were created by saving the global interface velocities, denoted as v Γg , the global interface forces, denoted as r Γg , and the displacement of the local domain, denoted as u l , at selected time steps. Each simulation contains approximately 3,000 time steps. Unlike the previous example presented in  Section 4 , the quantities at the interface nodes are chosen at the global interface nodes. The model contains a total of 24 global interface nodes. Furthermore, the local displacement u l was interpolated to a regular three-dimensional cartesian grid of size 31 × 31 × 8. As in the previous example, the data is partitioned such that 80% of the total dataset is used for training the network, while the remaining 20% is divided between cross-validation and test datasets, with each set comprising 10% of the total data.
Note that unlike the previous example, the magnitudes of the test cases have been limited to the range of magnitudes used in the training dataset to prevent failure of material. In this study, we investigate the robustness of trained PGANN on unseen data using the test cases presented in Table  9. To evaluate the performance of the PGANNs, we compare the displacement predicted by the NN (NN I and NN II) with the reference displacement obtained    from FEM. The results of this comparison is presented in Figure  25 , where the displacement at the final time step t = 1. 5 ms for each test case is displayed. The NMAEs corresponding to each case are shown in the bracket. Additionally, we also evaluate the prediction of the LVs using NN III, which was trained with 756 LSTM units. The results of this evaluation are displayed in Figure  26.
When introducing UEFI drivers, it is crucial to ensure that they are signed and added to the Secure Boot database  [19]. When a system is using secure boot, each piece of boot software is accompanied by a digital signature. This includes the bootloader and the operating system. These signatures are then compared to the keys stored in the firmware. If the keys match, the system boots up. If not, the system will stop booting. There are various types of secure boot solutions: • Recoverable Malware Protection: In this method, the secure boot process includes the ability to recover from a detected malware attack  [20]. This could mean a reset to factory settings or a rollback to a previous safe state, depending on the particular implementation. • Multilayered Security Features: This refers to the use of several different security measures together to protect the boot process  [21].
1) Secure boot with recovery The Code Authentication and Resilience Engine (CARE) is a hardware-based secure boot solution designed for the RISC-V system  [20]. Its hardware implementation improves security compared to software-based solutions. CARE protects against rootkit malware (malicious programs that gain unauthorized control over a computer while concealing their activities) and BIOS and secure boot attacks (attacks that exploit firmware to run unauthorized code during a system's boot process). It is good to mention here that conventional secure boot protocols only halt the boot sequence upon detection of an integrity anomaly, requiring software re-flashing, but here CARE provides recovery of the system. As shown in Figure  3  CARE is placed between the first stage boot code of the ROM and the second stage boot code of the flash.
CARE relies on a secure SPI (Serial Peripheral Interface) bus to communicate with ROM and Flash, and it securely stores data, like signing keys and device information, in the ROM (with specific access policies), which is critical for the device's recovery and security. As depicted in Figure  4 , CARE has two main components: the code integrity and authentication (CA) unit and the resilience engine (RE). When the system is powered up, the first-stage bootloader initializes the SPI and flash controllers and applies the memory protection rules. The control is then passed to the second stage boot code (bootstrap). The flash code is divided into frames and sent to the CA over the SPI bus. The frame is composed of a header with the signed digest of the data frame, the frame number, and the flash memory location; the rest of the frame is the payload.
While, theoretically, the flash can be automatically reloaded from ROM as the initial step of the secure boot, this approach can introduce significant operational overhead, especially for systems with large flash memories or where boot speed is critical. Moreover, CARE provides additional flexibility and recovery options that simple reloading may not offer. For example, CARE can identify and recover from issues at a granular level (i. e. , frame level) without requiring a complete reload of the entire flash memory, which can be beneficial in scenarios where quick recovery is essential or where network conditions might make fetching and reloading the whole codebase impractical. Furthermore, CARE can mitigate more advanced threats by providing an additional layer of security through its Code Integrity and Authentication (CA) unit and the Resilience Engine (RE).
This unit allows CARE to detect and recover from problems in a controlled and secure manner, which is impossible with a simple automatic reload mechanism. 2) Boot with boosted security features Another solution worth studying is ITUS 1  [21]. ITUS is implemented in LowRISC. LowRISC is an open-source SoC platform built around the open-source RISC-V ISA. ITUS aims to provide a trusted system through several security mechanisms, including secure boot, encryption, and authentication of off-chip memory accesses, key management, and cryptography acceleration. Those security features make it possible to create enclaves, which are isolated trusted execution environments used to protect sensitive data and processes. ITUS focuses on mitigating attacks that aim to gain unauthorized access to sensitive data, such as Rowhammer, Meltdown, or Foreshadow.
This ensures that only software with a recognized cryptographic signature is executed, enhancing the system's resistance against malware intrusions  [27] ,  [28]. One of the most sophisticated malware, Stuxnet, discovered in 2010, primarily targeted industrial control systems, specifically those associated with Siemens' Supervisory Control and Data Acquisition (SCADA) systems  [29] ,  [30]. Its propagation methods included the compromise of USB drives, leading to the execution of malware after its insertion into a system. By ensuring the integrity of the boot process, secure boot thwarts such malware from executing its malicious payload, especially if it attempts to modify boot or system files. Another notable incident, the Jeep Hack of 2015, saw security researchers remotely manipulating a Jeep Cherokee's functionalities by exploiting vulnerabilities in its entertainment system  [31].
While secure boot primarily safeguards the boot process, the overarching principle of executing only trusted software can be extended to other systems. In vehicular contexts, if the critical systems were isolated and restricted to run only signed, trusted software, it would significantly reduce the risk of such remote attacks. However, while a secure boot offers a formidable line of defense, it has challenges. Implementing secure boot, whether in hardware or software, can introduce performance overheads. This translates to increased area requirements in hardware, while in software, it can lead to increased power consumption  [32]. As we have seen before, CARE and ITUS present two solutions built on top of the RISC-V ISA. These techniques can be compared using a Trusted Platform Module (TPM)  [33].
However, the DICE engine cannot be universally implemented, as it requires the manufacturer to generate protected secrets, such as a unique device secret and specific certificates. On the other hand, ITUS and CARE present promising implementations of secure boot built upon the RISC-V ISA. They demonstrate minimal impact on system performance and offer additional security features, such as recovery or cryptography capabilities. However, it is vital to note that all these techniques require additional implementation on both hardware and software layers. Moving away from these active implementations, we will explore techniques that utilize existing internal indicators (passive implementations), like hardware performance counters or on-chip power sensors. We will also discuss techniques that leverage external power and electromagnetic field measurements, focusing on proposing a range of passive solutions.
However, external measurement techniques, which employ an external shunt resistor and external instrumentation, offer improved accuracy and flexibility. This superior performance is primarily attributed to the reliance on external hardware. However, this method may not be suitable for on-board malware detection because it requires physical access and proximity to the power consumption measurement instruments. In  [38] , the authors hypothesize that a malware execution produces enough changes in power usage to be able to detect its presence. To do so, they collected power profile data from a machine running in a clean state: only the OS, Internet Explorer (IE) running, and Regedit running. The machine is then infected with a particular malware, and the power profiles of the machine running with the malware, the machine running Internet Explorer with the malware, and the machine running Regedit with the malware are collected.
Therefore, six power profiles (three clean, three with the malware) are collected for each malware sample. Five malware samples are tested, all rootkits: Alureon, Pihar, Sirefef, Xpaj, and MaxRootkit. Two approaches are tested for the data analysis: • An unsupervised approach using ensemble voting of one-class anomaly detectors. • A supervised approach using kernel-based Support Vector Machine (SVM). The first approach uses several single-feature anomaly detectors that vote for the presence or absence of an anomaly. A value that deviates more than one standard deviation from the mean is flagged as an anomaly. The standard deviations and means are calculated from the training observations. This method reveals that the overall classifier achieves 100% True Detection Rate (TDR), with a lower False Detection Rate (FDR) than the supervised classifiers.
The authors in  [44]  have collected HPC data produced by malware and benign programs to train a set of classifiers to detect malware. This experiment has been carried out to detect Android malware and Linux rootkits. The study concludes that HPC can detect malware with relatively good accuracy. This study collects data through a Linux kernel module, which interrupts the execution every N cycles to retrieve information from the HPC. These methods slow down the system's performance and imply software-based security. That is why hardware implementation of such security features is preferred. Malware Aware Processors (MAP), as presented in  [45]  and  [46] , provide real-time malware detection on the chip; they are implemented on hardware by using simple classifiers. MAP is presented as a first line of defense so that when malware is detected, heavier software can be triggered for malware detection and remediation.
D. OFF-BOARD SIDE CHANNELS Some techniques can help detect malware execution at runtime through off-board measurements. Off-board measurements consist of physical measurements performed from outside the main circuit board. In  [40] , the objective is to analyze the electromagnetic emanation of a device running software and to detect and classify malware. Here, the assumption that malware changes the device's behavior regarding electromagnetic emanation has already been proven. The experiment used a Raspberry Pi 2B as the target device. This device is configured so that each malware ex-ecution will find valid files and will target them as it would normally. The malware dataset under test consists of DDoS malware: Mirai and Bashlite (a C&C server is present in the test environment to send commands to the infected machine), ransomware: Gonnarcy and kernel rootkits: Keysniffer, maK_It.
Electromagnetic emanations are acquired through an oscilloscope connected to an H-Field probe with an amplifier. In total, 3000 traces for each of the 30 malware binaries and 10,000 traces of benign activities are collected, making a dataset of 100,000 labeled traces. For classification, neural networks are implemented because of their pattern recognition capabilities. Two architectures are compared: a Multi-Layer Perceptron (MLP) and a CNN. Other architectures, such as SVM or Naive Bayes, have also been tested but rejected due to their lack of robustness in more complex scenarios. The MLP takes flattened spectrogram bandwidths as input. The CNN comprises three blocks, each with one or two convolution layers followed by a max pooling layer. Here are the results: These results demonstrate that malware can be classified based on the electromagnetic emanations from the device under test, even when obfuscation techniques are employed to conceal the malware or when variations of known malware are introduced.
A. SOFTWARE-ASSISTED XAI FOR MALWARE DETECTION MalConv  [48]  is a popular neural network designed for static analysis. It can be trained to analyze the bytes of a file to determine if it contains malware or goodware. This architecture is effective for detecting sequence patterns thanks to embedding and convolution layers, as shown in Figure  6. Malconv was tested for multi-class malware classification in  [49]. The explainability of MalConv has been addressed in  [50]. One of the methods used was decision boundary analysis. In a data space, that is, a space with enough dimensions to represent the possible combinations of the inputs, a decision boundary is a separation between data classes. In  [50] , the decision boundary is characterized by interpolating classified samples to find the moment of crossing from one class to another.
In parallel, the reverse engineering of the file produces a list of interesting indicators of maliciousness called Areas of Interest (AOI). Finally, the authors examine the overlap between the "manual" reverse engineering results and the explainability of low-level features and provide expert analysis insights. Increasingly, large language models are used for malware. For instance, IATelligence 2  brings information from GPT3  [53]  to provide details about parts of the examined file. More specifically, GPT3 is used to analyze the Import Address Table of a Windows executable file and to determine if there are potential related MITRE ATT&CK  3  techniques that can be used against these APIs. It would be interesting to see if the LLM can be integrated into explainability pipelines for malware detection.
V. DISCUSSION In this section, we compare the different techniques presented in the article in terms of metrics for evaluating malware detection. Our survey reveals that hardware-based techniques show great accuracy, with low performance overhead compared to other solutions such as TPMs. These techniques are well suited for IoT and embedded devices. Analyzing the current literature on detecting embedded malware, we have determined that ITUS  [21]  and CARE  [20]  effectively ensure the device's trustworthiness before usage. Additionally, CARE offers a recovery mechanism to avoid re-flashing the device in case of compromise. However, ITUS has more security modules, enabling the implementation of a Trusted Execution Environment (TEE) and enclaves. Other solutions require external hardware to exploit side channels to detect malware.
• Take the signal measurement at subsequent clock cycles of length d: w 1 , w 2 ,. , w d. • Perturb the measurement vector in n different ways to obtain n neighbor points. • Obtain the output values by running the perturbations n through the RNN network. • The perturbations and their outputs form a mini-dataset, which is used to train a linear regression model. The linear model mimics the RNN in the vicinity of the input signal w. • The linear model coefficients represent the weights with.
The CNN model stands out with the highest accuracy of 99. 82%. • Family classification: Samples are differentiated among various malware families in addition to the benign class. The results remain commendable, with an accuracy exceeding 97%. Once again, the CNN model achieves the highest accuracy at 99. 61%. • Novelty classification: Given the prevalence of variations of known malware in real-world scenarios, the models are evaluated against variations of the families being tested. These variations were not part of the training dataset. Despite this challenge, all models maintain a commendable accuracy of more than 92%. The CNN model shines with an accuracy of 99. 38%. • Virtualization and packer identification:.
, 2021). Nowadays, many empirical (regression or AI based) calculation schemes have been developed  (Sanders et al. , 1990; Savini et al. , 2020; Shammas, 2004) , along with theoretical optical formulae based on a pseudophakic model eye containing 3  (Haigis et al. , 2000; Hoffer, 1993; Holladay et al. , 1988; Retzlaff et al. , 1990)  or 4 refractive surfaces. Other approaches include numerical raytracing strategies, which use the tomographic measurements of the cornea together with the IOL design data to derive the appropriate lens power and predict the imaging performance of the pseudophakic eye (e. g. Okulix or PhakoOptics software). For example, the Olsen formula  (Olsen, 2007; Olsen et al. , 1995) , or the Castrop formula  (Langenbucher et al. , 2021 , Wendelstein et al. , 2022)  already make use of measurement data of the corneal front and back surface curvature to enhance the predictability of the postoperative outcome and to avoid the risk of misinterpretation of corneal power in patients with a history of corneal refractive surgery.
In total, a data set containing 35 422 measurements from a cataractous population taken with the IOLMaster 700 was considered in this retrospective data analysis. Incomplete data or data with an insufficient quality mark from the biometer were discarded before further analysis. All calculations are based on a pseudophakic model eye as shown in Figure  1. This model eye contains 5 refractive surfaces: a thin lens spectacle correction (refractive power: SEQ) at a distance VD = 12. 0 mm in front of the corneal apex, a cornea considered as a thick lens and an IOL considered as a thick lens  (Gatinel et al. , 2021; Langenbucher, Hoffmann, et al. , 2022). The thick lens cornea is specified by curvatures RC a and RC p at the front and back surface, a central thickness CCT and a refractive index nC.