Distributed
Object Technology
for Manufacturing Execution Systems
written by : Emmanuel ARNOULD, Dominique JUGNON
Introduction
Product life cycles in the manufacturing environment are usually very long when compared to those of the Information technology industry. Cars for example have a typical life cycle of 10 to 20 years. Airplanes have a much longer one, sometimes stretching over 50 years.
These life cycles are far from those practiced in the computing industry. Currently, a given PC model stays on the market 6 to 24 months, at most ! Many production sites are run on computers built in the 70s. The pace of change of the Information Technology is a major problem for the manufacturing industry : Interoperability of applications and migration of existing applications into new environments are an everyday challenge.
Industry managers have been facing this problem for many years now. Various solutions have been sought with, so far, little effect. A 1993 NIST tender for the electronic industry mentioned the following :
" The MES market is mainly composed of systems that are developed in house. The reason for this is that most production software systems are incompatible in terms of data exchange formats and require carefully crafted custom integration solutions. These solutions are not only expensive, but more importantly, they take a long time to achieve and are highly inflexible.
The commercial MES market is not conductive for third party developers as long as there is no clear model of integration. "
The advance in software standardization in office automation, due in large to the emergence of Microsoft, has enabled massive cost reductions and an real productivity increase for many. Office automation requirements are relatively similar from a company to an other. The difficulty in standardizing software for the manufacturing industry lies in the fact that different manufacturers have usually different requirements.
We will first described some failed attempts at standardising MES software. Then, this paper will show that by standardising at the proper level and by using the state of the art distributed object technology, it is now possible to bring an answer to software standardisation for the manufacturing industry. The APPLI-BUS concepts and implementation mechanisms are described to support this.
This paper distinguishes two main manufacturing application classes :
- ERP (Enterprise Resource Planing)
- MES (Manufacturing Execution Systems)
The rest of the paper addresses only the later, Manufacturing Execution Systems (MES). This class of application covers for instance :
- Production allocation and status,
- Data collection and acquisition,
- Quality management,
- Process management,
- Maintenance management,
- Supervisory systems,
- Statistical control,
Addressing Manufacturing
Lack of a base standard
Users faced with the development of manufacturing application have no base standard on which to start that will ensure that their work will interoperate with other in house or other commercial applications. Using Unix or NT and TCP/IP is NOT a standard application development framework. Most applications developed for manufacturing either rely on a proprietary environment or are monolithic pieces of code highly tied to the target environment. As unfortunate as that may be, application developers in this area have been left with little choice.
User requirements
The user requirements have been expressed in a number of surveys and consortium. They are basically the same as most other market segments. Recently again, a survey of a large European user consortium dedicated to automobile and aerospace industries has identified its top two concerns:
1. Interoperability
2. Migration
Interoperability
Interoperability is the capability of a new application to adapt naturally to the existing environment. It expresses the user concern of being able to share existing data, produced by existing applications, with new applications. For instance, if a user uses a CAD package to design a car body, he would like to be able to use the data generated by the CAD package to feed a car crash simulation package.
Currently, to realise the above, our user most likely will have to develop the interface software to plug the two applications, if possible. Another possibility are that one of the two software vendors will have included the adapter.
Obviously, this is a limiting factor for users to choose the best of breed application to solve a given problem.
Migration
As we have seen previously, it is important for users to be able to integrate seamlessly new applications and new technologies to existing environments. The opposite is true as well. New applications are typically designed with state of the art methods and data models. They don’t necessarily pay enough attention to previously written software. Because of its long product life cycles, the manufacturing industry needs to be able to integrate existing applications and devices into new environments.
The failed attempt of a standard manufacturing protocol
A first attempt at rationalising software for the manufacturing industry has been to try to homogenise the numerous protocols used to communicate with the manufacturing devices.
Everybody in the computing environment is familiar with TCP/IP. Many are also familiar with the ISO communication stack. Both are standard ways of communication between computers. These protocols became standards in the general move of the computer industry toward being a more mature industry. Part of this maturation requires a certain level of rationalization.
Networking is an essential part of computing and has been more and more so for the last ten to twenty years. The cost to the industry for not having a standard way of communicating would be today such that it would limit the usability of computing systems. For instance, one cannot imagine a new general purpose computer that would not have a TCP/IP connection capability.
Because networking has had such a large impact on computing, people in manufacturing have sought to address devices interoperability through a standard manufacturing protocol.
Unfortunately, the manufacturing devices do not represent a mass market such as the general purpose computers market. Manufacturing equipment must communicate within a given factory. But the various factories of the world have little need to communicate. For instance, why would the beer manufacturer Heineken need its manufacturing equipment to inter-operate with the manufacturing equipment of General Motors?
The above fact has left the people conceiving and developing manufacturing equipment with little care about how their equipment will communicate with the rest of the world. It is not a major concern. Usually, equipment device developers will develop their own proprietary protocol. Worse yet, they will typically have one protocol per device that they design. Some major manufacturing equipment vendors have tried to rationalize somewhat their offer. It is nonetheless highly proprietary.
In the early 80’s, General Motors has launched an effort called MAP : Manufacturing Automation Protocol. MAP was an attempt to rationalize, as a user, the numerous manufacturing protocols used in GM’s various production sites. The idea was to use the standard ISO communication stack, with a fixed profile adapted to the manufacturing class of problems. On top of it, GM defined a layer of services called MMS, Manufacturing Message Specification. The bundle, ISO stack plus MMS application service layer is commonly referred to as MMS.
Although GM put all its weight in the battle, MMS is far from being a success. To be able to serve a wide range of problems, MMS requires a powerful computing environment, hardly what is usually found on PLCs or NCs. On top of this, although it can be vary powerful, MMS is a fairly complex protocol to use for the basic protocol requirements that many applications use. MMS is now just yet another protocol, along with all the proprietary protocols.
The fact of the matter is simple : their is no economic justification for a standard communication protocol for manufacturing devices. Everybody agrees that it would be nice but :
- Manufacturing device vendors would open up to their competitors,
- Diffusion of the standard would be almost impossible to achieve,
- History has shown that it is technically difficult,
- There are hundreds of existing protocols on the market,
- There is no need for yet another one.
The middleware approach
While a communication standard in information technology is essential when connecting banks in Tokyo, Paris and Los Angeles, the need to connect manufacturing devices, as explained above, is rather faint. The European CNMA ESPRIT project was started in the mid 80s to exploit the MAP initiative in Europe. It attempted to establish MMS as a standard in Europe as well. CNMA turned into a new ESPRIT project, CCE-CNMA, in the early 90s. CCE-CNMA broke off with the CNMA project as its users did not really care about a standard manufacturing protocol. Their concern was mainly on application interoperability.
CCE-CNMA worked on developing an Integration Platform, called CCE : CIME Computing Environment. It provided a set of services to hide protocols, operating systems and access methods, while allowing the benefit from the new technologies capabilities. A yet broader perspective has been taken by the AIT consortium, started in the mid 90’s.
The Advanced Information Technology for Design and Manufacturing consortium (AIT) is a consortium gathering all the European car (Renault, Mercedes-Benz, ...) and aerospace vendors (A�rospatiale, Dassault, DASA, ...), plus a few equipment suppliers (Bosch, Siemens Automation, ...).
The AIT consortium has been created to address the problem of software application development for design and manufacturing. In the past, these users have been mainly driven by computer vendors with proprietary offers. For the last five to ten years, this situation has greatly changed, in particular with the arrival of the PC , the networking environment and more recently, Internet.
AIT is developing an Integration Platform, or middleware, for its upcoming application development.
AIT has endorsed the OMG-CORBA standard has the technological foundation for its works.
Middleware and the Object Technology
A middleware is a layer of software that sits between the operating system and the application, hides the complexities of operating systems, hardware platforms, and network protocols, allowing developers to focus on their applications. It provides distributed computing services through a simple application programming interface (API). The purpose of a middleware is :
Radically improves programming productivity
Shrinks project costs and schedules
Minimizes risk by reducing scope of effort
Builds competitive advantage
Supports open, flexible systems
Enables enterprise-wide applications to work together seamlessly
Results in completely portable applications
Dramatically reduces the level of expertise required to develop and maintain distributed applications
By using the power of the distributed object technology, a middleware approach does finally address the concerns of software for the manufacturing industry. The Object Request Broker, ORB, is the basic element of a distributed object computing (DOC) based platform.
The (ORB) is the middleware that establishes the client-server relationships between objects. Using an ORB, a client can transparently invoke a method on a server object, which can be on the same machine or across a network. The ORB intercepts the call and is responsible for finding an object that can implement the request, pass it the parameters, invoke its method, and return the results. The client does not have to be aware of where the object is located, its programming language, its operating system, or any other system aspects that are not part of an object's interface. In so doing, the ORB provides interoperability between applications on different machines in heterogeneous distributed environments and seamlessly interconnects multiple object systems.
The object technology is based on a standard called CORBA, from the OMG.
With a membership of over 700 software vendors, software developers and end users, OMG is developing "The Architecture for a Connected World." Established in 1989, OMG's mission is to promote the theory and practice of object technology for the development of distributed computing systems. The goal is to provide a common architectural framework for object oriented applications based on widely available interface specifications
The Common Object Request Broker Architecture (CORBA), is the Object Management Group's answer to the need for interoperability among the rapidly proliferating number of hardware and software products available today. Simply stated, CORBA allows applications to communicate with one another no matter where they are located or who has designed them. CORBA 1.1 was introduced in 1991 by Object Management Group (OMG) and defined the Interface Definition Language (IDL) and the Application Programming Interfaces (API) that enable client/server object interaction within a specific implementation of an Object Request Broker (ORB). CORBA 2.0, adopted in December of 1994, defines true interoperability by specifying how ORBs from different vendors can interoperate.
The object technology represents a real breakthrough to address the MES market. It adequately answers the major concerns related to interoperability and migration :
Interoperability
The CORBA 2.0 specification, adopted in 1994, created true out-of-the-box interoperability in heterogeneous environments and delivers this interoperability over the Internet through IIOP -- the Internet Inter-ORB Protocol.
When a client program built with ORB vendor B's product needs to talk to an object in a server built with ORB vendor A's product, the client program opens a TCP/IP connection to the server, and sends one or more IIOP requests to the server. The ORB component linked into the server locates or activates the object specified in the request and invokes the appropriate method on the object. The fact that the object is not built with the same ORB product is invisible to the client.
One of the most important aspects of CORBA/IIOP is its platform independence. CORBA ORBs interoperate without regard to vendor origin making CORBA/IIOP the truly ideal solution for application interoperability, in particular over Internet. This platform independence allows businesses to take advantage of the Internet without having to rebuild systems and networking hardware and software or forcing them to commit to a single vendor solution. CORBA/IIOP allows most every system that is now in operation to be incorporated with comparatively minor modifications so that a business's installed base, even if it is made up of equipment and software packages from a variety of vendors, will be able to integrate seamlessly.
Migration
A basic property of the CORBA based technology is the encapsulation capability. Encapsulation allows any existing application to be inserted in a " wrapper " to use it in a CORBA environment. This wrapper is developed on top of the existing application, without any change to the application code. It only requires to know the application access method.
Using encapsulation, new applications can communicate with older ones without having to know their internal behaviour in a distributed object computing environment.
APPLIBUS : a CORBA based MES
APPLI-BUS is a distributed object based middleware, conforming to the OMG-CORBA 2 specification. APPLI-BUS is designed to ease the development and integration of manufacturing applications in a distributed heterogeneous environment. APPLI-BUS frees the applications from any dependency toward manufacturing devices, networks, operating systems and machines used by the applications. It allows an independent evolution of the application, on one hand, and the underlying infrastructure, on the other hand.
Therefore, the final choice of the computing environment (machine type, operating system, network, ....) can be postponed to the very last moment. Furthermore, the environment may vary with no change to the application code. For instance, machines may be upgraded, manufacturing devices may be changed, ....
Infrastructure modifications are done by changing the configuration of APPLI-BUS, without the need to recompile any code. This is specially useful during the integration process, in particular on manufacturing sites.
Figure 1 APPLI-BUS
APPLI-BUS uses two main concepts : the Protocol and the Service
- the Protocol, to access the real objects,
- the Service, to perform processing on the objects.
Applications running on top of APPLI-BUS are using APPLI-BUS objects. Several applications can use simultaneously any given object.
APPLI-BUS components
APPLI-BUS is made of a number of components that run in one or more processes. These processes are running on one or more computers, in an heterogeneous distributed environment. They form the Integration Platform.
APPLI-BUS components are all software components. The APPLI-BUS components are :
AccessServer : the heart of APPLI-BUS ; it is the applications service provider.
AccessDriver : allows the access to the real objects.
ProcessingService : allows various processing on objects.
NameServer : naming service to localise the objects.
APPLI-BUS Programming Classes - APC - : the set of C++ classes to easily develop the client applications.
APPLI-BUS Corba Interface - ACI - : OMG-IDL language interface IDL - to develop client applications.
Client applications : applications using the APPLI-BUS services, written using either the APC interface or the ACI interface.
Figure 2 APPLI-BUS components
It is APPLI-BUS’ heart. It provides a standard transparent access to the objects, regardless of their location. Extra processing may be done on these objects before passing them on to the client applications.
The AccessServer receives requests (read, write, ...) from the client applications and returns the corresponding answers. It can also send unsollicited notifications to the applications (provided that the application has subscribed to the notification). A notification is an event generated by an object.
Access to the devices is done using AccessDriver components. Extra processing can be done using ProcessingService components. These components can be dynamically added to an AccessServer.
Each APPLI-BUS object (Variable, Device, ...) is managed by one and only one AccessServer.
The AccessServer has 4 roles :
handle the client application request that concerns it
pass the other client application requests to the approriate AccessDriver and ProcessingService components, for the objects of the request (any given request may concern several objects)
if an object emits an event, pass the corresponding notification to those client applications that have subscribed to the notification
appropriately poll the objects that are not able to generate events themselves and generate the appropriate notifications. This is important as most manufacturing devices are not capable of generating events.
There is no limit to the number of AccessServer components in a system. Several AccessServer may reside on the same machine.
Configuration file
Each AccessServer has a configuration file that describes the objects it manages. It provides the name and information necessary for each object. During the init phase, the AccessServer constructs all the needed objects according to the information present in this file.
The AccessDriver implements the data access protocols. Data may be :
variables on manufacturing devices (PLCs, Numerical controllers, robots, ...)
devices
computer data (files, data coming from another application, databases, ...)
Each AccessDriver is associated to one and only one AccessServer. It is connected to the AccessServer through the Protocol Plug Interface, PPI. The AccessDrivers are referenced in the corresponding AccessServer configuration file.
There is no limit to the number of AccessDriver that an AccessServer can support.
The ProcessingService components are used to add some processing to the objects managed by an AccessServer. This is very useful when optimising the overall system performance to benefit from the locality of some objects. Examples of ProcessingServices are :
scaling
averaging, mobile averaging, trending
filtering, thresholding, event generation
file storage
object archiving in a data base
business objects
Each ProcessingService is attached to one and only one AccessServer. It connects to the AccessServer through the Service Plug Interface, SPI. The ProcessingService components are referenced in the corresponding AccessServer configuration file.
There is no limit to the number of ProcessingService components that an AccessServer can support.
In fact, ProcessingService components are a certain type of client applications with the following properties :
higher performances due to local processing
processing factorisation. The results of a ProcessingService component are available to all client applications and all other ProcessingService components
capability to generate events
capability to receive requests from an AccessServer component
The NameServer component contains the list of all the APPLI-BUS objects in a distributed environment. Each object has a type and a localisation. During init, an AccessServer registers to the NameServer for the objects that it manages. The NameServer component answers to requests by returning the name of the AccessServer in charge of the object requested.
The NameServer component supports requests with the metacharacters * (zero or more characters) and ? (single character).
APPLI-BUS Programming Classes - APC -
This component provides a C++ interface to access the APPLI-BUS services. It allows the access to a set of APPLI-BUS objects spread in various AccessServer components, with a single request. It is implemented in the client library which is linked with the client application.
The APC classes allow the very fast development of client applications by focusing on the objects and their semantic, regardless of any access method or communication constraints of a distributed environment. APC uses a cache mechanism to store the name of the AccessServer components in charge of the accessed objects. Therefore, it is required to access the NameServer component only once to get an AccessServer component localisation.
Should an AccessServer disapear from the system, APC is automatically informed and invalidates its cache entries for the objects managed by that AccessServer component.
It is the component written by the APPLI-BUS user for the user application. Client applications may be developed one of two ways :
using the IDL interface. The application may be developed in any language supported by the ORB. It requires an IDL compiler for the selected language.
using the APC classes. APC classes offer a C++ interface.
Conclusion
This paper shows that the OMG-CORBA standard allows the implementation of software that addresses the major concerns of the manufacturing industry, interoperability and migration. These implementations will give a major boost to this market segment : they will allow a wider diffusion of high class applications that can be developed regardless of the final target environment. This represents a major breakthrough for the manufacturing industry. It is a similar move by Microsoft, some years ago, that has allowed a rationalisation of the office automation software.
Interesting web pages
AIT web site : http://www.ait.org.uk/
CORBA success stories : http://www.corba.org/csstory.htm
The CORBA FAQ : http://www.cerfnet.com/~mpcline/corba-faq
An article comparing CORBA/IIOP and ActiveX : http://www.omg.org/news/activex.htm
