Papyrus is aiming at providing an integrated and user-consumable environment for editing any kind of EMF model and particularly supporting UML and related modeling languages such as SysML and MARTE. Papyrus provides diagram editors for EMF-based modeling languages amongst them UML 2 and SysML and the glue required for integrating these editors (GMF-based or not) with other MBD and MDSD tools.
One of the objectives of the PROTEUS project is to provide domain specific languages (and related tools like editors, consistency checkers, etc) suitable to specify missions, environments and robot behaviours that have been specified by robotics experts involved in the project. The discussions within the PROTEUS project have led to the decision of defining three DSL s.
1 The Architecture DSL which will ease the definition of specific robotic architectures (reactive, deliberative, hybrid) and specific components that form those architectures (sensors, actuators, planners).
2 The “Control & Communication DSL” that will control the robotic components and will ease the definition of communication mechanisms between components (sending/receiving of events and data).
3 The “Algorithms DSL” that will ease the definition of algorithms which are to be used, triggered with the “Control & Communication DSL” for implementing behaviours in the different components of an architecture described with the Architecture DSL.
The domain model of a given domain specific language defines the concepts and the terminology of the language domain. The relationships between the concepts are described as well. In this section, we present the domain model of the RobotML DSL s based on the requirements defined in the previous section and on the knowledge base provided by the ontology. We have used UML class diagrams to represent the domain model. Figure 1 show a generic view of the RobotML domain model which describe the architecture of the robotic system (ie. its internal structure), the behavior of components (through FSMs or algorithms) , the communications between them and the deployment of robotic systems to specific robotic platforms.
This section introduces a high-level “executive” summary of the subject matter of the relevant sub- package. It contains an informal and lightweight description that identifies the subject matter itself (key concepts and relationships), the general principles of operation (semantics), design rationale, relationship to other packages and their subject matter, etc. The idea is that, for a cursory reader, this should provide sufficient information of the subject without delving into technical details.
The Proteus architecture domain model package contains six sub-packages:
A robotic System is composed of Systems that communicate with other Systems through Ports and have specific Evolution Models (i.e. behaviours). Systems could be Software or Hardware. Software systems are detailed in the RoboticSoftware package (Figure 6), Hardware Systems are detailed in the RobThe environment is the highest possible “container” for the physical objects to exist, and it is considered as part of the architecture of a robotic system. Figure 8 shows the robotic environment package which enables the specification of different types of environments. oticHardware package (Figure 7).
The System concept corresponds to the component concept. The term system is more appropriate to describe a robotic component, this is due to the fact that the term system is more meaningful for a robotician than the term component. A System is composed of properties, ports and connectors.
Figure 4 shows the details of the concept of property. A system is composed of properties which can be a subsystem or a variable. The Part property is typed by a system and thus corresponds to a subsystem. The BasicProperty is typed by a data type and thus corresponds to a variable.
Figure 5 Shows the details of the concept of port. A port formalizes an interaction point of a system. It is a special kind of properties that has a type and a communication policy. A ServicePort is a port that is specific to client/server communications. DataFlowPorts enable data flow-oriented communication between systems, where messages that flow across ports represent data items. ServicePorts support a request/reply communication paradigm (also called client/server model of communication), where messages that flow across ports represent operation calls. ServicePorts are typed by an interface which specifies a number of operations without stating how exactly they are implemented.
Detail of the robotic software package:
Figure 6 shows the details of the robotic software package. A software could be a driver which is the software system part of a DeviceSystem.
Details of the robotic hardware package:
Figure 7 shows the details of the robotic hardware package. A hardware could be: • a physic device: represents the hardware part of a device system, • a storage hardware: represents different forms of memory, • a computing hardware: represents physical processing devices capable of storing and executing program code, • a timing hardware: represents a hardware entity that is capable of following and evidencing the pace of time.
|Plugin name||update site|
The juno version not support the dynamic validation.
|Plugin name||update site|