The robotics glossary defines the tecnical terminology used on the Information Model. It is important to taking into account to understand well the hole document. As you can see in the Table of Content, firstly it has defined a general vocabulary and them more specific one: H-ROS types (classes of components that make up H-ROS) and ROS 2 (the most common words of the Robot Operating System 2).
Component and module have been used interchangeably in general terms, but to avoid confusion the term module is used to refer to a component that meets the modularity guidelines presented in ISO-22166 (International Organization for Standardization. Robotics — Modularity for service robots — Part 1: General requirements (ISO Standard No. 22166)), still in development. As a reference, a module is a component, whereas a component does not need to be a module.
black box module: Module whose inputs, outputs and general functions are known but whose internal contents or implementation are unknown. All modules described in this page and their requirements of are based on the black-box module concept. This does not exclude the use of Open Source Software to implement parts or all of the closed-box module’s functionalities.
component: A part of something that is discrete and identifiable with respect to combining with other parts to produce something larger. A component can be either software or hardware. Even a component that is mainly software or hardware can be referred to as a software or hardware component, respectively. A component does not need to have any special properties regarding modularity.
composability: Ability to assemble modules logically and physically using various combinations into new composite modules for performing more sophisticated operations.
configuration (noun): The arrangement of a modular robot in terms of the number and type of modules used, the connections between those modules, and the settings for those modules, in order to achieve the desired functionality of the modular robot as a whole. ISO 8373 also defines (joint) configuration but this is a different concept. This term describes the result of some process, i.e. the state something is in.
connector: Physical link that establishes connection between parts of the system. Examples can include communication, powering, and mechanical linking.
control signals: Signals for altering the state of a receiving module or component in some way. A control signal does not transmit structured data like sensor readings (images, sound, etc.) or other data processed as part of the robots application.
data/software communication interface: Protocol(s) at any layer including and above OSI layer 2 used for the logical layer in communication with other parts of the system.
execution life cycle: The finite state machine defining all stages of execution of a part’s function.
function: A defined objective or characteristic action of a system or component or module [ISO/IEC/IEEE 24765 3.1206-5 (Modified)].
functional safety: Part of the overall safety relating to the equipment under control (EUC) and the EUC control system that depends on the correct functioning of the electrical, electronic and programmable electronic (E/E/PE) safety-related systems and other risk reduction measures [IEC 61508-4:2010, 3.1.12].
granularity: The degree to which a robot module can be broken down into smaller separate modules.
information model: An abstraction and representation of the entities in a managed environment, their properties, attributes and operations, and the way that they relate to each other.
integrated development environment: Set of programs that assist users in editing, developing, debugging, and verifying modules/apps and for monitoring the status of the robot and/or its sub-systems.
interchangeability: Module property allowing it to be capable of being used to replace another module. Such interchangeability can relate to modules produced by one manufacturer of from different manufacturers.
interface: A shared boundary between two or more functional modules, defined by various characteristics pertaining to the functions, physical signal exchanges, and other characteristics [ISO/IEC/IEEE 24765-2010 3.1480].
interoperability: The capability to communicate, execute programs or transfer data or power among modules, or combine modules physically in a manner that requires the user to have little or no knowledge of the unique characteristics of the individual modules .
mechanical interface: Physical means of connection with other modules used for the transmission of physical forces and facilitating module function. Transmitted physical forces include forces controlled for an intended purpose as part of planned function, and uncontrolled forces both intentional (e.g. structural support) and unintentional (e.g. cushioning).
middleware: Software that connects two or more separate software modules in the same layer or between software layers, lies between the operating system and the software modules, and can control executions of the software modules.
modularity: The degree to which a system's components may be separated and recombined.
module: Component or assembly of components with a defined interface thus facilitating system design, integration, interoperability, and re-use. A module may have both hardware and software aspects simultaneously.
module property: Attribute or characteristic of a module, i.e. a module property for hardware can be the torque of an actuator, and module property for software can be the response time to a new command.
module property profile: Catalogue of the values of a sub-set of a module’s module properties.
open module: Module which allows interactions between external entities and it's internal elements. This neither requires nor prevents the use of Open Source Software to implement parts or all of the open module’s functionalities. An open module is still treated as a black box module, i.e. other modules may only communicate with the open module through it's official, manufacturer-specified module interface. An open module is not necessarily a composite module, nor is a composite module necessarily an open module.
package: Set of all software binaries, configuration information and support files necessary for a module with software aspects to function as designed. Packages can depend on other packages.
plug-n-play: (plug-n-work) hardware/robot component with ability to be self-discovered when connected to other components and able to start functioning as intended.
quality of service: Minimum level of performance of a module’s service to other modules connected to it for overall operation as intended.
reconfiguration: Altering the configuration of a modular robot in order to achieve an intended change in the function of the modular robot.
reusability: Ability to adopt modules, previously designed and produced, to facilitate the development of new modules to realise different bespoke required functionalities.
robot module: Module intended to be used as part of a modular robot system. Not all modules used in a modular robot system need to be robot modules, but if the primary intention of a module is to be used in a modular robot system, then it is a robot module.
self-configuration: A process by which robot systems automatically adapt their own configuration of modules without human direct intervention.
self-(re-)configuration: Changing the configuration of a modular robot (or component) through an automated process without human interaction except to initiate the process, if necessary. Typically, mechanical and electrical connections need to be manually (re-)configured, with the automation applying to (re-)configuration of the software aspects.
software aspects: Information regarding the external software properties necessary for a module and it's interface and the execution life cycle of that module’s function.
standardized communication interface (SCI): Interface compliant to a defined communication model by an internationally recognised organization and publicly available. The SCI used within H-ROS is the 7-layer OSI model [ISO 7498-1].
verification method: Method that tests a module, component or system and provides objective evidence of the extent to which a particular performance property is exhibited.
basic module: Module that is not decomposable into smaller modules. An example of decomposing a service robot into basic modules could be as input, processing, output or infrastructure support modules.
composite module: Module composed of other modules. A module manufacturer can choose to document the internal structure of it's composite module possibly including access to internal interfaces or documented procedures to replace some of the build in modules.
hardware module: Module whose implementation consists purely of physical parts, including mechanical parts, electronic circuits and any software, such as firmware, not externally accessible through the module's interface.
software module: Module whose implementation consists purely of programmed algorithms.
Sensor: Sensing components help robots perceive it's environment and share the information with the rest of the connected modules or with the user.
Actuator: Components within a robot that provide means of physical interaction with the environment.
Communication:Communication components provide means of interconnection between the modules of the robot or expose new communication channels to the overall network.
Cognition: Computation and coordination component, these modules perform most of the computationally expensive tasks within the robot.
Composite: Sophisticated sub-systems formed by composing basic components among the previous classes.
UI: Components that provide means of interfacing with the robot either though joysticks, tactile screens, voice commands, etc.
Power: Components whose purpose is to deliver power to the system or subsystems.
Package: Software is organized in “packages”. The goal of these packages it to provide this useful functionality in an easy-to-consume manner so that software can be easily reused.
Node: A "node" is an abstraction for a process that performs computation. ¿computing environment where a component execution framework is run in a remote setting.?
Topic: A "topic" is an abstraction for a name that is used to identify the communication channel between different nodes.
Message: A "message" is a simple data structure, comprising typed fields. Messages can include arbitrarily nested structures and arrays. Nodes communicate with each other by publishing messages to topics.
Service: Services enable Remote Procedure Call (RPC) request/response communication between nodes. A service is defined by a pair of messages: one for the request and one for the reply. Services are typically suitable for tasks that are inexpensive or “instantaneous” in the target module.
Action: Actions introduce the client/server paradigm within the message format of this standard. Actions allow Node A to send a request to perform a time consuming action in Node B. Actions also allows the monitor and interaction (stop, resume, cancel) with the remote task in execution.
Parameter: Numerical or other measurable factor forming one of a set that defines a module or sets the conditions of it's operation.