Design and Implementation of a Data Exchange Platform for TFT-LCD Virtual Production Control Systems

Design and Implementation of a Data Exchange Platform for TFT-LCD Virtual Production Control Systems

Min-Hsiung Hung*, 1, Yu-Chuan Lin2, Shih-Hao Li2, Haw-Ching Yang3, and Fan-Tien Cheng2

1Department of Computer Science and Information Engineering, Chinese Culture University, Taiwan
2Institute of Manufacturing Information and Systems, National Cheng Kung University, Taiwan
3Institute of System Information and Control, National Kaohsiung First University of Science and Technology, Taiwan

(Received 15 October 2011; Accepted 10 February 2012; Published on line 1 June 2012)
*Corresponding author: hmx4@faculty.pccu.edu.tw
DOI: 10.5875/ausmt.v2i2.121

Abstract: To solve the problems of delivery shortages and excess product inventories, the TFT-LCD manufacturers and their suppliers need to share production planning data, such as work in process (WIP) data, shipping demands, shipping plans, just-in-time (JIT) material demands, etc. In this paper, we develop a production planning data platform, called PPDEP, to fulfill such a demand. Specifically, a production planning integration server (PPIS) is constructed in each enterprise which communicates with other enterprises through the RosettaNet standards and integrates with internal systems through a designed generic application adapter and interface database. We also draw up a systematic PIP implementation procedure in this paper. In order to verify its effectiveness, the PPDEP has been practically applied to the factories of our cooperative TFT-LCD enterprises, Chimei Innolux (the manufacturer) and Himax (the supplier) to deliver data for a virtual production control system (VPCS) and to exchange B2B data for executing production planning applications. Testing results show that the PPDEP has a good performance record in delivering data for the VPCS. Also, the VPCS leveraging of the PPDEP can make it easier for the manufacturer to effectively monitor and project the production of the supplier in an active and timely manner.

Keywords: Data Exchange Platform; Production Planning; RosettaNet; TFT-LCD; Virtual Production Control System

I. Introduction

Currently, the panel industry has transformed itself into a multi-role specialization business model. Different companies specialize in the design or manufacture of different parts of final products. The production qualities of components, semi-finished products, and final products in all stages of the panel manufacturing processes can then be enhanced, thereby reducing the manufacturing costs. For example, in the manufacturing of TFT-LCD panels [1], the manufacturers produce LCD modules and buy other components, such as driving ICs and backlight modules from their suppliers to assemble the final products to be shipped to their customers.

According to the Global Competitiveness Report 2009-2010 [2] of the World Economic Forum, Taiwan's cluster development ranks sixth in the world. Thus, “Industry Cluster” is an important way to enhance the competitiveness of Taiwan's panel industry. In the production environment of industry clusters, upstream and downstream firms may form a supply chain due to the relationship of supply and demand. However, supply chains are typically subject to a bullwhip effect, which refers to a trend of larger and larger swings in inventory in response to oscillating demands in the supply chain for a product. To reduce the bullwhip effect on inventory, a manufacturer can share its material demand forecast with its supplier and authorize the supplier to manage manufacturer-side inventory, which is called the vendor managed inventory (VMI) [3, 4] model. By adopting the VMI model, forecast and authorization capabilities enable a supplier to produce and deliver material on time as well as maintain an agreed upon inventory of materials on the manufacturer side.

The VMI model can reduce the material shortage on the manufacturer side; however, the inventory problem is deferred to the supplier side when the supplier and manufacturer relationship is unequal. This occurs because manufacturers typically assume that their suppliers have unlimited capacity to respond to arbitrary material demand changes, which can be caused by several factors, such as market variation, forecast error, and production variation. When using the VMI model, suppliers need to keep large material inventories in order to be able to adapt to and meet the manufacturer’s demand changes, thereby shifting the bullwhip effect to the supplier side.

The supplier-side bullwhip effect [5] is mainly caused by manufacturer-side forecasting errors and production variations, both of which can be decreased by sharing work in process (WIP) information from the suppliers more completely and precisely. The completeness refers to complete sharing of production progress information with the manufacturer, whereas precision refers to sharing information with sufficient time resolution for estimating material production progress. If a manufacturer can receive complete and precise WIP information from the supplier, allowing it to identify production characteristics, i.e. capacity and throughput, and can factor these characteristics into subsequent demand changes, the manufacturer can reduce forecast errors and production variation and can freeze demands in the short-term. With frozen short-term demands, a supplier can effectively cut the material inventory which was reserved to respond to demand changes.

Based on these concepts, the authors proposed the virtual production control system (VPCS) [6], which is allocated on the manufacturer side to virtually evaluate and control the supplier-side’s production utilizing WIP information. The production control flow with the VPCS is shown in Figure 1. When a customer’s order changes, the VPCS allows the manufacturer to collect WIP information from the supplier to evaluate demand changes, production risk, and capacity bottlenecks. If a demand change is issued, the VPCS supports both sides to negotiate this change before it is released.

In the current domestic TFT-LCD industry, most manufacturers adopt traditional methods, such as e-mail, telephone, and the Web portal, to communicate with their suppliers. Figure 2 shows the typical communication paths for exchanging production planning data between a manufacturer and a supplier in the current domestic TFT-LCD industry. Firstly, according to the agreement with the manufacturer, the supplier periodically sends its WIP data to the manufacturer by e-mail. The manufacturer manually processes and keys WIP data into its MRP (Material Requirement Planning) system.

Secondly, in the case of middle to long term demands for materials, the manufacturer sends shipping demand forecasts [7, 8] to the supplier twice a month by e-mail. After receiving the shipping demands, the supplier is required to reply by e-mail to confirm the order. For short-term material demands, the manufacturer may adjust shipping demands and then send them to the supplier twice a week by e-mail. After accepting these shipping demands, the supplier sends the corresponding shipping plans to the manufacturer by e-mail.

Thirdly, when requiring just-in-time (JIT) materials, the production department of the manufacturer can use the ERP system to generate a JIT request and send it to the material management department. The JIT request is then sent to the supplier by e-mail. When receiving the JIT request, the supplier needs to log into the Web-based e-Procurement (EP) system of the manufacturer to provide the manufacturer with the shipping plan and to get an advanced shipment notification (ASN). Then the requested materials, along with the ASN, are shipped to the manufacturer. After checking on the delivery, the manufacturer manually updates the related information in the EPR system.

The above-mentioned traditional methods for exchanging production planning data possess several drawbacks. First, when the receivers obtain the data, they need to manually key that data into the back-end systems. This is inefficient and may cause errors in the data. Second, there are no common communication processes and data formats for delivering information through e-mail and Web portals. The manufacturer needs to transform the data of each supplier into desired formats manually or through customized interfaces, which may result in erroneous data or increase the manpower burden.

To overcome the above-mentioned shortcomings, this study developed a production planning data exchange platform, called PPDEP, for the TFT-LCD industry. Specifically, an off-the-shelf enterprise integration software package, called webMethods, was employed as the operational kernel and development tool for B2B communication and internal integration. Then, several RosettaNet PIP (Partner Interface Process) standards [9, 10] were adopted to implement the B2B communication [11, 12] services for exchanging production planning data. To validate its effectiveness, the PPDEP has been practically applied to the factories of our cooperative TFT-LCD enterprises, Chimei Innolux (the manufacturer) and Himax (the supplier) to deliver data for the VPCS and to exchange B2B data.

The rest of the paper is organized as follows. Section II describes the architecture design of the proposed PPDEP. Section III presents the core functional mechanisms in the PPDEP. A PIP implementation procedure is depicted in Section IV. Integrated testing and system performance are shown in Section V. An enterprise application example of the PPDEP is illustrated in Section VI. Section VII discusses and highlights the differences and contributions of the paper as compared to those in the literature. Section VIII is the summary and presents the conclusions of the paper.

II. Architecture Design of the proposed PPDEP

The architecture of the proposed production planning data exchange platform, PPDEP, for the TFT-LCD industry is designed as shown in Figure 3.

First, within the manufacturer and the supplier, the PPDEP needs an integration server, hereafter called a production planning integration server (PPIS). The PPIS is responsible for exchanging production planning data with the PPISs of other enterprises. It also needs to integrate various internal information systems. In this paper, the production planning data exchanged contain WIP data, shipping demands, shipping plans, JIT material requests, advanced shipment notifications, and receipt notices.

Data exchanges happening in an enterprise can be categorized into two types: B2B (Business to Business) and internal. B2B data exchange refers to the exchanging of data among cooperative enterprises. B2B data exchange activities are referred to as public processes because open standards are often adopted to enable enterprises to exchange business data without needing to define their own data formats and protocol specifications. Currently, the RosettaNet standards are widely used in the supply chains of many high-tech industries. Consequently, the proposed PPDEP adopts several RosettaNet PIP standards in order to effectively exchange production planning data between LCD manufacturers and their suppliers.

By contrast, an enterprise usually utilizes proprietary methods to exchange data among its internal information systems. Hence, these internal data exchange activities are referred to as private processes. To reduce the complexity of integrating back-end systems and to avoid affecting the systems in the production run, the PPDEP adopts an interface database approach, which will be detailed later, for integrating the PPIS and back-end systems. When the PPIS requires sending data to a back-end system, it will save those data into the interface database, and the back-end system can then acquire that data from the database. Similarly, when a back-end system needs to send data to the PPIS, it will store those data in the interface database, and the PPIS can then access the database to obtain that data.

In order to build a simulated B2B environment to test and validate the various designed data-exchange functions, the PPDEP possesses simulated ERP-system graphical user interfaces (GUIs) on the manufacturer side and on the supplier side. The simulated ERP-system GUI can let the users query and display various production planning data. Also, the GUI can allow the users to select and send data for B2B production planning. The data transmission results can be displayed on the GUI as well.

III. Design of PPDEP’s Core Components

This section describes the design of core components in the PPDEP, including the production planning integration server, B2B data exchange processes, the generic application adapter, the interface database, and the simulated ERP-system GUI.

Design of the Production Planning Integration Server

The functions of the production planning integration server, PPIS, are complicated because the PPIS needs to exchange production planning data with the PPISs of other enterprises and integrate various internal information systems. Thus, building the PPIS from scratch is not a smart way to proceed. Instead, adopting mature off-the-shelf enterprise integration software to construct the PPIS is a better approach in terms of development time, construction cost, and system reliability.

In this study, webMethods [13], one of the most widely used enterprise integration software packages, was adopted to construct the PPIS. The major components of webMethods include an Integration Server, a Developer, a Modeler, and a Trading Networks Console. The Integration Server, which is the core of the PPIS, is based on the SOA (Service Oriented Architecture) concept to provide various services for exchanging B2B data. The user can configure and manage the Integration Server using Web GUI. Also, various adapters of webMethods can be used to effectively integrate internal applications within the enterprise. In addition, several functions of webMethods, such as mapping data, supporting multiple communication protocols, and managing the profiles of trading partners, were used in constructing the PPDEP.

Design of B2B Data Exchange Processes

To design the B2B data exchange processes, the underlying production planning processes need to be analyzed, and appropriate RosettaNet PIPs are then chosen to construct the corresponding B2B processes and deliver the associated production planning data. The B2B processes for exchanging production planning data between our cooperative LCD manufacturer and the driver IC supplier are shown in Figure 4 and are taken as an example to illustrate the design.

In Figure 4, manufacturer production planning activities, such as collaboration, JIT requests, and receipting, are listed on the left-hand side, while on the right-hand side the corresponding activities of the supplier: production, shipping, and receipting are listed. The arrows in the middle represent the data flows and material flows.

First, for monitoring the production status of the WIP of the supplier so as to conjecture whether the supplier can ship the ordered products on schedule or not, the manufacturer usually asks the supplier to periodically send back various WIP data. After the manufacturer’s material management staffs receive the WIP data, they can then perform production planning and estimate the production capacity of the supplier accordingly, by using the VPCS. Among the RosettaNet PIPs standards, the PIP 7B1 was utilized to implement the B2B data exchange service to deliver WIP data from the supplier to the manufacturer.

Second, to prevent the supplier from running into the condition of overproduction or not being able to ship products on schedule, the manufacturer and the supplier must coordinate future demands for materials and product shipments. The manufacturer can forecast the material demands of one week to one month according to its production strategy and the production capacity limits of the supplier. Based on the material demand forecasts, the manufacturer sends shipping demands to the supplier.

After receiving the shipping demands, the supplier replies to the manufacturer with shipping plans based on its production and inventory statuses. After analyzing the RosettaNet PIPs standards, the PIP 4A4 was employed to implement the B2B data exchange service to deliver shipping demands from the manufacturer to the supplier, whereas the PIP 4A5 was employed to implement the B2B data exchange service to deliver shipping plans from the supplier to the manufacturer. After the manufacturer and the supplier agree on the shipping demands and shipping plans, the supplier proceeds to manufacture its products according to the production schedule. When requiring parts, like driving ICs, for assembling final products, like LCD panels, the manufacturer makes a JIT material release request to the supplier according to the items and the quantities in the shipping plans. Then, the supplier ships the requested products and sends a shipping notice to the manufacturer. After receiving the products, the manufacturer sends a receipt notice to the supplier. Among the RosettaNet PIPs standards, the PIPs 4D1, 3B2, and 4B2 were used to implement data exchange services for JIT material releases, shipping notices, and receipt notices, respectively.

Design of Generic Application Adapter

In this study, webMethods was chosen to construct the PPIS. Although webMethods has many functions for system integration these functions may not be suitable for integrating the PPIS with some internal systems in an enterprise. In order to conveniently integrate various internal systems and to apply the PPDEP to an enterprise that possesses low information capability, a type of generic application adapter was developed. The generic application adapter is a fast-construction, low-cost, and low- threshold approach for integrating various back-end systems.

The design concept of the generic application adapter of the PPIS is shown in Figure 5. An intermediate database, called an interface database, was created between the PPIS and the back-end system. Then an appropriate database adapter of the webMethods Integration Server was used to connect with the interface database. A data mapper may also be constructed to convert the data formats between the PPIS and the interface database.

In this way, the PPIS can integrate with the back-end system without needing to modify the programs of the back-end system. If a different type of interface database is used, just the database adapter needs to be replaced. Most systems can be integrated using a generic application adapter, thereby achieving the objective of low-cost and fast-construction system integration.

Design of Interface Database

Before the interface database of an enterprise can be designed, some pre-tasks must be completed, including analyzing the existing back-end systems, compiling the data items used in current production planning activities, and defining the internal communication messages. These pre-tasks are described as follows.

• Analyze the existing back-end systems:

The purpose of this task is to analyze the existing back-end systems related to the production planning activities and to associate the back-end systems with the appropriate PIPs. For example, the existing back-end systems with the associated PIPs of our cooperative enterprises in the TFT-LCD industry are shown in Figure 6. As shown in the figure, the LCD manufacturer possesses a virtual production system, which can exchange data through PIP 7B1 and a material requirement planning system, which can exchange data through PIP 4A4.

• Compile the data items used in production planning:

The purpose of this task is to compile the data items and their formats used in the current production planning activities of the TFT-LCD industry. The data sources include e-mails, excel and word files, and schemas in the database.

• Define the internal communication messages:

The purpose of this task is to define the internal communication messages between the PPIS and the back-end systems based on the B2B data shared between the manufacturer and the suppliers.

To design the interface database, a header table and a data table were created to store the data of each PIP. The header table contains the information, such as data version, transmission status, PIP’s ID, etc. The data table holds the data to be transmitted through that PIP. Both tables are related by the ID of the PIP. Figure 7 shows the sample schemas of the header table, RN7B1_LIST, and the data table, RN7B1, for PIP 7B1 in the interface database.

Design of Simulated ERP-system GUI

The design of the simulated ERP-system GUI meets the following two requirements:

• Display the queried data of the back-end system:

The simulated ERP-system GUI can let the users query and display various production planning data, such as WIP data, demand forecasts, shipping plans, JIT material requests, and so on.

• Transmit selected data to the PPIS:

The simulated ERP-system GUI can allow the users to select and send specific production planning data to the PPIS. The selected data will be saved into the interface database first. Then, the PPIS will activate the corresponding B2B data exchange service to acquire these data and then send them to the PPIS of the trading partner.

IV. PIP Implementation Procedure

Before conducting the PIP implementation, we should consult the PIP documents of RosettaNet thoroughly to understand the definitions and document formats of the PIPs to be implemented. For example, according to the RNIF specification, the message format of PIP 7B1 contains three parts: Preamble Header, Service Header, and Service Content. The Service Content hosts the major content of the business document conveyed in that PIP. The Service Content is different in different PIPs and, thus, is the major part that needs to be edited and designed in the PIP implementation. Before production planning data can be transmitted over the PPDEP, the data should be transformed to create each part of the RosettaNet message.

The designed PIP implementation procedure, using PIP 7B1 as an example, is depicted as follows:

Step 1. Install webMethods with the RosettaNet module.

Step 2. Create the profile of the trading partners:

Create the profile of the company and the trading partner. The information in the profile includes the names, DUNS numbers, and contact information of the trading partners, together with the transmission protocol, such as HTTPS.

Step 3. Load the par files of PIPs into webMethods:

Obtain the par files of PIPs, such as Pip7B1vV01_01.par, and copy them to the subdirectory of the RosettaNet module. Then, use the web-based GUI of the RosettaNet module to load the par files into webMethods. The par file contains IS (Integration Server) document types, internal and external TN XML document types that define how the trading network recognizes XML documents, and the Trading Partner Agreements (TPAs) that specify the transmission method through which the business documents are exchanged.

Step 4. Implement the initialization service of PIP:

The PPDEP adopts interface databases to integrate with back-end systems. After the internal TN document type is defined, the initialization service of PIP can be implemented. Figure 8 shows the implementation of the initialization service of PIP 7B1 using the webMethods Flow language. When enabled, the initialization service will periodically access the PIP’s header table, such as RN7B1_LIST, to check whether there are data to be transmitted or not. If there are data to be transmitted, the initialization service will activate the PIP, such as PIP 7B1, to transmit the data to the trading partner.

Step 5. Design the inbound and outbound mapping services:

In the PPIS of the sender side, the outbound mapping is designed to transform the outbound data from the original internal format into the format of the underlying PIP. Also, in the PPIS of the receiver side, the inbound mapping is designed to transform the inbound data from the PIP’s format into the document format of the back-end system. Figure 9 illustrates the outbound mapping and the inbound mapping for PIP 7B1. The first step to create the mapping service is to analyze the document format hosted in the PIP’s Service Content so as to determine the mapping flow. Usually, large XML documents consist of some non-repeated information and a great quantity of repeated information. For example, the non-repeated information in the documents of PIP 7B1 includes process ID, document generating time, and contact information of the sender and the receiver, whereas the repeated information comprises a large number of WIP data. According to the XML document format of the PIP, the services of outbound mapping and inbound mapping can be easily built using the webMethods Flow language.

Step 6. Construct services for warning notification and event logging:

A warning notification service is constructed in the PPIS. When any exception occurs in executing the PIP process, the PPIS can then detect that exception and send the related warning message to the responsible person. Also, an event logging service is created in the PPIS to record the events of the PIP execution. Consequently, when the PIP transmission completes or an exception occurs in the PIP execution, the PPIS can then automatically send an associated warning message to the assigned person so that they can log into the PPIS in a timely manner to view the current status of the system.

Step 7. Create the process model:

A RosettaNet PIP is either one-action (i.e. data only from the sender to the receiver) or two-action (i.e. requiring the receiver to reply data) according to the business process flow diagram of that PIP. For example, PIP 7B1 is one-action, and PIP 3A4 is two-action. In accordance with the action type of a PIP, a proper process model template is chosen first. Then, the process model for that PIP can be created by applying the previously-constructed services to the right positions in the process model. This action can be done through invoking these services, such as services of inbound mapping, outbound mapping, warning notification, and event logging, in the process model using the webMethods Modeler. The created process model can be activated by the initialization service implemented in Step 4 to execute the corresponding PIP.

Step 8. Establish the SSL data security protection mechanism:

By using the built-in tool of webMethods, the SSL data security protection mechanism can be rapidly established. First, both the sender and the receiver obtain their SSL certificates from a third-party certificate authority. Then each SSL certificate is installed into its associated PPIS, a webMethods Integration Server. Next, the port 443 of each PPIS is enabled. After that, the data transmitted between PPISs are protected by SSL.

V. Integrated Testing and System Performance

In order to test the proposed PPDEP in a simulated B2B environment, a type of simulated ERP-system GUI was developed using Microsoft Visual Studio C#.NET 2008, as shown in Figure 10. The GUI contains several sub-interfaces to enable the users to operate different functions of the supplier’s simulated ERP system. The provided functions include WIP data transmission, shipping demand monitoring, shipping plan generation, JIT pulling monitoring, ASN generation, and SRN monitoring. Figure 10 shows the user interface for the WIP data transmission function. After the user chooses the WIP data and the partner and presses the button, the selected WIP data are transmitted to the PPIS of the receiver side by the PIP 7B1 protocol through the PPDEP. The transmission status, successful or failed, can be displayed on the GUI as well.

To evaluate the data transmission performance of the PPDEP, the following experiment was conducted. Two servers were used, one hosting the PPIS of the supplier side and the other hosting the PPIS of the manufacturer side. The major hardware specifications of both servers include Intel Core2 Quad Q6600 CPU, DDR2 800 2GB RAM, and are equipped with a 100Mbps Ethernet adapter with physical IP. Both servers adopt the Windows Server 2003 as the operating system. The Oracle Database was utilized to construct the interface database.

Six PIPs were implemented in the PPDEP, including 7B1, 4A4, 4A5, 4D1, 3B2, and 4B2. All of them are one-action processes. Thus, the data transmission time in this experiment is defined as the interval between the time when the sender PPIS begins to transmit data and the time when the receiver PPIS completes receiving the data from the sender. The testing results of data transmission time of different PIPs are shown in Table 1.

As shown in Table 1, the data transmission time of every PIP is less than one minute. As compared with the current data exchange methods in Figure 2, the PPDEP can not only automatically exchange data between the sender and the receiver, but also has a good performance in B2B data exchange.

VI. Enterprise Application Paradigm of the PPDEP

The PPDEP has been practically applied to the factories of our cooperative TFT-LCD enterprises, Chimei Innolux (the manufacturer) and Himax (the supplier) to deliver data for VPCS and to exchange B2B data for executing production planning applications. Figure 11 shows the enterprise application example of the PPDEP. Through the PPDEP, the manufacturer can obtain correct WIP data from the supplier in a timely way and can then conjecture the inventory level and the production capacity of the supplier through the virtual production control system (VPCS) [6]. This measure makes it possible for the supplier to solve potential production problems in advance and increase the order fill rate. In turn, the manufacturer’s objective of just-in-time (JIT) material ordering can be fulfilled.

The VPCS aims to monitor the overall short-period production capacity and delivery performance of the supplier through the timely collection and analysis of data provided by the supplier. The design and functionality of the VPCS can be referred to in [6].

The WIP monitor module in the VPCS can compute the latest production time of the product based on the WIP data and shipping plans. The VPCS also contains a capacity conjecture module and a strategic decision compilation module. Thus, the VPCS is able to generate three categories of strategic decision information: (1) reports on data quality, (2) reports on WIP status and inventory analysis, and (3) analytical reports of order fill rates, all of which help the manufacturer to make strategic production decisions.

The PPDEP is essential to the VPCS. The testing results of this enterprise application paradigm show that by using the PPDEP, the manufacturer can obtain production planning data from the supplier in a timely manner, including shipping plans through PIP 4A5 and WIP transaction and snapshot data through PIP 7B1. These raw data can then be fed into the VPCS for further processing to achieve the above-mentioned objectives of the VPCS.

VII. Discussion

RosettaNet is a consortium aiming to create, implement, and promote open e-business standards for facilitating B2B integration. RosettaNet PIPs (Partner Interface Processes) provide process collaboration standards to implement business collaboration. The RosettaNet standards have been adopted by many companies in the informational technology, electronic components, and semiconductor manufacturing industries. There are some papers examining and evaluating RosettaNet standards in B2B integration from different aspects. Chang and Shaw [14] conducted an empirical study to examine and confirm the business value of RosettaNet in process sharing in the high-technology industry supply chain. Kauremaa et al. [9] evaluated the effectiveness of the RosettaNet standards in integrating the telecommunications supply chain. Nurmilaakso and Kauremaa [11] analyzed the applicability of B2B integration, together with the benefits from, and barriers to, RosettaNet, between major original equipment manufacturers and European operators in the telecommunications industry.

In addition, there are some experience papers focusing on the implementation of RosettaNet in B2B integration. Tikkala et al. [15] implemented a RosettaNet business-to-business integration platform using commonly available open source tools, J2EE and Web services. Gialelis et al. [16] presented a RosettaNet implementation utilizing Web services and ontologies for a collaborative continuous replenishment planning model. Wang and Song [17] surveyed and compared several architectures supporting RosettaNet and proposed an architecture supporting RosettaNet using Web services. M. Kim and D. Kim [18] designed and implemented a RosettaNet-based e-Logistics system that executes and manages multiple PIPs to automate logistics processes incorporating third-party logistics. Liu [19] presented the implementation of supply chain coordination focusing on collaborative planning, forecasting, and replenishment (CPFR) using RosettaNet and semantic Web services.

This work is also an experience paper focusing on the design and implementation of a RosettaNet-based data exchange platform for the TFT-LCD industry. The differences of this paper, as compared to existing experience papers, are highlighted in terms of the following two aspects. In the aspect of content, this paper presents the typical communication methods for exchanging production planning data between a manufacturer and a supplier in the current domestic TFT-LCD industry and describes the shortcomings of these traditional communication methods. Then, we present how a production planning data exchange platform, called PPDEP, is developed to effectively overcome these shortcomings. Furthermore, this paper shows the test results of the practical application of PPDEP to the factories of our cooperative TFT-LCD enterprises, Chimei Innolux (the manufacturer) and Himax (the supplier), to deliver data for a virtual production control system (VPCS) and to exchange B2B data. These tests are shown to validate the effectiveness of the PPDEP.

In the aspect of technology development, this paper first presents the design of the PPEDP B2B platform’s architecture. Then, the designs of the PPDEP’s core components are detailed, namely the production planning integration server, the B2B data exchange processes, the generic application adapter, the interface database, and the simulated ERP-system GUI. Next, a PIP implementation procedure is developed to allow the developers to systematically implement the RosettaNet PIP protocols. This paper also shows how to map the enterprise’s business processes to different RosettaNet PIPs. In addition to the methodology for implementing public B2B processes using RosettaNet PIPs, this paper proposes an interface database approach for easily integrating public B2B processes with the enterprise’s back-end systems as well. As compared to the experience papers mentioned above, the methodologies and procedures presented in this paper are more valuable to industrial practitioners because they are distinct, more complete, and industry-validated.

VIII. Conclusion

Currently, most domestic TFT-LCD companies adopt their own proprietary methods to exchange data with their business partners. This paper proposes a production planning data exchange platform, called PPDEP, for improving the shortcomings of the current data exchange methods of the domestic TFT-LCD industry. The PPDEP adopts webMethods, a popular off-the-shelf enterprise integration software package, as the production planning integration server (PPIS) within each partner enterprise in order to effectively integrate the enterprise’s internal data and to perform B2B data exchange with other enterprises. The RosettaNet PIP protocols are utilized to construct the B2B data exchange interfaces and business processes of the PPDEP. Consequently, the PPDEP can automate B2B data exchange, resulting in several benefits for domestic TFT-LCD companies, including relieving the manpower burden of companies, avoiding data errors, substantially increasing the promptness in B2B data exchange, and assuring security in data transmission. Also, the PPDEP provides a unified and RosettaNet-based data exchange scheme which makes integration among TFT-LCD enterprises easier, thus making it possible for the domestic TFT-LCD industry to enhance its international competitiveness.

The paper also designs a PIP implementation procedure using webMethods. In addition, the PPDEP has been practically applied to the factories of our cooperative TFT-LCD enterprises, Chimei Innolux (the manufacturer) and Himax (the supplier) to deliver data for VPCS and to exchange B2B data for executing production planning applications. As a result of the timely acquisition of production planning data from the supplier through the PPDEP, the VPCS is able to generate information which can help the manufacturer make strategic production decisions. The results of this paper can be a useful reference for TFT-LCD enterprises and industrial practitioners who wish to construct related B2B data exchange platforms.

Acknowledgement

This work was supported in part by the National Science Council, Taiwan, under grant: NSC 99-2221-E-034 -017 and in part by the Ministry of Economic Affairs, Taiwan, under Contract No.: 99-EC-17-A-02-S1-130.

References

  1. Technology introduction, ChiMei Innolux Corp., [Online].
    Available: http://www.chimei-innolux.com/
    [Accessed: July 2010]
  2. S. Klaus, S. i. M. Xavier, B. Jennifer, M. D. Hanouz, M. Irene, and G. Thierry, The global competitiveness report 2009-2010. Geneva: World Economic Forum, 2009.
  3. T. M. Choi, "Coordination and risk analysis of VMI supply chains with RFID technology," IEEE Transactions on Industrial Informatics, vol. 7, no. 3, pp. 497-504, 2011.
    doi: 10.1109/TII.2011.2158830
  4. Y. Yu, G. Q. Huang, Z. Hong, and X. Zhang, "An integrated pricing and deteriorating model and a hybrid algorithm for a VMI (vendor-managed-inventory) supply chain," IEEE Transactions on Automation Science and Engineering, vol. 8, no. 4, pp. 673-682, 2011.
    doi: 10.1109/TASE.2011.2140371
  5. T. Moyaux, B. Chaib-draa, and S. D'Amours, "Information sharing as a coordination mechanism for reducing the bullwhip effect in a supply chain," IEEE Transactions on Systems, Man, and Cybernetics, Part C: Applications and Reviews, vol. 37, no. 3, pp. 396-409, 2007.
    doi: 10.1109/TSMCC.2006.887014
  6. H. C. Yang, Y. L. Chen, M. H. Hung, and F. T. Cheng, "Virtual production control system," in IEEE Conference on Automation Science and Engineering (CASE), Toronto, Canada, 2010, pp. 984-989.
    doi: 10.1109/COASE.2010.5584297
  7. Collaborative forecasting primer, RosettaNet, 2003, [Online].
    Available: http://www.rosettanet.org/Views/DocumentExchange/tabid/3055/DMXModule/3398/Command/Core_Download/Method/attachment/Default.aspx?EntryId=7074
  8. M. C. Chen, K. Y. Chen, M. F. Hsu, and C. T. Yeh, "A web services-based collaborative planning, forecasting, and replenishment (CPFR) framework for managing spare parts of semiconductor equipment," IEEE Transactions on Semiconductor Manufacturing, vol. 22, no. 4, pp. 596-600, 2009.
    doi: 10.1109/TSM.2009.2028217
  9. J. Kauremaa, J. M. Nurmilaakso, and K. Tanskanen, "E-business enabled operational linkages: The role of Rosettanet in integrating the telecommunications supply chain," International Journal of Production Economics, vol. 127, no. 2, pp. 343-357, 2010.
    doi: 10.1016/j.ijpe.2009.08.024
  10. Rosettanet standards, RosetaNet, [Online].
    Available: http://www.rosettanet.org/TheStandards/RosettaNetStandards/tabid/473/Default.aspx
    [Accessed: December 2009]
  11. J. M. Nurmilaakso and J. Kauremaa, "Business-to-business integration: Applicability, benefits and barriers in the telecommunications industry," Computers in Industry, vol. 63, no. 1, pp. 45-52, 2012.
    doi: 10.1016/j.compind.2011.10.006
  12. M. Vujasinovic, N. Ivezic, B. Kulvatunyou, E. Barkmeyer, M. Missikoff, F. Taglino, Z. Marjanovic, and I. Miletic, "Semantic mediation for standard-based B2B interoperability," IEEE Internet Computing, vol. 14, no. 1, pp. 52-63, 2010.
    doi: 10.1109/MIC.2010.17
  13. Software AG webMethods product suite, [Online].
    Available: http://www.softwareag.com/corporate/products/wm/default.asp
    [Accessed: August 2010]
  14. H. L. Chang and M. Shaw, "The business value of process sharing in supply chains: A study of Rosettanet," International Journal of Electronic Commerce, vol. 14, no. 1, pp. 115-146, 2009.
    doi: 10.2753/JEC1086-4415140104
  15. J. Tikkala, P. Kotinurmi, and T. Soininen, "Implementing a Rosettanet business-to-business integration platform using J2EE and web services," in IEEE International Conference on E-Commerce Technology, München, Germany, 2005, pp. 553-558.
    doi: 10.1109/ICECT.2005.52
  16. J. Gialelis, A. P. Kalogeras, A. Kaklis, and S. Koubias, "Rosettanet-based implementation for a collaborative continuous replenishment planning model utilizing web services and ontologies," in IEEE Conference on Emerging Technologies and Factory Automation (ETFA), Catania, Italy, 2005, pp. 503-507.
    doi: 10.1109/ETFA.2005.1612565
  17. J. Wang and Y. T. Song, "Architectures supporting Rosettanet," in International Conference on Software Engineering Research, Management and Applications, Seattle, Washington, USA, 2006, pp. 31-39.
    doi: 10.1109/SERA.2006.18
  18. M. Kim and D. Kim, "Building a Rosettanet-based e-logistics automation system," in International Conference on Innovative Computing, Information and Control (ICICIC), Kumamoto, Japan, 2007, pp. 118-118.
    doi: 10.1109/ICICIC.2007.207
  19. Y. Liu, W. Ruan, and U. Venkatadri, "Rosettanet-based implementation of CPFR using semantic web services," in International Conference on Management and Service Science (MASS), Beijing, China, 2009, pp. 1-4.
    doi: 10.1109/ICMSS.2009.5302981

Refbacks

  • There are currently no refbacks.


Copyright © 2011-2017  AUSMT   ISSN: 2223-9766