Solving Laboratory Automation Problems by Using an Object-Oriented Framework Based on Business Objects

INTRODUCTION

A relevant standard adoption for Laboratory Automation Control is currently developed within an OMG (Object Management Group) to improve the quality and utility of software and information systems used in Life Sciences Research by using the Common Object Request Broker Architecture (CORBA) and the Object Management Architecture (OMA). The scope of this approach covers many aspects related to life sciences research, including genomics, bioinformatics, genetics, structural biology or computational molecular biology. An emerging new industry must focus on high end information technology solution to enable high quality process control, data acquistion, data feed forward and feed backward for process optimizaiton. The developed software must conform to existing standards such as GLP, GMP, GAMP, FDA, ISO9000 etc.

Many of the expected advantages are already foreseeable. The report encourages other companies to make the paradigm shift to the new technologies described herein. An existing laboratory production system requires different processing ways and material handling control systems.

In order to have a competitive advantage in the strongly contested laboratory automation market some automation operations (“Business Objects”) need highly labor-configurated or even pro-prietarily implemented information technology (IT) solutions.

The suggested approach is a state of the art IT architecture with a forward-looking, easy expandable framework. This framework should be able to manage nowadays company-internal IT projects, fulfilling both a modern IT archtitecture with prospects for the future and projects which are visible at a glance. Such a framework will guarantee the best balance between the integration effort of buyable and self developed (“high end”) IT solutions.

IT PROBLEMS

The traditional concepts use standard software (partially out-of-date) adding proprietary solutions resulting in a lot of maintenance problems. The consequence is an explosion of implemetation, integration and maintenance costs. Thus, this scenario becomes more and more unmanageable and leads to tremendous financial efforts.

The problems which semiconductor manufacturers have been facing in general are:

• *

  Integration of incompatibile IT architectures

• *

  The individual requirements on IT solutions of different firms are very complex

• *

  The firms have material handling problems

• *

  Complicated IT solutions for data processing

• *

  Complicated IT solutions for data archiving

• *

  Very complex data correlation mechanism

• *

  One has collection of automated islands

All these problems are immediately there when one has to deal with the sophisticated theme like laboratory automation.

This paper points out an approach of solving nowadays IT problems based on experiences known from an exemplary implementation, of the IT Solutions based on object oriented-frame-work, at semiconductor manufacturer company in Germany and provides a basis for the knowhow transfer between semiconductor industry and laboratory automation.

ANALYSIS AND SOLUTION

To regulate and to automate a particular equipment activity, semiconductor enterprises had to collect and manage tremendous amounts of process data, which are shared by the different business objects. At the same time, there will be a need of integrating new and ad hoc components and solutions to business problems.

The regarded process in this particular project is an aggregation of several machine resources and is characterized by many control parameters with feed forward / backward control loops with individual control algorithms. Machine, recipe and material management had to be considered like wise (Figure 1). Thus, the process automation is a “high end” application which is easy to maintain and to reuse for other process types. Therefore, main focus was on the reusability and interoperability of the components. The developed solution is based on shared business objects and it is possible to plug them into a distributed, heterogeneous business system without modification of the enterprise model. This makes the software itself highly flexible, integration of legacy applications is much easier and thus provides a comfortable integration of different labaratory equipment in the software.

Figure 1:

Framework Architecture

To make independently developed business objects interoperable, ideas of OMG's Business Object Component Architecture (1) were included: the objects must have a consistent way of representing business concepts, their relationships and interactions. To achieve the aim of consistent interoperability, it is important to specify the nature of business objects, their interactions and their services.

Figure 1 shows in general how OO-Framework architecture works. This architecture includes different buisness objects known as management components e.g. Recipe Management, Machine Management or Statistical Process Control(SPC) component etc. These components communicate with each other depending upon the communication infrastructure provided by the corresponding firms e.g. CORBA, DCOM or Message Bus. Every component takes care of the classes which it administrates individualy and provides only the required results to other components. The communication interface between the components is the Component Manager (Figure 2) which manages and makes itself compatible to the communication media. The example which has been developed by Fraunhofer - IPA is a Process Controller which initialises five components (Recipe Management, Machine Management, Process Job Management, Material Management and Event Management) and plugs itself to the Manufacturing Execution Systems (MES) or to Production Planning Systems (PPS) sharing the same communication infrastructure. This process controller takes an order from a MES and completes this order on a collection of machines managed by Machine Management component which furteher requires information from other four components.

Figure 2:

A Component Manager as a Business Object Interface

Figure 2. illustrates the fundamental aspects of business object interoperability. Each of the two business object implementations could be provided by different vendors on different platforms and languages.

The type Component Manager is the component's object instance and manages the extents of the instances which provide visibility not only to outside business objects. The business objects with their type managers support a number of interfaces and protocols by which they interoperate (event, query etc.).

Figure 3. At the same time, there are some shared services that cross business object frameworks that must be used in a consistent way to support execution in a distributed computing environment. These features are decisive quality factors of the project.

Figure 3:

Interoperability of Business Objects Results and Conclusion

The framework provides not only generic classes for specialization but a configurable and easy-to-integrate business solution. Initially, the framework's domain model was derived from the work of (2) but was extended by company-specific aspects. It is a framework showing reusability and easy integration of different components for other process automation projects. By using Unified Modeling Language (UML) (3) during analysis, design and implementation as a guide, supported by a CASE (Computer Aided Software Engineering) tool, future expansion efforts will be alleviated. Most parts were implemented in Java, using an object request broker (ORB) and a message bus for integrating legacy systems.

In the course of high automation in laboratory production a fully integrated information technology approach is required in order to insure process quality and to allow on-line process data acquisition. Therefore an interoperable, object-oriented Framework approach to specify laboratory automation systems requirements has been selected and the know-how gathered has been transferred from other industries such as semiconductor manufacturing.

The Fraunhofer-Institute IPA, Stuttgart Germany, conducts research which deals with the described problems. We have developed multiple OO-Framework solutions for Process Control or even Control of full manufacturing lines and visualization of this with corresponding real time simulations. Figure 4 shows the possible realization of the OO-Framework for laboratory automation as this particular problem has been realized by us for the semiconductor industries. The experience which we have made with the OO-Framework solutions are that:

Figure 4:

The future world

• *

  It provides a reusable and integrated system design

• *

  The basing implementation is done on advanced but proven open software technologies and standards

• *

  It reduces new application development/integration costs and cycle times through adoption of a pre-designed and pre-integrated system architecture

• *

  It provides a stronger and broader base of viable application suppliers

• *

  It reduces new ramp-up time because of faster equipment integration (e.g., make data collection and analysis tools available without integration delays)

• *

  It increases productivity of Computer Integrated Manufacturing system support teams because the software is easier to fix and enhance (with limited side effects)

It simplifies the baseline design of common objects at a meaningful level of granularity and detail:

• *

  initial application partitioning

• *

  labor data and behavior model common to all applications

• *

  resolves many data mapping, data synchronization, and data modeling issues

• *

  reusable design with well-defined extension mechanisms and model correctness being proven through industry validation and acceptance.

BENEFITS FOR AUTOMATED LABORATORIES

The experience has shown that OO Frameworks developed for semiconductor industries are very flexible and provide a very simple and comfortable tool to solve every day changing IT problems. The analogies in laboratory automation are same. The only difference between the frameworks for laboratory automation and semiconductor industries can be the bill of material which can be handled easily with the Material Management Component as the base classes will not change but additionally new classes will be added. The Process Job Management Component takes care of the whole process flow and has an integrated class which takes care of the dynamic scheduling. The Machine Management and Event Management component require no change at all because the event handling mechanism is coupled directly with machine events, which naturally can be defined easily as required. The Event Management components takes care of synchronization and inter component event handling mechanism on one side on the other side listens to the MES or PPS systems. The Machine Management component allows to create a new machine along with all it's characteristics in the real world so that the system integrator has to only know about his machine exactly. All these components put together in different configurations resulted into different process controllers which communicate with each other and with MES or PPS systems, so that no more automated islands exist.

Do not re-invent the wheel again and make use of existing technologies. Therefore Fraunhofer-IPA recommends to shift the paradigm towards innovative IT-solutions, which have been developed and proven in other industries over the past eight years.