dataesr/scientific-paragraphs-categorization huggingface dataset:
What is striking is the imbalance between the theoretical complexity (0. 6% of total MACs) of the second fully-connected layer and the percentage of the total time taken on the MPA to implement it (14. 2% of total latency). As discussed, the latency required to perform the pre-processing for this layer exaggerates this difference even more. In stark contrast however, the MPA implementations of the second convolutional layer and the first linear layer contribute less to the total time than would be expected from the computational complexity of these layers. This disparity is in large part due to the fashion in which data can be distributed over the MPA (depicted in Fig. 2 ) to permit the maximum parallel usage of computing resources. The bar chart in Fig. 7  shows the percentage utilization of all available MPX-p and their processing elements (PEs) for each layer.
5 µs. Despite it's conceptual simplicity, relative to the convolutions, this step requires a series of different microcodes to be loaded into MPX-p across the array (loading a microcode requires around 8 µs each time). The microcode that realizes the ReLU that operates on the final feature map requires only 21. 9 µs. Considering the pre-processing step and the weight transfer as data movement steps, only 11% of this total latency is incurred due to data movement operations while the remaining 89% is due to actual functional computations using this data. In contrast to typical von Neumann based neural network implementations, our CNN implementation on RETINE succeeds in spending the majority of its time computing with data rather than transporting it. In this work, we have achieved end-to-end CNN inference with 4-bit precision weights and activations at 265 FPS.
While we have implemented an adapted version of Lenet-5, the MPA is programmable and supports a wide range of neural networks. In this implementation, we have spatially distributed the number of filters as well as the ifmaps over several macropixels in parallel. The number of parallel units for each layer is a trade-off between the memory available locally in the macropixel, and the amount of data to be transferred to perform the processing. The mechanisms used to implement this network can be adapted for more complex networks. However, this scaling will probably be limited by the data movements to feed the computational elements. Fast data transfer mechanisms will probably have to be added. In a more fine-grained breakdown of the latency incurred within in the second convolutional layer, we observed that approximately 11% of the total latency was incurred by data and weight transfer codes, while 89% of the total time was dedicated to processing once the data was in place.
Importantly, this demonstrates that by computing in-sensor, in a massively parallel fashion, permits a departure from the von Neumann rhetoric whereby the majority of the time taken to implement neural network models is consumed due to data movement between either memory or sensor and processing units. In comparing our MPA implementation to other pixel-array processor implementations, we achieved a favourable frame rate for similar sizes of model. Furthermore we are able to achieve this using a higher bit-precision for the weights and activations. The four layer version of our neural network model implementation on the MPA was able to process 265 frames per second, while for a three layer version (omitting the final fully-connected layer) this was improved to 309 frames per second. Ultimately this study has demonstrated that macropixel processor array based neural network implementations are advantageous to pixel-array processor arrays because they allow for more operations to be applied per pixel.
In order to understand the parameters influencing the distributions of the alleles among the patients, we performed two simulations experiments in silico. First, we investigated the size of the reservoir from which the alleles are retrieved. We simulated the 24 genomic repertoires by drawing 24 times the 104 alleles present on average in them out of a simulated reservoir comprising 1000-5000 alleles. We repeated this draw 30 times, and then determined the mean number of draws of each allele. The distribution obtained with the reservoir including 2000 alleles was most similar to that observed in the genomic repertoires of our data (Supplementary Fig. 5a ). Similarly, drawing 24 times 37 alleles to simulate the 24 expressed repertoires, the distribution with a reservoir of 1000 alleles resembled that we observed for the expressed repertoires (Supplementary Fig.
Interestingly, one of the four positions that are imperfect in the repeats, the C at position 19, is necessary to encode the arginine (R) within the second copy of the motif ARAV (Fig. 7a ). RA within ARAV is a motif that is cleaved by a number of peptidase, such as the cathepsins (MEROPS database). Furthermore, the R residue is a common recognition site for trypsinlike peptidase. Thus, the CRJE sequences might also be involved in the proper removal of the constant part of the Msg-I proteins by enzymes in order to ensure the variation of each Msg' antigenicity. As far as the other species of the genus are concerned, Pneumocystis macacae and Pneumocystis oryctolagi harbor a CRJE sequence similar to that of P. jirovecii, including the presence of two R residues in addition to that present in the recognition site of the Kexin (Supplementary Note 7, Supplementary Fig.
PCR artefacts The production of artefacts during PCR amplification of mixed alleles results in additional non-biological diversity  55. In order to address the occurrence of this problem in our conditions, two plasmids containing each a single specific msg-I allele were mixed before or after PCR amplification, and then sequenced using PacBio CCS (plasmids PL1 and PL2 containing alleles PL1c172754267 and PL1u100008324 that show 62% identity, which is close to the average of 66% between all 1007 alleles observed in the study [Supplementary Data 5]). Chimeric amplicons were observed upon mixing before PCR, but not after PCR. Most of the reads corresponded to the two alleles present in the plasmids (92. 5%), 7. 5% presented a single nucleotide polymorphism probably corresponding to a PacBio error, and 0.
Allele identification and quantification A dedicated bioinformatics pipeline of analysis of the Pacbio CCS raw reads was developed to identify the alleles present in each sample as well as their abundance. Information about the versions of the software and its packages are provided in Supplementary Table  2. The multistep process consisted in the following sequence of analyses: 1. hmmer  56  was used to identify the reads corresponding to msg-I genes by aligning them to a profile-HMM specifically generated using 18 msg-I genes previously identified in a pilot experiment and trimmed after the CRJE in order to be in frame. The nhmmer program command was used to filter the reads by alignment length and bit score, which resulted in removal of ca. 5% of the reads and a final number of 9742 to 156,375 reads per sample for further analysis.
The primers were derived from those described by reference 60 : 5′ GCTGGAAAGTTGATCAAATTTGGTC 3′ and 5′ TTCGGACGAGACTACTCGCC 3′ (the six underlined bases were added in 5' to the first primer to adjust the annealing temperature, and the four underlined bases replaced those from P. carinii, the species infecting rats, that were in fact within the second primer). The PCR program included 3 min at 95 °C of initial denaturation, 30 to 35 cycles consisting of 30 sec at 95 °C, 30 s at 62 °C, and 45 sec at 72 °C, followed by 1 min of final elongation at 72 °C. After purification using the Qiagen PCR column kit, the amplicons were sequenced using PacBio CCS. The bioinformatic pipeline dedicated to the analysis of the ITS1-5. 8S-ITS2 reads started with hmmer to identify the correct genes followed by a filtering step by read size between 470 and 500 bps (see above, Allele identification and quantification).
Xue et al. 60. Highlighted that the ITS1-5. 8S-ITS2 region includes seven homopolymer stretches that are prone to errors during both amplification and sequencing. Hence, the length of the six homopolymers that showed variation in our data were homogenized (Supplementary Fig. 3 ). The redundant reads were then clustered using swarm (option d0) and only the clusters comprising more than 1% of the reads present in each patient were analyzed. The correspondence of the sequences of the 25 genotypes observed to those present in GenBank is given in Supplementary Table  4.
BLASTn analyses We searched similarities within the 37 subtelomeres present in the whole P. jirovecii genome assembled from a single strain using PacBio sequencing  8. We used the BLASTn algorithm on the NCBI website (https://blast. ncbi. nlm. nih. gov/Blast. cgi) with the default parameter values (expected threshold 0. 05) and the following settings: database: whole-genome shotgun contigs (wgs), limit by: BioProject, BioProject name: 382815 Pneumocystis jirovecii strain E2178, program selection: somewhat similar sequences (BLASTn). The 37 contigs carrying msg genes are entire or partial subtelomeres corresponding to most of the 34-40 that are present in P. jirovecii genome (17-20 chromosomes)  4. Nevertheless, 17 of the 37 contigs do not carry non-msg genes flanking the subtelomere, so that they could not be attributed to a specific chromosome previously described  4.
Bioinformatics search for site-specific recombinases Potential genes encoding site-specific recombinases were searched for in the P. jirovecii genome (accession number LFWA01000000) by matching this genome against large pools of representative bait sequences by using tBLASTn (NCBI BLAST suite). These pools were recruited through the InterPro annotations IPR011010 (DNA breakingrejoining enzyme, catalytic core) from a wide range of taxa. The Uni-Prot identifiers of the baits used were P03870, P13769, P13770, P13783, P13784, and P13785. To avoid missing candidates because of the use of too stringent conditions, the tBLASTn searches were conducted with relaxed parameters (E value from 1E-4 down to the default value). Each match with a suitable E value was investigated by looking for preexisting annotations.
Acknowledgements The present work was submitted by C. S. M. as partial fulfillment of a Ph. D. degree at the  Faculty of Biology and Medicine of the University of Lausanne. Sequencing was performed at the  Lausanne Genomic Technologies Facility, University of Lausanne. We thank  Patrick Taffé  ( Unisanté, Division of Biostatistics, University of Lausanne ) for input into the simulation experiments. This work was supported by  Swiss National Science Foundation  grant  310030_192802  to P. M. H. The  Swiss National Science Foundation  had no role in any steps of the study. M. T. C. is a Senior Research Career Scientist supported by  IK6BX005232   Department of Veterans Affairs. All materials are available from the corresponding author.
Data availability The PacBio CCS raw reads generated in this study have been deposited in the NCBI Sequence Read Archive and are accessible through accession code SRP434110. The msg-I raw data are accessible through accession numbers SRR24284242 to SRR2428430 and the ITS1-5. 8S-ITS2 raw data under SSR25739987 to SRR25740015 in BioProject accession number PRJNA936793. The sequences obtained in this study have been deposited in Genbank (1007 new msg-I alleles) under accession numbers OR489167 to OR490173 and 15 new ITS1-5. 8S-ITS2 alleles under accession numbers OR475686 to OR475700. A table including the relative abundance of each msg-I allele identified in each patient is provided as Supplementary Data 5. Source data are provided with this paper.
Industrial Control Systems (ICS) are specific systems that combine information technology (IT) and operational technology (OT). Due to their interconnection and remote accessibility, they become a target for cyberattacks. As a result of their complexity and heterogeneity in terms of devices and communication protocols, specific security controls and risk analysis methods need to be developed. In particular, in order to reduce the effort of deployment of risk analysis on such complex systems, automated methods need to be provided. This paper deals with automation of the risk identification process for ICS using the STRIDE threat modeling framework. We extend the well-known STRIDE modeling tool, namely Microsoft Threat Modeling Tool (MTMT), with an incremental template dedicated to ICS and provide additional tools to automate the analysis using specific vulnerability extraction from Internet CVE databases.
As the frequency of such attacks is increasing, securing ICS became a priority for governmental agencies and, consequently, cybersecurity controls are now mandatory for some critical industrial activities. The first step of securing and certifying industrial devices or systems is the cybersecurity risk assessment. Several risk assessment methods already exist and are used to evaluate the system's security as EBIOS Risk Manager  [4] , STRIDE  [18] , DREAD  [10] , LINDDUN  [9] , PASTA  [19]. However, such risk analysis methods are generic and applying them on specific types of systems can quickly become a tedious process. Therefore, in some application domains, developing dedicated templates and databases will help the modeling of systems during analysis. For instance, there are templates for medical devices or services deployed in Azure cloud.
Specifically, industrial systems are mainly composed of proprietary hardware (for liability reasons), and, de facto, there is a large choice of models that accomplish the same function (e. g. , PLCs or motor drivers). Therefore, it is difficult to maintain an up-to-date database of vulnerabilities which are specific to each particular model. In the same way, industrial devices usually communicate with multiple industrial network flow types (both secured and unsecured) at the same time. Contributions: In this paper, we propose a toolkit to simplify STRIDE modeling for industrial systems with an automated generation of threats based on known vulnerabilities. This toolkit includes an extendable database of ICS components permitting both to aggregating knowledge on ICS devices and to model them into Microsoft Threat Modeling Tool  [5]  (MTMT).
MTMT provides a user-friendly graphical environment to perform STRIDE-per-interaction analysis. According to Adam Shostack  [18] , STRIDE-per-interaction is an approach to threat enumeration that considers tuples of (origin, destination, interaction) and enumerates threats against them. In summary, our contributions are the following: • An extendable database of ICS components to model specific industrial architectures and threats; • An automated tool to generate MTMT templates from the database; • An improved methodology allowing to gather CVE (Common Vulnerability Exposures) from system's devices then matching their impact to STRIDE threats in MTMT. Outline: The rest of the paper is organized as follows. Section 2 describes background knowledge and state-of-the-art. Section 3 presents an industrial use case to showcase our contributions.
We have chosen a simple use case to focus on the description of our solutions. We will see later that our contributions allow to easily extend a database to include DCS and SCADA architectures. On the top of the Figure  1 , we can see a AVEVA system platform HMI software. Such HMI allows an operator to supervise the system. It displays plant information to the operating personnel graphically including a schematic representation of the plant, alarms and events logging. Underneath the HMI, the architecture includes a Yokogawa Centum VP PLC. In this use case, the PLC is used to control the system. It gathers data from the physical process and acts according to its embedded logic. Finally, connected to the Centum VP PLC, are two Honeywell ControlEdge RTUs (Remote Terminal Unit). RTUs are operated as ADC (Analog-Digital Converter), that is, they digitize physical quantities from the process and transfer it to the PLC.
ICS template The first step in MTMT is to model the system's architecture through a data-flow diagram. To perform this stage, the modeler requires a template. MTMT does not provide any template for ICS. AbuEmera et al. [1]  proposed a handmade MTMT template with a list of threats manually created. As their approach is made of a fixed list of generic devices and threats (e. g. , PLCs, RTUs, etc. ), no automated method can easily allow to consider real devices and their specific threats as part of their template. Thus, we created a new template oriented to automated extraction of threats from vulnerability databases allowing for tailored risk identification. As mentioned in Section 2. 2, a MTMT template is composed of stencils and threat types. Stencils describe generic components, such as Communication Protocol or PLC, which are declined in specific components named derived stencils, as ModBus TCP Protocol for Communication Protocol or Centum VP for PLC.
These properties Therefore, the quality of the model depends on the relevance of our properties. In the default Microsoft template, stencils already exist to define software (Generic Process) or communication protocols (Data Flows). So, we have defined properties of the AVEVA system platform and ModBus TCP derived stencils according to our knowledge and the publicly available documentation. To construct PLC and RTU stencils and properties we used protection profiles  [3]  for PLC provided by ANSSI, the French cybersecurity agency. This protection profile was written as part of the work of the Industrial Systems Cybersecurity Working Group (ISWG), which includes companies such as Phoenix Contact, Schneider Electric, Thales or Siemens. Protection profiles identify PLC parameters (sensitive assets, their threats, and their associated security objectives) which fit well with MTMT structure.
We consider that industrial devices, as RTU, may be viewed as PLC with less functionalities. For instance, properties as "Firmware" or "Operating mode" presented in Listing 1 are applicable for RTU but "User program", present in the PLC protection profile, is not a functionality provided by a RTU. This work to derive properties from PLC to other devices must be done by an expert to properly define the properties of the equipment. In this part, we introduced how we built the skeleton of our incremental database of ICS components from a typical industrial PLC architecture and how we defined components properties from protection profiles of the French cybersecurity agency. In the following part, we present an automated tool to generate MTMT templates from the database.
Template automation for MTMT Yet, there are currently hundreds if not thousands of industrial devices on the market and providing a template including all of them would be a tedious task. This way, we introduce a tool which allows to automatically add specific devices and their threats in MTMT as derived stencils. This tool lets any modeler specify exactly which devices are in use in their systems and have them automatically added to the template with their threats. In section 4. 1, we presented a template for ICS, made of generic devices. Our second contribution is to provide a tool that automates the creation of a template from a configuration file. The template provided in section 4. 1 integrates generic devices and data flows of a PLC architecture (PLC, RTU, industrial data flow and industrial software).
Based on this model, we propose a tool that generates, from a configuration file, a model with real devices needed by the designer (for example, a Yokogawa Centum VP PLC instead of a generic PLC). This configuration file will work as a database of real devices, data flows and threats. We can see this configuration file as a community database that modelers increment according to the devices they need. Once a device is created, it will be accessible to all users. This tool also includes the research of known vulnerabilities (describe later in Section 5) for all devices mentioned in the configuration file. We chose to use TOML  [17]  (Tom's Obvious, Minimal Language) for the configuration file. TOML is a configuration file format designed to be easily read and written with an open source specification.
It is structured through three main items : sections ([section. sub-section]), pairs (key = value), and comments (# comment). Listing 1 introduces a partial configuration file of the use case already filled with the information of our generic ICS template. Modelers only need to add which devices are required for their system and for which a research of CVE will be carried out. We choose to define TOML file as database instead of the XML-based MTMT template for the following reasons. Firstly, a model is associated with a single template, and thus, incrementing the template creates a conflict with former models. Secondly, TOML configuration file can be easily used for other tools. We propose the ability to filter CVE according to a period of time (e. g. , since 2001, between 2010 and 2020, etc.
) and/or a severity metric (CVSS score). Indeed, such filtering allows to avoid numerous vulnerabilities that do not matter (e. g. , too old or not critical). CVE are collected on NVD vulnerability database  [16]  according to the configuration file (devices and filters). Without filters there are 7 vulnerabilities for the AVEVA system platform, 25 for Yokogawa Centum VP, and 3 for Honeywell ControlEdge RTU (CVE research with incomplete names can lead to false positives). With filters defined in the TOML file, presented in Listing 1, we decrease vulnerabilities to 14 for Yokogawa Centum VP  (11 less). Obviously, the default ICS template can be customized by users for their particular needs adding threats from their CTI (Cyber Threat Intelligence), stencils for their domain-specific device family, etc.
Indeed, in this context Elevation of privilege and Spoofing have a close meaning but there are still distinguishable by their impact. As mentioned by Honkaranta et al. , the NIST Vulnerability Database (NVD) provides links from CVE to CWE and gives the possibility to match CVE with STRIDE. However, Loveless  [15]  showed in 2008 the difficulty of mapping CVE to a CWE correctly. According to Lovelss, up to 25% (missing, need details, inclusion) of CVE may not have corresponding CWE and consequently Honkaranta et al. 's method is inapplicable. To fill this gap, numerous articles  [6, 11, 20, 21]  propose AI-based solutions to map CVE to CWE. However, none of them made their program, algorithm, or source code available. To overcome this problem, we propose an improved method to map CVE with CWE in this article.
For example, WinCC CVE-2021-27384 "A vulnerability has been identified in SIMATIC HMI Comfort Outdoor Panels [. ]. SmartVNC has an out-of-bounds memory access vulnerability in the device layout handler, represented by a binary data stream on the client side, which can potentially result in code execution. " has an high impact on confidentiality, Integrity, and Availability in CVSS score vector. Our method will not take into account the Elevation of privilege threat (unauthorized code execution). Even if our method (compared to an intermediate mapping with CWE) tends to merge threats together, we still identify that a threat exists and must be addressed. Moreover, we argue that often, adding a countermeasure for one security objective will also improve other objectives (e. g. , adding authentication also often prevents tampering, or information disclosure).