dataesr/scientific-paragraphs-categorization huggingface dataset:
Development data Participants were provided with three datasets containing SCADA readings for 43 system variables, i. e. , tank water levels (7 variables, denoted as L_<tank id>), inlet and outlet pressure for one actuated valve and all pumping stations (12 variables, denoted as P_<junction id>), as well as their flow and status (24 variables, denoted as F_<actuator id> and S_<actuator id>, respectively). All variables are continuous, with the exception of the status of valve and pumps, represented by binary variables. The datasets were generated via simulation with epanetCPA, a Matlab toolbox that allows to design a variety of cyber attacks and simulate, with EPANET2 (version 2. 0. 12), the hydraulic response of a water distribution network  (Taormina et al. 2017 ). The toolbox is available at https://github.
com/rtaormina/epanetCPA. The hydraulic time step was set to 15 minutes, while the SCADA data reported to the participants were sampled with fixed hourly intervals. The first two datasets, hereafter named Training dataset 1 and Training dataset 2, were provided at the beginning of the competition, while the third one (Test dataset) was subsequently used to evaluate and rank the attack detection algorithms. • Training dataset 1 was generated with a simulation horizon of 365 days. A key aspect of the dataset is the absence of cyber attacks, which made it suitable for studying the operations of the water distribution system under normal operating conditions. • Training dataset 2 contains seven attacks, spanning over 492 hourly time steps. One attack was entirely revealed to the participants (by appropriately labelling the corresponding time steps), while the remaining attacks were either partially revealed or hidden; see Table  2  for additional details.
This corresponds to a post-attack scenario, in which forensics experts carry out an investigation to determine whether, when, and where the water distribution system has been affected. • Test dataset contains seven additional attacks, spanning over 407 hourly time steps (see Table  3 ). Naturally, no information regarding the attacks was revealed. Participants were required to run the detection algorithms on the Test dataset and to submit a detection report containing the following information: number of attacks detected, start and end time of each attack (in DD-MM-YYYY hh format), and the label of the attacked device(s) (optional). The operations of the water system were altered through malicious activation of hydraulic actuators, change of actuator settings, and deception attacks-amongst the most common for cyber-physical systems  (Cardenas et al.
2016 ). The replay attacks featured in the BATADAL consisted in replacing data for a given hour of the day with those recorded during the same hour one or two days before. Figure  2  illustrates attack #3 (Training dataset 2), where both pump operations and SCADA data are compromised. In this case, a deception attack manipulates Tank T1 water level readings sent by PLC2 to PLC1. PLC1 receives a reading equal to 0. 5 meters, which is below the low level thresholds that activate pumps PU1 and PU2 (4 and 1 meter, respectively). This results in both pumps working for the entire period of the attack, which lasts for 60 hours. Consequently, the water level in Tank T1 reaches the full tank level (6. 5 meters), with the excess water being spilled. The adversary tries to conceal the surge in T1 water level with a second deception attack that alters the signal sent by PLC2 to SCADA with a time-varying offset.
Time-to-detection The time-to-detection (T T D) is the time needed by an algorithm to disclose a threat. It is defined as the difference between the time t d at which the attack is detected and the time t 0 at which the attack started: T T D = t d -t 0. (1) The value of t d is inferred from the detection report, and it corresponds to the first time stamp flagged as 'under attack' while the attack is ongoing. The lower the value of T T D, the better the algorithm performs. If an attack is detected, we then have: 0 ≤ T T D ≤ ∆t, (2) where ∆t is the total duration of the attack. If the attack is not detected while it is ongoing (or at all), we set T T D = ∆t. To facilitate the comparison of all algorithms under different attack scenarios, the following performance score (S T T D ) was computed: S T T D = 1 - 1 n a na i T T D i ∆t i , (3) where n a is the number of attacks contained in a dataset, T T D i the time-to-detection relative to the i -th attack, and ∆t i the corresponding duration.
•  Pasha et al. (2017)  presented an algorithm consisting of three main interconnected modules working on control rules and consistency checks, pattern recognition, and hydraulic and system relationships. The first module checks the consistency of the data against the set of control rules characterizing the water system, while the second one uses statistical analysis to identify patterns for single hydraulic parameters and combination thereof. The idea is that patterns under cyber attacks may not follow the original ones. The anomalous behaviors detected by the first two modules are finally confirmed by the third one, which develops relationships for some physical quantities (e. g. , tank levels, flows) and compares their estimates against those reported by the first two modules. • Housh and Ohar (2017b) proposed a model-based approach that employs EPANET to simulate the hydraulic processes of the water distribution systems, and then uses the error between EPANET simulated values and the available SCADA readings to detect anomalous behaviors.
The approach consists of three main steps: first, available SCADA readings are used in a Mixed-Integer Linear Program to estimate the water demand in all nodes of C-Town; second, EPANET is used to generate reference values for the SCADA readings which are used to produce simulation errors when compared to actual readings; and third, a multi-level classification approach is implemented to classify the obtained simulation errors into event and normal conditions. A similar approach was successfully developed by Housh and Ohar (2017a) to detect contamination events in water distribution systems.
Algorithms performance Table  4  reports the values of the ranking, time-to-detection, and classification score (S, S T T D , and S CLF ) obtained by the competing algorithms on the test dataset. The table also reports the number of attacks detected, the values of T P R and T N R yielding the classification score, and the elements of the confusion matrix (i. e. , T P , F P , T N , and F N ). A visual comparison of S, S T T D , and S CLF is given in the scatter plot of Figure  3. (2017) detected only three attacks, leading to a score S equal to 0. 534.
In this regard, it is important to note that the BATADAL demand patterns were fairly regular and consistent across the three datasets. Similarly, the participants were given the same computational model of the C-Town network that was used to generate the SCADA data (i. e. , the input file C-Town. inp). Therefore, successful application of this approach in real-world settings might be hindered by various factors, such as the intrinsic variability of demand patterns, key uncertainties in the hydraulic model (e. g. , actual status of each component, pipe roughness, or pump performance curves), or the unavailability of a reliable system model. • Three data-driven algorithms belong to the cluster of high-performing detection mechanisms. This indicates that both model-based and data-driven approaches may be suitable for attack detection problems, although their performance would probably vary with the modelling context at hand.
• The adoption of supervised classification algorithms that learn how to classify the system state (as either safe or under attack) may not be ideal, since the number of attacks in the available data is generally limited. Supervised classification algorithms should always be combined with cross-validation schemes. • It appears that consistency checks and the analysis of control rules should lead to the identification of the simplest attacks. We note that the results described above were obtained on three specific datasets, which represent only a small portion of the entire set of cyber-attacks that could threaten a water distribution system. Hence, the generation of different attacks is likely to produce different results-a limitation observed in other battles (e. g. ,  Ostfeld et al. (2008) ).
FUTURE RESEARCH DIRECTIONS The BATADAL highlighted the following gaps that may need additional research efforts: • Robustness analysis. As mentioned above, the performance of an attack detection algorithm may depend-to a certain extent-on the data used during the calibration and validation process. To limit the impact of data when evaluating the robustness of an algorithm, it is thus advisable to generate stochastic simulation scenarios comprising varying hydraulic conditions (i. e. , water demand, initial tank levels) and multiple attack sequences. • Use of real SCADA data. A major limitation of the current research on cyber-security is the absence of detailed information on cyber attacks to water utilities (e. g. , timing, compromised devices, hydraulic response of the system). Access to such information and to the corresponding SCADA data-perhaps, in some anonymized forms-would drastically enhance our understanding on skills and limitations of detection algorithms.
Another challenge with SCADA data is that they often contain noise and measurement errors, so attack detection algorithms should be coupled with data preprocessing techniques. • Pressure deficient conditions and water quality problems. A limitation of this battle is its reliance of data generated with a demand-driven engine  (Taormina et al. 2017). The range of attacks should be thus extended to include pressure-deficient conditions, water quality problems, and adversial attempts aimed at threatening emergency responses, such as firefighting operations. In the absence of real SCADA data, simulated data could be generated by combining epanetCPA with more sophisticated hydraulic engines (e. g. ,  Sayyed et al. (2015) ) or water quality models (e. g. , EPANET-MSX,  Shang et al. (2007) ). • Sensitivity analysis.
The definition of the cut-off criteria defining outliers regulates the trade-off between T P R and T N R for most of the algorithms, so there is a need to adopt or develop sensitivity analysis tools that draw the appropriate line between normal and anomalous data  (Abokifa et al. 2017 ). This step should always precede the application of an algorithm to new datasets-or its deployment in a SCADA system. • Computational requirements and scalability to large networks. The algorithms presented in this paper were applied to a medium-sized water distribution system comprising one SCADA system and nine PLCs. Since attack detection algorithm are meant to run in real-time, it is necessary to evaluate their computational requirements as well as their scalability to larger networks. • Attack localization.
ACKNOWLEDGEMENTS Riccardo Taormina ,  Stefano Galelli , and  Nils Ole Tippenhauer  are supported by the  National Research Foundation (NRF) ,  Singapore , under its  National Cybersecurity R&D Programme  (Award No. NRF2014NCR-NCR001-40 ). Demetrios Eliades is supported by the  European Union 's  Horizon 2020 research and innovation programme  under grant agreement No. 739551  ( KIOS CoE ). Mohsen Aghashahi  and  M. Katherine Banks  are supported by  Qatar National Research Fund (QNRF)  under the grant  NPRP8-1292-2-548. B. M. Brentan ,  Enrique Campbell ,  G. Lima ,  D. Manzi ,  D. Ayala-Cabrera ,  M. Herrera ,  I. Montalvo ,  J. Izquierdo , and  E. Luvizotto Jr. are supported  CAPES  and  CNPq  founding agencies. Ahmed Abokifa ,  Kelsey Haddad ,  Cynthia Lo , and  Pratim Biswas ' work was carried out with the partial support from the  Lucy and Stanley Lopata Endowment at Washington University in St.
Introduction Since its coinage by K. Ashton in 1999  [1] , the term "Internet of Things" (IoT) has attracted a multitude of research and industrial interests. Today, the IoT paradigm embraces numerous architectures, protocols, standards, services, and applications for ubiquitous data acquisition and large-scale data analysis. A wide range of domains is impacted: housing, precision agriculture, retail, transportation, infrastructure monitoring, and personal healthcare, just to mention a few  [2]. In all these domains, autonomous devices (i. e. , "the things") are able to collect data and push them to the Internet. Authoritative sources like Gartner expect that, by 2020, around 26 billion objects will be connected to the Internet (https://www. gartner. com/newsroom/id/2636073) while, according to IDC (https://www.
Related Works 2. 1. From Green IT to Green IoT. According to the IoT paradigm, each day more devices are connected to the Internet. It follows that, in the near future, everything around us will be ultraconnected. The huge amounts of digital information produced need to be transferred from/to the devices through the Internet itself, hence generating high volumes of data traffic. Moreover, such exponential growth in data production requires the application of very advanced digital technologies able to quickly filter, process, and store the data flowing from devices to data centers (e. g. , big data, big stream, and data analytics  [11] ). Thus, both data and communications systems need to implement and adopt some power management policy to reduce their CO2 emissions and become truly environmentally sustainable.
Indeed, the consumption of energy by telecom operators, together with the cost of energy, is showing continuously growing trends  [17]. A wide portion of the research community is currently putting efforts in defining and implementing the fifth generation (5G) wireless cellular network technology, so as to support the drastic demands of user subscriptions and data bandwidths. Clearly, also in this case energy consumption represents a concern, as users' terminals are still powered by batteries. For a detailed review of the major challenges in 5G green communications, the reader is referred to  [18]. However, the assumption here is that batteries may be recharged when needed, while this is not the case for the vast majority of the billions IoT devices expected to spread out in the near future.
IoT in Africa: Challenges Any IoT deployment should tackle and solve a common set of technical challenges, such as end-to-end security, data privacy and trust, scalability, and interoperability  [2]. However, African scenarios reveal a pool of unique challenges. Especially in remote and rural areas, the main challenges are the high cost of hardware, the complexity of deployment, and the lack of technological ecosystem and background  [39]. Despite these difficulties, there are many opportunities for IoT in Africa. The following are but some of the most striking examples: monitoring of water, air, and soil quality, potable water management and optimization, warning systems for environmental threats (e. g. , drought, tsunami, flood, earthquake, wildfire), wild animal tracking devices, and deforestation control systems  [30, 40].
Dependency on Proprietary Infrastructures. Along with the worldwide IoT uptake, a large variety of IoT Clouds platforms offers an unprecedented level of diversity which contributes to limit dependency on proprietary infrastructures. Most of these dedicated IoT platforms have free account offers that, despite some limiting features, can largely satisfy the needs of most agriculture/micro and small farm/village business models. In order to take advantage of all these infrastructures, the design of an IoT versatile gateway should highly decouple the low-level gateway functionalities from the high-level data postprocessing features to maximize the customization of the data management part. Furthermore, by privileging high-level scripting languages such as Python, the customization process can be done in a few minutes, using standard REST API interfaces to IoT Clouds.
For instance, on the right-hand side of Figure  7  we show a tiny version of our gateway, based on a Raspberry Pi Zero board, coupled with a Loranga board (Loranga is a board officially supported by the WAZIUP European project and launched its own crowdfunding campaign on the Kickstarter platform. ). This gateway, being equipped with a 2G/3G modem and a LoRa radio transceiver, is particularly well-suited for deployments in remote areas. The gateway is able to handle offline scenarios or, more generally, situations in which the Internet connectivity is intermittent or not reliable: SMS can be sent if a cellular 2G dongle is attached, while data sent by IoT devices can be locally stored in a NoSQL MongoDB database. Eventually, being provided with an embedded web server, the gateway can also provide locally stored data that can be graphically displayed on users' smartphones and tablets, through a wireless LAN connection.
Ultimately, the gateway can also be used as a general purpose PC, by just connecting a keyboard and a display. All of these interactions mechanisms can be selectively enabled as needed. Customizing data management tasks can be done in few minutes, using standard tools, simple REST API interfaces  and available public Cloud platforms and services. We provide ready-to-use templates that already supports a number of publicly available IoT platform such as Node-Red, Firebase, ThingSpeak, Freeboard, GroveStream, and FIWARE as well as commonly used protocols like the MQTT. For instance, as shown in Figure  8 , the gateway can be been seen as a Node-Red node to be integrated into more complex flows developed in the Node-Red graphical programming framework.
Cloud Platform. In order to provide a whole software stack, we also developed our own Cloud platform. It essentially collects, stores, presents, and analyzes data coming from the gateways. Moreover, it allows users to code and deploy ad hoc applications, as well as to manage their own data and assets. In order to be suitable for the African market, the Cloud platform has some key design objectives: (i) Easy data processing, storing and visualization As depicted in Figure  9 (a), users interact with the Cloud platform through a web interface, namely, the dashboard. Moreover, we provide a mobile application since, as mentioned earlier, in Africa mobile phones, represent the primary means to get access to the Internet. Those two interfaces allow users to manage the IoT assets (i. e. , gateways and sensing devices).
USSD is also widely used because it allows a better interaction that SMS. Facebook is the primary social network used in Africa (http://www. internetworldstats. com/stats1. htm), with 170 million users. Another constraint is the Internet connection: the Internet link can be very intermittent. However, the vast majority of current IoT platforms are very Cloud-dependent, as the endpoint of all data sources is the Cloud. In this situation, if the Internet connection is not available, then users simply cannot access their Cloud-based applications. For this reason, we developed what we call the "Local Cloud" concept: a lightweight version of the platform is able to run locally on a single PC, or even on the IoT gateway itself. Thus, when the Internet connection is not available, the data is stored locally, until the remote connection is reestablished and the data can be uploaded to the Cloud side of the platform.
Finally, data security is a must for any IoT platform. We implemented both authentication and authorization security schemes. Before accessing the Cloud platform, the user needs to authenticate himself. For this, he needs to connect to the dashboard to create an account, as a user-name/password pair. Then, all transport packets are encrypted using the HTTPS protocol. Once logged in, the user can access a variety of resources, based on his roles and attributes. For instance, by default, he has access to the assets that he physically owns (being them gateways or sensing devices). The social media access is also configurable, so as to allow only certain users to access nonfree channels like SMS. Figure  9 (b) shows the implementation of the Cloud backend. All interactions are defined and supported by a purposely developed Application Protocol Interface (API) which defines eight endpoints, namely, (i) sensors: create, read, update and delete sensing devices; (ii) data: perform complex queries on stored data; (iii) notifications: send messages and alerts to users based on sensor values; (iv) social: send direct messages on social network channels like Twitter or Facebook; (v) users: manage users of a particular application, as well as their access rights; (vi) entities: create additional assets to be managed, such as farms, fields, etc.
; (vii) events: define complex relationships between entities (e. g. , to define a complex event processing engine, CEP); (viii) apps: host containerized applications in the Cloud platform. All those endpoints are protected using the Keycloak (http://www. keycloak. org/) open-source identity and access management technology. To manage data in a more abstract context, the platform integrated the FIWARE Orion (https:// fiware-orion. readthedocs. io/en/master/) context broker. In this way, our platform can manage both simple data (i. e. , a measurement value of 25) and more complex contexts (i. e. , measurement units, geo-referenced positions, etc. ). Data persistence is ensured by a MongoDB NoSQL DBMS, while such data is also sent to an ElasticSearch (https://www. elastic. co) instance, where it can be analyzed and visualized with powerful graphical tools, such as Kibana (https://www.
Deployment. We deployed five IoT sensor nodes in the field, marked with codes S8 to S34 in Figure  10. Each node incorporates a small set of sensors able to collect parameters such as soil moisture, ambient temperature, and relative humidity. The goal of such a deployment is to be able to capture and analyze soil and environmental data involved in the development of the crop. IoT nodes are connected to a local gateway, near the field, to which they forward gathered data. Data are captured from each node at regular intervals of two hours and sent to the gateway via LoRa communication (see Figure  11 ). Once sent to the gateway, data can be pushed to the Cloud platform using the APIs described in Section 4. The uploading process is achieved by first posting datapoints to a data broker and storing them in a flexible database following the required format.
Brian" is a popular Python-based simulator for spiking neural networks, commonly used in computational neuroscience. GeNN is a C++-based meta-compiler for accelerating spiking neural network simulations using consumer or high performance grade graphics processing units (GPUs). Here we introduce a new software package, Brian2GeNN, that connects the two systems so that users can make use of GeNN GPU acceleration when developing their models in Brian, without requiring any technical knowledge about GPUs, C++ or GeNN. The new Brian2GeNN software uses a pipeline of code generation to translate Brian scripts into C++ code that can be used as input to GeNN, and subsequently can be run on suitable NVIDIA GPU accelerators. From the user's perspective, the entire pipeline is invoked by adding two simple lines to their Brian scripts.
Since 2010 we have been developing the GPU enhanced neuronal networks (GeNN) framework  (Yavuz et al. , 2016)  that uses code generation techniques to simplify the efficient use of GPU accelerators for the simulation of spiking neuronal networks. Brian is a general purpose simulator for spiking neural networks written in Python, with the aim of simplifying the process of developing models  (Goodman and Brette, 2008, 2009). Version 2 of Brian  (Stimberg et al. , 2014)  introduced a code generation framework  (Goodman, 2010)  to allow for higher performance than was possible in pure Python. The design separates the Brian front-end (written in Python) from the back-end computational engine (multiple possibilities in.