A Robotic Wheelchair Component-Based Software Development

A robotic wheelchair system provides mobility for handicapped and elderly people who are unable to operate classical wheelchair system. Software development for such system is challenged by requirement for multi-disciplines expert knowledge which includes embedded systems, real-time software issues, control theories and artificial intelligence aspects. Software reuse is an approach to provide a way to reuse expertise that can be used across domains in software engineering. Software reuse can be a mechanism to support the attempts to transfer technology from other engineering fields to rehabilitation engineering. For example, (Bonail et al., 2009) and (Cheein et al., 2009) have attempted to transfer software platform and algorithms from robotic technologies to rehabilitation engineering software development. The technologies transfer requires a methodological support to enable a systematic software reuse of the multi-disciplines expert knowledge. Software reuse is one of the promising approaches to increase software productivity and improve its quality, as well as to decrease the costs of software development. This is because of software reuse uses existing software either in the form of component or knowledge to construct new software. Yet, applying software reuse in Embedded Real-Time (ERT) domain, such as robotic wheelchair sets major challenges to the software development process due to the resource-constrained and real-time requirements of the system. In order to overcome multi-constraints and multi-disciplinary knowledge in ERT software development problems, Component-Based Development (CBD) method becomes a promising approach for ERT software development (Bunse & Gross, 2006; Carlson et al., 2006). Existing industrial component technologies such as OMG’s CORBA Component Model (CCM), Microsoft’s (D) COM/COM++, .NET, SUN Microsystems’ JavaBeans and enterprise JavaBeans, are not suitable to develop ERT systems because they do not address the non-functional properties in ERT systems. With the purpose to meet the requirements of ERT systems, a number of component technologies such as Koala (Ommering, 2000), PECOS (Nierstrasz, et al., 2002) and KobrA (Atkinson, et al., 2002) have emerged. However, these component technologies still have some weaknesses. Koala and PECOS cannot support multi-disciplinary knowledge, but they can


Introduction
A robotic wheelchair system provides mobility for handicapped and elderly people who are unable to operate classical wheelchair system. Software development for such system is challenged by requirement for multi-disciplines expert knowledge which includes embedded systems, real-time software issues, control theories and artificial intelligence aspects. Software reuse is an approach to provide a way to reuse expertise that can be used across domains in software engineering. Software reuse can be a mechanism to support the attempts to transfer technology from other engineering fields to rehabilitation engineering. For example, (Bonail et al., 2009) and (Cheein et al., 2009) have attempted to transfer software platform and algorithms from robotic technologies to rehabilitation engineering software development. The technologies transfer requires a methodological support to enable a systematic software reuse of the multi-disciplines expert knowledge. Software reuse is one of the promising approaches to increase software productivity and improve its quality, as well as to decrease the costs of software development. This is because of software reuse uses existing software either in the form of component or knowledge to construct new software. Yet, applying software reuse in Embedded Real-Time (ERT) domain, such as robotic wheelchair sets major challenges to the software development process due to the resource-constrained and real-time requirements of the system. In order to overcome multi-constraints and multi-disciplinary knowledge in ERT software development problems, Component-Based Development (CBD) method becomes a promising approach for ERT software development (Bunse & Gross, 2006;Carlson et al., 2006). Existing industrial component technologies such as OMG's CORBA Component Model (CCM), Microsoft's (D) COM/COM++, .NET, SUN Microsystems' JavaBeans and enterprise JavaBeans, are not suitable to develop ERT systems because they do not address the non-functional properties in ERT systems. With the purpose to meet the requirements of ERT systems, a number of component technologies such as Koala (Ommering, 2000), PECOS (Nierstrasz, et al., 2002) and KobrA (Atkinson, et al., 2002) have emerged. However, these component technologies still have some weaknesses. Koala and PECOS cannot support multi-disciplinary knowledge, but they can

The robotic wheelchair system
A prototype of robotic wheelchair was developed to support our researches in ERT software engineering and rehabilitation robotics. The main considerations when developing this prototype were to have a low cost and 'open' system such that it enables different aspects of hardware and software experimentations to be performed. Due to these considerations, rather than basing the prototype on a standard power wheelchair such as the smart wheelchair system developed by Simpson et al. (2004), a commercially available manual wheelchair was used as the base for the robotic wheelchair prototype. An easily detachable add-on unit was developed to be attached to the manual wheelchair without significant modifications to the manual wheelchair. This add on unit consists of two geared direct current (DC) motors, two 12V batteries and a control box with embedded processor and associated electronics. Fig. 1 shows the prototype of robotic wheelchair which consists of a standard manual wheelchair and add on unit. The DC motors together with two small wheels provide the motorized wheels for mobility. The DC motors are powered by the 24V 14 Ampere obtained from the two 12V batteries. The voltage regulators in the control box provide 5V supplies for the sensors and the embedded processor from the two batteries. To provide the capability for sensing the environment, sets of sensors are attached to the robotic wheelchair. Infra red (IR) distance sensors are used to detect obstacles in the direction of the robotic wheelchair movement. Four IR sensors are mounted at the front and two IR sensors are mounted at the back. Sonar sensor is used to map room environment or detect far obstacles. It is mounted on the pole above the user head. Currently, the robotic wheelchair supports two ways of controlling. The first way is through the usual joystick or keypad control. The second way is through the movements of head. Head movements control is particularly useful for severely-handicapped people who have spinal cord injury or quadriplegia which cannot use their hands to control the wheelchair. In the developed prototype, the head movement control of the robotic wheelchair is achieved with the help of accelerometer or tilt sensor. The accelerometer senses head movements and based www.intechopen.com on the predetermined direction of movements, the robotic wheelchair can be controlled accordingly. Fig. 2 shows the side view of the robotic wheelchair with the locations of sensors. The embedded processor provides the intelligent decision making and motor control. All the sensors outputs are processed by the embedded processor and control the two DC motors as desired by the user. Automatic reactions such as stop or avoid when obstacles are detected are also handled by the embedded processor. In the robotic wheelchair prototype an ATMEL ATMega32 8-bit single-chip microcontroller is used as the embedded processor. The ATMega32 has 32 Kbytes of flash program memory, and 2 Kbytes internal Random Access Memory (RAM). The ATMega32 also includes an 8channels 10-bit analogue-to-digital converter (ADC), three timers, parallel input-output ports and several serial communication interfaces including Serial Peripheral Interface (SPI), Inter-Integrated Circuit (I2C) and Universal Synchronous Asynchronous Receiver Transmitter (USART). Fig. 3 shows the interfaces between the embedded processor, sensors and actuators in the robotic wheelchair.

The strategy to define the component-based development phases
A strategy is needed to allow the mapping of MARMOT and PECOS methods in order to identify overlapping phases in between the two methods. The mapping of these two methods is required in order to propose a new component-oriented developed method based on the two selected component models. Fig. 4 shows the models and phases of the methods. It comprises of three development process which are COA, COD and COP. The development process is then divided into five phases, which are analysis, early design, detailed design, composition and implementation. COA level involves the analysis phase; COD level involves two phases, which are early design and detailed design; and COP level involves composition and implementation phase. The analysis phase includes two strategies, which are preliminary information and system architecture planning. Preliminary information consists of the basic requirements of the use case diagram, use case description and interaction model. The system architecture planning transforms the circuit into Unified Modelling Language (UML) representation and in turn produces a preliminary containment hierarchy of the whole system. The early design phase contains the finer-grain component of software that further divides into two parts, which are specification and realization. In specification of components, three models are produced, which are functional model, behavioural model, and structural model. The structural model is also produced in realization of components, as well as the activity model and interaction model.

A component-based development process model for embedded real time software
Defining the integrated process of MARMOT and PECOS methods in a systematic form is important to enable and support the development of CASE tool for ERT system. Here, the process is represented using Software Process Engineering Meta-model (SPEM) (Schuppenies & Steinhauer, 2002). SPEM is a meta-model that is used to describe a concrete software development process or family of related software development process. The Fig. 5 below shows the SPEM icons that are used in this project: a. Activity: is the main subclass of Work Definition, it describes a piece of work performed by one Process Role. b. Document: a stereotype of work product. c. Process Role: the performer of Activities and responsible for a set of Work Products. d. Phase: a specialization of Work Definition such that its precondition defines the phase entry criteria and its goal (often called a "milestone") defines the phase exit criteria. e. Work Definition: kind of Operation that describes the work performed in the process. f. Work Product: an artifact is anything produced, consumed, or modified by a process. There are five phases in the process model; analysis phase, early design phase, detail design phase, composition phase and implementation phase. Each of these phases produces a work product for the related activities and has its own responsibilities in designing one or more artefacts. Fig. 6 illustrates the phases in COA, COD and COP process using SPEM. The details for each phase are discussed in the following subsection. Fig. 7 illustrates the use case diagram for analysis phase, whereas Fig. 8 represents the use case for early design and detailed design phase. Meanwhile, Fig. 9 illustrates the use case diagram for composition and implementation phase. These use case diagrams show the www.intechopen.com relationships between the process and the main activities in the software process based on the three level developments, which are COA, COD and COP. In the COA level, analysis phase is divided into two main activities. The first activity is collecting preliminary information which consists of three processes; requirement specification, requirement analyzing and interaction analyzing. The second activity is planning the system architecture which includes two processes; manually transforming electrical schematic diagram into UML representation and identifying the preliminary component.

Fig. 8. Use case diagram for early design and detailed design phase
The COD level includes two phases, which are early design and detailed design phase. In the early design phase, the finer-grain component includes two activities. The first activity is identifying component specification that will produce a functional model, behavioural model and structural model. The second activity identifies component realization that

Analysis phase
The purpose of analysis phase is to analyze the ERT system requirement. As was previously mentioned, ERT system requirement involves multi-disciplinary knowledge. Therefore, analyzing the ERT system requirement does not focus on software only but also on the hardware. In this analysis phase, the MARMOT method is used to support the multidisciplinary knowledge required for ERT system. It is divided into two parts; the first part is collecting the preliminary information and the second part is planning the system architecture. Collection of the preliminary information can be further divided into three activities, which are problem analysis, requirement description and interaction analysis. System architecture planning includes two activities, which are transforming electrical schematic diagram and identifying a preliminary component based on transformation electrical schematic diagram into UML representation. The analysis phase starts with analyzing the requirement, by identifying the problems and by looking at the application functionalities. It also identifies the user who is interacting with the application. This process produces the use case model of the system. The next activity involved is describing the requirement description thoroughly so as to produce the use case description table. This description table describes the multi-disciplinary knowledge of ERT system requirements. After that, interaction analysis is carried out to briefly draft the interaction between each state in order to produce the interaction model. Fig. 10 shows the flow of the activity in analysis phase, which is described in terms of work definition and work product as input. The next step involves in obtaining the information directly from the electrical schematic diagram in order to identify the possible preliminary component software. The electrical schematic diagram is manually transformed into UML and all hardware parts are removed to obtain a list consisting of only software parts. The software parts can be a component with a stereotype <>. The list of the possible software components is represented by the containment hierarchy diagram. Fig. 10 shows the work definition and work product of analysis phase.

Early design and detailed design phase
The purpose of an early design phase is to fine-grain the preliminary component containment hierarchy that is identified from the analysis phase. The preliminary component containment hierarchy at analysis phase is used as input for early design phase. The early design phase has two main activities, which are identifying component specification and component realization for each software component. These two activities produce UML diagram artefacts. Component specification produces three models, which are structural, behaviour and functional model whereas component realization also produces three models, which are structural, activity and interaction model. In this stage, multi-constraint extra-functionality requirement which focuses on timing is considered as model for the software component specification and realization, and is represented by timing diagram. At the detailed design phase, the integration point between the MARMOT and PECOS concept is produced. The detailed design phase includes three activities, which are refining the design component, constructing detail component information, generating the code template for single component and storing component into the component repository. Refinement of the design component involves some additional component to model the software behaviour. As a result, it produced a new version of preliminary component containment hierarchy. The process repeats until the component containment hierarchy fulfils the multi-disciplinary requirement. After the preliminary component containment hierarchy matures, the detailed component information is constructed. In this phase, PECOS modification is integrated whereby each component includes not only the functional requirement but also multi-constraint extra-functionality requirement. In this research, the focus is on timing of extra-functionality requirement. Therefore, regular component containment hierarchy is produced where the component includes timing, priority, outport and inport. Based on the detailed information of each component, the code template produces and stores the component into the component repository. It then produces component lists of the entire application. Fig. 11 shows the steps at early design and detail design phase.

Composition and implementation phase
The purpose of this phase is to integrate the components and generate the composition component code template for the entire application. The integration process integrates more than one component. In this stage, a component can have a sub-component, and it produces the composition component diagrams for the application. Once the composition is completed, the next step is to allocate property bundles value such as period and priority for active components using real-time scheduling theory. Meanwhile, the code template for the composition diagram is generated in the implementation phase. Fig. 12 illustrates each step at composition and implementation phase.

The wheelchair software development
The Intelligent Wheelchair (I-Wheelchair) case study, described in Section 2, was implemented to apply the integrated process model and show how the reuse activities from mobile robot systems to the I-Wheelchair were performed. The I-Wheelchair case study is an embedded system and it is relatable with the resource constraint of real-time and multidisciplinary requirements. I-Wheelchair software development as represented by the process model includes five different phases, which are analysis, early design, detailed design, composition and implementation phase. The following sub-section further elaborates each phase.

Analysis phase
As mentioned before, MARMOT method is implemented at the analysis phase. In this case, this phase involves processes like defining diagrams and textual specifications from the context realization of the I-Wheelchair system. It is divided into two parts, which are preliminary information and system architecture planning. Preliminary information produces use case diagrams, use case description and interaction model; and system architecture planning produces hardware UML diagram and preliminary containment hierarchy. The following sub-sections will be based on the I-Wheelchair case study.

Preliminary information
Preliminary information includes three activities which are requirement specification, analysis requirement and analysis interaction. The requirement specification of I-Wheelchair system is represented by the use case diagram, in which it consists of a textual and a graphical representation as shown in Fig. 13. www.intechopen.com The actor User initiates the task of controlling the I-Wheelchair movement whereby the actor Obstacle initiates the task of avoiding an obstacle around its environment. To analyze the interaction of the I-Wheelchair system, the interaction model diagram is used as shown in Fig. 14. The purpose of an interaction model is to represent the general flow of the I-Wheelchair control movement and obstacles avoidance by the two actors; User and Obstacle. It also illustrates several alternative actions that can be performed, and represents typical interaction of the operation for the overall system.
www.intechopen.com if the I-Wheelchair system detects an obstacle, it will stop moving and change the direction of its movement, and after that it will start to detect other obstacles; if no obstacle is detected, the system will move according to the current direction that is given by the user and it will start to detect other obstacles. A semaphore used in the implementation of the Obstacle interaction model to avoid deadlock situation. The infrared distance sensors at the back and front of the I-Wheelchair system are used to detect obstacles that labelled as input to the system as mentioned in Table 1. Therefore, the use case diagram, use case description table and interaction model can be useful for the ERT system developer to translate the hardware requirement into software requirement at the analysis phase.

System architecture planning
In this stage, the system architecture is planned by identifying the preliminary components. The identification of the component hardware is done based on the electrical microcontroller schematic diagram. As it requires software to calculate the control signal to be sent to motors, the motor is considered one of the initial hardware components. The microcontroller schematic diagram will be transformed into the UML presentation manually.

Early design phase
MARMOT was implemented based on the software requirement documentation of the I-Wheelchair. The discussion on the modelling for the I-Wheelchair was divided into two separate descriptions; specification and realization. As mentioned before, specification produced three types of model; functional, behavioural and structural model, represented by the operation specification table, UML state diagram and class diagram respectively. Realization produced the activity and structural model as well as the interaction model which are represented by the activity diagram, class diagram and interaction diagram respectively. The difference between the specification and the realization class diagrams are the details of the information provided where the specification class diagram only included the basic information while the realization class diagrams provided more detailed information such as the operation and the attribute. Fig. 16 and Fig. 17 show the examples of realization models, i.e. the Sensor class diagram and the Sensor interaction diagram.

Detailed design phase
The integration of MARMOT and PECOS was implemented in this phase by extending the MARMOT Regular Containment Hierarchy diagram. The hierarchy diagram of the I-Wheelchair system in this phase is derived and extended from the Preliminary Containment Hierarchy diagram from Fig. 15, which included the component name and also has the detailed description of the component diagram information. The regular containment hierarchy of the I-Wheelchair shown in Fig. 18 includes the hardware and software components. The hardware component is represented by the <component> stereotype with six hardware components such as sensor, LED, controller, joystick, motor and accelerometer www.intechopen.com and was initially derived from the schematic diagram. The Controller component interacts with the I-Wheelchair application using the device driver to support software component structural modelling.
The component definition used in this work was extended from the original PECOS model (Jawawi et al., 2006). Fig. 19 shows an example of a composite component definition. The component diagram also contained component types such as active and passive. In order to represent an active component, initial time and priority are set in the right side of the component. If there is no set value for timing and priority in that component, it means that the component is a passive component. Furthermore, each component has port information which consisted of two types of port; inport and outport. The port name is represented by a code such as IP00, signifying that the component has an inport port at the first position followed by IP01 for the inport port at the second position as illustrated in Fig. 19. The same rules were applied for the outport port. The components without shadow represent a leaf component (without any sub-components inside) while the components with shadow indicate that it has sub-components called composite components as illustrated in Fig. 18  From this composition diagram, code template was generated based a Component-Oriented Programming (COP) framework as proposed in Jawawi et. al (2007). The code consists of three block codes, which are the synchronization part, execution part, initialization part. The synchronization part synchronizes the connection port, the execution part chooses a behaviour based on the current command and the initialization part gives a default value. The COP is supported by an experimental component composition tool. Fig. 21 shows an interface of component composition using the COP tool and all the new and reusable components from other application are listed on the right hand site of the composition. The COP tool is still at development stage, current version of our tool supports component integration, composition and code generation of the structure composition. The designer needs to manually code the functional behaviour of each component. Once the composition is completed, the next step is to analyse the property bundles value such as period and priority for active components using real-time scheduling theory. The scheduling analysis of the composition can be done since the timing required for the analysis were documented with the designed composition.

Composition and implementation phase
www.intechopen.com

The software reuse results
The case study application showed how the process model can be used to support the CBD activities of the wheelchair software. The result of implementing these activities on the I-Wheelchair was software with 3583 lines of C codes which generates firmware with code size of about 8.6 Kb with RAM usage of about 1.6 Kb. The software was implemented on an ATMEGA32 8-bit microcontroller with 2 Kb RAM, which illustrated an implementation on a self-contained I-Wheelchair system. This size proves a light-weight solutions integrated in the developed process model is suitable for resource-constrained ERT systems. The realtime performance of the system was predicted during components composition. This prediction was verified in performance testing during implementation phase where the wheelchair showed a reliable behaviour especially on hard real-time tasks.
The design and implementation of the wheelchair software design components were derived from our previous studies and development of mobile robot software systems. One of the studies was the component engineering process of the reusable design components in the Autonomous Mobile Robot (AMR) software development documented in Jawawi et. al (2007). Each component in the reused component repository was modeled using the COP framework. The reusing process of the software components from an AMR system to the I-Wheelchair aims to analyze the reuse level resulting from the implementation of the process model activities. Amount of reused components were used to assess a reuse improvement effort by tracking percentages of reused components with two types of component reuse: reuse as is and instantiated reuse. The main concern in this amount of reused components is to measure the reuse of the software components on different platforms and different physical sizes of the AMR and the I-Wheelchair systems. The strategy adopted in analyzing the amount of reused components in this work is to compare the percentage of component reused in two cases: 1. Case 1 Reuse: MobileRobot1 to MobileRobot2 software reuse as reported in Jawawi et. al (2007) and 2. Case 2 Reuse: MobileRobot1 to I-Wheelchair software reuse as shown in this section. The differences between the three systems are tabulated in Table 2 and Table 3. Table 2 is to differentiate the platform and size of the systems and Table 3 is to differentiate the number of hardware used in the systems. The code used in the table is as: Mtr -Motor, Fan, Enc -Encoder, DS -Distance sensor, PS -Proximity sensor, TS -Temperature sensor, LS -Light sensor, AS -Accelerometer sensor and KP -Keypad.

MobileRobot1
AMD188ES ( Table 3, two hardware components exist in both systems are motor and distance sensor. The types of distance sensor used in three case-studies are the same but the types of motor used in the three cases studies are different. Mtr  Fan  Enc  DS  PS  TS  LS  AS  KP  MobileRobot1  2  0  2  2  2  0  0  0  0  MobileRobot2  2  2  0  1  0  1  1  0  0  I-Wheelchair  2  0  0  6  0  0  0  1  1   Table 3. The AMR and wheelchair systems sensors and actuators

Case-studies
To measure the software reuse rate, the number of reused component from the components repository will be analyzed. The parameters identified to analyze the amount of reused components in the two reused cases are: reused 100% from design components repository without changes (reuse as is), new components developed (new) and reused components by instantiating the components from MobileRobot1 for the MobileRobot2 or the I-Wheelchair software development (instantiated reuse). Table 4 shows the number of reused components in the two reused cases and the components are grouped into five groups according to our components repository groups.   Table 4 shows higher number of components reused without changes in robot to robot reused case as compared to robot to wheelchair reuse case. This was due to the differences in the components in HRI group and Behavior and Subsumption group. The wheelchair system required different HRI devices and the behavior of wheelchair is not fully autonomous, which still require human control to navigate the wheelchair system. It led to more number of new behavior components or changes to the existing behavior components. Apart from HRI group and Behavior and Subsumption group, other groups showed the same reused pattern. The analysis work was to identify the rate of components reused from the design repository integrated in the proposed process model. The component reused percentage is the calculation of percentage of reused software components over total software components in the composition. The summary of the component reused percentage for both reused cases are shown in Fig. 22. The figure shows up to 90% component reused rate achieved in designing MobileRobot2 software from the MobileRobot1 design components and 71% components reuse achieved in designing I-Wheelchair software from MobileRobot1 components. It showed that the reuse as is percentage for Case 1 is higher than Case 2. The instantiated reuse rate in both reused cases were about the same but the reused as is rate www.intechopen.com was higher in Case 1. This was due to high number of new components required in the wheelchair system as shown in Table 4. The amount of component reuse analyzed in this implementation aims to study the possibility to achieve software reuse from mobile robot software to robotic wheelchair software. The component reused results showed a high rate of component reused was shown in mobile robot to wheelchair reused case, but this rate is lower than mobile robot to mobile robot reused case. This high rate was possible in this implementation due to the same behavior-based control paradigm (Brooks, 1986) and sensors' types used in both wheelchair and mobile robot systems. The systematic process model used in this wheelchair implementation help the wheelchair developers to identify the possible reused component in at the early stage of the software development.

Comparison results of component-based development process models
This section discusses the results comparison between the integrated MARMOT and PECOS method with other method, based on the criteria as shown in Table 5 The comparisons were made on two existing CBD methods; COMponent-based design of software for Distributed Embedded Systems -version II (COMDES-II) (Ke et al., 2007) and ACCORD/UML (Gerard et al., 2002). ACCORD/UML's targeted audience includes engineers who are not software experts and COMDES-II is a component based software framework intended for efficient development of distributed embedded control systems with hard real-time requirements. Table 6 shows the evaluation summary of CBD methods based on the evaluation criteria. Based on the general criteria evaluation results, it showed all three methods support component at analysis phase and implementation phase. Only the proposed integrated method represent components at design phase using block diagram introduced by MARMOT to be included as part of it containment hierarchy diagram and represented in component composition diagram at implementation phase. COMDES-II and ACCORD methods combine the design phase component representation with the analysis phase. The integrated method defines the component representation in each phase, this enable all multi-disciplines experts for a system like the robotic wheelchair systems to define and specify their own components. Both the integrated method and ACCORD modelling techniques use UML except COMDES-II method that using actor model and function block model. The UML modelling enables multi-disciplines engineers to communicate and share their software components. The integration of MARMOT and PECOS is shown to support both multi-disciplinary and multi-constraint real-time requirement. ERT CBD methods criteria showed that only the integrated MARMOT and PECOS method supported multi-disciplinary including software and hardware and multi-constraint ERT requirement. COMDES-II and ACCORD only support software disciplinary element. All three CBD methods support different level of real-time constraints; for example ACCORD supports high level concurrency, the integrated method supports timing analysis and COMDES-II supports concurrency and time multitasking. This is due to different nature of ERT systems targeted by different methods and different real-time requirements supported such soft real-time, hard real-time, timetriggered or event triggered. The integrated MARMOT and PECOS aims to produce a systematic CBD process model of ERT system where the development process model can support multi-disciplinary knowledge and multi-constraint extra-functionality requirement. The component representation systematically supported all phases: the analysis, design and implementation phases, this can provide more reusability facilities in all phases.

COMDES-II
The systematic CBD process model allows the multi-disciplines experts in the robotics wheelchair CBD development to develop their reusable components and integrates their components with other. Among the software components developed by different discipline reused in the I-Wheelchair system development are such as BBC component, motors component, sensors and input-output components.

Conclusion
This chapter proposed a method to enable reuse of mobile robot software into a robotic wheelchair (I-Wheelchair) software system. The robotic wheelchair system prototype was developed to test the implementation result of the proposed method. The component-based development (CBD) of the robotic wheelchair software using a set of reusable components, and the software composition of the wheelchair software were illustrated. The integration of PECOS into MARMOT method would produces a systematic CBD process model in terms of multi-disciplinary knowledge and multi-constraint extra-functionality requirement. The application of the CBD method in the I-Wheelchair system illustrated how the MARMOT and PECOS were integrated to produce a systematic development method for CBD. The method guides developers to model and deploy the robotic wheelchair software using the www.intechopen.com CBD activities and the phases are defined by the process model. With the strengths of MARMOT and PECOS integrated into the method, it enabled the functional and nonfunctional requirements, especially the timing properties, to be modelled explicitly in all phases. Furthermore, the method also considered multi-disciplinary requirements in its models which help software engineers to focus on their problem-solving of the robotic wheelchair system development. The activities to reuse software from existing robotics systems were explicitly supported in the proposed process model. The implementation of the I-Wheelchair case study, demonstrated that the proposed method has helped to guide the CBD of the software system from the analysis of the product to the implementation phase through the defined process model. The component reused rate achieved in the wheelchair implementation from a mobile robot design repository was high up to 71% and this implementation was compared with components reuse from the same mobile robot design repository to another mobile robot system to identify the pattern of reuse in both reused cases. No direct relation between the process model proposed and the reused rate studied in this chapter but the process model helped developer to identify and implement the component in all CBD phases. For future works, the existing component-based development tools will be refined further to support COD and COP methods and to integrate the tools with the UML models produced in the COA method.

Acknowledgment
Special thanks to the Universiti Teknologi Malaysia for financing and funding this research through Research University Grant and also to our Embedded & Real-Time Software Engineering Laboratory (EReTSEL) members for their continuous support.