dataesr/scientific-paragraphs-categorization huggingface dataset:
This subsection details the deployment of an expected traffic profile on the different end-systems. For this experiment, we use two Linux Debian network hosts called H1 and H2, running on a mono-core 1. 2 GHz with 1 GB of RAM. They are connected to a router RT running a quad-core Intel processor @3. 8 GHz with 4 GB of RAM. The links between hosts are Ethernet RJ45 connections manually configured to 10baseTx-HD, in order to easily limit the link capacities without any software solution and thus to capture all the traffic without any loss. The experimental network topology has been already presented in figure  5. H1 runs the sender part of our tool and H2 runs the receiver part. After the beginning of the generation, the traffic profile tends quickly to a permanent and stable mode. At this moment, the processor consumption reported by system monitoring tools such as top & htop is around 5% CPU time on the transmitter H1 and 10% on the receiver H2.
The virtual memory allocated by the Linux Operating System for the tool is between 2 and 16MB on our hosts, depending on the number of sources we wants to start (16 MB when infinite number of sources). These measures remain stable until the program automatically finished or was stopped by the user. We captured different network traces: between 10 minutes and 10 hours. We will describe in the next subsections only one of them, because other captures concluded to the same results. The following subsections will analyze the captured data on the router during one hour, searching for the properties which characterize an Internet-like traffic profile.
Quantile-quantile plots As qualitative estimators, we used quantile-quantile plots diagrams  (Becker et al. , 1978)  (also called "QQPlots") to represent on the same diagram the measured values on the real network (i. e. the original data) and the measured values on the experimental network (i. e. the SourcesOnOff generated data). QQPlot diagrams sort independently X and Y values, and then represent points to the sorted coordinates. When the X and Y series are correlated, a linear tendency is visible on the diagram. On our QQPlot diagrams, we will represent a diagonal blue line of equation y=x, in order to represent a perfect correlation between x and y values. Firstly, we studied the Doff values, i. e. the inter-train durations. The set of values used for the X data is the set of durations between two consecutive TCP connections observed in the capture in the real network.
The set of values used for the Y data is the set of durations between two consecutive TCP connections measured in the traffic generated by our tool SourcesOnOff. In other words, the Y values are the durations our tool waited between starting two TCP connections. We can see on figure  7  that the values are very well correlated: most of the 9,700 points drawn on this figure are near the diagonal blue line of equation y=x. This means most values measured in the real network were successfully reproduced in our experimental network. The correlation factor is 99. 8% in our case for Doff values. A few points with high values are not well correlated: they come from the tail of the Weibull distribution densities. Secondly, we performed the same analysis with the Don values, i. e. the measurement of TCP connection durations (exchanged bytes between the different hosts).
We introduce SysML-Sec, a SysML-based Model-Driven Engineering environment aimed at fostering the collaboration between system designers and security experts at all methodological stages of the development of an embedded system. A central issue in the design of an embedded system is the definition of the hardware/software partitioning of the architecture of the system, which should take place as early as possible. SysML-Sec aims to extend the relevance of this analysis through the integration of security requirements and threats. In particular, we propose an agile methodology whose aim is to assess early on the impact of the security requirements and of the security mechanisms designed to satisfy them over the safety of the system. Security concerns are captured in a component-centric manner through existing SysML diagrams with only minimal extensions.
We introduce SysML-Sec, a SysML-based Model-Driven Engineering environment aimed at fostering the collaboration between system designers and security experts at all methodological stages of the development of an embedded system. SysML-Sec introduces both customized SysML diagrams for security matters and an associated methodology. The SysML-Sec methodology includes three SysMLbased stages. (i) System analysis starts with a partitioning-based process in which security requirements and threats can be identified together with functional features of the system. (ii) System design focuses on software-implemented security mechanisms. Finally, (iii) System validation intends to formally verify, simulate, and test the models built at previous stages by relying on model transformation techniques. This paper presents the overall methodology, with a particular focus on the design and proof of security mechanisms.
Designing Embedded Systems IT systems are commonly designed following a V-cycle, with building stages (requirements, analysis, design, deployment) followed with verification stages (e. g. , tests, formal proofs). For embedded systems, the V-cycle can obviously start only once functions have been partitioned into software and hardware. System partitioning usually relies on the Y-chart approach  [7]. This is the very first step to co-design software and hardware functions on the one hand, and the hardware architecture (defined in terms of execution, communications, and storage) on the other hand. The result of this process is an optimal hardware / software architecture with regards to criteria at stake for that particular system (e. g. , cost, performance, etc. ). In the scope of the DIPLODOCUS environment  [4] , on top of which SysML-Sec is built, the Y-Chart is implemented as follows: 1.
), then it may induce prohibitive re-engineering costs and late market availability. DIPLODOCUS relies on the SysML allocation mechanisms for the mapping stage. The UML deployment diagram might be a good candidate for this, but it is rather used for the deployment of alreadydesigned software functions: "the assignment of software artifacts to nodes", as stated in the UML standard. In DIPLODOCUS, functions may be fully hardware implemented. Moreover, they are highly abstracted, that is, we do not map any concrete artifacts (e. g. , a source file), but only high-level functional elements.
Rationale We designed the SysML-Sec environment in order to make it possible to describe security issues together with partitioning requirements, as further discussed in  [30]. In particular, our extensions bridge the gap between goal-oriented descriptions of security requirements and attacks, and the fine-grained representation of assets based on the software / hardware architecture (and their model-driven analysis). SysML-Sec also supports phases of the V-cycle after the partitioning stage, and notably the design of the software-partitioned functions  1. The main objectives of SysML-Sec are: • Guiding and increasing the collaboration between system engineers and security experts throughout the entire embedded system lifecycle. This has been the reason for our adoption of the OMG standards, and more specifically SysML, which are quite widespread in the embedded system world today.
Methodology The SysML-Sec methodology adopts a three-phase approach that first deals with the system analysis, then with software design, and finally with system validation, as depicted in Figure  1. The analysis includes the elicitation of requirements and attacks, and the partitioning of the system. The design stage includes the definition of security mechanisms, and the refinement of security requirements in security properties to be proved in the design. Lastly, the verification takes place at different engineering phases, as follows. Simulation is mostly used at the partitioning stage in order to evaluate the impact of security SysML-Sec mechanisms in terms or performance. Formal verification intends to prove the resilience of the system under design to threats. Testing is meant to do the same, but on the deployed implementation resulting from the design models.
Case Study: Firmware Update We illustrate SysML-Sec methodological stages with a "firmware update" case study. The latter is taken from a public deliverable of the European project EVITA  [19]. The main purpose of EVITA is to define a secure architecture for automotive embedded systems. Such systems are in charge of critical functions and are quite complex: they contain around 100 Electronic Controls Units (ECUs) all interconnected to the main system bus (CAN, FlexRay). Attacks are motivated by safety and economical reasons (notably theft). Security concerns, which were mostly related with physical access to the car are also evolving today with the advent of the connected car and of Car2X communications, which further exposes these systems. The considered case study aims at the update of an ECU software with a newer version of the firmware, as performed at a service station through diagnosis tools.
The second one defines data that are shared within each session of the same system. Typically, when considering a cryptographic protocol, the first pragma means that the data are pre-shared and common to all protocol sessions, and the second one states that the data are shared but have different values in each protocol session. InitialSystemKnowledge BlockID. attribute [BlockID. attribute]* For example, Figure  6  displays the block diagram of a key distribution protocol used as a security protocol so as to allow ECUs to communicate in a secure way. That protocol is built upon three different entities: the initiator of the key distribution (ECU1), a key master (KM) and the ECUs with which ECU1 expects to share keys (ECUN). All blocks define cryptographic functions, two of them being visible in ECUN (encrypt(), decrypt()).
Security Properties Security properties linked to the design are obtained from a refinement of security requirements elicited at analysis stage. A dedicated language has been defined for describing the commonly complex safety properties, which is based on SysML Parametric diagrams  [21]. On the contrary, security properties can usually be defined with a type (e. g. , confidentiality), and with design elements related to that kind (e. g. , the confidentiality of the attribute of a block). This simplicity pleads for a basic modeling solution, that is not based on complex diagrams or operators. Our solution again relies on pragmas, provided in notes of Block Diagrams: confidentiality and authenticity can be directly expressed at this level. A confidentiality pragma states that the content of an attribute of a block shall never be disclosed to an attacker:.
System Validation A system validation can be performed from partitioning models (e. g. , performance evaluation of the selected hardware architecture: load of CPUs and buses), from design models (e. g. , proof of safety and security properties), or from executable code automatically generated from deployment models (e. g. , safety and security tests)  [2]. Model transformations have been defined in order to transform SysML-Sec models into simulation, formal, or executable specifications. Mapping model transformations are given in  [20] , and design model transformations are described in  [26]  and  [16]. From partitioning models, it is possible to evaluate the impact of security mechanisms onto safety constraints, e. g. , real-time constraints such as latencies. An example of such a study is given in  [33]  where the impact of adding security-oriented MAC information in the messages of CAN bus is checked against safety-oriented properties (latencies) at partitioning stage.
Assessing security properties at design level mostly relies on formal approaches. For example,  [35]  proposes to verify cryptographic protocols with a probabilistic analysis approach. In more recent efforts,  [10]  introduces a first order Linear Temporal Logic (LTL) into the Isabelle/HOL theorem prover, thus making it possible to model both a system and its security properties, but unfortunately leading to non-easily reusable specific models. [23]  mixes formal and informal security properties, but the overall verification process is not completely automated, again requiring specific skills. Our approach focuses on refining semi-formal specifications into formal models using a graphical language, with the aim of formal validation of the satisfaction of security properties. In this respect, it may seem very similar to the UMLsec approach  [18] , a modeling framework aimed at defining security properties of software.
UMLsec also primarily features a model-based approach to security requirements engineering according to the abovementioned classification. It makes it possible to define security properties of software components and of their composition within a UML framework. It also features a rather complete framework addressing various stage of model-driven secure software engineering from the specification of security requirements to tests, including logic-based formal verifications regarding the composition of software components. With respect to the embedded system field which the current paper focuses on, UMLsec allows for the description of the mapping of already-designed software onto hardware nodes  [18]  through the use of UML deployment diagrams. According to OMG's own definition, such diagrams describe "a set of constructs that can be used to define the execution architecture of systems that represent the assignment of software artifacts to nodes.
". This means that they unfortunately cannot handle softwarehardware partitioning in the sense of  [7]. In contrast, SysML-Sec adopts the more holistic point of view of SysML proponents and focuses on the very evaluation of various mappings for security and functional features before and during detailed system design. Additionally, SysML-Sec provides hardware nodes with an explicit autonomous simulation and proof semantics. Lastly, SysML-Sec includes lowlevel hardware nodes whose use may impact communications and executions of functions, e. ,g. a DMA engine may favorize, or not, a urgent communication with regards to security-oriented communications. Similarly to UMLsec  [17] , our proposal additionally features a goal-based approach to describe security objectives. Still, our approach fits entirely within SysML with minor extensions (essentially new stereotypes and a few operators) and does not introduce any new diagram in order to make it easy to adopt for system engineers.
In particular, approximations can first be made based on the nature of security mechanisms, and most notably, the cryptographic algorithms used and their costs (both computationally and in terms of bandwidth usage). As the design of the security mechanisms to be deployed is increasingly refined, together with a more detailed hardware/software partitioning, simulations by the SysML-Sec framework can be used to achieve a more precise evaluation of those elements. Although not yet supported by our toolchain, tests might finally be used on the developed components to validate the adherence to safety requirements. Threat analysis itself pleads for such a move, to incorporate the description of security tests performed over implementations into the system model. In this respect, our proposal includes the use of the SysML parametric diagram for threat modeling.
SysML-Sec can thus encode an attack tree, yet it adopts a block-centric perspective with reuse in mind. We especially think that this will allow for the composition of the threat modeling performed by security analysts about components over-the-shelf (COTS) with system specific analyses. We plan to further extend SysML-Sec expressivity here: our declarative approach should be especially useful in order to incorporate knowledge from other threat modeling approaches. Tool support is in our opinion critical to the successful and systematic engineering of systems, and especially so in what regards non-functional requirements like security and the validation of their satisfaction in a given design. This need has been recognized by many other authors at various levels of the development lifecycle of IT systems.
Furthermore, the availability of free software is another important factor of success, would it only be due to their extensibility for specific needs. The KAOS framework  [36] , which pioneered goal-oriented security requirements engineering, features an entire dedicated environment. CARiSMA (a recent extension of UMLsec) integrates into the Eclipse development environment, which ensures a better acceptance factor. Threat modeling frameworks have also been developed SysML-Sec like Isograph Software's AttackTree+ for designing attack trees or the free software ADTool  [22]. There also exists a number of formal verification tools with nice interfaces like AVISPA  [5] , which provides good support for protocol verification. It can be observed that many of these tools address only a part of the development lifecycle of a system, which is detrimental to their adoption.
Conclusion and Future Work Embedded systems are becoming ever more complex and intricate combinations of software and hardware, exposed to a plethora of attacks as those systems open up to attackers through the introduction of communication functionalities. The economic incentives to reduce the time-to-market of such systems while ensuring equally good or better engineering qualities require the introduction of systematic security engineering methodologies with an appropriate support. The adoption of user-friendly tools featuring automated and simplified verification will likely become mandatory in this respect. Our proposal, SysML-Sec, specifically addresses that need at the diverse phases of system design and development. It is based on a popular language (OMG's SysML) and supported by a free software toolkit (TTool).
Also, it allows the posterior distribution of the Time to the MRCA between two alleles (T MRCA ) to be recovered. This property was used to discuss the risk that a false bottleneck be detected in a population submitted to immigration, comparing the expected distributions of T MRCA under both hypotheses. The method was evaluated and discussed in comparison with MSVAR  (Beaumont 1999 ) which makes use of the same type of data. It was implemented into an R package VarEff, available at http://cran. r-project. org/web/packages/VarEff and at https://qgsp. jouy. inra. fr.
Materials and methods We detail the genetic and demographic framework used in the present study, and outline the statistical setting used, assuming the studied population remained isolated. In order to discuss the effects of gene flow on the results, we developed a simple model to illustrate how permanent immigration may mimic the effect of a recent bottleneck on the distribution of T MRCA. Details on implementation and its uses can be found in the VarEff package and at the Quantitative Genetics Software Platform (https://qgsp. jouy. inra. fr).
The move of parameters values from the uth to the (u + 1)th iteration is obtained as: p uþ1 ¼ p u þ KDZ uþ1 where p u stands for the current values, Z u + 1 is a random vector of normal standard variates with zero mean and covariance matrix equal to the identity matrix, D is the matrix such that W = DD 0 is the Choleski decomposition of W, and K is a scale factor used to adjust the acceptance rate at a desired value. Implementation of the Metropolis-Hastings algorithm made use of the metrop function of the mcmc library  (Geyer 2009)  available in the R environment  (R Development Group Team 2008, version R 2. 10. 10 or later). The method was implemented in an R package available at http://cran. r-project. org/web/packages/VarEff. At the end of a run of VarEff, a list of demographic step functions is generated.
Atlantic salmon data sets The method was used to estimate the current and past effective sizes of wild Atlantic salmon populations sampled in two countries, France (Oir and Scorff) and Scotland (Shin and Spey) in  1988 , 1992 and 2005 (Nikolic et al. 2009a)). Estimations of sizes were searched for from sampling time to 5000 generation ago. The results revealed a large past ancestral size (median around 50 000-90 000) and a lower current size (Fig. 8 , Table  4 ), assuming a mutation rate of 0. 0003  (Nikolic et al. 2009b ). The general patterns of effective size (Fig. 8 ) were similar for the four populations, except for the 1988 sample of river Spey. Deriving the posterior distribution of the Time to the Most Recent Common Ancestor (T MRCA ) of a pair of alleles from the distribution of effective size (eqn A2 in Data S1) confirmed that these populations underwent a bottleneck.
7. This analysis provides an explanation for the wrong detection of strong bottleneck by a program like MSVAR when analyzing data generated according to an island model with constant population sizes, and we could propose an estimation for the time when a false bottleneck it detected eqn (8). Like MSVAR, our method is based on estimated distributions of coalescence times of alleles. In the case of immigration, similar alleles (at low k distance) drawn from the population derive mostly from an allele within the population, i. e. , during the 'scattering phase'  (Wakeley 1999). Distant alleles are likely to have coalesced in the large exter- (5000 generations ago) effective sizes for Oir, Scorff, Shin and Spey Atlantic salmon populations at the two sampling dates  (2005 and 1988 or 1992). The census size (N) of populations are also shown and the ratio N/N 0 of N to the harmonic mean (H) and median (M) of N nal population (the 'collecting phase'), as soon as one of them was an immigrant.
Acknowledgements The authors thank  Marion Ouedraogo  ( INRA-AgroCampus Ouest, Rennes, France ) for her help with R packaging and  Nicolas Edwards  for language revision. They also wish to thank  INRA (Rennes, France) , the  Spey Fishery Board Research Office of Morayshire (Scotland, UK) , the  Fisheries Research Services of Perthshire (Scotland, UK) , and the  Kyle of Sutherland District Salmon Fishery Board (Scotland, UK)  for providing support in the collection of scale and fin samples. Samples were genotyped at the  Toulouse Genopole Platform  (http://www. genotoul. fr/). This study was supported by the  Laboratoire de G en etique Cellulaire at INRA (Toulouse). The authors thank the two anonymous reviewers and the associate editor for their helpful comments and recommendations to improve this manuscript.
However, it has been shown  (Alexandru et al. , 2008; Omrani et al. , 2012)  that the nudging parameters should be carefully chosen in order to avoid excessive control of the large-scale atmospheric variability and decrease of the internal variability. The area of interest in this study is the Arctic Region including the northern part of the North Atlantic (Fig. 1 ). We investigate what effect inclusion or exclusion of certain regions has on the Arctic climate simulations and how it affects externally and internally generated variability. In particular we address three main questions: What is the influence of regional domain configuration on climate simulations over the Arctic region? What are the mechanisms responsible for differences between the coupled model simulations over different domains? Is it possible to estimate the contribution of internal modes to Artic climate variability? The structure of the remaining paper is as follows: Section 2 describes the experimental setup and the datasets.