dataesr/scientific-paragraphs-categorization huggingface dataset:
In this scenario, user-comfort is driven by luminosity and sound physical properties. A first application set (UserComfortApps) is dedicated to give sensor data access to decision making algorithms (App_Lum and App_RC_TV) that respectively control (1) the luminosity level by acting on the roller shutters and the light bulb and (2) the sound by acting on the TV remote controller and the Amazon echo smart speaker. A second application set (i. e. CommunicationCenterApps) is deployed, creating a home-working environment where the focus is put on controlling sound sources so as to prevent home workers to be disturbed during phone calls or video conferences (e. g. , App_Phone_TV mutes TV while a phone call is in progress). All applications are implemented through Node-RED flows. To illustrate the toolsets proposed within the DevOps approach, a scenario with two DevOps cycles has been defined, each cycle covering the development and the operational stages.
On the other hand, the overall speed of learning and learning performance can be increased, in particular in real-world situations where rewards are sparse. Yet, such offline pre-training again faces the uncertainty issue when formulating the source learning task to be learned in the offline setting. It is not possible due to design time uncertainty that this source learning task faithfully captures the actual online setting. To capture the problem of uncertainty, existing solutions thus make certain assumptions about the system and its uncertainty in order to be able to perform the training in the offline setting. This is also what we did above, by taking certain assumptions about the building domain and even taking real, historic data into account. However, while this may mean that the reinforcement learning enabler learns a policy that solves this specific problem (i.
Chapter 7. 2 describes how the SMOOL platform can be used in the SIS development and operation to monitor and control the desired security properties in the access to resources and communications between smart things of the SIS. Security assurance at operation does require an external service, agnostic to system design but tailored to final system deployment, that is supervising at all times the security behaviour of the different elements in the IoT system. The role of this security monitoring service is to make sure that security incidents or anomalies are early identified and corresponding alerts are raised to system operators. Chapter 7. 3 describes the ENACT enabler supporting at operations the situational awareness of SIS, the so called, Security and Privacy Monitoring Enabler. The enabler is capable of collecting data from different layers of the IoT system: network, system and application layers.
Security-by-Design in IoT Platforms Complex systems usually cover the security aspects by adding a layer intersecting or covering other business layers (user interface, data management, processes, etc. ). When dealing with IoT systems, the heterogeneous nature of sensors, communication channels, Edge devices or Cloud services often demands the architects focusing on business logic, leaving unattended the needed security controls on sensitive areas (e. g. securing the Edge devices, credentials management for key devices,…), even if some sensors may use weak encryption or even produce data in clear because they rely on transport layer encryption. Therefore, most of the security management is often handled by the developers creating dedicated solutions on the IoT platform. The platform could provide its own battle-tested security mechanisms but those may not fit well or at all with the security features required by the application developers.
The second problem is that the developer could miss some of the things to double-check when using one of the security concepts in the ontology. For instance, the need of salting before hashing encrypted payloads, or the need to authenticate the device before allowing it to publish data. The third issue is that freedom in security coding increases the list of potential security mistakes a nonexpert may make and an expert should review. In Figure  7. 2 a simplified version of KP layers is displayed. When a message containing sensor data (in SSAP format) arrives, the first layer is the Comms layer or communications stack, responsible for accepting and assembling the message by using any of the allowed connectors (TCP, Bluetooth, etc. ). The second layer is the Model layer where various operations on the message take place, such as parsing, data insertion into the ontology containers, comparison of previous and updated values, etc.
Reaction to Cyber Incidents and Anomalies Smart IoT systems allow devices and data generated to be in the core of the system behaviour, leaving human interaction as trigger elements or passive receptors of actions. In SIS most of the elements must run autonomously, re-adapt based on rules, start and stop things, etc. In fact, the SIS behave as complex ecosystems where elements can have different degrees of intelligence but all of them share a high degree of autonomy. And in these systems, a preventive control monitoring what is happening in terms of security is important, but also a reactive control when things go wrong, i. e. issues are detected. For example, hacking only one of the devices in a SIS could create dangerous situations. Imagine a hacked temperature sensor sending low values to keep a heat system running all the time.
Now, imagine a hack of a gas or smoke sensor to forge the sensed dangerous values and prevent them from being detected. Therefore, apart from monitoring and identifying potential issues and attacks, SIS security must be reactive to take countermeasures in real time. The best way to ensure control is having administration rights on the smart devices and Edge, but not all IoT elements can be controlled (for instance, generic sensors or devices from external vendors ready for plug-and-run). Thus, control must sense the IoT system and must act on it, and in cases where the device cannot be managed from the inside, the control must be done from some other part of the communication or data processing chain. Some security control systems are ready to detect general problems and react to them. Imagine a new device joins a weak security wireless network.
3. App agent, which collects data at application layer and generates security events accordingly. This agent can be customized depending on the SIS characteristics; e. g. if the SIS is in intensive use of the MQTT protocol, this agent can be developed with specific MQTT based rules for monitoring and controlling that only authorized users and assets (smart things, devices, services, etc. ) can communicate in the SIS. All the data gathered by the monitoring agents is sent to the back-end of the enabler. Depending on the size of the SIS, the amount of data recovered after some time can be huge which would likely cause processing difficulties. In order to avoid a bottleneck at next phases of data processing and analytics, the entry of the back-end is implemented by a streaming bus (based on the open source distributed streaming platform Apache Kafka  [4].
Moreover, the streaming bus provides extensibility to the solution by offering multiple channels where various kinds of data can be collected, and it also allows exchanging the outcome from the enabler in form of identified security events with external components. The back-end of the enabler includes a data storage infrastructure which stores in a NoSQL database (based on Elasticsearch  [2] ) all the acquired and pre-processed data from the agents. Multiple indexes are created in the storage infrastructure depending on the different sources of data. For example, in a Smart Building IoT system where many communication protocols can be working at the same time, the network data can easily be stored with the definition of approximately 1800 network attributes as shown in Figure  7. 8. Bearing in mind that network traffic is only one of the multiple data sources considered for the analytics within the enabler, dealing with enormous amounts of heterogeneous data is one of the major challenges addressed by this enabler in IoT environments.
Chapter 7. 2). This particular implementation allows the security administrator to continuously monitor all communications and data exchanged through the IoT Platform. Figure  7. 13 shows the architecture of the enabler integrated with SMOOL IoT Platform. The distinctive feature in this scenario is that a client of the SMOOL IoT Platform, called Security KP (cf. Chapter 7. 2. 2), works as an app agent for the enabler by monitoring all data and communications through the IoT Platform and identifying potential malicious intrusions. Furthermore, the integration with SMOOL IoT Platform provides the enabler security control capability to react to security incidents. For example, when detecting an unauthorized communication within SMOOL IoT Platform by the app agent (i. e. the Security KP), the enabler can respond by blocking all communications coming from the unauthorized client.
We have evaluated our solution with several industrial use cases, such as eHealth (Tellu), Smart Building (Tecnalia), and Intelligent Train System (Indra). The case studies have shown that it is stable and ready for production systems. The TaS provides the possibility to test the IoT system based on test scenarios using pre-prepared datasets. The datasets can be the recorded data from a real system or the data generated using some data mutation operators. The TaS also allows stressing the boundaries of the scenarios to detect potential problems. We focus on the network of sensors and the applications on top of them. Therefore, we do not consider the physical behavior of the sensors. We take it for granted that the sensors are reliable and correctly react to the physical changes (e. g. , if the physical temperature rises 2 degrees, the sensor will immediately send a message with a 2 degree higher reading).
The TaS enabler simulates sensors and actuators. The topology on the left side is very similar to the topology on the right side. The only difference is the simulated sensors and actuators. The simulated actuators collect the actuation data sent from the IoT system. The simulated sensors play the same role as the physical sensors providing the data signal to the IoT components. However, they are much more valuable than a physical sensor in terms of testing in the following ways: • Firstly, by using the dataset recorded from the physical environment, the sim- ulated sensors can repeatedly simulate the surrounding environment at a specific time. In reality, an event may happen only once, but the simulated sensor can generate the same event as many times as needed for testing purposes. • Secondly, the physical sensors passively capture the state of the surrounding environment.
It can be challenging to obtain different data from the physical sensors. In contrast, the simulated sensors use the dataset in the Data Storage as a data source. Therefore, we can generate various testing scenarios by modifying the event in the Data Storage. • Moreover, the TaS enabler also provides a module to manipulate the data from the sensors. The Regular and Malicious Data Generator can generate regular data to test the functionalities, operations, performance, and scalability. It can also generate malicious data to test the resiliency of the system to attacks. Besides the simulated sensors and actuators, the TaS enabler also provides some modules which support the testing process 8. 3. The Data Recorder module records all the messages going through the broker in the physical environment.
Each message can be considered as an event happening in the physical environment. Then, the recorded messages are forwarded to the broker in the testing environment. In this way, we have a "twin version" of the physical environment. What has happened in the physical environment is reproduced in the testing environment. Besides, the recorded messages are stored in a Data Storage as a dataset for later testing. The recorded dataset can be modified (muted) to create a new dataset, e. g. , "change the event order", "delete an event", "add a new event". All the testing datasets are stored in the Data Storage. The Regular and Malicious Data Generator enables the simulation of different sensor behaviors, from normal behavior to abnormal behavior, such as a DOS attack (the sensor publishes massive data messages in a short time), node failure (the sensor stops sending data).
The simulation of sensor The sensor provides the input data of an IoT system. The simulation of a sensor corresponds to the simulation of the data stream it provides. The simulated sensor has been designed for flexibility in the following ways: • It supports different types of data report formats: -PLAIN_DATA: the measurement value is published directly without any transformation, it can be a number, a string or an object, for example: 15 -JSON_OBJECT: the measurement value is transformed to be an object in JSON format, with the key is set by user, for example: "temp":15 -IPSO_FORMAT: the reported data follows the Internet Protocol for Smart Object (Object and Resource Registry). A temperature sensor can report the data in IPSO format as follows (Temperature Sensor in IPSO): -Dataset: The data source is from the data storage where the data has been recorded or created before simulating.
The simulation of an IoT device In an IoT system, the sensor and actuator are usually part of the same device. An IoT device can contain one to many sensors as well as one to many actuators. A list of simulated IoT devices forms the simulated network topology. Besides the list of devices, a network topology can also provide the identifier of the dataset (datasetId ),which contains the data to simulate the SIS in a given time, the global replaying options, the configuration to connect with the database, and the definition of the new dataset where the data generated from the simulations will be stored.
Data Mutation Testing Figure  8. 10 illustrates the Data Mutation Testing architecture. The Mutant Generator generates new sensor data from existing data stored in the Data Storage by applying one or many mutated functions, such as "change the event order", "change a value", and "delete an event". The mutated data are input for the simulation. The Evaluation module generates a report about the output differences when testing the system with the mutated and the original input data. The Data Mutation Testing method is for penetration, robustness, security, and scalability testing (e. g. , mutating the device identifier to obtain new devices). In the TaS enabler, we can mutate the device identity to generate many devices while testing the system scalability. There is also an interface to apply some mutation functions to a dataset manually.
The testbeds To simulate and test an IoT system in some specific scenarios, one of the easiest methods is to use a testbed. With testbeds, the developer can define exactly what is the input and what should be the corresponding output. This way, the tests can be done automatically and easily integrated in the DevOps Continuous Integration and Continuous Deployment processes. In TaS, testbeds are built from datasets which are recorded from a real system or generated by the TaS based on scenarios.
DataStorage The Data Storage contains all the datasets for testing and simulating. As depicted in Figure  8. 11, the datasets are fed into the DataStorage via three sources: the data from the real system recorded by the Data Recorder, the data generated by the Regular and Malicious Data Generator, and the data generated by the simulation. The datasets in the Data Storage are used to simulate the sensors and to validate the simulation output. The database connection of the TaS enabler is flexible. Two simulations can use different databases. If there is no configuration specified, the TaS enabler uses a default database. The database to connect to can be any database that the TaS enabler can reach.
Event An event represents a message sent through the communication channels. It can be a data message sent by a sensor or data received by an actuator. Figure  8. 12 presents the format of the event Schema. The timestamp attribute indicates the time when the event has been captured. The topic represents the MQTT/MQTTS bus channel related to the event. It is the  source channel of the event where the data message corresponds to sensor data. It is the destination channel of the event where the data message is data received by an actuator. Its value is crucial for identifying the event to be replayed. The datasetId attribute represents the dataset to which the event belongs. The isSensorData is set to True if the event presents a data message sent by a sensor. It is False if the event is a data message received by an actuator.
Dataset A dataset contains a series of events for a specific scenario. Figure  8. 13 presents the schema of a dataset. Each dataset has a unique id, name, and description to describe the dataset objective. The source attribute indicates the dataset source. A dataset can be created from a recording session by the Data Recorder (source: RECORDED) or generated by the Regular and Malicious Data Generator (source: GENERATED). A dataset can also be derived by cloning and modifying data from another dataset (source: MUTATED). By grouping the events by the dataset Id, we have all the events belonging to a dataset.
The data recorder and digital twins concept The TaS enabler provides the possibility to simulate an IoT system using historical data. To this end, a Data Recorder module is needed. Figure  8. 14 presents the data flow of the Data Recorder. All the events in the real system (coming from the broker) will be recorded. This data (including both sensor and actuator data) is stored in the Data Storage as a dataset. The sensor data can be forwarded directly to the testing system (using the forwarding broker). With the recorded data from the real system, the SIS can be tested with real input. The more data from sensors are recorded, the more test scenarios are tested. By synchronizing the Sensor simulator timestamps with the Data Recorder, it is possible to simulate a particular SIS (following the Digital Twin concept).
The regular and malicious data generator When testing the IoT system, there are many testing scenarios and cases that do not frequently occur in reality. With the real IoT system, it is almost impossible to collect the datasets for many testing scenarios. The TaS enabler provides a powerful The abnormal sensor behaviors are defined by energy, reporting time, and value constraints. Figure  8. 16 illustrates how a data value is generated based on the selected behaviours of the sensor. In the beginning, the energy constraint is checked. There are two behaviors related to energy. If the sensor is in the low-battery mode, we can reduce the reporting frequency. Notice that the user initially sets the frequency. If the sensor is out of battery, it stops sending data. In the next step, we consider the time constraint.
Test case While testing an IoT system, we may want to test different network topologies, such as adding a new device, removing a device, or just changing the way to There can be many different testing types (e. g. , functional, security, or scalability testing). A dataset defines a test. For test execution, the TaS enabler runs the simulation and testing using each dataset by following the test order in the test list. We can change the order of the datasets via the web interface.
The evaluation module The Evaluation module collects the simulated actuator data as well as the other metrics of the system. Then, it performs the evaluation based on the testing methodology (see Section 8. 2. 3. 1 for more details). The next section presents the implementation of the TaS enabler. The TaS enabler has been designed to be portable. It can be installed as a Node. js application and packaged as a docker image. Figure  8. 18 presents the communications between the modules inside a docker container and between the docker container and other modules. The REST Server provides an API to interact with the tool. Via this API, we can execute the module Data Recorder, Simulation, and Regular and Malicious Data Generator. The Database is external to the docker container and can be connected via the Data Storage module.
Smart home system In the Smart Home use case, we used the TaS enabler as part of the DevOps cycle. Figure  8. 21 shows the data flow of the TaS enabler. First, the Data Recorder records and builds the testing dataset from the real system. For each system change, such as new features, and software updates, the TaS enabler uses the recorded dataset to check the system reaction. By comparing the recorded system output with the simulated system output, we can detect miss behaviors in the updated system. Using the TaS enabler, we can automatically test the SIS in various test scenarios. However, due to the SIS complexity, a problem may happen at any moment while  the system is running. Knowing the root cause of the problem is very important to find the solution. Therefore, we need a tool to identify the root cause of the problem while running an SIS.
Therefore, the collected data can be easily labeled by actively performing different tests injecting known failures and attacks. • Passive learning: Once an incident is detected and alerted (e. g. , by a third- party tool) without knowing its origin, thanks to the aid of the system experts, manual RCA is performed by debugging different logs and correlating various events to determine the corresponding root causes. The result of this work can be stored in the database with its relevant attribute values. The historical data are derived from these two sources. The idea is to determine when the system reaches a known undesirable state with a known cause. It involves using the concept of Similarity Learning  [8] , i. e. , Ranking Similarity Learning. The RCA tool calculates the similarity of the new state with the known ones.
It presents the most similar states in the relative similarity order. The final goal is to recognize the incident's root origin by using historical data. In this way, the tool can recommend to the operator which countermeasures to perform based on known mitigation strategies. The RCA Enabler works following two phases: the knowledge acquisition phase (Figure  8. 23) and the monitoring phase (Figure  8. 24). The former is for building a historical database of known problems and incidents. The latter consists of monitoring the system in real-time, analyzing the newly-coming incident by querying the historical data, and suggesting possible root causes. It is worth noting that passive learning in the knowledge acquisition phase can be continuously run during the monitoring phase. We describe the details of each module in the following subsections.
In general, they can work on any system in which the data about the system's functioning state can be collected. For the RCA enabler, it would be beneficial if the owner or administrator has already acquired a certain level of understanding about the system to facilitate the training phase and the database creation for known incidents and root causes. Otherwise, we can perform penetration tests to discover potential vulnerabilities so that the attacks and failures can be injected and learned. Moreover, both tools have been developed to be generic enough so that adaptations can be easily made to make them applicable to various types of systems (e. g. , industrial SCADA systems, 5G mobile networks). We plan to adapt and use these two tools in several other collaborative projects in different contexts.