## 5 Discussion  
Part of the related works presented in Section 2.2 addressed the question of the application of MDE to the development of robotic software systems in general, and the other part addressed the specific problem of definition of DSML for robotics. Each of these works has contributed to filling the gaps regarding the application of software engineering methods and techniques to the robotics field. However, with respect to the questions raised in Section 1, these works present some shortcomings. The work presented in [52] does not allow us to represent all categories of architectures. For example, it does not take into account specific aspects of behavioral architectures such as the mechanisms of inhibiting output and suppressing inputs. The works described in [55; 58] do not address the specific issue of the representation of robotic software architectures. The proposition made by [56] is specific to the subsumption architecture. The study conducted by [53] concerns the specific case of the Aibo system, and the proposed meta-model is therefore restricted to this system. Likewise, the proposal made by [54] focuses on the development of the system for the control of a given prototype. Almost all of these works do not take into account the real-time aspects of robotic systems. Unlike the  
Figure 13: The RsaML model corresponding to the robotic architecture presented in Figure 12.  
previous solutions, RsaML provides a solution taking into account all categories of robotic software architectures and all types of robotic systems. It makes it possible to take into account functional and non-functional properties of robotic systems that cannot be included graphically in the meta-model. RsaML also offers the ability to include and verify real-time properties for robotic systems that have time constraints. As mentioned in Section 2.2, SmartSoft [63] brings a significant advance in the definition of DSML for robotics. We can recall, among other things, the interoperability provided by the possibility of generating code to CORBA and ACE (Adaptive Communication Environment). However, SmartSoft's meta-model does not distinguish hardware components from software components of robotic systems. This has the consequence of reducing the level of abstraction and therefore the possibility of abstracting the material that must support the developed system. RsaML provides the ability to model software architectures independently of the underlying hardware by decoupling the hardware and software components of a system. The components of smartSoft are kinds of \"black boxes\" offered to manage the robot. Consequently, the possibilities to specify/modify the desired behaviors of these components are almost nil. Furthermore, the tasks do not explicitly describe the actions that carry them out. RsaML takes this level of granularity into account by making it possible to specify at the level of the architectural model, the components, and the tasks that constitute them as well as the actions of the latter. This way of doing things promotes the modularity of the architectures defined, increases the maintainability of the systems built, and facilitates the reusability of the components of the latter. The SmartMars meta-model on which SmartSoft is built does not integrate semantic rules for the management of non-functional properties. The authors made new works [69] dedicated to the modeling of non-functional constraints for robotic software systems. RobotML [64] has also paved the way for the application of software engineering in the field of robotics. However, unlike RsaML, RobotML does not allow checking the non-functional properties of built models. Moreover, although RobotML defines a property allowing to specify the type of a task in the constructed model (periodic, aperiodic, etc. ), it does not offer elements for the specification of the real-time properties of the systems, which are essential elements to specify, for example, the policy and parameters for scheduling tasks.