esa-sceva/satcom-chunk-collection huggingface dataset:
# Hadoop vs. Spark: Impact on Performance of the Hammer Query Engine for Open Data Corpora
## 5 The _Hammer_ Prototype
### Evolving Step4/5 Executor toward Map-Reduce  
The work performed by _Step4/5 Executor_ is time-consuming, especially when the number of queries to process is large, as well as when the number of indexed data sets is only a few thousands (see Section 6). This motivates the introduction of the Map-Reduce approach, to try to improve performance.  
We decided to adopt a lazy strategy, in order to evaluate the impact of the minimal changes necessary to transform the single-process version of _Step4/5 Executor_ (Algorithm 1) into a Map-Reduce algorithm:  
* The first part of procedure **Step4/5_Executor** (lines from 1 to 3), which performs Step 4, becomes the _Map_ phase: each Map task executes procedure **Process_Query** on one single query. Consequently, the number of parallel tasks coincides with the number of queries in \(Q\).
* The second part of procedure **Step4/5_Executor** (line 4) becomes the _Reduce_ phase: results produced by the _Map_ phase are collected and evaluated against queries in \(Q\), by calling procedure **Evaluate_RM**.  
In order to activate Map and Reduce tasks, without relying on any specific framework, we make use of two pseudo-primitives: **Schedule_Map_Task** and **Schedule_Reduce_Task**. The former pseudo-primitive schedules a Map task, by specifying the procedure to call; the latter pseudo-primitive schedules a Reduce task at the end of all previously scheduled Map tasks, by specifying the procedure to execute.  
Algorithm 4 shows the modified versions of procedure **Step4/5_Executor**. Step 4 is always performed by lines 2 and 3; however, on line 3, procedure **Process_Query** is no longer called directly, while it is scheduled as a Map task. Similarly, on line 4, Step 5 is performed, but function **Evaluate_RM** is now scheduled as a Reduce task, in order to be executed when all Map tasks terminate.  
We developed two distinct implementations, one based on the _Hadoop_ framework, one based on the _Spark_ framework.  
Notice that we decided to adopt this strategy because we wanted to study the effect of the simplest transformation of the algorithm, without changing its structure. In fact, the reader can see that it was already naturally structured to be parallelized. This way, we can answer the questions: what is the effect of parallelization? Is Map-Reduce capable of fastening algorithms that were not thought to become Map-Reduce algorithms? Refer to Sections 6 and 7 for the answers.  
```
Procedure Step4/5_Executor(\(Q\), \(th\_krm\), \(th\_rm\))  Begin  MongoDB_Clear_FoundDS()  For Each \(q\in Q\)do  Schedule_Map_Task(ProcessQuery(\(q\), \(th\_krm\)))  End For Each  Schedule_Reduce_Task(Evaluate_RM(\(Q\), \(th\_rm\)))  End Procedure
```  
**Algorithm 4**Generic Map-Reduce version of **Step4/5_Executor**.
# Chained Anomaly Detection Models for Federated Learning: An Intrusion Detection Case Study
## 4 Evaluation
### Federated Learning with Blockchain Support  
With the addition of the MultiChain blockchain, both the weight updates and revised models are stored with each epoch on the blockchain. There are now two strategies to leverage the blockchain:  
1. A parameter server receives the weight updates directly from the deep learning servers and immediately processes them.
2. A parameter server only processes those weight updates that have been stored and validated on the blockchain.  
In both scenarios, the deep learning clients store their weight updates on the blockchain. However, depending on the block generation time (i.e., 15 s by default for MultiChain), the federated model averaging would be delayed a fair amount of time in the second scenario, especially if the parameter server waits for multiple block confirmations. However, the impact of this block generation and confirmation delay is relative to the actual duration of a single epoch, which for a single deep learning client is more than 1 min. Furthermore, we can reconfigure the block confirmation time in MultiChain to as low as 2 s and pause the block generation on a chain if there are no new weight updates as a method to reduce the number of blocks in a chain.  
The results of the first scenario are depicted in Figure 8. There is a slight delay caused by the blockchain--with a computational overhead varying between 5% and 15%--due to the fact that each deep learning client now also stores the local weight updates on the blockchain. The parameter server also stores the updated model on the blockchain. With a growing number of nodes, the blockchain needs to be synchronized more frequently. This causes interference in the network, albeit minimal. In the second scenario, the delays are more outspoken due to the block generation and confirmation times, even when waiting for just one block confirmation. For a target block time of 15 s, the time to generate a new autoencoder model update increased up to 41 s. We were able to reduce this to 13 s  
Figure 7: Federated training the autoencoder on benign data only using 20% of the data for testing.  
by lowering the target block time to 5 s. Additionally, it is not possible to change the target block dynamically time at runtime depending on the number of connected deep learning nodes, as this would be a security risk. An adversary could attempt to reduce this time and add blocks in a malicious manner.  
To minimize latencies, our proof-of-concept implementation relies on the first strategy, where the parameter server keeps track of unconfirmed weight updates for up to four block generations. In that case, it rolls back to a previous autoencoder model stored on the blockchain and discards any unconfirmed weight updates. In an online learning scenario with infrequent data updates, the second strategy is more appropriate.
## 5 Conclusions  
The study introduces a novel approach for farmers to enhance output, plant administration, and crop safeguarding using technology. It enables the early assessment of maize grain production on day 79 of the R2 stage, significantly improving upon traditional projections made during the black layer stage. The PEnseble 4 methodology has a remarkable accuracy of 91%, signifying a substantial improvement in predicting grain production compared to conventional methods. The researchers have effectively utilized ML techniques to develop a comprehensive model for predicting maize yield. This model provides accurate and data-driven predictions by combining environmental data from IoT sources and UAV data, such as soil properties, nutrients, weather conditions, and vegetation indicators. This research dramatically enhances agricultural output by offering farmers valuable insights to make informed decisions and adopt sustainable farming techniques. The selection of the most suitable model is contingent upon the unique attributes of each study situation. Ensemble and tree-based models are adept at capturing temporal trends in canopy density, whereas robust models that can handle high dimensionality and complexity perform exceptionally well in complicated circumstances. To improve the ability to make predictions, the researchers intend to continuously improve and optimize the ML model by utilizing sophisticated algorithms and approaches for feature engineering. Expanding the duration of data collection to encompass numerous growing seasons and a range of environmental variables would offer valuable information about how crops react and the variances in their yields. Integrating satellite imagery data with UAV data will improve the extent and detail of information, allowing for more accurate yield forecasts. By broadening the model's range, it can accurately forecast crop illnesses and pest infestations, offering crucial information for efficient disease control.  
Conceptualization, N.P. and A.T.; methodology, N.P. and K.S.; software, N.P.; validation, N.P., A.T. and K.S.; formal analysis, N.P.; investigation, N.P.; resources, K.S.; writing--original draft preparation, N.P.; writing--review and editing, A.T.; visualization, N.P.; supervision, A.T. All authors have read and agreed to the published version of the manuscript. This research received no external funding.  
Not applicable.  
The data presented in this study are available upon request from the corresponding author. The data are not publicly available due to the limitation of storage on cloud.  
The authors are grateful to the research and development team of K.S.P. Equipment Co., Ltd. for their assistance in procuring the necessary hardware and ground truth data. Additionally, the experimental area and plant management will be provided by Charoen Pokp-hand Foods Public Company Limited (CPF) and Chainat College of Agriculture and Technology, Chainart, Thailand.  
The authors declare no conflicts of interest.
## 4 Experimental Results and Discussions
### Experimental Setup
Furthermore, for different generations, even the same number of candidate solutions (including candidate paths and their opposite paths) may lead to different utilization rate of opposite paths. Generally speaking, the utilization rate of opposite paths is relative high during the former stage, while it is relative low during the later stage. The reason behind this variation is that, the population of candidate solutions is evolved over time towards better solutions and then more and more opposite paths may not be selected into the elitist population. For population-based intelligent algorithms, population diversity is undoubtedly one of the most important indicators of a population state. Measures to evaluate the population diversity play an important role in adaptively changing search strategies, in analyzing the behavior of soft computing algorithms, and in evaluating individuals to maintain population diversity in a positive manner. In this paper, an edge entropy measure is used to evaluate population diversity. The edge entropy was proposed by [PERSON] [35] firstly and defined as  
\[H=-\underset{e\in X}{\sum}\frac{F(e)}{N_{p}}\log(\frac{F(e)}{N_{p}}) \tag{5}\]  
where \(X\) is a set of edges included in the current population, \(N_{p}\) is the size of the population, and \(F(e)\) is the number of edges \(e\) in the current population.
# A Survey on Wireless Body Area Networks for eHealthcare Systems in Residential Environments
## 2 Candidate Wireless Technologies
### Alternative Low-Power Wireless Technologies
#### 2.2.3 RuBee  
RuBee [64] is considered an alternative to Radio-Frequency Identification (RFID). It is a bidirectional active wireless protocol that employs long wave magnetic signals (not RF signals) to transmit and receive 128 byte packets of data within a local network. RuBee is based on the IEEE 1902.1 [65] standard and is specifically designed to provide high security in harsh environments. Similar to the IEEE 802 standards, RuBee enables the networking of devices by employing point-to-point active radiating transceivers. This protocol operates at the low frequency end, 131 kHz. Similar to WiFi, Bluetooth and ZigBee, RuBee is an on-demand packet based protocol but with lower data rate. In addition, RuBee's low operating frequency provides a significant benefit in terms of power consumption. It can provide a battery life of up to fifteen years using a single lithium button cell battery and it is also able to provide a coverage distance of up to 50 feet according to [58]. However, RuBee's low operating frequency requires a bigger antenna size which makes this technology a likely inappropriate candidate for BAN applications where the size of antenna plays an important role. In contrast to RFID, RuBee does not have signal reflections and cannot be blocked by materials such as steel and liquid. Therefore, it is a robust technology especially in harsh environment visibility and security applications [66; 67].
## 2 Materials and Methods
### Chlorination Reaction
#### 2.2.3 Chlorination Procedure and Product Isolation
The solvent system used was a mixture of 0.1% trifluoroacetic acid in acetonitrile/water (25:75), at a solvent flow rate of 1.0 mL/min. The column effluent was monitored at 254 nm. The identification of DP1--DP3 and DP5 was achieved by comparison with a standard compound. The W13 fraction (78 mg), eluted with ethyl acetate/methanol (60:40, \(v/v\)), was dried, dissolved in an appropriate volume of water/ethanol (50:50, \(v/v\)), and analyzed using a Shimadzu 2010 series GC FID (Shimadzu, Milano, Italy). The gas chromatograph was equipped with an 80/120 CarbopackTM B AW/6.6% PEG 20M (2 m \(\times\) 2 mm I.D., glass). The following parameters were set during the experiments: carrier gas, nitrogen, injected samples, and 1.0 \(\upmu\)L, introduced into the injector using an AOC-20i auto sampler (Shimadzu, Milano, Italy). The initial temperature was 80 \({}^{\circ}\)C with a 2 min hold, followed by a 4 \({}^{\circ}\)C/min ramp to 200 \({}^{\circ}\)C with a 2 min hold. The identification of DP11, DP14, and DP15 was achieved by comparison with a standard compound. The fraction W15 (131 mg), eluted with ethyl acetate/methanol (50:50, \(v/v\)), was analyzed via HPLC using an octadecyl-silica ODS (2) column (15 cm \(\times\) 4.6 mm I.D.). The solvent system was a mixture of acetic acid, tetrahydrofuran, methanol, and water (1/2/10/87, \(v/v/v/v\)) at a solvent flow rate of 1.0 mL/min. The column effluent was monitored at 264 nm. The identification of compound DP13 was achieved by comparison with a standard compound. The fraction W22 (23 mg), eluted with methanol, was analyzed via HPLC with an electron capture detector (ECD), using a RP-18 column (25 cm \(\times\) 4.6 mm ID). The solvent system used was a mixture of 25% hexadecyltrimethylammonium chloride, KH\({}_{2}\)PO\({}_{4}\), water, and methanol (1:7.5:500:500, \(v/w/v/v\)) at a solvent flow rate of 1.5 mL/min. The identification of DP12 was achieved by comparison with a standard compound [39]. The structures of all the degradation byproducts are shown in Figure 3.
# Identification of Bottlenecks in Passenger Handling Processes Using Data-Driven Tools
## 3 Development and Excel-Based Implementation of the Simulation Model
### Simulation of Security Screening  
In the security screening subsystem, passengers are automatically and cyclically assigned to one of four available scanners immediately after completing their check-in process. This assignment is facilitated by a helper table, which distributes passengers to scanners in a round-robin sequence (1 through 4), as illustrated on the left side of Figure 5. Each scanner operates as an independent unit, meaning that a passenger is processed exclusively at their assigned scanner and cannot switch between devices during the simulation.  
As with the check-in desks, the duration of passenger service at each scanner is modeled using an exponential probability distribution. The generation of individual service times follows the same principle outlined previously in Equation (9) but applies a distinct mean service time (t_obs) specific to each security screening device. This enables the simulation to account for differences in scanner performance, staffing, or inspection protocols.  
Because the scanners function independently, the passenger screening process becomes relatively straightforward. However, it is still necessary to check two scenarios--whether the scanner is available or occupied. If the scanner is available, service begins immediately. If the scanner is occupied, the passenger must wait in the queue until the assigned scanner becomes free.  
The start time of passenger service is determined by comparing two values--the end time of the previous passenger's service and the current passenger's arrival time at the screening station. The larger of these values is taken as the start time of service. The end time is then calculated as the sum of the start time and service duration.  
The simulation tracks the same set of time-based performance parameters as used in the check-in process. These include the individual service time, service start and end times, queue time, and total time spent in the system. Such outputs are essential for evaluating  
Figure 5: Example of security screening process simulation.  
system performance, identifying potential bottlenecks, and optimizing the layout or staffing of the security screening subsystem.  
A table showing scanner assignments and a model of the first two security scanners with tracked characteristics are presented in Figure 5.
# SOLIOT--Decentralized Data Control and Interactions for IoT
## 7 Architecture and Prototypical Implementation
### Interactions and Protocols  
For the prototypical implementation, CoAP as a lightweight request-response protocol and MQTT as a publish-subscribe implementation have been selected. Respective endpoints for each protocol socket need to be opened, by default 1883 for MQTT and 5683 for CoAP.  
At each stage of the Digital Twin container hierarchy, the possible interactions are described through TD affordances. The affordances themselves impose regular RDF resources, and are treated as LDP children of their describing container. As such, the container links to them both through td:actions/td:events and ldp:contains attributes.  
In terms of MQTT interactions, several architectures are possible. For (a) point-to-point communication, an origin server could push its state to a MQTT Broker at the user agent. The user agent also deploys a client subscribing to its own broker, thereby receiving the sent message. Alternatively, the broker connector could be placed directly at the origin server, and all user agents interested into the resource state are subscribed there (b). Any event is then published by the origin server's internal MQTT client connector to this broker. This approach would, for instance, allow the origin server to control which user agents receives the messages.  
However, both approaches inherit significant drawbacks. In case (a), the origin server must know the user agent beforehand, which is an unrealistic assumption in a dynamic IoT network. Approach (b) requires that the device creating the data hosts an additional broker component. Embedded devices may not have the computing power or energy resources to do so. Furthermore, a 1-to-m, n-to-1, or 1-to-1 interactions as imposed by both (a) and (b) do not consider the strengths of MQTT but misuse the protocol to some degree. Communication patterns such as that can be implemented easier with other protocols and less overhead.  
Regarding the publish/subscribe pattern of MQTT, the assigned broker should be deployed outside of the SOLIOT instance but also of the origin server. The SOLIOT server only implements an MQTT client connector. In contrast to a state-based view of e.g., HTTP and CoAP, none of the CRUD interactions have been implemented yet. The information flow is therefore currently only supported from the SOLIOT origin server to the user agent. Next iterations of SOLIOT will address this issue and extend the current model unsafe interactions. This way, 'Things' with client sockets will be enabled to directly influence their own Digital Twin's Thing Description.  
Figure 7: Architecture Comparison.
# Design and Optimization of Non-Coplanar Orbits for Orbital Photovoltaic Panel Cleaning Robots
## 4 Conclusions  
This study explores and solves the problem of non-coplanar trajectory design and optimization for a photovoltaic panel cleaning robot for the first time. Based on the analyzed motion laws of the cleaning robot, this study established a trajectory model to obtain trajectory data. To ensure the robot's stability along its path, Bezier curves were employed as the smoothing model for designing the non-coplanar trajectory. Recognizing the significant impact of the scale parameter on the trajectory's shape, a nonlinear planning method based on the Sequential Quadratic Programming (SQP) algorithm was utilized to optimize the trajectory. The optimization results indicate that the performance of Bezier curves 1 and 2 improved by 35.63% and 40.57%, respectively. Furthermore, the optimization effects are corroborated by ADAMS simulation data, which reveal that the error values of the  
Figure 11: The simulation error curves for the four walking wheels: (**a**) wheel 1 error; (**b**) wheel 2 error; (**c**) wheel 3 error; (**d**) wheel 4 error.  
four wheels of the cleaning robot were reduced by a maximum of 8.79 mm, 23.78 mm, 10.11 mm, and 14.97 mm, respectively. The optimized robot demonstrated no jamming or derailment during the spanning motion phase, and its stability was significantly enhanced. This research provides a foundation for the photovoltaic panel cleaning robot to perform large-area-spanning cleaning tasks, ensuring the automated cleaning of large-scale photovoltaic power stations, which is crucial for environmental protection and improving power generation efficiency.  
Conceptualization, Y.Q.; Methodology, Y.Q.; Software, B.X.; Formal analysis, B.X.; Investigation, Y.Z. and Y.Q.; Data curation, Y.Z.; Writing--original draft, Y.Z.; Writing--review & editing, Y.Q. and B.X.; Visualization, Y.Z. and B.X.; Supervision, Y.Q.; Project administration, Y.Q.; Funding acquisition, Y.Q. All authors have read and agreed to the published version of the manuscript.  
This research was supported by the \"Natural Science Key Project of the Scientific Research Program of the Tianjin Municipal Education Commission under Grant 2022 ZD026 and 2022 ZD032\"; in part by the \"Tianjin Key Research and Development Program Projects under Grant 23 YFYSHZ00280\", led by the corresponding author, [PERSON].  
Not applicable.  
The data presented in this study are available on request from the corresponding author.  
The authors would like to thank the reviewers for their constructive comments on the paper.  
The remaining authors declare that the research was conducted in the absence of any commercial or financial relationships that could be construed as a potential conflict of interest.