dataesr/scientific-paragraphs-categorization huggingface dataset:
Introduction The most common architecture in industrial systems is a system where a supervisor component is connected to a set of slave devices, which can be either sensors or actuators. Sensors typically produce periodic or sporadic data (in the case of alarms) while actuators consume commands. Sensors can also receive data and commands (typically software/firmware updates, configuration or state changes), while actuators can also produce data (generally current state, possibly on the form of a heartbeat). In traditional Industrial Control Systems such as SCADA systems, none of these components is connected to open networks, and most of them rely on field buses, using wired communications and proprietary protocols (e. g. PROFINET, EtherCAT). As supply chain externalization and subcontracting become more and more common, and while industrial empires tend to divide in different legal entities, there is an increasing need for industrial systems interoperability  [1].
These topics are wellstudied from the safety viewpoint by SCADA systems, and embedded solutions have been proposed  [7]. If applicable on OT sensor data, business-specific edge computing may also be performed, i. e. computing of a local state of the gateway that will be send instead of (or in addition to) the raw data received from the OT sensors. However, this approach implies that compromising the gateway gives access to the whole subnetwork. In this case, it is possible to forge messages on behalf of the compromised gateway. Since the final receiver may be a critical system, such attacks potentially lead to catastrophic results, including crippling vital infrastructure, long term severe environmental damages and loss of human lives. In order to ensure security of the industrial system, we present in this document a hardware-based approach to secure the gateway communications, and give in Section 7.
OPC UA and OPC UA PubSub OPC UA is a standard  [10]  for data exchange in industrial communications. It provides safe and secure means to connect supervision systems (SCADA) with programmable logic controller (PLC), actuators, and sensors. Using OPC UA offers many advantages such as: • its interoperability ensured by an independent compliance laboratory, • its independence from hardware and platforms, • its high level of assessed security  [11, 12] , • its enhanced modeling capabilities, • its management by a foundation (OPC Foundation) of over 800 members, ensuring the development and dissemination of the technology. The OPC UA standard contains two different flavors: • connected communications with the classic client-server protocol, • publish-subscribe communications with the OPC UA PubSub protocol (with or without broker).
In the client-server approach, servers hold the data in an address space, and clients connects to them to fetch or write data to the servers. Among client-server services, one finds the address space discovery (browse), remote procedure call (method call), object oriented data management,. In a network topology where numerous (typically several hundreds) captors and actuators need to communicate with supervisors, a classical client-server approach requires a dense connection mesh to gather and distribute information. In this perspective, the PubSub mechanism is interesting because the supervisors only need to send one message to communicate information to all the remote devices. The Part 14 of OPC UA standard revision 1. 04 details the PubSub flavor of the OPC UA protocol. OPC UA PubSub is structured in two layers: the Transport layer and the Message layer.
This layered architecture ensures that OPC UA PubSub is not tied to a specific communication protocol which can be obsolete as technology evolves. This have been the case in the past with OPC DA which is based on the Microsoft COM/DCOM technology. OPC UA's transport layer has no relation with homonymous OSI transport layer. It covers communication protocols ranging from OSI layer 2 (data link) to layer 7 (application). In the case of OPC UA PubSub, it supports a set of well-established communication protocols in order to convey its payload between two clients: • Raw Ethernet, • Multicast UDP, • AMQP (Advanced Message Queuing Protocol), • MQTT (Message Queue Telemetry Transport), The first two protocols are dedicated to ''Controller to Controller'' communications, and do not require a broker (the network switches act as lightweight brokers by broadcasting messages).
OPC UA PubSub end-to-end encryption Message content can be encoded either in text (JSON) or binary (UADP), the latter being the only one to provide end-to-end encryption. Messages are composed of headers and a payload. When using encryption, only the payload, which bears data values, is encrypted. The whole Message is then signed and the signature is appended at the end of the message. In this way, regardless of the Transport layer, end-to-end encryption is achieved. OPC UA PubSub supports three security modes: encryption and signature, signature only, or none of them. There are multiple levels of encryption which are called security policies. They describe which algorithms are used, with which key lengths, signature scheme,. New security policies are regularly added by the OPC Foundation to keep up with the most current technologies.
The communication protocol is OPC UA PubSub with end-to-end encryption enabled. The MQTT protocol is used to transport the encrypted OPC UA PubSub messages, as it is more convenient to use a TCP broker to connect to remote devices. The gateway of the private subnetwork is then represented by two entry points: the MQTT broker and the SKS server used to distribute the group keys. The S2OPC library is used to build the SKS server, but also for the devices using the OPC UA PubSub protocol and the OPC UA clientserver protocol (connections between PubSub devices and the SKS server). The Paho 2  library is used by S2OPC as the library for the MQTT Transport of the OPC UA PubSub messages. The broker is an off-theshelf Mosquitto  3  broker. An OPC UA server is also added to the PubSub modules to expose the published data in a client-server manner.
On the software side, we used the S2OPC OPC UA client-server and PubSub libraries. The S2OPC library has been adapted to communicate with the TPM  [26]  through the TPM library from the Linux TPM2 & TSS2 Software community  [27]. All software used in this experiment is open-source, with the exception of tpm2-lib, a proprietary library developed by Thales and used as high-level API above TSS2. The proof of concept shows that it is possible to realize such a secure infrastructure with a Raspberry Pi 4 and the STPM4RasPI. It is relatively easy to provision the TPM, extract its public key, and have it signed by the certificate authority. Once this configuration is done, the remote device connects securely to the SKS server and fetches the group keys. The group keys are used to sign/encrypt the PubSub messages.
As shown in Fig. 6   Using these software and hardware components, we were able to implement a prototype of secure gateway for IIoT systems. More specifically, we ensured hardware-based authentication of the gateway, and then end-to-end signature and encryption for communications, as intended. Some very basic level of edge computing was also performed in the gateway, such as computing relative heating and timestamping the data. In more realistic use cases, more extensive computation should be performed at edge (i. e. in the gateway). Successful connection, persistent connectivity and effective signature and encryption were demonstrated through the use of forged messages and rogue gateways, which were both rejected by the SKS and unable to log in and access any secret or data from the system.
Residual risk and remediation: Modifying the OPC UA PubSub standard and providing individual signature key -while encryption key would stay group-based. This, however, would raise many issues in the key distribution process, especially if there is more than on publisher. Protections and Counter-measures: group messages are encrypted with group keys, using AES256 encryption, which is the state-of-the-art symmetric cryptographic standard, making it impossible to read data for an attacker. Protections and Counter-measures: while transmitted to the clients, group keys are encrypted with a temporary session keys, using AES256 encryption, which is the state-of-the-art symmetric cryptographic standard, thus making it impossible to read data for an attacker. Protections and Counter-measures: session keys are computed on both side using resident secret keys, and data transmitted through the network do not allow re-computing them for a listening third-party.
Regarding communication protocols of industrial use cases, Data Distributed Services  [44]  (DDS) is an open standard for real-time distributed communications. While the standard is open regarding the actual communications implementation, it supports a brokerless publish/subscribe pattern of communications, and so can be compared to OPC UA which offers such possibility in its PubSub version. DDS is a rich standard offering fine-grain control of the Quality of Service. A security standard has been published, allowing security patterns similar to OPC UA PubSub  [45]. Either base or security DDS specifications, however, only describe APIs when OPC UA provides in-depth protocol specifications, hence drastically increasing the tools inter-operability. Furthermore, in our knowledge no national cybersecurity authority has performed a thorough review of DDS Security, as it was the case for OPC UA by the German BSI  [46].
Conclusion We propose in this paper a consolidation of the authentication of devices that are part of a distributed system, with both legacy devices that cannot be updated because of safety requirements, and remote devices that must use the public network and require end-to-end encryption. The proposed solution uses open protocols to communicate its data (MQTT, OPC UA PubSub), enhancing the interoperability of the system, hence its maintainability. It also uses a TPM hardware module to conceal secret identifiers and guarantee the authenticity of the remote modules. The developed prototype shows that the remote data distribution works efficiently and securely. Functional tests included in the S2OPC suite all passed successfully, and operational communications were working as intended. Key distribution was performed in a relatively long time (around 10 s), probably because of the low bandwidth of the SPI bus connecting the TPM to the CPU.
Considering the timing needs of our application, such duration was acceptable. More constrained applications may require a closer integration of the TPM. On the security side, the experiment and the subsequent risk assessment described in Section 7. 3 highlight the next subjects of attention: (1) the protection of the group keys of the OPC UA PubSub security groups (threat 4. 7), and (2) protection of the clear-text nonce (threat 4. 8). The first item is under discussion within the OPC Foundation Security Working Group and an amendment can be soon added to the specification. On a final note, while performances of the remote component are proven satisfying on its industrial prototype, complete industrialization of the solution requires de-risking of the whole architecture, and more specifically further testing of the performances, since the solution's domain of application is Industrial IoT where a high number of devices provide situations similar to data lakes (this is particularly the case in the railway industry).
The COVID-19 pandemy has created a radically new situation where most countries provide raw measurements of their daily incidence and disclose them in real time. This enables new machine learning forecast strategies where the prediction might no longer be based just on the past values of the current incidence curve, but could take advantage of observations in many countries. We present such a simple global machine learning procedure using all past daily incidence trend curves. Each of the 27,418 COVID-19 incidence trend curves in our database contains the values of 56 consecutive days extracted from observed incidence curves across 61 world regions and countries. Given a current incidence trend curve observed over the past four weeks, its forecast in the next four weeks is computed by matching it with the first four weeks of all samples, and ranking them by their similarity to the query curve.
Arguably the closest method to our proposed one is the neural method of  [4]. The authors introduce a new neural forecasting model called Attention Crossing Time Series, that makes forecasts via comparing patterns across time series obtained from multiple regions. It interprets the attention mechanism  [5]  as an application of the "method of analogues". The model is demonstrated to outperform many recent SEIR models. In a nutshell, our proposed learning method uses all past incidence trend curves that are similar on 28 consecutive days to the last 28 last days of the trend incidence curve that is to be extended towards the future. To demonstrate the method, we use as learning database a collection of 27,418 COVID-19 past incidence trend curves across 61 world regions and countries. These trend curves are computed by the EpiInvert method  [6]  from the original raw incidence curves communicated by the governments.
A raw incidence curve is not the adequate input for forecasting because of its high noise and weekly oscillation. The weekly seasonality depends on each country, thus hindering comparison between raw incidence curves. Trend curves instead, being freed from seasonality and noise, are much more suitable to forecasting. Nevertheless, as we will show later, a daily forecast of the raw incidence can be deduced from its forecasted trend using the estimated seasonality. Let us denote by s = (s 1 , s 2 ,. , s 28 ), the last 28 values of the current incidence trend that we want to extrapolate, and by s f ¼ ðs f 1 ; s f 2 ; :::; s f 28 Þ the forecast for the next 28 days proposed in this work. Each of the 27,418 incidence trend curves in our database contains the values of 56 consecutive days extracted from observed past incidence curves.
We predict the evolution of the current incidence trend curve from the median of the 28 last days of the 27,418 database curves, where the median is computed on the 121 most similar curves. The similarity to the query of these candidate curves is measured on its first 28 days, which are matched to the 28 last observed days of the query curve s that we want to extrapolate. In summary, the 28 future samples s f of the current curve s are obtained as the median of the corresponding days 29 to 56 of the most similar past curves. Alternatively, we also tested a weighted average of all curves instead of the median, but it has a slightly inferior performance. We also compute empirical confidence intervals for the incidence trend forecast by applying the proposed method to the incidence curves of our database and obtaining a distribution of the forecast error as a function of the number of days passed from the current day (the last day of the used incidence curve).
In Fig  1  we illustrate the results of the proposed method for four countries, using their incidence curves up to May 5, 2022. This figure displays in black the raw input incidence curves, which show a strong weekly periodic bias. In the case of France for example, there is a strong deficit on week-ends compensated by a peak on Mondays. For our prediction, we therefore use a smooth incidence trend curve (in red), that is easier to extend and forecast than the original raw incidence. The usual way to compute an incidence trend curve is to apply a 7 or 14 days sliding average to the original raw incidence, which reduces the weekly effects  [7]. In our method, we use the more sophisticated EpiInvert method introduced in  [6, 8]  and available as a CRAN R package  [9]. This method is summarily described in the Material and Methods section.
Data sources The incidence trend database has been built using the daily incidence data, up to May 5, 2022, provided by Our World in Data in  [11]  for the following countries and regions: Argentina, Austria, Bangladesh, Belgium, Brazil, Canada, Chile, Colombia, Cuba, Czech Republic, Denmark, Germany, France, Greece, Hungary, India, Iraq, Iran, Ireland, Israel, Italy, Japan, Jordan, Kazakhstan, Malaysia, Mexico, Nepal, Netherlands, Peru, Philippines, Poland, Romania, Russia, Serbia, Slovakia, South Africa, South Korea, Spain, Sweden, Switzerland, Thailand, Tunisia, Turkey, Ukraine, United Arab Emirates, United Kingdom, USA, Vietnam, Africa, South America, North America, Asia, Europe, European Union, Oceania, and the world. 28-day forecast of the daily incidence for four countries, using the data up to May 5, 2022.
The current original raw incidence curve which suffers from periodic weekly effects. In red the current incidence trend computed by EpiInvert  [6] , in blue the forecast of the incidence trend curve by EpiLearn, in magenta the ground truth given by the incidence trend curve obtained 50 days later and in light blue the forecast of the raw incidence using Eq  (8). The cyan shaded area represents a 95% empirical confidence interval of the incidence trend forecast. The discontinuity at the past-future junction in Germany is due to a sharp drop of the incidence after the last observed day. When recalculating the incidence trend curve, the values of the past days are also changed by smoothing, thus creating the observed gap. The database provided by Our World in Data in  [11]  includes COVID-19 information about confirmed cases, deaths, vaccinations, testing and government responses.
Confirmed cases and deaths are collected by Johns Hopkins University by date of report, rather than date of test/death. Therefore, the number they report on a given day does not necessarily represent the actual number on that date, because of the long reporting chain that exists between a new case/death and its inclusion in statistics. This also means that time series can show sudden changes (negative or positive) when a country corrects historical data, because it had previously under-or -over estimated the number of cases/deaths. The comparative results with other methods, presented in the comparative results part of the Results section, have been obtained by using the raw evaluation scores published by the European Hub,  [1] , in the file https://github. com/covid19-forecast-hub-europe/covid19-forecast-hub-europe/tree/main/ evaluation/scores.
Forecasting method Next, we present the proposed method, let us, first, to introduce the following notation to manage the incidence curves and their forecast: • s o ¼ ðs o 1 ;. ; s o 28 Þ : the current raw incidence curve in the last 28 days. • s o;f ¼ ðs o;f 1 ;. ; s o;f 28 Þ : the forecast of the current raw incidence curve for the next 28 days in the future. • s = (s 1 ,. , s 28 ) : the current trend curve in the last 28 days. • s f ¼ ðs f 1 ;. ; s f 28 Þ : the forecast of the incidence trend curve for the next 28 days in the future. • fi k ¼ ði k 1 ;. ; i k 56 Þg N k¼1 : the collection of incidence trend curves in the database. • fs k ¼ ði k 1 ;. ; i k 28 Þg N k¼1 : the first 28 days of the database incidence trend curves that we use for comparison purposes with the current curve s. • fs f ;k ¼ ðs f ;k 1 ;.
; s f ;k 28 Þg N k¼1 : the forecast of the database curves for the last 28 days using as current curve the first 28 days. • E d ¼ fe d;k ¼ js f ;k d À i k dþ28 j s f ;k d g N k¼1 : empirical distribution of the relative forecast error for the database curves in the forecast day d = 1,. , 28.
Incidence trend curves database construction using EpiInvert Our proposed method, EpiLearn, uses a world-wide database of raw incidence curves from 61 countries and regions up to May 5, 2022. For each country or region, and for each day, starting 150 days after the beginning of the epidemic, we take the raw incidence data up to that day. Then, the resulting curve is further processed by applying the EpiInvert incidence decomposition algorithm  [6]  (see the Material and methods section) and we keep the last 56 values of the estimated incidence trend curve. To add a curve of this type to the database, we impose that the mean of the 56 values of the sequence must be larger than 1000. Taking into account that we normalize all database curves, the magnitude of the curves therefore has no influence in the forecast estimation.
Normalization of the database incidence curves EpiInvert is magnitude-invariant, that is, multiplying the raw incidence values by a scalar factor multiplies the estimated EpinInvert incidence trend values by the same scalar factor. Our forecast method preserves this magnitude-invariance by normalizing the magnitude of the incidence trend curves. Let N be the number of incidence trend curves stored in the database (in our case N = 27,418). For k = 1, 2, ‥, N, i k ¼ ði k 1 ; i k 2 ; :::; i k 56 Þ corresponds to the last 56 days of the incidence trend curve computed by EpiInvert and stored in the database. Each i k has been normalized by multiplying it by a scale factor so that the average of the first 28 values be equal to 1: P 28 j¼1 i k j 28 ¼ 1: ð4Þ Computing the distance between curves. We denote by ŝ the present-day incidence trend curve for the country being predicted, that has been normalized in the same way, so that ŝ ¼ 28 P 28 j¼1 s j s: ð5Þ We compare the normalized vectors ŝ and s k (the first 28 values of i k ) through the following magnitude-invariant distance average, dðŝ; s k ; mÞ ¼ P 28 j¼1 e À mð28À jÞ jŝ j À s k j j 28 ; ð6Þ where the parameter μ � 0 governs the exponentially weighted moving average.
Forecasting using a median of the closest database curves First, we select in the database the N median , the curves fs k n g n¼1;::;N median that are closest to the current one, using the similarity criterion  (6). N median is a parameter of the method. The median As EpiInvert also computes multiplicative weekly seasonality correction factors, q t , we additionally compute a forecast, s o, f , of the raw incidence curve, s o , by dividing the forecasted incidence trend curve by the corresponding seasonality factors, s o;f d ¼ s f d q 22þd%7 for d ¼ 1; ::; 28: ð8Þ where % is the modulus operator. By using q 22+d%7 as future seasonality factors we are simply making a 7-periodic extrapolation of the last seasonality factors estimated by EpiInvert. For four countries, it shows the current incidence trend by EpinInvert, its 5 closest curves in the database for their first four weeks, and the forecast, computed as the median of the 121 closest curves in their last four weeks.
Choice of the method parameters We have to choose the parameters of the method, N median and μ. For each curve i k ¼ ði k 1 ;. ; i k 56 Þ in the database, we use as current incidence curve the first 28 days of i k , that is, are the N median closest curves, in the database, using the distance (6), to s k (removing from the choice a neighborhood of k in the database). For each forecast day d = 1, ‥, 28, the relative forecast error is given by s k ¼ ði k 1 ;. ; i k 28 Þ. e d;k ¼ js f ;k d À i k dþ28 j s f ;k d : ð10Þ We define the method's median forecast error by By minimizing this median error, we obtained the optimal values N median = 121 and μ = 0. 0475. We optimized the parameters N median and μ using the first 14 forecast days because the expected error in the next 14 days is so large that we prefer to focus on the optimization for the first 14 days.