Requirement Analysis and Standardization activities

Recently, robotics systems are getting more and more complex. If in early days of robotics “AI problems” such as behavior control, theorem solving, reasoning etc were main focus of the research with the proliferation of more sophisticated hardware and software technologies the focus started to shift towards the “problem of integration”. In particular this is observable in robotics software domain. This change of focus created another problem, namely, gap between AI techniques and their integration and development in structured way into one coherent system. There have been many software (SW) projects trying to solve the problem, mostly implicitly, by tackling it one sided. Therefore, most of the current systems are either addressing integration/development problem (Player/Stage, ORCA2 etc) or AI problems (CARMEN, XPERO, OpenAI etc ). Of course, there have been several attempts to combine both thus, resulting in complete architectural systems supporting both integration and AI aspects such as LAAS architecture or 3T. Such systems are often referred to as robotic control architectures contrary to framework and middleware solutions. In such cases integration and AI combination was the side effect of an attempt to combine deliberative and behavioral paradigms for robot control.

Task specs and Layers

One of the main problems in robotics software domain is that it is not clear how things are organized and what interrelations they have to each other. Identifying this picture can assist in faster progress of the domain in particular when it is concerned “software reuse”. There exist meriad of software projects some concentrating on algorithms and AI, some on integration aspects or some that just serve as a tool support platform. Everytime a developer starts writing his application he looks into these projects to choose an appropriate one that can meet his needs or eventually he may deem all of them to be useless. To avoid such situation and to make this effort of choice less combersome, there should be some “methodology” or “systematic approach” on what level things should be developed, compared, reused or discarded. That is where comes in the four layered perspective. Figure 2 shows relation between different technology platform including OMG software models from software engineering domain and TOPCASED from aerospace and embedded systems domain. Here the technology platform stands for the collection of models, specifications and their sample implementations and respective tool support. It covers all stages of software lifecycle from design time to deployment time. While analysing the figure from top down one can consider the upper levels to be more general models of the lower levels. That is if one is given a general semnatic description of a system in some form of computer language (ontology level) then transformation/manipulation of the “model” written in this language should generate a more concrete model of the system considered.

Some text comes hereSome text comes hereSome text comes hereSome text comes hereSome text comes hereSome text comes hereSome text comes hereSome text comes hereSome text comes hereSome text comes hereSome text comes hereSome text comes hereSome text comes hereSome text comes hereSome text comes hereSome text comes hereSome text comes hereSome text comes hereSome text comes hereSome text comes hereSome text comes hereSome text comes hereSome text comes hereSome text comes hereSome text comes hereSome text comes hereSome text comes hereSome text comes here

Layer Name

A Set of standards which can be useful

Project/Standard description

Ontologies

• Description of Ontology (wikipedia way)
• John F. Sowa Ontology resources
• Knowledge Systems, AI Lab Stanford
• Web page on ontology related resources
• Ontology portal
• Requirement Analysis (wikipedia way)
• IEEE Standard Upper Ontology Working Group
• OWL
• OpenCyc/Cyc
• Dublin Core
• DAML onotology library
• Protege onotology library
• ODOL onotology library

Mathematical Representation

• MathML
• Modelica
• LateX/TeX
• OMDoc
• GELLMU
• SysML
• XMI

Computer Representation

• OSGI/R-OSGI
• Apache Felix
• DDS
• CWM

Hardware Representation

• netCDF
• HDF5
• XDR

The survey done provided us with twenty four different scientific data representation approaches. During the survey the following points were emphasized: Self-descriptive data representation – the format used to describe data should make clear what kind of semantics the data conveys. Existence of stable and up-to-date implementation – this item is related to the fact whether a system is still in use and what the latest updates to its implementation were. This also includes existence of the developer base which continuously contributes to the project and can provide support when needed. Good tool/language support and variety of APIs – apart from the stable library implementation the chosen approach should provide reasonable tool chain support and API for different programming languages. Tools are helpful if one wants to analyze or modify already existing files without the need of using programming interfaces. Several potentially promising candidate approaches were chosen out of these twenty four. They were analyzed along five main dimensions: Data model – is concerned with how the data are organized in storage media. It also concerns what the relation between different types of data is. Meta data support – is concerned how meta information is used in storage, how it describes local variables/data and the dataset globally. Additionally, a support for meta-data description language and tools dealing with it are taken into account. Data access modes – is concerned with how the data can actually be accessed, whether it is direct access to some particular set of data without reading the whole medium or sequential access. Storage model/data type support – is concerned with what kind of storage media are supported, how the data are allocated and what types of data are supported. Platform/tool support and APIs – is concerned with what implementation exist and on which platforms they can be deployed. It also considers variety of different tools and whether the implementation can be interfaces with other third party applications. We discuss each of the candidate approaches in detail with respect to the listed features in the next section.

Short name

Full name and www link

Description

CDF

Common data format site

The National Space Science Data Center's (NSSDC) Common Data Format (CDF) is a self-describing data abstraction for the storage and manipulation of multidimensional data in a discipline-independent fashion. CDF is a scientific data management package (known as the "CDF Library") which allows programmers an d application developers to manage and manipulate scalar, vector, and multi-dimensional data arrays . The basic component of CDF is a programming interface that is device independent. Client software library called CSCDF can be used with the CDF library to provide applications access to remote CDF datasets.

HDF

Hierarchical Data Format site

The Hierarchical Data Format is a multi-object file format that facilitates the transfer of various types of data between machines and operating systems. It allows self-definitions of data content and is easily extensible for future enhancements or compatibility with other standard formats. The latest versions of HDF supports the complete netCDF interface. The HDF library contains interfaces for storing and retrieving compressed and uncompressed raster images with palettes and an interface for storing and retrieving n-Dimensional scientific datasets together with the information about the data, such as labels, units, formats and scales for all dimensions.

netCDF

Network Common Data Format site

The network Common Data Form is an interface for scientific data access and a library that provides an implementation of the interface. It also defines a machine-independent format for representing data. Data stored in the netCDF format is self-describing, network transparent, direct-access, appendable, and sharable. There is a netCDF interface to HDF available. NcML is an XML representation of netCDF metadata, (roughly) the header information one gets from a netCDF file with the "ncdump -h" command. NcML is similar to the netCDF CDL (network Common data form Description Language), except, of course, it uses XML syntax. The CF conventions for climate and forecast metadata are designed to promote the processing and sharing of files created with the netCDF API The conventions define metadata that provide a definitive description of what the data in each variable represents, and of the spatial and temporal properties of the data. This enables users of data from different sources to decide which quantities are comparable, and facilitates building applications with powerful extraction, regridding, and display capabilities. NetCDF data is: Self-Describing. A netCDF file includes information about the data it contains. Portable. A netCDF file can be accessed by computers with different ways of storing integers, characters, and floating-point numbers. Direct-access. A small subset of a large dataset may be accessed efficiently, without first reading through all the preceding data. Appendable. Data may be appended to a properly structured netCDF file without copying the dataset or redefining its structure. Sharable. One writer and multiple readers may simultaneously access the same netCDF file. Archivable. Access to all earlier forms of netCDF data will be supported by current and future versions of the software.

XML

Extensible Markup Language site

The Extensible Markup Language (XML) is a general-purpose specification for creating custom markup languages. It is classified as an extensible language because it allows its users to define their own elements. Its primary purpose is to facilitate the sharing of structured data across different information systems, particularly via the Internet,[2] and it is used both to encode documents and to serialize data. In the latter context, it is comparable with other text-based serialization languages such as JSON and YAML. the first problem is that XML is not a very compact way of representing information. For instance, it would be possible to take an XML document and rework it into a proprietary binary format that would be much smaller even without the use of modern compression techniques. The second problem is that, while XML is easy to read, it is not in an optimal format for a parser to process and interpret. This means that more processing time is spent than may be necessary to get to the information stored in the document.

XDMF

Extensible Data Model and Format site1, site2

XDMF is an active, common data hub used to pass values and metadata in a standard fashion between application modules. XDMF views data as consisting of two basic types : Light data and Heavy data. Light data is both metadata and small amounts of values. Heavy data typically consists of large arrays of values. All light data in XDMF is stored using the eXtensible Markup Language ( XML ). Heavy data is currently confined to HDF5 but will eventually include formats like Oracle and Plot3D. XDMF is both a data model and format. That means that the size and shape of the data is described as is its’ intended use (i.e. XYZ Position vs. 3D Vectors ). Data format refers to the raw data to be manipulated. Information like number type ( float, integer, etc.), precision, location, rank, and dimensions completely describe the any dataset regardless of its size. The description of the data is also separate from the values themselves. We refer to the description of the data as Light data and the values themselves as Heavy data. Light data is small and can be passed between modules easily.

The process of the requirement analysis is performed based on two approaches:

1. Questionnaire – in this case authors with the help of experts compiled a set of questions on robotic software systems, ontologies, benchmarks and architectures. Here latter three topics are covered by the other project partners but some aspects related to communication software were also used for our analysis purposes. This questionnaire was distributed among service and industrial robotics companies by partner EUnited Robotics. There have been received 16 responses so far and the process is still in progress.
2. Interviews with stakeholders – in this case authors carried out several face-to-face interviews with people both from industry and academia. As the continuation to IROS 2007 San Diego workshop organized by the authors, we held an open expert meeting during ICRA 2008 conference in Pasadena. During the meeting several topics were discussed, including standardization and harmonization issues in robotics software community and how can the community promote “reuse” of the existing technologies and experiences from other domains. Additionally, we also performed interviews with members of currently running German National Service Robotics project, “DESIRE”. These interviews gave authors opportunity to study the situation and experiences in running “live project” with people who have hands on experience developing communication software/middleware.

REQUIREMENTS/PERFORMANCE

• What products do you offer that require distributed computing or communication middleware?
• What media, and protocols do you use for the communication between the software and hardware components of your product or application? Media: Field buses such as Industrial Ethernet, EthernetCAT, CANBUS, PROFIBUS, InterBus, I2C, Serial lines (RS 232, 422, 449 485 etc), PCI/ISA, Wireless networks, others. Protocols: IP, TCP, UDP, CANOpen, DeviceNet, DCCP, Sinec H1, others.
• What are the timing and bandwidth requirements and constraints for this inter-component and/or inter-process communication? In the range of 1-10 KHz or higher, 10-100 Mbits/s or higher; In the range of 100-1000 Hz, 1-10 Mbits/s; Less than 100 Hz, less than 1 Mbit/s
• What are other requirements for this communication? Reliability, Extensibility, Security, Availability, Safety

MAINTANANCE/STANDARDIZATION:

• Is your current solution satisfying or are there any problems which you would like to have solved in a better way?
• How much effort do you have to invest in the maintenance and adaptation of your communication solution?
• Is it important or necessary for you to have a “common/agreed upon by many” solution for your communication needs?

MIDDLEWARE APPROACHES:

• Are you using any of the following middleware approaches for your products or applications? Are you satisfied with its performance and functionality? Satisfied if no, why not: CORBA conforming, ICE (Internet Communication Engine), NET conforming, RPC/RMI based, Custom approach.
• If you are not using any middleware, what are the reasons for that?

Question #

Interviewee 1

Interviewee 2

Interviewee 3

Interviewee 4

Interviewee 5

Interviewee 6

1.2. Did you ever face the problem of the lack of standards in service robotics

Yes, communication with components. The problem is that there are many standards

Yes, methods and criteria for the evaluation of robot performances

There is often general confusion about the many types (levels of absraction) of "architecture" capable of being described within a robot system. On a more practical level specific safety standards would make it easier to meet legislative requirements, but it is probably too early to formulate these.

yes, For interconection of HW/SW modules

no

yes, electrical architectures and power systems

2.2. Which enhancements should be done with respect to scalability and technical soundness of the mechanisms used for implementation

Open source, stable implementation, portable code

no answer

Again across the wide variety of robot applications only design time commonility can sensibly be sought with common functional architectures. Within similar application areas common operational architectures may be implemeted offering build / compile time scalability. Only within product families / closely controlled application areas can implemetation architectures be shared and plug & play scalability be impletmented.

no answer

possibility to integrate controller in one network (cooperating systems)

no answer

3.1. What products do you offer that require distributed computing or communication middleware?

None

no answer

Our control systems often employ distributed computing. Assuming that by middleware you mean media / software combination then we frequently use bought in solutions up to the Transport layer of the OSI model.

robuBOX

no answer

military robotic platforms and systems (JAUS)

3.2. What media, and protocols do you use for the communication between the software and hardware components of your product or application?

CANBUS, Serial lines, I2C, PROFIBUS; DeviceNet, SMP

CANBUS, Serial lines, wireless networks, Ethernet, I2C, PCI/ISA; IP, UDP, TCP, CANOpen

Field buses, CANBUS, Serial Lines, wireless networks, ethernet, PROFIBUS, PCI/ISA; IP, UDP

CANBUS, Serial Lines, wireless networks, I2C, ethernet; IP, UDP, TCP, CANOpen

Field buses, CANBUS, Ethernet, PROFIBUS; IP, UDP, TCP, CANOpen, EtherCAT

CANBUS, InterBus, Serial lines, Wireless networks ethernet, I2C, PCI, PCI/ISA, Firewire; IP, UDP, YCP, CANOpen, JAUS

3.3. What are the timing and bandwidth requirements and constraints for this inter-component and/or inter-process communication?

less than 100 Hz, less than 1 Mbit/s

in the range of 100-1000Hz, 1-10Mbit/s

in the range of 1-10KHz or higher, 10-100 Mbits/s and in the range of 100-1000Hz, 1-10Mbits/s

In the range of 100-1000KHz, 1-10Mbits/s

In the range of 1-10 Khz or higher, 10-100 Mbits/s

all the ranges possible