## 5 Evolution of Our Domain-Specific Modeling Language  
To understand the relation between Sequencer and its successor RT-Sequencer better, Figure 4 depicts the connection between those two languages. There are three levels of modeling in Figure 4. The first level defines the _metamodeling level_, the second is _modeling level_ and the third is the _generated code level_, as depicted on the right side of Figure 4.  
The first level, indicated with M2, contains a metamodel, which is an abstraction that combines the properties of instances (models) that appear on the second level. The metamodel is constructed with metadata that define the properties and features of the language. Both our languages differ in the supported problem domains, as shown in Figure 4. While Sequencer supports the DAQ domain, RT-Sequencer was developed upon  
Figure 4: Relation between the Sequencer and RT-Sequencer.  
artifacts reused from Sequencer, and in this manner supports, besides the RTC domain, also the DAQ domain. According to [PERSON] et al. [2], RT-Sequencer can be classified in _piggyback_ pattern for language design if we consider that Sequencer has used an existing language partially. Different concepts were reused, representing visual blocks and connections, predefined concepts, local/global model variables, etc. However, new functionalities (e.g., the ability to define new concepts) forced us to extend Sequencer, and implement a much more complex metamodel for RT-Sequencer, that supports another domain in a way that new constructs can be defined.  
On the second level models appear in both languages. Models represent conceptual solutions from the problem domain, and correspond to the metamodel defined in level M2. In Figure 4, we can observe a slightly more complex structure for RT-Sequencer. While end-users define a single model in Sequencer, we need to define two models on this level for RT-Sequencer. In sublevel M1.1, we specify new language constructs; in sublevel M1.2, we define a model. Models in sublevel M1.1 expand our metamodels with new constructs, since the RT-Sequencer metamodel is defined in a way that it is possible to extend a language with new features (_self-extension_[35] in Figure 4). Besides, GPL code is used to define the logic of this new language. Consequently, the model on M1.2 is constructed using elements defined in the metamodel (level M2) and the model on level M1.1. With this separation into two models (on sublevels M1.1 and M1.2), RT-Sequencer supports multi-level modeling on this level [36; 37; 38], which will be discussed later in this paper.  
The last level is the generated program level (indicated by M0), where we use transformation rules for individual elements from the model and a transformation engine to produce the programming code, which will, finally, be executed inside the Dewesoft system. Figure 4 shows that domain experts can make RT programs and DAQ programs inside the RT-Sequencer. Note that the RT program combines both domains, the RTC and DAQ domains, since the RT-Sequencer language is based on the Sequencer as described in the M2 level.  
The above details of our extension are connected with both languages' structures. Note, other means of a language (language framework, etc.) were also reused from Sequencer, and incorporated in our new language RT-Sequencer, but are a bit outside of the scope of this paper.