3. Open Architecture, Modular and Distributed Control Systems
3.1. Essential Characteristics of Open Architecture Controllers
The flexible nature of RMS requires equally flexible control systems that can quickly and reliably adjust its control functionality depending on the systems available hardware modules at any given time.
Mehrabi et al. [3] have noted that software issues proved to be the area of greatest concern for the successful development and implementation of RMS.
For the realization of RMS, the system is required to be open at all three levels, namely: system, machine, and control. According to Koren [19] , the introduction of new modules in to a system may :
Enable the production of new products on an existing system
Improve the quality of production on the current system;
Decrease diagnostic times;
Lower the integration cost of discrete logic.
Furthermore, the addition of new modules may also:
Lower the capital investments for system upgrades when new parts are required to be produced.
The technical committee of open systems from Institute of Electrical and Electronic Engineers (IEEE) define an open system as a system that: “provides capabilities that enable properly implemented applications to run on a wide variety of platforms from multiple vendors interoperate with other system applications and present a consistent style of interaction with the user. “ [18]
The openness of the system is key to the effectiveness of the overall system, where openness is characterised by [18]:
Portability:
o The re-use of modules on different platforms without the need for modifications while maintaining the original functionality.
Extendibility:
o The ability of a number of modules to run on a system without conflict.
Interoperability:
o The integration of modules such that the modules function in a consistent way and communicate via pre-defined protocols of data exchange.
Scalability:
14
o The ability to add, integrate, remove or swap in new modules thereby scaling the system up or down to adapt the performance or functionality of the system.
Further to these characteristics of an open system, there needs to be a strong link between the software and hardware sub architectures of a RMS [11]. Similar to the modular hardware architecture of a MRMT, modularity is also a key characteristic for the openness of the software system [19] where modularity is defined as follows:
o The software parts of the system are created in modules with well-defined interfaces such that a number of these modules may be integrated to produce a desired functionality.
Figure 4 [10] illustrates how these criteria affects the system both internally and externally.
Bearing in mind one of the aims of OACS is to allow a user to be able to integrate user specific algorithms and programs, the user will require access to the internal data structures and variables in order to implement such control algorithms. Koren [19] highlights two basic types of controllers:
Vendor Specific (VS) controller:
o A system which is designed by a specific vendor and the possibility for expansion only exists with the integration of modules and algorithms that are supplied by that vendor.
Vendor Neutral (VN) controller:
o An open system designed by various vendors with the aim of allowing future integration of modules and algorithms that can be supplied/developed by any vendor/end user.
On comparison of the two basic types of controllers:
The closed architecture of a VS controller limits the possibility of future expansion unless the system uses VS products.
Open controllers aim to remove these VS limitations and introduce standardization across all platforms
Unlike the VS controller, the architecture of the VN controller is known; therefore any end user/control vendor may develop and integrate new methods and algorithms.
End users working on a VN system will have the option of choosing new modules or algorithms from a number of control vendors allowing the best algorithms to be added to a system.
Pritschow et al. [18] and Koren [19] further note that for the success of OA systems, the system must be:
Figure 4: Criteria for Open Control Systems
15
Vendor neutral;
Based on well-established open architecture standards;
Provide well defined methods for data exchange and control reconfiguration.
Based on this it is evident that the development of a VN controller is a key enabling technology for an OACS as it enables users to apply specific control algorithms and programs.
The architecture of the control system should be designed to allow the user to add, swap or integrate new modules at any given time as illustrated in Figure 5 [19]. A VN system will support this as it will allow the integration or addition of third party modules.
Figure 5: Three Critical Aspects of OA Controllers- Add, Swap and Integrate
Another key aspect for open systems is the reusability of basic modules in the creation of more complex algorithms via the integration into larger modules [19]. For example a basic limit switch module may be used in a position control module which in turn is used for an interpolation algorithm.
To accommodate for the effective re-use of software modules, a well-defined API is required for each module. The API for each module defines the way in which the module interacts with other modules [19].
Pritschow [18] emphasizes that the performance of the control system is influenced by the level of interoperability between the basic modules. Since basic modules are used as building blocks for the system, the development of well-defined API between the modules is crucial.
Most of the OA systems that have been developed are based on PC hardware and standard operating systems [20] such as Windows or Linux. These have real time processing capabilities. These PC based controllers have the ability to support commercially available peripherals. For example, interaction with external electronics and control modules can be implemented via I/O cards which are readily available for PC’s.
Since the robot programming languages are low level languages, the add on software development packages on PC’s such as Microsoft Visual C#, Nokia’s QT Designer and others can be utilized to ease the implementation of a PC based control system [20]. The OSACA Reference model in Figure 6 [21], presents an architecture design for the implementation of an OACS based on PC hardware.
16
The system architecture describes how the control application is built on the standard PC hardware.
The specifics of the computing system are encapsulated and is unnecessary knowledge for users. This encapsulation assists in control system portability and the interoperability between application modules [18].
Birla et al. have reviewed the Open Modular Architecture Controller (OMAC) API and concluded that the OMAC API seems the likely standard for the future [22]. The review covers the details of the API allowing third parties to: understand the standard and also to develop add-ons or to modify the current controllers using the OMAC API.
Further to the benefits of reconfigurability and scalability, the introduction of open control systems for RMT also assists in the cost reduction of systems upgrades, add to the flexibility of manufacturing systems in manufacturing new products and assist in prolonging the life cycle of RMS.
Since software issues proved to be the area of greatest concern for the successful implementation of RMS [3], this introduction to OA systems has emphasized key standards and features of OA systems and pointed out how the OACS will benefit RMS.