A generic embedded device for retrieving and ...

Procaedlngs ofthe 2004 IEEE Internatlmal Confennse on Robotics 6 Automallon New W a n S . LA -April 2004

A Generic Embedded Device for Retrieving and Transmitting Information of Various Customized Applications‘ Fan-Tien Cheng’ Guo-Wei Huang Chun-Hung Chen Institute of Manufacturine Eneineerine National Cheng Kungbniversity Tainan, Taiwan, ROC.

Index terms:Generic Embedded Device, e-Diagnostics, E-Maintenance. 1. Introdnetion In order to maintain the factory running efficiently and stably, all the hi&-tech manufacturers must prepare a huge budget for maintaining manufacturing equipment. And, the cost of equipment maintenance tends to go higher and higher with the continuous renovation of the equipment. Because the maintenance cost need to be wnsidered in the overall Foduction cost, the manufacturers require bener integrated maintenance management (IMM) systems for efficient cont~olof equipment maintenance cost. As such, the ovaall production cost may be efficiently r e d u d . A competent IMM system should be able to collect reaktime information from manufacturing equipment, so that it can execute the maintenance tasks according to the information collec~ed from equipment. Fa example, the system of maintenance performance auditing [I], is a maintenance system that bas been applied to semiconductor manufacturing. This system is able to propose maintenance suggestions according to the information collected from semiconductor manufacturing equipment [I]. Other maintenance systems, such as terotechnology [Z], total prcdudve maintenance [3], preventive maintenance [4]. condition based predictive maintenance [SI,

’ l k ~ m b o n d d l l l r l oW ! k N & m l f i d d l y nwnsOg U

1 Ibc ~

SI

LicorcCovndl oI&RcpblioofChio. M b &Cwmrt NO:NSC~9Z22lZGw6W.

W m t o . ( r - m r i l :[email protected]*.rn.

0-7603-8232-3/04/$17.00 @OM

IEEE

In

I_

etc., all rely on the information collected from equipment to support the executionof diagnosis and maintenance.

Abstract A Generic Embedded Device (GEO) that can be installed to various kinds of information equipment, sucb as manufachlring equipment, portal servers, automatic guided vehicles, etc., is successfully developed in this work. GED is equipped with an embedded rea-time operating system and several software modules to retrieve, collect, and manage equipment data. In particular, the communication management module of GED can bdnsmit and receive data to/from remote clients via both wired and wireless networks. Moreover, GED has an object-oriented application interface that flexibly enables GED to add-in or update any customized application. Three @ i d communication mechanism, namely the standard professes of exception notification, periodic inspection, and data inquiry are built in GED. As such, GED is able to handle a variety of customized applications, sucb as monitoring, detection, diagnostics, and prognostics of various kinds of information equipment. We believe that GED possesses the potentiality of information acquisition and transmission so that it can assist all kinds of information equipment to Each the goal of equipment-to-system (EZS) communication and facilitate the maintenance tasks.

Mm-Hsiung Hung Department of Elec&calEngineering Chunn - Chew - Institute of Techuoloev National Defense University Taoyuan, Taiwan, R O C .

A m o n g the researches for the applications of equipment information collection, many of them are based OD the technologies of embedded systems. Take the deviceto-business (DZB) idea proposed by the center of intelligent maintenance system (IMS) 161 as an example, a DZB device namely is a device designed with embedded system technology and also equipped with the function of collecting equipment information. However, detailed hardware architecture and sofhvare mechanism of a DZB device are not described in (61. Because an embedded system possesses the properties of distribution, real-time, and event-driven [71, the development of many computer-aided maintenance management systems [SI tend to be implemented on embedded systems. Moreover, embedded computing [9] is also the new direction in system architechre design and automation. The information collecting device designed with embedded system architecture has the properties of configurability, extensibility, and portability. Therefore, it can meet the product line goals [IO]. In addition, the applications of an embedded system can be distdbuted, dynamic, adaptive, and wireless. Thus, they can meet the information acquisition requirements of a manufacturing wmpany. Today‘s embedded systems are designed with network-centric approach [I I], and mostly adopt Web Services technology [I21 in the design of communication inframuchlre [13]. As for the skilk and technologies ofwllecting equipment information, CORBA [I41 is one of the most widely used communicatan protocols, and has been practically applied as a shop floor data bus for equipment wmmunication [15][16]. Recently, the real-time CORBA technology has also been developed. It is very suitable for applying to embedded systems [17]. Accarding to the survey mentioned above, we h o w that the approach of applying embedded systems to perform information acquisition of manufacturing equipment is the c m t tread, and CORBA is one of the most popular specification of interface connection adopted in the equipmenl end As for the external communication outside of equipment, mostly it is via IuternaYIntemet, and Web Services technology is most widely used in communicating with external systems.However, to the authors’knowledge, up to now, a complete generic embedded device system architecture which is able to integrate the technologies desmid above and possess the h c t i o m of information acquisition ftom manufacturing equipment and information transmission to the external systems may not exist. Therefore, the objective of this work aims at developing a Generic Embedded Device (GED) which can to be embedded to equipment for the putposes of information acquisition and transmission and supporting the functions of monitoring, detection, diagnostics, and

978

Authorized licensed use limited to: National Cheng Kung University. Downloaded on April 23, 2009 at 05:07 from IEEE Xplore. Restrictions apply.

prognostics. Except manufaciuring equipment, other information tools, such as various sewers, automated guided vehicles (AGVs), etc., also require preventive maintenance. Therefore, the GED developed in this work shall be applicable to all kinds of information tools mentioned above. For developing GED, we adopt the design pbilosopby of embedded systems and aim at reaching the goals of easy embedding and easy interfacing with all kinds of information equipment and edemal systems. The main purposeof GED is to provide equipment information to integrated maintenance systems. However, the existing researches of various embedded devices did not consider about how to manage and classify different infomation, and how lo process information transmission ailer the information is obtained from equipment. Therefore, another important subject of this work is to establish the standard processes of information acquisition and transmission. The rest of this paper is organized as follows. The functional requirements and development details of GED are described in Section 2. An e-diagnostics application example ofGED is presented in Section 3. Summary and conclusions are fmally made in Section 4.

2.12 Application Software Modules The s o h a r e architechre of GED is shown in Fig. 1. There M three main m d e s , Data Collector, Communication Manager, and Application (App). They are described as follows.

2. Development of the Generic Embedded Device The functional requirements of GED are described as follows: GED can be embedded into various kinds of information tools, such as manuf'cluring equipment, different kinds of servers, AGVs,etc. GED can interface with various kinds of equipment with equipment-dependent device drivers. GED can communicate with external systems via wired or wireless Intranethtemet. 0 GED possesses a built-in application interface such that various customized application software modules (for the purposes of monitoring, detection, diagnostics, prognostics, aC.)can be included in the GED. GED shall possess three built-in information acquisition and transmission mechanisms, namely the standard processes of exception notification, periodic inspection, and data inquiry. With these three mechanisms, GED can meet the goal of equipment to system (EZS) communication. Beside upon the requirements described above, GED is developed as follows.

2.1 System Architecture ofCED This GED includes hvo main portions, the operating environment built with the embedded real-time operating system and application software modules developed with object-orienbted technology. They are described below.

21.1 Embedded Real-time Operating System The embedded real-time operating system is &"eloped based upon embedded Linlur technology [I 81, which can apply open source to consbuct system soffware infrasbuchue and have abundant free software for providing application solutions. The system software modules include r d t i m e scheduler, TCPilP stacks, memory management, Java environment, etc. This embedded real-time operating system can be developed into disk-on-module, disk-on-chip, or compaa flash, and can run under the environments of a single board system, such as ARM, MIPS, or PowerPC.

Figure 1. Software Architechue of Generic Embedded Device Data Collector is the component responsible for information acquisition and management. It includes hvo sub-companenls, Collection Plan and Device Driver. Collection Plan is equipment-independent and responsible for managing and classifying information retrieved from Device Driver. The SEMPs provisional specification for dab collection management I191 and equipment services description [ZO] may serve as the design guides for designing Collection Plan. Device Driver is equipmentdependent and is in charge of collecting information from equipment via the methods described below: 0 Standard serial interfaces, such as RS232, RS485, etc. 0 Standard network protocols with TCPilP-wired m TCPAP-wireless. such as IEEE 802.11a IEEE 802.11b. Bluetooth, etc. Industlydefmed specifications, such as OPC, SEMI SECS I (w), SECS II ( ~ 5 j GEM , (E~o),HSMS (~371, OBEM (EW, CEM (ElZO) [ZI], etc. for semiconductor or electronic industries Self-defined messages, such as file transfer,etc. Communication Manager is the component responsible for managing wmmnnication. It includes three sub-components: Communication Agent, Collection Interface, and Application Interface. Collection Interface is in charge of interfacingCollection Plan component of Data Collector. V ICollection Interface, the equipment information sent by Data Collection is hansmitled to App through Application Interface or to external systems thmugh Communication Agent Application Interface is the application program interface that wnnects App to GED. App wntains one of various customized modules far the applications of monitoring, detection, diagnostics, or prognostics, etc. Communication Manager relies on Communication Agentfor

979

Authorized licensed use limited to: National Cheng Kung University. Downloaded on April 23, 2009 at 05:07 from IEEE Xplore. Restrictions apply.

transmining the equipment information to extemal systems, and vise versa. Communication Agent can adopt SOAP or Web Sewices specifications to transfer the information to the other end of Intranethtemet via wired m wireless wmunication The Web-Service Agent proposed in OUT previous work [22] is a good reference for the design of Communication Agent Other wmmunication specifications such as CORBA, DCOM, or RhQ ace also adaptable.

I

II 1

I

I

I

II

I

2.2

M e c h a n i s m of Information Acquisition and Transmission We have designed three standard models for the mechanisms of information acquisition and hammission of GED, i.e. the processes of exception notification, periodic inspection, and data inquiry. We respectively describe these three standard processes as follows.

I

I

I

I I

I

'II

I

1-

I

I

!

I

I

I

I

lnarad

I

I

2.2.1 Process of Exception Notification

I

I

Di

DD E1

e

I I

I

I

I

I

I

I

The process of periodic inspection is depicted in Fig. 3. This process is activated by App for the .~ purposes ofmonitoring, detection, &agnostics, m prognostics. This periodic inspection process includes three Steps. Step I generates a data collection plan, Step U collects data,fmally Step 111 analyzes and evaluates data. AAer obtaining the inspection result, this result is sent to ES. The detailed scenarios of Steps I, U, and In are d m i below. In Step I, App invokes submifRequesfOof Al to submit the request for a periodic inspection. Then, this request is passed to CI by calling de/iverRequestInfoO.And then, CI requests C P to set data type, buffer size, and sfart time by invoking serDmaTYpe0,selB~@eW), and sefStmTimeO. M e r these parameters are set properly, C P then generates a data mUection plan by calling neareoOraCo//ecfP/anO. In Step 11, App sends request to CI for wUecting equipment data by invoking request/orDafaOof AI and reque&oorDafaO of CI. CI, then, requests C P to s m data collection plan by invoking StwfDataCollectP/anO. Thus. C P starts to wllect equipment data by calling stm?DotoCollectO of DD and getData0 of Eq. ARer the essential equipment data are wllected, C P stam to classify and filter these data by invoking classi~&firterDataO. Finally, the data classified and filtered are sent to App for further pmcessing. In Step 111, App starts to analyze and evaluate data by invoking analyzeDafa0. The inspeaion result is then sent to ES by invoking submitSfdus0 of Al, sendSfams0of C 4 and sendSfafus0of ES.

z" , CP

I I

2.2.2 Process of Periodic Inspeetion

9

c1 04

I

Figure 3.Process of Periodic Inspection

The sequence diagram of exception notification is s h o w in Fig. 2. This process is initiated bvEauiDment (. E ..d . . . When an exception occurs to Eq, Eq invoke deliverExcrpfron0 of D e v m Driver (DD) to p u s this exception message IO Data Collection (DC). Then, DD calls Clarr~&/ilrrrErcepr,onO of Collection Plan (CP) to classify and filter this exception. ARer classification, his exception is sent to Collection Interface (Cl) of Communication Manager (CM) by invoking rmdExceprionlnfo0. At his s@, CI may chwse to smd this exception message to Application (App) by calling receivcExceprionln/o()of Application Interface (AI) and ano/~reErceprion/nfoO of &p for malyzlng and handling this exception. AAcr completing the analysis, App. thm sends the analyzing results to External System (ES) thmugh invoking .suhmirSrorur(j of AI. sendSrarurfi of Communication Agent (CA), and srndSfofus0 of ES. If analysis by App IS not necessary. CI may choose to send the exception directly to ES by &g .scnd&ceprronlnfo(j of CA and rendExceptiodnfo0 uf ES.

---_ ----

I

UIW0-

I

I

I

I

Figure 2. Process of Exception Notilieation

980

Authorized licensed use limited to: National Cheng Kung University. Downloaded on April 23, 2009 at 05:07 from IEEE Xplore. Restrictions apply.

2.2.3 Process of Data Inquiry The sequence diagram of data mquity is displayed in Fig. 4. The process of data inquiry is mainly requested by ES for acquiring the Eq data. Similarly, this process has three Steps. Because ES may be located at the other end of Internet, for security reasons, the request sent from ES shall be examined in Step I by calling submifRequest0 of C& identi&) of CI, and outhenticoleo of CI. Step n of the data ins+ process is to generate a data collection plan, The scenario of this step is similar to that of Step I of the periodic inspection process. Finally, Step 111 of Be data inquj. process is to acquire data. Again, the scenario of this step is similar to that of Step II of the periodic inspection process

I

23 Class Diagram of GED Based upon the functional requirements, system architecture, and information acquisition and transmission mechanism mentioned above, the class diagram of GED is designed. As shown in Fig. 5 , six classes are included in the GED's class diagram. They are: 0 Application Interface (AI) (sub-module of CM) 0 Communication Agent (CA)(sub-module of CM) 0 Collection Interface(Cl) (sub-module of CM) 0 Collection Plan (CP) (sub-module of DC) 0 Device Driver (DD) (sub-module of DC) 0 Application (App) In addition, two other relafed classes, Eq and ES, are also displayed in Fig. 5.

Figure 5. Class Diagram of GED Observing Fig. 5 , it is clear hat Eq and DD have mutually one-tc-one dependency relationship; while ES and CA possess mutually one-tummy dependency relationship. All the other relations among those classes inside GED are one-tmne association relationships. Due to the design mentioned above, we h o w that each Eq should have exactly one DD to connect to, and each ES may communicate with one to multiple CAS, and each CA may also communicate with one to many ESs. Apparently, this design meets the interface requirements of GED with Eq and ES. A s for those classes inside GED, their associated methods are designed according to those methods shown in the sequence diagrams (as in Figs. 2, 3, and 4) of the GED's information acquisition and transmission mechanisms.

3. Application Examples The GED is applicable to a variety of fields, such as: (I) Embedded in a manufachlring equipment, thus, we are able to execute monitoring. ermr detection and diagnosis, preventive maintenance, etc., on the equipment both I d l y and remotely. (2) Embedded in all kinds of servers, this enables the server itself or an external system to detect errors or performance degradalion of that server and do error-recovery or fault-tolerant considerations; hence the service quality and reliability of the server can be improved. (3) Embedded in an AGV, this enables the AGV itself or an extemal system to monitor the AGVs status, and detect and diagnose errors.

Figure 4. Process of Data Inquiry

981

Authorized licensed use limited to: National Cheng Kung University. Downloaded on April 23, 2009 at 05:07 from IEEE Xplore. Restrictions apply.

example is for the purpose of ediagnostics and emaintenance. Three application examples that apply the three mechanisms of information acquisition and transmission are described below. Example 1. Exception Notification As an exception or error DECUTS to CEM equipment, the equipment follows the process of exception notification and sends the exception information to App (Diagnosticshlaintenance)module via DC and CM. Then App sends the report of exception status to MES in the factory side by CAmdule of CM Example 2. Periodic Inspection By applying the periodic inspection process, the purposes of prognostics and preventive maintenance be fulfilled. To begin with, App decides the Supplierside can inspection period and passes the inspection request via CM to C P of DC for setting up the data collection plan. After the wllection plan is created, Remote via CM and DC, App SMS retrievingdata from the Diagnosfld equipment periodically. Then, with the data wllected from the equipment, App executes the analysis of prognostics and preventive maintenance Till the (RDMS, analysis is completed, App generates the status report and delivers the report to MES via CAmdule. Example 3. Data Inquiry As some diagnosis or maintenance problems occur, and App of GED is unable to solve the problems locally. The factory will ask the supplier CEYEpulpm.rd for assistance. At this moment, the supplier may *IthWn.dsEnb.dd.dO.v*.. Internet follow the process of data inquiry, to ask its RDMS module to make a data inquiry request to the unhealthy equipment in the f&& side. Because, Figure 6. Applic~tionExample of Applying GED to e-Diagnostics and the data inquiry request is an external message e-Maintenance of Semiconductor Manufacturing Q u i p m e n t sends by RDMS via Memer for security consider&ons, the request needs to de In this example, GED adopts Web Services as the specification of authenticated by CI of CM fmt, and then RDMS is allowed to information integration with ES. Therefore, MES or RDMS can obtain execute the process of data inquiry. After Seiving the related data from CEM equipment with the protocol of SOAP Since GED information of the data inquiry request sent by RDMS, CM passes supports the wired and wireless networking technologies, MES or them to C P of DC for setting up the data collection plan. Then, RDMS is able to obtain information fmm GED wired or wireless. RDMS is able to retrieve data from Eq via CM and DC. After ES Figure 7 presents the information integration arcbitecture diagram completes the data retrieving, the analysis of diagnosis and ofapplying GED to e-diagnostics and emaintenance of semiconductor manufacturing equipment: As shown in Fig. 7, a GED is embedded in each CEM equipment with DD adopting CEM interface specification [23] to retrieve equipment data from the equipment. The SOAP protocol of Web Service is applied to serve as the wmmunication infmshucture of this information integration architechlre. Each server (such as GED, MES, or RDMS) all equips with a Communication Agent [ U ] that takes care of all the communication requirements among the sewers by utilizing the web services description language (WSDL) [24]. The App module illustrated in Fig. 7 is replaced by a DiamosticsiMaintenance l h e example of applying GED to ediagnostics and e-maintenance of semiconductor manufacturing equipment is shown in Fig. 6. In this application example, we install GED to equipment whose interface specification is defined by SEMI CEM (EIZO) [23]. Using CEM standard,GED can retrieve data from the equipment, and provides the wllected data to the maDufacturing execution system @ES) at the factory side via Inhanet, or remote diagnosticd-tenance sewer (RDMS) at the supplier side via Internet.

Figure 7. Information Integration Architecture of Applying GED to e-Diagnostics a n d e-Maintennnre nf Srmirnnrlnrtnr Mannfwhtrinv Fniiinment

Authorized licensed use limited to: National Cheng Kung University. Downloaded on April 23, 2009 at 05:07 from IEEE Xplore. Restrictions apply.

maintenance can be executed remotely. The data inquiry process mentioned a h w e is, actually, the so call ediagnostics/e-mamtenance process. 4. Summary and Conclusions A GED for retrieving and tansmining information of various customized applications is developed in this work. Three main modules namely DC, CM and App are included in GED. DC has an equipmeatdependent DD that connects directly with a specific equipment by following the interface specification associated with that specific equipment. This interface specification may be wired or wireless. Also, DC has a equipment-independent C P that can generate a data collection plan according to the requirements specified by App or ES. The function of CM is to transmit the infomation to the right destination. CM has three interface ports namely CI, AI, and CA for interfacing with DC, App, and ES, respectively. CAmay adopt the specification of SOAP,CORBA, RMI, or DCOM to interface with ES wired ‘0 wireless. Customized applications can be included into App to accomplish the goals of monitoring, detection, diagnostics, or prognostics of equipment. It is believed that by embedding GED into any kind of information equipmen< we can enable this equipment to reach the goal of equipment-to-system c2S) communication and help maintenance engineers to achieve the pluposes of monitoring, detection, diagnostics, prognostics, and preventive maintenance of the equipment effectively and efficiently.

References [I] P. Y. L. Tul, R. Yam,P. Tse and A 0. W. Sun,“An Integrated Maintenance Management System for an Advanced Manufacturing Company,” Infemationol J o m a l of Advanced Maiufbcturing Technology, 17(9), pp. 692-703.2001.

191

B. R. Rau and M. S. Schlansker, “Embedded Computing: New Directions in Architecture and Automation,” in hfernational Confmence on High Peformance Computing, LNCS 1970, pp. 225-244,2000.

[IO]

R. L. Nor4 “Meeting the Product Line Goals for an Embedded Real-Time System,” in Intemafional WorRrhop on Softwore ArchitecturesforPro&tFamilia, LNCS 1951, pp. 19-29,2000.

[I I]

D. E. Culler, J. Hill, P. Buonadonna, R Szewczyk and A. Woo, “A Network-Centric Approach to Embedded Soffware for Tiny Devices,” in International Conference on Embedded Sofiare 2001, LNCS2211,pp. 114-130,2001.

[I21 J. Roy and A. Ramanujan, “Understanding Web Services,” IT Professional, vol. 3, pp. 69-73, Nov.-Dec. 2001. [I31 P. Siddhartha and S. Seogupta, “Web Services Interoperability: A Practitioner’s Experience,” in InfernafionolConferences on DOA, CoopIS and ODBASE 2002, LNCS 2519, pp. 587-601, 2002. [I41 OMG, The Common Object Request Broker: Archilecture and SpeciJTcarion,Revision 2.2, Object Management Group, 1998. [IS] F.-T. Cheng k d M.-T. Lin, “Enbancement of Semiconductor Equipment Commlmications using a Webenabled Equipment Dn&: /E€,? Transadtom on Se&ondurror Afanu/ach&g, vol 11,no 4, pp 372-380, N o v e m k 2001 [I61 F.-T. Cheng and C.-Y. Teng, “An Object Based Controller for Equipment Commlmications in Semiconductor Manufacturing,” Robotics and Compufer-IntegmfedMan~acturing,vol. 1815-6, pp. 371-386, October 2002.

[2]

E. N. White. Maintenance Planning, Documentofion,Grower Press, 1979.

[3]

S. Nakajima, TPM Development Progrom, Implementing Tolal Productive Mainlenance, Productivity Inc., 1989.

[4]

:. Schmidt, “Preventive Maintenance of D. Gude and KH Advanced Manufacturing Systems: A Laboratory Experiment and Its Implications for the Human-Centered Approach,” International Journal of Human Facfors in Manufacturing, x4), pp. 335-350, 1993.

[I81 J. Lambardo, Embedded Linux, New Riden Publishing, July

R. C. M. Yam, P. W. Tse, L. Li and P. Tu, “Intelligent Predictive Decision Support System for Condition-Based Maintenance,” International Journal of Advanced Manufacfuring Technoloa, 17(5), pp. 383-391,2001.

[ZO]

[SI

Confrol

and

[6]

Center of Intelligent Maintenance System (IMS), “IMS Annual Report”, http:llwww.imscenter.net, U.S.A., 2002.

[71

I. A. Stankovic, “Reflection in Red-Time Systems,” in Infernational conference on Meta-Level Architectures and Refection 1999, LNCS 1616, p. 1, 1999.

[8]

R. Jones, “Computer Aided Maintenance Management System,” InferndionalJournal ofMninrenance & Assef Manoxemenf, 9(2), 1994

[I71 A. Cervieri, R. S. de Oliveira and C. F. Resin Geyer, “An Adaptive Scheduling Service for Real-Time CORBA,” in Infernational Confeencs on DOA. CoopIS and ODBASE 2002, LNCS 2519, p. 884-899,2002. 2001.

[I91 SEMI DraA Doc.#3509, Provisional Sped~catioonfor Data Collection Mawgemenf,U.S.A. 2002. SEMI Draft Doc.#35 IO, Provisional Spec$cation/or Equipment Services Description, U.S.A., 2002.

[21] SEMI, SEMI International Standards CD-ROM, Semiconductor Equipment and Materials International, 2001.

[22] M.H. Hung, F.-T. Cheng, and S.X. Yeh, “Developing a Websmices-based eDiagnastics Framework” in Proc. 2003 IEEE Infernational Confmence on Robotics md Automation, Taipei, Taiwan, R.O.C., pp. 596-6503, September 2003. [23] Common Equipment http:l/www.semi.org.

Model

(CEM),

SEMT

[24] WSDL Specification. h ~ : / / ~ v w . w 3 c . o r ~ ~ t r / w s d l

983

Authorized licensed use limited to: National Cheng Kung University. Downloaded on April 23, 2009 at 05:07 from IEEE Xplore. Restrictions apply.

EI20.