Robotic Software Systems: From Code-Driven to Model-Driven Software Development

ion of operating system resources

Based on these observations, we assume that the next big step in advanced robotic systems towards mastering their complexity and their overall integration into any kind of environment and systems depends on separation of concerns. Since software plays a pivotal role in advanced robotic systems, we illustrate how to tailor a service-oriented component-based software approach to robotics, how to support it by a model-driven approach and according tools and how this allows separation of concerns which so far is not yet addressed appropriately in robotics software systems. Experienced software engineers should get insights into the specifics of robotics and should better understand what is in the robotics community needed and expected from the software engineering community. Experienced roboticists should get detailed insights into how model-driven software development (MDSD) and its design abstraction is an approach towards system-level complexity handling and towards decoupling of robotics knowledge from implementational technologies. Practitioners should get insights into how separation of concerns in robotics is supported by a service-oriented component-based software approach and that according tools are already matured enough to make life easier for developers of robotics software and system integrators. Experts in application domains and business consultants should gain insights into maturity levels of robotic software systems and according approaches under a short-term, medium-term and long-term perspective. Students should understand how design abstraction as recurrent principle of computer science applied to software systems results in MDSD, how MDSD can be applied to robotics, how it provides a perspective to overcome the vicious circle of robotics software starting from scratch again and again and how software engineering and robotics can cross-fertilize each other.

Separation of concerns
Separation of concerns is one of the most fundamental principles in software engineering (Chris, 1989;Dijkstra, 1976;Parnas, 1972). It states that a given problem involves different kinds of concerns, promotes their identification and separation in order to solve them separately without requiring detailed knowledge of the other parts, and finally combining them into one result. It is a general problem solving strategy which breaks the problem complexity into loosely-coupled subproblems. The solutions to the subproblems can be composed relatively easily to yield a solution to the original problem (Mili et al., 2004). This allows to cope with complexity and thereby achieving the required engineering quality factors such as robustness, adaptability, maintainability, and reusability. Despite a common agreement on the necessity of the application of the separation of concerns principle, there is not a well-established understanding of the notion of concern. Indeed, concern can be thought of as a unit of modularity (Blogspot, 2008). Progress towards separation of concerns is typically achieved through modularity of programming and encapsulation (or transparency of operation), with the help of information hiding. Advanced uses of this principle allow for simultaneous decomposition according to multiple kinds of (overlapping and interacting) concerns (Tarr et al., 2000). In practice, the principle of separation of concerns should drive the identification of the right decomposition or modularization of a problem. Obviously, there are both: (i) generic and domain-independent patterns of how to decompose and modularize certain problems in a suitable way as well as (ii) patterns driven by domain-specific best practices and use-cases. In most engineering approaches as well as in robotics, at least the following are dominant dimensions of concerns which should be kept apart (Björkelund et al., 2011;Radestock & Eisenbach, 1996): Computation provides the functionality of an entity and can be implemented in different ways (software and/or hardware). Computation activities require communication to access required data and to provide computed results to other entities.
Communication exchanges data between entities (ranging from hardware devices to interfaces for real-world access over software entities to user interfaces etc.).
Configuration comprises the binding of configurable parameters of individual entities. It also comprises the binding of configurable parameters at a system level like, for example, connections between entities.
Coordination is about when is something being done. It determines how the activities of all entities in a system should work together. It relates to orchestration and resource management.
It is important to recognize that there are cross-cutting concerns like quality of service (QoS) that have instantiations within the above dimensions of concerns. Facets of QoS for computation can manifest with respect to time (best effort computation, hard real-time computation) or anytime algorithms (explicated relationship between assigned computing resources and achieved quality of result). Facets of QoS for communication are, for example, response times, latencies and bandwidth. It is also important to recognize that various concerns need to be addressed at different stages of the lifecycle of a system and by different stakeholders. For example, configuration is part of the design phase (a component developer provides dedicated configurable parameters, a system integrator binds some of them for deployment) and of the runtime phase (the task coordination mechanism of a robot modifies parameter settings and changes the connections between entities according to the current situation and task to fulfill). It is perfectly safe to say that robotics should take advantage from insights and successful approaches for complexity handling readily available in other but similar domains like, for example, automotive and avionics industry or embedded systems in general. Instead, robotics often reinvents the wheel instead of exploiting cross-fertilization between robotics and communities like software engineering and middleware systems. The interesting question is whether there are differences in robotics compared to other domains which hinder roboticists from jumping onto already existing and approved solutions. One should also examine whether or not these solutions are tailorable to robotics needs.

Specifics in robotics
The difference of robotics compared to other domains like automotive and avionics is neither the huge variety of different sensors and actuators nor the number of different disciplines being involved nor the diversity of hardware-platforms and software-platforms. In many domains, developers need to deal with heterogeneous hardware devices and are obliged to deploy their software on computers which are often constrained in terms of memory and computational power. We are convinced that differences of robotics compared to other domains originate from the need of a robot to cope with open-ended environments while having only limited resources at its disposal. Limited resources require decisions: when to assign which resources to what activity taking into account perceived situation, current context and tasks to be fulfilled. Finding adequate solutions for this major challenge of engineering robotic systems is difficult for two reasons: • the problem space is huge: as uncertainty of the environment and the number and type of resources available to a robot increase, the definition of the best matching between current situation and correct robot resource exploitation becomes an overwhelming endeavour even for the most skilled robot engineer, • the solution space is huge: in order to enhance overall quality of service like robustness of complex robotic systems in real-world environments, robotic system engineers should master highly heterogeneous technologies, need to integrate them in a consistent and effective way and need to adequately exploit the huge variety of robotic-specific resources.
In consequence, it is impossible to statically assign resources in advance in such a way that all potential situations arising at runtime are properly covered. Due to open-ended real-world environments, there will always be a deviation between design-time optimality and runtime optimality with respect to resource assignments. Therefore, there is a need for dynamic resource assignments at runtime which arises from the enormous sizes of the problem space and the solution space. For example, a robot designer cannot foresee how crowded an elevator will be. Thus, a robot will need to decide by its own and at runtime whether it is possible and convenient to exploit the elevator resource. The robot has to trade the risk of hitting an elevator's user with the risk of arriving late at the next destination. To match the level of safety committed at design-time, the runtime trade-off has to come up with parameters for speed and safety margins whose risk is within the design-time committed boundaries while still implementing the intent to enter the elevator.

Model-centric robotic systems
The above example illustrates why we have to think of engineering advanced robotic systems differently compared to other complex systems. A complex robotic system cannot be treated as design-time finalizable system. At runtime, system configurations need to be changeable according to current situation and context including prioritized assignments of resources to activities, (de)activations of components as well as changes to the wiring between components. At runtime, the robot has to analyze and to decide for the most appropriate configuration. For example, if the current processor load does not allow to run the navigation component at the highest level of quality, the component should be configured to a lower level of navigation quality. A reasonable option to prepare a component to cope with reduced resource assignments might be to reduce the maximum velocity of the robot in order to still guarantee the same level of navigation safety. In consequence, we need to support design-time reasoning (at least by the system engineer) as well as runtime reasoning (by the robot itself) about both, the problem space and the solution space. This can be achieved by raising the level of abstraction at which relevant properties and characteristics of a robotics system are expressed. As for every engineering endeavour, this means to rely on the power of models and asks for an overall different design approach as illustrated in figure 1: • The solution space can be managed by providing advanced design tools for robot software development to design reconfigurable and adaptive robotic systems. Different stakeholders involved in the development of a robotic system need the ability to formally  .
model and relate different views relevant to robotic system design. A major issue is the support of separation of concerns taking into account the specific needs of robotics.
• The problem space can be mastered by giving the robot the ability to reconfigure its internal structure and to adapt the way its resources are exploited according to its understanding of the current situation. Fig. 2. Separation of concerns and design abstraction: models created at design-time are used and manipulated at runtime by the robot .
We coin the term model-centric robotic systems  for the new approach of using models to cover and support the whole life-cycle of robotic systems. Such a model-centric view puts models into focus and bridges design-time and runtime model-usage. During the whole lifecycle, models are refined and enriched step-by-step until finally they become executable. Models comprise variation points which support alternative solutions. Some variation points are purposefully left open at design time and even can be bound earliest at runtime after a specific context and situation dependent information is available.
In consequence, models need to be interpretable not only by a human designer but also by a computer program. At design-time, software tools should understand the models and support designers in their transformations. At runtime, adaptation algorithms should exploit the models to automatically reconfigure the control system according to the operational context (see figure 2). The need to explicitly support the design for runtime adaptability adds robotic-specific requirements on software structures and software engineering processes, gives guidance on how to separate concerns in robotics and allows to understand where the robotics domain needs extended solutions compared to other and at first glance similar domains.

User roles and requirements
Another strong influence on robotic software systems besides technical challenges comes from the involved individuals and their needs. We can distinguish several user roles that all put a different focus on complexity management, on separation of concerns and on software engineering in robotics: End users operate applications based on the provided user interface. They focus on the functionality of readily provided systems. They do not care on how the application has been built and mainly expect reliable operation, easy usage and reasonable value for money. Application builders / system integrators assemble applications out of approved, standardized and reusable off-the-shelf components. Any non trivial robotic application requires the orchestration of several components such as computer vision, sensor fusion, human machine interaction, object recognition, manipulation, localization and mapping, control of multiple hardware devices, etc. Once these parts work together, we call it a system. This part of the development process is called, therefore, system integration. Components can be provided by different vendors. Application builders and system integrators consider components as black boxes and depend on precise specifications and explications of all relevant properties for smooth composition, resource assignments and mappings to target platforms. Components are customized during system level composition by adjusting parameters or filling in application dependent parts at so-called hot spots via plug-in interfaces. Application builders expect support for system-level engineering.
Component builders focus on the specification and implementation of a single component. They want to focus on algorithms and component functionality without being restricted too much with respect to component internals. They don't want to bother with integration issues and expect a framework to support their implementation efforts such that the resulting component is conformant to a system-level black box view.
Framework builders / tool providers prepare and provide tools that allow the different users to focus on their role. They implement the software frameworks and the domain-specific add-ons on top of state-of-the-art and standard software systems (like middleware systems), use latest software technology and make these available to the benefit of robotics. 8

Robotic Systems
The robotics community provides domain-specific concepts, best practices and design patterns of robotics. These are independent of any software technology and implementational technology. They form the body of knowledge of robotics and provide the domain-specific ground for the above roles.
The essence of the work of the component builder is to design reusable components which can seamlessly be integrated into multiple systems and different hardware platforms. A component is considered as a black box. The developer can achieve this abstraction only if he is strictly limited in his knowledge and assumptions about what happens outside his component and what happens inside other components. On the other hand, the methodology and the purpose of the system integrator is opposite: he knows exactly the application of the software system, the platform where it will be deployed and its constraints. For this reason, he is able to take the right decision about the kind of components to be used, how to connect them together and how to configure their parameters and the quality of service of each of them to orchestrate their behavior. The work of the system integrator is rarely reusable by others, because it is intrinsically related to a specific hardware platform and a well-defined and sometimes unique use-case. We don't want the system integrator to modify a component or to understand the internal structure and implementation of the components he assembles.

Separation of roles from an industrial perspective
This distinction between the development of single components and system integration is important ( figure 3). So far, reuse in robotics software is mainly possible at the level of libraries and/or complete frameworks which require system integrators to be component developers and vice versa. A formal separation between component building and system integration introduces another and intermediate level of abstraction for reuse which will make it possible to • create commercial off-the-shelf (COTS) robotic software: when components become independent of any specific robot application, it becomes possible to integrate them quickly into different robotic systems. This abstraction allows the component developer to sell its robotic software component to a system integrator; • overcome the need for the system integrator to be also an expert of robotic algorithms and software development. We want companies devoted to system integration (often SMEs) to take care of the Business-to-Client part of the value chain, but this will be possible only when their work will become less challenging; • establish dedicated system integrators (specific to industrial branches and application domains) apart from experts for robotic components (like navigation, localization, object recognition, speech interaction, etc.); • provide plug-and-play robotic hardware: so far the effort of the integration of the hardware into the platform was undertaken by the system integrator. If manufacturers start providing ready-to-use drivers which work seamlessly in a component-driven environment, robotic applications can be deployed faster and become cheaper.
This separation of roles will eventually have a positive impact in robotics: it will potentially allow the creation of a robotics industry, that is an ecosystem of small, medium and large enterprises which can profitably and symbiotically coexist to provide business-to-business and business-to-client products such as hardware parts, software applications and complete robots with a specific application and deliver a valuable product to the customer.
To understand better what a robotics industry means, we draw an analogy to the personal computer industry. Apart from very few exceptions, we can identify several companies involved in the manufacturing of a single and very specific part of the final product: single hardware components (memories, hard drives, CPU, mother boards, screens, power supplies, graphic cards, etc.), operating systems (Windows, commercial Linux distributions), software applications (CAD, word processing, video games, etc.) and system integrators which provide ready-to-use platforms to the end user.

Service-oriented software components to master system complexity
Software engineering provides three major approaches that help to address the above challenges, that is component-based software engineering (CBSE), service-oriented architectures (SOA) and model-driven software development (MDSD). CBSE separates the component development process from the system development process and aims at component reusability. MDSD separates domain knowledge (formally specified by domain experts) from how it is being implemented (defined by software experts using model transformations). SOA is about the right level of granularity for offering functionality and strictly separates service providers and consumers.

Component-based software engineering
CBSE (Heineman & Councill, 2001) is an approach that has arisen in the software engineering community in the last decade. It shifts the emphasis in system-building from traditional requirements analysis, system design and implementation to composing software systems from a mixture of reusable off-the-shelf and custom-built components. A compact and widely accepted definition of a software component is the following one: "A software component is a unit of composition with contractually specified interfaces and explicit context dependencies only. A software component can be developed independently and is subject to composition by third parties." (Szyperski, 2002).
Software components explicitly consider reusable pieces of software including notions of independence and late composition. CBSE promises the benefits of increased reuse, reduced production cost, and shorter time to market. In order to realize these benefits, it is vital to have components that are easy to reuse and composition mechanisms that can be applied systematically. Composition can take place during different stages of the lifecycle of components that is during the design phase (design and implementation), the deployment phase (system integration) and even the runtime phase (dynamic wiring of data flow according to situation and context). CBSE is based on the explication of all relevant information of a component to make it usable by other software elements whose authors are not known. The key properties of encapsulation and composability result in the following seven criteria that make a good component: "(i) may be used by other software elements (clients), (ii) may be used by clients without the intervention of the component's developers, (iii) includes a specification of all dependencies (hardware and software platform, versions, other components), (iv) includes a precise specification of the functionalities it offers, (v) is usable on the sole basis of that specification, (vi) is composable with other components, (vii) can be integrated into a system quickly and smoothly" (Meyer, 2000).

Service-oriented architectures
Another generally accepted view of a software component is that it is a software unit with provided services and required services. In component models, where components are architectural units, services are represented as ports (Lau & Wang, 2007). This view puts the focus on the question of a proper level of abstraction of offered functionalities. Services "combine information and behavior, hide the internal workings from outside intrusion and present a relatively simple interface to the rest of the program" (Sprott & Wilkes, 2004). The (CBDI Forum, 2011) recommends to define service-oriented architectures (SOA) as follows: SOA are "the policies, practices, frameworks that enable application functionality to be provided and consumed as sets of services published at a granularity relevant to the service consumer. Services can be invoked, published and discovered, and are abstracted away from the implementation using a single, standards-based form of interface" (Sprott & Wilkes, 2004).
Service is the key to communication between providers and consumers and key properties of good service design are summarized as in table 1. SOA is all about style (policy, practice, frameworks) which makes process matters an essential consideration. A SOA has to ensure that services don't get reduced to the status of interfaces, rather they have an identity of their own. With SOA, it is critical to implement processes that ensure that there are at least two different and separate processes -for providers and consumers (Sprott & Wilkes, 2004).
reusable use of service, not reuse by copying of code/implementation abstracted service is abstracted from the implementation published precise, published specification functionality of service interface, not implementation formal formal contract between endpoints places obligations on provider and consumer relevant functionality is presented at a granularity recognized by the user as a meaningful service Table 1. Principles of good service design enabled by characteristics of SOA as formulated in (Sprott & Wilkes, 2004).

Model-driven software development
MDSD is a technology that introduces significant efficiencies and rigor to the theory and practice of software development. It provides a design abstraction as illustrated in figure  4. Abstractions are provided by models (Beydeda et al., 2005). Abstraction is a core principle of software engineering.
"A model is a simplified representation of a system intended to enhance our ability to understand, predict and possibly control the behavior of the system" (Neelamkavil, 1987).  In MDSD, models are used for many purposes, including reasoning about problem and solution domains and documenting the stages of the software lifecycle; the result is improved software quality, improved time-to-value and reduced costs (IBM, 2006).

Runtime Binaries
T r a n s fo r m a ti o n T r a n s fo r m a ti o n T r a n s fo r m a ti o n fo r D e p lo y m e n t T r a n s fo r m a ti o n P e r fo r m D e p lo y m e n t  The standard workflow of a model-driven software development process is illustrated in figure 5. This workflow is supported by tools like the Eclipse Modeling Project (Eclipse Modeling Project, 2010) which provide means to express model-to-model and model-to-code transformations. They import standardized textual XMI representations of the models and can parse them according to the used meta-model. Thus, one can easily introduce domain-specific concepts to forward information from a model-level to the model transformations and code generators. Tools like Papyrus (PAPYRUS UML, 2011) allow for a graphical representation of the various models and can export them into the XMI format. Overall, there is a complete toolchain for graphical modelling and transformation steps available that can be tailored to the domain specific needs of robotics. MDSD is much more than code generation for different platforms to address the technology change problem and to make development more efficient by automatically generating repetitive code. The benefits of MDSD are manifold (Stahl & Völter, 2006;Völter, 2006): (i) models are free of implementation artefacts and directly represent reusable domain knowledge including best practices, (ii) domain experts can play a direct role and are not requested to translate their knowledge into software representations, (iii) design patterns, sophisticated & optimized software structures and approved software solutions can be made available to domain experts and enforced by embedding them in templates for use by highly optimized code generators such that even novices can immediately take advantage from a coded immense experience, (iv) parameters and properties of components required for system level composition and the adaptation to different target systems are explicated and can be modified within a model-based toolchain.

Stable structures and freedom from choice
In robotics, we believe that the cornerstone is a component model based on service-orientation for its provided and required interactions represented in an abstract way in form of models. A robotics component model needs to provide component level as well as system level concepts, structures and building blocks to support separation of concerns while at the same time ensuring composability based on a composition theory: (i) building blocks out of which one composes a component, (ii) patterns of how to design a well-formed component to achieve system level conformance, (iii) guidance towards providing a suitable granularity of services, (iv) specification of the behavior of interactions and (v) best practices and solutions of domain-specific problems. MDSD can then provide toolchains and thereby support separation of concerns and separation of roles. The above approach asks for the identification of stable structures versus variation points (Webber & Gomaa, 2004). A robotics component model has to provide guidance via stable structures where these are required to support separation of concerns and to ensure system level conformance. At the same time, it has to allow for freedom wherever possible. The distinction between stable structures and variation points is of relevance at all levels (operating system interfaces, library interfaces, component internal structures, provided and required services etc.). In fact, identified and enforced stable structures come along with restrictions. However, one has to notice that well thought out limitations are not a universal negative and freedom from choice (Lee & Seshia, 2011) gives guidance and assurance of properties beyond one's responsibilities in order to ensure separation of concerns. As detailed in , stable structures with respect to a service-oriented component-based approach can be identified. These are illustrated in figure 6. At the system level (S), provided and required service ports ① of a component form a stable interface for the application builder. In an ideal situation, all relevant properties of a component are made explicit to support a black box view. Hence, system level properties like resource conformance of the component mapping to the computing platform can be checked during system composition and deployment.
At the component level (C), the component builder wants to rely on a stable interface to the component framework ②. In an ideal situation, the component framework can be considered as black box hiding all operating system and middleware aspects from the user code. The component framework adds the execution container to the user code such that the resulting component is conformant to a black box component view. At the framework level (F), two stable interfaces exist: (i) between the framework and the user code of the component builder ② and (ii) between the framework and the underlying middleware & operating system ③. The stable interface ② ensures that no middleware and operating system specifics are unnecessarily passed on to the component builder. The stable interface ③ ensures that the framework can be mapped onto different implementational technologies (middleware, operating systems) without reimplementing the framework in its entirety. The framework builder maintains the framework which links the stable interfaces ② and ③ and maps the framework onto different implementational technologies via the interface ③.

The SMARTSOFT-approach
The basic idea behind SMARTSOFT (Schlegel, 2011) is to master the component hull and thereby achieve separation of concerns as well as separation of roles. Figure 7 illustrates the SMARTSOFT component model and how its component hull links the stable interfaces ①, ② and ③.   Fig. 8. The views of a component builder and a system integrator on services by the example of a grid map service based on a query communication pattern. Figure 8 illustrates this concept by means of the query communication pattern which consists of a query client and a query server. The query pattern expects two communication objects to define a service: a request object and an answer object. Communication objects are transmitted by-value to ensure decoupling of the lifecycles of the client side and the server side of a service. They are arbitrary objects enriched by a unique identifier and get/set-methods. Hidden from the user and inside the communication patterns, the content of a communication object provided via E gets extracted and forwarded to the middleware interface H. Incoming content at H is put into a new instance of the according communication object before providing access to it via E. In the example, the system integrator sees a provided port based on a query server with the communication objects GridMapRequest and GridMap. The map service might be provided by a map building component. Each component with a port consisting out of a query client with the same communication objects can use that service. For example, a path planning component might need a grid map and expose a required port for that service. The GridMapRequest object provides the parameters of the individual request (for example, the size of the requested map patch, its origin and resolution) and the GridMap returns the answer. The answer is self-contained comprising all the parameters describing the provided map. That allows to interpret the map independently of the current settings of the service providing component and gives the service provider the chance to return a map as close to but different from the requested parameters in case he cannot handle them exactly. A component builder uses the stable interface E. In case of the client side of a service based on the query pattern, it always consists of the same synchronous as well as asynchronous access modes independent from the used communication objects and the underlying middleware. They can be used from any number of threads in any order. The server side in this example always consists of an asynchronous handler upcall for incoming requests and a separated answer method. This separation is important since it does not require the upcall to wait until the answer is available before returning. We can now implement any kind of processing model inside a component, even a processing pipeline where the last thread calls the answer method, without blocking or wasting system resources of the upcall or be obliged to live with the threading models behind the upcall. In the example, the upcall at the service provider either directly processes the incoming GridMapRequest object or forwards it to a separate processing thread. The requested map patch is put into a GridMap object which then is provided as answer via the answer method. It can be seen that the client side is not just a proxy for the server side. Both sides of a communication pattern are completely standalone entities providing stable interfaces A and E by completely hiding all the specifics of H and I (see figure 7). One can neither expose arbitrary member functions at the outside component hull nor can one dilute the semantics and behavior of ports. The different communication patterns and their internals are explained in detail in (Schlegel, 2007).

486
Robotic Systems -Applications, Control and Programming

www.intechopen.com
Besides the services defined by the component builder (A), several predefined services exist to support system level concerns . Each component needs to provide a state service to support system level orchestration (outside view B: activation, deactivation, reconfiguration; inside view F: manage transitions between service activations, support housekeeping activities by entry/exit actions). An optional diagnostic service (C, G) supports runtime monitoring of the component. The optional param service manages parameters by name/value-pairs and allows to change them at runtime. The optional wiring service allows to wire required services of a component at runtime from outside the component. This is needed for task and context dependent composition of behaviors.

The SMARTMARS meta-model
All the stable interfaces, concepts and structures as well as knowledge about which ingredients and structures form a well-formed SMARTSOFT component and a well-formed system of SMARTSOFT components are explicated in the SMARTMARS meta-model ( figure  9). The meta-model is abstract, universally valid and independent from implementation technologies (e.g. UML profile (Fuentes-Fernández & Vallecillo-Moreno, 2004), eCore (Gronback, 2009)). It provides the input for tool support for the different roles (like component developer, system integrator etc.), explicates separation of concerns and can be mapped onto different software technologies (e.g. different types of middleware like CORBA, ACE (Schmidt, 2011) and different types of operating systems).  Fig. 9. Excerpt of the SMARTMARS meta-model.

Policies and strategies behind SMARTSOFT services
A major part of the SMARTSOFT approach are the policies and strategies that manifest themselves in the structure of the component model, explain its building blocks and guide their usage. Separation of the roles of a component developer and a system integrator requires to control the interface between the inner part of a component and its outer part and to control this boundary. As soon as one gains control over the component hull, one can make sure that all relevant properties and parameters needed for the black box view of the system integrator become explicated at the component hull. One can also make sure that a component developer has no chance to expose component internals to the outside. SMARTSOFT achieves this via predefined communication patterns as the only building blocks to define externally visible services and by further guidelines on how to build good services.

487
Robotic Software Systems: From Code-Driven to Model-Driven Software Development

www.intechopen.com
A basic principle is that clients of services are not allowed to make any assumptions about offered services beyond the announced characteristics and that service providers are not allowed to make any assumptions about service requestors (like e.g. their maximum rate of requests). This principle results in simple and precise guidelines of how to apply the communication patterns in order to come up with well-formed services. As long as a service is being offered, the service provider has to accept all incoming requests and has to respond to them according to its announced quality-of-service parameters. We illustrate this principle by means of the query pattern. As long as there are no further quality-of-service attributes, the service provider accepts all incoming requests and guarantees to answer all accepted requests. However, only the service provider knows about its resources available to process incoming requests and clients are not allowed to impose constraints on the service provider (a request might provide further non-committal hints to the service provider like a request priority). Thus, the service provider is allowed to provide a nil answer (the flag is valid is set to false in the answer) in case he is running out of resources to answer a particular request. In consequence, all service requestors always must be prepared to get a nil answer. A service requestor is also not allowed to make any assumptions about the response time as long as according quality-of-service attributes are not set by the service provider. However, if a service provider announces to answer requests within a certain time limit, one can rely on getting at least a nil answer before the deadline. If a service requestor depends on a maximum response time although this quality-of-service attribute is not offered by the service provider, he needs to use client-side timeouts with his request. This overall principle ensures (i) loose coupling of services, (ii) prevents clients from imposing constraints on service providers and (iii) gives service providers the means to arbitrate requests in case of limited resources. It now also becomes evident why SMARTSOFT offers more than just a request/response and a publish/subscribe pattern which would be sufficient to cover all communicational needs. The send pattern explicates a one-way communication although one can emulate it via a query pattern with a void answer object. However, practical experience proved that a much better clarity for services with this characteristic is achieved when offering a separate pattern. The same holds true for the push newest and the push timed pattern. In principle, the push timed pattern is a push newest pattern with a regular update. However, in case of a push newest pattern, service requestors rely on having the latest data available at any time. This is different from a push timed pattern where the focus is on the service provider guaranteeing a regular time interval (in some cases even providing the same data). Although one could cover some of these aspects by quality-of-service attributes, they also have an impact on the kind of perception of its usage by a component developer. Again, achieving clarity and making the characteristics easily recognizable is of particular importance for the strict separation of the roles of component developers and system integrators. This also becomes obvious with the event pattern. In contrast to the push patterns, service requestors get informed only in case a server side event predicate (service requestors individually parametrize each event activation) becomes true. This tremendously saves bandwidth compared to publishing latest changes to all clients since one then always would have to publish a snapshot of the overall context needed to evaluate the predicate at the client side instead of just the information when an event fired. Figure 10 illustrates how the SMARTSOFT component model and its meta-elements provided by SMARTMARS structure and partition a typical robotics use-case, namely the navigation of a mobile platform. Besides access to sensor data and to the mobile base, algorithmic building blocks of a navigation system are map building, path planning, motion execution and self localization. Since these building blocks are generic for navigation systems independently of the used algorithms, it makes sense to come up with an according component structure and services (or expect readily available components and services). The current map is provided by a push newest server port (as soon as a new map is available, it is provided to subscribed clients which makes sense since path planning depends on latest maps) and the longterm map by a query server port (since it is not needed regularly, it makes sense to provide it only on a per-request basis). The state port is used to set the component into different states depending on which services are needed in the current situation: build no map at all (neutral), build the current map only (buildCurr), build the longterm map only (buildLtm) or build both maps (buildBoth). The push newest server publishes the current map only in the states buildCurr and buildBoth. Requests for a longterm map are answered as long as the component and its services are alive but with an invalid map in case it is in the states neutral or buildCurr (valid flag of answer object set to false). Accordingly, the SmartPlannerBreadthFirstSearch component provides its intermediate waypoints by a push newest server (update the motion execution component as soon as new information is available). The motion execution component regularly commands new velocities to the robot base via a send service. The motion execution component is also subscribed to the laser scan service to be able to immediately react to obstacles in dynamic environments. This way, the different services interact to build various control loops to combine goal directed and reactive navigation while at the same time allowing for replacement of components.

State-of-the-art and related work
The historical need in robotics to be responsible for creation of the application logic and to be at the same time the system integrator generated a poor understanding in the robotics community that these two roles ought to be separated. In consequence, most robotics frameworks don't make this distinction and consequently they don't offer any clear guideline to the developer on how to achieve separation of roles. For example, ROS (Quigley et al., 2009) is a currently widely-used framework in robotics providing a huge and valuable codebase. However, it lacks guidance for component developers to ensure system level conformance for composability. Instead, its focus is on side-by-side existence of all kinds of overlapping concepts without an abstract representation of its core features and properties in a way independent of any implementation. The only approach in line with the presented concepts is the RTC Specification (OMG, 2008) which is considered the most advanced concept of MDSD in robotics. However, it is strongly influenced by use-cases requiring a data-flow architecture and they do not yet considerably take into account requirements imposed by runtime adaptability.

Reference implementation of the SMARTMDSD TOOLCHAIN
The reference implementation of the SMARTMDSD TOOLCHAIN implements the SMARTMARS meta-model within a particular MDSD-toolchain. It is used in real world operation to develop components and to compose complex systems out of them. The focus of this section is on technical details of the implementation of a meta-model. Another focus is on the role-specific view and the support a MDSD-toolchain provides. We illustrate the reference implementation of the toolchain along the different roles of the stakeholders and their views on the toolchain.

Decisions and tools behind the reference implementation -framework builder view
The reference implementation of our SMARTMDSD TOOLCHAIN is based on the Eclipse Modeling Project (EMP) (Eclipse Modeling Project, 2010) and Papyrus UML (PAPYRUS UML, 2011). Papyrus UML is used as graphical modeling tool in our toolchain. Therefore, it is customized by the framework builder for the development of SMARTSOFT Components (component builder) and deployments of components (application builder). This includes for example a customized wizard to create communication objects, components as well as deployments. The modeling view of Papyrus UML is enriched with a customized set of meta-elements to create the models. The model transformation and code generation steps are developed with Xpand and Xtend (Efftinge et al., 2008) which are part of the EMP. These internals are not visible to the component builder and the application builder. They just see the graphical modeling tool to create their models and use the CDT Eclipse Plugin (Eclipse CDT, 2011) to extend the source code and to compile binaries. The SMARTMARS meta-model is implemented as a UML Profile (Fuentes-Fernández & Vallecillo-Moreno, 2004) using Papyrus UML. The decision to use UML Profiles and Papyrus UML to implement our toolchain is motivated by the reduced effort to come up with a graphical modeling environment customized to the robotics domain and its requirements by reusing available tools from other communities. Although some shortcomings have to be accepted and taken into account we were not caught in the huge effort related to implementing a full-fledged GMF-based development environment. This allowed us to early come up with our toolchain and to gain deeper insights and more experience on the different levels of abstraction. However, the major drawbacks of UML Profiles are: • UML is a general purpose modeling language covering aspects of several domains and is thus complex. Using profiles, it is only possible to enrich UML, but not to remove elements.
• Deployment and instantiations of components are not adequately supported.
• UML Profiles provide just a lightweight extension of UML. That means, the structure of UML itself cannot be modified. The elements can be customized only by stereotypes and tagged values.
To counter the drawbacks of UML Profiles, we only support the usage of the stereotyped elements provided by SMARTMARS to create the models of the components and deployments. Directly using pure UML elements in the diagrams is not supported. Thus, the models are created using just the meta-elements provided by SMARTMARS. Restricting the usage to SMARTMARS meta-elements, a mapping to another meta-model implementation technology like eCore (Gronback, 2009) is straightforward. The stereotyped elements can be mapped onto eCore without taking into account UML and its structure. In the current implementation of our toolchain, the restriction to only use SMARTMARS meta-elements is enforced with check (Efftinge et al., 2008), the EMP implementation of OCL (Object Management Group, 2010). In the model transformation and code generation steps of our toolchain pure UML elements are ignored. Another approach would be to customize the diagrams by removing the UML elements from the palette (see fig. 12) and thus restricting their usage. The latter approach is on the agenda of the Papyrus UML project and will be supported by future releases. The view of the component builder on the toolchain is depicted in figure 12. It is illustrated by a face recognition component which is a building block in many service robotics scenarios as part of the human-robot interface (detection, identification and memorization of persons). In its active state, the component shall receive camera images, apply face recognition algorithms and report detected and recognized persons. Thus, besides the standard ports for setting states (active, neutral) and parameters, we need to specify a port to receive the latest camera images (based on a push newest client) and another one to report on the results (based on an event server). The component shall run the face recognition based on a commercially available library within one thread and optional visualization mechanisms within a second and separated thread. Thus, we need to specify two tasks within the component. To create the model the component builder uses the SMARTMARS meta-elements offered in the palette. The elements of the created model can be accessed either in the outline view or directly in the graphical representation. Several of the meta-element attributes (tagged values) can be customized and modified in the properties tab (e.g. customizing services to ports, specifying properties of tasks, etc.). The model is stored in files specific to Papyrus UML. Pushing the button, the workflow is started and the PSI (source) files are generated. The user code files are directly accessible in the src folder. The component builder integrates his business logic into these files (in our example, the interaction with the face recognition library). The generated files the component builder must not modify are stored in the gen folder. These files are generated and overwritten each time the workflow is executed. For the further processing of the source files, the Eclipse CDT plugin is used (Makefile Project). The makefile is also generated by the workflow specific to the model properties. User modifications in the makefile can be done inside of protected regions (Gronback, 2009).

Development of components -framework builder view
Taking a look behind the scenes of the toolchain, the workflow ( fig. 13) appears as a two step transformation according to the OMG MDA (Object Management Group & Soley, 2000). The Platform Independent Model (PIM), which is created by the component builder using the meta-elements provided by the PIM UML Profile, specifies the component independently of the implementation technology. The first step in the workflow is the model-to-model is used to specify the unit in which time values are annotated. In the UML Profile for the CORBA-based PSM, an abstract task is specified (cannot be instantiated) and the two variants (1) standard task and (2) realtime task are derived from it. They are both not abstract and can thus be instantiated by the component builder to create the model. The standard task adds an optional attribute referencing to a SMARTTIMER meta-element. This is used to emulate periodic non-realtime tasks which are not natively supported by standard tasks of the CORBA-based SMARTSOFT implementation.

Model transformation and code generation steps
The M2M transformation maps the platform independent elements of the PIM onto platform specific elements of the selected target platform. Such a mapping is illustrated by the example of the SmartTask ( fig. 15 left) and the CORBA-based PSM. The SMARTTASK comprises several elements which are necessary to describe a task behavior and its characteristics.   Depending on the attribute isRealtime the SMARTTASK is either mapped onto a RTAITASK or a non-realtime SMARTCORBATASK 1 .T h eXtend transformation rule to transform the PIM SMARTTASK into the appropriate PSM element is depicted in figure 16. In case the attributes specify a non-realtime, periodic SMARTTASK, the toolchain extends the PSM by the elements needed to emulate periodic tasks (as this feature is not covered by standard tasks). In each case the user integrates his algorithms and libraries into the stable interface provided by the SMARTTASK (component builder view) independent of the hidden internal mapping of the SMARTTASK (generated code). Figure 17 depicts the Xpand template to generate the user code file for the task in the PSI. The figure shows the template on the left and the generated code on the right. The PSI consists of the SMARTSOFT library, the generated code and the user code ( fig. 15  right). To be able to re-generate parts of the component source code according to modified parameters in the model without affecting the source code parts added by the component builder, the generation gap pattern (Vlissides, 2009) is used. It is based on inheritancethe user code inherits from the generated code 2 . The source files called generated code are generated each time the transformation workflow in the toolchain is executed. These files contain the logic which is generated behind the scenes according to the model parameters and must not be modified by the component builder. The source files called user code are just generated if they do not already exist. They are intended for the component builder to add the algorithms and libraries. The generation of the user code files is more for the convenience of the component builder to have a code template as starting point. These files are in the full responsibility of the component builder and are never modified or overwritten by the transformation workflow of the toolchain. In this context generate once means that the file is only generated if it does not already exist. This is typically the case if the workflow is executed for the first time. The clear separation of generated code and user code by the generation gap pattern allows on the one hand to reflect modifications of the model in the generated source code without overwriting the user parts. On the other hand it gives the user the freedom to structure his source code according to his needs and does not restrict the structure as would be the case with, for example, protected regions. Consequently, the component builder can modify the period, priority or even the isRealtime attribute of the task in the model, re-generate and compile the code without requiring any modification in the user code files. The modification in the model just affects the generated code part of the PSI.

Deployment of components -application builder view
The deployment is used to compose a robotic system out of available components. The application builder imports the desired components and places them onto the target platform. Furthermore, he defines the initial wiring of the components by connecting the ports with the meta-element Connection. Figure 18 illustrates the composition of navigation Fig. 18. Screenshot of our toolchain showing the deployment of components to build a robotic system. components. In this example, the application builder (system integrator) imports components specific to a particular robot platform (SmartPioneerBaseServer) and specific to a particular sensor (SmartLaserLMS200Server). The navigation components (SmartMapperGridMap, SmartPlannerBreadthFirstSearch, SmartCDLServer) can be used across different mobile robots. The SmartRobotConsole provides a user interface to command the robot. The components are presented to the application builder as black boxes with dedicated variation points. These have to be bound during the deployment step and can be specified according to system level requirements. For example, a laser ranger component might need the coordinates of its mounting point relative to the robot coordinate system. One might also reduce the maximum scanning frequency to save computing resources. Parameters also need to be bound for the target system. For example, in case RTAI is used inside of a component, the RTAI scheduler parameters (timer model underlying RTAI: periodic, oneshot) of the target RTAI system have to be specified. If the application builder forgets to bind required settings, this absence is reported to him by the toolchain. The application builder can identify the provided and required services of a component via its ports. He can inspect its characteristics by clicking on the port icon which opens a property view. That comprises the communication pattern type, the used communication objects and further characteristics like service name and also port specific information like update frequencies. The initial wiring is done within the graphical representation of the model. In case the application builder wants to connect incompatible ports, the toolchain refuses the connection and gives further hints on the reasons. If the CORBA-based implementation of SMARTSOFT is used, the CORBA naming service properties IP-address and port-number have to be set. Furthermore, the deployment type (local, remote) has to be selected. For a remote deployment, the IP-address, username and target folder of the target computer have to be specified. The deployed system is copied to the target computer and can be executed there. In case of a local deployment, the system is customized to run on the local machine of the application builder. This is, for example, the case if no real robot is used and the deployed system uses simulation components (e.g. Gazebo). Depending on the initial wiring, parameter files are generated and also copied into the deployment folder. These parameter files contain application specific adjustments of the components. In addition, a shell script to start the system is generated out of the deployment model.

Deployment of components -framework builder view
To implement the deployment of components, some meta-elements are added by the framework builder to the UML Profile ( fig. 19). This section focuses on the CORBA-based deployment. Fig. 19. Meta-elements to support the deployment of components.
The deployment model contains relevant information like the initial wiring between components (Connection), naming service properties (CorbaNamingService), scheduler properties (RTAISetup) and parameters about the deployment itself (CorbaSmartSoftTarget). The models of the components are made available to the deployment model using the UML import mechanism. This allows to access the internal structure of the components. Out of the deployment model the parameter files and a start script are generated (M2T) using Xpand and Xtend in a similar way as these transformation languages are used to generate code for the components. Based on the deployment model several analysis and simulation models can be generated to get feedback from 3rd-party tools. For example, one can extract parameters of all realtime tasks mapped onto a specific processor to perform hard realtime schedulability analysis (CHEDDAR (Cheddar, 2010)) . As deployments and especially instantiations of components are not sufficiently supported by UML, a few workarounds are necessary as long as the SMARTMARS meta-model is implemented as UML Profile. For example, a robot with two laser range finders (front, rear) requires two instances of the same component. Each laser instance requires its individual parameters (e.g. serial port, pose on robot). These parameters are assigned to the deployment model by the application builder specifically for each component. In the implementation based on the UML Profile, we hence work on copies of components. Individual instances with their own parameter sets are considered in the abstract SMARTMARS meta-model and are also covered in the SMARTSOFT implementation, thus switching to a different meta-model implementation technology would allow for instances. This has not yet been done due to the huge manpower needed compared to just reusing UML tools.

Example / scenario
The work presented has been used to build and run several real-world scenarios, including the participation at the RoboCup@Home challenge. Among other tasks our robot "Kate" can follow persons, deliver drinks, recognize persons and objects and interact with humans by gestures and speech.
In the clean-up scenario 3 ( fig. 20) the robot approaches a table, recognizes the objects which are placed on the table and cleans the table either by throwing the objects into the trash bin or into the kitchen sink. There are different objects, like cups, beverage cans and different types of crisp cans. The cups can be stacked into each other and have to be thrown into the kitchen sink. Beverage cans can be stacked into crisp cans and have to be thrown into the trash bin. Depending on the type of crisp can, one or two beverage cans can be stacked into one crisp can. After throwing some of the objects into the correct disposal the robot has to decide whether to drive back to the table to clean up the remaining objects (if existing) or to drive to the operator and announce the result of the cleaning task. The robot reports whether all objects on the table could be cleaned up or, in case any problems occurred, reports how many objects are still left. Such complex and different scenarios can neither be developed from scratch nor can their overall system complexity be handled without using appropriate software engineering methods. Due to their overall complexity and richness, they are considered as convincing stress test for the proposed approach. In the following the development of the cleanup example scenario is illustrated according to the different roles.
The framework builder provides the tools to develop SMARTSOFT components as well as to perform deployments of components to build a robotic system. In the described example this includes the CORBA-based implementation of the SMARTSOFT framework and the SMARTMDSD toolchain which are both available on Sourceforge (http:// smart-robotics.sourceforge.net).
The component builder view of the SMARTMDSD toolchain supports component builders to develop their components independently of each other, but based on agreed interfaces. These components are independent of the concrete implementation technology of SMARTSOFT. Component builders provide their components in a component shelf. The models of the components include all information to allow a black-box view of the components (e.g. services, properties, resources). The explication of such information about the components is required by the application builder to compose robotic systems in a systematic way. To orchestrate the components at run-time, the task coordination language SMARTTCL  is used. Therefore, SMARTTCL is wrapped by a SMARTSOFT component and is also provided in the component shelf. The SMARTTCL component provides reusable action plots which can be composed and extended to form the desired behavior of the robot. The application builder uses the application builder view of the SMARTMDSD toolchain. He composes already existing components to build the complete robotic system. In the above described cleanup scenario, 17 components (e.g. mapping, path planning, collision avoidance, laser ranger, robot-base) are reused from the component shelf. It is worth noting that the components were not particularly developed for the cleanup scenario, but can be used in the cleanup scenario due to the generic services they provide. The SMARTTCL sequencer component is customized according to the desired behavior of the cleanup scenario. Therefore, several of the already existing action plots can be reused. Application specific extensions are added by the application builder. At run-time the SMARTTCL sequencer component coordinates the software components of the robot by modifying the configuration and parametrization as well as the wiring between the components. As SMARTTCL can access the information (e.g. parameters, resources) explicated in the models of the components at run-time, this information can be taken into account by the decision making process. That allows the robot not only to take the current situation and context into account, but also the configuration and resource usage of the components. In the described scenario, the sequencer manages the resources of the overall system, for example, by switching off components which are not required in the current situation. While the robot is manipulating objects on the table and requires all available computational resources for the trajectory planning of the manipulator, the components for navigation are switched off.

Conclusion
The service-oriented component-based software approach allows separation of roles and is an important step towards the overall vision of a robotics software component shelf. The feasibility of the overall approach has been demonstrated by an Eclipse-based toolchain and its application within complex Robocup@Home scenarios. Next steps towards model-centric robotic systems that comprehensively bridge design-time and runtime model usage now become viable. This book brings together some of the latest research in robot applications, control, modeling, sensors and algorithms. Consisting of three main sections, the first section of the book has a focus on robotic surgery, rehabilitation, self-assembly, while the second section offers an insight into the area of control with discussions on exoskeleton control and robot learning among others. The third section is on vision and ultrasonic sensors which is followed by a series of chapters which include a focus on the programming of intelligent service robots and systems adaptations.