The robotics net interconnection concept.
Key words: open robot interface architecture, industrial software standards, robot real time interconnection, scalable network concept, robotics net
Networked robots are still a niche in automation solutions. Taking a closer look to installations already set up, results in finding mainly proprietary solutions without a uniform continuity. RoboticsNET--certain aspects of it are described in this paper--is one of the first approaches to build up a uniform communication infrastructure for industrial robots.
2. ARCHITECTURE BASE DESIGN
For the analysis and design of an open, extensible and scalable architecture, which fulfils the up to date requirements of robot technology on state of current IT technology, the prerequisite of continuity is mandatory. In other words this condition requires the patency from connecting the sensor actor level to robot controllers as far as running up to the office and ERP level which finally leads to the design of the architecture containing the following main components:
* Central server a host computer in the role of a central server for database & web. The host collects and saves data from the various data collectors and enables client web access to robots.
* Data collector server a data collector server is a server computer which on the one side communicates with the robot controllers on the network and on the other side with the central server hosting the database and web services. The introduction of this concept is mandatory to guarantee the scalability of the system for large installations. For instance in large installations the data collector server buffers write demands to the SQL database on the central server during high load phases (several robot controllers write simultaneously). Events will not be buffered but passed through directly as well as the messages from the central server via data collector servers to robot controllers.
* Robot controller one ore more robot controllers with standard Ethernet network access and the availability of an appropriate application programming interface (ABB, 2005a).
* Network a network according to the characteristics described in the following sections.
* Communication protocol a TCP/IP based communication protocol supporting the robot controller application programming interface.
* Client local or remote PC's which are able to access the central server respectively the hosted applications by an internet browser (ABB, 2005b).
On account of the RoboticsNET scalability characteristic described in this paper, the information flow from or rather to the robot controllers can be distributed over several data collector servers. The implementation of the data collector server's interrogator can either be based on polling or an event driven mechanism. Spontaneous, asynchronous messages are always event driven. Due to performance reasons regarding load balancing, the data collector server implements an in-memory buffer, which also serves short, temporary connection interrupts. Being offline for a while leads to data loss. For a warm restart without data loss respectively error recovery the possibility of using a message queuing server exists to ensure data integrity. However, this leads to a performance decrease which is in contrast to the architecture's real time requirements.
3. REAL TIME CONSIDERATIONS
One of the major constraints for the network design of RoboticsNET was the usage of standard hard- and software from the office world with all its advantages and disadvantages. Since the aimed application scenarios the time frames can be significant higher than upper limits for real time control tasks via network (e.g. movement control of a milling cutter in a machining centre or control of drive systems) the determinism of communication becomes more important in comparison to the representative time frame concerning speed. The developed system design within the issue of real time Ethernet difficulty can be described as follows.
The tough requirement for real time properties in wide areas of automation was always the strong argument against the introduction of Ethernet technology with the CSMA/CD access method as a base communication system. Ethernet uses a user shared media realizing the network functionality. Every participant can send a network package after checking the media for being unused.
However, simultaneous transmitting and the finite velocity of propagation may lead to collisions on the media. CSMA/CD takes care of such collisions and retransmits the packages so that no package will be lost and finally reaches the target participant. The thereby elapsed time however, can not be predefined since the MAC access method is a non deterministic method, which excludes the usage in the area of real time systems.
The strong development progress in network switching technology conversely enables the avoidance of the described difficulty if used properly. Once a package arrives at the switch from a network segment, a check for the target segment is done. The forwarding just takes place if the target segment is being unused, which means, that currently no other package is on that segment. Exists already a package on the segment, the switch latches the package and transmits it immediately after the target segment gets free again. Therefore a switch applies a separate channel between the respective source and target port. But using the switching technology for the realization of real time operation requires two additional strong boundary conditions:
* maximum micro segmentation of the switched network (exactly one participant per port)
* full duplex operation of all used components Considering these two conditions without exceptions results in avoiding collisions and blanks the stochastic access method. Further the full bandwidth of the network is available for every participant. In order that the periods for package transmission can be appointed with declaration of an upper limit which results in determinism (non-blocking design with uncritical total delay). Of course, the backplane of the used switches must have an adequate bandwidth. For the aspired application scenarios a lowest switching capacity of 12 GBit/s and a forwarding rate of 9 Mpps are required (twenty-four 100 MBit/two 1 GBit Ports).
4. SCALABLE INTERCONNECTION CONCEPT
Based on different enterprise sizes and a certain economic regulatory environment for the use of industrial automation solutions, their scalability is looming up large. Particularly in robotics automation business, solutions are required, which--with a preceding increase of the number of robots in a factory--do not demand a paradigm change of established solutions or rather implemented concepts for the same kind of problem scenarios. The fundamental interconnection concept has therefore be focused on scalability regarding rising robot counts in the network and having in mind the use of it within a manufacturing execution system environment (Stopper, 2005).
On the base of a fully switched network RoboticsNET provides a reasonable delimitation founded on current available standard hard- and software for the usage in small, medium and large installations. The empirical tests have yielded in describing three classes of installations. In small installations up to eight robots, the central server and the data collector server can be hosted on the same machine without performance issues. Above that, a separation to different host computers is required. Up to 24 controllers can then be connected to a data collector server which corresponds to a medium installation. In large installations additional robot controllers can be supplied by adding data collector server's step by step (max. 24 controllers per data collector). The central server machine has to be designed for high availability (Stopper, 1999). Figure 1 shows the scalable layout for e.g. 216 robot controllers.
[FIGURE 1 OMITTED]
Robot controllers are connected with 100 MBit full duplex per port. The connection of the data collector server as well as the connection up to the GBit backbone (through which the central server is connected) takes place via the two GBit uplink ports. For that reason a flat network structure is the result which concurrently solves the 'many-to-one-traffic' problem too. This difficulty arises by maximum micro segmentation of a switched network whether a lot of participants access one micro segment with high frequency (e.g. typical server operation). That micro segment represents subsequently a bottleneck within the communication system. By usage of uplinks with a higher bandwidth the problem is bypassed. If there are no such special ports on a switch, usually the possibility for bundling of ports (link-aggregation) to one or more uplinks with higher bandwidth exists. To reach more performance on higher protocol levels, it is recommended to use packet oriented protocols (e.g. UDP prior to TCP).
5. CONCLUSION AND FURTHER RESEARCH
For the RoboticsNET architecture an increasing number of robots within the robot network do not affect the corresponding technical parameters or rather the principal system behaviour. The real time behaviour on the level of the network is created by the stringent use of a fully switched infrastructure with certain additional conditions avoiding collisions on the Ethernet which results in determinism. For guaranteeing the real time data accessibility and the scalability of the system, network micro segments are built with connections to data collector servers. Data collector servers are common server machines with an in-memory database, parameterized schedulers and software agents which are realizing the connection of the various robot controllers to a central host system with a persistent database. The aimed continuity of real time requirements within the RoboticsNET architecture considering a deterministic sense was realized from hardware side up to network level. Currently the software infrastructure uses legacy protocols and parameterized standard operating systems to already enable applications on that platform which lack required real time considerations and determinism. That case has to be improved within further research. One promisingly approach is in the direction of service oriented architectures (SOA) regarding software infrastructures. The point of central interest in SOA philosophy is platform independent interoperability. SOA conform implementations just should apply the process logic of the correlative applications. The manner how data can be exchanged, whether data transmission is encrypted or not and with which protocols software components communicate, adequate real time and quality of service requirements as well as further infrastructural problems, should be solved just by parameterization and configuration.
ABB (2005a). Robot Application Builder--FlexPendant Software Development Kit Users Guide, ABB Automation Technologies AB, Robotics, 3HAC 024914-00, RobotWare v5.07, Molndal, Sweden
ABB (2005b). Robot Application Builder--PC SDK Users Guide, ABB Automation Technologies AB, Robotics, 3HAC 024913-001, RobotWare v5.07, Molndal, Sweden
Stopper, M. (2005). Virtual Engineering for Industrial Robotic Work Cells, Final Program and Abstracts of the 4th Asian Conference on Industrial Automation and Robotics (ACIAR'05), Paper ID-Code: F-35, ISBN 974-8208-58-3, 2005, Bangkok, Thailand
Stopper, M. (1999). A Concept for Enterprise Automation Networks, Proceedings of the 10th International DAAAM Symposium, pp. 533-534, ISBN 3-901509-10-0, October 1999, Vienna, Austria
|Printer friendly Cite/link Email Feedback|
|Publication:||Annals of DAAAM & Proceedings|
|Date:||Jan 1, 2007|
|Previous Article:||Tetracycline diffusion through bacterial cellulose--polyvinyl alcohol membranes.|
|Next Article:||Outline of the Open Robot Interface for the network design.|