esa-sceva/satcom-chunk-collection huggingface dataset:
## 2 Automatic Optimization System Framework
### Multi-Software Integration Framework Based on DOS Command  
The framework was designed to avoid the manual, repetitive collection of data samples, thus reducing the labor costs involved. Simultaneously, it aimed to accommodate essential software tools such as MATLAB, Python, and NX/SST. Within this framework, MATLAB incorporates the multi-objective optimization algorithm NSGA-II to iteratively update the design parameters of the MCM component heat source layouts. Python is primarily responsible for centralizing the processing of various results from MATLAB, NX/SST, and the DOS command line, among others. NX/SST focuses on conducting thermal analysis simulations of MCM component models, providing data for multi-objective optimization and result validation. These software components are interconnected through batch scripts written in Go language for the DOS command line. The DOS command line also drives and terminates the calculations and data flow of each software. The overall auto mated framework process is depicted in Figure 1, encompassing file operations, MATLAB, Python, NX/SST, and other major DOS command line modules.  
(1) DOS command 1 is a preparatory task responsible for deleting the existing MODEL.MACRO file. This file is a macro program file developed for the NX/SST software. It records the changes made to the model, and modifying variables in this file allows for adjustments to the model parameters. Deleting the existing MACRO file is done to prevent conflicts with subsequently generated MACRO files.  
(2) DOS command 2 opens the MATLAB program and executes the PARACHANGE.M file. This file is responsible for optimizing the thermal layout of MCM components. Upon completion of the DOS command 2, a new PARACHANGE.M file, based on the information from the new generation of populations, replaces the original file in the MACRO file.  
(3) DOS command 3 is used to delete the existing simulation results RESULT.XLXS file. This file stores model result data related to NX/SST software execution of MODEL.MACRO.  
Figure 1: The automation framework of DOS command integration multi-software.  
Deleting the existing XLXS file help avoid conflicts with the new XLXS file generated by the DOS command 4.  
(4) DOS command 4 opens NX/SST to execute the new MODEL_MACRO file outputted by the DOS command 2 and outputs the RESULT.XLXS file.  
(5) DOS command 5 deletes the existing population fitness FITNESS.TXT file. This file stores data about population fitness values (generated by the DOS command 6). Deleting the existing FITNESS file also prevents conflicts with the FITNESS file outputted in the next round.  
(6) DOS command 6 opens the Python program and executes the DATAPOSTPROCESS.PY file. This file reads the RESULT.XLXS file generated by the DOS command 3, processes the data within it, calculates the population's fitness values, and generates the FITNESS.TXT file.  
After detailing each DOS command line and understanding how each software is invoked, it is also necessary to introduce the specific content of the optimization module, which is also part of the optimization design in this paper.
## 5 Communication in Vehicular Networks  
Despite the significant advancements these technologies have brought to transportation, they also pose unique communication challenges. Our investigation encompasses various connection and communication methods that enable vehicles to communicate with each other and with the infrastructure. The utilization of wireless communication technologies, such as cellular networks, ad hoc networks, and satellite communications, to support the IoV and IoFV will be thoroughly analyzed. Moreover, we scrutinize the critical considerations that must be taken into account in the design and implementation of these communication systems, including security, scalability, and reliability issues.
## 1 Introduction
range in the variation of the results of all calculated scenarios to provide the mean and variance of the seismic hazard analysis results. The uncertainty in the relationship between the seismic parameters originates from the unknown ground motion attenuation relation, which is currently obtained through fitting the empirical formulae to known ground motion-related data, among which include ground motion intensity indicators (e.g., PGA and spectral acceleration [19]), earthquake magnitude, and distance (epicenter distance or hypocentral distance). This formula is known as the GMPE, and currently, GMPEs can be classified into three types [20]: functional, controlling, and predictive. Functional formulas require the determination of functional relationships among the parameters; controlling formulas can estimate the independent effects among the parameters experimentally; and predictive formulas are only used for the calculation of non-deterministic relationships among the data. All physical aspects associated with the earthquake ground motion are not known [21], and even if they are known, they cannot be expressed in the form of a simple equation; the estimated ground motion relationship is the predictive model. After a large number of scholars' studies on the GMPE, the deviation value of the GMPE in these seismic areas has been reduced year by year [22; 23], but it still cannot provide a single definite GMPE [24]. For those areas with low seismicity, the selection of a suitable GMPE for the PSHA is an even more challenging step [25; 26]. Undoubtedly, the in-depth analysis of geological formations to solve the problems caused by uncertainty is the fundamental method to improve the PSHA, but facing the problems of many influencing factors and unclear unknown formations is not conducive to the use and design in the engineering field. The effect of the focal depth on the ground motion, which is widely known, has not been systematically considered in the PSHA [27]. This neglect is also present in the GMPE. Therefore, this paper focused on using known data to predict the PGA through the non-linear fitting ability of the BPNN, while the PSHA is based on the full probability formulation considering the effect of the focal depth. The organization of this paper is as follows. Section 2 describes the selection guidelines for the California earthquake catalogue, which includes both known PGA and unknown PGA data, in detail. The BPNN-based PGA prediction method and processes have been described in Section 3, and a preliminary judgment on the accuracy of the fitting results has been made. In Section 4, the PSHA considering the depth of the seismic source has been completed, with the data having been fitted using the BPNN. In Section 5, the resulting hazard curves are compared with the seismic zoning results in ACSE 7-16 to determine the accuracy of the method proposed in this paper. At the end of this paper, the relevant conclusions and recommendations have been summarized in Section 6.
###### Abstract
On the other hand, V2I communication enables vehicles to communicate with roadside units and infrastructure, such as traffic signals, which allows for better coordination between them. The transportation system has evolved with the integration of smart and connected technologies, as shown in Figure 3, not only for vehicles, but also for the road network, which has become smarter with the deployment of intelligent traffic infrastructures and sensors. Therefore, with the rapid development of Intelligent Transportation Systems (ITS) and the increasing emphasis on sustainable mobility, connected Hybrid Electric Vehicles (HEVs) and Plug-In Hybrid Electric Vehicles (PHEVs) have emerged as crucial components in the global effort to reduce emissions, improve energy efficiency, and achieve sustainable transportation. The integration of advanced Energy Management Systems (EMS) and eco-driving strategies in connected HEV/PHEVs has the potential to address these challenges by optimizing single-vehicle and transportation system performance. The choice of this topic is motivated by the growing demand for effective solutions that can harness the benefits of connected vehicle technologies and cooperative systems to enhance the performance of HEV/PHEVs in diverse traffic conditions. The importance of this topic lies in its potential to provide valuable insights for researchers, policymakers, and practitioners, thereby guiding the development of innovative EMS and eco-driving strategies that can maximize fuel economy, reduce emissions, and improve traffic flow. This review paper aims to provide a comprehensive overview of recent advances and challenges in the development and implementation of EMS and eco-driving strategies for connected HEV/PHEVs. We will analyze the current state of research, identify critical research gaps, and propose potential directions for future studies in this field. By doing so, we hope to contribute to the ongoing efforts toward achieving more sustainable and efficient transportation systems. In order to review these two aspects comprehensively, this  
Figure 3: Schematic of ITS technology. report is organized as follows: Section 2 introduces the basic architectures of HEV/PHEV. Section 3 outlines the types of EMS as the basics of cooperative optimization approaches. Section 4 defines eco-driving in the context of cooperative optimization with EMS and systematically reviews its research methods. Section 5 summarizes the framework of newer approaches to cooperative optimization in single-vehicle and multi-vehicle scenarios for HEV/PHEVs, respectively, discussing their optimization objectives, constraints, control logic, and effectiveness in reducing energy consumption. Finally, future studies and conclusions are presented in Sections 6 and 7.
## 3 Proposed Methods
### Taillight Detection
#### 3.1.4 Taillight Verification  
After the generation phase, several outliers that are not taillights seemingly appear, as illustrated in Figure 10. Therefore in the verification phase, the taillight verification step is presented to reduce the number of outliers to the maximum possible extent. This study mainly concentrates on three types of outliers: a brake lamp, a region having a small area, and a region having a vertical coordinates (Oy-axis coordinate) too high compared to that of the traffic road.  
Figure 9: Result of the generation phase: (**a**) input image; (**b**) output image.  
We consider each candidate region \(T\). Let the width, height, and vertical coordinates of \(T\) be \(w_{T}\), \(h_{T}\), and \(y_{T}\), respectively. Denoting \(\lambda_{1}\) as a threshold to represent the maximum ratio value between the width and height of the taillight region, \(T\) is considered as the brake lamp if the following condition is satisfied:  
\[\frac{w_{T}}{h_{T}}\geq\lambda_{1}, \tag{11}\]  
When the area of \(T\) is tiny, there are two possible cases: (1) \(T\) is not a taillight but just noise from the reflected surface and (2) \(T\) is possibly a taillight but is placed too far from the camera, and thus, has a little impact on the host vehicle. In both cases, \(T\) should be eliminated. With \(\lambda_{2}\) defined as a minimum value of the taillight's area, we check whether \(T_{i}\) is too tiny, by using the following equation:  
\[w_{T}*h_{T}<\lambda_{2}, \tag{12}\]  
The final type of outlier is the region that is placed too high from the traffic road. This region is highly likely a traffic light, building light, or an advertisement panel. To check this criterion on \(T\), we compare the ratio between \(y_{T}\) and the image's height \(H\) with a certain threshold value \(\lambda_{3}\) (Equation (13)). If this ratio is smaller than \(\lambda_{3}\), \(T\) will be erased from the detection result.  
\[\frac{y_{i}}{H}<\lambda_{3}, \tag{13}\]  
Through experiments, the values of \(\lambda_{1}\), \(\lambda_{2}\), and \(\lambda_{3}\) are, respectively, set as 10, 81, and 0.8. Figure 11 presents a detection result after the taillight verification stage. Finally, the pixel coordinates and the bounding box of each detected taillight region are already determined so that they can be used in further stages.  
Figure 10: Outliers: (**a**) brake lamp; (**b**) noise; (**c**) traffic light; (**d**) advertisement panel.
## 3 Experimental Results and Discussions  
### Description of Experimental Phenomena  
The failure characteristics of RAC hollow block masonry are presented in Figure 5. It can be noticed that the specimens with a different replacement ratio of RAs have the similar failure characteristics. The failure process can be summarized as the following phases:  
Figure 4: Test setup for the compressive strength: (**a**) experimental picture; (**b**) schematic diagram.  
Figure 5: Failure modes of compressive strength: (**a**) front view; (**b**) side view.  
Phase I: Before the test piece cracks, the value of the compression machine and dial indicator increased steadily with the increase of the load, and there were no abnormal phenomena on the surface of the specimen. The end of the first stage was accompanied by the appearance of the first micro-crack. Meanwhile, the micro-crack will not extend when the load stops increasing, and the specimen remains stable at this stage.  
Phase II: The specimen from the initial crack to the limit state was regarded as the second stage. With the emergence of slight vertical cracks on the narrow side of the recycled concrete hollow masonry, the bearing capacity of the specimens began to increase tardily. The vertical or oblique crack was generated on the wide side of the specimen, accompanied by the persistent augment in load. The dial indicator increased rapidly. With the further enhancement of the load, the penetrating cracks were generated on the narrow side of the specimen, which divided the test piece into several small columns. The RAC hollow block masonry reached ultimate bearing capacity when the load did not grow persistently. The reading of the hydraulic press and dial indicator fluctuates obviously. Then the second stage terminated.  
Phase III: When the limit load was exceeded, the number of the hydraulic press was decreased fiercely, and the deformation of the specimen increased sharply. The specimen was crushed and destroyed eventually.  
It can be seen from the failure status of RAC hollow block masonry that the top face and the connection of the two ribs were weak links, where the penetration cracks will appear firstly, and the whole specimen was destroyed finally. This was mainly attributed to by the fact that there were more holes and ribs in the recycled concrete block with three rows of holes, and there were still process grooves in the end of the holes at the junction of the two ribs on the top surface, which was effortless in forming a failure surface. The compression test values of the RAC hollow block masonry are listed in Table 4.
# Research Challenges for the Internet of Things: What Role Can OR Play?
## 3 How can OR Support the Future IoT?
### The Mathematical Tools and Techniques of OR Which May Support the IoT
#### 3.1.7 Reliability Theory  
Reliability theory can describe the probability of a system achieving its expected performance. The reliability of a system is determined by considering the reliability function of each component.  
[PERSON] et al. [60] used reliability theory to evaluate the reliability of the IoT. Five reliability functions were included for perception layer, Internet, mobile network, satellite communications, and application layer. A value of 0.87 was determined for the overall IoT reliability based on their assumptions. However, this must be considered as an estimate only since the IoT is still rapidly developing and the authors may not have considered all factors.  
Reliability Theory can further be applied to other IoT requirements such as Quality of Service and even data management. How reliable is the data acquired by the IoT? [PERSON] et al. [46] note that the reliability of data from IoT sensors will depend on factors such as data loss, noise, invalid data, and data redundancy where several sensors have measured the same object. A reliability model for IoT data could be constructed from consideration of all these factors.  
We discuss in more detail how Reliability Theory can support the IoT research challenge of Robustness in Section 4.2.
## 5 Conclusions  
Under the condition of pump speed adjustment, the schemes of asynchronous and synchronous starting and regulating of the two pumps were analyzed. In addition, the pump speed adjustment was compared to the joint adjustment of pump speed and valve opening. Furthermore, a genetic algorithm-based calculation method was implemented.  
Under the low operating conditions, the speed of Scheme ASYNC was about 13,300 r/min and that of Scheme SYNC was about 12,100 r/min, close to one-third of the rated operating condition. In Scheme SYNC, since the two pumps were in the same operating state, the overall operating conditions were stable. In scheme ASYNC, there was a pressure peak from the second stage to the third stage due to the asynchronous opening of the two pumps. At the same time, the opening time of the second pump needed to be strictly controlled. Compared with the pump speed adjustment, the joint adjustment of pump speed and valve opening could mainly improve the pump speed and the pressure of the pump outlet, enabling the regulating valve to work in a significant cavitation state. In this way, the pressure drop requirements of catalytic beds, regulating valves, and injectors could be met. The joint adjustment could reduce the regulation range of the pump by a factor of one-third, as well as maintain the pump efficiency at a high level.  
In addition, the joint adjustment of pump speed and valve opening revealed multiple combinations of pump speed and valve opening that could meet the requirements. Using the genetic algorithm-based calculation method proposed in this study, together with the curves of flow rate and pressure with pump speed and valve opening, the optimal combination of parameters satisfying the engine flow demand while minimizing energy consumption could be obtained. This method is applicable to propulsion systems with different thrust levels; however, the pressure peak resulting from different schemes may vary with different levels of thrust. Moreover, the dynamic characteristics of the propulsion system when more than two electric pumps are used in parallel are not clear. These issues deserve further investigation.  
Conceptualization, C.Z. and J.W.; methodology, N.Y. and C.Z.; software, C.Z. and G.C.; formal analysis, C.Z. and N.Y.; investigation, J.W.; writing--original draft preparation, C.Z., N.Y. and J.W. All authors have read and agreed to the published version of the manuscript. This research received no external funding.  
**Acknowledgments:** The authors thank the reviewers for their great help with the article during its review progress.  
**Conflicts of Interest:** The authors declare no conflict of interest.
# Secure Internal Data Markets
## 4 A Generalised Model for Secure Internal Data Markets
### Comparison to Other Data Market Approaches
In related terms, the issue of privacy is a big topic in the area of data markets, as can also be seen in the approaches outlined above, where especially the privacy of the data provider is a typical design criterion. In [39], the authors also focus on the privacy protection measures utilised on the data itself, i.e., assuming that the traded data contain privacy-relevant information, they apply the concept of differential privacy and measure the data loss attributed to the data sets in order to (i) protect the privacy of the data subjects and (ii) find a balance between pricing and data quality. The technique is very interesting and could, of course, also be applied to certain internal markets; still, it is, again, very specific since (i) it assumes that privacy-relevant data are traded, which is not the case in many industrial environments, and (ii) that there are different partners involved in the systems, leading more to a global data market model rather than a local one. The same holds true for the slightly older PRIVATA approach [40], focusing on the balancing of data noise and pricing, which is rather specific and not relevant for many internal market concepts, where there exist a trusted authority and rules, authorizing which data could be used under what circumstances, as well as connected trading entities. Furthermore, pricing can be very different in local markets [15]; thus, we did not touch this topic in our work, as it is very use-case specific, and thus needs to be resolved on a per-market basis. In [35], the authors focus on providing a global data market solution, with much of the control being exerted by the data owner in this approach, compared to the data-sharing process. While all the related techniques discussed in this section have great merit, they are not comparable to our work, as they (i) typically have a very specific set of requirements in mind and (ii) focus on global situations where the other partners are generally unknown (and often even protected against recognition by the approach itself). Still, the major contribution of our paper lies in outlining the many differences between local and global data markets in the area of security (also, ref. [15] provides insight on the differences between these two concepts, albeit omitting the topic of security at large); thus, while these approaches are useful in selected local scenarios, we focus on providing a very general and high-level general approach as a starting point for asking the right questions in the market design phase and providing a market specifically tailored to the needs of the specific company, consortium or even application in question (see [41] for a very specific and non-standard form of the \"data market\"), instead of providing a fixed market model that the partner(s) need to adapt to.
## 3 The Proposed Scheme
### Data Transmission  
For gathering data in each round, the BS chooses the cell head with the most residual energy as the cycle leader, responsible for receiving data from its two neighboring cell heads, aggregating with its own data, and eventually transmitting the aggregated data to the BS. In each round, when the cycle leader receives the request from the BS, it will send two tokens \(t_{1}\) and \(t_{2}\) to its two neighboring cell heads, respectively. Token \(t_{1}\) will be passed recursively along the cycle clockwise to the next cell head. Conversely, token \(t_{2}\) will be passed recursively along the cycle counterclockwise to the next cell head. Both tokens travel along the cyclic chain in opposite directions. Once a cell head receives the second token from the other direction, it drops the token and cuts the cycle, making itself as one end and the sender of the second token as the other end. As a result, both end cell heads respectively transmit their own aggregated data to the cycle leader in the opposite direction.  
For example, as shown in Figure 3, when cell head \(e_{1}\) receives the second token \(t_{2}\) passed along the cycle counterclockwise, it drops \(t_{2}\) and cuts the cycle, making itself as one end and \(e2\) as the other end. Likewise, when cell head \(e_{2}\) receives the second token \(t_{1}\) passed along the cycle clockwise, it drops \(t_{1}\) and cuts the cycle, making itself as one end and \(e1\) as the other end. Accordingly, both \(e_{1}\) and \(e_{2}\) respectively transmit their own aggregated data to the cycle leader in the opposite direction.