Modelling Heterogeneous CIM -Interfaceswith ODP

O. HERMANNS*C. POPIEN*

Abstract

Industrial office application systems represent a typical example oftheproblems encountered when building distributed applications wirhheterogeneous systems. In this context we introduce a concept tor anintegrating infrastructurefor Computer Integrated Manufacturing (CIM)based on the reference modelfor Open Pistributed Processing (ODP).

This paper discusses the matching of interfaces between inter-operating applications. This is realized by the extensive use of theODP-Trader.In order to manage heterogeneous interfaces it is necessaryto study the type manager ofthe Trader. We propose a HeterogeneousType Manager (HTM) in order to support open CIM structures. Thebasic idea of this HTM is the creation of a transformation functionbased on the theory of abstract data types. A~ interface is consideredas an algebrawhich is mappedonto its correspondingsignature.Thetype manager performs this mappingtor both the importer and exporterinterfaces and tries to find a relation between both signatures. Theresult of the type manager analysis is a transformation function whichenables a mapping from the importer to the exporter interface.

1 Introduction

~ ComputerIntegratedManufacturing(CIM)aims at the integrationof distributedcomputer aided systems in industrial applications. While this is easily stated, adecade of experiences from research and field installations shows that the aim hasnot been reached yet. One of the numerous problems ~ncountered in CIM is thehigh degree of heterogeneity of computer aided application systems and product

This work was supported by the Deutsche Forschungsgemeinschaft under Grant Na 134/5-1and title SUKITS.*RWTH Aachen, Lehrstuhl fur Informatik IV, Ahornst. 55, D-52074. e-mail: popienloli@informatik. rwth-aachen. deJournal of Information Science and Technology, Vol. 3, No. 1, Ocl. 1993.ISSN 0971-1988 @ 1993, ICCPI. Published by Tata McGraw-Hill.

?

36 Hennanns and Popien

data models. As a result, many application systems are unable to interoperate. Olleapproach to cope with this heterogeneity is the bottom-up integration of existingheterogeneous systems by provision of an integrating infrastructure(CIM-framework)for distributed computing [22].

While the general nation of CIM usuaIly comprises the whole enterprise, wewant to limit our discussion to engineering design environments. Here, alt productdesign and process planning activities are performed. Highly specialized computeraided application systems, like CAD (Computer Aided Design) or NC-programmingsystems, are used 10support professionals (designers, engineers, NC-programmers,etc.) who cooperate to create the docunrents (design drawings, NC programs,etc.) needed for manufacturing. The design process is characterized by a highdegree of complexity: documents depend upon each other, Olle single documentmay be manipulated by different people using different application systems,documents may be processed on remote systems, information is retrieved fromremote resources, eie.

Frameworks provide an approach to modeIling as weIl as basic services for the...........integration of heterogeneous application systems. Typical examples of frameworhare the CIM-OSA project [17] or the ODP standardization [5]. The basic servicessupport data and communication integration. Data integration provides the meansfor the management and storage of information (design drawings, NC-documents,process plans or associated management information) which is relevant für theintegration between different application systems. Communication integration isconcemed with the open exchange of information and a transparent interconneetionof the distributed application systems.

This paper will detail upon a specific aspectof communication integration inengineering environments. An approach für the transparent usage of remote servicesaccessed at CIM-Interfaces is presented. Examples of such services are simulationprograms (used to analyze the product, e.g. by the method of finite elements),conversion processors (used to trans form documents between proprietaryrepresentations and standardized product data models) or just output devices.TraditionaIly, the access to remote service was enabled by opening interfacespeeifications and by standardization. Unfortunately the standardization process istime consuming and standardized interfaces are hard to extend with new functionalitywithout circumnavigating the standard. In contrast, within the ODP standardization,a generalmodelof accessto remoteservicesis defined.The incorporationof these~

concepts iota a CIM-frameworkpromises to support a rapid generic and configurableintegration of heterogeneous distributed systems.

ODP was developed as an extension of Open Systems Interconnection [14] toreduce the complexity of computer networks and distributed information systems.The standardization of ODP is düne by both ISO (ISO/IEC JTCI/SC21/WG7) [5,23] and CCITT (Study Group VII) [6] in order to develop a reference model fürthe support of open distributed applications.

The second seetion of this paper examines distributed applications in engineeringenvironments and introduces an integrating infrastructure. It has been designed tosupport (he usage of rernote services (provided a( service interfaces) in importer/exporter configurations. In ODP, interface management is dolle by theOD? trader.

Modelling Heterogeneous CIM-Interfaces with ODP 37

The third section introduces some basic ODP concepts and presents the internaistructure of the trader and analyzes the interworking of different trader components.In order to manage heterogeneous interfaces it is necessary to study the typemanager of the trader. We propose a heterogeneous type manager in section Courin order to support open CIM structures. The basic idea of the heterogeneous typemanager is the creation of a transformation function based on the theory of abstractdata types. An interface is considered as an algebra which is mapped onto itscorresponding signature. The type manager performs this mapping for both theimporter and exporter interfaces and tries to find a relation between both thesignatures. The result of the type manager analysis is a transformation functionwhich enables a mapping from the importer to the exporter interface. Finally ibisapproach and the possibility of its implementation are discussed.

2 Integration of Distributed Systems

As introduced in Sec. 1, the integration of heterogeneous distributed applicationsystems in engineering environments may be supported by frameworks [22].Modelling is central to this approach. In order to achieve a complete description,the environment is modelled from different viewpoints, each using specific formaltechniques. ODP, for example, identifies five different viewpoints: Enterprise,Information, Computation, Engineering and Technology viewpoint [21]. Each leadsto an abstraction of the environment which emphasizes certain characteristics whileignoring the rest. The general modelling process of engineering environments leadsto a prescriptive architectural model of an integrating infrastructure presented inthe next section. For the modelling of CIM-Interfaces in the context ofcommunication integration, the computation and engineering viewpoint are mostpromising.

2.1 An Integrating Infrastructure

Oll approach proposes a framework for the integration of heterogeneous applicationsystems in engineering environments, which we call an integrating infrastructure[22, 18]. Its supports data integration by an entity called the CIM Manager andcommunication integration by a standardized protocol architecture and services fordistributed processing (cf. Fig. 1).

The CIM-Manager provides an uniform view of all product related informationwithin the integrated environment While the actual documents are stored in theapplication systems, the CIM-Manager maintains a set of descriptive data (statusinformation, location, ownership, versions, etc.) associated with each documentThe data is used to control the document flow through the environment and theconsistency of existing copies. User access to documents always involves the CIM-Manager. Thus, data integration is reached by the provision of a logically centralizedview of the distributedly stored information within the environment.

Communication integration copes with the physical distribution and hetero-geneity of the application systems in the integrated environment. The communicationservices support transparent inter-application and application-to-CIM-Manager dalaexchange. The protocol architecture supports the integration of weil established

- - - - - - -~ -----

38 Hermarms and Popien

Flg.l lntegrating CIM infrastructure

communication systems. Uniformity is reached by the use of standardized protocolprofiles. The design encloses several weil established LAN and transport layerstandards fOTthe lower layers of the ISO/OSI reference model [14] and uses astandardized transport service as a basis fOTuniform upper layer protocols [7]. The ~application oriented communication services provided by the infrastructure are:

. Electronic mai/, to allow the exchange of structured messages between co-operating users.. File transfer, to allow the exchange of documents between the applicationsystem.

. Data access, 10 enable access to distributed information stores (e.g. theCIM-Manager) [8].. Directory, to support transparent naming and addressing of remote systems,servicesand users [15].

Modelling Heterogeneous ClM-Interfaces wich GD? 39

These services together with a fIXedapplication program interface enable userswithin the engineering environment to retrieve and exchange informationtransparently. For a further support of distributed applications, a dedicated interfacemanages the transparent usage of remote services in the environment This interfacemanager (the Trader) provides a relation between the exported server operationsand the arguments importing applicationsystems (users). To increase the adaptabilityand flexibility, a generic mechanism is foreseen thai enables the dynamic bindingbetween users and servers.

We assume an extended client-server model of interaction [24]. A serverapplication entity exports a service as an operation with weIl defined semanticsand calling syntax. It reports this information to a central instance called theTrader. The Trader is responsible für the interface matehing between serviceexporters and users. An application interface (e.g. a CAD program) which is seekingtor some service (e.g. converter) takes the role of a service user. Therefore it requeststhe servers locality and operation syntax from the Trader. The Trader provides aD1appingfunction tor operations and associated parameters. With ibis information,

~ user can bind to the server and use the service by the invocation of operations.The technical fundamentals of this concept will be introduced in Sec. 3.

2.2 CAD as an Example of Open Distributed Processing

Computer Aided Design (CAD) is an application für which open distributedprocessing is most promising. Since the design process is a central task in engineeringdesign, CAD systems playa central role within engineering environments. We Candistinguish two separate scenarios: interworking between different CAD systemsand interworking between a CAD system and another engineering application. Thefirst scenariomight enable a so calledjoint design where several designers at differentplaces work on Olledesign sheet simultaneously [2]. The second scenario supportsthe usage of specific functionalities provided in CAD systems by other applicationsystems (e.g. graphical functions, format conversions, simulation processes or justfile operations). In any case an interface matching between the systems involvedin this process is necessary. This task can be supported by the interface managementcomponent of the CIM-Manager.

Conceptionally, we can view a CAD system as having a hierarchical modulararchitecture. The basic module is a database, on the next level we find a graphical

--ernel system and on the top level a graphical manipulation toolbox augmented#ith additional functionalities like simulation and conversion. The modules areaccessible via their functional interfaces. The data base interface provides datamanipulation operations, the graphical kernel interface exports procedural operationson graphie primitives while the toolbox exports user operation of arbitrarycomplexity. These interfaces are usually not standardized and differ from systemto system. In the following sections, we will introduce a concept to matchheterogeneous interfaces of ibis kind.

3 Modelling Distributed Systems with ODP

Open Distributed Processing (ODP) as an extension of Open Systems Interconnection

~-~- -- -~-

40 Hermanns and Popien

(OS I) is an attempt to model integrated distributed environments. Massivestandardizatioil work formulates the new ideas [9]. ODP intends in reducing thegrowing complexity of information systems and computer networks by regardingthem from the five viewpoints introduced in Sec. 2. So rar, the Reference Model(RM) of Open Distributed Processing consists of Courdifferent parts (Overviewand Guide to use [13], Prescriptive MoUel [9], Descriptive Model [10] andArchitectural Semantics [11]. Besides language models fOTthe five Viewpoints, itcontains definitions of so-called Common Functions. Olle of these CommonFunctions is the Trading Function, whose functionality can be compared with thaiof the OSI Directory [26].

Object orientation is a central notion in ODP [20, 19]. It is used mainly in theComputational Viewpoint. Each computer component as weIl as distributed systemsor parts of systems can be considered as objects [1,25]. A set of formallanguagesis defined for specifications of ODP functions in each of the viewpoints. Bachlanguage includes an abstraction of each of the other languages so thai the mutualconsistency of the specification in different languages can be verified. The ter~of each language and the mIes applying to the use of those terms are defin,--through object modelling techniques.

An abstract object, or an object fOTshort, is a functional entity. By focusing onthe behaviour of the object an abstraction is achieved. The behaviour of the objectis described in terms of the object interactions. All objects interact in the same waythrough interfaces called ports. An object may be accessed at a port. Ports may beof two types-symmetrical and asymmetrical-which determine the kinds ofinteractions they enable.

A port type is ca11edsymmetrical if a11instances of the port are identical. It isca11edasymmetrical, if each instance of the port is either a supplier or a consumer.Two objects can be bound by an abstractbind operation if they have either symmetrieports or Olleport is supplier and the other is consumer. The reverse operation iscaIled an abstract unbind operation.

An object can define a set of services thai is offered to consumers. In otherwords, an abstract service or service is the set of capabilities thai Olleobject offersby means of Olleor more of its ports. The former object is called abstract serviceprovider or provider, the lauer abstract service user or user. An abstract servicemay have any number of users and providers.

In order to realize the access from Olle object to another, it is necessary t~manage the binding betweenports. This process is.called interfacematching. Interfalmatching manages ,the ability of objects to export or import services. Thecorresponding object which organizes this process is called the GD? Trader. Thetrading function is a set of operations thai support the manipulations of a given setof service offers. Conceptually, the trader itself is an object which can access andmanipulate a given trading information domain using trading interfaces.

A user may import from more than Olle trader. It can be associated with a setof traders and be a client of each trader if it knows the syntax and semantics ofthe interfaces of each trader [12]. Another possibility for a user to communicatewith a set of traders is a Federation of Traders. Federated traders are a configurationof more than Olle trader whose enterprise policy permits Olle trader to access the

Modelling Helerogeneous CIM-Interfaces wilh ODP 41

service offers of the other traders. In such a trader federation, each trader is amember of the trading enterprise domain of each of the federated traders, i.e. eachtrader takes the role of an importer and/or exporter with respect to the othertraders. A trader federation is established by the trading administrator according tothe trading policies of the involved traders.

If a trader needs a service of another trader component, it has to make a federationcontract with this trader (nothing can force a trader component to join a contract).After establishing a federation contract, the service in question can be used, untilOlleof the contract partners wishes to end it Such a federation hag advantages: itallows a trader to organize its enlarged information trading domain by a collectionof domains and subdomains visible from itself and other traders; it provides accesscontrol and accounting in operations executed at remote traders, performed on thebasis of the end-user as the dient. Federation allows traders to negotiate the interfacetypes which are permitted to pass between them and to advise on the availabilityof instances of these interface types in order to reduce unnecessary access via the

~deration. .

OUTproposed structure of the ODP trader is shown in Fig. 2. A user accessesthe trader via a Trader User Agent (TUA). The TUA is connected to the TraderService Agent (TSA), that serves user requests. First, the TSA tries to salve therequest by forwarding a local request to the directory using a Directory User Agent(DUA). If a request cannot be resolved in the local trading domain, it is forwardedto all TSAs in the federation, the local TSA is involved.

If still no solution has been found, the Directory will be requested again to lookfür the service, but this time in a more extended part of the complete namespace.

FederationServiceControl

Directory User Agent

Fig.2 Overall structure 01a trader as part 01alederation

---- ~~

42 Hennanns and Popien

Note that the TSAs are nodes of a graph (Trader Federation Graph-TFG). DSAand TSA are standing in a I : I-relation, although neighbours in the TFG are notnecessarily neighbours in the Directory information Tree (DI1). A DSA may decideautonomously, how to extend the search area, since it is orten not sensible tosearch in the whole namespac~. This might span many different locations. Forexample, if Ollewishes to prior an article, Olledoes not want to use a printer inanother building.

In the process structure, only the trader and the DUA are analysed. A tradercomponent process consists of a TSA and a DUA. The TSA proc~ss itself isdivided in a Trader Request Control (TRC) process and a Federation Control (FC)process. The first hag to receive user requests and transform them into federationrequests. Orten, operations are to be performed in many domains. Since the FCprocess only solves requests für Olledomain, multiple requests are necessary to beforwarded by the TRC process. The communication with the federated tradercomponents is performed by the FC process via the Federation Contract Port (FCP)and the Federation Service Port (FSP). The port of the FC process leads to a Typ-...Manager, which is likely to be colocated wirb the trader component. The TSA c-th~ other side is connected to a (Iocal) DUA, which represents the interface to theDirectory Information Base (DIB). The internal structure of the DIB is apart ofthe x.SOO-Recommendation.

Refining the FC process, we find a Federation Service Control (FSC) processand a Federation Contract Control process. Here, the different Trader operationsappear für the first time in the gates to the FSC process. It is sensible to structuresearch. select and list operations as import operations, analogous export, withdrawand modify as export operations, see Fig. 3. Import operations need access to atype checker, since services found in the federation most be checked to be suitable.The import contract port leads to the federation contract control process where thecorresponding federation contracts für suitable services are made. Export operationson the other hand only need access to the federation contract control process inorder to initiale or cancel export contracts.

All data to be exchanged between processes is transmitted in a single data unit.It can be necessary to TUnprocesses in the trader concurrently, für example to useconcurrent federation contract control processes to increase throughput. In thiscase it is mandatory to give an identifier to each process. If a Federation Data Unit

(FDU) is sent to another TSA, the process identifier most also be gent to make SUfy,.that the response finds the fight federation contract control process. If all data aJtransmitted separately, each needs an identifier. Consequently, it is betteT to useframes which contain all data to reduce communication overhead.

While importing services from other traders, it is necessary to check, whethera local service hag the same type as the requested service or is at least of a typesuitable to it. Suitable means, for example, if a parameter of a local service is asupertype of the corresponding parameter of the requested service, there is noproblem to use this local service. On the other hand, there exists a concept in theconfiguration transparency functions, which offers a type checking functionality,the type manager[10].

Modelling Heterogeneous C/M-Interfaces with ODP 43

Fig.3 Internal structure and interfaces of afederation service control

4 Support of Heterogeneous Data Types in the ODP Trader

4.1 Interface Matching and Data Types

To examine the process of interaction and binding especially the data types areconsidered. Algebraic data modelling is a suitable specification technique to describeinterfaces. The following very general model of interface matching is describedaccord~g to [13].

If we have an importer I and an exporter E, the exporter creates an interface xof type Tl>written as x : Tl' Interface x is the behaviour thai can be observed atthe port. E advertises the existence of this interface x fOTexample by exporting to

~the trader interface reference x and type reference Tl> see Fig. 4. After this, the.!mportercreates an interface y of type T2,written as y : T2.So, the importer indicatesit wants to talk to some interface of type T2.I discovers through an import operationfrom the trader that y is an interface reference to an interface of type Tl becauseTl happens to be a subtype of T2. This decision is laken by the type manager. Portbinding between importer and exporter is possible and importer and exporter areundergoing aperiod of interaction.

Considering the standardized type manager in [10] it may support Olle ormany types. In the case of homogeneous interfaces the tasks of the typemanager are unimportant. But considering open distributed systems the opennessimplies heterogeneous data types which exist at interfaces of different systemscomponents.

44 Hennanns and Popien

1.

-..

CJI0"""""""" " ""'" .

,.

,

.

.,

'

.

'

.

'

,

'

,

"

.

'.'

.

""""""""""

.

'

.

'

.

'

..

"

..

'

.

'

..

'

,

'

..

'

.,

.

,..

.

,"

3.

..'", E..~., """"'" ..... ..... ..

Flg.4 Process of il11erface matching between an importer and an exporter

Let us look at the problem from another point of view. To connect a Germantape deck with a German plug with an American power point you need an adapterwhich realizes the interface between both of them. Additionally it is necessary 10have a transformator which transforms 110 V iota 220 V. This is the same problemwhich has to be solved by the type manager: the Heterogeneous Type Manager(HTM) gers an interface description from the impofter (the plug of the tape deck)and an interface description from the expofter (power point), and has to decidewhether the exporter is able to do the job of the importer. Additionally, it has togive a transformation function which corresponds to the adapter/transformator andis a precondition für the exporter/importer communication. The realization of theHTM is düne by an algebraic specification of data types.

There are two possibilities to localities für the HTM. First, it is possible toconsider it as apart of the trader or administrated trader. In this case the HTM canbe seen as apart of the federation import or type checking agent, see Fig. 3. The-----.second possibility is an external realization of the HTM. Then, communication Ü,executed via the Type Checking Port. Both of these cases use the same internalfunctionality of HTM which is explained in the following.

4.2 An Excurse info Foundations of Data Types

Now, same nations of the data type foundations are introduced according 10[16]and [3]. The basic notion of data type is the signature.

. A signature is a pair SIG =<S, OP>. S is a set of safts and OP a familyof sets OP ::: (Op(W,s0wes.,seS.The elements of OP are called operationsymbols.

Modelling HeterogenEous CIM-lnterfaces with ODP 45

This means a signature is a pair which consists of a set of sorts and a set ofoperation symbols, which are determined by a given so-called arity, consisting ofa sequence of sons. To each signature SIG we can construct SIG-algebras byassigning a set to each son and an operation to each operation symbol. The arityof the operation symbol is connected with the SOTtS,the operation symbol maps.. Let be given a signature SIG =<S, OP> and let be given a family of sets

A = (A')seS' We define AE: = {0} (e is the empty sequence) and Aw,s: = Awx A', WE S*, WES. We identify {0} x A' with A'. For each operationsymbol we define an operation FA:Aw -> A'. Then A := ((A')seS; (FA IFE OP}) is called a SIG-algebra. .

r----

In order to define a relation between two different algebras the notion ofhomomorphism is introduced. A function is a homomorphism if the result of adifferent order of two operations is the same.. Let SIG =<S, OP> be a signature, A and B SIG-algebras, h: A -> B a function

with h(AS) ~ (ßS) foT a11SES. hW : Aw -> Bw defines functions by hE:(0)=0 and hW,S(a,a): = (hW(a), h(a)) für a E Aw, a E A' 0 h is a homomorphism

[rom A to B if and only ifh . FA =FB . hw foT a11F E OP(w,s). .

While an algebra is comparable to a concrete data type, a signature can be seenas the syntax of an abstract data type. In order to define a relation between twoalgebras it is necessary to decide whether these two algebras are with the samesignature SIG. Therefore, a mapping function is defined which maps an algebraonto its corresponding specification.. Let be given an algebraA:= ((A')seS; (FA IF E OP})oWe define afunction

fA-> SIG by f(AS)=S,SESandf(FA)= F, FE OPoSIG = <S,OP> is thecorresponding signature to the algebra A. .

The relation between an algebra and its corresponding signature is presented inFig. 5. A more precise variation would consider the Quotient Term Algebra insteadof the specification of Abstract Data Types so that the equations in our approachare included indirectly.

t3 The Functionality of the Heterogeneous Type Manager

The HTM uses the abstract concept of the data structures, described above. Atrader has a directory with.all exponer entries. If the importer asks foTa serviceboth interface descriptions are given to the HTM in order to check a compatibility.The HTM does two things:

. first, he decides whether it is possible to match the interfaces so that a laterpan binding is realizableand

. sccond, he gives a function für the transformation of the importer interfacestructure into an exporter interface structure.

Figure 6 describes the internal processes of the HTM. The imponer interface is

46 Hennanns and Popien

---....

Flg.5 Specification 01Abstract Data Types in relation to Con.creteData Types

seen as an algebra which consists on sets and functions on these sets. A functionfmaps this algebra onto a corresponding signature SIG, according to Fig. 5. In thesame way, there exists a functiongwhich maps the algebra of the exporters interface.It is necessary that the exporters data type happens to be a subtype of the importersdata type. Related to the heterogeneous type manager it hag the task to find afunction h which maps SIGExpinto SIGImpso that h(SIGExp)~ SIGImp.It is outof the scope of this paper to explain several possibilities für finding such a functionh. In the simplest case this is the identical function.

After finding such a function f the HTM examines whether rn := (g . h . rl) {a homomorphism. In the case that it was not possible für the type manager tofind such a function h oe in the case that the function rn'is not a homomorphismthe HTM does not give any possibility für a port binding. Its result is theBoolean value "false". If the function rn is a homomorphism, rn can serve as atransformation function für the heterogeneous data types. The imponer can usethe function rn-I = (g . h .rltl =(f. h-I . g-I) to trans form its interface opera-tions into exporter operations so that a port binding between importer andexporter becomes possible. The importer is able to import the services of theexporter.

Modelling Heterogeneous ClM-Interfaces with ODP 47

Input inta HTM Input inta HTM

Summary and Conclusion

The presented paper has examined an approach 10 support distributed usage ofservices and data types in heterogeneous CIM systems. The problem of interfacematching between heterogeneous service providers and users was reduced by thefunctionalitYJ>fa HTM as apart of the ODP trader. The realization was dOllebyan algebraic methodology within the type manager. An integrating infrastructurefor engineering environments was introduced which incorporates these concepts.The heart of this infrastructure makes up a CIM Manager, which includes the HTMin order to match the interfaces of the various CIM application systems.

This.concept could be used to support the interworking of CAD systems. The~M is used 10 match the graphical kernet interfaces of several different CAD

.>ysrems.Thus it enables the joint usage of Ollekerne~by several distributed designers.

5

REFERENCES

1. Boogards K., A Methodology für the Architectural Design of Open DistributedSystems,PhD Thesis, University ofTwente, June 1990.

2. Ellis C.A., Gibbs S.J., Rein G.L., Groupware, CACM Vol. 34, No. 1.3. EhrigH., Mahr B.,Fundamentalsof AlgebraicSpecificationl, Springer-Verlag,Berlin,

1985.4. Eversheim Weck, Michaeli. Nagl. Spaniol. "The SUKITS-Projekt: An approach to a

posteriori.Integration ofCIM components," submitted to GI Jahrestagung, 1992.5. Griethuysen J.J.v., Open Distributed Processing. Invited Presentation, Protocol

Specifteation Testing. andVerificationlX, North-Holland, 1989.

48 Hemranns and Popien

6. Herbert A. (ed.), Advanced Networked Systems Architecture Reference ManualARM 1.00-Architecture Project Management, Cambridge, March 1989.

7. Hermanns 0., "Migration towards a functional profile fOT industrial networks " ,erscheint, Proc. ofthe EFOC/LAN, 1992.

8. Hermanns 0., "DataAccessProtocols fOTIntegratedEngineering Environments",Proc.of IEEE-COMPEURO con/, Paris, May 1993.

9. ISO/IEC JTCl/SC21 WG7 N315, Basic Reference Model of Open DistributedProcessing-Recommendation x.9yy, Basic Reference Model of Open DistributedProcessing-Part 2: Descriptive Model.

10. ISO/IEC JTCl/SC21/WG7 N432: Basic Reference Model of Open DistributedProcessing- W orking Document-Recommendationx.9zz: Part 3: PrescriptiveModel.

11. ISO/IEC JTCl/SC21/WG7 N434: Basic Reference Model of Open DistributedProcessing- Working Document-Part 4: Architectural Semantics.

12. ISO/IEC JTCl/SC21/WG7 N7047: Information Retrieval, TransferandManagementfor OSI-Working Document on Topic 9.1-ODP Trader.

13. ISO/IEC JTCl/SC21/WG7 N7053: Information Retrieval, Transfer and ManagementforOSI-Working Draft-BasicReference Model ofOpenDistributedProcessing-Part 1: Overview and Guide to Use. ~

14. International Standard 7498 "Information Processing Systems-Open Systel11JInterconnection-Basic Reference Model", 1984.

15. Jakobs K, Hermanns 0., Fichtner M., Using the Directory to support CIM Manage-ment", Proc. ofthe Factory 2000 Conference University ofYork, July 1992.

16. Klaeren H., Algebraische Spezifikation, eine Einfuehrung, Springer-Verlah, BerlinHeidelberg,NewYork,1983.

17. Kosake K., Vlietstra 1., "An Open System Architecture in Computer IntegratedManufacturing: CIM-OSA",Proc. oflFlP WorldCongress, pp 765-770,1989.

18. Kiesel N., Schwartz J., Westfechtel B., Object and process management für theIntegrationofheterogeneous CIM components",Proc. ofGI Jahrestagung, Springer,1992.

19. MeerJ.d.,Bulletinzum 'OpenDistributedProcessing' Workshop, BerEn, 1991.

20. Popien C, System Design Trajectory based on Open Distributed Processing, Proce-edings ofthe 1992 International ZurichSeminaronDigital Communications, Zurich,March 1992, IEEE Catalog No. 92THO439-0, S. 315-332.

21. Popien C., Spaniol 0., de Meer J., Systementwurf mit Open Distributed Processing,Praxis der Informationsverarbeitung und Kommunikation PIK 14, S. 192-201,April 1991.

22. Schwartz J., Westfechtel B., "Integrated Data Management in a Heterogeneous CIMEnvironment",Proc. ofCompEuro, May 1993.

23. Stefani J.B., Open Distributed Processing: The Next Target fOTthe Application op--FDTs, Working paper Centre National d'Etudes des TelCcommunications, France,November 1990.

24. Svoboda L, "The Client/Server Model of Distributed Processing", IFB 95, S. 485,Springer 1985.

25. Vissers CA., Scollo G., Sinderen, M.v., Architecture and Specification Style inFormal Description:; of Distributed Systems, Protoeol Specification, Testing, andVerification VII/, Atlantic City, 1988.

26. ISO/IEC9594-l: IT-OSI-The Directory: Overview of Concepts, Models, andServices, 1992.