Int J Adv Manuf Technol (2006) 27: 951959 DOI 10.

1007/s00170-004-2272-7

ORIGINAL ARTICLE

Zhou Bing-hai Xi Li-feng Yu Chuan-meng

DCOM and MMSbased control software architecture for automated manufacturing system

Received: 24 March 2004 / Accepted: 27 May 2004 / Published online: 29 June 2005 Springer-Verlag London Limited 2005 Abstract In this paper, we introduce the manufacturing message specication (MMS) and compare two distributed object approachesdistributed component object model (DCOM) and common object request broker architecture (CORBA), suggest characteristics that DCOM is more suitable for automated manufacturing system (AMS) control software integration. In order to make a control system provided with interoperability and recongurability etc., a hybrid control system is built for AMS, then a control software architecture is presented for AMS based on distributed object DCOM middleware and MMS standard. The object-oriented DCOM communication protocol is used to implement the MMS in a distributed object mode. DCOM and MMS combination brings the operating system independent communication capabilities to manufacturing devices such as CNC machine tools and industrial robots in AMS. Control software implementation of MMS concepts in the DCOM environment is particularly discussed. Finally, to verify the control software architecture for AMS, prototype development has been implemented in VC++ 6.0 developer environments. Keywords Automated manufacturing system Control system Distributed object model Manufacturing message specication Software architecture quickly in order to handle new products, to use new machines or processes [3, 4]. Therefore, control software of AMS must be exible and recongurable to adapt to the AMS changes in its environment. A typical AMS consists of hardware and control software. The hardware, which includes computer numerical control (CNC) machine tools, industrial robots, material handling systems, loading/unloading stations and storages, has been around for decades and problems associated with hardware have been well studied, and are reasonably well understood [5]. The control software typically controls a set of manufacturing devices with various real-time information and messages passing among control components. In current practice, most control software implementations have been developed specically for a particular facility, with no generic format or standardization for the systematic creation and planning of control software. This has resulted in systems that lack interoperability and recongurability, often require a long implementation time, have much less operational exibility than originally anticipated, and frequently incur high implementation costs [6]. AMS interoperability is one of the most important requirements for exible and recongurable control software implementation [7, 8]. The interoperability mainly includes platform interoperability, language interoperability, and notational interoperability. Platform interoperability resolves the differences in the hardware, system software, and the services that deal with communication between two objects [9]. It allows a client to make a transparent call to a server even if the server is running another process or is on another computer, so that the call looks as if it were an in-process (local) call. Language interoperability provides language independence such that applications, which are implemented in different programming languages, can be integrated. As a result, components written in different programming languages can communicate with each other. Notational interoperability can be further classied into data interoperability and object interface interoperability [9]. Data interoperability addresses disagreements on data formats, types, structures, and representations [10, 11]. Object interface interoperability deals with agreements on object interface characteristics [10]. Much dis-

1 Introduction
The development of manufacturing technology is always adapted to demands of the markets. Nowadays, manufacturing enterprises are often faced with erce competition, which is making automated manufacturing systems (AMS) a key factor in business strategy. Acting as an important part of AMS, control software has inuenced the performance of AMS importantly [1, 2]. There is an increasing demand on AMS to be recongured
Z. Bing-hai (u) X. Li-feng Y. Chuan-meng School of Mechanical Engineering, Shanghai Jiaotong University, Shanghai, China E-mail: bhzhou@sjtu.edu.cn

952

cussion of interoperability and its research have been concerned with distributed computing. For example, the recent emergence of the object management groups CORBA (common object request broker architecture) and Microsofts DCOM (distributed component object model) are all for this purpose. A number of standardization projects for control software of AMS have raised considerable efforts. However, up to now, most of the achievements lacked a modular and standardized architecture, applicable to a variety of specications and standards, such as the ISO (international organization for standardization) based MMS (ISO-MMS) could not easily be affordable in small manufacturing enterprises [12]. With the emergence of distributed object technology, it becomes reality to apply MMS to AMS easily. In this paper, rst, in order to overcome the limitations mentioned above and make control software of AMS provided with interoperability, recongurability and exibility, MMS standard and distributed object client/server concept are presented. Then we present a control software architecture based on DCOM and the standardized ISO-MMS concepts. Control software implementation of MMS concepts in the DCOM environment is particularly discussed. To implement the control software with standardization interfaces, interfaces of control components of control system are dened with Microsoft interface denition language (MIDL) and abstract syntax notation, one (ASN.1) of MMS services. Finally, prototype development has been implemented in VC++ 6.0 developer environments.

Fig. 1. MMS object group

2 MMS description
MMS is an international standardized messaging system used to exchange technology data and supervisory control information between networked devices and/or computer applications, independently of the application function being performed or the developer of the device or application [13]. MMS uses an abstract object-oriented modeling technique to describe the MMS objects and services. MMS denes a total of 16 objects and 86 services [14]. A service group comprises those services described in the standard that all refer to the same object or object group. The main objects are shown in Fig. 1. MMS only species these objects and their attributes. However, it does not dene how these objects communicate with each other or how they are implemented internally in a VMD (virtual manufacturing device) or who coordinates them. Since interoperability could be dened without details of internal implementation, it has not been addressed by the standard [15]. MMS is one of the services offered in the application layer of the seven-layer ISO-open systems interconnection (ISO-OSI) communication architecture. Communication in MMS is based on the client/server manner. The client/server communication model of MMS environment is shown in Fig. 2. The manufacturing message protocol machine (MMPM) takes care of exchanging the packets of information called protocol data units (PDUs) between the client application and the server application. Messages passed to the MMPM are in ASN.1 format; therefore, an encoding and decoding mechanism is required to pack and

Fig. 2. MMS client/server communication model

unpack manufacturing messages. Besides, as mentioned above, the MMS standard is based on the OSI communication model and it has four different phases, called messages, within a service communication: request corresponds to a client request passed to the communication provider-which in MMS is called the association control service element (ACSE), indication is a message from the ACSE to server corresponding to a request made by a client, response is a response which the server sends to a ACSE, and conrm is the ACSE notication of a servers response message. When a client application wants to communicate with a server application, it has to establish the connection to communicate with the remote application. To do that, it must dene some specications. The lower part of the application layer, ACSE, denes the specications for the establishment and termination of connections. As such, it can be ported to other communication environments, either physical or protocol [12]. The client/server scheme can be supported with

953

distributed object environments. In this situation, the actual ISOMMS standard cannot be used directly. A new version of MMS must be designed to match with distributed object constraints.

3 Distributed object approaches

Distributed objects are objects in the client/server system [16]. They are packed as independent pieces of code that can be accessed by remote client via method invocations. The client neednt know where the distributed object resides or what operating system it executes. Also distributed objects can be on the same computer or on different computers that site across a network. Currently, the industry has two popular standards to create a heterogeneous, distributed, and componentized infrastructure. They are DCOM and CORBA, which are two mature, interoperable, distributed object models that provide well-designed integration and communication standards. Both are considered low-level architectures. Table 1 compares and contrasts the two approaches. They are used as the backbones or middleware of modern distributed object environments. They facilitate the task of building distributed applications by presenting the network as one large virtual machine in which remote objects appear to be local. Middleware use frees the developer from many of the low-level programming tasks necessary to achieve integration of distributed applications and coordinated interactions between distributed objects, while at the same time providing many necessary support services. CORBA and DCOM both provide standard specications for achieving language interoperability and platform independence. They dene their own interface standards to deal with peculiar applications. They support distributed processing, object re-use, and the internet. CORBA can be purchased from multiple vendors, and DCOM is shipped with MS Windows X (for example, 85, 98, 2000 etc.). CORBA includes overheads such as complexity, expense, performance issues, and sheer size that may detract from its appeal [17]. DCOM, on the other hand, is an integral part of the Windows operating system and is relatively easy to use for system integration. The implementation also indicates that, based on our previous experience with CORBA [18], DCOM programming is easier and more productive. An additional advantage with DCOM

Fig. 3. DCOM architecture

is that we can develop distributed system interfaces using Microsoft resources. A slight difculty with DCOM is that it takes some time to master technical specication. Therefore, in this paper, we take DCOM middleware as the distributed client/server model for control software architecture. DCOM is a protocol that enables software components to communicate directly over a network in a reliable and efcient manner. DCOM architecture is shown in Fig. 3. COM run time provides object-oriented services to client and server, and uses remote procedure call (RPC) and the security provider to generate standard network packets that conform to the DCOM wire-protocol standard. The goal of the component object model (COM) is the development of the communicating software component, independent of a programming language and the required functionality. DCOM extends the functionality of COM, as it offers the possibility to communicate over local area network (LAN) or internet [16]. ActiveX controls are developed to facilitate the distribution of components over the internet. In this sense, ActiveX is an internet based representation of the DCOM communication. Using DCOM interfaces, a client object can forward a RPC to the specialized server object, which provides the necessary processing and returns the processing result to the server site.

4 Control system architecture

Advancement in computer and control technology has brought the control system of AMS into a new era. Hierarchical and heterarchical control architectures are two of the most popular control frameworks applied by industries and academics [19]. However, the loading on the central controller may be very heavy in the hierarchical control architecture, as the number of manufacturing devices in AMS increases. On the other hand, in a heterarchical architecture, control entities complexity will not be raised as the number of manufacturing devices increasing. However, due to the lack of a central controller, the control entities communication will be very busy and proper control strategies might be difcult to achieve [20, 21]. To combine advantages of hierarchical and heterarchical architectures, the incorporation of hierarchy in a distributed control system of AMS is illustrated in Fig. 4. Basically, it contains three levels: shop oor levelmainly including planning and scheduling component, processing plan-

Table 1. Comparison of DCOM and CORBA Criteria Purpose Language Module Approach DCOM CORBA

Middleware Middleware Interfacing using MIDL Interfacing using IDL General General Yes well-dened Yes well-dened Distributed transport mechanism transport mechanism Object re-use Binary (Executable code) Source code Internet Yes trough ActivX Yes trough IIOP Cost Low shipped with MS Windows High $1000 or more

954 Fig. 4. Hybrid control system architecture for AMS

ning component, system conguration component, dispatching and coordination component; control entities level-mainly including DNC control component, AGVs control component etc.; manufacturing devices level-mainly including computer numerical control (CNC) machine tools, industrial robots etc. The resulting control architecture has a basic structure of autonomous co-operating local components, which are capable of communicating with each other.

5 Control software framework architecture

A control software framework architectural design should satisfy several key requirements of control system architecture for AMS. The design should be a framework that is language independent, so that applications can be implemented in different programming languages and used by software clients that are writing using dif-

ferent programming languages. The design should be compliant to MMS for such a standard that provides a common interface among manufacturing devices. The design should be in conformity with object-oriented and component-oriented accepts. The design should have extendibility, which allows application developers to customize a control software system to satisfy new needs. With extensibility, new components can be plugged into the current control system, existing components can be replaced with new ones, or new components can be derived from exiting ones. In this way, the current control software grows and evolves over time, and components can be re-used by others. According to the design requirements, in our control software framework architecture, the control software is modeled as a set of intercommunication components. The components communicate with each other by using MMS messages within the DCOM environment. Control software framework architecture is shown in Fig. 5. The architecture is built on top of the infras-

Fig. 5. Control software framework architecture

955

tructures of the multi-tasks operating system, MS-programming language and distributed database, which provide the development environment of control software components and support the components running in the multi-tasks environment. The kernel part of the architecture is DCOM and MMS, which provide a communication platform of message passing for components and manufacturing devices in the distributed environment. In programming and engineering disciplines, a component is an identiable part of a larger program or construction. Usually, a component provides a particular function or a group of related functions. In programming design, a control software system is divided into components that are made up of modules. The individual components design is determined by the full denitions of the object-oriented classes, class inheritances, class associations, and class aggregations used in the implementation, as well as the interfaces and algorithms of the methods used to implement the operations. A component is a reusable program building block that can be combined with other components in the same or other computers in a distributed network to form an application. DCOM and MMS specify the interfaces and message passing specication of components. The architecture mainly species the interfaces, interoperability and collaboration among the components of the AMS control system. As such, this enables the architecture to keep proper exibility for the application components and to allow the developers to have suitable and enough freedom in designing their control software. The client component can transparently call the methods of a server component. The server component can be made available either in the same address space or on a different computer system. The communication infrastructure is responsible for nding the server components, the transfer of parameters and the transmission of return values.

Fig. 6. DCOM and MMS combination architecture

6 DCOM and MMS combination

As mentioned before, the MMS standard is used in the control software as the message protocol between components and manufacturing devices and can be implemented independently. Likewise, the communication between those components is carried out by means of DCOM middleware. The combination of these standards implies an adaptation of the MMS standard to take advantage of the resources provided by DCOM. Therefore, the control software uses the main part of MMS, which is related to ASN.1 syntax and semantic of messages between manufacturing devices. DCOM denes communication mechanisms between the client components and the server components. Whereas the MMS standard only denes object services for realizing a means of achieving the standard specication of messages between components and manufacturing devices, which have to be distributed and supported via messages. MMS needs to be adapted to be used with DCOM. Here, the key elements of DCOM and MMS combination architectures are described. The combination architecture of object oriented manufacturing message services over a DCOM communication platform is shown in Fig. 6. The interface of MIDL specication is com-

pliant with the MMS service abstractions (ASN.1). MMS PDUs are dened as structures which are associated with MMS services specied using the ASN.1 syntax. Generally, MMS has four messages for each service: request, indication, response, and conrm (see Fig. 2). The DCOM environment needs methods and MIDL specications. MMS services are transformed in methods, the PDUs of MMS request are transformed in method parameters. The PDUs of MMS response are transformed in methods results. In this study, the active template library (ATL) is used to provide useful wizards to write the COM interface of MIDL specication and the associated entities for the COM class implementation and the MFC library provides the Windows classes and wizards for the denition of the users MIDL. In the ATL, ASN.1 specications can be translated into MIDL specications by hand. Appendix A denes an interface example of MMS domain service of ASN.1 to MILD by manual translation, and Appendix B describes an example of MMS domain service of ASN.1 to C++ language by manual translation. In DCOMMMS combination, the COM run-time provides MMS object-oriented services to clients and servers. The MMS client object is linked with the MMS server object through the COM library; RPC and the security provider are used to generate standard network packets of the MMS PDUs that conform to the MIDL specication for local or remote communication. MMS services correspond to method invocations, an interaction (remotely or locally) between MMS objects is formed by calling an invocation method and its corresponding conrmation method for the asynchronous result of the interaction (e.g., invocation method request with conrmation method conrm). In case the invocation method would be handled synchronously at runtime the calling object has to wait until the method returns the result. If a remote call fails, the result will be received after a timeout, which is handled by DCOM.

7 Control software development and implementation for AMS

Prototype control software of hierarchy in a distributed control system of AMS has been developed by the Institute of Production & Control Technique of Shanghai Jiaotong University using component software engineering concepts as described above. The

956 Fig. 7. Hardware conguration of the example for AMS

hardware congurations of the prototype example are shown in Fig. 7. The local area network (LAN), which is compliant with the TCP/IP protocol, supports the message-passing communication between personal computers (PCs). The terminal server linked with the LAN has its own IP address, and can be identied by dynamic address assignation. The manufacturing device controllers are connected with a terminal server by RS-232C lines and controlled by command sending MMS messages coming from PCs by way of LAN and terminal server. In the prototype, the software congurations include: MS Windows 2000 server and professional operating system, MS SQL server database, the ATLactive template library, the MFC-Microsoft foundation classes libraries, VC++6.0 programming environment and the components of the control system. An example of the control components for hierarchy in a distributed control system is shown in Fig. 8. The interface indicates that the DNC control component is taking as the

user client. In the DCOM environment, the DNC component can recongure and control remote CNC machine tools (the DNC object server is a dynamic link library (DLL) ). The DNC component and the DNC server can be in the same computer or on different computers that site across a LAN by the DCOM message-passing mechanism. The interfaces of other components are not further described here due to limited texts. The components of the control system have been tested in connection with the physical shop oor at Wuxi Professional Institute, the results indicate that the components not only conde in controlling all equipment operations in the running AMS, but also can independently control the equipment operations (for example, CNC machine tools operations or robots operations etc.).

8 Conclusion
A systematic approach for developing a DCOM and MMS-based control software architecture was proposed in this paper. Based on this software architecture, the methods of distributed components are integrated by employing the distributed object DCOM middleware and object-oriented concepts. In DCOM and MMS combination, DCOM provides the implementation basis for the message passing of components to components through welldened interfaces of MIDL specication; MMS provides the manufacturing message passing standard. Together with the software architecture, a prototype implementation environment is described in detail. The resulting prototype proves the effectiveness of the MMS standard, distributed object DCOM middleware and object oriented concepts in the design of component based control software architectures. The testing results indicate that the control software provides with interoperability, recongurability, and exibility to survive changes in its environment.
Acknowledgement This work was supported by the National Key Laboratory of Flexible Manufacturing System Technology, China (Grant No. 51458060104JW0316) and the National High-Tech. R&D Program for CIMS, China (grant No. 2003AA414120). The authors would like to express sincere appreciation to other working group members at the Institute of Production & Control Technique of Shanghai Jiaotong University for par-

Fig. 8. The user interface of DNC control component

957 ticipating in the prototype system development. At last, the authors would like to thank the Editor for his detailed and helpful comments to improve the quality of the paper. // MMSAMSSrv.odl : type library source for MMSAMSSrv.exe import "oaidl.idl"; #include "MMSDomain.h" // This le will be processed by the MIDL compiler // to produce the type library (MMSAMSSrv.tlb).

References
1. Wright PK (1995) Principles of open-architecture manufacturing. J Manuf Syst 14:187202 2. Sivaram B, Robert WB, Douglas HN (2001) An architecture for metamorphic control of holonic manufacturing systems. Comput Ind 46:1331 3. Cheng FC, Shen E, Deng JY (1999) Development of a system framework for the computer-integrated manufacturing execution system: a distributed object-oriented approach. Int. J Comput Integr Manuf 12(5):384402 4. Sameh MS (2003) The reconguration issues in manufacturing systems. J Mater Process Technol 138:277283 5. Najjari H, Steiner SJ (1997) Integrated and intelligent control system for a exible manufacturing cell. Proc 1997 IEEE, ISIE97, Guimaraes, Porgugal, pp 165170 6. Orest S, Shige W, Kang GS (2001) Modeling manufacturing control software. Proc 2001 IEEE, Inter. Conf. on Robotics & Automation. Seoul, Kourea, pp 40724077 7. Omar A, Richard W, Francisco M, Jose LA (1999) MCSARCH: An architecture for the development of manufacturing control systems. Int J Prod Econ 62:4559 8. Raymond SSC, Lee BS, Lim RL (1997) Design and implementation of an MMS environment of ISODE. Comput Commun 20:1351364 9. Lockemann PC, Kolsch U, Koschel A (1997) The network as a global database: challenges of interoperability, proactivity, interactiveness, legacy. Proc 23rd VLDB Conference, pp 567574 10. Gail-Joon A (2000) Role-based access control in DCOM. J Syst Archit 46:11751184 11. Manola F (1995) Interoperability issues in large-scale distributed object systems. ACM Comput Surv 27(2):268270 12. Gressier-Soudana E, Epiventa M, Laurent A (1999) Component oriented control architecture: the COCA project. Microprocess Microsyst 23:95102 13. Mansour I, Rondeau E, Divoux T (2001) Industrial systems communications: design and integration. Int J Comput Integr Manuf 14(6):545559 14. Sengoda GS, Terrence GB, Beaumariage C (1994) Manufacturing communication: a review of the MMS approach. Comput Ind Eng 28(1):121 15. Wu Q, Divoux T, Lepage F (1999) Integrating multimedia communications into an MMS environment. Comput Commun 22:907918 16. Weck M, Peters A (1999) Component based control software for distributed manufacturing. Prod Eng 1(2):117120 17. Ivica C, Magnus L (2002) Challenges of component-based development. J Syst Softw 61:201212 18. Zhou, BH, Xi LF, Cao YS (2003) Component-based control software design for exible manufacturing system. J Dong Hua Univ 20(1):8185 19. Yang CO, Guan TY, Lin JS (2000) Developing a computer shop oor control model for a CIM systemusing object modeling technique. Comput Ind 41:213238 20. Yang CO, Lin JS (1998) The development of a hybrid hierarchical/heterarchical shop oor control system applying bidding method in job dispatching. Robot Comput Integr Manuf 14:199217 21. Bongaertsa L, Monostorib LS (2000) Hierarchy in distributed shop oor control. Comput Ind 43:123137

[ uuid(7FE8804F-DD42-4BF3-9E95-F75E89F09D58), version(1.0) ] library MMSAMSSrv { importlib("stdole32.tlb"); importlib("stdole2.tlb"); // Primary dispatch interface for CMMSAMSSrvDoc [ uuid(6585D6FD-DC9F-47DA-9367-FA614BD85E55) ] dispinterface IMMAMSSrv { properties: // NOTE - ClassWizard will maintain // property information here. Use // extreme caution when editing this section. //{{AFX_ODL_PROP(CMMSAMSSrvDoc) //}}AFX_ODL_PROP methods: // NOTE - ClassWizard will maintain // method information here. Use // extreme caution when editing this section. //{{AFX_ODL_METHOD(CMMSAMSSrvDoc) //}}AFX_ODL_METHOD }; [ object, uuid(E4CB6B81-59FB-4ECF-BA2B-1365ECD1C777), dual, helpstring("IRMMSDomain Interface"), pointer_default(unique) ] interface IRMMSDomain : IDispatch { [id(1), helpstring("method DomainInitiateDownload")] HRESULT DomainInitiateDownload([in]InitiateDownloadSequence_Request Request); [id(2), helpstring("method DomainDownloadSegment")] HRESULT DomainDownloadSegment([in]BSTR DownloadSegment_Request, [out , retval]DownloadSegment_Response *retResponse); [id(3), helpstring("method DomainTerminateDownload")] HRESULT DomainTerminateDownload( [in]TerminateDownloadSequence_Request Request); [id(4), helpstring("method DomainInitiateUpload")] HRESULT DomainInitiateUpload([in]BSTR InitiateUploadSequence_Request, [out, retval]InitiateUploadSequence_Response *retResponse); [id(5), helpstring("method DomainUploadSegment")] HRESULT DomainUploadSegment([in] int UploadSegment_Request, [out, retval]UploadSegment_Response *retResponse); [id(6), helpstring("method DomainTerminateUpload")] HRESULT DomainTerminateUpload( [in] int TerminateUploadSequence_Request ); [id(7), helpstring("method RequestDomainDownload")] HRESULT RequestDomainDownload( [in]RequestDomainDownload_Request request); [id(8), helpstring("method RequestDomainUpload")] HRESULT RequestDomainUpload( [in]RequestDomainUpload_Request Request); [id(9), helpstring("method LoadDomainContent")] HRESULT LoadDomainContent([in]LoadDomainContent_Request Request); [id(10), helpstring("method StoreDomainContent")] HRESULT StoreDomainContent([in]StoreDomainContent_Request Request); [id(11), helpstring("method DeleteDomain")] HRESULT DeleteDomain([in] BSTR DeleteDomain_Request);

Appendix A
Interface example of MMS Domain service of ASN.1 to MILD manual translation between MMSDCOM Client and MMS DCOM Server is described as follows:

958 [id(12), helpstring("method GetDomainAttributes")] HRESULT GetDomainAttributes([in] BSTR Request, [out, retval] GetDomainAttributes_Response *retResponse); }; //{{AFX_APPEND_ODL}} //}}AFX_APPEND_ODL}} [ uuid(44F72E6E-ACEC-4B27-888E-04CF3C82C3F0), helpstring("RMMSDomain Class") ] coclass RMMSDomain { [default] interface IRMMSDomain; }; }; struct UploadSegment_Response // ::= SEQUENCE { CString loadData; bool moreFollows = true; // [1] IMPLICIT BOOLEAN // DEFAULT TRUE }; // TERMINATE UPLOAD //int TerminateUploadSequence_Request; // ::= Integer32 ULSM Identifer //TerminateUploadSequence-Response ::= NULL // REQUEST DOMAIN DOWNLOAD struct RequestDomainDownload_Request // ::= SEQUENCE { CString domainName; // [0] IMPLICIT Identier, //listOfCapabilities [1] IMPLICIT SEQUENCE OF // VisibleString OPTIONAL, bool sharable; // [2] IMPLICIT BOOLEAN, //leName [4] IMPLICIT FileName }; //RequestDomainDownload-Response ::= NULL // REQUEST DOMAIN UPLOAD struct RequestDomainUpload_Request //::= SEQUENCE { CString domainName; // [0] IMPLICIT Identier, //leName [1] IMPLICIT FileName }; //RequestDomainUpload-Response ::= NULL // LOAD DOMAIN CONTENT struct LoadDomainContent_Request //::= SEQUENCE { CString domainName; //[0] IMPLICIT Identier, //listOfCapabilities [1] IMPLICIT SEQUENCE OF // VisibleString OPTIONAL, bool sharable; //[2] IMPLICIT BOOLEAN, //leName [4] IMPLICIT FileName, //thirdParty [5] IMPLICIT // ApplicationReference OPTIONAL }; //LoadDomainContent-Response ::= NULL // STORE DOMAIN CONTENT struct StoreDomainContent_Request //::= SEQUENCE { CString domainName; // [0] IMPLICIT Identier, CString lenName; // [1] IMPLICIT FileName, //thirdParty [2] IMPLICIT // ApplicationReference OPTIONAL }; //StoreDomainContent-Response ::= NULL // DELETE DOMAIN //CString DeleteDomain_Request; //::= Identier Domain Name //DeleteDomain-Response ::= NULL // GET DOMAIN ATTRIBUTES //CString GetDomainAttributes_Request; //::= Identier Domain Name struct GetDomainAttributes_Response // ::= SEQUENCE { //listOfCapabilities [0] IMPLICIT SEQUENCE // OF VisibleString, DomainState state; // [1] IMPLICIT DomainState, bool mmsDeletable; // [2] IMPLICIT BOOLEAN, bool sharable; // [3] IMPLICIT BOOLEAN, CString listOfProgramInvocations; // [4] IMPLICIT SEQUENCE // OF Identier, PI Names int uploadInProgress; // [5] IMPLICIT Integer8 }; class CMMSDOMAIN { public: CMMSDOMAIN(); virtual CMMSDOMAIN();

Appendix B
Example of MMS Domain service of ASN.1 to C++ language manual translation is described as follows:
ifndef __MMSDOMAIN_H__ #dene __MMSDOMAIN_H__ //************ DOMAIN MANAGEMENT SERVICES ************ enum DomainState { non_existent, loading, ready, in_use, complete, incomplete }; struct InitiateDownloadSequence_Request // ::= SEQUENCE { CString domainName; // [0] IMPLICIT Identier, CString listOfCapabilities; // [1] IMPLICIT SEQUENCE OF // VisibleString, bool sharable; // [2] IMPLICIT BOOLEAN }; //InitiateDownloadSequence-Response ::= NULL //- DOWNLOAD SEGMENT //CString DownloadSegment_Request; // ::= Identier struct DownloadSegment_Response // ::= SEQUENCE { CString loadData; bool moreFollows = true; // [1] IMPLICIT BOOLEAN // DEFAULT TRUE }; //- TERMINATE DOWNLOAD struct TerminateDownloadSequence_Request //::= SEQUENCE { CString domainName; // [0] IMPLICIT Identier, // discard [1] IMPLICIT ServiceError // OPTIONAL }; //TerminateDownloadSequence-Response ::= NULL //- INITIATE UPLOAD //CString InitiateUploadSequence_Request; // ::= Identier Domain Name struct InitiateUploadSequence_Response // ::= SEQUENCE { int ulsmID; // [0] IMPLICIT Integer32, CString listOfCapabilities; // [1] IMPLICIT SEQUENCE OF // VisibleString }; // UPLOAD SEGMENT //int UploadSegment_Request; // ::= Integer32 ULSM Identier

959 // Attributes public: InitiateDownloadSequence_Request DOMAINInitiateDownload_Request; CString DOMAINDownloadSegment_Request; DownloadSegment_Response DOMAINDownloadSegment_Response; TerminateDownloadSequence_Request DOMAINTerminateDownload_Request; CString DOMAINInitiateUpload_Request; InitiateUploadSequence_Response DOMAINInitiateUpload_Response; int DOMAINUploadSegment_Request; int DOMAINTerminateUpload_Request; StoreDomainContent_Request DomainStore_Request; CString DeleteDomain_Request; CString GetDomainAttributes_Request; GetDomainAttributes_Response DomainAttributes; // Operations public: }; #endif __MMSDOMAIN_H__ // __MMSDOMAIN_H__