## 4 Validation: Experimentations of RsaML
### Experimentation 2: Test of Semantics and Verification of a Model  
The objective is to check that the semantic rules in the meta-model (i.e., the abstract syntax of RsaML) are well integrated, making it possible to detect semantic errors correctly. In order to reach this goal, some semantic errors (with respect to the semantic rules defined) have been introduced in the case study described in Section 4.1.1, then the verification of the obtained model has been carried out and finally the errors generated have been compared with those expected. The verification of the modified model (i.e., the model including semantic errors) generated five (5) errors as shown in Figure 10. \begin{table}
\begin{tabular}{l l} \hline \hline
**Element of the System** & **Concepts of RsaML** \\ \hline Decision Layer & Layer \\ Procedural Exec & Module \\ f0-01 & Function \\ a0 & Action \\ aRT & RTAction \\ e0 & EntryPort \\ s0 & OutPutPort \\ \hline \hline \end{tabular}
\end{table} 
Table 3: Correspondence between some elements of Figure 8 and the concepts of RsaML. Figure 9: The RsaML model corresponding to the architecture presented in Figure 8.  
Figure 10 shows the errors generated as a result of the following anomalies:  
1. The number of defined layers is different from the number of layers actually created;
2. A port communicates with another port whose data type is different from its own;
3. A module of layer n modifies the data of another module located at layer n-2;
4. The execution time of a module is greater than the maximum execution time defined for the layer that contains it;
5. A function is defined as real-time, but contains non-real-time actions. Figure 11 shows details explaining these errors. It contains the numbers from 1 to 5 corresponding to the errors in Figure 10.  
In the diagram of Figure 11:  
* The problem items carry a small red cross;
* Extracts of couples (properties, values) of certain elements of the model are represented in rectangles connected to these elements by lines which we will call \"links\" in the following. The diagram in Figure 11 shows the following:  
1. Four (4) layers are declared for the architecture (_link 1a_), but only three layers (decisional, control, and functional) are actually created;
2. The type of data that the _e0_prodExec_ input port can receive is \"_alphanumeric_\" (_link 2a_), but it is connected to the output port (its Outputport property) _s0_ressourceCheck_, which sends it data of type \"_numeric_\" (_link 2b_);
3. The _proceduralExec_ module deletes the entry _e0_m01_ (_link 3a_) of module _m01_, which is at the functional layer (_link 3b_) at level n-2, whereas the decisional layer is at level n;
4. The execution duration of the _resourceChecker_ module is 2.5 (_link 4b_), while the maximum time of execution of the layer where it is located is 2.0 (_link 4a_);
5. The function _f0_m01_ is real-time (_link 5a_), but it contains an action which is not real-time (action _a0_f0_m01_). This experimentation shows that the integration of OCL constraints in the language works fine, that these constraints are well and truly verified when the language is used, and therefore that the static semantics of RsaML is potentially well defined. Figure 10: Semantic errors detected thanks to the semantic rules of RsaML. Experimentation 3: A Robotic System Whose Architecture Belongs to None of the Classical Categories of Architectures  
The objective of this last experiment is to verify that the language RasML can be used to model robotic systems whose architecture belongs to none of the classical categories of architectures. For this, we consider a robotic system taken from the literature and describe its software architecture with RasML. The robotic system considered is described in [54]. It is a system with a real-time executive that is represented by a single processor. The latter is connected to the sensors and actuators via two acquisition cards. Figure 12 shows the structure of the robotic system.