BENEFITS OF USING OPEN ARCHITECTURE FOR REAL-TIME

CONTROL OF ROBOTS AND MULTI-AXIS MACHINING SYSTEMS

Goran FERENC1, Maja LUTOVAC2, Jelena VIDAKOVIC3, Zoran DIMIC4, Vladimir
KVRGIC5
1, 2, 3, 4, 5

Lola Institute
Kneza Viseslava 70a, Belgrade, Serbia

Abstract
This paper presents benefits of using open architecture for real-time control of robots and multi-axis
machining systems. The global economy requires the incorporation of new technologies into existing
controllers and reducing development time and cost. An open architecture appears as a solution to deal with
these requirements. The aim of applying open architectures and open source tools is to increase
competitiveness of companies. This article explains rationale for the development of open architecture
control systems and presents a controller that has been developed using this design philosophy.
Keywords: Increasing competitiveness, open architecture, robot, multi-axis control

1. INTRODUCTION
Due to the high innovation speed in the microprocessor field and communication technology during past two
decades, it becomes necessary for companies to develop hardware independent software as far as possible in
order to stay competitive [1]. Hardware and software components have to be constantly upgraded, so open
architecture control (OAC) is a solution which deals with these requirements.
The early nineties are marked as the beginning years of initiatives for enabling control vendors, machine tool
builders and end users to benefit more from flexible and agile production facilities. The goal was oriented to
customer requirements. Implementation of customer specified controls as easy as possible was the main aim
at the start of using open architecture approach. This related to open interfaces and configuration methods in
a standardized, vendor neutral environment. Such systems were broadly accepted which resulted in reducing
costs and increasing flexibility. System integrators reused software and implemented algorithms specified by
user, while users were able to design their controls based on the given configurations [2].
Device oriented, heterogeneous systems where application software, system software and hardware are tight
coupled dominated in the past. This approach led to complexity and inflexibility, long development time and
very difficult way to include new functionalities in such systems.
Market requirements have been changed and therefore the design approaches are different now. Significant
efforts were made to maintain and further develop the products according to these requirements. Modern
approaches, which comprise extensive functionality to achieve a high quality and flexibility of machining
results combined with a reduced processing time, favor PC based solutions with a homogenous, standardized
environment. The structure is software oriented and configurable due to defined interfaces and software
platforms. Open control interfaces are necessary for continuously integrating new advanced functionality
into control systems and are important for creating reconfigurable manufacturing units [3]. Unbundling
hardware and software allows profiting from the short innovation cycles of the semiconductor industry and
information technology. With the possibility for reusing software components, the performance of the overall
system increases simply by upgrading the hardware platform. These two types of approach, heterogeneous
and homogeneous, are shown on Figure 1.

Figure 1 Heterogeneous and homogeneous environment

According to the model IEEE 1003.0 an open system is defined as a system which provides capabilities that
enable properly implemented applications to run on a variety of platforms from multiple vendors,
interoperate with other system applications and present a consistent style of interaction with the user.
The openness of a controller is defined through:

Portability, which indicates that application modules can be used on different platforms without any
changes, while maintaining their capabilities.

Extendibility, which implies that a varying number of application modules can be run on a platform
without any conflicts.

Interoperability, which indicates that application modules can work together in a consistent manner and
can interchange data in a defined way.

Scalability, which implies that functionality of the application modules, performance and size of the
hardware can be adapted depending on the user requirements.

According to IEEE definition an open control system must be:

Vendor neutral, which guarantees independence of single proprietary interests.

Consensus-driven, which means that it is controlled by a group of vendors and users (usually in the form
of a user group or an interests group).

Standards-based, which ensures a wide distribution in the form of standards.

Freely available, which means it is free of charge to any interested party.

2. MAJOR INTERNATIONAL ACTIVITIES

There are several international activities which proposed open architectures around the world, but main
efforts were being carried out in the USA, Germany and Japan. All these architectures have integrated
equipment of several different manufacturers and offer control solutions at a lower cost, maintaining the
same performance. The most significant activities are presented in the following subsections as well as their
main characteristics.

2.1 OSEC (JAPAN)

Six Japan companies Toshiba Machine Co., Toyoda Machine Works Ltda., Yamazaki Mazak Co., IBM Japan
Ltda., Mitsubishi Electric Co. and SML Corporation, composed the OSEC (Open System Environment for
Controllers) group, whose objective was to develop a platform of open architecture for numeric control
equipment [4].
The OSEC architecture was intended with aim to provide end users, machine makers, control vendors,
software vendors, system integrators and others a standard platform for industrial machine controllers, with

which they can add their own unique values to the industrial machines, and hence promote the technical and
commercial development of the industrial machines [2].
OSEC is focused only on PC platform and Windows environment and it does not allow distributed control [4].
The purpose of creating a PC based open architecture for controllers of manufacturing equipment is to provide
a control system that has high cost performance and is easy to maintain. When this architecture becomes open,
manufacturers will be able to integrate their own control systems with various combinations of PCs and
control subsystems based on it. Since the architecture is based on PCs, it is expected to see high quality
software targeted on the area of factory automation. A PC can act not only as a controller of equipment, but
also as the basis of an information system for plant operation.
The OSEC API is defined in the form of an interface protocol, which is used to exchange messages among
controller software components representing the functionality and the real-time cycle. The controller software
components are integrated into a consistent control system by means of this message exchange mechanism.
Each functional block can be encapsulated as an object so it is not necessary to deal with how a functional
block processes messages to it at architecture level [2]. OSEC architecture is shown on Figure 2.

Figure 2 OSEC architecture

There are many options for implementations such as device driver, interprocess communication, installation
mechanisms such as static library and DLL, hardware factors like selection of controller card, and
implementations of software modules added for execution control and/or monitoring of various software. In
other words, the implementation model to realize the architecture model is not limited to a particular model. In
this way, it is assured to incorporate various ideas in the implementation model depending on the system size
or its hardware implementation and/or utilization [4].

2.2 OSACA (EUROPE)

In the OSACA (Open System Architecture for Controls within Automation Systems) project different
partners (universities, control vendors and machine tool builders) wanted to develop a vendor neutral
open architecture controller [4]. The aim was to unite European interest and to create a vendor neutral
standard for open control system [2].
The basic technical approach of the OSACA architecture is the hierarchical decomposition of control
functionality into functional units. For each of these functional units (e.g. motion control, axes control or logic
control) the interfaces are specified by applying object-oriented information models. The process interface
consists of several process objects that are used to describe the dynamic behavior of the application modules
by means of finite state machine (FSM). It can also be used to activate specific functions in form of local or
remote procedure calls.
The interoperability of distributed application modules is supported by an infrastructure OSACA platform. A
platform is composed of hardware and program groups (operating system, communication system) that offer a
uniform service for the functional unit control [4]. The application-programming interface (API) with the
functional unit (FU) is based on a well-defined task.

The three main platform areas are:

Communication System: hardware and software are defined independently of the information exchange
interface among different modules of the controller application. The OSACA communication system
allows the information exchange in a transparent way between client and server applications.

Reference Architecture: determines the control FU and specifies the external interface. This is done to
enable the use and integration of external units through internal data in a well-defined way. FU examples
are Man Machine Interface, Interlock Logical Control and Axes Movement Control. For each identified
FU, an external module using an object-oriented communication for data interfacing with application
modules is defined. The interface of writing and reading data access is located in the Architecture
Oriented Object and this access is available with the use of a Communication Oriented Object.

System Configuration: Allows a controller dynamic configuration through a combination of different

application modules. This does not only allow determining a specific topology of a given functionality,
but also the synchronization among the distributed processes.

Figure 3 System platform OSACA 1998

Figure 3 describes the platform of the OSACA system, where a configuration request generated by a
microcomputer is sent to the system. The reconfiguration uses functional unit, which works, based on objectoriented programs, a class library, with variables and internal data. The OSACA application protocol uses a
client/server base mounted on the object-orientation principle. All functional units functionality will have
external access and it is configurable by the communication platform. From the customer's viewpoint, the
server can be accessed through shipping and reception of system communication messages.

2.3 OMAC (USA)

In the 1994 OMAC (Organization for Machine Automation and Control) is formed as the Open Modular
Architecture Controls User's Group to provide an organization for companies to work together and to [5]:

Collectively derive common solutions for both technical and non-technical issues in the development,
implementation and commercialization of open, modular architecture control technologies,

Promote open, modular architecture control development among control technology providers and
adoption among end users, OEMs (original equipment manufacturers), and system integrators,

Act as a repository for open, modular architecture control requirements and operating experience from
users, software developers, hardware builders and OEMs in manufacturing applications,

Facilitate the accelerated development and convergence of industry and government developed
technology guidelines to one set that satisfies common use requirements,

Collaborate with users groups around the world in pursuit of common international technology guidelines.

In the 2008 OMAC changes its name to the Organization for Machine Automation and Control to better
reflect the broader mission and scope of its on-going activities.
The OMAC API adopted an object-oriented approach to plug-and-play modularization, using interface classes
to define the Application Programming Interface (API). However, plug-and-play on a per-class basis is not
practical. Instead, a coarser granularity is necessary that resulted in the OMAC API defining different sizes
and types of reusable plug-and play entities. To differentiate, the OMAC API uses different terms to
distinguish them component, module, and task with each based on a Finite State Machine so that collaboration
is performed in a known manner. The term component applies to a reusable piece of software that serves as a
building block within an application (analogous to a hardware part), while the term module refers to a
grouping of components (analogous to a hardware assembly). In general, new OMAC API component
interfaces may extend functionality of existing components by means of aggregation or specialization.
Further, new components can aggregate or inherit from one or more interfaces [6].

Figure 4 OMAC API controller functionality

Figure 4 illustrates a sketch of OMAC API controller functionality. The HMI (Human Machine Interface)
module is responsible for human interaction with a controller including presenting data, handling commands,
and monitoring events and in the OMAC API mirrors the actual controller with references to all the major
modules and components via proxy agents. The Task Coordinator module is responsible for sequencing
operations and coordinating the various modules in the system based on programmable Tasks. The Task
Coordinator can be considered the highest level Finite State Machine in the controller. A Task Generator
module translates an application-specific control program into a series of application-neutral Transient Tasks.
The Axis Group module is responsible for coordinating the motions of individual axes, transforming an
incoming motion segment specification into a sequence of equidistant time-spaced set points for the
coordinated axes. The Axis module is responsible for servo control of axis motion, transforming incoming
motion set points into set points for the corresponding actuators 1 point. The Control Law component is
responsible for servo control loop calculations to reach specified set points [2].

2.4 OTHER RESEARCH ACTIVITIES

NIST: The National Institute of Standards and Technology proposed and used the RCS (Real-time Control
System) reference model architecture [7].
JOP: The aim of Japanese Open Promotion Group was to provide the opportunities for various companies to
discuss and work together on the standardization of open controller technologies. It has approximately 50
members, which included major Japanese controller vendors, machine tool builders, integrators, users, and
academics [2]. JOP has been conducted the CNC API standardization for three years. The specification of the
API set PAPI (Principal Application Program Interface) has defined and becomes new Japanese standard.

NGC: The Next Generation Controller Program, based on the RCS reference model, co-sponsored by the
National Center for Manufacturing Sciences (NCMS), the U.S. Air Force and Martin Marietta, organized
industry requirements and prepared a specification for an open systems architecture standard (SOSAS) [8].
ECA: The Enhanced Machine Controller Architecture is the next step beyond NGC/SOSAS by NET. In the
ECA project, an open machine tool has been implemented based on the NGC/SOSAS and RCS reference
model [9].
Other research projects like the Chimera project at Carnegie Mellon University [10], the Multiprocessor
Database Architecture for Real-Time Systems (MDARTS) [11] at the University of Michigan and the
Hierarchical Open Architecture Multi-Processor Motion Control System (HOAM-CNC) [12] at the
University of British Columbia (UBC), have demonstrated a variety of approaches to the OAC. UBC has
developed a user friendly, reconfigurable and modular tool kit for motion and machining process control
(ORTS). UBC, ISW at University of Stuttgart and WZL in Aachen have cooperated to realize a gateway
which allows access to the process control and monitoring tasks of ORTS via OSACA commands.

3. LOLA CONTROLLERS
Open architecture benefits are used for development of series of controllers at Lola Institute. This design
philosophy is implemented on the real-time Linux platform. OROCOS (Open RObot COntrol Software) is
installed on this platform. OROCOS is a project started in 2001, with the aim to develop a general-purpose,
free software and modular framework for robot and machine control. OROCOS is one of the most
comprehensive systems that follows a similar approach to OACs described in this paper.
The control system is structured in layers. On the bottom is the real-time Linux operating system, the
OROCOS Real-Time Toolkit (RTT) is referred as middleware lying between operating system and
application or components level. The RTT provides the infrastructure and the functionalities to build robotics
real-time applications in C++. The RTT allows setup, distribution and building of the real-time components,
which are the highest layer of the control system. Beside RTT, OROCOS is composed of OCL (OROCOS
Component Library), KDL (Kinematics and Dynamics Library) and BFL (Bayesian Filtering Library).
Every OROCOS component is an independent functional block. It inherits a public interface from its base
class called TaskContext and the interface consists of following primitives: properties, events, methods,
commands and data ports. Real-time state machines as well as program scripts can be integrated into
OROCOS components.
The series of Lola controllers are based on the network of components which are controlled by the real-time
finite state machine (FSM) and it is shown on figure 6 [13,14].

Figure 6 Real-time part of the controller

The system can be easily configured by adding appropriate components (e.g. Kinematics or Controller) to
control various types of robots and multi-axis machining systems such as: 6-axis robot manipulator, 5-axis
machining robot, 3-axis parallel kinematic milling machine, 3-axis DELTA robot or 1+2-axis human
centrifuge [15,16].

4. BENEFITS
There are a lot of benefits for suppliers and users of open control systems. The main benefits are shown on
Figure 5 [17]. Designers of robots and multi-axis machining systems benefit from a high degree of openness
covering also the internal interfaces. For users the external openness is much more important. It provides the
methods and utilities for integrating user specific applications into existing controls and for adapting to user
specific requirements, e.g. adaptable user interfaces or collection of machine and production data. The
external openness is mainly based on the internal openness but has functional or performance limitations.

Figure 5 Benefits of using open architecture control systems

There are more benefits of using open architecture controllers:

Object-oriented programming.

Easy and lower cost upgrades of existing components.

Easy and lower cost integration of new components.

Homogenous system, PC based.

Software-oriented.

Hardware-independent software.

Standards-based.

Freely available.

More choices for end users.

More competitive systems.

Reducing development time.

5. CONCLUSION
This paper described benefits of using open architecture for control of robots and multi-axis machining
systems. Open architecture provides wide range of benefits in development of robots and multi-axis
machining systems including software-oriented approach which leads to a reduction of hardware modules, PC

based solutions with a homogenous, standardized environment, reusable software possibility, system
reconfigurability, configuration and implementation of new applications and requirements, hardware
changeability, adaptable interface, less time for development and reduction of overall system costs.
Open control systems are essential for the realization of modular, flexible and reconfigurable manufacturing
systems. Considering increasing of the high level of automation and the wide-spread of special purpose
machines, requirements for open control systems based on vendor neutral standards become larger.

6. ACKNOWLEDGMENT
Part of this work related to the Lola controllers was created within the research project that is supported by
the Ministry of Science and Technological Development, Republic of Serbia: Development of the devices
for pilots training and dynamic flight simulation of modern combat aircraft: 3 DoF centrifuge and 4 DoF
spatial disorientation trainer.

7. REFERENCES
[1] Endsley, E., Lucas, M., Tilbury, D., Software tools for verification of modular FSM based logic control
for use in reconfigurable machining systems, Proceedings of the 2000 Japan-USA Symposium on
Flexible Automation, ISBN 0-7918-0765-8, July 2000.
[2] Pritschow, G., Altintas, Y., Jovane, F., Koren, Y., Mitsuishi, M., Takata, S., et al., Open Controller
Architecture - Past, Present and Future, Annals of the CIRP, ISSN 0007-8509, Vol. 50, No. 2, 2001,
463-470.
[3] Y. Koren et.al., Reconfigurable Manufacturing Systems, CIRP Annals, Vol. 2, 1999, 527-540.
[4] Asato, O., Kato, E., Inamasu, R., Porto, A., Analysis of open CNC architecture for machine tools,
Journal of the Brazilian Society of Mechanical Sciences, Print version ISSN 0100-7386 J. Braz. Soc.
[5] http://www.omac.org
[6] Birla, S., Faulkner, D., Michaloski, J., Sorenson, S., Weinert, G., Yen, J., Reconfigurable Machine
Controllers using the OMAC API, Proc. Of the CIRP 1st International Conference on Reconfigurable
Manufacturing. May 2001.
[7] Proctor, F., et al., Open architecture for machine control. NISTIR-5307, Tech. rep., NIST, MD, 1993.
[8] Next Generation Controller Specification for an Open Systems Architecture Standard, Manufacturing
Technology Directorate Wright Laboratory, September 1994.
[9] Proctor, F., Michaloski, J., Enhanced machine controller architecture overview. NISTIR-5331, Tech.
rep., NIST, Gaithersburg, MD 20899, December 1993.
[10] Stewart, D., Volpe, R., Khosla, P., Design of dynamically reconfigurable real-time software using portbased objects. CMU-RI-TR-93-11, Tech. rep., Carnegie Mellon University, Pittsburgh, PA 15213, July
1993.
[11] Lortz, V., Shin, K., MDARTS: A multiprocessor database architecture for real-time systems, Tech. rep.,
The University of Michigan, 1993.
[12] Altintas, Y., Munasinghe, W. K., A hierarchical open-architecture CNC system for machine tools, CIRP
Annals, Vol. 43, No. 1, 1994, 349-354.
[13] Kvrgi, V., Development of intelligent systems for industrial robots control and programming, PhD
thesis, Faculty of Mechanical Engineering University of Belgrade, 1998.
[14] Milievi, M., Vidakovi, J., Dimi, Z., Trgovevi, S., Modern open architecture control systems for
machine tools and robots control, Proceedings of 36th JUPITER conference, 32th symposium NURoboti-FTS, ISBN 978-86-7083-696-9, Faculty of Mechanical Engineering University of Belgrade,
2010, 4.41-4.46.
[15] Milievi, M., Kaplarevi, V., Dimi, Z., Kvrgi, V., Cvijanovi, V., Development of new control system
for robots and multi-axis machining systems, Proceedings of 4th International Conference on
Manufacturing Engineering ICMEN, ISBN 978-960-98780-4-3, 2011, 451-457.
[16] Milievi, M., Kaplarevi, V., Dimi, Z., Cvijanovi, V., Buan, M., Development of distributed control
system for robots control based on real-time Linux platform, 10th Anniversary International Conference
on Accomplishments in Electrical and Mechanical Engineering an Information Technology DEMI,
ISBN 978-99938-39-36-1, 2011, 813-818.
[17] Proctor, F., Practical Open Architecture Controllers for Manufacturing Applications, Open Architecture
Control Systems, ITIA Series, 1998.