|
The OSACA I project has been structured and
developed in accordance with the following working groups:
- WP 1: Reference
Architecture
- WP 2: Communication
System
- WP 3: System
Environment
- WP 4: Standardization
- WP 5: Demonstration
The following figure shows the relationships between the OSACA I
workpackages:
[Click on figure to see original size]
The OSACA system platform consists of system hardware, i.e.
electronic components, and system software. The system software contains core parts, like
the operating system or the communication system, and optional add-on system programs,
like a database system or a graphic system. It offers its services through a standardised
application program interface (API). The API is the only access to the platform for AOs.
It hides the actual implementation of the platform services and makes the platform
hardware independent.
The following figure shows the OSACA system platform:
[Click on figure to see original size]
OSACA I - WP 1: Reference
Architecture
For the OSACA reference architecture, the core of all the
requirements is openness. It is therefore important to give a precise definition of
openness for the reference architecture. OSACA has adopted the following definition:
An open control system, as understood in the OSACA project,
consists of a set of logically discrete components. The interfaces between these
components and between the components and the implementation platforms are well-defined
such that a meaningful combination of components from different vendors can cooperate with
each other to form a complete and correctly functioning control that runs on a variety of
platforms and presents a consistent interface to the human users as well as other
automation systems.
With this definition and other considerations and practical
limitations, the objectives of the OSACA reference architecture can be briefly summarized
as:
- Allowing independent developments of components
- Allowing precise description of the interactions among the components
- Allowing components to receive complete support
- Allowing the reference architecture itself to be extended
- Allowing gracious and gradual migration of existing controls
The task of work package 1 is to define the relevant aspects of the
components in a way that fulfils the requirements listed above. These relevant aspects are
formulated in function related attributes and services that can be accessed by other
components. The combination of these access possibilities and their associated behaviour
of the components shall suffice for the control of the assigned manufacturing equipment.
The control is made of a set of architecture objects (AO). These
architecture objects are grouped into 5 areas according to their main functions in the
control. Following is the definition of the subjects:
- Human-Machine Control (HMC):
- Human-Machine Control represents the machine, or part of the machine,
to the external entities, such as the operator, the supervising system over network, and
CAD/CAM systems for the machine, etc., and allows these entities to control the operation
of the machine. It could further provide utilities for preparation of jobs for the machine
as well as general utilization and management of the machine and the computing resources.
- Motion Control (MC):
- Motion Control enables the machine to produce relative motion of a
given degree of freedom. It does so by issuing appropriate commands to the axis controls
of the axes in its corresponding axes group of the machine. The motion can be required to
be precise, continuous, synchronised, and dynamically constrained.
- Logic Control (LC):
- Logic Controls are responsible for the operation of the actuators and
data taking of the sensors built in the machine. They should also ensure the consistence
of the operations and the data taken.
- Axis Control (AC):
- Axis Control includes all the means necessary for activating the axis
to execute movement commands within defined constraints. The commands are often issued
cyclically.
- Process Control (PC):
- Process Controls represent, when needed, the auxiliary systems of the
machine. They are also responsible for the data management and processing of the auxiliary
systems they represent.
Considering the amount of functionality which has to be included in
fields such as Motion or Man Machine Control, it becomes clear, that a further, finer
subdivision is necessary. This is the only way to substitute or complete part
functionalities such as a new motion guidance for laser cutting or a simulation programme.
For this reason, a hierarchical architecture was introduced. The five main fields of the
superior levels can be devided in part tasks in up to two further levels.
The following figure shows an example for the decomposition of the
hierarchically structured reference architecture.
[Click on figure to see original size]
OSACA I - WP 2: Communication
System
A main topic of the OSACA project concerns the field of
control-internal and control-external communication. For the area of control external
communication CAN, FIP, Interbus/S, Profibus, SERCOS or TCP/IP to mention only a few, a
great number of products and standards especially for field buses and drives are offered.
The fact, that it cannot been foreseen, which systems will win the competition, leads to
almost as many problems, as if there were no standards at all. In the area of control
internal communication there are a lot of vendor specific solutions and no standards at
all. In order to reach a certain decoupling for the development of application software as
well as from the events of the control internal hardware and software solutions, it is
necessary to provide even in this case a neutral inter-layer.
For this reasons, OSACA has specified a vendor neutral communication
system. According to the ISO/OSI reference model, the control-internal communication is
done via a uniform, message-oriented communication interface. To be able to fulfil the
high real time demands on a control, the layers 1 to 4 were combined into the OSACA Message
Transport System (MTS) and the layers 5 to 7 to the OSACA Application Services
System (ASS). To simplify the management of communication objects within the
architecture objects of applications a Communication Object Manager (COM), which is
optional, is introduced.
For the transport of arbitrary messages between arbitrary objects,
the Message Transport System (MTS) provides a hardware-independent interface. The
MTS internally makes use of available protocol stacks, as they have been mentioned before.
To be able to use this system both, for compact, as well as for distributed controls,
interfaces to shared-memory and message-queues according to the POSIX standard were also
provided. For control internal communication shared memory or message queues can be used
and for control external communication TCP/IP and PROFIBUS are applied.
The Application Services System (ASS) is responsible for the
connection management, encoding and decoding of messages, as well as for error treatment
within the communication system. In addition to that, data format conversions, as they are
necessary sometimes when data are exchanged between different types of CPU's and timer
functions are included.
The protocols, which are provided by ASS, were defined with
reference to the Manufacturing Message Specification (MMS) Standard. Again using
object-oriented principles, eleven communication object classes were specified,
which allow a comfortable modelling of all types of communication which are needed within
a control and for communication with superior and inferior systems. They offer services to
manage variables, processes, files, events, semaphores, directories, operator station and
containers. All object classes are described with regard to the services they offer, the
attributes and a state machine. Architecture objects using ASS in order to exchange their
request, response and report messages.
For a fast and simple implementation of new application software
modules, the Communication Object Manager (COM) as part of the architecture object
was introduced. The COM provides an optional frame with standard routines and call-back
functions for the creation and deletion of communication objects. It is an advanced link
between the communication system and the application. It helps to execute all those
application specific management tasks which are necessary to execute services in an
architecture object which were requested through the communication system.
The following figure gives an overview about the OSACA communication
system:
[Click on figure to see original size]
The OSACA communication system consisting of the Message Transport
System, the Application Services System and the Communication Object Manager supports an
easy going and vendor neutral design of user specific client and server applications. The
OSACA communication system is the vendor neutral link between the user specific
application, the control internal communication and the control external communication to
superior systems like cell control and factory wide networks.
OSACA I - WP 3: System Environment
Configuration system
The adaptation of a control to a special machine is normally done by
setting data. Often, several thousands of data items have to be set up with comparably
modest help functions until the control fits to the machine. Thus, the set up of a new
machine tool can take weeks. To reach a higher flexibility and user friendliness, it was
demanded that the control can change its configuration both, during boot up and
dynamically during its runtime. For this reason, the OSACA configuration system comprises
a configuration manager, which reads configuration data, sets up the corresponding
instances of object classes and introduces them to one another. This makes it possible to
adapt the control to a machine on a very high level.
Operating system
For automation systems real time operating systems are the base for
software development. After an analysis of a couple of real time operating systems and
international standards OSACA recommends the using of real time operating systems with an
application programming interface (API) complying to the POSIX standard. For applications
in the MMC area other operating systems are possible and today usual.
Database system
Database management systems are increasingly being used for data
maintenance and management in systems for Cell and NC control technology. The advantages
of database system like e.g. data integrity, fail safe etc. should be used on an open
control platform. In this context two aspects were pointed out: Integration of a database
system into OSACA reference architecture and the requirements for database systems. Three
different solutions to access the database were defined. The method which is offered
within a control depends from the control vendor.
Integration of Architecture Objects
The architecture objects are regarded as independent units, which
have no direct calling relations to the other AOs. In the control system they represent
single tasks which interact via message oriented communication. The main task of managing
architecture objects like initailizing and establishing connections between them is done
by the configuration system. Another aspect in integration of software are the mechanisms
for adding or substituting software. But the mechanisms depend on the operating system and
other details of the control vendor specific parts of the platform. These mechanisms rely
on techniques for linking of software systems. The control vendor normally offers one of
the mentioned mechanisms together with tools and other facilities of development
environment.
OSACA I - WP 4: Standardization
Based on the previous results this workpackage describes the
implementation guides for the reference architecture, the architecture objects, the
communication system and of the other parts of the control system.
OSACA I - WP 5: Demonstration
The OSACA project has initiated numerous PR-activities. A number of
articles were published in magazines and newspapers in several countries and information
material (brochures, posters) was mailed. The project was presented on several conferences
and workshops. Contacts to international organisations have been established. Contacts to
other ESPRIT projects like MATRAS, HEDRA, CAMATT, MAREA or MOSAIC were established either
by OSACA project members participating in the other projects or by presenting the OSACA
project results during workshops of the other projects. In order to promote and
disseminate the results of the OSACA project and to reach a wide-spread industrial
audience in 1994 a task force group was set up. It consisted of members of the European
machine tool builder associations (CECIMO and national organisations), members of the
European Commission and the OSACA partners.
|
