dataesr/scientific-paragraphs-categorization huggingface dataset:
Moreover, many applications such as monitoring of earthquake or volcanic activity, require data transmission in (quasi) real time. An algorithm that is generic enough to handle different signal processing applications from different domains does not exist. Even machine learning algorithms have different architectures, depending on the application. Thus, the Mermaid cannot be configured with just a few parameters, it must be programmed with fully fledged applications. However, developing signal processing applications to be embedded in an instrument such as Mermaid is challenging for the following four reasons: 1. Embedded software programming requires specific technical skills, and it can be off-putting for less technically skilled scientists who will have to learn C language programming and know specialized technical details regarding the instrument, such as the operation of the real time operating system, micro-controller, sensors, etc.
2. The embedded applications must comply with the limited resources of the instrument. Otherwise they may not behave as expected, induce elevated costs of data transmission, or considerably reduce the instrument life time. 3. The embedded applications must be reliable, without software bugs, and efficient, with a minimum impact on the instrument resources. Any miss-conceived code may compromise the instrument that is not directly accessible when deployed in the oceans. Less technically skilled developers are more prone to writing miss-conceived code. 4. The embedded applications developed independently and installed on the same instrument must not interfere with each other. Whether the applications are installed alone or with other applications their behavior must not change. To overcome these challenges, we have developed a programming language dedicated to the Mermaid.
Models for Programming Scientists use models to understand the world, for example, with climate models. Engineers use models to develop new systems (i. e. , a bridge, a computer program). These models are specific to a domain of expertise, for example, electronic engineers use models of resistances or transistors. The models are assembled together to develop a system, for example, an electronic circuit. A language, graphical or textual, which allows for editing the models, is usually called a Domain Specific Language (DSL)  [15]. The MeLa language is a DSL dedicated to the development of signal processing algorithms for the Mermaid floats. Models can be used in several ways in order to respond to the challenges that are introduced in the first section. First, models allow for us to represent systems at several levels of abstraction.
In software engineering assembly instructions are low-level models, whereas functions or tasks of an operating system are models with a high-level of abstraction. The MeLa language gains in abstraction with models that are dedicated to the development of applications for the instrument. Instead of programming applications with tasks, which need an expert in embedded software, the MeLa language offers models called acquisition modes. Using these models, the developer does not have to manage the execution priority of tasks, or the synchronization of execution with other tasks. Instead, developing an application with an acquisition mode only requires that the user defines the input sensor and the sampling frequency. This high level of abstraction allows for developers that are not embedded software experts to write applications for the instrument (challenge 1).
Third, models are used to generate the specific embedded software specific code to program the instrument. The code generation process is managed by a tool that is integrated in the language, such as a compiler. The transformation rules to generate the code are defined by embedded software experts; this ensures having a reliable and efficient code (challenge 3). For example, the acquisition modes generate several tasks, with their synchronization mechanism and execution priority. The embedded software code would not be reliable and efficient if directly written by a non-expert. It is also possible to generate several specific codes to program different platforms. In our case, we also generate code to execute the applications on a personal computer, it allows for scientists to settle the applications and verify that they behave as expected.
Finally, models allow for composing (i. e. , combine) applications that have been developed independently (challenge 4). The composition of applications consists mostly of verifying that applications are compatible in terms of both used computational resources (e. g. , they cannot use more resources than what is available) and sensors (e. g. , they cannot share a sensor if their configurations on this sensor differ). The concurrent execution of applications is also managed by the operating system at the time of execution time. Figure  1  illustrates how models are used in MeLa: 1. Scientists write applications in MeLa, which avoids embedded software concerns. The applications written in a text file are transformed into models (implemented as Java objects) with a parser. 2. The analysis verifies that the limits of the floats are not exceeded and the results are returned to developers allowing them identify problems and correct them.
Description of MeLa The MeLa language is both imperative and declarative. The imperative part of the language allows for writing the content of the algorithms with sequences of instructions, conditions, and loops. The declarative part allows for declaring the depth and duration of the float dives, when to execute an application, and which sensor an application has to use. The MeLa language is implemented with ANTLR  [17] , a DSL that is dedicated to the creation of other languages. The models behind MeLa are written in Java, an object-oriented programming language. The code to program the instrument generated from the models is in C language. An example of an application written with MeLa is given in Figure  2. This is a very simplified version of a seismic detection application. The mission configuration part (lines 1-4) allows for the developer to define the depth and duration of a dive.
Inside the sequences of instructions, the developer writes the algorithm with variables and functions. The variables must be first declared inside each acquisition mode in a section, called Variables (lines  [20] [21] [22] [23] [24]. The data types that are currently available to declare a variable are given in Table  A1. The functions are called inside the sequences of instruction (lines 28, 29, 37 and 40 of Table  A2 ). A list of functions currently available is given in Table  A2. Many of them have been selected from the CMSIS DSP library ( https://www. keil. com/pack/doc/CMSIS/DSP/html/index. html). The functions can be organized using statements that are commonly found in imperative programming languages, such as if conditions and for loops. A particular aspect of the if statements in MeLa is that each branch requires a probability to be given for its occurrence (e.
Both electronic boards are programmed with C languagel which allows writing software with efficient execution time and low memory usage. Both have a Real Time Operating System (RTOS) allowing them to execute several tasks concurrently. The pilot board software can be configured with several parameters, such as the dive duration, depth, and other ones more technical, such as the time interval between each depth correction. The acquisition board has access to the sensors and can be programmed by scientists with MeLa, which generates C code. Both of the boards can communicate with each other, for example, the acquisition board can ask to the pilot board for the ascent of the float.
Overview The applications written in MeLa are transformed in C code that is suitable to program the Mermaid floats. This process is called code generation and it is equivalent to a compiler, but it generates C code instead of the binary file used to program the microcontroller. The mapping between the MeLa code and the generated code is illustrated in Figure  5. A file to configure the pilot board is generated from the mission configuration part of the MeLa code. The rest of the MeLa code is used to generate the C code to program the acquisition board. The coordinator is mapped to a task containing a state machine (i. e. , a model of computation)  [18]  that manages the execution of acquisition modes and the messages exchanged with the pilot board. The acquisition modes are converted to processing tasks that contain the sequences of instructions and sensor tasks handling the data from sensors (one sensor task can feed several processing tasks).
Benefits of MeLa for Embedded Software Programming In MeLa, the functions accept different data types. For example, the max() function that searches the maximum value and index in an array accept integer and floating point arrays. On the contrary, the C language requires specific functions for each data type, for example, maxArrayFloat() and maxArrayInt(). In the MeLa library, the functions are defined by their MeLa name, their parameters types, and their C name. Several functions can have the same MeLa name, but different C names with different parameters types. When a function is called from the MeLa language, the parameter types are used to choose the function with the appropriate C name. For example, if the MeLa code is max(a) with a an array of integers, the corresponding function is the one that accepts arrays of integers and have the C name maxArrayInt(), if a is an array of floats the corresponding function is the one with the C name maxArrayFloat().
This mechanism is also called type inference, it makes programs easier to read and write by reducing the language verbosity  [20]. The verbosity is also reduced for variable declarations. A variable declared in MeLa can have a much more verbose C equivalent. For example, declaring a StaLta variable in MeLa requires only one line, StaLtaFloat stalta  (5, 15, 10) , but declaring it in C requires three lines, because it corresponds to an array, a circular buffer structure that contains the array, and a stalta structure that contains the circular buffer: extram float32_t stalta_cbuff_data  [25] ; circular_buffer_f32_t stalta_cbuff = {stalta_cbuff_data, 25, 0, 0, true}; stalta_f32_t stalta = {&stalta_cbuff, 5, 15, 10, 0, 0}; The circular buffer structure contains the pointer to the array of data, the length of the array, the index of the begin and end of the buffer, and a boolean indicating if the buffer is empty or not.
An improper initialization or usage of these variables could lead to undefined behavior. In MeLa, these are automatically initialized and they are hidden to the developer such that it prevents an improper usage (encapsulation principle). Additionally, the notion of pointer does not exist in MeLa, avoiding errors of writing to unknown memory addresses. For example, forgetting the & operator when defining the stalta structure would break the software. MeLa also hides the mapping of variables that can be stored into the microcontroller SRAM memory (128 kB) or an external SRAM memory that is in a separate chip (8 MB). In the generated C code, each array is mapped to the external memory that has more storage capacity, but small variables are mapped to the internal memory that is faster. Thus, writing an application with MeLa allows for programmers that are not expert in embedded software programming to write reliable and efficient applications (challenge 1 and 3).
It is computed from the mission configuration and the probabilities defined in an application (only probabilities leading to a function that trigger the ascent of the float are used). For example, if the maximum duration of the parking stage is 10 days, and the probability of the ascent is two per week, the λ parameter is equal to 10 * 2/7 = 2. 86. The probability to have zero ascent request is: p(0) = e -λ (2) Addittionally, the probability to have at least one ascent request is: p(k > 0) = 1 -e -λ (3) The mean parking duration, which is also the mean duration before the first ascent request, corresponds to the mean interval of time between each ascent request (i. e. , the invert of the probability defined in the MeLa language) multiplied by the probability to have at least one ascent request during the default parking duration.
Developing with MeLa Here, we describe a workflow to develop applications with the MeLa language. Figure  7  illustrates the workflow. The presented workflow allows for verifying that the applications do not exceed the limits of the instrument during the development process, before having a functional application. The programming of the instrument is only done once, at the very end. The first step is to define the duration and depth of a dive, the acquisition mode, and the coordinator. For each application, the developer has to choose between a continuous or a short acquisition mode. Continuous acquisition modes are more adapted to detect sporadic signals, like those that are emitted by earthquakes, because they process data without stopping. On the other hand, short acquisition modes are more adapted to monitor events that evolve slowly, like temperature or wind, because they have a reduced impact on the battery lifetime of the floats, since the sensor is switched off between each data packet.
The probabilities do not have to be exact, but they should be conservative to obtain a safe estimation of the battery life time and cost of satellite transmission. If the limits of the instrument are not exceeded, the application can be composed with another application to verify that they will be both able to execute on the same instrument. The dive depth and maximum duration must be the same and, if the same sensor is used at the same time by two applications, the configuration of the sensor must be the same (i. e. , sampling frequency). If they are different, an error is raised in order to force the developers to find a compromise. Once they are composed, it is necessary to again verify that the limits of the instrument are not exceeded. Most of the mechanisms used to execute the acquisition modes concurrently are managed by the embedded software code; this includes the scheduling of tasks and the exchange of data from sensors to processing tasks.
The applications can be executed on a laptop (i. e. , simulation). Simulation is complementary to static analysis, it focuses on the behavior of the applications instead of the instrument limitations. It allows for a developer to correctly set the parameters of an application without having to program a real instrument, for example, she can verify that an application records as many earthquakes as expected and adjust parameters to improve the performances. Currently, the simulation only handles the processing of data, it does not fully simulate the behavior of the instrument. The simulation code is generated from the MeLa code and it uses the same library of functions as the one used for the instrument. Most of the function implementations are exactly the same for the simulation and the instrument.
It ensures that simulation gives results that are close to those that will be obtained on a float. Some differences exist, because the DSP of the Cortex M4 is not available in a personal laptop. Emulating the float processor would allow to be even closer to the results of the instrument. During the simulation process, the probability values can also be refined. The code for the instrument is generated from the application. It can be compiled without any modification. Because verification of the limits of the instrument and simulation have been done during the development process, thanks to the MeLa capabilities, the applications can be deployed without requiring additional tests.
Implementation with MeLa The implementation with MeLa requires functions, like STA/LTA, triggers, wavelets transforms, and cumulative distributions. Implementing a specialized algorithm may require the involvement of an embedded software expert to write specific functions in C language in order to add them in the MeLa library. The MeLa language does not offer the full flexibility of a generic programming language in order to ensure the reliability and efficiency of the applications, and to permit the analysis of applications. However, the current library of functions (Table  A2 ) is already generic enough to be of use in many different applications. The MeLa code of the seismic application is accessible on Github, see the Supplementary Materials section. Once the seismic application has been implemented with the MeLa language, the analysis tool allows for verifying that the limits of the instrument are not exceeded.
Evaluation of the Algorithm The algorithm has been tested on a laptop with the simulation code that was generated from the MeLa language. To feed the algorithm, we have used 10 months of continuous recording from a Mermaid recovered in August 2019. We compared the results of the simulation with the events sent through satellite by the Mermaid before its recovery. All 12 earthquakes that were detected by the Mermaid are also detected by the algorithm implemented with the MeLa language. Three additional non seismic events have also been detected with the MeLa language, indicating slight differences in the implementations. Nevertheless, we conclude that the MeLa language can be used to implement advanced algorithms.
Implementation with MeLa The algorithm has been implemented with the MeLa language. The code is accessible on Github, see the Supplementary Materials section. For this application, the analysis estimates a processor usage of 2 pct. The autonomy of the float is found to be 4. 6 years; this is less than the seismic detection application because the power consumption of the sensor is higher, due to a higher sampling frequency. The estimated amount of data transmitted each month is only 14 kB. This is much less than the seismic application, because only timestamps are sent through satellite communication. However, the probability to record a blue whales D-call is estimated to be much higher with five records per hour. If 20 s of sounds where recorded for each detection, the amount of data to transmit each month would be 56,047 kB.
Evaluation Protocol We used the data from the DCLDE 2015 challenge that has been recorded with High-frequency Acoustic Recordings Packages deployed off the southern and central coast of California. The data spans all four seasons over the 2009-2013 period (See the full dataset documentation at http://cetus. ucsd. edu/dclde/datasetDocumentation. html. ) but we used a 50h-long subset that has been annotated during a recent collaborative campaign  [27]. The annotators have identified a total of 916 D-calls, plus 101 40 Hz annotated sound events. The high-frequency data have been decimated to 200 Hz bandwidth to feed the MeLa algorithm. Furthermore, we used as performance metrics the Precision (i. e. total number of detected calls) and Recall (i. e. total number of annotated calls), while using the python library sed_eval (https: //tut-arg.
github. io/sed_eval/sound_event. html)  [28]  for their implementation. As we are interested in soft detection of sound events, i. e. without the estimation of D-calls duration, we only used the onset time in our evaluation metrics with a large time collar of 6s from the reference time onset, within which the estimated onset needs to fit in, so that a detection is counted as being correct. The detection performance of the MeLa algorithm was compared to a custom Convolutional Neural Network (CNN)-based model. CNNs are increasingly used in classification applications that involve acoustics  [29] [30] [31]  and have recently revealed promising performance for marine mammal detection  [32] [33] [34] [35]. We used the ResNet architecture, which is a deep neural network using skip connections or short-cuts to jump over some layers  [36].
Only 18 layers were stacked to avoid overfitting, as the training set is not very large. It was trained from scratch to handle the size of the mel-spectrogram  [37]  images (110 × 90 instead of the initial shape of 224 × 224). Each image is generated from 5s audio excerpts sequentially taken from the recordings. Our implemented version is based on existing open source codes (https://github. com/keras-team/keras-contrib/blob/master/ keras_contrib/applications/resnet. py).
• The GPU used in the evaluation has a power consumption of 116 Watts, which would consume the 4 kWatts. h of energy that is available on the MERMAID float just after a day and a half. If the MeLa algorithm is used on the GPU to process one year of data, it will consume 46 W. h instead of 39 kW. h for the CNN; this is equivalent to the energy that is required by an electric car to travel, respectively, 300 m and 260 km. The algorithms that were developed with MeLa are suited to program Mermaid floats, but can also be used to process large amounts of data with low execution time and energy consumption, which also mean less environmental impact.
Discussion and Conclusions We have developed a programming language, called MeLa, dedicated to the Mermaid instrument, a multidisciplinary float that can monitor the oceanic environment with multiple sensors. The language is a DSL created using a Model Driven Engineering (MDE) approach  [38] [39] [40]. The language allows for scientists that are not specialists of embedded systems to write reliable and efficient applications of the Mermaid instrument. It uses models to verify that the applications comply with the limited resources of the instrument and to compose (i. e. , combine) applications developed independently, but to deploy in a same instrument. The code to execute the applications on a personal computer and the code for the instrument are generated from models using rules that were defined by embedded software experts.
Generic programming languages, such as C, Java or Python, do not have functionalities, such as those offered by MeLa. When compared to MeLa, writing applications with those languages increases the risk of making errors that may compromise the integrity of the instrument, even for an embedded software expert. A software library or a framework, such as Arduino (https://www. arduino. cc/), can reduce the risks with specialized functions that encapsulate low-level concerns (e. g. , a function that read a sensor) and by defining a default architecture for the code (e. g. , with a setup and a loop function for Arduino). It helps the developers, but the code is still written with a generic programming language for which the risk of errors is higher. Furthermore, those languages do not incorporate analysis capabilities that are included in MeLa, because it requires platform-specific information (e.
g. , energy consumption, execution time) that are not compatible with their generic aspect. Analysis tools exist, but also need platform-specific information, for example, the processor speed or the time that is required to read a sensor. There exists a few DSLs that are comparable to MeLa, such as CPAL  [41] , MAUVE  [42] , or Mbeddr  [43]. However they have mostly been designed for embedded software developers. They offer high-level programming abstractions but are still too close to embedded software concerns; for example, in CPAL and MeLa the processor usage is computed from execution times that must be manually inserted into the code, whereas, for MeLa, this information is hidden in the library of functions. Moreover, they do not include a composition tool for combining several applications.