Standardized Configuration in the Domain of Hinterland Container Terminals Manfred Gronalt, Martin Posset, Thouraya Benna University of Natural Resources and Applied Life Sciences, Vienna, Department of Economics and Social Sciences, Institute of Production and Logistics, Feistmantelstraße 4, 1180 Vienna, Austria
[email protected]
Abstract The aim of this paper is to introduce a configuration tool that was developed within a project on the optimization of hinterland container terminals (HCT) called SimConT. The tool enables fast and intuitive creation of an artificial image of a potential HCT. Within the configuration environment all interfaces for data entry are designed in a self-explanatory way to avoid extensive training measures for the user. All necessary data is ascertained and especially edited for a downstream simulation of hinterland container terminal operations. The main advantage of the configuration is to enable the definition of various terminals for customizing the simulation while planning or rebuilding terminals. This is a new and improved approach to develop a standard for configuration in the domain of HCTs.
Keywords Standardized configuration, Self-explanatory application, Hinterland container terminals, Reactive Interfaces
1
Introduction
Hinterland container terminals ensure efficient container turnover in modern logistic networks. In contrast to open sea container terminals HCTs are constrained in their storage capacity, are faced with higher container diversity and there are hardly predictable time windows for delivery and pickup. Increasing flows of goods along with increasing road transport emphasize the important role of intermodal hubs to match future demands with regard to economical and ecological needs. Therefore intermodal container turnover and the corresponding infrastructure have to be planned and coordinated exactly to guarantee frictionless intermodal transport by rail, truck and ship. In our approach we try to combine different perspectives on the definition of HCTs to enable a common understanding how to configure an intermodal hub. Planning and construction of such facilities involves a lot of people coming from different domains with different perspectives involving a lot of effort of building a macroworld out of their particular microworlds. Therefore the SimConT configuration creates an integrative perspective for decision makers of different domains to ensure consistent planning of hinterland container terminals. Complexity and the significant number of participants in the process of designing hinterland container terminal
infrastructure emphasize the need for a standardized way of structuring the planning process. The configuration includes all components and considers correlations necessary to depict an HCT. Keeping in mind these aspects, the aim of standardized configuration and further on simulation in this domain is to minimize the risk of stranded costs when planning or rebuilding the infrastructure. Implementing a configuration approach for a repetitive and customized simulation is a novelty in this area. The main advantage of standardized configuration within this domain is the fast definition of valid data sets for the simulation of HCTs. The SimConT HCT configurator enables users to make changes in basic settings to execute different simulation runs within short time. In contrast to commonly known applications like online configurations, the SimConT configuration is limited for B2B applications. The configuration guarantees fast and error free data for the simulation in advance while giving the user the possibility to make changes in the basic settings. The aim of our work is to eliminate elaborate adaptations before processing simulation runs. Several restrictions and requirements have to be considered when configuring layout and operation of an HCT. In this case study we cooperated with an Austrian HCToperator and an Austrian rail infrastructure operator to ensure the integration of practice based data and know-how. The SimConT configuration is built on practitioners experience and scientific expertise to ensure practicality. Our implementation enables decision makers to evaluate any desired terminal constellation in advance within short time. It works like a car configurator that allows the user to create favored car. The advantage of this approach is that it allows everybody to create a valid hinterland container terminal which can be used as a basis of common understanding for management, planners and civil engineers. Actual results of the SimConT configuration approach are a preliminary work for creating a prototype of a special hinterland container terminal configuration- and simulation-environment. In this contribution we want to introduce the idea and aim of SimConT, especially the concept and underlying logic to give an idea of the configuration object. Section 2 introduces an overview of our functional model and classifies the SimConT configuration based on typical configuration characteristics. Section 3 discusses the transformation of underlying models into a complete configuration and has a focus on interrelations and dependencies within these models. Within Section 4 we show the way we implemented the SimConT configuration, its components and the physical appearance of intelligent user interfaces. Finally, conclusions and future development of SimConT are discussed in Section 5.
2
Configurator and Classification
The SimConT configurator enables the creation of an artificial image of a potential terminal setup. It is composed of a system configuration module and an order configuration module (see Figure 1). Both modules are supposed to capture necessary layout-, operation- and order related data.
Figure 1: SimConT functional model
All interfaces offer intelligent error avoiding input fields for data entry and are designed in such a way that content and functions are self explanatory for the user. The entered and edited data set is then transmitted to the data generator where lists of inbound and outbound containers are produced automatically for the subsequent simulation [Hartmann 04]. We focused on a tool which is applicable as well for expert users as well as users who are not familiar in detail with the subject matter. The SimConT configuration guides the user to a consistent, redundancy free and executable data set which represents a complete model of a hinterland container terminal. Configuration enables the artificial reproduction of a specific product, service or system at little effort and data entry. Basically there are two common types of configurations B2C and B2B applications. Planning and design of complex products and systems require innovative tools to support engineers and decision makers. [Wallace/Dwarakanath 95]. Innovative applications add greatly to strengthen understanding and speed up learning and planning. Quality and effort of developing and planning complex systems often depends on expert’s expertise [Wallace/Ahmed 04]. Configuration enables the assembly of complex products and systems and is found in a significant number of contexts and it allows the configuration of the underlying product or system in nearly every possible composition [Stumptner 97]. Representation of knowledge, personalized customer support and distributed reusability of consolidated product configurations by means of configuration lead to significant business benefits [Jannach et al. 06]. It can be seen as synthesizing objects or microworlds to a final product or macroworld [Günter 95], [Cowan et. al 06]. The underlying configuration knowledge maps the architecture of the configuration object through functions and components [Felfernig et. al 01]. Furthermore it is a way of organizing knowledge. Most models consist of a repository, a corresponding logic and constraints which define the possible composition of components and scope of data entry. All kinds of configurators can be classified by the criteria shown in Figure 2.
Figure 2: Classification of configurators1 According to Figure 2 the SimConT configurator can be classified as a mixture of rule-based and model-based configuration [Blecker et al. 04a], [Stumptner 97], [Krebs et al. 03]. Its bottom up approach determines the complexity of data entry whereby the scale of interfaces is determined by the entry of the user. The logic is based on defined elements and configurable components. Each data entry is checked by loops and the resulting information is transmitted to the subsequent interfaces. The configuration has to be fast and intuitive to avoid abortion and to awaken the user’s attention [Hartmann et. al 07]. Therefore it is mandatory to define an
1
[Blecker et. al 04]
appropriate level of abstraction while keeping in mind a sufficient degree of detail [Jørgensen/Petersen 05]. Basically it is possible to distinguish the components of an HCT into three main categories, modes of transport, container storage and handling equipment [Arnold et. al 04], [Murty et al. 04], [Pumpe 00], [Steenken et al. 05]. Beside this simplification it is important to have a focus on interactions and relations of corresponding objects within these categories. Therefore we defined a set of objects, a set of relations and customized control logic to guide the user through the configuration [Günter/Kühn 99]. To alleviate the decision making problem we integrated chronological backtracking to enable the revision of antecedent configuration steps at every stage of the configuration. One of the main challenges in connection with the set of objects is the high degree of freedom within the specification of the individual objects. We only offer different classes of objects but the user has to specify the properties and potential value ranges of the objects to create a complete model. The relation between these components and objects represents the logic which determines the possible combinations of the configuration while the control logic prevents the transmission of incorrect terminal configurations to the simulation. The SimConT configuration is neither a terminal information system nor a natural configuration in terms of depicting a user’s conception. It is rather a tool for generating a valid, complete, and standardized data set of a hinterland container terminal. Resulting data sets might be used for quite a number of different objectives as optimization issues, characterization of terminals, benchmarking, and simulation.
3
Design and Methodology
Applying an individual adjustable and re-usable configuration is an innovative approach in the domain HCTs. The SimConT configuration is a peer-to-peer interface between users and the downstream simulation. While entering input data and necessary parameters the system has to create an artificial image of a potential terminal layout. As a consequence the configuration makes sure to that the simulation is adaptable to almost every favoured terminal constellation defined by the user. Especially in the domain of open sea terminals there is already a lot of work done on simulation and there is an enormous number of approaches and applications (see [Gambardella et al.], [Henesey et al.], [Lee et al. 03], [SCUSY 07], [Simcon 07], [Transcare 07], [Yun et al. 99]). Most solutions are tailor-made solutions to specific problem definitions or focus on particular issues and abstract input data. In common more or less all of them are faced with the problem of data gathering. Beside the difficulty of data collection the fine-tuning of such systems is a very challenging task. As a result it is often necessary to employ external consulting or extensive training. Our configuration forms a contrast in this domain because it allows standardized configuration of nearly any hinterland container terminal within short time. Overall design, comprehensiveness, modelling and logic of the SimConT configuration can be seen as a result of substantial workshops with strategic decision makers of Austrian hinterland container terminals. Additionally we made a lot of field visits to analyse real-life operations of selected HCTs all over Austria. The resulting model is a consequent conflation of theoretical knowledge out of the literature and operational expertise of our project partners. In our particular case we had to design the comprehensiveness and the functionality of our tool to the needs of our project partners while keeping in mind to develop a standardized application. Within the following section we describe
the underlying logic of a hinterland container terminals and the derived structure of the configuration. A container terminal can be characterized by means of transport, yard, and equipment (see [Choi et al 03], [Murty et. al. 04], [Steenken et al. 05]). Starting from these conditions we focused on rail and truck as main means of transport (see Figure 3). Concerning the yard we distinguish between loaded and empty containers. Both have to be stored in separated blocks or in blocks that have special sectors for empty containers. The layout of every block can be defined individually in its base size and dimension. Therefore we distinguish in symmetrical and asymmetrical blocks for container storage. Finally the third main category of equipment has to be defined. In our model we only consider stackers and rail mounted gantry cranes as free configurable types of equipment. After having specified the main categories it is necessary to link means of transport and infrastructure via equipment. Equipment must be allocated to blocks, tracks and truck lanes to enable the flow of containers (see Figure 3). In a first step we defined a structural- and functional- (see Figure 1) model to capture all relevant components of HCTs. Furthermore we aggregated the specific information in a separated system- and order model (see Figure 3 and Figure 4). Consequently all infrastructure- and orderrelated information is collected separately in corresponding models. The user has to create a physical image in first step that has to be filled with jobs in a second step. Only the conjunction of both models and related data sets ensures an executable basis for the subsequent simulation.
Figure 3: system model
The system model captures the underlying structure of the system configuration and contains all components concerning the infrastructure of an HCT (Figure 3). Separating the entry of infrastructure (hard facts) and orders (soft facts) facilitates to determine the degree of freedom in selection and data entry because of the construction of preceding constraints. Actually the configuration of infrastructure and orders is separated in two successive modules of the configurator. But we are already planning to combine these two models in a further development to make the tie trunk more obvious for the user. After having determined the hard facts (infrastructure) it is essential to fill the system with orders. Accordingly we defined a separated model for the corresponding flows within the system (see Figure 4).
Figure 4: order model
The basic setting of the order model is separated into operating hours, seasonality, number of trains and trucks, and the number of containers. Operating hours define the opening- and working hours of the terminal. Additionally we considered seasonal fluctuations for both means of transport to guarantee realistic delivery and pickup behaviour. While trucks are considered to be uniform, trains are characterized by different categories. For trains it is possible to set the maximum and minimum number of containers within each category freely. In the next step it is necessary to specify the distribution of turnover between different means of transport. The distribution of turnover defines how many containers are delivered and picked up by which kind of transport mode. Within the order model the number of import containers builds the linking between all other input data. The quantity of containers is composed by the number of containers delivered by trucks and rail while the total number of containers is determined by total import containers. Further distinction of containers is also done on the underlying number of import containers. Containers are further divided into loaded and empty containers. Empty containers are configurable by individual sizes and idle times but they are supposed to be not stackable. Loaded containers are classified as slow and fast movers in a first step. Slow and fast movers are differentiated by their idle time. Concerning loaded slow and fast mover containers there is an additional distinction in stackable and non stackable ones for each type. It is significant to differentiate between stackable and not stackable (see Figure 4) because latter decrease the capacity of the storage significantly. For example three not stackable containers take the same storage space as nine stackable containers. Irrespective of the stacking type different length and weight categories must be assigned to all types of containers. Information corresponding to characteristics of containers is summarized within categories and has to be specified only for the categories. The distribution of containers within the categories is done in percentage and based on the total number of containers.
4
Implementation
At present the tool is divided, corresponding to the underlying models, into a system configuration called SYSKON and an order configuration called ORDKON. As already mentioned above within the description of the models, the SYSKON component subsumes all infrastructure related information and the ORDKON component includes all the information about traffic flows, containers, and the settings of the simulation. Exclusively a complete system and order configuration enables a simulation run. Complete configurations are also at the same time valid configurations because the integrated control logic avoids invalid complete configurations. Within the next section we will give a brief overview of the SYSKON and ORDKON component.
4.1 SYSKON The SYSKON component allows rapid and straightforward entry of infrastructure related data. All necessary parameters are clustered in three main data sets (see Table 1) to facilitate data entry and the complexity of the control logical. Therefore we specified a master-, layout-, and operation data set that aggregate infrastructure and equipment, configuration and distances, and the linking of equipment and infrastructure.
Table 1: SimConT SYSKON data set
All data sets are further divided into subject related subsets that represent the content of the corresponding data entry masks (see Table 1). The master data set specifies the basic settings of the terminal and includes means of transport, loaded and empty container storage, and number and type of equipment. Within the layout data set the physical configuration and distances between all objects are defined. The operation data set includes the assignment of equipment to blocks and tracks. Only the combination of all data sets completes the configuration of the terminal (see Figure 5).
Figure 5: data set SYSKON and interfaces
Master data set: Data collected within the master data set forms the base of the whole configuration. Means of transport, storage, and equipment are the backbone of a terminal. The first interface of our configuration (means of transport interface) allows for rail and road transport as means of transport. For rail we distinguish between handling tracks and parking tracks that have to be defined by length and identification. While handling tracks are within the area of the terminal for container turnover, parking tracks are in front of the terminal for waiting or dispatched trains. According to trucks we offer the number of truck parking within the terminal and the number of gates. Subsequently we listed two interfaces (storage of loaded and unloaded containers interface) for the specification of the storage area for loaded and empty containers. Optionally the user has the choice between symmetrical and asymmetrical blocks. Additionally the input measurement is adaptable to the convention of the user. Therefore we consider meters, TEU (twenty feet equivalent unit), and SRT (Sectors, Rows, and Tiers) as units of measurement. In this connection sectors are a super class of several bays (see Figure 6). Irrespective of the unit of measurement the user chooses, internally all sizes are considered in foot.
Figure 6: storage block
Actually we considered a maximum number of eleven blocks (nine symmetrical and 2 asymmetrical). After having determined the number and corresponding dimension of blocks we go on to the storage of empty containers. Empty containers may be stored in separate blocks, within a sector of a block for loaded containers, or they are stored mixed with loaded containers in the same block. If they are stored within separate blocks the user simply chooses one block that will be considered exclusively for empty containers. In case of storage within a sector we need to know which block and which sectors within the block. Irrespective of the unit of measurement chosen by the user all blocks are converted into corresponding number of sectors (length/TEU) to facilitate data entry for the user. In a next step the terminal equipment needs to be specified (equipment interface). In particular we take into consideration rail mounted gantry cranes (RMGC) and reach stackers [Steenken et
al.04]. While cranes are limited in their free movement, stackers can reach nearly every place within the terminal. We decided to focus on these two types of equipment because we observed that these are the most commonly used in hinterland container terminals. In our case we limited the configuration to a maximum number of six cranes and six stackers. The configuration of the equipment can be done either manually by entering the technical specification or by choosing from a list of predefined types. Layout data set: Subsequently the above defined infrastructure has to be physically configured. The layout data set includes three masks: layout of the terminal, layout of the blocks, and distances (configuration and distance interfaces). In our approach we assumed that blocks can be configured either serial or parallel (Figure 7 shows serial configuration). After having determined the overall layout of the terminal the configuration switches to the next interface to determine the configuration of truck- and stacker lanes, gates, and tracks. The exact configuration is done within a graphical interface that appears like a sheet of white paper for drawing where the user has the possibility to place objects. We decided to introduce a graphical solution because the user immediately gets an idea of the configuration. The image of the terminal layout is converted into a matrix that has to be filled with data in the next step where we need to enter the related distances into the matrix.
Figure 7: configuration and distances
The user has to enter the distance between each track, block, and lane. Concerning the gate it is sufficient to enter the distance to the nearest block; all other distances will be calculated automatically by the system. By having determined the layout of the terminal we can go on to link the means of transport with the infrastructure. This is done by allocating the equipment to blocks and tracks. Operation data set: Within the last two interfaces (assignment of equipment to blocks and tracks) the equipment is allocated to enable the flow of containers between means of transport and the terminal. First of all the equipment must be allocated to container blocks. According to the technical specification of the equipment it is not possible to allocate it randomly. If the size of a block does not fit to the technical specification of the equipment, allocation is impossible (i.e.: the number of tiers is bigger than the number the stacker can reach). In case of allocating more than one crane or stacker to one block it is necessary to determine which rows of the block are handled by which equipment. In our case we only consider the splitting of rows (see Figure 6). At this status the configuration already knows how and by which equipment all blocks are handled. In the next step we need to define the linking of means of transport and blocks to specify the turnover of containers between rail, trucks, and blocks which is done by allocating the equipment to tracks and lanes.
Complete master, layout and operation data capture the system configuration of the hinterland container terminal. After having configured the hard facts of the terminal, the system has to be filled with traffic and container flows by applying the order configuration.
4.2 ORDKON In this section we give an introduction to the way we implemented the configuration of traffic and container flows. The segregation of system and order data in the actual state of development is intentionally to facilitate changes in configuration for the user. In case of several simulation runs with changing settings it is important to have quick access to the underlying setting. Analyzing the behaviour of the system under different conditions and settings is done in most case by changing either the infrastructure or the order setting. The ORDKON component is subdivided into three data sets: terminal and system, traffic and transport, and containers (see Table 2). The setting of the interfaces is determined by the settings of the system configuration.
Table 2: SimConT ORDKON data set
Consequently we sequenced the interfaces for data entry according to the logical sequence of the system data. Input fields are designed in such way that it is possible to make irrational but not logical incorrect settings. In a first step the setting of the terminal has to be specified. Further the input of containers, trains, and trucks. Concluding time windows, specifications, and categories are assigned to all objects. Adding order data to the above defined data sets completes the data set of a hinterland container terminal (see Figure 8).
Figure 8: data set ORDKON and interfaces
We implemented the ORDKON data sets (see Table 2) in four interfaces corresponding to terminal, amount of input, means of transport, and containers (see Figure 8).
Terminal and system data set: The terminal and system data set specifies the setting of the simulation (operating hours interface). Therefore it is required to determine the duration of the simulation run and the starting day. Further the simulation needs to know the operating hours of the terminal at each day of the week. We decided to have a separate input of time for each day of the week to guarantee realistic conditions. Entry is done via spin buttons to avoid extensive underlying control logic. The basic setting of the spin buttons is influenced by the setting and changing of the other spin buttons to make data entry as comfortable as possible. Traffic and transport data set: This set contains information about the arrival behaviour of containers and corresponding means of transport (import containers and train categories interface). The total number of containers going into the terminal is the starting basis for all other calculations. The ratio of import and export containers, slow- and fast movers, loaded- and empty containers, and sizes and weights is deduced from the total number of import containers. In the first instance containers are allocated to means of transport. We allow for up to ten different time windows for the arrival of each transport mode. Additionally we incorporated seasonal fluctuation in the arrival including four definable seasons with specific time windows. Time windows define the time slot for the arrival and the probability of arrival on a specific day of the week. The proportion of export containers is a proportion of the number of import containers. If the ratio is smaller than hundred percent it is possible to define specific time windows for export containers. Further on the incoming and outgoing trains have to be specified within categories. Trains are distinguished by their minimum and maximum number of containers within up to five categories while trucks are considered as single container loading units. Corresponding to each transport mode, time windows are set independently. After having defined quantities, time slots, and categories of means of transport it is necessary to specify the ratio of turnover between different transport modes (see Figure 9).
Figure 9: container flow
Container turnover has up to four different characteristics: train-train, train-truck, truck-train, and truck-truck. The proportion of each characteristic determines the amount of containers coming from a specific transport mode and its destination. There is no need for a terminal-train and terminal-truck characteristic because all containers are assigned an idle time. Consequently a train-truck container, arriving by train, is stored in the terminal for a specific period, assigned by the system, until it will be dispatched by truck. Container data set: Finally the container data set includes characteristics of containers (container interface). Again the total number of import containers builds the starting basis for calculation. First of all, containers are separated by loaded and empty containers. Each category is assigned an own idle time. In a first step different size classes must be assigned by a ratio based on hundred percent. The configuration considers container sizes ranging from twenty feet up to forty five feet. Container weight classes specify the lower and upper bound of weight and there are up to ten different classes. The complete data of system configuration and order configuration captures all information that is necessary to create and artificial image of a hinterland container terminal (see Figure 10). It
includes system related master, layout and operation data and order related terminal, traffic and container data. Data entry is based on twelve interfaces which are divided into the SYSKON and ORDKON configuration component.
Figure 10: hinterland container terminal configuration
The input of SYSKON and ORDKON is especially edited in columns and matrices for simulation. The data is stored within one standardized data sheet that is independent of configuration. Thereby we facilitate the re-usability of complete configurations by offering user the possibility to go back to already defined scenarios. Additionally we can speedup processing time of simulation because of the cancelling of double configuration.
the the the the
4.3 Intelligent user interface IUI The configuration consists of twelve user interfaces including the data sets mentioned in Table 1 and Table 2. Implementing the user interface, design and usability were the main challenges because of the transformation of a complex data set into logical and intuitive input masks [Wierzbicki 07]. During the design phase of the masks we had a special focus on usability and visual perception. All interfaces are provided with an error avoiding control logic to facilitate data entry to finally guarantee a valid and correct configuration [Krebs 06]. Switching from one mask to a subsequent one is only possibly if the data entry of the actual mask is done completely and correctly. Therefore the status of each interface is indicated by a traffic light (see Figure 11) in the upper left corner of the interface. Furthermore the correctness of each entry can be checked by the user via optical warning signals.
Figure 11: SYSKON master data interface
All interfaces have to be passed through in a sequential way to facilitate consistency checks of the configuration data set. Keeping in mind the complexity of the underlying data structure, it is indispensable to structure the data entry in an intuitive and visual self-explanatory way. One of the main challenges in designing a configuration in the domain of hinterland container terminals is to accelerate and simplify the process of data collection. Our focus was on highest possible attention on usability by providing fast access to a complex system. Transforming an elaborate data structure into a comprehensive and complete set of customized interfaces (see [Ardissono et al. 03a], [Ardissono et al. 03b], [Ardissono et. al 02]) was realized by incorporating ideas and logical approaches of practitioners. Although the underlying configuration can be defined as an expert system we raised a claim to develop a tool that is applicable for both experts and greenhorns in this domain. Starting from these conditions we decided to implement control logic as well as an optical surveillance to support the user. Initial experiences with test users showed that control logic without pointing out what was done wrong is like having no support. At least it is very hard for the user to identify and understand that he lapsed from the point of view of the system. Our automatic user monitoring guides the user through the configuration. The user always has the possibility to see the status of the configuration and the actual mask. At every stage the configuration shows which data entry has to re-done or which entries still have to be done to complete an entry set. The amount of information provided by the user is stored within matrices, binaries and data rows (see Figure 12). To speed up the loading of the data into the simulation each data set is indicated with a binary. Depending on the constellation of the configuration it is not always necessary to have a complete (in sense of including all possible information) data set and consequently it is reasonable to limit the search space. Providing a realistic scenario, all objects (storage blocks, equipment, and tracks) can be specified by their real identification (see Figure 12). For internal use all objects are assigned to an internal identification to standardize searching and loading procedures.
Figure 12: exemplary data set of configuration
Another aim was to offer several conventional units of measurement for data entry to avoid circumstantial conversions for the user. The configuration offers the possibility to enter the dimension of objects in meters, foot, and an internal commonly used unit. Because of the fact that the configuration offers different ways of defining the measurement of objects it always has to know the underlying scale unit to convert it into a standardized unit of measurement (foot). The resulting input is automatically converted into a standardized data format to guarantee input convention independent processing of data. We defined a maximal size for the underlying data set in a first step to set bounds to the degree of freedom of the configuration. Both data set size and simulation input where derived from each other to fix the amount of necessary and available data. One of the main necessities in designing a standardized configuration is to take a realistically available data set as a basis. There is no sense in developing a standardized tool that requires plenty afford for data gathering to deploy the tool.
5
Conclusions and Outlook
The present status of the SimConT configuration includes all essential properties which are necessary to depict and describe a hinterland container terminal. Our prototype enables the configuration of nearly every hinterland terminal layout, equipment and operation constellation. The SimConT configuration guides the user to a consistent, redundancy free and executable data set which represents a complete model of a hinterland container terminal. Layout and structure of the configuration are developed and designed to the special needs of HCT planners. Our approach ensures a common perspective on the underlying object to both experts and even inexperienced participants while planning and constructing hinterland terminal infrastructure. We tried to combine the different perspectives of terminal and network operators within our configuration by implementing consolidated nomenclature and standardized commonly agreed practice. Our application ensures fast and error free depicting of any hinterland terminal layout and operation and enables practitioners to get an idea of desired infrastructure in advance. Within short time it is possible to make changes in dimension, layout and operation of a potential HCT. Beside the resulting data set and the possibility of visualizing specific infrastructure, the output
data is structured appropriate to be used for further optimization issues, characterization of terminals, benchmarking, and simulation. During the cooperation with our partners we found out that future requirement of terminal operators are focused more and more on tactical and operational solutions. Therefore we want to include a reconfiguration logic and case-based reasoning into our configuration [Stumptner 97]. These requirements necessitate the development of a comprehensive knowledge base to store defined parameters of simulation runs. We want to enlarge our focus on customer profiling to develop even more user-adaptive interfaces [Ardissono et. al 03a] which actively react to the users’ actions. Furthermore we plan to implement an advisory system to ensure process simplification and personalization of the configuration [Blecker et. al 04b]. A further step will be a web-based user interface to provide location-independent configuration of HCTs combined with a local data repository and personalized reporting. Based on our further findings we plan to implement a key performance indicator based configuration that is location and language independent and advises the user through personalized graphical interfaces. We are presently working on the definition of a standardized set of indicators especially for the domain of hinterland container terminals. Currently there is no standard to compare the performance of intermodal inland hubs. Of course there is already a lot of work done in comparing different installations (see [Cullinane/Wang 06], [Cullinane et al. 05], [Tongzon/Heng 05], [Pestana/Athanassiou 04]), but almost all of them had a different focus and most of them deal with open sea container terminals. Our aim is to develop a standard for selected Austrian terminals to use this standard as a benchmark of performance measurement for other terminals. In the future the configuration will be able to collect and also calculate indicators. We plan to set up a standardized catalogue of indicators within the configuration. This catalogue will guide the user and show how to collect performance of his terminal. In our work we distinguish between descriptive- and performance- indicators. Corresponding to performance benchmarks we want to incorporate simulation results as successful practices related to a specific terminal configuration. Descriptive indicators will be collected during the configuration process by converting the input data of the user. Our contribution shows that there is still a lot of work that has to be done in the domain of hinterland container terminals to cope with future demand.
References Ardissono, Liliana / Goy, Anna / Holland Matthew / Jannach, Dietmar / Schäfer, Ralph / Zanker, Markus / Simeoni, Rossana (2002): Personalised Configuration of Products and Services in Co-operating Markets, Italy: Proceedings of the 6th international Conference Knowledge-Based Intelligent Information and Engineering, Crema, Italy, 2002. Ardissono, Liliana / Friedrich, Gerhard / Goy, Anna / Holland, Matthew / Petrone, Giovanna / Russ, Christian / Schäfer, Ralph (2003): User-Adaptive Configuration of Products and Services, Acapulco / Mexico: IJCAI workshop on Configuration, 2003.a Ardissono, Liliana / Goy, Anna / Holland, Matthew / Petrone, Giovanna / Schäfer, Ralph (2003): Customizing the Interaction with Configuration Systems, Pittsburg, in proceedings of the 9th international conference on User Modeling, 2003.b Arnold, Pierre / Peters, Dominique / Thomas, Isabelle (2003): Modelling a rail/road intermodal transportation system, Belgium: Elsevier Ltd., 2004.
Blecker, Thorsten / Abdelkafi, Nizar / Kreuter, Gerold / Friedrich, Gerhard (2004): Product Configuration Systems: State-of-the-Art, Concepualization and Extensions, Sousse/Tunesia: Centre de Publication Universitaire de Tunis, 2004a. Blecker, Thorsten / Abdelkafi, Nizar / Kreuter, Gerold / Friedrich, Gerhard (2004): An Advisory System for Customers’ Objective Needs Elicitation in Mass Customization, Klagenfurt: Proceedings of the 4th Workshop on Information Systems for Mass Customization (ISMC), Founchal/Portugal, 2004b. Choi, Hyung Rim / Kim, Hyung Soo / Park, Byung Joo / Park, Nam-Kyu / Lee, Sang Wan (2003): An ERP approach for container terminal operating systems, ORT, Maritime Policy and Management, 2003. Cowan, F., Scott / Allen, K., Janet / Mistree, Farrokh (2006): Functional Modelling in Engineering Design: a Perspectival Approach Featuring Living Systems Theory, Systems Research and Behavioral Science, 23, 2006. Cullinane, Kevin / Wang, Teng-Fei (2006): The efficiency of European container ports: a crosssectional data envelopment analysis, United Kingdom, International Journal of Logistics: Research and Applications, 2006. Cullinane, Kevin / Song, Dong-Wook / Wang, Teng-Fei (2005): The application of mathematical programming approaches to estimating container port production efficiency, United Kingdom, Journal of Productivity Analysis, 24, 2005. Felfernig, Alexander / Friedrich, Gerhard / Jannach, Dietmar (2001): Conceptual modeling for configuration of mass-customizable products, Klagenfurt: Artificial Intelligence in Engineering, 15, 2001. Gambardella, Luca, Maria / Bontempi, Gianluca / Taillard, Eric / Romanengo, Davide, Raso, Guido, Piermari, Pietro: Simulation and Forecasting in Intermodal Container Terminals, Switzerland: http://www.idsia.ch/~luca/ess96.pdf, 19.02.2007. Günter, Andreas (1995): KONWERK – ein modulares Konfigurierungswerkzeug, Deutsche Expertensystemtagung XPS 95, 1995. Günter, Andreas / Kühn, Christian (1999): Knowledge-Based Configuration – Survey and Future Directions, Berlin / Heidelberg: Springer Verlag, 1999. Hartmann, Andreas / Kaiser, Christian / Heitmann, Mark (2007): Produktkonfiguration online, Wist Zeitschrift für das Wirtschaftsstudium, 3, 2007. Hartmann, Sönke (2004): Generating Scenarios for Simulation and Optimization of Container Terminal Logistics, Kiel/Germany: OR Spectrum 26, Springer Verlag2004. Henesey, Lawrence / Davidsson, Paul / Persson, Jan, A.: Using Simulation in Evaluating Berth Allocation at a Container Terminal, Sweden: http://www.ide.hkr.se/~pdv/Papers/COMPIT2004.pdf, 19.02.2007. Jannach, Dietmar / Felfernig, Alexander / Kreutler, Gerold / Zanker, Markus / Friedrich, Gerhard (2006): Research Issues in Knowledge-Based Configuration, in: Blecker, Thorsten / Friedrich, Gerhard (2006): Mass Customization Information Systems in Business, London: Hershey, 2006.
Jørgensen, A., Kaj / Petersen, Ditlev, Thomas (2005): Product Modelling on Multiple Abstraction Levels, Proceedings of the International Mass Customization Meeting 2005 (IMCM'05). Berlin, Germany: Hamburg University of Technology, Germany; University of Klagenfurt, Austria, 2005. Krebs, Thorsten (2006): Evolution of Configuration Models- a Focus on Correctness, Germany: Proceddings of the ECAI 2006 Workshop on Configuration, Riva del Garda, Italy, 2006. Krebs, Thorsten / Hotz, Lothar / Ranze, Christoph / Vehring, Guido (2003): Towards Evolving Configuration Models, Germany: Proceedings of 17th Workshop Planen, Scheduling und Konfigurieren (PUK 2003) Hamburg, 2003. Lee, Tae-Woo / Park, Nam-Kyu / Lee, Dong-Won (2003): A simulation study for the logistics planning of a container terminal in view of SCM, Korea: Maritime Policy and Management, 30, 2003. Murty, Katta, G. / Liu, Jiyin / Wan, Yat-wah / Linn, Richard (2005): A decision support system for operations in a container terminal, Amsterdam: Decision Support Systems / Elsevier Science, 2005. Pestana Barros, Carlos / Athanassiou, Manolis (2004): Efficiency in european Seaports with DEA: Evidence from Greece and Portugal, Maritime Economics and Logistics, 6, 2004. Pumpe, Dieter (2000): Ein Referenzmodell zur Planung und Steuerung der Abläufe in SeehafenContainerterminals, Berlin: Technische Universität, 2000. SCUSY: http://www.isl.org/products/simulation.php?lang=de, 19.02.2007. Simcon: http://www.simcon.sk/, 19.02.2007. Steenken, Dirk / Voß, Stefan / Stahlbock, Robert (2004): Container Terminal operation and operations research – a classification and literature review, Berlin / Heidelberg: OR Specturm / Springer Verlag, 2005. Stumptner, Markus (1997): An overview of knowledge-based configuration, Amsterdam, AI Communications, IOS Press, 1997. Tongzon, Jose / Heng, Wu (2005): Port privatisation, efficiency and competitiveness: some empirical evidence from container seaports (terminal), Transportation Research Part A: Policy and Practice, 39, 2005. Transcare: http://www.transcare.de/tools/terminal-check/index.html, 19.02.2007. Wallace, M., Ken / Ahmed, Saeema (2004): Identifying and supporting the knowledge needs of novice designers within the aerospace industry, Journal of Engineering Design, 15, 2004. Wallace, M., Ken / Dwarakanath, K., Shantaram (1995): Decision-making in engineering design: Observations from design experiments, Journal of Engineering Design, 6, 1995. Wierzbicki, Andrzej, P. (2007): Modelling as way of organising knowledge, Poland: European Journal of Operational Research, 176, 2007. Yun, Won, Young (1999): A simulation model for container-terminal operation analysis using an object-oriented approach, Korea: International Journal of Production Economics, 59, 1999.
