dataesr/scientific-paragraphs-categorization huggingface dataset:
This reveals the effect of the learning algorithm. It has analyzed which channels are more occupied and more disturbed by other users of the band (emulated here by the traffic generator). The topright green and therefore the bottom-right blue data explain such a choice. Channel #4 has known 16 successes (over 17), so a rate of 94%. We remind that successes mean that the IoT device received on that channel 16 ACK from the gateway after transmitting 17 times in this channel. So just one "exchange" was lost, either in UL or in DL, due to a collision with some interfering signal in the channel. We can see on the opposite that no success has been obtained for channel #0, so it has a 0% rate. UCB data, in bottom-left green part, are harder to follow, as UCB 1 indexes rapidly converge to very close values, but at each transmission, the IoT device chooses channel with highest UCB 1 index, as in (6).
Device side For this experiment, we implement an IoT device by using a Pycom card 4 composed of an Expansion Board and a LoPy 4 module which can support LoRa wireless connectivity, as shown on Fig. 7. The Pycom card is programmed in the MicroPython language. The frequency channels used in the experiments are those authorized in France, the country of experimentation. The IoTligent proposal is agnostic to K, the number of channels in the standard, and thus, it can be used in any country. We had to make several modifications in the LoRa library written in C and the ESP32 chip library written in MicroPython. By default indeed, the Pycom configuration for Europe is to use only 3 channels in a random access manner: 868. 1, 868. 3, and 868. 5 MHz (with a duty cycle of 1%). So, for measurement 3 of Section 7 with more channels involved, we added a custom configuration region in the LoRa library with 16 channels, covering the band from 865.
Network side We have access to the LNS provided by Acklio Company. The LNS sends the received messages to an AS which is a Linux server, running in the cloud. The AS is running a Python program that enables to display data and metadata (i. e. , frequency, time of reception, etc. ). This programs also contains instructions to send an ACK to the device, using in DL the same frequency used by the IoT device at UL. 6 Measurement 2: IoTligent operation in a real LoRaWAN network.
Device side configuration We use the LORAWAN mode at 868 MHz with an over-theair-activation (OTAA) using app_EUI and app_key keys, as shown in the following MicroPython code for the Pycom device: The transmit channel frequency is then chosen in a set of K channels, which is set here at K = 3 in this experiment. We use standard Europe UL channels with the following frequency table (in Hz): The IoTligent device infinite while is started, running the algorithm presented in the Section 3. 2 and  [5] , in order to choose which frequency to be selected at each iteration before 4 Pycom documentation: https://GitHub. com/PyCom/PyCom-libraries Fig. 7  Pycom module composed of a LoPy4 and an Expansion Board Fig. 8  Indoor gateway used for measurement 3 experiments on the left side and packaged Pycom device on the right side executing a send operation.
Network sideapplication server (AS) The AS runs a Python program that receives data from the LNS, as well as LoRa metadata with all parameters of the LoRaWAN transmission (frequency, SF, BW, time of arrival, etc. ). This program also sends an ACK message to the device in DL. First, an acknowledgement attempt is sent by default at the same frequency than the message transmitted by the device it answers to. Then we block any other retransmission.
Learning algorithm in Pycom device The learning algorithms used in IoTligent are (any) bandit algorithms, such as those first used for cognitive radio dynamic spectrum access in  [5] , and implemented in the exhaustive open-source SMPyBandits Python library  [17]. We take here the example of UCB 1 algorithm, as presented above. We have chosen this algorithm as it is known to be efficient and to converge quickly and also for its ease of implementation. The only data necessary to be stored for the UCB From the point of view of the learning algorithm, a success occurs when an IoTligent device receives an ACK from the IoT network (as explained above), which means that the currently used frequency channel suffered no collision in both UL and DL. Otherwise, a failure occurred. The update of the selected channel empirical means X k is reconstructed easily from the number of activations and the previously stored X k value.
Data Set To select AKARI sources without HSC counterparts securely and investigate their physical properties, we compile multi-wavelength data. AKARI NEP-W was observed by many facilities, and thus we have abundant dataset from ultraviolet (UV) to radio (see e. g. ,  Kim et al. 2012; Oi et al. 2020 , and references therein for a full description). We particularly utilized the following data sets in addition to the AKARI NEP-W catalog  (Kim et al. 2012 ) and HSC catalog  (Oi et al. 2020)  that are summarized in Table  1. The area coverage of each dataset is summarized in Figure  1. We used NIR data provided by  Jeon et al. (2014)  who conducted a deep imaging with J-and H-bands taken by FLoridA Multi-object ImagingNear-ir Grism Observational Spectrometer  (FLAMINGOS: Elston et al. 2006)  on the Kitt Peak National Observatory (KPNO) 2.
The AKARI NEP-W consists of 4-7 exposures by the HSC with a FoV of 1. 5 • in diameter through dithering observations. Therefore, objects around the edges of each exposure frame would be missed from the HSC catalog created by the HSC pipeline  (Bosch et al. 2018)  although they exist on the HSC image (see  Oi et al. 2020, in details). Nevertheless, we should note that the visual inspection might be highly dependent on the classifier. The number of objects selected in this work may have an uncertainty. Hence, the population census results such as number counts and volume density of AKARI sources without HSC counterparts should be addressed in future work, and we focus on an overview of their physical properties in this work. For those AKARI sources without HSC counterparts, we compiled a multi-wavelength dataset up to 500 µm.
Since the optically-dark galaxies tend to be located at z > 2 (e. g. ,  Franco et al. 2018; Yamaguchi et al. 2019; Williams et al. 2019; Wang et al. 2019) , we optimized the range of z photo , which reduces the computing time. Aside from being an excellent SED-fitting tool, CIGALE is known to be a good estimator of z photo , since it utilizes a large number of models covering the whole SED including the MIR-FIR regime. For example, Ma lek et al. (  2014 ) calculated z photo for AKARI sources in the AKARI Deep Field South. They demonstrated that accuracy of the z photo by using the normalized median absolute deviation defined as σ ∆z/(1+zspec) = 1. 48 × median(|∆z|/(1+z spec )) in the same manner as  Ilbert et al. (2006). The resultant σ ∆z/(1+zspec) is 0. 056, lower than what obtained by a software using mainly optical to NIR data  (Ilbert et al.
AGN fraction Figure  9  shows the AGN fraction (f AGN ), L IR (AGN) / L IR. The mean AGN fraction of AKARI sources with and without HSC counterparts is 0. 06 and 0. 22, respectively, indicating our sample tends to harbor AGNs. We also find that f AGN of objects with L18W and SPIRE detection is 0. 16, smaller than average of all objects in our sample. On the other hand, given the overlapped redshift range (0. 8 < z < 2. 0), the mean f AGN of AKARI sources with and without HSC counterparts is 0. 12 and 0. 23, respectively. This could indicate that one of the reasons for the difference in f AGN between the two samples may be the difference in sample selection and redshift. Other possible uncertainties caused by a limited number of MIR data are discussed in Section 4. 6. 2.
(2020)  in an overlapped redshift range (0. 8 < z < 2. 0), the mean SFR of AKARI with and without HSC counterparts is 319 and 207 M yr -1 , respectively. This indicates that the observed difference in SFR may be due to the redshift difference. We showed that our estimate of z photo is expected to be secure in some ways (see Sections 2. 3 and 4. 3), but these arguments are indirect. Although  Ma lek et al. (2014)  demonstrated the accuracy of z photo based on CIGALE for an AKARI sample at z spec < 0. 25, they utilized optical data points for z photo estimation, and the redshift range for the sample differs from our sample. We need to investigate how the lack of optical data affects the accuracy of z photo for AKARI objects at z > 0. 8. Hence, we estimate z photo of AKARI objects with z spec in the band-merged catalog (S.
SUMMARY In this paper, we report the physical properties of AKARI sources that do not have optical counterparts in the HSC/Subaru catalog  (Oi et al. 2020). The parent sample is drawn from IR sources in the AKARI NEP-W field  (Kim et al. 2012). By using AKARI, HSC, Gaia, FLAMINGOS/KPNO and IRAC/Spitzer catalogs and images, we select 583 objects as opticallydark IR sources without HSC counterparts. Thanks to the continuous filters of AKARI in the MIR and multiwavelength data up to the FIR (SPIRE/Herschel), we successfully pin down their optical-FIR SEDs, even if flux densities in some bands are upper limits. We com-pare the physical properties derived by the CIGALE SED fitting between AKARI objects without HSC counterparts and mid-IR selected AKARI objects with HSC counterparts  (Wang et al.
ACKNOWLEDGMENTS We gratefully acknowledge the anonymous referee for a careful reading of the manuscript and very helpful comments. This research is based on observations with AKARI, a  JAXA  project with the participation of  ESA. This work has made use of data from the  European Space Agency (ESA) mission Gaia  (https://www. cosmos. esa. int/gaia),processed by the Gaia Data Processing and Analysis Consortium (DPAC, https://www. cosmos. esa. int/web/gaia/dpac/consortium). Funding for the DPAC has been provided by national institutions, in particular the institutions participating in the Gaia Multilateral Agreement. This work is based on observations made with the  Spitzer Space Telescope , which is operated by the  Jet Propulsion Laboratory, California Institute of Technology  under a contract with  NASA.
Thus, they become stuck, unable to move forward by adding more functionalities to their existing systems, and they are limited with the experiments they can do to target their objectives. The heterogeneity that characterizes the industrial system building blocks and applications justifies the interest of the community in research related to the field of system interoperability, i. e. , most systems and business applications are not initially developed to work together. Applications to be used for the M&S of the system could have been developed on different computer architectures, incompatible operating systems (Windows, Linux, macOS), or using different execution platforms (. NET, Java). Moreover, some companies are still using legacy systems (systems that have become obsolete or outdated) that are hard to access, causing security problems, provoking environmental issues, and, in many cases, preventing the collaboration with other external systems.
JaamSim JaamSim is a free Java-based open-source simulation package developed by an Australian Engineering company named Ausenco. The main feature that differentiates JaamSim from other off-the-shelf commercial DESs is that users can design and make their own high-level object palettes  [10]. When JaamSim is launched, a graphical interface appears. Users can use this graphical interface to add entities and create the simulation model or write/edit a configuration file (. cfg) in which all entities/objects can be added and configured. Some users might prefer the graphical interface to drag and drop their entities and configure them on GUI (graphical user interface). Others, especially programmers, would find it faster and easier to create/edit the configuration file (. cfg). This software is used in this research, instead of other simulators, due to its transparency, reliability, capability, and, most importantly, because it is an open-source software that can be configured to interact with external third-party applications.
According to this architecture, each layer has its own functionalities. The Eclipse base provides a powerful and modular IDE, allowing implementation on the upper layers. The Papyrus editor allows developers to customize UML profiles. The Moka layer is the execution component of Papyrus; it can also be expanded to execute customized UML profiles. The UML diagram, designed with the Papyrus graphical editor, is sent to the Moka run-time module to be executed (Figure  5 ). Moka is compatible with UML and foundational UML (fUML) standards. fUML is a subset of the UML language that has standardized execution semantics maintained by the object management group (OMG). An fUML model is, therefore, executed as a programming source code (e. g. , C, Java). A standardized textual syntax for fUML, called "action language for fUML" (Alf), also exists.
This syntax is particularly used to define more detailed behaviors for a finer granularity simulation. According to this architecture, each layer has its own functionalities. The Eclipse base provides a powerful and modular IDE, allowing implementation on the upper layers. The Papyrus editor allows developers to customize UML profiles. The Moka layer is the execution component of Papyrus; it can also be expanded to execute customized UML profiles. The UML diagram, designed with the Papyrus graphical editor, is sent to the Moka run-time module to be executed (Figure  5 ). Moka is compatible with UML and foundational UML (fUML) standards. fUML is a subset of the UML language that has standardized execution semantics maintained by the object management group (OMG). An fUML model is, therefore, executed as a programming source code (e.
g. , C, Java). A standardized textual syntax for fUML, called "action language for fUML" (Alf), also exists. This syntax is particularly used to define more detailed behaviors for a finer granularity simulation. fUML is a bridge language that allows a translation from graphical to executable code, executed by the Moka run-time (Figure  5 ). The Moka engine uses the concepts of "Visitor" and "Advice" (Figure  6 ). A Visitor is a Moka object, automaticaly instantiated for each element of the UML diagram (e. g. , start points, stop points, transitions, steps). It can be associated with one or more Advice. An Andvice is a Moka object that allow to add behaviors during the execution time. During the execution phase, the engine collects every advice and visitor contained in the model (Figure  6 ).
The engine terminates the Advice by calling the canFinish() method. If a task termination is accepted, the finish() method of the Advice is called, and the next UML element is processed by the execution engine. Specific behaviors are added to the above methods. Implementation of HLA, FMI standards, and interactions with the external risk management tool is declared and managed in these methods. The main idea of this chapter is to add and develop a new Moka extension for each standard and fUML is a bridge language that allows a translation from graphical to executable code, executed by the Moka run-time (Figure  5 ). The Moka engine uses the concepts of "Visitor" and "Advice" (Figure  6 ). A Visitor is a Moka object, automaticaly instantiated for each element of the UML diagram (e. g. , start points, stop points, transitions, steps).
It can be associated with one or more Advice. An Andvice is a Moka object that allow to add behaviors during the execution time. According to this architecture, each layer has its own functionalities. The Eclipse base provides a powerful and modular IDE, allowing implementation on the upper layers. The Papyrus editor allows developers to customize UML profiles. The Moka layer is the execution component of Papyrus; it can also be expanded to execute customized UML profiles. The UML diagram, designed with the Papyrus graphical editor, is sent to the Moka run-time module to be executed (Figure  5 ). Moka is compatible with UML and foundational UML (fUML) standards. fUML is a subset of the UML language that has standardized execution semantics maintained by the object management group (OMG). An fUML model is, therefore, executed as a programming source code (e.
• Risk monitoring for studying the impact of treatment on the system. The risk management tool is a module designed for including a risk treatment over the production system's simulation. This separation allows engineers to model the system on a tool and define rules that will impact the system in a separate module  [34]. Risk occurrence and severity must be observed or calculated by experts, and then described to the system through equations and algorithms. The objective is to implement a connected adhoc system communicating with the simulation engine (Moka) during simulation execution. This system can insert assigned hazards as tasks of the main Papyrus model by expanding or reducing the simulated duration. As presented in Figure  7 , the risk management tool is a set of tasks connected to the main Papyrus model, as well as to an SQLite database containing a list of risks associated with impacts (in terms of time).
This system can insert assigned hazards as tasks of the main Papyrus model by expanding or reducing the simulated duration. As presented in Figure  7 , the risk management tool is a set of tasks connected to the main Papyrus model, as well as to an SQLite database containing a list of risks associated with impacts (in terms of time). Links between the Papyrus model and risk management tool are made using the ID reference system. The link between Papyrus and the risk management tool is realized by adding a UML profile over the UML diagram in order to add an ID to the tasks of the Papyrus model (Tasks 1 and 3 in Figure  7 ). The Moka extension is also customized to execute the risk management module on every The link between Papyrus and the risk management tool is realized by adding a UML profile over the UML diagram in order to add an ID to the tasks of the Papyrus model (Tasks 1 and 3 in Figure  7 ).
The Moka extension is also customized to execute the risk management module on every task that extends the custom UML profile. Tasks of the risk management tool contain equations based on statistical laws provided by the company's engineers. Randomized values are also added in order to generate hazards in the Papyrus model. During the execution process, the behavior described in Figure  8  can be observed. When Papyrus executes a task, it will be associated with a native execution duration (normal processing time of a machine in the production system). This duration is extended or reduced by its associated task that exists in the risk management module. This associated task is developed by engineers in order to describe the probabilities of issues. Risk setup is done with an SQL database that allows users to store risk laws and impacts that are executed during the simulation by the risk management module.
This duration is extended or reduced by its associated task that exists in the risk management module. This associated task is developed by engineers in order to describe the probabilities of issues. Risk setup is done with an SQL database that allows users to store risk laws and impacts that are executed during the simulation by the risk management module. Each task is represented by a unique ID. In our example, Figure  9  and Equation (1) illustrate delivery time simulation for the shop floor supply. For instance, Task1 (delivery) is represented by Risk1 (potential delivery issue) (Figure  8 ). The equation representing potential late delivery for the product of Task1 is provided by the manufacturing expert. Equation (1) represents a law of temporal degradation in the simulation regarding late delivery.
As it is an open-source software, it was possible to edit its Java code and add new modules in order to make it an HLA-compatible DES. As described in Figure  10 , this work added a method to all JaamSim objects that reads all attributes assigned to JaamSim objects; if an entity has an attribute called "waitRTIOrder", it will be considered as an HLA entity able to collaborate with external systems and exchange data. This entity then asks for time advancement from RTI; in such cases, the federate updates the attributes and asks for time advancement. After this step, it will wait for the RTI reply in order to advance in time and process to the next entity. If no "waitRTIOrder" attribute exists, the next component will be processed. This process is repeated until the end of the simulation. JaamSim objects; if an entity has an attribute called "waitRTIOrder", it will be considered as an HLA entity able to collaborate with external systems and exchange data.
FMI Implementation The eclipse modeling framework (EMF) generator allows us to create one or several UML profiles attachable to the model. This profile contains a stereotype with parameters (Figure  13 ) that will be filled by users and is accessible by our custom extensions. From the list of AdviceFactories, a new advice associated with each behavior is added for the needs of Papyrus: one for HLA-JaamSim, one for the delivery process, and one for the risk management module. Each Advice must declare canStart() and canStop() functions, which will be executed by the Moka engine during the simulation. These functions are used to create entry points to HLA and FMI standards. In these functions will be interactions with a FederatesManager, who will use RTI functions to communicate with JaamSim through HLA.
• The terminate() function ends the simulation. This work has developed a simple FMU for a cosimulation model with the JavaFMI library (Figure  14 ). The EMF generator contained in Papyrus enables the generation of source code for a Moka extension. This code is inherited from the Papyrus execution engine class. Based on it, one is able to override functions of the engine in order to modify its behaviors: It is through this addition of advice that functions can be added to Papyrus on actions designated by the user. By applying the stereotype on some UML tasks, the user will add custom advice and thus, modify the behavior of Moka during the model execution. From the list of AdviceFactories, a new advice associated with each behavior is added for the needs of Papyrus: one for HLA-JaamSim, one for the delivery process, and one for the risk management module.
Global Orchestration Figure  15  introduces the process-oriented model of DMSF using BPMN (business process model and notation), a business process modeling standard, and a flowcharting technique that provides a graphical notation to define and describe business processes. Papyrus and JaamSim are configured as two separate federates running on different machines/workstations and having different IP addresses. The communication between those two machines is based on the publish/subscribe mechanism of the HLA standard on a port number defined in the code when the federation is created/joined. The firewall might block the communication on the aforementioned port number, so the inbound/outbound rules should be configured to allow the communication on the RTI-defined port. The objects/attributes and interactions/parameters are needed to properly control, configure, and then run the company's simulation model on JaamSim.