An information model for modular robots: the Hardware RobotInformation Model (HRIM)

Irati Zamalloa, Iñigo Muguruza,Alejandro Hernández, Risto Kojcev and Víctor Mayoral

Abstract— Today’s landscape of robotics is dominated by verti-cal integration where single vendors develop the final productleading to slow progress, expensive products and customer lock-in. Opposite to this, an horizontal integration would result in arapid development of cost-effective mass-market products withan additional consumer empowerment. The transition of anindustry from vertical integration to horizontal integration istypically catalyzed by de facto industry standards that enablea simplified and seamless integration of products. However, inrobotics there is currently no leading candidate for a globalplug-and-play standard.This paper tackles the problem of incompatibility between robotcomponents that hinder the reconfigurability and flexibilitydemanded by the robotics industry. Particularly, it presentsa model to create plug-and-play robot hardware components.Rather than iteratively evolving previous ontologies, our pro-posed model answers the needs identified by the industry whilefacilitating interoperability, measurability and comparability ofrobotics technology. Our approach differs significantly with theones presented before as it is hardware-oriented and establishesa clear set of actions towards the integration of this model inreal environments and with real manufacturers.

I. INTRODUCTION

Existing and emerging robot technologies have thepotential to rapidly disrupt many areas, yet we are stillin the early days of the robotics revolution. In 2011, M.Jändel [1] described that one of the main hurdles of therobotics transformation is the lack of integrative standards.According to Jändel, a global standard for plug-and-playrobotics would be instrumental for transforming thestructure of the industry and dramatically reducing costs,thus facilitating the applications of robotics to all domainsof modern society. In summary, a plug-and-play standardthat eases interoperability and reusability for robotics wouldsignificantly contribute to the development of relevanthardware and software which can quickly be assembled forsolving the task at hand.

The importance of reusability and interoperability inrobotics was also highlighted by Mayoral et al. [2], wherethe authors introduce how the integration effort of a robot,composed by diverse sub-components or parts, supersedesmany other tasks. In that paper, the Hardware RobotOperating System (H-ROS) was presented. A commoninfrastructure that reduces the integration effort by creatingan environment where components can simply be connectedand interoperate seamlessly. This infrastructure becomes

Erle Robotics

particularly relevant when working with modular robots,robots composed by different sub-modules that may ormay not come from the same manufacturer. Seamless andunambiguous communication between robots and theircomponents is a popular topic in the research field ofrobotics. As introduced in IEEE Standard Ontologies forRobotics and Automation [3], similar to humans who requirea common and well defined vocabulary for communication,robots present an analogous need. An intermediate standardlanguage with clear and well defined terms is a sine quanon condition for inter and intra robot interoperability.

Several groups have studied a unified way of representingknowledge and provided a common set of terms anddefinitions to facilitate interoperability in the roboticsdomain. Yet, there seem to be conflicting different viewson the topic [4]. Leaving aside the somewhat contradictorylandscape of definitions and uses of terminology [5], ourteam concludes the following:

Models and ontologies are critical for the developmentof robotic systems, specially for the interoperability,measurability and comparability of robotics technology.To the best of our knowledge, most work and studiescentered around ontologies for robotics technology arefocused on the software abstractions and little discus-sion has been presented on how this work can be trans-lated to real hardware systems to promote integrability,portability and reusability.

The current state of the art shows that, in an attempt tocreate standards and international agreements [6], severalontologies have been produced in the domain of robotics,however these models still have not been accepted neithertranslated to industry. Robot component manufacturers stilllack of a common set of principles to follow when designingthe interfaces of their robot hardware devices. As concludedby Zamalloa et al. [7], due to the vertical approach thatmost robot manufacturers follow and the lack of identifiedcollaborations between them, no single player in roboticshas currently the position of establishing a de facto standardby itself.

This work addresses the need in the robotics industry ofa common interface that facilitates interoperability amongdifferent vendors of robot hardware components. To this end,our work gets inspiration from previous results presentedin [2], [3], [8], [9], and defines a model for hardware in

arX

iv:1

802.

0145

9v3

[cs

.RO

] 1

6 Fe

b 20

18

robotics created through interactions with robot hardwarevendors and implemented using the widely spread RobotOperating System (ROS) [10]. In the content that follows,the words component and module are used interchangeably.Section II will introduce relevant previous work. SectionIII will introduce the Hardware Robot Information Model(HRIM), and Section IV will present conclusions and futurework.

II. RELATED WORK

A. Ontologies in Robotics

Approaches for ontology-based knowledge engineeringin robotics have been studied for years exploring thehuman-robot and robot-robot interaction. Ontologies sustainnot only a common understanding of the domain forhumans, but also for robotic systems which need to achieveinteroperability, perform their tasks in an autonomous wayor interact with humans.

Within ’An IEEE Standard Ontology for Robotics andAutomation’ [11], Schlenoff et al. discuss the developmentof a standard ontology and its associated methodology forknowledge representation and reasoning in robotics andautomation. Such standard aimed to provide a commonset of terms and definitions, allowing for unambiguousknowledge transfer among any group of humans, robots,and other artificial systems which were summarized in [3].The purpose of this standard is to provide a methodologyfor knowledge representation and reasoning in roboticsand automation. Open source implementations of it haverecently been made available [12].

The W3C Semantic Sensor Networks Incubator Group(SSN-XG)1 [13] aims to build a general and expressiveontology for sensors. According to Compton et al. [14],this initiative included members and developers from otherontologies such as CSIRO, MMI and OOTethys. The OpenGeo Spatial (OGC) organization adopted the SSN-XGontology in W3C-OGC project2 and created SOSA (Sensor,Observation, Sample, and Actuator), a lightweight butself-contained core ontology to cover elementary needs.

A recent initiative that used SSN-XG gets described byZander et al. [8], where they present the ReApp architecturethat aims to further improve the re-use of robotics software.According to the authors, ReApp builds upon the ROScomponent model and introduces significant enhancementsin terms of metadata and tooling by using a model-drivendesign methodology backed by a semantic description ofsoftware components based on ontologies. ReApp ontolo-gies allow the creation of high-level models of differentcomponents and their corresponding interfaces, which canbe automatically transformed to source code and collect

1http://www.w3.org/2005/Incubator/ssn/

2https://www.w3.org/TR/vocab-ssn/

relevant information for the developer in a single, integratedstep. ReApp was evaluated in a simple industrial scena-rio with commercially available robots performing differentautomation tasks. To best of our knowledge, there is noreal commercialization nor acceptance of ReApp proposedontologies in industrial scenarios.Space Plug-and-Play Avionics (SPA) [15] is a collectionof standards designed to facilitate rapid constitution andtesting of spacecraft systems using modular componentsand plug-and-play technology. All the components describetheir own functions through and electronic datasheet, bya ontology limited to satellites. From a technical pointof view, SPA has the potential to expand into a genericplug-and-play standard for robotics, however, there is norobotics organization supporting it and currently, it is mainlyfocused on nanosatellites and plug-and-play architecturesfor space applications [16].

In the presented previous work, several attempts have beenmade to produce standards and international agreements inthe robotics domain. However, there has not been wideacceptance of any of the proposed ontologies and there isstill a lack of a common set of principles to follow whendesigning the interfaces of hardware devices. This workfocuses on proposing a simple and flexible ontological modelthat manufacturers of robot hardware components can use tocreate interoperable devices.

B. Robotics Models

The Object Management Group (OMG3) is an international,open membership, not-for-profit technology standards andindustry standards consortium. The work at the OMGis divided in Domain Task Forces (DTF). Particularly,the Robotics DTF, created in 2005, aims to foster theintegration of robotics systems from modular componentsthrough the adoption of OMG standards. The RoboticTechnology Component (RTC) [17] [18], is one of thestandards focused on modular software components createdby the OMG. It defines a component model and importantinfrastructure services applicable to the development ofsoftware for robotics. The developers can combine RTCsfrom multiple vendors into a single application, acceleratingthe necessary time to create flexible designs. According tothe official document, an RTC is a logical representation ofa hardware and/or software entity that provides well-knownfunctionality and services. In the proposed documents,the hardware aspect of robotics is not well explained nordefined. The RTC proposed ontological model is discussedin more detail by Stampfer et al. [19]. According to them,RTC and SmartSoft were the first available initiativesfor specifying the structures and semantics of a roboticcomponent. The RTC standard had a worldwide impact onthe robotics community and raised the awareness about theneed of component models and structures for robotics. Yet,the standard itself was not widely accepted in Europe and

3http://www.omg.org/

USA and remained mainly used in Japan.

Based on RTC, Japan Embedded Systems TechnologyAssociation (JASA) submitted the Hardware AbstractionLayer for Robotics Technology (HAL4RT) to the OMGas a proposed specification. HAL4RT is an ApplicationProgram Interface (API) for the layer between an applicationsoftware of a middleware and the drivers for devices (suchas sensor inputs, motor control commands) that increasesthe portability and reusability of the device drivers. Thisspecification aims to enable device makers, device usersand software users to build robotic software withoutany concern about the differences among the targeteddevices. Although, RTC and HAL4RT define a Platform-Independent Model (PIM) [11] for robotic systems, the mainobjective of each one is different. While RTC standardizessoftware components in a very general manner, HAL4RTis specifically centered in a subset of existing hardwarecomponents.

However, it seems that HAL4RT has not gone beyond 1.0beta version. We must highlight that, apart of HAL4RT 1.04

document, the rest of the remaining information is onlyavailable in Japanese. For example, Open Embedded Library(OpenEL) 3.0, an implementation of HAL4RT developed byUpwind Technologies, is described entirely in Japanese.

III. HARDWARE ROBOT INFORMATION MODEL (HRIM)

In this section we present HRIM, a common interfacethat facilitates interoperability among different vendors ofrobot hardware components with the purpose of buildingmodular robots. HRIM focuses on the standardization ofthe logical interfaces between robot modules, designing aset of rules that each device has to meet in order to achieveinteroperability.

Even though HRIM5 was born as part of the H-ROSproject, it is an independent standard interface for robotmodules which contains rules/specifications that standardizeinteractions between different robot components. Similar toother robotics standardization approaches (such as ReAppor BRICS), HRIM builds upon the component model ofROS, since it stands out as one of the largest integrationplatforms with implementations and mappings to severallanguages and platforms. The popularity of ROS led to ahuge variety of new algorithms and solutions of technicalchallenges in robotics. ROS is a representative exampleof the current situation in robotics software. Already in2009, it was mentioned as the most promising emergingstandard in the Roadmap for US Robotics [20], and sincethen, it has only grown enabling the reuse of the code andcreating simulation platforms to support early developmentand testing of algorithms, without compromising the safety

4http://www.omg.org/spec/HAL4RT/About-HAL4RT/

5https://therobotmodel.com/

of researchers and hardware.

HRIM aims to complement ROS with a standardizationeffort focused on hardware. It is a model that defines thesoftware interface which the different robot componentshave to meet in order interoperate seamlessly. HRIM isdesigned to be implemented by companies which aremanufacturing modular hardware components, in order tofacilitate the integration effort when building robots.

HRIM shares some correlation with different standardizationprojects, specifically with HAL4RT and OpenEL presentedin 20126, where they proposed an open platform to stan-dardize the specifications of the software implementation ofrobotics and control systems unifying the different interfacesof each device manufacturer with the objective of enableapplications running on different hardware. However, wemust highlight some differences and enhancements:

HRIM considers all types of devices necessary for theconstruction of a robot including but not limited tocomponents that provide: sensing, actuation, commu-nication, cognition, user interfaces or power.HRIM infrastructure is based on a thorough marketanalysis of each type of device. These interactions withmanufacturers allow the model to take into accountall the possibilities (features) that the robotic hardwaremarket offers.HRIM defines the units used for all the devices, takinginto account the official repository of ROS [21] andthe International System of Units [22], enabling a welldefined and correct communication between devicesand systems.HRIM contemplates all the robotics hardware, so thatusers can build any type of robot. For example, in theActuator category, besides servomotors, different typesand subtypes of actuation devices are being defined.Such as a gripper, a vacuum gripper, etc.Compared with HAL4RT and OpenEL, HRIM takesinto account devices with complex data streams. Forinstance, a camera can send an image or a video.

Comparing to other related work and standards, HRIMaims for generality, which is essential for acceptance of themodel and for achieving global hardware standardization ofrobotic components.

The following subsections are focused on explaining the con-cepts of HRIM and its potential benefits for applicability inrobotics. In section A the classification of hardware modulesis explained. Section B introduces the naming conventionfollowed within HRIM. Section C describes the HRIMgeneral structure. This explanation has been complementedwith section D, where an HRIM component model exampleis provided: the model of a servomotor module, which helpsunderstanding the whole explained theory in a real context.

6https://staff.aist.go.jp/t.kotoku/omg/2012Burlingame/robotics2012-12-15.pdf

A. Module classification

In order to build any robot, real world implementation requi-res taking into account the common hardware componentsused in robotics. The robot modules have been classified in6 types of modules which correspond to the task they canperform:

Sensors: help robots perceive its environment and sharethe information with the rest of the connected modulesor with the user.Actuators: components within a robot that providemeans of physical interaction with the environment.Communication: provide means of interconnectionbetween the modules of the robot or expose newcommunication channels to the overall network.Cognition: specialized in computation and coordina-tion, these modules perform most of the computatio-nally expensive tasks within the robot.User Interfaces (UI): provide means of interfacingwith the robot, typically related to human-robot inter-action such as joysticks, tactile screens or voice input.Power: components whose purpose is to deliver powerto the system or subsystems.

Each type is composed by sub-types or devices related tothe functionality of the component. For example, a camerais a sub-type of the sensor type.

B. Naming convention

The standardization of the naming rules listed, allows thehardware vendor, developer or robot operator (user) tofacilitate interoperability and reduce the time to read andunderstand the code, focusing on more important tasks thanthe syntax. The naming convention presented below is basedin the ROS component model:

Package

hrim_<device_kind>_<device_name>_<vendor_id>_<product_id>

Node

hrim_<device_kind>_<device_name>_<instance_id>

Topic

hrim_<device_kind>_<device_name>_<instance_id>/<topic_name>

Message

hrim_<device_kind>_<device_name>_msgs/msg/<message_name>.msg

Generic Message

hrim_generic_msgs/msg/<message_name>.msg

Service

hrim_<device_kind>_<device_name>_<instance_id>/<service_name>

Service (file)

hrim_<device_kind>_<device_name>_srvs/srv/<service_name>.srv

Action

hrim_<device_kind>_<device_name>_action/<action_name>.action

Parameterparam name="<parameter_name>" type="<data_type>value="<parameter_value>"

where:hrim: Hardware Robot Information Model.<device_kind>: module classification, explained in sectionA.<device_name>: or sub-type, for example, camera.<vendor_id>: identifier for the device vendor.<product_id>: identifier for the product, typically, the ma-nufacturer part-number.<instance_id>: unique identifier for each device.<topic_name>: descriptive term for each topic.<message_name>: descriptive term of each message.<parameter_name>: descriptive term of each parameter.<data_type>: type of data for the corresponding parameter.<parameter_value>: the value contained in the parameter.

C. General structure

The HRIM information model consists of differentHRIM component models as illustrated in Figure 1, eachrepresenting a different device sub-type used in modularrobots. These component models are built with the ROScommunication abstractions: topics, services, parametersand actions. All of them are labeled as mandatory oroptional, in order to inform the device manufacturer if theinformation must be included or not. The optional aspectsare related to the characteristics of each particular device.In the following paragraphs, the two aspects are explainedin detail to understand the difference and the correct use ofboth of them.

Fig. 1: The general structure in which all the HRIM component models are based on. Each component has topics, services, parametersand actions to communicate. For each one of these abstractions, the figure illustrates that some will be mandatory and some othersoptional.

C.1. Mandatory: is the content that all the modules mustinclude, in order to enable interoperability between differentcomponents.

Device purpose: HRIM detects the essence of thedevice and captures this information in the devicepurpose abstractions. These elements define the basicinformation that allows the user to work with thecomponent. It is a customized information for eachsub-type of module that globalizes to all of its kind,making them interoperate, even when coming fromdifferent manufacturers. The device purpose of themodule is what makes it different from other sub-types,so it has to be composed by at least a topic, a service,an action, or a mix between them, complemented byparameters.

Common requirements: capture various informationto improve the user experience and ensure a correctoperation of the whole robotic system. As picturedin Figure 1, four of them use generic messages suchas: ID.msg, which publishes the general identity ofthe component, Power.msg, that publishes the powerconsumption, Status.msg, which inform about theresources that are consumed, Simulation3D.msg andSimulationURDF.msg, that sends the device 3D modeland related information. Specs<DeviceName>.msg isa custom message which reports the main features ofthe device.

C.2. Optional: these are additional capabilities whichwill be included depending on the particular characteristicsof each device. The manufacturer of each component willbe in charge of including the optional information or not.As showed in Figure 1, there are two groups, additional

capabilities and optional hardware, defined in order tosimplify the whole HRIM, while respecting the modularitymentioned at the beginning of this section.

Additional capabilities: capture complementaryaspects to the component device purpose. Usuallythese are topics, services, actions or parameterscustomized for each component sub-type. For example,a camera able to control the brightness of the imageneeds a parameter to adjust such, therefore it iscategorized as optional due to the fact that not allcameras contain such capability.

Optional hardware: many devices include additionalsub-devices enhancing their own capabilities. Optionalhardware capture these aspects. For example, a cameradevice could include a microphone. In that case, thecontent of the HRIM michophone component modelwould be added as optional hardware within the HRIMcamera component model.

Each HRIM component model will be summarized throughthe template showed in Figure 3, which is divided in twomain categories: the first category includes the topics,services, actions and the second, the parameters, all of themlabeled with mandatory (M) or optional (O). Although theHRIM component model is created for each device, all ofthem follow the same general structure with some commonaspects illustrated in Figure 2. Furthermore, the color codeused in Figure 1 has been respected.

The first five topics listed in Figure 2 are the common topicsthat use generic messages.

id: ID.msg is the identification of each module. It isdesigned to inform the user and also the system aboutthe component itself. /id topic should be programmed

to be released only when the user requires it.

Fig. 2: HRIM component model summary including the commonaspects.

Fig. 3: HRIM component model summary template. On the top,the name of the device that is summarized is showed, then thetopic, service and action name with the corresponding .msg, .srvor .action and the direction (if it is needed): Pub:published orSub:subscribed. The parameters are described by the type of dataand its corresponding unit.

power: Power.msg publishes information of the powersource (power supply or PoE), and the current po-wer consumption. The Power.msg provides continuousinformation regarding the power consummation andpower requirements of each module, allowing the easyconstruction of modular robots.status: Status.msg is designed to inform about theresources that are being used by each component.Similar to the Power.msg, it is programmed to publish

continuously in order to simplify the robot buildingprocess.

simulation: Simulation3D.msg and Simulatio-nURDF.msg allow the user to obtain the 3D modeland a URDF fragment of each module in order tobuild a virtual robot which then can be easily usedin simulation frameworks, such as Gazebo or MoveIt.The simulation topics do not start publishing untilthey detect a user interface or a simulation frameworkconnected to the system.

The rest of the HRIM component model abstractions, suchas specs or <device_purpose>, are specifically designed andcustomized for each component. To give a better unders-tanding of these concepts, a practical example is given insubsection D.

D. HRIM component model example: rotary servomotor

This section elaborates the practicality of the HRIM modeltrough its implementation on a real device. We have chosenthe rotary servomotor since it is one of the most usedcomponents in robotics and sufficient to explain most of theHRIM details.

HRIM defines a rotary servomotor as a smart actuator thatcreates a circular movement and allows for precise controlof position, velocity, effort and, sometimes, acceleration.Apart from the common requirements (ID, Status, Power,Specs and Simulation, detailed in the previous section),all rotary servomotors will contain a topic referring to thecircular movement. Figure 4 presents a summary of theHRIM rotary servomotor model on which the manufacturerswill have to base themselves to configure their ownrotary servomotor. The hardware maker must include,at least, the mandatory aspects. The optional parameterscan be added if the module contains these additional features.

The following paragraphs provide a walkthrough of theabstractions proposed for the HRIM component model ofa rotary servomotor:

Specs: SpecsRotaryServo.msg describes all thenecessary specifications for the implementation of arotary servomotor.

Device purpose: rotary servomotors belong to theactuator type classification. In this case, it is necessaryto define an end goal (position) which can be achievedwith different velocity or acceleration.

Servomotors always contain the common informationdefined for the actuator category. In the rotary servomotorcase, it has four optional topics. The first two are additionalcapabilities that complement the rotary servomotor purpose.The rest are independent sensors that can appear integratedin the component, called optional hardware.

Fig. 4: Rotary servomotors model summary.

State: through StateRotaryServo.msg, a rotaryservomotor continuously publishes informationregarding the motor condition, how is it working, andthe reason in case of error.

Acceleration: some rotary servomotors have the optionto control the acceleration. If that is the case, themanufacturer has to use the GoalAcceleration.msg andexpose the acceleration, so that the user can controlthis feature.

Temperature: the temperature sensor is an independentsensor which can usually be integrated into otherdevices in order to know the interior temperature ofthe module. As you can see in Figure 4, this topic goeshand in hand with two parameters that, in this case,are mandatory to be able to control the temperature ina correct way.

Reconfiguration: Through messages likeReconfiguration.msg, a module is able to informabout its particularities, so that it can be automaticallyintegrated in the robot with as little interaction fromhumans as possible. This reconfiguration functionalityis expected to be extended in the future, and likely,additional types of reconfiguration will be includedwithin HRIM.

As an information model for modular robots, HRIM has beenbuilt with modularity in mind. Each block has a unique andwell identified purpose, making HRIM reusable among manyhardware components purposed for robotics.

IV. CONCLUSION AND FUTURE WORK

It is obvious that the robotics community is well aware ofthe need for standardization, however there is no leadingcandidate for a global plug-and-play standard. The effortsmade so far are country-specific or lack of relevance insimplifying the day to day building robot process. HRIMoffers to the robotics community a common interface thatfacilitates the manufacturing of reusable and interoperablerobot hardware modules for the construction of modularrobots. An information model for modular robots builtupon the principles and abstractions of the popular RobotOperating System (ROS) framework.

The contribution of the paper is twofold. First, we documentand discuss the current state of the art of models andontologies in robotics from the perspective of hardware.Second, we present HRIM, an information model for robothardware, while including examples that explain our designchoices.

Unlike other models and standardization initiatives, HRIMis focused on hardware. It is being built side by side withmanufacturers and experts who actively contribute with theiropinions and feedback. Given the continuous technologicaladvances in the robotics industry, HRIM proposes a modelthat will evolve hand in hand with the available technology.The work presented here is accessible and documented athttp://therobotmodel.com.

Our team is actively working on HRIM, standardizing a vastvariety of components in order to create a solid data basethat will increase the choices of interoperable componentswhen designing a robot. Similar to ReApp, we contemplateimplementing MDE techniques to make HRIM usable amongrobotics frameworks, not only with ROS. For this, we shouldtake a step back creating a PIM (Platform Independet Mo-del), making the model framework agnostic. Furthermore,our team would like to explore the possibility of creating anHRIM electronic datasheet, where all the component typescould be listed and describe their functions and capabilitieselectronically. This would simplify the access to the model,spread its information in the community and facilitate the

manufacturers’ adoption.We hope for wide acceptance of HRIM, which will lead tobetter integration of further components and user experiencein robotics.

ACKNOWLEDGMENT

The authors would like to thank Lander Usategui and AsierBilbao for their contributions supporting the setup and vali-dation of the information model with practical examples onreal hardware. The authors would also like to thank GeoffreyBiggs for his feedback and insights on the informationmodel.

REFERENCES

[1] M. Jändel, “Plug-and-play robotics,” in Proceedings of NATO Sym-posium on Emerged/Emerging “Disruptive” Technologies (IST-099),2011.

[2] V. Mayoral, A. Hernández, R. Kojcev, I. Muguruza, I. Zamalloa,A. Bilbao, and L. Usategi, “The shift in the robotics paradigm; thehardware robot operating system (h-ros); an infrastructure to createinteroperable robot components,” in 2017 NASA/ESA Conference onAdaptive Hardware and Systems (AHS), July 2017, pp. 229–236.

[3] “Ieee standard ontologies for robotics and automation,” IEEE Std1872-2015, pp. 1–60, April 2015.

[4] A. Gómez-Pérez, “Ontological engineering: A state of the art,”Expert Update: Knowledge Based Systems and Applied ArtificialIntelligence, vol. 2, no. 3, pp. 33–43, 1999, ontology EngineeringGroup ? OEG. [Online]. Available: http://oa.upm.es/6493/

[5] T. Haidegger, M. Barreto, P. Gonçalves, M. K. Habib, S. K. V.Ragavan, H. Li, A. Vaccarella, R. Perrone, and E. Prestes, “Appliedontologies and standards for service robots,” Robotics and AutonomousSystems, vol. 61, no. 11, pp. 1215–1223, 2013.

[6] T. Haidegger, M. Barreto, P. Gonçalves, M. K. Habib, S. K. V.Ragavan, H. Li, A. Vaccarella, R. Perrone, and E. Prestes,“Applied ontologies and standards for service robots,” Robotics andAutonomous Systems, vol. 61, no. 11, pp. 1215 – 1223, 2013,ubiquitous Robotics. [Online]. Available: http://www.sciencedirect.com/science/article/pii/S092188901300105X

[7] I. Zamalloa, R. Kojcev, A. Hernández, I. Muguruza, L. Usategui,A. Bilbao, and V. Mayoral, “Dissecting robotics-historical overviewand future perspectives,” arXiv preprint arXiv:1704.08617, 2017.

[8] S. Zander, G. Heppner, G. Neugschwandtner, R. Awad, M. Essinger,and N. Ahmed, “A model-driven engineering approach for ROS usingontological semantics,” CoRR, vol. abs/1601.03998, 2016. [Online].Available: http://arxiv.org/abs/1601.03998

[9] Object Management Group (OMG), “Hardware Abstraction LayerFor Robotic Technology (HAL4RT) Specification, Version 1.0,”OMG Document Number formal/2016-01-01 (http://www.omg.org/spec/HAL4RT/), 2016.

[10] M. Quigley, K. Conley, B. Gerkey, J. Faust, T. Foote, J. Leibs,R. Wheeler, and A. Y. Ng, “Ros: an open-source robot operatingsystem,” in ICRA workshop on open source software, vol. 3, no. 3.2.Kobe, 2009, p. 5.

[11] C. Schlenoff, E. Prestes, R. Madhavan, P. Goncalves, H. Li, S. Bala-kirsky, T. Kramer, and E. Miguelanez, “An ieee standard ontology forrobotics and automation,” in Intelligent Robots and Systems (IROS),2012 IEEE/RSJ International Conference on. IEEE, 2012, pp. 1337–1342.

[12] S. Rama Fiorini, “Ieee1872-owl, owl specification of the core ontologyfor robotics and automation (cora) and other ieee 1872-2015 ontolo-gies,” https://github.com/srfiorini/IEEE1872-owl, 2017.

[13] M. Compton, P. Barnaghi, L. Bermudez, R. Garcıa-Castro, O. Corcho,S. Cox, J. Graybeal, M. Hauswirth, C. Henson, A. Herzog, V. Huang,K. Janowicz, W. D. Kelsey, D. L. Phuoc, L. Lefort, M. Leggieri,H. Neuhaus, A. Nikolov, K. Page, A. Passant, A. Sheth, andK. Taylor, “The ssn ontology of the w3c semantic sensor networkincubator group,” Web Semantics: Science, Services and Agents onthe World Wide Web, vol. 17, no. 0, 2012. [Online]. Available:http://www.websemanticsjournal.org/index.php/ps/article/view/312

[14] M. Compton, C. Henson, L. Lefort, H. Neuhaus, and A. Sheth, “Asurvey of the semantic specification of sensors,” in In 2nd InternationalSemantic Sensor Networks Workshop, 2009.

[15] J. Lyke, “Space-plug-and-play avionics (spa): A three-year progressreport,” vol. 3, 05 2007.

[16] J. Lyke, Q. Young, J. Christensen, and D. Anderson, “Lessons learned:Our decade in plug-and-play for spacecraft,” in Proceedings of the 28thAnnual AIAA Conference on Small Satellites, Logan, UT, 2014.

[17] N. Ando, T. Suehiro, K. Kitagaki, T. Kotoku, and W.-K. Yoon, “Rt-component object model in rt-middleware—distributed componentmiddleware for rt (robot technology),” in Computational Intelligencein Robotics and Automation, 2005. CIRA 2005. Proceedings. 2005IEEE International Symposium on. IEEE, 2005, pp. 457–462.

[18] N. Ando, T. Suehiro, and T. Kotoku, “A software platform forcomponent based rt-system development: Openrtm-aist,” in Interna-tional Conference on Simulation, Modeling, and Programming forAutonomous Robots. Springer, 2008, pp. 87–98.

[19] D. Stampfer, A. Lotz, and C. Schlegel, “Fiona deliverable d2. 2.1 stateof the art on service-oriented software component models.”

[20] J. M. Hollerbach, M. T. Mason, and H. I. Christensen, “A roadmapfor us robotics–from internet to robotics,” Workshop on emergingtechnologies and trends., 2009.

[21] ROS, 2014. [Online]. Available: http://www.ros.org/reps/rep-0103.html

[22] Bureau International des Pois et Mesures, 2014. [Online]. Available:http://www.bipm.org/en/publications/si-brochure/section2-2.html