# MeLa: A Programming Language for a New Multidisciplinary Oceanographic Float
## 2 A Programming Language Based on Models
### 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  
Figure 1: Models used in MeLa. 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. The coordinator (lines 7-9) allows her to define when to execute an algorithm during the descent, parking or ascent steps of the dive. In this example, she has only chosen to run the Seismic algorithm during the parking stage, because the ascent and descent are too noisy for seismic monitoring. The algorithmic part of an application is contained in what we called acquisition modes. The developer has to define the input of the acquisition mode. There are two parameters for the input, 1) the sensor with its sampling frequency and 2) the array name and size in which the sensor puts the samples. In the example, the sensor is the low frequency hydrophone with a sampling frequency of 40 Hz (line 16). The samples are put in an array, called x, containing 40 samples (line 17). The samples are processed when the array is fully filled by the sensor. There are two kinds of acquisition modes, the ContinuousAcqMode, for which packets of data are continuously recovered, in a streamed way, and the ShortAcqMode for which single packet of data is recovered. The latter can be periodically executed with a time interval defined in the coordinator (e.g., ParkAcqModes: Temperature every 1 h). Figure 3 provides a comparison between the two  
Figure 2: Application example. The functions ‘seisDetection’ and ‘seisDiscrimination’ have been left to keep the example short, they do not exist in the language, the real algorithm for seismic detection is presented in Section 4.1.  
acquisition modes. Choosing an acquisition mode mainly depends on what is monitored and it has implications for the resources that are used by the applications. Details about how to choose an acquisition mode are given in Section 3. The algorithmic part inside a continuous acquisition mode is executed periodically, each time that the sensor sends a packet of data. During the acquisition, it is necessary to ensure that all of the packets of data are processed, in order to guarantee the integrity of acoustic signals. On the other side, it may be necessary to suspend the acquisition to temporary execute an algorithm that has a long execution time. The MeLa language separates the content of acquisition modes in two kinds of sequences of instructions in order to help the developer to think about these important aspects:  
1. The RealTimeSequence (lines 27-34) is associated with real time constraints to guarantee that all the data from the sensor are processed. The execution time of the sequence must be shorter than the time between each packet of data, and other applications cannot delay the processing of a block of data until the point of missing a packet of data. The method used in order to verify these constraints is a scheduling analysis and it is described in Section 2.5.1. 2. The ProcessingSequence (lines 36-42) does not have real time constraints. Using this sequence means that the developer accepts to miss some data from the sensor. However, this sequence allows for calling instructions with a long execution time that would raise an error inside a RealTimeSequence. A RealTimeSequence can only be called from a ContinuousAcqMode.