Arunkumar Ramaswamy

A Model-Driven Framework Development Methodology for Robotic Systems by

Keywords: ADL Architecture Description Language, AET Average Execution Time, AMAL Architecture Modeling and Analysis Language, AQL Acceleo Query Language, CBSE Component Based Software Engineering, CIM Computation Independent Model, CPC Component-Port-Connector, DSL Domain Specic Language KAOS Knowledge Acquisition in Automated Specication OCL Object Constraints Language OMG Object Management Group, PCL Point Cloud Library, PDM Platform Dependent Model, PFH Point Feature Histogram, PHD Probability Hypothesis Density, PIM Platform Independent Model SOA Service Oriented Architecture, SoC Separation of Concerns, SSML Solution Space Modeling Language, TCA Task Control Architecture, UML Unied Modeling Language, WCET Worst Case Execution Time, XMI XML Metadata Interchange, XML eXtensible

Most innovative applications having robotic capabilities like self-driving cars are developed from scratch with little reuse of design or code artifacts from previous similar projects. As a result, work at times is duplicated adding time and economic costs. To address this, standardization, benchmarking, and formalization activities in robotics are being undertaken by many technical working groups and independent agencies such as, IEEE, ISO, and OMG. Absence of integrated tools is the real barrier that exists between early adopters of such eorts and early majority of research and industrial community. In addition, Robotic systems are becoming more safety critical systems as they are deployed in unstructured human-centered environments. These software intensive systems are composed of distributed, heterogeneous software components interacting in a highly dynamic, uncertain environment. However, no signicant systematic software development process is followed in robotics research. This is AADL Architecture Analysis and Design Language.

a real barrier for system level performance analysis and reasoning, which are in turn required for scalable benchmarking methods and reusing existing software.

The process of developing robotic software frameworks and tools for designing robotic architectures is expensive both in terms of time and eort, and absence of systematic approach may result in ad hoc designs that are not exible and reusable.

Therefore, within the context of architecture design, component development, and their support tools, a coherent practice is required for developing architectural frameworks. Making architecture meta-framework a point of conformance opens new possibilities for interoperability and knowledge sharing in the architecture and framework communities. We tried to make a step in this direction by proposing a common model and by providing a systematic methodological approach that helps in specifying dierent aspects of software architecture development and their interplay in a framework.

As a part of the methodology, we also propose a solution space modeling language for design space exploration by modeling the functional as well as non-functional properties of the components.

I

Résumé :

La plupart des applications robotiques, telles que les véhicules autonomes, sont développées à partir d'une page blanche avec quelques rares réutilisations de conceptions ou de codes issus d'anciens projets équivalents. Pour répondre à ce problème, les activités de standardisation, d'évaluation, et de formalisation en robotique sont actuellement prises en charge par de nombreux groupes de travail, ainsi que par des agences indépendantes telles que l'IEEE, l'ISO, et l'OMG. L'absence d'outils intégrés rend difficile la communication entre les organismes menant cet effort, et la majorité des chercheurs et industriels. Qui plus est, les systèmes robotiques deviennent de plus en plus critiques, dans la mesure où ils sont déployés dans des environnements peu structurés, et centrés sur l'humain. Ces systèmes à fort contenu logiciel qui utilisent des composants distribués et hétérogènes interagissent dans un environnement dynamique, et incertain. Cependant, aucun processus de développement de logiciel n'est systématiquement suivi dans le cadre de la recherche en robotique, ce qui complique la réflexion au niveau système, ainsi que l'évaluation complète des performances d'un système robotique. Or, il s'agit là d'étapes indispensables pour la mise en place de méthodes d'évaluation extensibles, ainsi que pour permettre la réutilisation de composants logiciels pré-existants.

Le développement de structures logicielles et d'outils de conception d'architectures, orientés pour la robotique, coûte cher en termes de temps et d'effort, et l'absence d'une approche systématique pourrait conduire à la production de conceptions adhoc, peu flexibles et peu réutilisables. De ce fait, dans le cadre de la conception d'architectures, et du développement de composants, et de la mise en place d'outil correspondant, une pratique cohérente est obligatoire pour le développement de structures architecturales. Faire de la meta-structure de l'architecture un point de convergence offre de nouvelles possibilités en termes d'interopérabilité, et de partage de la connaissance, au sein des communautés dédiées à la mise en place d'architectures et de structures. Nous suivons cette direction, en proposant un modèle commun, et en fournissant une approche méthodologique systématique aidant à spécifier les différents aspects du développement d'architectures logicielles, et leurs relations au sein d'une structure partagée. Dans le cadre de cette méthodologie, nous proposons également un langage de modélisation de l'espace de solution pour l'exploration de l'espace de conception, par la modélisation des propriétés fonctionnelles et nonfonctionnelles des composants.

II values for a property and a navigator for browsing history of values . Sir Issac Newton

A robotic system is a software intensive system that is composed of distributed, heterogeneous software components interacting in a highly dynamic and uncertain environment. According to IEEE 1471-2000 standard, a software-intensive system is "any system where software contributes essential inuences to the design, construction, deployment, and evolution of the system as a whole" [START_REF] Hilliard | Recommended Practice for Architectural Description of Software-Intensive Systems[END_REF]. However, a major part of the robotics research concentrates on the delivery of proof of concepts" in order to substantiate the researcher's idea, for example, a robust path planning algorithm or a real-time collision detection system. Typically, these are developed from scratch or by using external code-based libraries [START_REF] Harris | Survey of popular robotics simulators, frameworks, and toolkits[END_REF]. Nevertheless, when such components are composed with other functional modules, the system does not exhibit the expected behavior. Hence, the approach in which dierent functionalities are integrated, commonly known as architecture of the system, determine the overall behavior of the robot. Therefore, the robot architecture inuences the system emergent behavior to a large extent even when the behavior of individual functional components are known [START_REF] Mataric | Designing emergent behaviors: From local interactions to collective intelligence[END_REF].

In order to address challenges posed by large scale integration eorts in robotics, many researchers have created a wide variety of frameworks [START_REF] Mohamed | Middleware for robotics: A survey[END_REF]. These frameworks helped to manage complexity to some extent, and facilitated rapid prototyping of software for experiments, resulting in the many robotic software systems that are currently being used in academics and industry. Each of these frameworks was designed for addressing a particular purpose, perhaps in response to perceived weaknesses of other available frameworks, or to place emphasis on aspects, which were seen as most important in their own development process. However, relying on a given library results in applications that cannot be easily portable.

Issac Newton once stated that "If I have seen further it is by standing on the shoulders of giants" and he acknowledges the process of discovering truth by building on previous discoveries. The statement is highly relevant in this current era of rapid technological progress, where most of the technical progress is built on the foundations of earlier innovations [START_REF] Scotchmer | Standing on the Shoulders of Giants: Cumulative Research and the Patent Law[END_REF]. Most of the innovative robotic projects, e.g., in government funded projects, and systems, where robotics research plays a vital role, e.g., self-driving cars, are built almost from scratch every time with little reuse of design or code artifacts from previous similar projects. This is mainly due to the fact that software components developed are hard-bound to their operational context and thus they are least reusable. Component Based Software Engineering (CBSE) is proposed in Robotics to manage complexity, reusability, and portability. In CBSE, components are standalone systems having predened interfaces, which perform a specic functionality. Typically, these components use a communication middleware to interact with each other and do not impose any specic architecture on the designer. However, such techniques did not solve the challenges raised by the robotics domain where the systems are deployed in uncertain real-world environment. The core problem is that when such components are merged and/or combined with other functional modules, the system does not always exhibit the expected behavior. The fundamental tenet in this process is to reuse existing works and to benchmark one's invention with others. Scenario and application based benchmarking techniques are often considered in robotics. However, such techniques are not scalable enough considering the open-ended, unstructured, and dynamic environments where robots are deployed. In addition, large application domains in robotics make it more complex.

We believe that the replication and benchmarking of such complex systems should be performed at higher abstraction levels and with better formalized process and quantitative evaluation procedures. This is dicult with the absence of formal specication and specialized tools.

Software Engineering in Robotics

Software plays a key role in robotics as it is the medium to embody intelligence in the machine [START_REF] Brugali | Software Engineering for Robotics[END_REF]. Since robotics and their application are becoming more pervasive than ever, software in these systems is often required to [START_REF] Schmidt | Model-driven engineering[END_REF] operate in distributed and embedded environment consisting of diverse computational capabilities, (2) interact in various communication paradigms, (3) adapt to changes in an indeterministic environment, and nally (4) should behave rationally. Despite advances in programming languages and supporting tools, code-centric development of such complex systems requires immense eort.

The fundamental tenet of Software Engineering (SE) is that the development and evolution of software systems can be facilitated by adopting a systematic, disciplined, quantiable approach in each phases of a software application's life span, from requirements analysis, system architecture denition, and component design to code implementation, testing, and deployment [START_REF] Brugali | Software Engineering for Robotics[END_REF]. Despite this understanding, it is still common for an engineering team to develop the decision-making and control system of a robotics system from scratch, only to discover that it is too dicult to separate this software from the rest of the system and reuse it [START_REF] Medvidovic | Engineering Heterogeneous Robotics Systems: A Software Architecture Based Approach[END_REF]. In the past, the robotics community has been shown reluctance in adopting modern software engineering methods for developing software architectures. This has led to the increased time-to-market and large system integration eorts when such systems are to be used in safety critical applications.

In the last two decades, the robotics research community has seen a large number of middlewares, code libraries, and component frameworks developed by dierent research laboratories and universities. They facilitate software development by providing infrastructure for communication (e.g., ROS [START_REF] Quigley | ROS: an Open-source Robot Operating System[END_REF]), real-time control (e.g., Orocos [START_REF] Bruyninckx | Open robot control software: the OROCOS project[END_REF]), abstract access to sensors and actuators (e.g., Player [START_REF] Gerkey | The player/stage project: Tools for multi-robot and distributed sensor systems[END_REF]), algorithm reuse (e.g., OpenCV [START_REF] Bradski | Learning OpenCV: Computer vision with the OpenCV library[END_REF], PCL [START_REF] Rusu | 3D is here: Point cloud library (PCL)[END_REF]), and simulation (e.g., Stage [START_REF] Gerkey | The player/stage project: Tools for multi-robot and distributed sensor systems[END_REF], Gazebo [START_REF] Koenig | Design and Use Paradigms for Gazebo, An Open-Source Multi-Robot Simulator[END_REF]).

To a large extent, these frameworks have helped in rapid prototyping of individual functionalities, but system level analysis still remains an issue. Usually, the system Figure 1-1: Deviation from linear problem solving caused by wicked problems [START_REF] Schmidt | Model-driven engineering[END_REF] level properties, such as response time, exibility, and deployment have been realized as accidental outcomes, rather than a design decision. It is high time that roboticists transform themselves as system thinkers in addition to being domain experts.

Motivated by the positive results from the application of Model-driven Software Development (MDSD) in other domains, such as automotive, avionics, etc., there is an encouraging trend in its adoption in the robotics domain [START_REF] Schlegel | Robotic Software Systems: From Code-Driven to Model-Driven Software Development[END_REF]. MDSD helps the domain experts shift their focus from implementation to the problem space. The robotic software architects are attracted by the fact that appropriately selecting the viewpoints and levels of abstraction, the system can be analyzed more eciently.

However, the model-driven work ow cannot directly be applied in the robotics domain. The unpredictability spans over various phases in software development -from requirement specication, system design, implementation, integration, and till it is deployed in real world scenarios. The system cannot be realized in an uni-directional process ow because the solution for a robotic problem cannot be nalized during the design time. It is because neither the problem space nor the target environment can be completely modeled as in embedded systems.

Realizing MDSD vision requires addressing a variety of complex interrelated soft-ware engineering problems that is further aggravated by the issues intrinsic to the robotics domain. The use of MDSD in software lifecycle is considered to be a 'wicked problem' [START_REF] France | Model-driven Development of Complex Software: A Research Roadmap[END_REF]. A wicked problem has multiple dimensions that are related in complex ways and thus cannot be solved by cobbling solutions to the dierent problem dimensions. In many of the complex robotics systems, the development of software in a linear fashion is not practically possible. It is because the problem is not well understood until a solution is developed. The Figure 1-1, which is inspired from an article by Douglas C. Schmidt, illustrates several iterations between problem understanding and solution that exists during software design, implementation, and testing [START_REF] Schmidt | Model-driven engineering[END_REF]. To cope with the problem of software complexity MDSD researchers need to develop technologies that developers can use to generate domain-specic software development methodology and associated tools. Such Integrated Development Environment (IDE) should consist of languages and supporting infrastructure that are tailored to the robotic applications. Developing such technologies requires codifying knowledge that reects a deep understanding of the common and variable aspects of the gap bridging process. Such an understanding can be gained only through costly experimentation and systematic accumulation and examination of experience. Developing such technologies is thus a wicked problem [START_REF] France | Model-driven Development of Complex Software: A Research Roadmap[END_REF].

Model-Driven Software Engineering

In Model-Driven Software Engineering (MDSE), modeling techniques are used to tame the complexity of bridging the gap between the problem domain and the software implementation domain [START_REF] France | Model-driven Development of Complex Software: A Research Roadmap[END_REF]. Although component-based development and modeldriven engineering address complexity management, the former adopts a bottom-up approach, while the latter is more top-down in nature [START_REF] Torngren | Component-based vs. Model-based Development: A Comparison in the Context of Vehicular Embedded Systems[END_REF]. In MDSE, the complexity of the software is managed by using the mechanism called `separation of concerns (SoC)'. In MDSE approach, abstract models are gradually converted into concrete executable models by a series of systematic transformation processes. Models are designed based on meta-models and domain-specic language(DSLs).

The next section has two objectives:

1. To identify the current model-driven approaches in robotics.

2. Analyze how the identied approaches achieve general modeling related advantages and how eective they are in satisfying robot specic requirements.

We evaluate the identied approaches in robotics by addressing the following questions:

-How is domain knowledge modeled and how it is used in various phases of software development?

-What are the common Separation of Concerns (SoC) that are relevant in robotics and how these SoCs are used for analyzing the desirable properties and facilitate system level reasoning?

-How are the models used at run-time?

-How are the non-functional properties incorporated in the system?

-How are the robotic component specic requirements, such as composability, compositionality, variability, technology neutrality, addressed in these systems?

MDSE Approaches in Robotics

This section provides an overview of some of the MDSD approaches available in robotics. To the best of our knowledge, there are four model based approaches in robotics: BRICS [START_REF] Klotzbuecher | The BRICS Component Model: A Model-Based Development Paradigm For Complex Robotics Software Systems[END_REF], RobotML [START_REF] Dhouib | RobotML, a Domain-Specic Language to Design, Simulate and Deploy Robotic Applications[END_REF], SmartSoft [START_REF] Schlegel | Robotic Software Systems: From Code-Driven to Model-Driven Software Development[END_REF], and V3CMM [START_REF] Alonso | V3CMM: a 3-View Component Meta-Model for Model-Driven Robotic Software Development[END_REF] approach.

There are many component-based approaches, in which modeling is mainly used for generating basic skeleton codes rather than using models as a developmental artifact.

These four model-based approaches are briey described below: Port represent the type of communication, for example: dataow, events, service calls, etc. and the connectors connect two compatible ports. The components are congured by using their visible properties, for example: maximum iterations for a planning algorithm. The compositional aspect concerns the interaction between the other 4 concerns. The BRICS approach is built using Eclipse and all the concepts are currently not integrated in the toolchain. The workow can be roughly summarized as follows:

BRICS Component Model

1. Dene the structural architecture by using components, port, and connectors.

2. Dene a coordinator for each composite component using state machines. The workow is described below:

1. Dene the architecture using a component-port-connector diagram.

2. Dene the communication policy between components by setting the port attributes.

3. Dene the behavioral model of each component using state machines.

4. Create a deployment plan by allocating the components to a middleware or a simulator.

5. Execute Model to Text (M2T) transformation to generate the executable code.

SmartSoft

SmartSoft [START_REF] Schlegel | Robotic Software Systems: From Code-Driven to Model-Driven Software Development[END_REF] employs a model-driven approach in creating component skeleton 2. The platform specic information is then added to a PIM and component attributes are rened (e.g., wcet: 80 ms [estimation]).

3. In the deployment phase, a system is designed by wiring the components and system level parameters are extracted with the help of a Platform Description Model (PDM) (e.g., wcet: 85 ms [measurement]).

4. The timing parameters of system are exported to an external tool called Cheddar [START_REF] Singho | Cheddar : a Flexible Real Time Scheduling Framework[END_REF] to analyze for the timing analysis.

5. The PSI is generated from Platform-Specic Model (PSM) using Model to Text (M2T) transformation.

V 3 CMM V 3 CMM component meta-model consists of three complementary views: structural, coordination, and algorithmic views [START_REF] Alonso | V3CMM: a 3-View Component Meta-Model for Model-Driven Robotic Software Development[END_REF]. The structural view describes the static structure of the components, coordination view describes the event-driven behavior of the components and the algorithmic view describes the algorithm executed by each component based on its current state. The structural view consists of component, ports, interfaces and their interconnections. The coordination model is dened using UML state machines, while algorithmic view consist of UML activity diagrams. The workow is described below:

1. Dene the common data types and interfaces.

2. Create the simple and complex component denitions.

3. Design the behavioral model of each component using the UML state machines.

4. Design the algorithmic models using the UML activity diagrams.

5. Link activities to state machines and state machines to components.

Feature Analysis

An overview of features available in each approach is depicted in Table 1.1. We have identied these required features from our previous research work as detailed in [START_REF] Ramaswamy | Component Based Decision Architecture for Reliable Autonomous Systems[END_REF].

A brief discussions on these features are provided in the following sections:

Separation of Concerns

In MDSD, the complexity of the software is managed `Separation of Concerns (SoC)'.

Vertical SoC is built on multiple levels of abstraction. Model Driven Architecture (MDA), a model-driven architecture standardized by OMG species four abstraction layers -Computation-Independent Model (CIM), Platform-Independent Model (PIM), Platform-Specic Model (PSM), and Platform-Specic Implementation (PSI) [START_REF]OMG: Model-Driven Architecture, Object Management Group Std[END_REF]. Horizontal SoC manages complexity by providing dierent overlapping viewpoints of the model at the same abstraction level. All of the MDSD approaches in robotics primarily use only two vertical SoC -PIM and PSI. Horizontal SoC is seen only in one of the abstraction layer -PIM. We depict a comparison of SoCs for the four approaches in Figure 1-2.

Composability

A model is said to be composable if its core properties do not change upon integration. In other words, the composability of a model guarantees preservation of its properties across integration with other components. A highly composable model can freely move around in the design space and assemble itself to a more complex structure that is semantically correct. However, functional composability such as, semantic correctness and non-functional composability of the composed models are not addressed in any of the approaches. It is very important in robotics since the components are highly heterogeneous in nature in terms of semantics and necessary for providing unambiguous interfaces. For example, the authors of [START_REF] Laet | Geometric Relations between Rigid Bodies: Semantics for Standardization[END_REF], in their proposal of standardization, have provided approximately 24 dierent ways of representing a geometric relation between rigid bodies and have proposed a DSL based on it [START_REF] Laet | Domain Specic Language for Geometric Relations between Rigid Bodies targeted to robotic applications[END_REF].

Compositionality

Compositionality allows to deduce properties of a composite component models from its constituent components. It enables hierarchical composition of components and provides correctness of the structure. The reusability of a component is enhanced by providing compile-time guarantees by verifying that formal parameters and actual parameters match regardless of the software module's location. The behavior of the reused components can be predicted in the new conguration and the result of the composition can be analyzed for anomalies. Only syntactic correctness of the architecture is addressed in all the approaches. It is worth mentioning that the works associated with Ptolemy [START_REF] Buck | Ptolemy: A framework for simulating and prototyping heterogeneous systems[END_REF] framework provide formal proofs for correctness when heterogeneous actors with dierent models of computation are composed. The major hindrance in robotics is the lack of standards, however, the robotics domain task force at OMG [START_REF] Kotoku | Robot Middleware and its Standardization in OMG-Report on OMG Technical Meetings in St. Louis and Boston[END_REF] and standard committee at IEEE Robotics and Automation society is in the process of standardization. The European project `RoSta' provides standards and a reference architecture for service robots [START_REF] Rosta | Robot Standards and Reference Architectures[END_REF]. Most of the approaches previously analyzed does not provide support for the composability and compositionality properties. Smartsoft provides composability at the service level by explicating Quality of Service (QoS) parameters and required resources [START_REF] Steck | Towards Quality of Service and Resource Aware Robotic Systems through Model-Driven Software Development[END_REF]. This is due to the fact that the component attributes are not explicitly modeled using formal methods.

Static and Dynamic Variability

Static variability is the conguration of the system and dynamic variability is related to the context dependent coordination of the components. Conguration denes which system can communicate with each other and coordination determines when such communication can occur. Conguration can be completely specied during design time while coordination is achieved by allowing variability during design time and run-time dynamic invocation. Static variability and limited context-dependent dynamic variability is provided by the analyzed approaches. SmartSoft models variation points, context, QoS, and Adaptation rules using the Variability Modeling Language (VML) to support run-time variability for service robotics [START_REF] Inglés-Romero | Dealing with Run-Time Variability in Service Robotics: Towards a DSL for Non-Functional Properties[END_REF]. BRICS uses feature models similar to the one used in Software Product Line (SPL) to specify, implement, and constraint resolution of variabilities and provide graphical models for selecting possible conguration during design time [START_REF] Gherardi | An eclipse-based Feature Models toolchain[END_REF]. Recently the authors of [START_REF] Lotz | Towards a stepwise variability management process for complex systems: A robotics perspective[END_REF] have proposed an approach for dynamic variability modeling and its exploitation at run-time for robotic systems.

Technology Neutrality

The component properties and specication should not depend on a specic technology. Software technology neutrality and hardware neutrality to some extent are achieved by many of the already available code-based frameworks, such as, ROS [START_REF] Quigley | ROS: an Open-source Robot Operating System[END_REF],

Player project [START_REF] Gerkey | The player/stage project: Tools for multi-robot and distributed sensor systems[END_REF], etc. To a larger extent, all the MDSD approaches have achieved middleware independence by using various M2T approaches for generation of executable code.

Modeling Domain knowledge

A primary focus of MDSD is the separation of domain knowledge and implementation details. Among the compared approaches, domain knowledge is explicitly modeled only in RobotML. In RobotML, the DSL is designed with the robot domain ontology as the backbone. In fact, the domain concepts that are required while designing the DSL is derived from the ontology. The ontology is used for two purposes -to normalize the robot domain concepts and to act as an inference mechanism during runtime [START_REF] Lortal | Integrating Ontological Domain Knowledge into a Robotic DSL[END_REF].

However, it is not clear from the literature how the ontologies can eectively be used for modeling developmental and run-time models.

Round-tripping Problem

Round-tripping is a major concern of a model

System level reasoning

SmartSoft and RobotML provide support to some extend to reason about the timing analysis of the models at the system level. Properties such as WCET, Periods, etc, are provided as attributes to components. During the system deployment these properties are exported to an external tool `Cheddar' for schedulability analysis [START_REF] Schlegel | Design Abstraction and Processes in Robotics: From Code-Driven to Model-Driven Engineering[END_REF]. Semantic reasoning is not yet realized in any approaches because of the lack of standards.

Run-time Models

In robotics, the adaptation of the robotic system to the dynamic environments are in the computational algorithms of the constituent systems. This severely limits the conguration space of such systems. Explicit modeling of the variabilities and variation points during the system design can help nd the best possible solution during run-time and can lead to the use of framework supported adaptation mechanisms.

Hence, in order to achieve run-time adaptation, explicit models of variation points, variabilities, context or environment and decision mechanisms should be supported by the framework. In [START_REF] Inglés Romero | Using Models@ Runtime for Designing Adaptive Robotics Software: an Experience Report[END_REF] run-time models are used for simple scenarios. The authors in [START_REF] Inglés-Romero | Dealing with Run-Time Variability in Service Robotics: Towards a DSL for Non-Functional Properties[END_REF] have demonstrated how SmartSoft framework with support of VML can be used for run-time adaptation for service robots.

Non-Functional Properties

Non-Functional Properties (NFP) dene how a functionality operates, for example, performance, availability, eectiveness, etc. The functional and non-functional attributes of the components are considered to make `who does, what, and when' decisions depending on the operational context. However, non-functional properties are not given sucient importance compared to that of the functional requirements during the developmental stages. SmartSoft uses NFPs as attributes to a component model and employs those attributes during the development process.

Brief Overview on Robotic Architectures

The initial work on robot architectures began with two extreme approaches -one is based on sense-plan-act paradigm [START_REF] Agre | What are plans for?[END_REF], which is a deliberative approach and the other is based on a purely reactive Brooks' subsumption architecture [START_REF] Brooks | A Robust Layered Control System for a Mobile Robot[END_REF]. To take advantage of these two extreme approaches, a number of hybrid architectures were then proposed. A notable one is Gat's three layer architecture that uses controller, sequencer, and deliberator layers to enable the robot to make high level plans and at the same time reactive to sudden events [START_REF] Gat | On three-layer architectures, Articial intelligence and mobile robots: case studies of successful robot systems[END_REF]. In NASREM architecture, the perceived information passes through several processing stages until a coherent view of the cur-rent situation is obtained. A plan is then adopted and successively decomposed by dierent modules until the desired actions can be directly executed by the actuators [START_REF] Albus | Overview of NASREM: The NASA/NBS standard reference model for telerobot control system architecture[END_REF]. The Task Control Architecture (TCA), developed by Simmons, provides a general framework for controlling distributed robot systems. TCA is essentially a high-level robot operating system with a set of commonly required mechanisms to support distributed communications, task decomposition, resource management, execution monitoring, and error recovery [START_REF] Simmons | A task description language for robot control[END_REF].

Majority of the robot architectures found in literature [START_REF] Medeiros | A survey of control architectures for autonomous mobile robots[END_REF], in one form or another consists of the below three distinct characteristics:

• Hierarchical vs. Centralized architectures

• Behavioral vs. Functional systems.

• Reactive vs. Deliberative control

Cognitive architectures such as ACT-R [START_REF] Anderson | ACT-R: A theory of higher level cognition and its relation to visual attention[END_REF] and ICARUS [START_REF] Langley | A unied cognitive architecture for physical agents[END_REF] use concepts from articial intelligence and cognitive psychology to create and understand synthetic agent that support the same capabilities as human and thus makes the robots more pervasive in a social environment. These architectures can be broadly classied as conceptual architectures, though their depth of inuence in robotic domain as a whole may be dierent. For example, the hybrid architectures concentrated mainly on how low level reactive behaviors can be coordinated using high level planning and decisional algorithms, while an expert system that models human driver is valid in very narrow contexts.

Architecture Modeling in Robotics

Typically software architectures are modeled as a collection of interacting components, where low level implementation details are hidden while expressing abstract high-level properties. An architecture model captures multiple abstraction levels or viewpoints that satisfy the requirements of dierent stakeholders. A hardware engineer would like to see the components allocated to a particular processor, while a system architect would be interested in component topology. A good architecture model facilitates decision making and acts as a mediator between requirements and design, implementation, reuse, maintenance, and run-time adaptation [START_REF] Garlan | Formal modeling and analysis of software architecture: Components, connectors, and events[END_REF].

The architectures that concern the execution and implementation aspects lie in the lower end of the abstraction axis. Modeling languages such as UML [START_REF] Rumbaugh | Unied modeling language reference manual, the[END_REF], SysML [START_REF] Friedenthal | A practical guide to SysML: the systems modeling language[END_REF],

and Marte [START_REF] Faugere | Marte: Also an uml prole for modeling aadl applications[END_REF], model the system that is more closer to the software realizations.

Their semantics are mostly implementation-specic and contain semantic models, such as communication patterns, model of computation (MoC). There is another category of architecture that consists of conceptual architectures that are tightly bound to specic implementation models. Architectures such as GenoM [START_REF] Alami | An architecture for autonomy[END_REF], and ACT-R [START_REF] Anderson | ACT-R: A theory of higher level cognition and its relation to visual attention[END_REF] provide their software development kits (SDK) to design systems complying with those models. The main advantages of such models is that more stringent validation methods can be applied and can maintain traceability from domain concepts to its implementations. However it takes signicant eort to port from one implementation technology to another.

We can view this as a spectrum of models on an abstraction axis as shown in Based on our comparative survey on existing model-driven frameworks in robotics and qualitative analysis of their features, we found that many of the domain-specic requirements such as architecture level analysis, system reasoning, non-functional property modeling, run-time models, component composition, etc., were addressed dierently in these approaches. In addition, it is hard to nd a single approach that has features according to one's requirement. Systematic development process and detailed instructions for building such frameworks and supporting infrastructure have not been studied enough. In addition, there is no clear denition on how OMG's Model Driven Architecture (MDA) could be realized in a framework.

The contributions from this thesis comprise conceptual methodology and a development approach that facilitates design, analysis, and deployment of framework for robotic systems. The methodology will be based on three well-established software engineering paradigms: Model-Driven Software Development (MDSD), Component-Based Software Engineering (CBSE), and Knowledge-Based Engineering (KBE). The main advantages of our proposed framework are:

1. Rapid development of custom framework for required set of domains.

2. Support for ecient integration of existing heterogeneous architecture styles that accelerates the complex system design.

3. Enables analysis, comparison, and benchmarking of various functional units and architectural paradigms.

4. Homogeneous development environment irrespective of framework or middleware and thus promoting faster adoption among software developers and system engineers.

Thesis Contents and Contributions

The remaining of the thesis is organized as follows:

Chapter 2 introduces the methodology of SafeRobots Framework. It discusses the dierent conceptual spaces in the framework and drives through the systematic developmental phases in the proposed methodology.

Chapter 3 discusses the concepts of Non-Functional Properties (NFP) and Quality of Services (QoS). The importance of modeling these properties in robotics especially in human-machine systems is explained in this chapter. A metamodel for modeling NFP is also introduced in this chapter.

Chapter 4 identies several inherent problems in the software design stage of robotics software development. The chapter starts by discussing several challenges faced during design phase of robotic software development. In this direction, dierent problems posed during the software development of a robotic software subsystem in an industrial setup are analysed. A domain-specic language that facilitates the design space exploration specic to the eld of robotics is also introduced.

Chapter 5 investigates the possibility of a common model for framework specication so as to model heterogeneous architectural paradigms. It reviews and studies dierent robotic architectures from an abstraction and software engineering point of view. A domain-specic language in the operational space that integrates with our SafeRobots methodology is proposed in this chapter.

Chapter 6 details dierent tools used and the stages involved in implementing the framework by the developer of the tool. It provides a brief overview on Eclipse Modeling Framework and discusses the selected tools and approaches supporting the framework development.

Chapter 7 employs the proposed framework and methodology to specic applications in robotics. Two case studies are shown so as to demonstrate how a system can be developed and formally specied in our framework. The rst case study uses a mobile robot mapping application and shows how two dierent architectures were developed from the same solution model and by semi-automated model transformations.

The second case study is about an application in cognitive architecture domain. A lane keeping and lane changing assistance system is modeled using our framework. [START_REF] Schlegel | Robotic Software Systems: From Code-Driven to Model-Driven Software Development[END_REF]. There is a pressing need to tailor proven approaches of software engineering in other domains to the requirements of robotics. In this direction, there is a need for a methodology that do not constraint any specic framework or architecture. In this context, the • To identify the core software engineering methods and developmental phases involved, on which the proposed framework is developed.

• To propose a conceptual methodology for developing software with generic tools for robotics domain.

• To analyze dierent software developmental phases involved in our methodology.

Motivating Example

Consider the problem of designing a software architecture for a mobile robot that needs to create a map of an indoor environment. The mobile robot is equipped with two `Time of Flight' (ToF) cameras positioned at right angles to each other with an overlapping `Field of View' (FoV). The goal is to develop a SLAM1 based mapping system using the point cloud data from the two ToF sensors. Assume that a hypothetical library is also given that provides software code implementing the SLAM algorithm. The library also contains a functions that can extract the points on a single plane (Virtual Laser Scanner) and for simple point cloud registration.

Since all the computational algorithms are provided as implemented software components, the primary task of the system developer is to design a data ow structure connecting these components. Using pragmatic knowledge, this can be achieved by connecting each camera to the virtual laser scanner function and simply summing up the two planar point clouds and then fed it to the SLAM algorithm along with the pose estimates. Another alternative is to combine the raw point cloud from the two cameras applying the provided registration function and then convert the resulting point cloud to the planar laser data. Although, the two approaches seems to be very similar in functionality (creating a map), the system level emergent non-functional properties are dierent. The non-functional properties of each software component, such as execution time, condence level, cannot be predicted at this stage because we do not have any data regarding the hardware platform in which it will be executed or whether all these computational components will be executed on a single platform or in a distributed fashion, and there is no information regarding the network bandwidth, latencies, etc. This will inuence the rate at which the SLAM algorithm will be executed and it will aect the resolution and condence level of the resulting map.

An informal representation of these two solutions is illustrated in Figure 2-1.

Nonetheless, it is clear that we have used our pragmatism and past experiences to arrive at this mental solution model. This integration method is highly nondeterministic, since the system integration for the same problem with the same `ingredients' provides dierent results because the knowledge used is in the designer's mental form. The disparity will be more evident for complex situations or when the system designer's knowledge is dierent from the algorithm developer's knowledge.

Since such knowledge is not explicitly encoded anywhere in the design specication, this can hinder the system evolution for large scale projects.

Conceptual Paradigms in SafeRobots Framework

Building on the identied problems and domain-specic requirements, we propose a conceptual methodological framework called `Self Adaptive Framework for Robotic Systems (SafeRobots)'. This section provides an overview of the three orthogonal, yet complementary software engineering methods, on which the proposed methodology is developed (see Figure 2-2). In Component-Based Software Engineering (CBSE) approach, a software is developed using o-the-shelf components and custom-built components. A software component is a unit of composition with contractually specied interfaces and explicit context dependencies only, and can be deployed independently and is subject to composition by third parties [START_REF] Szyperski | Component software: beyond object-oriented programming[END_REF]. In our previous research paper [START_REF] Ramaswamy | Formal models for cognitive systems[END_REF], we have identied specic requirements of components, that are more relevant in robotics: composability, compositionality, static and dynamic variability, component abstraction, and technology neutrality. The main goal of CBSE is to manage complexity and foster software reuse by employing the divide and rule strategy. In order to promote reuse, the focus should be on the design and implementation of individual components and on the techniques that maximize component interoperability and exibility. A more detailed discussion on CBSE in robotics can be found in [START_REF] Brugali | Component-Based Robotic Engineering (Part I)[END_REF].

Model-Driven Engineering

In Model-Driven Engineering (MDE), modeling techniques are used to tame the complexity of bridging the gap between the problem domain and the software implementation domain [START_REF] France | Model-driven Development of Complex Software: A Research Roadmap[END_REF]. Although component-based development and model-driven engineering address complexity management, the former adopts a bottom-up approach, while the latter is more top-down in nature [START_REF] Torngren | Component-based vs. Model-based Development: A Comparison in the Context of Vehicular Embedded Systems[END_REF]. In MDE, the complexity of the software is managed by using the mechanism called `separation of concerns (SoC)'.

Conceptually, it can be classied into vertical and horizontal SoCs. Vertical SoCs are built on multiple levels of abstraction. Model-Driven Architecture (MDA) [START_REF]OMG: Model-Driven Architecture, Object Management Group Std[END_REF],

a trademarked name for MDE by Object Management Group (OMG), species four abstraction models -Computation Independent Model (CIM), Platform Independent Model (PIM), Platform-Specic Model (PSM), and Platform-Specic Implementation (PSI). The computation independent model focuses on the environment of the system, the requirements of the system without any structural or processing details.

The platform independent model focuses on the operation of the system while hiding the details regarding the platform, middleware, etc. The platform-specic model is generated using PIM by adding platform specic details. The platform-specic implementation is then generated by using appropriate Model to Text (M2T) transformations. Horizontal SoCs manage complexity by providing dierent overlapping viewpoints of the model at the same abstraction level. In [START_REF] Radestock | Coordination in evolving systems[END_REF], the authors suggest four horizontal SoCs for large scale distributed systems: coordination, conguration, computation, and communication. In summary, the main challenges in MDE are designing modeling languages at right abstraction level, modeling with multiple overlapping viewpoints, model manipulation, and maintaining viewpoints' consistency [START_REF] France | Model-driven Development of Complex Software: A Research Roadmap[END_REF].

Knowledge-Based Engineering

Knowledge-Based Engineering (KBE) has the potential to change automated reasoning, methodologies, and life cycle of software artifacts. In order to achieve that, domain concepts should be represented at various granularity levels in accordance with multiple abstraction layers. For example, in the case of self-driving cars, for system level reasoning, the knowledge required is regarding the environment, the socio-legal contraints, trac rules, etc., and for platform independent layers, the knowledge required is about algorithmic parameters, structural conguration, semantics of data, etc. In general, information and knowledge can be represented in symbolic and nonsymbolic representation. In the non-symbolic approach, a promising work is proposed by Gardenfors that represents conceputual spaces in the context of cognitive science [START_REF] Gärdenfors | Conceptual Spaces: The Geometry of Throught[END_REF]. Conceptual spaces are simple geometric representations based on quality dimensions, designed for modeling and managing concepts. The quality dimensions are used as framework to assign properties to objects and to specify relationships between them. The reasoning is mainly based on the distances between points in this conceptual space. In general, the smaller the distance between two objects, the more similar they are. For example, the distance from the concept `canny edge detector' to the concept `grayscale image' is smaller than to the RGB image'. However formalizing this approach with respect to software development is beyond the scope of this thesis.

Developmental Phases in SafeRobots Framework

The dierent developmental phases, modeling languages, and models involved in the proposed framework are illustrated in Figure 23. The software development process in robotics can be conceptually divided into three spaces: problem space, solution space, and operational space, where each space is supported by the knowledge space.

The following developmental phases are involved in the proposed framework:

General Domain Knowledge Modeling

The domain knowledge modeling in this phase is independent of the problem specication or application constraints. The domain concepts can be formally modeled using ontologies, Domain-Specic Languages (DSLs), Knowledge graphs, etc. The models at this level capture the robotic domain specic concepts, meta-data about the computational algorithms and standard interfaces, their structural dependencies, etc. The domain knowledge complements the various application specic development process by providing a knowledge base for abstract concepts such as image, point clouds, links, joints, platform, etc.

Problem Modeling

In

Overview

SafeRobots is an architecture agnostic framework development methodology, tailored to the needs of robotic domain. It is supported by extensible tools and provides a set of basic metamodels and domain-specic languages, and a formal process for the design and development of software for robotic systems. The methodology comprises four conceptual spaces as shown in Figure 2-3: knowledge space, problem space, solution space, and operational space. The knowledge space is common with the other three spaces and provides abstract knowledge on robotic domain-specic concepts. The models at this level capture the robotic domain-specic concepts, meta-data about the computational algorithms, and standard interfaces, their data structures, etc. The domain knowledge complements the various application-specic development process by providing a knowledge base for abstract concepts such as image, point clouds, links, joints, platform, etc.

The three spaces -problem space, solution space, and operational space are application-specic modeling phases. However, models in solution space can be reused across dierent applications and hence the solution space models can be seen as do- specic functionalities are modeled in the solution space. In the solution space, only functional requirements are considered while non-functional requirements are specied as properties in this space. In other words, the models in the solution space satisfy only the functional requirements, however, these models comprise non-functional specications as well, but it may not comply with the requirements. For example, a non-functional requirement may specify certain condence level for the data, but the solution space models contains the information on how aforementioned condence can be evaluated from it models, and it may not necessarily satisfy the condence requirement. The models in the operational space are derived from the solution space model by applying the non-functional constraints. Concrete architectural models are specied in this operational space. If there are multiple models that satisfy the non-functional requirements, there are considered as variation points, which are dynamically resolved during run-time.

The conceptual spaces in the our approach are hierarchically arranged in such a way that the lower layer uses the knowledge gained in the upper layer. For example, models in solution space comply to the functional requirements from problem space and use the domain knowledge from knowledge space. Non-functional requirements from problem space is applied to solution space models to create operational space models. The models in all these spaces is supported by domain concepts in knowledge space as well. The following section provides a brief description of the three conceptual spaces and modeling -requirement modeling in the problem space, solution space modeling in the solution space, and architecture modeling in the operational space.

Knowledge Space

The knowledge space provides abstract knowledge on robotic domain-specic concepts. The domain knowledge modeling in knowledge space is independent of the problem or application constraints. Our methodology does not recommend any particular way of modeling these concepts. However, some parts of our development uses ontologies to some extend. Ontologies are mainly used in Articial Intelligence (AI) and Semantic Web communities to represent knowledge as a set of concepts and relationships of a domain [START_REF] Bechhofer | OWL: Web ontology language[END_REF]. Ontology can be thought of as a knowledge representation approach that represents key concepts with their properties, relationships, rules, and constraints. The IEEE Robotics and Automation Society is sponsoring the working group Ontologies for Robotics and Automation to streamline development trends, work on the harmonization of taxonomies and ontologies, along with the standardization of terms, interfaces, and technologies [START_REF] Haidegger | Applied ontologies and standards for service robots[END_REF]. The goal is to provide a standard ontology and associated methodology for knowledge representation and reasoning in robotics and automation, together with the representation of concepts in an initial set of application domains [START_REF] Schleno | An IEEE standard ontology for robotics and automation[END_REF]. Going one step further, software components and various implementations of algorithms can be represented in the form of knowledge graphs. Some examples include the selection and conguration of sensors, robust software components that implement specic functionalities, such as object detectors, classiers, etc. For such representations, conceptual spaces introduced by Gardenfors is very promising by presenting a framework for representing information on the conceptual level that provide us with a natural way of representing similari-ties [START_REF] Gardenfors | Conceptual spaces as a framework for knowledge representation[END_REF]. The authors of [START_REF] Chella | A cognitive architecture for articial vision[END_REF] have used such a framework to enable the systematic integration of dierent knowledge representations required in robotics. Recently, the authors of [START_REF] Hochgeschwender | Declarative specication of robot perception architectures[END_REF] have extended this framework to represent robotics perception architectures and showed how to model and store ready-to-use perception graphs and to eciently select the most appropriate perception graph at run time [START_REF] Blumenthal | An approach for a distributed world model with QoS-based perception algorithm adaptation[END_REF].

Solution Space

The solution space for implementing a functionality in robotics domain is large. A complex robotic system cannot be nalized during design-time [START_REF] Schlegel | Robotic Software Systems: From Code-Driven to Model-Driven Software Development[END_REF]. Hence, there is a need to support reasoning during development stages by the system designer to mitigate the uncertainty. Nowadays, there is a trend to delay decisions to handle uncertainty at runtime instead of handling it during development-time [START_REF] Giese | Living with Uncertainty in the Age of Runtime Models[END_REF]. Nevertheless, there is a need to dene the solutions at a higher abstraction level at which relevant properties and characteristics are expressed. Solution space modeling is performed with the help of functional requirements from the problem model as constraints applied to the concepts modeled in knowledge space. In other words, a solution space model captures multiple solutions for the given problem by considering only the functional requirements and given domain knowledge base modeled in problem independent knowledge space. The strategy is to postpone the decisions on non-functional requirements at a later stage, since such properties can be estimated only when platform-specic decisions are made. The solution model also helps in -system level reasoning, making tradeos, documenting decisions, and comparing them, and for formally proving and validating the nal implementation.

Solution space to Operational space transformation

Once the solution space model for a given problem is modeled, the next step is to transform it into an operational model. It is to be noted that the solution space model only satises the functional requirements and the non-functional requirements are enforced only while it is transformed to the operational model. It is common that there may be more than one solution that satises the non-functional requirements, in which case, the best possible solution can only be resolved during runtime. In addition to these solution subsets, there may be some solutions that partially satises or may depend on the context variables that can be estimated in real execution scenarios.

Hence, the transformation has two stages -design time and runtime.

A reduced form of the transformation process is illustrated in Figure 234. The core idea is a systematic semi-automated process to use models from problem space, solution space, and knowledge space to guide the system designer to make principled decisions and trade os during the system development process. The high level models are functional models, non-functional models, architecture metamodels (conventions and patterns), and middleware metamodels. In the transformation process, the user includes the custom software code, maps the software components to the corresponding architecture models, and generate a system architecture. It is to be noted that models are not only primary artifacts for development, they are primary means by which the dierent users such as developers and system architects interact and share.

The functional models consist of operations that have to be carried out in order to accomplish a specic functionality. In other words, in order to have the Navigate skill, the four sub-skills are required.

The functional model can also model more complex functionalities, for example, Fig- Non-functional properties (NFP) dene how a functionality operates, for example, performance, availability, eectiveness, etc. For example, the NFP model of a mapping functionality may require that the resolution of the map should be less than a specic value, res_map < 3cm. The core idea is to apply constraints from problem space to the models (functional and non-functional) in solution space together with domain concepts from knowledge space to guide the user in the process of system design.

The vision of our methodology is to use the functional and non-functional models to generate the system architecture in a tool-assisted way with core software engineering methods and systematic developmental phases. The semi-automatic transformation process also uses metamodels of architecture, communication middleware, supporting tools, and custom software components to generate the architecture of the system. If the system architect needs to change the middleware, he/she has to change the middleware metamodel and perform the transformation process to generate the architecture in a dierent middleware. The process is the same if he/she has to change the architecture, the corresponding metamodel has to be replaced. The architecture metamodel consists of abstract information and constraints related to the architecture.

Operational Space

In the operational space, a concrete architecture of the system is modeled that satises the functional and non-functional requirements. Robotics domain is highly heterogeneous with domains ranging from conceptual domain such as perception, planning, control, decision making to computational domain consisting of discrete, continuous; software domain consisting of communication middlewares, operating systems, etc.

Hence, the meta-framework architecture should be extensible in order to incorporate dierent domain models. The composed domain models should be semantically compatible. For example, assume a model incorporates concepts from two domains a and b. In domain a, the modeling element connector represents a computation process, and in domain b, the connector represents an instantaneous transition between two states. These two domains are semantically incompatible unless the conict between them is resolved, say by assigning the computational process to the component.

The model relationships enable integration of various domains so as to built more complex systems. The support for architectural views manages complexity by promoting separation of concerns (SoC). Our Open Semantic Framework proposed in Chapter 5 helps to modify and extend the semantics to incorporate dierent domain concepts and to capture the relationships and identify the conicting domain semantics.

Related Works

We have discussed dierent MDSD approaches in Robotics in Chapter 1. In addition, there are many approaches that target specic area of software development life cycle such as,task coordination [START_REF] Klotzbücher | Coordinating robotic tasks and systems with rFSM Statecharts[END_REF], deployment [START_REF] Hochgeschwender | A model-based approach to software deployment in robotics[END_REF], and integration [START_REF] Fernández-Madrigal | A software engineering approach for the development of heterogeneous robotic applications[END_REF] of software for robotic systems. Recently, SmartMDSD Toolchain v2 was released that provides an Integrated Development Environment (IDE) for robotics software development that combines a set of DSLs and tools that guides experts and stakeholders through a formalized development process [START_REF] Stampfer | The SmartMDSD Toolchain: An Integrated MDSD Workow and Integrated Development Environment (IDE) for Robotics Software, Special Issue on Domain-Specic Languages and Models in Robotics[END_REF]. The authors have used an approach of using models to cover and support the whole life-cycle of robotic components and their evolution from design phase to run-time usage. As an extension of BRICS approach, HyperFlex toolchain proposes a development process that denes how reference architectures can be exploited for building robotic applications. It provides a set of principles and tools that support the software engineers and the robotic developers in the task of designing, reusing, and composing robotic systems [START_REF] Gherardi | Modeling and Reusing Robotic Software Architectures: the HyperFlex toolchain[END_REF].

Conclusion and Contributions

In this chapter, we proposed SafeRobots methodology based on three orthogonal Once the solution space of a problem is modeled, an appropriate solution or a set of solutions is selected depending on the application context and quality requirements.

After this resolution, a more concrete solution (system architecture) is modeled in the operational space. A semi-automated transformation will facilitate this process of mapping to the operational space models. A detailed analysis of solution space modeling and framework design in operational space is provided in Chapter 4 and 5, respectively.

Chapter 3

Specication of Non-Functional Properties

Quality is never an accident. It is always the result of intelligent eort.

John Ruskin

Introduction

A major part of the robotics research concentrates on the delivery of `proof of concepts' in order to substantiate the researchers' ideas, for example, a robust path planning algorithm or a real-time collision detection system. Typically, these are developed from scratch or by using external code-based libraries. Nevertheless, when such components are merged and/or combined with other functional modules, the system does not always exhibit the expected behavior. This has led to the increased time-to-market and large system integration eorts when such systems are to be used in safety critical applications. The main issue that arises when such heterogeneous components are combined, is in ensuring reliability and safety at the system level.

In cyber-physical systems execution correctness encompass both functional and nonfunctional properties. However, only functional semantics is treated in traditional programming languages. Software modules built on such programming languages becomes unreliable unless it is handled at the component level in the hierarchy.

Adaptable components should provide a way to incorporate Non-Functional Properties (NFP) along with the data that they consume and produce. System engineers take into account the non-functional properties of components to characterize the system architecture. It necessitates a mechanism in which the NFPs propagate in component interactions so that it will assist system engineers to provide a better architecture for target applications. The condence level of the components does not depend only on the eciency of the implemented algorithm but also on the context in which it is executed such as resource availability, external disturbance, etc. For example, if a component is implementing localization using adaptable particle lters, the quality and response time depends on the number of particles used, which in turn depends on available memory during execution time, the state uncertainty level [START_REF] Hilliard | Recommended Practice for Architectural Description of Software-Intensive Systems[END_REF], etc. The component developer cannot test these properties unless it considers a Worst Case Execution Time (WCET) anticipating the available resources and the component should be incorporated in the anticipated platform. Nonetheless, that will fail the very purpose of reusable component for a reconguring system.

Specication and utilization of NFPs are crucial for building quality robotic software architectures. While functional properties decide what the system is supposed to do, the non-functional properties specify the conditions and how a functionality operates. Description of non-functional properties are essential for design analysis and renement decisions, as well as automatic generation of code and test cases [START_REF] Suleiman | Non-functional property specications for WRIGHT ADL[END_REF].

Usually, these properties are not explicitly dealt during robotic system development because of their complexity, informal way of their requirement specication, high abstraction level, as well as due to the limited support of languages, methodologies, and tools [START_REF] Chung | On Non-Functional Requirements in Software Engineering[END_REF]. Hence, it is necessary that a framework developer for robotics domain should provide a facility for the system designer to specify NFP in a more consistent manner. Accordingly, the purpose of this chapter is:

• To introduce the importance of NFPs in Robotics and Human-Machine Interaction systems.

• To structure the specication of NFPs using a common metamodel.

• To provide tooling support for NFP specication that integrates with the SafeRobots methodology.

Non-Functional Properties and Quality of Service

Non-functional properties dene how a functionality operates, for example, performance, availability, eectiveness, etc. QoS is the aptitude of a service for providing a quality level to the dierent demands of the clients [START_REF] Marte | UML Prole for MARTE: Modeling and Analysis of Real-Time Embedded Systems[END_REF]. There is no general consensus in the community about the concepts of NFP and QoS. In [START_REF] Jacobson | The unied software development process-the complete guide to the unied process from the original designers[END_REF], the authors dene Non-Functional Properties (NFP) as the element that species system properties, such as environmental and implementation constraints, performance, platform dependencies, maintainability, extensibility, and reliability; in short, a requirement that species constraints on a functional requirement. In the early phases of system development,

Non-Functional Properties are considered as requirements that impose certain constrains to be met. Subsequently, during the development process, these properties will become integral part of the system. Non-Functional Requirements are not implemented in the same way as functional ones. NFPs are seen as by products when a functionality is implemented. In software engineering terms, usability, integrity, eciency, correctness, reliability, maintainability, testability, exibility, reusablity, portability, interoperability, performance, etc. constitute NFPs [START_REF] Chung | On Non-Functional Requirements in Software Engineering[END_REF]. At the same time, what determines QoS is highly domain specic. For example, throughput and bandwidth determines QoS for a network; performance, fault-tolerance, availability, and security for an embedded system; personality, empathy, engagement, and adaptation for social robots [START_REF] Tapus | Socially assistive robotics[END_REF]; resource utilization, run-time adaptation for service robots [START_REF] Inglés-Romero | Dealing with Run-Time Variability in Service Robotics: Towards a DSL for Non-Functional Properties[END_REF]. In [START_REF] Steinfeld | Common metrics for human-robot interaction[END_REF], the authors identied some non-functional properties (in the form of metrics)

for tasks in navigation, perception, management, and manipulation for Human-Robot Interaction. For example, eectiveness of a navigation task can be measured by:

• Percentage of navigation tasks successfully completed

• Coverage of area

• Deviation from planned route

• Obstacles that were successfully avoided

• Obstacles that were not avoided, but could be overcome Eciency can be measured by time to complete the task, operator time for task, average time for obstacle extraction, etc.

The management of NFPs in component models is one of the main challenges in the component-based software engineering community. The starting point in their management, namely their specication in a context of component models is not addressed in a systematic way [START_REF] Sentilles | Integration of extrafunctional properties in component models[END_REF]. The purpose of NFPs is to provide additional information about the components, complementing the structural information that is provided by the component model. This additional information is intended to give a better insight in the behavior and capability of the component in terms of reliability, safety, security, maintainability, accuracy, compliance to a standard, resource consumption, and timing capabilities, among many others. In that sense, these properties bridge the gap between the knowledge of what a component does and its actually capabilities. As the system development progresses, the meaning of the NFPs typically changes from 'required' to 'exhibited'. In most cases, the value of the property also might change as knowledge about the system and its target platform changes.

For example, a NFP requirement in the requirement specication phase might be considered as a NFP property in the design phase with an estimated value. As the system development progresses towards implementation, the value will be replaced by a measured value [START_REF] Sentilles | Integration of extrafunctional properties in component models[END_REF]. Hence, NFPs shall be allowed to assume multiple values that are valid depending on the context of existence.

Example of Relevance to Human-Machine Systems

In this section, we discuss why specifying NFP is important for robotic systems that involve human interaction. In a typical Human-Machine Interaction (HMI) system, a task is performed by cooperation of the human and the automation component.

The system adopts a cognitive architecture to model human psychology and makes optimum decisions on dynamic task allocation between human and the machine counterpart depending on the context. However, such architectures do not dene how these systems are implemented in a software. This is due to the gap in the abstraction axis In certain tasks, humans outperform automation while in some others, it is the opposite. However, in most of semi-autonomous systems involving humans, for example in cars, many functions that human performs are provided by the automation also. Although the software component and the human counterpart can perform the same functionality, it is the quality expected from the entire system and the context that determines which one should be activated or deactivated in compliance with the regulation authority such as FAA for civil aviation. A typical human-machine system maintains three kinds of models: (a) human model, (b) environment model, and (c) the internal state model of the system as shown in Figure 3-1. The functionality is achieved through the interaction of these three models. Most modeling languages provide support for the description of functional behavior, while the nonfunctional requirements are normally described using informal comments even though these properties play a vital role in determining the quality of the system. A decision making system estimates the quality provided by the human and that of the automation, and decides the authority for control. For example, attributes such as response time, accuracy, and reliability may comprise the quality of the software component, while alertness, skills, and expectation-intention correlation may decide the quality of the human.

Furthermore, selecting the services based on the quality have advantage not only between human and automation agents but also within the automation system itself.

Since the functionalites are viewed as services it is possible to compose basic low level services in dierent fashion to provide dierent functionalities. For example, in cars, voice recognition service can be used in an entertainment system as well as in a navigation system. However, the bottleneck is more related to the business models existing in industries that develop such systems. The standard approach for automobile OEMs is to develop systems by assembling components that have been completely or partly designed and developed by external vendors [START_REF] Sangiovanni-Vincentelli | Embedded system design for automotive applications[END_REF]. Because of the increasing complexity of automobile systems with large number of distributed features, such an approach will also lead to various compositional issues commonly known as feature interactions. Therefore, Service Oriented Architectures (SoA) are gradually being adopted in these systems where various functionalities are provided as services and the assembled components are seen as service providers. This software engineering paradigm has many advantages in Human-Machine collaborative work.

Advances in human behavior research helps to model various human actions. These actions can be seen as services provided by human, for example, steering, braking, etc, applying acceleration by the driver can be viewed as services provided by the human driver. In some context, humans provide high quality services while in some others the machine counterpart does. For example, in the case of assisted parking, human steering control service is delegated to the machine still retaining the authority over acceleration with the driver.

The problem of dynamic adaptation is to maintain the QoS of the system at a certain level. In order to do that in a system involving humans, the QoS of human models as well as for automation models needs to be specied in a common framework.

The challenge is that various attributes that determine a NFP are heterogeneous in nature while considering human and machine models. We can address this problem using our common NFP structure to specify the QoS of human, machine, and their interactions.

NFP Metamodel

In order to set a general consensus, based on empirical observations, the following assumptions are made: A NFP are determined by a set of non-functional attributes Dynamic attributes can change during system operation, for example, frames per second of a camera. Derived attributes can be static or dynamic and depend on the constituent attributes when they are hierarchically composed. Qualitative attributes refer to discrete characteristics that may not be measured directly but provide a high level abstraction that are meaningful in a domain, for example, reliability of a network channel. Sometimes a qualitative attribute needs some quantitative measures also, for instance, round robin scheduler with a refresh rate of 100ms.

Tool Support for NFP specication

In Chapter 5, we will introduce a framework specication method that supports semantic extension for dierent domains. This extension framework provides a tool support in the form of viewpoints and property sheets. In order to make use of this tool support, the NFP structure is mapped to the Property element as shown in Figure 3-3. However, additional plugins were created for improving usability mainly for two reasons. First, to facilitate that a property can assume multiple values and secondly, to provide a view that help user to navigate through history of values for a property. In early phases of the system life cycle when a component is being modeled, the properties can be an estimation or even a requirement. The accuracy of the estimation during the development process can be changed, as a result of an increasing amount of information or a change in the way the value is obtained. In the run-time phase (or even in the development phase in some cases), the property value could be measured [START_REF] Sentilles | Integration of extrafunctional properties in component models[END_REF]. For this purpose, appropriate tools are provided to allow a property to assume multiple values.

One of the major ambition of MDE is to provide automated code generation to be executed on a target platform [START_REF]OMG: Model-Driven Architecture, Object Management Group Std[END_REF]. On one hand it is important to have a structure for specifying the NFPs that can be reviewed at dierent design phases and that facilitates in verication and validation eorts. On the other hand, certain NFPs cannot be preserved at code level and sometimes they cannot be accurately determined until the execution of the code [START_REF] Cancila | Toward correctness in the specication and handling of non-functional attributes of high-integrity real-time embedded systems[END_REF]. To facilitate this process, the tool allows multiple values for an NFP during the development process and helps to incorporate a full round-trip engineering approach in order to evaluate quality attributes of the system by code execution monitoring as well as code static analysis, and then provide back-propagation of the resulting values to modeling level [START_REF] Ciccozzi | Round-trip support for extrafunctional property management in model-driven engineering of embedded systems[END_REF].

Example of NFP specication in an Assistive Lane Keeping System

Assistive lane keeping is a perfect example for dynamic function allocation in Human-Machine system. The automation part is the lateral control of the vehicle to keep the vehicle in the same lane. The system takes control by applying the required torque on the steering wheel in case of lane departure situations. In Chapter 7,

we have used this application as case study for specifying framework for developing cognitive systems. NFPs of Human and Machine are formally modeled using the proposed NFP metamodel. In Figure 34, eciency property of human, machine and interaction model is specied. We dene QoS for eciency as the response time in which the human will react to a critical event (here lane departure). Modeling representing various aspects of human driver such as memory, perception, control, monitoring, and decision skills. A detailed description of the model can be found in [START_REF] Salvucci | Modeling driver behavior in a cognitive architecture[END_REF]. The eciency model of the human driver, machine and their interactions based on the proposed NFP metamodel. The policy functions can be dened based on logic systems, such as a rst order logic, predicate logic, etc., by the system designer. An example on how such specications can be employed in a framework is provided in Chapter 7.

Related Works

The importance of specifying non-functional properties in computer vision systems is studied in [START_REF] Fenn | Addressing the non-functional requirements of computer vision systems: a case study[END_REF]. In [START_REF] Inglés-Romero | Dealing with Run-Time Variability in Service Robotics: Towards a DSL for Non-Functional Properties[END_REF], the authors showed how to express variability in a robotic system for non-functional properties using a DSL called Variability Modeling Lan-guage (VML). They have also provided a mechanism to express how a system should adapt at run-time based on those properties and adaptation rules. In [START_REF] Sykes | Exploiting non-functional preferences in architectural adaptation for self-managed systems[END_REF], a practical means of exploiting non-functional properties in an architectural assembly process with structural constraints are introduced. The authors of [START_REF] Steck | Towards Quality of Service and Resource Aware Robotic Systems through Model-Driven Software Development[END_REF] have proposed a development process and meta-model that allows the explication, management and analysis of non-functional properties which enables analysis of resource usage and verication of resource constraints. Although there is little literature that deals directly with modeling NFPs in human-machine systems, the works in metrics used in human-machine systems can be used for reference. Metrics for standardization for Human-Robot Interactions (HRI) have been proposed by [START_REF] Olsen | Metrics for evaluating human-robot interactions[END_REF], [START_REF] Burke | Task performance metrics in human-robot interaction: Taking a systems approach[END_REF], [START_REF] Steinfeld | Common metrics for human-robot interaction[END_REF], and [START_REF] Saleh | Towards generalized performance metrics for humanrobot interaction[END_REF].

The proceedings of the workshop on 'the Metrics for Human-Robot Interaction' proposed several guidelines for the analysis of human-robot experiments and forwarded a handbook of metrics that would be acceptable to the HRI community [START_REF] Burghart | Proceedings of Metrics for Human-Robot Interaction[END_REF].

Garlan et al. [START_REF] Garlan | Model-based adaptation for self-healing systems[END_REF], in their work on Acme, enable architectural adaptation by writing repair strategies which work within an architectural style. Each component declares a number of non-functional properties to be monitored by the running system.

If a constraint is violated, a repair strategy is invoked in response. [START_REF] Mylopoulos | Representing and using nonfunctional requirements: A process-oriented approach[END_REF] proposes two complementary approaches for using Non-Functional information -process oriented and product oriented. Process oriented approach used NFP to guide the development of software systems. While in the product oriented approach, the non-functional characteristics of the nal product are explicitly stated, making it possible to examine if products fall within the constraints of non-functionality. There are three UML proles that are standardized by the Object Management Group (OMG) that deal with modeling QoS for software components - [START_REF] Qosft | UML Prole for Modeling Quality of Service and Fault Tolerance Characteristics and Mechanisms Specication[END_REF], [START_REF] Spt | UML Prole for for Schedulability,Performance, and Time Specication[END_REF], and [START_REF] Marte | UML Prole for MARTE: Modeling and Analysis of Real-Time Embedded Systems[END_REF] proles. In [START_REF] Dobson | QoSOnt: a QoS ontology for servicecentric systems[END_REF] a

QoS ontology for service-oriented systems has been proposed. Our intention is to structure the property specication at a certain abstraction level and to integrate in our framework development methodology. The level of details and constraints on those specication is decided by the framework developer and it is open for him to map the required concepts. In the context of safety in autonomous systems, the authors of [START_REF] Morse | Formal specication and analysis of autonomous systems under partial compliance[END_REF] describe the computation of probabilities according to dierent specications, based on functional and non-functional requirements, through probabilistic model checking.

Conclusion

Providing a systematic way of NFP specication and integrating it with development process by appropriate tools are essential for ecient framework development process.

The importance of Non-Functional properties in robotics and human-machine systems were discussed. Modeling those properties are necessary in architectures where functionality alone cannot be used for making both design time and run-time decisions.

Our NFP metamodel provides a generic base for specifying the non-functional aspects of both human and machine models. The main challenge in nding structure for NFP specication is to provide a exible mechanism to address a large variety of property types and providing a tooling support to manage them. The challenge of dealing with heterogeneous attributes are addressed by categorizing the attributes into proles hierarchically and then using policies to compare at a higher abstraction level.

My Contributions

The main contributions in this chapter are enumerated below:

1. The chapter analyzed the importance of specifying and integrating NFPs in Framework development in Robotics domain.

2. A metamodel to structure the specication of Non-Functional Properties is proposed. A common structure for NFP helps in specifying the non-functional aspects of both human and machine models.

3. An extensible tooling support is developed to manage NFP specication and their management.

Chapter 4

Solution Space Modeling

The more of the context of a problem that a scientist can comprehend, the greater are his chances of nding a truly adequate solution.

Russell L. Acko

Introduction

Architecting a robotic system is a science of integrating various independently operable heterogeneous systems such as perception, navigation, planner, controller, etc.

Traditionally in robotics, the adaptation of the robotic system to the dynamic environments is embedded in the functionality of the constituent systems, for example, by designing a dynamic path planning algorithm. This practice limits the adaptation within the functional boundaries of the system components. Therefore, the purpose of this chapter is:

• To identify the inherent problems in the software design stage of robotic software development.

• To propose a Domain-Specic Language (DSL) that facilitates the design space exploration specic to the eld of robotics

The solution space for implementing a functionality in robotics domain is large.

Unlike in research laboratories, where domain experts are involved in software development, in industries there is a clear separation of roles. Domain experts design the system (e.g., using UML class diagrams) and make key decisions on algorithms that are then communicated to the software developer who develops the software code.

Robotic experts can oversee various algorithmic solutions, specify abstract software component interfaces, predict high level dependencies, etc.; however, they may not be well versed in best software engineering practices, cannot predict execution time of algorithms, etc. A software developer, sometimes, anticipates and assumes several facets about the target environments while implementing and testing software components that may not be valid in the nal system composition. For example, a developer may implement a particular localization algorithm that requires the sensor data to have a certain condence level and resolution, which may not be satised in the target application. The underlying reason is that no formal model is used to analyze and manage the solution space available to various stakeholders. Taking into account several experts' opinion from academics and industry, the robotic system designs are fallible due to these general reasons:

1. Most of the robotic system designs are purely functional, they do not explicitly capture the non-functional aspects, such as, timing properties, etc.

2. The decision on which algorithms to use is decided by the domain expert during the design phase without considering the operational prole of those functionalities and its prerequisites, run-time environment, potential interactions etc.

Only functional verication of individual systems is conducted and the per-

formance of these modules cannot be guaranteed when it coexists with other systems, for example, the obstacle detection system may take more time to compute when it is executed along with other systems in the real world scenario.

4. Lack of common ontologies and reluctance of roboticists to accept any standard development process.

Motivational Experiment

The problems faced and lessons learnt during the system design, software development, and eld experiments conducted during a research at Renault were the driving forces to propose a model-based approach. The objective of the experiment was to design and implement a vehicle tracking system using Velodyne HDL-64E lidar sensor. Velodyne lidar is a high denition laser scanning system that generates about a million points per second using its rotating sensor head containing 64 semiconductor lasers as shown in Figure 4 Large number of segmentation algorithms are available in the literature to segment point cloud data. Some of them were dependent on the type of the sensor (e.g., Lidar, Time-of-Flight Cameras), properties of data (e.g., density, resolution, colour, intensity), environment features (e.g., indoor, outdoor, cluttered, at or sloppy terrain, vegetative land). In addition, the intention to use the tracking system in a variety of applications, such as ground truth generation, and autonomous driving, whose requirements for timing properties, resolution and condence levels are entirely dierent, makes it dicult to choose an appropriate algorithm.

The rotating head of lidar takes non-negligible amount of time to capture a frame.

If the lidar is mounted on a moving vehicle, the generated 3D point cloud frames get distorted due to this motion. Since this was not properly captured in the initial designs, considerable amount of time was spent on implementing software that later failed in eld experiments. One such incorrect component composition was when

Point Cloud Histograms (PFH) were used as feature descriptors in the data association step. PFH descriptors captures the spatial distribution of points in the point cloud. When the tracking system was used in moving vehicle without including an undistortion process on the point cloud data, the feature correspondences do not work. The undistortion process requires a high performance inertial localization system to compute the pose of the vehicle at the timestamp of each captured point and applies coordinate transformation to compute the exact 3D point. Such induced requirements and constraints must be captured to make the system more adaptable, for run-time dynamic wiring of software components, and for deriving a product from product line systems.

Context information was unavailable during design time as well as during eld experiments. Certain algorithms can be integrated to the system only by using such information, for example, an object classier needs the road information to help in classifying between vehicles or buildings on the road side, between pedestrians and parking poles, etc. Several algorithms (ground classication, for instance) require parameter selection based on the context, such as terrain type -sloppy or at, road width, etc.

Identied Challenges

From the experiment discussed above, and from the previous experiences in developing similar robotic systems, the common challenges can be broadly classied into four categories:

1. Uncertain problem space: Ambiguity in requirements due to the desire to reuse the system across various applications.

2. Large solution space: Availability of multiple algorithms for implementing a functionality.

Lack of design time context information:

The developer cannot anticipate all the use cases and his/her assumptions are not properly documented.

4. Incorrect level of abstraction: Code-centric designs cannot provide the right level of abstraction that promote portability and reusablity.

To address these aforementioned problems, we propose a modeling language to formally model the solution space and to specify the quality attributes during design time. The approach is to capture multiple solutions in the model that permits formal analysis, reasoning, and decision making on selecting best possible solution depending on the functional and non-functional properties. The solution model also helps in -system level reasoning, making tradeos, documenting decisions, and comparing them, and for formally proving and validating the nal implementation.

Solution Space Model

By critical analysis of the problems described in Section 4.

Functional Model

A functional model satises the behavioral requirements of the system. A behavioral or functional requirements are those requirements that specify the inputs (stimuli)

to the system, the outputs (response) from the system, and the behavioral relationships between them [START_REF] Davis | Software requirements: objects, functions, and states[END_REF]. The functional model in the solution space should not be interpreted as a data ow diagram, but as a relationship diagram between functional concepts.

Functional Metamodel

A functional metamodel is depicted in Figure 4-4 that conforms to the solution space meta-metamodel. This metamodel imposes soft constraints on the dispatch policies of the gates and the number of ports [START_REF] Ramaswamy | Formal models for cognitive systems[END_REF]. Soft constraints means that the dispatch policies are not concretely dened but only conceptual restrictions are only imposed in the metamodel. The intention is to facilitate the designer to apply application specic policies, at the same time, the gates can be used for automated reasoning of the solution space. f) User-dened gate does not have any constraints on the number of ports and dispatch policy.

Solution Space Model for Lidar Based Vehicle Tracking System

This section models the solution space of a lidar based vehicle tracking problem using the proposed SSML. --------------------------------------------------------------------------------- Ground points are automatically rejected and there is no requirement for explicitly classifying the ground and non-ground points. The NFP of segmentation process are modeled in a similar way as previously described in this section. In this example, two contexts are considered; one for a ground truth generation application and another for autonomous driving application. The intention is to reason, analyze, and extract appropriate solutions from the solution space that satisfy the context requirements. If two or more solutions satisfy the requirements, it will be considered as variation point that can be resolved in the design or implementation phase, or dynamically selected during run-time. For simplicity, only the performance property is considered here. The performance is modeled with Also it is reasonable to compare the AET of dierent computations on the same platform for primary investigations. The resolution is divided into three levels depending on the grid size of the map: High, Medium, and Low, to facilitate the demonstration. The appropriate solution in dierent contexts is extracted in a staged process as described below:

---------------------------------------------------------------------------------
1 G21-(C21-G23-C26)(C23)- G24-C27-G25 (C21), 2 G21-(C22-G22-C24-G23- C26)(C23)- (C22-G22-C24) G24-C27-G25 (C24-G24-C27), 3 G21-C22-G22-C25-G25 (
1. Find the multiple solutions available in the solution space model.

2. Find the variation sub-paths among the multiple solution paths.

3. List the sub-paths from the variations found in step 2.

4. For a given context, nd whether the homogeneous sub-paths satisfy the quality policy (NFP or QoS Policy) of that subpath. A homogeneous sub-paths is a set of sub-paths that perform exactly the same functionality.

5. Consider all the sub-paths satised in step 4 and check for any contradictory results, for example, if the solution passed in one homogeneous check and failed in another.

6. If there were any contradictory results, repeat the quality check for the solution at the higher level in the hierarchy.

The solution resolution steps of segmentation model are captured in Table 4.1.

There are three execution paths as listed in the table. Two variation points are then found -one variation sub-path between execution path 1 and 2 and the second between 2 and 3. It is to be noted that individual paths that end with a synchronizer gate cannot be considered as separate execution path since all the paths are mandatory for synchronization. The next step is to list out the sub-paths in the variation points. The four sub-paths are indicated in the second half of the table. The sub-path 1 and 2, and 3 and 4 are homogeneous pairs since they represent the same functionality. The policy used were (Resolution==High) for ground truth application and (Resolution==High) AND (AET<50ms) for autonomous driving application. In stage 1, two solutions satisfy the policy and in the next stage, one solution is extracted by considering the policy in that level.

Solution to Operational Space Transformation

After the solution space model for a given problem is modeled in SSML language, the next stage is to transform it to an operational model. It is to be noted that the solution space model only satises the functional requirements and the non-functional requirements are enforced only while it is transformed to the operational model. It is common that there may be more than one solution that satises the NFP requirements, in which case, the best possible solution can only be resolved during runtime.

In addition to these solution subsets, there may be some solutions that partially satisfy or may depend on the context variables that can be estimated in real execution scenarios. Hence, the transformation has two analysis stages -design time and runtime.

The solution model for point cloud segmentation problem is shown in Figure 456.

The solution space model is a form of Directed Acyclic Graph (DAC) with functional computations represented as edges, and gates form the nodes of the graph. The nonfunctional properties associated with the edges are assumed to be fully observable in our study. This is a valid assumption for most of the NFP properties such as, WCET, Required Memory, etc., as these can be estimated using external tools when the execution context is known. This assumption can be extended to qualitative properties

Transformation Process

The solution space model is transformed into MDP model in a systematic approach. A solution space model is composed of gates and connectors as basic modeling elements that represent decision points and computational functionalities respectively. The connectors are transformed to states and gates are translated to edges connected to these states. Figure 4 After translating the gates to MDP model, the nal MDP model of the complete system is generated by merging the corresponding decision states.

MDP Model Analysis

The analysis of the MDP model is performed in two stages -design time and runtime.

The design time analysis is an oine process to compute a subset of solution space model given the problem model. Runtime analysis is an online process during the

Design-time Analysis

The functional and non-functional requirements are modeled in the problem space of the framework. The NFP requirements are modeled in domain-specic language, which is presented in Chapter 3. However, for simplicity, in this chapter we specify them as simple name-value pairs. For example, estimated execution time of a functional computation is denoted as ET : 20ms.

Due to the stochastic nature of the execution context, a xed sequence of actions may not work. There should be a policy that species what should be performed next from any given state. The overall goal of the system is to maximize the utility that depends on the sequence of states selected. We attach a bounded reward R(s) to each state. The rewards are specied in terms of the NFP property attached to the state.

For decision states, rewards are not specied since they do not inuence the overall utility directly. In this chapter, we use the term reward in general, in some case it can represent a cost, for e.g. execution time (ET). This depends on how the requirement is specied, ET < 100ms denotes ET as a cost and usability, U > 3 presents it as a reward. The policy, π should yield expected utility value that is satised by the requirement. For example, assume that a policy π x can provide a expected reward in terms of execution time of < 21, 44 > for a particular subset of solution space model. Due to the stochastic nature of the system, the expected reward will always be a range of values. Only the overall utility of each path is considered during the The expected utility, U h for each model path can be computed as:

U h ([s 0 , s 1 , s2, • • • , s n ]) = R(s 0 ) ⊕ R(s 1 ) ⊕ R(s 2 ) ⊕ • • • R(s n ) (4.1)
Where, R(s) is the reward for state s, ⊕ denotes a composition operator. Figure 4-9 illustrates the utility values for a model consisting of two paths. The composition scheme depends on the type of non-functional property used as rewards. For example, ET property can be simply composed by adding the values of all the states in the sequence, while most of qualitative properties have more complex composition schemes. In many cases, the composition of NFP properties depend on the external environment and the system architecture. For example, the composition of component performance may depend on scheduling policies and the system conguration.

Currently, the common practice is to dene the composition based on some constraints/assumptions. For example, static memory usage is considered to be additive give that there is no concurrency in assembly execution [START_REF] Sentilles | Managing extra-functional properties in component-based development of embedded systems[END_REF]. The utility values are computed for all the available paths in the solution space model. Only those paths that satisfy the requirements are then selected. For example, if the requirement species the ET < 100ms, only those paths with utility value of ET less than 100ms are selected for the runtime resolution.

Runtime Analysis

The MDP model generated after the design time analysis is a subset of solution space that satises the non functional requirements. However, the best possible solution can be selected only during runtime due to the environment dependency. During the runtime analysis each NFP reward is replaced by the expected utility value from that state to the terminal state in form of < min(U h ), max(U h ) >. The Figure 4-11 shows an example of a runtime MDP model in which each functional state is augmented with the expected utility forecast. The utility forecast estimation is performed using a probabilistic model checker called PRISM, which is a tool used for formal modeling and analysis of systems that exhibit random or probabilistic behavior [START_REF] Kwiatkowska | PRISM 4.0: Verication of probabilistic real-time systems[END_REF]. For example, the state s 2 in Figure 4-11 is augmented with a expected utility forecast of < 89, 134 >, which means that the ET property will have a value in that range from The area can be computed as:

P (ET < ET req ) = P (ET s i ≤ ET req -ET current ) = (ET req -ET current ) -min(U h ) max(U h ) -min(U h ) (4.2)
The execution branch with the highest probability of satisfying the requirement will be selected at the decision point. We have explained the process with the help of ET as the reward, however this can be extended to any quantitative property as reward with proper composition operation as discussed earlier.

Operational Models

The SafeRobots component model adopts the separation of concerns approach proposed by the BRICS framework [START_REF] Vanthienen | The 5C-based architectural Composition Pattern: lessons learned from re-developing the iTaSC framework for constraint-based robot programming[END_REF]. The component semantics is mapped to the 5Cs -Communication, Computation, Conguration, Coordination, and Composition.

In addition, the operation space also consist of architectural models in the form of meta model that species the constraints and knowledge regarding the conguration of the nal system. The solution space model to operational model transformation performs this semantic mapping to the 5Cs. However, the conguration-coordination pattern uses internally the MDP models and the mechanisms discussed previously for runtime coordination and dynamic invocation of computational components. Finally, the operational model is automatically translated to executable code using Model to Text (M2T) transformation. The real advantage of our process is that the selfadaptation capability is introduced before architectural decisions are made and they handled by the framework tool and hence, it enables evaluation and benchmarking of robotic architecture in an ecient manner.

Related works

By learning from the shortcomings of code-based approaches, the software engineering community in robotics is gradually moving towards Model-Driven Software Development (MDSD) approach [START_REF] Schlegel | Robotic Software Systems: From Code-Driven to Model-Driven Software Development[END_REF]. Modeling solution space using SSML can be seen as a complementary approach to many existing methods in the robotics. Software product line approach is popular in software engineering community to enhance product quality and reduce developmental cost by promoting constructive reusability [START_REF] Heymans | Software product lines: State of the art[END_REF].

Recently, the authors of [START_REF] Gherardi | Variability modeling and resolution in component-based robotics systems[END_REF] have adapted this approach in robotic domain by providing feature resolution and transformation steps. However, one should have already identied well dened boundaries for variation points and a reference architecture for adapting this approach. In addition, many DSLs are proposed in robotics domain for deployment, simulation [START_REF] Dhouib | RobotML, a Domain-Specic Language to Design, Simulate and Deploy Robotic Applications[END_REF], component creation [START_REF] Manso | Robo-Comp: a tool-based robotics framework[END_REF], etc. All these languages reside in the operational space, our proposed SSML can complement and facilitate a smooth transition from problem space to operational space.

Similar to our transformation approach, the authors of [START_REF] Ghezzi | Managing nonfunctional uncertainty via model-driven adaptivity[END_REF] have used a probabilitybased functionality adaptation for distributed mobile applications. However, they mainly address the problem of unexpected high response time and faults during the runtime of the system alone. Current research in self-adaptive systems concerns on the eective utilization of models during runtime. In such situations, the runtime models should reect the most up-to-date information in order to perform online analysis and reasoning. There are some interesting reference architectures available from self-adaptive systems and models@runtime communities [START_REF] Bencomo | Models@run.time, Foundations, Applications, and Roadmaps[END_REF]. In [START_REF] Welsh | Understanding the scope of uncertainty in dynamically adaptive systems[END_REF] authors have proposed a technique to explicitly document the existence of uncertainty about how architectural decision contribute towards satisfying non-functional properties in the form of soft goals. The technique allows developers to deal with uncertainty during both development time and runtime [START_REF] Welsh | Run-time resolution of uncertainty[END_REF].

Conclusion

This chapter focused on the problems faced while developing software for robotic

systems. An experience report on developing a lidar based vehicle tracking system in an industrial context is used for motivational purpose. The problems were classied into four categories: uncertain problem space, large solution space, lack of design-time context information, and abstraction issue. In this chapter, Solution Space Modeling Language is proposed to address the multiple solution problem and to formally specify NFP during system design. Solution space modeling can expand this design space, help nding the best possible solution, and also permit to perform run-time adaptation of the system. Solution model helps in early analysis of quality attributes, to identity variations and acts as a bridge between problem and implementation space.

More research is required on formal methods for specifying composable policies of Gates, NFP, and QoS in the proposed SSML language. Once the solution space of a problem is modeled, an appropriate solution or a set of solutions are selected depending on the application context and quality requirements. A transformation model will facilitate this process of mapping to the operational space models, for example, discrete timing properties of gates can be employed for process allocation, selecting scheduling policies, etc. In Part III of this thesis, we discuss the tooling support based on Eclipse IDE for graphical and textual editing of SSML models and using Eclipse plug-in feature for semantic enrichment of the model.

My Contributions

In this chapter, we started by discussing several challenges faced during design phase of robotic software development. Subsequently, we analysed dierent problems posed during the software development of a robotic software subsystem in an industrial context (intelligent vehicles). The following contributions are made in this chapter.

• We studied common reasons that makes the robotic system designs fallible by taking into account the previous experience of robotics experts in various experiments in academics and industry,

• The common challenges are then broadly classied into four categories: uncertain problem space, large solution space, lack of design time context information, and incorrect level of abstraction.

• To address these aforementioned problems, we proposed a modeling language -Solution Space Modeling Language (SSML), to formally model the solution space and to specify the quality attributes during design time.

• The relevancy of the model is demonstrated by modeling the solution space of vehicle tracking problem. NFP and QoS Policies facilitated the quality ow across functionalities at dierent granularity levels.

• The resolution of solution space might not always result in a static operational model. Typical the resolution process performed during development time result in a subset of solutions that are modeled as variation points in the architecture. This is attributed mainly due to certain context-based properties that can be estimated only during runtime. We formally dene the solution space to operational space transformation process and employs a probabilistic approach to resolve the solution model during design time and execution time. These operations are handled automatically by the framework tool and are independent of any particular robotic framework.

Chapter 5

Architecture Modeling in Operational Space

It is always easier to destroy a complex system than to selectively alter it.

Roby James

Introduction

Despite the research that spanned almost three decades, the robotics community has not converged to a single or a minimal set of ecient architectures [START_REF] Kortenkamp | Robotic systems architectures and programming[END_REF]. Although most of the existing architecture styles can be classied into three categories: hierarchical, behavioral, and hybrid; it is very common that each robotic system designer or research group builds their own architecture from scratch considering only their short-term immediate requirements. The design, simulation, and programming of robotics systems is challenging as expertise from multiple domains needs to be integrated conceptually and technically. In addition, complex robotic systems typically involve software components that use a variety of mathematical models for problem solving, for e.g., state machines for robot control [START_REF] Argall | Learning to select state machines using expert advice on an autonomous robot[END_REF], stochastic Petri Nets for navigation [START_REF] Kim | Navigation behavior selection using generalized stochastic petri nets for a service robot[END_REF]. Furthermore, as an emerging solution for handling complex and evolving software problems, several Domain Specic Languages (DSLs) have been proposed for specic functional domains in robotics [START_REF] Nordmann | A survey on domain-specic languages in robotics[END_REF]. They indeed help to raise the level of abstraction through the use of specic concepts that are closer to the respective domain concerns and facilitate validation and analysis [START_REF] Lesire | Validation of real-time properties of a robotic software architecture[END_REF]. A typical process for designing a robot architecture involves 'mix and match' of such architecture paradigms, mathematical models, DSLs, and implementation technologies.

Without any common conformance model, this process is expensive both in terms of time and eort, and absence of systematic approach may result in adhoc designs that are not exible and reusable. Therefore, within the context of architecture design, component development and their support tools, a coherent practice is required for developing architectural frameworks. The purpose of this chapter is:

• To investigate the possibility of a formal meta-framework model so as to model frameworks that support heterogeneous domains related to robotics.

• To propose a formal way to speciy the interactions between dierent architecture concepts (e.g., state transition system [START_REF] Harel | Statecharts: A visual formalism for complex systems[END_REF] and process control system [START_REF] Davis | Software requirements: objects, functions, and states[END_REF]) and paradigms (e.g., behavior-based [START_REF] Arkin | Behavior-based robotics[END_REF] and cognitive architecture [START_REF] Chong | Integrated cognitive architectures: a survey[END_REF]) in the operational space.

Software Architecture

The unprecedented growth of software systems in size and complexity has led to new opportunities, but also to increased challenges in designing and specifying the system.

Architecture frameworks and architecture description languages are created as a way to capture the conventions and common practices of architecting and the description of architecture within each application domain.

A software architecture helps in several purposes such as:

1. To recognize and reuse common paradigms so that their high level relationships and interactions can be clearly understood.

2. To describe the system topology and guide the decisions leading to the system structure.

3. To make principled choices among design alternatives.

4.

To specify high-level properties, which are essential for the analysis of the system.

Denitions of terms that are central to our concept development and further discussions are given below.

Basic Denitions

The following terms and denitions have been adapted from the international standard for describing the architecture of a software-intensive system -ANSI/IEEE Std 1471-2000 [51]. The next section provides more details about this standard.

-A system is a collection of components organized to accomplish a specic function or set of functions.

-The architecture of a system is the system's fundamental organization, embodied in its components, their relationships to each other and to the environment, and the principles guiding its design and evolution.

-The architecture framework are a collection of conventions, principles and practices for the description of architectures established within a specic domain of application and/or community of stakeholders.

-The concern denes an interest in a system relevant to one or more of its stakeholders. A concern pertains to any inuence on a system in its environment, including developmental, technological, business, operational, organizational, political, economic, legal, regulatory, ecological and social inuences.

-An architecture view expresses the architecture of the system-of-interest in accordance with an architecture viewpoint (or simply, viewpoint).

There are some arguments and discussions in the community regarding the denitions and their relationships between the concept of architecture description, framework, and meta-frameworks [START_REF] Emery | Every architecture description needs a framework: Expressing architecture frameworks using ISO/IEC 42010[END_REF][122] [START_REF] Emery | Updating IEEE 1471: architecture frameworks and other topics[END_REF]. In order to position our work and motivate its importance, the relationships illustrated in Figure 5-1 are followed in the rest of the chapter. Architecture conforms to an architecture framework and is specied using an Architecture Description Language (ADL). Architecture addresses known concerns for known stakeholders for the system of interest. Architecture frameworks The fundamental goal of an architecture framework is to codify a common set of architecture practices within a community: for the sake of understandability, commonality and synergy -reducing the need for individual architects to re-invent the wheel; and to promote interoperability. To achieve this goal, the Standard establishes its minimal requirements on architecture frameworks in terms of their content and presentation. Unless otherwise mentioned, in the rest of this chapter, the term 'international standard' refers to ISO/IEC/IEEE 42010:2011(E) [START_REF] Standard | Systems and Software Engineering -Architecture Description[END_REF], Recommended

Practice for Architectural Description of Software-intensive Systems.

Architecture Framework and Architecture Description

The international standard denes architecture framework as conventions, princi- A well-dened architecture allows to reason about system properties at a high level [START_REF] Garlan | Introduction to the special issue on software architecture[END_REF]. Typical properties include interface compatibility between components, interaction protocols, performance, resource consumption, conformance to standards, and reliability. Despite its relevance, the practice of architecture description in robotics, is not much used or appreciated. According to the international standards, an architecture description is a work product to express an architecture.

In the life-cycle of the system, an architecture description has many uses:

-a basis for system design and development activities.

-a basis to analyze and evaluate an alternate implementation of an architecture.

-documenting essential aspects of a system, such as, intended use and its environment, principles, assumption, and constraints to guide future system evolution.

-to guide architecture decisions, their rationales and implications.

-specifying a group of systems sharing common features (such as architectural styles, reference architectures and product line architectures)

Architecture descriptions are used to create, utilize, and manage systems to improve communication and co-operation, enabling them to work in an integrated, coherent fashion. Architecture frameworks and architecture description languages are being created as assets that codify the conventions and common practices of architecting and the description of architectures within dierent application domains.

Model Kinds in Robotics

According to the International standard, conventions for a type of modeling are called model kind. Example of models kinds that are common in robotics are state machines, component-based software architectures, control diagrams, and probabilistic models.

State machines model the discrete behavior of a robot control system. It decides what activities must be running in the system in concurrent ways, and based on which events the system must switch its overall behavior to another set of concurrent activities. The structure of these switches is modeled by the states being connected through transitions. Structural hierarchy abstracts away how the system reacts to a set of events [START_REF] Scioni | Hierarchical Hypergraphs for Knowledgecentric Robot Systems: a Composable Structural Meta Model and its Domain Specic Language NPC4[END_REF].

A Bayesian Network (BN) is a directed acyclic graph G = (V, E) with nodes representing a set of RVs X1, X2, ..., X|V |, and edges denoting conditional dependence relationships between random variables. In a nutshell, the structure of the BN encodes the assertion that each node is conditionally independent of its non-descendants, given its parents [START_REF] Wang | BayesStore: Managing large, uncertain data repositories with probabilistic graphical models[END_REF]. BNs are widely used in robotics for localization, and for several learning algorithms [START_REF] Doucet | Rao-blackwellised particle ltering for dynamic bayesian networks[END_REF].

Knowledge networks such as the semantic web, and conceptual graphs are widely used to enable sharing and reuse of knowledge by specifying the terms and relationships among them [START_REF] Zender | Conceptual spatial representations for indoor mobile robots[END_REF]. In robotics, these kind of models are used to represent knowledgelinked semantic object maps in order to provide a range of information for robots to accomplish complex tasks [START_REF] Tenorth | Knowrob: Map-knowledge linked semantic object maps[END_REF]. In such models, nodes represent facts, data, etc., and edges represent relationships.

Control diagrams such as Cartesian position control and other data ow models such as Simulink [START_REF] Piltan | PUMA-560 robot manipulator position computed torque control methods using Matlab/Simulink and their integration into graduate nonlinear control and Matlab courses[END_REF] consists of node that represent certain functions and edges represents their input/output relationships.

Component based software architectures are approaches used to compose software systems from o-the-shelf and custom components [START_REF] Brugali | Trends in component-based robotics[END_REF]. In such models, nodes represent a piece of software with contractually specied interfaces that implement robotic functionality and the connector represents their interactions [START_REF] Brugali | Software Engineering for Robotics[END_REF].

One can see that all the aforementioned models are some form of Hierarchical Graphs with certain additional properties. This is an important realization since our language proposed in the next section has a basic formalism on which the semantic and other properties are added according to the concerned domain.

Architecture Modeling and Analysis Language

A well-dened architecture framework is a key component for architecture description. Architecture Modeling and Analysis Language (AMAL) together with specic viewpoints and supporting tools forms the core of the operational space in SafeRobots methodology.

A key outcome of IEEE 1471 -Recommended Practice for Architectural Description of Software-Intensive Systems, was the introduction of architecture viewpoints A conceptual overview of dierent constructs is shown in Figure 5-1. The approach we have taken is to dene a set of basic primitives upon which to construct dierent domain models.

AMAL Core Elements

The structure of AMAL is dened using four core elements: Component, Port, Connector, and Role. The semantics of the core elements are extended using properties as detailed in the next section. Figure 5-2 shows relationships between AMAL elements using Ecore diagram. The AMAL metamodel provides minimal syntactic rules using constraints, for example, a port cannot be connected to another port without a connector. The description of each core element is as follows: 3) Connector: A connector represents the interaction between the components and are identied as the building blocks of the architecture. Depending on the domain semantics it can represent a data stream, event connections, state transitions, etc. 4) Role: A role represents the interface of the connectors similar to ports is for components. For example, a remote procedure call (RPC) connector consists of two roles: a callee and a caller role, an event broadcaster connector consists of one broadcaster role and arbitrary number of receiver roles. When connectors connect two components, roles are associated with compatible ports. As a very simple example, Figure 5-3 depicts a system containing two nodes: talker

Open Semantics Framework

Property associated with core elements of AMAL facilitates the annotation mechanism for extending the semantics of the model elements. For example, it can contain information on its semantic information, non-functional properties, the graphical representation of the model element, etc. The contents of the property are not interpreted by AMAL. It has to be dened by the domain models. A deployment domain may use non-functional property associated with the component to dynamically allocate resources.

Figure 5-4 shows the textual representation of the publish-subscribe system. For simplicity, only the semantic information is shown as associated property in the model.

The attributes of the Property element are shown using the syntax -Property name: type = value. For convenience, we represent the property as {name, type, value} in the text. It is to be noted that the textual form of the model is shown only for illustrative purpose. The model creation and manipulation is accomplished using the tools associated with specic viewpoints. However, it is important for the viewpoint or tool developer to understand how it will be captured in the model. For example, if the user click on a tool to create a node in the system, the tool will create a component with associated property as {Node,semantic_element,}. Furthermore, a property can represent complex properties by composing more properties and can refer to other properties according to the AMAL metamodel. This mechanism along with viewpoints and tools provides the framework with dierent viewpoints, customized tools and rich visualizations. The following two sections discuss the concept of viewpoints and views, and constraint specication.

Viewpoints and Views

A Viewpoint of a system is a work product establishing the conventions for the construction, interpretation and use of architecture views to frame specic system concerns. The concept of view and viewpoints is central to the International Standard. A viewpoint is a way of looking at systems; a view is the result of applying a viewpoint to a particular system of interest. In other words, a view is a description of the system relative to a set of concerns from a certain viewpoint. Similar to the use of modules and packages to manage the complexity of system, we employ viewpoints to manage the complexity of framework. Furthermore, the views can be seen as constructs for the management of architecture. The relationship between the aforementioned notions can be seen as follows:

viewpoints : framework :: views : architecture :: packages : system AMAL does not enforce any particular views or viewpoints, but provides facilities for specifying viewpoints and further to create tooling support for view creation, interpretation, modication, etc. AMAL strongly encourages the practice of dening and selecting viewpoints according to the stakeholder's concerns and treating viewpoints as rst-class elements of architecture. In the framework modeled using AMAL, each view is governed by exactly one viewpoint. Each view conforms to one set of conventions, but can be possibly using multiple model kinds. However, for specic purposes, viewpoints can be combined in any manner.

There are two dierent approaches for creating views: constructive and projective approaches. In the constructive approach, views of the system based on model kinds are created individually. These views are then synthesized to an overall model. Model correspondences are performed for integrating views from multiple model kinds. In the projective approach, the views are derived from the overall model. AMAL strongly recommends the projective approach. This is to avoid the problem of view integration and view consistency. Since the semantics of AMAL is open, new model kinds can be extended from the meta-model and hence projective approach is a more convenient approach. Currently, constructive approach has not been applied using AMAL formalism and is not further discussed in this thesis.

Motivated from the benets of Separations of Concerns (SoC) in addressing the inherent complexity in large software intensive systems, multiple views are being used in software architecture. However, they introduce the problem of view integration and model consistency. The notion of multiple views appeared in one of the earliest work titled "Foundations for the study of software architecture" by Perry and Wolf [START_REF] Perry | Foundations for the study of software architecture[END_REF].

Although the concept of view is not dened during that time, it states that:

Three important views in software architecture are those of processing, data, and connections ... all three views are necessary and useful at the architectural level.

Most of the views are not independent or fully orthogonal. Elements of one view are connected to elements in another view, following certain rules and heuristics. A general technique called model correspondences introduced by ISO 42010, is used for expressing relations between views. Model Correspondence rules are constraints on two or more architecture models, which is enforced on a model correspondence.

Constraint Specication

The model instance that conforms to AMAL metamodel is not rened enough to provide all the relevant aspects of a specication. The AMAL metamodel itself is developed as an Ecore model which is typically not rened enough to provide all the relevant aspects of a specication. There is, among other things, a need to describe additional constraints about the objects in the model. Such constraints cannot be described in natural language as they will always result in ambiguities. In order to write unambiguous constraints, formal languages called Object Constraints Language (OCL) is used [START_REF]Object Constraint Language, Object Management Group Std[END_REF].

OCL is a formal language that has been developed as a business modeling language within the IBM Insurance division, and has its roots in the Syntropy method. OCL is a pure specication language; therefore, an OCL expression is guaranteed to be without side eect. When an OCL expression is evaluated, it simply returns a value.

It cannot change anything in the model. This means that the state of the system will never change because of the evaluation of an OCL expression, even though an OCL expression can be used to specify a state change (e.g., in a post-condition).

OCL can be used for a number of dierent purposes. In our context, we use it to to specify invariants on model elements in AMAL metamodel and for to describe preand post conditions on Operations and Methods. An OCL expression is an invariant of the type and must be true for all instances of that type at any time. For example, if in the context of the Connector element in AMAL model, the following expression would specify an invariant that the number of roles must always be more than 2:

context Connector inv:

self.roles > 1

Framework Specication Templates

This section provide templates for documenting framework specication, viewpoints, and views. The template consists of a set of slots or information items followed by a brief description of its intended content, guidance for developing that content, and in some cases appropriate examples are given. Not every slot is needed for specifying the The given AQL query checks whether the property associated with the selected model element is {statemachine,semantic_element,} Typical Stakeholders: A listing of the system stakeholders expected to be users or audiences for views prepared using this viewpoint.

Views: Operation on views: Operations dene the methods to be applied to views or to their models. Operations can be divided into categories:

• Creation methods: These are the means by which the model elements represented by this view are created. This is usually in the form of process guidance and are specic to the tool used for creating viewpoint. Since we adopt Sirius tool, the operations are implemented using the user interface provided by the tool.

• Interpretive methods: These are the means by which view are to be understood by the system stakeholders.

• Analysis methods: These are used to check, reason and transform, predict, apply and evaluate results from this view.

• Design methods: These are used to realize or construct systems using information from this view.

Examples: This section provides examples for the framework developer. Notes: Any additional information that users of this views might need or nd helpful.

Sources: Identify the sources for this views, if any, including author, history, literature reference, etc.

AMAL Specication Formalism

We adopt a formalism to specify the framework. The formalism denes the participating domain models, viewpoints, views, and their relationships.

Denition 1: An architectural framework X, that conforms to AMAL formalism is a tuple

M X , DM, IM, R AM AL X , R DM AM AL , R IM AM AL , where
• M X is the model dened in framework X.

• DM is the domain model where the framework X has conceptual relationships.

• IM is the implementation model that framework X supports. Robotics domain is heterogeneous with domains ranging from conceptual domain such as perception, planning, control, decision making; computational domain consisting of discrete, continuous; software domain consisting of communication middlewares, operating systems, etc. Hence, the meta-framework architecture should be extensible in order to incorporate dierent domain models. The composed domain models should be semantically compatible. For example, assume a model incorporates concepts from two domains a and b. In domain a, the modeling element connector represents a computation process, and in domain b, the connector represents an instantaneous transition between two states. These two domains are semantically incompatible unless the conict between them is resolved, say by assigning the computational process to component.

In Figure 56, model relationships among multiple domain models and implementation models, in AMAL formalism are shown.

Denition 2: The viewpoints V n , of an architectural framework X is a set of tuple

M V 1 , M V 2 , R V 1 V 2 , R V 2 V 1 , where • M V 1 is the model dened in viewpoint V 1 . • M V 2 is the model dened in viewpoint V 2 .
• R V 1 V 2 is a relation that associates model elements from V 1 to V 2 . • R V 2 V 1 is a relation that associates model elements from V 2 to V 1 .
Architectures are specied as a collection of viewpoints and their relationships among them. A viewpoint isolates independently solvable aspect of a system in order to manage complexity. For example, a deployment view of the system addresses only the concerns related to initiating the execution of components in a particular order.

The relation between the viewpoints is an important requirement for an analyzable architecture. The relationships are loosely coupled (uni-directional) or tightly coupled (bi-directional). For example, a coordination view that models `when components should communicate' should be aware of the conguration view that models `who communicates with whom' of a system, while conguration view need not know about the coordination model.

Case Study on an Example Framework

In this section, we describe how a hypothetical framework (say `TrackX') can be designed using our meta-framework. TrackX is a framework for designing software system for tracking vehicles using lidar. It uses concepts and algorithms from perception and object tracking domain. We have selected only minimal concepts from these domains for the simplicity of explanation. The framework shall support model- Viewpoints: structural, coordination. AMAL Formalism: The TrackX framework in AMAL formalism is dened as:

With reference to the domain models, the framework can be dened as:

T rackX AM AL ⇒ M T rackX , P M, CM, RM, GM, R T rackX AM AL , R P M AM AL , R CM AM AL , R RM AM AL , R GM AM AL , R CM P M .
With reference to the required viewpoints, the framework can be dened as:

T rackX AM AL ⇒ M SV , M CV , R AM AL SV , R AM AL CV , R SV CV .
A pictorial representation of the relationship between dierent domains in shown in Figure 7-10. Each element is explained as follows:

M SV denotes the model in the structural view (SV) of the system.

M CV : denotes the model in the coordination view (CV) of the system.

Dierent domain models and their relationships are described below: T rackX captures the relations that are not explicitly captured by other model relationships. In this case, all the relations have been implicitly captured by the model relationships.

Structural viewpoint specication

Viewpoint name: Structural viewpoint Viewpoint overview: The structural view models the interconnection of var-

Related Works

Architecture Description Languages

ADLs developed in terms of the international standard include Rapide [START_REF] Luckham | Specication and analysis of system architecture using rapide[END_REF], Wright [START_REF] Allen | A formal basis for architectural connection[END_REF], SysML [START_REF]OMG, Systems modeling language (OMG SysML) specication, Object Management Group, OMG Available Specication[END_REF], and ArchiMate [START_REF] Iacob | ArchiMate 1.0 Specication[END_REF]. Our approach of providing common syntax with semantic content, whose semantic enrichment is provided specialized subdomain specic language is conceptually related to that of ACME [START_REF] Garlan | ACME: An Architecture Description Interchange Language[END_REF]. ACME is an interchange language for software architecture that provides structural core that represents commonalities between various Architectural Description Languages (ADL) [START_REF] Clements | A survey of architecture description languages[END_REF]. ACME uses annotations to add semantic information by sub-languages. However, the objective is to serve as a common representation for software architectures and that permits the integration of diverse collection of independently developed architecture analysis tools. The Architecture Analysis and Design Language (AADL) is a modeling language standardized by Society of Automotive Engineers (SAE) to specify and analyze software architectures for complex real-time embedded systems.

Views and Viewpoints

There are number of existing approaches utilizing viewpoints and views in software systems architecture. The earliest work on viewpoints appeard in Ross' Structured Analysis in 1977 [START_REF] Ross | Structured analysis (SA): A language for communicating ideas[END_REF]. Many rst generation software engineering techniques used functional and data viewpoints. Nuseibeh, Kramer and Finkelstein treated viewpoints as rst class entities, with associated attributes and operations [START_REF] Nuseibeh | A framework for expressing the relationships between multiple views in requirements specication[END_REF]. Clements et al.

introduced the term viewtype for categorization of viewpoints [START_REF] Clements | Documenting software architectures: views and beyond[END_REF]. Three categories of viewpoints are described in their work: module, component, and connector, and allocation viewtypes. Kruchten's 4+1 view model takes four views as its starting point [START_REF] Kruchten | The 4+ 1 view model of architecture[END_REF]. The integration of these viewpoints is accomplished through a fth viewpoint which is a set of scenarios used to validate the other view and their interactions. The authors of [START_REF] Abd-Allah | Reasoning about the composition of heterogeneous architectures[END_REF] investigated the composition of heterogeneous styles in architectures.

They characterized a style (which is actually a view in our terminology) as a collection of constraints on the structure, behavior, and resource usage of the components and connectors in a software system.

Architecture Meta-Frameworks

The authors of [START_REF] Smeda | Meta architecting: Towards a new generation of architecture description languages[END_REF] introduced Meta Architecture Description Language (MADL) to dene, comment, document, compare architectures, in particular semiformal architectures. Their main proposal is for unifying ADLs in the context of software architectures and to provide reexivity in architecture metamodeling. However our work is at the framework level and we introduced common primitive elements with semantic extensibility to manage complexity of multiple viewpoints and views. Rich Hilliard introduced decorative stance as an alternative to constructive views in frameworks. Our work is more similar to this approach. The approach is to decorate a primary representation with attributes pertaining to other concerns, rather than separate concerns. This is to address multiple-view problem in architectures, that lead dierent specication describe dierent, but overlapping issues. In another work, behavioral semantics are integrated in structural formalism [START_REF] Allen | A formal approach to software architecture[END_REF]. Our method does not enforce any such specic views and it entirely depends on the framework developer. The Practical Architecture Method prescribes no particular view; instead the determination of useful views is part of the architect's work and is driven by concerns related to the specic system [START_REF] Emery | Experiences applying a practical architectural method[END_REF].

Conclusion

Making architecture meta-framework a point of conformance opens new possibilities for interoperability and knowledge sharing in the architecture and framework communities. We tried to make a rst step in this direction by proposing common model and provided a systematic approach that helps in specifying dierent aspects and their interplay in a framework. The multi-domain architecture modeling helps to build integrated intelligent robotic systems. We have presented an architecture description language Architecture Modeling and Analysis Language to model system architectures based on heterogeneous architectural paradigms. The semantic extensibility feature of AMAL helps to rene the semantic knowledge, and to specify inter-domain relationships. It provided a homogeneous development environment irrespective of framework or middleware and thus promoting faster adoption among software developers and system engineers.

My Contributions

The contributions of my thesis brought in this chapter are:

1. Formalized the robotic framework design and development process in order to build custom frameworks and integrate existing best practices in architecture development.

2. A meta-framework language, AMAL is proposed that provides a minimal set modeling elements.

3. The Open Semantic Framework helps to modify and extend the semantics to incorporate dierent domain concepts and to capture the relationships and identify the conicting domain semantics.

4. The model relationships enables integration of various domains in the framework and support building complex robotic systems.

5. Our approach of framework specication and development is suitable to compare various architectures. Describing various architecture with the same formalism facilitates their comparison and analysis. reuse of code generation templates: The models needs to be transformed to executable code at some point of time in the development process. Such model to text transformation templates can be reused across frameworks.

reuse of graphical editors: The tools required for model parsing and visualization can be reused. The views are generated by applying viewpoints to the model. The associated tools for model creation and manipulation can be easily reused. For example, in the new framework, if there is a viewpoint to model state machine, this can be reused from another framework if it uses the same model kind.

reuse of infrastructure: The usefulness of the framework is considerably increased if it provides facilities for logging, messaging, tracing, debugging, etc.

Such supporting tools can be easily imported and reused in our approach.

7. The potential benet of having a common base for the models is developing application and platform neutral meta-architecture. It promotes reuse in system modeling in robotics and in the development of reusable tools and generic algorithms.

8. Irrespective of the framework, the look and feel of the graphical interfaces will be the same. The tools provided with the frameworks provides homogeneous user interfaces and thus promoting faster adoption among users.

Part II

Framework Implementation and Extended Applications 100 Chapter 6

Framework Implementation

Give us the tools and we will nish the job Winston Churchill

Introduction

In a model driven approach, the vision is that models become artifacts to be maintained along with the code. This will only happen if the benet obtained from producing the models is considerably higher and the eort required to keep them in line with the code is considerably lower than the current practice. Models are valuable as tools for abstraction, for summarizing, and for providing alternative perspectives. The value is greatly enhanced if models become tangible artifacts that can be simulated, transformed, checked etc., and if the burden of keeping them in step with each other and the delivered system is considerably reduced. Tooling is essential to maximize the benets of having models, and to minimize the eort required to maintain them.

Specically, more sophisticated tools are required than those in common use today, which are in many cases just model editors. In this chapter, we detail the dierent tools used and the stages involved in implementing the framework by the developer of the tool. Section 6.2 provides a brief overview on Eclipse Modeling Framework and discusses about selected tools supporting the framework development. Dierent stages in our framework implementation process are detailed in Section 6.3.

Eclipse Modeling Framework

Eclipse is an open source software project dedicated to providing a robust, fullfeatured, and commercial-quality platform for developing and supporting highly integrated software engineering tools [START_REF] Merks | The Eclipse Modeling Framework[END_REF].

The Eclipse platform denes a set of frameworks and common services that collectively make up the "integrationware" required to support a comprehensive tool integration platform. Except the small Eclipse runtime kernel, all the platform components are plug-in tools integrated seamlessly through predened extension points [START_REF] Yang | Using Eclipse as a tool-integration platform for software development[END_REF]. Fundamentally, Eclipse is a framework for plug-ins. Beside its runtime kernel, the platform consists of the workbench, workspace, help, and team components. Other tools plug into this basic framework to create a usable application. Plug-ins can also dene new extension points for others to extend. For example, a group of plugins implements the workbench user interface.

The Eclipse Modeling Framework (EMF) is a modeling framework and code generation facility for building tools and other applications based on a structured data model. From a model specication point of view as described in XML Metadata mation [START_REF] Kolovos | The Epsilon Book[END_REF]. All languages in Epsilon build on top of a common expression language that promotes code across your model-to-model transformations, code generators, validation constraints etc .

Framework Implementation Process

In this section, we detail dierent stages in which the framework developer can specify, implement, and deploy the framework tool.

Stage 1: The rst step is to specify the framework using the templates and formalism proposed in Chapter 5. This process identies the domains involved, required viewpoints in the framework, target platform and middleware, etc. The domain models and their relationships are formally specied using our AMAL based approach. Based on the artifacts generated in this stage, the developer creates appropriate Eclipse plugins to implement the framework.

Stage 2: In this stage, the developer implements the framework specication. As discussed in the previous section, Eclipse Modeling Framework is used for implementing the framework.

Stage 2.1: The developer creates meta models of identied domain models involved in the framework. This can be performed in two ways:

1. By creating an Ecore metamodel and mapping its elements with the respective elements in AMAL metamodel. For this procedure, the developer develops the metamodel based on Ecore and generates necessary java templates using the tools by EMF. The developer then develops Model transformation tool to transform the model to our AMAL compatible model. However, we recommend the second procedure, as it eliminates the need to create a model transformation tool.

2. By using the facility provided by Sirius to create model elements directly based on AMAL metamodel. For when the user create a component that represents a state machine, the property of the component will be having name as semantic_element and value as state_machine as shown below.

Property state_machine : semantic_element 104 Sirius supports dynamic changes of tool designs even while the development is in progress and the developer can take advantage of this feature to develop tools much faster.

Stage 2.2:

The developer provides necessary constraints on the model elements.

There are three options available to perform validation on the constraints:

1. Object Constraints Language (OCL): Although many approaches have been proposed to enable automated model validation, the OCL is the de facto standard for capturing constraints in modeling languages specied using objectoriented meta modeling technologies. While its powerful syntax enables users to specify meaningful and concise constraints, its purely declarative and side-eect 3. Epsilon Validation Language (EVL): EVL can be used to specify and evaluate constraints on models of arbitrary metamodels and modelling technologies.

EVL constraints are quite similar to OCL constraints. However, EVL also supports dependencies between constraints (e.g. if constraint A fails, don't evaluate constraint B), customizable error messages to be displayed to the user and specication of xes, which users can invoke to repair inconsistencies. Also, as EVL builds on Epsilon Object Language, it can evaluate inter-model constraints (unlike OCL) [START_REF] Kolovos | The Epsilon Book[END_REF].

In our case, we suggest to use any of the aforementioned methods to specify constraints depending on usecase. We primarily used Sirius validation mechanism as it is easy to use without any external dependencies. In some cases, OCL is also used for specifying the constraints specically while creating a standalone metamodel. EVL is mainly used for validation during model transformation process.

Stage 2.3: Implementing the graphical modeling workbench is the process that consumes most of the time according to our experience. Initially, we used Graphiti

[157] for creating the graphical user interfaces. Later, we switched to Sirius that have inbuilt support for implementing the viewpoints, dierent graphical options, and validation mechanisms.

Stage 3:

Eclipse is an open platform and it is designed to be easily and innitely extensible by third parties. At the core is the Eclipse SDK, various products/tools around this SDK. A plugin is a small unit of Eclipse Platform that can be developed separately. It must be noted that all of the functionalities of Eclipse are located in dierent plugins. The resulting framework that we implemented is a set of plugins as shown in Figure 6-2. In order to promote reusability, the developer should to make it more modular in the form of several plugins. For example, if the framework has a structural viewpoint and behavioral viewpoint, these will be implemented as two separate plugins. The specic viewpoint will be available to the user only if the corresponding plugin is installed. This also helps in mix and match of frameworks according to the user's need. The plugins can also be provided in the form of a repository, from where the user selects and installs according to the requirement.

The only constraint is that necessary relationship and model transformations should be accordingly available in the tool. for systematic engineering of dierent models. Macro process outlines the order in which models are developed, transformed, and coordinated. Micro process is mostly concerned with producing a particular model. We have detailed these processes based on our reference implementation and suggestions based on our experiences. We have carefully avoided certain tools in the process which requires high level of knowledge in the domain of Java object oriented language, EMF, and Eclipse plug-in development.

Our recommended tools simplies the product, reduces design time and rapidly increases the overall productivity of building the framework. However, it is to be noted that our methodology does not enforce any particular formal process in developing the model. This can be considered as one of our future works.

Chapter 7

Extended Applications

Introduction

Framework design and tools development that support the framework are expensive in terms of development time and expertise. Therefore, frameworks should be developed only when many applications are going to be developed within a specic problem domain, allowing to save time by reusing the tools and to recoup the time invested to develop them. The purpose of this chapter to provide some insights on framework development using example applications in which our methodology is applied. The chapter is organized as follows: In Section 7.2 we discuss some of the existing methods for framework development. Section 7.3 and 7.4 discusses two case studies in which specic processes from our methodology are detailed.

Existing Framework Development Methods

Framework Development based on Generalization

When a framework and support tools are designed, the main concern is to recognize things that should be kept exible. These are called the hot spots of the framework [START_REF] Pree | Meta patterns, a means for capturing the essentials of reusable objectoriented design, Object-oriented programming[END_REF]. In order to identify variant parts, some of the following questions should be answered [START_REF] Yang | A UML-based object-oriented framework development methodology[END_REF]:

1. Which concepts of the problem domain exist in variants and should be treated uniformly?

2. Is it possible to nd a concrete concept that can be generalized?

3. Which parts of the system might change?

4. Where might a user want to hook custom code into the framework? and How?

The author of [START_REF] Koskimies | Designing a framework by stepwise generalization[END_REF] suggests a two-phase design method to build an initial version of a framework; the rst phase is called problem generalization and the second phase is called framework design. Problem generalization starts from the specication of a representative application of the intended framework, and generalizes it in a sequence of steps into the most general form. During the second phase the generalization levels of the previous phase are considered in reverse order leading to an implementation for each level. One of the limitations of this method is that essential tasks to problem generalization or framework design are not dened concretely. Also, concrete guidelines to identify hot spots are not described in this method.

Framework Development based on Application Experiences

This method is a pragmatic framework development approach [START_REF] Wilson | Writing frameworks-capturing your expertise about a problem domain, Tutorial Notes[END_REF]. The rst step is to develop some candidate applications in the problem domain. Then, the next step is to identify the common features in these applications and extract these into a framework. To evaluate whether the extracted features are the right ones, redevelop the these applications based on the framework. The advantage of this method is that the framework development is easy, because we extract commonalities from pre-built applications through previously building applications. Whereas it requires much of time to build framework in the case of complex or large domain, and it is dicult to evaluate whether extracted commonalities are the right ones.

Framework Development based on Domain Analysis

The rst activity is to analyze the problem domain so as to identify and understand well-known abstractions in the domain [START_REF] Wilson | Writing frameworks-capturing your expertise about a problem domain, Tutorial Notes[END_REF]. This is similar to the one discussed for lane keep assistance example in Chapter 5. Analyzing the domain requires analyzing existing applications and the analysis of existing applications will also take a large portion of the budget. After the abstractions have been identied, the next step is to develop the framework together with a test application and modify the framework if necessary. Subsequently, a second application based on the framework is developed.

Then, through domain analysis, commonalities are identied. In this direction, we In this chapter, we present two applications in which our methodology and framework development process are explained. We have adopted a mix of the above three approaches for framework development in our case study. We start with problem analysis based on the case study where the required domains are identied, and then we try to generalize using past experiences in framework specication to nally to develop the tool. Specically, our two case studies addresses the following aspects:

• Our rst case study provides an overall process of framework development from requirement specication to code generation. Requirement modeling in problem space is provided as an example in this case study. For experimental purpose, an example transformation process from solution model to a basic architecture model in operational space is also provided.

• Second case study focuses on how frameworks based on cognitive architecture can be specied using our approach. We show how non-functional properties are used in human behavior modeling and their interaction with the help of an example of lane keeping and assistance system.

Case Study 1: Mobile Robot Navigation

In this section, we will use a mobile robot navigation example to demonstrate how a robotic system can be developed and formally specied in our SafeRobots methodolgy. stacles if the mapping process is completed. The system should be based on ROS middleware [START_REF] Quigley | ROS: an Open-source Robot Operating System[END_REF] and the developer intends to use Gazebo simulator [START_REF] Koenig | Design and Use Paradigms for Gazebo, An Open-Source Multi-Robot Simulator[END_REF].

We assume that the knowledge space of the SafeRobots already denes domain specic knowledge, such as the structure of laser range scan, image properties, etc., in the form of knowledge graphs and ontologies. The following section discusses dierent processes, such as requirement modeling, solution space modeling, and architecture modeling corresponding to the problem space, the solution space, and the operational space of the SafeRobots framework, respectively.

Requirement Modeling

The functional and non-functional requirements of the mobile robot are modeled using KAOS notation [START_REF] Van Lamsweerde | Requirements engineering: from system goals to UML models to software specications[END_REF]. It is a hierarchical structure in which the goals are rened into conjoint subgoals (AND renement) or a combination of disjoint subgoals (OR renement). The goals are decomposed until the leaf node (shown as ellipses) that represents a requirement [START_REF] Giese | Living with Uncertainty in the Age of Runtime Models[END_REF]. We use an extended version of KAOS notation in which the non-functional requirements can be represented as nodes or by attaching a NFP model to a functional goal node. Each functional goal can be associated with a nonfunctional model specied using the NFP language. For example, the requirement says that the robot should navigate to the goal position (goal G1.

Solution Space Modeling

The solution space model captures the design space available for a given domain or functionality. The nal executable models generated during the architecture modeling process are called operational models, and they usually comprise a reduced subset of solution space model. The reduction is carried out by considering the required system level non-functional properties such as response time, condence, resolution levels, etc, as constraints to the solution space model. We have already shown a reduction process based on MDPs in Chapter 4. If there are multiple solutions that satisfy the constraints, they are modeled as variation points that can be resolved during runtime when more contextual information is available. The following sections describe how the architecture for the case study can be implemented using a simple subsumption architecture and a more complex Hierarchical Behavior-Based Architecture (HBBA).

Subsumption Architecture

A layered reactive control architecture called subsumption architecture was introduced by Brooks in 1985 [START_REF] Brooks | A Robust Layered Control System for a Mobile Robot[END_REF]. It is primarily based on the decomposition of robot Interaction performance can be aected by an unbalanced allocation of computing resources. For instance, acceptable delays in vocal interaction can be dicult to satisfy if computationally expensive modules are simply added to the architecture: it may result in a robot that can navigate eciently, but may not perform well engaging and interacting with people, or vice versa. To solve this, human-inspired selective attention [START_REF] Broadbent | Perception and Communication[END_REF] takes place in HBBA by perceptual ltering of Perception modules and by conguration and activation of Behaviors. Computing resources allocation can therefore be prioritized according to the current Intentions of the robot.

Architecture Metamodel

A formal model of HBBA using Ecore metamodel is shown in Figure 7-6. It denes that the system primarily consists of modules and knowledge. Task, Desire, Intention, The average resources usage for subsumption architecture is signicantly higher than that of the HBBA architecture due to the fact that all behaviors are active all the time.

However, for the HBBA, the behaviors are activated only when the required desires are present. The higher resource usage for HBBA as seen in the Figure 7-8 occurs when a GoTo Desire with maximum intensity is generated by Scenario Coordinator, which in turn activates the planning and navigation components required to the reach the goal new production rules and memory elements. When such cognitive architectures are integrated in existing systems, there is no formal way to analyze and validate the system, since the control ow cannot be explicitly represented [START_REF] Leuchter | Software engineering for cognitive modeling: Visualization of production systems[END_REF]. Systematic approaches and tools are required so as to increase the breadth of inuence of cognitive models and to prove their capabilities in addressing much more complex tasks, and 1 A production is a rule that collectively form an information processing model of some cognitive task or a range of tasks. Each production represents a retrieval of knowledge from long-term memory.

Production systems are a major formalism for modelling integrated cognitive architecture [START_REF] Young | Production systems in cognitive psychology[END_REF] building robust human-machine systems. In this case study, a framework for designing service oriented architecture is developed using our approach. We use a lane keeping and lane change assistance system as an example application. Specically, we concentrate on the formal denition of dierent aspects of the framework. We explain how multiple domains are incorporated using our AMAL formalism. We also emphasize the importance of modeling Non-Functional properties in human-machine systems using this case study. In the next section, an overview on human-machine systems are provided and it shows how modeling of NFP and QoS, helps in dynamic adaptation of the system. In Section 7.4, we use a Lane keeping and lane changing assistance system as an application to demonstrate our approach. It is to be noted that our intention is to demonstrate framework specication that facilitate cognitive architecture based system, and sometimes during the discussions, we tend to go into the details of the architecture and the domain itself. Hence, the merits and demerits of the architecture is of no concern in our case study.

Overview on Human-Machine Systems

In earlier times, function allocation in human-machine systems was primarily a design decision. Consider the case of cruise control in today's cars, the steering control is allocated to the human driver while the automation is responsible for applying acceleration. This is an example for static function allocation. Some of the traditional strategies for function allocation are: (a) assigning each function to the most capable agent, (b) allocating to machine every function that can be automated, and (c) applying an appropriate allocation policy [168]. However, in adaptive human-machine systems the function allocation is a run-time problem. Consider the case of auto-pilot taking control of an aircraft in emergency situations. In such systems, there is some kind of control sharing and trading that happens. The rst example of adaptive cruise control is a control sharing case, while the second one is a control trading problem. In the latter case, the software takes the control of system with or without the consent of human.

Application: Lane keeping and lane changing assistance system

Lane keeping and lane changing assistance in automobiles is a perfect application in which human and automation have to be integrated seamlessly. Research in intelligent transportation systems has improved the vehicle's ability to sense, understand, make decisions, and ultimately act on its own accord in its operating environment.

The desire for better driver assistance and machine intelligence drives automobile manufactures to pack more sensors and more computation into their vehicles in a cost-eective manner. Hence, the vehicle architecture designer has to integrate various domain concepts and subsystems that have their own design paradigms and constraints. In this case study, we intend to design a framework that supports building an architecture for a system that provides assistance for lane keeping and lane changing. The automation part is the lateral control of the vehicle to keep the vehicle in the same lane and the assistance is provided by applying a thrust on the steering wheel. The system takes control by applying the required torque on the steering wheel in case of lane departure situations. The driver behavior and external environment have to be continuously monitored in order to predict the driver's intention. Specically, the system has to predict whether the driver is trying to change the lane or he/she is erroneously departing from the lane. Most of the commercially available lane keeping assistance systems predict the driver's behavior during the maneuver execution phase. But there are promising results in research, that predicts the driver's intention in the decision phase by modeling cognitive processes behind the behavior.

The theoretical basis for our cognitive model of the driver is based on the works of D. Salvucci [START_REF] Salvucci | Modeling driver behavior in a cognitive architecture[END_REF][START_REF] Salvucci | A two-point visual control model of steering[END_REF][START_REF] Salvucci | Lane-change detection using a computational driver model[END_REF]].

An overview on the application framework

The standard approach for automobile OEMs is to develop systems by assembling components that have been completely or partly designed and developed by external vendors [START_REF] Sangiovanni-Vincentelli | Embedded system design for automotive applications[END_REF]. Because of the increasing complexity of automobile systems with large number of distributed features, such an approach will also lead to various compositional issues commonly known as feature interactions. Therefore, Service Ori- model various human actions. These actions can be seen as services provided by the human, for example, steering, braking, applying acceleration by the driver can be viewed as services provided by the human driver. In some contexts, humans provide high quality services while in some others the machine counterpart does. For example, in the case of assisted parking, human steering control service is delegated to the machine still retaining the authority over acceleration with the driver. Furthermore, selecting the services based on the quality has advantage not only between human and automation agents but also within the automation system itself. Since the functionalities are viewed as services, it is possible to compose basic low level services in dierent fashion to provide dierent functionalities. For example, in cars, voice recognition service can be used in an entertainment system as well as in a navigation system.

In the target application of our proposed framework, we design a SoA for lane keeping and lane changing assistance system based on AMAL formalism. The proposed framework supports designing the architecture by using two complementary views -structural view and behavioral view. An example of an architecture modeled by using this framework is shown in Figure 7-9. The structural view models the interconnection of various computational algorithms and its communication aspects,

ACT-R Cognitive Architecture

The ACT-R cognitive architecture is based on rigid theory of human cognition and provides a computational framework that constraints the models that are cognitively plausible. It consists of four modules -Intentional, Declarative, Visual and Manual Modules. A central production system communicates with these modules through vation that represents the relative ease with which the chunk can be recalled. The activation level decay over time to replicate forgetting aspects of human. Similarly, the procedural rule has real-values quantities called utilities that represent the cost and probability of reaching the goal if that rule is chosen. In addition, learning mechanisms aects the activation and utilities, and creates new chunks and production rules. Conict resolution mechanism uses activation and utilities to choose ring when multiple production condition matches [START_REF] Taatgen | Modeling paradigms in ACT-R, Cognition and multi-agent interaction: From cognitive modeling to social simulation[END_REF].

ACT-R Metamodel The Ecore model shown in Figure 7-11 also contains constraints such as the production system always communicates to modules through buers. The constraints that are not expressed by Ecore model are specied using Object Constraints Language (OCL) [START_REF] Warmer | The object constraint language: getting your models ready for MDA[END_REF]. Figure 7-14 also shows a typical sequence of activities in the system. The request for service can be generated either from human or machine. The service description with all the required parameters and required levels of QoS is computed with respect to the context. For example, emergency braking service will be at a high level while a music streaming service will be at a lower level. Appropriate services found from a repository are composed to check for conict, redundancy etc. and QoS is computed for the composed service. The composed service is veried with QoS specication and the required service is activated. A supervisor continuously monitors the quality level of the running services and reconguration is done when anomalies are detected. the relation between domain models can be specied. Table 7.1 shows the relations that maps model elements across dierent domain models that was described in previous sections. For better understanding, some of the relation models is coupled together, for example, R BV AM AL and R SC AM AL shown as separate relation in Figure 7-10 is coupled in form of R SC BV in Table 7.4.4 to represent the relation between behavioral view and statechart formalism.

R CM

SV represents the relation between Communication Model (CM) and the Struc- tural View (SV) in AMAL formalism. Table 7.1a shows the mapping between CM model elements to model elements in structural view. Intuitively, the communication patterns are mapped to connectors in SV. Table 7.1a also lists the number of roles that each connector is associated with, depending on the patterns, for example, a connector that represent push_timed can have 1 publisher role and `n' number of subscriber role.

R P M

SV represents the relation between Perception Model (PM) and the structural view in AMAL formalism.

∆ψ = k car ∆thw car + k f ollow (thw car -thw f ollow )∆t (7.2)
where ψ is the acceleration value, thw car is the time headway to the lead vehicle, ∆thw car is the dierence of thw car with respect to the previous cycle, and thw f ollow is the time headway for following a lead vehicle. The monitoring model is dened by a random probability measure (p monitor ) that checks left or right lane, and forward and backward with equal likelihood. The decision model is dened by the safe distance (d saf e ) and the lead vehicle distance that is considered as safe by the driver. The memory is modeled as total number of references that can be stored in declarative knowledge, decay time for the memory, and memory creation time. The properties are specied using domain-specic language and they can be parsed only using the domain knowledge. For example, the property ACT-R shown in Figure 7-17 denes two control laws for lateral and longitudinal control, and the execution time for the control loop, model parameters. The QoS property is dened for a service component in the SOA domain when the software realization is used as a service. Notice that qos_policy(response_time, confidence) shown in Figure 7-17 uses the response time and the condence prop- QoS policies of this model in our approach is listed in Table 7.2. In ACT-R domain, the model parameters are production_cycle_time and lane_change_score. The production_cycle_time is the cycle time (nominally 50ms) needed to re a production rule. The lane_change_score is the probability of lane changing behavior by the human driver. It is computed as shown below:

Score = logS(LK) logS(LC) + logS(LK) (7.3)
where LK is the lane keeping model, LC is lane changing model, and S is the similarity score between model simulation and the observed human data (refer to [START_REF] Salvucci | Lane-change detection using a computational driver model[END_REF] for more theoretical details). Two non-functional properties are dened, when this model is realized in software -response_time and confidence. The response_time is dened as 3 X production_cycle_time represented the time required for ring three productions rules (nominally 150ms). Two rules for encoding near point and far point, and one to issue motor commands as shown in Figure 7-18. When this software implementation is used as a service in SOA domain, these non-functional properties are employed to compute the QoS. Table 7.2 shows that QoS is the sum of normalized response_time and confidence. Hence, the main idea is to determine the relevant parameters in higher abstraction level (QoS in SOA domain) using independent low-level domain-specic parameters (model parameters in ACT-R domain).

Domain

Conclusion

In this chapter, we started by discussing some of the existing methods for framework development. Two applications in which our methodology and framework development process were then explained. We have adopted a mix of the three approaches for framework development in our case study. We started with problem analysis based on the case study and subsequently, required domains were identied, and then we tried to generalize using past experiences in framework specication. Our rst case study provided an overall process of framework development from requirement specication to framework development in operational space. For experimental purpose, an example transformation process from solution model to a basic architecture model in operational space is also provided. Second case study focused on how frameworks based on cognitive architecture can be specied using our approach. We showed how non-functional properties are used in human behavior model and their interaction with the help of a case study on lane keeping and assistance system. The process of developing robotic software frameworks and tools for designing robotic architectures is expensive both in terms of time and eort, and the lack of a systematic approach may result in adhoc designs that are not exible and reusable. Accordingly, we identied the current model-driven approaches in robotics and we analyzed how these approaches achieve general modeling related advantages and how eective they are in satisfying robotic domain specic requirements. Based on our comparative survey on existing model-driven frameworks in robotics and qualitative analysis of their features, we found that many of the domain-specic requirements such as architecture level analysis, system reasoning, non-functional property modeling, run-time models, component composition, etc., were addressed dierently in these approaches.

Hence, it is hard to nd a single approach that has features according to one's requirement. In addition, it is dicult to reuse these solutions encoded in tools, model transformations, and middleware modules. Systematic development process and detailed instructions for building such frameworks and supporting infrastructure have not been studied enough. In this direction, the thesis proposes a conceptual methodology and development approach that facilitates specication, design, and deployment of framework for robotic systems.

We analyzed the importance of specifying and integrating NFPs in Framework development in Robotics domain. Providing a systematic way of NFP specication and integrating it with development process by appropriate tools are essential for ecient framework development process. The importance of Non-Functional properties in robotics and human-machine systems were discussed with an example from cognitive architecture domain. Modeling those properties are necessary in architectures where functionality alone cannot be used for making both design time and run-time decisions. Our NFP metamodel provides a generic base for specifying the non-functional aspects of both human and machine models. The main challenge in nding structure for NFP specication is to provide a exible mechanism to address a large variety of property types and providing a tooling support to manage them. The challenge of dealing with heterogeneous attributes are addressed by categorizing the attributes into proles hierarchically and then using policies to compare at a higher abstraction level.

We studied common reasons that make the robotic system designs fallible by taking into account the previous experience of robotics experts in various experiments in academics and industry. For motivational purpose, we used an experience report on developing a lidar based vehicle tracking system in an industrial context. To address the identied problems, we proposed a modeling language -Solution Space Modeling Language (SSML), to formally model the solution space and to specify the quality attributes during design time. Solution space modeling can expand this design space, help nding the best possible solution, and also permit to perform run-time adaptation of the system. Solution model helps in early analysis of quality attributes, to identity variations and acts as a bridge between problem and implementation space.

The resolution of solution space might not always result in a static operational model.

Typically, the resolution process performed during development time results in a subset of solutions that are modeled as variation points in the architecture. This is attributed mainly due to certain context-based properties that can be estimated only during runtime. We formally dened the solution space to operational space transformation process and employed a probabilistic approach to resolve the solution model during design time and execution time. These operations are handled automatically by the framework tool and are independent of any particular robotic framework.

The specication of architecture framework is intended to facilitate its development and to establish the relationships between dierent domain models in a formalized manner. We saw that most of the discussed model kinds in robotics are some form of Hierarchical Graphs with certain additional properties. This is an important observation since our metamodel has a basic formalism on which the semantic and other properties are added according to the concerned domain. Making architecture meta-framework a point of conformance opens new possibilities for interoperability and knowledge sharing in the architecture and framework communities. The rst step in this direction is made by proposing common model and by providing a systematic approach that helps in specifying dierent aspects and their interplay in a framework. We emphasized on the infrastructure modularity and the reuse of transformation tools and middleware modules. The uniform denition and underlying common conformance model of architecture viewpoints and coordinated collection of these viewpoints can promote reuse of tools and techniques to the robotic communities using these frameworks. It is also possible to integrate existing tools based on

Eclipse that has a well-formed meta model by mapping its elements with that of our AMAL model.

As the community nd better ways to abstract and standardize concepts in robotics, Domain Specic Languages (DSLs) will become more and more attractive. By mapping these concepts with our meta level models, it is possible to save considerable amount of time for development tools by reusing system infrastructure code. We believe that combining the benets of integrating existing solutions with benet of having common underlying structure result in more mature tools. In addition, by specifying the relationship with other domain models in an already existing framework, it is possible to integrate these DSLs with less eort. We also discussed how our methodology can be employed to model domain knowledge and how they can be applied in intelligent software tools and processes, to develop complex robotic systems. The main challenge is to adopt the domain model at the appropriate granularity to assist the system designer in systematic software development process to develop ecient and reusable software for robotic systems. search problem [START_REF] Harman | The role of articial intelligence in software engineering[END_REF]. Our experience indicates that the existence of large solution space available for system designers leads to poor software quality. In Chapter 4, we showed that multiple algorithms are available for implementing a functionality in robotics and early decisions assuming future operating conditions tend to degrade the software quality. Once the solution space for a given problem is modeled in our SSML, computational search techniques can be applied to evaluate the system objectives and to converge to a reduced set of solutions. We showed one method using a probabilistic method. However, more research is required in this direction, especially when the system consists of humans and robots with a specic goal to accomplish. For example, the system's objective to maximize its Quality of Service (QoS) can be dened as:

M aximize k i=1
QoS(m i )

(8.1)
where m i is an abstract term that represents an algorithm (algorithmic sequence), model (human or automation), or a control ow. We have seen the benets of modeling NFP of human driver, automation and their interaction in the case study of assistive lane keeping system for vehicles. The QoS of the m i can be dened as:

QoS(m i ) = n j=1 c ij x ij (8.2)
where, c ij are application-specic coecients and x ij are model parameters.

It is an open research question how adaptation can be made in real world complex systems.

There exist some interesting approaches based on ontologies and genetic programming in the domain of Service Oriented Architectures (SOA) [START_REF] Canfora | An approach for QoS-aware service composition based on genetic algorithms[END_REF], but these are still in their infancy.

Part IV

A.1.2 Graphical Modeling Workbench

Building a very exible graphical editor for editing the models is really a laborintensive task. EMF provides an object graph for representing models, as well as capabilities for (de)serializing models in a number of formats, checking constraints, and generating various types of tree editors for use in Eclipse. The Graphical Editor Framework (GEF) and Draw2D provide the foundations for building graphical views for EMF and other model types [START_REF] Merks | The Eclipse Modeling Framework[END_REF]. The Graphical Modeling Framework (GMF), by encapsulating GEF and Draw2D, provides a tool for creating graphical editor with a high degree of exibility. Creation of editor in GMF is often complex and highly depends on Java, XML and Eclipse plug-in knowledge.

To implement graphical interfaces and tools for our methodology, we choose a graphical modeling workbench, Sirius, whose concepts of viewpoints and view lies closer to our approach. In addition, the structure of our framework description templates discussed in Chapter 5 makes it easier for the framework developer to implement it.

Sirius

Sirius framework is built on top of Graphical Modeling Framework (GMF) and uses interactive editors called "modelers" to create, visualize and edit models. Depending [177] as recommended language for dening expressions. By using a Java class as Java Extensions and Acceleo queries, dened in .mtl les, Sirius supports customization according to the particular user needs in form of service methods which is available inside all the representations dened in the viewpoint. Considering that Sirius encapsulates GMF, user can customize the program code on GMF level too. However, this is an advanced feature, because user must have a deep knowledge of GMF.

The ve main concepts on which Sirius is based are stored using Viewpoint Specication Model (VSM). In the Sirius terminology, the following concepts are dened:

-viewpoint is a core element which is a logical set of representation specications and representation extension specications.

-representation is a group of graphical construction which represent domain data.

It also describes the structure, appearance and behavior of models. There are four

Model to Model Transformation

Model to model transformation templates are dened using Epsilon Transformation Language (ETL). ETL provides all the standard features of a transformation language but also provides enhanced exibility as it can transform many input to many output models,and can query/navigate/modify both source and target models. More specically, ETL can be used to transform an arbitrary number of input models into an arbitrary number of output models of dierent modelling languages and technologies at a high level of abstraction. ETL adopts a hybrid style and features declarative rule specication using advanced concepts such as guards, abstract, lazy and primary rules, and automatic resolution of target elements from their source counterparts.

Also, as ETL is based on EOL reuses its imperative features to enable users to specify particularly complex, and even interactive, transformations [START_REF] Kolovos | The Epsilon Book[END_REF].

Model to Text Transformation

Code generation is a Model to Text transformation that translates a source model that is described by a DSL and produce a target model that usually is described by a general purpose programming language, such as Java or C++.

The code generation templates in SafeRobots framework are dened in Epsilon Generation Language (EGL). EGL provides a language tailored for model-to-text transformation (M2T). EGL can be used to transform models into various types of textual artefact, including executable code (e.g. Java), reports (e.g. in HTML), images (e.g. using DOT), formal specications (e.g. Z notation), or even entire applications comprising code in multiple languages (e.g. HTML, Javascript and CSS).

EGL is a template-based code generator (i.e. EGL programs resemble the text that they generate), and provides several features that simplify and support the generation of text from models, including: a sophisticated and language-independent merging engine (for preserving hand-written sections of generated text), an extensible template system (for generating text to a variety of sources, such as a le on disk, a database server, or even as a response issued by a web server), formatting algorithms (for producing generated text that is well-formatted and hence readable), and traceability [%=out.preserve("/*", "*/", "anId", true, //user code here %]

3- 4 A 4 - 4 7 - 9 153 A- 6 154 XII 1 Feature

 4447915361541 high level NFP specication of Eciency property of human driver and automation, and their interactions . . . . . . . . . . . . . . . . . 4-1 Test Vehicle used for vehicle tracking experiment. Lidar and GPS are mounted on top of the vehicle and embedded computers are located in the trunk of the vehicle (see picture inset). . . . . . . . . . . . . . . . 4-2 Relationship between the proposed models . . . . . . . . . . . . . . . 4-3 Metamodel (left) and its graphical representation (right) of SSML. Dispatch Gate, Port, and Connector represents the functional aspect and NFP and QoS Prole represents the non-functional aspect. . . . . . . IX Metamodel for functional modeling (left) and graphical representation of dispatch gates (right). . . . . . . . . . . . . . . . . . . . . . . . . . 4-5 Solution space model for tracking system. High level model is shown (top), zero delay gates (G1-5) are inserted to separate the computations. Connector C1 representing data preprocessing is modeled (right) 4-6 Connector C2 representing segmentation shown in Figure 4-5 is modeled in the gure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-7 Vehicle Tracking Results: Segmented point clouds (left), detected vehicles (middle), tracked vehicles (right) . . . . . . . . . . . . . . . . . 4-8 SSML Gates and corresponding MDP models . . . . . . . . . . . . . 4-9 Design-time model analysis . . . . . . . . . . . . . . . . . . . . . . . . 4-10 Solution space model for tracking system (top) and the corresponding MDP model (down). . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-11 An example of annotated runtime MDP model (top) and the probability analysis of expected utility forecast (down) . . . . . . . . . . . . . 5-1 Relationship between various concepts related to architecture and framework . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-2 Metamodel of Architecture Modeling and Analysis Language (AMAL) 5-3 Illustration of AMAL model instance with semantic information . . . 5-4 Simple publish-subscribe system represented in AMAL . . . . . . . . 5-5 Screenshot of the model creating methods implementing in Sirius. The gure shows a component creating on the left and a connection creation method on the right. Note that roles are also created while a connector is created. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-6 AMAL Model Relationships . . . . . . . . . . . . . . . . . . . . . . . 5-7 A prototype model of vehicle tracking system designed using the TrackX framework. Structural view (left) and Coordination view (right) of the system is shown . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-8 An illustration of the proposed framework topology . . . . . . . . . . 5-9 Framework model of a TrackX framework . . . . . . . . . . . . . . . . 5-10 Model relations between Communication Domain Model (CM), Perception Domain Model (PM), ROS Model (RM), and AMAL core elements X 5-11 Visualization of state transition view and its corresponding AMAL model 6-1 Eclipse modeling framework and supporting tools . . . . . . . . . . . 6-2 Structure of the framework with appropriate plugins . . . . . . . . . . 7-1 Illustration of features discussed in the respective case studies . . . . 7-2 Requirement model using KAOS notation . . . . . . . . . . . . . . . 7-3 A excerpt form solution space model of perception and navigation domains . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-4 Ecore metamodel of subsumption architecture . . . . . . . . . . . . . 7-5 Architecture Model in AMAL formalism . . . . . . . . . . . . . . . . 7-6 Ecore metamodel of HBBA architecture . . . . . . . . . . . . . . . . 7-7 Architecture for the case study . . . . . . . . . . . . . . . . . . . . . 7-8 CPU usage for Subsumption and HBBA architecture . . . . . . . . . Architecture modeled in the proposed framework . . . . . . . . . . . 7-10 Framework model of driver assistance system using AMAL formalism. Various domains and their relationships are shown. . . . . . . . . . . 7-11 Ecore diagram of ACT-R metamodel . . . . . . . . . . . . . . . . . . 7-12 Ecore diagram of Harel statechart . . . . . . . . . . . . . . . . . . . . 7-13 Ecore diagram of relational model R ACT R SC between ACT-R model and statechart model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-14 A reference model for service oriented architecture . . . . . . . . . . . 7-15 Ecore diagram of service oriented architecture domain model . . . . . 7-16 Ecore diagram of communication domain model . . . . . . . . . . . . 7-17 Control component in AMAL formalism . . . . . . . . . . . . . . . . 7-18 Production system in ACT-R driver model for lane changing behavior using statechart formalism . . . . . . . . . . . . . . . . . . . . . . . . A-1 Overview of the EMF tool set . . . . . . . . . . . . . . . . . . . . . . A-2 Graphical Workbench Specication using Sirius . . . . . . . . . . . . A-3 Basic concept behind Model Transformation . . . . . . . . . . . . . . A-4 Metamodel for ROS Middleware . . . . . . . . . . . . . . . . . . . . . XI A-5 Code Snippet showing a M2M ETL template for transforming a AMAL compliant model to ROS Middleware-based model . . . . . . . . . . . Code Snippet showing a M2T EGL template for generating C++ code from a ROS + Boost Statecharts model . . . . . . . . . . . . . . . . . Comparison of MDSE Approaches in Robotics . . . . . . . . 4.1 Solution comparison for segmentation w.r.t application: Ground truth generation and Autonomous Driving . . . . . . . . . . . . . . . . . . 7.1 Metamodel relations between Communication Domain Model (CM), Perception Domain Model (PM), Statechart Model (SM), ROS Model (RM), NFP Model (NFP), SOA Model (SOA), Structural View (SV) and Behavioral View (BV) . . . . . . . . . . . . . . . . . . . . . . . . 7.2 An example for estimation of quality parameters while composing multiple domains . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . seen further it is by standing on the shoulders of giants

BRICS

  Component model[START_REF] Klotzbuecher | The BRICS Component Model: A Model-Based Development Paradigm For Complex Robotics Software Systems[END_REF] is built upon two complimentary paradigms -Modeldriven approach and Separation of Concerns (SoC). The syntax of the model is represented by Component-Port-Connector (CPC) meta-model and their semantics is mapped to the 5Cs -Communication, Computation, Conguration, Coordination, and Composition. The components represent computation and can be hierarchically composed to represent composite components. A composite component contains a coordinator who is in charge of starting and stopping the computational components.

3 .

 3 Perform a Model to Text (M2T) transformation to generate executable code (currently Orocos and ROS middleware are supported). RobotML RobotML is a DSL for designing, simulating, and deploying robotic applications. It is developed in the framework of the French research project PROTEUS [19]. The domain model consists of architecture, communication, behavior, and deployment metamodels. The architectural model denes the structural design using the CPC model. In addition, it also denes the environment, data types, robotic mission, and platform. The communication model associated with ports denes the type of communication -dataow port or service port. The behavior model is dened using state machines. Specic activities are associated with states and transitions are mapped to specic algorithms. The deployment model species a set constructs that dene the assignment of each component to a target robotic middleware or simulator.

( 1 .

 1 called component hull in SmartSoft terminology) that mediates the external visible services of a component and internal component implementation. The skeleton provides links to four dierent artifacts: internal usercode, communication to external components, platform-independent concepts such as threads, synchronization, etc., and platform-specic middleware, and operating system. The communication between external services (interfaces to other components) and internal visible access methods (interface to user code inside component) is based on a set of communication patterns. A set of seven communication patterns are identied that are relevant to robotics systems: send, query, push newest, push time, event patterns, state, and wiring patterns. The wiring pattern provides dynamic connection of components at run-time. These patterns provide required abstraction from implementation technologies with respect to the middleware systems. In order to promote loose coupling between components, the objects are transmitted by value and the data are marshaled into a platform-independent representation for transmission. The behavior of the component is specied by an automaton with generic states Init, FatalError, Shutdown, and Alive. The Alive state can be extended by the user-dened states. The life cycle of the component is managed using these pre-dened states including the fault detection. The workow can be summarized as follows: Create a Platform-Independent Model (PIM) of a component skeleton with stable interfaces to usercode, externally visible interfaces, and interfaces to Smart-Soft framework. The component model contains explicit parameters and attributes, that nally need to be validated while generating platform-specic models (e.g., wcet: 100 ms [requirement]).

Figure 1 - 2 :

 12 Figure 1-2: A comparison of vertical and horizontal separation of concerns

Figure 1 - 3 :

 13 Figure 1-3: Architecture Modeling Spectrum in Robotics

Figure 1 - 3 .

 13 Figure 1-3. One can notice the concentration of architectures on both ends of the spectrum and the signicant gap in the middle. Our meta-framework approach, proposed in Chapter 5, tries to lls this gap by acting as a transition architecture model that bridges the gap between conceptual architectures and low level implementation architectures.

Figure 1 - 4 :

 14 Figure 1-4: Relationship between the concept of Architecture and Framework

Figure 2 - 1 :

 21 Figure 2-1: Informal Model for a mapping system

Figure 2 - 2 :

 22 Figure 2-2: Developmental Phases and Conceptual Paradigms in SafeRobots Framework

Figure 2 - 3 :

 23 Figure 2-3: SafeRobots Methodology

Figure 2 - 4 :

 24 Figure 2-4: Transformation from solution space to operational space

Figure 2 -

 2 5a shows an informal model of a functional model for navigating a mobile robot. The dark and white circle represents the starting and ending points of the directed graph representation. The model shows that for navigating a mobile robot, four dierent operations: Move Forward, (a) Navigate (b) Sensor fusion and Mapping

Figure 2 - 5 :

 25 Figure 2-5: Informal model of mobile robot functionality

ure 2 -

 2 5b shows a functional model for a sensor fusion and mapping operation for a mobile robot. The Sensor Fusion and Sampler block receives data from two Laser acquisition blocks and sends data to the SLAM block. In a certain sense, the model can be viewed as a data ow diagram, but conceptually it shows the relationship between functions in order to achieve more complex functions. Non-Functional model are also linked with these functions that can be in the form of attributes as shown in Figure2-5b. Non-Functional model captures the non-functional properties of a functionality.

  software development approaches: Component-Based Software Engineering, Model-Driven Software Development, and Knowledge-Based Engineering. The developmental phases in this framework can be classied into four phases: General Domain Knowledge Modeling, Problem Specic Solution Modeling, Problem Specic Concrete Modeling, and Executable Code Generation. Functional and Non-Functional Metamodel are proposed to model functional and non-functional aspects of the system.

Figure 3 - 1 :

 31 Figure 3-1: Models and their Interactions in a typical Human-Machine System

Figure 3 -

 3 Figure 3-2: NFP Metamodel

Figure 3 - 3 :

 33 Figure 3-3: Common tooling support with additional editors for having multiple values for a property and a navigator for browsing history of values

Figure 3 - 4 :

 34 Figure 3-4: A high level NFP specication of Eciency property of human driver and automation, and their interactions

Figure 4 - 1 :

 41 Figure 4-1: Test Vehicle used for vehicle tracking experiment. Lidar and GPS are mounted on top of the vehicle and embedded computers are located in the trunk of the vehicle (see picture inset).

- 1 .

 1 The tracking system should detect vehicles in the environment and compute its state -2D position and velocity. It was foreseen to use the system for the following scenarios: a) Ground truth generation, b) Path planning for autonomous vehicle, c) Trac surveillance, and d) Map building applications. The experiment was successfully completed, however, in an ad-hoc manner that made it impractical in several other anticipated application scenarios. This section document some of the encountered problems and classies them into four core categories.In our work, we employed the classical approach of performing data association on segmented scenes across frames followed by the probabilistic state estimation. The process ow is composed of the following four stages: a) Data acquisition: Spatiotemporal point cloud data is acquired; b) Segmentation: Points clouds are segmented to object level; c) Data association: Point cloud features are computed for segmented clusters and then associated with objects across frames; d) State estimation: Probabilistic inference methods such as Kalman Filters, PHD Filters are applied to estimate the position and velocity of the detected vehicles. Some of the relevant problems encountered during the design and development of the tracking system are discussed below.

  2, the desirable features for a solution space model are deduced: a) It should be a graphical model that can be visually inspected, as well as machine readable; b) It must be a hierarchical model that provides views at dierent granularity levels; c) Non-Functional Properties (NFP) and Quality of Service (QoS) must be explicitly stated; d) It must capture

Figure 4 - 2 :

 42 Figure 4-2: Relationship between the proposed models

Figure 4 - 3 :

 43 Figure 4-3: Metamodel (left) and its graphical representation (right) of SSML. Dispatch Gate, Port, and Connector represents the functional aspect and NFP and QoS Prole represents the non-functional aspect.

a)

  Splitter gate consists of 1 input port and n output ports. It creates n splits/copies of the input data and transfers to its output ports. b) Merger gate consists of n input ports and 1 output port. It merges the data from n input ports to the output port.

Figure 4 - 4 :

 44 Figure 4-4: Metamodel for functional modeling (left) and graphical representation of dispatch gates (right).

Figure 4 - 5 :

 45 Figure 4-5: Solution space model for tracking system. High level model is shown (top), zero delay gates (G1-5) are inserted to separate the computations. Connector C1 representing data preprocessing is modeled (right)

Figure 4 -

 4 [START_REF] Mohamed | Middleware for robotics: A survey[END_REF] shows the high level model of a classical approach in tracking described in section 4.2. Four connectors, C1, C2, C3, C4, represent data preprocessing, segmentation, data association, and state estimation process and the zero delay gates are inserted to dierentiate between these processes. This model consists of single sequence of processes that do not have multiple solution paths at this hierarchical level. In this context, a solution is referred as an execution path or simply a path in the solution space model. In textual form, it is represented as a sequence of labels indicating gates and nodes in that solution. The path represented by adjacent parenthesis, for example (path 1)(path 2), indicates a mandatory parallel execution path. The lidar data preprocessing solution model captures two solutions: G11-C11-G12-C13-G15-C18 and G11-(C11-G12-C14-G13-C16)(C12-G13-C15)-G14-C17-G15-C18. The two solutions do the same functionality: converting raw sensor data into point cloud frame. The dierence between the two solutions is the quality aspect that changes with context. In this case, context represents the motion of the vehicle and the dierence in quality is due to time latency of lidar, as explained in section 4.2. The NFPs that are considered for this process are performance and resource cost. The NFP attributes that model performance are response time, resolution, and average distortion. An example snippet from the NFP model for data preprocessing represented by C11 is shown in Listing 4.1. CONTEXT : vehicle NFP : vehicle_motion NFP_ATTRIBUTES : velx : base_velocity_x : msrd : dynamic : mps , vely : base_velocity_y : msrd : dynamic : mps , velz : base_velocity_z : msrd : dynamic : mps , rr : roll_rate : msrd : dynamic : degpsec , pr : pitch_rate : msrd : dynamic : degpsec , yr : yaw_rate : msrd : dynamic : degpsec ; NFP_POLICY : vehicle_motion_policy () ; *********************************************************************************** NFP : C11 . response_time ; NFP_ATTRIBUTES : fps : frame_per_second : msrd : static : int , tp : transmission_speed : msrd : static : msec ; wcet : worst_case_execution_time : est : static : msec ; NFP_POLICY : response_time_lidar_policy () ;

  : angular_resolution : est : static : deg , rps : rotations_per_second : msrd : static :Hz , tlppr : total_laser_points_revolution : msrd : static : int , pplpr : points_per_laser_per_revolution : msrd : static : int ; NFP_POLICY : resolution_lidar_policy () ; -----------------------------------------------------------------------------------IMPORT NFP C11 . response_time , C11 . resolution , C11 . average_distortion NFP : C11 . performance ; NFP_ATTRIBUTES : rtl : response_time , rl : resolution_lidar ; NFP_POLICY : c11_performance_policy () ; -

1 :

 1 Relevant snippets of the Non-Functional Model of vehicle, environment, and lidar data preprocessing process.Another signicant advantage of modeling functional and non-functional aspects separately is that certain invalid compositions of systems can be found. For example, referring to the problem described in section 4.2 regarding PFH feature correspondence failure, such anomalies in system composition can be captured without explicitly indicating that Point Feature Histogram (PFH) feature `requires' undistortion process. Listing 4.1 shows an example of non-functional properties associated with Lidar data parser (connector C11 in Figure4-5). The modeling elements comply to the data structure presented in Chapter 3. Resolution property of lidar data preprocessing process shown in Listing 4.1 using vehicle context to determine the resolution of the point cloud data. Hence, if PFH feature that requires a better resolution is composed without undistortion process, the QoS of the system will be lower since the resolution constraint does not satisfy point cloud resolution level.The solution space for segmentation process represented by connector C2 in Figure4-5 is modeled in Figure4-6. The objective is to cluster a point cloud frame into smaller clusters in such a way that each cluster represents individual objects. There are multiple data processing steps and algorithms to achieve the goal. In general, a point cloud data can be segmented into clusters using two methods: 1) By directly processing the 3D data and clustering using some criteria such as Euclidean distance or 2) By mapping the point cloud to a 2D image and performing segmentation in 2D space using image processing techniques and then projecting back to the 3D space to compute the nal point cloud clusters. Each algorithmic step indicated in Figure4-6is briey explained as follows:Ground Classier: The algorithm can classify ground and non-ground points from a point cloud frame. By rejecting the ground points, this algorithm can signicantly reduce the number of points for further processing.2D Projection Method: This method uses (x,y) coordinates of the point cloud and converts it to a two-dimensional binary image. This is best suited for point clouds consisting of non-ground points and hence, it receives data from a ground classier.Euclidean Clustering: This algorithm uses Euclidean distance to cluster the point clouds. It can be applied on non-ground point cloud data to generate the nal point cloud clusters.2.5D Projection: This algorithm can convert a point cloud to a 2D grayscale image.

Figure 4 - 6 :

 46 Figure 4-6: Connector C2 representing segmentation shown in Figure 4-5 is modeled in the gure

1 :

 1 Solution comparison for segmentation w.r.t application: Ground truth generation and Autonomous Driving Image Segmentation: Using image processing techniques, connected regions are found in the image and a bounding box is computed for each region. 2D to 3D Box Mapping This uses a list of 2D boxes and the correspondence point clouds and generates 3D point cloud clusters. Some intermediate results are shown in Figure 4-7.

Figure 4 - 7 :

 47 Figure 4-7: Vehicle Tracking Results: Segmented point clouds (left), detected vehicles (middle), tracked vehicles (right)

Figure 4 - 8 :

 48 Figure 4-8: SSML Gates and corresponding MDP models

Figure 4 -

 4 10 shows the translated MDP model for the point cloud segmentation solution model. The states are annotated with two kinds of NFP property -Execution time (ET) and Resolution (Res). These are translated directly from the solution model. The transformation of solution space model to MDP model is performed by the SafeRobots tool and is generally hidden from the user.

Figure 4 - 9 :

 49 Figure 4-9: Design-time model analysis

Figure 4 - 10 : 4 - 11 .

 410411 Figure 4-10: Solution space model for tracking system (top) and the corresponding MDP model (down).

Figure 4 - 11 :

 411 Figure 4-11: An example of annotated runtime MDP model (top) and the probability analysis of expected utility forecast (down)

Figure 5 - 1 :

 51 Figure 5-1: Relationship between various concepts related to architecture and framework

  ples, and practices for the description of architectures established within a specic domain of application and/or community of stakeholders [51]. Architecture frameworks and architecture description languages (ADLs) are two mechanisms widely used in architecting. The uses of architecture frameworks include: creating architecture descriptions; developing architecture modeling tools and architecting methods; and establishing processes to facilitate communication, commitments and interoperation across multiple projects.

Figure 5 - 2 :

 52 Figure 5-2: Metamodel of Architecture Modeling and Analysis Language (AMAL)

Figure 5 - 3 :

 53 Figure 5-3: Illustration of AMAL model instance with semantic information

Figure 5 - 4 :

 54 Figure 5-4: Simple publish-subscribe system represented in AMAL

Figure 5 - 5 :

 55 Figure 5-5: Screenshot of the model creating methods implementing in Sirius. The gure shows a component creating on the left and a connection creation method on the right. Note that roles are also created while a connector is created.

Figure 5 - 6 :

 56 Figure 5-6: AMAL Model Relationships

Figure 5 - 7 :

 57 Figure 5-7: A prototype model of vehicle tracking system designed using the TrackX framework. Structural view (left) and Coordination view (right) of the system is shown

Figure 5 - 8 :

 58 Figure 5-8: An illustration of the proposed framework topology

Figure 5 - 9 :

 59 Figure 5-9: Framework model of a TrackX framework

  model. It captures the semantic compatibility between the domain and conicts (if any) in the relationship. For example, the previous two relation model maps communication pattern in CM and Dispatch_Gate in PM to the same model element Connector in SV. The relation R CM P M species that these two concepts are seman- tically compatible since Dispatch_Gate and communication pattern represent the interaction between computations in their respective domains. R CV AM AL represents the relation between state machine formalism in the coordination view and the model elements in AMAL formalism. Figure 5-10 shows the mapping between SM model elements to model elements in coordination view. States are mapped to component and transitions to connectors in relationship model. It is to be noted that components in the structural view and coordination view need not be semantically compatible since it resides in two dierent views. R CV SV represents the relation from coordination view to structural view. A component (state) in CV is mapped to arbitrary number components in the SV. It means that a state inuence (activate/deactivate) one or more components in structural view. In addition, the relationship is unidirectional from CV to SV denoting loose coupling between the two views. It is recommended and in fact comparatively easy to provide only a unidirectional mapping because the structural model can express dierent behavior depending on the coordination model. R RM AM AL represent the relation from ROS middleware implementation model to AMAL formalism. For convenience, we map the model elements from structural view model elements in AMAL to ROS since coordination view do not inuence the ROS node interconnection structure directly. R GM AM AL and R RM GM are not shown explicitly as Gazebo internally depends on ROS middleware and hence have the similar relation as R RM AM AL . R AM AL

Figure 5 - 10 :

 510 Figure 5-10: Model relations between Communication Domain Model (CM), Perception Domain Model (PM), ROS Model (RM), and AMAL core elements

6 .

 6 Our approach of having minimal primitive elements with associated properties promotes reuse of software reuse of model to model transformation code: Our framework is dened as a collection of viewpoints and views, and the relationship between the domain models. New frameworks can be created with dierent set of domain models and mixing it in dierent fashions. Since all the domain models use the same set of primitive elements, the model to model transformation code can be easily reused in the new framework.

Figure 6 - 1 :

 61 Figure 6-1: Eclipse modeling framework and supporting tools

  free nature introduces a number of limitations in the context of a contemporary model management environment. In OCL, structural constraints are captured in the form of invariants. Each invariant is dened in the context of a metaclass of the metamodel and species a name and a body. The body is an OCL expression that must evaluate to a Boolean result, indicating whether an instance of the meta-class satises the invariant or not. Execution-wise, the body of each invariant is evaluated for each instance of the meta-class and the results are stored in a set of <Element, Invariant, Boolean> triplets. Each triplet captures the Boolean result of the evaluation of an Invariant on a qualied Element [135]. 2. Sirius Validation Mechanism: Sirius allows to dene custom validation rules, which will only be applied while the user creates the model in the graphical modeler. To dene validation rules the developer rst create a Validation element inside the diagram, and then add one or more Semantic Validation Rule or View Validation Rule. Both kinds of rules are similar, but semantic rules check the structure of the underlying semantic model, which view validation rules can check the structure of the representation itself. When a rule is violated, a marker will appear on the diagram on the problematic elements and in the Problems view [156].

Figure 6 - 2 :

 62 Figure 6-2: Structure of the framework with appropriate plugins

Figure 7 - 1 :

 71 Figure 7-1: Illustration of features discussed in the respective case studies

Figure 7 - 2 :

 72 Figure 7-2: Requirement model using KAOS notation

Figure 7 -

 7 3b shows the solution space model in SSML language for a functionality from perception domain and navigation domain. The Figure 7-3a models the design space for a point cloud segmentation function (subgoal of requirement G1.1.1). The model formally species four dierent solution paths in which point clouds can be segmented. We have already discussed this model in Chapter 4. Similarly, Figure 7-3b shows a model for obstacle avoidance functionality from the navigation domain. This is the real advantage that the domain model can be reused, instead of reusing just software code libraries. It is to be noted that the solution model only comply with the functional constraints and the non-functional properties are specied as such in the model. In other words, the NFPs specied in the requirement model are not imposed on the SSML model. The NFP constraints are imposed only in the next phase, i.e. architecture modeling. The strategy is to (a) Point cloud segmentation domain model (b) Obstacle avoidance domain model

Figure 7 - 3 :

 73 Figure 7-3: A excerpt form solution space model of perception and navigation domains

Figure 7 - 4 :

 74 Figure 7-4: Ecore metamodel of subsumption architecture

Figure 7 - 5 :

 75 Figure 7-5: Architecture Model in AMAL formalism

Figure 7 - 6 :

 76 Figure 7-6: Ecore metamodel of HBBA architecture

7. 3 . 3

 33 DiscussionThe operational model for our mobile robot use case in subsumption and HBBA architecture are shown in Figure7-7. These are the nal executable model after human-assisted transformation from solution space model. During this transformation process, the decision is made, which is specic with respect to the target architec-(a) Operational Model in Subsumption Architecture (b) Operational Model in HBBA Architecture

Figure 7 - 7 :

 77 Figure 7-7: Architecture for the case study

Figure 7 -

 7 Figure 7-8 illustrates the CPU usage for subsumption and HBBA architectures.

Figure 7 - 8 : 1 .

 781 Figure 7-8: CPU usage for Subsumption and HBBA architecture

Figure 7 - 9 :

 79 Figure 7-9: Architecture modeled in the proposed framework

Figure 7 - 10 :

 710 Figure 7-10: Framework model of driver assistance system using AMAL formalism. Various domains and their relationships are shown.

Figure 7 -

 7 Figure 7-10 illustrates various domains and their relationships involved in the architecture modeled in AMAL formalism. Domain models are specied using metamodels. The various domains and their formal models in the proposed framework are described in the following sections.

Figure 7 - 11 :

 711 Figure 7-11: Ecore diagram of ACT-R metamodel

Figure 7 -

 7 Figure 7-11 shows the structure of the ACT-R 6.0 framework as an Ecore diagram.

Figure 7 - 12 :Figure 7 - 13 :Figure 7 - 13 .

 712713713 Figure 7-12: Ecore diagram of Harel statechart

Figure 7 -

 7 Figure 7-14: A reference model for service oriented architecture

Figure 7 -

 7 Figure 7-14 shows an abstract architecture of a service oriented system. The reference architecture is used here only as a way to explain the concepts hiding all the technology and platform specic details. The architecture is comprised of a number of low level services that provide support for service discovery, QoS negotiation, supervisors, etc.

Figure 7 -

 7 Figure 7-15 shows the metamodel of service oriented architecture.

Figure 7 - 15 :

 715 Figure 7-15: Ecore diagram of service oriented architecture domain model

Figure 7 -

 7 [START_REF] France | Model-driven Development of Complex Software: A Research Roadmap[END_REF] shows the metamodel of communication pattern domain used in our case study.

Figure 7 - 16 :

 716 Figure 7-16: Ecore diagram of communication domain model

Figure 7 - 17 :

 717 Figure 7-17: Control component in AMAL formalism

Figure 7 -

 7 Figure 7-17 shows the specication of control component in AMAL formalism. It shows four properties corresponding to four dierent domains -Graphics, ACT-R, Non-functional property, and service oriented architecture. The domain models and their relations were discussed in the previous sections. The graphics property is used for visualization by the modeling tool, for example, control component will be shown as circular nodes while modeling graphically in statecharts domain. The property name, for instance ACT-R determines the domain in which the properties are valid.

Figure 7 -

 7 Figure 7-18 shows the production system of ACT-R driver model proposed for lane changing behavior in statechart formalism. Notice the control component is visualized as circular node in this domain. This is due to the Graphics property dened for that domain. The state represents the goal and the transitions that originate from the state represents the production rules for that goal. REQUIRES ACTR ; import control_skill , monitor_skill , decision_skill , memory_skill NFP : performance ; NFP_ATTRIBUTES : cs : control_skill : derived , ms : monitor_skill : derived , ds : decision_skill : derived , memory_skill : derived ; NFP_POLICY : eh .cs > thr_cs & eh .ms > thr_ms & eh .ds > thr_ds ;-------------------------------------------NFP : control_skill ; NFP_ATTRIBUTES : prep_time : static :ms , exec_time : static :ms , kfar_lateral : dynamic , knear_lateral : dynamic , ki_lateral : dynamic , kfar_speed : dynamic , knear_speed : dynamic , ki_speed : dynamic ; NFP_POLICY : contrl_policy () ; -------------------------------------------NFP : monitor_skill ; NFP_ATTRIBUTES : prob_monitor : dynamic , NFP_POLICY : monitor_policy () ; -------------------------------------------NFP : decision_skill ; NFP_ATTRIBUTES : safe_distance : dynamic :m , NFP_POLICY : decision_policy () ;

Figure 7 - 18 :

 718 Figure 7-18: Production system in ACT-R driver model for lane changing behavior using statechart formalism

Figure A- 1 : 2 .

 12 Figure A-1: Overview of the EMF tool set

3 . 4 .

 34 EReference is used to represent one end of an association between classes. It has a name, a boolean ag to indicate if it represents containment, and a reference (target) type, which is another class. EDataType is used to represent the type of an attribute. A data type can be a primitive type like int or oat or an object type. Basic templates and support code is generated from the Ecore model using the transformation engine provide by the EMF as illustrated in Figure A-1. Ecore and its XMI serialization, is the center of the EMF world. An Ecore model can be created from any of at least three sources: a UML model, an XML Schema, or annotated Java interfaces. Java implementation code and, optionally, other forms of the model can be generated from an Ecore model.

  on the required visual representations, Sirius supports three dierent dialects (kinds of representations): diagrams (graphical modelers), tables, and trees (hierarchical representations), but new dialects can be added through programming[156]. Sirius provides possibility of analysis, roles and concerns of same data using dierent viewpoint on the same domain model. Sirius provides tools to specify the viewpoints which are relevant for user business domain which are usually specied as a EMF metamodel. Due to Sirius uses domain specication, which is not strictly in the scope of Sirius, it provides a graphical modeler for creating a DSM, which denes concepts and their relations in the abstract. After dening DSM models, Sirius allows easily creation of specic concrete representations of these models, and representations can be presented in more than one diagrams, tables, matrices (cross-tables) or hierarchies (trees)[157].

Figure A- 2 :

 2 Figure A-2: Graphical Workbench Specication using Sirius

Figure A- 3 :

 3 Figure A-3: Basic concept behind Model Transformation

Figure A- 5 show a snippetFigure A- 4 :

 54 Figure A-4: Metamodel for ROS Middleware

Figure A- 5 :

 5 Figure A-5: Code Snippet showing a M2M ETL template for transforming a AMAL compliant model to ROS Middleware-based model

Figure A- 6 :

 6 Figure A-6: Code Snippet showing a M2T EGL template for generating C++ code from a ROS + Boost Statecharts model

Table 1 .

 1

	Feature	RobotML[19] SmartSoft [15] BCM [18] V3CMM [20]
	SoC
	Composability
	Compositionality
	Static Variability
	Dynamic Variability
	Component Abstraction
	Technology Neutrality
	Knowledge Model
	System Reasoning
	Run-time Models
	NFP Model

6. Execute Model to Model (M2M) transformation to generate UML models and M2T transformation to generate the executable code. 1: Feature Comparison of MDSE Approaches in Robotics

  In our NFP metamodel terminology, the attributes that determine NFPs are called QoS attributes. Each NFP has at least one QoS prole associated with it. A QoS prole consists of a set of QoS attributes and a QoS policy that denes how the attributes aect the quality of NFP.

). QoS is a high level property for comparing a functionality in dierent contexts (e.g., QoS of a specic object classication algorithm is better in indoors as compared to outdoor environments). Policies associated with NFP and QoS determine how these properties are estimated from its constituent attributes. Policies are functions that act on a set of attributes, and dene how these properties are estimated. Policies can be dened using logic systems, such as a rst order logic, predicate logic, etc

[START_REF] Rosa | Process(NFL): a language for describing non-functional properties[END_REF]

. In a nutshell, NFP_Policy(NFP attributes) denes NFP, QoS_Policy(NFPs, Context) denes QoS of a functionality. However, there is no strict rule to identify whether a property is NFP or QoS. In our work, we use a rule of thumb that a functionality (or system) can have multiple NFPs (e.g., performance, eciency), but can have only a single QoS property (e.g., QoS_Policy(performance, efficiency, context) denes QoS).

Based on the assumptions made in Section 3.2, a metamodel is proposed for specifying the NFP as shown in Figure

3

-2. NFP and QoS are the root entities in this metamodel. NFP has at least one NFP Policy and a set of NFP Attributes. Similarly, QoS has at least one QoS Policy and a set of NFPs as its attributes. NFP attributes

  -8 shows the translation of SSML gates to MDP graphs.The grey states are decision points where multiple edges can be connected. The decision states do not have an associated NFP properties, hence they are also called as non-impact states. The NFP property associated with the connectors in solution space are augmented with the corresponding states in the MDP model. As shown in Figure4-8, splitter gate is transformed into two decision states and one impact state that represents the connector connected to the input port of the gate. Three edges that originate from the second decision state has an associated probability that should sum to 1. The MDP model corresponding to Merger gate consists of two decision states and one impact state. In this model, the impact state represent two functional computations connected to the input ports of the gate. This means that

both functionalities are active in this state and the NFP property associated with this state is estimated by composing the properties of the two functionalities. The MDP model of the selector gate is composed of the same number of impact states corresponding to the number of ports in the gate. In the MDP model of delay gate, an additional impact state D 1 is added that has a time-based NFP property. Similarly for the synchronizer gate, the additional state Z 1 models the time delay caused by the data synchronization.

  The identifying name or phrase of the view governed by this viewpoint. Examples: This section provides examples for the framework developer. Notes: Any additional information that users of this viewpoint might need or

	nd helpful.
	Sources: Identify the sources for this viewpoint, if any, including author, his-
	tory, literature reference, etc.

  IMAM AL is a relation that associates model elements from implementation model IM to AMAL model elements.

• R DM AM AL is a relation that associates model elements from DM to AMAL model elements.

• R

  This requirement is specied using NFP language as shown in Listing 7.1 and is attached to the G1.2 goal in the requirement model. The model species a valid property to goal G1.2, and the NFP_POLICY species how it is evaluated based on the NFP_ATTRIBUTES -pose of the goal and robot.

	2) only if goal
	position in map is explored and the condence in the pose of the robot with respect
	to the map is above a threshold level.
	import goal , robot ;
	NFP : ( G1 .2) . valid ;
	NFP_ATTRIBUTES : goal . pose , robot . pose ;
	NFP_POLICY : map ( goal . pose ). is_explored () AND robot . pose . isConfident () ;
	Listing 7.1: NFP model for goal -G1.2 in requirement model

  OCL constraints on the size of Retrieval Buer and activation level of merged chunks are shown in Listing 7.2. The rst constraint states an invariant that the buer can hold a maximum of MAX_RB number of elements at any time. The second formalism states that when two chunks are merged, the activation level of the resulting chunk is the sum of the activation of the added chunks.It consists of three model elements: states, transitions, and connectors. A virtual element name node is used to simplify the concepts. State can be composite or atomic, depending on whether it has leaf nodes or not. An active node consists of exactly one leaf node that must be active. The Boolean function guard determines whether a transition can occur and eect function is executed when transition occurs. The eect function can represent computation and, hence consumes time. The functions associated with states are executed during the in-state do activity. The action entry and exit are executed upon entering and leaving the state.

	context : Retrieval_Buffer
	inv : self . size >= MAX_RB
	context : merge ( chunk_source : Chunk , chunk_target : Chunk )
	def : chunk_target . activation += chunk_source . activation
	Listing 7.2: OCL constraints on buer size and activation level of merged chunks
	7.4.3 Harel Statecharts
	The Harel statechart [118] is a formalism of state machines and state diagrams for the
	specication and design of complex discrete-event systems, that include the notion of
	hierarchy, concurrency, and communication.
	Harel Statecharts Metamodel
	Figure 7-12 shows an Ecore model of minimalist variation of Harel statecharts, rFSM
	proposed by [70], for dening execution and interaction semantics of robotic tasks.

Table 7

 7

	.1b shows the mapping between PM model elements to
	model elements in structural view. Since the PM is modeled by SSML language,
	the mapped is between abstract elements of SSML with that of AMAL. In SSML,

the connector represents the computation process, Dispatch_Gate represent the interconnection between computations, Ports represent abstract data types and NFP represents the non-functional property of the algorithm. The relation table maps

Table 7 .

 7

2: An example for estimation of quality parameters while composing multiple domains

  8.2 Future Directions 8.2.1 Search-Based Software Engineering Search-Based Software Engineering (SBSE) reformulates software engineering as a

In robotics, Simultaneous Localization and Mapping (SLAM) is the computational problem of constructing or updating a map of an unknown environment while simultaneously keeping track of an agent's location within it[START_REF] Bailey | Simultaneous localization and mapping (SLAM): Part II[END_REF].

Acknowledgments

Foremost, I would like to express my sincere gratitude to my supervisors Prof. Bruno Monsuez and Prof. Adriana Tapus for their continuous support during my research, for their patience, motivation, enthusiasm, and immense knowledge. Their invaluable help with constructive comments and suggestions throughout my research and thesis writing have contributed to the success of this work. I could not have imagined having better advisers and mentors for my study. I would also like to thank Prof. Adriana Tapus for motivating and inspiring me to organize workshops that helped me become established as part of the research community. The workshops at 'IEEE Systems Man and Cybernetics Conference (SMC 2014)' and 'Robotics: Science and Systems (RSS 2015)' would not have happened without her encouragement and support. I gratefully acknowledge the funding received towards my research from the Vedecom Institute. I am truly indebted to Dr. Ibanez-Guzman Javier who has been always played a key role in encouraging and mentoring me. I am fortunate to continue my work with him. I would also like to thank Mr. Karthi Balasubramanian, Assistant Professor, Amrita University for nurturing my interest in robotics during my undergraduate studies.

I also convey my deepest gratitude to my parents for their whole hearted cooperation.

Most importantly, I wish to thank my loving and supportive wife, Sreelakshmi for providing me with unfailing support, prayers, and continuous encouragement. I also extend my sincere gratitude to all persons who were in one way or other involved directly or indirectly with the project. Above all I am always thankful to God almighty for giving me good health and mental attitude for completing the thesis.

III IV

Abbreviations

framework. These templates are designed in such a way as to claim the conformance with the provisions of the International Standard ISO/IEC/IEEE 42010:2011(E).

Framework Template

Framework name: The name of the framework or phrase for identication. Viewpoint overview: An abstract or brief overview of the framework and its key features.

AMAL Formalism: The denition of the framework in AMAL formalism, which is detailed in Section 5. 3.6 System stakeholders: A listing of system stakeholders expected to be users of this framework Concerns: A listing of the architecture-related concerns that are required for this framework.

Viewpoints: A listing of viewpoints available for the users. Examples: This section provides examples for the framework developer. Notes: Any additional information that users of this views might need or nd helpful.

Sources: Identify the sources for this views, if any, including author, history, literature reference, etc.

Viewpoint Template

Viewpoint name: The name of the viewpoint or phrase for identication. Viewpoint overview: An abstract or brief overview of the viewpoint and its key features.

Concerns: A listing of architecture related concerns framed by this viewpoint. This is a critical information as it decides whether the viewpoint is valid or not at the current abstraction level. At the tool level, when the user selects a model element, the current list of valid viewpoints are visible to the user. This usually takes the form of preconditions in viewpoint designing tool. In our framework Acceleo Query Language (AQL) is used for dening the precondition. AQL is View Template View name: The name of the viewpoint or phrase for identication. View overview: An abstract or brief overview of the viewpoint and its key features.

Model Kinds: Each model kind specied by this view is identied in this section.

For each model kind used, describe the convention to structure the properties associated with AMAL core elements. Key modeling resources that the view makes available including how the model elements are visually rendered by the view and determine the vocabularies for constructing the view. These includes the tools for operations such model creation, deletion, making connections, editing properties, etc.

For example, for specifying the source and target of a connector are specifying as below in AQL: For better understanding, model kinds can also be presenting in the form of metamodels specifying the structure and vocabulary.

A model kind may be documented in a number of ways such as:

1. by specifying a metamodel that denes its core elements and their relationships.

2. by providing a pseudo code that conforms to AMAL metamodel by specifying the associated properties.

3. via a language denition or by reference to existing modeling language.

Component-Port-Connector view specication

View name: Component-Connector view View overview: The structure of the system is modeled as nodes and their interconnections using edges.

Model Kinds: Node Graph Operation on views:

• Creation methods: The tools for creating models shall be provided in tools palette. The model element creation of nodes and connectors will be provided. The model deletion operation shall be implemented as key bindings.

• Design methods: The view shall allow the creation of sub nodes and hence the tool shall disable the capability to create composite nodes.

State transition view specication

View name: State-transition view View overview: The behavior of the system is modeled using state machine formalism.

Model Kinds: State Machine Operation on views:

• Creation methods: The tools for creating models shall be provided in tools palette. The model element creation of states and transitions will be provided. The model deletion operation shall be implemented as key bindings.

Interchange (XMI), EMF provides tools and runtime support to produce a set of Java classes for the model, along with a set of adapter classes that enable viewing and command-based editing of the model, and a basic editor [START_REF] Budinsky | Eclipse modeling framework: a developer's guide[END_REF]. Associated with EMF, there is an ecosystem of plugins that assist the developer during dierent phases of model based tool development as illustrated in Figure 6-1. A brief overview on the selected tools is given below. Detailed discussion on each tool is provided in Appendix A for reference.

Ecore Tools for Metamodeling

Ecore Tools plugin provides a complete environment to create, edit, and maintain Ecore models. This component facilitates handling of Ecore models with a Graphical Ecore Editor and bridges to other existing Ecore tools. It is a powerful tool for designing Model-Driven Architecture (MDA), which can be used as a starting point for software development. Typically, the process is to dene the objects (of type EClass) in the domain of application, their attributes, and their relationships. In addition, specic operations that belong to these objects are also dened using the EOperation model element. By default, EMF will generate skeletons, or method signatures which can modied according to our use.

Sirius for designing graphical workbench

Sirius allows to create custom graphical modeling workbenches by leveraging the Eclipse Modeling technologies, including EMF and Graphical Modeling Framework (GMF) [START_REF]Eclipse and Graphical Modeling Framework[END_REF] [START_REF] Vijovi | Sirius: A rapid development of dsm graphical editor[END_REF]. The modeling workbench created is composed of a set of Eclipse editors (diagrams, tables and trees) which allow the users to create, edit and visualize EMF models. All graphical characteristics and behaviors can be congured with a minimum technical knowledge. This description is dynamically interpreted to materialize the workbench within the Eclipse. Since no code generation is involved, the specier of the workbench can have instant feedback while adapting the description.

Once completed, the modeling workbench can be deployed as a standard Eclipse plugin. In our reference implementation, Sirius is used for developing graphical user interfaces and viewpoint development.

Epsilon for Model transformation and Code Generation

Epsilon provides consistent and interoperable languages for common model-driven engineering activities such as code generation, model validation and model transfor-

AMAL formalism

The Subsumption-based architecture of our mobile robot use case requires knowledge from three conceptual domains and two implementation domains. The conceptual domains are Perception, Navigation, and Subsumption-based control, and implementation domains are ROS middleware and Gazebo simulator. The framework of our mobile robot architecture in AMAL formalism is dened as:

where, M M RA is the system architecture model that performs the tasks mentioned in the requirement model; P M, N M are the solution space model pertaining to perception and navigation domains; SBT is the architecture model of subsumption architecture; RM, GM are domain models of ROS and Gazebo; and their relationship among these models and with AMAL model are also included in the specication. SBT , denes that a module in subsumption architecture is a com- ponent in AMAL model; and the relationship R RM AM AL denes that a component in AMAL is a node in ROS middleware. Therefore, in a system point of view, the module in subsumption architecture is mapped to the ros node. The transformation process from solution space model to the architecture model using these relationship specication. However, they cannot be completely automated, and it is a human-assisted process since there are architecture specic decisions to be taken. For example, in this case the information related to the layer at which the behavior belongs is not available in the SSML model and the designer has to manually include it in the transformation process.

Hierarchical Behavior-Based Architecture

The Hybrid Behavior-Based Architecture (HBBA) is a robot control framework that was originally developed for the IRL-1 humanoid robot [START_REF] Ferland | Natural interaction design of a humanoid robot[END_REF]. HBBA combines two robot control paradigms: behavior-based control (Think the way you act), and Hybrid control (Think and act concurrently) [START_REF] Matari¢ | Behavior-based systems[END_REF]. HBBA unies both paradigms by adding layers on top of a behavior-producing modules (referred to as Behaviors), al- 7.1c species that these two con- cepts are semantically compatible since Dispatch_Gate and communication pattern represent the interaction between computations in their respective domains. In the similar fashion, the relationships between model elements between the domain models are shown in Table 7.1.

Discussion

In this section, we highlight dierent aspects on our multi-domain architecture formalism for control component in Human driver model. To provide a theoretical basis for our discussions, a brief overview of the driver model is discussed below. More detailed description can be found in [START_REF] Salvucci | Modeling driver behavior in a cognitive architecture[END_REF].

Human

Non-Functional Property Composition

The NFP specication provides a structure using a formal language and helps to manage those properties using the associated tools. The NFP models are utilized in the three spaces -problem, solution, and operation spaces; and are used to make developmental time decisions and runtime QoS resolution. The NFP policies that are dened by the user are used to compose and compare these properties. Compositions of NFPs are based on dierent composition theories, and, in addition, they are often not only the result of compositions of component properties, but also depend on other elements of a particular system architecture or even its environment. For example, determining the composition of component performance may depend on the scheduling policies and the system architecture. According to [START_REF] Crnkovic | Concerning predictability in dependable component-based systems: Classication of quality attributes[END_REF], NFPs can be classied in categories depending on the composition domains (i.e. type of parameters that determine the composition). However, due to the highly heterogeneous nature of these properties, there is no formally dened method to compose the components and estimate the emergent properties [START_REF] Crnkovic | A classication framework for software component models[END_REF]. However, more research is required in this direction.

Runtime Models

The resolution of solution space might not always result in a static operational model.

Typically the resolution process performed during development time result in a subset of solutions that are modeled as variation points in the architecture. This is attributed mainly due to certain context-based properties that can be estimated only during runtime. In these situations, the runtime models should reect the most up-to-date information in order to perform online analysis and reasoning. In this direction, reference architectures are available from self-adaptive systems and models@runtime research [START_REF] Bencomo | Models@run.time, Foundations, Applications, and Roadmaps[END_REF]. A detailed discussion on addressing uncertainty in models can be found in [START_REF] Giese | Living with Uncertainty in the Age of Runtime Models[END_REF]. A proposal for adapting the Eclipse Modelling Framework (EMF), for a more dynamic usage of models in the context of Models@Runtime is already made by the authors of [START_REF] Fouquet | An Eclipse modelling framework alternative to meet the models@runtime requirements[END_REF]. Innovative approaches in reasoning on the presence of uncertainty and its inuence during runtime needs to be studied.

Appendix A Eclipse Modeling Framework and Supporting Plugins

A.

Eclipse Modeling Framework

Eclipse is an open source software project dedicated to providing a robust, fullfeatured and commercial-quality platform for developing and supporting highly integrated software engineering tools [START_REF] Merks | The Eclipse Modeling Framework[END_REF]. The Eclipse platform denes a set of frameworks and common services that collectively make up the "integrationware" required to support a comprehensive tool integration platform. Except the small Eclipse runtime kernel, all the platform components are plug-in tools integrated seamlessly through predened extension points [START_REF] Yang | Using Eclipse as a tool-integration platform for software development[END_REF]. Fundamentally, Eclipse is a framework for plug-ins. Besides its runtime kernel, the platform consists of the workbench, workspace, help, and team components. Other tools plug into this basic framework to create a usable application. Plug-ins can also dene new extension points for others to extend. For example, a group of plug-ins implements the workbench user interface.

A.1.1 Metamodeling using Ecore

According to the Eclipse Foundation, the core EMF framework includes a metamodel (Ecore) for describing models and run-time support for the models, including change notication, persistence support with default XMI serialization, and a reective API for manipulating EMF objects generically. In other words, Ecore denes the structure representations (dialects) available: diagrams, tables, matrices and trees.

-mapping strongly depends of dialect and identies a sub-set of the semantic model element that should appear in a representation and indicates how they should be represented.

-style is used to congure the visual appearance of the elements -tool describes behaviors mapping.

Sirius works with models which describe semantics of editors -structure, appearance and behavior of dedicated representations and associated tools. For creation of editor, no Java code is necessary. A main disadvantage is need for interpreted expressions which will be evaluated at runtime to provide a behavior specic to domain and

representations. An expression can be written in Acceleo [177], OCL [START_REF]Object Constraint Language, Object Management Group Std[END_REF] or Java language.

Property sheet views are widely used in our framework for editing the component

Exented Editing Framework

Extended Editing Framework (EEF) provides advanced editing components for the properties of EMF elements and a default generation based on standard metamodels.

Most of the concepts of the language can be congured using expressions based on various interpreters. By using EEF along with Sirius, all the interpreters can be leveraged and makes it available in Sirius and it is possible to use it out of Eclipse Sirius, with our own interpreter. By using EEF with AQL, we can navigate very However, no significant systematic software development process is followed in robotics research.

The process of developing robotic software frameworks and tools for designing robotic architectures is expensive both in terms of time and effort, and absence of systematic approach may result in ad hoc designs that are not flexible and reusable. Making architecture meta-framework a point of conformance opens new possibilities for interoperability and knowledge sharing in the architecture and framework communities. We tried to make a step in this direction by proposing a common model and by providing a systematic methodological approach that helps in specifying different aspects of software architecture development and their interplay in a framework.