dataesr/scientific-paragraphs-categorization huggingface dataset:
Acknowledgements This article is based on work from  COST Action FP1304 PROFOUND (Towards Robust Projections  of  European Forests under Climate Change ), supported by  COST (European Cooperation in Science and Technology). AH acknowledges funding through the  ANR  " ALIEN" project  ( ANR-14-CE36-0001-01 ). GP acknowledges funding by the  Swiss National Science Foundation  ( SNF 163250 ). PM acknowledges that half of the computational work for the LANDIS-II model was executed on the IT resources of the ReCaS-Bari data center, which were made available by two projects financed by the  MIUR (Italian Ministry for Education, University and Research)  in the " PON Ricerca e Competitività 2007-2013 ′′ Program: ReCaS (Azione I -Interventi di rafforzamento strutturale ,  PONa3_00052 , Avviso 254/Ric) and  PRISMA (Asse II -Sostegno all 'innovazione, PON04a2_A).
In a third part, to show that our approach also includes the zenith case, we make a comparison between the modeled SWDs in the zenith direction with wind velocities from a ground weather station and radiosonde soundings (RSs). The three main conclusions from our data case are: first, the SWDs are correlated in time by about four days, and in space, with an angular correlation distance of about 20 • , both for the dry and wet seasons; second, the postfit residuals are almost uncorrelated with the SWDs from a temporal and spatial point of view, but with a diurnal component; third, there is a weak correlation between the SWDs and wind velocity, the pattern depends on the season. Index Terms-Global positioning system (GPS), precipitable water (PW), slant wet delays (SWDs), spherical harmonics, trigonometric functions, wind velocity, zenith wet delays (ZWDs).
They were improved year after year, culminating in the family of Vienna-mapping functions  [9]. They exist for both zenith total delay (ZTD) and ZWD in a similar fashion. They map the propagation delay along the bended ray to the vertical direction, as seen from the radio wave receiver. They are based on the assumption of a horizontally layered atmosphere. Nevertheless, small variations with respect to the layering exist. First, the layering itself can change as a function of the local values of the temperature This work is licensed under a Creative Commons Attribution 4. 0 License. For more information, see https://creativecommons. org/licenses/by/4. 0/ and pressure fields. Some mapping functions take this into account by introducing the surface temperature and pressure of a discretized atmosphere from worldwide databases.
A straightforward extension should have been to introduce sine and cosine of multiple of the azimuth, as it is done for spherical harmonics. The answer is certainly that the data acquired at this time, both in coverage and accuracy, were insufficient to determine these additional terms. However, we are now 27 years later, with highly precise GNSS orbits, additional constellations of GNSS satellites, and certainly, in the near future, low-Earth orbit GNSS augmented constellations, and this answer is now obsolete. At the moment, almost all the current GNSS software, that were written with positioning in mind, are outputting, integrated vertical values, like ZTD, ZWD, and gradients, all of them considered as constants for a given time resolution (typically from hourly values to 5-min interval).
In a second part, we will give the mathematical description of our new tool that permits to derive time and space correlations of the water vapor fields as seen from one GPS receiver. In a third part, we will study the correlation to our reconstructed SWDs along the zenith direction (quasi-ZWDs), to illustrate the fact that our algorithm is a generalization of the usual way to monitor ZWD/PW values, and so can handle integrated zenith quantities as a special case. We will illustrate all the computations with the practical example of GPS data acquired from the International GNSS Service (IGS) THTI station over the wet and dry seasons at the Geodesy Observatory of Tahiti (OGT).
The wet delay, due to the dipole component of the water vapor, is linked to the partial pressure of the water vapor or equivalently the relative humidity  [25]. In the zenith direction, it is named ZTD, and can be divided into two components: the zenith hydrostatic delay (ZHD) and the ZWD (nonhydrostatic)  [26]. In this article, we used the Bernese Software Version 5. 2  [28]  based on the precise point positioning (PPP) approach for the tropical permanent GPS station THTI (Fig. 1 , IGS reference name) located in the Central Southern Pacific Ocean  [5]  to derive the GPS ZTDs during four months in the wet season from November 5, 2017 to March 8, 2018 and four months in the dry season from May 13 to September 15, 2018. Details about our GPS data processing are summarized in Table  I. To validate the quality of our GPS results, we compared our GPS ZTDs with IGS final troposphere products downloaded from the crustal dynamics data information system (CDDIS) archive of GNSS product troposphere files generated by the Jet Propulsion Laboratory (JPL) based on the PPP approach and providing a 5-min resolution (see Table  I )  [29].
A. Data Processing The ZHDs can be accurately calculated using the Saastamoinen model (  1 ) with an accuracy of 1-2 mm  [30]. Then, the ZWDs can be obtained by subtracting ZHDs from ZTDs, as shown in (  2 ) ZHD = 2. 2768P s / f (λ, H ) (1) ZWD = ZTD -ZHD (2) where f (λ, H ) = 1-0. 00266•cos(2λ)-0. 00028• H , λ(rad) is the station latitude, H (km) is the geoid height in kilometers, and P s (hPa) is the surface pressure. For the meteorological parameters, we used the data from a rain gauge station which is colocated with the GPS station THTI. The recorded data with 1-min sampling include temperature, relative humidity, pressure, rainfall accumulation, and rainfall intensity  [31]. The SWDs, highly variable in space and time, are usually modeled as the ZWDs multiplied by a wet-mapping function m f wet (ε) that accounts for the dependence on the elevation, plus horizontal gradients to consider the azimuthal variability of the atmosphere.
B. Variation of the North and East Horizontal Gradients In this section, we analyzed the impact of the horizontal gradients on our SWD estimates, which describe the azimuthdependent part of the neutral atmosphere  [43]. The horizontal gradients were estimated during our GPS data processing with the same time interval of 5 min as the ZTD estimates. Fig. 3  shows the variations of the north and east horizontal gradients in the wet season [Fig. 3(a) ] and in the dry season [Fig. 3(b) ]. Table  III  summarizes the statistics of the horizontal gradients. It can be noticed that the time variations of the north and east gradients are relatively stable with respect to time, with a mean of about 0. 30 mm and an rms of about 1. 4 mm. They are not correlated with the geometry of the line-of-sights of the satellites  [44].
B. Correlation Between SE and Wind Velocity In this section, we investigated the impact of the wind velocity on the SE values. Two kinds of wind data sets were considered: the first one is the local "ground" wind data with an hourly resolution retrieved from the National Oceanic and Atmospheric Administration (NOAA) (ftp. ncdc. noaa. gov), collected on a 10-m mast located at the weather station (TAHITI-Faa'a, about 3 km from our GPS THTI station), the second wind data set is from radio soundings (1000 and 2500 m) with twice a day launches (00:00 UTC and 12:00 UTC), from the same weather station. Wind flow over the Island of Tahiti is stirred by two main anticyclones. The one is a steady tropical anticyclone centered on the Easter Island (110 • W, 28 • S), which creates strong and warm trade winds in the east/north-east direction on Tahiti (sometimes in the south-east direction, especially during austral winter).
In both seasons, correlation is positive between SE and the 1000-m wind speed. In the wet season, wetter trade winds drag moist air parcels. As the advection of water vapor increases, the SE values also increases. In the dry season, the drier trade winds allow more evaporation around Tahiti, which contributes to a rise of SE values. These assumptions need to be further investigated through the use of microscale meteorological simulations. Is the approach developed in this article directly implementable in GNSS software, as a replacement of the mapping functions complemented by gradients? The response is a careful yes. Strictly speaking, a mapping function defines, from the point of view of differential geometry, a coordinate chart that is a nonorthogonal system of coordinates made of the refracted elevation, the length along the bended ray, and the azimuth.
Besides, this coordinate chart may evolve with time as a complex function of weather parameters (for example, the VMF1 mapping function). In such a complex, evolving system of coordinates, defining second-order quantities like structure/covariance functions is almost impossible, as these functions will mix the propagation medium properties with the underlying geometry of the coordinate chart. It is the opinion of the authors that such an implementation in GNSS software implies at least the use of a constant (i. e. , not evolving with time) system of coordinates (i. e. , a constant mapping function), that therefore must be computed with respect to some standard model of the atmosphere, carefully designed and normalized. The approach developed in this article can be seen as an intermediate step.
ACKNOWLEDGMENT The authors would like to thank the  Center for Orbit Determination in Europe (CODE)  for providing access to the GPS database, the  European Center for Medium-Range Weather Forecasts (ECMWF)  for giving access to the VMF1 data files, the  National Oceanic and Atmospheric Administration (NOAA)  for providing the surface temperature and the dew point temperature, and the final  International GNSS Service (IGS) Crustal Dynamics Data Information System (CDDIS)  for giving ZTD products. They also thank  Météo-France  for providing all the data relative to their weather station located at the  International Airport of Tahiti.
IoT devices often operate unsupervised in ever-changing environments for several years. Therefore, they need to be updated on a regular basis. Current approaches for software updates on IoT, like the recent SUIT proposal, focus on granting integrity and confidentiality but do not analyze the content of the software update, especially the IoT application which is deployed to IoT devices. To this aim, in this paper, we present IoTAV, an automated software analysis framework for systematically verifying the security of the applications contained in software updates w. r. t. a given security policy. Our proposal can be adopted transparently by current IoT software updates workflows. We prove the viability of IoTAV by testing our methodology on a set of actual RIOT OS applications. Experimental results indicate that the approach is viable in terms of both reliability and performance, leading to the identification of 26 security policy violations in 31 real-world RIOT applications.
Securing the IoT software update process is key to the security of the IoT. To this end, the IoT ecosystem must be provided with the means to ensure the integrity of the software updates, i. e. , that the updated software has not been tampered with by a malicious agent. The IETF IoT group is addressing the problem through the development of a new standard, Software Updates for Internet of Things (SUIT)  [19] , for the software update process of IoT devices. In SUIT, an IoT Software Maintainer (ISM) creates an update bundle, i. e. , the firmware image (composed of an operating system and an application) holding the core logic of the IoT device. Then, the ISM uploads the updates to a distribution server, the Update Server (US), that dispatches the update to the devices using over-the-air (OTA) or wire technologies.
g. , the network operator or the IoT device manufacturer. IoTAV can be applied to both new and previously deployed devices. Moreover, it does not require the source code and, therefore, can be applied to third party applications whose source code is not available. As we will see later (cf. Sect. 3. 5) it is almost independent of the hardware that will host and run the application. Finally, the framework complements and leverages current firmware updates workflows, including the new SUIT solution. To demonstrate the effectiveness of the proposed solution, we developed a prototype implementation of IoTAV for the SUIT update process in the RIOT ecosystem  [24]. Finally, we validated the prototype against a set of 31 real-world RIOT applications, thereby identifying 26 security policy violations.
Paper organization. The rest of the paper is structured as follows. Section 2 introduces the major concepts of the IoT software update process and then details the SUIT standard, along with its security limitations. Section 3 describes our novel IoT Application Verification Framework for the automatic analysis of the applications contained in the IoT updates. Furthermore, it provides the specifications of a prototype implementation for the RIOT ecosystem. Section 4 discusses an assessment of IoTAV against real-world RIOT applications and presents the collected results along with a discussion on the current limitations of the approach. Section 5 analyzes the state-of-the-art proposals for securing IoT software updates and for analyzing IoT apps, thereby underlying the differences w. r. t. our approach.
Software Updates for IoT Devices The IoT software update process is an essential operation for maintaining a suitable level of efficiency and security of IoT devices. Over the last few years, the research community has been working on the definition of several IoT update processes  [20] , among which the software update for resource-constrained devices is still an open research challenge  [1]. Resource-constrained devices, as specified in RFC 7228  [7] , use microcontrollers (like the Arm Cortex-M) on which they run a real-time operating system such as Contiki, FreeRTOS or RIOT  [14] , just to cite a few. To this aim, several firmware update solutions have been proposed in the last years, like FOSE  [11] , The Update Framework (TUF) 3  , and Uptane  [21]. However, most of the proposed mechanisms are tied to specific operating systems or hardware architectures, and thus, they are not general-purpose.
1. The typical firmware update procedure works as follows: an IoT software Maintainer compiles the OS and the IoT app and generates a new firmware image. In the SUIT specification, firmware images comprise a manifest file that embeds information such as the location of the firmware image for delivery, Fig. 1. A SUIT update scenario (inspired by  [29] ) where a developer is able to introduce a malicious app in the update pipeline. dependencies, cryptographic information, and device data. Both the firmware and the manifest are then published onto the IoT Firmware Update Server, which is responsible for storing the update and notifying the IoT devices about the availability of a new update. On the device side, the firmware update is handled by a firmware update module named Firmware Consumer, which retrieves both the manifest and the firmware image.
Upon receiving a notification from the IoT Firmware Update Server, the Firmware Consumer retrieves the manifest, checks the digital signature and the firmware sequence number to ensure the integrity and the freshness of the update image. If the verification succeeds, the IoT device pulls the firmware from the URI provided in the SUIT manifest, and stores the firmware image on the flash memory. The flash memory is divided into several memory regions (slots) containing (i) the bootloader and (ii) two slots, one containing the current firmware and the other is reserved for the update firmware. After the writing process, the bootloader reads the metadata from the firmware slots and chooses to boot the newest valid firmware. Using such an approach, an interruption in the update process (e. g. , due to power loss) cannot cause the system to boot an invalid, corrupted or incompletely received image  [29].
Furthermore, SUIT allows the ISM to transfer its authority to another entity, e. g. , a third-party developer, that can deliver to the ISM some components of a software update (e. g. , the executable of the application to be updated) or triggers the update process directly. In this case, the ISM has no mechanism to assess the content of the external software components, and must fully trust the external entity. For instance, consider the scenario depicted in Fig. 1. The ISM delegates two external developers (i. e. , A and B) for updating the OS and the IoT application, respectively. Let us assume that developer A is honest (i. e. , she dispatches a benign and reliable OS image), while developer B is malicious (i. e. , she introduces a malware IoT application). According to the SUIT workflow, the ISM blindly composes the firmware image and dispatches the update to the Firmware Server.
Application Extraction and Modeling The first step of the IoT app verification process is the model generation. To do that, IoTAV parses the firmware image and identifies the part of the executable related to the application logic. After that, the Application Modeling lifts the application machine code to a higher-level language, usually an Intermediate Representation (IR), by relying on a disassembler. From the IR, the service can then deduce the structure of the application program. The IoT Application Verification Framework builds a complete application model through a fruitful combination of Control Flow Graphs (CFGs), Call Graphs (CGs), and Interprocedural Control Flow Graphs (ICFGs). A CFG is a directed graph made by nodes representing basic blocks, e. g. , pieces of branch-less code, chained through edges to represent the control flow transfer.
Although CFGs are widely used to model all the possible execution paths of a function call  [28] , they are able to represent the control-flow of a single procedure only. To overcome such limitation, IoTAV model generation procedure combines the CFGs of each procedure with the calling relationship between them, through CGs, thereby obtaining the ICFG of the whole application. Algorithm 1 shows the pseudo-code of the ICFG construction algorithm. Each call site node is a root node of its own (local procedure) CFG. It is referenced in other computed CFGs since its procedure is called by the other ones. As a consequence, the app_icf g contains a list of the CFGs rooted at the start_node and at each callee_node, each related to another one by reference. Hence, by constructing the ICFG from an executable, IoTAV gets the structure of the entire application.
IoTAV Implementation In order to evaluate the feasibility and effectiveness of the IoT Application Verification Framework, we developed a prototype implementation of IoTAV as a server appliance compatible with the SUIT update process for a RIOT ecosystem. It is worth noticing that, although the IoT Application Verification Framework is compatible with a generic SUIT update process, the focus of this prototype is the compliance with the current RIOT implementation. SUIT in the RIOT Ecosystem. RIOT  [5]  is an open-source OS, based on a modular architecture built around a soft real-time micro-kernel. RIOT is structured in software modules that are aggregated at compile-time, around a kernel providing core functionality like process scheduling, inter-process communication, and threading. This approach allows building the complete system in a modular manner, including only modules that are required by the application at stake.
One of these modules is the application module, which contains the IoT application. RIOT implements the SUIT update described in Section 2. The RIOT update firmware is a bundle that contains both the OS and the IoT application in a single Executable and Link Format (ELF) file. The IoT Software Maintainer can (i) build the update, (ii) generate the corresponding manifest file, and (iii) push them to the IoT Firmware Update Server, by using a suit/publish command 5. On the device side, after the board boots the new firmware, RIOT starts two threads: the idle thread and the main thread. The main thread is the first thread that runs and calls the main function. This function needs to be defined by the user application. Application Modeling. Concerning static code analysis, the angr framework 6  is one of the most popular frameworks used in top-ranked teams of the DARPA Cyber Grand Challenge.
It is a python-based binary analysis framework that currently supports the most common architectures, including x86, ARM, MIPS, and AMD, and it allows to retrieve the CFG of a program from its executable. IoTAV uses this tool to extract the CFG of each program procedure and to compute the overall ICFG. Since the entry point of the user application is the main function, the IoTAV computes the ICFG from there, which lets the analysis focus only on the application. For this, angr can be configured to begin the ICFG recovery directly from the main symbol in the program. Policy Specification and Model Checking. PRISM (Probabilistic Symbolic Model Checker)  [22]  is one of the many existing model checkers. It is free, opensource, and it analyzes complex systems according to probabilistic behaviors.
Experimental Results Table  1  summarizes the analysis results on the entire dataset. For each of the analyzed applications, we provide general details (name and Size of the executable), the execution times (Modeling time, Verification time, and Total time), and the results of the verification on the three policies. Since our analysis unveiled some vulnerabilities in the RIOT applications, we reported our findings to the RIOT Development Team. The outcome of IoTAV verification process showed that the node_mqtt_-bmx280 application (belonging to the demo dashboard use case) does not comply with the mqtt_enc property, thereby indicating that the MQTT communication is unencrypted, and thus, the data are transmitted insecurely through the network. Since the source code of the application is available on Github 11  , we both inspected the source code and tested the application to validate our findings.
The manual analysis confirmed that data are published to an MQTT broker unencrypted. Besides, we were able to execute the node on the evaluation board. We successfully intercepted the plaintext data traffic sent by the application through the tcpdump tool. Also, the emcute_mqttsn application failed the mqtt_enc property as well. Furthermore, IoTAV discovered that lua_basic and lua_repl applications do not comply with the st_enc policy, since they include some file storage operations without the adoption of any encryption support in place. Finally, the experimental results show that the 71% of the dataset (22 out of 31) violate the uns_c, and thus adopting insecure or deprecated C primitives. Notes on Performance. IoTAV successfully evaluated the applications of the dataset with a mean processing time of 191.
On this topic, some proposals for static and dynamic analysis of IoT applications have been already put forward. Soteria  [8]  and IotSan  [23]  are static analysis systems that automatically extract a model of an IoT application and use a model checker to validate application-specific properties. However, they require the source code of the application. On the dynamic side, IoTGuard  [9]  is a policy-based enforcement system that monitors the execution of IoT applications. IoTGuard requires to instrument the source code to collect application data at runtime and build up a dynamic model that represents the runtime behavior of the application. The limitation of this approach is its invasiveness as well as the need to modify the business logic of the application. Previous solutions focus only on a single application, while SIoT  [27]  is the first tool that analyzes distributed IoT applications to detect buffer overflow attacks.