dataesr/scientific-paragraphs-categorization huggingface dataset:
OBSERVATIONS AND DATA REDUCTION Each Cepheus field was observed simultaneously with the Herschel Space Observatory's Spectral and Photometric Imaging Receiver (SPIRE) and Photodetector Array Camera and Spectrometer (PACS) instruments in parallel mode, as part of the Herschel Gould Belt Survey (HGBS) Key Program  (André et al. 2010)   1. Further information on Herschel, SPIRE, and PACS can be found in papers by  Pilbratt et al. (2010) ,  Griffin et al. (2010) , and  Poglitsch et al. (2010) , respectively. Table  1  summarizes the Herschel observations of the five Cepheus fields, giving the name of each field, the J2000 coordinates of the reference position of each map, the observational date (in UT), and the Observation IDs (OBSIDs), respectively. Each field was observed twice, with scans made in roughly perpendicular position angles, at a scanning speed of 60 s -1.
To extract YSOs or protostars, we used only the Herschel maps at 70 µm. YSOs and protostars will heat their surrounding dust to temperatures higher than those of cold cores, making them stand out obviously at 70 µm as point-like objects (e. g. , see  Dunham et al. 2008). For both sets of extractions, source fluxes and sizes are measured from the native Herschel maps of all five wavelengths, appropriately deblended, background subtracted, and aperture corrected. Source lists were constructed from identified sources deemed reliable following separate standard criteria for each extraction. These criteria are listed in Appendix B. Finally, to reduce potential contamination by background galaxies, source positions were cross-checked with the NASA/IPAC Extragalactic Database (NED) and the SIMBAD database.
4 K for L1157, L1172, L1228, L1241, and L1251, respectively. The observed size of each core was determined as the geometrical average of the FWHMs of its major and minor axes in the high-resolution (18. 2) column density map of its host Cepheus cloud (F W HM a , respectively. This angular size was converted to a physical size (R obs core ) assuming the ∼360 pc distance to the Cepheus Flare clouds (see §1). A deconvolved radius was also determined via R decon core = (R obs core 2 -HP BW N H 2 2 ) 1/2 where HP BW N H 2 is the physical size of the 18. 2 beam, i. e. , 0. 032 pc at the ∼360 pc distance of the core. We use the determined mass and size of each core to obtain estimates of their peak column densities (N peak H2 ), determined from the peak flux densities at the 36. 3 resolution of the 500 µm data (see Appendix C and online material).
1). Earlier comparisons of HGBS column densities with extinction maps  (Benedettini et al. 2015; Könyves et al. 2020 , Pezzuto et al. 2020, in press ), however, have indicated such Herschel-based column densities may underestimate the true column densities at lower extinctions, e. g. , A V < 4. To explore this possibility for Cepheus, we used near-infrared data from 2MASS  (Skrutskie et al. 2006)  to determine extinction maps of each cloud at 4 FWHM resolution and compared these extinctions to those expected from Herschel data. Specifically, Figure  12  contains a histogram showing the difference between the extinctions from the two datasets for A V < 4. For this histogram, the 18 FHWM resolution Herschel-based column densities were smoothed to the 4 FWHM resolution of the 2MASS extinction maps, regridded to the same 2 × 2 pixels of the 2MASS extinction maps, and converted to extinctions using the common A V -to-H 2 conversion factor of N(H 2 ) = A V × 0.
94 × 10 21 from  Bohlin et al. (1978). The comparison clearly shows the Herschel data consistently produce lower extinctions than those expected from 2MASS data by ∼0-2 magnitudes, with a peak difference at ∼1 magnitude. Though the intrinsic resolutions of the datasets differ significantly, the Herschel-based column density estimates we use as the basis of our discussion here may be systematically lower by ∼1 × 10 21 cm -2. Accordingly, the line masses of Cepheus filaments may be systematically larger by ∼2 M pc -1 , somewhat increasing the fraction of such filaments in the transcritical line mass range. See  Benedettini et al. (2015)  and  Könyves et al. (2020)  for discussions of possible sources of the disparity between extinctions and Herschel-derived column densities. Even with a modest increase in local column densities, star formation is occurring in Cepheus in relatively low column density environments.
ACKNOWLEDGMENTS We thank the input of an anonymous referee whose comments greatly improved this paper. J. D. F. and J. K. acknowledge the financial support of a  Discovery Grant  from the  NSERC of Canada. N. S. and S. B. acknowledge support by the  Agence National de Recherche (ANR/France)  and the  Deutsche Forschungsgemeinschaft (DFG/Germany)  through the project " GENESIS"  ( ANR-16-CE92-0035-01/DFG1591/2-1 ). SPIRE has been developed by a consortium of institutes led by  Cardiff Univ. (UK)  and including:  Univ. Lethbridge (Canada) ;  NAOC (China) ;  CEA ,  LAM (France) ;  IFSI ,  Univ. Padua (Italy) ;  IAC (Spain) ;  Stockholm Observatory (Sweden) ;  Imperial College London ,  RAL ,  UCL-MSSL ,  UKATC ,  Univ. Sussex (UK) ; and  Caltech ,  JPL ,  NHSC ,  Univ. Colorado (USA). This development has been supported by national funding agencies:  CSA (Canada) ;  NAOC (China) ;  CEA ,  CNES ,  CNRS (France) ;  ASI (Italy) ;  MCINN (Spain) ;  SNSB (Sweden) ;  STFC ,  UKSA (UK) ; and  NASA (USA).
PACS has been developed by a consortium of institutes led by  MPE (Germany)  and including  UVIE (Austria) ;  KUL, CSL, IMEC (Belgium) ;  CEA, OAMP (France) ;  MPIA (Germany) ;  IFSI, OAP/AOT ,  OAA/CAISMI, LENS, SISSA (Italy) ;  IAC (Spain). This development has been supported by the funding agencies  BMVIT (Austria) ,  ESA-PRODEX (Belgium) ,  CEA/CNES (France) ,  DLR (Germany) ,  ASI (Italy) , and  CICT/MCT (Spain). This work received support from a  Discovery grant  from the  National Science and Engineering Council of Canada. This research has made use of the SIMBAD database, operated at  CDS, Strasbourg (France) , and of the NASA/IPAC Extragalactic Database (NED), operated by the  Jet Propulsion Laboratory, California Institute of Technology , under contract with the  National Aeronautics and Space Administration.
The authors in  [4]  assert that PSA Group vehicles can send roughly 170 different types of data ranging from vehicle identification number, GPS coordinates, engine rounds per minute to the current angle of the steering wheel, etc. This amount of data has great value for automotive manufacturers as well as for third parties since it allows the development of several applications and services in different domains (improve driver's safety, enhance mobility experience, personalize insurance costs, etc. ). In PSA experience  [4] , MQTT is used as a communication protocol that connects, through a broker, vehicles as publishers and PSA automotive infrastructure as a subscriber. Data is then collected from vehicles and processed in both off-line and on-line (real or near real-time) fashions by PSA Big Data infrastructure.
Furthermore, because of the sensitivity of several automotive applications, we provide in this paper formal proofs of the correctness of our proposed protocol (i. e. , the three components will behave as they are supposed to do). To this end, we used components formal validation based on Promela language  [6]  and the model checker SPIN  [7] ,  [8]. To the best of our knowledge, this is the first research work addressing both formal verification and performance improvement of a data exchange protocol specifically tailored to CVs infrastructures. The rest of the paper is organized, as follows: works related to our proposition are presented in Section II. In Section III, we succinctly present the MQTT protocol and provide a brief introduction to the model checker SPIN and Promela language. Section IV describes the proposed MQTT-CV protocol.
To summarize, we can say that compared with state-ofthe-art solutions, the originality and contribution of the work presented in this paper are (1) the proposition of MQTT-CV (a publish/subscribe protocol dedicated to connected vehicles), (2) its specification with Promela language, and (3) its analysis/verification with the SPIN model checker. Additionally, real implementation and experimentation have been conducted to demonstrate the effectiveness of our approach in terms of noticeable performance improvement (i. e. , workload reduction) in the context of automotive big-data infrastructures.
B. Spin Model Checker and Promela Language SPIN is one of the world's most popular, and arguably one of the world's most powerful, tools for detecting software defects in concurrent system designs  [8]. More specifically, SPIN is an open-source tool that has been developed at Bell Labs by Gerard Holzmann, and since has been applied, so to speak, to everything; from the verification of complex call processing software (used in telephone exchanges) to the validation of intricate control software for interplanetary spacecraft  [8]. In SPIN, a formal specification is built using Promela; an imperative language close to C programming language (variables declaration, data types, etc. ). A Promela program is composed of a set of processes that are defined with the statement proctype. To perform system analysis and verification, SPIN transforms each process into an automaton.
V. M Q T T-C V C ORRECTNESS In this section, we provide correctness proofs of our proposal MQTT-CV. To this end, we used the well-know SPIN model checker and its associated Promela language. Generally, the proofs are depicted in four steps: (a) the use of a representative case study, (b) this case study is modeled using UML language and (c) implemented in the Promela language. (d) Finally, formal verification is performed using SPIN. The aforementioned steps are described in the following subsections.
B. UML Modeling Before formally analyzing MQTT-CV, we propose a UML sequence diagram (Fig. 3 ) that models a scenario of interaction between the main components implementing this protocol; that is, broker, vehicles, and automotive infrastructures. This model will be utilized later in Section V-C to implement MQTT-CV using Promela language. As Fig. 3  demonstrates each of the three components is modeled with a lifeline. The infrastructure starts interactions by sending a reqsub message that allows it to subscribe to a specific topic. The broker responds by sending an acknowledgment ack. After that, two interactions occur in parallel (see the UML parallel combined fragment). In the first interaction, the vehicle sends data related to both topics; temperature and vehicle speed. Whilst in the second one, the broker sends the received data while (1) respecting the infrastructure conditions and (2) taking into account its chosen topics.
C. Promela Implementation To be able to use the model checker SPIN, MQTT-CV must be implemented in Promela language. To do so, we consider the UML protocol specification described in Fig. 3  and the case study presented in Section V-A and Fig. 2. In more specific words, we associate a Promela process (proctype statement) to each interacting component (one broker, two vehicles, and two automotive infrastructures). In SPIN, these five processes will be executed in a parallel fashion and will be launched by the init process: The interactions between these concurrent processes can simply be implemented via the communicating channels allowing to send/receive integers. Indeed, this abstraction of data exchange is sufficient to simulate and verify the proposed protocol. The channels we have defined to implement MQTT-CV are: r chan_reqsub1 and chan_reqsub2: are, respec- tively, used by the first and second subscribers to request a subscription (from the broker) on one or many topics.
The subscriber sends an integer to indicate the desired topics. r chan_acksub1 and chan_acksub2:u s e db yt h e broker to, respectively, send an acknowledgment to the first and second subscribers after their subscription requests. r chan_cvbroker_tmp and chan_cvbroker_spd: used by connected vehicles to send data about topics defined in the broker. As their names indicate, these two channels are, respectively, dedicated to the temperature and speed topics. r chan_brokersub1_tmp and chan_brokersub1_spd: used by the broker to send data (i. e. , temperature and speed) to the first subscriber (automotive infrastructure 1). r chan_brokersub2_tmp and chan_brokersub2_spd: used by the broker to send data (i. e. , temperature and speed) to the second subscriber (infrastructure 2). In the next subsections, we provide and discuss the Promela code that we propose to implement the subscribers, publishers, and broker.
Note that there are no deadlock states in this automaton. The Promela code of infrastructure 2 is relatively close to the first one. 2) Publishers Code: The following Promela code shows the implementation of the first considered connected vehicle: The above code corresponds to the first inner-loop of Fig. 3. Note that this process defines two internal parameters; temp1 and speed1. These two variables, which represents temperature and speed, are, respectively, initialized to 30 and 130, and will be sent to the broker through their corresponding channels. The scheduling of vehicle 1 actions is described in Fig. 5. We mention that in the Promela code of the second connected vehicle (which has not been shown in this paper), the temperature has been set to 45 and speed to 20.
D. SPIN Formal Verification of MQTT-CV After implementing MQTT-CV components using Promela language, we focus, in this subsection, on SPIN verification of our proposal. 1) MQTT-CV Simulation With SPIN: Fig. 7  represents an extract of a random MQTT-CV simulation performed using SPIN. As shown in this figure, the different processes interact by sending messages using communicating channels which are defined as integers. For example, the broker starts by receiving the message 3 in channel 1 from Subscriber 1 (1!3). This indicates that Subscriber 1 is requesting a subscription to both topics; temperature and vehicles' speed. The broker responds by sending message 1 through channel 6 to Subscriber 1. The interactions continue by sending data Vehicle 1 and Vehicle 2 to the broker, and then, from the broker to Subscriber 1 and Subscriber 2.
E. Formal Verification of Temporal Properties The Promela specification of MQTT-CV protocol described in the previous section allows only the simulation with SPIN of MQTT-CV behaviors and the verification of a part of its safety properties, for example those related to deadlock states. In this section, we focus on the specification and the verification of MQTT-CV liveness properties. Informally, a liveness property asserts that program execution eventually reaches some desirable states, which also means that system eventually will do something good, for example by producing desired outputs  [19]. In our case, to prove that our protocol behaves correctly, by allowing the broker to send only the required data by the infrastructures, we need to verify some liveness properties, like: r p1 : always when a broker receives a temperature t, where t ≥ 40 • C, this data will be sent to infrastructures.
So, in Promela, for each process, each message, and send/receive events, a flag is declared. These flags are updated together with each send/receive event, using a atomic statement to ensure the values assignment in one execution step. For example, in the following we present the corresponding Promela code of the process Broker, enriched with the flags. Send and receive flags indicate that the process is respectively sending or receiving messages. For example, the flags msg_speed, and msg_tmp refer respectively the last speed and temperature message sent. And the flags lf_broker, lf_v1, lf_inf 1, indicate the last process (in this case broker, vehicle1, and infrastructure1) sending or receiving data. These flags are update at each sending and receiving events. To verify the LTL properties p_1 -p_8 expressed informally above, we specify them with LTL and Promela as described in the following listing: We obtained the following results after their verification with SPIN: r p1 and p3 are verified, which confirms that the broker send the received data that meet the conditions of the specified filter.
VI. EXPERIMENTAL VALIDATION OF MQTT-CV To conduct our experiments and assess both MQTT and the proposed MQTT-CV solution, we have opted for Eclipse Mosquitto  [21]. In a nutshell, this tool, written in C, is a message broker that implements the MQTT protocol versions 3. 1 and 3. 1. 1. Actually, given its lightweight feature (i. e. , its lightweight technique of carrying out messaging using the publish/subscribe model), Mosquitto is also suitable for IoT messaging and low-power single-board devices (such as low-power sensors, mobile devices, cell phones, embedded microcontrollers, etc. ). Furthermore, Mosquitto, which is free, open-source, and available for both Linux and Windows platforms, provides a C library for implementing and launching MQTT publishers and subscribers through their respective mosquitto_pub and mosquitto_sub command lines.
During this whole working phase, the considered evaluation metrics (detailed below in Section VI-B) were continuously recorded at the level of both the broker and infrastructure. The goal is to evaluate the effect of the proposed solution on these two entities. Note that there is no difference in the vehicles' performance in both architectures; MQTT and MQTT-CV. In both cases, vehicles read and report the same data for fair comparison purposes. The amount of data sent by each vehicle is set to 727 178 items. Of course, vehicles report this data (to the broker) with a certain data rate of x messages/second. However, in order to be more accurate, rather than tracking and reporting the number of connected vehicles or their data rate (i. e. , number of published messages per second), we have measured the broker load in terms of received "publish" messages over one minute.
B. Validation Metrics The two main criteria we used for the evaluation of MQTT-CV and MQTT are the CPU and the RAM usage. r CPU usage: this criterion, which is expressed in per- centage, represents the processor load in both the broker and infrastructure machines. The goal is to compare our MQTT-CV approach with MQTT and measure their effect on the broker and infrastructure performances (advantages and disadvantages). To collect this first information (i. e. , CPU load), we have considered several Linux tools/commands such as the wellknown top, ps, and PowerShell Core (Get-Process, etc. ). r RAM usage: this evaluation metric measures the quantity of memory that has been consumed by both the broker and infrastructure entities during their working stages. We mention that this information has been also collected using the Linux tools mentioned above.
More in detail, to specify the interaction between its different components (vehicles, broker, and automotive infrastructures), we have modeled MQTT-CV using the UML sequence diagram. After that, we have (1) implemented MQTT-CV using Promela language, and (2) utilized SPIN to perform simulations that allow analyzing some iteration scenarios. Finally, using SPIN, we have verified that MQTT-CV satisfies the safety property related to deadlock states, and liveness properties that express temporal constraints on MQTT-CV behaviors. In more exact words, we have proven that the broker, vehicles, and automotive infrastructures behave correctly and that MQTT-CV will never enter a deadlock situation. Moreover, we proved also, that the broker ensures data filtering before their sent. As future works, we intend to improve MQTT-CV and make it able to handle more complex conditions that automotive infrastructures can express on proposed topics.
The yellow analog card     in Fig. 15 a  shows the signal conversion module for process controlling signal conditioning (PWM amplifier). The induction machine rotor position measurement is performed using incremental encoder with 10 bits resolution as shown by Fig. 15 d. The whole process as shown by Fig. 12  , including DFIG, DC motor, back-to-back converter, and control algorithm, has been simulated based on Matlab/Simulink software. Then, Embedded Coder has been used to generate a readable, compact and fast executable code for embedded processors and FPGA used in dSPACE hardware. This approach allows a rapid control prototyping significantly reducing the control strategy implementation for real-world applications. In the following, a stepby-step methodology is described in order to implement a DFIG-based WEC emulator on laboratory.
Grid-side converter results Grid-side converter control described by Fig. 6  has been implemented using dSPACE hardware/software. For this experimental validation, the grid voltage RMS value was equal to 30 V rms , the DC bus is controlled to maintain U * 0 = 10 0 V regardless of the load R L. The considered load is 2 kW resistance with a maximum DC voltage of U RL max = 220 V. The smoothing inductance is L = 5 mH and the DC bus capacitor is equal to C = 500 µF. The experimental setup scheme is given by Fig. 16. In this scheme, two grid phase-to-phase voltages U ab g and U bc g are measured in order to estimate the grid angle θ s. Moreover, two line currents i fa and i fb are measured in order to be controlled in such way that the line currents are sinusoidal and in-phase with the corresponding phase-to-neutral voltages (no reactive power).
Generator-side converter results The validation of the generator-side converter control has been performed based on the scheme given by Fig. 22. For this experiment, adjustable DC power supply has been used rather than the grid-side converter. A diode is used is series in order to protect the DC supply as this structure is irreversible. The DFIG should be operated only on sub-synchronous mode, i. e. M ≤ s , with s = 150 0 rpm is the synchronous speed. The control algorithm is implemented using dSPACE hardware/software. A picture of the experimental setup for generator-side converter control validation is given by Fig. 23. A Fluke power quality analyser is used to visualize the active and reactive powers flow on the DFIG stator. These two quantities are controlled thanks to the rotor-side converter.
Conclusion and future works This paper has dealt with key issues related to doubly-fed induction generators-based wind turbines, including system architecture, modeling and control objectives, and active/reactive powers transfer to the power grid. Power electronic converters and conventional transformers have been proven to be efficient to carry out tasks needed to interface this type of wind turbines to the power grid. The proposed digital control strategy has been successfully implemented on dSPACE board using Embedded Coder from Matlab/Simulink. Specifically, the control strategy has been implemented and experimentally validated for each subsystem, namely: grid-side converter, rotor-side converter, and grid-connection. In this context, a labscale experimental platform has been designed and realized.
The combination of neuromorphic visual sensors and spiking neural network offers a high efficient bio-inspired solution to real-world applications. However, processing event-based sequences still remain challenging because of the nature of their asynchronism and sparsity behavior. In this paper, a novel spiking convolutional recurrent neural network (SCRNN) architecture that takes advantage of both convolution operation and recurrent connectivity to maintain the spatial and temporal relations from event-based sequence data are presented. The use of recurrent architecture enables the network to have arbitrary length of sampling window allowing the network to exploit temporal correlations between event collections. Rather than standard ANN to SNN conversion techniques, the network utilizes supervised Spike Layer Error Reassignment (SLAYER) training mechanism that allows the network to adapt to neuromorphic (event-based) data directly.