- Email: [email protected]
Interoperability: An Overview
Copyright (:I IFAC Intelligent Components and Instruments for Control Applications, Annecy, France, 1997
INTEROPERABILITY : AN OVERVIEW
J.P. Thomesse
CRlN-CNRS ENSEM-INPL 2 avenue de la foret de haye 54516 Vandreuvre les Nancy. France Fax 03 83 44 0763 E-mail thomesse@loriajr
Abstract : This paper presents an overview on the interoperability, specially between sensors, actuators and fieldbus. The reasons for non interoperability are analyzed. Two main problems are studied: how to build interoperable equipments ot systems, and how to test, to verify, or to prove the interoperability. The methods, the solutions, or the approaches, to build or to verify the interoperability are described. After some defmitions pulled out of the standards or of testing organisations, the global interoperability is decomposed into four partial ones,which are relevant of services, of protocols aspects including the coding (syntax and semantics) of data or exchanged objects, of resources necessary to manage the communication and the cooperation between application processes, and of temporal aspects in the behaviour of the communication and processes. Giving some examples of possible verification without puting all the equipments on a testing platform, we show the interest of the verification regarding the test approach. Keywords : Interoperability, test, services, protocols, performances, companion standards, fieldbus .
1.
long time. But it achieves success with the defmition of the OSI model (Zimmermann, 1980) by ISO at the beginning of the eighties, making easier the heterogeneous systems implementation. Heterogeneity, here is the keyword, is at the source of a lot of problems. The automation systems are more and more complex, based on equipments from different vendors, specially when sensors, actuators, field devices are considered. The word interoperability is more recent, essentially with the networks development, (Bonnes, 1988), but other domains are also concerned (software, data bases, operating systems). Interoperability is a property of several equipments to "work" together for a given goal, or the property of an equipment to work with an existing system (a set of equipments). The emergence of standards (de facto and de jure) makes easier the interoperability of equipments conform to a given standard. But that's not a
INTRODUCTION
This paper deals with interoperability which is the basic property required for equipments to build a system. The first part is concerned with an analysis of this property, the second one with the methods to obtain and test or verify it. This paper contains then firstly a general problem statement and also an overview of solutions or a state of the art based on works which have been developped in our team. Interoperability, openness, two words more and more used as well by vendors of automation components as by their end-users ; by the first one, as property of their equipements and systems, by the second one as requirements or as problems. The word openness is not recent. In computer science, the compatibility problems does exist for a
433
complete guarantee. Why ? How to do to solve the problem ? How to be sure that equipments will be interoperable ? And what is formally the interoperability ? This paper tries to answer these questions, specially in the automation systems built with a fieldbus. In the flrst section we will place the notions of equipment, system, communication and application architectures, services or protocols specifications and standards in reference to each other. The interoperability general problem is not only related to communication mechanisms but also to the application specification and implementation. It is then useful to have, at flrst, a common understanding of all these concepts. They will be illustrated by exemples taken in the instrumentation area The second section entitled "Interoperabilities" will summarize their different deflnitions given by standardization bodies and conformance testing organizations. Regarding layered structures, the following kind of interoperabilities will be introduced: the layer interoperability, the proflle one, the communication one, the application interoperability sometimes called interworking which include a lot of properties. But the communication aspects will be of major interest in the following. Therefore, another classification of interoperabilities will be proposed in the third section, starting from an analysis of the non interoperability reasons. They are related to incompatibilities between the available services, or to differences in the protocols implementations even if they are conformable to a standard. Other reasons as the lack of resources, or as temporal behaviours may be also at the source of interoperability problems. We will conclude this section with an analysis of the interoperabilities regarding their application dependence or independence. Let us now analyze how this problem may be solved. Two complementary approaches must be used. The first one is called "interoperability building", the second "interoperability testing". They occur at different stages of an application development. Interoperability building : different operations may be used in order to make compatible different equipments in a system. This approach is described in the section four. Interoperability testing : usually, the interoperability testing is issued from the experiences in conformance testing. But it makes a complete abstraction of the application dependent aspects. And that is how interoperability problems may be discovered at a late stage in the application integration. Therefore we propose another approach in order to minimize or to reduce such phenomena. The question is whether it is possible to prove or to verify the interoperability of equipments in a system for a given application. Models are then necessary ; models of the application architecture, of the support architecture (processors and networks), and models of the application processes distribution on the equipments. We developped for some years such models and
verification systems, which will be presented in the last section of this paper. 2. PRELIMINARY DEFINITIONS The following notions will be defined in order to have a common understanding when speaking about different interoperabilities and the reasons for non interoperability .
2.1. Systems and equipments Interoperability is a property of several equipments to "work" together for a given goal. Or interoperability is the property of an equipment to work with an existing system (a set of equipment). What is an equipment ? What is a system ? An equipment is any station connected to the network and the able to exchange data with each other. A system is a set of equipments connected to a network. . We consider in this paper that the interoperability problems are related to the communication or connection mechanisms between different equipments .. A sensor is an equipment, a PLC is another equipment regarding a fieldbus, but it is a system regarding the internal bus connecting the boards, which are then equipments. At this level, such informal relations examples should be defined : IOPl(El, E2, .... , En, Corn) to express that all the Ei are interoperable with the communication system Corn or IOP2(Ei, SI) to express that the equipment Ei is interoperable with the system SI including a communication system. 2.2. Layered communication architecture Any equipment is supposed having a communication system architectured according to a layered structure as the OSI model, without regarding in detail the layers number, the services and protocols. 2.3.
Specifications and standards
Service specification. A service specification defmes the services provided by a layer, indepedently of the protocols which may realize the service. Such a specification may be a standard. All the services of a standard are not always necessary for a given equipment. Subsets of the services called "conformance classes" may be standardized. Protocol stecification. A protocol speciflcation defmes the PDUs (Protocol Data Unit) exchanged between the layer entities and the rules to carry on them. Companion standard. A companion standard is an element of the application layer which explains the objects and the services of an ASE (Application Service Element) in a restricted domain, for some kind of device, of application, and so on. Network Management standard. A network management standard specifies how an equipment or a network must be configured, maintained, observed. Application specification . An appl ication specification is a definition, formal or not of the application distributed around the considered network.
434
2.4.
The interoperability related to the services is the property of equipments to provide the required serv ices . Knowing the conformance classes implemented in each equipment, it is not to difficult to test if all the equiments of an application are interoperable or not.
Implementation
We call here implementation all the operations of design, realization, programming, wiring, to build an equipment. An equipment is the result of implementation of communication standards and of a part of the application specification.
4.2. Interoperability related to protocols
2.5. Conformance and performance testing
The interoperability related to the protocols is defined by the capability of all the equipments having to exchange PDUs to respect exactly the same rules. That means that all the options, all the parameters in the implementations must be compatible.
Conformance testing. The conformance testing defined by ISO (1988) concerns only the implementation of the communication layers. The conformance is tested layer by layer, or if impossible, the complete profile implementation is globally tested. Performance testing. The performance testing has an objective, to measure the capabilities of an implementation, in term of resources, of time behaviour, of connections maximum number, and so on.
4.3. Interoperability related to resources Each communication between two or more equipments require resources in memory. MMS for examples supposes an opening of connection and then a memory allocation in each equipment. WorldFIP (Thomesse, 1994) or CAN (Paret, 1996) require the availability of buffers to store the exchanged data. The interoperability related to the resources is defined by the capability of the equipments to offer the required resources.
3. INTEROPERABILITIES This section defmes the usual interoperabilities. 3.1. Layer interoperab ility. Two or more N-Iayers are said Layer-interoperable if the conformance test results are successful and if it has been shown that they realize the N-service defmed in the standard and required by the profile. 3.2. Profile interoperability. Two or more equipments are said Profileinteroperable if their layers are layer-interoperable. Gadre (1990) distinguishes the theoretical (by proof) and demonstrable (by test) interoperabilities for the previous ones. This criterion takes into account the methods to verify interoperabilities, as they will detail in the two last sections.
4.4. Interoperability related to ttmeliness Considering a MAC protocol using a token mechanism, an equipment must answer in a given delay after the token receipt. The interoperability related to temporal aspects is the property of all the equipments to meet all the delays defined in a given profile. 4.5. Application dependant interoperability Communication interoperability and application interoperabilities are often distinguished. This classification is not so obvious. The application needs cannot be forgotten in communication considerations. Let us take some examples. A sensor is conform to a communication profile, but according to a subset of services. This sensor may be interoperable with other equipments for a given application and not for another one which needed other services. A PLC supporting MMS services is able to manage a maximum of five simultaneous connections. It may be interoperable with equipments for an application which don't requ ire more than five connections, but not for another which needs more. Three kinds of interoperability may be then defmed : the interoperability of communication systems independently of the application, the interoperability of commun ication systems which is application dependant and the interoperability of application strictly speaking (also called interworking) which depends on its specification and its programming.
4.NON-INTEROPERABILITY REASONS In this section, we will introduce why equipments which achieve conformance testing with success, may be not interoperable. The reasons come from services unavailability, from different options in the protocol implementation, from time behaviour incompatibilities or from lack of resources (memory, ...). Some of non interoperability reasons are only dependent on communication characteristics, other are dependent on the application. That means that an equipement may be interoperable with a system for a given application and not for another one. These criteria have been identified and explained by Benkhellat (1992; 1995). 4.1. lnteroperability related to the services Let us take an example. Considering a distributed application built using the MMS ASE (Manufacturing Message Specification) (ISO, 1990), the equipments are then in relation according to the client-server model. The interoperability of the equipments is conditionned by the availability, for each service used, of request and confirmation primitives located by the client and of indication and response primitives located by the server.
5. INTEROPERABILITY BUILDING This section deals with the ways to obtain interoperability of equipments.
435
"observer" IS m Charge 01 ventymg the contormance of the exchanged PDUs. The same architecture may be used to test the capacities and some performances of the implementations. Active testing. Such an approach (ferry clip) has been used by Zeng (1988; 1989) and Witteman (1993). Rafiq (1990a) proposed another active method. The PDUs are derivated through the tester in order to be able to verify them as in the previous method but also to modify them to test how errors are recovered. Theoretical testing. Castanet and Kone (1993) defmed formally a relation of interoperability and its canonical tester following the works of Brinksma (1988) and Leduc (1991). The implementations are modeled with TIOSM, (Timed Input Output State Machine), a canonical tester is defined, and the evaluation made through the analysis of the global behaviour. The main problem is the number of states in the graph of accessibility, which is very quickly growing and then limits the method applicability. But Kone (1994) proposed the so-called "au-vol" technics which limits the number of states. This approach is also a step towards the a priori verification. This approach cannot cover all the cases, and specially doesn't take into account the specification of a given application. Performance testing. No performance testing method is standardized, as for interoperability. The objective is the identification of capabilities in terms of resources, of time response or more generally of characteristics of timely behaviour (ACERLI, 1991; Weis, 1996). They are usually made on platforms as the previous tests. The experiences might be useful for the a priori verification. Such tests may be complementary of more usual performances evaluation of distributed application (Lecuivre, 1995; Alimi, 1994).
5.1 . "Plug and play" equipment "Plug and play" explains that after the connection of an equipment to a network, without any other operation, the equipment can run with the others. That's more an objective than a reality. In fact, such equipments are obtained after some operations as parameters setting or program downloading, or after a special programming to adapt the equipment to the system or, reciprocally, the system to the equipment. 5.2. Configuration The configuration of an equipment or of a system is an operation which may lead to interoperability through different operations as parametrization, downloading. The configuration may be done in different ways, manually, through handheld systems, through the network itself. 5.3. Specific Development The specific development operation is the last solution, if possible, to obtain interoperability between equipments and/or systems. The matter is to develop programs in order to translate, to adapt to each other existing softwares, codes, functions, and so on, implemented in a given equipment. 5.4. Companion standards Companion standards are born with MMS development. A companion standard is a specification of a type of equipment, a type of functionality. It is a part of OS1 application layer. It specifies the data exchanges in term of the application, and the services on these data or objects. They are sometimes called interoperability guidelines (in WorldF1P (AFNOR, 1989)), or SNVT (in LON (LON, 1995), or profiles (in 1nterbus-S (DIN, 1995)), or function blocks, or sometimes "8th layer" or "user layer" by 1SA and IEC technical committees. They may be defmed through a general language.
6.2.
The idea of a priori verification is not to be obliged to build the system with all the equipments for testing their interoperability. This approach leads to "prove" the interoperability on models, which may include the application specification. It is decomposed in four kinds of proofs according to the reasons for non interoperability, reasons related to services, protocols, resources, and time. The first problem is to defme the models to represent the equipments : on one hand the communication system, and on an other hand the application. The models must also cover the needs for the four interoperabilities verification. The first works in this domain concerned the verification of interoperability related to the protocols as an extension of the conformance testing. (cf. previous section). Interoperability related to services. This interoperability is verified from two sets of information, the conformance classes of each equipment, resulting of a conformance test, and the needs in term of services of each application process. The verification consists in mapping both of the sets together. Benkhellat (1995) experimented this
6. INTEROPERAB1LITY VERIFICATION 6.1.
A priori verification
Interoperability testing
This part describes the main usual methods for testing the interoperability. They are coming from the conformance testing approach (Arakawa et ai, 1972). The interoperability testing allows to verify in a real environment, if several implementations are able to communicate in order to provide the required services. These tests have been early defmed for OS1 products (Lenzini and Zoccolini, 1992), (CNMA, 1989). Two tests methods are identified by Rafiq (1990b), the active test and the passive one. Passive testing. An example of passive test is given by the test of MMS (CNMA, 1989; Berthet et ai, 1995). It stems directly from the conformance testing methods. Two or more implementations are connected on the network. Special application processes generate requests, answer through responses and so on. A specific station called
436
approach defming the functional architecture in term of required services for each application process, the support architecture with a FIP fieldbus in term of conformance classes, the mapping being verified by a Prolog system. Interoperability related to temporal aspects. The objective is to verify if several equipments have compatible temporal behaviour without having to connect them together. It is then necessary to have models of their behaviour including temporal aspects. An experiment has been made with the FIP fieldbus medium access control (Benkhellat, 1994). Each equipment is modeled through a maximum and a minimum response time measured by a tester which could be the conformance one. The global network is modeled by the transmission time, and temporizers. The functional architecture is modeled by the identified data and their periodicities of production and comsumption. The ~perational architecture is modeled by the 10catlOn of the producers and consumers .pro.cesses . . Th.e interoperability verification consIsts m searchmg If received values are always correct or not. Interoperability related to protocols. This interoperability is verified through models based on languages as Lotos (Bolognesi and Brinksma, 1987), Estelle or states-transitions systems. Interoperability related to resources. An approach similar to the verification of interoperality related to timeliness should be applied. It is usually tested through the performance testing. A complete a priori verification requires a solution to characterize the implementations. And a lot of works have still to be done.
Fig. 1. Conformance testing of implementations
Design impleme interop Choice of uipments and distribu
6.3. Interoperability and life cycle The conformance testing operation is the test of a realization of a given specification. The figure 1 shows the stages according the V life cycle. Normally, the specification stage is followed o~ a validation one. They are one time made for a service and the associated protocol. Then the design of implementations and the corresponding conformance test are made for each implementation. The figure 2 shows on the same model of life cycle, the positions of interoperability testing and of interoperability verification. The application specification may be the definition of a specific one, suited to test the interoperability of given equipments. But it may be applied to any application. The stage called "design and choice of equipments" is the one when the designer defines the necessary equipments, the distribution of the application and try to prove that the constraints will be met. This proof stage is the a priori verification of the interoperabilities, ~ v.:ell from the communication as from the application point of view. The stage "interoperability te~ting" is the a posteriori verification, when all the equlpments have been realized, connected, and so on. It IS clear that both of the stages are necessary, but the more a priori verification may be done, the less must be done after realization.
Fig. 2. Interoperability testing and verification 7.
CONCLUSION
In this paper an overview on interoperability has been presented. This word covers different properties of equipments which are all needed to build a system for a given application. They may be tested after ~e system building or verified before, at the deSign stage. A lot of progress must be done in this way. The first problem to be solved is the characterization of the equipments with regard of the application specification. Formal techniques relevant as well of qualitative as quantitative models must be used. Much remains to be done to solve the problem of the states number explosion with the complexity of the system to be verified. That's a problem ~~i~h cannot be solved without formal deflnltlOns of interoperabilities (Benkhellat, 1995). Finally, the interoperability verification must. be included for one part in the conformance testmg stage, (for the aspects which are application indepen-
437
dent and equipment characterization), for another one, in the life cycle of the application development, (at the design stage).
industrial control systems for for CENELEC (1996b). Gadre J., C. Rohrer, C. Summers and S. Symington (1990). A COS study of OSI Interoperability. Computer standards and interfaces, 9, pp 217237. ISO (1988). IS 9646-1 to IS 9646-5. Open Systems Interconnection OSI conformance testing methodology and framework. ISO (1990). ISOIIEC IS 9506 Manufacturing Message Specification. Kone O. (1994). Interconnexion de systemes ouverts: Test d'interoperabilite, test avec contraintes de temps physique. These, Bordeaux, France. Lecuivre J. (1995). A framework for validating distributed real time applications by performance evaluation of communication profiles. In IEEE Workshop on Factory Communication Systems, JD Decotignie ed, pp 37-46. Leduc G. (1991). Equivalence associee a la relation de conformite, con/. et simplification du testeur canonique en LOTOS, CFIP'91, Ingenierie des protocoles, Hermes, Paris, pp 425-440. Lenzini L. and F. Zoccolini (1992). Interoperability tests on OSI products in the framework of the OSIRIDE intertest initiative. Computer Networks and ISDN Systems, 24, pp 65-79. LON (1995). Documentation Echelon Corporation, 4015 Miranda Avenue, Palo Alto, CA 94304, USA. Paret (1996), Le reseau CAN, Controller Area Network, Dunod, France. Rafiq O. (1990a). The Astrid testing approach : principles, tools and carrying out. Computer standards and interfaces. 11, pp 85-94. Rafiq O. (1990). Sur la verification de l'interconnexion des systemes. In CIM'90. Bordeaux, France, pp 557-564. Thomesse J.P . (1993). Le reseau de terrain FIP, Revue Reseaux et Informatique Repartie, Hermes, Vol 3, N°3, 1993, pp 287-321. Weis F. (1996). Une approche pour I'integration d'applications MMS . These Conservatoire National des Arts et Metiers, Paris, France. Witteman M. F. and R. C. van Wuijtswinkel (1993). A TM Broadband network testing using the ferry principle. IFIP Int. Workshop on protocol test systems, (0. Rafiq Ed), Pau, France, pp 129142. Zeng H. X., Q. Li, X.F. Du and C.S. He (1988). New advances in ferry testing approaches. Computer Networks and ISDN Systems, 15, pp 47-54. Zeng H. X., S. T. Chanson and B. R. Smith (1989) . On ferry clip approaches in protocol testing. Computer Networks and ISDN Systems, 17, pp 77-88. Zimmermann H. (1980). OSI reference model. The ISO model of architecture for open system interconnection, IEEE Trans. COM-28 n04, April 80, pp 425-432.
8. ACKNOWLEDGEMENTS The author would thank all the members of his team specially Y. Benkhellat and M. Siebert for their fundamental contributions to our research. 9. BIBLIOGRAPHY ACERLI (1991). Projet STRIN MMS MP, Mesures de performances pour MMS, Association des Centres d'Essai des Reseaux Locaux Industriels, France. AFNOR (1989). French Standards NF C46601 to C46607. FIP bus for exchange of information between transmitters, actuators and programmable controllers. Published between 1989 and 1992. Alimi R. (1995). Modelisation des reseaux de communication industrielle a EDFIGDF. These de l'universite P. et M. Curie. Paris, France. Arakawa N., M. Phalippou, N. Risser (1992). Combination of conformance and interoperability testing. IFIP Forte'92. Benkhellat M. L., M. Siebert and J. P. Thomesse (1992). Interoperability of sensors and distributed systems. Journal Sensors and actuators A, Vol A37 and A38, (2), pp247-254. Benkhellat Y. and Thomesse J.P. (1994). Validation of timing properties for interoperability in distributed real time applications. Proc 13th PSTV, IFIP, Chapman and Hall, pp331-338. Benkhellat M.L. (1995). Formalisation et verification de l'interoperabilite dans les systemes de communication, These de l'INPL, Nancy, France. Berthet G., P. Castori, p. Pleinevaux, F. Restrepo, K . Vijayananda and F. Vamparys (1995). Interoperability testing : Experience with MAP and CNMA. In Proc 13th lASTED Int. Conf. on Applied Informatics, (M. Hamza, Ed). pp 60-65 . Bonnes G. (1988). Verification d'interoperabilite OSI, X400 et LU 6.2. In G. Pujolle Ed, De nouvelles architectures pour la communication ppI33-140, Eyrolles, Paris, France. Brinksma E. (1988). A theory for the derivation of tests. In PSTV VIII, IFIP, Elsevier Science Publisher, pp 235-247. Bolognesi T. and E. Brinksma (1987). Introduction to the ISO specification language LOTOS . Computer networks and ISDN systems. pp 2529. Castanet R . and O. Kone (1993). Deriving coordinated testers for interoperability. In 6th IFIP international workshop on protocol test systems, O. Rafiq Ed, pp 335-348. CNMA (I989). TT CNMA, Esprit project 2292, MMS interoperability test system, Test suite structure and tests purpose. DIN (1995). German Draft Standard 19 258-1. Interbus-S, sensor and actuator network for
438
INTEROPERABILITY : AN OVERVIEW
J.P. Thomesse
CRlN-CNRS ENSEM-INPL 2 avenue de la foret de haye 54516 Vandreuvre les Nancy. France Fax 03 83 44 0763 E-mail thomesse@loriajr
Abstract : This paper presents an overview on the interoperability, specially between sensors, actuators and fieldbus. The reasons for non interoperability are analyzed. Two main problems are studied: how to build interoperable equipments ot systems, and how to test, to verify, or to prove the interoperability. The methods, the solutions, or the approaches, to build or to verify the interoperability are described. After some defmitions pulled out of the standards or of testing organisations, the global interoperability is decomposed into four partial ones,which are relevant of services, of protocols aspects including the coding (syntax and semantics) of data or exchanged objects, of resources necessary to manage the communication and the cooperation between application processes, and of temporal aspects in the behaviour of the communication and processes. Giving some examples of possible verification without puting all the equipments on a testing platform, we show the interest of the verification regarding the test approach. Keywords : Interoperability, test, services, protocols, performances, companion standards, fieldbus .
1.
long time. But it achieves success with the defmition of the OSI model (Zimmermann, 1980) by ISO at the beginning of the eighties, making easier the heterogeneous systems implementation. Heterogeneity, here is the keyword, is at the source of a lot of problems. The automation systems are more and more complex, based on equipments from different vendors, specially when sensors, actuators, field devices are considered. The word interoperability is more recent, essentially with the networks development, (Bonnes, 1988), but other domains are also concerned (software, data bases, operating systems). Interoperability is a property of several equipments to "work" together for a given goal, or the property of an equipment to work with an existing system (a set of equipments). The emergence of standards (de facto and de jure) makes easier the interoperability of equipments conform to a given standard. But that's not a
INTRODUCTION
This paper deals with interoperability which is the basic property required for equipments to build a system. The first part is concerned with an analysis of this property, the second one with the methods to obtain and test or verify it. This paper contains then firstly a general problem statement and also an overview of solutions or a state of the art based on works which have been developped in our team. Interoperability, openness, two words more and more used as well by vendors of automation components as by their end-users ; by the first one, as property of their equipements and systems, by the second one as requirements or as problems. The word openness is not recent. In computer science, the compatibility problems does exist for a
433
complete guarantee. Why ? How to do to solve the problem ? How to be sure that equipments will be interoperable ? And what is formally the interoperability ? This paper tries to answer these questions, specially in the automation systems built with a fieldbus. In the flrst section we will place the notions of equipment, system, communication and application architectures, services or protocols specifications and standards in reference to each other. The interoperability general problem is not only related to communication mechanisms but also to the application specification and implementation. It is then useful to have, at flrst, a common understanding of all these concepts. They will be illustrated by exemples taken in the instrumentation area The second section entitled "Interoperabilities" will summarize their different deflnitions given by standardization bodies and conformance testing organizations. Regarding layered structures, the following kind of interoperabilities will be introduced: the layer interoperability, the proflle one, the communication one, the application interoperability sometimes called interworking which include a lot of properties. But the communication aspects will be of major interest in the following. Therefore, another classification of interoperabilities will be proposed in the third section, starting from an analysis of the non interoperability reasons. They are related to incompatibilities between the available services, or to differences in the protocols implementations even if they are conformable to a standard. Other reasons as the lack of resources, or as temporal behaviours may be also at the source of interoperability problems. We will conclude this section with an analysis of the interoperabilities regarding their application dependence or independence. Let us now analyze how this problem may be solved. Two complementary approaches must be used. The first one is called "interoperability building", the second "interoperability testing". They occur at different stages of an application development. Interoperability building : different operations may be used in order to make compatible different equipments in a system. This approach is described in the section four. Interoperability testing : usually, the interoperability testing is issued from the experiences in conformance testing. But it makes a complete abstraction of the application dependent aspects. And that is how interoperability problems may be discovered at a late stage in the application integration. Therefore we propose another approach in order to minimize or to reduce such phenomena. The question is whether it is possible to prove or to verify the interoperability of equipments in a system for a given application. Models are then necessary ; models of the application architecture, of the support architecture (processors and networks), and models of the application processes distribution on the equipments. We developped for some years such models and
verification systems, which will be presented in the last section of this paper. 2. PRELIMINARY DEFINITIONS The following notions will be defined in order to have a common understanding when speaking about different interoperabilities and the reasons for non interoperability .
2.1. Systems and equipments Interoperability is a property of several equipments to "work" together for a given goal. Or interoperability is the property of an equipment to work with an existing system (a set of equipment). What is an equipment ? What is a system ? An equipment is any station connected to the network and the able to exchange data with each other. A system is a set of equipments connected to a network. . We consider in this paper that the interoperability problems are related to the communication or connection mechanisms between different equipments .. A sensor is an equipment, a PLC is another equipment regarding a fieldbus, but it is a system regarding the internal bus connecting the boards, which are then equipments. At this level, such informal relations examples should be defined : IOPl(El, E2, .... , En, Corn) to express that all the Ei are interoperable with the communication system Corn or IOP2(Ei, SI) to express that the equipment Ei is interoperable with the system SI including a communication system. 2.2. Layered communication architecture Any equipment is supposed having a communication system architectured according to a layered structure as the OSI model, without regarding in detail the layers number, the services and protocols. 2.3.
Specifications and standards
Service specification. A service specification defmes the services provided by a layer, indepedently of the protocols which may realize the service. Such a specification may be a standard. All the services of a standard are not always necessary for a given equipment. Subsets of the services called "conformance classes" may be standardized. Protocol stecification. A protocol speciflcation defmes the PDUs (Protocol Data Unit) exchanged between the layer entities and the rules to carry on them. Companion standard. A companion standard is an element of the application layer which explains the objects and the services of an ASE (Application Service Element) in a restricted domain, for some kind of device, of application, and so on. Network Management standard. A network management standard specifies how an equipment or a network must be configured, maintained, observed. Application specification . An appl ication specification is a definition, formal or not of the application distributed around the considered network.
434
2.4.
The interoperability related to the services is the property of equipments to provide the required serv ices . Knowing the conformance classes implemented in each equipment, it is not to difficult to test if all the equiments of an application are interoperable or not.
Implementation
We call here implementation all the operations of design, realization, programming, wiring, to build an equipment. An equipment is the result of implementation of communication standards and of a part of the application specification.
4.2. Interoperability related to protocols
2.5. Conformance and performance testing
The interoperability related to the protocols is defined by the capability of all the equipments having to exchange PDUs to respect exactly the same rules. That means that all the options, all the parameters in the implementations must be compatible.
Conformance testing. The conformance testing defined by ISO (1988) concerns only the implementation of the communication layers. The conformance is tested layer by layer, or if impossible, the complete profile implementation is globally tested. Performance testing. The performance testing has an objective, to measure the capabilities of an implementation, in term of resources, of time behaviour, of connections maximum number, and so on.
4.3. Interoperability related to resources Each communication between two or more equipments require resources in memory. MMS for examples supposes an opening of connection and then a memory allocation in each equipment. WorldFIP (Thomesse, 1994) or CAN (Paret, 1996) require the availability of buffers to store the exchanged data. The interoperability related to the resources is defined by the capability of the equipments to offer the required resources.
3. INTEROPERABILITIES This section defmes the usual interoperabilities. 3.1. Layer interoperab ility. Two or more N-Iayers are said Layer-interoperable if the conformance test results are successful and if it has been shown that they realize the N-service defmed in the standard and required by the profile. 3.2. Profile interoperability. Two or more equipments are said Profileinteroperable if their layers are layer-interoperable. Gadre (1990) distinguishes the theoretical (by proof) and demonstrable (by test) interoperabilities for the previous ones. This criterion takes into account the methods to verify interoperabilities, as they will detail in the two last sections.
4.4. Interoperability related to ttmeliness Considering a MAC protocol using a token mechanism, an equipment must answer in a given delay after the token receipt. The interoperability related to temporal aspects is the property of all the equipments to meet all the delays defined in a given profile. 4.5. Application dependant interoperability Communication interoperability and application interoperabilities are often distinguished. This classification is not so obvious. The application needs cannot be forgotten in communication considerations. Let us take some examples. A sensor is conform to a communication profile, but according to a subset of services. This sensor may be interoperable with other equipments for a given application and not for another one which needed other services. A PLC supporting MMS services is able to manage a maximum of five simultaneous connections. It may be interoperable with equipments for an application which don't requ ire more than five connections, but not for another which needs more. Three kinds of interoperability may be then defmed : the interoperability of communication systems independently of the application, the interoperability of commun ication systems which is application dependant and the interoperability of application strictly speaking (also called interworking) which depends on its specification and its programming.
4.NON-INTEROPERABILITY REASONS In this section, we will introduce why equipments which achieve conformance testing with success, may be not interoperable. The reasons come from services unavailability, from different options in the protocol implementation, from time behaviour incompatibilities or from lack of resources (memory, ...). Some of non interoperability reasons are only dependent on communication characteristics, other are dependent on the application. That means that an equipement may be interoperable with a system for a given application and not for another one. These criteria have been identified and explained by Benkhellat (1992; 1995). 4.1. lnteroperability related to the services Let us take an example. Considering a distributed application built using the MMS ASE (Manufacturing Message Specification) (ISO, 1990), the equipments are then in relation according to the client-server model. The interoperability of the equipments is conditionned by the availability, for each service used, of request and confirmation primitives located by the client and of indication and response primitives located by the server.
5. INTEROPERABILITY BUILDING This section deals with the ways to obtain interoperability of equipments.
435
"observer" IS m Charge 01 ventymg the contormance of the exchanged PDUs. The same architecture may be used to test the capacities and some performances of the implementations. Active testing. Such an approach (ferry clip) has been used by Zeng (1988; 1989) and Witteman (1993). Rafiq (1990a) proposed another active method. The PDUs are derivated through the tester in order to be able to verify them as in the previous method but also to modify them to test how errors are recovered. Theoretical testing. Castanet and Kone (1993) defmed formally a relation of interoperability and its canonical tester following the works of Brinksma (1988) and Leduc (1991). The implementations are modeled with TIOSM, (Timed Input Output State Machine), a canonical tester is defined, and the evaluation made through the analysis of the global behaviour. The main problem is the number of states in the graph of accessibility, which is very quickly growing and then limits the method applicability. But Kone (1994) proposed the so-called "au-vol" technics which limits the number of states. This approach is also a step towards the a priori verification. This approach cannot cover all the cases, and specially doesn't take into account the specification of a given application. Performance testing. No performance testing method is standardized, as for interoperability. The objective is the identification of capabilities in terms of resources, of time response or more generally of characteristics of timely behaviour (ACERLI, 1991; Weis, 1996). They are usually made on platforms as the previous tests. The experiences might be useful for the a priori verification. Such tests may be complementary of more usual performances evaluation of distributed application (Lecuivre, 1995; Alimi, 1994).
5.1 . "Plug and play" equipment "Plug and play" explains that after the connection of an equipment to a network, without any other operation, the equipment can run with the others. That's more an objective than a reality. In fact, such equipments are obtained after some operations as parameters setting or program downloading, or after a special programming to adapt the equipment to the system or, reciprocally, the system to the equipment. 5.2. Configuration The configuration of an equipment or of a system is an operation which may lead to interoperability through different operations as parametrization, downloading. The configuration may be done in different ways, manually, through handheld systems, through the network itself. 5.3. Specific Development The specific development operation is the last solution, if possible, to obtain interoperability between equipments and/or systems. The matter is to develop programs in order to translate, to adapt to each other existing softwares, codes, functions, and so on, implemented in a given equipment. 5.4. Companion standards Companion standards are born with MMS development. A companion standard is a specification of a type of equipment, a type of functionality. It is a part of OS1 application layer. It specifies the data exchanges in term of the application, and the services on these data or objects. They are sometimes called interoperability guidelines (in WorldF1P (AFNOR, 1989)), or SNVT (in LON (LON, 1995), or profiles (in 1nterbus-S (DIN, 1995)), or function blocks, or sometimes "8th layer" or "user layer" by 1SA and IEC technical committees. They may be defmed through a general language.
6.2.
The idea of a priori verification is not to be obliged to build the system with all the equipments for testing their interoperability. This approach leads to "prove" the interoperability on models, which may include the application specification. It is decomposed in four kinds of proofs according to the reasons for non interoperability, reasons related to services, protocols, resources, and time. The first problem is to defme the models to represent the equipments : on one hand the communication system, and on an other hand the application. The models must also cover the needs for the four interoperabilities verification. The first works in this domain concerned the verification of interoperability related to the protocols as an extension of the conformance testing. (cf. previous section). Interoperability related to services. This interoperability is verified from two sets of information, the conformance classes of each equipment, resulting of a conformance test, and the needs in term of services of each application process. The verification consists in mapping both of the sets together. Benkhellat (1995) experimented this
6. INTEROPERAB1LITY VERIFICATION 6.1.
A priori verification
Interoperability testing
This part describes the main usual methods for testing the interoperability. They are coming from the conformance testing approach (Arakawa et ai, 1972). The interoperability testing allows to verify in a real environment, if several implementations are able to communicate in order to provide the required services. These tests have been early defmed for OS1 products (Lenzini and Zoccolini, 1992), (CNMA, 1989). Two tests methods are identified by Rafiq (1990b), the active test and the passive one. Passive testing. An example of passive test is given by the test of MMS (CNMA, 1989; Berthet et ai, 1995). It stems directly from the conformance testing methods. Two or more implementations are connected on the network. Special application processes generate requests, answer through responses and so on. A specific station called
436
approach defming the functional architecture in term of required services for each application process, the support architecture with a FIP fieldbus in term of conformance classes, the mapping being verified by a Prolog system. Interoperability related to temporal aspects. The objective is to verify if several equipments have compatible temporal behaviour without having to connect them together. It is then necessary to have models of their behaviour including temporal aspects. An experiment has been made with the FIP fieldbus medium access control (Benkhellat, 1994). Each equipment is modeled through a maximum and a minimum response time measured by a tester which could be the conformance one. The global network is modeled by the transmission time, and temporizers. The functional architecture is modeled by the identified data and their periodicities of production and comsumption. The ~perational architecture is modeled by the 10catlOn of the producers and consumers .pro.cesses . . Th.e interoperability verification consIsts m searchmg If received values are always correct or not. Interoperability related to protocols. This interoperability is verified through models based on languages as Lotos (Bolognesi and Brinksma, 1987), Estelle or states-transitions systems. Interoperability related to resources. An approach similar to the verification of interoperality related to timeliness should be applied. It is usually tested through the performance testing. A complete a priori verification requires a solution to characterize the implementations. And a lot of works have still to be done.
Fig. 1. Conformance testing of implementations
Design impleme interop Choice of uipments and distribu
6.3. Interoperability and life cycle The conformance testing operation is the test of a realization of a given specification. The figure 1 shows the stages according the V life cycle. Normally, the specification stage is followed o~ a validation one. They are one time made for a service and the associated protocol. Then the design of implementations and the corresponding conformance test are made for each implementation. The figure 2 shows on the same model of life cycle, the positions of interoperability testing and of interoperability verification. The application specification may be the definition of a specific one, suited to test the interoperability of given equipments. But it may be applied to any application. The stage called "design and choice of equipments" is the one when the designer defines the necessary equipments, the distribution of the application and try to prove that the constraints will be met. This proof stage is the a priori verification of the interoperabilities, ~ v.:ell from the communication as from the application point of view. The stage "interoperability te~ting" is the a posteriori verification, when all the equlpments have been realized, connected, and so on. It IS clear that both of the stages are necessary, but the more a priori verification may be done, the less must be done after realization.
Fig. 2. Interoperability testing and verification 7.
CONCLUSION
In this paper an overview on interoperability has been presented. This word covers different properties of equipments which are all needed to build a system for a given application. They may be tested after ~e system building or verified before, at the deSign stage. A lot of progress must be done in this way. The first problem to be solved is the characterization of the equipments with regard of the application specification. Formal techniques relevant as well of qualitative as quantitative models must be used. Much remains to be done to solve the problem of the states number explosion with the complexity of the system to be verified. That's a problem ~~i~h cannot be solved without formal deflnltlOns of interoperabilities (Benkhellat, 1995). Finally, the interoperability verification must. be included for one part in the conformance testmg stage, (for the aspects which are application indepen-
437
dent and equipment characterization), for another one, in the life cycle of the application development, (at the design stage).
industrial control systems for for CENELEC (1996b). Gadre J., C. Rohrer, C. Summers and S. Symington (1990). A COS study of OSI Interoperability. Computer standards and interfaces, 9, pp 217237. ISO (1988). IS 9646-1 to IS 9646-5. Open Systems Interconnection OSI conformance testing methodology and framework. ISO (1990). ISOIIEC IS 9506 Manufacturing Message Specification. Kone O. (1994). Interconnexion de systemes ouverts: Test d'interoperabilite, test avec contraintes de temps physique. These, Bordeaux, France. Lecuivre J. (1995). A framework for validating distributed real time applications by performance evaluation of communication profiles. In IEEE Workshop on Factory Communication Systems, JD Decotignie ed, pp 37-46. Leduc G. (1991). Equivalence associee a la relation de conformite, con/. et simplification du testeur canonique en LOTOS, CFIP'91, Ingenierie des protocoles, Hermes, Paris, pp 425-440. Lenzini L. and F. Zoccolini (1992). Interoperability tests on OSI products in the framework of the OSIRIDE intertest initiative. Computer Networks and ISDN Systems, 24, pp 65-79. LON (1995). Documentation Echelon Corporation, 4015 Miranda Avenue, Palo Alto, CA 94304, USA. Paret (1996), Le reseau CAN, Controller Area Network, Dunod, France. Rafiq O. (1990a). The Astrid testing approach : principles, tools and carrying out. Computer standards and interfaces. 11, pp 85-94. Rafiq O. (1990). Sur la verification de l'interconnexion des systemes. In CIM'90. Bordeaux, France, pp 557-564. Thomesse J.P . (1993). Le reseau de terrain FIP, Revue Reseaux et Informatique Repartie, Hermes, Vol 3, N°3, 1993, pp 287-321. Weis F. (1996). Une approche pour I'integration d'applications MMS . These Conservatoire National des Arts et Metiers, Paris, France. Witteman M. F. and R. C. van Wuijtswinkel (1993). A TM Broadband network testing using the ferry principle. IFIP Int. Workshop on protocol test systems, (0. Rafiq Ed), Pau, France, pp 129142. Zeng H. X., Q. Li, X.F. Du and C.S. He (1988). New advances in ferry testing approaches. Computer Networks and ISDN Systems, 15, pp 47-54. Zeng H. X., S. T. Chanson and B. R. Smith (1989) . On ferry clip approaches in protocol testing. Computer Networks and ISDN Systems, 17, pp 77-88. Zimmermann H. (1980). OSI reference model. The ISO model of architecture for open system interconnection, IEEE Trans. COM-28 n04, April 80, pp 425-432.
8. ACKNOWLEDGEMENTS The author would thank all the members of his team specially Y. Benkhellat and M. Siebert for their fundamental contributions to our research. 9. BIBLIOGRAPHY ACERLI (1991). Projet STRIN MMS MP, Mesures de performances pour MMS, Association des Centres d'Essai des Reseaux Locaux Industriels, France. AFNOR (1989). French Standards NF C46601 to C46607. FIP bus for exchange of information between transmitters, actuators and programmable controllers. Published between 1989 and 1992. Alimi R. (1995). Modelisation des reseaux de communication industrielle a EDFIGDF. These de l'universite P. et M. Curie. Paris, France. Arakawa N., M. Phalippou, N. Risser (1992). Combination of conformance and interoperability testing. IFIP Forte'92. Benkhellat M. L., M. Siebert and J. P. Thomesse (1992). Interoperability of sensors and distributed systems. Journal Sensors and actuators A, Vol A37 and A38, (2), pp247-254. Benkhellat Y. and Thomesse J.P. (1994). Validation of timing properties for interoperability in distributed real time applications. Proc 13th PSTV, IFIP, Chapman and Hall, pp331-338. Benkhellat M.L. (1995). Formalisation et verification de l'interoperabilite dans les systemes de communication, These de l'INPL, Nancy, France. Berthet G., P. Castori, p. Pleinevaux, F. Restrepo, K . Vijayananda and F. Vamparys (1995). Interoperability testing : Experience with MAP and CNMA. In Proc 13th lASTED Int. Conf. on Applied Informatics, (M. Hamza, Ed). pp 60-65 . Bonnes G. (1988). Verification d'interoperabilite OSI, X400 et LU 6.2. In G. Pujolle Ed, De nouvelles architectures pour la communication ppI33-140, Eyrolles, Paris, France. Brinksma E. (1988). A theory for the derivation of tests. In PSTV VIII, IFIP, Elsevier Science Publisher, pp 235-247. Bolognesi T. and E. Brinksma (1987). Introduction to the ISO specification language LOTOS . Computer networks and ISDN systems. pp 2529. Castanet R . and O. Kone (1993). Deriving coordinated testers for interoperability. In 6th IFIP international workshop on protocol test systems, O. Rafiq Ed, pp 335-348. CNMA (I989). TT CNMA, Esprit project 2292, MMS interoperability test system, Test suite structure and tests purpose. DIN (1995). German Draft Standard 19 258-1. Interbus-S, sensor and actuator network for
438