A Decentralised Software Process Approach For Real time Navigation of Service Robots

Convergence of Communication, Computing and Control is considered by many as the future of Information Technology. In the same breadth, the recent advances in Key Technology such as Telematics, M2M, Smart Wireless Communication Devices (SWCD) and Sensor Networks (WSN) from Telecommunications’ domain; Artificial Intelligence (AI), Sensor Fusion , Behavior Fusion and Hybrid algorithms (ANFIS, GA) from the Robotics Domain; Open Source Systems (OSS), Geographical Information Systems ( GIS), Service Oriented Architecture (SOA) and Session Initiated Protocol (SIP) from the Information Technology Domains necessitates a paradigm shift in approaches to building applications for future Robots. Early single function robotic systems were designed as control systems with a clear feedback model. A Sensor generates feedback, and any deviation from the expected feedback generated by the Sensors updates a control signal to minimize the error over time. As complexity of modern day Service Robots grew and the robots needed to perform multiple functions, the perception-action loop was extended linearly to include a planning component resulting in the sense-plan-act paradigm. Obviously it does not perform very well in dynamic and unpredictable environments: the sensors and real world models are usually inadequate as the actions are not always a direct consequence of perception. The hybrid deliberate/reactive approach has proven very successful, practical and robust in a large number of implementations, and it appears that there is general agreement among the research community that this is the best type of architecture for Service Robots. However, some types of modules are hard to force into any particular layer. In a general framework, it is imperative that no special architecture is preferred for enforcement and a good support for builders of the hybrid deliberate/reactive architecture is important so that the framework supports parallel execution of behaviours. This is precisely where the proposed architecture scores above the other architectures. The major problems for robotics today lie, not in the hardware but on the software side. There are plenty of well functioning and robust algorithms developed by competent researchers readily available. Each new implementation would provide significant gains in the performance and capabilities, but it will be lost due to non portability and reuse issues. 14


X A Decentralised Software Process Approach
For Real time Navigation of Service Robots

Introduction
Convergence of Communication, Computing and Control is considered by many as the future of Information Technology. In the same breadth, the recent advances in Key Technology such as Telematics, M2M, Smart Wireless Communication Devices (SWCD) and Sensor Networks (WSN) from Telecommunications' domain; Artificial Intelligence (AI), Sensor Fusion , Behavior Fusion and Hybrid algorithms (ANFIS, GA) from the Robotics Domain; Open Source Systems (OSS), Geographical Information Systems ( GIS), Service Oriented Architecture (SOA) and Session Initiated Protocol (SIP) from the Information Technology Domains necessitates a paradigm shift in approaches to building applications for future Robots. Early single function robotic systems were designed as control systems with a clear feedback model. A Sensor generates feedback, and any deviation from the expected feedback generated by the Sensors updates a control signal to minimize the error over time. As complexity of modern day Service Robots grew and the robots needed to perform multiple functions, the perception-action loop was extended linearly to include a planning component resulting in the sense-plan-act paradigm. Obviously it does not perform very well in dynamic and unpredictable environments: the sensors and real world models are usually inadequate as the actions are not always a direct consequence of perception. The hybrid deliberate/reactive approach has proven very successful, practical and robust in a large number of implementations, and it appears that there is general agreement among the research community that this is the best type of architecture for Service Robots. However, some types of modules are hard to force into any particular layer. In a general framework, it is imperative that no special architecture is preferred for enforcement and a good support for builders of the hybrid deliberate/reactive architecture is important so that the framework supports parallel execution of behaviours. This is precisely where the proposed architecture scores above the other architectures. The major problems for robotics today lie, not in the hardware but on the software side.
There are plenty of well functioning and robust algorithms developed by competent researchers readily available. Each new implementation would provide significant gains in the performance and capabilities, but it will be lost due to non portability and reuse issues.
While the lowest layer or reactive layer has to be embedded on the robot controller due to the obvious fact that this layer requires the highest response and lowest CPU time, in our approach the Middleware layer helps us to switch based on deliberative approaches from the repository of allowable robot behaviours. What was essentially an traditionally AI Rule Based Behaviour Switching now graduates to a Location Based Behaviour Switching based on a host of Soft computing techniques . Most of the commercial Service Robotics industries even today, employ at best the "earlier" or traditional approaches to software reuse, which are built on the paradigm of a set of libraries containing many small building blocks. Some of the more advanced establishments use object-oriented frameworks resulting in a generic design that can be instantiated for each object system constructed. While the Object oriented framework ideally captures the elements common to a family of related systems, it is essentially a large design pattern capturing bulk of the system functionality in one specific kind of object system, which is maintained as a single entity. Each software system using framework is only an instantiation of that framework. Traditionally, control of generalised Service Robots required welldefined activities tightly coupled across different hierarchies on single platform i.e. monolithic control architecture. In a distributed system or multiprocessor, Middleware allocates system resources, giving requests to the operating systems on the individual processors to implement those decisions. One of the key differences between Middleware and Software Libraries are that Middleware manages resources dynamically. In a uniprocessor, the operating system manages the resources on the processor (for example, the CPU itself, the devices, etc.) and Software Libraries perform computational tasks based on those allocations. By Process we mean a system element that is independent, and can be freely deployed and versioned. This approach loosely couples the various layers into process components that are well defined entities that can be replaced or made redundant without affecting the rest of the systems. It is shown here how they can be developed and tested separately and integrated later building on the Middleware Framework to provide a systematic approach to developing software that would be easy to integrate, manage, and reuse The field of robotics relies heavily on various technologies such as Mechatronics, computing systems, and wireless communication. Given the fast growing technological progress in these fields, robots can cater to a wide range of applications. However real world integration and application development for such a distributed system composed of many robotic modules and networked robotic devices is very difficult. Therefore, Middleware services provide a novel approach offering many possibilities and drastically enhancing the application development for robots. (Mohamed, Al-Jaroodi et al. 2008) Middleware is prevalent in IT-oriented server systems than in Embedded Systems. Several Embedded Middleware Systems have been developed based on IT standards but with heavy footprints. Middleware architectures are slowly and steadily evolving to support embedded operations. A Telematics device Middleware and the GPRS link enable configuring and reconfiguring the devices as many times as required and this is effectively used to change the control program and actions remotely to use the robot for different services without having to make any major changes to the design, hardware or software. This paper discusses our domain, existing architectures, component and processes execution techniques and the approach we took to integrate these to form a distributed decentralised web enabled service that is robust and safe-fail. The resulting architecture is simple, and can www.intechopen.com support a wide range of trade-offs that can be manipulated easily at run-time based on control of processes rather than control of discrete actions. The current approach is a loosely coupled integration of different process technologies and computational mechanisms.

The Service Robot Domain
The Services area is just emerging as the future of field application and Services computing has been recognized as a new foundational discipline of the modern services industry (Zhang 2008). Even though the number of Service Robots currently in operation is small, the number of people working in the service field shows a constant growth rate. Consequently, there is an enormous potential for the expansion of this sector. Due to often strict requirements with respect to safety (personal and functional) associated with robot autonomy and navigation in partially or entirely unknown environments (coupled with the convergence issues) the use of robots for carrying out service tasks has been very limited. Only a fraction of existing services which incorporate handling, transportation and working can be automated. A successful design of future Service Robots will be based upon detailed knowledge of available technologies and methodologies to design handling devices or mobile platforms, peripheral devices, and organizational schemes which account for a flexible, fault-tolerant and user friendly human-machine interaction. (Schraft 1994)  Such a Design philosophy calls for architecture that must also provide a structure that improves the coherence and modularity of the system, while supporting large scale robotic system development which include considerations of real-time response and a layered www.intechopen.com decomposition of the system to distinguish the granularity of the modules responsibilities. Service Robots must have highly competent reactive mechanisms to be safe, flexible and easy to use. At the same time, planning and sequencing are useful to reduce the repetition and taxation on the user for direction. (Kawamura, Pack et al. 1995). The uncertainties from the environment, the complexities of software/hardware interactions, and the variability of the robotic hardware make the task of developing robotic software complex, hard, and costly. Hence, it has become increasingly important to leverage robotic developments across projects and platforms. (Nesnas, Wright et al. 2003) In spite of an explosion of technology and methods, the Service Robots are still not complex and in their early stages of development. Many researchers specialize in one or more areas/topics, which usually involve development of algorithms. However, in order to test the competence on a real robot, a complete system is needed involving a process based approach. Many of these are required to run in parallel and need to communicate both synchronously and asynchronously. It has to also accommodate changing application requirements, incorporate new technology, interoperate in heterogeneous environments, and maintain viability in changing environments. This puts a tremendous burden on the developer if he or she has to build everything from scratch and hence a delay in "Market ready" products. Hence, it has become increasingly important to develop Service Robots on General Platforms and Frameworks. (Ragavan and Ganapathy 2007). We present a Novel Decentralised Architecture for Navigation and Control of Service Robots based on control of processes rather than control of discrete actions. The current approach is a loosely coupled integration of different process technologies and computational mechanisms. It is our firm contention that a well designed software architectural framework is necessary to effectively leverage microcontrollers (Read Service Robots), wireless networks (read Telematics, distributed wireless networks) and process orchestration (read service) to address problems of complexity, scale and reliability of networked Service Robots

a. Layered Architecture and Hybrid approaches
Early robotic systems for single functions were designed as control systems with a clear feedback model. A Sensor generates feedback, which is compared to the expected feedback derived from a model of the system. Any deviation is used to update the control signal so as to minimize the error over time. As complexity grew and the robots needed to perform more than one function, the perception-action loop was extended to have a planning component. This was a natural linear extension beyond traditional control towards modern day Service Robots. This resulted in a hierarchical system having an elaborate model of the world, using sensors to update this model, and to draw conclusions based on the updated model. Obviously it does not perform very well in dynamic and unpredictable environments as the sensors and real world models are usually inadequate. That the actions are not a direct consequence of perception is perhaps the reason why it is also called the sense-plan-act paradigm.
Reactive approaches are often capable of autonomously exploring new regions in the environment and, as there is no fixed plan, they are generally able to respond rapidly to any changes that may occur in the operating environment. Moreover, they are more tolerant to uncertainties in sensor measurements and the errors. Robots that were running reactive behaviour based systems performed very well, also in changing environments. However, the purely reactive scheme is not capable of performing complex tasks. A software www.intechopen.com architecture based on purely reactive approach is usually monolithic and requires rewriting of control software for even small changes in the task, or environment. On the other hand deliberative navigation methods generally assume that the obstacles in the environment in which a robot moves are known in terms of their physical location and dimensions. The navigation task is then to plan a path that is both collision free and satisfies certain optimization criteria. The classical deliberative approach to navigation is based entirely on planning and on explicit symbolic models of the world exhausts the computation resources all along the way (Brooks 1991). Even more, it does not seem to operate successfully in a dynamic changing world. It has difficulties in dealing with sensors' errors as well. The models it uses are not realistic; it appears that the world is too complicated to be presented completely. Attempts to create a complete model that includes all the essential knowledge needed to deal with the uncertainties and surprises of the real world, became enormously big and the planning too expensive in time and computer resources. Hence, it has become increasingly important to leverage upon Hybrid Approaches to robotic developments across projects and platforms.

b. Hybrid Approaches
A hybrid approach, combining low-level reactive behaviours with higher level deliberation and reasoning, has since then been common among researchers (Arkin 1990;Cattoni, Di Caro et al. 1994). The hybrid systems are usually modelled as having three layers as shown in Figure 1; one deliberative, one reactive and one middle layer (Gat 1992) and this approach for a long time now remains vastly unchallenged. There is also a sound architectural rationale for having exactly three major components and not just because three is an aesthetically pleasing number. It has to do with the role of internal state and with ability to organize algorithms according to whether they contain no state, contain state reflecting memories about the past, or contain state reflecting predictions about the future. Abstractions are then used to isolate aspects of reality that can be tracked or predicted reliably, and to ignore other aspects (Erann 1998). (Gat 1992) and BERRA (Lindstrom, Oreback et al. 2000) www.intechopen.com

Fig. 2. Three Layer architectures -ATLANTIS
The Lowest Layer or control layer is mainly reactive with no decision making and the process computations at this layer use the least amount of CPU time and are tightly coupled to the Sensor-Actuator layer. The Middle level or grey layer bridges the gap between the two layers (Cattoni, Di Caro et al. 1994) and is usually either a Rule Based Layer or a Finite State Machine deciding which set of behaviours should be running. It also acts as a supervisory layer and catches failures of the reactive layer and then executes deliberative plans. The highest level of activities like planning and world modelling are done at this level and these are the areas that need significant computing resources. The advances in distributed computing techniques and communication infrastructure are leveraged in the proposed architecture to offer a decentralized control system.

Decentralised Hybrid Software approach
The hybrid deliberate/reactive approach has proven very successful, practical and robust in a large number of implementations, and it appears that there is a general agreement among the research community that this is the best type of architecture for Service Robots. However, some types of modules are hard to force into any particular layer. In a general framework, it is imperative that no special architecture is preferred for enforcement and a good support for builders of the hybrid deliberate/reactive architecture is important so that the framework supports parallel execution of behaviours. This is precisely where this proposed architecture scores above the other architectures. The major problems for robotics today lie, not in the hardware but on the software side.
There are plenty of well functioning and robust algorithms developed by competent researchers readily available (Ibrahim and Fernandes 2004). Each new implementation would provide significant gains in the performance and capabilities but it will be lost due to non portability and reuse issues. While the lowest layer or reactive layer has to be embedded on the robot controller due to the obvious fact that this layer requires the highest response and lowest CPU time, the Middleware layer helps us to switch from the repository of allowable robot behaviours. What was essentially an AI Rule Based Behaviour Switching now graduates to a Location Based Behaviour Switching in the current architecture. In contrast to the "earlier" or traditional approaches to software reuse, which are built on the paradigm of a set of libraries containing many small building blocks, object-oriented frameworks allow the highest common abstraction level between a number of similar systems to be captured in terms of general concepts and structures. The result is a generic design that can be instantiated for each object system constructed (Lewandowski 1998). The Object oriented framework (Bagchi and Kawamura 1992) , (Miller and Lennox 1990) (Chochon 1993) is ideally suited for capturing the elements common to a family of related systems. In this sense, the framework is essentially a large design pattern capturing the essence of one specific kind of object system. The bulk of the system functionality is captured in the framework, which is maintained as a single entity. Each software system using framework is an instantiation of that framework (Lewandowski 1998). Object and component frameworks can also be seen as a special breed of object-oriented systemsthey are extensible, semi-finished pieces of software. Completing the semi-finished software leads to different software pieces, typically specific applications, that share the same core.
Though frameworks have been developed for a wide range of domains, they use common construction principles (Marcus, Wolfgang et al. 2000)

Middleware approach
In a distributed system or multiprocessor, Middleware allocates system resources, giving requests to the operating systems on the individual processors to implement those decisions. One of the key differences between Middleware and Software Libraries are that Middleware manages resources dynamically. In a uniprocessor, the operating system manages the resources on the processor (for example, the CPU itself, the devices, etc.) and Software Libraries perform computational tasks based on those allocations. Real world integration and application development for such a distributed system composed of many robotic modules and networked robotic devices becomes very difficult without Middleware. Middleware is prevalent in IT-oriented server systems than in Embedded Systems. Several embedded Middleware systems have been developed based on IT standards but with heavy footprints. Middleware architectures are slowly and steadily evolving to support embedded operations (Schmidt 2002). Middleware is software infrastructure that has been used to successfully integrate and manage software for complex distributed systems . Middleware is generally constructed to provide communication between application software and processes in P2P, client-Server or Publish -Subscribe models. Most Middleware address a particular domain such as Web Services, RTOS etc and define simple and uniform architectures for developing applications in that domain. Standard mechanisms for defining software interfaces and functionalities encourage the development of well-defined and reusable software. The Middleware concepts introduced make implementing the control systems more flexible so that they can be dynamically reconfigured with ease and can be upgraded or adapted in a flexible manner. An appropriate Middleware would allow software components to be integrated easily and provide standard functionalities such as support for robustness and fault tolerance, which can be easily reused in most applications. Therefore, Middleware Services provide a novel approach offering many possibilities and drastically enhancing the application development for robots. We present a novel decentralized architecture as shown in Figure 2 for navigating and controlling a Service Robot based on control of processes rather than control of discrete actions. By Process we mean a system element that is independent, and can be freely deployed and versioned. This approach loosely couples the various layers into process components that are well defined entities that can be replaced or made redundant without affecting the rest of the systems. It is shown here how they can be developed and tested separately and integrated later building on the Middleware Framework to provide a systematic approach to developing software that would be easy to integrate, manage, and reuse. At the core of the framework lies a Smart Wireless Communication device (SWCD) operating on Middleware. The SWCD Telematics framework based design accommodates three dimensions of variability namely: • varying operating systems, • varying hardware platforms, and • varying implementation languages.

Fig. 3. SWCD based Decentralized System Architecture
Since the framework does a mapping from a constant high-level API to a set of native APIs of different operating systems and hardware platforms, only few interactions are sufficiently complex to warrant dynamic modeling. This static management of variables (as opposed to run-time dependencies) is sufficient since OS, platform, and language dependencies can all be resolved at build time. This still allows for later variability with respect to the features used in an application since the latter will only include those portions of the framework that are actually required and included in a given hardware configuration. (Marco 2003)

Implementation, Integration and Experimental Test setup
The implementation of the distributed software engineering concepts introduced in the earlier section permits our Service Robot application to be dynamically reconfigured with ease and to be upgraded or adapted in a flexible manner using the P2P, Client Server and Producer-Consumer models.
www.intechopen.com  The Robot communicates with the sensors through the event channels in the Publish -Subscribe mode through the GPIO's. The control components are software modules that perform the tasks of path planning, goal seeking, obstacle avoidance target tracking and localisation. The sensor components consist of device drivers and hardware. The sensors used here are GPS, vision systems and IMU and there exists a loose coupling through the Middleware providing an abstract communication channel referred to in the Figure 4 as Event Channel. The sensors register with the event channel as Publishers of data (e.g. camera as image data and GPS as position data) and Process components (e.g. Obstacle Avoidance and Target Tracking) are Subscribers. Subscribers get the data from whatever is available from the Publishers and new Publishers can be added at will.

Component Decomposition
The data flow diagram of the communication server is shown in the picture below. Many SWCD's can communicate to the communication server.

Fig. 6. Data Flow diagrams
The way-point and alert management processes are not shown separately in the picture as they form a part of the communications module. In addition to acting as a gateway for incoming and outgoing data communications, the communications module also acts as a monitor for alerts. Events monitored on the server side like way-points, SWCD notreporting events, Geofence alerts, etc are handled by the communications module based on the live data feeds from the SWCD and hence, this component is an always-on module. As seen in the diagram, the communications module communicates with the SWCD's using either TCP over GPRS (preferred) or it falls back to SMS (over GSM modem). In case history data needs to be read from a remote unit in the absence of a GPRS network, the module does a data call to the SWCD via the modem.

GPRS Data Acquisition Module
A heterogeneous asynchronous communication process spread over four process layers and two physical layers is at the core of this design process as shown in Figure 7. The Communication Server Module was developed based on Client/Server architecture to acquire the GPS data over a GPRS network using a TCP/IP connection. In regions of poor GSM coverage the module switches to SMS for command transfer. GPS devices running on GSM/GPRS SIM cards were configured as clients to stream positional information to a Test Communication Server which had to be located external to the university network due to Static IP/Firewall restrictions. The units streamed data directly from GPS devices to an external communication server which performed the processes of data acquisition and validation functions before passing on the data for Data Fusion.

www.intechopen.com
The remaining process of the Communication Services such as data and alert processing, command and alert service responses and configuration despatches was spread over a remote system within the university campus through the web. Therefore, data was collected externally, and the client application was used to stream the bulk data to the Server for processing.

Fig. 7. Communication Process flow
Data received at the server was validated prior to structuring based on the starting characters of the string ($GPRMC) and by checking whether the third element in the string represents character 'A', which implies the validity of the string. Once validated, each string was structured using Sensor Bridge components.  Thereafter, the useful information such as latitude, longitude, time, date and speed were extracted to be stored for further processing. The inertial measurement readings obtained through the GPIO of the GPS modules are also streamed along with the position info to provide for near real time location awareness.

Mobile Object Database and Database Management
A Mobile Object Database (MOD) system was developed using MySQL as the data repository to store the processed GPS data. MySQL is an open source database management system, noted mostly for its speed, reliability and flexibility. Furthermore, MySQL incorporates spatial extensions under the specification of the Open GIS Consortium (OGC), which is an organization that groups many other organizations that prescribe standards for GIS data processing. The Mobile Object Database for this system was developed adhering to the structure of the geometry types proposed by the OGC. Figure 8 depicts the structure of a spatial table created for a GPS device using geometry type 'POINT' to store latitude and longitude values.

Fig. 9. Filtered and structured Position Information
A database connection between the MIS process and MySQL was established using a .NET connector component provided by MySQL. Data processed and structured into series tables using Sensor Bridge components were written into separate spatial tables to manage and store Geo-fences and Route patterns that have either been acquired through reactive navigation or through route patterns marked on the GIS system as shown in Figure 9, which can be retransmitted to the Mobile robot through GPRS in order to navigate objects successively.

Transmission of Routes and Virtual Boundaries
Geo-Fences are virtual boundaries the robot is supposed to remain within to reach the goal and /or keep away to avoid dangers. Geo-Fences and the route vectors saved in the MOD are retrieved from the application to be transmitted back to the corresponding Mobile devices as shown in Figure 10. The Geo-Fences can also be created from the Maps like Google Earth and the boundary information can be sent to the Robot through the Telematic unit. PFAL (Device Middleware) commands were used to configure predefined routes and virtual boundaries in the GPS devices. For route configuration, a virtual boundary was created within a 30m radius for each waypoint in the route as required by the PFAL commands. Figure 10 depicts the configuration of a route to be transmitted to GPS devices

Over The Air (OTA) Configuration and GPIO Enabling and Disabling
The Device Middleware and the GPRS link enable configuring and reconfiguring the devices as many times as required and this is effectively used to change the control program and actions remotely to use the robot for different services without having to make any major changes to the design, hardware or software.
The feature diagram of a Smart Telematics Platform at various levels of abstraction as applied to a functional Product design is shown below. Middleware framework provides the maximum flexibility as the underlying SWCD hardware Platform is variable with respect to its assortment of components. Fig. 11. Variable assortment of components form the variable SWCD hardware Platform Sample configuration scripts sent over the air to configure, activate and connect to the device is shown below in Figure 12. The GPIO's data requests can be enabled or disabled "on the fly" through Over The Air Commands to optimise on the performance of the mobile device that is resource and energy starved. Video camera for instance which consumes huge amounts of battery power can be switched ON/OFF or at optimised rates at any time based on events or by the remote operator. Figure 13 shows the Middleware commands that are sent through GPRS or SMS to dynamically configure, enable or reconfigure the GPIO's. The approach to the design of the Middleware Framework appears to be through the mapping of elements of the SWCD platform's feature model (see fig. 11) to the classes and packages. Atomic features have generally been turned into classes and composite features into packages. Additional packages and classes have been created for elements not covered by the hardware feature model but for which abstractions needed to be provided, such as utilities for handling concurrency etc. Classes have been interrelated using refinement/ abstraction, implementation, and generic dependency relations. Relations have been defined in such a fashion that hardware/OS dependencies have been kept within as few classes as possible, reducing the effort posed by adding support for a new platform. Common base and dedicated interface classes have been used to capture commonalities among devices of a kind, such as stream-or message-based communications devices/classes.

Geographic Information System (GIS)
A GIS system is a technique that manipulates, integrates and maps geographical information based on positional coordinates. (Latitude / Longitude). Many GIS software applications have been developed and integrated to precisely plot and display positional information, such as ArcGIS, MapPoint, Google Maps etc. Companion papers (A.U. Alahakone 2007; Ragavan and Ganapathy 2007) describe the GIS systems that was developed along this work as a separate processes to remotely track the mobile object/robot on a web page embedding Google Maps APIs. Google APIs are freely available and accessible on the internet, and provide satellite maps as well as street maps. GIS systems incorporate several layers, each providing a different set of information to represent positional data. Google APIs provides the ability to embed many types of layers to enhance the quality of the data representation of the GIS system. This service as shown in Figure 14 is used to plan the path, create Geo-fence specifications and waypoint locations. Like wise options are available for the robot to be controlled and commanded over the web as a Tele-robot if need be.

Results and Discussion
In spite of a host of integration issues, software integration of the process modules was seamless. It has been established that dynamic heterogeneous systems can be evolved such as:-an embedded RTOS controller of the robot communicating through a GPRS mobile network, through a Windows based communication server that is a client/server application over TCP/IP, communicating the raw data acquired over a secure connection to be structured, processed, validated and fused at a remotely located server running on a different version of a Windows system across a Firewall, to be further stored in an Open Source Spatial MOD Database System running on MySQL, for further reporting and tracking of the robot movements in near Real-Time over a Web based GIS Tracking System continuously and accurately on a Map and send the information stored or created such as a Geofence or Route all the way back to the robot. The entire operation is completed with a round trip time of a few hundreds of milliseconds. Lastly it should be noted that our hybrid approach has considerably evolved over time based on lessons learnt in real-time and in distributed systems. As a test example the Path Planning and Navigation System for Service Robots was successfully developed and deployed. It has also been established that Middleware can be used reliably to integrate disparate systems and processes and help in smooth evolution of Complex Dynamical Systems.

Conclusion
Modules and Components have been developed for an Asynchronous, Loosely Coupled to Uncoupled, Process Based, and Safe-Fail System as discussed and reported in this paper. The processes have been successfully deployed across hybrid and heterogeneous platforms from dedicated RTOS processors on the robot to distributed and disparate server machines connected through the World Wide Web. It has also been established that Middleware can be used reliably to integrate disparate systems and processes and helps in smooth evolution of Complex Dynamical Systems. Having demonstrated how these strategies can be successfully implemented using the distributed networked software infrastructure such as Middleware, Webware and Hardware, a major challenge lies as future work in understanding how to make the most of it especially,  understanding the tradeoffs between knowledge representations that are process based reactive, deliberative or hybrid and  how to reduce the risk by managing software related failures in network controlled systems.  Secure and fast methods for OTA download.