International Journal of Operations & Production Management

Emerald Article: Using Simulation to Solve Design and Operational Problems K. Chaharbaghi

Article information:
To cite this document: K. Chaharbaghi, 1990"Using Simulation to Solve Design and Operational Problems", International Journal of Operations & Production Management, Vol. 10 Iss: 9 pp. 89 - 105 Permanent link to this document: http://dx.doi.org/10.1108/01443579010006163 Downloaded on: 18-07-2012 To copy this document: permissions@emeraldinsight.com This document has been downloaded 615 times since 2005. *

Users who downloaded this Article also downloaded: *

Purnendu Mandal, Biswajit Mahanty, 1990"Decomposition of Demand and Optimisation for a PerpetualInventory System", International Journal of Operations & Production Management, Vol. 10 Iss: 7 pp. 47 - 56 http://dx.doi.org/10.1108/01443579010003058 D.J. Smith, 1990"The Use of Microcomputer-based Simulation Models in theTeaching of Operations Management", International Journal of Operations & Production Management, Vol. 10 Iss: 5 pp. 5 - 14 http://dx.doi.org/10.1108/01443579010139760 N. Singh, Kwok Hung Shek, Dave Meloche, 1990"The Development of a Kanban System: A Case Study", International Journal of Operations & Production Management, Vol. 10 Iss: 7 pp. 28 - 36 http://dx.doi.org/10.1108/01443579010140498

Access to this document was granted through an Emerald subscription provided by OXFORD BROOKES UNIVERSITY For Authors: If you would like to write for this, or any other Emerald publication, then please use our Emerald for Authors service. Information about how to choose which publication to write for and submission guidelines are available for all. Please visit www.emeraldinsight.com/authors for more information. About Emerald www.emeraldinsight.com With over forty years' experience, Emerald Group Publishing is a leading independent publisher of global research with impact in business, society, public policy and education. In total, Emerald publishes over 275 journals and more than 130 book series, as well as an extensive range of online products and services. Emerald is both COUNTER 3 and TRANSFER compliant. The organization is a partner of the Committee on Publication Ethics (COPE) and also works with Portico and the LOCKSS initiative for digital archive preservation.
*Related content and download information correct at time of download.

Using Simulation to Solve Design and Operational Problems

K. Chaharbaghi
Middlesex Business School, London Introduction Over the past two decades radical changes have taken place within industry in order to make the production capability a formidable competitive weapon. These changes have involved a shift towards advanced technologies such as computer aided engineering and flexible automation[l] and organisational concepts such as just-in-time and total quality control philosophies [2]. There is little doubt that the production sector has moved into a new industrial era where advanced manufacturing technology will play a vital role. However, the operational and financial success of advanced production systems hinges on the sound integration of equipment and methods, monitoring and control. One of the predominant features of the new generation of production systems is the presence of a high level of integration and flexibility. These systems are capable of performing many production functions that are interdependent, often culminating in intricate interactions. Therefore, in planning the design and operation of one of these systems it is essential to consider it as a sophisticated whole rather than as a series of individual items of equipment and subsystems. Over a particular planning horizon, there are a number of configurations that are feasible technically. Each configuration will have different parameters with respect to the product range, processing sequences, machining systems, storage facilities, material handling systems, operational logic, expansion opportunities and a host of other parameters. The required planning task is to determine which of these configurations are operationally feasible and to select the one which meets the management's demands most closely. Clearly this cannot be based on ad hoc judgement due to the complex nature of the problem. It necessitates the application of a modelling technique that mimics the performance of the available configurations and forms a coherent approach for obtaining the most suitable strategy. Discrete event simulation has emerged as one of the most appropriate modelling tools to plan the design and operation of production systems. The purpose of this article is to provide an overview of this powerful modelling technique in the analysis of production systems. Emphasis is mainly placed on its relevance, application and implementation together with current simulation modelling environments and future simulation-based concepts and techniques. Relevance of Simulation in Problem Evaluation Due to the inherent complexity of the new generation of production systems, the

Design and Operational Problems 89

Received October 1989 Revised January 1990

IJOPM 10,9

90

development of an adequate formal modelling philosophy that creates a clear case for or against production strategies has been found by systems analysts to be difficult. The growing necessity for a detailed quantitative analysis of advanced production systems has led to the development of a number of modelling techniques. These techniques have been based on two fundamental notions. (1) A model represents a system or environment. Its accuracy and complexity depend on the factors considered and the assumptions employed. (2) A model is constructed to find a solution. On the basis of these two notions, two major categories of modelling tool have been developed for production systems: analytical and simulation. Analytical methods are those modelling tools that employ mathematical relationships to describe system characteristics. In most cases the diversity of production parameters and their interdependence complicates the task of analytical modelling. Many dynamic interactions within the process of production do not lend themselves to simple mathematical formulations. There also exist many causes of transience such as resource failures and supply shortages that are difficult to define within a mathematical methodology. Owing to these difficulties, the application of analytical methods entails a reliance on the use of an array of assumptions and approximations regarding the system characteristics [3,4,5,6,7]. Using these techniques, typical key assumptions employed include: service times are governed by exponential distributions, work stations possess perfect reliability, transportation times are fixed, systems are hypothesised as self-regulating (i.e. a fixed number of circulating parts are initially imposed and every finished part is replaced by an equal unprocessed one), queuing discipline is on the basis of a first come first served rule and no blocking can ever take place (i.e. no restriction on the size of buffer stocks). A number of attempts have been made to reduce the level of approximation employed, by removing some of these unrealistic assumptions[3,4,8,9]. However, with the ever-increasing complexity of today's production environments, these techniques are approaching the stage where the modelling activity is degenerating into a theoretical exercise with little practical end result. This is because these models bear little relationship to the real systems, which are complex. At the other extreme lies the simulation technique. Using this technique, no specific formulation is adhered to. The technique is based on the logical interpretation of a system's state which depends on time. An analogue of the system under study, whose characteristics are as similar to those of real life as possible, is set up and is then set in motion so that its behaviour can be

investigated over a desired period of time. In this way, solutions for complex production problems are obtained within an "assumption-free" framework. The appeal of analytical techniques, that encompass an array of assumptions, over simulation lies in the level of intelligence which they incorporate. They reduce the burden of decision making by developing a solution through the clarification of the intricate relationships that exist among the design parameters and performance measures. On the other hand, by its very nature, the simulation technique is incapable of creating its own solution and merely provides the results which correspond to the repercussions of the policies. The task of decision making is delegated to the decision maker who weighs the results and selects the configuration that satisfies the performance requirements best. From this consideration it can be seen that if the number of factors affecting the system performance under any given alternative is large, a gap-free analysis can only be performed after each alternative has been examined under all possible combinations of the interacting factors. With the incorporation of stochastic parameters, the problem is even further exacerbated by the necessity of taking representative random samples of the different measurements. Owing to the combinatorial difficulties associated with the simulation technique, in some cases the factorial experimentation is ruled out due to the resource and time constraints imposed on the design projects. Instead, selected alternatives are examined to highlight their merits as well to as to attempt to cast light on their unforeseen demerits. There is no question about the necessity of using simulation in planning the design and operational philosophy of advanced production systems since the study of important design issues such as internal and external perturbations and scheduling rules is well beyond the capabilities of the analytical techniques. Analytical tools, although useful in the study of production systems, cannot form the solitary foundation for a coherent design and operational philosophy. Applications Areas of Simulation in Analysis of Production Systems The objective of any series of simulation experiments is to determine the most suitable configuration for a system to achieve the stated goals. Due to the surrogate nature of simulation any number of experiments may be made with no effect on the real system. Because of this freedom to experiment and the prediction accuracy of the simulation technique, it is possible for system analysts to investigate large problem spaces and assess any proposed system. Thus simulation may be applied in many situations to address the key areas of system design and operation. The ability of a production system to achieve particular goals depends on two major criteria: design and operational control. The system design involves a trade-off between structure and adaptability. The structure reduces the need for intervention and interaction whilst adaptability demands the flexibility to respond to change. The operational control involves measurement, feedback, monitoring against expectation and correction. Thus, at the design and operation stages of production systems it is essential to define clearly the demands that will be placed on a system in order to achieve its stated goals. This necessitates that several planning considerations are carefully studied. These encompass:

Design and Operational Problems 91

IJOPM 10,9

92

Layout planning which is concerned with layout of the facilities within a system. Important considerations include the minimisation of work handling between machines and ensuring sufficient floor space for allocation of inventory. Capacity planning which relates to the determination of the absolute production capacity. Important considerations include trading off the benefits in response rate and throughput time, which are derived from having high capacity levels, with the cost of acquiring too much capacity and its consequent under-utilisation. Inventory planning which concerns creating a flow of items through the production system so that the actual output matches the required output at the right time. Important considerations encompass the balance of achieving the aims and minimising the cost incurred by the inventory levels. Resource planning which is concerned with providing sufficient resources that can achieve the production goals economically. Important considerations include ensuring that over-investment is avoided and operational problems such as queue formation are overcome. Reliability analysis which relates to the effect of prevalent transient occurrences. Important considerations encompass minimising perturbation caused by transient effects whilst casting light on the required costs to solve the perturbations. Scheduling analysis which relates to the determination of stringent rules that control production. Important considerations include that at no point in time does the system exhibit operational ambiguity and that the specified due-dates can be satisfied. None of these planning areas should be considered in isolation. They are all interrelated features that have major implications in the design and operation of any production system. Therefore the application of simulation encompasses all these planning areas. It is not in any way restricted to the design stage, but rather an ongoing activity extending from the initial design through to operation. Any information regarding a system may be retrieved from a running model. However, in the simulation of production systems to aid analysis, a set of measures of system performance effectiveness must be defined and retrieved from the simulation runs in order to highlight the merits and demerits of the configurations under investigation. The measures that have been employed to gauge the efficiency of production strategies include: Resource utilisation which is the ratio of the resource productive time to the total time under consideration. Manufacturing lead time which relates to the total time taken for a system to produce an order under consideration. Production rate which is the production output per given unit of time.

Work-in-progress inventory level which refers to the sum of all queue sizes contained in the system (this measure is often expressed as the monetary value of the in-process inventory). Queue time which relates to the amount of time spent by an order waiting for a particular resource (this is often represented as an average value). Scrap level which refers to the scrap produced due to factors such as in-process failure. Manufacturing capability (MC) which gives, for a particular job order, an indication of the degree to which perturbation causes such as machine failures affect the manufacturing lead time. It is calculated via the relationship:

Design and Operational Problems 93

Production efficiency (PE) which highlights, for a particular job order, the degree to which perturbation causes affect the production output. It is expressed as:

(When MC and PE equal unity it implies that the perturbation causes have no effect on the system capability to produce a particular job order while a value of these measures less than unity implies the reverse.) Demanded production lead time success ratio (DPLTSR) which indicates, for a particular job order, the degree of success in meeting the specified due-date. It is given by:

(A value of this measure less than unity indicates lateness in meeting the specified due-date while a value greater than unity implies the reverse. Clearly, if the management's objective is to achieve a just-in-time production philosophy then the value of this ratio for all jobs must be kept at unity. This is a very important issue as it will result in the minimisation of inventory costs as well as full customer satisfaction.)

IJOPM 10,9

The measures described above provide a good indication of system performance in many application areas of simulation. References[10-17] give detailed industrial examples where the concepts and measures presented in this section are demonstrated. Requirements for Successful Implementation of Simulation Projects In industrial environments, a simulation project may be initiated due to one of three major reasons. First, a system is already in existence but is experiencing undesirable effects where the remedies are not apparent (e.g. production bottlenecks, protracted manufacturing lead times and excessive work-in-progress inventory levels). Second, a system in existence appears to be satisfactory yet improvements in performance are deemed to be possible if operational changes are made. Third, a system is being designed and a full investigation of its performance is considered prudent both operationally and financially. However, a simulation project should only be initiated when a number of important factors have been comprehensively assessed. Of primary importance to any organisation initiating a project is whether it can be justified economically. It must be seen that the simulation project is a good insurance policy for the management and that the costs incurred by it will be recovered through savings on capital investment, reduction of inventory costs, improved performance, enhanced customer satisfaction etc. Furthermore, the project duration must be carefully considered because in today's dynamic environments it is likely that systems may be totally redefined within the time span of the project, thus making the outcome superfluous. Once the above considerations are closely examined and a decision is reached to proceed with a simulation project, a sound strategy must be adopted for its implementation. Simulation projects can become very lengthy, expensive and non-productive if they lack direction and are subject to poor control. In many organisations, there is a misconception that a simulation project is merely a programming activity. As a result, most simulation projects have simply comprised stages of computer code preparation and several runs of the constructed codes to obtain results. The very crucial issue of creating credible models, whose outcome will be accepted by its end-users, is often ignored. For the successful conclusion of a simulation project, extreme importance must be placed on the issue of communication. This ensures that a correct decision will be arrived at which is implemented confidently through the agreement of all concerned. Figure 1 outlines a strategy for conducting sound simulation projects. This strategy comprises three phases: definition, communication and model construction. With the above strategy the project commences by entering the definition phase. Here the aims of the project must be laid down by establishing the performance levels that are acceptable for the system to be investigated together with the nature of the decisions to be made. A set of performance criteria such as those given in the previous section should also be defined to judge the relative merits and demerits of differing system designs. An initial configuration, or a set of configurations, can then be proposed for investigation. The definition phase is finally completed by collecting the relevant data for the proposed configurations.

94

Design and Operational Problems 95

The project next enters the model construction phase. Here a diagrammatic modelling concept, which is easily interpreted and understood by all involved parties, should be employed to construct schematic models for the system configurations to be investigated. In the communication phase, through discussion and modifications to the schematic models, all the involved parties must arrive at a consensus over the

IJOPM 10,9

96

description of systems as well as the assumptions which have to be incorporated due to the unavailability of data. In the model construction phase, the approved schematic models are converted into representative computer models. Once prepared, the computer models must be verified to provide the necessary proof of their logical correctness and hence the validity of their applications. This can be achieved by closely examining the computer models to ensure that they are fault free. Further, the computer models can be given special instructions to output the behaviour of systems event by event over a short simulation period. The use of event by event output enables easy detection of any fault that is present in the computer simulation models. Through this thorough process of examination it can be certified that the constructed computer models perform their tasks as intended. The project re-enters the communication phase by presenting the results obtained from the verified codes. Here it must be pointed out that it is possible to extract a good deal of information from a simulation run of a computer model. Thus it is very easy to generate many pages of indigestible statistics regarding the simulated system during a simulation run. However, developments in the field of computer graphics have meant that techniques are increasingly more cost effective for the presentation of simulation output in graphical form. This is significant in terms of communication because visual presentation of data in graphical forms such as bar charts, pie charts and X-Y graphs is preferable to figures presented in tabular form. Of even more interest to the decision makers is the visualisation of the dynamic behaviour of the system under study. An animated presentation of the interaction of objects within a system presents the results of a simulation in a way that allows the decision makers to interpret the behaviour of the real system better. At this stage of the project the models have to be validated before basing the decision-making process on their outcome. To validate the models it must be seen that they closely represent reality. There are techniques that can be employed for this purpose. If the system under investigation is in existence then the predicted performance can be compared with the actual one. Alternatively for a system that is not in existence, it is necessary to make a subjective validation by assessing whether the results are realistic in terms of the analysts' experience of similar systems. The predicted performance corresponding to the validated models should be compared to see which system definition meets the required performance. If such a system definition can be found, the';simulation project is concluded. Otherwise the three phases of the outlined strategy may be repeated until a system definition is selected as the most appropriate. In Figure 1 attention is drawn to the roles of the modeller and the decision maker. There are basically three ways of filling these roles in simulation projects depending on the complexity of the system under investigation, the significance of the decision to be made and the availability of the simulation expertise. With the first alternative, both the decision-making process and modelling roles are taken by the same person. This may arise when short-term operational decisions

are assessed by an industrial engineer with simulation expertise. With the second alternative, the decision-making role is filled by a number of people amongst whom there is the relevant simulation expertise. This may arise when long-term strategic decisions for a system are examined by management and technical teams within an organisation. With the third alternative, the decision-making team contains no simulation expertise and so the modelling role is taken by an outside specialist. The two latter cases apply to most simulation projects. The most time consuming and costly area of simulation projects lies in the model building activity that occurs in the model construction phase. It is this activity which must be properly planned and monitored for the cost effectiveness of simulation projects. Figure 2 shows the approximate relationships that exist between the simulation project cost, system complexity and the frequency of simulation usage. Here it must be pointed out that the simulation cost is generally proportional to the time-span of the project. The main factors affecting this time span include modelling expertise and system complexity. Planes ABCD and WXYZ of Figure 2 reveal these relationships when the modelling task is carried out in-house and when it is delegated to an outside specialist respectively. In both cases, an increase in system complexity leads to an increase in project cost. This is clearly due to the increased time required for the modelling of more complex systems. When the modelling task is carried out in-house a general reduction of simulation cost will be experienced due to learning curve effects and the diminishing investment cost associated with the simulation software. However, if the modelling task is delegated to an outside specialist the cost of successive projects remains constant for systems of comparable complexity. The allocation of the modelling as an in-house or outside specialist task depends on the organisation's policy regarding simulation. It must be determined how frequently simulation is going to be used as a planning tool. Reference can then be made to the relative positions of planes ABCD and WXYZ of Figure 2 to determine whether the in-house modelling is more economical than the outside specialist option. The relative positions of planes ABCD and WXYZ are affected most acutely by the simulation software employed and as such these planes cannot be defined quantitatively. Nevertheless they can be viewed as a general concept varying from organisation to organisation. As highlighted in the introduction, manufacturing systems are growing in complexity. Further, due to the dynamic nature of today's manufacturing sector, systems are being reconfigured more frequently, not necessarily in terms of resources and equipment but rather in terms of product mix, production volumes, demanded lead times, production process alterations, etc. It is against these backgrounds that the application of simulation has dramatically increased. As a result, the in-house modelling approach has been gaining more popularity. Organisations have a wide choice of simulation software packages. The following section gives an overview of the current range of modelling environments that have been employed for discrete event simulation of manufacturing systems.

Design and Operational Problems 97

IJOPM 10,9

98

Discrete-event Simulation Modelling Environments A special purpose simulation software package is not essential for the implementation of a simulation project. It is possible to create a simulation model of a system using one of the high level general purpose languages such as Fortran, Pascal, etc. However, this demands a great deal of effort because details such as the organisation of time and activity, the naming and structuring of entities within the model and the testing of activities and conditions between elements, are required to be explicitly programmed. The growing cognisance of simulation as a powerful tool for system analysis has led to the development of many computer simulation software packages. The use of these obviates the need for the explicit programming of details on the modellers' part as the majority of them will be contained in the package itself. For discrete event simulation modelling, three distinct groups of software tools have been identified. These groups are shown in Figure 3. The reason for the division between these software tools is that differing levels of user friendliness and modelling flexibility have been incorporated in their design. This is symptomatic of many software developments, i.e. the more user friendliness is emphasised, the more frequently there is a trade-off against the flexibility or the capability of the software to deal with a variety of problematic situations. In the context of discrete event simulation, the general purpose high level languages (group 3 in Figure 3) offer the user the ultimate flexibility to model virtually any system. However, using these languages as stated above, a tremendous amount of effort is required to model a system. At the other extreme of these software tools lie simulation templates and interactive simulation

systems (group 1 in Figure 3) which provide the user with a high level of user friendliness at the expense of modelling flexibility.

Design and Operational Problems 99

Across the range of the three software groups outlined in Figure 3 there are over 100 different packages used for simulation purposes. An overview of representative software tools from groups 1 and 2 in Figure 3 is presented below. An Overview of Group 1 Type Simulation Software With this group of software the user is provided with either predefined simulation templates or an interactive system. With the former, the user employs special blocks that define typical features of the modelling environment. Representative examples of these, which are highly popular, include SLAM (process oriented approach)[18], SIMAN (process oriented approach)[19] and GPSS[20]. Interactive simulation systems transform a model presented in a relatively simple symbolism into a representative computer code. A typical example of these is the DRAFT[21] simulation software. These representative software tools are described to present the general features of group 1 simulation software. SLAM is a Fortran based simulation package and an acronym for "simulation language for alternative modelling". Using the process orientation of SLAM a network structure comprising specialised symbols is employed. These symbols which are called nodes and branches are combined to represent a process pictorially. There are approximately 20 node types in SLAM which facilitate modelling features such as objects entering or exiting the system, seizing or

IJOPM 10,9

100

freeing a resource, changing variable values and starting or stopping entity flow based on system conditions. The pictorial representation of a system is transcribed by the modeller into an equivalent statement model which serves as an inputfileto the SLAM processor. It must be pointed out here that with "the extended simulation system" (TESS)[22] the preparation of these input statements can be eliminated by constructing SLAM network models at the graphics terminal. The process orientation approach of SLAM to simulation modelling is user friendly but it does not offer the flexibility required in the modelling of complex systems[18]. Like SLAM, "simulation analysis" (SIMAN) is a Fortran based simulation software package. Using the process orientation of SIMAN a set of special block diagram symbols are used whose shapes indicate their functions. These symbols are combined by arrows to control the flow of entities block by block. The block diagrams may be entered to the SIMAN processor in either an interactive graphics mode or a batch mode via input statements. Using the interactive graphics mode the block diagram models are constructed directly on the computer terminal whereas, using statements, an equivalent block diagram input file is created. Like SLAM, the process orientation of SIMAN lacks the flexibility to model complex systems[19]. Like SIMAN, "general purpose simulation language" (GPSS) models a system in a block diagram format. The block diagram is a collection of characteristically shaped figures connected by directed line segments. There is a set of approximately 40 blocks associated with GPSS, whose shapes are predefined. GPSS has been developed over a long period of time, having been first introduced in 1961 by IBM. It is now available in a wide number of dialects. It is written in assembly language and was first designed for use by non-programmers. As a consequence it did not offer features found in many other programming languages. One significant feature that was not available was the ability to include subroutines in the program. For the analysis of small systems this was relatively unimportant. However, as the language was used for larger applications the lack of subroutine facility had to be overcome. The latest versions of GPSS offer a facility through a help block which gives the user the ability to invoke subroutines written in languages other than GPSS, usually in Fortran[23]. As such, GPSS exhibits much the same features as the process oriented SIMAN and SLAM simulation systems and is relatively poor in flexibility because of its rigid block represented structure[24]. DRAFT is an example of an interactive system which generates a simulation program from a simple graphical description of the logic of a discrete event queuing model. This graphical description is referred to as the entity cycle diagram and utilises three basic symbols: set, activity and flag (these symbols are explored in [25]). The procedure for inputting the data to the DRAFT system is relatively simple. The DRAFT system has been designed to generate simulation programmes in differing simulation languages. These include SIMON, SIMSCRIPT and SIMULA[26]. Although the DRAFT system shields the user from the intrinsic difficulties associated with general simulation languages, it can only handle simple queuing systems. For more complex systems, they

must befirstsimplified and then modifications to the generated program of the simplified system must be made to obtain an accurate representation of the reality. Depending on the capabilities of the target language, this can lead to substantial efforts being required. In conclusion, group 1 type simulation softwares are user friendly tools and are adequate for the analysis of manufacturing systems that are not too complex. However, for the analysis of more complex systems, either departure from them is necessary or the systems under study must be simplified through the use of assumptions. Other group 1 type simulation software packages include HOCUS[27], MAST[28] and INSPECT[29]. An Overview of Group 2 Type Simulation Software The group 2 type simulation softwares are either general purpose high level programming languages, which exhibit discrete event simulation features, or modules specially prepared for simulation tasks using a high level general purpose language such as Fortran. Examples of the former include SIMULA[30] and SIMSCRIPT[31]. Examples of the latter include SLAM[18], SIMAN[19] and SIMON[21,32] discrete event routines. SIMULA and SIMSCRIPT both have features such as the ability to define complex data structures, allocate memory dynamically and handle lists, shown in most of the general purpose high level languages. They also have built-in features which are concerned with simulated system time[33,34,35,36]. Each language provides a clock and maintains a list of event notices in chronological order. Because of these features they are slightly higher level languages than say Fortran. It is, however, the responsibility of the programmer to define and implement any structure for a simulation model. SIMULA is not a fully fledged simulation language but rather that it is a kernel in which to write application languages or contexts[33]. As a result of the need for the programmer to define the structure, it has been found that few contexts are used frequently and according to Birtwistle[33] many are badly structured. Neither language has any associated means of defining a system schematically to aid the conversion from system definition to representative computer program. SLAM, SIMAN and SIMON discrete event Fortran routines are mathematical/ logical expressions that perform event modelling functions such as queue manipulation, event scheduling, controlling the time mechanism and observation recording for output. The discrete event orientation offered by these routines must be applied to gain the flexibility not given by the group 1 type simulation software. However, there is a penalty to be paid in terms of modelling effort. In order to model features such as transient effects, complicated operation jumping and scheduling rules, which may potentially be part of more complex systems, it is necessary for the modeller to go de per into the structure and deal directly with event calendars and system variables using the base language which is usually Fortran. Thus there is a higher likelihood that the model development time span will be considerably extended due to the extensive debugging and error checking required. In conclusion, group 2 type simulation softwares a e flexible environments for

Design and Operational Problems 101

IJOPM 10,9

102

discrete event simulation purposes. However, they require programming effort and technical expertise. GASP IV[37] is another example of group 2 type simulation software. "Dynamic systems simulation language" (DSSL)[38] is a recent development in discrete event simulation modelling. It has been devised to model complex environments with a view to retaining the flexibility level of the group 2 type simulation software whilst moving towards the user friendliness offered by the group 1 type modelling tools. In its development, the provision of a means of communication for the participants of simulation projects has also been borne in mind. Using DSSL, discrete systems are modelled in two stages. In the first stage, the use of a few rationalised blocks (less than ten) is made to construct a diagrammatic model which fully represents the operational logic of the system under study. In the construction of the diagrammatic model the user is given the versatility of defining the interactions of objects within a system as well as the rules that govern the initiation, discontinuation and prioritisation of functions performed by the objects in any desired way. The diagrammatic models provide a basis on which the participants of simulation projects with or without programming knowledge can communicate. The second stage of modelling involves combining a set of Fortran based modules using an associated logical structure. The resulting computer model mirrors the diagrammatic model. The vocabulary and grammar of DSSL is well defined, enabling the modeller to perform the transcription process efficiently and accurately. The use of Fortran as the base language gives the user the flexibility of inputting any desired value for system parameters from tailor-made data files, changing the value of system parameters while the model is in motion, retrieving any desired information from the model and obtaining any performance measure of interest within the simulation model. Therefore, DSSL provides a versatile framework in which trustworthy models of complex environments are readily constructed in an assumption-free manner. In practice, the choice of the simulation software is usually resolved by the software available to the user or by the availability of the modelling expertise in a particular software. However, where there is a choice, a number of packages must be carefully assessed because it may be found at a later stage in any project that substantial effort has been invested in a methodology which proves incapable of modelling all the required features of the system under study. Research Directions Hitherto most research and development work has been directed towards the modelling aspect of simulation in order to reduce the effort involved in model construction which forms the major part of most simulation projects. Not surprisingly, as indicated above, numerous simulation software systems have been developed with varying degrees of user friendliness and flexibility. In brief, the state-of-the-art of simulation from the modelling angle looks relatively healthy and there is no doubt that in future the capabilities of existing simulation modelling methodologies will be improved by the incorporation of additional features such as better error checking and debugging facilities and enhanced graphic systems

for output representation. However, apart from the modelling there is another important side to simulation. This is concerned with system analysis and it is this aspect of simulation which is now gaining research momentum. The work in this field can be categorised into two groups: user oriented and application oriented. The former relates to the development of techniques which minimise the effort required to analyse systems for the attainment of the required goals or an optimum configuration according to a specified set of criteria. The application oriented research is concerned with the development and validation of new generalised operations and production management concepts and rules for the improved performance of a variety of systems. The major limitation of the simulation technique is that it does not provide a solution. Using simulation, the most commonly employed approach in problem evaluation is that of constructing a number of models for different configurations and comparing the results in order to arrive at a solution. This approach to system analysis usually culminates in a prolonged decision-making process because the study of highly complex simulation results is very time-consuming. The problem is further exacerbated due to the intensive computational time involved in simulation runs. As a result, the above approach is impractical for solving complex problems of a combinatorial nature which are pressing and require an immediate answer. To overcome this problem the decision-making process must be automated by furnishing the simulation media with an intelligent mechanism which is capable of interpreting the knowledge generated by the simulation regarding the behaviour of the system, drawing inferences, searching for a solution, finding an appropriate level for system parameters that result in optimum performance according to a set of specified criteria, making recommendations and highlighting how such conclusions have been arrived at. Such capabilities will not only provide the management with a comprehensive decision support system but also minimise the effort required to perform the analysis. One of the strengths of the simulation technique is that it gives the user the freedom to experiment with any desired configuration for a system or environment. This, coupled with the predictive accuracy, enables the researchers in the operations and production management field to study a number of problematic dimensions and try numerous ideas without the need to implement them in real life and hence experience possible adverse effects. In this way new knowledge will be gained which is global in terms of applicability and can be applied to a variety of systems or environments. The objective should be the establishment of concepts which will culminate in the most cost effective method of operating systems while placing special emphasis on satisfying the output goals such as due-date requirements. It is conceivable that given current computing power the application of such concepts might be limited due to the high computational requirements associated with the simulation technique. However, considering the current rate of advancement in computing technology, this should be overcome thus enabling these concepts to be applied effectively. It is to be hoped that the fascination with the combinatorial nature of today's complex design and operational problems and the desire continuously to improve the performance levels of systems

Design and Operational Problems 103

IJOPM 10,9

together with the rapid advancement in computing technology will narrow the gaps over the next decade in the broad and exciting areas of research highlighted above.
References
1. Spur, G., "Growth, Crisis and Future of the Factory", Robotics and Computer-Integrated Manufacturing, Vol. 1 No. 1, 1984, pp. 21-37. 2. Hammond, R.W., "Utilising Manufacturing Excellence Concepts for the Successful Application of Shop Floor Technologies", AUTOFACT Conference Proceedings, 1988. 3. Dupont-Gatelmand, C , "A Survey of Analytical and Simulation Models for the Design and Control of Flexible Manufacturing Systems", Manufacturing Systems, Vol. 12 No. 2, 1983, pp. 157-64. 4. Buzacott, J.A., "Modelling Manufacturing Systems", Robotics and Computer-Integrated Manufacturing, Vol. 2 No. 1, 1985, pp. 25-32. 5. Valcada, A., Mastretta, M. and Aicardi, M., "Comparison of Different Computerised Design Tools for Flexible Manufacturing", Proceedings of the Third International Conference on Flexible Manufacturing Systems, 1984. 6. Solberg, J.J., "Analytical Performance Evaluation for the Design of Flexible Manufacturing Systems", Proceedings of the 17th Institute of Electrical & Electronics Engineers Conference on Decision and Control, 1979. 7. Suardo, G.M.S., "Workload Optimisation in a FMS Modelled as a Closed Network of Queues", Annals of the CIRP, Vol. 28 No. 1, 1979, pp. 381-3. 8. Dubois, D., "A Mathematical Model of a Flexible Manufacturing System with Limited In-process Inventory", European Journal of Operational Research, Vol. 14 No. 1, 1983, pp. 66-78. 9. Gershwin, S.B. and Ammar, M., "Reliability in Flexible Manufacturing Systems", Proceedings of the 18th Institute of Electrical & Electronics Engineers Conference on Decision and Control, 1979. 10. Chaharbaghi, K., Davies, B.L. and Rahnejat, H., "Application of Simulation in Planning the Design of Flexible Assembly Systems", Proceedings of the Fourth Conference on UK Research in Advanced Manufacture, Institute of Mechanical Engineers, 1986. 11. Browne,J. and Davies, B.L., "A Preliminary Review of Batch Sizes in a Job Shop Using a Digital Simulation Model", Simulation, Vol. 41 No. 4, 1983, pp. 149-53. 12. Chaharbaghi, K. and Davies, B.L., "The Analysis of Flexible Manufacturing Systems for Reliability", International Journal of Advanced Manufacturing Technology, Vol. 1 No. 4, 1986, pp. 79-100. 13. Chaharbaghi, K., Davies. B.L. Sparshot, D.I. and Janes, P., "Planned Flexibility: The Key to Improved Production", International Journal of Advanced Manufacturing Engineering, Vol. 1 No. 3, 1989, pp. 155-64. 14. Chaharbaghi, K., Davies, B.L. and Minett, S.C., "Planning for Just-in-time Production", International Journal of Computer Integrated Manufacturing, Vol. 2 No. 5, 1989. 15. Chaharbaghi, K., Davies, B.L., Rahnejat, H. and Dobbs, P.J., "An Expert System Approach to Discrete-Change Simulation", International Journal of Operations & Production Management, Vol. 8 No. 2, 1988, pp. 14-34. 16. Barrett, R.T. and Barman, S., "A SLAM II Simulation Study of a Simplified Flow Shop'', Simulation, Vol. 47 No. 5, 1986, pp. 181-9. 17. Schroer, B.J., Black, J.T. and Zhang, S.X., "Just-in-Time, with Kanban, Manufacturing System Simulation on a Microcomputer", Simulation, Vol. 45 No. 2, 1985, pp. 62-70. 18. Pritsker, A.A.B., Introduction to Simulation and SLAM II, Systems Publishing Corporation, 1984.

104

19. Pegden, CD., Introduction to SIMAN, Systems Modelling Corporation, 1984. 20. Shriber, T., Simulation Using GPSS, John Wiley & Sons, New York, 1974. 21. Mathewson, S.C., DRAFT II/SIMON Manual, Department of Management Science, Imperial College of Science and Technology, 1982. 22. Standridge, C.R., "Performing Simulation Projects with the Extended Simulation System (TESS)", Simulation, Vol. 45 No. 6, 1985, pp. 283-91. 23. Henriksen, J.O., "State-of-the-Art GPSS", Proceedings of the 1983 Summer Computer Simulation Conference, 1983. 24. Rahnejat, H., "Simulation Aids Design for Flexible Automation", International Journal of Advanced Manufacturing Technology, Vol. 1 No. 2, 1986, pp. 91-108. 25. Poole, T. and Szymankiewicz, J., Using Simulation to Solve Problems, McGraw Hill, 1977. 26. Mathewson, S.C., "The Application of Program Generator Software and Its Extensions to Discrete Event Simulation Modelling", IIE Transactions, Vol. 16 No. 1,1984, pp. 3-18. 27. Kochan, A., "HOCUS Takes the Risk out of Planning FMS", FMS Magazine, Vol. 2 No. 2, 1984, pp. 91-3. 28. Lenz, J.E., "MAST: A Simulation Tool for Designing Computerised Metal Working Factories", Simulation, Vol. 40 No. 2, 1983, pp. 51-8. 29. Peck, S.N., "Intermediate Generality Simulation Software for Production", Journal of Operational Research Society, Vol. 36 No. 7, 1985, pp. 591-5. 30. Birtwistle, G.M., Discrete Event Modelling on SIMULA, MacMillan Press, 1979. 31. Russell, E.C., "Building Simulation Models with SIMSCRIPT II.5", CACI, 1983. 32. Hill, P.R., "SIMON - A Computer Language in ALGOL", in Hollingdale, S.H. (Ed.), Digital Simulation in Operational Research, English Universities Press, 1967. 33. Birtwistle, G.M., "The Design Decisions behind DEMOS", Proceedings of the 1981 UKSC Conference on Computer Simulation, 1981. 34. Eklundh, B., "SIMULA - A Way of Thinking", Proceedings of the 1979 Winter Simulation Conference, 1979. 35. Vaucher, J.G., "A 'Wait Until' Algorithm for General Purpose Simulation Languages", Proceedings of the 1973 Winter Simulation Conference, 1973. 36. Maryanski, F.J., Digital Computer Simulation, Hayden Book Company, 1980. 37. Pritsker, A.A.B., GASP IV Simulation Language, John Wiley & Sons, New York, 1974. 38. Chaharbaghi, K., DSSL II Reference Manual, 1989.

Design and Operational Problems 105