Using a Simulator for Testing and Validating a Newspaper ... - CiteSeerX

Using a Simulator for Testing and Validating a Newspaper Production Decision Support System Fredrik Fällström, Stig Nordqvist, Björn Hedin and Vlad Ionesco KTH/Royal Institute of Technology, Division of Graphic Arts Technology SE-100 44 Stockholm, Sweden. E-mail: [email protected]

Abstract This paper presents and discusses the use of a software simulation tool for testing and validating a production decision support system. The developed simulator is specially designed for simulation of the entire newspaper production process. We propose methods for testing and validating a global production management system (GPMS), before implementing it in the production environment. Newspaper production is a complex time-critical process characterized by heterogeneous computer based production tools in a distributed environment. A GPMS is an application of decision support systems for the entire newspaper production process, and needs to collect events from various production subsystems to get the current production state. In order to test a GPMS without disturbing the daily production, there is a need for a simulation tool wich must simulate the event providers. This can only be achieved by using a strictly specified communication mechanism between the event providers and the GPMS.

rapidly, more reliably and with more flexibility. One important aspect is that TidSim generates data with the same communication mechanism as the actual process uses. In this paper we discuss the following: • The fundamentals of the newspaper production process. • The developed TidSim simulator. • The open and vendor-independent communication mechanism between the GPMS and the entire production process, also used by the simulator. • Proposed methods for testing and validating a newspaper production GPMS using TidSim. • Conclusions and future work. Stage 1

Stage 2 DSS

TidSim Simulator

Control

Tracking Scheduling

Newspaper Process

Global Production Managment System

1. Introduction and background For several years, researchers have discussed the importance of decision support systems (DSS) for various applications and industries. Now we can see that DSS are being developed and implemented with various results. In this paper, we present a method to test and validate a version of DSS called the Global Production Management System (GPMS) [7], which is being developed in a research project for the newspaper industry in Sweden [2]. In the early stages of the research project in 1993–94, the focus was to understand and model the entire production process. For this we developed a process simulator called TidSim for the newspaper production process [8]. The focus was to simulate the behaviour of the process using real process data and to present the events in userfriendly screen interfaces. This paper focuses on describing the detailed functionality of the developed TidSim simulator. One important hypothesis is: by using a simulator such as TidSim to test and validate a newspaper production DSS, such as a GPMS, we can develop the system more

Figure 1. The figure shows the central topics discussed in the paper: the process; the GPMS; the TidSim simulator and the common communication mechanism used.

Let us view the developed TidSim simulator as an advanced prototype tool for a GPMS. In figure 1, TidSim is a mirror image of the process and simulates its behaviour given by the set of parameter files taken from the process studied. Stage one is when the development and construction of the GPMS takes place. It is also here that the primary testing and validating takes place. Stage two is when the GPMS is implemented in the real process. In this stage the simulator is replaced with the real systems. One important issue is the use of a strict communication mechanism strategy commonly used in both stages.

1.1. GPMS–global production management systems The basic modules in a GPMS are [10]: tracking of the entire production at a given granularity; scheduling of re-

Proceedings of The Thirtieth Annual Hawwaii International Conference on System Sciences ISBN 0-8186-7862-3/97 $17.00 © 1997 IEEE

1060-3425/97 $10.00 (c) 1997 IEEE

sources, products and processes in production plans; and controlling the process supported by management systems such as DSS and simulation. The GPMS is also connected to the various local systems scattered over the entire process and provides the foundation for a global integrating system for monitoring and control using a common and open infrastructure, i.e., hardware, software, databases and communication [7]. A decision support system, such as the GPMS, will have to collect event information from local production subsystems to obtain the current production state and to collect statistical data for future use. By processing the data, investigating decision options and looking at statistics, the system will be able to guide the user to make the correct decisions. Since newspaper production consists of a number of local system “islands”, there is a need for a well-defined communication mechanism between the local systems and the GPMS [6].

1.2. The fundamentals of newspaper production The publishing process has been mapped and discussed in several publications, especially the process of newspaper production [9 and 14]. Newspaper production is a complex time-critical process characterized by heterogeneous computer-based production tools in a distributed environment, which makes it very interesting for study. The daily production is an extreme case of concurrent engineering where the final product is defined very late in the manufacturing process. This puts high demands on the flexibility and reliability of a GPMS. A typical newspaper production run, from design to distribution, takes 100–1000 persons 24–36 hours to accomplish. Based on earlier work, we can represent the entire production process—from the editorial offices to the distribution—as in figure 2 [11]. This overall model of the newspaper production provides the foundation for this paper. The process functions are briefly described below. CUSTOMERS Ad Gathering and Processing E V E N T S

Editorial Gathering and Processing

Production flow Process information Edition Planning

Product Assembly

First, we can identify three coordinated activities: advertising marketing, sales and space reservations. Incoming external advertising material is received from the customers and is checked and routed forward. Advertising booking information is forwarded to the edition planning. This planning function is an iterative process, balancing advertising reservations and editorial requests within the space available. We then have the editorial gathering and processing of information. This function is a composite of story and graphics creation, image processing and editing. Thereafter the advertising and editorial material are sent to the product assembly, where page elements are placed into fixed and numbered pages for a specific physical product. This is normally an integrated part of the editorial work. At this stage, a defined page original is ready for printing and distribution. The first step is plate-making, the socalled back-end of prepress, which consists of converting the electronic page original description into one or more printing plates. The working steps are ripping (converting a PostScript file into a bitmap), recording (printing the bitmap on film) and printing plate exposure. The recording step is optional. The printing consists of replicating the originals, i.e., printing, cutting and folding newspapers and preprinted inserts. The function also deals with material handling, primarily of paper reels and inks. Mailroom and packaging, the so-called postpress production, consists of assembling the complete newspaper product, including the main product, supplements and inserts. Thereafter the product is prepared and addressed for distribution, which includes counting, stacking, bundling, labelling and palletizing the product. Circulation manages subscriptions and circulation. It can also include distribution planning, i.e., the planning of routes, transportation and delivery personnel. The output consists of circulation orders for printing, address data for the labelling of copies and bundles, and a distribution plan. Distribution processing consists of the transportation and delivery of copies to retailers and subscribers, which completes the cycle.

1.3. The relation to groupware and workflow tools Plate Making

Paper and Ink

Inserts

Printing Material Handling

Mailroom Packaging

Distribution Processing

Circulation Management READERS

R E A D E R S

Figure 2. [11] An overall model of newspaper production and the relationships between the activities within the process, described in terms of production flow and process information exchange.

There are many similarities between traditional workflow management and the GPMS concept, e.g. tracking and scheduling. The goal is to distribute information within the company to optimize workflow and get a more efficient production. However, there are some differences. While workflow management usually covers office-like work for a longer period of time, newspaper prepress production is a chaotic and very time intensive work where one or more unique products are manufactured every day. In addition, newspaper production includes three very different produc-

Proceedings of The Thirtieth Annual Hawwaii International Conference on System Sciences ISBN 0-8186-7862-3/97 $17.00 © 1997 IEEE

1060-3425/97 $10.00 (c) 1997 IEEE

tion phases: prepress production (original production), printing of newspaper copies and distribution of the printed copies. The most fundamental groupware tool is e-mail, which became available during the 1980’s. The groupware concept also includes document management, scheduling, workflow and workgroup applications [5]. To distribute and share information, a network infrastructure is needed for the communication. In early approaches specialized solutions were used, for example Lotus Notes based on proprietary database technology. During 1995–96 the first intranet-based solutions was developed [13]. Workflow tools like Lotus Notes have been tried in the newspaper industry, but they have not gained widespread acceptance.

2. The TidSim newspaper production process simulator In this chapter we describe the TidSim simulator. First, a short introduction of the set goals for the simulator project, followed by a presentation of the main modules within TidSim, which simulates different parts of the production process. We then discuss some important issues of internal structure: the way TidSim stores events and how the internal message handling is done—both important for the system to be flexible and configurable for different scenarios. Over a period of three years, we have developed a software tool to simulate the newspaper production process. The tool is called TidSim, short for “Newspaper Simulator” in Swedish. The first version was constructed and published as an MSc thesis, during the summer of 1993 [3]. The latest version, 3.6, is the basis of this paper, where among other improvements the ability to export events to a GPMS has been added. The TidSim project was started to test new ideas concerning how to connect the different production subsystems in the newspaper industry to obtain a view of the entire production process at the newspaper. Newspaper production consists of a chain of very different and heterogeneous processes. Each sub-process typically has a well-functioning production system with optimization capabilities. However, the optimizations are performed on a local basis, i.e., each local system optimizes the subprocess without giving any consideration to how it will affect other parts of the production [7]. Since the production chain is tightly dependent on each link, this sometimes gives a poor result. With TidSim we wished to test how changes in one part of the production affect other parts, economically and in delays. To make this possible, the simulator tool needed to include the complete production process, from advertising booking to the delivery of the printed newspaper copies.

Each part of the production had to behave very close to reality for a good result. We also needed an attractive prototype to show our ideas to the newspaper industry. We therefore decided to equip the simulator with an attractive GUI and a true client/server architecture, for the system to look and behave like a real GPMS. We chose the NEXTSTEP operating system, because of its object-oriented architecture and advanced support for client/server application development [17]. At the end of 1995 we had achieved the set goals.

2.1. Main modules in TidSim The different parts of the production process are simulated as separate independent modules. Each module is configurable in great detail to allow the simulation of different scenarios. The main modules in TidSim are: Format module. The decision regarding newspaper format, i.e., the number of pages and the choice of colour capability on each page. Due to limitations in a standard printing press, there is a limited set of ways to print colours on different pages in a newspaper. Page module. Handles the import of advertising and editorial material into the system. The module also controls the positioning of material on the pages. Transfer module. To print a newspaper, each page has to be transferred from the editorial building, where the page make-up is made, to the printing house and there to go through a multiple-step transformation into printing plates. This module simulates the transfer and each of the transformation steps. Press module. Simulates the printing of newspaper copies. The process behaviour, such as press speed and runnability, is dependent on the choice of press configuration in the format module. Mailroom module. In the mailroom, inserts and supplements are inserted in the printed copies. The complete products are then packaged into newspaper bundles of different sizes and loaded onto trucks for distribution. This module handles these processes. Distribution module. Simulates the distribution of the newspaper bundles according to predefined routes to different drops. Economy module. Each of these processes affects the economic state of the production. This module collects information from the other modules about their current economic state and a prognosis of their final economic state. A result is calculated continuously. By comparing the prognosis with a given planned value, the simulator gives a good picture of the economic state of the production. In addition to the main modules, there are a number of user modules where the user can monitor and interact with the system (figure 3).

Proceedings of The Thirtieth Annual Hawwaii International Conference on System Sciences ISBN 0-8186-7862-3/97 $17.00 © 1997 IEEE

1060-3425/97 $10.00 (c) 1997 IEEE

copies 67784

Printing 01.45:00-01.46:07 Copies: 409 Speed: 22000

60000

Reel Change 01.46:07 Unit: 4

50000

Reel stand 3 - Paper left: Reel stand 4 - Paper left: 12719 Reel stand 5 - Paper left:

40000

Stopped 01.46:07-02.16:07 Waste: 500 Cause: Web Break

30000

Restart Wast 02.16:07-02.17:07 Waste: 250

20000

Restart Copy 02.17:07-02.20:07 Copies: 1000 Speed: 18000

10000

00.11

Total copies: 51171 Total waste: 1750 (3.31%)

ideal Press speed

01.00 actual

02.24 waste

Produced copies

time

Printing 02.20:07-02.35:06 Copies: 4495 Speed: 18000 Planned press start: 00.11 Actual press start: 00.11

Figure 3. The Press module. An example of a client module in TidSim.

2.2. Storage of events within the simulator

We find the modularity to be of great importance. A flexible system should allow replacement of a module without interference with other parts of the system. The modules are however just logical groupings of functionality. We do not really need a specific module, but we need the functionality within that module. Therefore there is no point in demanding the presence of a specific module, as long as the work gets done. One module could be replaced with a set of small modules which together cover the duties of the original module. To develop a system where no specific modules are required, there is a need for a message mechanism that encapsulates all intermodule communica-

Server

Client export

mes

mes t en

ev

E

con

L

2.3. Internal message handling in TidSim

export

U MOD

Each of the main modules records and stores events in categorised event logs, in TidSim called “reports”. The format module keeps track of the format report, the page module handles the page report and so on. There is one report for each main module. A report consists of a number of time-stamped event entries. The press report, for example, consists of printing events such as press start, stop and current press speed. For performance reasons, updates are not continously sent to the TidSim clients. Instead, a timer module generates timer events, that trigger the server to send updates to the clients. In this case the reports also function as a buffer of events not yet sent to the clients. The reports can be used to test how the production behaves when a change is made in the resource performances or when a production disturbance is introduced into the system. This is done by including a module that reads a saved set of reports for a specific production run and regenerates the stored events in a new run. By “replaying” the production with different sets of configuration data, we gain knowledge about how the changes in the configuration data affect the overall production result in terms of time delays and costs.

tion. In TidSim, this is done by sending all messages outside a module to a message dispatcher (figure 4). By registering as a receiver of a specific message type (opcode), a module will get all messages of the specified type without any knowledge of the sender. In addition, a set of question types are defined. A module can register as a responder to questions of a specific type, and will then get the chance to answer the question whenever it is asked. This allows a module to ask for information from other modules without needing to know which module provides the information. The message mechanism can be used as the connection between the server and connected clients since the NEXTSTEP environment allows messages to be sent between object instances across the network. This allows an abstraction layer for complete hiding of the network communication.

D U L ES

Reel stand 2 - Paper left:

Press Report Copies: 9413 Speed: 32000

S

update

con

O

Reel stand 1 - Paper left: 1718 m

Printing graph

M

Press Reel stands

Figure 4. The message mechanism in TidSim. The message dispatchers are labelled “mes”. The arrows shows how messages are sent between the modules. For performance and error handling reasons, each client has a local message dispatcher which communicates with the server message dispatcher through connection modules (labelled “con”).

The highly modular structure within the simulator system together with the logging mechanism allows the easy export of events generated by the simulator to feed an external GPMS for testing and validating purposes. This is done by including an export module (figure 4) within the server that, when receiving a time update, reads through the generated reports and sends the events to the GPMS through the GPMS communication mechanism.

3. Communication mechanism for the GPMS In this chapter, we discuss the communication mechanism required for the GPMS to interact with local systems or a simulator. We start with some general requirements, and continue with a description of the solutions used for our implementation. Next, we describe the message inter-

Proceedings of The Thirtieth Annual Hawwaii International Conference on System Sciences ISBN 0-8186-7862-3/97 $17.00 © 1997 IEEE

1060-3425/97 $10.00 (c) 1997 IEEE

change model for the newspaper industry developed by IFRA (INCA-FIEJ Research Association) called IFRAtrack [16]. IFRA is an international newspaper research organisation. The GPMS needs to collect events from the subprocesses. By using an open and strict communication mechanism between local systems and the GPMS, it should be possible to replace one local system with another with minimal interference with the other systems, as long as the new system can deliver (and handle) the same events as the old system. The communication mechanism should be well-defined, platform-independent, easy to use and implement, and powerful enough to deliver information of importance about the production chain: • Well-defined to make different vendor’s products compatible. One should be able to replace one system with another as long as the needed events are delivered with the correct communication syntax. • Platform-independent because there are a number of different operating system environments in the newspaper production process. Often different platforms are mixed on the same newspaper. The prepress department might use Macintosh-based or MS Windows-based systems, while the press and mailroom uses MS DOS, OS/2 or Unix systems. For the communication mechanism to work properly between these platforms, it should not be dependent on specific network protocols or byte-order differences. • Easy to use and implement to make it possible to add the mechanism to an already installed system without too much modification work. • Powerful enough to supply the GPMS with the needed information. Limitations in the communication mechanism should not stop the GPMS from obtaining information otherwise available from the local system.

not only to distribute events but also to give information about when an event should occur, i.e. to develop a production plan. This makes it possible to compare the actual production to the planned production. Therefore the communication message format should allow the setting of deadlines. This level should allow the GPMS to notify local systems when deadlines are passed, which means a partly twoway communication. The third level is the most complex, the ability for the GPMS to send control messages. This is needed for the GPMS to inform local systems when the production plan is rescheduled [10]. This final level needs a full two-way communication mechanism.

events

1

GPMS

2 alerts 3 control

deadlines, 2 resource usage

messages

Local production systems

Figure 5. The different levels of communication needed for the GPMS to interact with local systems: (1) Event tracking, (2) scheduling information and alerts and (3) control messages from the GPMS back to the local systems.

To apply global optimization to the newspaper production process, all three levels of communication are needed. The gathering of information from local systems by event tracking, the production scheduling and dynamic rescheduling, and the ability to apply the production plan to the local systems by sending control messages.

3.1. Three levels of communication between local systems and the GPMS

3.2. IFRAtrack—a newspaper industry standard for event tracking (the first level of communication)

We divide the communication between local production systems and the GPMS into three different levels (figure 5). The first, and most basic level, is the tracking of events [16]. All events important to the production chain should be made available to the GPMS. Events are caused by activities. Typically, an event describes the state change of an activity, for example when a page is completed in the make-up process. This event might be triggered when the user selects the final print-out from the page layout program at the editorial department. At this level, there is no feedback from the GPMS back to the local systems. The communication is one-way only. The second level introduces scheduling. There is a need,

IFRA has developed an object model, called IFRAtrack [16] for the interchange of information between local systems in the newspaper production process. The aim is to create a standard for the industry to avoid system incompatibilities. The model is based on objects passing through the different activities within the production process. The activities are defined as “workflows”. Each object can be defined in one or more workflows. For example, a physical page is an object class that could be defined in the workflows page make-up, transfer to the printing house and plate-making. A route is another object class defined in for example the loading and distribution workflows. The objects are linked

Proceedings of The Thirtieth Annual Hawwaii International Conference on System Sciences ISBN 0-8186-7862-3/97 $17.00 © 1997 IEEE

1060-3425/97 $10.00 (c) 1997 IEEE

together to build a production structure. An instance of the product class is linked to a number of physical page objects and so on. The object model has a fixed number of registered object classes, but the workflows are as yet unspecified, except for the generic workflow production which should be used when no other workflow is defined. It is the responsibility of each implementation to decide which workflows are to be used. The model is extendable, new object classes and object attributes can be registered to IFRA and become part of the standard. Messages are interchanged using the IFRA Message Format (IMF), which is a text-based format consisting of a message header with a time stamp, an object identification part and finally the object data (figure 6). BEGIN IMF IFRATRACK "1.1" SUPPLIER "Big Brother" APPLICATION "BB XTension" TIME "19960526163015" BEGIN OBJECT MODIFY CLASS PhysicalPage BEGIN OBJECT_PATH UID "960526001024" END OBJECT_PATH BEGIN STATES pagemakeup = completed END STATES END OBJECT END IMF

message header

object identification

object data

proposed IFRAtrack standard. We support the standard and believe that the model will be improved in the future.

3.3. Using the IFRAtrack RDB solution as the communication mechanism for a modular GPMS Earlier in this chapter, we have discussed the different levels of communication needed for a GPMS to interact with local production systems (event providers). We have briefly described the IFRAtrack model, which we have found suitable for the first communication level, event tracking, and partly for the second level, the setting of deadlines. For the resource handling and control messages we have not yet found a good solution. For message delivery, we have chosen the database solution with a standard Oracle relational database, since we find it to be the most general and modular solution. No reasonably modern newspaper production system should have any trouble in exporting a simple well-defined SQL insert statement whenever an event of interest occurs in the system. The GPMS itself (figure 7) is built around a relational database and intranet technology [4]. The user interaction is handled through a local WWW server connected to the database. GPMS clients written in HTML and Java let the user monitor and interact with the system by using a WWW browser such as Netscape Navigator.

Figure 6. Example of a message conforming to the IFRA Message Format (IMF) version 1.1 syntax. The message describes the completion of a page in the make-up process.

The IFRA specification does not say how the message should be delivered, but two main solutions are suggested. One solution is to use the file system and put text files with IMF messages in specified IMF directories, where receiving systems can read and parse the files. The other solution is to use a dedicated database table within a central database as an IMF buffer, where local systems can put IMF messages as plain text strings, and where other systems can pick them up. We believe that the IFRAtrack model is well suited for event tracking (as the name implies). The model also allows the setting of deadlines. However, there are some serious limitations. There is no way to include information about resource usage or allocation. The IMF message can tell when a page is completed, but not who completed it. It can tell when something should be finished, but not which resources should be used. In addition, no support for control messages is included in the standard. This might be a subject for future work by IFRA. Despite the limitations we have built the GPMS on the

IMF

IMF database

Not yet defined

IMF GEN

GEN

GPMS server updates

GEN

Local production systems

GPMS clients

Figure 7. A view of the GPMS communication mechanism with the IFRAtrack relational database solution.

The IMF database table includes a time stamp field where the receiving time at the server host is used. The time stamp included in the IMF is not reliable since local systems clock settings are not necessarily synchronised. For a local system to provide events to the GPMS through the IMF database, the system needs Oracle client software and an IMF generator to build the messages. The IMF generating software is easy to produce. In our case we have offered to supply most of the generating code, which has proven to be a good way to make the systems conform smoothly to the standard.

Proceedings of The Thirtieth Annual Hawwaii International Conference on System Sciences ISBN 0-8186-7862-3/97 $17.00 © 1997 IEEE

1060-3425/97 $10.00 (c) 1997 IEEE

We find some similarities between the requirements for the internal message mechanism inside a system and the communication mechanism between different systems. Both should be modular, well-defined and should allow communication without direct contact between the sender and the receiver. Once these requirements are fulfilled, local systems or modules can be replaced without affecting other parts of the system. When building a GPMS to be able to work in a simulated environment as well as in live production without modification, this becomes obvious. Some or all of the local systems (event providers) will be replaced by the simulator when working in the simulated environment.

4. Testing and validating the system In this chapter, we describe how to prepare a simulation run, the local systems currently connected to our prototype GPMS installation, and how they can be replaced by the simulator to test and validate the GPMS. We see four main purposes for feeding the GPMS with simulated events: demonstration, debugging, full system testing and performance testing. Demonstration. By using the simulator at high speed, it is possible to walk through the entire production process during a single demonstration session. We have not been able to find any other tool capable of doing this. It is important, both for the executives and for operators at the newspaper, to get the look and feel for the system at an early stage, and for us to receive important feedback [8]. By making the development of the system an iterative process with prototype demonstrations, where the future user can influence the final result, we firmly believe that they develop a more positive attitude towards the system. Debugging. The newspaper production process is a time-critical process, sensitive for disturbances. A very short delay early in the process can cause high delay costs in the distribution stage. It is not therefore possible to do heavy on-site debugging without affecting the production. It is preferable to do as much debugging as possible in a simulated environment before the installation. With TidSim we argue that we can develop the system more reliably and with more flexibility. Full system testing. When building a GPMS for the newspaper production process, we cannot expect that all needed event providers (local systems) can immediately connect to the system. There will be information gaps for a period of time, when local systems are updated to supply the needed events or replaced for new systems where the support can be built-in from the start. With a simulator capable of providing events for the entire production process, all functions can be tested and validated, even if some local systems are not yet connected. This will save time in

the development of the GPMS, since we do not need to wait for all local systems before we can test and validate the full system. Performance testing. Sending messages between local systems and the GPMS can cause heavy traffic on the network if messages are sent frequently, depending of the granularity of tracking. Also, since database access is involved both for the IMF database and for the GPMS itself, the database transactions may be heavy. Typically, the newspaper production process has a number of peaks during the day, when the load can be very high. For example, at the edition design stage, the complete production structure is defined and sent to the GPMS through numerous IMF messages. With the simulator, it is possible to test how different behaviours of event providers affect the network load and database transaction load. We have made a number of simulations which have helped us to build and test the tracking part of the GPMS and have provided considerable feedback for the parts we now are working with—scheduling and control.

4.1. Modelling the production process We need a good and stable model of the newspaper production process in order to build the simulator. For this, we need to understand the process in great detail. Therefore we have spent a considerable amount of time out on newspapers to study and model the production process, especially by J. Stenberg [15]. To be able to run the simulator with good results, we need to be able to configure the model for a specific newspaper or scenario. In TidSim, this is done through a set of configuration files. If the configuration data are bad, the simulation will be meaningless, no matter how good the simulator is in simulating the production process. We have found this to be a big problem during the work on the project, since some of the configuration data are performance and error estimations, i.e. data usually not available at the newspaper to be simulated [11]. For example, the simulator needs to know characteristics about different configurations of the printing press, how each possible press configuration affects the runnability of the printing process. This kind of information can only be obtained by a long period of detailed data collection, and by studies of the printing and mailroom process behaviour [15]. We are now in a position where we have collected enough statistical data and can see differences in the behaviour of different press configurations and physical formats of the newspaper (number of pages, inserts, supplements, etc.). Some parts of the production can be very different at different newspapers. If the differences are major, it may not be enough to modify the configuration data. However,

Proceedings of The Thirtieth Annual Hawwaii International Conference on System Sciences ISBN 0-8186-7862-3/97 $17.00 © 1997 IEEE

1060-3425/97 $10.00 (c) 1997 IEEE

because of the highly modular structure of the simulator, multiple versions of a module (with different behaviours) can be present in the simulator at the same time. The module to be used is selected at run-time.

4.2. Replacing local systems in the real process with the TidSim simulator When running the GPMS in a simulated environment, we need to replace the local systems with the simulator. Since there is no direct contact between the GPMS and local systems, and all communication is done through the IMF database, this is an easy task to achieve, once the simulator conforms to the IFRAtrack standard. TidSim is equipped with a powerful IMF generator module (figure 8) capable of creating a complete production structure of objects, setting deadlines and updating the object structure continuously during the simulation run. The IMF generator is the export module mentioned earlier (figure 4). IMF Generator Product model Supplier:

TidSim

Application:

TidSimServer

Date:

19961211

Issue:

C_961211

Edition:

Edition A

Version:

V1

Product:

Main Product

Job:

Main Job

Set model...

OFF

Tracking restrictions Don’t track Elements Don’t track Reels Don’t track Drops Don’t track Bundles Message destination Display in window Save to file Insert into database

Last generated message BEGIN IMF IFRAtrack 1 SUPPLIER "TidSim" APPLICATION "TidSimServer" TIME "19961210090000"

ON

BEGIN OBJECT CREATE CLASS Route BEGIN OBJECT_PATH UID "ro_C_961211_Motala" END OBJECT_PATH BEGIN ATTRIBUTES Name = "Motala" END ATTRIBUTES BEGIN STATES ITEM PRODUCTION VALUE CREATED ITEM DISTRIBUTION VALUE CREATED END STATES BEGIN LINKS EditionVersion += BEGIN OBJECT_PATH UID "ev_C_961211_V1" END OBJECT_PATH END LINKS END OBJECT

Figure 8. The IMF generator module in TidSim.

When using a simulator to test and validate the GPMS, there may be a need to run the simulation faster than real time or to use a saved set of IMF messages. For the simulation to work, the time stamp generated by the simulator should be used instead of the current time at the server host. Therefore there is a need to be able to run the system in two different modes: a live production mode where the server time is used for the time stamps and a simulation mode where the time stamps provided by the local production systems (the simulator) are used instead. When the simulator is correctly configured, it is necessary to decide which parts of the production process to

simulate, i.e. for which measuring points the simulator should generate events. We define a measuring point as a specific part of the production where events can be collected to “measure” the production state. We have installed a pilot prototype of our GPMS at a medium-size Swedish newspaper, Östgöta Correspondenten [1]. As we propose in figure 1, we have the real newspaper process with local production systems to consider, and a simulator to simulate the process behaviour. The prototype installation receives events from a number of local systems communicating with the GPMS through the IMF database as discussed earlier. The communication is one-way only, i.e., we have implemented the first level of communication and parts of the second level—tracking and some scheduling functions. Figure 9 shows the connected local systems, some of them constructed by us and some by external vendors. There is an edition design system for the creation of the product structure. This is where the tracking objects are created. An extension to the most common page layout program in the newspaper industry, QuarkXPress, handles the page production events. At the multiple-step page output process there are three measuring points: when a page is being ripped (converted from a PostScript file to a bitmap), the Autologic system sends events; when the page films are developed, events are sent by a hand-held bar-code reader and finally when the plate-making process is completed, the PageVision system from Data Oy will soon be able to send events. The printing process events are generated by the CopyTrack system from Denex. Events are generated when the printing press starts and stops. During printing, information about the press speed and the number of printed copies are sent at short intervals. The Denex system also generates an event when a truck is fully loaded with bundles and is leaving the loading dock. GPMS

Route update

Product structure

Edition Design

DENEX

CopyTrack Page layout XTension

IMF database Printing update

Page prod. update

Ripping

Autologic

RIP

Page film output

Bar-code reader

Plate making

Data Oy

PageVision

Figure 9. Connected local systems at our prototype GPMS installation at Östgöta Correspondenten, a medium-size Swedish newspaper.

The measuring points in the figure conform well to the reports in TidSim. The format report contains edition de-

Proceedings of The Thirtieth Annual Hawwaii International Conference on System Sciences ISBN 0-8186-7862-3/97 $17.00 © 1997 IEEE

1060-3425/97 $10.00 (c) 1997 IEEE

sign events, the page report contains page production events, the transfer report contains page output events, the press report contains printing update events and finally, the distribution report contains events about loading and departure of trucks. In fact, TidSim is capable of sending more detailed events than the real local systems, which allows us to test future improvements of the GPMS not yet supported by the local systems.

5. Conclusions and discussion Developing a GPMS for the newspaper production process is a complex project [12]. When the system is tested in live production, local system incompatibilities limit the testing to selected parts, until the local systems fully support the interaction with the GPMS. Therefore it is difficult to test the system behaviour fully. Since the production process is time-critical and small disturbances can lead to high delay costs, we propose that, instead of early live testing, the system should be tested in a simulated environment, isolated from the live production, where the simulated local systems behaviour is fully controlled. By using a full production process simulator like TidSim, we obtain access to a simulated environment through the complete development process, from early debugging to the final testing and validation. This means that we can limit the live production testing to a minimum. This will save time and result in a more reliable product, since the testing and debugging can be done in a more flexible way. The simulator also makes it possible to perform virtually live demonstrations of the system at an early stage. This is important in order to obtain feedback from executives and operators. By involving the future users, we believe that the result will be improved and that the users will develop a more positive attitude towards the system. To get the simulator and the GPMS to work together in a simulated environment we have found some requirements to be necessary: • The simulator must be very flexible: configurable in great detail, separately for each subprocess to be simulated, and easy to modify when the configuration files are insufficient. Therefore, we have argued for the simulator to be highly modular, which is the case with TidSim. • The GPMS interaction with local systems must not be dependent on any specific local system presence. There should be no direct contact between the GPMS and local systems—all interaction should go through a welldefined, standardized communication mechanism. We also maintain that this communication mechanism should be made simple, and easy to implement, to enable present and future systems to conform to the standard without too much extra work. We believe that the IFRAtrack standard is a good approach for the tracking part, with an

extendable model and a simple text-based message format. We believe that building a GPMS that conforms to the discussed requirements not only saves money and makes development faster, but will also produce a very solid system easy to maintain and upgrade in the future, due to its modular design. The need for a well-defined communication mechanism and ideas about global production management should be applicable to GPMS discussed in this paper, as well as to traditional workflow management. We propose that more work should be done to compare and integrate research in these areas.

6. Future work We have now completed the tracking part of the GPMS prototype installation in our research project, and we are now working with the scheduling and control parts. We shall look into the need for an extension of the communication mechanism to handle scheduling and control messages. This will then be implemented in the simulator. When the interchange of messages between the simulator and the GPMS becomes two-way, it will be possibile to use the simulator not only as a development tool, but also as a decision support tool for the GPMS when running in live production. This could be seen as a stage 3 in figure 1, where the GPMS and the simulator is used simultaneously. The simulator can then be used to test different scenarios. This will of course put even higher demands on the simulation accuracy. The theoretical results will be published in the form of two PhD-theses and two licentiate of engineering (post MSc degree) theses.

7. Acknowledgements The authors wish to thank Johan Stenberg and Professor Nils Enlund, at the division of Graphic Arts Technology, Royal Institute of Technology in Sweden, for their support. We also extend our gratitude to the whole project group of participating companies.

8. References [1] K.A. Andersson, “An Oracle-based production tracking system at the Östgöta Correspondenten”, Newspaper Techniques, IFRA, Darmstadt, May 1996, pp 27–30. [2] N. Enlund, “Global Production Management in the Publishing Industry”, ‘RI-95 Proceedings’, St. Petersburg, Russia, May 1995, 7 pp.

Proceedings of The Thirtieth Annual Hawwaii International Conference on System Sciences ISBN 0-8186-7862-3/97 $17.00 © 1997 IEEE

1060-3425/97 $10.00 (c) 1997 IEEE

[3] F. Fällström and T. Petersson, “Implementering och design av mjukvarusimulator för tidningsproduktion”. System documentation and MSc thesis report (in Swedish), Royal Institute of Technology, Department of Numerical Analysis and Computing Science, February 1994. [4] B. Hedin, F. Fällström and V. Ionesco, “An Intranet Solution for a Real-time GPMS in Newspaper Production”, ‘Proceedings of the 30th Hawaii International Conference’, Hawaii, 1997, 9 pp. [5] P. Karon, “Groupware”, InfoWorld, volume 15, issue 16, April 11, InfoWorld Publishing Company, 1994, pp 51–54. [6] S. Karttunen, “Production Data Capture and Messaging Architecture in Media Production Networks”, ‘Proceedings of the TAGA Conference’, Rochester, NY, 1996, 16 pp. [7] S. Nordqvist and N. Enlund, “Global Production Management for Integrating Prepress, Press and Postpress Systems in Newspapers”, Banks, W.H. (ed.), Advances in Printing Science and Technology, IARIGAI ’93, Volume 22, Pentech Press, London, 1993, pp 274–294. [8] S. Nordqvist, J. Stenberg and S. Karttunen, “Modelling of Production Management Solutions: TidSim Newspaper Production Simulator”, ‘Proceedings of the TAGA Conference’, Rochester, NY, 1994, pp 511–526. [9] S. Nordqvist, “Newspaper Prepress—the Process and its Production Management”. Thesis for the degree of Licentiate of Engineering (in Swedish), Royal Institute of Technology, division of Graphic Arts Technology, Stockholm, Sweden, December, 1994, pp 132.

[11] S. Nordqvist and F. Fällström, “Simulation of Newspaper Production Process—Decision and Management Support Tools”, ‘Proceedings of the TAGA Conference’, Rochester NY, 1996, 20 pp. [12] S. Nordqvist, “Global Production Management Systems— Decision and Management Support Tools”, Thesis for the degree of Doctor of Technology, Royal Institute of Technology, division of Graphic Arts Technology, Stockholm, Sweden, December, 1996. [13] B. Roberts, “Groupwar Strategies”, Byte, volume 21, number 7, The McGraw-Hill Companies Inc, USA, 1996, pp 68–78. [14] J. Stenberg, “Newspaper Printing and Distribution: the Production Process and its Logistics”, Thesis for the degree of Licentiate of Engineering (in Swedish), Royal Institute of Technology, division of Graphic Arts Technology, Stockholm, Sweden, December, 1994, pp 147. [15] J. Stenberg, “Management of the Newspaper Production and Distribution Process”, Working manuscript of a thesis for the degree of Doctor of Technology, Royal Institute of Technology, division of Graphic Arts Technology, Stockholm, Sweden, January, 1997. [16] B. Thoyer, “IFRAtrack: a Recommendation for the interchange of status information between local and global tracking systems in newspaper production”, Version 1, IFRA, Darmstadt, 1995. [17] NeXT Software Inc., “NeXT Software Inc. World Wide Web site”, “http://www.next.com/”, 1996.

[10] S. Nordqvist and N. Enlund, “Control and management methods for prepress production in multichannel newspapers”, ‘Proceedings of the TAGA Conference’, Rochester, NY, 1995, pp 483–501.

Proceedings of The Thirtieth Annual Hawwaii International Conference on System Sciences ISBN 0-8186-7862-3/97 $17.00 © 1997 IEEE

1060-3425/97 $10.00 (c) 1997 IEEE